Кратко

  • RFC 9730 не заменяет распределённый GMPLS централизованным управлением и не делает обратного: сетевые элементы по-прежнему могут обнаруживать ресурсы, строить локальную топологию, вычислять маршруты по своей политике и устанавливать LSP через RSVP-TE, тогда как контроллеры могут координировать домены, выбирать или предварительно вычислять путь и поручать входному узлу его развернуть.
  • При отказе «контроллер принял команду», «домен создал LSP», «локальная защита переключила трафик» и «клиентский сервис восстановлен» — четыре разных утверждения. Каждому соответствует своя цепочка телеметрии, временных меток и подтверждений; RFC 9730 не задаёт единого продукта мониторинга, универсального предела свежести или готового формата такого доказательства.

Не один контур управления, а несколько сопряжённых контуров

RFC 9730, опубликованный IETF в марте 2025 года как Informational под названием Interworking of GMPLS Control and Centralized Controller Systems, описывает совместную работу двух подходов. В распределённом GMPLS сетевой элемент может собирать сведения о состоянии узлов и каналов, строить собственное представление топологии, вычислять маршрут с учётом локальной политики и через RSVP-TE выполнять покадровую — точнее, hop-by-hop — установку меток и состояния LSP.

Централизованная система добавляет другой масштаб принятия решений. Она может иметь более широкий обзор, сопоставлять запрос услуги с доступными ресурсами, выполнять расчёт через несколько доменов и передавать входному узлу уже выбранный путь. В таком сценарии контроллер не обязан программировать каждый промежуточный элемент. RFC 9730 допускает, например, запрос к ingress через PCInitiate или NETCONF, после чего RSVP-TE работает между сетевыми элементами и создаёт состояние по маршруту.

Это различие существенно для операционной ответственности. Команда контроллера может быть логически корректной, но её выполнение зависит от того, что знает входной узел, что допускает локальная политика, какие ресурсы доступны в момент сигнализации и как промежуточные элементы применяют метки и кросс-соединения. Обратная ситуация тоже возможна: домен успешно поддерживает или восстанавливает LSP локально, хотя верхний контроллер ещё не обновил свою модель.

ACTN: координация поверх доменов без обязательной полной видимости

RFC 8453 помещает Multi-Domain Service Coordinator, MDSC, между запросами Customer Network Controller и ресурсами Provisioning Network Controller. MDSC отображает и переводит сервисные требования, координирует несколько доменов и работает с абстракцией. PNC, в свою очередь, конфигурирует и наблюдает сетевые элементы и может публиковать вверх как сырую, так и абстрагированную топологию.

По MPI передаются запросы связности или изменения полосы, а также представления ресурсов, отфильтрованные политикой. Поэтому «глобальный граф» многодоменной сети не означает полного знания внутренних связей каждого домена. MDSC может видеть, какие виртуализированные или агрегированные возможности предоставляет домен, не зная его точной внутренней структуры.

Для старших операторов это важная граница интерпретации. Централизованный расчёт может быть глобальным по охвату и одновременно намеренно неполным по деталям. Если домен скрывает внутренние ограничения, верхний уровень способен корректно выбрать последовательность доменов и всё же столкнуться с отказом внутри одного из них. Сам по себе такой результат не доказывает, что централизованное вычисление ошибочно, как не доказывает и обратное — что локальная сигнализация неисправна.

Где на самом деле вычисляется путь

В архитектуре нет единственной обязательной точки вычисления. Маршрут может быть рассчитан контроллером, входным узлом на основе его Traffic Engineering Database или PCE. Классический PCE возвращает путь PCC, который сам решает, использовать ли его и когда развернуть. В режиме PCE-initiated инициатива может сместиться: PCE способен запускать создание, сопровождение и удаление LSP.

Из-за этого формулировка «маршрут рассчитан» всегда требует контекста. Нужно знать, кто выполнял вычисление, какое представление топологии использовалось и кто обладал полномочием на развертывание. Путь, найденный MDSC по абстрактной междоменной модели, отличается по смыслу от пути, найденного ingress по локальному TED, хотя оба могут привести к одному и тому же рабочему LSP.

В многодоменном случае установка также неоднородна. Возможны сквозной RSVP-TE, сшитые доменные LSP или отдельные сегменты. Междоменные метки могут выделяться пограничными узлами или контроллерами. Поэтому единое пользовательское соединение может опираться на несколько независимых цепочек состояния и несколько административных областей, каждая из которых подтверждает только свою часть.

Свежесть состояния — свойство цепочки, а не флаг

RFC 9730 допускает, что сетевые элементы и контроллеры располагают сырым, сокращённым или абстрагированным состоянием, причём на разных временных шкалах. Документ не задаёт универсального предела свежести. Для практики это означает, что слово «актуальная топология» без уточнения недостаточно.

Состояние проходит по цепочке: обнаружение или локальное событие, публикация, транспорт, обработка, фильтрация, хранение, возможная абстракция, затем чтение алгоритмом вычисления. Даже если PNC быстро принимает информацию от NEs, MDSC может получить агрегированное представление позже. Даже если MDSC уже обновился, ingress может продолжать опираться на собственный TED. И наоборот, локальный узел может раньше всех знать о потере ресурса.

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

Защита и восстановление: локальная скорость и более широкий пересчёт

