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

Функциональная спецификация RSVP. Формат сообщений RSVP

Сообщение RSVP состоит из общего заголовка, за которым следует тело сообщения, состоящее из переменного числа объектов переменной длины. Для каждого типа сообщения RSVP существует набор правил допустимого выбора типов объектов. Эти правила специфицированы с использованием стандартных форм Бакуса-Наура (BNF), дополняемых опционными субпоследовательностями, которые помещаются в квадратные скобки. Объекты следуют в определенном порядке. Однако, во многих случаях (но не во всех) порядок объектов не играет роли. Приложение должно создавать сообщения с порядком объектов, предлагаемом в данном документе. Но оно должно быть способно воспринимать объекты в любом порядке.

Общий заголовок

Рис. 10.30. Формат общего заголовка

В общем заголовке имеются следующие поля:

Vers. 4 бита — Номер версии протокола. В данном описании = 1.

Флаги: 4 бита — 0x01-0x08. Зарезервированы.

Флаги пока не определены.

Тип Msg. Тип сообщения (8 бит).

1 = Path
2 = Resv
3 = PathErr
4 = ResvErr
5 = PathTear
6 = ResvTear
7 = ResvConf

Контрольная сумма RSVP: 16 бит

Дополнение по модулю один контрольной суммы сообщения (в процессе вычисления поле контрольной суммы считается нулевым). Если в поле записан нуль, это означает, что контрольная сумма не вычислялась.

Send_TTL: 8 бит

Значение TTL для протокола IP, с которым было послано сообщение.

Длина RSVP: 16 бит

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

Форматы объектов

Каждый объект состоит из одного или более 32-битных слов с 4-байтовым заголовком. Формат объекта показан на рис. 10.31:

Рис. 10.31. Формат объекта

Заголовок объекта имеет следующие поля.

Длина в байтах

16-битовое поле, содержащее полную длину объекта в байтах. Длина должна быть кратна 4 октетам, минимальное значение равно 4.

ClassNum

Идентифицирует класс объекта. Каждый класс объекта имеет свое имя, которое в данном документе записывается прописными буквами. Приложения RSVP должны распознавать следующие классы.

• NULL

  Объект NULL имеет код Class-Num, равный нулю, а его C-тип игнорируется. Его длина должна быть, по крайней мере, равна 4, но может быть любой, кратной 4. Объект NULL может появиться где угодно в последовательности объектов. Его содержимое получателем игнорируется.
• SESSION

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

  Несет в себе IP-адрес узла, поддерживающего протокол RSVP, который послал это сообщение, и дескриптор логического выходного интерфейса (LIH). RSVP_HOP характеризует предшествующий узел (hop).
• TIME_VALUES

  Содержит значение периода обновления R, используемого отправителем сообщения. Этот объект необходим в каждом сообщении Path и Resv.
• STYLE

  Определяет стиль резервирования, а также зависящую от стиля информацию, которая не включена в объекты FLOWSPEC или FILTER_SPEC. Объект STYLE необходим в каждом сообщении Resv.
• FLOWSPEC

  Определяет желательный уровень QoS, в сообщениях Resv.
• FILTER_SPEC

  Определяет субнабор информационных пакетов сессии, которые должны получить желательный уровень QoS (специфицированный объектом FLOWSPEC ), в сообщениях Resv.
• SENDER_TEMPLATE

  Содержит IP-адрес отправителя и, может быть, некоторую дополнительную информацию, идентифицирующую отправителя. Этот объект необходим в сообщениях Path.
• SENDER_TSPEC

  Определяет характеристики информационного трафика отправителя. SENDER_TSPEC необходим в сообщениях Path.
• ADSPEC

  Несет в себе данные OPWA в сообщении Path.
• ERROR_SPEC

  Специфицирует ошибку в сообщениях PathErr и ResvErr или подтверждение в сообщении ResvConf.
