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

Исключение циклов сообщений RSVP

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

• Сообщения Path. Эти сообщения направляются точно тем же путем, что и информационные IP-пакеты. Следовательно, не должно возникать циклов для сообщений типа Path (за исключением циклов, связанных с переходными процессами установления маршрута).
• Сообщения PathTear. Эти сообщения используют ту же маршрутизацию, что и сообщения Path и, следовательно, не могут образовывать циклы.
• Сообщения PathErr. Так как сообщения Path не образуют циклов, они формируют состояние прохода, описывающее обратный маршрут для каждого из отправителей, который не может иметь петель. Сообщения PathErr всегда направлены определенному отправителю и, следовательно, не могут образовывать циклы.
• Сообщения Resv. Эти сообщения направлены определенному отправителю и не могут иметь циклы. Однако, сообщения Resv с произвольным выбором отправителя (wildcard) (стиль WF) имеет потенциал для запуска циклов обновления.
• Сообщения ResvTear. Хотя сообщения ResvTear маршрутизируются так же, как и сообщения Resv, при повторном проходе по петле состояние будет отсутствовать (аннулировано) и любое сообщение ResvTear будет отброшено.
• Сообщения ResvErr. Эти сообщения для стиля резервирования WF могут вызывать зацикливание по той же причине, что и для сообщений Resv.
• Сообщения ResvConf. Эти сообщения направляются фиксированному уникастному получателю и не могут приводить к циклам.

Если топология не содержит петель, зацикливания сообщений Resv и ResvErr при произвольном выборе отправителя можно избежать, следуя приведенному выше правилу: состояние, которое получено через определенный интерфейс, никогда не должно переадресовываться через этот же интерфейс. Однако когда топология содержит петли, необходимы дополнительные усилия для предотвращения циклов автоматического обновления для сообщений Resv и ResvErr с произвольным выбором отправителя. Решением этой проблемы может быть включение списка адресов получателей в объект SCOPE.

Когда сообщение Resv со стилем WF должно быть переадресовано определенному предыдущему узлу, следует определить новый список адресов для объекта SCOPE на основе аналогичного объекта, полученного с соответствующими сообщениями Resv. Если новый объект SCOPE пуст, сообщение не направляется предыдущему узлу. Правила для вычисления нового объекта SCOPE для сообщения Resv приведены ниже.

1. Образуется объединение наборов IP-адресов отправителей, перечисленных во всех объектах SCOPE состояния резервирования данной сессии. Если состояние резервирования от некоторых NHOP не содержит объектов SCOPE, должен быть создан заменяющий список отправителей, который и помещается в указанное объединение. Для сообщения, полученного выходным интерфейсом OI, список замен представляет собой набор отправителей, которые маршрутизированы на этот OI.
2. Любые локальные отправители (т.е., любое приложение отправителя в данном узле) удаляются из этого списка.
3. Если объект SCOPE должен быть послан PHOP, следует удалить из набора любого отправителя, который не присылает данные через PHOP.

На рис. 10.32 дан пример Resv -сообщений (стиль WF). Адресный список объекта SCOPE показан в квадратных скобках.

Рис. 10.32. Объекты SCOPE при резервировании в стиле WF

Объекты SCOPE не являются обязательными, если мультикастинг-маршрутизация использует совместные деревья или если стиль резервирования предполагает явный выбор отправителей. При работе с объектами SCOPE в сообщениях ResvErr стиля WF следует придерживаться следующих правил.

1. Узел, который обнаружил ошибку, отправляет сообщение ResvErr, содержащее копию объекта SCOPE, который соответствует состоянию резервирования или сообщению, вызвавшему ошибку.
2. Предположим, что узлом получено сообщение ResvErr с произвольным указанием отправителей (wildcard), содержащее объект SCOPE со списком адресов отправителей L. Сообщение ResvErr, переадресованное интерфейсу OI, должно содержать объект SCOPE, извлеченный из L и включающий только те адреса отправителей, которые маршрутизированы на OI. Если этот объект SCOPE пуст, сообщение ResvErr не должно посылаться OI.

Состояние блокады

Основным правилом при формировании сообщения обновления Resv является объединение спецификаций flowspecs резервирования в узле посредством вычисления их LUB (наименьший верхний предел). Однако это правило модифицируется при наличии состояния блокады, возникшего из-за сообщений ResvErr при решении проблемы KR-II.

Когда получено сообщение ResvErr, его спецификация flowspec Qe используется для формирования или обновления элемента местного состояния блокады. Каждый элемент состояния блокады состоит из спецификации flowspec Qb, взятой из спецификации сообщения ResvErr, и соответствующего таймера блокады Tb. Когда время таймера блокады истекает, соответствующее состояние блокады аннулируется.

Гранулярность состояния блокады зависит от стиля сообщения ResvErr, которое явилось ее причиной. Каждому конкретному стилю может соответствовать свой элемент состояния блокады ( Qb(S),Tb(S) ), где S — отправитель. Для произвольного стиля выбора отправителя состояние блокады определяется предыдущим узлом P.

