Кратко

  • RFC 9546 требует ставить d-ACH сразу после S-Label и выделяет активному OAM собственный циклический восьмибитный счётчик.
  • PREOF обязан использовать этот счётчик при обработке OAM; стандарт прямо говорит, что OAM и App-flow имеют разные пространства номеров.
  • Непрерывная серия OAM подтверждает лишь сеанс в рамках Node ID, Level, Session ID и времени, но не историю производственных пакетов и не результат приложения.

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

Общая S-Label подталкивала признать ошибочным именно прикладной отчёт. Но RFC 9546 не позволяет смешать принадлежность к сервису с идентичностью событий. Такое различие заложено в заголовке пакета.

Одна метка связывает потоки, но не объединяет их номера

В сервисном подуровне DetNet S-Label идентифицирует поток. В активном OAM поверх MPLS заголовок DetNet Associated Channel Header, d-ACH, должен идти непосредственно после этой метки. Узел понимает, к какому сервису относится тест, и применяет предусмотренные функции.

Однако в d-ACH находится собственный Sequence Number. При обработке OAM PREOF должен брать информацию о последовательности именно оттуда. Затем документ проводит жёсткую границу: App-flow и OAM используют разные пространства номеров.

Появление тестового пакета 64 после 63 подтверждает локальную непрерывность теста. Оно не определяет номер производственного пакета, не показывает выбранную копию данных, состояние рабочего буфера и своевременность прикладной обработки. Нормативного равенства между OAM 64 и производственным событием 64 не существует.

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

Полный d-ACH задаёт границы свидетельства

Первые четыре бита равны 0001, чтобы отличить пакет от IP и данных DetNet. Далее идут четырёхбитная Version — в RFC определена версия ноль, — циклический восьмибитный Sequence Number, 16-битный Channel Type, 20-битный Node ID, трёхбитный Level, пять битов Flags и четырёхбитный Session ID.

Node ID называет узел-источник и должен быть уникально назначен внутри домена DetNet. Способ распределения остаётся за рамками стандарта. Поэтому корректное двадцатибитное значение не доказывает глобальную уникальность и правильность инвентаря. Нужны сведения о домене, владельце значения в данный период и процедуре обнаружения коллизий.

Level создаёт иерархию, похожую на уровни доменов обслуживания. Внутренняя команда и внешняя граница сервиса могут видеть разные части одного объекта. Session ID различает параллельные сеансы одного узла на одном уровне. Channel Type указывает протокол связанного канала.

Защищаемый ключ включает S-Label, Node ID, Level, Session ID, Channel Type, эпоху конфигурации, точку наблюдения и время. Восьмибитное число без этой рамки ещё не является историей.

Циклический счётчик требует эпохи

Источник обязан задать номер до передачи. Начальное значение рекомендуется выбирать непредсказуемым, а обычная стратегия увеличивает его на единицу для каждого активного пакета OAM. Допускаются и другие методы, например намеренно необычная последовательность для негативной проверки Ordering Function.

После 255 идёт 0. RFC считает диапазон достаточным, поскольку активный OAM работает существенно медленнее App-flow. Это предположение для заданного применения, а не разрешение на любую частоту теста, срок хранения или алгоритм без сведений о перезапуске.

Ряд 254, 255, 0, 1 может быть нормальным оборотом или началом нового сеанса. Повтор способен означать копию, оборот, перезапуск либо смешение двух сеансов после утраты Session ID. Пропуск может возникнуть в сети, сборщике, генераторе или при специально заданном отрицательном тесте.

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

Успех PREOF принадлежит обработанному пространству

Packet Replication, Elimination and Ordering Functions создают копии, удаляют поздние дубликаты и восстанавливают порядок. Каждое решение основано на видимых пакетах, локальном окне истории, таймерах и переданном пространстве номеров.

Для OAM источником служит d-ACH. Для производственных данных существует собственный контекст App-flow. Удаление копии теста не сообщает, какая копия данных была выбрана. Упорядоченный тест не доказывает одинаковые приходы и сроки в рабочем буфере.

Даже совместная судьба не объединяет счётчики. Она повышает релевантность сравнения, но не создаёт отсутствующие производственные события. Эквивалентность ECMP, LAG, туннеля, классификации и ресурсов остаётся отдельной задачей; положительный ответ на неё не отменяет раздельную бухгалтерию.

Сопоставлять можно, выдавать одно за другое нельзя

Запись ассоциации фиксирует нужную S-Label и правильное положение d-ACH. Запись сеанса определяет Node ID, Level, Session ID, Channel Type, эпоху и политику теста. Журнал OAM-PREOF хранит решения по тестовым номерам. Отдельная производственная книга прослеживает номера данных, копии, вывод и прикладной приём.

Эти книги можно коррелировать. Одновременные разрывы дают основание для расследования; изменение после одной конфигурации усиливает гипотезу. Но точная формулировка такова: две ограниченные по сфере записи совпали во времени. Номер OAM не доказал доставку пакета данных.

Разделение открывает реальные варианты: генератор теста перезапустился, Node ID столкнулись, сборщик потерял запись, производственные копии разделили скрытый риск, окно порядка истекло или приложение отвергло доставленные данные. Одна зелёная линия не уполномочена исключать эти сценарии.

Источники