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

Рисунок 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.

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

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

Когда получено сообщение ResvErr, его спецификация flowspec Qe используется для формирования или обновления элемента местного состояния блокады. Каждый элемент состояния блокады состоит из спецификации flowspec Qb, взятой из спецификации сообщения ResvErr и соответствующего таймера блокады Tb. Когда время таймера блокады истекает, соответствующее состояние блокады аннулируется.

Гранулярность состояния блокады зависит от стиля сообщения ResvErr, которое явилось ее причиной. Каждому конкретному стилю может соответствовать свой элемент состояния блокады (Qb(S),Tb(S)), где S - отправитель. Для произвольного стиля выбора отправителя состояние блокады определяется предыдущим узлом P.

Элемент состояния блокады со спецификацией flowspec Qb называется блокадой резервирования со спецификацией flowspec Qi, если Qb не больше чем Qi.
Например, предположим, что LUB ( least upper bound) двух спецификаций flowspecs было вычислено путем выбора максимума составляющих их компонент. Тогда Qb блокирует Qi, если для некоторой компоненты j, Qb[j] ? Qi[j].

Предположим, что узел получает сообщение ResvErr от предыдущего узла P (или, если стиль выбора отправителя S является явным) в результате ошибки доступа. Тогда:

Для P (или S) создается элемент состояния блокады, если он не существует.

Qb(P) (или Qb(S)) делается равным flowspec Qe из сообщения ResvErr.

Запускается (или перезапускается) соответствующий таймер блокады Tb(P) (или Tb(S)) на время Kb*R. Здесь Kb является фиксированным множителем, а R равно интервалу времени обновления состояния резервирования. Kb можно варьировать.

Если имеется локальное состояние резервирования, которое не заблокировано, немедленно генерируется обновление резервирования для P (или S).

Сообщение ResvErr переадресуется последующим узлам. Если бит InPlace=0, сообщение ResvErr направляется всем последующим узлам, где имеется состояние резервирования. Если бит InPlace=1, сообщение ResvErr направляется только следующим узлам, чьи Qi блокированы спецификацией Qb.

В результате предлагается модифицированное правило для объединения спецификаций flowspecs при формировании сообщения обновления резервирования.

Если имеются какие-либо локальные запросы резервирования Qi, которые не заблокированы, они объединяются путем вычисления их LUB. Заблокированные резервирования игнорируются. Это позволяет требовать меньшее резервирование, которое имеет шанс на успех, после того как большее резервирование не удалось.

В противоположном случае (все локальные запросы Qi блокированы), они объединяются путем взятия GLB (Greatest Lower Bound) спецификаций Qi.

Этот алгоритм объединения обновления применяется отдельно для каждого потока (каждого отправителя или PHOP), вносящего вклад в общее резервирование (стили WF или SE).

На Рисунок 4.4.9.6.11 приведен пример использования состояния блокады для совместного резервирования (стиль WF).Имеется два предшествующих узла, помеченных как (a) и (b), и два последующих узла, помеченных как (c) и (d). Большее резервирование 4B пришло сначала от (c), но "застряло" где-то до PHOP (a), а не по пути через PHOP (b).

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