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

Вслед за протоколом RSVP исследовательская группа RAP (IETF) [RAP] занялась разработкой масштабируемой модели управления политикой при помощи протокола RSVP. Сначала протокол RSVP был дополнен функциями, позволяющими узлам обмениваться данными о «правилах» (rules and policy) [RFC2750] управления запросами на резервирование ресурсов. Далее был разработан протокол COPS (Common Open Policy Service, Общая Открытая Служба Правил) [RFC2748], позволяющий узлам с реализованным протоколом RSVP (RSVP capable node) осуществлять распределение и управление информацией о «правилах» среди сетевых элементов. Отметим, что здесь и далее в рамках дисуссии о протоколе COPS под термином «правила» будем понимать правила, критерии и ограничения, которые могут быть применены к запросам на предоставление ресурсов «из-конца-в-конец».

Протокол COPS использует архитектуру «клиент-сервер» и представляет собой последовательность запросов и ответов о правилах. При реализации COPS на сети предполагается наличие двух основных компонент, между которыми он функционирует:

• «Точка выполнения решения» (Policy Enforcement Point, далее - PEP): сетевые элементы, в рамках которых на основе существующих правил принимается решение о поддержке или отклонении запросов резервирования ресурсов;

• «Точка принятия решения» (Policy Decision Point, далее - PDP): сетевые элементы, содержащие текущие правила и осуществляющие проверку поступающих запросов в соответствии с этими правилами, часто называются «серверами правил» (англоязычный термин - external policy server).

На рис. 4.23 представлено место функционирования протокола COPS на сети. РЕР посылает запрос к PDP каждый раз, когда необходимо принять решение о поддержке поступившего запроса на резервирование ресурсов, т.е. в простейшем случае, когда речь идет только о функционировании протокола RSVP на сети, маршрутизатор, ресурсы которого резервируются на основе сообщений RATH и RESV, является и точкой выполнения решения РЕР, и точкой принятия решения PDP - налицо совмещение функций обеих компонент. При реализации COPS на сети очевидно, что масштабируемость может быть достигнута путем внедрения одной точки PDP для обслуживания нескольких точек РЕР (клиентов).

PDP также может быть реализована распределенно, PDP может иметь «Локальные точки принятия решений» (Local Policy Decision Point, далее - LPDP), с помощью которых нагрузка, связанная с хранением данных и обработкой поступающих запросов, может быть возложена на подчиненные «серверы правил» ближе к точкам РЕР (клиентам), которыми они управляют. LPDP обязаны сообщать о принятых решениях PDP, являющихся для PDP предварительными, причем PDP может отменить их. Далее PDP принимает решение на основе полученного запроса и решении, принятом LPDP.

На транспортном уровне для достоверной доставки сообщений между РЕР и PDP используется протокол TCP. Каждая РЕР устанавливает соединение TCP с соответствующей ей PDP. Также отметим, что на сетевом уровне для данных протокола COPS используется протокол защиты Ipsec [RFC2401], позволяющий существенно повысить уровень безопасности, в которой нуждается COPS, в первую очередь потому, что несанкционированный доступ к правилам COPS может привести к информационному захвату сети.

⇐Многопротокольная маршрутизация по метке mpls | Управление трафиком и качество обслужевания в сети | Поддержка mpls в архитектуре diffserv⇒