Интегрированные сети ISDN
RSVP в ЭВМ и маршрутизаторе
Рисунок 4.4.9.6.1. RSVP в ЭВМ и маршрутизаторе
1. Потоки данных
RSVP определяет сессию как поток данных с определенным местом назначения и заданным транспортным протоколом. Каждая сессия является совершенно независимой.
Сессия RSVP описывается тремя параметрами: DestAddress, ProtocolId [, DstPort]. DestAddress – IP-адрес места назначения информационных пакетов (уникаст или мультикаст). ProtocolId – идентификатор IP протокола. Опционный параметр DstPort – обобщенный порт места назначения, т.е., еще одна точка демультиплексирования на транспортном или прикладном уровне. DstPort может быть определено полем порта места назначения UDP/TCP.
Заметим, что, строго говоря, не обязательно включать в описание сессии DstPort, когда DestAddress является мультикастным, так как различные сессии могут всегда иметь различные мультикаст-адреса. Однако, DstPort необходим для того, чтобы разрешить более одной уникаст-сессии для одной и той же ЭВМ-получателя.
Для уникастной передачи может быть один получатель, но много отправителей; RSVP может выполнить резервирование для передачи много_точек -> одна_точка.
2. Модель резервирования
Простой запрос резервирования RSVP состоит из "flowspec" (спецификация потока) и "filter spec" (спецификация фильтра); эта комбинация называется "описателем потока". Спецификация flowspec определяет желательное значение QoS. Спецификация фильтра в сочетании со спецификацией сессии определяют тип набора пакетов. Спецификация flowspec используется для задания параметров диспетчеров в узлах, через которые транспортируется поток, а спецификация фильтра – для определения параметров классификатора пакетов. Информационные пакеты, адресованные конкретной сессии, но не удовлетворяющие какой-либо спецификации фильтра обрабатываются без гарантий обеспечения оговоренного QOS.
Спецификация flowspec в запросе резервирования включает в себя значение класса услуг и два набора параметров:
Форматы и содержимое 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 в ЭВМ получателя. Эти данные могут позднее служить для динамической адаптации соответствующих запросов резервирования.
3. Стили резервирования
Запрос резервирования включает в себя набор опций, которые в совокупности называются стилем.
Одна опция резервирования определяет способ резервирования различными отправителями в пределах одной сессии.
Другая опция резервирования контролирует выбор отправителей. В одних случаях каждому отправителю ставится в соответствие определенная спецификация фильтра, в других – таких спецификаций не требуется вовсе. В настоящее время определены следующие стили:
Стиль WF использует опции: "разделенного" резервирования и произвольного выбора отправителя ("wildcard"). Таким образом, резервация со стилем WF создает резервирование, которое делится между потоками всех отправителей. Это резервирование может рассматриваться как общая “труба", чей размер равен наибольшему из ресурсных запросов от получателей, и не зависит от числа отправителей. Стиль резервирования WF передается в направлении отправителей и автоматически распространяется на новых отправителей при их появлении.
Символически можно представить запрос резервирования стиля WF как:
WF( * {Q}),
где звездочка представляет произвольную подстановку при выборе отправителя, а Q – спецификация flowspec
- Стиль FF (Fixed-Filter)
Стиль FF использует опции: "четкое" (distinct) резервирование и "явный" (explicit) выбор отправителя. Таким образом, простой запрос со стилем FF создает точно заданное резервирование для информационных пакетов от определенного отправителя, без совместного использования ресурса с другими отправителями в пределах одной и той же сессии. Символически простой запрос резервирования FF можно представить как:
FF(S{Q}),
где S – выбранный отправитель, а Q – соответствующая спецификация flowspec; эта пара параметров образуют дескриптор потока. RSVP позволяет применение нескольких простых стилей резервирования FF одновременно, при этом формируется список дескрипторов потоков:
FF(S1{Q1}, S2{Q2}, ...)
Полное резервирование в канале для данной сессии характеризуется суммой Q1, Q2, ... для всех отправителей, куда посланы запросы.
- Стиль SE (Shared Explicit)
Стиль SE использует опции: "разделенное” (shared) резервирование и "явный" (explicit) выбор отправителя. Таким образом, стиль резервирования SE формирует одно резервирование, которое совместно используется несколькими отправителями. В отличие от стиля WF, SE позволяет получателю непосредственно специфицировать набор отправителей. Запрос резервирования SE, содержащий flowspec Q и список отправителей S1, S2, ... можно представить в символьной форме как:
SE((S1,S2,...){Q} )
Разделенное резервирование, выполненное с применением стилей WF и SE, пригодно для мультикастных приложений, где несколько источников данных редко осуществляют передачу одновременно. Пакетная передача голоса может служить примером разделенного резервирования, так как лишь ограниченное число людей говорят одновременно. Каждый получатель может направить запрос резервирования WF или SE на удвоенную полосу пропускания, необходимую одному отправителю, позволяя тем самым говорить обоим партнерам одновременно. С другой стороны стиль FF, который осуществляет четкое резервирование для потоков отдельных отправителей, подходит для передачи видеосигналов.
Правила RSVP не позволяют объединять разделенные резервирования с четкими резервированиями, так как эти модели абсолютно несовместимы. Не допускается также объединение явного и произвольного (wildcard) выбора отправителей, так как это может вызвать предоставление незаказанных услуг получателю, который указал тип услуг явно. Таким образом, стили WF, SE и FF не совместимы.
Можно моделировать эффект WF резервирования, используя стиль SE. Когда приложение запрашивает WF, процесс RSVP получателя может использовать местный статус для выполнения эквивалентного резервирования SE, которое в явном виде перечисляет всех отправителей. Однако резервирование SE вынуждает классификатор пакетов в каждом узле в явном виде выбрать каждого отправителя из списка, в то время как WF позволяет классификатору пакетов осуществить произвольный выбор отправителя и порта с помощью "wild card".
Когда список отправителей велик, стиль резервирования WF обеспечивает значительно меньшие издержки, чем SE.
4. Примеры стилей
На Рисунок 4.4.9.6.2. показан пример маршрутизатора с двумя входными интерфейсами IА и IБ, через которые проходят входные потоки, и двумя выходными интерфейсами IВ и IГ, через которые осуществляется переадресация входных потоков. Пусть существует три отправителя S1 (S2 и S3), подключенные к интерфейсам IА и IБ, соответственно. Имеется три получателя R1 (R2 и R3), которые маршрутизированы через выходные интерфейсы IВ и IГ, соответственно. Будем также предполагать, что интерфейс IГ подключен к широковещательной сети, а R2 и R3 достижимы через разные маршрутизаторы, не показанные на рисунке.
Здесь нужно специфицировать мультикастные маршруты в пределах узла, отображенного на Рисунок 4.4.9.6.2. Предположим сначала, что информационные пакеты от каждого из отправителей Si, показанных на рисунке, маршрутизованы на оба выходных интерфейса. При этих предположениях на рисунках 4.4.9.6.3, 4.4.9.6.4 и 4.4.9.6.5 проиллюстрированы стили резервирования WF, FF и SE, соответственно.
