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

Но с распространением приложений реального времени, и, в частности, Интернет-телефонии, провайдеры все чаще сталкиваются с тем, что для сохранения своего бизнеса и привлечения клиентов им необходимо принять специальные меры для этих типов информа­ционных потоков.

Один из способов сделать это - заключение соглашений об уровне сервиса (Service Level Agreement, SLA), т. е. контрактов, где четко указано, какого уровня доступность, сер­висы и цены ожидает получить заказчик. В таком соглашении сервис-провайдеры должны гарантировать срок бессбойной работы и длительность задержки в конкретное время суток для конкретных видов приложений. Оно также может содержать информацию о доступности пользовательского соединения.

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

Сервис-провайдер может определить два или более уровней QoS и взимать за них со­ответствующую плату. Наинизший уровень QoS может использоваться для доставки данных по мере возможности по типу Internet. Более высокий уровень обслуживания - для критиче­ски важных данных, включая приложения ERP с низким процентом потерянных пакетов и контролируемой задержкой. Самый высокий уровень обслуживания - для приложений ре­ального времени типа видеоконференции и видеосвязи; этот уровень должен характеризо­ваться очень малой задержкой и вариацией задержки, а также очень низким процентом поте­рянных пакетов.

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

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

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

Типичная сеть с поддержкой администрирования на основе стратегий и механизмов обеспечения QoS показана на рис. 5.11. Ее построение потребует интеграции множества сер­веров, LDAP-каталогов, использования разных протоколов и сетевых устройств: коммутато­ров/маршрутизаторов опорной сети PEP 1, коммутаторов/маршрутизаторов непосредствен­ного подключения терминалов PEP 2, коммутаторов/маршрутизаторов территориально-распределенной сети PEP 3.

Рис. 5.11. Типичная сеть с поддержкой администрирования на основе стратегий и механизмов обеспечения QoS

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

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

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

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

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

• консоль для задания стратегий - средство администрирования, с помощью которого сетевой администратор создает и редактирует набор правил управления;

• точка принятия решений (policy decision point, PDP) - сервер, обеспечивающий выбор­ку правил из хранилища и выработку решений;

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

• хранилище стратегий - способный работать с протоколом LDAP сервер, на котором в специальном каталоге хранятся стратегии.

802.1р анализирует поля приоритета в заголовке пакета. Ей в помощь IEEE предложил спецификацию 802.1Q. предусматривающую 32-разрядный заголовок пакета, предшествующий адресам отправителя и получателя в кадре Ethernet. Этот 32-разрядный заголовок может быть определен маршрутизаторами, коммутаторами и даже станциями конечных пользователей. Он содержит информацию о группах виртуальных локальных сетей и сигнализации 802.1р.

На основании этого заголовка маршрутизаторы и коммутаторы (на втором и на треть­ем уровнях) могут принимать решения о приоритете трафика с учетом предопределенных правил, заданных администратором сети.

Стандарт 802.1 р призван обеспечить QoS при коммутации в локальных сетях, поэтому он может быть не столь привлекательным, как рассмотренные выше технологии для глобаль­ных сетей Интернет-телефонии.

По сути, MPLS привносит коммутацию каналов, какую мы имеем в ATM, в мир па­кетных сетей, связанных с IP. На практике MPLS можно использовать для доставки IP-трафика по сетям IP.

Следует отметить, что DiffServ функционирует на третьем уровне, a MPLS - на вто­ром, поэтому с технической точки зрения обе технологии могут мирно существовать друг с другом. Как уже упоминалось, DiffServ классифицирует пакеты при их поступлении на крае­вой маршрутизатор, поэтому данный стандарт, скорее всего, будет использоваться на грани­це сети, например, между компанией и ее сервис-провайдером.

А ввиду того, что MPLS предполагает включение дополнительных меток и использо­вание маршрутизаторов/коммутаторов, способных интерпретировать данную информацию, он, вероятно, найдет применение исключительно внутри корпоративных сетей или базовой сети оператора, где требуется высокий уровень QoS для IР-трафика.

Если DiffServ требует некоторой настройки сетевых маршрутизаторов, то MPLS пред­полагает более серьезную модернизацию, чтобы маршрутизаторы могли читать метки и на­правлять пакеты по конкретным маршрутам.

В настоящее время DiffServ пользуется более широким вниманием, и он ближе к окончательной стандартизации, чем MPLS. Однако каждая из технологий имеет свои пре­имущества в конкретных областях сети, поэтому поставщики, скорее всего, будут поддержи­вать их обе.

При IP-коммутации узел анализирует первые несколько пакетов поступающего трафи­ка и, в случае короткой посылки, например запроса DNS или SNMP, обрабатывает их как обычный маршрутизатор. Но если узел идентифицирует длительный поток - от трафика telnet или ftp до загрузки файлов через Web и мультимедийных приложений, то IP-коммутатор переключается на нижележащую структуру ATM и применяет сквозную комму­тацию для быстрой доставки данных адресату.

IP-коммутация поддерживает различные уровни QoS и может использовать ATM, имеющий многочисленные встроенные средства поддержки QoS, и RSVP.

Конкуренцию IP-коммутации составила тег-коммутация. Как видно из названия, данная технология предполагает присоединение к пакетам меток для информирования коммутаторов и маршрутизаторов о природе трафика. Не углубляясь в анализ пакета, устройства просто счи­тывают метку в заголовке для определения соответствующего маршрута потоку трафика.

Если DiffServ задействует заголовок DS, уже имеющийся в пакетах IPv4, то MPLS ис­пользует 32-разрядную информационную метку, добавляемую к каждому IP-пакету. Эта мет­ка, добавляемая при входе в сеть с поддержкой MPLS, сообщает каждому маршрутизатору вдоль пути следования, как надо обрабатывать пакет. В частности, она содержит информа­цию о требуемом для данного пакета уровне QoS.

В отличие от поля DS, метка MPLS изначально не является частью пакета IP. Скорее, она добавляется при поступлении пакета в сеть и удаляется при выходе пакета из сети MPLS.

В обычной ситуации маршрутизаторы анализируют заголовок пакета для определения его адресата. Ввиду того, что такой анализ проводится на каждом транзитном узле независи­мо, предсказать, каким маршрутом будет следовать пакет, практически невозможно, поэтому обеспечение гарантированного уровня QoS оказывается невероятно сложной задачей.

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

DiffServ, кроме того, сокращает служебный трафик по сравнению с RSVP и IntServ, опирающимися на сигнализацию из конца в конец. DiffServ классифицирует потоки в соот­ветствии с предопределенными правилами и затем объединяет однотипные потоки. Подоб­ный механизм делает DiffServ гораздо более масштабируемым, чем его предшественника IntServ. Весь трафик с одинаковыми метками рассматривается одинаковым образом, поэтому реализация DiffServ в сети крупного предприятия или по каналам глобальной сети оказыва­ется более реальной задачей.

Как можно догадаться, преимущества DiffServ нельзя получить автоматически. Мар­шрутизаторы должны понимать «меченые потоки» и уметь соответствующим образом реаги­ровать на них. Это потребует модернизации микропрограммного обеспечения маршрутиза­торов. К счастью, с популяризацией DiffServ все большее число производителей намеревает­ся поддерживать данную архитектуру в будущих версиях своих продуктов.