Три грани одной проблемы

Эта статья дополняет материал о работе протокола IP в пределах одной логической подсети и освещает принципы работы этого протокола во множестве логических подсетей.

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

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

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

3. Выбор протокола маршрутизации. Поддержка работы IP в распределенных сетях осуществляется с помощью стандартных протоколов маршрутизации, таких как RIP и OSPF. В технологии ATM запросы на установление коммутируемых виртуальных соединений (SVC) маршрутизируются с помощью протокола PNNI. Таким образом мы можем выделить две основные модели работы. Согласно первой традиционные протоколы маршрутизации работают поверх сети ATM и рассматривают ее как один из протоколов канального уровня в подсети, а ATM использует свой собственный протокол маршрутизации. Второй моделью предусматривается интеграция всех протоколов маршрутизации в единый протокол и создание общей базы данных, отражающей топологию сети. При этом как маршрутизаторы IP, так и коммутаторы ATM должны принимать совместное участие в процессе обмена информацией о сетевой топологии. Знание топологии позволяет вычислить оптимальный маршрут через существующие IP- и ATM-сети.

НОРМАЛЬНЫЕ ГЕРОИ ВСЕГДА ИДУТ В ОБХОД...

Напомним, что протокол IP работает в режиме без установления логического соединения. Это означает, что начиная посылать пакеты их адресату, хост не знает, по какому пути они будут реально переданы. Пакеты передаются через один или более маршрутизаторов в пути до тех пор, пока они не достигнут получателя. Такой метод иногда называют доставкой по мере возможности (best-effort delivery). Гарантированная доставка данных осуществляется с помощью протокола TCP, функционирование которого основано на установлении логического соединения между конечными точками, что позволяет ему обнаруживать и исправлять все ошибки при передаче и приеме данных.

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

Итак, основное различие между двумя рассмотренными подходами заключается в передаче данных без установления или с установлением соединения. В первом случае полномочия по выбору маршрута делегируются всем маршрутизаторам в пути между отправителем и получателем. Во втором - маршрут выбирается до того, как данные начнут реально передаваться. Реализация протокола IP в сетях ATM без установления соединения достаточно проста и не требует изменений в его существующих методах работы. При этом сеть ATM рассматривается как протокол канального уровня (только очень быстрый), который позволяет осуществить взаимодействие между хостами и маршрутизаторами в одной логической подсети, как это описано в документе RFC 1577. Трафик между устройствами, расположенными в разных подсетях, будет передаваться через промежуточные маршрутизаторы, даже если эти устройства подключены к одной сети ATM (см. Рисунок 1).

(1x1)

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

В некоторых случаях оптимальным было бы решение, при котором виртуальное соединение устанавливается напрямую между отправителем и получателем, т. е. в обход маршрутизаторов (см. Рисунок 2). Однако при этом его установление, поддержание и завершение может быть сопряжено с дополнительными накладными расходами. Например, подобное соединение не будет оправдано, если хост подает короткие и редкие запросы к какой-либо службе. Наиболее эффективного использования сетевых ресурсов можно достичь лишь при сочетании этих двух методов. Т. е. для приложений, которым сервиса с доставкой по мере возможности достаточно, трафик можно передавать через маршрутизатор по умолчанию, а для приложений, требующих определенного качества обслуживания, необходимо устанавливать виртуальное соединение. При этом решение о применении того или иного метода может быть принято заранеенапример c помощью протокола RSVP. Сетевые ресурсы вдоль выбранного пути выделяются на основании запросов протокола RSVP об их резервировании.

(1x1)

Интересен метод, когда сама сеть ATM определяет необходимое трафику качество обслуживания. В этом случае пакеты передаются через сеть традиционным способом, но если сетевая инфраструктура вычислила оптимальный путь, основываясь на наличии доступных ресурсов и требованиях трафика, то она перенаправит данные по нему. Более подробно подходы для различных типов трафика и их комбинации рассмотрены в документе RFC 1932. Таблица 1 содержит сведения о наиболее общих подходах к выбору способа передачи трафика.

