Кратко

  • Положительный PCRep подтверждает, что PCE нашёл решение для конкретного снимка TED, ограничений, целевой функции и политик. Он не подтверждает принятие результата PCC или установку на устройстве.
  • Сигнализация или программирование, резервирование ресурсов, RIB/FIB, состояние LSP, телеметрия пакетов и итог услуги требуют отдельных последующих подтверждений.

Интерфейс управления умеет превращать несколько стадий в один красивый объект. Линия на карте может быть предложением алгоритма, делегированным намерением, установленным LSP или фактическим путём трафика. Внешне она та же. Смысл меняется радикально.

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

RFC 4655, подготовленный Adrian Farrel вместе с Jean-Philippe Vasseur и Jerry Ash в рабочей группе PCE IETF, даёт для этого точный язык. PCE вычисляет маршрут по сетевому графу с применением ограничений. В варианте внешнего PCE головной узел обращается за расчётом до начала сигнализации, а PCE использует TED с учётом локальной политики.

Это не архитектура, в которой расчёт тайно означает исполнение. Исполнение показано отдельной функцией.

На какой реальности основан ответ

Traffic Engineering Database хранит сведения о топологии и ресурсах домена. Они могут поступать из расширений IGP или по внешнему каналу. PCE способен видеть всю TED, её часть или данные с задержкой.

RFC 4655 предупреждает: недостаточная синхронизация может увеличить число неудачных установок вычисленных путей и дать неоптимальные решения. Даже идеальный алгоритм не отменяет старение входных данных. Поэтому вместе с ERO важно сохранять версию и время TED.

RFC 5440, авторами которого являются Vasseur и Jean-Louis Le Roux, определяет обмен PCReq/PCRep. В запросе задаются конечные точки, полоса, приоритеты и другие атрибуты. Ограничения определяют допустимость. Целевая функция, описываемая, в частности, RFC 5541, выбирает предпочтительный вариант. Политика может влиять и на запрос, и на выдачу результата.

Если сохранить лишь готовое ERO, невозможно воспроизвести, почему именно этот путь считался правильным. Вычислительное доказательство включает вопрос, а не только ответ.

Предел положительного PCRep

В RFC 5440 положительный сценарий заканчивается после трёх действий: PCE получает запрос, успешно вычисляет путь и отправляет вычисленные пути PCC. ERO кодирует путь TE LSP и доступен для немедленной сигнализации.

Доступность для сигнализации — это граница между этапами, а не свидетельство окончания второго этапа.

При RSVP-TE далее работает процедура сигнализации и резервирования из RFC 3209. Промежуточный узел может отказать, а ресурсы могли измениться. В Segment Routing RFC 9256 различает candidate path, segment list, SR Policy на headend и трафик, направленный в эту политику. RFC 8664 переносит SR-информацию в PCEP, но не подтверждает программирование FIB и движение пакетов.

RSVP-TE и SR нельзя описывать как один механизм установки. Их объединяет лишь правило доказательства: рассчитанное представление пути ещё не является событием в плоскости данных.

Stateful PCE даёт новые сообщения, а не гарантию

Stateful PCE поддерживает синхронизацию состояния, обновления и delegation. RFC 8231 оставляет владение состоянием LSP за PCC. Атрибуты от PCE подчиняются локальной политике PCC. Делегирование даёт ограниченное право обновлять атрибуты конкретного LSP и может быть отозвано.

Дальнейшее состояние сообщает PCRpt. Если LSP стал Up или Active, PCC обязан это передать; при неудаче установки он сообщает Down и причину. В документе отдельно указано, что прямого соответствия между PCRep и PCRpt нет, а за одним ответом вычисления могут следовать несколько отчётов о состоянии.

Тем самым протокол различает знание вычислителя и знание владельца состояния. RFC 8281 позволяет PCE инициировать LSP, но инициатива всё равно должна пройти политику, возможности устройства и фактическое исполнение.

Ступени операционного подтверждения

Сначала PCC принимает или отклоняет результат. Затем запускается сигнализация либо программирование. После этого проверяются резервирование, RIB и FIB. Только счётчики, probes, трассировка и flow telemetry показывают реальные пакеты. Измерения потерь, задержки, джиттера и доступности за определённый период отвечают на вопрос об услуге или SLA.

Запись RIB не равна записи FIB. Запись FIB не равна наблюдавшемуся трафику. Одно наблюдение трафика не равно SLA. Каждая ступень сильнее предыдущей только в отношении собственного вопроса.

Это видно и в эксплуатации. Документация Juniper по PCEP говорит, что PCC заново сигнализирует LSP после получения атрибутов PCE, и предлагает отдельные команды для сессии, LSP, SPRING-TE и маршрутов. Руководство Paragon разбирает ситуацию, когда сервер подтвердил заказ, но LSP остаётся Down, поскольку PCC не может его сигнализировать. Это пример одной реализации, однако он наглядно отделяет контрольное подтверждение от рабочего состояния.

Точная роль Farrel

Публичный профиль Farrel в IETF охватывает множество RFC и ролей. Для этой темы важен совместный вклад в RFC 4655: Farrel, Vasseur и Ash сформулировали архитектуру, в которой вычисление, информация, политика и сигнализация остаются различимыми. Базовый PCEP написали Vasseur и Le Roux. Stateful-расширения, инициирование LSP и SR-поддержку развивали другие авторы и рабочая группа. Реализации и эксплуатационные подтверждения принадлежат инженерам и операторам.

Такое распределение заслуг усиливает, а не уменьшает оценку Farrel. Оно не позволяет принять один документ за всю систему — так же, как ERO нельзя принять за работающую услугу.

Источники