Кратко

  • draft-ietf-mpls-frr-ext-00 позволяет входному узлу защищаемого RSVP-TE LSP запросить цели оптимизации и жёсткие границы метрик у точек локального ремонта, рассчитывающих резервные LSP. PLR устанавливает FRR_EXT protection, если выполняет запрос, и может перейти к локальной политике без флага, если требования невыполнимы.
  • Флаг даёт общий краткий ответ, но не происхождение решения. Для каждого PLR нужна запись, связывающая точный запрос, поддержку функции, причину перехода, версию политики, источник и возраст метрик, контекст расчёта, полученный резерв и последующие проверки.

Ноль не равен диагнозу

Представим защищаемый LSP с четырьмя Points of Local Repair. Входной узел просит каждый PLR минимизировать среднюю задержку, удержать суммарную задержку ниже заданной границы и не использовать канал с чрезмерной вариацией задержки. В ответе Resv три точки устанавливают новый признак, четвёртая — нет.

Если система мониторинга показывает четвёртую точку красным, оператор легко прочитает это как отсутствие защиты. Проект такого вывода не поддерживает. Узел мог не распознать FAST_REROUTE_EXT, проигнорировать его по правилу совместимости и рассчитать резерв локально. Он мог распознать объект, но не найти путь, удовлетворяющий всем жёстким границам, а затем применить собственную политику. Наконец, явного расширенного запроса могло не быть: решение изначально оставили PLR.

Резервный путь возможен во всех трёх случаях. Различаются полномочия, причина и нужное действие. Делегирование требует оценки политики. Неподдерживаемая функция — инвентаризации и плана обновления. Невыполнимое ограничение — проверки топологии, данных и самого порога.

Короткий протокольный признак не обязан переносить всё объяснение. Но эксплуатационная система обязана не выдавать его краткость за полноту знания.

Новый документ рабочей группы, а не готовый стандарт

Первая версия под именем рабочей группы, draft-ietf-mpls-frr-ext-00, датирована 23 августа 2026 года. Datatracker показывает Signaling Optimization Objective and Bounded Metrics for MPLS Fast Reroute Backup LSP Tunnels как активный документ MPLS WG с состоянием IESG I-D Exists. В заголовке указан Standards Track и срок действия до 24 февраля 2027 года. Это не RFC, не решение IESG и не подтверждение внедрения.

Предшественником был draft-deshmukh-mpls-frr-ext-02. 18 августа председатель MPLS зафиксировал принятие прежнего проекта рабочей группой и попросил переиздать его как draft-ietf. Объявление от 23 августа подтверждает, что версия 00 стала предметом работы группы. Принятие определяет коллективную площадку доработки, но не окончательный результат.

Техническая основа — RFC 4090. Он определяет локальный быстрый ремонт RSVP-TE LSP и объект FAST_REROUTE, который несёт приоритеты, аффинити, предел числа переходов и полосу. Новый проект добавляет сопутствующий TLV-объект FAST_REROUTE_EXT для целей оптимизации и ограниченных метрик.

Входной узел может потребовать наследовать цели и границы защищаемого LSP либо задать другие. Если явной конфигурации нет, цели и границы определяет локальная политика PLR. Центр формулирует намерение, однако вычислительная власть остаётся распределённой.

Цель выбирает лучшее, граница отсекает недопустимое

Среди целей оптимизации предусмотрены IGP- и TE-метрика, незарезервированная полоса, минимальная, средняя и максимальная задержка. Стоимость и задержка минимизируются, свободная полоса максимизируется. Можно передать несколько разных целей с весами для нормализации.

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

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

Критерии выбора целей и границ проект сознательно оставляет за пределами спецификации. Вес не раскрывает целиком метод приведения разных единиц. Это сохраняет свободу операторов, но переносит доказательство смысла в их локальные процессы.

Разные пути к локальному решению

Первый путь — запланированное делегирование. Расширенного требования нет, местная политика правомерно принимает решение.

Второй — совместимость. PLR не знает новый объект, поэтому игнорирует его и передаёт дальше без изменений. Резерв рассчитывается локально. Для объяснения нужен зафиксированный на тот момент набор функций и версия узла.

Третий — осознанный откат. PLR понимает объект и применяет границы как жёсткие условия, но не находит подходящего пути. Проект разрешает вернуться к локальным целям и границам; в таком случае FRR_EXT protection в соответствующем подобъекте RRO ответа Resv устанавливаться не должен. Здесь важны и исходный запрос, и выбранная замена.

