Кратко

  • RFC 3060 стандартизировала повторно используемую информационную модель политик — группы, правила, условия, действия и связи между ними. Алгоритм, превращающий эти атрибуты в результат, авторы явно оставили на усмотрение реализаций.
  • Модель позволяла задавать приоритеты и отмечать обязательный или рекомендуемый порядок действий, но от этого не становилась общей средой исполнения. RFC 3460 позднее изменила модель и добавила стратегии принятия решений; ни один из документов не доказывает, что разные устройства одинаково применяли политики.

Правило может переноситься, его смысл — не обязательно

Файл политики может выглядеть переносимым, но приводить к разному поведению на границе сети. Два устройства получат условия и действия с одинаковыми именами, однако будут опираться на разные локальные возможности, расширения или процедуры оценки. Именно это различие лежит в основе RFC 3060 — первой версии модели Policy Core Information Model (PCIM), опубликованной в феврале 2001 года.

PCIM описывала структуру информации. Классы представляли элементы политики, а классы ассоциаций показывали, как связаны их экземпляры. PolicyRule соединяла условия с действиями. PolicyGroups объединяли правила или другие группы; правила могли иметь приоритет. Условия можно было записывать как «ИЛИ» над выражениями «И» либо как «И» над выражениями «ИЛИ», в том числе с отрицанием отдельных утверждений. Это давало разработчикам общий способ описать назначение правила и условия его применения.

Но схема не обязательно была тем местом, где сеть принимала решение. RFC отделяла информационную модель от алгоритма её интерпретации. Собственный пример документа показывает суть: общее правило могло назначить трафику инженерного отдела обслуживание Bronze, а исключение с более высоким приоритетом — Gold для конкретного инженера. Модель позволяла задать пересечение и приоритет. Конкретной реализации всё равно предстояло оценить условия, определить действующий порядок и преобразовать выбранное действие в поведение конкретного устройства.

«Декларативная» модель с сознательно оставленным пробелом

RFC 3060 называет свой подход декларативным, но сразу уточняет смысл этого слова. Модель определяет сущности и атрибуты; она не задаёт ни алгоритм получения результата из этих атрибутов, ни явную последовательность шагов обработки. Желаемый порядок действий можно обозначить как обязательный или рекомендуемый, но процедура оценки остаётся за рамками общей информационной модели.

Это аккуратно очерченная граница, а не свидетельство существования универсальной среды исполнения. Заявление вроде «если условие C истинно, применить действие A» требует конкретных определений C и A. Нужна и обработка отсутствующих или неподдерживаемых атрибутов, конфликтующих политик, локальных исключений и различий в возможностях устройств. PCIM предусматривала точки расширения, включая классы условий и действий, специфичные для поставщика. Это делало модель адаптируемой, но позволяло локальной семантике различаться даже при общем базовом формате.

Авторы описали компромисс: представление должно было быть понятным людям и удобным для диагностики, но при этом посильным для обработки на широком спектре устройств. Коллективный опыт управления политиками тогда оставался ограниченным, отмечала сама RFC. Вместо исчерпывающего языка на все случаи авторы предпочли общее ядро для актуальных тогда задач, например VPN и QoS, и возможность развивать модель вместе с требованиями и опытом.

Документ также связывал PCIM с совместной работой рабочей группы IETF Policy Framework и проекта DMTF Common Information Model. Последующие документы должны были сопоставить абстрактную информационную модель с конкретными реализациями; в качестве примера приводился каталог на основе LDAPv3. Это важная оговорка: модель была входом для возможного пути реализации, но не доказательством того, что её принял какой-либо определённый каталог, сервер политик или маршрутизатор.

У соседних частей архитектуры были другие задачи

Более ранняя структура управления допуском на основе политик в RFC 2753 разделяла точку принятия решения (PDP), где решение формировалось, и точку применения политики (PEP), где оно воздействовало на сетевой элемент. Затем RFC 2748 определила COPS как протокол обмена запросами и решениями между этими ролями. RFC 3084 описала вариант использования COPS для предоставления баз политической информации. Это соседние уровни, но не одно и то же с PCIM: транспортный протокол, модель предоставления данных и информационная схема отвечают на разные вопросы.

Такое разделение выявляет и проблему измерения. Каталог может содержать правило; PDP — оценить его; PEP — получить решение; маршрутизатор — установить конфигурацию. Каждое действие — отдельное событие. Наличие похожего на PCIM объекта в хранилище не показывает, какую версию политики использовало устройство, поняла ли точка решения расширение, приняла ли решение точка применения и получили ли пакеты ожидаемую обработку.

Следующая редакция изменила модель, но не стандарт доказательств

В январе 2003 года RFC 3460 обновила PCIM. Она добавила элементы, объявила некоторые устаревшими и заменила их, изменила представление приоритетов и ввела стратегии принятия решений, задаваемые администратором. Это было реальное развитие информационной модели. Оно также показало, что прежний словарь не застыл: последующие документы могли пересмотреть способы описания наборов правил и вариантов их оценки.

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

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

Из этого следует практический урок — требовать свидетельства по всей цепочке. Какая схема и какие расширения применялись? Какую версию политики оценивала точка решения? Какой алгоритм разрешал пересечения и приоритеты? Что установила точка применения? Что сеть сделала на самом деле? Совместимое описание политики может быть полезным, но оно не служит подтверждением совместимых результатов.

Источники