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

AПроцедуры рассылки меток LDP


В этом разделе описана схема рассылки в терминах отклика LSR на следующие события:

  1. Получение сообщения запроса метки;

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

  3. Получение сообщения запроса ликвидации метки;

  4. Получение сообщения освобождения метки;

  5. Получение сообщения отзыва метки;

  6. Распознание нового FEC;

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

  8. Получение сообщения уведомления / аннулирован запрос метки;

  9. Получение сообщения уведомления / нет ресурсов для метки;

  10. Получение сообщения уведомления / Нет маршрута;

  11. Получение сообщения уведомления / детектирована петля;

  12. Получение сообщения уведомления / для метки есть ресурсы;

  13. Детектирование доступности локальных ресурсов для метки;



  14. LSR решает не использовать коммутацию по метке для данного FEC;

  15. Таймаут для отложенного запроса метки.

Спецификация поведения LSR в ответ на событие имеет три части:

  1. Краткое изложение. Описание того, как реагирует LSR на события.

  2. Контекст. Список элементов относящихся к части алгоритма спецификации. (Смотри 3.)

  3. Алгоритм. Алгоритм отклика LSR на событие.

Краткое изложение может опускать детали отклика LSR, такие как ведение журналов или поведение, зависящее от режима анонсирования меток LSR, использования режима управления, или режима удержания меток. Алгоритм исчерпывающе и однозначно специфицирует отклик LSR.

Алгоритмы в данном разделе используют процедуры, определенные спецификацией архитектуры MPLS [RFC 3031] для маршрутизации трафика шаг-за-шагом. Это следующие процедуры:

  1. Процедура рассылки меток, которая выполняется нижестоящим LSR, чтобы определить, когда рассылать метки LDP партнерам для FEC . Архитектура определяет четыре процедуры рассылки меток:

  1. Независимое управление Downstream Unsolicited , называемое в [RFC3031] PushUnconditional .

  2. Упорядоченное управление Downstream Unsolicited? называемое в [RFC 3031] PushConditional.

  3. Независимое управление Downstream On Demand, называемое в [RFC 3031] PulledUnconditional.

  4. Упорядоченное управление Downstream On Demand, называемое в [RFC 3031] PulledConditional.


  1. Процедура отзыва метки, которая выполняется нижерасположенным LSR, чтобы определить, когда отзывать ассоциацию FEC-метка, разосланную ранее LDP партнерами. Архитектура определяет процедуру отзыва метки. Всякий раз, когда LSR разрывает ассоциацию метки и FEC, он должен отозвать ассоциацию FEC-метка для всех партнеров LDP, которым ранее была разослана эта информация.


  2. Процедура запроса метки, которая выполняется вышестоящим LSR , чтобы определить, когда явно запросить, чтобы нижестоящий LSR связал метку с FEC . Архитектура определяет три процедуры запроса метки:


  • Никаких запросов. LSR никогда не посылает запросов метки.


  • Запросить, когда нужно. LSR запрашивает метку, когда она ему требуется.


  • Запрос на запрос. Эта процедура используется LSR без поддержки объединения. LSR запрашивает метку, когда он получает такой запрос, в дополнение к случаям, когда он нуждается в ней сам.

    1. Процедура освобождения метки, которая выполняется вышестоящим LSR , чтобы определить, когда освободить полученную ранее ассоциацию метки с FEC. Архитектура определяет две процедуры освобождения меток:


    2. Консервативное сохранение (retention) метки, называемое освобождение при замене (Release On Change) [RFC3031].


    3. Свободное сохранение метки, называемое никакого освобождения при замене (No Release On Change) [RFC3031].

      1. Процедура использования метки (Label Use ), которая выполняется LSR, чтобы определить, когда начать использование переадресации для ассоциации FEC-метка. Архитектура определяет три процедуры использования метки:


      2. Немедленное использование (Use Immediate). LSR немедленно использует для переадресации, метку, полученную от узла следующего шага для заданного FEC.


      3. Использование, если нет петель. LSR использует для переадресации пакетов FEC-метку, полученную от узла следующего шага для данного FEC, если только заранее известно, что это не приведет к зацикливаниям.


      4. Использование, если не обнаружена петля. Эта процедура аналогична немедленному использованию, если только LSR не обнаружил петель в LSP. Использование метки будет продолжаться до тех пор, пока не изменится следующий шаг для FEC.

        1. Процедура Label No Route (называемая в [RFC3031] Label Not Available [метка недоступна]), которая выполняется вышестоящим LSR, чтобы определить, как реагировать на уведомление об отсутствии маршрута от нижестоящего LSR в ответ на запрос FEC-метки. Архитектура спецификации определяет две процедуры Label No Route:


        2. Повторная попытка запроса. LSR должен выдать запрос метки позднее.


        3. Никаких повторов запроса. LSR должен полагать, что нижестоящий LSR предоставит метку, когда у вышестоящего LSR имеется узел следующего шага и он не должен повторно посылать запрос.



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