• POLICY_DATA

  Несет в себе информацию, которая позволит локальному модулю, определяющему политику, принять решение, допустимо ли административно соответствующее резервирование. Может присутствовать в сообщениях Path, Resv, PathErr или ResvErr.
• INTEGRITY

  Несет в себе криптографические данные для аутентификации исходного узла и для верификации содержимого сообщения RSVP. Использование объекта INTEGRITY описано в ссылке [Baker96] в конце данного раздела.
• SCOPE

  Несет в себе список ЭВМ-отправителей, к которым должно быть переадресовано данное сообщение. Может присутствовать в сообщениях Resv, ResvErr или ResvTear.
• RESV_CONFIRM

  Несет в себе IP-адрес получателя, который запросил подтверждение. Может присутствовать в сообщениях Resv или ResvConf.

CType

Тип объекта, уникален в пределах класса Class-Num.

Максимальная длина объекта равна 65528 байт. Поля Class-Num и C-Тип могут использоваться совместно как 16-битовое число для определения уникального типа для каждого из объектов.

Старшие два бита Class-Num применяются для определения того, какие действия должен предпринять узел, если он не распознает Class-Num объекта.

Сообщения Path

Каждая ЭВМ-источник периодически отправляет сообщения Path для каждого из информационных потоков, берущих здесь свое начало. Это сообщение содержит объект SENDER_TEMPLATE, определяющий формат пакетов данных, и объект SENDER_TSPEC, специфицирующий характеристики трафика потока. Опционно сообщение может содержать объект ADSPEC, несущий в себе информацию о потоке (OPWA).

Сообщение Path направляется от отправителя к получателю по тому же маршруту, по которому движутся информационные пакеты. IP-адрес источника в сообщении Path должен характеризовать адрес отправителя, в то время как адрес места назначения должен быть равен DestAddress для текущей сессии. Эти адреса гарантируют, что сообщение будет корректно маршрутизовано даже через области сети, не поддерживающие RSVP. Формат сообщения Path имеет следующий вид:

<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]

Если присутствует объект INTEGRITY, он должен следовать непосредственно за стандартным общим заголовком. Не существует каких-либо иных ограничений порядка передачи, хотя упомянутое выше требование является рекомендательным. Число объектов POLICY_DATA может быть произвольным.

Объект PHOP (т.е., предыдущий RSVP_HOP ) каждого сообщения Path содержит адрес предшествующего узла, например, IP-адрес интерфейса, через который только что было послано сообщение Path. Он также содержит дескриптор логического интерфейса (LIH).

Каждый узел вдоль пути, поддерживающий RSVP, перехватывает сообщение Path и обрабатывает его с тем, чтобы сформировать состояние пути для отправителя, заданного объектами SENDER_TEMPLATE и SESSION. Любой из объектов POLICY_DATA, SENDER_TSPEC и ADSPEC также записываются в состояние пути. Если случилась ошибка при обработке сообщения Path, посылается сообщение PathErr первичному отправителю сообщения Path.

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

Процесс RSVP переадресует и размножает (если требуется, — например, при мультикастинге) сообщения Path, используя маршрутную информацию, которую он получает от соответствующих процессов маршрутизации. Маршрут зависит от DestAddress сессии и для некоторых протоколов маршрутизации — от адреса источника. Маршрутная информация обычно включает в себя список выходных интерфейсов, куда должно направляться сообщение Path. Так как каждый выходной интерфейс имеет свой IP-адрес, сообщения Path, посланные разными интерфейсами, содержат отличные адреса PHOP. Кроме того, объекты ADSPEC, содержащие сообщения Path, будут отличаться для разных выходных интерфейсов.

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

• Мультикастные сессии

  Мультикастинговая маршрутизация позволяет иметь стабильное дерево рассылки, в котором сообщения Path от одного и того же отправителя приходят от более чем одного PHOP, и RSVP должен быть готов поддерживать все такие состояния пути. RSVP не должен пересылать сообщения Path, которые прибывают через входной интерфейс, отличный от указанного в маршрутной таблице.
