Протокол RSVP

Введение

Протокол резервирования ресурсов (Resource Reservation Protocol — RSVP) представляет собой протокол управления сетью, позволяющий Internet-приложениям использовать различное качестао обслуживания (Quality of Service — QoS) для разных потоков данных. Требуемая скорость! обработки данных сетью зависит от приложения. Некоторые приложения, в том числе традиционные интерактивные и пакетные, нуждаются в надежной , доставке данных, но не предъявляют строгих требований к ее своевременности. Более ; новые типы приложешй, такие как видеоконференции, IP-телефония и другие мультимедийные коммуникации, требуют обратного: данные должны доставляться вовремя, но не обязательно с гарантией. предназначен для обеспечения в IP-сетях возможности выполнять различные требования по производительности, предъявляемые разными типами приложений.

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

Первые варианты протокола RSVP были разработаны совместно Институтом научной информации (Information Sciences Institute — ISI) при Южнокалифорнийском уни- версйтете (University of Southern California — USC) и исследовательским центром Xerox в Пало-Альто (Xerox’s Palo Alto Research Center — PARC). Позже проблемная группа проектирования Internet (Internet Engineering Task Force — IETF) предложила открытую версию RSVP, созданную на основе версии USC и PARC. Данная версия RSVP описана в RFC 2205. В этой главе описываются функциональные возможности RSVP, касающиеся потоков данных, качества обслуживания, запуска сеансов, стиля резервирования ; и реализации "мягкого" состояния. Среда RSVP показана на рис. 50.1. й -ii

Потоки данных протокола RSVP

RSVP поток данных представляет собой последовательность дейтаграмм, имеющих . один источник и получатель (последний может представлять собой как одну, так и не- . сколько физических станций). С понятием потока данных тесно связано качество обслуживания. Требования QoS передаются по сети путем спецификации потока (flow specification). Она представляет собой структуру данных, используемую узлами в объединенных сетях для запросов специальных услуг. Спецификация потока описывает уровень обслуживания потока данных. Существует три типа потоков данных, соответствующих классам обслуживания RSVP.

1.      Гарантированная доставка.

2.       Гарантированная скорость.

3.       Гарантированная задержка.

Рис. 50.1. В протоколе RSVP информация об узле доставляется получателям вместе с потоками данных

Режим негарантированной доставки (best-effort traffic) представляют собой традиционные потоки данных протокола IP. Этот режим применяется при передаче файлов (например, электронной почты), монтировании дисков, интерактивной регистрации, а также при электронных транзакциях. Эти приложения требуют гарантированной доставки данных независимо от того, сколько времени на это потребуется. Для упорядочения принятых случайным образом дейтаграмм и для запроса повторной передачи потерянных и искаженных дейтаграмм передача данных гарантированной доставки опирается на собственные механизмы протокола TCP.

Режим гарантированной скорости (rate-sensitive traffic) требует гарантированной скорости передачи от источника к получателю. Примером такого приложения являются видеоконференции Н.323, работающие под управлением ISDN (Н.320) или ATM (Н.310), но применяемые также в Internet и во многих интранет-сетях протокола IP. Шифрование Н.323 имеет постоянную (или почти постоянную)

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

Режим гарантированной максимальной задержки (delay-sensitive traffic) применяется к потокам данных, требующим своевременной доставки и соответствующего изменения скорости. Например, скорость передачи видео MPEG-II колеблется от 3 до 7 Мбит/с, в зависимости от того, насколько интенсивно изменяется изображение. Если на экране показывают окрашенную стену, то достаточно 3 Мбит/с, а для океанских волн потребуется 7 Мбит/с. Источник видеосигнала MPEG-II посылает ключевые и дельта-фреймы. Обычно в секунду передается 1 или 2 ключевых фрейма с изображением всей картинки и от 13 до 28 дельта-фреймов, описывающих изменения ключевого фрейма. Дельта-фреймы, как правило, значительно меньше ключевых. В результате скорость передачи фреймов может изменяется в широких пределах. Однако для нормальной работы кодека (кодера-декодера) необходимо, чтобы каждый фрейм передавался в течение заданного времени. Необходимо согласовать определенный приоритет передачи данных в дельта-фреймах. К службам RSVP, поддерживающим передачу данных с гарантированной задержкой, относятся служба управления задержками (не являющаяся службой реального времени) и прогнозирующая служба (служба реального времени).

Обработка потоков данных по протоколу RSVP

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

Примечание

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

