> For the complete documentation index, see [llms.txt](https://linkmeup.gitbook.io/sdsm/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://linkmeup.gitbook.io/sdsm/9.-multicast/2.-pim/6.-zavershenie.md).

# Завершение

1. Должна быть обеспечена обычная юникастовая связность с помощью IGP или статических маршрутов. Это лежит в основе алгоритма RPF.
2. Дерево строится только после появления клиента. Именно клиент инициирует построение дерева. Нет клиента — нет дерева.
3. RPF помогает избежать петель.
4. Все маршрутизаторы должны знать о том, кто является RP — только с её помощью можно построить дерево.
5. Точка RP может быть указана статически, а может выбираться автоматически с помощью протокола BootStrap.
6. В первой фазе строится RPT — дерево от клиентов до RP — и Source Tree — дерево от источника до RP. Во второй фазе происходит переключение с построенного RPT на SPT — кратчайший путь от получателя до источника.

Ещё перечислим все типы деревьев и сообщений, которые нам теперь известны.

**MDT — Multicast Distribution Tree**. Общий термин, описывающий любое дерево передачи мультикаста.\
**SPT — Shortest Path Tree**. Дерево с кратчайшим путём от клиента или RP до источника. В PIM DM есть только SPT. В PIM SM SPT может быть от источника до RP или от источника до получателя после того, как произошёл SPT Switchover. Обозначается записью **(S, G)** — известен источник для группы.\
**Source Tree** — то же самое, что SPT.\
**RPT — Rendezvous Point Tree**. Дерево от RP до получателей. Используется только в PIM SM. Обозначается записью **(\*, G)**.\
**Shared Tree** — то же, что RPT. Называется так потому, что все клиенты подключены к одному общему дереву с корнем в RP.

Типы сообщений PIM Sparse Mode:\
**Hello** — для установления соседства и поддержания этих отношений. Также необходимы для выбора DR.\
**Join (\*, G)** — запрос на подключение к дереву группы G. Не важно кто источник. Отправляется в сторону RP. С их помощью строится дерево RPT.\
**Join (S, G)** — Source Specific Join. Это запрос на подключение к дереву группы G с определённым источником — S. Отправляется в сторону источника — S. С их помощью строится дерево SPT.\
**Prune (\*, G)** — запрос на отключение от дерева группы G, какие бы источники для неё не были. Отправляется в сторону RP. Так обрезается ветвь RPT.\
**Prune (S, G)** — запрос на отключение от дерева группы G, корнем которого является источник S. Отправляется в сторону источника. Так обрезается ветвь SPT.\
**Register** — специальное сообщение, внутри которого передаётся мультикаст на RP, пока не будет построено SPT от источника до RP. Передаётся юникастом от FHR на RP.\
**Register-Stop** — отправляется юникастом с RP на FHR, приказывая прекратить посылать мультикастовый трафик, инкапсулированный в Register.\
**Bootstrap** — пакеты механизма BSR, которые позволяют выбрать маршрутизатор на роль BSR, а также передают информацию о существующих RP и группах.\
**Assert** — сообщение для выбора PIM Forwarder, чтобы в один сегмент не передавали трафик два маршрутизатора.\
**Candidate-RP-Advertisement** — сообщение, в котором RP отсылает на BSR информацию о том, какие группы он обслуживает.\
**RP-Reachable** — сообщение от RP, которым она уведомляет всех о своей доступности.\
\&#xNAN;*Есть и другие типы сообщений в PIM, но это уже детали*

А давайте теперь попытаемся абстрагироваться от деталей протокола? И тогда становится очевидной его сложность.

1\) Определение RP,\
2\) Регистрация источника на RP,\
3\) Переключение на дерево SPT.

Много состояний протокола, много записей в таблице мультикастовой маршрутизации. Можно ли что-то с этим сделать?

На сегодняшний день существует два диаметрально противоположных подхода к упрощению PIM: SSM и BIDIR PIM.