Магистраль mbone

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

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

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

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

Версия 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

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

Как уже было сказано, протокол 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	3	Up	200	1	2,3
128.2.0.0	255.255.0.0	128.7.5.2	5	Up	150	2	1
128.3.0.0	255.255.0.0	128.6.3.1	2	Up	150	2	1,3
128.4.0.0	255.255.0.0	128.6.3.1	4	Up	200	1	2

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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, ограничивает его применение в больших распределенных сетях.