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

10.5.1. Механизмы протокола RSVP

Сообщения RSVP

На рис. 10.28 проиллюстрирована модель RSVP узла маршрутизатора. Каждый поток данных приходит со стороны предшествующего узла через соответствующий входной интерфейс и выходит из маршрутизатора через один или несколько выходных интерфейсов. Один и тот же интерфейс для разных потоков в пределах одной сессии может выполнять как входную, так и выходную роль. Несколько предшествующих узлов и/или последующих узлов могут для коммуникаций использовать один и тот же физический интерфейс; например, на рисунке два узла Г и Г' подключены к широковещательной сети через интерфейс I_Г.

Рис. 10.28. Маршрутизатор, использующий RSVP

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

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

• Шаблон отправителя

  Сообщение Path должно нести в себе шаблон отправителя (Sender Template), который описывает формат пакетов данных, посылаемых отправителем. Этот шаблон имеет форму спецификации фильтра, которая может использоваться для отделения пакетов данного отправителя от других пакетов в пределах сессии.

  Шаблоны отправителя имеют тот же формат, что и спецификации фильтра, которые применяются в сообщениях Resv. Следовательно, шаблон отправителя может специфицировать только его IP-адрес и опционно UDP/TCP порт, с учетом идентификатора протокола, заданного для сессии.
• Спецификация Tspec отправителя

  Сообщения Path должны содержать спецификацию отправителя Tspec, которая определяет характеристики информационного трафика, формируемого отправителем. Спецификация Tspec используется для предотвращения избыточного резервирования.
• Спецификация Adspec

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

  Сообщения Path посылаются с теми же адресами отправителя и получателя, что и данные, так что они будут корректно маршрутизироваться даже через сетевые области, не поддерживающие RSVP. С другой стороны, сообщения Resv посылаются от узла к узлу; каждый узел, поддерживающий RSVP, переправляет сообщение Resv по уникастному адресу предшествующего узла RSVP.

10.6. Объединение Flowspecs

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

Так как flowspecs непрозрачны для RSVP, действительные правила для сравнения flowspecs должны быть определены и реализованы вне рамок этого протокола. Реализация RSVP потребует обращения к специальной программе, чтобы выполнить объединение спецификаций flowspec.

Заметим, что спецификации flowspecs представляют собой в общем случае многомерные векторы; они могут содержать как Tspec, так и Rspec компоненты, каждая из которых может сама быть многомерной.

Например, если один запрос требует высокой пропускной способности, а другой — жесткого ограничения задержек, то один не может быть "больше" другого. В таком случае, вместо взятия большего, прикладная программа объединения должна уметь сформировать такую спецификацию flowspec, которая по крайне мере столь же велика, как и каждая из составляющих; математически это наименьший верхний предел LUB (least upper bound). В некоторых случаях спецификация flowspec по крайне мере настолько мала, насколько нужно; тогда это наибольший нижний предел GLB (Greatest Lower Bound).

Для вычисления эффективного значения flowspec ( Re, Te ), инсталлируемого в интерфейс, используются следующие шаги [RFC-2210]. Здесь Te — эффективная спецификация Tspec, а Re — эффективная спецификация Rspec.

