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

Дата добавления: 2015-07-13