Универсальная сеть на базе технологии Diff-Serv

Сервисы

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

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

Способы задания сервиса

В зависимости от потребностей клиента и возможностей провайдера параметрам сервиса дается качественное или количественное определение. Примером качественного определения может служить такое: «трафик, принимаемый в сеть с уровнем сервиса «А», будет доставляться с малой задержкой». Количественное определение выглядит, например, следующим образом: «95% трафика в пределах спецификации «Б» будет доставлено по назначению или 98% трафика в пределах спецификации «В» будет доставлено с задержкой, не превышающей 50 мс». Кроме того, существует сравнительный способ определения: «трафик, принимаемый в сеть с уровнем сервиса «Г», получит вдвое большую пропускную способность, чем трафик с уровнем сервиса «Д».

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

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

Границы распространения сервиса

Границы предоставления сервиса DS определяют подмножество элементов топологии сети, на которые распространяется обслуживание трафика в пределах той или иной спецификации сервиса. Если клиент подключен к сети провайдера в точке «А», то спецификация сервиса может гарантировать определенное качество транзита пользовательского трафика от точки «А» до любого выходного узла сети, до конкретного выходного узла «Б» или до некоторого набора выходных узлов.

Естественно, ограничения на область распространения сервиса позволяют провайдеру при проектировании и модернизации инфраструктуры сети подготовить все ресурсы, необходимые для предоставления данного сервиса. Планировать распределение ресурсов для передачи потока из точки «А» в точку «Б» легче, чем обеспечивать ими все возможные направления транспорта данных. Следовательно, ограничения на топологию сервиса должны сказываться на его тарификации. Важно помнить, что услуги DS ориентированы на поставщиков трафика (например, на крупных контент-провайдеров, чьи Web-узлы активно посещаются и которые генерируют большой объем трафика), а сервисы IS, наоборот, приспособлены под нужды потребителей трафика.

Динамические и статические спецификации сервиса

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

Функции отдельных компонентов

Входной узел провайдера. Минимальным требованием к этому узлу является ограничение трафика клиента теми значениями его параметров, которые указаны в спецификации кондиционирования. Последнюю можно упрощенно представить в виде записи [кодовое слово; параметры потока; границы распространения сервиса; метод обработки трафика, не вписывающегося в оговоренные в спецификации рамки].

Провайдер должен установить BA-классификатор для распределения трафика по агрегаторам поведения в зависимости от значения DSCP. После классификатора потоки, относящиеся к каждому из агрегаторов, должны пройти через соответствующие этим агрегаторам кондиционеры трафика.

Дополнительно провайдер может взять на себя функции распределения микропотоков по агрегаторам поведения, а также контролировать разделение ресурсов между микропотоками по запросу клиента. Это потребует установки на входном узле провайдера (помимо BA-классификатора) мультиполевого классификатора.

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

Выходной узел клиента. Вообще говоря, пользователь не обязан применять какие-либо специальные методы фильтрации или кондиционирования трафика, однако (как и на границе «провайдер — провайдер») он, возможно, предпочтет подавать на вход домена DS уже предварительно обработанный поток. Иногда маркировка трафика на стороне клиента просто необходима (например, если в сети применяется шифрование пакетов методом IPSec или IPv6 либо в том случае, когда приложения используют динамически выделяемые значения портов или сетевых адресов). Кроме того, предварительное кондиционирование трафика в соответствии со спецификацией кондиционирования позволяет избежать непредсказуемых последствий при формировании или фильтрации трафика провайдером.

Примеры услуг сети DS

Настало время поговорить о том, как же строятся наиболее востребованные типы сервиса с помощью технологии DS. Мы рассмотрим услуги виртуальной выделенной линии и сервис, гарантирующий доставку данных, которые распределены на потоки с заданными приоритетами. Для их реализации определены две группы PHB — соответственно Expedited Forwarding и Assured Forwarding.

Группа Expedited Forwarding PHB

Группа типов локального поведения Expedited Forwarding (EF) специально разработана для организации виртуальной выделенной линии в целях передачи трафика через домен DS. По этой линии (как по высококачественному выделенному каналу) поток передается с минимальными вариабельностью, значением задержки и потерями, причем для него гарантируется определенная пропускная способность. Воспользовавшись сервисом Expedited Forwarding, организация может построить собственную выделенную (с точки зрения QoS) сеть поверх общедоступной сети провайдера.

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

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

