Маршрутизация и сигнализация

Технология ATM основывается на установлении соединений, поэтому данные нет необходимости маршрутизировать на всем пути, а достаточно выполнить маршрутизацию запросов на организацию виртуальных соединений.

Сама концепция ATM стимулирует постоянное увеличение размеров сетей, построенных на базе этой технологии. Данное обстоятельство связано с тем, что в ее основе заложены возможности скоростной передачи больших массивов данных. Это позволяет проводить объединение отдельных, территориально-разнесенных сетей организации в единую корпоративную сеть. Впоследствии, по мере удешевления устройств ATM, технология ATM станет все активнее применяться не только в центральной части, но и на периферии, что приведет к формированию сложной, смешанной топологии.

В отличие от большинства сетевых технологий, ATM использует стратегию передачи с установлением виртуального соединения. Если отправитель намеревается передавать данные в такой сети, то он должен послать запрос с адресом получателя, заявить требуемое качество обслуживания и т. д. Процесс передачи собственно данных начнется только тогда, когда отправитель получит извещение о том, что получатель готов принимать его данные и что виртуальное соединение может быть установлено с запрошенными параметрами.

Естественно, в сложной корпоративной сети организация связи между абонентами может потребовать одновременного установления множества виртуальных соединений. В таких условиях приоритетной задачей является определение оптимального маршрута между каждой парой абонентов. При этом следует помнить, что виртуальное соединение запрашивается со вполне определенным качеством услуг. Т. е. такая сеть живет достаточно сложной внутренней жизнью: кто-то запрашивает соединение, кто-то производит передачу данных по уже установленному соединению, кто-то требует закрытия соединения и т. д. Для решения каждой из этих задач существует свой протокол. В рамках данной статьи мы рассмотрим только те действия, что предшествуют установлению виртуального соединения. За маршрутизацию запросов на открытие виртуальных соединений отвечает протокол PNNI (Private Network-to-Network Interface).

Маршрутизация запросов на установление виртуальных соединений - ответственная задача. Маршрут, по которому протокол PNNI отправляет запрос до получателя, в дальнейшем преобразуется в виртуальное соединение. Задача усложняется по мере роста сети, числа коммутаторов и абонентов в ней. В такой сети возможных маршрутов между абонентами друг с другом может быть множество.

Форумом ATM в апреле 1996 года была завершена разработка первой редакции (фазы) протокола PNNI. На этом этапе протокол состоит из двух частей: протокола маршрутизации и протокола сигнализации. В процессе разработки протокола PNNI основным условием было выдвинуто достижение результата с максимальной эффективностью. С этой целью разработчиками были привлечены различные алгоритмы и методы, зарекомендовавшие себя в других сетевых протоколах, как-то: маршрутизация от источника, формирование иерархической структуры и алгоритм состояния канала.

ИЕРАРХИЧЕСКАЯ АДРЕСНАЯ СХЕМА

Основной задачей протокола маршрутизации является распространение информации о текущей сетевой топологии между коммутаторами и группами коммутаторов в сети. Эта информация затем используется коммутаторами для определения оптимального маршрута к получателю запроса. Немаловажно, что этот маршрут должен отвечать запрошенным требованиям к качеству услуг.

Основу протокола маршрутизации составляет алгоритм определения состояния канала. Этот алгоритм отличается масштабируемостью, малым временем восстановления после изменений в топологии сети и небольшим служебным трафиком. В добавление к этому алгоритму протокол PNNI включает в себя два расширения, с целью его адаптации к современным сетевым технологиям, - поддержку качества услуг и способность формирования иерархических структур. Благодаря добавлению возможности формирования иерархических структур протокол PNNI может эффективно работать в сетях практически любой степени сложности и размера.

