8. Лекция: Методы обеспечения качества обслуживания Архитектура интегрированных услуг (IntServ)
Integrated Service (IntServ, RFC 1633) – модель интегрированного обслуживания. Может обеспечить сквозное (End-to-End) качество обслуживания, гарантируя необходимую пропускную способность. IntServ использует для своих целей протокол сигнализации RSVP, позволяет приложениям выражать сквозные требования к ресурсам и содержит механизмы обеспечения данных требований. IntServ можно кратко охарактеризовать как резервирование ресурсов (Resource reservation).
Протокол rsvp
Данный протокол позволяет приложениям посылать сигналы в сеть о своих QoS-требованиях для каждого потока. Чтобы определить количественные характеристики этих требований с целью управления доступом, используются служебные параметры.
Протокол RSVP применяется в приложениях с групповой рассылкой, таких как приложения аудио- и видеоконференций. Несмотря на то, что изначально протокол RSVP был ориентирован на мультимедийный трафик, с его помощью легко можно резервировать полосу пропускания для однонаправленного трафика, например для трафика сетевой файловой системы (Network File System – NFS) и управляющего трафика виртуальных частных сетей (Virtual Private Networks – VPN).
Протокол RSVP сигнализирует о запросах резервирования ресурсов по доступному маршрутизируемому пути в сети. При этом RSVP не производит собственную маршрутизацию; напротив, этот протокол был разработан для использования других, более мощных протоколов маршрутизации. Как и любой другой IР-трафик, при определении пути для данных и управляющего трафика RSVP полагается на применяемый в сети протокол маршрутизации.
Работа протокола rsvp
Конечные системы используют протокол RSVP для запрашивания у сети определенного уровня QoS от имени потока данных приложения. RSVP-запросы передаются по сети при прохождении каждого узла, который применяется для передачи потока. Протокол RSVP пытается зарезервировать ресурсы для потока данных на каждом из этих узлов.
RSVP-совместимые маршрутизаторы помогают доставить нужные потоки данных в нужную точку назначения. На рис. 8.1 изображены основные модули, информация о потоке данных и информация об управляющих потоках клиента и маршрутизатора, поддерживающих протокол RSVP
Рис.
8.1. Основные модули RSVP
Перед тем как зарезервировать ресурсы, RSVP-демон маршрутизатора соединяется с двумя локальными модулями принятия решения – модулем управления доступом (admission control) и модулем управления политикой (policy control). Модуль управления доступом определяет, имеет ли узел достаточно свободных ресурсов для обеспечения запрошенного уровня QoS. Модуль управления политикой определяет, есть ли у пользователя права для того, чтобы произвести резервирование. Если какая-либо из проверок не прошла, RSVP-демон отправляет сообщение об ошибке процессу приложения, которое создало запрос. Если обе проверки прошли нормально, RSVP-демон устанавливает параметры классификатора пакетов (packet classifier) и планировщика пакетов (packet scheduler) для получения нужного уровня QoS. Классификатор пакетов определяет класс QoS для каждого пакета, а планировщик пакетов управляет передачей пакетов, основываясь на их классе QoS. Взвешенный алгоритм равномерного обслуживания очередей (Weighted Fair Queuing – WFQ) и взвешенный алгоритм произвольного раннего обнаружения (Weighted Random Early Detection – WRED) обеспечивают поддержку QoS на уровне планировщика. Алгоритмы WFQ и WRED рассмотрены ниже.
Во время процесса принятия решения модулем управления доступом резервирование затребованной полосы пропускания производится только в том случае, если для запрашиваемого класса трафика достаточно оставшейся части. В противном случае запрос на доступ отклоняется, но трафик все равно передается с качеством обслуживания, определенным по умолчанию для данного класса трафика. Во многих случаях, даже если запрос на доступ отклонен на одном или нескольких маршрутизаторах, модуль все еще может реализовать приемлемое качество обслуживания, установив резервирование на перегруженных маршрутизаторах. Это возможно из-за того, что другие потоки данных могут не полностью использовать заказанную ими полосу пропускания.
Резервирование всегда должно следовать по одному и тому же одноадресному пути или по многоадресному дереву. В случае выхода из строя линии связи маршрутизатор должен сообщить об этом RSVP-демону, чтобы генерируемые им RSVP-сообщения передавались по новому пути.
Процесс установки резервирования можно разбить на пять отдельных шагов.
Отправители данных посылают управляющие сообщения RSVP PATH по тому же пути, по которому они отправляют обычный трафик с данными. В этих сообщениях описываются данные, которые уже отправляются или только будут отправляться.
Каждый RSVP-маршрутизатор перехватывает РАТН-сообщения, сохраняет IP-адрес предыдущей точки назначения, записывает вместо него свой собственный адрес и отправляет обновленное сообщение дальше по тому же пути, по которому передаются данные приложения.
Станции-получатели выбирают подмножество сеансов, для которых они получили РАТН-информацию и с помощью RSVP RESV-сообщения запрашивают RSVP-резервирование ресурсов у предыдущего маршрутизатора. RSVP RESV -сообщения идут от получателя к отправителю в противоположном направлении по маршруту, пройденному RSVP РАТН-сообщениями.
RSVP-маршрутизаторы определяют, могут ли они удовлетворить эти RESV-запросы. Если нет, они отказывают в резервировании. Если да, то они объединяют полученные запросы на резервирование и отсылают запрос предыдущему маршрутизатору.
Отправители, получив запросы на резервирование ресурсов от соответствующих маршрутизаторов, считают резервирование ресурсов состоявшимся. Т.е реальное резервирование ресурсов осуществляется RESV-сообщениями.
Механизм RSVP-резервирования схематически показан на рис. 8.2.
Рис.
8.2. Механизм RSVP-резервирования
ресурсов