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

Н.И. ЛИСТОПАД, И.О.ВЕЛИЧКЕВИЧ

http://www.mpt.gov.by/File/2009_02/Listopad.pdf

Введение

Обеспечение качества обслуживания (QoS) - одно из важнейших требований, предъявляемых к сетям с коммутацией пакетов современными мультимедийными приложениями, системами дистанционного обучения и т. д.

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

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

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

Классификация трафика в сетях телекоммуникаций

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

Характеристики QoS особенно важны в случае, когда сеть передает одновременно трафик разного типа, например, трафик web-приложений и голосовой. Это связано с тем, что различные типы трафика предъявляют разные требования к характеристикам QoS. Добиться синхронного соблюдения характеристик QoS для всех видов трафика очень сложно, поэтому обычно используют следующий подход [1, 2]: классифицируют существующие в сети трафики, относя каждый из них к одному из распространенных типовых видов, а затем добиваются одновременного выполнения определенного подмножества из набора требований QoS.

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

• относительная предсказуемость скорости передачи данных;

• чувствительность трафика к задержкам пакетов и их вариациям;

• чувствительность трафика к потерям и искажениям пакетов.

Предсказуемость скорости передачи данных.

В данном отношении трафик приложений можно условно разделить на два класса:

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

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

Чувствительность трафика к задержкам пакетов. Перечислим основные типы приложений в порядке уменьшения чувствительности к задержкам пакетов [4].

Трафик реального времени включает в себя аудио- и видеоинформацию, критичную к задержкам при передаче. Допустимые значения задержек обычно не превышают 0,1 с. Кроме того, задержка должна иметь малые флуктуации (jitter).

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

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

Чувствительность трафика к потерям и искажениям пакетов. Следует рассмотреть отдельно потери и искажения пакетов.

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

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

свои пределы, поэтому процент потерянных пакетов не может быть большим (не более 1 %).

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

• bandwidth (BW) - полоса пропускания. Описывает номинальную пропускную способность среды передачи информации, определяет ширину канала. Измеряется в bit/s (bps), kbit/s (kbps), Mbit/s (Mbps);

• delay - задержка при передаче пакета;

• jitter - колебание (вариация) задержки при передаче пакетов;

• packet Loss - потери пакетов. Определяет количество (вероятность) пакетов, отбрасываемых сетью во время передачи.

Классы приложений

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

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

Существует немного устойчивых сочетаний характеристик, описывающих определенный класс приложений. При стандартизации технологии ATM, изначально разрабатываемой для поддержания различных типов трафика, установлены четыре класса приложений: А, В, С и D. Для приложений, не относящихся ни к одному из них, принят пятый класс X. Для каждого класса рекомендуется использовать собственный набор характеристик QoS (таблица 1).

Таблица 1

Модели обеспечения QoS

Лучшая возможность (Best Effort Service). В данной модели используются все доступные ресурсы сети без выделения отдельных классов трафика и регулирования. Считается, что лучшим механизмом обеспечения QoS является увеличение пропускной способности. В принципе, это правильно, однако некоторые виды трафика (например, голосовой) очень чувствительны к задержкам пакетов и вариации скорости их прохождения. Модель Best Effort Service даже при наличии больших резервов допускает возникновение перегрузок в случае резких всплесков трафика.

Для обеспечения соответствующего QoS в IP-сетях международная организация IETF (Internet Engineering Task Force) определила две основные модели: Integrated Services (IntServ) и Differentiated Services (DiffServ) [1, 2].

Интегрированный сервис (Integrated Service). Модель интегрированного обслуживания обеспечивает сквозное (End-to-End) качество обслуживания, гарантируя необходимую пропускную способность. IntServ использует протокол сигнализации RSVP (протокол резервирования сетевых ресурсов - Resource ReSerVation Protocol), который обеспечивает выполнение требований ко всем промежуточным узлам [9]. Протокол функционирует следующим образом: узел-источник до передачи данных, требующих определенного нестандартного качества обслуживания (например, постоянной полосы пропускания для передачи видеоинформации) посылает по сети специальное сообщение о пути (path message), содержащее данные о типе передаваемой информации и требуемой пропускной способности. Сообщение передается между маршрутизаторами по всей линии от узла-отправителя до адреса назначения, при этом определяется последовательность маршрутизаторов, в которых необходимо зарезервировать определенную полосу пропускания. Маршрутизатор, получив такое сообщение, проверяет свои ресурсы с целью определения возможности выделения требуемой пропускной способности. При ее отсутствии маршрутизатор запрос отвергает. Если необходимая пропускная способность достижима, то маршрутизатор настраивает алгоритм обработки пакетов таким образом, чтобы указанному потоку всегда предоставлялась требуемая пропускная способность, а затем передает сообщение следующему маршрутизатору вдоль пути. В результате по всему пути от узла-отправителя до адреса назначения резервируется необходимая пропускная способность [10].

