Взаимодействие устройств в разных логических подсетях

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

q Маршрутизация или установление виртуального соединения. Есть два варианта передачи IP-информации. Первый вариант подразумевает, что хост сам умеет определять АТМ-адрес получателя по известному ему IP-адресу. Поэтому он сам может установить виртуальное соединение и отвечает за доставку. Согласно второму методу, пакеты IP передаются маршрутизатору, который теперь становится ответственным за их дальней­шую доставку;

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

q Выбор протокола маршрутизации. Для поддержки протокола IP в рас­пределенных сетях используются стандартные протоколы маршрутизации, такие как RIP и OSPF. В технологии ATM для маршрутизации запросов на установление коммутируемых виртуальных соединений использует­ся свой протокол — PNNI. Учитывая это, можно предложить две схемы. В первой традиционные протоколы маршрутизации работают поверх сети ATM, рассматривая ее как один из протоколов канального уровня в подсети, a ATM использует свой собственный протокол маршрутизации. Во второй схеме протоколы маршрутизации интегрируются в единый протокол и со­здается общая база данных, отражающая топологию сети. Для создания такой базы данных требуется совместное участие маршрутизаторов IP и коммутаторов ATM. Зато в результате становится возможным вычисление оптимального маршрута с учетом как IP-, так и АТМ-топологии.

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

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

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

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

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

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

Таблица 16.2. Методы передачи трафика разного типа

Протокол NHRP

Установление виртуального соединения между отправителем и получателем, расположенными в различных логических подсетях, требует наличия специаль­ного протокола, отвечающего за определение соответствия между IP- и АТМ-адресами устройств. Рабочая группа ROLC (Routing Over Large Clouds) комитета IETF после рассмотрения ряда различных подходов остановилась на протоколе NHRP (Next Hop Resolution Protocol, протокол определения следующего пе­рехода), основной целью которого является разрешение IP- и АТМ-адресов устройств в сети, состоящей из нескольких логических подсетей. Протокол NHRP можно рассматривать как расширенную версию протокола ATMARP, основная функция которого заключается в определения соответствия между IP- я АТМ-адресами устройств в одной логической подсети. В отличие от 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, так и на маршрутизаторе.

Клиенты протокола NHRP подключаются к сети с указанием АТМ-адреса сервера NHS, который их обслуживает. Существуют два основных метода, кото­рые могут использоваться для регистрации клиентов на сервере NHS: ручной и автоматический. Во втором случае используется специальное регистрационное сообщение протокола NHRP, которое, помимо прочего, содержит следующую важную информацию:

{АТМ-адрес клиента, IP-адрес клиента1Р — адрес сервера NHS}.

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

На рис. 16.11 сеть ATM состоит из трех логических подсетей X, Y и Z, кото­рые связаны между собой двумя маршрутизаторами, назначенными в качестве серверов NHS для подсетей Х и Y. Эти маршрутизаторы поддерживают стан­дартные протоколы маршрутизации, например OSPF, и связаны друг с другом постоянным виртуальным соединением. Предположим, что отправителю (стан­ция Х.1), расположенному в подсети Х и имеющему IP-адрес Х.1 и АТМ-адрес ААА, необходимо передать данные получателю (станция Z.3), расположенному в подсети Z и имеющему IP-адрес Z.3 и АТМ-адрес ВВВ. Процесс передачи данных можно разделить на пять шагов.

1. На первом шаге отправитель формирует пакет с данными и передает его через существующее виртуальное соединение своему маршрутизатору по умолчанию. При этом отправитель посылает маршрутизатору Х запрос NHRP, содержащий следующую информацию: {ААА, Х.1, Z.3}.