Протокол DVMRP

Протоколы групповой маршрутизации

Магистраль MBONE

В 1992 году в Internet была создана специальная информационная магистраль с поддержкой групповой адресации — Multicast Backbone (MBONE). Целью MBONE было тестирование групповой передачи пакетов для стимулирования разработки приложений, поддерживающих групповую адресацию. В апреле 1996 года MBONE объединяла более 2800 подсетей. Очевидно, что с появлением но­вых приложений и услуг, поддерживающих групповую адресацию, количество подсетей, работающих с магистралью MBONE, возрастет. Основной целью вве­дения групповой адресации можно считать стремление начать аудио- и видеове­щание через Internet.

Магистраль MBONE состоит из областей, связанных групповыми маршрути­заторами. Эти маршрутизаторы соединены между собой так называемыми тун­нелями. Виртуальные туннели позволяют передавать групповой трафик через ту часть Internet, которая не поддерживает групповую адресацию. Туннелирование происходит посредством инкапсуляции в стандартные IP-дейтаграммы. Таким образом дейтаграммы с групповыми адресами теперь воспринимаются как обыч­ные.

В настоящее время в качестве протокола групповой маршрутизации в MBONE используется DVMRP. Некоторые эксперты прогнозируют переход от протокола DVMRP к другим протоколам групповой маршрутизации, в частнос­ти, MOSPF и PIM. К их описанию мы и приступаем.

Версия 1 протокола DVMRP (Distance Vector Multicast Routing Protocol) опи­сана в документе RFC 1075. Этот протокол основан на протоколе RIP и алго­ритме TRPB. Основное отличие между протоколами RIP и DVMRP состоит в том, что первый нацелен на определение следующего транзитного узла на пути к получателю, а второй — на определение предыдущего транзитного узла на пути к отправителю. Протокол DVMRP предназначен для передачи группового трафика через распределенную сеть и использует алгоритм вектора расстояния. Протокол строит дерево доставки на основе несколько модифицированного ал­горитма RPB. Однако ведущие поставщики маршрутизаторов в своих последних изделиях наряду с алгоритмом RPB используют алгоритм RPM. Поэтому ны­нешняя реализация протокола DVMRP немного отличается от оригинальной спецификации RFC.

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

Маршрутизатор передает дейтаграммы с групповым адресом через свои пор­ты, если значения поля TTL в заголовках дейтаграмм больше, чем значения, указанные для портов. Это служит для ограничения зоны действия групповой передачи дейтаграмм. В табл. 9.3 перечислены наиболее часто используемые значения TTL.

Таблица 9.3. Типичные значения TTL

Значение	Зона действия
	Данное устройство
	Данная сеть
	Даннае область
	Данный регион
	Данный континент
	Без ограничений

Как уже было сказано, протокол DVMRP использует алгоритм RPM. Напом­ним, что в соответствии с этим алгоритмом, первая дейтаграмма с групповым адресом для любой пары (отправитель, группа-получатель) передается через всю распределенную сеть. Эта дейтаграмма поступает ко всем маршрутизаторам в сети, которые высылают усекающие сообщения в случае, если в подключенных к ним подсетях нет членов группы-получателя. В результате происходит усече­ние дерева доставки от источника. После некоторого промежутка времени про­исходит проверка правомерности усечения: усеченные части дерева «реабилитируются», следующая дейтаграмма для пары вновь передается через всю распределенную сеть, и усечение определяется заново.

Протокол DVMRP реализует механизм быстрого восстановления усеченных частей дерева доставки. Если маршрутизатор, ранее отвечавший усекающими сообщениями для пары (отправитель, группа-получатель), вдруг обнаружил новых членов группы-получателя в подключенных подсетях, он посылает вос­станавливающее сообщение (graft). Это позволяет восстановить усеченную часть дерева доставки, не дожидаясь регулярной процедуры обновления.

При работе нескольких маршрутизаторов DVMRP в локальной сети из них выбирается один доминантный маршрутизатор (Dominant Router, DR), отвеча­ющий за периодическую рассылку сообщений HMQ, протокола IGMP. После инициализации сети каждый маршрутизатор назначает самого себя в качестве доминантного и является им до тех пор, пока не получит от соседнего маршрутизатора сообщение HMQ, содержащее меньший IP-адрес. Выбор доминантного маршрутизатора помогает частично устранить дублирование сообщений, рассы­лаемых в локальной сети.

Для иллюстрации сказанного рассмотрим пример (рис. 9.11). Маршрутиза­тор Ml может получать дейтаграммы от отправителя через маршрутизаторы М2 или МЗ. Если у маршрутизатора М2 метрика к сети отправителя меньше, чем у маршрутизатора МЗ, он продолжит передачу трафика от отправителя, а марш­рутизатор МЗ будет отбрасывать трафик, предотвращая тем самым его дублиро­вание. Если метрика маршрутизатора М2 равна метрике МЗ, то доминантным становится маршрутизатор с наименьшим IP-адресом на своем порожденном порте.

