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

Сообщения отмены прохода

Получение сообщения PathTear (path teardown) аннулирует состояния прохода. Соответствующее состояние должно согласовываться с объектами SESSION, SENDER_TEMPLATE и PHOP. Кроме того, сообщение PathTear для мультикастной сессии может соответствовать только состоянию прохода для входного интерфейса, через который получено сообщение PathTear. Если соответствия состоянию прохода нет, сообщение должно быть отброшено без дальнейшей рассылки.

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

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

Сообщение PathTear может содержать в своем дескрипторе отправителя объект SENDER_TSPEC или ADSPEC, но они должны игнорироваться.

Удаление состояния прохода в результате получения сообщения PathTear или тайм-аута должно модифицировать состояние резервирования в данном узле. Эта модификация зависит от стиля резервирования. Например, предположим, что PathTear удаляет состояние прохода отправителя S. Когда стиль специфицирует явный выбор отправителя (FF или SE), всякое резервирование со спецификацией фильтрации, соответствующей отправителю S, должно быть удалено; когда стиль предусматривает произвольный выбор отправителя (WF), резервирование удаляется, если S является последним отправителем, участвующим в сессии. Эти изменения резервирования не должны вызвать немедленную посылку сообщения обновления Resv, так как сообщение PathTear уже вызвало необходимые изменения. Они не должны также вызвать отправку сообщения ResvErr, так как это может вызвать лавину таких сообщений.

Сообщения отмены Resv

Получение сообщения ResvTear (reservation teardown) вызывает удаление соответствующего состояния резервирования. При этом проверяется соответствие объектов SESSION, STYLE и FILTER_SPEC, а также LIH в объекте RSVP_HOP. Если соответствие не обнаружено, сообщение ResvTear игнорируется. Сообщение ResvTear может отменить любой субнабор спецификаций фильтрации в состояниях резервирования стилей FF или SE.

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

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

Объекты FLOWSPEC в списке дескрипторов потоков сообщения ResvTear будут игнорироваться и могут быть опущены. Сообщение ResvTear может включать в себя объект SCOPE, но он должен игнорироваться.

В зависимости от изменения состояния узла получение сообщения ResvTear может вызвать переадресацию этого сообщения, посылку модифицированного сообщения Resv или не вызвать никакого сообщения. Эти три случая могут быть проиллюстрированы для стиля резервирования FF на рис. 10.26.

• Если получатель R2 посылает сообщение ResvTear для резервирования S3{B}, соответствующее резервирование удаляется из интерфейса ( I_Г ) и посылается ResvTear для S3{B} интерфейсу ( I_Б ).
• Если получатель R1 посылает ResvTear для резервирования S1{4B}, соответствующее резервирование удаляется из интерфейса ( I_В ) и немедленно посылается модифицированное сообщение Resv FF(S1{3B}) интерфейсу ( I_А ).
• Если получатель R3 посылает сообщение ResvTear для S1{B}, никаких изменений резервирования не происходит и никаких сообщений далее не посылается.

Сообщения об ошибке прохода

Сообщения PathErr (path error) несут в себе данные об ошибке в обрабатываемых сообщениях Path. Они направляются отправителям данных и маршрутизируются от узла к узлу, используя состояние прохода. При каждом шаге IP-адрес места назначения является уникастным адресом предыдущего узла. Сообщения PathErr не модифицируют состояния узлов, через которые проходят; они предназначаются только приложению отправителя.

Объект ERROR_SPEC специфицирует ошибку и включает в себя IP-адрес узла, который обнаружил эту ошибку (Error Node Address). Для приобщения необходимой информации в сообщение могут быть включены один или более объектов POLICY_DATA.

Сообщения об ошибках Resv

Сообщения ResvErr (reservation error) сообщают об ошибках при обработке запросов Resv или о спонтанном нарушении резервирования, например, в результате административного вмешательства.

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

Объект ERROR_SPEC специфицирует ошибку и включает в себя IP-адрес узла, который обнаружил ошибку (Error Node Address). Для приобщения необходимой информации в сообщение могут быть включены один или более объектов POLICY_DATA. Объект RSVP_HOP содержит адрес предыдущего узла, а объект STYLE копируется из сообщения Resv.

Следующие правила, зависящие от стиля резервирования, определяют структуру ошибки дескриптора потока.

• Стиль WF:

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

  <error flow descriptor> ::= <FF flow descriptor>

  Каждый дескриптор потока в сообщении Resv стиля FF должен обрабатываться независимо, и для каждого из них, имеющего ошибку, должно посылаться отдельное сообщение ResvErr.
• Стиль SE:

  <error flow descriptor> ::= <SE flow descriptor>

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

Заметим, что сообщение ResvErr содержит только один дескриптор потока. Следовательно, сообщение Resv, которое содержит N > 1 дескрипторов потока (стиль FF), может быть причиной N сообщений ResvErr.

Вообще говоря, сообщение ResvErr следует пересылать всем получателям, которые могут быть причиной данной ошибки. Конкретнее:

