Анатомия МPOA

Недавно принятый ATM Forum стандарт MPOA обещает повысить эффективность эмуляции ЛВС в АТМ, а также облегчить интеграцию сетей, использующих АТМ, в существующую инфраструктуру.

ДЕТАЛИ
LANE 2.0 - что нового?

В июле 1997 ATM Forum утвердил стандарт MPOA (Multiprotocol Over ATM) 1.0. Стандарт разрабатывался с целью обеспечения полной интеграции маршрутизируемых сетей и сетей с коммутацией третьего уровня с виртуальными сетями, построенными на базе магистралей ATM. Появления MPOA сторонники ATM ожидали уже довольно давно. С одной стороны, LANE обеспечивал эффективную работу традиционных протоколов межсетевого взаимодействия поверх ATM в рамках отдельных подсетей. В то же время разработанный IETF протокол NHRP (Next Hop Resolution Protocol) дал возможность разделять сети ATM на подсети и оптимизировать работу маршрутизаторов по объединению этих подсетей. Появление стандарта MPOA, объединяющего в себе оба этих подхода, стало следующим логичным шагом.

"КИРПИЧИКИ" MPOA

MPOA разработан в соответствии с архитектурой клиент-сервер, таким образом его логическими компонентами могут быть либо клиент MPOA (MPC), либо сервер MPOA (MPS) (См. Рисунок 1).

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

Выступая в качестве точки входа в систему MPOA (в терминах стандарта - "ingress"), MPC регистрирует поток пакетов, который пересылается по эмулируемой ЛВС (ELAN) маршрутизатору, содержащему MPS. Если поток может выиграть при использовании кратчайшего пути в обход маршрутизаторов, то с целью получения информации, необходимой для установления кратчайшего пути к точке назначения, клиент задействует протокол на базе NHRP по типу запрос-ответ. Если такой путь доступен, то MPC сохраняет эту информацию в своем входном кэше (ingress cache), устанавливает кратчайший VCC (Virtual Channel Connection) и перенаправляет кадры по назначению.

Находясь на выходе (egress), MPC получает от других MPC кадры и пересылает их на свои локальные интерфейсы. К кадрам, полученным по кратчайшему пути, MPC присоединяет соответствующий заголовок DLL (Data Link Layer) и перенаправляет их на cледующие уровни. Информацию заголовка DLL клиент MPC получает от MPS и помещает в выходной кэш (egress cache). MPC может обслуживать одного или более клиентов эмуляции сетей (LEC) и связать с одним или более MPS.

MPS - это логический компонент маршрутизатора, отвечающий за пересылку информации к MPC на межсетевом уровне. В соответствии с протоколом NHRP и с расширениями, о которых речь пойдет немного позже, MPS включает в себя полный сервер NHS (Next Hop Server). MPS взаимодействует с локальным NHS и функциями маршрутизатора, отвечая на запросы MPOA от входного MPC и передавая информацию заголовка DLL выходному MPC.

Устройства, поддерживающие MPOA, условно можно поделить на следующие группы:

• пограничные устройства, имеющие MPC, LEC и порт моста;
• хосты MPOA, имеющие MPC, LEC и внутренний стек хоста;
• маршрутизаторы, содержащие MPS (включающие, в свою очередь, NHS);
• LEC и функции маршрутизации.

Естественно, компоненты MPOA могут быть скомбинированы в рамках одного устройства и по-другому, в частности функциональность маршрутизатора можно расширить, передав ему также функции MPC. Вообще говоря, одно устройство может содержать в себе несколько MPC и/или MPS, каждый из которых способен обслуживать несколько LEC (но каждый LEC привязан только к одному MPC или MPS).

Основные процессы MPOA - это конфигурация MPS и MPC, поиск ими друг друга, распознавание конечных пунктов, управление соединением и собственно передача данных.

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

Автоматический поиск информации о компонентах MPOA реализован с помощью расширенного в этих целях протокола LANE LE_ARP в версии LANE 2.0. Протокол передает тип компонента и его адрес АТМ. Эта информация может меняться и поэтому должна динамически обновляться. Регистрация MPC, не содержащих в себе NHC (Next Hop Client), на уровне NHRP не производится.

