Опубликован: 28.09.2007 | Уровень: специалист | Доступ: платный
Лекция 10:

Алгоритмы мультимедиа

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

Простой запрос резервирования RSVP состоит из flowspec (спецификация потока) и filter spec (спецификация фильтра); эта комбинация называется описателем потока. Спецификация flowspec определяет желательное значение QoS. Спецификация фильтра в сочетании со спецификацией сессии определяют тип набора пакетов.

Спецификация flowspec используется для задания параметров диспетчеров в узлах, через которые транспортируется поток, а спецификация фильтра — для определения параметров классификатора пакетов. Информационные пакеты, адресованные конкретной сессии, но не удовлетворяющие какой-либо спецификации фильтра, обрабатываются без гарантий обеспечения оговоренного QoS.

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

  1. Rspec, который определяет желательное значение QoS, и
  2. Tspec, который описывает информационный поток. По существу этот набор параметров дает возможность определить, распространяется ли данное резервирование на данный конкретный пакет.

В Tspec могут входить: IP-адрес отправителя, адрес получателя, номера портов получателя и отправителя, поле TOS и код транспортного протокола. Чем больше параметров входит в Tspec, тем сложнее задача транзитного маршрутизатора, тем больше и задержка. В случае IPv6 задача существенно упрощается (если ограничиться классификацией по меткам и не анализировать номера портов).

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

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

  1. Необходимо избегать IP-фрагментации потока данных, для которого желательно резервирование ресурсов. Документ [RFC-2210] специфицирует процедуру вычисления минимального MTU для приложений, использующих средства RSVP.
  2. IPv6 вводит переменное число Internet заголовков переменной длины перед транспортным заголовком, увеличивая трудность и стоимость классификации пакетов. Эффективная классификация информационных пакетов IPv6 может быть достигнута путем использования поля метки потока заголовка IPv6.
  3. 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 в ЭВМ получателя. Эти данные могут позднее служить для динамической адаптации соответствующих запросов резервирования.

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

Запрос резервирования включает в себя набор опций, которые в совокупности называются стилем. Одна опция резервирования определяет способ резервирования различными отправителями в пределах одной сессии.

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

  • Стиль WF (WildcardFilter)

    Стиль WF использует опции разделенного резервирования и произвольного выбора отправителя (wildcard). Таким образом, резервирование со стилем WF создает резервирование, которое делится между потоками всех отправителей.

    Резервирование WF может рассматриваться как общая труба, чей размер равен наибольшему из ресурсных запросов от получателей и не зависит от числа отправителей.

    Стиль резервирования WF передается в направлении отправителей и автоматически распространяется на новых отправителей при их появлении. Символически можно представить запрос резервирования стиля WF как:

    WF( * {Q}),

    где звездочка представляет произвольную подстановку при выборе отправителя, а Q — спецификация flowspec.

  • Стиль FF (FixedFilter)

    Стиль FF использует опции четкое (distinct) резервирование и явный выбор отправителя. Таким образом, простой запрос со стилем FF создает точно заданное резервирование для информационных пакетов от определенного отправителя, без совместного использования ресурса с другими отправителями в пределах одной и той же сессии. Символически простой запрос резервирования FF можно представить как:

    FF(S{Q}),

    где S — выбранный отправитель, а Q — соответствующая спецификация flowspec; эта пара параметров образует дескриптор потока. RSVP позволяет применение нескольких простых стилей резервирования FF одновременно, при этом формируется список дескрипторов потоков:

    FF(S1{Q1}, S2{Q2}, ...)

    Полное резервирование в канале для данной сессии FF характеризуется суммой 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 позволяет классификатору пакетов осуществить произвольный выбор отправителя и порта с помощью wildcard. Когда список отправителей велик, стиль резервирования WF обеспечивает значительно меньшие издержки, чем SE.

Примеры стилей

