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


Сообщения Resv


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

<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <empty> |
<flow descriptor list> <flow descriptor>

Если присутствует объект INTEGRITY, он должен непосредственно следовать за общим заголовком. За объектом STYLE следует список дескрипторов потоков. Объекты в списке дескрипторов должны следовать требованиям записанных в BNF.

Объект NHOP (напр., RSVP_HOP) содержит IP-адрес интерфейса, через который посылаются сообщения Resv, и LIH для логического интерфейса, где требуется резервирование.

Появление объекта RESV_CONFIRM сигнализирует о запросе подтверждения резервирования и несет в себе IP-адрес получателя, которому должен быть послан ResvConf. Число объектов POLICY_DATA не лимитировано.

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

  • Стиль WF:

<flow descriptor list> ::= <WF flow descriptor>
<WF flow descriptor> ::= <FLOWSPEC>

  • Стиль FF:

<flow descriptor list> ::=
<FLOWSPEC> <FILTER_SPEC> |
<flow descriptor list> <FF flow descriptor>
<FF flow descriptor> ::=
[ <FLOWSPEC> ] <FILTER_SPEC>

Каждый запрос стиля FF описывается одной парой (FLOWSPEC, FILTER_SPEC), несколько таких запросов могут быть уложены в один список дескрипторов потока сообщения Resv. Объект FLOWSPEC может быть опущен, если он идентичен последнему такому объекту в списке; первый дескриптор потока стиля FF должен содержать FLOWSPEC.

  • Стиль SE:




Начало  Назад  Вперед