Кратко

  • Редакция 14 draft-ietf-mpls-mna-ioam, опубликованная 11 сентября 2026 года, вводит нормативное правило для узла MPLS с неизвестным способом балансировки нагрузки.
  • Для потока, обозначенного Flow ID MNA, 19-битная часть Sequence Number MNA, начинающаяся с бита 1 LSE, должна быть неизменной, если в балансировке участвует стек меток; теперь то же правило действует и при неизвестном способе.
  • Механизм определения способа балансировки оставлен за рамками проекта. Фиксация разрядов исключает один источник возмущения, но не подтверждает неизменность пути измерения.
  • Оператору нужен локальный документ об исходной гипотезе хеширования, её основании, охваченных узлах и точке наблюдения, прежде чем сравнивать данные IOAM-DEX.

Счётчик рядом с плоскостью пересылки

В RFC 9326 прямой экспорт IOAM использует два полезных ориентира. Flow ID позволяет сопоставлять экспортированные записи одного потока, а Sequence Number обычно начинается с нуля и увеличивается на единицу для каждого пакета этого потока с DEX. Способ назначения Flow ID стандарт не устанавливает.

В draft-ietf-mpls-mna-ioam-14 оба необязательных поля получают MPLS-представление. Flow ID MNA и Sequence Number MNA занимают по одному полному 32-битному элементу стека меток формата D. За вычетом обязательного ведущего бита и бита S, обозначающего дно стека, полезное значение каждого поля составляет 30 бит.

Эта компоновка сближает телеметрию с механизмом выбора пути. Некоторые узлы строят хеш балансировки с участием содержимого стека меток. Если весь номер последовательности меняется от пакета к пакету, наблюдательный счётчик может стать меняющимся входом хеша. Средство измерения тогда способно влиять на то, какой именно путь оно измеряет.

Консервативная ветвь для неизвестного

В редакции 13 были описаны две ситуации. Когда известно, что узел балансирует по данным стека меток, 19 бит Sequence Number MNA начиная с позиции 1 в LSE обязаны оставаться неизменными для конкретного Flow ID. Когда известно, что применяются иные методы, можно менять все биты номера последовательности.

Официальное сравнение редакций 13 и 14 показывает добавленную ветвь. Если техника узла неизвестна, применяется то же 19-битное ограничение. Следующее положение фиксирует границу документа: способы узнать применяемую узлами MPLS технику балансировки в него не входят.

Таким образом, неопределённость не даёт права задействовать всю изменяемую часть счётчика. Сначала действует безопасное ограничение. Чтобы перейти к случаю, где разрешено менять все биты, эксплуатационная сторона должна располагать основанием считать другой метод известным. Сам проект не предлагает стандартного запроса к устройству или процедуры проверки.

Редакция 14 уточняет и соседние правила. При сброшенном флаге F весь Format D LSE для Flow ID должен отсутствовать; при сброшенном Q отсутствует весь элемент для Sequence Number, включая фиксированные биты. Block-Number в заголовке после стека теперь обязан быть нулевым, если альтернативная маркировка не используется: прежнее SHOULD заменено на MUST. Ряд неверных сочетаний действий внутри и после стека объявлен ошибочным и требует удаления пакета.

Основанием служат архитектура IOAM в RFC 9197, уже ограничивающая применение контролируемым доменом и требующая учитывать ECMP, рамочная модель MPLS Network Actions в RFC 9789 и базовое решение в RFC 9994. Документ также опирается на развивающийся проект заголовка MNA после стека и существующие определения, включая реестр IANA IOAM Trace-Type.

Ограничение не подтверждает маршрут

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

Flow ID служит ключом сопоставления, а не универсальным удостоверением потока. Непрерывная последовательность совместима с развилкой на следующем узле; разрыв может возникнуть в экспорте или сборщике, а не при пересылке. В источниках нет названной реализации, испытания совместимости, захвата пакетов, результата по стабильности пути или измеренной нагрузки.

Граница доверия задана отдельно. Действия IOAM и IOAM-DEX предназначены для одного доверенного административного домена. Пограничные узлы должны отфильтровать пакеты с такими действиями, пришедшие из другого домена или ненадёжного источника, до допуска внутрь. Вспомогательные данные могут передаваться открыто, поэтому без дополнительной защиты нельзя полагаться на их целостность.

Карточка Datatracker описывает активный Internet-Draft рабочей группы MPLS с предполагаемым статусом Proposed Standard. Группа передала документ в IESG для публикации, а состояние IESG — Publication Requested; история отражает версии. Запрашиваемые коды по-прежнему обозначены TBA. Редакция не является выделением IANA, одобрением, RFC или подтверждением внедрения.

Источники