Протоколы Internet
Протокол PIM
4.4.9.5 Протокол PIM
Семенов Ю.А. (ГНЦ ИТЭФ)
Главным преимуществом данного протокола является эффективная поддержка работы "рассеянных" мультикастинг-групп. Такие группы могут включать не только членов из разных автономных систем, но и находящихся на разных континентах. Протоколы MOSPF и DVMRP хороши для сетей, где нет ограничений по пропускной способности каналов.
PIM базируется на традиционных маршрутных протоколах, конкретно не связан ни с каким из них, им используются сформированные этими протоколами маршрутные таблицы. Существует два режима работы протокола - DM (для компактных групп) и SM (Protocol Independent Multicast-Sparse Mode (PIM-SM)). Protocol Specification. D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, RFC-2117, June 1997) (для рассеянных групп). В режиме DM протокол PIM строит дерево маршрутов аналогично DVMRP.
В режиме SM маршрутизаторы, имеющие членов мультикастинг-группы, посылают сообщения о присоединении к дереву рассылки в узлы, которые называются точками встречи (RP). Отправители используют RP для объявления о своем существовании, а получатели, чтобы узнать о новых отправителях. В качестве RP может использоваться любой маршрутизатор, поддерживающий протокол PIM.
Когда какой-то клиент хочет подключиться к некоторой группе, ближайший к нему маршрутизатор посылает специальное сообщение о включении в группу (PIM-joint) узлу, объявленному для данной группы точкой встречи (RP). Число RP в сети может быть произвольным. Узел RP пересылает сообщение о включении узлу-отправителю (или отправителям). Если маршрутизатор не имеет информации о RP, включается схема, работающая для компактных групп. При обработке сообщения о включении в группу промежуточные маршрутизаторы формируют часть дерева мультикастинг-маршрутов между RP и получателем. При отправке мультикастинг-пакета соответствующий маршрутизатор посылает узлу RP регистрационное сообщение (PIM-register), куда вкладывается информационный пакет. Если используется несколько RP, отправитель должен посылать пакеты всем RP. Получатель же должен быть подключен лишь к одному из RP. В случае, когда сообщение о включении достигнет отправителя раньше, чем RP, подключение осуществляется, минуя RP. Если необходимо оптимизировать дерево доставки пакетов, маршрутизаторы-получатели должны послать сообщение о включении самому отправителю. После этого дерево соединений видоизменяется, некоторыми узлами, если требуется, посылается сообщение об отключении. Ниже приведен пример взаимодействия узлов при формировании дерева маршрутов в режиме SM-PIM (рис. 4.4.9.5.1).
Следует заметить, что большинство протоколов для маршрутизации мультимедийной информации формируют маршрут не от отправителя к получателю, а в обратном направлении. Это имеет под собой веские причины. Дерево рассылки должно быть построено так, чтобы поток отправителя как можно дольше и меньше разветвлялся. Желательно, чтобы разветвления происходили как можно ближе к получателю. Это соображение проиллюстрировано на рис. 4.4.9.5.2. На рисунке условно, в виде сетки маршрутизаторов (желтые кружочки) показан фрагмент сети Интернет. Зеленым прямоугольником отмечен передатчик, а голубыми кружочками приемники – члены группы. Маршруты от передатчика к приемникам можно проложить индивидуально (выделены зеленым цветом), а можно и “коллективно” (синий цвет). От передатчика до маршрутизатора отмеченного красным цветом следует один поток для всех приемников. Такое решение приводит к минимизации сетевой загрузки, ведь всем приемникам посылаются одни и те же пакеты. Чем позже их пути разойдутся, тем лучше. Именно этот алгоритм и реализует протокол PIM. Точки разветвления потоков на рис. 4.4.9.5.2 отмечены крестами (RP).
Рис. 4.4.9.5.1. Иллюстрация реализации протокола мультикастинг маршрутизации PIM
Получатель посылает PIM-joint пакет в RP, устанавливая канал от RP до получателя. Из рисунка видно, что исходный маршрут d-c-b-a длиннее оптимального d-b-a. Последний может быть реализован после посылки PIM-joint команды от a к d.
При решении транспортных задач в мультимедиа чаще используется протокол UDP (малая избыточность и отсутствие подтверждений).
Рис. 4.4.9.5.2.
Ниже приводится более подробное, хотя и неполное описание протокола pim.
Используемые сокращения и термины
Маршрутизатор получает сообщения join/prune от соседних маршрутизаторов, которые обслуживают группы пользователей. Он переадресует информационные пакеты, адресованные группе G, только через те интерфейсы, через которые ранее было получено сообщение join.
Специальный маршрутизатор DR ( designated router) рассылает периодически сообщения join/prune в точки встречи (RP) для каждой группы, в которой имеются активные участники. Для описания дерева маршрута используются маршрутные записи, содержащие адрес отправителя, групповой адрес, номер входного интерфейса, через который принимаются пакеты, список интерфейсов, через которые осуществляется рассылка, таймеры, флаги и пр. Выходные интерфейсы указывают на соседние маршрутизаторы, через которые пролегает путь к RP. В центре этого маршрутного дерева, включающего в себя всех членов группы, находится RP. Когда источник информации посылает что-то группе в первый раз, его DR отправляет уникастное сообщение register в RP.
Для того чтобы присоединиться к мультикатинг-группе G, ЭВМ передает IGMP-сообщение (или ICMP в случае IPv6). При этом предполагается, что ЭВМ будет выполнять функции получателя (R).
Когда DR получает уведомление о членстве новой группы от IGMP G, он просматривает соответствующие RP. DR формирует запись мультикастинг-маршрута для группы (*,g) [wild card мультикастная запись для группы G, определяющая ее состояние]. Адрес RP включается в специальное поле маршрутной записи, содержащейся в периодически рассылаемых сообщениях join/prune (см. рис. 4.4.9.5.9). При этом в список выходных интерфейсов включается тот, к которому подключен новый член группы, а в качестве входного интерфейса указывается тот, через который посылаются уникастные пакеты к RP.
Когда не остается ни одного непосредственно подключенного члена группы, протокол IGMP уведомляет об этом DR. Если DR не имеет ни локальных, ни удаленных получателей, запись (*,g) ликвидируется.
Запись (*,g), инициирует формирование DR сообщения join/prune с RP-адресом в его join-списке и установленными битами WC и RPT. Равенство WC=1 говорит о том, что согласно этой записи будут пересылаться пакеты любого отправителя. Список удаления (prune) остается пустым. Когда бит RPT=1, это указывает на то, что подключение осуществлено через общее RP-дерево и, следовательно, сообщение join/prune будет идти по этому RP-дереву. Когда бит WC= 1, это означает, что адрес принадлежит RP, а получатели предполагают получать пакеты от всех отправителей.
Каждый маршрутизатор, расположенный по пути к отправителю, создает и отслеживает изменения маршрутной записи для (*,g), когда он получает сообщения join/prune с RPT=WC=1. Интерфейс, через который получено сообщение join/prune, добавляется к списку выходных интерфейсов (OIF) для (*,g). На основе этой записи каждый маршрутизатор по пути между получателем и RP посылает сообщение join/prune, в котором RP включен в список join. Поле данных этого пакета содержит мультикаст-адрес=G, join=RP, wc-бит, RPT-бит, prune=null.
Когда ЭВМ начинает посылать мультикастинг-пакеты группе, сначала DR должен доставить их в RP для последующей раздачи по дереву RP. DR отправителя в начале инкапсулирует каждый информационный пакет в сообщение register (см. рис. 4.4.9.5.7) и отправляет его по уникастному адресу RP данной группы. RP извлекает каждое сообщение register и переадресует вложенные информационные пакеты вдоль RP-дерева.
Если поток данных позволяет использовать дерево кратчайшего пути до отправителя (SPT), RP может сформировать новую маршрутную запись для дерева мультикаст-маршрута, специфичного для данного отправителя (SP-дерево).
DR отправителя прекратит инкапсуляцию информация в пакеты registers, когда он получит сообщение register-stop от RP. RP отравляет сообщения register-stop в качестве отклика на сообщение registers, если RP не имеет более активных членов группы.
Новый приемник может подключиться к существующему RP-дереву, для которого установлено обрезание (prune state) (например, из-за того, что другие получатели переключились на SP-деревья). В этом случае состояние обрезания аннулируется с тем, чтобы обеспечить доставку данных новому получателю.
В стабильном состоянии каждый маршрутизатор периодически посылает сообщения join/prune для каждой маршрутной записи PIM. Сообщения join/prune посылаются соседу, указанному в соответствующей записи. Такие сообщения позволяют отследить изменения состояния системы и топологию членства в группе.
Для того чтобы получить информацию о RP, все маршрутизаторы в пределах PIM-домена собирают сообщения bootstrap. Сообщения bootstrap пересылаются от узла к узлу в пределах домена. За организацию рассылки этих сообщений несет ответственность специальный маршрутизатор BSR (bootstrap router). Сообщения bootstrap используются для выполнения динамического выбора BSR, когда это необходимо, а также для получения информации об RP. Домен в этом контексте представляет собой набор смежных маршрутизаторов, поддерживающих PIM, и сконфигурированных для совместной работы в рамках границ, определенных пограничными маршрутизаторами PMBR (PIM multicast border router), соединяющими PIM-домен с остальным Интернет.
Маршрутизаторы используют набор доступных RP (называемый {RP-set}), для того чтобы осуществить связь отдельных групп с соответствующими RP. Некоторое число маршрутизаторов в домене конфигурируется как кандидаты для выполнения функций BSR. Для назначения BSR в домене существуют простые правила выбора. Часть маршрутизаторов в домене конфигурируются также как кандидаты для работы в качестве RP (C-RP); как правило, это те же маршрутизаторы, что и кандидаты в BSR. Кандидат в RP периодически посылает BSR домена уникастное сообщение candidate-rp-advertisement (C-RP-ADVS). C-RP-ADVS включает в себя адрес C-RP, а также опционный групповой адрес и поле длины маски. BSR включает набор этих кандидатов в RP (набор RP), вместе с соответствующим групповым префиксом периодически рассылаемых сообщений.
Маршрутизаторы получают и запоминают содержимое сообщений bootstrap. Когда DR получает указание о членстве в группе от IGMP, DR использует хэш-функцию для установления соответствия между групповым адресом и одним из C-RP, чей префикс включает в себя данную группу. Для конкретной группы G, хэш-функция использует только те C-RP, чьи групповые префиксы покрывают G. Когда соответствие установлено, DR посылает сообщение join/prune (или уникастный пакет register) соответствующему rp.
Сообщения bootstrap информирует о работоспособности точек встречи (rp), обслуживающих сессию. Если RP включен в сообщение, он считается рабочим, в то время как отсутствие rp в сообщении, приводит к удалению его из списка, с которым работает алгоритм. Каждый маршрутизатор продолжает использовать содержимое, полученное в последнем сообщении bootstrap, пока не будет получено новое сообщение bootstrap.
Если зона PIM-домена теряют доступ к старому BSR, они выберут новый BSR, который разошлет RP-набор, содержащий RP, доступные в пределах данной зоны. Любая область в любой заданный момент времени обслуживается только одним BSR, который и осуществляет посылку сообщений bootstrap.
Для того чтобы обеспечить совместимость с сетями, работающими в режиме DM, с протоколами типа DVMRP, все пакеты, генерируемые в области PIM-SM, должны быть переправлены мультикастным пограничным маршрутизаторам области PMBR (multicast border router) и переадресованы в сеть DVMRP. Маршрутизатор PMBR размещается на границе домена PIM-SM и взаимодействует с другими типами мультикаст-маршрутизаторов, например, такими, которые поддерживают протокол DVMRP. Таким образом, PMBR должен поддерживать оба протокола. Для поддержки совместной работы все маршрутизаторы должны поддерживать специальный тип маршрутных записей, обозначаемых (*,*,rp).
Информационные пакеты, соответствуют записи (*,*,rp), если нет никаких других записи, например, (s,g) или (*,g), групповой адрес места назначения пакета согласуется с RP, указанным в записи (*,*,rp). В этом смысле запись (*,*,rp) представляет собой объединение всех групп, которые работают через данную точку встречи RP. PMBR инициализируют состояние (*,*,rp) для каждой RP в каждом доменном наборе RP. Состояние (*,*,rp) заставляет pmbr посылать сообщения (*,*,rp) join/prune каждой активной RP в домене. В результате деревья рассылки строятся так, что передают все пакеты, возникающие в пределах PIM-домена (и ретранслируются в точки встречи) в направлении пограничных маршрутизаторов PMBR.
PMBR осуществляют также доставку внешних пакетов маршрутизаторам в пределах PIM-домена. Для решения этой задачи эти маршрутизаторы инкапсулируют внешние пакеты, полученные через интерфейсы DVMRP, в сообщения register, после чего уникастным образом переадресуют их в точку встречи RP PIM-домена. Сообщение register имеет бит, указывающий на то, что пакет сформирован пограничным маршрутизатором.
Информационные пакеты обрабатываются также как и при других мультикаст-схемах. Маршрутизатор сначала проверяет адреса отправителя и группы. Затем определяется адрес RP, если непосредственная передача невозможна. Если пути доставки не существует, пакет выбрасывается. При наличии пути выясняется интерфейс, через который должна производиться передача, и пакет переадресуется.
Информационные пакеты никогда не вызывают обрезания ветвей маршрутного дерева. Однако информационные пакеты могут запустить процессы, которые в конечном итоге приведут к такому результату.
Когда имеется несколько маршрутизаторов, соединенных с сетью, имеющей много каналов доступа, один из них должен быть выбран в качестве ретранслятора (DR; обычно это маршрутизатор с наибольшим IP-адресом). Это справедливо для любой точки сети в любое время. Процедуре выбора предшествует обмен сообщениями Hello.
При наличии параллельных проходов к источнику или RP для выбора маршрута применяются сообщения assert. Используя сообщения assert, адресованные `224.0.0.13' (группа all-pim-routers) в локальной сети, вышестоящий маршрутизатор может узнать, где осуществляется переадресация сообщений. Нижестоящие маршрутизаторы, получая сообщения assert, узнают, какой маршрутизатор выбран в качестве ретранслятора, и куда следует посылать сообщение join. Обычно это тот же нижележащий маршрутизатор-сосед (reverse path forwarding), но иногда это может быть и не так, например, когда в локальной сети используется несколько протоколов маршрутизации. RPF-сосед для конкретного отправителя или RP является следующим маршрутизатором, которому переправляются пакеты по пути к отправителю или RP. По этой причине он может рассматриваться как хорошая промежуточная инстанция для пересылки пакетов отправителем.
Когда приходит пакет в выходной интерфейс, маршрутизатор посылает сообщение assert в локальную сеть с множественным доступом, указывая, какую метрику он использует для достижения отправителя информационных пакетов. Маршрутизатор с наименьшим значением метрики и станет базовым ретранслятором. Все прочие вышестоящие маршрутизаторы вычеркнут этот интерфейс из своего списка выходных интерфейсов. Нижестоящие маршрутизаторы также производят сравнение, если ретранслятором не является RPF-сосед.
С понятием метрики связано и значение предпочтения метрики. Оно введено, чтобы решать проблемы в случае, когда вышестоящие маршрутизаторы использует другие уникастные протоколы маршрутизации. Численно меньшее значение предпочтения соответствует более высокому приоритету. Значение предпочтения рассматривается в качестве старшей части метрики при сравнении, которое осуществляется при обработке сообщений assert. Предпочтение может быть присвоено уникастному протоколу маршрутизации и должно быть взаимосогласованным для всех маршрутизаторов локальной сети с множественным доступом.
Сообщения assert нужны для маршрутных записей (*,g), так как деревья RP и SP для некоторых групп могут возникать зоны перекрытия в сетях с множественным доступом. Когда assert посылается для записи (*,g), RPT-бит устанавливается равным 1. Первый бит поля предпочтения всегда устанавливается равным 1, для того чтобы отметить, что проход соответствует RP-дереву. RPT-бит всегда обнуляется для предпочтения, которое относится к записям SP-деревьев. Это приводит к тому, что проход через SP-дерево выглядит всегда редпочтительнее, чем проход через RP-дерево. Когда деревья SP и RP перекрываются для какой-то LAN, этот механизм устраняет дублирование для данной сети.
DR может уступить процесс (*,g) assert другому маршрутизатору LAN, если существует несколько проходов к rp через lan. В этом случае DR не является более "ближайшим" маршрутизатором для местных получателей и он удаляет LAN из своего (*,g) списка выходных интерфейсов. Маршрутизатор-победитель становится “ближайшим” и ответственным за рассылку сообщений (*,g) join для RP.
Подавление join/prune может использоваться в локальных сетях с множественным доступом, для того чтобы сократить число дублирующих управляющих сообщений. Для нормальной работы протокола этого не требуется. Если получено сообщение join/prune, которое соответствует существующим маршрутным записям (s,g), (*,g) или (*,*,rp) для данного входного интерфейса, а поле holdtime сообщения join/prune больше, чем join/prune-holdtime получателя, может быть запущен таймер (join/prune-suppression-таймер) маршрутной записи получателя с тем, чтобы заблокировать последующие сообщения join/prune. После завершения работы таймера получатель отправляет сообщение join/prune, и возобновляет периодическую посылку join/prune, для данной записи. Таймер join/prune-suppression должен перезапускаться каждый раз, когда приходит сообщение join/prune с большим значением holdtime.
Когда уникастная маршрутизация претерпевает изменения, RPF производит проверку активных маршрутных записей (s,g), (*,g) и (*,*,rp) и вносит необходимые поправки. В частности, если в списке выходных интерфейсов появляется новый принимающий интерфейс, то он удаляется из этого списка. Предшествующий входной интерфейс может быть добавлен в список выходных интерфейсов с помощью последующих сообщений join/prune, поступающих от нижестоящих узлов. Сообщения join/prune, полученные текущим входным интерфейсом, игнорируются, а сообщения, полученные новыми или существующими выходными интерфейсами, обрабатываются. Остальные выходные интерфейсы останутся в прежнем состоянии до тех пор, пока не будут отключены нижележащими маршрутизаторами или по таймауту из-за отсутствия соответствующих сообщений join/prune. Если маршрутизатор имеет запись (s,g) с установленным битом spt, а обновленная запись IIF(s,g) не отличается от IIF(*,g) или IIF(*,*,rp), тогда маршрутизатор переводит бит SPT в нулевое состояние.
Соседи-маршрутизаторы, поддерживающие протокол pim, периодически обмениваются сообщениями Hello (см. рис. 4.4.9.5.6). Сообщения Hello могут также рассылаться мультикастным образом с использованием адреса 224.0.0.13 (группа all-pim-routers). Пакет содержит значение holdtime (время сохранения информации).
Когда маршрутизатор получает сообщение hello, он запоминает IP-адрес соседа, устанавливает таймер отправки на время, соответствующее holdtime, заключенное в Hello, и определяет выделенный маршрутизатор (DR) для данного интерфейса. В качестве DR выбирается объект с наибольшим Ip.
Когда маршрутизатор, который является активным DR, получает Hello от нового соседа (например, от IP-адреса, которого нет в таблице DR), DR уникастным образом передает RP-информацию новому соседу.
PIM-соседи, от которых в течение определенного времени не поступало сообщений Hello, считаются отключившимися. Если DR отключился, выбирается новый DR из числа соседей с наибольшим IP-адресом.
Сообщения join/prune служат, для того чтобы подключить или удалить ветвь мультикастинг-дерева рассылки. Сообщение содержит как join-, так и prune-списки, любой из них может иметь нулевую длину. Эти сообщения содержат все подключенные и отсоединенные источники данных, достижимые через данный узел адресат сообщения. Период отправки сообщений join/prune определяется значением [join/prune-period].
Маршрутизатор периодически посылает сообщения join/prune каждому конкретному RPF-соседу, соответствующему каждой маршрутной записи (s,g), (*,g) и (*,*,rp). Сообщения join/prune посылаются только тогда, когда RPF-сосед является PIM-соседом.
Кроме периодически рассылаемых сообщений некоторые из join/prune пакетов могут генерироваться как следствие следующих событий:
Может так случиться, что размер сообщения join/prune превысит MTU сети. В этом случае сообщение может быть фрагментировано, информация, относящаяся к различным группам, будет послана в разных пакетах. Однако, если сообщение join/prune должно быть фрагментировано, полный prune-список, соответствующий группе G, должен быть включен в одно сообщение join/prune согласно RP-дереву join для G. Если такая семантическая фрагментация невозможна, при транспортировке пакетов от соседа к соседу должна использоваться IP-фрагментация.
Для любой новой записи (s,g), (*,g) или (*,*,rp), сформированной входящим сообщение join/prune, бит SPT сбрасывается.
Если запись имеет таймер join/prune-suppression, полученное сообщение join/ prune не указывает на маршрутизатор в качестве места назначения, тогда принимающий маршрутизатор рассматривает join- и prune-списки, с тем чтобы выяснить, нет ли там адресов полностью соответствующих существующим состояниям (s,g), (*,g) или (*,*,rp), для которых принимающий маршрутизатор осуществляет рассылку сообщений join/prune. Элемент join- или prune-списка полностью соответствует маршрутной записи, только тогда, когда их IP-адреса и RPT-флаги тождественны. Если приходящее сообщение join/prune полностью соответствует существующим записям (s,g), (*,g) или (*,*,rp), а сообщение join/prune приходит на входной интерфейс для данной записи, маршрутизатор сравнивает holdtime сообщения со своим собственным значением join/prune-holdtime. Если его значение join/prune-holdtime меньше, запускается таймер join/prune-suppression. Если join/prune-holdtime равно holdtime сообщения, коллизия разрешается в пользу отправителя сообщения join/prune, который имеет больший ip-адрес. Когда время join/prune таймера истекает, маршрутизатор отправляет сообщение join/prune для соответствующей маршрутной записи.
Когда отправитель начинает отправку данных группе, его пакеты инкапсулируются в сообщения register и посылаются в RP. Если скорость передачи гарантируется каналом, RP устанавливает соответствующее состояние для отправителя и начинает посылать сообщения (s,g) join/prune отправителю с S в join-списке.
Когда DR получает сообщение register-stop, он перезапускает таймер register-suppression в соответствующей записи (s,g) на register-suppression-timeout секунд. Если имеются данные, которые должны быть зарегистрированы, DR может послать RP сообщение register нулевой длины, за probe-time секунд до истечения времени таймера register- suppression.
Сообщения assert используются для принятия решения, какой из параллельных маршрутизаторов, подключенных к локальной сети с множественным доступом, должен быть ответственным за ретрансляцию пакетов в LAN.
Все управляющие сообщения PIM имеют номер протокола 103. Сообщения PIM являются либо уникастными (например, registers и register-stop), либо мультикастными для группы `all-pim-routers' `224.0.0.13' (например, join/prune, asserts, и т.д.). Формат заголовка пакета протокола PIM показан на рис. 4.4.9.5.3.
Рис. 4.4.9.5.3. Формат заголовка сообщения PIM
Поле OIM VER – версия протокола (в настоящее время = 2). Поле тип характеризует PIM-сообщение. Возможные значения поля тип представлены в таблице 4.4.9.5.1.
Таблица 4.4.9.5.1. Коды типа сообщений
| Код поля тип | Тип сообщения pim |
| 0 | hello |
| 1 | register |
| 2 | register-stop |
| 3 | join/prune |
| 4 | bootstrap |
| 5 | assert |
| 6 | graft (используется только в pim-dm) |
| 7 | graft-ack (используется только в pim-dm) |
| 8 | candidate-rp-advertisement |
Рис. 4.4.9.5.4. Формат закодированного группового адреса
Поле длина маски имеет 8 бит. Значение поля определяет число последовательных бит, выровненных по левому краю, которые определяют адрес. Маска равна или меньше длины адреса * 8 (то есть 32 бита для IPv4 и 128 для IPv6). Поле групповой мультикаст адрес содержит адрес группы и имеет число байт, равное указанному в поле длина адреса. Формат кодированного адреса отправителя показан на рис. 4.4.9.5.5.
Рис. 4.4.9.5.5. Формат кодированного адреса отправителя
Поле бит s (бит рассеянности) содержит 1 для PIM-SM. Этот бит используется для обеспечения совместимости с PIM v.1.
Поле бит W (бит WC). Бит WC =1, если подключение (join) или удаление (prune) используются для маршрутной записи (*,g) или (*,*,rp). Если wc=0, join или prune используются для маршрутной записи (s,g), где s – адрес отправителя. Сообщения join и prune, посылаемые в RP, должны иметь этот бит равным 1.
Поле бит R (бит RPT). Бит RPT=1, если информация о (s,g) послана в RP. Если RPT=0, информация должна быть послана S, где S – адрес отправителя.
Поле длина маски имеет длину 8 бит. Значение этого поля охарактеризовано выше в комментарии к рисунку 4.4.9.5.4.
Поле адрес отправителя имеет длину, определяемую полем заголовка длина адреса. Для IPv4, она равна 4 октетам. Формат сообщения Hello показан на рис. 4.4.9.5.6.
Первые два байта представляют собой заголовок PIM-сообщения. Поле optiontype определяет тип опции, значение которой задано в поле optionvalue. Поле optionlength задает длину поля optionvalue в байтах. Поле optionvalue имеет переменную длину и содержит значение опции. Поле опция может содержать следующие значения:
Рис. 4.4.9.5.6. Формат сообщения Hello
optiontype = 1; optionlength = 2; optionvalue = holdtime; где holdtime равно времени в секундах, в течение которого получатель должен сохранять доступность к соседу. Если holdtime установлено равным `0xFFFF', получатель этого сообщения никогда не прервет соединение с соседом по таймауту. Это может использоваться для каналов ISDN, для того чтобы избежать поддержания канала путем периодической посылки сообщений Hello. Более того, если holdtime= 0, информация объявляется устаревшей немедленно. Диапазон значений optiontype 2 – 16 зарезервирован на будущее. Сообщение register посылается DR или PMBR в RP, когда необходимо передать мультикаст-пакет по rp-дереву. IP-адрес отправителя при этом равен адресу DR, а адрес места назначения – адресу RP. Формат сообщения register показан на рис. 4.4.9.5.7. Постоянная часть заголовка здесь идентична, показанной на рис. 4.4.9.5.3.
Рис. 4.4.9.5.7. Формат сообщения register
Поле B – (бит border) пограничный бит. B=1, если маршрутизатор непосредственно соединен с отправителем. Поле N – бит нулевого регистра. n устанавливается DR равным 1 при тестировании RP до истечения времени регистрации (register-suppression timer). Поле информационный мультикаст-пакет представляет собой оригинальное сообщение, посланное отправителем.
Сообщение register- stop является уникастным, направляемым от RP к отправителю сообщения register. IP-адрес отправителя является адресом, к которому направлялось сообщение регистрации. IP-адрес места назначения равен адресу отправителя сообщения register. Формат сообщения register-stop показан на рис. 4.4.9.5.8.
Рис. 4.4.9.5.8. Формат сообщения register-stop
Поле закодированный групповой адрес имеет тот же смысл, что и на рис. 4.4.9.5.4. Для сообщений register-stop поле длины маски содержит длину адреса * 8 (32 для IPv4), если сообщение послано для одной группы.
Поле уникастный адрес отправителя представляет собой IP-адрес ЭВМ отправителя из мультикастного информационного пакета. Длина этого поля в байтах задано полем длина адреса. Значение (0.0.0.0) может быть использовано для обозначения любого адреса.
Сообщение join/prune посылается маршрутизаторами в направлении вышестоящих отправителей и RP. Сообщения join служит для построения совместно используемых маршрутных деревьев (RP-деревьев) или деревьев отправителей (SPT). Сообщения prune посылаются для отключения деревьев отправителей, когда участники покидают группу, а также для отправителей, которые не используют общее дерево. Формат сообщения join/prune показан на рис. 4.4.9.5.9.
Рис. 4.4.9.5.9. Формат сообщения join/prune
Поле адрес вышестоящего соседа представляет собой IP-адрес RPF или вышестоящего соседа. Поле holdtime характеризует время в секундах, в течение которого получатель должен поддерживать активное состояние join/prune. Если holdtime сделано равным `0xffff', получатель сообщения отключает таймаут для данного выходного интерфейса. Если holdtime сделано равным `0', таймаут происходит немедленно. Поле число групп равно количеству мультикаст-групп, содержащихся в сообщении.
Поле закодированный мультикастный групповой адрес имеет формат, показанный на рис. 4.4.9.5.4. Произвольная группа (wildcard) (*,*,rp) характеризуется адресом 224.0.0.0 и `4' в поле длина маски. Подключение (*,*,rp) имеет биты WC и RPT равные 1.
Поле число подключенных отправителей равно количеству адресов подключенных отправителей для данной группы. Поля адрес подключенного отправителя -1 .. N представляют собой список отправителей, которым посылающий маршрутизатор переправляет мультикастные дейтограммы при получении их через интерфейс, на который пришло данное сообщение. Формат полей кодированного адреса отправителя следует описанию на рис. 4.4.9.5.5.
Рис. 4.4.9.5.10. Формат сообщения bootstrap
Сообщения bootstrap пересылаются мультикастным способом группе `all-pim-routers', через все интерфейсы, имеющие PIM-соседей (за исключением того, через который получено сообщение). Сообщения bootstrap генерируются в BSR и посылаются с TTL=1. Формат сообщения bootstrap показан на рис. 4.4.9.5.10.
Сообщение bootstrap делится на семантические фрагменты, если исходное сообщение превосходит предельный размер пакета. Формат этих фрагментов представлен ниже (см. также рис. 4.4.9.5.10):
Поле метка фрагмента является случайным числом и служит для идентификации фрагментов принадлежащих одному и тому же сообщению. Фрагменты одного и того же сообщения имеют идентичные метки фрагмента. Поле длина хэш>-маски – это длина маски хэш функции в битах. Для IPv4 рекомендуется значение 30, а для IPv6 - 126. Поле BSR-приоритет содержит значение BSR-приоритета для включенного BSR. Это поле рассматривается как старший байт при сравнении BSR-адресов. Поле уникастный BSR-адрес является IP-адресом маршрутизатора (bootstrap) домена. Размер этого поля в байтах специфицирован в поле длина адреса. Поля закодированный групповой адрес -1..n является групповым префиксом (адрес и маска), с которым ассоциируются кандидаты RP. Поля число RP -1..N равны числу адресов кандидатов RP, включенных в сообщение bootstrap для соответствующего группового префикса. Маршрутизатор не замещает старый RP-набор для данного группового префикса до тех пор, пока не получит новое число RP-адресов для этого префикса. Адреса могут содержаться в нескольких фрагментах. Если получена только часть RP-набора для данного префикса, маршрутизатор эту часть выбрасывает, не изменяя RP-набора. Поля FRAG RP-cnt-1..m представляет собой число адресов кандидатов RP, включенных в этот фрагмент сообщения bootstrap, для соответствующего группового префикса. Поле `FRAG RP-cnt' облегчает разбор RP-набора для данного группового префикса, когда он размещается в более чем одном фрагменте. Поля уникастные rp-адреса -1..m представляют собой адреса кандидатов RP, для соответствующего группового префикса. Длина поля в байтах специфицировано полем длина адреса. Поля rp1..m-holdtime характеризуют значения holdtime для соответствующих RP. Это поле копируется из поля `holdtime' RP, записанного в BSR.
Сообщение assert посылается когда мультикастный информационный пакет получен выходным интерфейсом, соответствующим (s,g) или (*,g), относящимся к отправителю. Формат такого сообщения представлен на рис. 4.4.9.5.11.
Рис. 4.4.9.5.11. Формат сообщения assert
Поле закодированный групповой адрес характеризует групповой адрес места назначения пакетов, который явился причиной посылки сообщения assert. Поле уникастный адрес отправителя содержит IP-адрес отправителя из дейтограммы, вызвавшей посылку мультикастного пакета Assert. Длина поля в байтах определена полем длины адреса. Поле R
представляет собой RPT-бит. Если IP мультикастинг дейтограмма, вызвавшая посылку пакета assert направляется вниз по RP-дереву, тогда RPT-бит равен 1. Если маршрутизация осуществляется вдоль SPT, бит равен 0. Поле предпочтение несет в себе значения кода предпочтения, присвоенного уникастному протоколу маршрутизации, который организует проход до ЭВМ. Поле метрика содержит значение метрики для таблицы маршрутизации. Единицы измерения должны соответствовать требованиям маршрутного протокола.
Сообщения кандидата RP посылаются периодически C-RP способом и уникастно адресуются к BSR. Формат таких сообщений показан на рис. 4.4.9.5.12.
Рис. 4.4.9.5.12. Формат сообщения кандидата RP (C-RP)
Поле # префиксов (Prefix-Cnt) содержит количество кодированных групповых адресов, включенных в сообщение, указывая групповые префиксы, для которых производится C-RP оповещение. Значение поля Prefix-Cnt = `0' предполагает использование префикса 224.0.0.0 с длиной маски 4, что означает - все мультикастные группы. Если C-RP не снабжена информацией о групповом префиксе, C-RP заносит в поле значение по умолчанию равное `0'. Поле A характеризует бит указания. Этот бит указывает, что BSR не должен переписывать информацию о групповых префиксах, приведенную в C-RP оповещении. В большинстве случаев C-RP устанавливает этот бит, равным 0. Поле Holdtime содержит значение времени, в течение которого оповещение корректно. Это поле позволяет определить время, когда оповещение устареет. Поле уникастный RP-адрес представляет собой адрес интерфейса, который объявляется кандидатом в RP. Длина этого поля в байтах определена полем длина адреса. Поле закодированный групповой адрес -1..n является групповым префиксом, для которого производится уведомление кандидатом в RP.
Литература
| 1 | Deering, S., D.Estrin, D.Farinacci, V.Jacobson, C.Liu, L.Wei, P.Sharma, and A.Helmy. Protocol independent multicast (pim) : Motivation and architecture. Work in Progress. |
| 2 | Deering, S., D.Estrin, D.Farinacci, V.Jacobson, C.Liu, and L.Wei. The PIM architecture for wide-area multicast routing. ACM Transactions on Networks, April 1996. |
| 3 | Estrin, D., D.Farinacci, V.Jacobson, C.Liu, L.Wei, P.Sharma, and A.Helmy. Protocol independent multicast-dense mode (pim-dm): Protocol specification. Work in Progress. |
| 4 | Deering, S. Host extensions for ip multicasting, Aug 1989. RFC1112. |
| 5 | Fenner, W. Internet group management protocol, version 2. Work in Progress. |
| 6 | Atkinson, R. Security architecture for the internet protocol, August 1995. RFC-1825. |
| 7 | Ballardie, A.J., P.F. Francis, and J.Crowcroft. Core based trees. In Proceedings of the ACM SIGCOMM, San Francisco, 1993. |