ПЯТЬ ШАГОВ ДО ИСТИНЫ

Установление виртуального соединения между отправителем и получателем, расположенными в различных логических подсетях, требует наличия специального протокола, отвечающего за определение соответствия между IP- и ATM-адресами устройств. После рассмотрения ряда различных подходов рабочая группа ROLC (Routing Over Large Clouds) комитета IETF остановилась на протоколе NHRP (Next Hop Resolution Protocol), основной задачей которого является разрешение IP- и ATM-адресов устройств в сети, состоящей из нескольких логических подсетей.

Протокол NHRP можно рассматривать как расширенную версию протокола ATMARP, основная функция которого заключается в определении соответствия между IP- и ATM-адресами устройств в одной логической подсети. Однако, в отличие от ATMARP, протокол NHRP поддерживает разрешение адресов в среде со множеством логических подсетей.

Изначально протокол NHRP разрабатывался как дополнение к классическому IP, и, следовательно, его применение было ограничено только сетями на базе этого протокола. Однако, теоретически, он может поддерживать работу любого протокола третьего уровня (например, IP, IPX и AppleTalk) в любой сети, относящейся к классу NBMA (ATM, frame relay, X.25, SMDS и т. п.).

Следует отметить, что NHRP - это больше, чем просто протокол. Он включает в себя помимо служебных сообщений два важных компонента: сервер следующего перехода (Next Hop Server, NHS) и клиент следующего перехода (Next Hop Client, NHC).

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

При подключении к сети клиенты протокола NHRP указывают ATM-адрес сервера NHS, который их обслуживает. Зарегистрировать клиентов на сервере NHS можно двумя методами: вручную и автоматически. Во втором случае регистрация осуществляется с помощью специального сообщения протокола NHRP, содержащего помимо дополнительных полей следующую важную информацию: {ATM-адрес клиента, IP-адрес клиента, IP-адрес сервера NHS}

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

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

(1x1)

Как показано на этом рисунке, сеть ATM состоит из логических подсетей X, Y и Z, которые связаны между собой двумя маршрутизаторами, играющими роль серверов NHS для подсетей X и Y. Эти маршрутизаторы поддерживают стандартные протоколы маршрутизации, например OSPF, и связаны друг с другом по постоянному виртуальному соединению (PVC). Предположим, что отправителю (станция X.1), расположенному в подсети X и имеющему IP-адрес X.1 и ATM-адрес AAA, необходимо передавать данные получателю (станция Z.3), расположенному в подсети Z и имеющему IP-адрес Z.3 и ATM-адрес BBB. Весь процесс передачи данных включает пять основных шагов.

На первом шаге отправитель формирует пакет с данными и передает его получателю через существующее виртуальное соединение до своего маршрутизатора по умолчанию. При этом отправитель посылает маршрутизатору X запрос протокола NHRP (Next Hop Resolution Request), содержащий следующую информацию: {AAA, X.1, Z.3}.

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

На третьем шаге маршрутизатор Z получит запрос и определит, что он обслуживает указанный IP-адрес и в его таблице имеется запись с соответствующим ATM-адресом (BBB) получателя. После этого маршрутизатор Z сформирует ответ протокола NHRP (Next Hop Resolution Reply) с искомым ATM-адресом получателя и возвратит его отправителю по тому же пути, по которому пришел запрос. Необходимо отметить, что ответ может посылаться и напрямую отправителю запроса, если установление виртуального соединения разрешено административно. Посылка ответа напрямую позволяет значительно сократить время реакции на запрос, но в этом случае промежуточные серверы не смогут кэшировать информацию, содержащуюся в ответе.

Передача на четвертом шаге маршрутизатором Z ответа по пути прохождения запроса позволит маршрутизатору X добавить запись {Z.3, BBB} в свою таблицу. Впоследствии эта информация может использоваться для формирования так называемого неавторизованного ответа протокола NHRP для других станций, расположенных в подсети X, если им потребуется обратиться к Z.3. Отметим, что авторизованный ответ протокола дается только серверами, обслуживающими указанных клиентов. В свою очередь, клиенты также могут подавать авторизованный запрос, отвечать на который имеет право только обслуживающий их сервер. Если клиенты формируют неавторизованный запрос, то ответить может любой сервер, таблица которого содержит соответствующий ATM-адрес для указанного IP-адреса.

