Относительно недавно мне посчастливилось познакомить и даже поконфигурять 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
!
interface Ethernet 0
description Multicast Source
ip address 10.0.0.1 255.255.255.0
ip pim sparse-mode
!
interface Ethernet 1
description Network A
ip address 10.1.0.1 255.255.255.0
ip pim sparse-mode
!
interface Ethernet 2
description Network B
ip address 10.2.0.1 255.255.255.0
ip pim sparse-mode
!
interface Ethernet 3
description Link to MR2
ip address 10.10.10.1 255.255.255.0
ip pim sparse-mode
!

!
ip access-list standard IPTV
permit 224.11.0.0 0.0.0.3

 MR2#sh run

Ip multicast-routing
!
interface Ethernet 0
description Link to MR1
ip address 10.10.10.2 255.255.255.0
ip pim sparse-mode
!
interface Ethernet 1
description Network C
ip address 10.3.0.1 255.255.255.0
ip pim sparse-mode
!
ip pim rp-address 10.0.0.2 IPTV override
!
ip access-list standard IPTV
permit 224.11.0.0 0.0.0.3
!

Команда "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 таблице маршрутизации маршрут до источника и выбирает тот интерфейс, через который идет маршрут до этого источника. Эта проверка необходима для того чтобы избежать образования петель.

Distance vector multicast routing protocol

  • Первый, нах! протокол маршрутизации для мультикаст.
  • Dense-mode implementation
  • Distance-vector
  • Для RPF не использует Unicast таблицу.
  • Можно использовать туннелирование между островками Unicast.
  • Для передачи routing info использует отдельный протокол.

PIM

Protocol Independent Multicast

  • Использует unicast routing table для RPF check. Использует любой IGP, BGP или оба.
  • ASM: Sparse / Dense / Sparse-Dense/ Bidirectional modes.
  • Version 1 (encapsulate messages into IGMP, sent to 224.0.0.2)/ 2 (encapsulate messages into protocol 103, sent to 224.0.0.13). Могут использоваться совместно даже на одном интерфейсе.
  • Отдельно есть SSM.

Dense mode

Пригоден для использования с большим количеством получателей в сети.

Messges

  • Hello : для нахождения и поддержания соседства.
  • Join/prune : имеют одинаковый формат сообщения. В dense mode используются prune сообщения - сообщить upstream роутеру об отказе от группы.
  • Graft/graft-ack : graft используется для запроса трафика у upstream роутера, которому уже пришел prune запрос.
  • Assert : для выбора gesignated forwarder (DF) для сегмента, где > 1 роутера.

Neighborship

Соседство устанавливается и поддерживается с помощью hello сообщений. В зависимости от версии шлем на нужный адрес.

  • Version 1 (encapsulate messages into IGMP, sent to 224.0.0.2)
  • Version 2 (encapsulate messages into protocol 103, sent to 224.0.0.13).

hello сообщения могут содержать hold-time - как долго сосед будет в состоянии up без отправки hello. В Junos если holdtimer = 0, то роутер будет использовать локальный таймер. По умолчанию = 105 сек.

Designated router election

Dense : целесообразно использовать только в том случае, если используем IGMPv1, т.к. он не имеет встречного механизма выбора query роутера.

Flooding

Для доставки multicast использует SPT.

  • Все роутеры получат одну копию исходного потока.
  • Каждый роутер проводит RPF check. Пакеты, которые не прошли RPF check - отбрасываются.
  • Пакеты прошедшие RPF check копируются и флудятся во все порты (OIL), за исключением порта, откуда трафик пришел (IIF).
  • (S,G) создается на каждом роутере (даже на котором вообще нет получителей).
  • Роутеры, не имеющие напрямую включенных получателей должны периодически посылать prune, чтобы быть исключенными из SPT дерева.

Prunning unwanted traffic

Prune отправляется в случае:

  1. Если нет получателей, подключенных к роутеру.
  2. Если на роутер пришел prune от downstream роутера.

Информация (S,G) хранится на роутере 3 минуты. Если появляется новый получатель или отваливается старый, роутер не мгновенно среагирует на изменения, не будет ждать таймаут 3 минуты, а сразу обновит инфо.

Prune нужно отправлять периодически, так как есть определенный таймаут, после которого возобновляется вещание multicast трафика во все порты.

Source-based tree

В итоге после отправки всех prune, на сети вырисовывается shortest-path tree, по которому и ходит в дальнейшем трафик.

Prunning on milti-access network

При отправке роутером (R2) prune к upstrem роутеру, может пострадать другой роутер из этого же multi-access сегмента (R1).

