# Завершение

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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://linkmeup.gitbook.io/sdsm/9.-multicast/2.-pim/6.-zavershenie.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.