Кратко

  • RFC 3317 предлагал устройству DiffServ до установки политики сообщить поддерживаемые функции, направление, пределы очередей и планировщиков, глубину цепочки и допустимые связи между элементами.
  • Отчёт о возможностях был ориентиром, а не гарантией: полный граф всё равно мог оказаться невыполнимым и требовал явного отказа PEP; сохранённая конфигурация не доказывала обработку пакетов.

RFC 3317 удобно читать с конца его истории. В 2016 году IESG перевёл документ и связанную семью COPS-PR/SPPI в статус Historic, сославшись на ограниченное внедрение и переход работ по управлению к NETCONF и YANG. Поэтому детальность 96-страничной спецификации нельзя принимать за свидетельство массовой практики. Зато она точно показывает, какую границу пытались выразить разработчики начала 2000-х.

Граница проходила между намерением политики и возможностями конкретного класса устройств. Differentiated Services сортирует пакеты, измеряет поток, применяет маркировку или другое действие, использует алгоритм отбрасывания, ставит трафик в очередь и отдаёт планировщику. RFC 3317 описывал эти функции через классы Policy Information Base и их экземпляры, которые Policy Decision Point мог передавать Policy Enforcement Point.

Последовательность имела структуру: classifier, meter, action, algorithmic dropper, queue, scheduler. Если обработке требовалось вернуться к более раннему типу, моделировался следующий Traffic Conditioning Block. Ссылки Next задавали продолжение, а результаты классификации и измерения создавали ветви. Получался направленный граф, хотя формально он хранился в таблицах.

Параметры отделялись от связей. Счётчик мог ссылаться на строку token bucket с rate и burst, планировщик — на минимальные и максимальные скорости. Одни параметры использовались повторно, новые конкретные типы могли появляться в других PIB. Но корректность строк и ссылок не означала, что весь граф помещается в аппаратную конвейерную обработку.

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

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

Получив сведения, PDP строил политику для административного домена, типа интерфейса, роли и направления. Строка data path указывала первый элемент. Отсутствие строки или zeroDotZero означало обычную IP-обработку. Модель работала с типами интерфейсов, а не с каждой физической портовой реализацией, и тем самым сознательно оставляла часть местных различий за пределами описания.

RFC 3317 прямо предупреждал, что capability classes дают общие ориентиры и не перечисляют все возможные или невозможные конфигурации. Общий буфер, внутренний процессор или сочетание двух допустимых функций могли нарушить план. Если PEP получал политику, которую не способен реализовать, он должен был отправить PDP отчёт об ошибке. Отказ был не опровержением отчёта о возможностях, а его необходимым дополнением.

Из этого следуют разные уровни доказательства. Capability report фиксирует общее заявление устройства. Скомпилированный граф фиксирует намерение контроллера. Ответ COPS-PR фиксирует результат транзакции. Чтение состояния показывает сохранённые строки. Только наблюдение в data plane может подтвердить прохождение ожидаемых стадий, а пользовательский эффект требует отдельной оценки качества.

Оба направления обмена раскрывали чувствительные сведения. Устанавливаемые строки могли содержать смысл клиентских контрактов или фильтров и при подмене менять распределение ресурсов. Уведомления о возможностях раскрывали характеристики устройства. RFC ссылался на IPsec между PDP и PEP: ложный capability report способен направить построение по неверному пути, а ложная policy — изменить приоритеты и полосу.

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

Устройство должно сначала сузить пространство допустимых графов, а затем сохранить право окончательного отказа. Первая ступень делает планирование разумным; вторая признаёт неполноту модели. Историческая ошибка начинается тогда, когда один из этих документов превращают в доказательство следующего: «может в общем» становится «выполнит эту комбинацию», а «принял конфигурацию» — «обеспечил услугу».

Источники: RFC 3317, RFC 3318, RFC 3290, RFC 3084, RFC 3159, RFC 2475 и решение IESG 2016 года о смене статуса.