У роутера из этого же сегмента (R1) есть 2 сек, чтобы отправить join к upstream роутеру и тем самым убить prune от R2.

При этом на R2 будет литься трафик, но сам роутер не будет его передавать другим роутрам, так как нет получателей.

Grafting back

SPT уже установлено, но в сети появился новый получатель.

Роутер, получивший IGMP report от получателя, генерирует Graft-message и шлет его по SPT к источнику на upstream-router. Истоник известен, т.к. на всех роутерах хранятся (S,G) записи.

Роутер, ближайший к источнику в ответ на graft сообщение генерирует graft-ack сообщение и посылает его к конечному свитчу. На этом же роутере сохранена запись (S,G), но без OIL interfaces. После получения report, список OIL интерфейсов обновляется, в сторону источника отправляется Join сообщение.

После этого получатель видит свой заветный трафик, не ожидая никаких таймаутов.

Assert mechanism in Multiaccess networks

В multi-access сегменте несколько роутеров могут начать посылать трафик вниз к получателям. Чтобы этого избежать, проводятся выборы DF.

Assert сообщение содержит информацию: source, group, metric preference, metric. Наименьшее значение metric pref / metric - выигрывает. если значения равны, то выигрывает наибольший ip роутера.

При этом downstream роутер как-то хитро переподписывается на группу, что получает в итоге трафик от одного роутера.

Configuration

По дефлту при добавлении интерфейса в protocols pim, включается version 2, sparse mode.

Set protocols pim assert-timeout 180 set protocols pim interface ge-0/0/0.0 mode dense priority 1 hello-interval 30 show pim interfaces show pim neighbors show pim neighbors detail show pim join extensive show pim source detail show multicast rpf show multicast route extensive show route table inet.1 show route table inet.1 extensive show multicast next-hops show pim statistics show multicast usage

можно использовать traceoptions

Mtrace from-source group 224.7.7.7 ttl 20 source || запускается от роутера, ближнего к получателю

Пинг source:

Ping 224.7.7.7 ttl 10 interface ge-0/0/0.900 bypass-routing || запускается от роутера, ближнего к получателю.

Пинг получателя: тоже как-то можно продиагностировать, но придется заморочиться.

Sparse mode

Shared tree (rendezvous point tree) = (*,G)

Source-based tree (shortest path tree (SPT)) = (S,G)

Более приспособлена к реальности: поток получают только роутеры, заинтересованные в потоке. Работа в 2х режимах: ASM/SSM. При работе ASM, требуется RP.

  • DR (designated router) - занимается только отправкой register-message, join message в multi-access сети.
  • DF (designated forwarder) - занимается передачей трафика в multi-access netw.

Messages

  • Hello : поиск соседей, поддержание соседства, выбор DR в multi-access netw. (отправляется на dst-address 224.0.0.13, src-adderss - p2p интерфейса)
  • Join/Prune : подписка/отписка. (отправляется на dst-address 224.0.0.13, src-address - p2p интерфейса)
  • Assert messages : выборы designated router (DR).
  • Register / register-stop : сообщения между source и RP.
  • Bootstrap and candidate-RP : для работы bootstrap.

Designated router

Sparse : выбор роутера проводится со стороны как получателей и так и источников.

  • receiver DR: отправляет PIM join и PIM prune сообщения от получателей к RP.
  • source DR: отправляет PIM register сообщения от источника к RP.

Выбор основан на DR priority field в hello сообщениях. По умолчанию = 1. Можно задавать вручную. Больший приоритет - выигрышней. Если приоритеты равны, то выигрывает с наибольшим ip.

Set protocols pim interfaces xe-0/0/0.50 priority 50

Можно активировать выбор DR и на p2p линке.

Set protocols pim dr-election-on-p2p

Join operations, Receiver -> RP

От подписчика на роутер поступает (*,G) report. Роутер не знает какой именно источник будет использоваться, поэтому он направляет пакет к upstream роутеру не в сторону источника, а в сторону RP.

Строится rendevous-point tree (RPT) или shared tree .

Source DR -> RP

RP получает register сообщение, деинкапсулирует его и начинает слать чистый мультикаст в интерфейс к которого пришел report на подписку к этой группе.

Если у RP есть подписчики на нужную группу, то RP шлет join (S,G) к источнику. После этого строится source-based tree. И роутер, подключенный к источнику сможет слать чистый мультикаст в направлении RP. В короткий промежуток времени RP получит 2 копии одного и того же трафика, чтобы отписаться от инкапсулированного мультикаста, RP шлет register-stop к source DR.

Если на RP приходят register от источника, но у него нет подписчиков на эту группу, то RP отправит register-stop в сторону источника.