• Уникастные сессии

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

Сообщения Resv

Сообщения Resv несут в себе запросы резервирования от узла к узлу, от получателей к отправителям в направлении, противоположном движению потока данных. IP-адрес места назначения сообщения Resv является уникастным адресом предшествующего узла, полученным из состояния прохода. IP-адрес источника является адресом узла, который посылает сообщение. Сообщение Resv имеет следующий формат:

<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <empty> |
<flow descriptor list> <flow descriptor>

Если присутствует объект INTEGRITY, он должен непосредственно следовать за общим заголовком. За объектом STYLE следует список дескрипторов потоков. Объекты в списке дескрипторов должны соответствовать требованиям, записанным в BNF.

Объект NHOP (напр., RSVP_HOP ) содержит IP-адрес интерфейса, через который посылаются сообщения Resv, и LIH для логического интерфейса, где требуется резервирование.

Появление объекта RESV_CONFIRM сигнализирует о запросе подтверждения резервирования и несет в себе IP-адрес получателя, которому должен быть послан ResvConf. Число объектов POLICY_DATA не лимитировано.

Ниже приведены правила, которые специфицируют структуру дескриптора потока для каждого из стилей резервирования.

• Стиль WF:

  <flow descriptor list> ::= <WF flow descriptor>
  <WF flow descriptor> ::= <FLOWSPEC>
• Стиль FF:

  <flow descriptor list> ::=
  <FLOWSPEC> <FILTER_SPEC> |
  <flow descriptor list> <FF flow descriptor>
  <FF flow descriptor> ::=
  [ <FLOWSPEC> ] <FILTER_SPEC>

  Каждый запрос стиля FF описывается одной парой спецификаций (FLOWSPEC, FILTER_SPEC), несколько таких запросов могут быть уложены в один список дескрипторов потока сообщения Resv. Объект FLOWSPEC может быть опущен, если он идентичен последнему такому объекту в списке; первый дескриптор потока стиля FF должен содержать FLOWSPEC.
• Стиль SE:

  <flow descriptor list> ::= <SE flow descriptor>
  <SE flow descriptor> ::=
  <FLOWSPEC> <filter spec list>
  <filter spec list> ::= <FILTER_SPEC>
  | <filter spec list> <FILTER_SPEC>

Набор отправителей (reservation scope), которым направляется конкретный запрос резервирования, определяется следующим образом.

• Явный выбор отправителя

  Резервирование переадресуется всем отправителям, чьи объекты SENDER_TEMPLATE, записанные в состоянии прохода, соответствуют объекту FILTER_SPEC.
• Произвольный выбор отправителей (wildcard)

  Запрос с произвольным выбором отправителя соответствует всем отправителям, которые маршрутизированы на данный выходной интерфейс.

Когда сообщение Resv с произвольным выбором отправителя переадресуется более чем одному предыдущему узлу, в сообщение должен быть включен объект SCOPE. В этом случае список IP адресов для рассылки хранится именно в этом объекте.

Сообщение Resv, которое пересылается узлом, является в общем случае результатом объединения входящих сообщений Resv. Если одно из этих объединенных сообщений содержит объект RESV_CONFIRM и имеет число FLOWSPEC, большее, чем FLOWSPEC всех других объединенных запросов резервирования, тогда этот объект RESV_CONFIRM переадресуется в виде исходящего сообщения Resv. Объект RESV_CONFIRM из одного из объединенных запросов (чья спецификация flowspecs равна, меньше или сравнима с объединенной спецификацией flowspec и которая не подвергнута блокаде) запустит генерацию сообщения ResvConf, содержащего RESV_CONFIRM. Объект RESV_CONFIRM в запросе, который подвергнут блокаде, не будет переадресован или возвращен, он будет аннулирован в текущем узле.