1. Определяется эффективная спецификация flowspec для выходного интерфейса. В зависимости от технологии канального уровня, это может требовать объединения спецификаций flowspecs различных последующих узлов. Это означает вычисление эффективной спецификации flowspec как LUB flowspecs. Какие спецификации следует объединять, определяется средой канального уровня, в то время как процедура объединения задается используемой моделью обслуживания [RFC-2210]. В результате получается спецификация flowspec, которая непрозрачна для RSVP, но в действительности состоит из пары ( Re, Resv_Te ), где Re является эффективной спецификацией Rspec, а Resv_Te — эффективная спецификация Tspec.
2. Производится вычисление спецификации Path_Te, зависящей от приложения и представляющей собой сумму всех Tspecs, которые были присланы в сообщениях Path, пришедших от различных предшествующих узлов (например, некоторые или все узлы A, Б, и Б' на рис. 10.28).
3. ( Re, Resv_Te ) и Path_Te передаются системе управления трафиком. Управление трафиком вычислит эффективную спецификацию flowspec, как минимум Path_Te и Resv_Te.

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

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

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

Протокол RSVP посылает свои сообщения в виде IP-дейтограмм без какого-либо улучшения надежности. Периодическая передача сообщений обновления от ЭВМ и маршрутизаторов позволяет компенсировать случайные потери отдельных RSVP-сообщений. Если тайм-аут удаления установлен равным K периодам обновления, то RSVP может допускать потерю K-1 RSVP-пакетов подряд без аннулирования состояния. Механизм управления сетевым трафиком должен быть отконфигурирован так, чтобы предоставить минимальную полосу пропускания для сообщений RSVP и предотвратить их потерю из-за перегрузки канала.

Состояние, поддерживаемое RSVP, является динамическим. Для изменения набора отправителей Si или изменения любого запроса QoS, ЭВМ просто начинает посылать измененные сообщения Path и/или Resv. В результате будет осуществлено соответствующее изменение RSVP-состояния во всех узлах вдоль пути, а неиспользуемые состояния будут аннулированы по тайм-ауту, если не поступит прямых указаний по их ликвидации до этого.

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

Состояние, которое получено через конкретный интерфейс I*, никогда не должно переадресовываться этому интерфейсу. Состояние, которое направляется интерфейсу I*, должно вычисляться на основе состояний, полученных от других интерфейсов, исключая I*. Тривиальный пример, поясняющий это правило приведен на рис. 10.29, где показан маршрутизатор с одним отправителем и одним получателем на каждом интерфейсе (R1, S1 и R2, S2). Интерфейсы IA и IБ выполняют как входные, так и выходные функции. Оба получателя используют WF-стиль резервирования, в котором сообщения Resv переадресуются всем предшествующим узлам группы вдоль маршрута, за исключением узла, от которого это сообщение получено. В результате достигается независимое резервирование для обоих направлений (на рис. 10.29 "Получает" и "Отправляет" подразумевает внешнее направление по отношению к маршрутизатору).

Рис. 10.29. Независимые резервирования

Существует еще одно правило, которое управляет процессом переадресации сообщений Resv: состояние из сообщения Resv, полученное через выходной интерфейс Io, следует передавать входному интерфейсу Ii только в том случае, когда сообщение Path от Ii переадресовано к Io.

5.8. Аннулирование (Teardown)

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

Существует два типа RSVP сообщений аннулирования: PathTear и ResvTear. Сообщение PathTear направляется всем получателям и ликвидирует состояние прохода, а также все зависящие от него состояния резервирования. Сообщение ResvTear уничтожает состояние резервирования и направляется всем отправителям.

Запрос аннулирование (teardown) может посылаться приложением оконечной системы (получатель или отправитель) или маршрутизатором в результате тайм-аута или при появлении привилегированной задачи. После инициализации запрос-аннулирование должен переадресовываться от узла к узлу без задержки. Сообщение аннулирования уничтожает специфицированное состояние в узле-получателе.

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

Необходимо иметь возможность ликвидировать любой субнабор установленных состояний. Для состояний прохода минимально это может быть один отправитель. Для состояний резервирования таким объектом является спецификация фильтра. Например, в случае, показанном на рис. 10.29, получатель R1 может послать сообщение ResvTear только отправителю S2 (или любому субнабору из списка спецификаций фильтрации), оставляя S1 без изменений.

Сообщение ResvTear специфицирует стиль и фильтры, любая спецификация flowspec игнорируется. Любая рабочая спецификация flowspec будет убрана, если все ее спецификации фильтров будут ликвидированы.

Ошибки

Существует два типа RSVP сообщений об ошибках: ResvErr и PathErr. Сообщения PathErr очень просты, они посылаются отправителю — виновнику ошибки и не изменяют состояния прохода в узлах, через которые проходят. Существует всего несколько причин ошибок прохода.

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

1. Первая проблема резервирования килера (KR-I) возникает, когда уже имеется резервирование Q0. Если другой получатель делает новое Q1 > Q0, результирующее объединенное резервирование Q0 и Q1 может быть отвергнуто системой контроля доступа в некотором последующем узле. Это не должно вредить услугам на уровне Q0. Решение этой проблемы весьма просто: когда контроль доступа не пропускает запрос резервирования, существующее состояние резервирования сохраняется.
2. Вторая проблема (KR-II) противоположна первой: получатель, выполняющий резервирование Q1, сохраняет свое состояние даже в случае непрохождения контроля доступа для Q1 в каком-то узле. Это не должно мешать другому получателю установить меньшее резервирование Q0, которое бы прошло, если бы не было объединено с Q1.

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

Запрос резервирования, не прошедший контроль допуска создает состояние блокады в соответствующем узле, но остается действующим во всех предшествующих узлах. Было предложено, чтобы эти резервирования до точки отказа были удалены. Однако они были сохранены по следующим причинам:

• У получателя имеются две возможные причины настаивать на резервировании:
  1. заказываемый ресурс доступен по всей длине пути, или
  2. нужно получить желаемый уровень QoS вдоль оговоренного пути так далеко, как это возможно. Конечно, во втором случае, а может быть и в первом, получатель захочет настаивать на резервировании, осуществленном вплоть до точки блокировки.
• Если бы эти резервирования в предыдущих узлах не были сохранены, реагирование RSVP на некоторые переходные отказы стало хуже. Например, предположим, что маршрут переключился на альтернативный, который сильно перегружен, так что существующие резервирования не могут быть удовлетворены и система возвращается к исходному маршруту. Состояние блокады в каждом из маршрутизаторов до узкого места не должно быть немедленно удалено, так как не позволит системе быстро восстановиться.
• Если бы мы не обновляли резервирование в предшествующих узлах каждые Tb секунд, они могли бы быть удалены по тайм-ауту ( Tb — время тайм-аута состояния блокады).

Подтверждение

Чтобы запросить подтверждение на свое резервирование, получатель Rj включает в сообщение Resv объект запроса подтверждения, содержащий IP-адрес Rj. В каждой точке объединения только наибольшая из спецификаций flowspec и соответствующий объект запроса подтверждения посылаются далее. Если запрос резервирования от Rj равен или меньше уже существующего резервирования, его Resv не переадресуется последующим узлам, и если Resv включает в себя запрос подтверждения, отправителю Rj посылается сообщение ResvConf. Если запрос подтверждения переадресуется, это делается немедленно и не более одного раза на каждый запрос. Этот механизм подтверждения имеет такую последовательность:

• новый запрос резервирования со спецификацией flowspec, большей, чем любая из действующих в данной точке спецификаций сессии, обычно вызывает либо сообщение ResvErr, либо ResvConf, отправляемое получателю каждым из отправителей данных. В этом случае сообщение ResvConf будет подтверждением, относящимся ко всему пути;
• получение ResvConf не предоставляет никаких гарантий. Предположим, что два запроса резервирования от получателей R1 и R2 пришли в узел, где они были объединены. R2, чье резервирование было вторым по времени, может получить подтверждение ResvConf от данного узла, в то время как запрос R1 еще не прошел весь путь и может еще быть отвергнут каким-то последующим узлом. Таким образом, R2 может получить ResvConf, когда не имеется полномасштабного резервирования вдоль всего пути; более того, R2 может получить ResvConf, за которым последует сообщение ResvErr.

Управление политикой

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

Когда запрашивается новое резервирование, каждый узел должен ответить на два вопроса: "Имеется ли достаточно ресурсов, чтобы удовлетворить запрос?" и "Позволено ли данному пользователю осуществлять резервирование?" Эти два решения называются "управлением доступа" и "управлением политикой", соответственно. Различные административные домены в Интернет могут иметь разные политики резервирования.

На вход управления политикой поступают специфические блоки данных, которые заключены в объектах POLICY_DATA протокола RSVP. Эти блоки могут включать в себя параметры доступа пользователя, его класс, номер акаунта, пределы квоты и пр. Подобно flowspecs, эти данные недоступны для RSVP, который просто передает их, когда требуется, системе управления политикой. Аналогично, объединение этих данных должно выполняться системой управления политикой, а не самим протоколом RSVP. Заметим, что точки объединения данных, характеризующих политику, должны находиться на границах административных доменов.

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

Безопасность

При использовании протокола RSVP возникают определенные проблемы безопасности.

• Целостность сообщений и аутентификация узлов

  Повреждение или фальсификация запросов резервирования может привести к получению услуг неавторизованными пользователями или к отказам в услугах. RSVP осуществляет защиту против таких атак с помощью механизма аутентификации, действующего в каждом из узлов и использующего шифрование с применением хэш-функций. Механизм поддерживается объектами INTEGRITY, которые могут быть включены в любое сообщение RSVP. Эти объекты используют технику криптографических дайджестов, которая предполагает, что соседи RSVP совместно владеют секретом шифрования (см. [Baker96]).
• Аутентификация пользователя

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

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

  Для решения этой проблемы определено расширение RSVP, в котором идентификатор секретности (IPSEC SPI) играет ту же роль, что и номер порта [RFC-2207].

Области, не поддерживающие RSVP

Невозможно развернуть протокол RSVP (или любой новый протокол) во всем Интернет одновременно. Более того, RSVP, вероятно, никогда не будет развернут повсеместно. RSVP должен гарантировать корректную работу, когда два RSVP-маршрутизатора объединены друг с другом через сетевую область, не поддерживающую этот протокол. Конечно, промежуточная сетевая область, лишенная поддержки RSVP, не способна осуществлять резервирование ресурсов. Однако если эта область обладает достаточной емкостью, она может обеспечить необходимый уровень услуг.

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

Хотя RSVP работает корректно и через сетевые области без поддержки RSVP, узлы из этой области могут внести искажения в QoS. При встрече области без поддержки RSVP протокол устанавливает бит-флаг NonRSVP и передает его механизму управления трафиком. Управление трафиком комбинирует этот однобитовый флаг со своей собственной информацией об источниках и передает ее вдоль транспортного пути получателям, используя спецификацию Adspecs [RFC-2210].

При некоторых топологиях маршрутизаторов с поддержкой RSVP и без нее возможна доставка сообщений Resv не в тот узел или не на тот интерфейс. Процесс RSVP должен быть готов обрабатывать такие ситуации. Если адрес места назначения не соответствует ни одному локальному интерфейсу, а сообщение не является Path или PathTear, то оно должно передаваться далее без какой-либо обработки в данном узле. Чтобы обработать случай с неправильным интерфейсом, используется дескриптор логического интерфейса LIH (Logical Interface Handle). Информация предыдущего узла, включенная в сообщение Path, содержит не только IP-адрес предшествующего узла, но также и LIH, определяющий логический выходной интерфейс; обе величины записываются в состояние прохода. Сообщение Resv, пребывающее в адресуемый узел, несет в себе IP-адрес и LIH правильного выходного интерфейса, т.е. интерфейса, который должен получить запрошенное резервирование, вне зависимости от того, на какой интерфейс оно п опало.

Модель ЭВМ

Прежде чем будет сформирована сессия, ей должен быть присвоен идентификатор ( DestAddress, ProtocolId, DstPort ), который рассылается всем отправителям и получателям. Когда RSVP сессия сформировалась, в оконечных системах должны произойти следующие события.

H1 Получатель посредством IGMP подключается к мультикаст-группе, заданной адресом DestAddress

H2 Потенциальный отправитель начинает посылать сообщения Path по адресу DestAddress

H3 Приложение получателя принимает сообщение Path

H4 Получатель начинает посылать соответствующие сообщения Resv, задавая дескрипторы нужных потоков

H5 Приложение отправителя получает сообщение Resv

H6 Отправитель начинает посылать информационные пакеты

Существует несколько соображений, касающихся синхронизации.

• H1 и H2 могут произойти в любом порядке.
• Предположим, что новый отправитель начинает отправку данных (H6), но пока не существует мультикастинг-маршрутов, так как ни один получатель не подключился к группе (H1). Тогда данные будут выбрасываться в некотором узловом маршрутизаторе (какой это будет узел, зависит от используемого протокола маршрутизации), пока не появится хотя бы один получатель.
• Предположим, что новый отправитель начинает рассылку сообщений Path (H2) и данных (H6) одновременно, и имеется некоторое число получателей, но сообщения Resv пока не достигли отправителя (например, потому что его сообщения Path еще не дошли до получателей). Тогда исходные данные могут прийти к получателю без желаемого уровня QoS. Отправитель может немного облегчить эту проблему, подождав прибытия первого сообщения Resv (H5). Однако получатели, которые достаточно далеко, могут еще не получить необходимого резервирования.
• Если получатель начинает посылать сообщения Resv (H4) до получения какого-либо сообщения Path (H3), RSVP пришлет получателю сообщение об ошибке.

Получатель может просто игнорировать такие сообщения об ошибке или может избежать их, ожидая сообщений, прежде чем посылать сообщения Resv. Программный интерфейс приложения (API) для RSVP в данной спецификации не определен, так как он может зависеть от ЭВМ и ОС.