Дифференцированное обслуживание (Differentiated Service). Архитектура DiffServ предполагает существование связанных областей сети (DiffServ-доменов), в пределах каждой из которых проводится единая политика по классификации служб передачи пакетов. Классификация производится на основании анализа заголовков пакетов, но при этом могут приниматься во внимание и другие параметры, предусмотренные производителем маршрутизатора. В результате выполнения классификации каждому пакету ставится в соответствие номер некоторого класса обслуживания, реализованного в данном DiffServ-домене. Такой номер класса обслуживания называется DiffServ CodePoint (DSCP). Выбранное значение DSCP записывается в заголовок IP-пакета в поле [14]. Для каждого класса обслуживания администратор DiffServ-домена может установить набор требований к параметрам QoS. После классификации пограничные устройства приводят параметры информационных потоков, поступающих в DiffServ-домен в соответствие с требованиями, устанавливаемыми для выбранных классов обслуживания. При этом часть пакетов может быть помещена в очередь или отброшена, если информация поступает быстрее, чем это разрешено для данного класса обслуживания. Названая процедура необходима, так как почти всегда DiffServ-домен может обеспечить передачу потока информации в соответствии с некоторым классом обслуживания, только если при поступлении этот поток также соответствует некоторому набору параметров. Маршрутизаторы DiffServ-домена обрабатывают значение DSCP и в соответствии с его значением пересылают пакет следующему маршрутизатору, гарантируя при этом соблюдение определенного набора характеристик (PerHop Behavior - PHB), обеспечиваемых на участке передачи между двумя соседними маршрутизаторами. В DiffServ PHB являются минимальными строительными блоками, из которых строятся различные классы обслуживания, реализуемые в DiffServ-домене. Конкретные механизмы, которые могут быть использованы для создания различных PHB, отличаются в маршрутизаторах разных моделей или производителей. Как правило, PHB настраиваются на основе низкоуровневых механизмов, таких как, например, очереди с приоритетами или очереди с весами [5]. Практически подтверждено: архитектура DiffServ действительно позволяет организовать внутри DiffServ-домена несколько так называемых виртуальных служб передачи информации, которые предназначены для выполнения пересылки потоков данных, обеспечивая при этом максимально возможное соответствие параметров передачи соответствующим классам обслуживания (но не гарантируя полного соответствия). Надо отметить,что в DiffServ не предусматривается каких-либо механизмов уведомления сетевых устройств со стороны приложений о том, сколько ресурсов им требуется или какое количество потоков они планируют пересылать [5]. В этом плане архитектура DiffServ соответствует традиционной архитектуре сети Интернет, когда на сетевых устройствах не запоминается информация об активных потоках, при этом в сетевых устройствах хранятся только правила обработки пакетов, а в каждом пакете содержится вся информация, необходимая для его доставки получателю. Корректная передача пакетов обеспечивается за счет того, что все промежуточные устройства выполняют идентичный алгоритм обработки пакетов.

Анализ технологий обеспечения QoS

IntServ определяет два класса по обеспечению гарантированного уровня обслуживания в пакетных сетях, а именно: класс контролируемой загрузки (controlled-load) [12] и класс гарантированного обслуживания (guaranteed QoS) [13]. На основе данной модели (в зависимости от класса обслуживания) для определенного типа трафика может быть предоставлена необходимая полоса пропускания в канале связи, а также обеспечиваться минимальная задержка при передаче пакетов или минимальный уровень их потерь.

Основными компонентами модели IntServ являются следующие функциональные составляющие [3, 5]:

• модуль резервирования ресурсов (flow resource reservation);

• модуль управления доступом (flow admission control);

• классификатор трафика (packet classifier) и диспетчер очередей (packet scheduler).

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

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

Отличительной особенностью протокола резервирования ресурсов RSVP является универсальность, так как отправлять запросы на резервирование может любое приложение, поддерживающее данный протокол. Однако имеется ряд недостатков, препятствующих широкому применению RSVP в пакетных сетях [2, 3].

1. Увеличивается время установления соединения, что собенно нежелательно при функционировании такого протокола, как, например, H.323 (стандарт мультимедийных приложений). Это связано с тем, что протокол работает в два этапа: сначала служебные пакеты RSVP обрабатываются маршрутизаторами на пути от речевого шлюза источника до речевого шлюза назначения (сообщение Path), а затем, если шлюз назначения готов принять речевой поток, они должны обработать служебные пакеты "резервирования", следующие от речевого шлюза назначения к шлюзу источника (сообщение Resv).

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

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

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

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

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

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

• обеспечивает единое понимание того, как должен обрабатываться трафик определенного класса;

• позволяет разделить весь трафик на относительно небольшое число классов и не анализировать каждый информационный поток отдельно;

