Примеры сетевых топологий
         

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


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

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

Вызов: SESSION( DestAddress , ProtocolId, DstPort
[ , SESSION_object ]
[ , Upcall_Proc_addr ] ) -> Session-id

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

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

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

Вызов: SENDER( Session-id
[ , Source_Address ] [ , Source_Port ]
[ , Sender_Template ]
[ , Sender_Tspec ] [ , Adspec ]
[ , Data_TTL ] [ , Policy_data ] )

Отправитель использует этот вызов, чтобы определить или модифицировать атрибуты информационного потока. Первое обращение к 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


Вызов: RESERVE( session-id, [ receiver_address , ]
[ CONF_flag, ] [ Policy_data, ]
style, style-dependent-parms )

Получатель использует этот вызов, для того чтобы осуществить или модифицировать резервирование для сессии `session-id'. Первое обращение RESERVE инициирует периодическую передачу сообщений Resv. Последующие вызовы RESERVE могут служить для модификации параметров предыдущих обращений.

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


Вызов: RELEASE( session-id )

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


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

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

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

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



1. Info_type = PATH_EVENT

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

Обращение (отклик): <Upcall_Proc>( ) -> session-id,
Info_type = PATH_EVENT,
Sender_Tspec, Sender_Template
[ , Adspec ] [ , Policy_data ]

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

2. Info_type = RESV_EVENT

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

Обращение (отклик): <Upcall_Proc>( ) -> session-id,
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.

Обращение (отклик): <Upcall_Proc>( ) -> session-id,
Info_type=PATH_ERROR,
Error_code , Error_value ,
Error_Node , Sender_Template
[ , Policy_data_list ]

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

4. Info_type = RESV_ERR

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

Обращение (отклик): <Upcall_Proc>( ) -> session-id,
Info_type = RESV_ERROR,
Error_code , Error_value ,
Error_Node , Error_flags ,
Flowspec, Filter_spec_list
[ , Policy_data_list ]



Параметр 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.

Обращение (отклик): <Upcall_Proc>( ) -> session-id,
Info_type = RESV_CONFIRM,
Style, List_count,
Flowspec, Filter_spec_list
[ , Policy_data ]

Параметры интерпретируются также как и для отклика Resv Error.

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

36. Интерфейс управления трафиком 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 и субкод причины.


Содержание раздела