Если между RP и источником есть роутер, то промежуточный роутер примет register-stop, начнет отбрасывать мультикаст трафик, но источник как слал его так и будет слать дальше.

Если появится новый источник, то заново повторится весь сценарий: register -> RP, (S,G) -> source, multicast -> RP, register-stop -> source.

Также на RP будет сохранена запись (S,G), т.е. если появятся получатели, то RP пошлет запрос сразу к источнику.

Также роутер между источником и RP каждые 3 минуты будет отправлять register на RP, чтобы RP знало, что источник все еще жив.

Tunnel requeriments

Для RP и source DR требуется туннелирование. (Не требуется только если RP=DR).

Возможности туннелирования зависят от платформы. Иногда требуется даже докупать доп оборудование (платы).

На MX сериях туннелирование включается так:

Set chassis fpc X pic X tunnel-services bandwidth 1g

Проверка:

Show interfaces terse | match "pe|pd"

SPT switchover

В ситуациях, когда есть роутеры (R6), для которых путь до источника через RP является не оптимальным, происходит перестроение дерева.

На R6 есть получатель. R6 отправляет (*,G) к RP. От RP приходит пакет (S,G). В таком случае R6 узнает об источнике.

Если R6 видит более оптимальный путь до источника, то он шлет (S,G) к источнику по этому пути (до R1 - ближайший к источнику).

Upstream роутер, получив (S,G) также ищет более короткий путь и шлет (S,G) join вверх по топологии.

Когда между R1 и R6 установлено source-based tree, мультикаст трафик может идти напрямую от R1 к R6. Есть небольшой промежуток времени, когда R6 будет получать 2 копии мультикаст.

R6 отправляет prune сообщение uptream роутеру в сторону RP. RP проверит, что больше не получателей конкретной группы и отправит prune (S,G) к source DR.

В итоге трафик польется оптимальным путем.

Но на R6 (ближний к получателю) останется 2 записи о группе:

  • (S,G) - где в качестве upstream state будет указан: Join to source, Prune from RP . И в incoming interface: интерфейс в сторону R1 (ближний к источнику).
  • (*,G) - в качестве upstream state указан: Join to RP . Incoming interface: интерфейс в сторону RP.

(S,G) - более специфичный.

На RP при этом будет храниться информация следующего вида: (S,G) Sate : Group x.x.x.x, Source: y.y.y.y, Upstream State: Prune to Source

RP

В sparse обязательно должна использоваться RP.

  • RP должна быть расположена оптимально, желательно поближе к источникам, чтобы не гонять большие объемы трафика от источников и максимально исключить перестроение на spt.
  • Инкапсуляция и деинкапсуляция трафика от источника делается посредством использования tunnel-services. Tunnel-services не требуется, если DR = RP.
  • Для одной группы - 1 RP.
  • Для надежности, есть 3 механизма нахождения rp: static, auto-RP, bootstrap . Можно использовать все сразу, тогда по предпочтительности: BSR -> auto-RP -> static.
  • Anycast-RP может быть использована с любым из механизмов нахождения RP (можно потом почитать здесь: http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/ip-multicast/whitepaper_c11-508498.html).

Static RP

Прописывается вручную. Минус - никакого резервирования. В случае, когда RP - умерла, требуется ручками поправить конфигурацию.

Override - при использовании нескольких механизмов поиска RP, static - менее приоритетный. Override - сделает его приоритетной остальных.

Set protocols pim rp local address x.x.x.x set protocols pim rp local group-ranges 227.0.0.0/24 - RP будет работать только с этими группами (по дефолту: все IPv4, IPv6). set protocols pim rp local override

Не RP:

Set protocols pim rp static address x.x.x.x

Auto-RP

  • Используется с PIMv1 и v2.
  • Нестандартное проприетарное решение (вроде от Cisco, нет RFC).
  • Позволяет резервировать RP, но не делает балансировку между RP.
  • Использует мультикаст для распространения инфо, связанной с RP - dense-mode.
  • По PIM домену распространяет набор соответствий group-RP.

Компоненты:

  • Candidate-RP (C-RP) : периодически отсылают инфо о себе на 224.0.1.39 (слушает только mapping agent) (announce messages).

Announce message :

C-RP IP | 224.0.1.39 | group 224/4

  • Mapping agent : слушает C-RP, выбирает RP для каждой группы (наибольший ip), анонсирует победителя RP для группы на 224.0.1.40 (Discovery message - слушают все auto-rp роутеры).

Discovery message /mapping message:

Mapping agent IP | 224.0.1.40 | RP 1 - group 224/4

RP выбирается для групп.

Если RP сдохнет, то mapping agent выбирает новую RP. В общем, время падения составляет несколько минут.

