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

Наталья Олифер

14.01.2002

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

Основной движущей силой развития сети всегда были приложения. В ответ на их постоянно растущие требования к пропускной способности появляются высокоскоростные технологии. Новым видам трафика, например 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.

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

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

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

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

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

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

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

Например, следующее сочетание характеристик приложения (изохронное, устойчивое к потерям, порождающее трафик типа равномерного потока) соответствует таким популярным приложениям, как 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 узла в свою очередь могут включать компоненты двух типов:

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

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

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

Протоколы сигнализации 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 сетей АТМ.