Кратко

  • RFC 3429 назначил зарезервированное значение MPLS 14 меткой OAM Alert Label, чтобы распознавать OAM-пакеты пользовательского плана. Это не заменяет функции, заданные рекомендацией ITU-T Y.1711.
  • В описанном RFC случае PHP предпоследний LSR снимал обычную верхнюю метку, сохраняя метку OAM и полезную нагрузку для MPLS-узла на выходе, который поддерживает OAM. Узел без обработки MPLS-меток был другим случаем и тогда не входил в область применения Y.1711.
  • TTSI в пакете помогает установить входной LSR-источник. Этот идентификатор не доказывает исправность LSP, доставку клиентских данных или обработку аварийного сигнала.

Значение implicit-null (3) передаётся по управляющему протоколу, но никогда не попадает в пакет. Оно сообщает предпоследнему LSR: снять верхнюю метку, а не заменить её. Такой PHP экономит выходному узлу дополнительный поиск. Пакету обслуживания и эксплуатации при этом нужно сохранить собственный признак, иначе после снятия верхней метки выход может не отличить его от обычного трафика.

В RFC 3429 для этого назначено значение 14 из диапазона MPLS-меток, зарезервированного RFC 3032. Метка получила имя OAM Alert Label и служит для идентификации OAM-пакетов пользовательского плана. Назначение номера не описывает полностью содержимое OAM-пакета, не предписывает реализацию каждому маршрутизатору и не удостоверяет состояние пути.

Как распределены функции между спецификациями

Рекомендация ITU-T Y.1711 определяет функции MPLS OAM и структуру сообщений. RFC 3031 описывает архитектуру MPLS и механизм PHP. RFC 3429 выделяет значение в пространстве MPLS-меток, позволяющее совместимому выходному узлу классифицировать такой пакет. Это три сопряжённых уровня, а не одно общее доказательство работоспособности сети.

В первом сценарии RFC 3429 конечный узел остаётся MPLS LSR с управляющей и транспортной функциями, но запрашивает PHP, поскольку не может выполнять два поиска меток на линейной скорости. Предпоследний узел снимает верхнюю обычную метку и передаёт дальше метку OAM вместе с полезной нагрузкой. Если выход поддерживает MPLS OAM, он видит значение 14 во главе оставшегося стека и распознаёт пакет обслуживания.

TTSI (Trail Termination Source Identifier) внутри полезной нагрузки указывает входной LSR, создавший OAM-пакет, в рамках описанного механизма. Таким образом, сведения об источнике остаются в пакете и после удаления внешней метки. Но TTSI не является историей всех переходов: он не подтверждает правильную пересылку на каждом узле, работу обратного пути или получение данных удалённым приложением. Распознанная метка также не сообщает сама по себе, завершилась ли успешно конкретная функция CV, FDI, BDI или другой элемент Y.1711.

Одинаковый запрос PHP не означает одинаковый выход

Во втором сценарии конечный узел не умеет искать или обрабатывать MPLS-метки и вообще не распознаёт помеченные пакеты. Он также может запросить implicit-null и PHP. Однако такое сигнальное сообщение не наделяет узел функциями OAM. RFC 3429 прямо указывает: действовавшие тогда функции Y.1711 применимы только к первому случаю. Второй требовал дальнейшей проработки; для сценария carrier supporting carrier также оставалась будущая работа.

Если конечный LSR не поддерживает MPLS OAM, RFC 3429 предписывает отбросить полученный OAM-пакет. Поэтому отсутствие записи на выходе не доказывает ни исправность LSP, ни то, что PHP нарушил пересылку. RFC 3031 объясняет осторожность: неизвестную метку нельзя бездумно удалить, а остаток — переадресовать как обычный IP-пакет. Метка может нести смысл, который невозможно восстановить только по IP-заголовку. Отбросить безопаснее, чем произвольно переосмыслить, но наблюдаемость от этого не появляется.

Запись в реестре не равна поддержке на узлах

Действующий реестр значений MPLS Label Values IANA по-прежнему связывает значение 14 с OAM Alert Label и RFC 3429. Стабильная запись помогает разным спецификациям использовать один термин. Она не показывает, какие LSR сегодня реализуют Y.1711, где включён PHP и как конкретное устройство регистрирует отброшенный пакет.

RFC 3429 опубликован в ноябре 2002 года как информационный документ, а не отчёт о внедрении. Его историческая ценность — в ясно очерченной границе: ITU-T описывает функции OAM, IETF резервирует MPLS-маркер, а конечному узлу всё равно требуется способность разобрать его и полезную нагрузку. Реестр закрепляет общую семантику, но не выполняет мониторинг вместо сети.

Для проверки реального пути нужно собрать раздельные свидетельства: объявленную обработку implicit-null, фактическое действие предпоследнего LSR, стек меток у выхода, поддержку OAM конечным узлом, связь TTSI с входным LSR и результат конкретной OAM-функции. Доставку клиентского трафика следует проверять отдельно. Фразы «метка 14 зарегистрирована», «OAM включён» и «LSP активен» относятся к разным слоям; ни одна из них не подтверждает получение услуги клиентом.

Источники