Кратко

  • В RFC 3084 всё содержимое сообщения DEC в COPS-PR считалось единой транзакцией: либо PEP применял все удаления и установки, либо сообщал о неудаче и возвращался к последнему успешному состоянию.
  • Успешный RPT завершал конкретную операцию, но не гарантировал вечного совпадения. При разрыве устройство продолжало использовать кэшированный Request-State; после восстановления связи требовалась синхронизация либо допущение, что обе стороны сохранили одно и то же.

Правило становилось реальностью в другой машине

PDP помещает в одно DEC удаление старого фильтра и установку нового. TCP доставляет байты, PEP отвечает Success. У сервера появляется не только запись об отправке: точка применения утверждает, что выполнила транзакцию.

Но область такого свидетельства ограничена. PEP ещё должен преобразовать экземпляры PIB в локальные очереди, классификаторы и планировщики. RPT не является трассировкой пакета и не доказывает, что приложение получило ожидаемую услугу. Он подтверждает действие на границе enforcement point, а не весь конечный результат.

Опубликованная в марте 2001 года RFC 3084 определила COPS-PR — применение Common Open Policy Service для provisioning. Policy Decision Point передавал данные Policy Enforcement Point. Policy Information Base задавала классы и экземпляры: PRI была экземпляром, PRID — его идентификатором. Механизм мог обслуживать QoS, безопасность и другие области, не навязывая им одну модель политики.

Это отличается от уже опубликованного материала о RFC 3060. PCIM отделяла общую информационную схему от локального алгоритма оценки. COPS-PR решала следующий вопрос: как понятное решение установить, подтвердить, сохранить во время сбоя и снова согласовать с сервером.

Атомарность защищала замену от половинчатого результата

Одно DEC могло содержать несколько решений. Удаления шли перед установками, чтобы определить приоритет внутри транзакции, а не создать две независимые временные фазы. Всё сообщение должно было завершиться одним результатом. Если хотя бы часть не устанавливалась, PEP отправлял Failure и возвращал состояние последней успешной DEC.

Так старая политика не исчезала без работоспособной замены. Каждый DEC требовал solicited RPT, включая пустое решение. Протокол сохранял различие между намерением PDP и заявленным результатом PEP.

RFC также показала предел отката. При немедленном solicited failure существовала ясная предыдущая точка. Ранее успешно установленная конфигурация могла сломаться позже и породить unsolicited failure. После асинхронных изменений правильное состояние для возврата уже могло стать неоднозначным. Сообщить об отказе было возможно, восстановить прошлое — не всегда.

Несовпадение версий зависело от направления

В PIB могли появляться новые классы. Если новый PDP отправлял неизвестную PRC старому PEP, устройство обязано было вернуть ошибку и восстановить предыдущее хорошее состояние. Если новым был PEP, а старым PDP, экземпляры нового класса просто не поступали. Для устаревших классов существовали другие правила игнорирования.

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

COPS-PR также устраняла конкурирующих авторов. Для области, определённой Client-Type, конфигурацию обновлял один сервер. Пока PEP был соединён с PDP, политика фактически блокировалась даже для локальной консоли. Это упрощало полномочия, но делало идентичность PDP, соединение и сохранённое состояние частью контура управления.

Во время молчания полномочия переходили к кэшу

После потери связи PEP пытался подключиться к последнему PDP, затем к настроенному резервному. Пока соединения не было, активный Request-State продолжал применяться. При возврате LastPDPAddr показывал, чьи решения ещё находятся в кэше. PDP мог потребовать синхронизацию сообщением SSQ.

Тогда PEP повторно выдавал REQ для всех известных Request-States. PDP посылал удаления отдельных PRID или префиксов, чтобы прийти к известному согласованному состоянию. Если синхронизация не запрашивалась, клиент мог предположить, что сервер его узнал и считает текущий кэш верным. Это правило работы, а не независимая проверка совпадения.

Локальные изменения, которые невозможно было сообщить во время разрыва, всё равно требовали последующего отчёта. Если связь не восстанавливалась в административно заданный срок, PEP удалял установленные Request-States, а PDP отдельно завершал срок своих записей. Два таймера ограничивали осиротевшую политику, но не доказывали одновременное удаление.

Позже SPPI и дополнительные PIB расширили систему моделями QoS, общего каркаса и обратной связи об использовании. В 2016 году IETF перевела RFC 3084 и связанные документы в Historic, сославшись на ограниченное внедрение и переход конфигурационного управления к NETCONF и YANG. Это свидетельство направления стандартов, а не доказательство полного отсутствия или исчезновения реализаций.

Главный исторический урок — не смешивать звенья доказательств. Намерение PDP, атомарная DEC, RPT, кэш, повторная синхронизация, локальная конфигурация и поведение трафика связаны, но не равны. Надёжная доставка переносит правило; только сверка и наблюдение показывают, какое правило устройство сохранило.

Источники

  1. https://www.rfc-editor.org/info/rfc3084
  2. https://www.rfc-editor.org/rfc/rfc3084.html
  3. https://datatracker.ietf.org/doc/rfc3084/
  4. https://www.rfc-editor.org/errata/rfc3084
  5. https://www.rfc-editor.org/rfc/rfc2748.html
  6. https://www.rfc-editor.org/rfc/rfc2753.html
  7. https://www.rfc-editor.org/rfc/rfc3159.html
  8. https://www.rfc-editor.org/rfc/rfc3198.html
  9. https://www.rfc-editor.org/rfc/rfc3317.html
  10. https://www.rfc-editor.org/rfc/rfc3318.html
  11. https://www.rfc-editor.org/rfc/rfc3483.html
  12. https://datatracker.ietf.org/doc/status-change-copspr-sppi-to-historic/
  13. https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
  14. https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/