Элемент состояния блокады со спецификацией flowspec Qb называется блокадой резервирования со спецификацией flowspec Qi, если Qb не больше, чем Qi. Например, предположим, что LUB (least upper bound) двух спецификаций flowspecs было вычислено путем выбора максимума составляющих их компонент. Тогда Qb блокирует Qi, если для некоторой компоненты .

Предположим, что узел получает сообщение ResvErr от предыдущего узла P или, если стиль выбора отправителя S является явным — в результате ошибки доступа. Тогда:

1. для P (или S ) создается элемент состояния блокады, если его не было;
2. Qb(P) (или Qb(S) ) делается равным flowspec Qe из сообщения ResvErr ;
3. запускается (или перезапускается) соответствующий таймер блокады Tb(P) (или Tb(S) ) на время Kb*R. Здесь Kb является фиксированным множителем, а R равно интервалу времени обновления состояния резервирования. Kb можно варьировать;
4. если имеется локальное состояние резервирования, которое не заблокировано, немедленно генерируется обновление резервирования для P (или S );
5. сообщение ResvErr переадресуется последующим узлам. Если бит InPlace=0, сообщение ResvErr направляется всем последующим узлам, где имеется состояние резервирования. Если бит InPlace=1, сообщение ResvErr направляется только следующим узлам, чьи Qi блокированы спецификацией Qb.

В результате предлагается модифицированное правило для объединения спецификаций flowspecs при формировании сообщения обновления резервирования.

• Если имеются какие-либо локальные запросы резервирования Qi, которые не заблокированы, они объединяются путем вычисления их LUB. Заблокированные резервирования игнорируются. Это позволяет требовать меньшее резервирование, которое имеет шанс на успех, после того как большее резервирование не удалось.
• В противоположном случае (все локальные запросы Qi блокированы), они объединяются путем взятия GLB (Greatest Lower Bound) спецификаций Qi.

Этот алгоритм объединения обновления применяется отдельно для каждого потока (каждого отправителя или PHOP), вносящего вклад в общее резервирование (стили WF или SE).

На рис. 10.33 приведен пример использования состояния блокады для совместного резервирования (стиль WF). Имеется два предшествующих узла, помеченных как (a) и (b), и два последующих узла, помеченных как (c) и (d). Большее резервирование 4B пришло сначала от (c), но "застряло" где-то до PHOP (a), а не по пути через PHOP (b). Рисунок показывает оконечное состояние после меньшего резервирования 2B, пришедшего позднее из (d). Это стабильное состояние нарушается каждые Kb*R секунд, когда состояние блокады удаляется по тайм-ауту. Следующее обновление (4B), посылаемое предыдущему узлу (a), предположительно будет отвергнуто путем посылки сообщения ResvErr, которое восстановит состояние блокады, возвращая ситуацию к тому, что изображено на рисунке. В то же самое время сообщение ResvErr будет направлено следующему узлу (c) и всем получателям, ответственным за резервирование 4B.

Рис. 10.33. Блокада для стиля WF

Локальное восстановление

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

