Протокол PIM
Относительно недавно мне посчастливилось познакомить и даже поконфигурять multicast routing для IPTV. Изначально, я с этой темой была совершенно не знакома, и это заставило меня вылакать горлышко от цистерны водки перекопать огромное количество документации, чтобы войти в курс дела.
И вот незадача. Обычно в документации выкладывают все и сразу и для человека, впервые столкнувшегося с этой темой, не понятно с чего начать. Во время чтения pdf’ок я ловила себя на мысли, что было бы неплохо наткнуться где-нибудь на статью, которая могла бы коротким путем провести от теории к практике, чтобы понять с чего стоит начать и где заострить внимание.
Мне не удалось обнаружить такую статью. Это побудило меня написать эту статейку для тех, кто также как и я столкнется с вопросом, что это за зверь IPTV и как с ним бороться.
Введение
Это моя самая первая статья (но не последняя! есть еще много зверей), постараюсь изложить все как можно доступнее.Первым делом озвучим несколько понятий, чтоб исключить дальнейшие недопонимания. Существует три вида трафика:
- unicast - одноадресный, один источник потока один получатель
- broadcast - широковещательный, один источник, получатели все клиенты в сети
- multicast - многоадресный, один отправитель, получатели некоторая группа клиентов
Какой вид трафика использовать для IPTV?
Очевидно, что для вещания каналов наибольшее предпочтение отдается multicast.
Любой TV-канал, который мы хотим вещать в сеть, характеризуется адресом группы, который выбирается из диапазона, зарезервированного для этих целей: 224.0.0.0 – 239.255.255.255
.
Для работы IPTV необходим роутер, поддерживающий multicast (далее MR). Он будет отслеживать членство того или иного клиента в определенной группе, т.е. постоянно следить какому клиенту какой отправлять TV-канал.
Для того чтобы клиент смог зарегистрироваться в одной из этих групп и смотреть TV-канал используется протокол IGMP (Internet Group Management Protocol).
Немного о том, как работает IGMP.
Есть сервер, который включен в роутер MR. Этот сервер вещает несколько TV-мультиков, например:Клиент включает канал News, тем самым, сам не подозревая, он отправляет запрос на MR для подключения к группе 224.12.0.1. С точки зрения протокола IGMP это запрос “JOIN 224.12.0.1 ”.
Если пользователь переключается на другой канал, то он сначала отправляет уведомление MR, что он отключает канал News или покидает эту группу. Для IGMP это “LEAVE 224.12.0.1 ”. А затем повторяет аналогичный запрос JOIN для нужного канала.
MR иногда спрашивает всех: “а какой группе кто подключен?”, чтобы отключать тех клиентов, с которыми оборвалась связь и они не успели отправить уведомление LEAVE . Для этого MR использует запрос QUERY .
Ответ абонента на этот запрос это MEMBERSHIP REPORT , который содержит список всех групп, в которых состоит клиент.
Настройка multicast routing.
Предположим, что клиенты одной группы смотрят один и тот же мультик, но находятся они в разных сегментах сети (network A и network B). Для того, чтобы они получили свой мультик и придуман multicast routing.
Пример настройки роутеров MR1 и MR2.
| Network A | 10.1.0.0/24 |
| Network B | 10.2.0.0/24 |
| Network C | 10.3.0.0/24 |
| MR1 | MR2 |
| MR1#sh run Ip multicast-routing |
MR2#sh run Ip multicast-routing |
Команда "ip multicast-routing " включает соответствующий routing, если же он выключен, то роутер не пересылает multicast пакеты, т.е. они не дойдут до недоумевающего зрителя мультиков.
Остановимся чуть поподробнее на команде "ip pim sparse-mode ".
Про режимы протокола PIM и сам протокол.
PIM (Protocol Independent Multicast) - протокол маршрутизации multicast рассылки. Он заполняет свою таблицу multicast маршрутизации на основе обычной таблицы маршрутизации. Эти таблицы можно просмотреть с помощью команд “sh ip mroute ” и “sh ip route ” соответственно. Целью протокола PIM является построение дерева маршрутов для рассылки multicast сообщений.У протокола PIM существует два основных режима: разряженный (sparse mode ) и плотный (dense mode ). Таблица multicast маршрутизации для них выглядит немного по-разному. Иногда эти режимы рассматривают как отдельные протоколы - PIM-SM и PIM-DM.
В нашей конфигурации на интерфейсах мы указали режим "ip pim sparse-mode ".
(config-if)# ip pim?
Dense-mode Enable PIM dense-mode operation
sparse-dense-mode Enable PIM sparse-dense-mode operation
sparse-mode Enable PIM sparse-mode operation
………
В чем же разница?
PIM-DM использует механизм лавинной рассылки и отсечения (flood and prune). Другими словами. Роутер MR отправляет всем все multicast потоки, которые на нем зарегистрированы. Если клиенту не нужен какой-то из этих каналов, то он от него отказывается. Если все клиенты, висящие на роутере, отказались от канала, то роутер пересылает “спасибо, не надо” вышестоящему роутеру.PIM-SM изначально не рассылает зарегистрированные на нем TV-каналы. Рассылка начнется только тогда, когда от клиента придет на нее запрос.
Т.е. в PIM-DM MR отправляет всем, а потом убирает ненужное, а в PIM-SM MR начинает вещание только по запросу.
Если члены группы разбросаны по множеству сегментов сети, что характерно для IPTV, PIM-DM будет использовать большую часть полосы пропускания. А это может привести к снижению производительности. В этом случае лучше использовать PIM-SM.
Между PIM-DM и PIM-SM существуют еще отличия.
PIM-DM строит дерево отдельно для каждого источника определенной multicast группы, т.е. multicast маршрут будет характеризоваться адресом источника и адресом группы. В multicast таблице маршрутизации будут записи вида (S,G), где S - source, G - group.
У PIM-SM есть некоторая особенность. Этому режиму необходима точка рандеву (RP - rendezvous point ) на которой будут регистрироваться источники multicast потоков и создавать маршрут от источника S (себя) до группы G: (S,G).
Таким образом, трафик идет с источника до RP по маршруту (S,G), а далее до клиентов уже по общему для источников определенной группы дереву, которое характеризуется маршрутом (*,G) - "*" символизирует «любой источник». Т.е. источники зарегистрировались на RP, и далее клиенты уже получают поток с RP и для них не имеет значения, кто был первоначальным источником. Корнем этого общего дерева будет RP.
Точкой рандеву является один из multicast роутеров, но все остальные роутеры должны знать “кто здесь точка RP”, и иметь возможность до нее достучаться.
Пример статического определения RP (MR1). Объявим всем multicast роутерам, что точкой рандеву является 10.0.0.1 (MR1):
Все остальные роутеры должны знать маршрут до RP:
ip route 10.0.0.0 255.255.255.0 10.10.10.1
Существуют так же и другие способы определения RP, это auto-RP и bootstarp router, но это уже тема для отдельной статьи (если кому-нибудь будет интересно – пожалуйста )?
Посмотрим, что будет происходить после настройки роутеров.
Мы по-прежнему рассматриваем схему с роутерами MR1 (RP) и MR2. Как только включаем линк между роутерами MR1 и MR2, то должны увидеть в логах сообщения Для MR1:
%PIM-5-NBRCHG: neighbor 10.10.10.2 UP on interface Ethernet3
Для MR2:
%PIM-5-NBRCHG: neighbor 10.10.10.1 UP on interface Ethernet0
Это говорит о том, что роутеры установили отношение соседства по протоколу PIM друг с другом. Проверить это также можно с помощью команды:
MR1#sh ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority, S - State Refresh Capable
| Neighbor Address | Interface | Uptime/Expires | Ver | DR Prio/Mode |
| 10.10.10.2 | Ethernet3 | 00:03:05/00:01:37 | v2 | 1 / DR S |
Не забываем про TTL.
В качестве тестового сервера мне было удобно использовать плеер VLC. Однако, как позже обнаружилось, даже если выставить через GUI достаточный TTL, он все равно (надеюсь только в использованной мной версией) упорно отправлял multicast пакеты с TTL=1. Запускать упрямого пришлось с опцией «vlc.exe –ttl 3» т.к. у нас на пути будет два роутера, каждый из которых уменьшает TTL пакета на единицу.Как же все таки обнаружить проблему с TTL? Один из способов. Пусть сервер вещает канал 224.12.0.3 с TTL=2, тогда на роутере MR1 пакеты проходят нормально, а за роутером MR2 клиенты уже не смогут смотреть свой мультик.
Обнаруживается это с помощью команды «sh ip traffic» на MR2. Смотрим на поле “bad hop count” – это число пакетов, которые “умерли”, как им и отмеряно, по TTL=0.
MR2#sh ip traffic
IP statistics:
Rcvd: 36788 total, 433 local destination
0 format errors, 0 checksum errors, 2363 bad hop count
……………………………………
Если этот счетчик быстро увеличивается, значит - проблема в TTL.
Show ip mroute
После включения вещания трех каналов на сервере в таблице multicast маршрутизации наблюдаем следующее:MR1# sh ip mroute
(*, 224.12.0.1), 00:03:51/stopped, RP 10.0.0.1, flags: SP
(10.0.0.2, 224.12.0.1), 00:03:52/00:02:50, flags: PT
Outgoing interface list: Null
(*, 224.12.0.2), 00:00:45/stopped, RP 10.0.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(10.0.0.2, 224.12.0.2), 00:00:45/00:02:50, flags: PT
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list: Null
(*, 224.12.0.3), 00:00:09/stopped, RP 10.0.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(10.0.0.2, 224.12.0.3), 00:00:09/00:02:59, flags: PT
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list: Null
Видим, что появились маршруты вида (S,G), например (10.0.0.2, 224.12.0.3), т.е. зарегистрировался источник 10.0.0.2, который вещает для группы 224.12.0.3. А так же маршруты с RP до клиента: (*,G), например (*, 224.12.0.3) – которые они будут использовать, так называемое общее для всех дерево.
Как только на интерфейс MR1 (RP) приходит запрос на получение канала 1, в multicast таблице маршрутизации происходят следующие изменения:
MR1#sh ip mroute
…………………
(*, 224.12.0.1), 00:33:16/00:02:54, RP 10.0.0.1, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
(10.0.0.2, 224.12.0.1), 00:33:17/00:03:25, flags: T
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3, Forward/Sparse, 00:02:37/00:02:53
Стало видно, что приходят запросы на эту группу с порта Ethernet3.
RPF проверка
Возможна ситуация, когда роутер получает multicast поток на двух интерфейсах. Кого из этих двух интерфейсов роутер будет считать источником?Для этого он выполняет проверку RPF (Reverse Path Forwarding) - проверяет по обычной unicast таблице маршрутизации маршрут до источника и выбирает тот интерфейс, через который идет маршрут до этого источника. Эта проверка необходима для того чтобы избежать образования петель.
Protocol Independent Multicasts (PIM) /Мультикастинг не зависящий от протокола/ - семейство многоадресных протоколов маршрутизации для сетей, созданный для решения проблем групповой маршрутизации. PIM называется протоколо-независимым, потому что базируется на традиционных маршрутных протоколах (например Border Gateway Protocol), вместо того, чтобы создавать собственную сетевую топологию .
Режимы работы протокола
Уплотнённый режим (Dense Mode)
Protocol Independent Multicast-Dense Mode (PIM-DM) используется для компактных групп, обычно с высокой плотностью получателей. Он косвенно строит деревья кратчайшего пути, наводняя всю сеть мультикастингом, а затем на обратном пути обрезает ветви дерева, где не имеется получателей. Этим PIM-DM реализует метод RPF (Reverse Path Forwarding) с усечением (Prune). Пробные датаграммы рассылаются каждые 3 минуты, что является одним из недостатков данного протокола .
Часто протокол PIM-DM используется совместно с протоколом DVMRP (Distance Vector Multicast Routing Protocol).
Описание протокола PIM-DM находится в RFC 3973 .
Разреженный режим (Sparse Mode)
Protocol Independent Multicast-Sparse Mode (PIM-SM) строит однонаправленные общие деревья с корнем в точке рандеву (Rendezvous Point - RP) для каждой мультикастинг-группы. В качестве RP может быть использован любой маршрутизатор, который поддерживает протокол PIM. Дополнительно PIM-SM создает деревья кратчайшего пути для каждого отправителя.
PIM-SM используется для сетей с произвольным рассредоточением пользователей с ограниченной пропускной способностью сетевых каналов .
Описание протокола PIM-SM находится в RFC 4601 .
Мультикаст с заданным источником (Source Specific Multicast)
Protocol Independent Multicast-Source Specific Multicast (PIM-SSM) развивает концепцию выделения мультикаста не только групповым адресом, но и адресом источника трафика для группы. Является производным от PIM-SM
Описание протокола PIM-SSM находится в RFC 4607 .
Напишите отзыв о статье "Protocol Independent Multicast"
Примечания
Ссылки
- (англ.) (PDF)
|
||||||||||||||||||||||||||||||||||
Отрывок, характеризующий Protocol Independent Multicast
Кутузов отступил к Вене, уничтожая за собой мосты на реках Инне (в Браунау) и Трауне (в Линце). 23 го октября.русские войска переходили реку Энс. Русские обозы, артиллерия и колонны войск в середине дня тянулись через город Энс, по сю и по ту сторону моста.День был теплый, осенний и дождливый. Пространная перспектива, раскрывавшаяся с возвышения, где стояли русские батареи, защищавшие мост, то вдруг затягивалась кисейным занавесом косого дождя, то вдруг расширялась, и при свете солнца далеко и ясно становились видны предметы, точно покрытые лаком. Виднелся городок под ногами с своими белыми домами и красными крышами, собором и мостом, по обеим сторонам которого, толпясь, лилися массы русских войск. Виднелись на повороте Дуная суда, и остров, и замок с парком, окруженный водами впадения Энса в Дунай, виднелся левый скалистый и покрытый сосновым лесом берег Дуная с таинственною далью зеленых вершин и голубеющими ущельями. Виднелись башни монастыря, выдававшегося из за соснового, казавшегося нетронутым, дикого леса; далеко впереди на горе, по ту сторону Энса, виднелись разъезды неприятеля.
Между орудиями, на высоте, стояли спереди начальник ариергарда генерал с свитским офицером, рассматривая в трубу местность. Несколько позади сидел на хоботе орудия Несвицкий, посланный от главнокомандующего к ариергарду.
Казак, сопутствовавший Несвицкому, подал сумочку и фляжку, и Несвицкий угощал офицеров пирожками и настоящим доппелькюмелем. Офицеры радостно окружали его, кто на коленах, кто сидя по турецки на мокрой траве.
– Да, не дурак был этот австрийский князь, что тут замок выстроил. Славное место. Что же вы не едите, господа? – говорил Несвицкий.
– Покорно благодарю, князь, – отвечал один из офицеров, с удовольствием разговаривая с таким важным штабным чиновником. – Прекрасное место. Мы мимо самого парка проходили, двух оленей видели, и дом какой чудесный!
– Посмотрите, князь, – сказал другой, которому очень хотелось взять еще пирожок, но совестно было, и который поэтому притворялся, что он оглядывает местность, – посмотрите ка, уж забрались туда наши пехотные. Вон там, на лужку, за деревней, трое тащут что то. .Они проберут этот дворец, – сказал он с видимым одобрением.
Протокол PIM (Protocol Independent Multicast - независимая от протокола групповая рассылка) предлагает два разных сценария групповой рассылки. Так называемый плотный режим работы протокола рассчитан на ситуацию, когда члены группы рассылки располагаются плотно, то есть большая часть маршрутизаторов некоторой области задействована в групповой рассылке дейтаграмм.
Разреженный режим работы протокола предназначен для случая, когда маршрутизаторов, хосты которых являются членами группы, относительно немного и эти маршрутизаторы разбросаны далеко друг от друга.
Разработчики протокола PIM отметили несколько последствий применения каждого из режимов работы протокола. Поскольку в плотном режиме в групповую рассылку вовлекается большая часть маршрутизаторов, разумно положить, что это должны делать все маршрутизаторы. Для такой ситуации хорошо подходит применяемый в протоколе RPF метод лавинной маршрутизации, когда групповые дейтаграммы пересылаются всем групповым маршрутизаторам (кроме тех, кто явным образом отсечет себя от дерева). В разреженном режиме, напротив, маршрутизаторов, которые должны участвовать в групповой рассылке, немного, и они удалены друг от друга. В этом случае представляется значительно менее привлекательным применяемый в протоколе RPF метод, постоянно заставляющий маршрутизатор посылать отсекающие сообщения, чтобы избежать получения ненужного ему группового трафика. В разреженном режиме протокол исходит из предположения, что маршрутизатор по умолчанию не участвует в групповой рассылке. То есть маршрутизатор не должен выполнять никаких действий, если только не хочет присоединиться к группе рассылки. Такие рассуждения предполагают подход с выбором центрального узла, которому маршрутизаторы явным образом посылают сообщения с запросом о присоединении к той или иной группе рассылки. Остальные маршрутизаторы никак не участвуют в групповой рассылке. Таким образом, разреженный режим работы протокола может рассматриваться как управляемый получателем (ничего не случится до тех пор, пока получатель явно не заявит о желании вступить в группу), а плотный режим работы протокола - как управляемый отправителем (отправитель рассылает дейтаграммы всем, если только маршрутизаторы явно не заявят о своем нежелании их получать).
В плотном режиме работы протокол PIM реализует метод лавинной маршрутизации по обратным маршрутам с отсечениями, то есть, по сути, напоминает протокол DVMRP. Вспомним, что протокол PIM не зависит от нижележащего протокола выборочной (одноадресной) рассылки. Другими словами, протокол PIM может взаимодействовать с любым протоколом одноадресной маршрутизации. Поскольку протокол PIM не предъявляет никаких требований к нижележащему протоколу одноадресной маршрутизации, используемый в нем алгоритм продвижения данных по обратному маршруту несколько проще, чем в протоколе DVMRP, но он также и менее эффективный.
В разреженном режиме работы протокола PIM используется метод центрального узла (RFC 2189, RFC 2201), аналогичный применявшемуся в более раннем протоколе групповой маршрутизации СВТ (Core-Based Tree - дерево с вершиной в ядре). В протоколе PIM маршрутизаторы посылают центральному маршрутизатору, называемому точкой встречи, сообщение JOIN (присоединиться), чтобы присоединиться к дереву. Как и в протоколе СВТ, промежуточные маршрутизаторы переходят в состояние групповой рассылки и переправляют сообщение JOIN точке встречи. В отличие от протокола СВТ, в протоколе PIM в ответ на сообщение JOIN не посылается подтверждение. Сообщения JOIN периодически отправляются «вверх по течению» для обновления состояния дерева маршрутов протокола PIM. Еще одна особенность протокола PIM заключается в способности переключаться с общего для группы дерева на дерево конкретного отправителя после присоединения к точке встречи. Это может оказаться полезным, так как при использовании нескольких деревьев, построенных для конкретных отправителей, концентрация трафика уменьшается.
В разреженном режиме работы протокола PIM маршрутизатор, получивший дейтаграмму от одного из присоединенных к нему хостов, пересылает ее точке встречи. Затем точка встречи рассылает эту дейтаграмму по общему для группы дереву, используя групповую маршрутизацию. Если к дереву не присоединился ни один из маршрутизаторов (то есть у данного источника групповой рассылки нет получателей), отправитель уведомляется точкой встречи о том, что он должен прекратить посылать ей дейтаграммы.
Протокол PIM реализован на многих маршрутизаторах, а также развернут в сети UUNet как часть проекта потоковой доставки мультимедиа. Другим реализованным протоколом групповой маршрутизации является протокол MOSPF (Multicast OSPF - протокол OSPF для групповой рассылки). Протокол MOSPF (RFC 1584) работает в автономных системах, использующих протокол OSPF для выборочной рассылки (см. раздел «Маршрутизация в Интернете»), и представляет собой расширение протокола OSPF. В этом протоколе маршрутизаторы добавляют к распространяемым путем широковещательной рассылки уведомлениям о состоянии линий информацию о членстве своих хостов в группах.
Главный писатель по вопросам технологий
Вам кто-то послал по электронной почте файл PIM, и вы не знаете, как его открыть? Может быть, вы нашли файл PIM на вашем компьютере и вас заинтересовало, что это за файл? Windows может сказать вам, что вы не можете открыть его, или, в худшем случае, вы можете столкнуться с соответствующим сообщением об ошибке, связанным с файлом PIM.
До того, как вы сможете открыть файл PIM, вам необходимо выяснить, к какому виду файла относится расширения файла PIM.
Tip: Incorrect PIM file association errors can be a symptom of other underlying issues within your Windows operating system. These invalid entries can also produce associated symptoms such as slow Windows startups, computer freezes, and other PC performance issues. Therefore, it highly recommended that you scan your Windows registry for invalid file associations and other issues related to a fragmented registry.
Ответ:
Файлы PIM имеют Сжатые файлы, который преимущественно ассоциирован с Personal Information Manager File.
Файлы PIM также ассоциированы с PixMaker Project File, Ultimate Draw Pascal Text Mode Image, PIMPLE Compressed File (Ilia Muraviev) и FileViewPro.
Иные типы файлов также могут использовать расширение файла PIM. Если вам известны любые другие форматы файлов, использующие расширение файла PIM, пожалуйста, свяжитесь с нами , чтобы мы смогли соответствующим образом обновить нашу информацию.
Как открыть ваш файл PIM:
Самый быстрый и легкий способ открыть свой файл PIM - это два раза щелкнуть по нему мышью. В данном случае система Windows сама выберет необходимую программу для открытия вашего файла PIM.
В случае, если ваш файл PIM не открывается, весьма вероятно, что на вашем ПК не установлена необходимая прикладная программа для просмотра или редактирования файлов с расширениями PIM.
Если ваш ПК открывает файл PIM, но в неверной программе, вам потребуется изменить настройки ассоциации файлов в вашем реестре Windows. Другими словами, Windows ассоциирует расширения файлов PIM с неверной программой.
Установить необязательные продукты - FileViewPro (Solvusoft) | | | |
PIM Инструмент анализа файлов™
Вы не уверены, какой тип у файла PIM? Хотите получить точную информацию о файле, его создателе и как его можно открыть?
Теперь можно мгновенно получить всю необходимую информацию о файле PIM!
Революционный PIM Инструмент анализа файлов™ сканирует, анализирует и сообщает подробную информацию о файле PIM. Наш алгоритм (ожидается выдача патента) быстро проанализирует файл и через несколько секунд предоставит подробную информацию в наглядном и легко читаемом формате.†
Уже через несколько секунд вы точно узнаете тип вашего файла PIM, приложение, сопоставленное с файлом, имя создавшего файл пользователя, статус защиты файла и другую полезную информацию.
Чтобы начать бесплатный анализ файла, просто перетащите ваш файл PIM внутрь пунктирной линии ниже или нажмите «Просмотреть мой компьютер» и выберите файл. Отчет об анализе файла PIM будет показан внизу, прямо в окне браузера.
Перетащите файл PIM сюда для начала анализа
Просмотреть мой компьютер »
Пожалуйста, также проверьте мой файл на вирусы
Ваш файл анализируется... пожалуйста подождите.
Протокол PIM-SM является одной из двух версий протокола PIM (Protocol Independent Multicast - независимое от протокола групповое вещание), описываемого в спецификации RFC 2362:
- версии плотного режима PIM-DM (Protocol Independent Multicast - Dense Mode);
- версии разряженного режима PIM-SM (Protocol Independent Multicast - Sparse Mode).
Эти версии существенно отличаются друг от друга способом построения и использования покрывающего дерева, но у них есть и одно общее свойство. Оно вынесено в название каждого из этих протоколов и означает независимость данного протокола от конкретных протоколов маршрутизации. Если DVMPR использует в своей работе механизмы RIP, а протокол MOSPF является расширением протокола OSPF, то протокол PIM может работать совместно с любым протоколом маршрутизации. Протокол PIM задействует готовые таблицы маршрутизации для продвижения групповых пакетов и служебных сообщений и для него не имеет значения, с помощью какого протокола маршрутизаторы строят эти таблицы.
Протокол PIM-DM похож на протокол DVMPR. Он, также являясь протоколом плотного режима, строит для доставки групповых пакетов деревья с вершиной в источнике, используя для этого проверки продвижения по реверсивному пути и технику широковещания и усечения. Основное отличие состоит в том, что PIM-DM применяет готовую таблицу маршрутизации, а не строит ее сам, как это делает DVMPR.
Главной особенностью протокола PIM-SM является то, что он рассчитан на работу в разряженном режиме, то есть он посылает групповые пакеты только по явному запросу получателя. Для доставки данных каждой конкретной группе получателей протокол PIM-SM строит одно разделяемое дерево, общее для всех источников этой группы (рис. 1).
Рис. 1. Разделяемое дерево протокола PIM-SM
Вершина разделяемого дерева не может располагаться в источнике, так как источников может быть несколько. В качестве вершины разделяемого дерева используется специально выделенный для этой цели маршрутизатор, выполняющий функции точки встречи (RP). Все маршрутизаторы в пределах домена PIM-SM должны обладать согласованной информацией о расположении точки встречи. Различные группы могут иметь как одну и ту же, так и разные точки встречи.
Самым распространенным и возможно самым простым способом конфигурирования локальных (в пределах одного домена PIM-SM) точек встречи является назначение их статически среди множества маршрутизаторов данного домена. Это" приводит к весьма определенной конфигурации и позволяет в дальнейшем легче находить ошибки, чем при других подходах.
Для получателей каждой конкретной группы и источников, вещающих на эту группу, маршрутизатор точки встречи является посредником, который связывает их между собой.
Процесс доставки протоколом PIM-SM группового тр&фика от источника к получателям, принадлежащим некоторой группе, может быть представлен трехэтапным:
1. Построение разделяемого дерева с вершиной в точке встречи, которое описывает пути доставки групповых пакетов между точкой встречи и членами данной группы. Это дерево называют также деревом точки встречи (Rendezvous Point Tree, RPT).
2. Построение дерева кратчайшего пути (Shortest Path Tree, SPT), которое будет доставлять пакеты между источником данной группы и точкой встречи.
3. Построение набора SPT-деревьев, которые ради повышения эффективности будут использованы для доставки пакетов непосредственно между источником и каждым из получателей группы.
ПРИМЕЧАНИЕ
Порядок следования этапов не фиксирован. Например, источники группового вещания могут начать передачу до того, как появятся слушатели, заинтересованные в этом трафике, или дерево кратчайшего пути между источником и его слушателями может уже быть построенным, когда будет сделан новый запрос на присоединение к группе.
Рассмотрим работу протокола PIM-SM на простом примере. На рис. 2 показана одно-доменная сеть, в которой протокол PIM-SM устанавливает связь между одним получателем A и одним источником 5. Будем считать, что работа сети соответствует модели ASM (групповое вещание из любого источника), на всех узлах сети развернут протокол IGMP и все маршрутизаторы поддерживают протокол PIM-SM. Будем считать также, что точка встречи сконфигурирована статически: и источники, и получатели знают индивидуальный адрес точки встречи, роль которой в этой сети играет маршрутизатор D. Для оповещения узлов сети об адресе точке встречи имеется стандартный протокол автоматического оповещения, называемый протоколом загрузки.
Рис. 2. Этап 1 - построение разделяемого дерева
Этап 1 - построение разделяемого RPT-дерева от получателя к точке встречи. Когда разделяемое дерево уже построено, трафик группового вещания передается от точки встречи в направлении заинтересованных получателей. Однако процесс построения разделяемого дерева движется в обратном направлении - от получателей к точке встречи на основе пошагового (hop-by-hop) подхода.
Итак, пусть хост A решает присоединиться к группе G, по этой причине он посылает IGMP-сообщениё отчета о членстве, содержащее адрес группы G, в локальную сеть, к которой он подключен. Это сообщение будет получено маршрутизатором С, через который данная локальная сеть подключена к другим сетям.
Маршрутизатор С, получив от хоста A это IGMP-сообщение, посылает сообщение протокола PIM-SM о присоединении (join) на индивидуальный адрес маршрутизатора Д выполняющего функции точки встречи. Это сообщение продвигается обычным образом на основе таблиц маршрутизации, построенных любыми протоколами маршрутизации. На всех промежуточных маршрутизаторах, расположенных вдоль пути от хоста-получателя к точке встречи, фиксируется состояние продвижения для данной группы. Каждый маршрутизатор добавляет интерфейс, принявший сообщение протокола PIM-SM о присоединении, к своему списку интерфейсов, через которые заинтересованным получателям может быть доставлен трафик группы, упомянутой в сообщении. В результате для данной группы формируется разделяемое дерево, и его корнем является точка встречи.
В нашем примере на данном этапе нет активных источников, поэтому данные группового вещания еще не поступают к точке встречи (см. рис. 2).
Этап 2 - построение SPT-дерева от источника к точке встречи. Когда источник S становится активным и начинает посылать пакеты с групповым адресом в свою локальную сеть, маршрутизатор F, к которому эта сеть непосредственно подключена, замечает, что источник 5 стал источником группового вещания. Маршрутизатор F посылает Р1М-сообщение о регистрации (register) на индивидуальный адрес точки встречи (маршрутизатора D). При этом сообщение о регистрации инкапсулируется в пакет группового вещания от источника 5 (рис. 3).
Когда маршрутизатор D (точка встречи) получает сообщение о регистрации, он реагирует на это двумя действиями. Во-первых, он продвигает инкапсулированные данные группового вещания по разделяемому дереву (RPT) от точки встречи до получателя, во-вторых, посылает PIM-сообщение о присоединении назад по направлению к источнику с тем, чтобы создать дерево кратчайшего пути (SPT). Это сообщение передается от одного маршрутизатора к другому, при этом информация о присоединении к группе фиксируется на соответствующих интерфейсах.
Как только дерево кратчайшего пути от источника к точке встречи построено, маршрутизатор D начинает получать по две копии каждого пакета группового вещания. Одна копия приходит от источника 5 по вновь созданному кратчайшему пути, другая - от маршрутизатора F, который, продолжая реагировать на выявленную активность источника 5, снова посылает сообщение о регистрации, в котором в инкапсулированном виде содержится вторая копия группового пакета. Когда маршрутизатор точки встречи распознает эту ситуацию, он посылает маршрутизатору F сообщение с требованием прекратить регистрацию (register stop). Получив это сообщение для данной пары источник-группа, маршрутизатор F прекращает генерировать сообщения о регистрации и инкапсулировать в них групповые пакеты источника. Вместо этого он начинает посылать их в исходном виде с групповым адресом, так как к этому моменту источник уже присоединился к дереву группы, и это присоединение зафиксировано на нужных маршрутизаторах.
Рис. 3. Этап 2 - регистрация источника с построением дерева кратчайшего пути
Таким образом, поток данных группового вещания от источника S начинает передаваться по SPT-дереву до точки встречи, а затем далее от точки встречи по разделяемому дереву ко всем заинтересованным получателям (в том числе на маршрутизатор С, к которому подключен хост A).
Этап 3 - построение дерева кратчайшего пути от источника к получателю. Когда маршрутизатор С получает первый групповой пакет, он узнает из его заголовка IP-адрес отправителя, каковым в данном случае является источник 5. На основании этого адреса маршрутизатор С пытается построить дерево кратчайшего пути непосредственно от источника до самого себя. В нашем примере кратчайший путь - это путь через маршрутизатор В. Маршрутизатор С посылает сообщение о присоединении маршрутизатору В, который затем, в свою очередь, посылает сообщение о присоединении маршрутизатору F. При этом каждый из них фиксирует интерфейс, на который он будет направлять пакеты да данной группы.
Теперь, когда дерево кратчайшего пути для пары (источник 5, получатель A) построено, маршрутизаторы F, В и С«ачинают продвигать пакеты группового вещания вдоль него. Когда пакеты начинают прибывать на маршрутизатор С, он обнаруживает по две копии каждого пакета - одна приходит по новому кратчайшему пути через маршрутизатор В, другая по разделяемому дереву от маршрутизатора D. Чтобы прекратить дублирование, маршрутизатор С посылает PIM-сообщение об отсечении точки встречи (маршрутизатору D), который отсекает источник от разделяемого RPT-дерева (рис. 4).
Рис. 4. Этап 3 - построение дерева кратчайшего пути от источника к получателю
С этого момента маршрутизатор С получает только по одной копии каждого пакета от и точника 5 через свое отдельное дерево кратчайшего пути и передает его в локальную сет в которой находится получатель.
Для упрощения мы описали случай, когда в сети имеется только одна точка встречи и с здается только одно разделяемое дерево. Однако технология допускает наличие в сет нескольких точек встречи. Решение о том, сколько в сети должно быть точек встречи и ю их расположить, составляет предмет планирования сети и протоколом PIM не опред ляется.