В сети, поддерживающей протокол PNNI, маршрутизация запросов выполняется на основании первых 19 байт адреса ATM (напомним, что весь адрес состоит из 20 байт). Последний, двадцатый, байт используется внутри конечной системы для идентификации протоколов верхних уровней и приложений. Каждый коммутатор в сети (или узел в терминологии протокола PNNI) имеет уникальный 22-байтовый идентификатор (node ID), основу которого составляет ATM-адрес коммутатора.

В протоколе PNNI отдельные узлы объединяются в группы (в этом они аналогичны областям маршрутизации протокола OSPF). Каждая из них идентифицируется с помощью 14-байтового идентификатора группы (group ID). Все узлы в одной группе должны иметь один и тот же идентификатор, причем последний формируется на основе ATM-адреса коммутатора.

Связь между адресацией и идентификацией группы очень простая. Для того чтобы каждая сеть была легко администрируемой и масштабируемой, адреса должны присваиваться таким образом, чтобы место нахождения любого узла можно было однозначно определить по его адресу. Объединение узлов в группы подразумевает присвоение им единого адресного префикса, уникального для данной группы.

Анализ такого адресного префикса позволяет и администратору и протоколу маршрутизации однозначно определять расположение узлов в сети. Информация об уровне иерархии протокола закладывается в состав адресного префикса.

Давайте рассмотрим приведенную концепцию адресации на примере (см. Рисунок 1). Администратор определил адресную схему, при которой первые 12 байт адреса ATM являются общими для всех узлов в группе.

В рассматриваемом примере символ "A" представляет эти 12 байт (например, А = 39.9.9.9.9.9.9.0.0.9.9.0). Тринадцатый байт адреса ATM служит для идентификации коммутаторов в группе. Коммутаторы имеют адреса A.1, A.2, A.3, А.4. Следующие шесть байт ATM-адреса используются в качестве идентификатора конечной системы (End System Identifier, ESI).

Конечная система, подключенная к коммутатору с адресным префиксом A.4, может иметь адрес {A.4.2.3.4.1.1.1}, где {2.3.4.1.1.1} - это ее идентификатор. Как уже было отмечено ранее, двадцатый байт используется конечной системой для идентификации протоколов высших уровней и не указывается в явном виде. Рассмотренный пример наглядно демонстрирует, что благодаря простой и логичной конфигурации ATM-адресов сеть становится более управляемой и масштабируемой.

HELLO, MY DARLING!

Для получения информации о текущем состоянии своих соседей коммутаторам приходится постоянно обмениваться между собой специальными сообщениями. В протоколе PNNI эту функцию выполняет "протокол приветствия" (Hello Protocol).

Получаемые от соседних коммутаторов сообщения этого протокола служат для подтверждения их работоспособности и функциональности протокола PNNI. В состав сообщения протокола приветствия входит идентификатор группы, к которой принадлежит отправитель данного сообщения. Это позволяет соседним коммутаторам удостовериться, что они принадлежат к одной и той же группе. После подтверждения факта принадлежности к одной группе коммутаторы будут включать в исходящие сообщения дополнительно к идентификатору узла идентификатор своего порта, с которого это сообщение отправлено.

После того как идентификатор узла и идентификатор порта соседнего узла были установлены, они также будут возвращаться в исходящих сообщениях. В результате после получения сообщения с локальной и удаленной идентификационной информацией узел будет знать, что обмен сообщениями был успешен и данный канал связи можно использовать для решения задач протокола PNNI (см. Рисунок 2).

КАЖДОМУ УЗЛУ ПО ЭЛЕМЕНТУ!

Протоколом PNNI собирается такая информация о маршрутной топологии сети, как данные об узлах, каналах связи и доступных адресных префиксах. Кроме того, эта информация включает скорость передачи данных, задержку и т. д., т. е. те параметры, которые сеть может гарантировать. Дополнительно администратор имеет возможность назначать приоритеты некоторым маршрутам.