Для распознавания адреса MPOA использует расширенный протокол по типу запрос-ответ NHRP, при помощи которого и определяет адреса ATM начальной и конечной точек устанавливаемого кратчайшего соединения.

Вкратце весь процесс пересылки пакетов в сетях, поддерживающих MPOA, осуществляется следующим образом. Пакет попадает в систему через входной MPC. По умолчанию пакет перенаправляется при помощи механизма LANE маршрутизатору, покидая систему MPOA через встроенный LEC входного MPC. Если же пакет принадлежит потоку, идущему по установленному кратчайшему соединению, входной MPC отрезает у него заголовок DLL и пересылает сам пакет по этому пути. Возможно, что MPC перед пересылкой придется также присоединить к пакету ярлык с информацией, полученной во время распознавания адресов. Иными словами, если не было определено никакого потока данных, то все пакеты, посылаемые от MPC к MPS, получают ярлык с адресом на уровне межсетевого взаимодействия, как будто они пересылаются по стандартной эмулируемой ЛВС. Граничное устройство MPOA в этом случае выполняет роль моста второго уровня. Когда же превышается пороговое количество пакетов, проходящее по одному адресу межсетевого уровня за фиксированный отрезок времени, MPC посылает запрос на получение адреса ATM конечного пункта кратчайшего соединения, скорее всего другого MPC, выполняющего роль выходной точки из системы MPOA. Выходной MPC проверяет выходной кэш на наличие записи, соответствующей данному типу пакетов. Затем пакет снабжается полученной из кэша информацией и передается на уровень выше. В случае отсутствия в кэше соответствующей записи пакет отбрасывается.

Взаимодействие эмуляции ЛВС c маршрутизацией реализовано в MPOA следующим образом. Для инициализации запроса на определение адреса и ответа на него MPS обращается к своему NHS. Все входные и выходные NHS находятся в состоянии обработки запросов NHRP и отслеживают изменения в информации о маршрутах, динамически ее обновляя. По мере поступления обновленных данных от своих NHS, MPS модифицируют или очищают содержимое кэша относящихся к ним MPC. MPOA обеспечивает также взаимодействие с устройствами, поддерживающими только NHRP. Для находящихся в том же домене ION-устройств (Internetworking Over Non-Broadcast Multi-Access) NHRP MPC выглядит как стандартный NHC. Между расположенными в различных подсетях IP хостами MPOA, поддерживающими NHRP, могут быть установлены кратчайшие пути передачи. Как показано на Рисунке 2. кратчайшие соединения возможны между хостами и/или граничными устройствами MPOA и хостами и/или маршрутизаторами, поддерживающими NHRP. Единственное ограничение на интероперабельность MPOA и NHRP - это то, что устройства разных типов должны находиться в различных подсетях, поскольку механизмы подобного взаимодействия в рамках одной подсети в настоящее время стандартом не определены.

(1x1)

ПРИМЕР ФУНКЦИОНИРОВАНИЯ

Рассмотрим поподробнее процесс работы MPOA на каком-нибудь примере. Не останавливаясь на тривиальном случае функционирования MPOA в рамках одной ELAN (все устройства MPOA будут взаимодействовать друг с другом через LANE), перейдем сразу к взаимодействию различных эмулируемых ЛВС через маршрутизируемую инфраструктуру. Для примера возьмем конфигурацию сети, изображенную на Рисунке 3. В нее входят две ELAN, каждая из них состоит из одного хоста MPOA и одного граничного устройства MPOA, к которому подключено несколько хостов локальной сети. Обе эмулируемых сети объединены с помощью маршрутизатора, поддерживающего MPOA. Для простоты в схему введен только один маршрутизатор, хотя на практике входной и выходной MPS могут разделять несколько маршрутизаторов, через которых проходит путь по умолчанию. Поскольку входные и выходные MPS функционируют независимо даже в рамках одного устройства, для простоты на Рисунке 3 можно указать только один маршрутизатор, отметив, что в общем случае выходной и выходной MPS будут взаимодействовать через NHRP.

