Кратко

  • Динамика групп, разные инициаторы состояния и конкурирующие цели оптимизации заставили RFC 2102 оставить вне ядра Nimrod и построение multicast-маршрута, и механизм пересылки.
  • Общей стала не методика расчёта, а структура установленного состояния: разделяемые и корневые от источника деревья могли сосуществовать при едином толковании связей пересылки.
  • Запись о ветви подтверждала локальное копирование, но не членство, разрешение, полное покрытие, кратчайший путь, резервирование или доставку.

В RFC 2102 совместимость начинается там, где алгоритм уже закончил работу. Маршрутизатор видит flow-id, родителя и набор дочерних направлений. На этом уровне ему не нужно знать, построил ли ветвь отправитель, запросил ли её получатель или вывел ли её другой маршрутизатор. Но значение записи должно быть однозначным.

Почему выбор оставили открытым

И unicast, и multicast требуют построения маршрута и пересылки пакетов. Nimrod задавал режимы unicast-пересылки, но не алгоритм маршрута. Для multicast RFC 2102 не фиксировал обе фазы.

Причины были структурными. Состав группы меняется. Состояние может создавать отправитель, получатель или промежуточные узлы. Эвристики тоже решают разные задачи: дерево с меньшей суммарной стоимостью может увеличить задержку; кратчайшие пути к каждому получателю могут потребовать больше ресурсов и состояния.

DVMRP строил деревья от источника с помощью reverse path forwarding. CBT сокращал состояние общим деревом вокруг core, но мог удлинять пути. PIM совмещал общее и source-specific дерево. MOSPF вычислял по link-state и данным о членстве. IDPR позволял источнику выбрать policy route и установить промежуточное состояние копирования.

Минимальное соглашение находилось в FIB

RFC 2102 утверждал: дерево доставки определяется характером информации пересылки в маршрутизаторах, а не способом её создания. Если структура и смысл совпадают, реализации могут сосуществовать.

В примере Nimpim Join добавляет предыдущий узел в child list существующего flow. Для нового flow устанавливаются parent, child и target. Prune удаляет ребёнка и уничтожает flow только после опустошения списка. Пакет несёт flow-id, а forwarding agent копирует его по установленным связям.

Получатель поэтому может присоединить ветвь к дереву отправителя без повторного расчёта у источника. Общее дерево может смениться деревом источника. Несколько методов могут действовать одновременно, пока состояние остаётся одинаково интерпретируемым.

Чего строка состояния не доказывает

Child list не является реестром получателей. RFC 1112 размещает IGMP-членство на непосредственно подключённом сегменте и использует собственные таймеры и агрегацию. Состояние пересылки — более поздняя проекция.

Это и не разрешение. Ограничения по адресатам могут потребовать нескольких деревьев для непересекающихся частей одной группы. Видимая ветвь не показывает отсутствующих адресатов и действующую политику.

Оптимальность также не следует из записи. CBT может вести через core; обратный кратчайший путь PIM зависит от симметрии метрик. Резервирование и качество — отдельные утверждения: строка не подтверждает admission, задержку, jitter или безопасное совместное использование ресурсов.

Наконец, она не доказывает, что источник отправил данные, остальные состояния сохранились, последний переход состоялся или приложение получило полезный результат. RFC 2102 не обсуждал безопасность, поэтому членство и авторизация тоже не выводятся из установленной ветви.

Историческое значение границы

RFC 1992 уже допускал разные карты и режимы пересылки; RFC 1753 разделял пользовательское и сервисное состояние. RFC 2102 перенёс эту дисциплину на multicast: сделать общим только то, что необходимо для совместного исполнения.

Поздняя Minimum Initial Specification Лу Хэна даёт язык для такой тонкой общей поверхности, а Running-Code Primacy запрещает считать публикацию внедрением. Это аналитическая параллель, а не историческая зависимость. RFC 2102 — Informational и не свидетельствует о развёртывании Nimrod.

Его долговечный вывод прост: расчёты могут отличаться, смысл исполнения — нет. Ветвь доказывает только ветвь; остальные выводы требуют собственных свидетельств.

Источники