И наконец, на пятом шаге отправитель запроса (станция X.1) получит ответ и выполнит два действия: запишет полученную информацию в свою память и установит коммутируемое виртуальное соединение напрямую со станцией Z.3 через сеть ATM для последующей передачи данных.

СООБЩЕНИЯ, РАСШИРЕНИЯ....

Описания наиболее важных типов сообщений протокола NHRP представлены в Таблице 2. Следует отметить, что все сообщения состоят из двух частей: фиксированной и расширенной. Расширенная часть, если она присутствует в сообщении, содержит список полей, используемых для передачи дополнительной служебной информации (Таблица 3). Это позволяет NHRP адаптироваться к работе с различными протоколами и конфигурациями. Более детальную информацию о формате сообщений и их содержимого можно найти в спецификации протокола NHRP.

Следует помнить, что протокол NHRP не является протоколом маршрутизации. Он не обменивается маршрутной информацией с соседними устройствами, как это делают такие протоколы, как RIP или OSPF, и не определяет маршрут от отправителя к получателю. Его основная цель состоит в разрешении адресов для сети, состоящей из множества логических подсетей, хотя он и может работать совместно с любым протоколом маршрутизации, относящимся к классу IGP или EGP.

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

(1x1)

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

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

Это можно проиллюстрировать на примере простой сети (см. Рисунок 5). Запрос протокола NHRP, содержащий IP-адрес станции R.1, передается через сеть ATM до тех пор, пока не достигнет сервера NHS R, реализованного на граничном маршрутизаторе. Предположим, что данный маршрутизатор имеет два порта: один для подключения к сети ATM с адресом CCC, второй - для подключения к локальной сети (например, Ethernet), где сформирована подсеть R протокола IP.

(1x1)

Ответ протокола NHRP, сгенерированный граничным маршрутизатором R, будет содержать ближайший к станции R.1 адрес ATM, т. е. адрес самого маршрутизатора и длину префикса получателя, который равен числу бит в префиксе IP-адреса подсети R. Эта информация может кэшироваться другими серверами NHS в пути следования запроса, что позволит клиентам NHRP, ищущим устройства в подсети R, быстро получить неавторизованный ответ и установить прямое соединение по ATM-адресу CCC.

Можно рассмотреть пример другой сети, в которой оба клиента NHRP и серверы NHS подключены к обычной локальной сети и являются граничными для сети ATM. Маршрутизатор I находится в логической подсети X и работает как входящий, в то время как маршрутизатор E расположен в логической подсети Y и служит выходящим для потока трафика (см. Рисунок 6).

(1x1)

Станция X.1 начинает посылать пакеты станции Y.3. Маршрутизатор I формирует и посылает запрос протокола NHRP, передаваемый через сеть ATM маршрутизатору E. После того как маршрутизатор E ответит, они могут установить между собой виртуальное соединение, по которому будут передаваться данные между станциями X.1 и Y.3.

Потенциальной опасностью здесь является образование петли маршрутизации. Подобная возможность реализуется при наличии еще одного обходного пути между подсетями X и Y вне данной сети ATM в случае потери протоколом маршрутизации части информации о маршруте (например, метрики пути для протоколов класса IGP). Решением данной проблемы может быть, например, закрытие пути, установленного с помощью протокола NHRP. Более детально возможные ситуации возникновения петель и пути их решения рассмотрены в документе RFC 1932.

ОБЩИЙ ПРЕФИКС

Модель работы классического IP (RFC 1577) имеет очевидные ограничения. Виртуальные соединения (постоянные или коммутируемые) могут устанавливаться между членами одной логической группы, и при этом маршрутизатор не требуется. Для взаимодействия же клиентов, расположенных в различных логических подсетях, маршрутизатор необходим. Даже если эти клиенты находятся в одной сети ATM, то они не имеют возможности взаимодействовать напрямую, так как номера сети/подсети и маски подсети у них отличаются. Они логически удалены друг от друга и, следовательно, для их взаимодействия требуется маршрутизатор.

