Качество обслуживания

Простое повышение пропускной способности не гарантирует работоспособности приложений.

Основной движущей силой развития сети всегда были приложения. В ответ на их постоянно растущие требования к пропускной способности появляются высокоскоростные технологии. Новым видам трафика, например IP-телефонии, аудио- и видеовещания, требуется низкий уровень задержек пакетов, поддержка групповой доставки пакетов и т. д. Простое повышение пропускной способности сети уже не гарантирует, что разнообразные приложения, работающие в сети, получат то обслуживание, которое им необходимо. Таким образом, нужны новые механизмы, чтобы обеспечить условия для высокого качества обслуживания (Quality of Service, QoS) с учетом всего многообразия требований, предъявляемых приложениями к сети.

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

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

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

Транспортный сервис, который предоставляли такие сети, получил название сервис "по мере возможности". Сеть "старается" обработать поступающий трафик как можно быстрее, но при этом результат непредсказуем. В качестве примеров можно назвать большинство популярных технологий, разработанных в 80-е гг.: Ethernet, Token Ring, IP, X.25. Сервис "по мере возможности" основан на некотором "справедливом" алгоритме обработки очередей пакетов: например, когда пакеты всех потоков рассматриваются как равноправные и обрабатываются в порядке поступления (First In - First Out, FIFO). Если очередь становится слишком большой (не умещается в буфере), проблема решается простым отбрасыванием вновь поступивших пакетов.

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

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

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

В отношении предсказуемости скорости приложения могут быть разделены на два больших класса.

Приложения, трафик которых представляет собой равномерный поток (Stream). Этот класс приложений характеризуется высокой степенью предсказуемости порождаемого трафика, который поступает в сеть с более или менее постоянной битовой скоростью (Constant Bit Rate, CBR). Хотя скорость потока может изменяться, тем не менее она имеет легко вычисляемую верхнюю границу. Например, аудиопотоки данных являются трафиком CBR, и для элементарного голосового потока верхняя граница составляет 64 Кбит/с.
Приложения с пульсирующим трафиком (Burst). Они отличаются высокой степенью непредсказуемости, когда периоды затишья сменяются передачей больших блоков данных. В результате для трафика характерна переменная битовая скорость (Variable Bit Rate, VBR). Так, в случае файлового сервиса интенсивность трафика может увеличиваться от нуля, когда файлы не передаются, до бесконечности, когда после передачи запроса с координатами файла приложение стремится как можно быстрее передать данные. (Понятно, что реальная скорость передачи ограничена возможностями сети.) Строго говоря, любые приложения генерируют неравномерный трафик, в том числе и потоковые. Просто коэффициент пульсации (т. е. отношение максимальной мгновенной скорости к средней) у этих двух типов приложений отличается радикально. У приложений с пульсирующим трафиком он обычно находится в пределах от 10:1 до 100:1, а у потоковых существенно меньше.

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

Асинхронные приложения: практически нет ограничений на время задержки (эластичный трафик). Пример - электронная почта.
Синхронные приложения: чувствительны к задержкам, но допускают их.
Интерактивные приложения: задержки могут быть замечены пользователями, но они не сказываются негативно на функциональности приложений. Пример: текстовый редактор, работающий с удаленным файлом.
Изохронные приложения: при превышении порога чувствительности к задержкам функциональность приложения резко снижается. Пример: передача голоса, когда при превышении порога задержек в 100 - 150 мс качество воспроизводимого голоса резко ухудшается.
Сверхчувствительные к задержкам приложения. Задержка доставки данных сводит функциональность к нулю. Пример: приложения, управляющие техническим объектом в реальном времени. При запаздывании управляющего сигнала на объекте может произойти авария.

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

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

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

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

Например, следующее сочетание характеристик приложения (изохронное, устойчивое к потерям, порождающее трафик типа равномерного потока) соответствует таким популярным приложениям, как IP-телефония, поддержка видеоконференций, аудиовещание через Internet. Устойчивых сочетаний характеристик не так уж много. Так, при стандартизации технологии АТМ были определены четыре класса приложений: A, B, C и D. Кроме того, все не попавшие ни в один из этих классов приложения были отнесены к классу X, в котором комбинация характеристик приложения может быть произвольной.

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

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

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

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

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

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

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

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

СЛУЖБА QoS

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

На Рисунке 1 представлена базовая архитектура службы QoS с элементами трех основных типов:

средств QoS узла;
протоколов сигнализации QoS;
централизованных функций политики, управления и учета QoS.

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

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

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

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

Классификация трафика выделяет из общей последовательности пакетов, поступающих в устройство, пакеты одного потока с общими требованиями к качеству обслуживания. Классификация может выполняться на основе различных формальных признаков пакета - адресов источника и назначения, значений портов TCP/UDP, значения приоритета, значения метки потока (в версии IPv6).
Профилирование трафика на основе правил (policing) подразумевает проверку соответствия каждого входного потока параметрам его профиля. В случае нарушения параметров профиля (в частности, при превышении длительности посылки или средней скорости) происходит отбрасывание или маркировка пакетов этого потока. Отбрасывание нечастых пакетов снижает интенсивность потока и приводит его параметры в соответствие с указанными в профиле. Маркировка пакетов без отбрасывания нужна для того, чтобы они все же были обслужены данным узлом (или последующими по потоку), пусть и с более низким качеством (например, с увеличенным значением задержки). Для проверки соответствия входного трафика заданному профилю механизм кондиционирования выполняет измерение параметров потока. Для этого обычно используется один из известных алгоритмов, например алгоритм "дырявого ведра" (leaky bucket) или более гибкий алгоритм GCRA.
Формирование трафика (shaping) предназначено для придания прошедшему профилирование трафику нужного распределения по времени. С помощью данной функции стремятся сгладить пульсации трафика, чтобы поток пакетов на выходе из устройства был более равномерным, чем на входе. Сглаживание пульсаций уменьшает очереди в сетевых устройствах, которые будут обрабатывать трафик далее по потоку. Формирование трафика целесообразно и для восстановления временных соотношений трафика приложений, работающих с равномерными потоками, например голосовых приложений.

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

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

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

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

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

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

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

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

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

Наталья Олифер - обозреватель "Журнал сетевых решений/LAN". С ней можно связаться по адресу: olifer@lanmag.ru