2004 г.
4.4.9.4. Протокол мультикастинг-маршрутизации DVMRP
Семёнов Ю.А. (ГНЦ ИТЭФ),
book.itep.ru
DVMRP - (Distance Vector Multicast Routing Protocol) мультикастинг-протокол, где в качестве метрики применен вектор расстояния (см. также описание RIP, RFC-1058). DVMRP использует идеологию документа RFC-1054, а также алгоритм TRPB (Truncated Reverse Path Broadcasting). При получении первого пакета маршрутизатор не имеет информации о группе. Он посылает полученный пакет через все интерфейсы, кроме того, через который этот пакет получен. Если пакет пришел не через интерфейс, который используется маршрутизатором для посылки пакетов отправителю мультикаст-информации, полученный пакет выбрасывается. При получении пакета маршрутизатором, в зоне ответственности которого нет членов группы, он посылает сообщение об исключении (prun-команда). Эти сообщения используются для отсечения от дерева маршрутов веток, не содержащих членов группы. По истечении определенного времени "отрезанные" ветки дерева маршрутов "отрастают" вновь и снова могут быть отсечены (протокол TRPB). В настоящее время этот протокол рассматривается в качестве экспериментального и его широкое применение не рекомендуется. DVMRP относится к внутренним протоколам маршрутизации, пригодным для использования в пределах автономной системы.
Протокол DVMRP используется для построения дерева мультикасинг-маршрутов. Предполагается, что в дальнейшем принцип "вектора расстояния" может быть заменен алгоритмом "состояния канала" (MOSPF аналог OSPF). Целью протокола DVMRP является описание обратного пути к источнику мультикастинг-дейтограмм. Протоколы состояния канала предполагают широковещательную рассылку информации о членстве в группе. При получении мультикаст-пакета маршрутизатор определяет дерево кратчайших маршрутов.
DVMRP-дейтограмма состоит из небольшого заголовка фиксированного размера и длинного списка записей. Заголовок DVMRP-сообщений имеет формат IGMP (рис. 4.4.9.4.1):
Рис. 4.4.9.4.1 Формат заголовка DVMRP-сообщений
Поле версия равно 1. Поле тип содержит всегда код 3. А поле субтип может принимать значения:
1 = Отклик; сообщение о маршрутах до некоторого (-ых) мест(а) назначения.
2 = Запрос; поиск маршрутов до определенного места назначения;
3 = Сообщение о выходе из членов группы;
4 = Отмена заявки о выходе из группы.
Контрольная сумма вычисляется также как и в других IP-протоколах. Отдельные записи в указанном списке выполняют роль команд и их размер должен быть кратен 16 бит (их границы соответствующим образом выравниваются). Максимальная длина DVMRP-сообщения, включая заголовок, не может превышать 512 байт.
В настоящее время IETF установлены следующие значения TTL и порогов при передаче видео- и аудио-информации по мультикастинг-каналам. Колонка TTL содержит значение времени жизни IP-пакета при его отправке для каждого из указанных приложений. В колонке порог записано значение TTL, при котором пакет будет пропущен дальше.
Таблица 4.4.9.4.1. Значения TTL для различных приложений
Вид мультикастинг-туннеля | TTL | Порог |
IETF канал 1 GSM-аудио (~18кб/с) | 255 | 224 |
IETF канал 2 GSM-аудио | 223 | 192 |
IETF канал 1 видео | 127 | 96 |
IETF канал 2 видео | 95 | 64 |
Местное аудио | 63 | 32 |
Местное видео | 31 | 1 |
Мультикастинг-дейтограмма с исходным TTL=64 доступна для достаточно обширной области, а мультикастинг-дейтограмма с исходным TTL=128 доступна для целого континента, дейтограмма же с исходным TTL=255 дойдет до любой точки сети Интернет. Понятия "узкий регион" и "обширная область" достаточно неопределенные и будут уточняться позднее.
Маршрутные сообщения, посылаемые конкретному физическому интерфейсу, также как и запросы подтверждения членства в мультикастинг-группе должны иметь TTL=1. Цикл обмена маршрутной информацией между мультикастинг- маршрутизаторами (FULL_UPDATE_RATE) равен 60 сек. Подтверждение членства в группе должно посылаться каждые 120 сек (QUERY_RATE). Если подтверждение не получено в течение 2*QUERY_RATE+20 секунд, то членство в данной группе аннулируется. Соседний мультикастинг-маршрутизатор считается работающим при отсутствии подтверждений (UPDATE-сообщений) в течение 4*FULL_UPDATE_RATE.
Описанные выше протоколы DVMRP и MOSPF имеют общий недостаток - широко используют широковещательные режимы рассылки пакетов и требуют каналов с высокой пропускной способностью. Они удобны для компактных групп (например, все члены группа находятся в пределах одной автономной системы). Для обслуживания более широких групп предложен протокол PIM.
Назад: 4.4.9.3. Транспортный протокол реального времени RTCP
Оглавление: Телекоммуникационные технологии
Вперёд: 4.4.9.5. Протокол PIM