Еще раз напомним, что под узлом в PNNI понимается коммутатор, а не конечная система. Иными словами, конечная система не включается в топологию маршрутизации запросов. Адреса, присвоенные конечным системам, объединяются в так называемый доступный адресный префикс, рекламируемый коммутатором, к которому эта система подключена. Запрос на установление виртуального соединения с конечной системой по заданному адресу следует через сеть до указанного коммутатора, а он передает сигнал конечной системе.

Как уже было отмечено, маршрутизация в протоколе PNNI основывается на алгоритме состояния канала. Каждый узел порождает запись с описанием "видимой" им части его локальной топологии, т. е. данные о себе, сведения об исходящих каналах и все адресные префиксы, на основании которых другие могли бы судить о доступности этого узла. В терминологии протокола PNNI эти записи называются элементами состояния топологии (PNNI Topology State Element, PTSE). Если узел имеет все элементы PTSE об узлах своей группы, то он может вычислить маршрут для любого адреса этой группы.

Благодаря наличию взаимосвязи между элементами PTSE, они могут быть явным образом использованы в целях маршрутизации. Доступный адресный префикс имеет смысл только в случае наличия элемента PTSE с описанием узла, для которого этот префикс определен.

Аналогично канал связи может быть задействован только в том случае, если элементы PTSE определены для обоих узлов на его концах и если элементы PTSE описывают этот канал в обоих направлениях. Нужно отметить, что узел создает элементы PTSE для своих исходящих каналов, и, следовательно, два элемента PTSE, описывающие оба направления канала, создаются каждым из узлов по обоим концам канала.

Рассмотрим пример, поясняющий связь между физической сетью и описывающими ее элементами PTSE. Предположим, что существует группа, в которой все адреса имеют общий 12-байтовый префикс и в которой работают два коммутатора с адресами А.1 и А.2 (см. Рисунок 3).

Конечные системы, подключенные к этим двум коммутаторам, имеют адреса А.1.0.0.0.0.0.1 и А.2.7.6.5.4.3.2 соответственно. Узел А.1 формирует три элемента PTSE, описывающие "видимую" им топологию. Первый элемент - для описания самого узла, второй - для описания канала связи от его шестого порта к третьему порту узла А.2, и третий элемент - для описания доступности адреса. Аналогично узел А.2 формирует свои три элемента PTSE.

Чтобы любой узел в сети мог вычислить маршрут, информация о топологии (т. е. элементы PTSE) должна быть известна каждому узлу. Более того, параметры качества услуг (например, пропускная способность канала и задержка) могут меняться при установлении и после закрытия виртуальных соединений, поэтому информация о топологии должна периодически обновляться. Постоянное обновление информации необходимо для учета реальной сетевой топологии при вычислении маршрута. Протоколом PNNI поддерживаются два способа распространения элементов PTSE в сети - начальный обмен информацией о сетевой топологии и механизм веерной рассылки (flooding). Рассмотрим эти способы более подробно.

При активизации узел не обладает информацией о топологии сети и, следовательно, не может вычислять маршруты. Это, в свою очередь, означает, что он не может обрабатывать запросы на установление виртуальных соединений. После обмена приветствиями эти два узла синхронизируют информацию о сетевой топологии для уменьшения времени нахождения в таком состоянии, т. е. обмениваются своими наборами элементов PTSE. Во время синхронизации каждый узел посылает другому обобщенную информацию об имеющихся у него элементах PTSE. Отсутствующую у них информацию узлы могут запросить у соседей.

Во время работы сети ее состояние постоянно меняется. Одни узлы активизируются, другие выходят из строя, каналы связи становятся недоступными, загруженность узлов и каналов меняется (в зависимости от трафика и т. д.).

Изменения в любой части сетевой топологии приводят к тому, что затронутый ими узел создает новые элементы PTSE (например, элементы для нового канала связи) или обновляет имеющиеся (скажем, при изменениях параметров качества обслуживания). Новые и измененные элементы PTSE передаются всем соседям этого узла: последние сохраняют новую информацию, а затем передают ее далее всем своим соседям. Благодаря такой схеме новая информация быстро распространяется по всей группе. Для повышения надежности узел обязан подтвердить получение новых элементов PTSE. Данный процесс и носит название веерной рассылки.

