Контроль качества в сетях IP

Объединение Integrated Services и Differentiated Services позволяет обеспечить адекватное качество обслуживания в Internet.

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

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

Однако, благодаря давно ведущимся в сетевой отрасли разработкам в области технологий frame relay и ATM, многие необходимые для реализации QoS в сетях IP механизмы уже имеются. Дело не только в том, что IP может передаваться по сетям frame relay и ATM и, тем самым, эффективно использовать их механизмы поддержки качества обслуживания, но и в том, что IETF заимствует у этих технологий концепции QoS и преобразует их с целью применения непосредственно к IP-трафику. IETF разработала два стандарта для обеспечения качества обслуживания: так называемые интегрированные услуги (Integrated Services, IntServ) и дифференцированные услуги (Differen-tiated Services, DiffServ).

РЕЗЕРВИРОВАНИЕ КАНАЛОВ ПОДДЕРЖИВАЕТ НОВЫЕ ПРИЛОЖЕНИЯ

Стремясь удовлетворить растущий спрос на многоадресную рассылку в IP-сетях и обслуживание в реальном времени для широкого круга новых приложений, рабочая группа IETF Integrated Services Working Group представила предварительную версию (RFC 1633) расширения архитектуры и протоколов Internet, обеспечивающую интегрированные услуги, т. е. услуги IP в реальном времени и обычные услуги IP безотносительно реального времени. В соответствии с концепциями IntServ приложения могут выбирать для своих потоков данных любой из многочисленных контролируемых уровней качества обслуживания. Для этого к базовым сервисам IP добавляются новые компоненты и механизмы.

Обслуживание в реальном времени требует гарантий, и эти гарантии не могут быть обеспечены без резервирования. Протокол резервирования (ReSerVation Protocol, RSVP) (RFC 2205) предусматривает, что ресурсы резервируются для каждого потока, требующего QoS, на каждом промежуточном маршрутизаторе на пути от отправителя к получателю с использованием сигнализации «из конца в конец». Это, в свою очередь, требует хранения на маршрутизаторах данных о состоянии каждого конкретного потока и, как следствие, подразумевает кардинальные изменения в общей модели Internet. Кроме того, такое решение предлагает способ передачи требований приложения элементам сети, расположенным вдоль пути, и обмена служебной информацией QoS между сетевыми элементами и приложением.

Рисунок 1. По зарезервированному каналу хосты-отправители RSVP посылают сообщения Path вдоль маршрутов, определенных протоколами маршрутизации. Сообщения Path содержат информацию, используемую для передачи сообщений RSVP Reservation Request (Resv) в обратном направлении. Хосты-получатели посылают сообщения Resv хостам-отправителям вдоль пути, в направлении, противоположном тому, которое будут использовать пакеты данных.

Рисунок 1 иллюстрирует, как осуществляется резервирование каналов. Каждый хост-отправитель RSVP передает сообщение RSVP Path по маршрутам одноадресной/многоадресной рассылки, предоставляемым протоколами маршрутизации, т. е. по тому же пути (или путям), по которым будут пересылаться данные. На основании сообщений Path каждый узел вдоль маршрута запоминает так называемое состояние пути. Состояние пути включает как минимум IP-адрес предыдущего узла маршрута; впоследствии эти адреса используются для передачи сообщений другого типа — Reservation Request (Resv) — от узла к узлу в обратном направлении.

Каждый хост-получатель посылает сообщения RSVP Resv по маршруту в сторону отправителей. Эти сообщения должны следовать точно в обратном направлении по тому пути (путям), по которому будут пересылаться пакеты данных, и быть доставлены всем хостам-отправителям, входящим в список выбранных отправителей. Сообщения Resv создают и поддерживают так называемое состояние резервирования на каждом узле вдоль пути. В конечном счете они должны быть доставлены самим хостам-отправителям, чтобы последние могли задавать соответствующие параметры управления трафиком для первого отрезка маршрута.

Сообщения Path пересылаются с теми же адресами отправителя и получателя, что и данные, так что они будут корректно передаваться через те части сети, где RSVP не поддерживается. Сообщения же Resv передаются от одного транзитного узла к другому; каждый узел, поддерживающий RSVP, направляет сообщение Resv по адресу предыдущего транзитного узла RSVP.