• узел, который обнаружил ошибку в запросе резервирования, посылает сообщение ResvErr узлу, от которого получен ошибочный запрос резервирования.

  Это сообщение ResvErr должно содержать информацию, необходимую для определения ошибки и для маршрутизации сообщения об ошибке последующим узлам. Такое сообщение, следовательно, включает в себя объект ERROR_SPEC, копию объекта STYLE и соответствующий дескриптор потока, где зафиксирована ошибка. Если ошибка является результатом отказа при попытке увеличить резервирование, тогда существующее резервирование должно быть сохранено и должен быть установлен бит-флаг InPlace в ERROR_SPEC сообщения ResvErr ;
• узлы переадресуют сообщение ResvErr последующим узлам, которые имеют локальное состояние резервирования. Для резервирования с произвольным выбором отправителей имеется дополнительное ограничение на пересылку сообщений ResvErr, связанное с блокировкой возможных циклических маршрутов. Существует строгое правило рассылки сообщений при ошибке, связанной с разрешением доступа. Сообщение ResvErr, которое посылается, должно нести в себе спецификацию FILTER_SPEC соответствующего состояния резервирования;
• когда сообщение ResvErr достигает получателя, приложение должно принять объект STYLE, список дескрипторов потока и объект ERROR_SPEC (включая его флаги).

Сообщения подтверждения

Сообщения ResvConf посылаются в ответ на запрос подтверждения резервирования. Сообщение ResvConf посылается в результате появления объекта RESV_CONFIRM в сообщении Resv. Сообщение ResvConf посылается по уникастному адресу ЭВМ получателя, адрес берется из объекта RESV_CONFIRM.

Объект RESV_CONFIRM является копией объекта в сообщении Resv, который вызвал подтверждение. ERROR_SPEC используется только для переноса IP-адреса исходного узла в поле адрес узла с ошибкой (Error Node Address). Равенство кода ошибки и значения нулю свидетельствует о подтверждении. Список дескрипторов потоков специфицирует конкретное резервирование, которое подтверждается. Это может быть субнабор из списка дескрипторов потоков Resv, для которого запрошено подтверждение.

Использование портов

Сессия RSVP определяется в нормальной ситуации тремя параметрами: DestAddress, ProtocolId, DstPort. Здесь DstPort является полем порта назначения UDP/TCP. DstPort может быть опущен (сделан равным нулю), если ProtocolId специфицирует протокол, который не имеет поля порта места назначения.

RSVP допускает любое значение для ProtocolId. Однако реализации оконечных систем RSVP могут знать об определенных значениях для этого поля и, в частности, о значениях для UDP и TCP (17 и 6 соответственно). Оконечная система может выдать сигнал ошибки приложению, которая:

• специфицирует ненулевое значение DstPort для протокола, который не имеет портов типа UDP/TCP, или
• специфицирует нулевое значение DstPort для протокола, который имеет порты, специфицированные для UDP/TCP.

Спецификации фильтра и шаблоны отправителя определяют пару: SrcAddress, SrcPort, где SrcPort — поле UDP/TCP порта. В некоторых случаях SrcPort может быть опущен (установлен равным нулю). Существуют следующие правила использования нулевого значения полей DstPort и/или SrcPort в RSVP.

1. Порты назначения должны быть взаимосогласованными.

   Состояния прохода и резервирования для одного и того же DestAddress и ProtocolId должны иметь свои значения DstPort, которые все равны нулю или все не равны нулю. Нарушение этого условия в узле является ошибкой "конфликт портов назначения (Conflicting Dest Ports)".
2. Правило портов назначения.

   Если DstPort в описании сессии равен нулю, все поля SrcPort, используемые для этой сессии, также должны быть равны нулю. При этом предполагается, что протокол не имеет портов типа UDP/TCP. Нарушение этого условия в узле вызовет ошибку Bad Src Ports.
3. Порты источников должны быть взаимосогласованы.

   ЭВМ-отправитель не должна посылать состояния прохода со значением SrcPort как равным, так и неравным нулю. Нарушение этого условия вызовет ошибку Conflicting Sender Port. Заметим, что протокол не допускает произвольного назначения номеров портов (wildcard), т.е., нулевой порт не может соответствовать ненулевому порту.

Посылка сообщений RSVP

Сообщения RSVP посылаются от узла к узлу между RSVP-маршрутизаторами, поддерживающими этот протокол, в виде IP-дейтограмм с кодом протокола 46. IP-дейтограммы предназначены также для использования между оконечными системами и первыми/последними маршрутизаторами.

Сообщения Path, PathTear и ResvConf должны посылаться с опцией Router Alert IP [RFC-2113] в их IP-заголовках.

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

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

• Одиночное RSVP-сообщение не должно превосходить максимального размера IP-дейтограммы, примерно 64K байт (на практике значительно меньше!).
• Перегруженные сетевые области, которые не поддерживают RSVP, могут потерять отдельные фрагменты, а это приведет к потере всего сообщения.

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

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

1. Когда узел N направляет сообщение Path выходному логическому интерфейсу L, он включает в сообщение дескриптор логического интерфейса LIH (logical interface handle). Значение LIH содержится в объекте RSVP_HOP.
2. Следующий узел N' запоминает значение LIH в своем состоянии прохода.
3. Когда N' посылает сообщение Resv узлу N, он включает в него значение LIH из состояния прохода (содержится в объекте RSVP_HOP ).
4. Когда сообщение Resv прибывает в N, его значение LIH выдает информацию, необходимую для осуществления резервирования в определенном логическом интерфейсе. Заметим, что узел N создает и интерпретирует LIH, которое совершенно не доступно для узла N'.