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

ТРЕБОВАНИЯ РАЗНЫХ ТИПОВ ПРИЛОЖЕНИЙ.

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

По предсказуемости скорости трафика приложения делятся на два больших класса: с трафиком в виде равномерного потока (Stream) и с нерегулярным трафиком (Burst). Первый класс приложений характеризируется высокой степенью предсказуемости порождаемого трафика, поэтому он имеет более или менее постоянную скорость (Constant Bit Rate, CBR). Скорость потока может меняться, но ее верхняя граница предопределена. Например, аудиопотоки данных относятся к классу CBR, и для элементарного голосового потока верхняя граница равна 64 Кбит/с.

Второй класс отличается высокой степенью непредсказуемости, когда периоды бездействия сменяются активностью, соответствующей доставке больших «блоков данных». Такой трафик характеризируется переменной битовой скоростью (Variable Bit Rate, VBR). Так, при работе файлового сервиса интенсивность трафика может возрастать от нуля, когда файлы не передаются, до бесконечности, когда после передачи запроса с информацией о местонахождении файла приложению требуется как можно быстрее получить данные. Строго говоря, любые приложения генерируют нерегулярный трафик, в том числе и потоковый. Просто коэффициент нерегулярности (то есть отношение максимальной мгновенной скорости к средней) у этих двух типов приложений радикально отличается. У приложений с нерегулярным трафиком он обычно находится в диапазоне от 10:1 до 100:1, тогда как у потоковых приложений эти значения существенно меньше.

Другой критерий классификации приложений по типу трафика — их восприимчивость к задержке пакетов. Далее перечислены основные типы приложений в порядке увеличения данного показателя:

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

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

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

Второй тип приложений объединяет приложения, трафик которых несет информацию об инерционных физических процессах. Устойчивость к потерям объясняется тем, что небольшое количество отсутствующих данных можно восстановить с помощью принятых. Так, при потере одного пакета с несколькими последовательными замерами голоса недостающие замеры могут быть заменены аппроксимацией на основе соседних значений. К такому типу приложений относится большая часть мультимедийных приложений (аудио- и видеоприложения). Однако устойчивость к потерям имеет свои пределы, поэтому количество потерянных пакетов не может превышать 1%. Отметим также, что далеко не любой мультимедийный трафик устойчив к потерям данных, в частности, сжатый голос или видеоизображение очень чувствительны к потерям, поэтому относятся к первому типу приложений.

Три перечисленных характеристики по сути независимы. Приложение с равномерным потоком может быть как асинхронным, так и синхронным, а синхронное приложение — как чувствительным, так и нечувствительным к потерям пакетов. Однако практика показывает, что большинство используемых приложений описывается всего несколькими возможными комбинациями указанных характеристик. Например, комбинация «равномерный поток, изохронность, устойчивость к потерям» соответствует таким популярным приложениям, как IP-телефония, видеоконференции и аудиовещание через Internet. С другой стороны, для ряда сочетаний характеристик трудно привести пример реального приложения, например: «равномерный поток, асинхронность, чувствительность к потерям». Устойчивых сочетаний характеристик не так уж и много. При стандартизации технологии ATM были определены четыре класса приложений: A, B, C и D. Кроме того, для всех приложений, не попавших ни в один из этих классов, определен класс X, в котором сочетание характеристик приложения может быть произвольным.

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

ПАРАМЕТРЫ КАЧЕСТВА ОБСЛУЖИВАНИЯ

Трем критериям классификаций приложений соответствуют три группы параметров для определения и задания требуемого качества обслуживания:

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

При определении всех этих параметров важно, за какой период измеряется каждый из них. Чем он короче, тем более жесткими являются требования качества обслуживания и тем труднее их выдержать. Поэтому провайдеры сетей IP предпочитают указывать в соглашениях SLA среднемесячные величины, поскольку испытывают сложности с обеспечением QoS. В то же время провайдеры сетей frame relay и ATM, располагающие мощными средствами QoS, способны гарантировать требуемые параметры качества обслуживания с усреднением за период в несколько секунд.

