Опубликован: 28.09.2007 | Доступ: свободный | Студентов: 5794 / 808 | Оценка: 4.20 / 4.10 | Длительность: 47:32:00
ISBN: 978-5-94774-707-2
Лекция 10:

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

Будущая совместимость

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

  1. Неизвестный класс

    Существует три возможных способа, чтобы приложение RSVP могло работать с объектом неизвестного класса. Этот выбор определяется двумя старшими битами октета Class-Num.

    • Class-Num = 0bbbbbbb. Все сообщение должно быть отброшено и возвращена ошибка Unknown Object Class (неизвестный класс объекта).
    • Class-Num = 10bbbbbb. Узел должен игнорировать объект без дальнейшей пересылки или отправки сообщений об ошибке.
    • Class-Num = 11bbbbbb. Узел должен игнорировать объект, но может переадресовать его далее без модификации со всеми сообщениями, вызванными данным запросом.

    Ниже приведены более детализированные правила работы с нераспознанными классами объектов для Class-Num вида 11bbbbbb.

    1. Такие объекты неизвестного класса, включенные в сообщения PathTear, ResvTear, PathErr или ResvErr, должны немедленно переадресовываться в рамках того же сообщения.
    2. Такие объекты неизвестного класса, включенные в сообщения Path или Resv, должны быть записаны в соответствующие состояния и посланы в сообщениях обновления, сопряженных с указанным состоянием.
    3. Когда формируется обновление Resv путем объединения нескольких запросов резервирования, сообщение обновления должно включать в себя объединение объектов неузнанных классов всех компонентов запроса. В этом объединении каждый такой объект может присутствовать только один раз.
    4. Исходный порядок таких объектов необязательно сохранять. Однако формируемое сообщение должно подчиняться общим правилам в отношении упорядочения объектов.

    Хотя объекты с неизвестным классом не могут объединяться, эти правила позволяют передать их вплоть до узла, который сможет их распознать и объединить.

  2. Неизвестный C-Тип для известного класса

    Появление объекта с неизвестным C-типом приведет к выбрасыванию всего сообщения и генерации сообщения об ошибке ( ResvErr или PathErr ). Сообщение об ошибке будет включать Class-Num и C-тип, который был не распознан. Оконечная система, которая отправила нераспознанное сообщение, может использовать эту информацию, чтобы попытаться повторить попытку с объектом другого C-типа.

    Объекты определенных классов ( FLOWSPEC, ADSPEC и POLICY_DATA ) не прозрачны для протокола RSVP, который просто передает их системе управления трафиком или другим модулям управления. В зависимости от внутренних правил любой из упомянутых модулей может отвергнуть C-тип и информировать об этом RSVP-процесс; RSVP должен тогда отвергнуть такое сообщение и проинформировать об ошибке.

Интерфейсы RSVP

RSVP в маршрутизаторе имеет интерфейсы для управления трафиком, а в ЭВМ — интерфейсы для приложений (т.е., API), а также для управления трафиком (если такой контроль предусмотрен).

