Протоколы Internet


Протокол резервирования ресурсов RSVP - часть 34


  • Образуется объединение наборов IP-адресов отправителей, перечисленных во всех объектах SCOPE состояния резервирования данной сессии. Если состояние резервирования от некоторых NHOP не содержит объектов SCOPE, должен быть создан заменяющий список отправителей, который и помещается в указанное объединение. Для сообщения, которое получено выходным интерфейсом OI, список замен представляет собой набор отправителей, которые маршрутизированы на этот OI.
  • Любые локальные отправители (т.е., любое приложение отправителя в данном узле) удаляются из этого списка.
  • Если объект SCOPE должен быть послан PHOP, следует удалить из набора любого отправителя, который не присылает данные через PHOP.
  • На рис. 4.4.9.6.10 показан пример Resv сообщений (стиль WF). Адресный список объекта SCOPE показан в квадратных скобках.

    >

    Интерфейс IА

    Интерфейс IБ

    Интерфейс IВ

    Получает

    Отправляет

    Получает

    Отправляет

    Получает

    Отправляет

    WF([S1,S2,S3])

    WF([S4])

    WF([S2,S3,S4])

    WF([S1])

    WF([S4,S1])

    WF([S2,S3])

    Рис. 4.4.9.6.10. Объекты SCOPE при резервировании в стиле WF

    Объекты SCOPE не являются необходимыми, если мультикастинг-маршрутизация использует совместные деревья или если стиль резервирования предполагает явный выбор отправителей. При использовании объектов SCOPE в сообщениях ResvErr стиля WF следует придерживаться следующих правил:

    1. Узел, который обнаружил ошибку, отправляет сообщение ResvErr, содержащее копию объекта SCOPE, соответствующего состоянию резервирования или сообщению, которое вызвало ошибку.
    2. Предположим, что узлом получено сообщение ResvErr с произвольным указанием отправителей (wildcard), содержащее объект SCOPE со списком адресов отправителей L. Сообщение ResvErr, переадресованное интерфейсу OI должно содержать объект SCOPE, извлеченный из L и включающий только те адреса отправителей, которые маршрутизированы на OI. Если этот объект SCOPE пуст, сообщение ResvErr не должно посылаться OI.

    28. Состояние блокады

    Основным правилом при формировании сообщения обновления Resv является объединение спецификаций flowspecs резервирования в узле посредством вычисления их LUB (наименьший верхний предел). Однако это правило модифицируется при наличии "состояния блокады", возникшего из-за сообщений ResvErr при решении проблемы KR-II.




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