После того как узел получил, сохранил и разослал далее новые элементы PTSE, любые последующие их копии удаляются по получении. В результате процесс веерной рассылки определенного элемента PTSE закончится, когда его получат все узлы.

Следует отметить, что только значительные изменения в сетевой топологии приводят к рассылке новой информации. Это позволяет контролировать загруженность сети служебным трафиком и регулировать нагрузку на коммутаторы. Возможность контроля нагрузки на коммутаторы важна тем, что при получении новой информации маршруты в сети может понадобиться определять заново, а это потребует дополнительных ресурсов коммутаторов.

НЕ ТАК ВАЖЕН АДРЕС, КАК ЕГО ПРЕФИКС!

Коммутаторы в сети ATM рекламируют доступность всех подключенных к ним объектов, в том числе адреса всех подключенных конечных систем и адреса в других сетях. В крупных сетях коммутатор не в состоянии рекламировать доступность каждого индивидуального адреса. В подобных случаях он рекламирует адресные префиксы и таким образом сообщает о доступности совокупной области всех адресов, разделяющих данный префикс.

Механизм обобщения адресов в протоколе PNNI основан на генерации адресных префиксов, которые и рекламируются коммутатором. При проверке коммутатором факта доступности определенного адреса, он сопоставляет его с обобщенными адресами. Если префиксы совпадают, то рекламируется именно обобщенный адрес, а не все известные адреса с тем же префиксом.

Адреса с одним и тем же префиксом называются родными адресами (native address). Если адрес не соответствует какому-либо обобщенному адресу, то его необходимо рекламировать индивидуально. Такой адрес называется чужим адресом (foreign address).

Протокол PNNI также оперирует понятием ограничивающего обобщенного адреса с целью контроля за распространением информации о доступности адреса. При регистрации адреса, префикс которого совпадает с ограничивающим адресом, этот адрес не будет рекламироваться коммутатором. В ситуациях, когда более чем один обобщенный или ограничивающий адрес совпадает с данным адресом, определение подходящего обобщенного или ограничивающего адреса производится в соответствии с механизмом наибольшего совпадения адресного префикса.

Рекламируя свои собственные 13 байт адресного префикса, коммутатор одновременно рекламирует доступность всех подключенных к нему конечных систем. Это возможно благодаря тому, что адреса конечных систем формируются в результате объединения 13 байт адресного префикса коммутатора и 6 байт собственных идентификаторов.

Приведенные выше рассуждения можно проиллюстрировать рисунком (см. Рисунок 4). Все адреса в группе имеют один общий адресный префикс А. Коммутаторы имеют адреса А.1, А.2, А.3, A.4. Т. е. каждая конечная система, подключенная к коммутатору А.4, имеет адрес А.4.Х, где Х - ее идентификатор.

Каждый коммутатор автоматически создает 13-байтовый обобщенный адрес на основании своего ATM-адреса (например, А.1, А.2) и рекламирует его доступность при помощи элемента PTSE, в котором этому обобщенному адресу соответствует доступный адресный префикс.

Иногда адрес конечной системы может иметь иной префикс, нежели коммутатор. Так, сервер конфигурации LANE может использовать адрес независимо от того, к какому коммутатору он подключен. Такое решение является оправданным, так как иначе клиентам потребуется изменять конфигурацию каждый раз, как только сервер изменит свое местоположение в сети.

Если коммутатор имеет канал связи с другой сетью ATM, то одним обобщенным адресом не обойтись. В рассматриваемом примере коммутаторы А.2 и А.4 подключены к другой сети ATM, в которой все адреса имеют префикс 39.9.1. Кроме того, коммутатор А.4 подключен к определенной части этой сети, адреса которой имеют префикс 39.9.1.1.