Интерфейс приложения RSVP

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

  • Регистрация сессии

    Этот вызов инициирует RSVP обработку сессии, заданной DestAddress, ProtocolId и, возможно, номером порта DstPort. В случае успеха вызов SESSION возвращает локальный идентификатор сессии Session-id, который может использоваться при последующих вызовах.

    Параметр Upcall_Proc_addr определяет адрес вызова процедуры получения кода ошибки или информации о событии. Параметр SESSION_object включен для организации механизма поддержки более общего описания сессии (обобщенный порт назначения). Обычно SESSION_object опускается.

  • Определение отправителя

    Отправитель использует этот вызов, чтобы определить или модифицировать атрибуты информационного потока. Первое обращение к SENDER для регистрации сессии как Session-id заставит RSVP начать рассылку сообщений Path для данной сессии; последующие вызовы будут модифицировать информацию о проходе. Параметры SENDER интерпретируются следующим образом:

    • Source_Address. Это адрес интерфейса, через который будут посылаться данные. Если этот параметр пропущен, будет использоваться интерфейс по умолчанию. Этот параметр необходим для ЭВМ с двумя и более сетевыми интерфейсами;
    • Source_Port. Это UDP/TCP порт, через который будут посылаться данные;
    • Sender_Template. Этот параметр включен для поддержки механизма более общего описания отправителя (обобщенный порт источника). Обычно этот параметр может быть опущен;
    • Sender_Tspec. Этот параметр описывает трафик потока (смотри [RFC-2210]);
    • Adspec. Этот параметр может быть специфицирован для инициализации вычисления свойств QoS вдоль пути (смотри [RFC-2210]);
    • Data_TTL. Это IP TTL параметр, который несут в себе информационные пакеты. Он необходим, чтобы гарантировать условие, при котором сообщения Path не будут попадать за пределы зоны мультикастинг-сессии;
    • Policy_data. Это опционный параметр несет в себе управляющую информацию для отправителя. Эта информация может задаваться системной службой и для приложения может быть недоступной;
    • RESERVE. Получатель использует этот вызов, чтобы осуществить или модифицировать резервирование session-id сессии. Первое обращение RESERVE инициирует периодическую передачу сообщений Resv. Последующие вызовы RESERVE могут служить для модификации параметров предыдущих обращений.

Опционный параметр receiver_address может использоваться получателем в маршрутизаторе или ЭВМ с несколькими сетевыми интерфейсами; это IP-адрес одного из интерфейсов узла. Флаг CONF_flag должен быть установлен, если желательно подтверждение резервирования. Параметр Policy_data специфицирует управляющие данные получателя, в то время как параметр style указывает на стиль резервирования. Остальные параметры зависят от стиля; обычно они соответствуют спецификациям фильтра и flowspecs.

  • Отбой. Вызов: RELEASE( sessionid )

    Этот вызов удаляет состояние RSVP для сессии, указанной в sessionid. Узел затем шлет соответствующие сообщения отмены (teardown) и прекращает рассылку сообщений обновления для session-id.

  • Вызовы Error/Event (ошибка/событие)

    Общая форма вызова имеет вид:

    Обращение: <Upcall_Proc>( ) > sessionid, Info_type, information_parameters

    Upcall_Proc представляет собой процедуру, чей адрес был дан при вызове SESSION. Это обращение может произойти асинхронно в любое время после вызова SESSION до вызова RELEASE и служит для индикации ошибки или события.

В настоящее время имеется пять типов обращений, отличающихся параметром Info_type. Выбор информационных параметров зависит от типа.

  1. Info_type = PATH_EVENT

    Обращение Path Event приводит к тому, что получение первого сообщения Path для данной сессии указывает приложению получателя на наличие, по крайней мере, одного отправителя или на изменение состояние прохода.

    Это обращение выдает спецификации Sender_Tspec, Sender_Template, Adspec и управляющую информацию из запроса Path.

  2. Info_type = RESV_EVENT

    Обращение Resv Event запускается в результате получения первого сообщения RESV или как следствие модификации предшествующего состояния резервирования для данной сессии.

    Обращение (отклик): <Upcall_Proc>( ) > sessionid,
    Info_type = RESV_EVENT,
    Style, Flowspec, Filter_Spec_list
    [ , Policy_data ]

    Flowspec — эффективное значение QoS, которое получено. Заметим, что сообщение Resv (стиль FF) может вызвать несколько обращений RESV_EVENT, по одному для каждого дескриптора потока.

  3. Info_type = PATH_ERROR

    Событие Path Error индицирует ошибку в информации отправителя, которая была специфицирована в запросе SENDER.

    Параметр Error_code определяет ошибку, а Error_value может нести в себе некоторую дополнительную (возможно, системно-зависимую) информацию об ошибке. Параметр Error_Node специфицирует IP-адрес узла, который обнаружил ошибку. Параметр Policy_data_list, если он присутствует, содержит любые объекты POLICY_DATA из неудачного сообщения Path.

  4. Info_type = RESV_ERR

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

    Параметр Error_Node специфицирует IP-адрес узла, который обнаружил данное событие. Имеется два флага Error_flags:

    InPlace

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

    NotGuilty

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

    Filter_spec_list и Flowspec содержат соответствующие объекты из дескриптора ошибки. List_count специфицирует число FILTER_SPECS в списке Filter_spec_list. Параметр Policy_data_list содержит любые объекты POLICY_DATA из сообщения ResvErr.

  5. Info_type = RESV_CONFIRM

    Событие Подтверждение указывает, что получено сообщение ResvConf.

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

