pim протокол что это
Pim протокол что это
Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.
Protocol Independent Multicast (PIM) — это группа протоколов, которые занимаются маршрутизацией мультикаст. И, хотя некоторые основы работы протоколов из этой группы одинаковы, каждый конкретный протокол работает по-разному.
«Protocol independent» в названии протокола означает, что PIM может работать с unicast таблицей маршрутизации, независимо от того, как именно она заполнены. То есть, он может использовать, например, маршруты OSPF, EIGRP, статические маршруты и др. Кроме того, сам PIM не передает информацию о маршрутах, а строит дерево для передачи мультикаст трафика на основе таблицы маршрутизации unicast.
На этой странице описываются принципы работы PIM, которые одинаковы во всех вариантах протокола. А также кратко описаны основы работы каждого варианта PIM. Подробная информация на страницах соответствующих варианту PIM.
Содержание
[править] Маршрутизация мультикаст
PIM это один из протоколов для маршрутизации мультикаст. Однако PIM не строит отдельной таблицы маршрутизации, не передает маршруты, а использует существующую таблицу маршрутизации unicast для передачи трафика и служебных сообщений.
Как и другим протоколам, для того чтобы маршрутизировать мультикаст, PIM должен построить дерево для передачи мультикаст. В зависимости от того, какой именно вариант PIM работает, может использоваться sourse tree, shared tree, одно из них, или оба одновременно.
Для PIM таблица маршрутизации мультикаст будет состоять не из маршрутов, как для unicast, и из записей вида (источник, группа) или (S, G). Эти записи могут быть двух типов:
Кроме самой записи, (S, G) или (*, G), для каждой записи хранится информация о том, какой интерфейс локального маршрутизатора ведет вверх по дереву, к источнику или RP (и откуда, соответственно, будет приходить данные мультикаст), и какие интерфейсы ведут вниз, к получателям или нижестоящим соседям (куда данные мультикаст будут передаваться).
Подробнее о деревьях передачи мультикаст трафика, а также о важной терминологии о направлении движения по дереву:
Второе фундаментальное понятие, связанное с маршрутизацией мультикаст — проверка RPF.
Reverse Path Forwarding (RPF) — это проверка, которую выполняют маршрутизаторы, для того чтобы убедиться, что multicast трафик передается по пути без петель.
[править] Семейство протоколов PIM
PIM может работать в нескольких режимах, которые можно считать разными протоколами. Базовые принципы работы, такие как, установка отношений соседства, проверка RPF, работают во всех вариантах PIM одинаково. Разные варианты протокола отличает то, как маршрутизаторы заполняют таблицу маршрутизации мультикаст, как маршрутизатор передает пакеты, которые получил от источника, каким образом маршрутизаторы узнают об источниках и группах.
Два основных режима, в которых может работать PIM:
Также в Cisco отдельно выделяют вариант PIM Sparse-Dense, который является гибридом соответствующих вариантов PIM. Подробнее о нем на странице PIM-SM в Cisco.
Кроме протоколов PIM-DM и PIM-SM, есть также протоколы, которые основаны на PIM-SM, но имеют свою специфику работы:
[править] Одновременное использование протоколов
Протоколы PIM-SM, BIDIR-PIM и PIM-SSM могут одновременно использоваться сети. Они не исключают друг друга. Если все три протокола должны работать в сети одновременно, то разграничение их работы выполняется назначением разным протоколам разных диапазонов групп. То есть, в итоге, именно группа определяет каким образом будет обрабатываться трафик, по правилам какого протокола.
Так как каждый из протоколов ориентирован на определенную модель работы, то выбрать конкретный протокол довольно просто.
PIM-DM на сегодняшний день уже считается устаревшим протоколом и редко используется.
PIM-SM используется чаще других и при небольших количествах групп и источников, может работать в любой сети.
BIDIR-PIM используется для оптимизации работы сетей, в которых используются приложения с моделью взаимодействия many-to-many. По сравнению с работой PIM-SM, в BIDIR-PIM эти приложения намного меньше влияют на сеть даже при большом количестве групп и источников.
PIM-SSM используется в сетях, где поддерживается IGMPv3, так как именно в этой версии IGMP клиент может указать рассылку от какого источника он желает (или не желает) получать.
[править] PIM-DM
В PIM-DM информация об источнике и группе распространяется по всему домену мультикаст. Выполняется это с помощью процедуры флудинга. Распространение информации об источнике и группе происходит независимо от того, есть ли в данный момент клиенты, которые хотят получать данные этой группы.
Так как информация передается всем маршрутизаторам, то каждый маршрутизатор знает о существующих группах и источниках. И следовательно, когда появляется клиент, которых хочет получать трафик определенной группы, любой маршрутизатор в мультикаст домене знает где находится источник, который передает данные этой группы, и строит SPT-дерево к источнику.
Как правило, в реальной жизни, этот вариант PIM редко используется.
[править] PIM-SM
В PIM-SM информация не флудится по всему домену, как в PIM-DM. В PIM-SM маршрутизаторы добавляются в дерево передачи мультикаст трафика, только если они явно отправляют PIM Join. То есть, явно сообщают о том, что они хотят получать трафик определенной группы. Это происходит, когда у маршрутизатора есть непосредственно присоединенные клиенты, которые хотят получать трафик (отправили IGMP Join), или когда он получил PIM Join от нижестоящего маршрутизатора.
Для координации работы в домене PIM-SM, одному из маршрутизаторов назначается роль rendezvous point (RP). RP знает обо всех парах (источник, группа) в домене. А все остальные маршрутизаторы обязательно должны знать, IP-адрес RP.
Когда появляется новый источник мультикаст, маршрутизатор, который непосредственно присоединен к источнику, регистрирует источник на RP. Таким образом RP узнает об источнике и о том, на какой адрес группы источник передает трафик, то есть о паре (S, G).
Когда маршрутизаторы получают запросы от клиентов, на присоединение к группе, то они отправляют запрос «вверх» к RP. То есть, строят shared дерево с вершиной в RP (shared потому что RP будет вершиной для всех групп). Так как RP знает об источнике, то от RP до источника строится дерево SPT, с вершиной в источнике. RP соединяет эти два дерева.
[править] Bidirectional PIM
Bidirectional PIM (BIDIR-PIM) создан для оптимизации работы PIM в сетях, где модель взаимодействия many-to-many. То есть, в таких сетях, где получатели и источники это одни и те же устройства.
По сути, BIDIR-PIM использует как основу PIM-SM, но с некоторыми изменениями.
BIDIR-PIM использует только RPT-деревья (shared tree). И, вместо проверки RPF, использует понятие Designated Forwarder (DF). А деревья, которые BIDIR-PIM строит к RP, теперь двунаправленные.
[править] Формат сообщений PIM
[править] Общие возможности различных режимов PIM
Несмотря на то, что разные варианты работы PIM (а можно сказать и разные протоколы из семейства PIM), работают по-разному, у них есть базовые общие принципы работы.
[править] Отношения соседства
Все протоколы из семейства протоколов PIM, устанавливают отношения соседства с помощью сообщений Hello.
Сообщения Hello по умолчанию отправляются каждые 30 секунд на адрес 224.0.0.13 (All-PIM-Routers).
Кроме обнаружения соседей, с помощью сообщений Hello, отслеживается состояние соседей.
Для работы PIM это очень важно, так как отправка трафика, отправка служебных сообщений, проверка RPF, возможно только на тех интерфейсах где обнаружены соседи PIM.
[править] Сообщения Assert и выбор Forwarder
Сообщение Assert позволяет маршрутизаторам, которые передают трафик одной группы в одну и ту же сеть, согласовать кто из них будет передавать трафик в сеть, для того чтобы не отправлять копии пакетов.
Когда маршрутизатор получает на исходящем интерфейсе с множественным доступом пакет multicast, он начинает отправлять сообщение Assert в сегмент. В сообщении передается информация об источнике и группе, метрике маршрута к источнику и administrative distance, которая соответствует маршруту к источнику.
Маршрутизатор, который будет отправлять трафик в сеть, определяется на основании сообщений Assert таким образом:
Маршрутизатор, который был выбран, называется Forwarder.
После выборов Forwarder продолжает отправлять multicast трафик в сеть. Другие маршрутизаторы, которые участвовали в выборах, исключают интерфейс ведущий в сегмент с множественным доступом из списка исходящих интерфейсов.
[править] Изменения unicast таблицы маршрутизации
Если таблица маршрутизации изменилась и путь к источнику multicast трафика новый, то PIM-DM тоже должен внести изменения.
Когда изменяется RPF-маршрутизатор, PIM-DM сначала отправляет сообщение Prune прежнему RPF-маршрутизатору. Затем сообщение Graft отправляется новому RPF-маршрутизатору для того чтобы построить новое дерево.
Приручаем multicast
Остановимся на анализе мультикаст-трафика через IGMP-протокол. Рассмотрим реализацию работы протокола IGMP, работы протокола PIM, отправки JOIN-запросов. После анализа проблемы была разработана оптимальная конфигурация сетевого оборудования, эффективная настройка QOS. Данная задача появилась после обнаружения проблемы в сети, такой как прерывание сигнала у клиентов, наличие фризов и прерывание звука.
IGMP — Internet Group Management Protocol — это сетевой протокол взаимодействия абонентов мультикаст-трафика и ближайшего к ним сетевого оборудования.
Пользователь имеет подписку на следующую группу IP-адресов: 224.0.0.0 до 239.255.255.255. PIM Protocol реализован в режиме Sparse mode. Это означает, что трафик льется только на ту ветку, в которой есть клиенты, желающие войти в мультикаст-группу. Они отправляют сообщения PIM Join. Если клиенты не отправляют Join, то трафик им отправляться не будет. PIM Sparse Mode включен на двух интерфейсах. В сторону источника мультикаст-трафика и в сторону клиента. На стороне клиента имеет цифровой ресивер или абонентское устройство —IPTV-приставка.
Для справки: dense mode предполагает, что мультикаст-трафик идет до абонента, и неважно, подписывается ли он на определенный канал. Мультикаст идет во все порты, потом, если он не нужен по месту назначения, то отправляется служебный пакет PIM Prune, и трафик перестает идти по этой ветке.
IGMP-протокол реализуется в сторону клиента. PIM-протокол устанавливает соседство с другими маршрутизаторами. Для этого применяются служебные сообщения PIM Hello.
В нашей сети применялась вторая версия протокола IGMP.
Абонентское устройство, которое решает получить multicast-трафик, отправляет запрос в сообщении IGMP Membership Report (так называемый репорт).
Если абонентское устройство больше не желает получать мультикаст-трафик, то оно отправляет сообщение IGMP Leave. Эта функция реализована коммутаторах уровня доступа. IGMP Membership Group-Specific Query — повторное сообщение коммутатором в сеть о том, есть ли клиентские устройства, которые будут запрашивать мультикаст-трафик. Если их нет, то передача трафика прекращается.
IGMP snooping реализуется на сетевом оборудовании, отдельного включения функции недостаточно, необходима дополнительная настройка. После включения данной функции управляемые коммутаторы могут анализировать трафик — мультикаст-поток.
Если коммутатор обнаруживает IGMP-пакет, то он вносит порт в список мультикаст-групп. Если от абонента идет сообщение IGMP Leave, то коммутатор удаляет порт из подписчиков групп.
IGMP snooping позволяет предотвращать мультикаст шторм. Если функция IGMP snooping не включена, то оборудование ретранслирует multicast-трафик во все порты, которые находятся в одном VLAN. Это не эффективно, а также способно вызвать проблемы на сетевых устройствах, вынужденных обрабатывать высокий поток данных. Это может загружать CPU-оборудования. IGMP snooping улучшает работу сети.
Однако для того, чтобы получить мультикаст-трафик, нужно реализовать эту функции на стороне клиента. К примеру, если клиент подключен через роутер, то необходимо позаботиться о включении этой функции на роутере.
Проверить корректность работы мультикаст-вещания можно путем анализа трафика через Wireshark, после включения телевидения через VLC-медиаплеер. В настройках VLC указываем, к примеру, udp:@239.255.0.A:5500. Для передачи потока используется UDP протокол, далее идет мультикаст адрес, далее порт.
При разработке QOS учитывалось, что «красить» трафик желательно ближе к ядру сети. Его необходимо красить ближе к Randezvous Point. (Ну это для нашего случая)
На коммутаторах уровня доступа у нас применялись следующие настройки:
Глубокий анализ проблемы, применение средств диагностики и понимание работы протокола IGMP позволяет выработать эффективную и оптимальную конфигурацию мультикаст-трафика в вашей сети.
Pim протокол что это
4.4.9.5 Протокол PIM
Семенов Ю.А. (ГНЦ ИТЭФ)
Протокол PIM (Protocol Independent Multicast) призван решить проблемы маршрутизации для произвольного числа и расположения членов группы и для произвольного числа отправителей информации. В настоящее время протокол не является стандартом.
Главным преимуществом данного протокола является эффективная поддержка работы «рассеянных» мультикастинг-групп. Такие группы могут включать не только членов из разных автономных систем, но и находящихся на разных континентах. Протоколы MOSPF и DVMRP хороши для сетей, где нет ограничений по пропускной способности каналов.
Базовая идеология PIM (SM и DM)
В режиме 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).
Базовая особенность PIM
Рис. 4.4.9.5.1. Иллюстрация реализации протокола мультикастинг маршрутизации PIM
Получатель посылает PIM-joint пакет в RP, устанавливая канал от RP до получателя. Из рисунка видно, что исходный маршрут d-c-b-a длиннее оптимального d-b-a. Последний может быть реализован после посылки PIM-joint команды от a к d.
При решении транспортных задач в мультимедиа чаще используется протокол UDP (малая избыточность и отсутствие подтверждений).
Алгоритм работы PIM
Ниже приводится более подробное, хотя и неполное описание протокола PIM.
Используемые сокращения и термины
Целью протокола 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 (называемый
Маршрутизаторы получают и запоминают содержимое сообщений 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.
Формат заголовка сообщения PIM
Рис. 4.4.9.5.3. Формат заголовка сообщения PIM
Таблица 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 |
Поле длина адреса характеризует длину кода адреса в байтах. Поле контрольная сумма вычисляется методом суммирования всего PIM-сообщения по модулю 1, это поле имеет длину 16 бит. Формат закодированного группового адреса показан на рис. 4.4.9.5.4.
Формат закодированного группового адреса
Рис. 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.
Поле длина маски имеет длину 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
Рис. 4.4.9.5.7. Формат сообщения register
Сообщение 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.
Рис. 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):
Сообщение 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)