Информация об этих обобщенных адресах заносится в базу коммутаторов А.2 и А.4. В результате запрос на установление виртуального соединения по адресу 39.9.1.1.Х будет передан коммутатору А.4, а затем - в подключенную сеть. Запрос по адресу 39.9.1.2.х будет передан на коммутатор А.2, а затем - в другую сеть.

Данный пример показывает эффективность использования обобщенных адресов и маршрутизации запросов на основе наибольшего совпадения префиксов. С помощью настройки обобщенных адресов связь во всей сети обеспечивается с небольшими накладными расходами, а выбор более узкого обобщенного адреса (например, 39.9.1.1) позволяет оптимизировать маршрутизацию запросов.

ПОЧЕТНЫЙ ПРЕДСТАВИТЕЛЬ...

Размер группы в протоколе PNNI ограничен лишь объемом доступной памяти и мощностью процессоров коммутаторов. Каждый узел, канал связи и доступный адресный префикс повышают объем хранимой информации о топологии группы и, следовательно, требуют дополнительных ресурсов коммутаторов. Кроме того, рост размеров группы приводит к увеличению времени расчета маршрутов при передаче запросов.

Для лучшей масштабируемости сети протокол PNNI поддерживает механизм иерархического построения сети, благодаря которому она может обслуживать практически неограниченное количество каналов связи и узлов в сети и при этом задействовать ограниченные ресурсы коммутаторов.

При построении иерархии каждая группа может иметь представителя в виде логического узла (Logical Group Node, LGN), расположенного на следующем, более высоком уровне иерархии. Рассмотрим пример, в котором 10 узлов организованы в две группы (см. Рисунок 5). Узлы X.Y.1, X.Y.2 и т. д. представлены логическим узлом X.Y, а узлы X.Z.1, X.Z.2 и т. д. - логическим узлом X.Z.

Логические узлы связаны двумя логическими каналами, соответствующими каналам связи между группами (каналы от X.Y.2 до X.Y.1 и от X.Y.3 до X.Z.2). Следует отметить, что логические узлы и каналы между ними не являются реальными узлами и каналами связи, это скорее элементы PTSE, которые создаются для формирования иерархии.

Протокол приветствия между узлами в различных группах (например, между X.Y.3 и X.Z.2) автоматически определяет каналы, связывающие две различные группы. Эта информация затем используется для создания каналов между логическими узлами. Логический узел, представляющий группу, должен обладать информацией о доступности всех адресов в данной группе. Продолжая построение иерархической структуры, логические узлы могут сами формировать группы.

Все узлы в группе владеют информацией о топологии своей группы - о каждом узле, канале и доступном адресном префиксе. Однако узлы не обладают информацией о топологии других групп. В рассматриваемом примере узел X.Y.1 владеет информацией об узлах X.Y.2, X.Y.3 и X.Y.4 и каналах связи между ними, но ничего не знает о других узлах и каналах в соседней группе.

Узлы в нижних по уровню группах имеют информацию о логических узлах в верхних по уровню группах. Так узел X.Y.1 знает о логическом узле X.Z и о двух каналах между его группой и логическим узлом X.Z. Узел X.Y.1 владеет также информацией о доступности адресов в логическом узле X.Z.

Если узлу X.Y.1 необходимо найти маршрут для передачи запроса по адресу X.Z.6.x, то он выберет маршрут до логического узла X.Z через узлы X.Y.2 или X.Y.3, каждый из которых имеет канал до X.Z. По достижении запросом на виртуальное соединение узла X.Y.2 или X.Y.3, он будет передан соседней группе через узел X.Z.1 или X.Z.2 соответственно. Первый узел в группе, получивший запрос (т. е. X.Z.1 или X.Z.2), будет вычислять маршрут до получателя (X.Z.6), используя имеющуюся детальную информацию о топологии этой группы.

