Кратко

  • RFC 10014 рекомендует не использовать «in-band OAM» и «out-of-band OAM» как универсальные характеристики. Следует отдельно указывать активный, пассивный или гибридный метод, совпадение пути и равную либо различную обработку пересылки.
  • Выделенный зонд способен пересечь те же узлы и линии, но получить иной приоритет, очередь, scheduling, shaping или защитную обработку. Он может достоверно подтвердить путь и не отражать опыт рабочего трафика.
  • Результат, влияющий на SLA, автоматическое действие или закрытие инцидента, нужно связать с потоком, направлением, классом, эпохой, слоем, доменом обслуживания, выборкой пакетов и расчётом, предположениями о пути и обработке, правилом решения, полномочием изменения и независимой проверкой эффекта.

В отчёте сети всё было нормально. Сессия контроля входила через тот же граничный узел, проходила тот же core и покидала ту же линию, что и критичный сервис. Но пользовательские запросы регулярно превышали тайм-аут. Поскольку договор обещал «in-band OAM», зелёная сессия стала основанием закрыть сетевой инцидент.

Карта не показала развилку внутри маршрутизатора. Контрольные пакеты имели привилегированный класс, а рабочие стояли в перегруженной очереди. Путь совпадал, обработка — нет. Зонд сообщил верный факт, но организация превратила его в ответ на другой вопрос.

RFC 10014 опубликован в июне 2026 года как Best Current Practice IETF. Он не вводит единый протокол OAM и не переписывает старые RFC. Документ требует точнее называть свойства измерения. Для систем, где показатель запускает failover, определяет SLA или закрывает аварию, точность слов ограничивает власть автоматики.

Внутри какой именно «полосы»

Термины in-band и out-of-band пришли из радио и телефонии, где есть физически понятный канал. В пакетной сети «внутри» может относиться к разным объектам. Данные OAM могут находиться в самом пользовательском пакете. Отдельный пакет может идти тем же топологическим путём. Он может также получить ту же QoS-обработку. Это независимые признаки.

Первая ось RFC 10014 — участие. Active OAM генерирует выделенные пакеты. Passive OAM наблюдает существующие потоки, не создаёт тестовые пакеты и не изменяет наблюдаемые. Hybrid OAM сочетает активную и пассивную части. In-Data-Packet OAM — узкий случай Hybrid Type I, при котором данные OAM едут в пакетах, несущих полезную нагрузку.

Вторая ось — путь. Path-Congruent OAM проходит точно через те же узлы и линии, что и наблюдаемый трафик. Non-Path-Congruent такой гарантии не даёт. В определении ничего не сказано об очереди внутри узла.

Третья ось — обработка. Equal-Forwarding-Treatment означает ту же релевантную QoS, очередь, планирование и shaping. Different-Forwarding-Treatment допускает отличие.

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

Совпавший маршрут ещё не означает общую судьбу

VCCV — наглядный пример. Его сообщения идут по пути pseudowire и поэтому исторически назывались in-band. В терминах RFC 10014 это активный, path-congruent метод с возможной отличающейся обработкой. Он способен доказать доступность пути и обойти очередь, которая навредила сервису.

BFD показывает, почему отличие бывает правильным. Для быстрой фиксации отказа контрольным пакетам могут дать высший приоритет. Это полезно для liveness и convergence. Но стабильная BFD-сессия не становится доказательством малой задержки или потерь обычного класса.

Когда совпадают и путь, и обработка, возникает более сильное fate-sharing. Всё же синтетический пакет не получает автоматически размер, burst-профиль, шифрование, транспортную историю, тайм-аут и деловую семантику транзакции. Сетевой риск сужается, а результат приложения остаётся отдельным объектом проверки.

Фразе «OAM зелёный» поэтому не хватает координат: какой stream, направление, класс, эпоха, слой, домен и утверждение? Непрерывность, маршрут, loss, delay и завершение операции нельзя заменять друг другом.

Наблюдаемая совокупность задаёт предел вывода

MPLS Echo — активный пакет, построенный для проверки конкретного FEC и поведения data plane. Label stack, TTL, entropy, размер и обратный путь ограничивают вывод. Сильный результат для выбранного FEC может не представлять другой ECMP outcome или большой производственный поток.

MPLS loss/delay measurement различает Inferred Loss, считающий сгенерированные тестовые сообщения, и Direct Loss, который переносит в OAM-сообщениях счётчики пользовательского трафика. Второй метод гибридный: активная доставка пассивного наблюдения. Один процент потерь без информации о совокупности стирает важное различие.

RFC 9197 помещает поля IOAM в выбранные пакеты данных. Для них внутри домена связь с путём и обработкой сильна. Но не доказаны выбор всех пакетов, полнота экспорта, разрешение в другом домене и обработка payload приложением.

RFC 9341 чередует маркировку блоков рабочего трафика и выводит потери/задержку из счётчиков и времени в точках наблюдения. Реальный трафик — преимущество метода; определение flow, границы блоков, часы, счётчики и reordering всё равно формируют смысл.

Ни активный, ни пассивный, ни гибридный подход не является универсальным победителем. Доказательность возникает при совпадении измеренной совокупности и объекта решения.

Слой и домен обслуживания ограничивают ответственность

RFC 7276 описывает OAM как инструменты обнаружения, локализации, уведомления и контроля производительности и подчёркивает многослойность. Провайдер может измерять MPLS между PE, клиент — IP между CE, overlay и приложение — дополнительные границы.

Все результаты способны быть истинными. Здоровый core не подтверждает access, CPE, tunnel, gateway или application. Неудачный тест клиента сам по себе не локализует причину в core. Домен обслуживания ограничивает и технический вывод, и право распределять ответственность.

Нельзя терять направление: туда и обратно могут идти разные пути и очереди, а RTT складывает два распределения. Нельзя терять эпоху: результат до изменения SR policy, queue map, защиты или ПО описывает прежнюю конфигурацию. Время требует версий topology и policy.

OAM — область функций, а не единый судья

RFC 6291 закрепил Operations, Administration, and Maintenance. Operations поддерживает работу и ищет проблемы; Administration учитывает ресурсы; Maintenance обеспечивает ремонт, обновление и профилактику. Provisioning связан, но отделён.

Connectivity check не становится одновременно инвентарём, диагнозом, разрешением изменения и финальной приёмкой. Интегрированная платформа, однако, может наблюдать, интерпретировать, действовать и закрывать. Каждый переход требует отдельной ответственности.

Измерительная система отвечает за наблюдение. Service owner — за его применимость. Automation owner — за threshold и blast radius. Change authority — за разрешение действия. Outcome owner — за восстановление. Общий интерфейс не объединяет полномочия.

Минимальный контракт доказательства

Сначала фиксируются service/aggregate, источник, назначение, направление, класс, слой, домен, stream/FEC/правило выбора, версия конфигурации и forwarding epoch. Затем режим. Для выделенных пакетов path congruence и treatment отмечаются как гарантированные, ожидаемые, выборочно подтверждённые, неизвестные или разные.

Семантика включает конструкцию, размер, частоту, маркированную совокупность, counter wrap/reset, часы, синхронизацию, точки, окно, формулу, sampling, threshold, confidence и missing-data policy. Нулевые потери без знаменателя и окна непроверяемы.

Происхождение включает версии реализации и политики, идентичность/аутентификацию/целостность коллектора, configuration hash, time source, controller и correlation rule. Подлинное значение может относиться не к тому stream.

Действие отделяется от эффекта: объект, область, idempotency key, approval, commit, rollback и независимый service test. Успешный reroute при продолжающихся сбоях означает окончание автоматики, но не инцидента.