Судьба конвергенции «в руках» QoS

Успех или провал конвергенции зависит от того, насколько сложной окажется реализация гарантированных уровней качества сервиса (QoS) в среде IP с помощью механизма управления на основе правил. К сожалению, данная технология пока только разрабатывается.

Верите ли вы в конвергенцию? Или, конкретнее, верите ли вы в тот новый мировой порядок, который позволит передавать речь, данные и видео в полной гармонии друг с другом по одной высокоскоростной IP-сети? Если да, то вы верите в успех разработок в области сетевого администрирования по заданной стратегии, поскольку успех конвергенции зависит от того, сумеет ли IP-сообщество обеспечить управляемую поддержку QoS. Ведь именно это и является сутью названного механизма.

На первый взгляд, до внедрения еще далеко, поскольку стандарты продолжают формироваться, протоколы не прошли надлежащего тестирования, а продукты не достигли зрелости. Так не рано ли изучать основы сетевого управления на базе правил?

Что такое правила

Набор правил, или стратегия, описывает способ распределения ресурсов сети между ее клиентами — пользователями, приложениями или хост-машинами. Выделение этих ресурсов может происходить как статически, так и динамически, в зависимости от разных факторов, например времени дня, объема самих свободных ресурсов или наличия у клиентов подтвержденных авторизацией привилегий.

Высокоуровневые формулировки стратегии (например, «Предоставлять приоритет всем пакетам трафика voice-over-IP») преобразуются в структурированный набор правил вида «если <условие>, то <реакция>», который хранится в базе администратора, извлекается и интерпретируется различными сетевыми компонентами. Заметим, что системы первого поколения не могли сами интерпретировать высокоуровневые формулировки, а требовали от администратора формализованных условных операторов вида »если порт = HTTP (80), то установить приоритет трафика IP = 4».

Строительство инфраструктуры

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

• консоль для задания стратегий — средство администрирования, с помощью которого сетевой администратор создает и редактирует набор правил управления;
• точка принятия решений (policy decision point, PDP) — сервер, обеспечивающий выборку правил из хранилища и выработку решений;
• точки реализации стратегий (policy enforcement point, PEP) — различные сетевые устройства (маршрутизаторы, коммутаторы и брандмауэры), претворяющие в жизнь решения PDP (т.е. правила управления сетью) с помощью списков доступа, алгоритмов управления очередями и других средств;
• хранилище стратегий — способный работать с протоколом LDAP сервер, на котором в специальном каталоге хранятся стратегии.

Связь между элементами PDP и PEP обеспечивает несложный протокол запросов/ответов Common Open Policy Service (COPS). Его преимущества перед SNMP состоят в ориентации на соединения (он охватывает процесс установления/разрыва соединения), большей надежности и наличии механизмов, предотвращающих попытки одновременного обновления данных одной точки PEP несколькими PDP.

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

Чтобы обеспечить оптимальный процесс хранения и извлечения из хранилища правил, составляющих стратегии, их внутреннее представление должно быть формализовано в структуру данных. Рабочая группа IETF Policy Framework Working Group (PFWG) разработала модель Policy Framework Core Information Model, в которой определен высокоуровневый набор объектно ориентированных классов, достаточный для представления базовых стратегий управления. Объектные классы могут расширяться производными классами конкретных типов стратегий — например, обеспечения QoS или безопасности.

Уже сейчас между производителями существует соглашение, закрепляющее некоторые технические аспекты данной технологии. Так, информация о стратегиях должна храниться в LDAP-совместимом каталоге. Группа PFWG построила отображение модели Core Information Model на структуру каталога LDAP. Концепции, заложенные в эту модель, не только пользуются широкой поддержкой производителей, но и закреплены IETF в проектах нескольких стандартов. Хотя ни один из них еще не достиг стадии предложений по спецификациям (request for comments, RFC), они дают ясное представление о том, как построить сеть, управляемую по заданным правилам.

QoS в теории...

Сегодня существуют три стандарта QoS, представляющих интерес с точки зрения корпоративных сетей, — Differentiated Services (Diff-Serv), Resource Reservation Protocol (RSVP) и 802.1p.

Diff-Serv по-новому определяет способ использования байта признаков type-of-service (TOS) для протокола IP v.4 или поля Traffic Class для IP v.6 при задании требований QoS. Он обеспечивает обратную совместимость параметров QoS при работе с битами, указывающими на приоритет, и полями TOS в IP-трафике, а также может применяться для обобщенных или агрегатированных классов трафика.

RSVP основан на понятии потока и позволяет приложению сообщать параметры QoS, которые требуются для его работы (время задержки, пределы нарушения синхронизации и величины полосы пропускания), с помощью передачи управляющего сообщения по всему маршруту этого потока. Получив такое сообщение, маршрутизатор либо резервирует ресурсы для приложения-отправителя, либо отказывает ему в доступе к сети.