• нет необходимости в организации предварительного соединения и в резервировании ресурсов;

• не требуется высокая производительность сетевого оборудования;

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

Недостатки модели DiffServ:

• в условиях однородного трафика (например, только голосового) принцип применения приоритетов теряет смысл, и сеть начинает работать в режиме Best Effort Service;

• отдельные внутренние маршрутизаторы могут неадекватно отреагировать на значения битов в поле ToS или даже изменить их;

• поскольку DiffServ работает за счет выборочного сброса пакетов в периоды сетевой перегрузки, то соединения с низким приоритетом вообще могут разорваться во время "всплесков" сетевой активности.

Одной из реализаций модели DiffServ является технология многопротокольной коммутации на основе меток (Multiprotocol Label Switching - MPLS), которая на сегодняшний день стала одной из основных для построения крупных сетей операторов, предоставляющих услуги с обеспечением качества обслуживания. Данная технология предназначена для ускорения коммутации пакетов в транспортных сетях. Основное ее отличие от ранее рассмотренных в том, что MPLS изначально не является технологией обеспечения качества и становится таковой только при использовании протокола RSVP-TE.

На границе сети MPLS маршрутизаторы помечают пакеты специальными метками, определяющими дальнейший маршрут следования пакета к месту назначения. В результате анализируются не адреса IP, a короткие цифровые метки, что существенно снижает сетевую задержку и требования к производительности маршрутизаторов. Для корректного взаимодействия их между собой и обмена информацией о создаваемых метках используются протоколы распределения меток (LDP, CR-LDP, RSVP-TE и др.).

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

Технология MPLS характеризуется высокой масштабируемостью и рассматривается в качестве наиболее перспективной для передачи IP-трафика.

Преимущества технологии MPLS:

• выбор маршрута на основе анализа IP-адреса;

• ускоренная коммутация (сокращает время поиска в таблицах);

• гибкая поддержка QoS, интегрированных сервисов и виртуальных частных сетей;

• эффективное использование явного маршрута;

• сохранение инвестиций в уже установленное ATM-оборудование;

• разделение функциональности между ядром и граничной областью сети.

Однако внедрение технологии MPLS, как правило, связано с организацией высокоскоростной магистрали, что требует установки высокопроизводительного оборудования и, как следствие, серьезных финансовых затрат [6].

Корпоративную сеть можно строить, используя услуги, гарантирующие определенный уровень QoS, которые предлагают операторы связи на основе технологии MPLS. Тем не менее, несмотря на значительные преимущества технологии с точки зрения обеспечения QoS, дополнительная гарантия доставки пакетов может создать проблемы в области масштабируемости. К тому же эта технология внедрена пока еще очень немногими операторами, что ограничивает возможности использования данного варианта. Поэтому в настоящий момент для построения корпоративных мультисервисных сетей, объединяющих небольшое число точек подключения на основе выделенных каналов связи, отсутствует технология, которая в полной мере, с учетом соотношения цена/качество, обеспечивала бы возможности по предоставлению необходимого уровня QoS.

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

Интетро-дифференцированное обслуживание (Integrated Services Operation over Diffserv Networks). Опубликованный в 2000 г. стандарт RFC2998 описывает принципы организации взаимодействия IntServ/RSVP и DiffServ для предоставления QoS от источника получателю. Слабые места одной модели компенсируются соответствующими решениями другой. С одной стороны, плохо масштабируемая IntServ на магистральных участках сети может быть заменена на более простую DiffServ. С другой, с помощью RSVP решается вопрос с неопределенностью получаемого сервиса в DiffServ-сети.

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

Возможна организация двух вариантов взаимодействия протоколов качества обслуживания [8]:

• DiffServ-регион не поддерживает RSVP-сигнализа-цию, и ресурсы выделяются на статической основе;

• обработка RSVP-сообщений производится в DiffServ-регионе.

В первом случае совместная работа основана на статическом соглашении клиента с оператором SLS (спецификация уровня сервиса). В простейшей ситуации описывается значение пропускной способности в DiffServ-сети, получаемое трафиком пользователя: Tx (отправитель) генерирует сообщения Path, которые направляются к узлу Rx (получатель) через DiffServ-регион.

При прохождении через DiffServ-регион содержимое RSVP-сообщений игнорируется, и они пересылаются как

обычный пакет с данными. При получении узлом Rx сообщения Path генерируется запрос на резервирование RESV, который затем направляется обратно к узлу Tx. При успешной обработке запроса каждым совместимым RSVP-маршрутизатором и прохождении через DiffServ-регион сообщение RESV достигает маршрутизатора Er1, который на основании SLS производит сравнение ресурсов, запрашиваемых в сообщении RESV, и ресурсов, доступных в DiffServ-регионе. Если Er1 подтверждает запрос, информация RESV отсылается далее по направлению к узлу Tx. В ином случае сообщение отвергается, и узлу Rx отправляется оповещение об ошибке. В полученном узлом Tx сообщении могут содержаться данные о маркировании соответствующим кодом пакетов, адресуемых в узел Rx. Значение кода определяется по умолчанию или из сообщения RESV.

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