Как видно из примера, запрос может быть доставлен узлу в другой группе даже при отсутствии детальной информации об ее топологии. Это позволяет значительно сократить необ-

ходимую в общем случае информацию о топологии, так как узлы вне какой-либо группы "видят" только один логический узел, представляющий такую группу.

Логические узлы (например, X.Y и X.Z) могут быть, в свою очередь, представлены другим логическим узлом

на более высоком уровне иерархии протокола PNNI. Повторяя этот процесс объединения информации о топологии на каждом уровне иерархии, протокол может масштабироваться до практически неограниченных размеров.

Задача создания элементов PTSE с описанием логического узла, каналов и доступности адресов для группы более высокого уровня выполняется одним из реальных узлов в определенной группе, называемым лидером группы (Peer Group Leader, PGL). Системный администратор может задать, какой узел будет выполнять функции PGL. Например, это может быть узел с наибольшей вычислительной мощностью.

ПРИНЦИПЫ СИГНАЛИЗАЦИИ

Вторая часть протокола PNNI - протокол сигнализации - контролирует установление и завершение коммутируемых виртуальных соединений двух типов: "точка-точка" и "точка-группа". Протокол сигнализации PNNI базируется на спецификации UNI 3.1 и 4.0 с добавлением механизмов поддержания маршрутизации запросов на соединение через сеть и определения альтернативных маршрутов в случае неудачи с первым запросом.

Протокол сигнализации PNNI базируется на технологии маршрутизации от источника, и, следовательно, первый (входящий) коммутатор будет вычислять маршрут через всю сеть ATM до последнего (выходящего) коммутатора, который рекламировал свою связь с требуемой частью сети.

Для реализации маршрутизации от источника необходим список промежуточных коммутаторов в пути следования запроса. Этот список создается первым коммутатором и называется транзитным списком (Designated Transit List, DTL). При маршрутизации от источника коммутаторы внутри сети не принимают решения о дальнейшей маршрутизации, а просто передают запрос в соответствии со списком DTL.

Маршрутизация от источника отличается от традиционной маршрутизации, которая реализована, например, в сети Internet. Основное отличие состоит в методе вычисления маршрута. При традиционной маршрутизации каждый узел определяет следующий и передает ему информацию, т. е. передача данных осуществляется как бы шаг за шагом. При этом узлы принимают решения о маршрутизации в соответствии с общими правилами.

Маршрутизация от источника позволяет значительно повысить производительность сети, так как вычисление маршрута не выполняется на промежуточных коммутаторах между первым и последним в пути. Кроме того, эта технология увеличивает гибкость сети, так как коммутаторы могут реализовывать свои собственные алгоритмы вычисления маршрута. Она снижает вероятность образования петель маршрутизации за счет того, что маршрутизация определенного запроса контролируется только одним (первым) коммутатором для каждого соединения.

Характерно, что алгоритм вычисления маршрута не является частью спецификации протокола PNNI. Такой алгоритм должен поддерживаться всеми коммутаторами в сети, но реализация внутренних методов вычисления маршрутов может отличаться.

Соединение типа "точка-точка" является двунаправленным и связывает две конечные системы в сети ATM. Ключевое требование к устанавливаемому соединению - это поддержание требуемого приложениями качества обслуживания. Сначала коммутатор определяет маршрут от отправляющего узла к получающему. Этот маршрут указывается в списке DTL и включает узлы, через которые будет проходить соединение.

Список DTL помещается в запрос на установление виртуального соединения. Запрос передается через каждый узел по маршруту до получателя, а список DTL указывает промежуточным узлам дальнейший путь передачи.

Определение каналов связи в сети, способных обеспечить затребованное для этого соединения качество услуг, осуществляется с помощью специального алгоритма GCAC (Generic Call Admission Control, GCAC). При вычислении маршрута выбраны будут только те каналы связи, которые соответствуют требованиям GCAC.

