Технология IntServ

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

Рабочая группа IЕТF определила протокол RSVP как сигнальный протокол для архитектуры IntServ. Этот протокол позволяет приложениям посылать сигналы в сеть о своих QoS-требованиях для каждого потока. Чтобы определить количественные характеристики этих требований с целью управления доступом, используются служебные параметры.

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

На рис. 3.3 показаны основные модули, информация о потоке данных и информация об управляющих потоках клиента и маршрутизатора, поддерживающих протокол RSVP.

Перед тем, как зарезервировать ресурсы, RSVP-demon маршрутизатора соединяется с двумя локальными модулями принятия решения — модулем управления доступом (admission control) и модулем управления политикой (policy control). Модуль управления доступом определяет, имеет ли узел достаточно свободных ресурсов для обеспечения запрошенного уровня QoS. Модуль управления политикой определяет, есть ли у пользователя администраторские права, для того чтобы произвести резервирование. Если какая-либо из проверок не прошла, RSVP-demon отправляет сообщение об ошибке процессу приложения, которое создало запрос. Если обе проверки прошли нормально, RSVP-demon устанавливает параметры классификатора пакетов (packet classifier) и планировщика пакетов (packet scheduler) для получения нужного уровня QoS. Классификатор пакетов определяет класс QoS для каждого пакета, а планировщик пакетов управляет передачей пакетов, основываясь на их классе QoS. Взвешенный алгоритм равномерного обслуживания очередей (Weighted Fair Queuing - WFQ) и взвешенный алгоритм произвольного раннего обнаружения (Weighted Random Early Detection - WRED) обеспечивают поддержку QoS на уровне планировщика.

Рис. 3.3. Реализация протокола RSVP в узлах и маршрутизаторах

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

Резервирование всегда должно следовать по одному и тому же пути. В случае выхода из строя линии связи маршрутизатор должен сообщить об этом RSVP-demon, чтобы генерируемые им RSVP-сообщения передавались по новому пути.

Процесс установки резервирования состоит из следующих шагов:

♦ отправители данных посылают управляющие сообщения RSVP-РАТН по тому же пути, по которому они отправляют обычный трафик с данными. В этих сообщениях описываются данные, которые уже отправляются или только будут отправляться;

♦ каждый RSVP-маршрутизатор перехватывает РАТН-сообщения, сохраняет IP-адрес предыдущей точки назначения, записывает вместо него свой собственный адрес и отправляет обновленное сообщение дальше по тому же пути, по которому передаются данные приложения;

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

♦RSVP-маршрутизаторы определяют, могут ли они удовлетворить эти RESV-запросы. Если нет, они отказывают в резервировании. Если да, то они объединяют полученные запросы на резервирование и отсылают запрос предыдущему маршрутизатору;

♦отправители, получив запросы на резервирование ресурсов от соответствующих маршрутизаторов, считают резервирование ресурсов состоявшимся.

Функции RSVP-компонентов представлены в табл. 3.9.

Таблица 3.9

Функции RSVP-компонентов

Компонент	Функция
RSVP-отправитель (RSVP sender)	Приложение, инициирующее отправку трафика в RSVP-сеансе. Спецификации потока, которые RSVP-отправители могут передавать по RSVP-сети: - средняя скорость передачи данных; - максимальный размер всплеска.
RSVP-получатель (RSVP receiver)	Приложение, которое получает трафик в RSVP-сеансе. Во время конференции или при передаче голоса по протоколу IP (VоIP) приложение может играть роль и RSVP-отправителя, и RSVP-получателя. Спецификации потока, который RSVP-получатели могут передавать по RSVP-сети: - средняя скорость передачи данных; - максимальный размер всплеска: - QoS, включая: - гарантированное обслуживание - в РАТН-сообщениях также описываются максимально возможные задержки в сети; - обслуживание с управляемой нагрузкой - маршрутизаторы гарантируют только то, что сетевые задержки будут минимальны

В табл. 3.10 представлено сравнение технологий DiffServ и IntServ.

Таблица 3.10

Сравнение технологий DiffServ и IntServ

Показатели сравнения	Технология DiffServ	Технология IntServ
Методы обеспечения QoS	Применение алгоритмов обработки пакетов в очередях узлов сети	Приложение запрашивает необходимый уровень QoS, протокол RSVP резервирует необходимые ресурсы сети
Классы обслуживания	На уровне приоритизации	Предоставляет гарантийное обслуживание
Процедуры установления соединения	Нет	Да
Предоставление долговременных гарантий QoS	Да (соответствующие параметры на узлах сети не сбрасываются во время отсутствия соединения)	Нет (обеспечение QoS предоставляется только на время соединения)
Наличие служебного трафика во время соединения	Отсутствует	Да (используется большой объем дополнительной информации для процедур установления, поддержания и разъединения каждого соединения)
Масштабируемость сети	Высокая	Низкая
Сложность реализации	Низкая	Высокая
Применение технологии на оборудовании различных производителей	Могут быть трудности	Да
Возможная интеграция в сети МРLS	Да	Да
Рекомендуемые области применения	На магистральных сетях, с минимальными требованиями QoS	На сетях масштаба LAN и МАN для абонентов, использующих приложения с высокими требованиями QoS

Дата добавления: 2015-10-21