Есть также структурная ошибка. Если способный PLR получает FAST_REROUTE_EXT без сопутствующего FAST_REROUTE, он должен отвергнуть Path с Policy Control Failure. Это дефект формирования запроса, а не обычная локальная автономия.

Сводить результаты в один статус «FRR не выполнен» опасно. Организация может обновлять оборудование там, где нужно изменить предел, или ослаблять правило там, где отправитель создал неверное сообщение.

Установленный флаг тоже не обещает будущее

Выполнив полученные цели и границы, PLR обязан установить новый флаг в RRO. Входной узел может проверить каждую точку ремонта отдельно, а не принимать успешное резервирование за единообразное соблюдение требований. Это ценный шаг.

Но свидетельство узко: PLR утверждает, что в момент сигнализации рассчитал резерв, удовлетворяющий запросу. Флаг не называет поколение TE-базы, возраст измерений, версию алгоритма, отброшенные варианты и способ нормализации. После изменения нагрузки, резервов или топологии он не становится постоянной гарантией.

Он не подтверждает реальное переключение. RFC 4090 заранее готовит локальные пути для быстрой реакции на отказ. Успешный Resv не доказывает, что детектор сработает верно, состояние осталось в оборудовании, основной и резервный пути не разделяют физическую причину отказа, в нужный момент хватит полосы или сквозная услуга выполнит SLA.

Криптографическая аутентификация RSVP защищает целостность сообщения. Она не обновляет устаревшую метрику и не объясняет полномочия локального правила. Подлинность сообщения, качество данных и обоснование решения — разные доказательства.

У числа есть источник и время

RFC 7471 и RFC 7810 задают расширения метрик инженерии трафика для OSPF и IS-IS, включая показатели задержки. PLR может использовать построенную на них TE-базу, статическую конфигурацию или иной локальный источник. Проект FRR не выбирает универсальный авторитет.

Среднее, измеренное несколько секунд назад, и проектное значение многомесячной давности выглядят одинаково как число. Незарезервированная полоса зависит от класса, состояния резервов и частоты обновления. При нескольких целях нормализация определяет, как сравниваются разные единицы; один переданный вес не сохраняет формулу и версию.

Поэтому запись «граница 20, флаг 0» не отвечает, почему выбрали резерв. Нужны источник, единица, время наблюдения, эпоха топологии, реализация расчёта и политика, получившая власть.

Запись о происхождении ограничений для каждого PLR

Daniel Kade предлагает внутреннюю запись, индексированную защищаемым LSP и точкой ремонта. Это не дополнение к протоколу и не требование IETF.

Сначала фиксируются личности: сессия, входной узел, PLR, защищаемый ресурс и точка слияния. Сохраняются точные отпечатки FAST_REROUTE и FAST_REROUTE_EXT, все типы метрик, веса, значения, границы и охват. Отмечаются поддержка, результат разбора, наличие базового объекта и сведения Resv/RRO.

Если флага нет, причина не угадывается по биту. Записывается наблюдаемая категория: отсутствие явного запроса, неподдерживаемое расширение, невыполненная жёсткая граница или иной подтверждённый случай. Рядом указываются локальная политика и её версия, владелец исключения, срок и условие пересмотра.

Контекст расчёта включает источник, единицу и время каждой метрики, эпоху топологии или TE-базы, предел устаревания, нормализацию, версию вычислителя и полученный резервный путь. Если заявляется разнесение по риску, сохраняются реально проверенные данные о совместных группах риска; логически иной маршрут не равен физической независимости.

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

Доступ к записи может быть ограничен операционным кругом. Она не раскрывает топологию и не навязывает всем PLR единый алгоритм, а делает местный выбор проверяемым для ответственных лиц.

Общее минимальное сообщение и достаточная локальная память

Новый флаг полезен как минимальный общий язык. Входной узел формирует структурированное требование, а каждый PLR отвечает в известном месте. Совместимость не требует одинаковой внутренней политики.

Проблема возникает, когда минимум становится пределом сохранённого знания. Единица говорит о выполнении в определённый момент. Отсутствие флага объединяет несколько путей к локальной власти. Организация должна дополнить их версией правила, временем данных, владельцем, сроком действия и дорогой назад.

Выбор лежит не между центральным приказом и местной свободой. Он лежит между непрозрачной и объяснимой свободой. Документированный откат сохраняет защиту в переходный период и не даёт забыть, какая политика победила.

Источники