Таким образом, сервис виртуальной выделенной линии требует наличия двух компонентов:

• специально настроенной конфигурации узлов, позволяющей установить такую минимальную скорость отправки потока, относящегося к данному агрегатору поведения, которая не зависит от интенсивности других потоков, проходящих через тот же узел;
• процедур кондиционирования трафика (т.е. его фильтрации и формирования), гарантирующих, что скорость его поступления на каждый из узлов не превысит установленного значения минимальной скорости отправки потока с этого узла.

Локальное поведение узла относительно трафика EF должно обеспечивать скорость отправки его пакетов не ниже заданного значения — вне зависимости от статуса потоков, причисленных к другим агрегаторам поведения. Реальная скорость отправки потока (усредняемая за интервал времени, в течение которого можно передать один полноразмерный пакет), должна быть не меньше заданной скорости. При реализации группы Expedited Forwarding PHB должна быть предусмотрена защита менее приоритетного трафика от полного отсутствия доступа к ресурсам, что возможно при неконтролируемом поступлении в сеть трафика класса EF. Примерами алгоритмов управления очередью для групп EF PHB служат WFQ и CBQ. Для маркировки пакетов, которым предоставляется сервис виртуальной выделенной линии, рекомендуется использовать значение кодового слова «101110».

Пример использования сервиса виртуальной выделенной линии Между точками А и В — 320 кбит/с Между точками А и С — 160 кбит/с

Пример сети, в которой реализован сервис виртуальной выделенной линии для соединения УАТС клиента, имеющего несколько точек подключения, приведен на рис. 4. Предположим, что трафик должен передаваться между точками «A» и «B» с качеством, приемлемым для IP-телефонии, и скоростью не менее 320 кбит/с, а также между точками «A» и «С» со скоростью 160 кбит/с. Данное требование оговаривается в заключаемом с провайдером контракте, в который входят четыре отдельные спецификации сервиса:

• в направлении от «А» к «В» трафик, имеющий скорость выше 320 кбит/с, отбрасывается, а остальной помечается как EF;
• в направлении от «В» к «А» трафик, имеющий скорость выше 320 кбит/с, отбрасывается, а остальной помечается как EF;
• в направлении от «А» к «С» трафик, имеющий скорость выше 160 кбит/с, отбрасывается, а остальной помечается как EF;
• в направлении от «С» к «А» трафик, имеющий скорость выше 160 кбит/с, отбрасывается, а остальной помечается как EF.

Пакеты, не вписывающиеся в рамки спецификации кондиционирования, отбрасываются, поскольку их формирование увеличивало бы задержку, к которой трафик сервиса EF нетерпим. В соответствии со спецификацией сервиса предоставляются и ресурсы сети: в канале AD должна быть зарезервирована полоса не менее 480 кбит/с (в обоих направлениях), а в каналах DB и DC — полосы 320 и 160 кбит/с соответственно (также в обоих направлениях). Кондиционер трафика должен ограничивать скорость поступления трафика от данного клиента с маркировкой EF: в точке «A» — значением 480 кбит/с, а в точках «B» и «C» — значениями 320 и 160 кбит/с.

Группа Assured Forwarding PHB

Группа типов локального поведения с гарантированной доставкой предназначена для передачи IP-трафика с количественно определенными показателями качества обслуживания. Сервис AF можно использовать для обеспечения качественной связи в пределах виртуальной частной сети передачи данных, организованной поверх общедоступной сети провайдера. Если интенсивность трафика в пределах такой сети не превышает уровня, определенного в спецификации кондиционирования, то провайдер гарантирует высокую вероятность доставки данных. При этом трафик, чьи параметры превышают значения, указанные в спецификации кондиционирования, доставляется с более высокой вероятностью потерь и с большей величиной задержки передачи. Важным требованием к сервису AF является сохранение первоначального порядка следования пакетов, принадлежащих к одному микропотоку.

Пользователем такого сервиса может быть поставщик контента, скажем услуг «аудио или видео по запросу» (когда неинтерактивный по своей природе обмен требует наличия гарантированной пропускной способности, но передаваемый трафик не очень чувствителен к длительной неравномерной задержке). Поскольку для трафика группы AF задержки в сети не очень критичны, его приоритет должен быть ниже, чем для трафика группы EF, но выше, чем для трафика best effort.

