Схема взаимодействия различных частей COPS
Рисунок .1. Схема взаимодействия различных частей COPS.
На рисунке .1 показано взаимодействие различных компонентов политики (взято из [WRK]). Здесь, COPS используется для обмена описаниями политики между узлами реализации политики PEP (Policy Enforcement Point) и удаленными пунктами принятия политических решений PDP (Policy Decision Point) в пределах контекста конкретного типа клиента. Может использоваться опционный пункт принятия локального политического решения LPDP (Local Policy Decision Point) в отсутствии PDP.
Предполагается, что каждый конкретный клиент политики функционально совместим с PEP [WRK]. PEP может обмениваться информацией с сервером политики.
PEP ответственен за инициализацию постоянного TCP-соединения с PDP. Узел PEP использует это соединение для посылки запросов и получения откликов-решений от удаленного PDP. Коммуникация между PEP и удаленным PDP происходит в основном в форме обменов запрос-решение, хотя удаленный PDP может по своей инициативе послать PEP и не запрошенное решение, чтобы вызвать изменение одобренных ранее состояний запросов. PEP имеет также возможность сообщать удаленному >PDP, что решение PDP успешно исполнено локально. Узел PEP ответственен за уведомление PDP об изменении состояния запроса в PEP. Наконец, в функции PEP входит аннулирование любого состояния, которое не может быть использовано из-за событий, имевших место у клиента, или в силу решений, принятых сервером.
После этого PEP посылает конфигурационный запрос, и ожидает присылки от PDP именованных блоков конфигурационных данных (в виде сообщений-решений). Когда именованные конфигурационные данные успешно доставлены PEP, он должен послать PDP сообщение-отчет, подтверждающее получение конфигурационных данных. Сервер с помощью сообщения-решения может после этого обновить или удалить конфигурационную информацию. Когда PDP посылает решение об удалении именованной конфигурационной информации на PEP, PEP стирает специфицированные данные и посылает PDP в качестве подтверждения сообщение-отчет.
Протокол политики предполагает коммуникацию с само идентифицируемыми объектами, которые содержат данные, необходимые для идентификации состояний запроса, устанавливающие контекст запроса, его тип, содержащие ссылки на поступившие ранее запросы, принятые политические решения, поступившие сообщения об ошибках и прочие данные специфичные для клиента.
Чтобы идентифицировать разные виды клиентов, в каждом сообщении приводится тип клиента. Разные типы клиентов могут иметь различные специфические данные и могут требовать различных политических решений. Ожидается, что каждый новый тип клиента имеет соответствующее описание, характеризующее специфику его взаимодействия с данным протоколом описания политики.
Контекст каждого запроса соответствует типу события, его вызвавшего. Объект контекста COPS идентифицирует тип запроса и сообщения, которые вызвали данное политическое событие, посредством своих полей типа сообщения и запроса. COPS идентифицирует три типа событий: (1) приход сообщения (2) выделение локальных ресурсов, и (3) переадресацию исходящего сообщения. Каждое из этих сообщений может потребовать различных решений. Содержимое сообщений COPS-запросов/решений зависит от контекста. Четвертый тип запроса полезен для типов клиентов, которые хотят получить конфигурационную информацию от PDP. Это позволяет >PEP послать конфигурационный запрос специфическому именованному устройству или модулю, который требует инсталляции конфигурационной информации. PEP может также иметь возможность принимать локальные политические решения с помощью LPDP (Local Policy Decision Point) [WRK], однако, PDP всегда остается точкой принятия решений. Это означает, что соответствующая информация о локальных решениях должна передаваться PDP. То есть, PDP должен быть предоставлен доступ к информации, чтобы принять окончательное политическое решение. Чтобы обеспечить такую возможность, PEP должен послать информацию о локальном решении удаленному PDP посредством объекта решения LPDP. PEP должен затем следовать решению PDP, так как оно является окончательным.
Наконец, допустимость ошибки ( fault tolerance) является обязательной особенностью данного протокола, в частности из-за того, что он ассоциируется с управлением услугами и безопасностью в распределенных сетях. Допустимость ошибки может быть достигнута за счет того, что PEP и удаленный PDP постоянно проверяют свое соединение путем посылки тестовых сообщений keep-alive (“еще жив?”). Когда обнаружен отказ, PEP должен попытаться восстановить контакт с удаленным PDP или соединиться с альтернативным (backup) PDP. Пока PEP не имеет связи, он должен ограничиться принятием локальных решений. Как только соединение восстановлено, PEP должен уведомить PDP о любом ликвидированном состоянии или о событиях, которые произошли с момента потери соединения. Кроме того, удаленный PDP может потребовать, чтобы все внутренние состояния PEP были заново синхронизованы (все ранее поступившие запросы должны быть продублированы). После отказа и до того как новое соединение будет восстановлено в полном объеме, ущерб в обслуживании может быть минимизирован, если PEP кэширует переданные ранее решения и продолжает их использовать в течение некоторого ограниченного времени. В разделах 2.3 и 2.5 детально рассмотрены механизмы COPS для обеспечения надежности.
Содержание раздела