Интегрированные сети ISDN
         

Блокада для стиля WF



Рисунок 4.4.9.6.11. Блокада для стиля WF

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

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

При этом используются следующие правила спецификации:

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

  • Когда приходит сообщение Path с адресом предыдущего узла, который отличается от записанного в состоянии прохода, RSVP должен немедленно послать сообщение обновления Resv этому PHOP.

    • 30. Временные параметры

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

    Более подробно:

  • Флойд и Джакобсон [FJ94] показали, что периодические сообщения, генерируемые независимыми сетевыми узлами, могут взаимно синхронизоваться.
    Это может привести к деградации сетевых услуг, так как периодические сообщения могут сталкиваться с другими сетевыми пакетами. Так как RSVP периодически посылает сообщения обновления, он должен избегать синхронизации сообщений и гарантировать, чтобы любая возникшая синхронизация не была стабильной. По этой причине таймер обновления должен быть рэндомизован в диапазоне [0.5R, 1.5R].


  • Чтобы избежать преждевременной потери состояния, L должно удовлетворять условию L ? (K + 0.5)*1.5*R, где K небольшое целое число. Тогда в худшем случае, K-1 последовательных сообщений могут быть потеряны без ликвидации состояния. Чтобы вычислить время жизни L для комбинации состояний с различными R R0, R1, ..., заменяем R на max(Ri). В настоящее время по умолчанию K = 3. Однако может быть необходимо установить большее значение K для узлов с высокой вероятностью потерь. K может устанавливаться при конфигурации интерфейса вручную или с помощью какой-либо адаптивной процедуры.


  • Каждое сообщение Path или Resv несет в себе объект TIME_VALUES, содержащий время обновления R, использованное при генерации обновлений. Узел получателя использует это R для определения времени жизни L записанного состояния, созданного или обновленного данным сообщением.




  • Время обновления R выбирается локально для каждого из узлов. Если узел не использует локального восстановления резервирования, нарушенного в результате изменения маршрута, меньшее значение R ускоряет адаптацию к изменениям маршрута, но увеличивает издержки RSVP. Узел может настраивать эффективное значение R динамически, чтобы контролировать уровень издержек, связанных с сообщениями обновления. В настоящее время по умолчанию выбирается R = 30 секундам. Однако значение по умолчанию Rdef должно выбираться индивидуально для каждого интерфейса.


  • Когда R меняется динамически, существует предел того, как быстро оно может расти. Отношение величин R2/R1 не должно превосходить 1 + Slew.Max. В настоящее время, Slew.Max равно 0.30. При K = 3, один пакет может быть потерян без таймаута состояния, в то время как R увеличивается на 30% за период обновления.




  • Чтобы улучшить надежность, узел может временно после изменения состояния посылать сообщения обновления более часто.


  • Значения Rdef, K и Slew.Max, используемые в приложении, должны легко модифицироваться для каждого интерфейса.




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



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

  • Краевые точки сети.


  • Точки объединения данных от многих отправителей.


  • Точки ветвления, где трафик в различных ветвях может требовать различных уровней резервирования.


    • 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. В отсутствии автоматических механизмов осуществляется ручная конфигурация.

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

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

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

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


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

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

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

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

    Процесс RSVP должен посылать сообщения Resv приложению через специфицированный интерфейс.


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

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


  • Протокол мультикастной маршрутизации может переадресовать данные в пределах маршрутизатора от Isp к Iapp. В этом случае Iapp появится в списке выходных интерфейсов состояния прохода Isp и сообщения Resv должны будут посылаться через Isp.


  • Когда сообщения Path и PathTear переадресованы, состояние прохода, помеченное как "Local_Only", должно игнорироваться.


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

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

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

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


    Этот выбор определяется двумя старшими битами октета Class-Num.

  • Class-Num = 0bbbbbbb. Все сообщение должно быть отброшено и возвращена ошибка "Unknown Object Class" (неизвестный класс объекта).


  • Class-Num = 10bbbbbb. Узел должен игнорировать объект без дальнейшей пересылки или отправки сообщений об ошибке.


  • Class-Num = 11bbbbbb. Узел должен игнорировать объект, но может переадресовать его далее без модификации со всеми сообщениями, вызванными данным запросом.


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

  • Такие объекты неизвестного класса, включенные в сообщения PathTear, ResvTear, PathErr или ResvErr, должны немедленно переадресовываться в рамках того же сообщения.


  • Такие объекты неизвестного класса, включенные в сообщения Path или Resv, должны быть записаны в соответствующие состояния и посланы в сообщениях обновления, сопряженных с указанным состоянием.


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


  • Исходный порядок таких объектов необязательно сохранять. Однако формируемое сообщение должно подчиняться общим правилам в отношении упорядочения объектов.


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

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

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

    Объекты определенных классов (FLOWSPEC, ADSPEC и POLICY_DATA) не прозрачны для RSVP, который просто передает их системе управления трафиком или другим модулям управления.


    В зависимости от внутренних правил любой из упомянутых модулей может отвергнуть C-Тип и информировать об этом RSVP-процесс; RSVP должен тогда отвергнуть такое сообщение и проинформировать об ошибке.

    35. Интерфейсы RSVP

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

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

    37. Интерфейс маршрутизации RSVP

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

    • Запрос маршрута


    Для пересылки сообщений Path и PathTear процесс RSVP должен быть способен запрашивать процесс маршрутизации с целью получения маршрутных данных.

    Ucast_Route_Query( [ SrcAddress, ] DestAddress,

    Notify_flag ) -> OutInterface

    Mcast_Route_Query( [ SrcAddress, ] DestAddress,

    Notify_flag )

    -> [ IncInterface, ] OutInterface_list

    В зависимости от протокола маршрутизации запрос может зависеть или нет от SrcAddress, т.е., от IP-адреса ЭВМ-отправителя, который является также IP-адресом источника сообщения. IncInterface характеризует интерфейс, через который ожидается прибытие пакета. Некоторые мультикастные протоколы маршрутизации могут не выдавать этот адрес. Если флаг Notify_flag = True, блок маршрутизации отправит сообщение о непреднамеренном изменении маршрута, если такое изменение произойдет.

    Мультикастный маршрутный запрос может вернуть пустой список OutInterface_list, если за оговоренным маршрутизатором нет ни одного получателя. Запрос маршрутной информации может вернуть сообщение `No such route' (такой маршрут отсутствует) возможно, в результате временной рассогласованности (например, сообщение Path или PathTear для запрошенного маршрута не дошло). В любом случае локальное состояние должно быть актуализовано так, как это требуется в запросе, который не может быть переслан далее.

    • Сообщение об изменении маршрута


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



    Ucast_Route_Change( ) -> [ SrcAddress, ] DestAddress,

    OutInterface

    Mcast_Route_Change( ) -> [ SrcAddress, ] DestAddress,

    [ IncInterface, ] OutInterface_list

    • Обнаружение списка интерфейсов


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

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

    38. Пакетные I/O интерфейсы RSVP

    Реализация RSVP нуждается в следующей поддержке со стороны систем ввода/вывода пакетов и со стороны механизма переадресации узла.

    • Неизбирательный режим приема сообщений RSVP


    Пакеты, полученные для IP-протокола (код 46) но не адресованные узлу, должны быть переправлены программе RSVP для последующей обработки. Сообщения RSVP переправляемые таким образом включают сообщения Path, PathTear и ResvConf. Эти типы сообщений несут в себе IP-опцию оповещение маршрутизатора (Router Alert), которая может быть использована для выделения этих пакетов в высокоскоростном канале переадресации. В качестве альтернативы узел может перехватывать все пакеты с кодом протокола 46.

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

    • Спецификация выходного канала




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

    • Спецификация адреса источника и TTL




    RSVP должен быть способен специфицировать IP-адрес отправителя и TTL, которые могут использоваться при посылке сообщений Path.

    • Оповещение маршрутизатора




    RSVP должен быть способен вызвать посылку сообщения Path, PathTear и ResvConf с опцией оповещения маршрутизатора (Router Alert).

    39. Манипуляции, зависящие от вида услуг

    Flowspecs, Tspecs и Adspecs являются объектами, совершенно недоступными для RSVP; их содержимое определено в документах спецификации услуг. Для того чтобы манипулировать этими объектами процесс RSVP должен иметь в своем распоряжении следующие программы, зависящие от типа услуг.

    • Сравнение спецификаций потоков


    Compare_Flowspecs( Flowspec_1, Flowspec_2 ) ->

    result_code

    Возможный результат операции result_codes указывает: flowspecs равны, Flowspec_1 меньше, Flowspec_2 больше, flowspecs совместимы и можно вычислить LUB, или flowspecs не совместимы. Заметим, что, сравнивая две спецификации, мы косвенно сопоставляем Tspecs, которые они содержат. Хотя процесс RSVP не может сам осуществить разбор flowspec с целью извлечения Tspec, он может использовать вызов процедуры Compare_Flowspecs для косвенного вычисления Resv_Te.

    • Сравнение LUB Flowspecs


    LUB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->

    Flowspec_LUB

    • Вычисление GLB Flowspecs


    GLB_of_Flowspecs( Flowspec_1, Flowspec_2 ) ->

    Flowspec_GLB

    • Сравнение Tspecs


    Compare_Tspecs( Tspec_1, Tspec_2 ) -> result_code

    Возможным результатом процедуры result_codes может быть: Tspecs равны или Tspecs не равны.

    • Сумма Tspecs


    Sum_Tspecs( Tspec_1, Tspec_2 ) -> Tspec_sum

    Этот вызов используется для вычисления Path_Te.


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