Кратко

  • RFC 3353 показал замкнутый старт traffic-driven multicast LSP: новой ветви требовался пакет как сигнал, но пакет не мог прийти по L2 до появления этой ветви.
  • Смешанная пересылка L2/L3 или инициатива вышестоящего LSR разрывали цикл, однако наблюдение пакета, маршрутное состояние, обмен метками, программирование репликации и доставка оставались разными фактами.

Поток уже идёт к одному получателю. За другим downstream-LSR к группе присоединяется второй. Чтобы молчащие группы не занимали пространство меток, сеть хочет создавать новый LSP только после появления данных. Второй маршрутизатор должен увидеть первый пакет и запросить ветвь.

На L2 он не увидит пакет без ветви, которую этот пакет должен запустить. Триггер ждёт путь, путь ждёт триггер. RFC 3353 назвал это проблемой курицы и яйца. За метафорой стоял точный операционный вопрос: на какой стороне отсутствующего соединения находится наблюдатель и кто вправе превратить наблюдение в привязку метки?

RFC 3353 вышел в августе 2002 года как Informational. Он не стандартизировал единый протокол и не сообщал о массовом внедрении. Документ упорядочивал выборы, возникавшие при отображении деревьев IP multicast на MPLS. У unicast обычно один следующий переход. У multicast один вход может иметь несколько выходов, а дерево меняется вместе с составом получателей.

Общее дерево обозначалось (*,G), дерево источника — (S,G). Первое экономило метки, но требовало multipoint-to-multipoint и операций слияния. Второе уменьшало часть проблем слияния, зато размножало состояние по источникам и группам. Ограничения нижнего уровня — размер пространства меток, возможность merge и работа с TTL — также меняли решение. Универсального победителя RFC не выбирал.

Flood-and-prune делал состояние особенно подвижным. Пакет создавал запись, ненужные ветви отсекались, таймер бездействия удалял состояние. Если L2 повторял каждое изменение, росли сигнализация и оборот меток. Если LSP строились заранее, ресурсы занимали пустые деревья. Ожидание трафика экономило в покое и переносило цену на первый пакет.

Документ выделял три вида запуска. Request-driven реагировал на Join, Prune или сообщения резервирования. Topology-driven переносил дерево из multicast-таблицы на L2 даже без данных. Traffic-driven ждал реальных пакетов. Каждый подход платил в другой валюте: связностью протоколов, неиспользуемым состоянием или задержкой запуска.

Первым выходом была инициатива upstream-LSR. Он уже видел поток и мог запросить метку у нижестоящего узла либо объявить метку, назначенную сверху. Наблюдение и действие оказывались по одну сторону разрыва. Поэтому таблица RFC связывала тип триггера с направлением распространения меток, а не представляла их независимыми настройками.

Вторым выходом была смешанная пересылка L2/L3. Узел продолжал коммутировать готовую ветвь на L2, а новую временно маршрутизировал на L3. Первый пакет доходил по IP, создавал недостающее наблюдение, после чего можно было обменяться метками и запрограммировать ветвь. После проверки поток переходил на MPLS. Смешанный режим был обратимым мостом, а не архитектурным недоразумением.

Мост требовал исключить дубли. L3 не должен был посылать копии на интерфейсы, уже обслуживаемые L2. Без смешанного режима downstream не мог запуститься от трафика, поэтому запрос должен был исходить сверху. Комбинация двух допустимых параметров могла оказаться неработоспособной, если интерфейс конфигурации не показывал эту зависимость.

Так возникает лестница доказательств. Пакет на upstream подтверждает одно локальное прибытие. Cache miss подтверждает отсутствие локальной записи. Строка MRT подтверждает локальное управляющее состояние. Label request или mapping подтверждает шаг сигнализации. Запись ASIC подтверждает программирование одного устройства. Ни один из этих фактов сам по себе не подтверждает получение всеми листьями.

Пример Unix Multicast Forwarding Cache раскрывал ещё одну границу. Первый пакет вызывал cache miss, multicast-daemon возвращал маршрут. Когда L2 начинал коммутировать последующие пакеты, L3 переставал их видеть. Таймер L3, опирающийся только на собственные счётчики, мог удалить живой поток.

RFC предлагал обновлять L3-счётчики по измерениям L2. Это решало практическую проблему, но превращало число в межуровневую проекцию. Оно означало уже не только «сколько переслал IP», а «какую активность сообщил связанный нижний уровень». Источник, окно, эпоха сброса и соответствие ветви становились частью смысла.

PIM-SM создавал ещё одну переходную область. (*,G) и (S,G) могли сосуществовать при переходе от общего дерева к дереву источника. Некоторое время пакеты одного источника приходили по двум входам. L3 мог подавить неверную копию по специфическому состоянию. Чистый L2 должен был допустить краткую дупликацию, завести дополнительные метки или вернуть решение на L3. Метка ускоряла действие, но не выбирала правильную копию.

Инкапсуляция проводила жёсткую границу. Источник общего дерева мог туннелировать данные к корню, где они декапсулировались. Обе операции относились к L3. Один непрерывный L2 LSP не мог пройти через точку интерпретации, будто её нет. MPLS мог обслуживать туннель или остальные ветви, но не отменял смену уровня.

Piggy-backing привязки метки к multicast-сообщениям синхронизировал маршрут и label и уменьшал отдельный обмен. За это приходилось расширять каждый протокол, отказываться от части комбинаций и иногда менять надёжный LDP поверх TCP на периодический soft state. Синхронное сообщение всё ещё не было квитанцией репликации.

На multiaccess-среде несколько downstream-LSR нуждались в одной метке. Они могли помнить все назначения, делить диапазоны или выбирать распределитель. Upstream-назначение использовало единственный верхний узел дерева, но топологическое изменение могло заменить его. Downstream-назначение лучше сохраняло метку при такой замене, однако требовало согласовать несколько предложений. RFC оставил выбор эксплуатации.

Позднейшие документы сделали дерево явнее. RFC 4461 сформулировал требования к добавлению и удалению листьев, отказам и масштабированию P2MP TE LSP. RFC 4875 описал RSVP-TE, где P2MP LSP состоит из нескольких source-to-leaf sub-LSP, объединяемых в branch-LSR. Он отдельно подчеркнул: состояние сигнализации может разветвиться там, где данные не реплицируются. Управляющее дерево не являлось квитанцией доставки.

RFC 5332 исправил одно ожидание раннего периода. Раздельное использование link-layer codepoint для MPLS unicast и multicast из RFC 3032 так и не было внедрено; второму codepoint придали значение upstream-assigned label на общей среде. RFC 6513 позже сохранил для multicast VPN выбор между distribution tree и ingress replication через unicast-туннели. Место копирования менялось, цена оставалась.

Историческая ценность RFC 3353 — в сохранённой последовательности. До ветви с меткой существовали первый пакет, временный путь L3 или решение upstream. После сигнализации оставались программирование, репликация и проверка. Реальная сеть состояла из этой цепочки, а не из единого зелёного статуса.

Источники