Кратко

  • RFC 3063 разрешал назначить метку после возврата потока, сделав отсутствие петли условием построения пути, а не выводом из одной лишь таблицы маршрутизации.
  • Цвет, счётчик переходов и TTL сохраняли фиксированный размер управляющего состояния; гарантия оставалась внутри процедуры и не доказывала ни внедрение механизма, ни доставку пакетов.

Метка оставалась последним шагом

Главная идея RFC 3063 не в том, чтобы просто обнаружить петлю. Обнаружение привязано к конкретному решению: в режиме предотвращения узел не отправляет привязку метки, пока управляющий поток не вернётся.

MPLS не заставляет каждый маршрутизатор заново просматривать весь маршрут при пересылке каждого пакета. Маршрутизатор коммутации по меткам связывает метку с классом эквивалентности пересылки (FEC). Если следующий переход меняется, пока маршрут третьего уровня всё ещё замкнут в петлю, ранняя раздача метки может установить LSP, унаследовавший эту петлю. RFC 3063 превращает построение в заслон: кандидатный путь сначала должен удовлетворить правилам потока, и лишь затем освобождается привязка.

Опубликованный в феврале 2001 года документ имеет статус Experimental и прямо говорит, что не задаёт стандарт Интернета. Поток — это последовательность сообщений управления путём с тремя атрибутами: цветом, счётчиком переходов и временем жизни (TTL). Цвет объединяет IP-адрес инициатора с локальным идентификатором события, который должен быть уникальным во времени и пространстве. Когда тот же цвет возвращается, узел понимает, что поток прошёл по кругу. Счётчик переходов поддерживает возрастающую величину вдоль пути; для некоторых состояний обнаруженной петли предусмотрено особое значение «неизвестно».

TTL ограничивает дальность управляющего сообщения, но сам по себе не доказывает отсутствие петли.

Узлы могут продлевать поток в сторону выхода, объединять совместимые запросы, останавливать его при повторном появлении знакомого цвета, отзывать после потери следующего перехода или возвращать подтверждения по пройденному пути. В режиме предотвращения привязка метки отправляется лишь после такого возврата. В режиме обнаружения узел может вернуть привязку сразу после получения окрашенного потока, но этот ответ не запускает его возврат. Один и тот же механизм задаёт разные моменты освобождения; если назвать их одним общим «предотвращением петель», исчезает важная операционная граница.

Масштаб состояния тоже ограничен. Вектор пути увеличивается вместе с длиной LSP, а объект потока остаётся фиксированного размера. Пока поток идёт, маршрутизаторы временно хранят его цвет и счётчик переходов на соответствующих соединениях. После возврата активный цвет можно отбросить, оставив только счётчик. RFC 3063 утверждает, что такой выбор ограничивает размер сообщений независимо от размера сети, а при смене следующего перехода вовлекает только узлы ниже по новому пути. Это сравнение из проекта авторов, а не опубликованный замер в работающей сети.

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

Квитанция управляющего уровня — не трасса пакетов

Архитектура MPLS в RFC 3031 отделяет процедуры распространения меток от их применения на плоскости пересылки. Возврат потока свидетельствует лишь о конкретном состоянии управляющего уровня, проверенном алгоритмом. Он не показывает, что все таблицы пересылки получили правильную метку, что пакеты прошли по пути или что при другом порядке событий не возникала временная петля. Для этого нужны данные плоскости пересылки: состояние FIB, счётчики, пробы и заданный интервал наблюдения.

Более поздняя спецификация LDP RFC 5036 описывает настраиваемое обнаружение петель с помощью TLV Path Vector и Hop Count. Вектор перечисляет идентификаторы пройденных LSR; повтор идентификатора или достижение настроенного ограничения приводит к обработке сообщения как петли. Это другой механизм LDP, описанный позже в Standards Track, а не потоковая схема RFC 3063 со статусом Experimental. Его появление не устанавливает долю внедрения потоков и не доказывает, что стандартизаторы отказались от них по технической причине.

RFC 5715 позднее рассматривает сходимость без петель после изменения топологии — смежную, но иную проблему, чем запрет на установку циклического LSP.

Исторический вывод не обязан быть рассказом о победе или провале. RFC 3063 поставил квитанцию управляющего уровня перед выпуском метки и избежал вектора, растущего вместе с путём. По модели RFC возвращённый путь не содержит петли; фактическая реализация, сохранение прежнего пути и доставка пакетов требуют отдельных свидетельств.