Documente online.
Zona de administrare documente. Fisierele tale
Am uitat parola x Creaza cont nou
 HomeExploreaza
upload
Upload




Протокол мультикастинг-маршрутизации DVMRP

Rusa


Протокол мультикастинг-маршрутизации DVMRP Семенов Ю.А. (Гi 12212p158m 3;Ц ИТЭФ)



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-сообщений

вычисляется также как и в других IP-протоколах. Отдельные записи в указанном списке выполняют роль команд и их размер должен быть кратен 16 бит (их границы соответствующим образом выравниваются). Максимальная длина DVMRP-сообщения, включая заголовок, не может превышать 512 байт.



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

Таблица 4.4.9.4.1. Значения TTL для различных приложений

TTL

IETF канал 1 GSM-аудио (~18кб/с)

IETF канал 2 GSM-аудио

IETF канал 1 видео

IETF канал 2 видео



Мультикастинг-дейтограмма с исходным 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.




Document Info


Accesari: 991
Apreciat: hand-up

Comenteaza documentul:

Nu esti inregistrat
Trebuie sa fii utilizator inregistrat pentru a putea comenta


Creaza cont nou

A fost util?

Daca documentul a fost util si crezi ca merita
sa adaugi un link catre el la tine in site


in pagina web a site-ului tau.




eCoduri.com - coduri postale, contabile, CAEN sau bancare

Politica de confidentialitate | Termenii si conditii de utilizare




Copyright © Contact (SCRIGROUP Int. 2025 )