На рис. 10.24. показан пример маршрутизатора с двумя входными интерфейсами IА и IБ, через которые проходят входные потоки, и двумя выходными интерфейсами IВ и IГ, через которые осуществляется переадресация входных потоков. Пусть существует три отправителя S1, S2 и S3, подключенные к интерфейсам IА и IБ, соответственно. Имеется три получателя R1, R2 и R3, которые маршрутизированы через выходные интерфейсы IВ и IГ, соответственно. Будем также предполагать, что интерфейс IГ подключен к широковещательной сети, а R2 и R3 достижимы через разные маршрутизаторы, не показанные на рисунке.

Здесь нужно специфицировать мультикастные маршруты в пределах узла, отображенного на рис. 10.24. Предположим сначала, что информационные пакеты от каждого из отправителей Si, показанных на рисунке, маршрутизованы на оба выходных интерфейса. При этих предположениях на рисунках 10.25, 10.26 и 10.27 проиллюстрированы стили резервирования WF, FF и SE соответственно.

Конфигурация маршрутизатора

Рис. 10.24. Конфигурация маршрутизатора

Для простоты эти примеры показывают flowspec как одномерное кратное повторение некоторого базового качества ресурса B. Колонка "Резервирует" отображает запросы резервирования RSVP, полученные через выходные интерфейсы IВ и IГ, а колонка "Получает" — результирующее состояние резервирования для каждого интерфейса. Колонка "Посылает" показывает запросы резервирования, посланные предшествующим узлам (IА и IБ). В колонке "Резервирует" каждая рамка представляет один зарезервированный виртуальный канал с соответствующим дескриптором потока.

Рис. 10.25, демонстрируя стиль WF, приводит две ситуации, в которых требуется объединение.

  1. Каждый из двух узлов, следующих за интерфейсом IГ, посылают независимые запросы резервирования RSVP; эти два запроса должны быть объединены в одну спецификацию flowspec (3B), которая используется для выполнения резервирования в интерфейсе IГ.
  2. Резервирования для интерфейсов IB и IГ должны быть объединены, чтобы осуществить переадресацию запросов резервирования далее и получить спецификацию flowspec (4B).
Пример резервирования WF (Wildcard-Filter)

Рис. 10.25. Пример резервирования WF (Wildcard-Filter)

На рис. 10.26 проиллюстрирован стиль резервирования FF (Fixed-Filter). У каждого выходного интерфейса имеется отдельное резервирование для каждого запрошенного источника, но это резервирование будет общим для всех получателей, которые послали запрос. Дескрипторы для получателей S2 и S3, полученные через выходные интерфейсы IВ и IГ, вкладываются в пакеты запросов, направляемых предыдущему узлу (IБ). С другой стороны, три различные дескриптора потоков, специфицирующих отправителя S1, объединяются в один запрос FF(S1{4B}), который посылается предыдущему узлу (IА).

На рис. 10.27 показан пример стиля резервирования SE. Когда резервирования стиля SE объединяются, результирующая спецификация фильтра является объединением исходных спецификаций, а результирующая спецификация flowspec равна наибольшей из flowspec.

Пример резервирования FF (Fixed-Filter)

Рис. 10.26. Пример резервирования FF (Fixed-Filter)
Пример резервирования SE (Shared-Explicit)

Рис. 10.27. Пример резервирования SE (Shared-Explicit)

Приведенные примеры предполагают, что информационные пакеты от S1, S2 и S3 маршрутизируются через оба выходных интерфейса. Нижняя часть рис. 10.24 показывает еще одно предположение о маршрутизации: информационные пакеты от S2 и S3 не переадресуются интерфейсу IВ, например, из-за того, что сеть обеспечивает более короткий путь для пакетов отправителя к R1. Рис. 10.25 показывает пример резервирования WF именно при этом предположении (стрелками отмечены допустимые маршруты). Так как нет пути от IБ к IВ, резервирование, переадресуемое интерфейсом IБ, рассматривает резервирование только для интерфейса IГ.

Наталья Шульга
Наталья Шульга

Курс "информационная безопасность" .

Можно ли на него записаться на ПЕРЕПОДГОТОВКУ по данному курсу? Выдается ли диплом в бумажном варианте и высылается ли он по почте?

Мария Архипова
Мария Архипова
Александр Картаков
Александр Картаков
Россия