Для установления соединения типа "точка-точка" запрос передается по маршруту, указанному в списке DTL. При получении очередным транзитным узлом запроса, он использует алгоритм GCAC с целью определения наличия ресурсов для выполнения требований данного запроса. Если ресурсов достаточно, то необходимая их часть резервируется, а вызов передается следующему узлу в соответствии со списком DTL.

В ответ на запрос возможность установления соединения подтверждается уведомлением. При этом маршрут передачи запроса и подтверждения один и тот же. Для завершения установления соединения любой стороной могут быть посланы специальные сообщения. При получении этих сообщений ресурсы коммутаторов, выделенные для данного соединения, будут освобождены.

Вполне возможно, что какой-либо узел на маршруте от отправителя запроса до получателя не будет иметь необходимых ресурсов. Это может случиться, например, если в сети произошли изменения, а информация о них запоздала.

В случае отсутствия требуемых ресурсов протокол PNNI включает специальный механизм блокирования (crankback), в результате чего запрос возвращается обратно тому узлу, на котором данный список DTL был создан, с указанием причины блокировки запроса. Используя полученную информацию, данный узел может вычислить новый маршрут в обход узла или канала связи, не способных предоставить требуемые ресурсы. Это, в свою очередь, увеличивает вероятность успешного установления виртуального соединения по другому маршруту.

Рассмотрим пример (см. Рисунок 6). Предположим, что запрос отправляется конечной системой U1, подключенной к узлу А.1, конечной системе U2, подключенной к узлу А.4. Основываясь на запрошенных параметрах качества обслуживания и текущей информации о топологии, узел A.1 формирует список DTL, содержащий узлы А.1, А.2, А.3 и А.4.

Узел А.1 передает запрос на установление соединения узлу А.2, который определяет, что по некоторым причинам канал связи между ним и А.3 не способен удовлетворить требованиям запроса (например, из-за нехватки пропускной способности). Узел А.2 возвращает запрос обратно узлу А.1 с сообщением о блокировке вызова. Узел А.1 вычисляет новый маршрут в обход перегруженного канала связи. При этом он формирует новый список DTL, содержащий узлы А.1, А.3 и А.4, и, если имеющиеся ресурсы достаточны, этот запрос будет успешно обработан, и виртуальное соединение установлено.

Виртуальное соединение типа "точка-группа" является однонаправленным соединением от корневого узла до всех узлов, называемых листьями. Поток данных следует только от корня, который устанавливает соединение, до узлов, которые были включены в состав этого соединения.

Изначально корневой узел устанавливает соединение типа "точка-группа" до одного получателя. Процедура установления такого соединения аналогична процедуре установления соединения типа "точка-точ-ка". Остальные узлы могут затем быть добавлены к существующему соединению.

Для добавления других получателей к установленному соединению корень формирует список DTL для маршрута от него до определенного конечного узла. Первая часть списка DTL может описывать общую часть маршрута до всех получателей. Вторая часть будет указывать оставшуюся часть маршрута от точки разветвления до нового получателя.

И IP НЕ ПРОБЛЕМА...

Идея использования протокола PNNI в сетях IP заставила Форум ATM заняться разработкой протокола I-PNNI (Integrated PNNI), предназначенного для маршрутизации в обеих средах. Рассмотренная выше модель работы протокола PNNI подразумевает, что маршрутизаторы вне сети ATM продолжают использовать традиционные протоколы маршрутизации.

Протокол I-PNNI вместо этого предполагает применение протокола PNNI как коммутаторами в сети ATM, так и маршрутизаторами в сетях IP. Такое решение исходит из факта большей производительности и масштабируемости сетей, поддерживаемых протоколом PNNI.

Поддерживающие протокол I-PNNI маршрутизаторы смогут работать в иерархической структуре коммутирующих систем, выбирать лидера группы и т. д. Элементы PTSE будут также доступны маршрутизаторам, что позволяет им определять оптимальный маршрут из конца в конец объединенной маршрутизирующей и коммутирующей системы.