Предположим, что хост 1 посылает пакеты хосту 2. По умолчанию хост 1 пошлет пакет в рамках LANE маршрутизатору по прямому виртуальному каналу, а маршрутизатор, сохраняя формат LANE, перешлет пакет по другому прямому VCC хосту 2. MPC хоста 1 находится в нашем случае во входном состоянии.MPC хоста 1 заранее определяет MAC-адрес подключенного к его ELAN MPS посредством рассылки автоконфигурационного запроса LANE. Клиент MPC хоста 1 устанавливает на основании адреса назначения межсетевого уровня появление потока пакетов. (Дополнительно MPC может идентифицировать потоки на базе информации более высокого уровня, в зависимости от реализации стандарта производителем.) Установив наличие потока в направлении хоста 2, пересылка которого по кратчайшему пути была бы более эффективной, MPC начинает процесс определения адреса АТМ выходного устройства. (Заметим, что, вообще говоря, одно устройство может содержать как входной, так и выходной MPC.) Чтобы получить адрес, входной MPC посылает запрос на определение адреса (MPOA Resolution Request) соответствующему MPS на маршрутизаторе.

Входной MPS обрабатывает полученный запрос, и, если пункт назначения является для него локальным (как в нашем случае), он может ответить на него немедленно. В общем случае он через свой NHS отправляет запрос далее по цепочке маршрутизаторов. Входной MPS использует свой адрес уровня межсетевого взаимодействия как обратный для переадресуемого запроса, что гарантирует получение ответа именно им. MPS копирует все остальные поля запроса, в частности АТМ-адрес MPC и все поля TLV (Type-Length-Value). MPS присваивает переадресуемому запросу новый идентификатор и устанавливает контрольные биты запроса таким образом, чтобы последующие NHS не кэшировали итоговые адреса уровня межсетевого взаимодействия и адреса АТМ.

Когда запрос NHRP, обращенный к локальному MPC, достигает обслуживающего его выходного MPS, последний генерируeт запрос на помещение данных в выходной кэш (MPOA Cache Imposition Request) и посылает его выходному MPC, в нашем случае MPC хоста 2. Запрос предоставляет тому необходимую информацию об инкапсуляции и текущем состоянии системы.

Выходной MPC посылает обратно ответ о помещении информации в кэш (Cache Imposition Reply). При подготовке ответа MPC определяет, располагает ли он ресурсами для обслуживания новой записи в кэше и, в перспективе, приема нового VCC. В случае, когда запрос только обновляет содержимое существующего кэша, ресурсы, как правило, находятся. Если MPC не может разместить в своем кэше еще одну запись или ресурсов устройства недостаточно для поддержки еще одного VCC, MPC указывает соответствующий флаг ошибки в отсылаемом обратно ответе. Если же проблем с ресурсами нет, то MPC устанавливает флаг успешной обработки запроса и отсылает свой адрес ATM, а также, при необходимости, ярлыки (Egress Cache Tag Extention), которые входной MPC будет использовать при пересылке данных по кратчайшему соединению. В реальной практике возможны конфигурации, в которых выходной MPC получает конфликтующие между собой инструкции относительно пересылки пакетов по одной и той же паре адресов (ATM и уровня межсетевого взаимодействия). Если это происходит, то с целью обеспечения правильной пересылки пакетов MPC должен совершить одно из следующих действий:

• если поддерживается Egress Cache Tag Extention, то MPС включает в свой ответ ярлыки, уникальные для каждой комбинации из начального и конечного адресов АТМ и конечного адреса уровня межсетевого взаимодействия;
• возвращает в ответе измененный адрес ATM, тем самым побуждая запрашивающий MPC инициализировать новый виртуальный канал;
• возвращает отказ, сообщая в ответе, что невозможно установить еще один кратчайший путь, или просто отказывает в установлении кратчайшего пути для этого потока.

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

Ответ выходного MPC получает сначала выходной MPS. Тот посылает ответ инициализировавшему запрос входному MPS по протоколу NHRP, в который, естественно, включается и сам ответ на запрос MPOA. Входной MPS по получении ответа восстанавливает оригинальные идентификатор запроса и обратный адрес и отсылает ответ на запрос MPOA об адресе входному MPC. Получив ответ, MPC устанавливает стандартными средствами ATM от себя до выходного MPC виртуальный канал, по которому в дальнейшем и идет пересылка пакетов.

В трех других случаях (хост 1 - хост Б, хост А - хост Б и хост А - хост 2) взаимодействие хостов из двух различных ELAN происходит аналогично, с тем только различием, что там, где это необходимо, пакеты LAN преобразуются в ячейки АТМ и/или обратно.