Протокол IntServ определяет три класса обслуживания. Первый из них — это гарантированное обслуживание (RFC 2212), с гарантиями на пропускную способность, величину задержки и процент потерь. Второй класс — это обслуживание с контролируемой нагрузкой (RFC 2211), аналог услуг доставки по мере возможности в сети с небольшой нагрузкой. Третий — это услуги доставки по мере возможности, аналогичные тем, которые сейчас предлагает Internet при любых уровнях нагрузки.

ДОСТОИНСТВА INTSERV

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

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

Еще одно достоинство — гарантированная величина задержки. В своей статье (см. врезку «Ресурсы Internet») А. Парех показывает, что если маршрутизатор поддерживает дисциплину обслуживания, известную под названием «взвешенные справедливые очереди» (Weighted Fair Queuing, WFQ), и если трафик имеет более или менее определенную природу (например, если он соответствует каким-то ограничениям, в частности ограничениям алгоритма token bucket), то для времени задержки пакетов в сети может быть задана абсолютная верхняя граница. Этот простой и очень мощный результат может быть отнесен не только к отдельному маршрутизатору, но и к произвольной сети маршрутизаторов.

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

НЕДОСТАТКИ INTSERV

Самый неприятный вопрос, связанный с IntServ, касается масштабируемости RSVP, особенно в высокоскоростных магистральных сетях. Действительно, объем ресурсов, которые необходимы маршрутизатору для обработки и хранения информации RSVP, увеличивается пропорционально количеству потоков QoS. Измерения трафика показывают, что большинство соединений IP «из конца в конец» существует очень недолго, и в каждый момент времени магистральным маршрутизатором поддерживается несколько тысяч активных соединений. Следовательно, многочисленные потоки IntServ в канале с большой пропускной способностью значительно увеличивают нагрузку на маршрутизаторы. Более того, каждый раз при изменении топологии все зарезервированные пути необходимо прокладывать заново.

Еще одна проблема состоит в том, что архитектура Internet строилась исходя из предположения, что вся касающаяся состояния потоков информация должна храниться на конечных узлах; впрочем, создание стека протоколов TCP/IP на основе этой концепции как раз и обеспечило эффективность Internet, благодаря которой сеть и пользуется столь впечатляющей популярностью. Чтобы сохранить эффективность стека протоколов Internet, отслеживаемое маршрутизаторами с поддержкой резервирования ресурсов состояние потока может быть сделано «мягким». RSVP периодически рассылает обновляющие сообщения для сохранения состояния вдоль зарезервированных путей. При отсутствии своевременных обновляющих сообщений состояние автоматически устаревает и удаляется (RFC 2210).

ДИФФЕРЕНЦИРОВАННЫЕ УСЛУГИ

Механизмы DiffServ (RFC 2474) усовершенствуют IP с целью преодолеть ограничения IntServ/RSVP и обеспечить масштабируемое избирательное обслуживание в Internet без необходимости запоминать состояние каждого потока и поддерживать сигнализацию (более подробную информацию об этом можно найти в источниках, перечисленных во врезке «Ресурсы Internet»). Из небольшого, корректно определенного набора строительных блоков, применяемых в сетевых узлах, могут быть созданы самые разнообразные сервисы. Услуги могут предоставляться «из конца в конец» или внутри доменов сети; они могут удовлетворять количественным требованиям к производительности (например, гарантировать пиковую пропускную способность) или же обеспечивать относительную производительность (в частности, различать классы трафика).

В отличие от RSVP, в случае DiffServ отправитель и получатель не обмениваются информацией о требованиях к качеству обслуживания, что исключает затраты (временные) на прокладку пути, присущие RSVP. Преимущества от использования DiffServ получают кратковременные потоки, поскольку отсутствие затрат на настройку QoS увеличивает скорость реакции и сокращает дополнительный трафик, возникающий вследствие того, что хосту необходимо быстро «договориться» с другим хостом.

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

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

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

АРХИТЕКТУРА DIFFSERV