Заключение

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

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

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

Как показывает проведенный анализ, наиболее перспективными и сбалансированными технологиями QoS являются MPLS + RSVP-TE и Int-DiffServ благодаря тому, что объединяют в себе лучшие стороны обеих моделей. Так, в MPLS за счет маршрутизации по меткам возможно более гибкое распределение ресурсов сети, что позволяет использовать несколько альтернативных путей доставки трафика для создания высокоскоростных магистралей, объединения локальных сетей. В свою очередь, Int-DiffServ представляет собой золотую середину соотношения цена/качество. Но и для этих технологий существуют ограничения, не позволяющие применять данные методы. MPLS все еще слабо распространена и является дорогостоящей технологией для корпоративных сетей, а Int-DiffServ требует определенных затрат на реализацию и не может обеспечить высоких показателей по совместимости.

ЛИТЕРАТУРА

1. Копачев, А.Г. Методы управления трафиком в мульти-сервисных сетях // Информатизация образования. - 2004. -№ 4. - С. 69-74.

2. Cisco Systems. DiffServ - The Scalable End-to-End QoS Model / Cisco Systems // Cisco IOS Technologies [Electronic resource]. - 2005. - Mode of access: http://www.cisco.com/en/ US/technologies/tk543/tk766/ 1echnologies_whi1e_papei09186a00800a3e2f_ps6610_P[oducts_White_Papei:hlml. - Date of access: 15.01.2009.

3. Димариа, М.Дж. На что способны QoS? / М.Дж. Дима-риа // Сети и системы связи [Электронный ресурс]. - 2003. -Режим доступа: http://www.ccc.ru/magazine/depot/03_14/ read.html?0301.htm. - Дата доступа: 15.01.2009.

4. Тарасов, A.B. Качество обслуживания в современных сетях / A.B. Тарасов // Провайдинг России [Электронный ресурс]. - 2005. - Режим доступа: http://www.hub.ru/ modules.php?name=Pages&op=showpage&pid=141. - Дата доступа: 15.01.2009.

5. Cisco Systems Quality of Service (QoS) / Cisco Systems // Internetworking Technology Handbook [Electronic resource]. -2005. - Mode of access: http://www.cisco.com/en/US/docs/ internetworking/technology/handbook/QoS.html. - Date of access:

6. Трухан, A.B. Качество обслуживания в сетях телекоммуникаций // Информатизация образования. - 2007.

7. Федодеев, Д. Алгоритмы управления очередями / Д. Фе-додеев// Открытые системы [Электронный ресурс]. - 2007. -Режим доступа: http://www.osp.ru/text/print/302/4659316.html. -Дата доступа: 15.01.2009.

8. Bernet, Y. RFC 2998 - Integrated Services Over Diffserv Networks / Y. Bernet //Rfc Editor [Electronic resource]. - 2000. -Mode of access: http://www.rfc-editor.org/rfc/rfc2998.txt. - Date of access: 15.01.2009.

9. Braden, R. RFC1633 - Integrated Services in the Internet Architecture: an Overview / R. Braden // Internet FAQ Archives [Electronic resource]. - 1994. - Mode of access: http:// www.faqs.org/rfcs/rfc1633.html. - Date of access: 15.01.2009.

10. Braden, Ed.R. Prosecuting international crimes: selectivity and the international criminal law regime / R. Ed. Braden // Information Sciences Institute [Electronic resource]. - 1997. -Mode of access: http://www.isi.edu/in-notes/rfc2205.txt

11. Rosen, E. RFC 3031 - Prosecuting Multiprotocol Label Switching Architecture / E. Rosen // Internet Engineering Task Force [Electronic resource]. - 2001. - Mode of access: http:// www.ietf.org/rfc/rfc3031.txt. - Date of access: 15.01.2009.

12. Wroclawski, J. RFC 2211 - Specification of the Controlled-Load Network Element Service / J. Wroclawski // Rfc Editor [Electronic resource]. - 1997. - Mode of access: http://www.rfc-editor.org/rfc/rfc2211.txt

13. Shenker, S. RFC 2212 - Specification of Guaranteed Quality of Service / S. Shenker // Rfc Editor [Electronic resource]. -1997. - Mode of access: http://www.rfc-editor.org/rfc/rfc2212.txt -Date of access: 15.01.2009.

14. Postel, J. RFC 791 - Internet Protocol / J. Postel // Rfc Editor [Electronic resource]. - 1981. - Mode of access: http:// www.rfc-editor.org/rfc/rfc791.txt. - Date of access: 15.01.2009.