Сервер – ориентированные механизмы конвергенции атм и iр Классический iр
Протокол классического IР является первым протоколом (1994г.), определяющим способ работы IР-сетей через транзитную АТМ.
Рассмотрим работу протокола классического IР на рисунке 10:
Рис.10. Логические IР-подсети в сети АТМ
Взаимодействие IР-подсетей через транзитную АТМ-сеть заключается в следующем:
АТМ-сеть представляется в виде нескольких логических IР-подсетей. Все узлы одной подсети имеют общий адрес сети.
Весь трафик между IР-подсетями обязательно проходит через маршрутизатор, хотя и есть возможность передавать его непосредственно через АТМ- коммутаторы.
Маршрутизатор может быть подключен к сети одним физическим интерфейсом, которому присваивается несколько IР-адресов в соответствии с количеством логических подсетей.
Сервер АТМАRР управляет таблицей, записи которой определяют соответствие между IР и АТМ адресами устройств. Сервер может обслуживать несколько подсетей и обычно роль сервера выполняет маршрутизатор, имеющий интерфейсы во всех подсетях.
Узлы конфигурируются традиционным способом, то есть для каждого узла задается собственный IР-адрес, маска и IР-адрес маршрутизатора по умолчанию и, кроме того, задаются собственный АТМ-адрес и АТМ-адрес АТМАRР-сервера.
Каждый узел использует АТМ-адрес сервера, чтобы выполнить обычный АRР-запрос и узнать АТМ-адрес получателя.
Зная АТМ-адрес получателя, узел устанавливает с ним виртуальное соединение, после чего начинает передачу данных.
При взаимодействии узлов, расположенных в разных IР- подсетях, каждый узел узнает АТМ-адрес маршрутизатора по умолчанию, устанавливает с ним виртуальное соединение и передает ему IР-пакет, предназначенный для другой сети.
Протокол nhrp
Установление виртуального соединения между отправителем и получателем, расположенными в разных подсетях, требует наличия специального протокола, отвечающего за разрешение IР и АТМ-адресов устройств.
NHRP – Next Hop Resolution Protocol – протокол определения следующего перехода, предназначен для разрешения IР и АТМ-адресов в сети, состоящей из нескольких подсетей, т.е. этот протокол можно рассматривать как расширение АТМАRР протокола.
Протокол NHRP включает в себя два компонента:
сервер следующего перехода (NHS)-Next Hop Server
клиент следующего перехода (NHC) – Next Hop Client.
Клиенты подключаются к сети с указанием АТМ-адреса сервера, который их обслуживает. Клиентами могут быть как конечные узлы, так и маршрутизаторы.
Сервер NHS хранит специальную таблицу IР и АТМ-адресов устройств, подключенных к сети. Такая таблица может строиться автоматическим или ручным способом. При построении таблицы автоматически каждый клиент посылает серверу специальное регистрационное сообщение:
{АТМ-адрес клиента, IР-адрес клиента, IР-адрес сервера NHS}
Покажем на рисунке 11 процесс разрешения адреса удаленного устройства:
Рис.11. Процесс разрешения адреса
Сеть состоит из 3-х логических подсетей Х, У, Z, которые связаны между собой маршрутизаторами, назначенными в качестве NHS-серверов. Эти маршрутизаторы поддерживают стандартные протоколы маршрутизации, например, OSPF, и связаны между собой постоянными виртуальными каналами. Предположим, что отправителю, расположенному в Х-подсети и имеющему IР-адрес Х.1. и АТМ-адрес ААА, необходимо передать данные получателю, расположенному в Z-подсети и имеющему IР-адрес Z.3 и АТМ-адрес ВВВ.
Процесс передачи данных состоит из 5-ти этапов:
Отправитель формирует пакет с данными и передает его через существующее виртуальное соединение своему маршрутизатору по умолчанию. Затем отправитель вслед за пакетом посылает маршрутизатору запрос NHRP, содержащий информацию {AAA, X.1, Z.3}.
После получения запроса маршрутизатор Х проверит, обслуживает ли он станцию Z.3, т.е. существует ли в его таблице запись об этой станции. Если маршрутизатор Х не обслуживает эту станцию, то он перешлет запрос соседнему маршрутизатору Z.
Маршрутизатор Z получит запрос и определит, что он обслуживает указанную в запросе станцию. После этого маршрутизатор Z сформирует ответ NHRP и отправит его по тому же пути, по которому пришел запрос. Ответ содержит информацию {BBB, Z.3}. Ответ может посылаться и напрямую отправителю, если это разрешено администратором. Отправка ответа напрямую сократит время реакции на запрос, но в этом случае промежуточные сервера не смогут кэшировать информацию, содержащуюся в ответе.
Если ответ будет передаваться по пути следования запроса, то на 4-ом шаге в таблице маршрутизатора Х появится запись {BBB, Z.3}. Это может в последующем использоваться при обслуживании других клиентов.
Отправитель запроса получает ответ и выполняет два действия:
запоминает полученную информацию,
устанавливает виртуальное соединение напрямую со станцией Z.3 через АТМ-сеть, минуя маршрутизаторы, после чего начинается передача данных.