Интерфейс управления трафиком RSVP

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

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

  1. IP-уровень

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

  2. Сеть

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

  3. Драйвер канального уровня

    В технологиях с множественным доступом размножение пакетов может осуществляться на уровне канального драйвера или сетевого интерфейса.

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

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

    Вызов: TC_AddFlowspec( Interface, TC_Flowspec,TC_Tspec, TC_Adspec, Police_Flags ) > RHandle [, Fwd_Flowspec]

    Параметр TC_Flowspec определяет желательное значение QoS для управления доступом. Его значение вычисляется как максимум совокупности спецификаций flowspecs для последующих узлов (см. ниже описание вызова Compare_Flowspecs ). Параметр TC_Tspec определяет эффективное значение спецификации отправителя Tspec Path_Te. Параметр TC_Adspec задает спецификацию Adspec. Параметр Police_Flags несет в себе три флага: E_Police_Flag, M_Police_Flag и B_Police_Flag.

    Если данный вызов оказался успешным, он устанавливает новый канал резервирования, соответствующий RHandle ; в противном случае, он возвращает код ошибки. Код RHandle используется вызывающей программой для будущих ссылок на это резервирование. Если служба управления трафиком модифицирует flowspec, вызов вернет модифицированный объект Fwd_Flowspec.

  • Модификация резервирования
    Вызов: TC_ModFlowspec( Interface, RHandle, TC_Flowspec,
    TC_Tspec, TC_Adspec, Police_flags ) [ > Fwd_Flowspec ]

    Этот вызов используется для модификации существующего резервирования. TC_Flowspec передается блоку контроля разрешения. Если разрешения нет, текущая спецификация flowspec остается в силе. Соответствующие спецификации фильтров, если таковые имеются, остаются не затронутыми. Другие параметры определены так же, как и в TC_AddFlowspec. Если система модифицирует flowspec, вызов вернет также модифицированный объект Fwd_Flowspec.

  • Уничтожение спецификации Flowspec

    Вызов: TC_DelFlowspec( Interface, RHandle )

    Этот вызов ликвидирует существующее резервирование, включая спецификацию flowspec и все сопряженные спецификации фильтров.

  • Добавление спецификации фильтра

    Вызов: TC_AddFilter( Interface, RHandle, Session , FilterSpec ) > FHandle

    Этот вызов добавляет новую спецификацию фильтра для резервирования, заданного RHandle. Запрос посылается после успешного вызова TC_AddFlowspec. Этот вызов возвращает дескриптор фильтра FHandle.

  • Уничтожение спецификации фильтра

    Вызов: TC_DelFilter( Interface, FHandle )

    Этот вызов используется для удаления какого-либо фильтра, идентифицируемого FHandle.

  • Модификация OPWA

    Вызов: TC_Advertise( Interface, Adspec, Non_RSVP_Hop_flag ) > New_Adspec

    Этот вызов используется при OPWA и служит для вычисления выходной спецификации New_Adspec для заданного интерфейса. Битовый флаг Non_RSVP_Hop_flag должен устанавливаться в случае, когда демон RSVP обнаруживает, что предшествующий узел содержит один или более маршрутизаторов, не поддерживающих RSVP. TC_Advertise вставит эту информацию в New_Adspec для оповещения обнаружения такого узла.

  • Запрос резервирования

    Обращение (отклик): TC_Preempt() > RHandle, Reason_code

    Чтобы выдать новый запрос резервирования, модули контроля разрешения и управления могут осуществить выделение квот для одного или двух существующих резервирований. Это вызовет отклик TC_Preempt() на каждое привилегированное RSVP-резервирование, отправляя дескриптор резервирования RHandle и субкод причины.

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

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

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

Мария Архипова
Мария Архипова