Исключение циклов сообщений RSVP

Переадресация сообщений RSVP должна исключать возможность образования петель. В спокойном состоянии сообщения Path и Resv направляются каждому узлу только раз за период обновления. Это исключает зацикливание пакетов, но имеется еще возможность петель "автоматического обновления". Такие петли автоматического обновления сохраняют состояние "вечно", даже если оконечные узлы прекращают их обновление до тех пор, пока получатели не покинут мультикастинг-группу и/или отправители прекратят посылку сообщения Path. С другой стороны сообщения об ошибке и об аннулировании (teardown) посылаются немедленно и могут служить причиной возникновения циклов.

Рассмотрим каждый тип сообщения.

Сообщения Path. Эти сообщения направляются точно тем же путем, что и информационные IP-пакеты. Следовательно, не должно возникать циклов для сообщений типа Path (за исключением циклов, связанных с переходными процессами установления маршрута).
Сообщения PathTear. Эти сообщения используют ту же маршрутизацию, что и сообщения Path и, следовательно, не могут образовывать циклов.
Сообщения PathErr. Так как сообщения Path не образуют циклов, они формируют состояние прохода, которое описывает обратный маршрут для каждого из отправителей, который не может иметь петель. Сообщения PathErr всегда направлены определенному отправителю и, следовательно, не могут образовывать циклов.
Сообщения Resv. Эти сообщения направлены определенному отправителю и не могут иметь циклов. Однако, сообщения Resv с произвольным выбором отправителя (wildcard) (стиль WF) имеет потенциал для запуска циклов обновления.
Сообщения ResvTear. Хотя сообщения ResvTear маршрутизируются также как и сообщения Resv. При повторном проходе по петле состояние будет отсутствовать (аннулировано), и любое сообщение ResvTear будет отброшено.
Сообщения ResvErr. Эти сообщения для стиля резервирования WF могут вызывать зацикливание по той же причине, что и для сообщений Resv.
Сообщения ResvConf. Эти сообщения направляются фиксированному уникастному получателю и не могут приводить к циклам.

Если топология не содержит петель, зацикливания сообщений Resv и ResvErr при произвольном выборе отправителя можно избежать, следуя приведенному выше правилу: состояние, которое получено через определенный интерфейс, никогда не должно переадресовываться через этот же интерфейс. Однако, когда топология содержит петли, необходимы дополнительные усилия для предотвращения циклов автоматического обновления для сообщений Resv и ResvErr с произвольным выбором отправителя. Решением этой проблемы может быть включение списка адресов получателей в объект SCOPE.

Когда сообщение Resv с стилем WF должно быть переадресовано определенному предыдущему узлу, следует определить новый список адресов для объекта SCOPE на основе аналогичного объекта, полученного с соответствующими сообщениями Resv. Если новый объект SCOPE пуст, сообщение не направляется предыдущему узлу. Правила для вычисления нового объекта SCOPE/ для сообщения Resv приведены ниже:

Образуется объединение наборов 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 следует придерживаться следующих правил:

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

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