Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Протокол 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}.

2. После получения запроса маршрутизатор Х проверит, обслуживает ли он станцию Z.3, то есть существует ли в его таблице запись для этой станции. Если маршрутизатор не обслуживает эту станцию, на втором шаге он пе­решлет полученный запрос соседнему маршрутизатору Z.

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

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

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

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

 

Таблица 16.3. Типы сообщений протокола NHRP

Тип сообщения Описание
NHRP Next Hop Resolution Request (Запрос на разрешение адреса)   Посылается от клиента к серверу для определения АТМ-адреса по известному IP-адресу. В запросе указываются: тип устройства, посылающего запрос (конечная станция или маршрутизатор), авторизованный или неавторизованный это запрос, IP- и АТМ-адреса клиента и искомый АТМ-адрес  
NHRP Next Hop Resolution Reply (Ответ на предыдущее сообще­ние)   Посылается сервером в ответ на предыдущий запрос. Содержит IP- и АТМ-адреса отправителя и найденные адреса получателя. Также содержит указатель авторизации ответа (авторизованный/неавторизованный)  
NHRP Registration Request (Запрос на регистрацию)   Посылается от клиента к серверу (по его IP-адресу) при регистрации. Содержит IP- и АТМ-адреса клиента  
NHRP Registration Reply (Ответ на предыдущее сообщение)   Посылается сервером клиенту в ответ на предыдущий запрос. Указывает на успешную или неуспешную регистрацию  
NHRP Error Indication (Информирование об ошибке)   Используется для информирования об ошибке отправителя сообщения NHRP. Содержит поле, указывающее на код ошибки  

 

Таблица 16.4. Список некоторых расширении

Расширенная часть Описание
End of Extensions (Конец расширений)   Указывает на завершение списка расширений  
NBMA ID Subnetwork (Идентификатор подсети NBMA)   Уникальный идентификатор, который используется для гарантии того, что сообщение не покинет данную сеть NBMA  
NHRP QoS Extension (Расширение для параметров QoS)   В запросе NHRP используется для указания желаемого качества обслуживания  
NHRP Authentication (Параметры аутентификации)   Содержит информацию об аутентификации (например пароль)  

 

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

Существует несколько важных вопросов, которые необходимо рассмотреть при внедрении поддержки протокола NHRP.

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

 

 

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

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

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

 

 

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

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

 

 

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

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

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

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

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

 




Поделиться с друзьями:


Дата добавления: 2015-07-13; Просмотров: 2947; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.011 сек.