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

Сообщения отмены Resv


Получение сообщения ResvTear (reservation teardown) удаляет соответствующие состояния резервирования. При этом проверяется соответствие объектов SESSION, STYLE и FILTER_SPEC, а также LIH в объекте RSVP_HOP. Если соответствие не обнаружено, сообщение ResvTear игнорируется. Сообщение ResvTear может отменить любой субнабор спецификаций фильтрации в состояниях резервирования стилей FF или SE.

Сообщения ResvTear отправляются получателями или любым узлом, в котором состояние резервирование аннулируется в результате таймаута, далее они движутся в направлении получателей.

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

<ResvTear Message> ::= <Common Header> [<INTEGRITY>]
<SESSION> <RSVP_HOP>
[ <SCOPE> ] <STYLE>
<flow descriptor list>
<flow descriptor list> ::= (see earlier definition)

Объекты FLOWSPEC в списке дескрипторов потоков сообщения ResvTear будут игнорироваться и могут быть опущены. Сообщение ResvTear может включать в себя объект SCOPE, но он должен игнорироваться.

В зависимости от изменения состояния узла получение сообщения ResvTear может вызвать переадресацию этого сообщения, посылку модифицированного сообщения Resv или не вызвать никакого сообщения. Эти три случая могут быть проиллюстрированы для стиля резервирования FF на рис. 4.4.9.6.4.

  • Если получатель R2 посылает сообщение ResvTear для резервирования S3{B}, соответствующее резервирование удаляется из интерфейса (IГ) и посылается ResvTear для S3{B} интерфейсу (IБ).
  • Если получатель R1 посылает ResvTear для резервирования S1{4B}, соответствующее резервирование удаляется из интерфейса (IВ) и немедленно посылается модифицированное сообщение Resv FF( S1{3B} ) интерфейсу (IА).
  • Если получатель R3 посылает сообщение ResvTear для S1{B}, никаких изменений резервирования не происходит и никаких сообщений далее не посылается.



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