Для span protection RFC 9730 не вводит нового требования. Централизованная система может заранее вычислить непересекающиеся рабочий и защитный пути, но фактическое быстрое переключение может выполняться локальным APS или механизмами GMPLS Notify. Это естественное разделение: широкий расчёт и локальная реакция не обязаны работать на одной временной шкале.

Контроллер также может обновлять альтернативу для одного домена. Однако свежесть такого запасного пути зависит от скорости отчётности, обработки, хранения и состояния head-end. Наличие «предрассчитанного» маршрута не означает, что ресурс в нём гарантированно свободен в момент отказа.

Многодоменный отказ усиливает эту разницу. GMPLS-домен может сначала попытаться выполнить сегментное перенаправление. Если локальных ресурсов недостаточно или отказал междоменный канал, результат поднимается через Controller(G) к MDSC. Тогда MDSC может рассчитать и инициировать альтернативу через несколько доменов, в том числе включив новый домен. Это уже не просто локальная защита, а переход ответственности от быстрого доменного механизма к более широкому координатору.

RFC 4873 дополнительно допускает, что ветвь или Point of Local Repair создаёт независимый recovery LSP к merge node. При динамическом выборе branch и merge часть решения остаётся локальной; если восстановление невозможно, об этом нужно сообщить. Такой механизм показывает, почему «централизованный контроллер управляет восстановлением» — слишком неточная фраза. Контроллер может определить политику, вычислить путь или запустить процедуру, но конкретное переключение в точке ремонта выполняет сетевой элемент.

Быстрое перенаправление распадается на три действия

Удобная операционная модель — разделить fast reroute на вычисление, создание и обнаружение/переключение. Контроллер или PCE может вычислить обходной путь. RSVP-TE может создать и поддерживать detour или bypass. PLR локально обнаруживает проблему и переключает трафик.

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

RFC 4426 различает span, segment и end-to-end recovery и допускает одновременную работу нескольких уровней. Это добавляет ещё одну осторожность: параллельные механизмы могут взаимодействовать через preemption и reversion. Восстановление одного сервиса может изменить доступность ресурсов для другого, а возврат на основной путь способен создать дополнительный переходный период. Поэтому измерять только момент первого восстановления недостаточно; нужен также след того, что произошло после него.

Что считать доказательством успешного восстановления

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

На доменном уровне нужны сырой TED или результат локальной политики в той мере, в какой его можно зафиксировать, получение PCInitiate или NETCONF, сообщения RSVP Path/Resv либо ошибки, программирование метки и кросс-соединения, а также состояние, эквивалентное отчёту PCRpt, если оно доступно в используемой реализации.

Для локального восстановления важны временная метка детектирования, идентификация PLR или branch/merge, защищаемый участок, состояние detour или bypass, момент фактического переключения, уведомления о нехватке ресурсов и последующие preemption или reversion.

Но даже полный набор этих признаков не доказывает пользовательский результат. Финальная граница — endpoint reachability, наблюдаемая производительность и свидетельство выполнения SLO на клиентской стороне услуги. Успешный RSVP Resv подтверждает состояние сигнализации. Подтверждение кросс-соединения говорит о программировании узла. Переключение PLR подтверждает локальную защиту. Только наблюдение на сервисной границе показывает, восстановилась ли услуга в требуемом качестве.

Отказ контроллера: что должно продолжать жить

RFC 9730 исходит из того, что уже существующие услуги и заранее созданная защита должны продолжать работать, когда контроллер недоступен. Для такой архитектуры желательны резервирование и backup-функции сетевых элементов. Это не требование, что любой новый сервис должен создаваться без контроллера; скорее, граница ответственности проходит между сохранением уже запрограммированного состояния и способностью выполнять новые глобальные решения.

Оператору следует различать по крайней мере три режима: контроллер недоступен, но существующие LSP и защита работают; контроллер недоступен, а локальный домен способен выполнять часть восстановления; и случай, когда для нового междоменного пути действительно требуется MDSC или иной верхний координатор. Их нельзя объединять в общий индикатор «control plane up/down».

Безопасность следует за полномочиями

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

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

Здесь важно не расширять область RFC 9730 за её пределы. RFC 9731 о VN YANG, RFC 9732 о разделении ресурсов NRP и RFC 9889 о реализации 5G slice не являются спецификациями восстановления RFC 9730. Они могут быть рядом в архитектуре, но доказывают другие свойства. Точно так же RFC 9730 не определяет единый телеметрический продукт, целевой показатель сходимости или универсальный формат доказательства, а часть негmpls-механизмов восстановления лежит вне его области.

Практический вывод

Смысл RFC 9730 для оператора не в выборе «централизованного» или «распределённого» лагеря. Он в более точном разделении действий. Глобальный контроллер может видеть междоменную задачу и выбирать подходящий путь; PNC может переводить её в возможности домена; ingress может инициировать сигнализацию; RSVP-TE — создавать состояние; PLR — переключить трафик; MDSC — подключиться, когда локальный ремонт не справляется.

Чем сложнее сеть, тем менее полезно одно итоговое сообщение «reroute successful». Инженерной и управленческой ценностью обладает связанная последовательность доказательств, в которой видно, кто что знал, какое решение принял, когда оно было принято, где оно было реализовано и что в итоге увидел клиент.

Источники

Проверено 2026-09-14: соответствующих errata для RFC 9730 не найдено.