Протокол маршрутизации запросов PNNI

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

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

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

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

Рассмотрим пример, иллюстрирующий приведенную концепцию адресации (рис. 12.4). Администратор выбрал такую адресную схему, при которой первые 12 байт адреса ATM являются общими для всех узлов в группе. Буква «А» представляет эти 12 байт (допустим, А = 39.9.9.9.9.9.9.0.0.9.9.0). Тринадцатый байт адреса ATM служит для идентификации коммутаторов в группе (коммутаторы имеют адреса А.1, А.2, А.З, А.4). Следующие шесть байт адреса ATM используются в качестве идентификатора конечной системы, подключенной к соответствующему коммутатору (End System Identifier, ESI).

Конечная система, подключенная к коммутатору с адресным префиксом А.4, может иметь адрес А.4.2.3.4.1.1.1. Поэтому 2.3.4.1.1.1 – это ее идентификатор.

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

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

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

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

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

Рассмотрим элементы PTSE на примере сети на рис. 12.6. У нас есть группа, в которой все адреса имеют общий 12-байтовый префикс. В ней работают два коммутатора с адресами А.1 и А.2. Конечные системы, подключенные к этим коммутаторам, имеют адреса А. 1.0.0.0.0.0.1 и А.2.7.6.5.4.3.2, соответственно. Узел А.1 формирует три элемента PTSE. Первый элемент – описание самого узла, второй – описание канала связи от его порта 6 к порту 3 узла А.2 и третий

элемент – описание своего доступного адреса. Узел А.2 также хранит три элемента PTSE.

Для вычисления маршрута информация о топологии (то есть элементы PTSE) должна быть известна каждому узлу. Так как параметры качества обслуживания (например, пропускная способность канала и задержка) могут меняться, информация о топологии должна обновляться. В протоколе PNNI распространение записей PTSE в сети разделяется на две фазы – начальный обмен информацией о сетевой топологии и последующий лавинный обмен (flooding). Рассмотрим эти фазы более подробно.

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

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

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

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

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

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

Обобщенный адрес (summary address) в протоколе PNNI используется при генерации адресного префикса, который объявляется коммутатором. Когда коммутатор узнает, что он может предоставить доступ к определенному адресу, он проверяет, входит ли этот адрес в состав обобщенного. Если да, то вместо объявления отдельного адреса маршрутизатор сообщает об обобщенном. В ситуациях, когда одному адресу может отвечать несколько обобщенных адресов, для определения подходящего обобщенного адреса используется механизм наибольшего совпадения адресного префикса.

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

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

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

Каждый коммутатор автоматически создает 13-байтовый обобщенный адрес, основываясь на своем АТМ-адресе (например, А.1, А.2) и объявляет его доступность при помощи создания элемента PTSE, в котором доступный адресный префикс эквивалентен этому обобщенному адресу. Объявляя свои собственные 13 байт адресного префикса, коммутатор также сообщает о доступности всех подключенных к нему конечных систем. Это происходит из-за того, что адреса конечных систем формируются на основе объединения 13 байт адресного префикса коммутатора и 6 байт собственных идентификаторов.

Но существуют ситуации, когда адрес конечной системы имеет префикс, отличный от префикса адреса коммутатора, к которому она подключена. Например, сервер конфигурации 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 поддерживает иерархическое построение сети, что позволяет обслуживать практически неограниченное число каналов связи и узлов, не требуя при этом чрезмерных ресурсов коммутаторов.

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

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

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

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

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

Если узлу X.Y.I необходимо найти маршрут для запроса по адресу X.Z.6.X, он выберет маршрут до логического узла X.Z, проходящий через узлы X.Y.2 или X.Y.4 (так как они имеют каналы до X.Z). Когда запрос на виртуальное соединение достигнет узла X.Y.2 (или X.Y.4), он будет передан соседней группе на узел X.Z.I (или X.Z.2). Этот узел вычислит маршрут до получателя (X.Z.6), используя имеющуюся у него подробную информацию о топологии группы.

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

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

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

Протокол сигнализации PNNI

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

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

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

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

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

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

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

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

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

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

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

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

В заключение нашего рассмотрения протокола PNNI следует отметить, что предшественником PNNI был протокол IISP (Interim Interswitch Protocol), разработанный Форумом ATM в 1995 году. IISP – это очень простой протокол сигнализации. Он требует ручной настройки таблиц адресных префиксов на каждом коммутаторе. Он не масштабируем и не поддерживает качество обслуживания.

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

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

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

Часть IV