Конфигурация

Обязательно на всех роутера включить sparse-dense mode и включить 2 группы, по которым передается служебная инфо. Dense - для передачи служебной информации, Sparse - трафик.

Set protocols pim interface all mode sparse-dense set protocols pim dense-groups 224.0.1.39 set protocols pim dense-groups 224.0.1.40

Set protocols pim rp auto-rp discovery

discovery - только получение mapping (group-RP) сообщений.

Set protocols pim rp local address 10.200.86.3 set protocols pim rp auto-rp announce

announce - без local address : только слушает announce сообщения, с local address : слушает и отправляет announce.

RP + mapping agent:

Set protocols pim rp local address 10.200.86.3 set protocols pim rp auto-rp mapping

mapping - позволяет отправку (и получение) как announce (C-RP), так и mapping (group-RP) сообщений. Если на роутере не будет настроен local address, то роутер сможет отправлять только announce.

Несколько Mapping Agent , настраиваем только на них:

Set protocols pim auto-rp mapping mapping-agent-election

Mapping agent с наименьшим IP (проиграл) перестает слать mapping messages в сеть, при получении mapping message от агента с бОльшим IP.

Set protocols pim auto-rp mapping no-mapping-agent-election

Bootstrap

  • Работает только с PIMv2. Для распространения информации используют сообщения PIMv2.
  • backup RP обеспечивает средство защиты от падения RP и некую балансировку для одних и тех же групп между RP. Но по прежнему для 1 активной группы - используется 1 RP.
  • сообщения между роутерами происходит с source Lo interface роутера. Поэтому Lo обязательно должны быть routable. Можно проверить: show pim bootstrap

Компоненты:

  • Candidate-RP: заявляет о себе BSR через unicast (advertisement message).
  • Bootstrap router: выбирается на основании наивысшего приоритета (далее наивысшего ip), получает оповещения от C-RP, определяет RP/group соответствие - это RP-set, включает RP-set в bootstrap сообщения и распространяет по сети.

BSR - всего лишь роутер, который будет передавать информацию: RP-set: RP <-> группы. То есть в выводе: sh pim rps мы увидим все RP.

Выборы:

  1. Выбор BSR: каждый роутер предполагает, что он BSR. Генерирует BSR-сообщения другим BSR (ip+приоритет+пустой RP-set). Когда роутер получает BSR-сообщение с бОльшим приоритетом (или бОльшим ip), он перестает генерировать сообщения. Выбранный BSR-роутер продолжает генерировать сообщения, остальные лузеры-BSR просто передают эти сообщения своим соседям. Т.о. все роутеры знают об активном BSR. BSR генерирует BSR сообщение, в котором содержится ip BSR, пустой RP-set. DA = 224.0.0.13.
  2. C-RP передают инфо о себе BSR: свой ip, перечисляют group range.
  3. BSR собирает C-RP оповещения, складывает их в RP-set (RP+group range). Отправляет RP-set всем PIM роутерам.
  4. Каждый PIM роутер выбирает для группы действующую RP: делает hash из C-RP ip, group range, mask. Наименьший hash для группы определяет выбранную RP.

Чтобы исключить роутер из выборов (чтобы он перестал отправлять BSR сообщения), можно ему поставить приоритет = 0. Конфигурация

Set protocols pim rp local 10.200.86.3 set protocols pim rp bootstrap priority 200

особого конфига не нужно, просто должен быть включен PIM на интерфейсах.

Нельзя, чтобы одновременно на сети были включены Auto-RP и Bootstrap.

Blair> show pim bootstrap Instance: PIM.master BSR Pri Local address Pri State Timeout 10.200.86.3 200 10.200.86.1 100 Candidate 110 oban> show pim rps Instance: PIM.master Address family INET RP address Type Mode Holdtime Timeout Groups Group prefixes 10.200.86.1 bootstrap sparse 150 145 0 224.0.0.0/24 10.200.86.3 bootstrap sparse 150 None 1 235.0.0.0/8 10.200.86.9 bootstrap sparse 150 145 0 232.1.1.0/24 10.200.86.3 static sparse 150 None 1 235.0.0.0/8

Anycast RP

Может использоваться как с MSDP, так и без него.

  • на lo добавляем еще один адрес . Изначальный адрес lo лучше сделать primary, anycast адрес - оставить как есть.
+ primary; + preferred; address 172.30.5.1/32 { ... } + address 172.30.5.254/32;
  • nni линки и lo добавляем в protocols pim. Указываем новый адрес lo как адрес RP
