Технология 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-компонентов

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

Таблица 3.10

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