• Когда маршрутизация обнаруживает изменение набора выходных интерфейсов для места назначения G, RSVP должен обновить состояние прохода, подождать короткий период W и затем послать сообщение обновление Path всем сессиям G/* (т.е., любой сессии с местом назначения G, вне зависимости от порта назначения). Короткая выдержка перед рассылкой сообщения обновления Path нужна, чтобы позволить завершиться переходным процессам в маршрутном протоколе. В настоящее время предлагается W = 2 сек; однако, эта величина должна быть задана при конфигурировании каждого интерфейса.
• Когда приходит сообщение Path с адресом предыдущего узла, который отличается от записанного в состоянии прохода, RSVP должен немедленно послать сообщение обновления Resv этому PHOP.

Временные параметры

Существует два временных параметра, соответствующие каждому элементу прохода или состоянию резервирования RSVP в узле: период обновления R между последовательными коррекциями состояния соседнего узла и время жизни локального состояния L. Каждое сообщение RSVP Resv или Path может содержать объект TIME_VALUES, специфицирующий значение R, которое было использовано при генерации данного сообщения обновления. Эта величина R затем используется для определения значения L. Величины R и L могут варьироваться от узла к узлу. Ниже данные соображения излагаются более подробно.

1. Флойд и Джакобсон [FJ94] показали, что периодические сообщения, генерируемые независимыми сетевыми узлами, могут взаимно синхронизоваться. Это может привести к деградации сетевых услуг, так как периодические сообщения могут сталкиваться с другими сетевыми пакетами. Так как RSVP периодически посылает сообщения обновления, он должен избегать синхронизации сообщений и гарантировать, что любая возникшая синхронизация не будет стабильной. По этой причине таймер обновления должен быть рэндомизован в диапазоне [0.5R, 1.5R].
2. Чтобы избежать преждевременной потери состояния, L должно удовлетворять условию L \ge (K + 0.5)*1.5*R, где K — небольшое целое число. Тогда, в худшем случае, K-1 последовательных сообщений могут быть потеряны без ликвидации состояния. Чтобы вычислить время жизни L для комбинации состояний с различными R R0, R1, ..., заменяем R на max(Ri). В настоящее время по умолчанию K = 3. Однако может быть необходимо установить большее значение K для узлов с высокой вероятностью потерь. K может устанавливаться при конфигурации интерфейса вручную или с помощью какой-либо адаптивной процедуры.
3. Каждое сообщение Path или Resv несет в себе объект TIME_VALUES, который содержит время обновления R, использованное при генерации обновлений. Узел получателя использует это R для определения времени жизни L записанного состояния, созданного или обновленного данным сообщением.
4. Время обновления R выбирается локально для каждого из узлов. Если узел не использует локального восстановления резервирования, нарушенного в результате изменения маршрута, меньшее значение R ускоряет адаптацию к изменениям маршрута, но увеличивает издержки RSVP. Узел может настраивать эффективное значение R динамически, чтобы контролировать уровень издержек, связанных с сообщениями обновления. В настоящее время по умолчанию выбирается R = 30 секундам. Однако значение по умолчанию Rdef должно выбираться индивидуально для каждого интерфейса.
5. Когда R меняется динамически, существует предел того, как быстро оно может расти. Отношение величин R2/R1 не должно превосходить 1 + Slew.Max. В настоящее время, Slew.Max равно 0.30. При K = 3 один пакет может быть потерян без тайм-аута состояния, в то время как R увеличивается на 30% за период обновления.
6. Чтобы улучшить надежность, узел может временно после изменения состояния посылать сообщения обновления более часто.
7. Значения Rdef, K и Slew.Max, используемые в приложении, должны легко модифицироваться для каждого интерфейса.

Политика в области трафика и узлы с неинтегрированными услугами

Некоторые уровни QoS могут требовать определенной политики в управлении трафиком в некоторых или всех перечисленных ниже случаях.

1. Краевые точки сети.
2. Точки объединения данных от многих отправителей.
3. Точки ветвления, где трафик в различных ветвях может нуждаться в различных уровнях резервирования.

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

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

• E_Police_Flag — управление входом

  Этот флаг устанавливается для первого узла RSVP, который реализует управление трафиком. Например, ЭВМ-отправители должны поддерживать RSVP, но многие из них не поддерживают управление трафиком, — в этом случае флаг E_Police_Flag в ЭВМ-отправителе должен быть равен нулю. Флаг устанавливается равным 1, когда достигнута первая ЭВМ, поддерживающая управление трафиком. Это контролируется флагом E_Police в объектах SESSION.
• M_Police_Flag — управление объединением

  Этот флаг должен быть установлен для резервирования, использующего стили WF или SE, когда объединяются потоки более чем одного отправителя.
• B_Police_Flag — управление ветвлением

  Этот флаг должен быть установлен, когда инсталлированная flowspec меньше или сравнима с FLOWSPEC какого-либо другого интерфейса для того же самого FILTER_SPEC и SESSION.

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

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

ЭВМ с несколькими сетевыми интерфейсами

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

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

Посылка данных

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

RSVP-процесс ЭВМ посылает затем приложению сообщения Path только через специфицированный интерфейс.

Выполнение резервирования

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

Процесс RSVP должен посылать сообщения Resv приложению через специфицированный интерфейс. Однако когда приложение исполняется в маршрутизаторе, а сессия является мультикастной, возникает более сложная ситуация. Предположим, что в этом случае приложение получателя присоединяется к группе через интерфейс Iapp, который отличается от Isp — ближайшего интерфейса по пути к отправителю. Теперь имеется два возможных пути для мультикастной маршрутизации при доставке информационных пакетов приложению. Процесс RSVP должен определить, какой вариант выбрать, просмотрев состояние прохода и решив, какой из входных интерфейсов следует использовать для посылки сообщений.

1. Протокол мультикастной маршрутизации может создавать отдельные ветви дерева доставки к Iapp. В этом случае будет существовать состояние прохода для обоих интерфейсов Isp и Iapp. Состояние прохода в Iapp должно только соответствовать резервированию локального приложения. Оно должно быть помечено процессом RSVP как Local_only. Если существует состояние прохода Local_only для Iapp, сообщение Resv должно посылаться через Iapp. Заметим, что есть возможность для блоков состояния прохода Isp и Iapp иметь один и тот же следующий узел, если в маршрут вклинивается область, не поддерживающая RSVP.
2. Протокол мультикастной маршрутизации может переадресовать данные в пределах маршрутизатора от Isp к Iapp. В этом случае Iapp появится в списке выходных интерфейсов состояния прохода Isp и сообщения Resv должны будут посылаться через Isp.
3. Когда сообщения Path и PathTear переадресованы, состояние прохода, помеченное как Local_Only, должно игнорироваться.