Масштабируемость архитектуры DiffServ достигается за счет объединения классификационных признаков трафика, при этом информация о типе трафика передается в пакетах IP посредством маркировки поля DiffServ. Пакеты классифицируются и маркируются так, чтобы они могли получить определенный режим обработки на каждом узле на протяжении всего пути следования. При этом сложные операции классификации, маркировки, определения правил обслуживания и формирования трафика необходимо выполнять только на границах сети или же на хостах. Сетевые ресурсы выделяются для потоков трафика на основе правил обслуживания, которые определяют, каким образом трафик маркируется и кондиционируется (т. е. приводится к определенному виду) при входе в сеть, поддерживающую DiffServ, а также то, как этот трафик обрабатывается внутри данной сети. Множество характеристик канала, таких, как пропускная способность, задержка, вариация задержки и/или потери, могут контролироваться и настраиваться с помощью следующих компонентов.

Соглашение об уровне сервиса (Service Level Agreement, SLA). Дифференцированное обслуживание распространяется за границу домена DiffServ благодаря заключению SLA между сетью, из которой приходит трафик, и доменом DiffServ, в который трафик направляется. SLA может определять классификацию пакетов и правила перемаркировки; оно также может устанавливать профили трафика и действия, выполняемые с потоками, соответствующими или не соответствующими заданному профилю. Кроме того, SLA предусматривает (прямо или косвенно) соглашение о кондиционировании трафика (Traffic Conditioning Agreement, TCA) между доменами.

Рисунок 2. На этом схематическом изображении классификатора пакетов и модуля согласования трафика контролер определяет соответствие потока трафика определенному профилю. Маркировщик пакетов использует поле Differentiated Services (DiffServ) для отнесения пакета к одному из агрегированных потоков DiffServ. Формирователь задерживает пакеты для выравнивания потока в соответствии с профилем, а отбраковщик удаляет пакеты для обеспечения соответствия потока профилю.

Правила классификации пакетов определяют подмножество трафика, которое может получить дифференцированное обслуживание, за счет кондиционирования и/или отображения на один или несколько агрегированных потоков (с помощью перемаркировки кодов DiffServ) внутри домена DiffServ (см. Рисунок 2). Классификатор отбирает пакеты из потока трафика в зависимости от содержания некоторой части заголовка пакета. Профиль трафика задает временные свойства потока трафика, выбранного классификатором. Имеющиеся правила определяют соответствие конкретного пакета профилю. В зависимости от его соответствия (или несоответствия) профилю к пакету могут применяться различные операции кондиционирования или учета.

Модификация трафика. Кондиционирование трафика включает такие операции, как измерение, формирование, профилирование и/или перемаркировка, чтобы гарантировать, что трафик, попадающий в домен DiffServ, удовлетворяет правилам, определенным в соглашении TCA в соответствии с политикой выделения ресурсов домена (см. Рисунок 2). Контролер определяет, соответствуют ли параметры трафика его профилю. Результаты проверки для конкретного пакета (например, соответствие пакета профилю) могут использоваться для инициирования операций маркировки, отбрасывания или формирования.

Маркировщики пакетов присваивают полю DiffServ пакета конкретное кодовое значение (codepoint), включая маркированный пакет в конкретный агрегированный поток. Формирователи задерживают некоторые или все пакеты в потоке, чтобы обеспечить соответствие потока его профилю. Формирователь обычно имеет буфер ограниченного размера, так что пакеты могут быть отброшены из-за нехватки в буфере места для размещения задержанных пакетов. Отбраковщики удаляют некоторые или все пакеты в потоке, чтобы обеспечить его соответствие профилю, — этот процесс называется приведением потока в соответствие с требованиями политики, или профилированием. При выходе пакетов из модуля кондиционирования трафика пограничного узла DiffServ поле Differentiated Services Codepoint (DSCP) каждого пакета должно иметь соответствующее значение.

Определение поля DiffServ. Предложенное в качестве замены поле заголовка пакета IP, называемое полем DiffServ, изменяет существующие определения октета IPv4 Type of Service (ToS) (RFC 1349) и октета IPv6 Traffic Class (RFC 2460). Шесть разрядов поля DiffServ интерпретируются как кодовое значение DSCP, которое и используется для выбора правил пошаговой обработки (Per-Hop Behavior, PHB), которой пакет подвергается в каждом узле. Два разряда поля Currently Unused (CU) остаются резервными.

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

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

