Модель резервирования

Простой запрос резервирования RSVP состоит из "flowspec" (спецификация потока) и "filter spec" (спецификация фильтра); эта комбинация называется "описателем потока". Спецификация flowspec определяет желательное значение QoS. Спецификация фильтра в сочетании со спецификацией сессии определяют тип набора пакетов. Спецификация flowspec используется для задания параметров диспетчеров в узлах, через которые транспортируется поток, а спецификация фильтра – для определения параметров классификатора пакетов. Информационные пакеты, адресованные конкретной сессии, но не удовлетворяющие какой-либо спецификации фильтра обрабатываются без гарантий обеспечения оговоренного QOS.

Спецификация flowspec в запросе резервирования включает в себя значение класса услуг и два набора параметров:

"Rspec”, который определяет желательное значение QoS, и
"Tspec", который описывает информационный поток.

Форматы и содержимое Tspecs и Rspecs определяются общими моделями обслуживания [RFC-2210] и обычно недоступны для RSVP. Конкретный формат спецификации фильтра зависит от того, используется IPv4 или IPv6. Например, спецификация фильтра может использоваться для выделения некоторых составных частей информационного потока, осуществляя отбор с учетом полей пакетов прикладного уровня. В интересах упрощения в описываемом стандарте RSVP спецификация фильтра имеет довольно ограниченную форму: IP-адрес отправителя и, опционно, номер порта SrcPort (UDP/TCP).

Так как номера портов UDP/TCP используются для классификации пакетов, каждый маршрутизатор должен уметь анализировать эти поля. Это вызывает потенциально три проблемы.

Необходимо избегать IP-фрагментации потока данных, для которого желательно резервирование ресурсов. Документ [RFC-2210] специфицирует процедуру вычисления минимального MTU для приложений, использующих средства RSVP.
IPv6 вводит переменное число Internet заголовков переменной длины перед транспортным заголовком, увеличивая трудность и стоимость классификации пакетов.
Эффективная классификация информационных пакетов IPv6 может быть достигнута путем использования поля метки потока заголовка IPv6.
IP-уровень безопасности как для IPv4, так и IPv6 может шифровать весь транспортный заголовок, скрывая номера портов промежуточных маршрутизаторов.

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

A. Резервирование канала

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

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

Б. Переадресация запроса назад

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

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

Базовая модель резервирования RSVP является однопроходной: получатель посылает запрос резервирования вдоль мультикастинг-дерева отправителю данных и каждый узел по пути воспринимает или отвергает этот запрос. RSVP поддерживает улучшенную версию однопроходного варианта алгоритма, известного под названием OPWA (One Pass With Advertising) [OPWA95]. С помощью OPWA управляющие пакеты RSVP, посланные вдоль маршрута для сбора данных, которые могут быть использованы для предсказания значения QoS маршрута в целом. Результаты доставляются протоколом RSVP в ЭВМ получателя. Эти данные могут позднее служить для динамической адаптации соответствующих запросов резервирования.

Содержание раздела