Многоцелевое расширение почты Интернет

           

A.1.Детектирование изменения FEC следующего шага


Краткое изложение:

Отклик LSR на изменение следующего шага для FEC может включать в себя одну или более операций:

  1. Удаление из таблицы маршрутизации метки, соответствующей старому значению следующего шага для FEC;

  2. Передача сообщений присвоения метки для FEC одному или более партнерам LDP;

  3. Передача запроса метки новому узлу следующего шага для заданного FEC;

  4. Любая операция, которая может иметь место, когда LSR получает ассоциацию метка-FEC из узла следующего шага.

    Контекст:

  5. LSR. LSR, обрабатывающий событие.

  6. FEC. FEC, для которого изменился следующий шаг.

  7. New Next Hop. Новый следующий шаг для данного FEC.

  8. Old Next Hop. Предыдущий следующий шаг для FEC.

  9. OldLabel. Метка, (если имеется) ранее полученная от старого узла следующего шага.

  10. CurAttributes. Атрибуты, если имеются, ассоциированные в настоящее время с данным FEC.

  11. SAttributes. Атрибуты, подлежащие включению в сообщение запроса метки, (если имеются), которые надо послать новому узлу следующего шага.

Алгоритм :

NH.1 Получал ли LSR ранее от старого узла следующего шага и сохранил ли ассоциацию метка-FEC? Если нет, goto NH.6.
NH.2 Удалить метку из маршрутной таблицы. (Смотри замечание 1.)
NH.3 Использует ли LSR свободное сохранение меток? Если да, goto NH.6.
NH.4 Исполнить процедуру Send_Message(Old Next Hop, Label Release, OldLabel).
NH.5 Удалить ассоциацию метка-FEC, ранее полученную от старого узла следующего шага.
NH.6 Имеет ли LSR ожидающий запрос метки со старым значением следующего шага? Если нет, goto NH.10.
NH.7 Использует ли LSR консервативное сохранение меток?

Если нет, goto NH.10.
NH.8 Исполнить процедуру Send_ Message(Old Next Hop, Label Abort Request, FEC, TLV), где TLV является ID запроса метки, который несет в себе ID ожидающего запроса метки.
NH.9 Записать запрос ликвидации метки для FEC как ожидающий для старого узла следующего шага.
NH.10 Имеется новый следующий шаг для данного FEC?

Если нет, goto NH.16.
NH.11 Получил ли ранее LSR от нового узла следующего шага ассоциацию метка-FEC? Если нет, goto NH.13.
NH.12 Генерировать событие: Получена ассоциация метки от нового узла следующего шага. Goto NH.20. (Смотри замечание 2.)
NH.13 Использует ли LSR анонсирование Downstream on Demand? ИЛИ

Использует ли узел следующего шага анонсирование Downstream on Demand? ИЛИ

Использует ли LSR консервативное сохранение меток?

Смотри замечание 3.) Если да, goto NH.14. Если нет, goto NH.20.
NH.14 Исполнить процедуру Prepare_Label_Request_Attributes(следующий шаг, FEC, CurAttributes, SAttributes)
NH.15 Исполнить процедуру Send_Label_Request(New Next Hop, FEC, SAttributes). (Смотри замечание 4.) Goto NH.20.
NH.16 Продолжить итерацию через NH.19 для следующего партнера
NH.17 Послал ли LSR ранее партнеру ассоциацию метка-FEC?

Если нет, продолжить итерацию для следующего партера через NH.16.
NH.18 Исполнить процедуру Send_Label_Withdraw(Peer, FEC, Label previously sent to Peer).
NH.19 Завершить итерацию через NH.16.
NH.20 DONE

Замечания:

  1. Если метки нет в таблице маршрутизации, NH.2 не имеет последствий.

  2. Если LSR имеет метку для FEC от нового узла следующего шага, ему следует вести себя, как если бы он только что получил метку от нового узла следующего шага.

  3. Целью проверки режима сохранения метки является избежание участка с шагами LMp.12- LMp.13 процедуры обработки сообщения присвоения метки, где LSR, работая в режиме консервативного сохранения метки, может отправить сообщение присвоения метки, полученное от нового узла следующего шага, прежде чем обнаружит, что следующий шаг для данного FEC изменился.

  4. Вне зависимости от используемой LSR процедуры запроса метки, он должен послать запрос метки, если условия в NH.8 выполняются. Следовательно, он выполняет непосредственно процедуру Send_Label_Request, а не процедуру запроса метки LSR.



Содержание  Назад  Вперед