Выделение сетевых ресурсов. Реализация, конфигурация, функционирование и администрирование поддерживаемых групп PHB в узлах домена DiffServ должны, в соответствии с политикой распределения ресурсов данного домена, обеспечить эффективное распределение ресурсов этих узлов и связывающих узлы каналов между обслуживаемыми агрегированными потоками трафика. Модули кондиционирования трафика позволяют ввести дополнительный контроль за использованием этих ресурсов за счет применения соглашений TCA и, возможно, за счет организации обратной связи между узлами и другими модулями кондиционирования данного домена.

Недавно IETF определила для стандартизации две группы PHB в дополнение к используемой по умолчанию группе PHB с доставкой по мере возможности. Ими стали группы Expedited Forwarding (EF, RFC 2598) и Assured Forwarding (AF, RFC 2597). EF PHB определяется как такая обработка пакетов некоторого агрегированного потока DiffServ, при которой скорость отправления пакетов агрегированного потока из любого узла DiffServ должна быть равна или превышать скорость прибытия пакетов. С помощью EF PHB можно предоставлять обслуживание «из конца в конец» через все домены DiffServ с низким уровнем потерь, низкими задержками, низкими вариациями задержек и гарантированной пропускной способностью. Такое обслуживание для конечных узлов выглядит как соединение «точка-точка» или арендованная виртуальная линия.

Группа AF PHB обеспечивает доставку пакетов IP в соответствии с четырьмя независимо обрабатываемыми классами AF. Внутри каждого класса может быть выделено определенное количество ресурсов, необходимых для трансляции пакетов (некоторый объем буфера и пропускная способность), и назначен один из трех уровней предпочтения при отбрасывании. В случае перегрузки порядок отбрасывания пакетов определяется относительной важностью пакета внутри класса AF.

БУДУЩЕЕ КАЧЕСТВА ОБСЛУЖИВАНИЯ

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

В форме Internet Draft (см. врезку «Ресурсы Internet») была предложена гибридная структура (см. Рисунок 3), которая, по-видимому, является наиболее выигрышным компромиссом. Она предусматривает применение модели, в которой периферийные подсети поддерживают RSVP и IntServ. Эти подсети связаны сетями DiffServ. Благодаря масштабируемости сетей DiffServ данная модель позволяет расширить диапазон действия сетей IntServ/RSVP. Промежуточные сети DiffServ выглядят для сетей IntServ/RSVP как одно транзитное звено. Хосты, подключенные к периферийным сетям IntServ/RSVP, передают через сети DiffServ запросы друг другу на резервирование ресурсов для каждого отдельного потока. Внутри периферийных сетей IntServ/RSVP применяется стандартная обработка протоколов IntServ/RSVP, а сигнальные сообщения RSVP передаются через сети DiffServ прозрачным образом. Устройства на границе между сетями IntServ/RSVP и сетями DiffServ обрабатывают сообщения RSVP и обеспечивают входной контроль с учетом наличия ресурсов внутри сети DiffServ.

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

Механизмы IntServ реализуются на границе корпоративных сетей, где пользовательскими потоками можно управлять на уровне настольных систем. Это лучше подходит для определения качества обслуживания внутри предприятия, где вопросы масштабируемости могут решаться за счет определения доменов совместной работы. Использование сигнальных сообщений RSVP обеспечивает контроль доступа к сети DiffServ с учетом наличия ресурсов и требований политики. Это также значительно упрощает конфигурацию классификаторов DiffServ, модулей политики и других компонентов кондиционирования трафика. Важным стимулом к использованию IntServ в настольных системах является реализация компанией Microsoft протокола RSVP и средств поддержки качества обслуживания в Windows 2000.

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

Современные потенциально высокоэффективные реализации QoS на уровне IP, если их правильно применить, позволят Internet стать де-факто универсальной платформой для глобальных коммуникаций.

Ресурсы Internet

Вернуться