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

При работе протокола 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. Методы передачи трафика разного типа

Трафик	Метод
Обычный	Протокол RSVP или другие технологии для определения необходимости создания виртуального соединения
Короткоживущий (SMTP, запросы к DNS и т. д.)	Маршрутизация
В реальном времени	Маршрутизация до тех пор, пока протокол RSVP не укажет на необходимость виртуального соединения
TCP (то есть с изменяющимся объемом)	Маршрутизация по умолчанию, но если возможно использовать протокол RSVP или другие технологии для определения необходимости виртуального соединения

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