Как видно, решение об использовании маршрутизации или установлении виртуального соединения принимается на основе IP-адресов устройств, и оно не всегда является верным. Некоторые типы трафика (например, запросы к DNS) желательно передавать через маршрутизаторы, в то время как критичному к задержкам трафику может потребоваться установление виртуального соединения. Однако, как уже было упомянуто, при выборе пути следования трафика требования приложений не принимаются во внимание.

Решение этой проблемы лежит в расширении модели IP. Новой моделью вводится понятие группы логических адресов (Logical Address Group, LAG), представляющей собой набор хостов и маршрутизаторов с общим префиксом IP-адресов. Маршрутизаторы внутри LAG логически расположены на расстоянии одного перехода от хостов и будут рекламировать доступность LAG с метрикой 0 (т. е. доступность напрямую). Расширенная модель IP еще не является стандартом и находится в стадии рассмотрения.

ОЦЕНИМ НАШИ ПОТЕРИ

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

Потеря производительности сети ATM с поддержкой протокола IP может произойти за счет повышения объема передаваемой информации. После распределения полезной информации по ячейкам (48 байт каждая) уровнем адаптации AAL5 генерируется одна или несколько служебных ячеек. Чем короче IP-дейтаграмма, тем чаще будут появляться дополнительные, служебные ячейки.

Служебной информацией считаются также байты заголовков протоколов TCP и IP и заголовок идентификации данных определенных протоколов (LLC/SNAP). Кроме того, служебной информацией являются дополнительные байты (от 0 до 47) для выравнивания размера кадра уровня AAL5 таким образом, чтобы его длина была кратна размеру ячейки (53 байт). Рисунок 7 показывает последовательность формирования информационных и служебных ячеек ATM.

(1x1)

Очевидно, что чем меньше размер передаваемой дейтаграммы протокола IP, тем менее эффективна ее передача. Теоретически, если все ячейки несут полезную информацию и нет дополнительных ячеек со служебной информацией, эффективность передачи IP-трафика будет определяться только структурой самой ячейки и будет равна 90,5% (100 * (48/53)). На практике такая эффективность не достижима, но при передаче дейтаграмм протокола IP большой длины влиянием ячеек со служебной информацией можно пренебречь. Рисунок 8 показывает эффективность передачи дейтаграмм в зависимости от их размера.

(1x1)

Приведенные выше рассуждения можно проиллюстрировать цифрами. При использовании SONET на физическом уровне и ATM в качестве протокола второго уровня передача IP-трафика происходит с 10-процентной потерей пропускной способности сети.

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

В общем случае схема расчетов следующая. На первом шаге определяется параметр (E), характеризующий количество ячеек, необходимых для передачи каждых 100 обычных TCP -> IP- или UDP -> IP- пакетов. На втором шаге рассчитывается средний размер пакета для данного вида трафика (A). И на последнем шаге определяется эффективность использования ячеек (U), которая соответствует количеству (в процентах) ячеек, необходимых для передачи полезного IP-трафика. Этот параметр можно рассчитать по следующей формуле:

U = 100 * A / (53 * E)

Коэффициенты U и E учитывают любые накладные расходы сети ATM, возникающие при передаче IP-трафика. Здесь под накладными расходами понимается передаваемая контрольная информация, которая добавляется при инкапсуляции дейтаграммы в кадры AAL5, а затем в ячейки (например, заголовок LLC/SNAP, байты для выравнивания и т. д.). Исследования показали, что при посылке пустых (т. е. без данных) пакетов TCP -> IP значение коэффициента E составляет 37%. В этом случае реально передаваемой информацией являются байты заголовков протоколов, занимающие 2 ячейки (E = 200, U = 100 * 40 / (53 * 200) = 37,7). Это значение можно считать наихудшим. Наилучшее теоретическое значение коэффициента E составляет, как уже говорилось, 90,5% при размере дейтаграммы 64 Кбайт.