При многоадресатной сеансе копия каждой дейтаграммы, переданной одним источником, отправляется нескольким получателям. Одноадресатный сеанс характеризуется одним источником и одним получателем. Иногда адреса источника и получателя RSVP указывают на один и тот же Internet-узел. Однако один узел может содержать несколько логических источников и получателей, различающихся номерами портов, так что каждый номер порта соответствует отдельному приложению. Если RSVP отслеживает такую информацию о приложении, то одноадресатный сеанс может привести к передаче данных нескольким приложениям, расположенным на одном узле-получателе.

Качество обслуживания RSVP

В контексте RSVP качество обслуживания (Quality of Service — QoS) является атрибутом, описанным в спецификациях потока, которые используются для определения маршрута обмена данными между объектами (маршрутизаторами, получателями и источниками). используется для определения QoS узлами и маршрутизаторами, узлы используют RSVP для запросов уровня QoS потоков данных приложений. Маршрутизаторы применяют RSVP для доставки запросов QoS другим маршрутизаторам по маршруту следования потока данных. Таким образом, RSVP поддерживает состояние маршрутизаторов и узлов для предоставления запрашиваемой службы.

Запуск сеанса RSVP

Для того чтобы запустить многоадресатный сеанс RSVP, получатель первым присоединяется к многоадресатной группе, определенной IP-адресом получателя при помощи протокола IGMP. При одноадресатном сеансе одноадресатная маршрутизация выполняет ту же роль, что и IGMP совместно с адресом протокола PIM (Protocol-Independent Multicast, независимый от протокола групповой адрес) для многоадресатного сеанса. После того как получатель присоединится к группе, потенциальный источник начинает посылать сообщения по маршруту RSVP на IP-адрес получателя. Приложение- получатель получает маршрутное сообщение и начинает посылать соответствующие запросы на резервирование, определяющие желательные признаки потока, используя протокол RSVP. После получения запроса на резервирование приложение-источник начинает отправлять пакеты данных.

Стиль резервирования RSVP

Стилем резервирования называют набор управляющих переменных, которые определяют количество поддерживаемых параметров. поддерживает два основных класса резервирования: раздельное и совместное. При раздельном резервировании каждому источнику в каждом сеансе выделяется свой поток. Совместное резервирование применяется для нескольких источников, которые заведомо не пересекаются друг с другом. На рис. 50.2 показаны схемы раздельного и совместного резервирования RSVP и их назначение. Все возможные варианты "стиль/назначение" описываются ниже.

Стиль групповой фильтрации

Стиль групповой фильтрации (Wildcard-Filter — WF) заключается в совместном или групповом резервировании. WF-резервирование представляет собой одиночное резервирование, при котором смешиваются все источники. Резервирование можно представить как "трубу" с совместным доступом, размер которой определяется наибольшим из ресурсов, запрошенных всеми получателями данного канала, независимо от количества источников. Резервирование распространяется на все узлы источников, в том числе автоматически — на новые источники по мере их появления.

Рис. 50.2. поддерживает как совместное, так и индивидуальное резервирование

Стиль фиксированной фильтрации

Стиль фиксированной фильтрации (Fixed-Filter — FF) определяет индивидуальное резервирование с явным указанием масштаба. При использовании FF-стиля создаются отдельные запросы на резервирование для пакетов данных, поступающих из разных источников. Масштаб резервирования определяется явно, по списку источников. Общее резервирование канала для данного сеанса представляет собой совокупность FF-резервирований для всех источников, указанных в запросе. Запросы на FF-резервирование от разных получателей, но для одного источника, должны быть объединены для совместного резервирования в данном узле.

Стиль явного совместного резервирования

Стиль явного совместного резервирования (Shared-Explicit — SE) определяет совместное резервирование среды с явным указанием масштаба. При использовании SE-сгиля создается одиночное резервирование, в котором смешиваются все источники. Как и при FF-резервировании, набор источников (и, следовательно, масштаб) явно определяются получателем, создающим данное резервирование.

Применение стилей резервирования RSVP

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

Гибкое состояние RSVP

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

Механизмы протокола RSVP обеспечивают общие средства создания и обслуживания состояния распределенного резервирования многоадресатных и одноадресатных маршрутов доставки.

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

При изменении маршрута следующее маршрутное сообщение инициализирует состояние нового маршрута. Последующие запросы на резервирование устанавливают состояние резервирования. Состояние неиспользуемого сегмента сбрасывается по истечении установленного времени. (Спецификация RSVP требует, чтобы новое резервирование начиналось через 2 секунды после изменения топологии.)

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

Литература:

Руководство по технологиям объединенных сетей, 4-е издание. : Пер. с англ. — М.: Издательский дом «Вильяме», 2005. — 1040 с.: ил. – Парал. тит. англ.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100