ЧТО ДАЕТ MPOA

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

Еще одно достоинство MPOA - это его нацеленность на интеграцию с протоколом RSVP. Группа IETF в настоящее время работает над стандартизацией взаимодействия RSVP и ATM, что даст возможность приложениям, применяющим RSVP, использовать предоставляемое ATM гарантированное качество услуг (QoS).

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

Не стоит обходить вниманием и вопросы совместимости с существующей инфраструктурой. По умолчанию все устройства MPOA функционируют в обычном режиме эмуляции ЛВС. Хотя для работы MPOA требуется поддержка стандарта LANE 2.0, устройства будут функционировать в этом режиме и с оборудованием на базе старого стандарта версии 1.0, поскольку, во-первых, между стандартами обеспечена обратная совместимость, а во-вторых, самые серьезные расширения LANE касаются в основном именно обеспечения работы MPOA (подробно см. врезку "LANE 2.0 - что нового?"). Устройства MPOA сами определяют наличие в сети подобного оборудования, что облегчает их установку в сети.

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

ЗАКЛЮЧЕНИЕ

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

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ MPOA

1. Магистраль ATM [UNI 3.0, UNI 3.1 или UNI 4.0)
2. Поддержка LANE 2.0
3. Поддержка протокола NHRP

ДЕТАЛИ

LANE 2.0 - что нового?

Принятие стандарта MPOA сопровождалось разработкой новой версии LANE. (Cобственно, MPOA функционирует только на базе LANE 2.0.) Какие же изменения появились в стандарте LANE? Минимальная версия LEC должна, во-первых, поддерживать новый набор конфигурационных переменных и TLV (значительная часть которых обслуживает MPOA) и предоставлять расширенный сервис (API) по пересылке этих данных на более высокие уровни. Во-вторых, LEC версии 2 не обязаны обеспечивать QoS, сервисы многоадресной рассылки, мультиплексирование VCC и сигнализацию версии 4.0. Аналогично минимальный сервис эмуляции поддерживает расширенный набор конфигурационных переменных и TLV, хотя и не имеет расширенного API к более высоким уровням. Сервис эмуляции также поддерживает запросы на адреса LE_ARP и на многоадресную отсылку, хотя, опять-таки, не обязан предоставлять какие-либо дополнительные сервисы по многоадресной рассылке. Этот минимальный набор и является необходимым требованием для нормального функционирования MPOA.

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

Когда клиент, поддерживающий LANE 2.0, взаимодействует со "старыми" компонентами сервиса эмуляции сетей, он, разумеется, не должен совершать действий, которые LES версии 1 может счесть недопустимыми. Однако клиент может включать в свои запросы и ответы расширенные TLV. Если эта дополнительная информация достигнет других клиентов версии 2, она может оказаться для них полезной. Однако при такой неопределенности MPOA будет работать некорректно. Клиент должен предупредить такую ситуацию заранее, выставляя при инициализации ELAN флаги V2 Capable и V2 Required.

В случае взаимодействия "нового" сервиса LANE со "старыми" клиентами ситуация упрощается, поскольку сервис версии 2 согласно стандарту должен включать в себя все функции сервиса версии 1. Гораздо более сложная ситуация возникает при смешанных клиентах обеих версий. Совместимость на уровне клиентов версий 1 и 2 обеспечивается посредством добавления или срезания заголовков мультиплексирования VCC. LANE 2.0, вообще говоря, поддерживает одновременную работу мультиплексированных и немультиплексированных соединений LLC в рамках одной ELAN, без внесения каких-либо изменений в работу клиентов версии 1. Разумеется, такая прозрачность достигается за счет клиентов версии 2. В расширенном наборе TLV появляются поля, информирующие о наличии в сети мультиплексированных VCC и поддерживающих их клиентов. Клиент LANE 2.0 отслеживает, какие VCC передачи данных мультиплексированы, а какие нет, и срезает/добавляет заголовки LLC на мультиплексированных VCC, не затрагивая при этом немультиплексированные VCC.

Поскольку все форматы кадров (за исключением заголовка LLC, нескольких флагов и TLV) остаются идентичными в обеих версиях LANE, обеспечение интероперабельности производителями становится не такой уж сложной задачей.

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