Маршрутизаторы в распределенной сети должны поддерживать единичную адресацию и групповой трафик. Два соответствующих процесса на одном из маршрутизаторов будут периодически обмениваться сообщениями об обновле­нии таблиц маршрутизации с соседними маршрутизаторами. Причем такие со­общения являются независимыми от используемого протокола маршрутизации класса IGP. Иными словами, на маршрутизаторе будут работать два процесса: один — для маршрутизации обычного трафика с единичной адресацией, а дру­гой — для группового трафика.

В табл. 9.4 показан пример таблицы маршрутизации, сформированной прото­колом DVMRP. По сравнению с традиционной таблицей (например, для прото­кола RIP) в приведенной таблице содержатся дополнительные поля «Source Subnet» (исходная сеть) и «From-Gateway» (от маршрутизатора). Они заменяют поля «Destination» (получатель) и «Next-Hop Gateway» (следующий маршрути­затор в пути). Таблица маршрутизации протокола DVMRP хранит информацию о кратчайших путях в каждую подсеть распределенной сети, однако членство в группах не учитывается. Кроме того, не учитываются полученные усекающие сообщения.

Таблица 9.4. Таблица маршрутизации протокола DVMRP

Source Subnet	Subnet Mask	From Gateway	Metric	Status	TTL	InPort	OutPorts
128.1.0.0	255.255.0.0	128.7.5.2		Up			2,3
128.2.0.0	255.255.0.0	128.7.5.2		Up
128.3.0.0	255.255.0.0	128.6.3.1		Up			1,3
128.4.0.0	255.255.0.0	128.6.3.1		Up

Столбцы в этой таблице имеют следующее назначение:

q Source Subnet — IP-адрес сети отправителя групповых дейтаграмм;

q Subnet Mask — маска подсети отправителя. Протокол DVMRP использу­ет маску подсети в каждой сети;

q From Gateway — маршрутизатор, находящийся на одном переходе назад на пути к отправителю;

q TTL — время жизни в секундах (см. выше).

Назначение остальных полей очевидно и не требует пояснения.

Так как таблица маршрутизации протокола DVMRP не содержит информа­цию о членстве в группах, то таблица передачи формируется на основе инфор­мации об известных группах и полученных усекающих сообщениях, то есть на основании данных из таблицы маршрутизации. Таблица передачи отображает построенные деревья доставки от источника для каждой пары (отправитель, группа-получатель). В табл. 9.5 показан пример таблицы передачи.

Таблица 9.5. Передача протокола DVMRP

Source Subnet	Multicast Group	TTL	InPort	OutPorts
128.1.0.0	224.1.1.1		l(Pr)	2(P),3(P)
128.1.0.0	224.2.2.2			2(P),3
128.1.0.0	224.3.3.3
128.2.0.0	224.1.1.1			2(P),3

Столбцы в этой таблице имеют следующее назначение:

q Source Subnet — IP-адрес сети отправителя групповых дейтаграмм;

q Multicast Group — групповой IP-адрес, по которому послана дейтаграмма;

q InPort — родительский порт для данной пары. Параметр (Рr) говорит о том, что через этот порт было послано усекающее сообщение;

q OutPorts — порожденные порты. Параметр (Р) говорит о том, что марш­рутизатор получил через этот порт усекающее сообщение.

Текущую реализацию протокола DVMRP часто называют «плоской». Это связано с тем, что каждый маршрутизатор магистрали MBONE должен хранить информацию обо всех возможных маршрутах в каждую локальную сеть, связан­ную с магистралью MBONE. Так как число подсетей в магистрали постоянно увеличивается, растут и размеры служебных таблиц. В какой-то момент марш­рутизаторы MBONE перестанут справляться с нагрузкой.

Для разрешения этой проблемы предназначена иерархическая версия прото­кола DVMRP. При использовании иерархической маршрутизации магистраль MBONE будет разделена на несколько регионов (доменов) маршрутизации. Каждый регион работает со своим протоколом групповой маршрутизации, а для маршрутизации между регионами используются другие протоколы. Иерархичес­кая структура снижает требования к ресурсам маршрутизаторов: каждый маршрутизатор должен поддерживать служебную информацию только о своем регио­не и ему не нужно знать детальную структуру других регионов. Протокол пере­дачи между регионами, в свою очередь, не учитывает внутреннюю топологию регионов.

Каждый регион имеет свой уникальный идентификатор (Region-ID). Марш­рутизаторы внутри регионов могут поддерживать любой существующий группо­вой протокол маршрутизации — DVMRP, MOSPF или PIM. Эти протоколы относятся к протоколам первого уровня (Level I, L1). Каждый регион должен иметь, по крайней мере, один пограничный маршрутизатор, отвечающий за связь между регионами. Такие маршрутизаторы поддерживают протокол DVMRP — протокол второго уровня (Level 2, L2) (рис. 9.12). Они обмениваются между собой идентификаторами регионов, а не адресами подсетей внутри регионов, поэтому протокол DVMRP несколько модифицирован. Он формирует дерево доставки для пары (регион, группа-получатель), а не для обычной пары (отпра­витель, группа-получатель).

Протокол DVMRP — самый распространенный протокол групповой маршру­тизации. Его несложно внедрить, так как он основан на простом известном про­токоле RIP. С другой стороны, именно тот факт, что основой DVMRP является протокол RIP, ограничивает его применение в больших распределенных сетях.

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