Протокол RSVP реализован в маршрутизаторах (некоторые из которых выпускаются уже более года) фирм Cisco, Nortel Networks и многих других производителей.

802.1p использует механизмы второго уровня модели OSI и обеспечивает интерпретацию трех бит заголовка (которые задают параметры виртуальной сети и применяются в 802.1Q для маркировки пакета и определения необходимого ему уровня QoS).

Администраторы корпоративных сетей скорее всего предпочтут для поддержки основных QoS-требований стандарт Diff-Serv, однако для наиболее «требовательных» приложений будут пользоваться и RSVP. Действительно, при передаче речи поверх IP лучше подождать, чем мириться с низким качеством связи.

Механизм обеспечения QoS на уровне сетевого устройства, применяемый в Diff-Serv, включает в себя четыре операции.

Сначала на основании информации заголовка, относящейся к уровням со 2 по 4, пакеты классифицируются. Затем они маркируются в соответствии с произведенной классификацией и данными бит Diff-Serv. В зависимости от маркировки выбирается алгоритм передачи трафика (при необходимости — с выборочным удалением пакетов), позволяющий избежать заторов. Формирование трафика чаще всего состоит в организации очередей с учетом приоритетов.

По мере дальнейшего удешевления специализированных микросхем (ASIC), реализующих функции протоколов уровня 3, оснащенные ими устройства станут применяться уже не на границе территориально-распределенной сети, как сегодня, а в оборудовании, непосредственно связанном с сетевыми терминалами. Именно такие терминалы, по мнению большинства производителей, должны в конечном счете реализовывать функции QoS.

На практике классификация и маркировка выполняются при создании списков контроля доступа (access control list, ACL). В качестве алгоритмов регулирования трафика чаще всего применяется рандомизация (например, отбрасывание пакетов по обычному случайному закону или с учетом их весового коэффициента). В алгоритмы формирования трафика входят циклический перебор, использование очередей (равноправных с учетом веса пакетов, для различных классов, для разных классов с весами) и многие другие. В настоящее время администратор сети задает алгоритмы регулирования и формирования трафика для каждого интерфейса отдельно. Поэтому неудивительно, что крупномасштабные реализации механизмов QoS в IP-сетях редки.

...и на практике

За последний год-полтора не осталось ни одного крупного производителя, не анонсировавшего решений для управления сетями на основе набора правил; однако пока лишь немногие из них довели дело до готового продукта.

В марте 1999 г. в рамках своего проекта CiscoAssure Policy-Based Networking корпорация Cisco приступила к поставкам ПО QoS Policy Manager 1.0 (QPM). Кроме того, в соответствии с этим же проектом началась разработка механизма обеспечения безопасности на основе стратегий — соответствующее приложение называется Cisco Security Manager. Оба продукта будут использовать единую инфраструктуру, но их объединения в общий пакет ПО не предполагается.

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

Менеджер стратегий QPM представляет собой первое поколение необходимых продуктов. Он обеспечивает некоторые преимущества в производительности, однако администратор не избавляется от рутинной деятельности (вроде выбора механизма организации очередей или параметров формирования трафика) и обязан хорошо разбираться в многочисленных алгоритмах работы с очередями, реализованных Cisco.

Указанная версия QPM не поддерживает LDAP-каталогов и COPS. Появление данных возможностей ожидается в первой половине 2000 г. (реализация COPS уже обкатывается в лабораториях Cisco). Число устройств, способных взаимодействовать с QPM, будет увеличено в следующей версии с нынешних 200 приблизительно до 1000.

С августа текущего года корпорация Nortel поставляет ПО Optivity Policy Services 1.0 (OPS), в котором воплощены многие концепции стандартов IETF, включая сервер стратегий, протокол COPS и совместимое хранилище на базе LDAP-каталогов. Существующая версия OPS использует для хранения набора правил собственную ветвь дерева каталога LDAP, но вскоре этот механизм будет заменен на стандартный, который работает со схемой LDAP-каталога, предлагаемой IETF. Nortel в числе первых разместил клиентскую часть COPS (для связи PEP с PDP) на сетевом устройстве — в составе ПО BayRS версии 13.20, управляющего маршрутизаторами. Клиент Nortel поддерживает и другие устройства, в том числе маршрутизаторы производства Cisco.

В случае применения OPS типичный сеанс может включать в себя добавление маршрутизатора или индивидуальных интерфейсов, создание фильтров Traffic Pattern, настроенных на определенные типы трафика, и выбор реакций, таких как Deny, Mark и Police (отсеять пакет, маркировать, выбрать алгоритм передачи). Однотипные интерфейсы допускается объединять в группы. Как и QPM корпорации Cisco, OPS обеспечивает существенный выигрыш в производительности, но требует от пользователя знания огромного количества деталей работы с продуктом. Например, из программы, задающей алгоритмы передачи трафика, нельзя выбрать для интерфейса механизм организации очередей и управлять им. Это приходится делать из приложения для конфигурирования маршрутизатора, стандартно поставляемого Nortel с каждым устройством. Компания планирует восполнить данный пробел в I квартале 2000 г.