rp { local { address 172.30.5.254; interface ge-0/0/0.208; interface ge-0/0/2.200; interface ge-0/0/3.204; interface lo0.0;
  • строим MSDP-соседство между PE, которые буду выполнять роль RP. Соседство на lo-primary адресах.
+ msdp { + peer 172.30.5.2 { + local-address 172.30.5.1; *если не хотим использовать MSDP, то можно и без него. Используем все предыдущие шаги и потом: + rp { + local { + family inet { + address 172.30.5.254; + anycast-pim { + rp-set { + address 172.30.5.2; + local-address 172.30.5.1;

Specific config

Shortest-path tree cutover (не переключаться на shotest-path tree)

set protocols pim spt-threshold infinity no-spt set policy-options policy-statement no-spt term 1 from route-filter 235.4.5.6/32 exact set policy-options policy-statement no-spt term 1 from source-address-filter 10.66.66.2/32 exact set policy-options policy-statement no-spt term 1 then accept set policy-options policy-statement no-spt term 2 then reject

Делается для того, чтобы ограничить дополнительный статус (S,G), который создается при переключении на source-based tree.

Или если из-за других причин не выгодно, чтобы последний роутер перестраивался на SPT.

PIM join load balancing

set protocols pim join-load-balance

Если до источника есть несколько равнозначных путей, использоваться будет только 1 (т.к. пройдет RFP-check только 1, альтернативные пути будут простаивать). Имеется ввиду, что будут балансироваться как join к upstream роутеру, так и трафик в сторону downstream.

Используя команду выше, может использоваться несколько интерфейсов к источнику.

BFD

Bidirectional Forwarding Detection работает можно настроить также и для PIM.

set protocols pim interface ge-1/0/0.900 family inet bfd-liveness-detection

Таймеры

set protocols pim join-prune-timeout 230 || by default 210 set protocols pim reset-tracking bit || в multi-access сетях для настройки подавления join от нескольких роутеров. set protocols pim propagation-delay 500 || время, кот определяет как долго ждать выполнения prune на upstream роутере. В теч этого времени роутер ждет любых prune override join message от других роутеров. set protocols pim override-interval 2000 || макс время для задержки отправки join сообщений. Если в multi-access появился prune, то таймер гарантирует, что не все downstream роутеры среагируют одновременно join сообщением.

Troubleshoting

show pim interfaces show pim neighbors extensive || можно посмотреть RX Join groups!! show pim statictics || статистика различных пакетов show multicast usage show multicast route extensive || информация об группах, присутствующих на данном роутере show route table inet.1. || таблица форвардинга show multicast next-hops show pim join extensive || помимо прочего, полезно: "Upstream state: Join to Source, Prune to RP" show pim source detail show multicast rpf x.x.x.x show pim rps || какие rp известны, через какой механизм, какой набор групп приходит show pim rps extensive || помимо того, что выше - видны конкретные группы, статус, time active и много всяких подробностей show pim bootsrap || активный BSR роутер traceoptions || для диагностики не забываем включать show pim neighbors Instance: PIM.master Interface IP V Mode Option Uptime Neighbor addr xe-1/1/0.910 4 2 HPLGT 13w2d5h 212.1.253.189 xe-1/2/0.822 4 2 HPLG 03:08:00 192.168.152.49 B = Bidirectional Capable = bidirectional mode supported G = Generation Identifier = gracefull restart turned on for pim H = Hello Option Holdtime, L = Hello Option LAN Prune Delay, P = Hello Option DR Priority, T = Tracking Bit = Join Suppression supported, если нет T - то у соседа настроен: reset-tracking-bit show him neighbors detail Interface: xe-1/2/0.822 Address: 192.168.152.49, IPv4, PIM v2, sg Join Count: 2 , tsg Join Count: 0 BFD: Disabled Hello Option Holdtime: 105 seconds 102 remaining Hello Option DR Priority: 1 Hello Option Generation ID: 1593016797 Hello Option LAN Prune Delay: delay 1000 ms override 3000 ms Address: 192.168.152.50, IPv4, PIM v2, Mode: Sparse, sg Join Count: 0, tsg Join Count: 0 Hello Option Holdtime: 65535 seconds Hello Option DR Priority: 1 Hello Option Generation ID: 1898464853 Hello Option LAN Prune Delay: delay 500 ms override 2000 ms Join Suppression supported pim { traceoptions { file pim.log size 10m; flag all;

PIM Join и PIM Prune можно посмотреть в pim statistics (как принятые так и отправленные).

> show pim statistics interface xe-1/2/0.822 Instance: PIM.master Family: INET PIM Interface statistics for xe-1/2/0.822 PIM Message type Received Sent Rx errors V2 Hello 389 413 0 V2 Register 0 0 0 V2 Register Stop 0 0 0 V2 Join Prune 0 195 0

В monitor traffic interface не будут отображаться PIM Join, PIM Prune. Если требуется помониторить входящие и исходящие пакеты, то можно только замиррорить трафик.

При включенном traceoptions, join также отчетливо видны (исходящие):

Traceoptions { file pim.log size 10m; flag all; flag join detail; flag prune detail; > show log pim.log | match 235.69.101. Oct 13 13:21:50.354863 group 235.69.101.1 joins 1 prunes 0 Oct 13 13:21:50.354881 group 235.69.101.2 joins 1 prunes 0 Oct 13 13:21:50.354897 group 235.69.101.4 joins 1 prunes 0 Oct 13 13:21:50.354913 group 235.69.101.11 joins 1 prunes 0 Oct 13 13:21:50.354929 group 235.69.101.19 joins 1 prunes 0 Oct 13 13:21:50.354944 group 235.69.101.20 joins 1 prunes 0

Bidirectional mode

То же самое что и Sparse, только в bidirectional PIM роутеры строят shared bidirectional trees и не производят переключение на SPT. За счет этого в процессе работы используются только (*,S).

Считается, что этот режим более масштабируемый для сети.

В отличие от PIM-SM, в данном режиме не требуется PIM Register tunneling.

Протоколы PIM и IGMP

Чтобы доставить мультикаст от источника до получателя существует много протоколов - IGMP, PIM, MSDP, MBGP, MOSPF, DVMRP. В настоящее время из выше перечисленных протоколов используются в основном: PIM и IGMP .

Рисунок 6.8

PIM (Protocol Independent Multicast) строит путь движения мультикастового трафика от источника до получателей через маршрутизаторы. PIM обеспечивает построение графа сети, связывающего все хосты в определенной группе, причем между двумя хостами существует только один путь. Такой граф называют покрывающим деревом. Протокол PIM осуществляет постоянный мониторинг покрывающего дерева, и время от времени отсекает те ветви дерева, которые из-за изменения состояния сети уже не ведут к членам той или иной группы.

Протокол IGMP (Internet Group Management Protocol ) – gротокол группового управления в Интернете, был разработан в 1989 году. IGMP- это сетевой протокол взаимодействия клиентов мультикастового трафика и ближайшего к ним маршрутизатора. С помощью этого протокола маршрутизатор узнаёт о наличии получателей мультикастового трафика и об их отключении. Роль IGMP очень проста: если клиентов нет, то передавать мультикастовый трафик в сегмент не надо. Если появился клиент, он уведомляет маршрутизатор с помощью IGMP о том, что хочет получать трафик.

Источник программ IPTV не нуждается в протоколе IGMP. Любой компьютер, подключенный к Интернету, может стать источником группового вещания, при этом ему не требуется никакого дополнительного программного обеспечения, кроме того, которое включено в состав обычной реализации стека TCP/IP.

Чтобы стать получателем групповых данных, узел должен «выразить» свою заинтересованность маршрутизатору, к которому непосредственно подсоединена его сеть. Для этого хост должен установить взаимодействие с маршрутизатором по протоколу IGMP.

При вещании ТВ программ в режиме multicast видеосервер рассылает только один видеопоток (для каждой из ТВ-программ), независимо от числа абонентов.

На участке соединения видеосервер - шлюз доступа (Ethernet-коммутатор, DSLAM) происходит трансляция всех ТВ-программ (рисунок 6.6). На участке соединения коммутатор - STB транслируется только та программа, которую выбрал абонент для просмотра. Это происходит посредством протокола IGMP.

Рисунок 6.6

В IGMP определено три типа сообщений:

1) Запрос о членстве . С помощью этого сообщения маршрутизатор пытается узнать, в каких группах состоят хосты в локальной сети, присоединенной к какому-либо его интерфейсу. Запрос о членстве существует в двух вариантах: в одном из них маршрутизатор делает общий запрос обо всех группах «IGMP General Query» (общий запрос), в другом его интересует информация только о некоторой конкретной группе, адрес которой указывается в запросе«IGMP Group Sepcific Query» .

2) Отчет о членстве (IGMP Report ) . Этим сообщением хосты отвечают маршрутизатору, который послал в сеть запрос о членстве. В сообщении содержится информация об IP-адресе группы, в которой они состоят. Маршрутизатор, являясь членом всех групп, получает сообщения, направленные на любой групповой адрес. Для маршрутизатора, получающего ответные сообщения, важен только факт наличия членов той или иной группы, а не принадлежность конкретных хостов конкретным группам. Отчет о членстве хост может послать не только в ответ на запрос маршрутизатора, но и по собственной инициативе, когда он пытается присоединиться к определенной группе. После такого сообщения хост может рассчитывать на то, что трафик для этой группы действительно будет доставляться в сеть, к которой этот хост принадлежит.

3) Покинуть группу (IGMP Leave ). Это сообщение хост может использовать, чтобы сигнализировать «своему» маршрутизатору о желании покинуть некоторую группу, в которой он до этого состоял. Получив это сообщение, маршрутизатор посылает специфический запрос о членстве членам только этой конкретной группы « IGMP Group Sepcific Query» , и если не получает на него ответ (то есть это был последний хост в группе), то перестает передавать трафик группового вещания для этой группы.

Сообщения с запросами о членстве посылаются маршрутизатором регулярно с некоторой частотой. На каждом из интерфейсов с установленными средствами IGMP маршрутизаторами поддерживаются кэш-таблицы групп. Кэш-таблица содержит список всех групп, в составе которых есть хотя бы один член. Для каждой строки таблицы установлен таймаут. Маршрутизатор регулярно посылает запросы «IGMP General Query» (по умолчанию - каждые 60 секунд), чтобы проверить, что в каждой группе еще имеются члены. Если для некоторой группы ответ не поступает в течение установленного для нее тайм-аута, то соответствующая строка удаляется из кэш-таблицы, и маршрутизатор считает, что членов этой группы в сети больше нет.

Локальная сеть может иметь несколько хостов, заинтересованных в получении трафика одной и той же группы, но маршрутизатору достаточно подтверждения только от одного хоста для того, чтобы продолжить передавать трафик в сеть для этой группы. Основываясь на информации, полученной с помощью IGMP, маршрутизаторы могут определять, в какие подключенные к ним сети необходимо передавать групповой трафик.

Чтобы хост смог получать трафик группового вещания, недостаточно установить на нем протокол IGMP, с помощью которого хост может отправить сообщение своему маршрутизатору о желании присоединиться к группе. Помимо этого, надо сконфигурировать сетевой интерфейс хоста так, чтобы он стал захватывать из локальной сети кадры, несущие в себе пакеты группового вещания для той группы, к которой присоединился хост.

Чтобы стало понятнее, как работает IPTV, рассмотрим небольшой пример (рисунок 6.9) . Для работы IPTV необходим роутер, поддерживающий multicast (далее MR ). Он будет отслеживать членство того или иного клиента в определенной группе, т.е. постоянно следить, какому клиенту какой отправлять TV-канал. В сети есть сервер (Мulticast источник ), подключённый к роутеру MR. Этот сервер вещает TV-каналы, например:

Предположим, что клиент включает канал News, тем самым, сам не подозревая, он отправляет запрос на MR для подключения к группе 224.12.0.1. С точки зрения протокола IGMP это сообщение«IGMP Report 224.12.0.1 ” . После получения Multicast Router"ом данного сообщения, MR регистрирует его, и Ethernet коммутатор (SW ) приступает к копированию широковещательных пакетов, предназначенных для данной группы, в порт, к которому подключен клиент. Клиент начинает получать трафик.



Рисунок 6.9 – Принцип работы IGMP

Если клиент переключается на другой канал, то он сначала отправляет уведомление MR , что он отключает канал News, т.е. покидает эту группу. Для IGMP это сообщение “LEAVE 224.12.0.1 ” (ВЫЙТИ из группы 224.12.0.1). А затем опять шлёт сообщение «IGMP Report » для нужного канала.

Маршрутизатор MR получив сообщение “LEAVE ” для какой-либо группы, должен убедиться, что больше никаких других получателей этого канала нет, посылает сообщение «IGMP Group Specific Query» дважды. И если ни один STB не откликнется, то MR перестаёт передавать трафик этой группы.

Кроме того, MR периодически (каждые 60 секунд) опрашивает всех: «к какой группе кто подключен?», для выяснения состава групп в текущей момент времени, чтобы отключать тех клиентов, с которыми оборвалась связь. При этом MR использует запрос «IGMP General Query » (Общий з апрос) . Если на 3 подряд «Query» не было с интерфейсов MR ответа «IGMP Report» для какой-то группы, MR удаляет этот канал из своей таблицы мультикастовой маршрутизации - перестаёт посылать трафик этого канала до тех пор, пока к этой группе не подключится, хотя бы один клиент.

После присоединения к необходимой группе, клиентское оборудование начинает принимать поток данных по протоколу UDP на порт 1234.

Таким образом, переключение каналов с дистанционного пульта-«ленивчика », столь привычное и простое для пользователей традиционного те­левидения, представляет сложность для сети IPTV. Всякий раз, когда пользо­ватель IPTV переключает канал, в сети начинает кипеть работа :

1) Во-первых, пользователя следует отключить от группы Multicast.

2) Во-вторых, подключить его к новой группе Multicast.

3) В-третьих, если канал вещания вообще отсутствует в данный момент, так как его никто не смотрит, значит, нужно инициировать вещание и создать новую группу Multicast.

Итак, повторим ещё раз:

IGMP Report - посылается клиентом при подключении, если клиент хочет получать трафик конкретной группы или в ответ на запрос маршрутизатора о членствеIGMP Query.

IGMP General Query - посылается маршрутизатором периодически, чтобы проверить, какие группы сейчас нужны.

IGMP Group Sepcific Query - посылается маршрутизатором в ответ на сообщение Leave, чтобы узнать есть ли другие получатели в этой группе. В качестве адреса получателя указывается адрес мультикастовой группы.

IGMP Leave - посылается клиентом, когда тот хочет покинуть группу.

7 Пассивные оптические сети (PON) – переворот в широкополосном доступе

Оптоволокно на последней

миле: это надо PONять

Технология PON используется для реализации структур FTTH «волокно до жилища». Возможности технологии GPON удивляют в первую очередь тем, что доступ к ресурсам сети Интернет возможен на скорости до 1 Гб/с, что в двести раз выше, чем по медным линиям.

Сеть строится с помощью пассивных делителей оптической мощности (сплиттеров), не требующих питания и обслуживания. Особенностью технологии является 100% оптический канал от АТС до квартиры или офиса клиента, что позволяет повысить качество передачи сигнала (голоса, данных, видео) и в десятки раз увеличить скорость передачи данных.

Инфраструктура GPON отличается крайней неприхотливостью и безопасностью: не требует электропитания и может быть смонтирована в любом, даже неприспособленном помещении

Основные преимущества PON:

1 Простота и перспективность реализации распределительной инфраструктуры;

2 Отсутствие промежуточных активных узлов;

3 Быстрое развёртывание сети;

4 Простота сопряжения с любым внешним оборудованием;

5 Высокая гибкость при развитии и наращивании сети;

6 Независимое использование любых протоколов работы и технологий связи;

7 Повышенная надёжность;

8 Простота подключения новых абонентов и удобство обслуживания (подключение, отключение или выход из строя одного или нескольких абонентских узлов никак не сказывается на работе остальных);

9 Невысокая стоимость создания сети и т. д.

Протокол 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) is a family of multicast routing protocols that can provide one to many and many to many distribution of data over the Internet. The protocol independent part refers to the fact that PIM does not include its own topology discovery mechanism … Wikipedia

    Protocol Independent Multicast - (PIM) est une famille de protocoles de routage IP multicast qui permet la diffusion vers un groupe d hôtes. PIM est dit Protocol Independent car il base ses décisions de routage sur la topologie établie par d autres protocoles comme BGP. Il… … Wikipédia en Français

    Protocol-Independent-Multicast

    Protocol Independent Multicast - (PIM) ist ein Verfahren in der Netzwerktechnik, das dynamisches Routing von Multicast Paketen im Internet ermöglicht. Anders als traditionelle Verfahren wie DVMRP oder MOSPF ist PIM auch bei stark verstreuten Teilnehmern bzw. Multicast Gruppen… … Deutsch Wikipedia

    Multicast - is sometimes also incorrectly used to refer to a multiplexed broadcast. In computer networking, multicast is the delivery of a message or information to a group of destination computers simultaneously in a single transmission from the source… … Wikipedia

    - (MSDP) is a Protocol Independent Multicast (PIM) family multicast routing protocol defined by Experimental RFC 3618. MSDP interconnects multiple IPv4 PIM Sparse Mode (PIM SM) domains which enables PIM SM to have Rendezvous Point (RP) redundancy… … Wikipedia

    Multicast address - A multicast address is a logical identifier for a group of hosts in a computer network, that are available to process datagrams or frames intended to be multicast for a designated network service. Multicast addressing can be used in the Link… … Wikipedia

    Multicast - Kommunikationsformen / Routing Schemata Unicast Broadcast Anycast … Deutsch Wikipedia

    IP-Multicast - Multicast (ähnlich dem Gruppenruf) bezeichnet in der Telekommunikation eine Nachrichtenübertragung von einem Punkt zu einer Gruppe (auch Mehrpunktverbindung genannt). Der Vorteil von Multicast besteht darin, dass gleichzeitig Nachrichten an… … Deutsch Wikipedia

    IP multicast - is a method of sending Internet Protocol (IP) datagrams to a group of interested receivers in a single transmission. It is often employed for streaming media applications on the Internet and private networks. The method is the IP specific version … Wikipedia