Кратко

  • Для каждого Segment List в пути-кандидате SR Policy RFC 9779 требует отдельный сеанс. Одного имени политики недостаточно, чтобы установить объект измерения.
  • При одностороннем измерении ответ может уйти вне полосы по IP/UDP; при двустороннем запрос способен указать отдельный MPLS-путь возврата. Доставка свидетельства не равна доказательству прямого пути.
  • Метки времени, счётчики и Block Number приобретают силу для SLA лишь вместе с выбором ECMP, идентичностью ответчика, правилом порога и зафиксированным действием.

Успешный ответ оставляет главный вопрос открытым

Система получила корректный пакет, вычислила задержку и показала зелёный индикатор. Но ответ пришёл по IP/UDP вне исследуемого направления MPLS. У Segment List было несколько равнозначных реализаций, а значение Entropy Label, повлиявшее на хеш, не сохранилось. Арифметика может быть точной, хотя связь результата с конкретным путём или услугой ещё не доказана.

RFC 9779, опубликованный в мае 2025 года как Proposed Standard, применяет к SR-MPLS сообщения измерения потерь и задержки из RFC 6374. Если путь-кандидат SR Policy содержит несколько Segment Lists, для каждого создаётся отдельный сеанс и отправляется запрос. Пакет несёт стек меток SR-MPLS, затем GAL и G-ACh; TTL каждой записи стека равен 255.

Это и есть техническая единица свидетельства. Запись «Policy A, 8 мс» стирает путь-кандидат, Segment List и сеанс. Чем раньше данные сведены к одному показателю, тем труднее впоследствии доказать, что именно было измерено.

Прямой путь несёт пробу, обратный — результат

В одностороннем режиме запрос может включать UDP Return Object из RFC 7876. Ответчик отправляет результат вне полосы в IP/UDP на заданные адрес и порт. Разделение сделано намеренно: доставка результата не обязана зависеть от направления MPLS, которое проверяется.

В двустороннем режиме ответчику следует по возможности использовать входящий линк или тот же путь в обратном направлении. Если нужен определённый возврат, инициатор добавляет Return Path TLV типа 5. Его под-TLV содержит стек MPLS-меток либо Binding SID; поддерживающий механизм ответчик обязан применить указанный маршрут.

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

Destination Address TLV указывает предполагаемого ответчика. Локальный адрес допускает Success, несовпадение — Invalid Destination. Раздел безопасности рассматривает и подмену обратного пути: запрос можно отбросить, если адрес назначения ответа не локален для инициатора. Проверка источника и контроль доступа дополняют эту защиту. Происхождение ответа является частью доказательства.

Счётчик должен сохранять свой интервал и направление

Для задержки используется Channel Type 0x000C. Прямой режим потерь 0x000A способен дать точный учёт, но может требовать аппаратной поддержки; выводимый режим 0x000B приблизителен. Совмещённые измерения используют 0x000D и 0x000E. Нельзя выдавать оценку за прямой счётчик, а код процедуры — за договорное решение.

Для прямых потерь принятый трафик надо отнести к верному сеансу. RFC 9779 использует Path Segment Identifier, охватывающий SR Policy, путь-кандидат или Segment List. RFC 9545 определяет PSID, а RFC 9714 — инкапсуляцию для Alternate Marking. Эти документы поддерживают идентификацию, но не отменяют необходимость хранить связь с сеансом.

Block Number TLV типа 6 сопоставляет счётчики последовательных блоков. Инициатор считает переданные пакеты, ответчик — принятые; флаг R различает направление счётчиков запроса и ответа. Номер у ответчика можно синхронизировать по LM-запросам, не синхронизируя часы.

Назначение номеров блоков RFC оставляет локальным решением. Номер связывает два набора счётчиков, но не решает, исключается ли обслуживание, представляет ли поток договорную услугу и кто вправе объявить нарушение. Измерение и оценка остаются разными уровнями.

ECMP требует узкой формулировки вывода

Segment List с Node-SID или Anycast-SID может реализоваться по нескольким ECMP-путям. RFC 9779 допускает разные Entropy Labels, чтобы влиять на хеш и измерять задержку различных путей. Измерение потерь между разными ECMP-путями прямо оставлено за рамками документа.

Одна точная выборка поэтому не описывает автоматически весь Segment List. Нужно хранить Entropy Label или эквивалентный контекст выбора, версии топологии и политики, сеанс и интервал. «Потерь нет» шире, чем доказано; «в этом блоке при данном выборе пути потерь не обнаружено» проверяемо.

Результаты могут стать расширенными TE-метриками и распространяться через OSPF, IS-IS или BGP-LS. Это вход управления, но не команда перестроить маршрут. Свежесть, доверие, порог, подавление колебаний и откат задаёт оператор.

Запись Datatracker подтверждает документ и историю стандартизации. Источники не подтверждают конкретные внедрения, поддержку поставщиков или полевые результаты. Статус стандарта нельзя превращать в недоказанное заявление об эксплуатации.