Некоторые утверждают (и не без оснований), что поддержка администрирования на базе стратегий появилась в продукции Cabletron раньше, чем у какого-либо другого производителя. Четыре года назад компания приступила к выпуску Virtual Network Server (VNS) — своего рода ранней версии PDP. Однако продукт основывался не на стандартах, а на фирменной технологии SecureFast Switching.

Теперь коммутаторы Cabletron семейства SmartSwitch поддерживают механизм стандарта 802.1p и поле ToS/Diff-Serv. Устройство способно формировать до четырех очередей на порт, использовать алгоритм WFQ, а также осуществлять классификацию и маркировку с помощью пакетной информации уровней 2—4 (т.е. действуя на более высоком уровне модели OSI). А ведь большинство производителей рассчитывает реализовать классификацию и маркировку лишь в последующих версиях своих устройств.

QoS-менеджер Cabletron называется Spectrum Policy Aware. Начало его продаж ожидается в I квартале 2000 г. Информация о стратегиях будет храниться в LDAP-совместимом каталоге, а связь между PDP и PEP поддерживаться с помощью COPS и других протоколов. Кроме того, сетевые устройства PEP, реализующие правила, смогут использовать LDAP для взаимодействия с сервером каталогов.

Сервер стратегий корпорации 3Com поступит на рынок не ранее I квартала 2000 г. Его рабочее название — Transcend Policy Service. Ожидается, что он будет отвечать разрабатываемым IETF стандартам, а также поддерживать задание и выполнение наборов правил и взаимодействие устройств с помощью COPS. Правила должны храниться в LDAP-совместимых каталогах, а работу с ранее выпущенным оборудованием и ПО обеспечат программы-посредники.

3Com намеревается реализовать поддержку QoS во многих своих продуктах. Так, коммутаторы уровня 2 дополнятся механизмом 802.1p, а коммутаторы уровня 3 и маршрутизаторы — возможностями работы с ToS/Diff-Serv и RSVP. ПО Dynamic Access позволяет организовать классификацию и маркировку пакетов даже на уровне сетевого адаптера — правда, лишь при условии, что это устройство производства 3Com.

Неуправляемое управление

Ближайшие перспективы администрирования на основе стратегий в среде, состоящей из продуктов различных производителей, оставляют желать лучшего. К сожалению, реализации механизмов работы с набором правил и алгоритмы формирования трафика сильно различаются не только в продуктах разных производителей, но даже в пределах ассортимента одной компании. Чтобы добиться реальной совместимости устройств или их единого администрирования, нужны стандартные модели общих функций для задания и выполнения алгоритмов и формирования трафика. Необходимо также обеспечить единое представление схемы реализации QoS и информации о стратегиях в базе данных Policy Information Base (PIB), равно как и поддержку работы с PIB сетевыми устройствами.

Большинство производителей ограничивается рамками собственного оборудования и, по мере сил, реализацией совместимости с продукцией Cisco. Однако обширный список механизмов QoS, поддерживаемых устройствами этой компании, с каждым днем становится все длиннее. Поспевать за ним, конечно, очень трудно. И все же, несмотря на столь мрачные виды на совместимость в ближней перспективе, повод для оптимизма остается, поскольку пути достижения такой совместимости ясны, и производители оборудования готовы по нему идти.

* * *

Концепция сетевого управления на основе стратегий находится сегодня на раннем этапе реализации. IETF добилась значительных успехов, но требуется сделать намного больше. По всей вероятности, пройдет еще не меньше года, прежде чем основная часть будущих стандартов достигнет стадии RFC. Возможно, IP-сообществу понадобятся еще год или два для ясного осознания преимуществ таких технологий, как Diff-Serv и RSVP, и начала их внедрения для обеспечения QoS в реальных сетях. Как только будет сформирован разумный консенсус в данной области, производители смогут перейти к решению следующей задачи: сделать использование этих методов в сетях предприятий простым и удобным для клиентов.

Не бойтесь прыгать с разбегу — вода еще холодновата, но становится все теплее. Окунув ноги в волны новой технологии уже сейчас, вы сможете обеспечить поддержку механизмов QoS для своей сети в будущем.

ОБ АВТОРЕ

Типичная сеть с поддержкой администрирования на основе стратегий и механизмов обеспечения QoS потребует интеграции множества серверов, LDAP-каталогов, использования разных протоколов и сетевых устройств (PEP 1 — коммутатор/маршрутизатор опорной сети; PEP