CC BY
158
А.И. Шопов
ОБЕСПЕЧЕНИЕ КАЧЕСТВА ОБСЛУЖИВАНИЯ НА ОСНОВЕ ДИФФЕРЕНЦИРОВАННЫХ И ИНТЕГРИРОВАННЫХ УСЛУГ.
ИХ ВЛИЯНИЕ НА ПРОИЗВОДИТЕЛЬНОСТЬ СЕТИ
Shopov A.I.
QUALITY OF SERVICE SUPPORT ON THE BASIS OF DIFFERENTIATED AND INTEGRATED SERVICES. THEIR INFLUENCE ON NETWORK PRODUCTIVITY
Ключевые слова: Качество обслуживания (QoS), дифференцированные услуги (Differentiated Services - diffserv), интегрированные услуги (Integrated Services - intserv).
Keywords: Quality of service (QoS), differentiated services (Differentiated Services - diffserv), integrated services (Integrated Services - intserv), RSVP protocols RSVP.
Аннотация
В данной статье рассмотрены архитектуры дифференцированных услуг (Differentiated Services - diffserv) и интегрированных услуг (Integrated Services - intserv), использующихся для обеспечения функций QoS на сетевом уровне эталонной модели OSI. Проведен анализ влияния данных услуг на производительность сети.
Abstract
In the given article architectures of differentiated services (Differentiated Services - diffserv) and integrated services (Integrated Services - intserv), used to support functions QoS on the level of network of reference model OSI. The analysis of influence of given services on productivity of network will be carried out.
Цель качества обслуживания (Quality of Service) - предоставление гарантированных и дифференцированных услуг в масштабах любой мультисервисной сети, для поддержания различных видов трафика, предъявляющих различные требования к характеристикам сети. Дифференциация услуг обусловливает наличие нескольких уровней качества обслуживания, каждому из которых соответствует собственная архитектурная модель обеспечения функций QoS. При этом решения QoS должны быть хорошо маштабируемы, для того чтобы удовлетворять запросы постоянно растущего числа пользователей сетей. Но нельзя забывать, что сервисы QoS, выполняя свои функции, в некоторых случаях могут оказать и негативное влияние на общую производительность сети.
Differentiated Services (DiffServ) - это масштабируемая архитектура, предназначенная для организации дифференцированного обслуживания нескольких агрегированных информационных потоков. Дифференцированный уровень обслуживания может задаваться как в терминах некоторых количественных параметров (пропускная способность, допустимые величины задержек и потерь пакетов), так и в терминах относительных приоритетов одних служб по отношению к другим.
Архитектура DiffServ предполагает существование соседствующих DiffServ-доменов -связных областей сети, в пределах каждой из которых проводится единая политика по предоставлению определенного множества служб передачи пакетов, обеспечивающих соответствие параметров передачи тому или иному набору требований. Такие наборы требований, как правило, называют классами обслуживания. Для каждого информационного потока, поступающего в DiffServ-домен, пограничные устройства выполняют его классификацию т.е. определяют, в соответствии с каким классом обслуживания следует пересылать через DiffServ-домен данный поток. Классификация производится, как правило, на основании анализа заголовков пакетов, но при этом могут приниматься во внимание и другие параметры, предусмотренные производителем маршрутизатора. В результате выполнения классификации каждому пакету ставится в соответствие номер некоторого класса обслуживания, реализованного в данном DiffServ-домене. Такой номер класса обслуживания называется DiffServ CodePoint (DSCP). Выбранное значение
DSCP записывается в заголовок IP пакета, для чего используются 6 бит поля дифференцированной услуги (DS), которое входит в байт типа обслуживания (Type of Service - ToS) из заголовка пакета Internet Protocol (IP) Version 4 или байт класса трафика (Traffic Class) пакета IP Version 6. Это позволяет иметь в DiffServ-домене до 64-х различных классов обслуживания (для IPv4), хотя следует отметить, что в настоящее время стандартизировано лишь несколько значений DSCP.
Для каждого класса обслуживания в пределах DiffServ-домена устанавливается набор требований, которым должен соответствовать поток информации, поступающий в DiffServ-домен.
Пограничные устройства DiffServ-домена с помощью классификатора классифицируют информационные потоки, поступающие в сеть, путем установки соответствующего значения поля DSCP. А также проводят мониторинг входящего в сеть трафика с целью проверки его соответствия установленному профилю (классу) с помощью функций дозирования трафика, выравнивания трафика и отбрасывания пакетов.
Функция дозирования проверяет трафик на соответствие заданному профилю на основании дескриптора трафика. Результаты проверки передаются либо функции выравнивания трафика, либо функции отбрасывания пакетов для принятия соответствующего решения в отношении "плановых" и "внеплановых" пакетов.
Функция выравнивания трафика (traffic shaping) осуществляет задержку пакетов путем их буферизации с целью удовлетворения параметров заданного профиля.
Функция отбрасывания пакетов осуществляет отбрасывание всех пакетов, удовлетворяющих параметрам заданного профиля трафика. Это действие часто называют также ограничением трафика (traffic policing).
Данные процедуры необходимы, так как DiffServ-домен может обеспечить передачу потока информации в соответствии с классом обслуживания, только если поток соответствует требованиям данного класса. Например, DiffServ-домен может гарантировать передачу информации с заданной задержкой только при условии, что интенсивность поступления информации не будет превышать некоторое пороговое значение, так как в противном случае ухудшатся параметры пересылки пакетов всех информационных потоков, а не только того, интенсивность которого превысила пороговое значение.
Внутренние маршрутизаторы DiffServ-домена обрабатывают значение DSCP, записанное в поле DS заголовка пакета, и в соответствии с его конкретным значением пересылают пакет следующему маршрутизатору, обеспечивая при этом соблюдение того или иного набора характеристик. Набор таких характеристик, обеспечиваемых на участке передачи между двумя соседними маршрутизаторами, называется Per-Hop Behavior (PHB-политика). В архитектуре DiffServ PHB-политики являются минимальными строительными блоками, из которых строятся различные классы обслуживания, реализуемые в DiffServ-домене. Конкретные механизмы, которые могут быть использованы для создания различных PHB-политик, могут отличаться в маршрутизаторах разных моделей или производителей. Как правило, PHB-политики настраиваются на основе таких низкоуровневых механизмов, как, например, очереди с приоритетами или очереди с весами.
Архитектура DiffServ позволяет организовать внутри DiffServ-домена несколько виртуальных служб передачи информации, которые будут выполнять пересылку потоков данных, обеспечивая при этом максимально возможное соответствие параметров передачи соответствующим классам обслуживания (но не гарантируя полного соответствия). Надо отметить, что в DiffServ не предусматриваются каких-либо механизмов уведомления сетевых устройств со стороны приложений о том, сколько ресурсов им требуется или какое количество потоков они планируют пересылать. В этом плане архитектура DiffServ соответствует традиционной архитектуре сети Интернет, когда на сетевых устройствах не запоминается информация об активных потоках, а сеть в целом является сетью без состояния. При этом в сетевых устройствах хранятся только правила обработки пакетов, а в каждом пакете содержится вся информация, необходимая для его доставки получателю. Корректная передача па-
кетов обеспечивается за счет того, что все промежуточные устройства выполняют идентичный алгоритм обработки пакетов.
Следует особо отметить хорошую масштабируемость архитектуры DiffServ. Относительно «дорогие» операции по классификации трафика выполняются только при поступлении информации в DiffServ-домен на его границе. А внутренние маршрутизаторы, в том числе и обслуживающие магистраль сети, по которой одновременно передается большое число потоков, используют поле DS заголовка пакетов. Такая обработка лишь незначительно усложняет традиционный процесс анализа сетевых пакетов и может быть весьма эффективно реализована в маршрутизаторах. Кроме того, при применении DiffServ не требуется выполнения запроса на выделение ресурсов, требуемых для того или иного потока, поэтому на выполнение этого действия не затрачивается время. В результате существенно выигрывают кратковременные потоки, время существования которых сравнимо со временем, затрачиваемым на обмен служебной информацией, необходимой для выполнения резервирования.
Существует и ряд недостатков службы DiffServ. Во-первых, DiffServ практически может быть использована лишь для агрегированных макропотоков, препятствием применения ее для обслуживания микропотоков является относительно небольшое число классов обслуживания, которые могут быть реализованы в DiffServ-домене. Во-вторых, эта служба не гарантирует для обслуживаемых потоков точного выполнения установленных для этих потоков требований к параметрам QoS. Фактически вместо резервирования сетевых ресурсов для каждого агрегированного потока выполняется попытка обеспечить относительное упорядочивание агрегированных потоков, так что с одним агрегированным потоком будут «обращаться лучше», чем с другим, в зависимости от правил обслуживания, определенных для каждого агрегированного потока.
Архитектура Integrated Services (IntServ) и реализующая эту архитектуру интегрированная служба включает ряд механизмов, которые обеспечивают требуемый уровень QoS при передаче пакетов определенных двухточечных или групповых сетевых соединений (микропотоков) «из конца в конец», т.е. для всего пути, по которому передается информация. Архитектура IntServ была разработана в результате реализации предложений, разработанных на основе выводов из проведенных в начале 1990 годов экспериментов по многоадресной трансляции через Интернет заседаний комитетов Internet Engineering Task Force (IETF). Главный вывод состоял в том, что приложения реального времени зачастую не могут хорошо работать через Интернет из-за меняющихся задержек передачи пакетов данных при прохождении ими очередей на коммуникационных устройствах и потерь пакетов при перегрузках этих устройств. Был также сделан вывод о необходимости разработки механизмов, которые будут в реальном времени обеспечивать заданные уровни параметров передачи пакетов для всего маршрута, по которому передается информация, в том числе путем резервирования требуемой для этого полосы пропускания каналов.
В разработанных предложениях под термином Integrated Services понимается модель работы сети Интернет, включающая традиционную, так называемую «best-effort», службу доставки информации, службу, обеспечивающую пересылку пакетов с гарантированным соблюдением определенных параметров передачи, и службу доставки в режиме управляемого распределения пропускной способности каналов.
Архитектура IntServ является надстройкой над стандартной моделью передачи данных в Интернет, расширяющей ее новой функциональностью. Она позволяет сочетать службы передачи трафика реального времени и службу управляемого распределения канальных ресурсов совместно с обычным способом передачи информации. Для обеспечения гарантированных параметров передачи пакетов в IntServ используется механизм предварительного резервирования ресурсов на маршрутизаторах. Такой подход требует хранения на маршрутизаторах некоторой информации об активных потоках, что существенно отличает модель IntServ от традиционной схемы работы сети Интернет. Управление трафиком в IntServ реализуется с помощью трех компонент: планировщика пакетов, классификатора и обработчика запросов на резервирование. Планировщик пакетов отвечает за отправку пакетов в соответ-
ствии с их приоритетами. Для этого он может, например, использовать набор очередей, а также какие-либо другие механизмы. Задача классификатора - определить, какой уровень обслуживания требуется каждому пакету, поступающему в маршрутизатор. Обработчик запросов на резервирование принимает решение о возможности или невозможности удовлетворения того или иного запроса на резервирование и в случае, если резервирование возможно, выполняет необходимые действия.
Для передачи запросов на резервирование в IntServ применяется специальный протокол RSVP (ReSerVation Protocol). В соответствии с этим протоколом отправители информации рассылают специальные сообщения RSVP Path по уникальному (unicast) или групповому (multicast) адресу. Маршрутизаторы, в которых реализована поддержка протокола RSVP, получая такие сообщения, запоминают информацию о пути прохождения RSVP трафика. Получатели информации, желающие принимать данные с теми или иными параметрами передачи, отправляют сообщение RSVP Resv. Это сообщение пересылается RSVP маршрутизаторами в обратном по отношению к RSVP Path направлении. Получив такое сообщение, каждый маршрутизатор, поддерживающий RSVP, пытается выполнить резервирование и пересылает пакет следующему RSVP маршрутизатору на пути к источнику информации. Резервирование считается успешным, если всем RSVP маршрутизаторам между отправителем и получателем информации удалось зарезервировать необходимые ресурсы.
Таким образом, IntServ и RSVP наделяют сеть достаточно мощными возможностями, которые позволяют весьма эффективно передавать данные, чувствительные к параметрам передачи. Особенно следует отметить тот факт, что RSVP позволяет выполнять резервирование для каждого отдельного микропотока (под микропотоком понимается совокупность пакетов с зафиксированными значениями IP адресов отправителя, получателя и номерами соответствующих портов). IntServ является единственной средством обеспечения QoS, поддерживающей работу с информационными потоками с точностью до микропотоков.
Однако у протокола RSVP и в целом у архитектуры IntServ имеется ряд недостатков. С одной стороны, управление распределением ресурсов требуется как раз в тех каналах, емкость которых ограничена, а ее расширение затруднено. С другой стороны, если емкости недостаточно, то может получиться так, что зарезервировать емкость для большого количества соединений окажется невозможно ввиду ограниченности телекоммуникационных ресурсов. При этом резервирование емкости каналов для некоторых потоков отрицательно сказывается на качестве обслуживания остальных потоков даже в периоды, когда зарезервированная емкость временно не используется.
Отметим также, что IntServ не предусматривает каких-либо средств обеспечения QoS для макропотоков, что существенно ограничивает область применения IntServ.
Далее, ввиду того что на маршрутизаторах запоминаются и поддерживаются состояния активных информационных потоков, возникает серьезная проблема с возрастанием нагрузки на маршрутизаторы и с масштабируемостью службы IntServ, особенно в высокоскоростных магистральных сетях.
Кроме того, для использования протокола RSVP и модели IntServ необходимо, чтобы приложения выполняли специальные RSVP запросы на резервирование сетевых ресурсов по пути передачи информации. Если при разработке новых приложений реализовать необходимую функциональность не представляется сложным, то для многочисленных существующих сетевых приложений необходимость таких значительных изменений является серьезной проблемой.
RSVP требует включения в состав ПО маршрутизаторов дополнительных программных модулей, реализующих довольно сложные алгоритмы по выполнению резервирования, что приводит к существенному повышению стоимости моделей маршрутизаторов, поддерживающих IntServ и RSVP.
Исходя из изложенного выше материала, можно сделать выводы, что архитектура дифференцированных услуг является достаточно масштабируемой, так как требует от коммутационного оборудования минимума вычислений и не перегружает сеть передачей служебной информации. Это достигается за счет того, что все сложные операции по классифи-
кации потоков информации проводятся единожды на границах DiffServ-домена, а внутренние коммутаторы действуют согласно стандартным правилам, определенным для того или иного класса, не выполняя дополнительных вычислений. Но при этом данная архитектура не дает гарантий точного выполнения установленных для информационных потоков требований к параметрам QoS, а лишь старается обеспечить максимально возможное соответствие этих параметров. Т.е. во время пиковой нагрузки некоторые пакеты могут быть задержаны или даже отброшены совсем, что является неприемлемым, например, для трафика реального времени и снижает общую производительность сети.
Интегрированные услуги, напротив, гарантируют каждому потоку выполнение определенных требований QoS, но при этом они не могут работать с большим количеством потоков, так как иногда не представляется возможным зарезервировать емкость пропускных каналов для большого числа потоков. Также следует отметить, что для работы IntServ требуется довольно весомая часть коммутационных ресурсов, затрачиваемая для передачи служебной информации протокола RSVP, резервирования ресурсов, выполнения дополнительных вычислений, хранения информации об активных потоках. Можно говорить о том, что данные средства применимы прежде всего внутри корпоративных сетей для решения ограниченного круга задач, действительно нуждающихся в предварительном резервировании сетевых ресурсов при условии относительно небольшого числа активных RSVP соединений.
Следует отметить, что и у дифференцированных и у интегрированных услуг в глобальных сетях могут возникать проблемы совместимости оборудования различных производителей и проблемы совместимости политик резервирования или PHB-политики, реализуемых различными операторами. Так как эти архитектуры еще являются слабо стандартизованными.