С одной стороны, параметры качества обслуживания могут быть отнесены к трафику, порождаемому приложениями пользователя. С другой стороны, эти же параметры указывают на способность сети обслуживать данный трафик. Пусть, например, у пользователя имеется приложение, которое порождает равномерный поток с постоянной скоростью N. При заключении соглашения SLA с провайдером он берет на себя обязательство, что направляемый в сеть трафик приложения не будет превышать максимальную скорость N. Провайдер, в свою очередь, гарантирует, что минимальная величина пропускной способности, предоставляемой сетью этому приложению, будет не меньше N. Тем самым обеспечивается приемлемое качество обслуживания трафика данного приложения.

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

МОДЕЛЬ СЛУЖБЫ QOS

Базовая архитектура службы QoS включает элементы трех основных типов (см. Рисунок 1):

Рисунок 1. Базовая архитектура средств QoS.

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

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

Эти средства могут включать элементы двух типов:

  • механизмы обслуживания очередей;
  • механизмы «кондиционирования» трафика.

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

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

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

Классификация трафика. Эта функция позволяет выделить пакеты одного потока, имеющие общие требования к качеству обслуживания. Классификация может выполняться на основе различных формальных признаков пакета — адресов отправителя и получателя, портов TCP/UDP, приоритета пакета, метки потока (в версии IPv6).

Профилирование трафика на основе правил (policing). Для каждого входного потока имеется соответствующий ему набор параметров QoS, который часто называют профилем трафика. Профилирование трафика подразумевает проверку соответствия каждого входного потока параметрам его профиля. В случае нарушения параметров профиля (например, превышения длительности активности или средней скорости) пакеты потока удаляются или маркируются. Изъятие части пакетов снижает интенсивность потока и приводит его параметры в соответствие с указанными в профиле. Маркировка пакетов без их удаления применяется, когда пакеты все же могут быть обслужены данным узлом (или следующими по потоку), но качество обслуживания будет отличаться от указанного в профиле (например, задержка увеличится). Для проверки соответствия входного трафика заданному профилю механизм кондиционирования измеряет параметры потока при помощи одного из известных алгоритмов, например, алгоритма «дырявого ведра» (leaky bucket) или более гибкого алгоритма GCRA.

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

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

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

Одно из простейших средств сигнализации — маркировка пакета, когда в него включается информация о требуемом для пакета качестве обслуживания. Наиболее часто в этих целях используется поле приоритета (в пакете IPv4 — первые три бита поля Type Of Service, TOS). Продвигаясь от устройства к устройству, пакет несет с собой свои требования к качеству обслуживания, правда, в достаточно обобщенной форме: поле приоритета имеет всего несколько возможных значений, поэтому и дифференциация качества обслуживания возможна всего для нескольких агрегированных потоков сети.

Централизованные функции политики, управления и учета QoS не являются необходимым элементом архитектуры службы QoS, но очень желательны в крупных сетях. Для крупной сети необходимость централизации средств политики QoS очевидна. Единые правила, справедливые для всех устройств сети, хранятся на сервере (или нескольких серверах с тиражируемыми базами правил). Администратор конфигурирует правила в одном месте, что снижает трудоемкость задачи и количество ошибок. Затем посредством специального протокола эти правила рассылаются по всем сетевым устройствам, поддерживающим качество обслуживания, а сетевые устройства применяют политику для кондиционирования трафика и управления очередями в соответствии с нужными параметрами.

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

Описанной модели службы QoS соответствует большинство конкретных протоколов поддержки QoS, таких как RSVP, DiffServ сетей TCP/IP, протоколов служб CBR, VBR и ABR сетей ATM.

Дмитрий Федодеев — инженер департамента системной интеграции компании «Инжиниринг+Электроникс». С ним можно связаться по адресу: Fedodeev_D@epluse.ru.