Документ REC 2597 определяет четыре класса сервиса AF, для каждого из которых узел DS выделяет ограниченное количество ресурсов — пропускной способности канала и объема буферного пространства. В пределах каждого из классов AF пакеты маркируются тремя возможными уровнями вероятности потерь. В случае возникновения перегрузки в первую очередь отбрасываются пакеты, отмеченные тем кодовым словом, которое соответствует более высокой вероятности потерь. При возникновении перегрузки для сервисов класса AF могут использоваться ресурсы, отведенные под другие классы, если отнесенный к ним трафик отсутствует.

Таким образом, уровень обслуживания пакета, требующего сервиса AF, зависит, во-первых, от количества ресурсов, зарезервированных для того класса, к которому он принадлежит, во-вторых, от уровня нагрузки на линию при обслуживании пакетов данного класса и, в-третьих, от вероятности отбрасывания пакетов данного класса. Пакет сервиса AF, принадлежащий к классу i и имеющий уровень вероятности отбрасывания j, маркируется кодовым словом AFij.

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

При реализации сервиса AF необходимо обеспечивать низкий (усредненный по времени) уровень нагрузки, позволяющий минимизировать среднее время задержки, но не препятствующий краткосрочному возрастанию нагрузки, чтобы всплески, характерные для трафика сетей передачи данных, без потерь пропускались в сеть. Это означает, что для реализации сервиса AF потребуется активный алгоритм управления очередями, например RED, в дополнение к WFQ.

При возникновении перегрузки устройство, обеспечивающее сервис AF, отбрасывает пакеты в соответствии со значениями их кодовых слов. Вероятность такого отбрасывания должна зависеть от среднего по времени значения перегрузки, а не от мгновенной ее величины. Документ RFC 2597 требует также, чтобы сигнал о наличии перегрузки в сети был не дискретным, а непрерывным, изменяющимся пропорционально степени перегрузки. Тогда адаптивный транспортный протокол, например TCP, сможет приспособиться к ухудшению условий и отреагировать на них снижением скорости транспортировки потока.

Значения DSCP, рекомендованные для маркировки пакетов группы AF, приведены в табл. 2. Они могут беспрепятственно сосуществовать с селекторами класса.

Вопросы на будущее

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

Прежде всего, открытым остается вопрос о способе конфигурирования устройств в крупном домене DS. Несомненно, здесь не обойтись без автоматизированной системы учета и распределения ресурсов. Поскольку речь идет о системе управления, обменивающейся контрольной информацией с устройствами DS, необходимо располагать протоколом распределения конфигурационных параметров. В его роли может выступить один из стандартных протоколов управления сетью (SNMP, CMIP).

Не менее важные задачи — организация взаимодействия между отдельными доменами DS, автоматизация процесса заключения транзитных соглашений и выделения ресурсов под них. Возможным решением здесь является применение диспетчера пропускной способности (bandwidth broker).

Еще один существенный аспект функционирования DS-сети — обеспечение совместного использования архитектур DS и IS. Как отмечалось в начале статьи, эти архитектуры скорее дополняют друг друга, чем конкурируют, поскольку они имеют разные возможности и области применения. Сейчас в качестве протокола взаимодействия диспетчеров пропускной способности и средства передачи по сети конфигурационных параметров активно рассматривается RSVP.

Мы описали те компоненты технологии DS, которые определены в существующих стандартах или спецификациях. В основном их разработка велась в рамках группы diffserv консорциума IETF. Поскольку в нее входят представители крупнейших компаний — производителей сетевых устройств и решений, есть все основания ожидать скорого воплощения стандартов DS в выпускаемом ими оборудовании. К числу активных участников процесса стандартизации DS относятся Cisco, Ericsson, IBM, Microsoft, Motorola, Nortel, Sun, Torrent.

Кстати, согласно планам упомянутой группы, вся деятельность по разработке стандартов DS должна быть завершена к концу текущего года. Кроме того, в исследования таких аспектов архитектуры DS, как динамическое управление, использование диспетчера пропускной способности и динамических спецификаций сервиса, существенный вклад вносят участники проекта Internet 2, в рамках которого применение этих компонентов отрабатывается в экспериментальном порядке.

Работа поддержана грантами РФФИ № 98-07-90171, № 00-07-90123

ОБ АВТОРЕ

* Окончание. Начало см. «Сети», 2000, № 8, с. 22.

Что почитать

Задачи на будущее