Кратко

  • Возможность, синхронизированное состояние, PCUpd и PCInitiate — разные типы протокольных фактов; ни один из них сам по себе не подтверждает достигнутый контроль или сервисный эффект.
  • PCC может делегировать PCE обновление заданных атрибутов LSP, но сохраняет собственность на состояние, локальную политику и право отозвать делегирование.

В эксплуатационном отчёте слово «делегирован» легко становится заменой нескольких отсутствующих записей. Если PCE получил состояние LSP или отправил запрос, возникает соблазн сказать, что сеть уже управляется PCE. Такая фраза смешивает намерение, разрешение, действие оборудования и результат для трафика — именно те поверхности, которые протокол оставляет раздельными.

RFC 9504 переносит stateful PCEP в GMPLS-контролируемую среду. PCC и PCE могут согласовывать возможности, синхронизировать данные LSP, запрашивать обновление атрибутов и инициировать установление LSP. Это позволяет точно установить, кто и что сообщил либо запросил. Но точность записи не создаёт факта, который запись не наблюдала.

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

Второй предел — владение состоянием. RFC 8231 требует, чтобы stateful PCE узнал состояние LSP у PCC до вычисления или обновления атрибутов. State Report сообщает об изменении, Update Request просит его выполнить. Делегирование даёт PCE право обновлять атрибуты определённых LSP, пока оно действует. Но владельцем состояния остаётся PCC; атрибуты подчиняются его локальной политике, и PCC может отозвать делегирование. Следовательно, делегирование — это не передача сети, а управляемая и обратимая область действий над записью.

PCInitiate не отменяет эту границу. RFC 8281 называет PCE-initiated LSP LSP, инстанцированным вследствие запроса PCE; сообщение побуждает конечный узел настроить LSP. Запрос доказывает, что запрос был направлен. Он не доказывает принятие конечным узлом, резервирование ресурса, настройку cross-connect, установленный forwarding state или перенос трафика. Даже различение предполагаемого и фактического пути в отчётах RFC 9504 не является само по себе измерением доступности сервиса или выполнения SLA.

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

Такой подход согласуется с тезисом Heng Lu о минимальной начальной спецификации: общий слой должен фиксировать минимально совместимый факт, оставляя принятие и последствия локальному субъекту. Работающий код важен как доказательство работоспособности механизма. Он не меняет того, кто принял риск и кто может отменить действие.

Вместо вопроса «контролирует ли PCE сеть?» оператору стоит спросить: какие атрибуты какого LSP делегированы каким PCC, какая политика применяется и какие записи связывают запрос с наблюдаемым эффектом? Этот вопрос не ограничивает автоматизацию; он не позволяет ей выдавать запрос за полномочие, а полномочие — за итог.

Источники