RFC 5036 Часть 2

Donation Goal Detail
image_print

Часть 1

4. Согласование с IANA

LDP определяет несколько пространств имен, требующих управления:

  • Message Type;
  • TLV Type;
  • FEC Type;
  • Status Code;
  • Experiment ID;

В последующих параграфах приведены рекомендации по управлению этими пространствами имен.

4.1. Пространство имен Message Type

LDP делит пространство типов сообщений на три части. Ниже приведены рекомендации по управлению этими частями.

  • Message Type 0x0000 – 0x3DFF. Сообщения, типы которых относятся к этому диапазону, являются частью базового протокола LDP. В соответствии с политикой [IANA], значения Message type из этого диапазона выделяются по процедуре IETF Consensus.
  • Message Type 0x3E00 – 0x3EFF. Сообщения, типы которых относятся к этому диапазону, зарезервированы для фирменных (Vendor-Private) расширений и ответственность за них лежит на производителях (см. параграф 3.6.1.2. Сообщение LDP Vendor-Private). Участие IANA в распределении этой части пространства имен не требуется.
  • Message Type 0x3F00 – 0x3FFF. Сообщения, типы которых относятся к этому диапазону, зарезервированы для экспериментальных расширений и ответственность за них ложится на экспериментаторов (см. параграф 3.6.2. Экспериментальные расширения LDP). Участие IANA в распределении этой части пространства имен не требуется, однако IANA отвечает за управление частью пространства имен Experiment ID (см. ниже).

4.2. Пространство имен TLV Type

LDP делит пространство типов TLV на три части. Ниже приведены рекомендации по управлению этими частями.

  • TLV Type 0x0000 – 0x3DFF. Типы TLV из этого диапазона являются частью базового протокола LDP. В соответствии с политикой [IANA], значения TLV type из этого диапазона выделяются по процедуре IETF Consensus.
  • TLV Type 0x3E00 – 0x3EFF. Типы TLV из этого диапазона зарезервированы для фирменных (Vendor-Private) расширений и ответственность за них ложится на производителей (см. параграф 3.6.1.1. LDP Vendor-Private TLV). Участие IANA в распределении этой части пространства имен не требуется.
  • TLV Type 0x3F00 – 0x3FFF. Типы TLV из этого диапазона зарезервированы для экспериментальных расширений и ответственность за них ложится на экспериментаторов (см. параграфы 3.6.2. Экспериментальные расширения LDP и 4.5. Пространство имен Experiment ID). Участие IANA в распределении этой части пространства имен не требуется, однако IANA отвечает за управление частью пространства имен Experiment ID (см. ниже).

4.3. Пространство имен FEC Type

Диапазон типов FEC – 0 – 255.

В соответствии с политикой [IANA], значения FEC из диапазона 0 – 127 выделяются по процедуре IETF Consensus, из диапазона 128 – 191 – в порядке подачи заявок (процедура First Come First Served), а значения 192 – 255 зарезервированы для приватного использования (Private Use).

4.4. Пространство имен Status Code

Диапазон значений кодов состояния (Status Code) – 0x00000000 – 0x3FFFFFFF.

В соответствии с политикой [IANA], значения значения Status Code из диапазона 0x00000000 – 0x1FFFFFFF выделяются по процедуре IETF Consensus, из диапазона 0x20000000 – 0x3EFFFFFF – в порядке подачи заявок (процедура First Come First Served), а значения из диапазона 0x3F000000 – 0x3FFFFFFF зарезервированы для приватного использования (Private Use).

4.5. Пространство имен Experiment ID

Диапазон значений Experiment ID – 0x00000000 – 0xffffffff.

В соответствии с политикой [IANA], значения значения Experiment ID из диапазона 0x00000000 – 0xefffffff выделяются в порядке подачи заявок (процедура First Come First Served), а значения из диапазона 0xf0000000 – 0xffffffff зарезервированы для приватного использования (Private Use).

5. Вопросы безопасности

В этом разделе рассматриваются угрозы, которым может быть подвержен протокол LDP и меры по снижению влияния таких угроз.

5.1. Обманные пакеты

Два типа коммуникаций LDP могут быть подвержены атакам на базе обманных пакетов.

  1. Раскрытие обмена по протоколу UDP.LSR показывает свои намерения организовать и поддерживать сессии LDP путем периодической передачи сообщений Hello. Прием сообщения Hello служит для организации новой «Hello-смежности», если такие отношения не были организованы ранее, или обновления существующей смежности. Обманные пакеты Hello для существующих отношений смежности могут к возникновению тайм-аутов для смежности в прерыванию связанных сеансов LDP. Угроза может быть реализована путем передачи обманных сообщений Hello с малым значением Hold Time, заставляющим получателя ожидать приема сообщений Hello в течение обманно заданного короткого интервала, в то время, как легитимный сосед (партнер по сессии) бдут передавать сообщения Hello более редко (с согласованной ранее частотой).Маршрутизаторы LSR, непосредственно соединенные между собой на канальном уровне обмениваются через соединяющий их канал сообщениями Basic Hello. Угроза воздействия обманных сообщений Basic Hellos может быть снижена двумя путями:
  • восприятие сообщений Basic Hello только через интерфейсы, к которым подключены доверенные LSR;
  • игнорирование сообщений Basic Hello, не направленных по групповому адресу All Routers on this Subnet (все маршрутизаторы данной подсети).

Маршрутизаторы LSR, не соединенные непосредственно на канальном уровне, могут использовать сообщения Extended Hello для индикации своего намерения организовать сеанс LDP. LSR может снизить влияние угроз использования обманных пакетов Extended Hello за счет фильтрации таких пакетов с восприятием только тех пакетов, адреса отправителей которых соответствуют заданному списку.

  1. Сеансовый обмен данными по протоколу TCP.LDP задает использование опции TCP MD5 Signature для обеспечения достоверности и целостности сеансовых сообщений.В [RFC2385] отмечено, что алгоритм MD5 некоторые считают недостаточно сильным для защиты протокола LDP. Указано также возможность реализации похожей опции TCP с более строгим алгоритмом хэширования (например, SHA-1). Насколько нам известно, такая опция TCP не была определена и реализована. Тем не менее, отметим, что протокол LDP может использовать любые методы цифровой подписи TCP и при определении и реализации более строгого, нежели MD5, алгоритма обновление LDP для использования такого алгоритма не вызовет существенных затруднений.

5.2. Конфиденциальность

LDP не поддерживает механизмов обеспечения конфиденциальности при распространении меток.

Требования безопасности при распространении меток в значительной мере совпадают с требованиями безопасности для протоколов распространения маршрутной информации. За счет механизма контроля подлинности и целостности сообщений протокол LDP обеспечивает уровень защиты, который достаточно хорош, но не превосходит уровня защиты самих протоколов маршрутизации. Рассмотрение более общего вопроса о требованиях к уровню конфиденциальности для протоколов маршрутизации выходит за пределы данного документа.

Можно сказать, что защита конфиденциальности при распространении меток нужна для предотвращения угрозы подмены меток. Однако такая защита не поможет против атак с обманными метками, пока пакеты с метками будут передаваться в открытом (незашифрованном) виде. Более того, атаки с использованием обманных меток могут быть организованы без наличия сведений о привязках FEC к меткам.

Для предотвращения атак с обманными метками требуется обеспечить, чтобы пакеты данных исходили от доверенных LSR, а включенные в пакеты метки были корректно получены самими LSR.

5.3. Отказ служб

Протокол LDP потенциально уязвим для двух типов атак на отказ служб (DoS):

  1. Общеизвестный номер порта UDP для LDP Discovery.Администратор LSR может защититься от DoS-атак с использованием сообщений Basic Hello за счет организации прямых соединений только с доверенными LSR, которые не будут являться источниками атак. Интерфейсы к партнерам, расположенным в том же административном домене, не рассматриваются в качестве источника угроз, поскольку они находятся под собственным административным контролем. Интерфейсы к внешним партнерам могут быть потенциальным источником атаки, поскольку они находятся под чужим управлением. Администратор может снизить риск атак за счет организации соединений LSR только с теми внешними партнерами, которые не могут послужить источником атак Basic Hello.DoS-атаки с использованием сообщений Extended Hello представляют более серьезную опасность. Эту угрозу можно предотвратить путем фильтрации сообщений Extended Hello с использованием списков доступа, определяющих адреса, для которых разрешен механизм Extended Discovery. Однако фильтрация требует ресурсов LSR.В средах, где можно идентифицировать доверенное облако MPLS, маршрутизаторы LSR на краях облака могут служить для защиты внутренних LSR этого облака от DoS-атак с использованием сообщений Extended Hello путем фильтрации сообщений Extended Hello, приходящих из=за пределов доверенного облака MPLS, принимая лишь сообщения с адресов, разрешенных списками доступа. Такая фильтрация позволяет защитить внутренние LSR, но будет потреблять ресурсы краевых маршрутизаторов.
  2. Общеизвестный номер порта TCP для организации сессий LDP.Подобно другим протоколам управляющего плана, которые используют транспорт TCP, протокол LDP может быть целью DoS-атак (например, SYN). Протокол LDP уязвим для таких атак не более и не менее других подобных протоколов, работающих на базе TCP.Для снижения угрозы таких атак можно воспользоваться приведенными ниже рекомендациями.
    • LSR следует избегать «неразборчивого» (promiscuous) прослушивания TCP на предмет организации сеансов LDP. Следует прослушивать порт только для обнаруженных ранее партнеров. Это позволит отбрасывать пакеты, связанные с атакой, до их обработки, поскольку пакеты атакующего в большинстве случаев не будут соответствовать существующим или организуемым соединениям.
    • Использование опции MD5 позволяет защититься от SYN-атак, поскольку пакеты не будут восприниматься до проверки корректности значения хэша MD5. Однако такая проверка будет требовать расчета контрольной суммы для каждого принимаемого сегмента SYN (расход ресурсов маршрутизатора).
    • Использование списков доступа на границе облака MPLS (как описано выше для сообщений Extended Hello) позволит защитить внутренние узлы от атак извне облака.

6. Направления дальнейших исследований

Перечисленные ниже вопросы не решены в текущей версии протокола LDP и требуют дополнительного изучения.

  • В параграфе 2.16 [RFC3031] требуется, чтобы начальное согласование протокола распространения меток между LSR позволяло каждому LSR определить способность партнера поддерживать стек меток. В данной версии LDP предполагается, что маршрутизаторы LSR поддерживают это для всех типов меток, кроме ATM и Frame Relay. В будущих версиях протокола определение упомянутой возможности может стать частью согласования сессии.
  • Поддержка в LDP классов обслуживания (CoS) в данной версии не определена. Поддержка CoS может быть включена в будущие версии.
  • Поддержка протоколом LDP групповой адресации не определена в текущей версии и может быть включена в будущие версии протокола.
  • Поддержка коммутации по меткам с множеством путей (multipath label switching) не определена в текущей версии протокола LDP и может быть включена в будущие версии.
  • Поддержка сигнализации максимального размера блока данных (MTU) не определена в текущей версии LDP и рассматривается в экспериментальном документе [LDP-MTU].
  • В текущей версии спецификации не решен вопрос обнаружения партнеров в средах с множественным доступом без широковещания (NBMA1). В рамках данной спецификации возможно обнаружение за счет использования расширенных процедур детектирования. Задача определения механизма обнаружения семантически похожа на процедуру Basic Discovery (ограничение в 1 интервал и привязка hello-смежности к интерфейсу), которая использует заданный в конфигурации адрес соседа, и требует дальнейшего изучения.
  • В текущей спецификации не поддерживается сброс отношений смежности. Мотивация такого сброса и определение подходящего механизма требуют дополнительного изучения.
  • В текущей версии спецификации отсутствует метод защиты сообщений Hello для детектирования обманных сообщений. Сценарии, в которых такая защита требуется, и механизм защиты требуют дополнительного изучения.
  • В текущей версии спецификации не поддерживается возможность детектирования быстрого рестарта управляющего плана с потерей состояния. Метод решения этой задачи (возможно за счет использования номера «инкарнации/экземпляра» в сообщении Hello) требует дальнейшего изучения.
  • В текущей версии спецификации не поддерживаются сообщения end of LIB (аналог end of RIB в BGP), которые LDP LSR (работающий в режиме DU) может использовать при следующей организации сессии. Обсуждение необходимости такого механизма и его реализации требует дальнейшего изучения.
  • В настоящей спецификации не рассматриваются ситуации, когда разные LSR анонсируют один и тот же адрес. Такие ситуации возникают обычно в результате конфигурационных ошибок и цель в данном случае заключается в том, чтобы обеспечить маршрутизаторы LSR, анонсирующие один адрес информацией, которой оператору будет достаточно для исправления ошибок в конфигурации. Спецификация такого механизма будет опубликована в форме отдельного документа.

7. Отличия от RFC 3036

Ниже приведен список изменений, внесенных в RFC 3036.

  1. Удален класс Host Address FEC и ссылки на него, поскольку в реализациях данный класс не используется.
  2. Список ритературы разделен на нормативные документы и дополнительные источники.
  3. Из списка нормативных документов удален «MPLS using ATM VP Switching», а также удалены ссылки на него.
  4. Удалена ссылка на RFC 1700 с заменой на http://www.iana.org/assignments/address-family-numbers.
  5. Удалена ссылка на RFC 1771 с заменой на RFC 4271.
  6. Прояснено использование флага F.
  7. Добавлена опция, позволяющая использовать «расщепление горизонта» (split horizon) при упорядоченном управлении (Ordered Control).
  8. Прояснена обработка сообщений с флагом U на этапе инициализации сессии.
  9. Прояснена обработка флага E в процессе инициализации сессии.
  10. Добавлен текст, разъясняющий, что сообщение Shutdown в диаграмме состояний реализовано, как уведомление с полем Status TLV, показывающим критическую ошибку.
  11. Добавлена ситуация, когда размер TLV слишком мал (при рассмотрении TLV с некорректным форматом).
  12. Разъяснены угрозы, связанные с обманными сообщениями Hello.
  13. Добавлены ссылки на RFC 4271 и RFC 4278, а также пояснительный текст в части использования опции MD5.
  14. Добавлен текст из RFC 3031, разъясняющий использование неявных NULL-меток.
  15. Включено представление DLCI для удаления нормативной ссылки на RFC 3034.
  16. Ссылки на RFC 3031, RFC 3032 и RFC 3034 перенесены в раздел дополнительной литературы.
  17. В параграфе, описывающем обработку неизвестных TLV, удалена ссылка на несуществующий раздел (ошибка в исходном документе).
  18. Добавлен текст, разъясняющий, как добиться интероперабельности при передаче фирменных TLV и сообщений.
  19. В процедурах обработки запросов меток для случая обнаружения петель изменена процедура передачи уведомления перед прерыванием остальной части обработки.
  20. В процедурах обработки освобождения меток разъяснено поведение поддерживающих слияние LSR.
  21. В процедурах обработки освобождения меток разъяснено поведение в случае получения неизвестного FEC.
  22. В примечании 4 (A.1.7. Детектирование смены FEC Next Hop) изменен текст для указания корректного набора условий передачи запроса на метку (опечатка в исходном документе).
  23. В процедурах приложения A.1.14. Принятие LSR решения о прекращении коммутации по меткам для FEC разъяснено, что метку не допускается использовать повторно до получения сообщения о ее освобождении.
  24. В описании процедуры Prepare_Label_Mapping_Attributes добавлено примечание, относящееся к трактовке неизвестных TLV в соответствии со значениями флагов U и F.
  25. В процедурах обработки сообщений Address разъяснено поведение для случаев, когда LSR получает повторный анонс для анонсированного ранее адреса или отзыв для адреса от LSR, который этот адрес не анонсировал ранее.
  26. В описании процедур обработки полученного отображения метки разъяснено значение PrevAdvLabel для случая, когда ранее не передавалось сообщения с анонсом этой метки.
  27. В описании процедур обработки полученного отображения метки для случая обнаружения петли изменен процесс отправки уведомления до прерывания оставшейся части обработки.
  28. В описании процедур обработки полученного отображения метки исправлен этап LMp.10 для обработки сообщений об отображении для дополнительных (несливаемых) LSP того же класса FEC.
  29. В описании процедуры обработки полученного отображения метки разъяснено поведение при получении дубликата метки для того же класса FEC.
  30. В описании процедур обработки запросов на прерывание (Label Abort Request) разъяснено поведение для не поддерживающих слияния LSR.
  31. Добавлен ряд пунктов в список вопросов, требующих дальнейшего изучения:
    • расширение для обмена информацией об MTU;
    • базовое детектирование партнеров в средах NBMA;
    • опция для прерывания отношений смежности;
    • механизмы защиты сообщений Hello;
    • детектирование быстрого рестарта управляющего плана с потерей состояния;
    • поддержка сообщений end of LIB;
    • механизмы для случая анонсирования одного адреса разными LSR.

8. Благодарности

Этот документ был создан в процессе подготовки спецификации протокола LDP в качестве проекта стандарта. Исходный документ был опубликован, как RFC 3036 в январе 2001. Он был подготовлен рабочей группой MPLS (IETF) и написан совместно Loa Andersson, Paul Doolan, Nancy Feldman, Andre Fredette и Bob Thomas.

Идеи и текст RFC 3036 были взяты из множества источников. Мы благодарим Rick Boivie, Ross Callon, Alex Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov Rekhter и Arun Viswanathan за их вклад в подготовку RFC 3036.

Редакторы выражают свою признательность Eric Gray, David Black и Sam Hartman за просмотр и и замечания к текущей версии документа.

В дополнение к этому редакторы выражают благодарность члена рабочей группы MPLS за их идеи и поддержку при подготовке документа, особенно отмечая Eric Rosen, Luca Martini, Markus Jork, Mark Duffy, Vach Kompella, Kishore Tiruveedhula, Rama Ramakrishnan, Nick Weeds, Adrian Farrel и Andy Malis.

9. Литература

9.1. Нормативные документы

[IANA] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 2434, October 1998.

[RFC1321] Rivest, R., “The MD5 Message-Digest Algorithm”, RFC 1321, April 1992.

[ASSIGNED_AF] http://www.iana.org/assignments/address-family-numbers

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[RFC2385] Heffernan, A., “Protection of BGP Sessions via the TCP MD5 Signature Option”, RFC 2385, August 1998.

[RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G., Rekhter, Y., and P. Doolan, “MPLS using LDP and ATM VC Switching”, RFC 3035, January 2001.

[RFC3037] Thomas, B. and E. Gray, “LDP Applicability”, RFC 3037, January 2001.

9.2. Дополнительная литература

[CRLDP] Jamoussi, B., Ed., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, “Constraint-Based LSP Setup using LDP”, RFC 3212, January 2002.

[LDP-MTU] Black, B. and K. Kompella, “Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol”, RFC 3988, January 2005.

[RFC2328] Moy, J., “OSPF Version 2”, STD 54, RFC 2328, April 1998.

[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O’Dell, M., and J. McManus, “Requirements for Traffic Engineering Over MPLS”, RFC 2702, September 1999.

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, “Multiprotocol Label Switching Architecture”, RFC 3031, January 2001.

[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, “MPLS Label Stack Encoding”, RFC 3032, January 2001.

[RFC3034] Conta, A., Doolan, P., and A. Malis, “Use of Label Switching on Frame Relay Networks Specification”, RFC 3034, January 2001.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., “A Border Gateway Protocol 4 (BGP-4)”, RFC 4271, January 2006.

[RFC4278] Bellovin, S. and A. Zinin, “Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification”, RFC 4278, January 2006.

Приложение A. Процедуры распространения меток LDP

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

  • прием сообщения Label Request;
  • прием сообщения Label Mapping;
  • прием сообщения Label Abort Request;
  • прием сообщения Label Release;
  • прием сообщения Label Withdraw;
  • идентификация нового класса FEC;
  • детектирование изменения следующего интервала для FEC;
  • прием сообщения Notification – Label Request Aborted;
  • прием сообщения Notification – No Label Resources;
  • прием сообщения Notification – No Route;
  • прием сообщения Notification – Loop Detected;
  • прием сообщения Notification – Label Resources Available;
  • детектирование доступности локальных ресурсов для меток;
  • принятие LSR решения о прекращении коммутации меток для FEC;
  • тайм-аут для отложенного запроса метки.

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

  1. Описание – обзор отклика LSR на событие.
  2. Контекст – список элементов, упомянутых в алгоритме (п. 3).
  3. Алгоритм – алгоритм действий для отклика LSR на событие.

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

При описании алгоритмов используются процедуры, определенные в спецификации архитектуры MPLS [RFC3031] для трафика с поэтапной маршрутизацией. К таким процедурам относятся:

  • Процедуры распространения меток (Label Distribution), которые выполняются нисходящим LSR для решения вопроса о распространении меток для FEC партнерам LDP. Архитектура определяет 4 процедуры Label Distribution:
    • нисходящее распространение меток без запроса с независимым управлением (Downstream Unsolicited Independent Control), называемое PushUnconditional в [RFC3031];
    • нисходящее распространение меток без запроса с упорядоченным управлением (Downstream Unsolicited Ordered Control), называемое PushConditional в [RFC3031];
    • нисходящее распространение меток по запросам с независимым управлением (Downstream On Demand Independent Control), называемое PulledUnconditional в [RFC3031];
    • нисходящее распространение меток по запросам с упорядоченным управлением (Downstream On Demand Ordered Control), называемое PulledConditional в [RFC3031].
  • Процедура отзыва меток (Label Withdrawal) которая выполняется нисходящим LSR для решения вопроса от отзыве отоборажения FEC-label, анонсированного ранее партнерам LDP. Архитектура определяет одну процедуру отзыва – Label Withdrawal. Всякий раз при разрыве связки метки с классом FEC маршрутизатор LSR должен отозвать соответствующее отображение для всех партнеров LDP, которым это отображение анонсировалось.
  • Процедуры запроса метки (Label Request), которые выполняются восходящим LSR для решения вопроса о явном запросе у нисходящего LSR привязки метки к FEC и передачи соответствующего отображения. Архитектура определяет три процедуры Label Request:
    • никогда не запрашивать (Request Never) – LSR никогда не запрашивает меток;
    • запрос при необходимости (Request When Needed) – LSR запрашивает метку при возникновении потребности в ней;
    • запрос по запросу (Request On Request) – эта процедура используется LSR, не поддерживающими слияния. LSR запрашивает метку при получении запроса на нее или при возникновении потребности в текой метке.
  • Процедуры освобождения метки (Label Release), которые выполняются восходящим LSR для решения вопроса об освобождении ранее полученного отображения метки на FEC. Архитектура определяет две процедуры Label Release:
    • консервативное удержание меток (Conservative Label retention), именуемое ReleaseOnChange в [RFC3031];
    • либеральное удержание меток (Liberal Label retention), именуемое NoReleaseOnChange в [RFC3031].
  • Процедуры использования меток (Label Use), которые выполняются LSR для решения вопроса о начале использования метки FEC для коммутации/пересылки. Архитектура определяет три процедуры Label Use:
    • использовать сразу (Use Immediate) – LSR незамедлительно начинает использование меток, полученных от следующего интервала для FEC при коммутации/пересылке пакетов;
    • использовать при отсутствии петель (Use If Loop Free) – LSR использует метку FEC, полученную от следующего интервала для этого FEC при коммутации/пересылке, если он определил, что при использовании такой метки не возникает петли;
    • использовать, если петель не обнаружено (Use If Loop Not Detected) – эта процедура совпадает с Use Immediate, пока LSR не детектирует петли в FEC LSP. Использование метки FEC для коммутации/пересылки будет осуществляться до тех пор, пока не сменится следующий интервал для FEC или не будет обнаружена петля.

    Данная версия LDP не включает механизма предотвращения петель, следовательно перечисленные ниже процедуры не используют процедуру Use If Loop Free.

  • Процедуры Label No Route (именуется NotAvailable в [RFC3031]), которые выполняются восходящим LSR для решения вопроса о реагировании на сообщения No Route от нисходящего LSR в ответ на запрос отображения FEC-метка. Спецификация архитектуры определяет две процедуры Label No Route:
    • повторный запрос (Request Retry) – LSR следует повторить запрос метки позднее;
    • без повторного запроса (No Request Retry) – LSR следует считать, что нисходящий маршрутизатор LSR будет обеспечивать отображение метки, когда ему известен следующий интервал пересылки, и повтрять запрос не следует.

A.1. Обработка событий при распространении меток

В этом разделе определены процедуры распространения меток LDP путем задания алгоритма обработки для каждого события при распространении меток. Требование к реализациям LDP заключается в том, что обработка событий должна давать эффект, указанный в алгоритме. Таким образом, реализации не обязаны в точности выполнять все шаги, укаазнные в алгоритме, если она обеспечивает тот же самый эффект.

Алгоритмы обработки событий при распространении меток используют общий набор действий. Приведенные ниже спецификации группируют эти действия в процедурные блоки. Спецификации для таких общих процедур даны в отдельном приложении A.2. Общие процедуры распространения меток.

Реализации будут использовать структуры данных для хранения информации о протокольных действиях. В этом приложении указана сохраняемая информация, которая нужна для описания алгоритма, и предполагается возможность нахождения такой информации при возникновении потребности в ней. Детали структур данных спецификация не задает.

A.1.1. Получение Label Request

Описание

Отклик LSR на получение запроса отображения FEC-label от партнера LDP может включать одно или несколько перечисленных ниже действий:

  • передача запрашивающему LSR уведомления, показывающего, почему отображение метки для FEC не может быть предоставлено;
  • передача отображения FEC-label запрашивающему LSR;
  • передача запроса для отображения FEC-label на следующий интервал FEC;
  • установка меток для использования LSR при коммутации/пересылке.

Контекст

  • LSR – маршрутизатор, обрабатывающий событие;
  • MsgSource – партнер LDP, передавший сообщение;
  • FEC – класс FEC, указанный в сообщении;
  • RAttributes – атрибуты, полученные в сообщении (например, Hop Count, Path Vector);
  • SAttributes – атрибуты, которые будут включаться в сообщение Label Request, передаваемое FEC Next Hop;
  • StoredHopCount – счетчик интервалов, ранее записанных для FEC (при наличии таковых).

Алгоритм

LRq.1 Выполнить процедуру Check_Received_Attributes (MsgSource, LabelRequest, RAttributes).

При обнаружении петли переход на LRq.4.

LRq.2 Это следующий интервал для FEC?

Если нет, перейти на LRq.5.

LRq.3 MsgSource совпадает с адресом следующего интервала (Next Hop)?

Если нет, перейти на LRq.6.

LRq.4 Выполнить процедуру Send_Notification (MsgSource, Loop Detected).

Перейти на LRq.13.

LRq.5 Выполнить процедуру Send_Notification (MsgSource, No Route).

Перейти на LRq.13.

LRq.6 LSR уже получал запрос метки для FEC от MsgSource?

Если нет, перейти на LRq.8 (см. примечание 1).

LRq.7 Запрос метки является дубликатом?

Если да, перейти на LRq.13 (см. примечание 2).

LRq.8 Записать запрос метки для FEC, полученный от MsgSource, и пометить его, как ожидающий.

LRq.9 Выполнить процедуру LSR Label Distribution:

Для режима Downstream Unsolicited Independent Control или Downstream On Demand Independent Control

      1. LSR ранее получил и удерживает отображение метки для FEC от Next Hop?Если да, установить Propagating = IsPropagating.Если нет, установить Propagating = NotPropagating.
      2. Выполнить процедуру Prepare_Label_Mapping_Attributes(MsgSource, FEC, RAttributes, SAttributes, Propagating, StoredHopCount).
      3. Выполнить процедуру Send_Label (MsgSource, FEC, SAttributes).
      4. Если нет, перейти на LRq.10.
      5. LSR является выходом для FEC? или LSR ранее получил и удерживает отображение метки для FEC от Next Hop?Если да, перейти на LRq.11.

Для режима Downstream Unsolicited Ordered Control или Downstream On Demand Ordered Control

      1. LSR является выходом для FEC? или LSR ранее получил и удерживает отображение метки для FEC от Next Hop? (см. примечание 3)Если нет, перейти на LRq.10.
      2. Выполнить процедуру Prepare_Label_Mapping_Attributes(MsgSource, FEC, RAttributes, SAttributes, IsPropagating, StoredHopCount)
      3. Выполнить процедуру Send_Label (MsgSource, FEC, SAttributes).Перейти на LRq.11.

LRq.10 Выполнить процедуру LSR Label Request:

для Request Never

      1. Перейти на LRq.13.

для Request When Needed или Request On Request

      1. Выполнить процедуру Prepare_Label_Request_Attributes (Next Hop, FEC, RAttributes, SAttributes);
      2. Выполнить процедуру Send_Label_Request (Next Hop, FEC, SAttributes).Перейти на LRq.13.

LRq.11 LSR успешно отправил метку для FEC по адресу MsgSource?

Если нет, перейти на LRq.13 (см. примечание 4).

LRq.12 Выполнить процедуру LSR Label Use.

Для Use Immediate или For Use If Loop Not Detected

      1. Установить метку, переданную MsgSource, и метку от Next Hop (если LSR не является выходным) для коммутации/пересылки.

LRq.13 Завершено.

Примечания

  1. Если MsgSource не является LSR со слиянием меток, этот маршрутизатор будет передавать запрос метки для каждого восходящего партнера LDP, который запросил у него метку для FEC. LSR должен быть способен отличать запросы от MsgSource, не поддерживающих слияния меток, от дубликатов запросов меток.LSR использует идентификатор сообщения Label Request для детектирования дубликатов запроса. Это означает, что LSR (восходящий партнер) не может повторно использовать значение идентификатора, указанного в сообщении Label Request, пока обработка запроса не будет завершена.
  2. Когда LSR передает партнеру запрос метки, он записывает информацию об этой передаче и помечает запрос, как ожидающий завершения. Пока запрос остается помеченным, как ожидающий, LSR не следует отправлять партнеру новый запрос на ту же метку. Повторный запрос будет дубликатом. Описанная ниже процедура Send_Label_Request следует этому правилу.Дубликат запроса рассматривается, как протокольная ошибка. Такие дубликаты принимающему LSR следует отбрасывать (возможно, с генерацией соответствующего уведомления для MsgSource).
  3. Если LSR не поддерживает слияния меток, эта проверка будет давать отрицательный результат.
  4. Процедура Send_Label может давать отрицательный результат по причине нехватки ресурсов. В таких случаях LSR не следует выполнять процедуру Label Use.

A.1.2. Получение Label Mapping

Описание

Отклик LSR га получение отображения FEC-label от партнера LDP может включать одно или несколько из перечисленных ниже действий:

  • передача сообщения Label Release для метки FEC партнеру LDP;
  • передача сообщений Label Mapping для FEC одному или множеству партнеров LDP;
  • установка вновь полученной метки для использования LSR при коммутации/пересылке.

Контекст

  • LSR – маршрутизатор, обрабатывающий событие;
  • MsgSource – партнер LDP, передавший сообщение;
  • FEC – класс FEC, указанный в сообщении;
  • Label – метка, указанная в сообщении;
  • PrevAdvLabel – метка для FEC (при наличии таковой), которая была анонсирована восходящему партнеру; в предположении, что метка ранее не анонсировалась, эта метка будет совпадать с меткой в обрабатываемом сообщении Label Mapping;
  • StoredHopCount – счетчик интервалов, ранее записанных для FEC (при наличии таковых);
  • RAttributes – атрибуты, полученные в сообщении (например, Hop Count, Path Vector);
  • SAttributes – атрибуты, которые будут включаться в сообщение Label Request, передаваемое FEC Next Hop.

Алгоритм

LMp.1 Получено отображение, соответствующее ожидающему запросу метки для FEC, который ранее был передан MsgSource?

Если нет, перейти на LMp.3.

LMp.2 Удалить запись ожидающего запроса метки для FEC.

LMp.3 Выполнить процедуру Check_Received_Attributes (MsgSource, LabelMapping, RAttributes).

Если не обнаружено петли (No Loop Detected), перейти на LMp.9.

LMp.4 Получал ли LSR отображение метки для FEC от MsgSource? (см. примечание 1)

Если нет, перейти на LMp.8 (см. примечание 2).

LMp.5 Соответствует ли полученная ранее от MsgSource метка значению Label (т. е., метке в полученном сообщении)? (см. примечание 3).

Если нет, перейти на LMp.8 (см. примечание 4).

LMp.6 Удалить соответствующее отображение метки для FEC, полученное ранее от MsgSource.

LMp.7 Прекратить использование метки Label для коммутации/пересылки (см. примечание 5).

LMp.8 Выполнить процедуру Send_Message (MsgSource, Label Release, FEC, Label, Loop Detected Status code). Перейти на LMp.33.

LMp.9 Получал ли LSR отображение метки на FEC от MsgSource для интересующего LSP? (см. примечание 6).

Если нет, перейти на LMp.11.

LMp.10 Соответствует ли полученная ранее от MsgSource метка значению Label (т. е., метке в полученном сообщении)? (см. примечание 3).

или

Получено ли отображение метки в ответ на ожидающий обработки запрос, переданный MsgSource? (см. примечание 12).

Если да, перейти на LMp.11.

LMp.10a LSR работает в режиме Downstream Unsolicited? Если да, удалить отображение для метки, полученное ранее от MsgSource и прекратить использование этой метки для коммутации/пересылки. Выполнить процедуру Send_Message (MsgSource, Label Release, FEC, ранее полученная от MsgSource метка).

LMp.11 Определить Next Hop для FEC.

LMp.12 Является MsgSource следующим интервалом (Next Hop) для FEC?

Если да, перейти на LMp.14.

LMp.13 Выполнить процедуру LSR Label Release:

для консервативного удержания (Conservative Label):

      1. перейти на Lmp.32;

для либерального удержания (Liberal Label):

      1. записать отображение метки для FEC со значениями Label и RAttributes, полученными от MsgSource; перейти на LMp.33.

LMp.14 Является LSR входом для FEC?

Если нет, перейти на LMp.16.

LMp.15 Организовать использование Label для коммутации/пересылки.

LMp.16 Записать отображение метки для FEC со значениями Label и RAttributes, полученными от MsgSource.

LMp.17 Выполнить операции до LMp.31 для каждого партнера (см. примечание 7).

LMp.18 LSR ранее передавал отображение метки на FEC партнеру Peer для рассматриваемого LSP? (см. примечание 8).

Если да, перейти на LMp.22.

LMp.19 LSR использует процедуру распространения меток Downstream Unsolicited Ordered Control?

Если нет, перейти на LMp.28.

LMp.20 Выполнить процедуру Prepare_Label_Mapping_Attributes (Peer, FEC, RAttributes, SAttributes, IsPropagating, StoredHopCount).

LMp.21 Выполнить процедуру Send_Message (Peer, Label Mapping, FEC, PrevAdvLabel, SAttributes) (см. примечание 13).

Перейти на LMp.28.

LMp.22 Выполнить операции до LMp.27 для каждого отображения метки на FEC, переданного ранее партнеру Peer.

LMp.23 Значение RAttributes в полученном отображении согласуется с переданным ранее партнеру Peer? Если да, продолжить итерацию с LMp.22 для следующего отображения (см. примечание 9).

LMp.24 Выполнить процедуру Prepare_Label_Mapping_Attributes (Peer, FEC, RAttributes, SAttributes, IsPropagating, StoredHopCount).

LMp.25 Выполнить процедуру Send_Message (Peer, Label Mapping, FEC, PrevAdvLabel, SAttributes) (см. примечание 10).

LMp.26 Обновить запись отображения метки на FEC, переданного ранее партнеру Peer для включения новых атрибутов.

LMp.27 Завершение итерации, начинающейся с LMp.22.

LMp.28 У LSR есть запросы метки для FEC от партнера Peer, помеченные, как ожидающие?

Если нет, перейти на LMp.30.

LMp.29 Выполнить процедуру Label Distribution:

для режима Downstream Unsolicited Independent Control или For Downstream Unsolicited Ordered Control:

      1. выполнить процедуру Prepare_Label_Mapping_Attributes (Peer, FEC, RAttributes, SAttributes, IsPropagating, UnknownHopCount);
      2. выполнить процедуру Send_Label (Peer, FEC, Sattributes); в случае отказа продолжить итерацию для следующего партнера с LMp.17;
      3. если для партнера Peer нет ожидающих запросов, перейти на LMp.30 (см. примечание 11);

для режима Downstream On Demand Independent Control или For Downstream On Demand Ordered Control:

      1. выполнить итерацию до п. 5 для каждого запроса метки для FEC от партнера Peer, помеченного, как ожидающий;
      2. выполнить процедуру Prepare_Label_Mapping_Attributes (Peer, FEC, RAttributes, SAttributes, IsPropagating, UnknownHopCount);
      3. выполнить процедуру Send_Label (Peer, FEC, Sattributes); в случае отказа продолжить итерацию для следующего партнера с LMp.17;
      4. удалить запись ожидающего запроса;
      5. завершение итерации, начинающейся с п. 1;
      6. перейти на LMp.30.

LMp.30 Выполнить процедуру Label Use:

для режима Use Immediate или Use If Loop Not Detected:

      1. операции до п. 3 для каждого отображения метки на FEC, переданного ранее партнеру Peer;
      2. организовать использование полученной и переданно партнеру метки для коммутации/пересылки;
      3. завершение итерации, начинающейся с п 1;
      4. перейти на LMp.31.

LMp.31 Завершение итерации, начинающейся с LMp.17.

Перейти на LMp.33.

LMp.32 Выполнить процедуру Send_Message (MsgSource, Label Release, FEC, Label).

LMp.33 Завершено.

Примечания

  1. LSR, поддерживающим слияние, следует иметь не более одного полученного отображения метки на FEC для рассматриваемого LSP. Если слияние меток не поддерживается, число полученных отображений меток FEC может быть более 1 для LSP.
  2. Если LSR обнаруживает петлю и ранее не получал отображения меток для FEC от MsgSource, он просто освобождает метку.
  3. Соответствует ли поле Label в полученном сообщении любому отображению меток, идентифицированному на предыдущем этапе (LMp.4 или LMp.9)?
  4. Незапрошенное отображение с разными метками от одного партнера будет попыткой организовать коммутацию по множеству путей (multipath label switching), которая не поддерживается в данной версии LDP.
  5. Если метка Label не используется для коммутации/пересылки, LMp.7 не дает никакого эффекта.
  6. Если полученное сообщение с отображением метки соответствует ожидающему запросу метки в LMp.1, значит (по определению) LSR ранее не получал отображения метки на FEC для рассматриваемого LSP. Если LSR является склеивающим восходящие метки для рассматриваемого LSP, ему следует иметь не более 1 полученного отображения. Если слияние меток не поддерживается, число полученных отображений на один класс FEC может быть больше 1 – по одному для каждого получающегося LSP.
  7. Итерация LMp.17 включает MsgSource для обработки в случаях, когда LSR работает в режиме Downstream Unsolicited Ordered Control. Упорядоченное управления не позволяет LSR анонсировать метку для FEC, пока он не получит отображение метки от своего следующего интервала (MsgSource) для FEC.
  8. Если LSR поддерживает слияние LSP, он может иметь отображения меток для FEC LSP, переданные ранее одному или множеству партнеров. Если LSR не поддерживает слияния, у него может быть отображение метки для рассматриваемого LSP, переданное не более, чем одному LSR.
  9. При этой проверке рассматривается атрибуто Loop Detection Path Vector. Если полученное значение RAttributes включает Path Vector и ранее значение Path Vector не передавалось партнеру Peer или полученное значение Path Vector не соответствует значению Path Vector, ренее переданному партнеру, атрибуты считаются не соответствующими друг другу. Отметим, что LSR не обязан сохранять полученное значение Path Vector после его распространения в сообщении с отображением. Если LSR не сохраняет Path Vector, у него не будет возможности проверить соответствие вновь полученному значению Path Vector. Это означает, что LSR при получении отображения с Path Vector всякий раз должен распространять значение Path Vector.
  10. В LMp.22 – LMp.27 обрабатываются ситуации, которые могут возникать, когда LSR, использующий независимое управление, получает отображение от нисходящего партнера после того, как было передано отображение восходящему партнеру. В таких случаях от LSR требуется распространять в восходящем направлении все изменившиеся атрибуты (такие, как Hop Count). Если включено детектирование петель, в число распространяемых атрибутов необходимо включать Path Vector.
  11. LSR, работающий в режиме Downstream Unsolicited, должен обрабатывать все получаемые сообщения Label Request. При наличии ожидающих обработки запросов меток для выполнения этих запросов следует переходить к процедурам Downstream on Demand.
  12. Как определено в LMp.1.
  13. LSR, работающий в режиме Ordered Control, может на этом этапе партнера, от которого он получил анонс, потребовавший генерации сообщения label-map. Это будет давать эффект «расщепления горизонта».

A.1.3. Получение Label Abort Request

Описание

Когда LSR получает сообщение Label Abort Request от своего партнера, он проверяет, отвечал ли ранее на запрос указанной метки. Если такой отклик был передан, сообщение игнорируется. Если отклик не передавался, партнеру отправляется уведомление Label Request Aborted. В дополнение к этому при наличии ожидающего обработки запроса метки у нисходящего партнера для рассматриваемого LSP, тому передается сообщение Label Abort Request для прерывания LSP.

Контекст

  • LSR – маршрутизатор, обрабатывающий событие;
  • MsgSource – партнер LDP, передавший сообщение;
  • FEC – класс FEC, указанный в сообщении;
  • RequestMessageID – идентификатор сообщения с запросом метки, обработка которого будет прервана;
  • Next Hop – следующий интервал для FEC.

Алгоритм

LAbR.1 Сообщение соответствует ранее полученному от MsgSource сообщению Label Request? (см. примечание 1).

Если нет, переход на LAbR.12.

LAbR.2 LSR ответил на полученный ранее запрос метки?

Если да, переход на LAbR.12.

LAbR.3 Выполнить процедуру Send_Message (MsgSource, Notification, Label Request Aborted, TLV), где поле TLV содержит Label Request Message ID TLV, полученное в сообщении Label Abort Request.

LAbR.4 LSR имеет ожидающее обработки сообщение Label Request для FEC?

Если да, переход на LAbR.7.

LAbR.5 LSR имеет отображение метки для FEC?

Если нет, переход на LAbR.11.

LAbR.6 Генерация события: сообщение Received Label Release для FEC от MsgSource (см. примечание 2).

Перейти на LAbR.11.

LAbR.7 LSR поддерживает слияние LSP для FEC?

Если нет, переход на LAbR.9.

LAbR.8 Есть ожидающие обработки запросы метки для этого FEC?

Если да, переход на LAbR.11.

LAbR.9 Выполнить процедуру Send_Message (Next Hop, Label Abort Request, FEC, TLV), где поле TLV содержит Label Request Message ID TLV, содержащее значение Message ID, использованное LSR в ожидающем завершения обработки сообщении Label Request.

LAbR.10 Запись информации о том, что запрос на прерывание метки FEC находится в состоянии ожидания.

LAbR.11 Удаление записи о запросе метки для FEC от MsgSource.

LAbR.12 Завершено.

Примечания

  1. LSR использует FEC и Label Request Message ID TLV из запроса на прерывание метки для поиска своей записи (при ее наличии) о полученном ранее запросе метки от MsgSource.
  2. Если LSR получил отображение метки от NextHop, ему следует вести себя, как будто он анонсировал отображение метки MsgSource, а тот освободил эту метку.

A.1.4. Получение Label Release

Описание

Когда LSR получает сообщение Label Release для FEC от своего партнера, он проверяет, удерживают ли освобождаемую метку другие партнеры. Если таких партнеров нет, LSR прекращает использование метки для коммутации/пересылки и, если LSR удерживает отображение метки от следующего интервала FEC, это отображение освобождается.

Контекст

  • LSR – маршрутизатор, обрабатывающий событие;
  • MsgSource – партнер LDP, передавший сообщение;
  • FEC – класс FEC, указанный в сообщении;
  • Next Hop – следующий интервал для FEC.

Алгоритм

LRl.1 FEC соответствует известному классу FEC?

Если нет, перейти на LRl.14.

LRl.2 Удалить MsgSource из записи партнеров, удерживающих метку Label для FEC (см. примечание 1).

LRl.3 Сообщение соответствует ожидающему обработки отзыву метки для FEC, переданному ранее MsgSource?

Если нет, перейти на LRl.5.

LRl.4 Удалить запись ожидающего отзыва метки для FEC, ранее переданного MsgSource.

LRl.5 LSR использует слияние меток для этого FEC?

Если нет, перейти на LRl.7 (см. примечание 2).

LRl.6 LSR имеет ожидающие завершения обработки анонсы меток для этого FEC?

Если да, перейти на LRl.11.

LRl.7 LSR является выходом для FEC?

Если да, перейти на LRl.11.

LRl.8 Существует Next Hop для FEC? и LSR имеет ранее полученное от Next Hop отображение метки для FEC?

Если нет, перейти на LRl.11.

LRl.9 LSR настроен на распространение освобождения меток?

Если нет, перейти на LRl.11 (см. примечание 3).

LRl.10 Выполнить процедуру Send_Message (Next Hop, Label Release, FEC, Label from Next Hop).

LRl.11 Прекратить использование Label при коммутации/пересылке трафика от MsgSource.

LRl.12 Продолжает ли кто-либо из партнеров удерживать метку Label для FEC?

Если да, перейти на LRl.14.

LRl.13 Освободить метку Label.

LRl.14 Завершено.

Примечания

  1. Если LSR использует режим распространения меток Downstream Unsolicited, ему не следует повторно анонсировать MsgSource отображение метки FEC, пока MsgSource не запросит этого.
  2. В LRl.5 – LRl.9 определяется, следует ли LSR распространять Label Release своему нисходящему партнеру (LRl.9).
  3. Если достигнут LRl.9, это означает, что ни один из восходящих LSR не удерживает метку для FEC, а сам LSR удерживает метку для FEC от FEC Next Hop. Маршрутизатор LSR может распространять Label Release на Next Hop. За счет распространения Label Release маршрутизатор LSR освобождает потенциально дефицитный ресурс меток. При этом он также увеличивает задержку повторной организации LSP, когда MsgSource или другой восходящий LSR передаст новое сообщение Label Request для FEC.Решение вопроса о распространении отзывов меток не задается протоколом. Распространение меток будет корректно работать в любом случае. При решении вопроса о распространении отзыва следует принимать во внимание такие факторы, как дефицит ресурсов меток, важность сохранения малой задержки при организации LSP, управление организацией LSP в рабочей среде (по входу или по выходу).

A.1.5. Получение Label Withdraw

Описание

Когда LSR получает сообщение Label Withdraw для FEC от партнера LDP, он отвечает сообщением Label Release и прекращает использование метки для коммутации/пересылки. В режиме упорядоченного управления (Ordered Control) LSR передает сообщение Label Withdraw каждому партнеру LDP, которому он ранее передавал отображение метки для FEC. Если LSR использует режим анонсирования меток Downstream on Demand с независимым управлением, он действует, как в случае распознания FEC.

Контекст

  • LSR – маршрутизатор, обрабатывающий событие;
  • MsgSource – партнер LDP, передавший сообщение;
  • FEC – класс FEC, указанный в сообщении;
  • Next Hop – следующий интервал для FEC.

Алгоритм

LWd.1 Прекратить использование метки для коммутации/пересылки (см. примечание 1).

LWd.2 Выполнить процедуру Send_Message (MsgSource, Label Release, FEC, Label).

LWd.3 У LSR имеется ранее полученное и удерживаемое отображение метки для FEC от MsgSource?

Если нет, перейти на LWd.13.

LWd.4 Удалить соответствующее отображение метки на FEC, полученное ранее от MsgSource.

LWd.5 LSR использует Ordered Control?

Если да, перейти на LWd.8.

LWd.6 MsgSource использует режим анонсирования меток Downstream On Demand?

Если нет, перейти на LWd.13.

LWd.7 Сгенерировать событие: Распознание нового FEC. Перейти на LWd.13 (см. примечание 2).

LWd.8 Выполнить итерацию до LWd.12 для каждого партнера, отличного от MsgSource.

LWd.9 LSR ранее передавал отображение метки на FEC партнеру Peer?

Если нет, продолжить с LWd.8 для следующего партнера.

LWd.10 Метка, переданная ранее партнеру Peer, «отображает» отзываемую метку?

Если нет, продолжить с LWd.8 для следующего партнера (см. примечание 3).

LWd.11 Выполнить процедуру Send_Label_Withdraw (Peer, FEC, ранее переданная партнеру Peer метка Label).

LWd.12 Завершение итерации, начинающейся с LWd.8.

LWd.13 Завершено.

Примечания

  1. Если метка Label не используется для коммутации/пересылки, LWd.1 не дает никакого эффекта.
  2. LWd.7 используется в случаях, когда LSR работает в режиме распространения меток Downstream On Demand с независимым управлением. В такой ситуации LSR следует передавать запрос метки следующему интервалу для FEC, как для случая распознания FEC.
  3. LWd.10 обрабатывает ситуации как при поддержке слияния меток (одна или множество входящих меток отображаются в одну исходящую), так и без таковой (одна метка отображается в одну исходящую метку).

A.1.6. Распознание нового FEC

Описание

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

  • передача отображения метки для FEC одному или множеству партнеров LDP;
  • передача запроса метки для FEC следующему интервалу FEC;
  • любое из действий, выполняемых при получении LSR отображения метки на FEC от следующего интервала FEC.

Контекст

  • LSR – маршрутизатор, обрабатывающий событие;
  • Label – метка, указанная в сообщении;
  • FEC – класс FEC, указанный в сообщении;
  • InitAttributes – атрибуты, связанные с новым классом FEC (см. примечание 1);
  • SAttributes – атрибуты, включаемые в сообщения Label Mapping или Label Request, если они передаются партнерам;
  • StoredHopCount – счетчик интервалов, ранее записанных для FEC (при наличии таковых).

Алгоритм

FEC.1 Выполнить процедуру Label Distribution:

Для режима Downstream Unsolicited Independent Control:

  1. Выполнить итерации до п. 5 для каждого партнера;
  2. LSR ранее получил и удерживает отображение метки на FEC от Next Hop?Если да, установить Propagating = IsPropagating;Если нет, установить Propagating = NotPropagating;
  3. Выполнить процедуру Prepare_Label_Mapping_Attributes (Peer, FEC, InitAttributes, SAttributes, Propagating, Unknown hop count(0));
  4. Выполнить процедуру Send_Label (Peer, FEC, Sattributes);
  5. Завершение итерации с п. 1;Переход на FEC.2.

Для режима Downstream Unsolicited Ordered Control:

  1. Выполнить итерации до п. 5 для каждого партнера;
  2. Является LSR выходом для FEC? или LSR ранее получил и удерживает отображение метки на FEC от Next Hop?Если нет, продолжить итераци для следующего партнера;
  3. Выполнить процедуру Prepare_Label_Mapping_Attributes (Peer, FEC, InitAttributes, SAttributes, Propagating, StoredHopCount).
  4. Выполнить процедуру Send_Label (Peer, FEC, SAttributes).
  5. Завершение итерации с п. 1;Переход на FEC.2.

Для режима Downstream On Demand Independent Control или For Downstream On Demand Ordered Control:

  1. Переход на FEC.2 (см. примечание 2).

FEC.2 LSR ранее получил и удерживает отображение метки на FEC от Next Hop?

Если да, перейти на FEC.5.

FEC.3 Next Hop является партнером LDP?

Если нет, перейти на FEC.6.

FEC.4 Выполнить процедуру запроса метки Label Request:

для Request Never:

  1. Переход на FEC.6;

для Request When Needed или For Request On Request:

  1. Выполнить процедуру Prepare_Label_Request_Attributes (Next Hop, FEC, InitAttributes, SAttributes);
  2. Выполнить процедуру Send_Label_Request (Next Hop, FEC, Sattributes);Переход на FEC.6.

FEC.5 Сгенерировать событие: Получено отображение метки от Next Hop (см. примечание 3).

FEC.6 Завершено.

Примечания

  1. Примером атрибута, который может быть частью InitAttributes, является параметр, задающий желаемый характеристики LSP – например, класс обслуживания CoS3. (отметим, что текущая версия протокола LDP не задает атрибута CoS, на расширения LDP могут делать это).Способы задания InitAttributes для FEC (если эти атрибуты используются) выходят за пределы спецификации LDP. Отметим, что InitAttributes не будет включать известные атрибуты Hop Count или Path Vector.
  2. LSR, использующий режим распространения меток Downstream On Demand, будет передавать метку только в том случае, если у него имеется ранее полученный запрос метки, помеченный, как ожидающий. У LSR в этом режиме не будет ожидающих запросов, поскольку он отвечает на все запросы меток для неизвестных FEC передачей запрашивающему LSR уведомления No Route и отбрасывает запрос (см. LRq.3).
  3. Если у LSR имеется метка для FEC от Next Hop, ему следует вести себя, как при получении метки от Next Hop. Такая ситуация возникает для режима либерального удержания меток.

A.1.7. Детектирование смены FEC Next Hop

Описание

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

  • прекращение использования метки старого FEC для коммутации/пересылки;
  • передача сообщений Label Mapping для FEC одному или множеству партнеров LDP;
  • передача запроса метки новому FEC next hop;
  • любые действия, которые могут выполняться при получении LSR отображения метки от нового FEC next hop.

Контекст

  • LSR – маршрутизатор, обрабатывающий событие;
  • FEC – класс FEC, указанный в сообщении;
  • New Next Hop – новый следующий интервал для FEC;
  • Old Next Hop – прежний следующий интервал для FEC;
  • OldLabel – метка, полученная ранее от Old Next Hop (при наличии таковой);
  • CurAttributes – атрибуты, связанные с FEC (если таковые имеются);
  • Sattributes – атрибуты для включения в сообщение Label Request, передаваемое New Next Hop (при наличии таких атрибутов).

Алгоритм

NH.1 LSR ранее получил и удерживает отображение метки для FEC от Old Next Hop?

Если нет, перейти на NH.6.

NH.2 Прекратить использование метки для коммутации/пересылки (см. примечание 1).

NH.3 LSR использует либеральное удержание меток (Liberal Label retention)?

Если да, перейти на NH.6.

NH.4 Выполнить процедуру Send_Message (Old Next Hop, Label Release, OldLabel).

NH.5 Удалить отображение метки для FEC, полученное ранее от Old Next Hop.

NH.6 LSR имеет ожидающий завершения обработки запрос метки от Old Next Hop?

Если нет, перейти на NH.10.

NH.7 LSR использует консервативное удержание меток (Conservative Label retention)?

Если нет, перейти на NH.10.

NH.8 Выполнить процедуру Send_Message (Old Next Hop, Label Abort Request, FEC, TLV), где TLV содержит значение Label Request Message ID TLV с идентификатором ожидающего запроса метки.

NH.9 Записать информацию об ожидании прерывания запроса метки для FEC от Old Next Hop.

NH.10 Имеется New Next Hop для FEC?

Если нет, перейти на NH.16.

NH.11 LSR ранее получил и удерживает отображение метки для FEC от New Next Hop?

Если нет, перейти на NH.13.

NH.12 Сгенерировать событие: Получение Label Mapping от New Next Hop.

Перейти на NH.20 (см. примечание 2).

NH.13 LSR использует режим анонсирования Downstream on Demand advertisement? или Next Hop использует режим анонсирования Downstream on Demand advertisement? или LSR использует режим Conservative Label retention? (см. примечание 3).

Если да, перейти на NH.14.

Если нет, перейти на NH.20.

NH.14 Выполнить процедуру Prepare_Label_Request_Attributes (Next Hop, FEC, CurAttributes, SAttributes).

NH.15 Выполнить процедуру Send_Label_Request (New Next Hop, FEC, SAttributes). (See Note 4.)

Перейти на NH.20.

NH.16 Итерация до NH.19 для каждого партнера Peer.

NH.17 LSR ранее передавал отображение метки на FEC партнеру Peer?

Если нет, продолжить итерацию с NH.16 для следующего партнера.

NH.18 Выполнить процедуру Send_Label_Withdraw (Peer, FEC, переданная ранее партнеру метка Label).

NH.19 Завершение итерации с NH.16.

NH.20 Завершено.

Примечания

  1. Если метка Label не используется для коммутации/пересылки, NH.2 не дает эффекта.
  2. Если у LSR имеется метка для FEC от New Next Hop, ему следует вести себя, как при получении метки от New Next Hop.
  3. Цель проверки режима удержания меток заключается в том, чтобы избежать «гонки» на этапах LMp.12-LMp.13 при обработке сообщения Label Mapping, когда LSR, работающий в режиме консервативного удержания меток, может освободить отображение метки, полученнок от New Next Hop до того, как обнаружит изменение следующего интервала для FEC.
  4. Независимо от процедуры Label Request, используемой LSR, маршрутизатор должен отправить запрос метки при выполнении условия NH.13. Следовательно, он будет напрямую выполнять процедуру Send_Label_Request вместо LSR Label Request.

A.1.8. Получение сообщения Notification/Label Request Aborted

Описание

Когда LSR получает уведомление Label Request Aborted от партнера LDP, он записывает, что соответствующая транзакция (если она есть) была завершена.

Контекст

  • LSR – маршрутизатор, обрабатывающий событие;
  • FEC – класс FEC, указанный в сообщении;
  • RequestMessageID – идентификатор сообщения из запроса метки, обработка которого прерывается.
  • MsgSource – партнер LDP, передавший сообщение Notification.

Алгоритм

LRqA.1 Уведомление соответсвует запросу на прерывание метки для FEC? (см. приложение 1).

Если нет, перейти на LRqA.3.

LRqA.2 Записать факт прерывания запроса метки для FEC.

LRqA.3 Завершено.

Примечание

  1. LSR использует FEC и RequestMessageID для поиска записи о запросе на прерывание метки (если таковой существует).

A.1.9. Получение сообщения Notification/No Label Resources

Описание

Когда LSR получает уведомление No Label Resources от партнера LDP, он прекращает отправку сообщений с запросом меток до тех пор, пока не получит от этого партнера уведомление Label Resources Available.

Контекст

  • LSR – маршрутизатор, обрабатывающий событие;
  • FEC – класс FEC, указанный в сообщении;
  • MsgSource – партнер LDP, передавший сообщение Notification.

Алгоритм

NoRes.1 Удалить запись об остающемся запросе метки для FEC, переданном MsgSource.

NoRes.2 Сделать запись о том, что отображение метки для FEC от MsgSource требуется, но ресурсов для выделения меток не хватает.

NoRes.3 Установить запись состояния, показывающую, что не следует передавать запросы меток MsgSource.

NoRes.4 Завершено.

A.1.10. Получение сообщения Notification/No Route

Описание

Когда LSR получает уведомление No Route от своего партнера LDP в ответ на сообщение Label Request, его отклик диктуется процедурой Label No Route. Маршрутизатор LSR не будет предпринимать дальнейших действий или отложит запрос метки, запустив таймер, по истечение которого передаст новое сообщение Label Request.

Контекст

  • LSR – маршрутизатор, обрабатывающий событие;
  • FEC – класс FEC, указанный в сообщении;
  • Attributes – атрибуты, связанные с запросом метки;
  • MsgSource – партнер LDP, передавший сообщение Notification.

Алгоритм

NoNH.1 Удалить запись остающегося запроса метки FEC, переданног MsgSource.

NoNH.2 Выполнить процедуру LSR Label No Route.

для Request No Retry:

  1. Переход на NoNH.3.

для Request Retry:

  1. Записать отложенный запрос метки для FEC и атрибуты для передачи MsgSource.
  2. Запустить таймер.Переход на NoNH.3.

NoNH.3 Завершено.

A.1.11. Получение сообщения Notification/Loop Detected

Описание

Когда LSR получает код состояния Loop Detected от партера LDP в ответ на сообщение Label Request или Label Mapping, он ведет себя, как при получении уведомления No Route.

Контекст

См. A.1.10. Получение сообщения Notification/No Route.

Алгоритм

См. A.1.10. Получение сообщения Notification/No Route.

Примечание

  1. Когда уведомление Loop Detected приходит в ответ на сообщение Label Request, оно содержится в поле Status Code TLV сообщения Notification. В случае отклика на сообщение Label Mapping код состояния приходит в Status Code TLV сообщения Label Release.

A.1.12. Получение сообщения Notification/Label Resources Available

Описание

Когда LSR получает уведомление Label Resources Available от партнера LDP, он возобновляет запросы меток у партнера.

Контекст

  • LSR – маршрутизатор, обрабатывающий событие;
  • MsgSource – партнер LDP, передавший сообщение Notification;
  • SAttributes – атрибуты, сохраненные с отложенным сообщением Label Request.

Алгоритм

Res.1 Установить запись состояния, показывающую возможность запроса меток у MsgSource.

Res.2 Итерация до Res.6 для каждой записи отображения метки на FEC, требуемого от MsgSource, для которой не хватало ресурсов.

Res.3 MsgSource является следующим интервалом для FEC?

Если нет, переход на Res.5.

Res.4 Выполнить процедуру Send_Label_Request (MsgSource, FEC, Sattributes); при отказе итерация прерывается.

Res.5 Удалить запись о недоступности ресурсов для отображения метки на FEC, требуемого от MsgSource.

Res.6 Завершение итерации, начинающейся с Res.2.

Res.7 Завершено.

A.1.13. Обнаружение доступности локальных ресурсов для меток

Описание

После передачи маршрутизатором LSR уведомления No Label Resources партнеру LDP и последующего возобновления доступности ресурсов LSR передает партнеру уведомление Label Resources Available.

Контекст

  • LSR – маршрутизатор, обрабатывающий событие;
  • Attributes – атрибуты, связанные с запросом метки.

Алгоритм

ResA.1 Итерация до ResA.4 для каждого партнера, которому LSR ранее передал уведомление No Label Resources.

ResA.2 Выполнить процедуру Send_Notification (Peer, Label Resources Available).

ResA.3 Удалить запись о передаче партнеру уведомления No Label Resources.

ResA.4 Завершение итерации, начинающейся с ResA.1.

ResA.5 Итерация до ResA.8 для каждой записи об отображении метки на FEC от партнера Peer, которая нужна, но недоступна по причине нехватки ресурсов (см. примечание 1).

ResA.6 Выполнить процедуру Send_Label (Peer, FEC, Attributes); при отказе итерация прерывается.

ResA.7 Очистить запись о требуемом, но недоступном отображении метки на FEC.

ResA.8 Завершение итерации, начинающейся с ResA.5

ResA.9 Завершено.

Примечание

  1. Итерация ResA.5 – ResA.8 служит для обработки ситуаций, когда LSR использует режим анонсирования Downstream Unsolicited и ранее не имел возможности выделить метку для FEC.

A.1.14. Принятие LSR решения о прекращении коммутации по меткам для FEC

Описание

LSR может в одностороннем порядке принять решение от отказе от коммутации по меткам для FEC данного партнера LDP. Для LSR недопустима передача партнеру сообщения Label Withdraw для FEC.

Контекст

  • Peer – партнер;
  • FEC – класс FEC;
  • PrevAdvLabel – метка для FEC, анонсированная ранее партнеру Peer.

Алгоритм

NoLS.1 Выполнить процедуру Send_Label_Withdraw (Peer, FEC, PrevAdvLabel) (см. примечание 1).

NoLS.2 Завершено.

Примечание

  1. LSR может прекратить использование метки для коммутации/пересылки в рамках этого события или при обработке сообщения Label Release от партнера в ответ на отзыв метки. Если LSR не ждет сообщения Label Release от партнера, ему не следует повторно использовать метку, пока не будет получено сообщение Label Release.

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

Описание

Запросы меток откладываются в ответ на уведомления No Route и Loop Detected. Когда завершается отсчет таймера для отложенного запроса метки, LSR запрашивает метку повторно.

Контекст

  • LSR – маршрутизатор LSR, обрабатывающий событие;
  • FEC – класс FEC, с которым связан тайм-аут;
  • Peer – партнер LDP, с которым связан тайм-аут;
  • Attributes – атрибуты, сохраненные с отложенным сообщением Label Request.

Алгоритм

TO.1 Найти запись для отложенного запроса метки.

TO.2 Peer является следующим интервалом для FEC?

Если нет, переход на TO.4.

TO.3 Выполнить процедуру Send_Label_Request (Peer, FEC).

TO.4 Завершено.

A.2. Общие процедуры распространения меток

В этом приложении описаны базовые процедуры, используемые алгоритмами обработки событий при распространении меток.

A.2.1. Send_Label

Описание

Процедура Send_Label обеспечивает выделение метки FEC для партнера LDP, если это возможно, и передает этому партнеру отображение метки на FEC. Если LSR не может выделить метку и имеет от партнера ожидающий запрос метки, он передает партнеру LDP уведомление No Label Resources.

Параметры

  • Peer – партнер LDP, для которого передается отображение метки;
  • FEC – класс FEC, для которого передается отображение метки;
  • Attributes – атрибуты для включения в отображение метки.

Дополнительный контекст

  • LSR – маршрутизатор LSR, выполняющий процедуру;
  • Label – метка, выделяемая и передаваемая партнеру.

Алгоритм

SL.1 LSR выделил метку?

Если нет, переход на SL.9.

SL.2 Выделить метку Label и связать ее с классом FEC.

SL.3 Установить использование метки Label для коммутации/пересылки.

SL.4 Выполнить процедуру Send_Message (Peer, Label Mapping, FEC, Label, Attributes).

SL.5 Записать отображение метки на FEC со значениями Label и Attributes, переданными партнеру Peer.

SL.6 LSR имеет запись о запросе метки для FEC от партнера Peer, помеченном, как ожидающий?

Если нет, переход на SL.8.

SL.7 Удалить запись об ожидающем запросе метки для FEC от партнера Peer.

SL.8 Вернуть код успешного завершения.

SL.9 LSR имеет запрос метки для FEC от партнера Peer, помеченный, как ожидающий?

Если нет, переход на SL.13.

SL.10 Выполнить процедуру Send_Notification (Peer, No Label Resources).

SL.11 Удалить запись об ожидающем запросе метки для FEC от партнера Peer.

SL.12 Записать факт передачи уведомления No Label Resources партнеру Peer.

Перейти на SL.14.

SL.13 Записать отображение метки, требуемое для FEC, и значение Attributes для партнера Peer, запрос которого не был выполнен по причине нехватки ресурса меток (см. примечание 1).

SL.14 Вернуть код отказа.

Примечание

  1. SL.13 обслуживает ситуации для режима анонсирования Downstream Unsolicited, когда LSR не может выделить метку для FEC, чтобы отправить ее партнеру Peer.

A.2.2. Send_Label_Request

Описание

LSR использует процедуру Send_Label_Request для передачи запроса метки для FEC партнеру LDP, если это разрешено.

Параметры

  • Peer – партнер LDP, которому передается запрос метки;
  • FEC – класс FEC, для которого запрашивается метка;
  • Attributes – атрибуты для включения в запрос метки (например, Hop Count, Path Vector).

Дополнительный контекст

  • LSR – маршрутизатор LSR, выполняющий процедуру.

Алгоритм

SLRq.1 Запрос метки для FEC был ранее передан партнеру Peer и помечен, как ожидающий?

Если да, вернуть код успешного завершения (см. примечение 1).

SLRq.2 Имеется запись состояния, показывающая возможность запроса метки у партнера Peer?

Если нет, переход на SLRq.6

SLRq.3 Выполнить процедуру Send_Message (Peer, Label Request, FEC, Attributes).

SLRq.4 Записать факт передачи запроса метки для FEC партнеру Peer и пометки его, как ожидающего.

SLRq.5 Вернуть код успешного завершения.

SLRq.6 Отложить запрос метки, записав, что отображение метки на FEC и значение Attributes от партнера Peer требуются, но нет ресурсов для меток.

SLRq.7 Вернуть код отказа.

Примечание

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

A.2.3. Send_Label_Withdraw

Описание

LSR использует процедуру Send_Label_Withdraw для отзыва метки FEC у партнера LDP. Для этого LSR передает партнеру сообщение Label Withdraw.

Параметры

  • Peer – партнер LDP, у которого отзывается метка;
  • FEC – класс FEC, для которого отзывается метка;
  • Label – отзываемая метка.

Дополнительный контекст

  • LSR – маршрутизатор LSR, выполняющий процедуру.

Алгоритм

SWd.1 Выполнить процедуру Send_Message (Peer, Label Withdraw, FEC, Label).

SWd.2 Записать факт передачи отзыва метки для FEC партнеру Peer и пометить его, как ожидающий.

A.2.4. Send_Notification

Описание

LSR использует процедуру Send_Notification для передачи партнеру LDP сообщения Notification.

Параметры

  • Peer – партнер LDP, которому передается сообщение Notification;
  • Status – код состояния для включения в сообщение Notification.

Дополнительный контекст

Нет.

Алгоритм

SNt.1 Выполнить процедуру Send_Message (Peer, Notification, Status).

A.2.5. Send_Message

Описание

LSR использует процедуру Send_Message для передачи партнеру LDP сообщений LDP.

Параметры

  • Peer – партнер LDP, которому передается сообщение;
  • Message Type – тип передаваемого сообщения;
  • Дополнительные поля сообщения.

Дополнительный контекст

Нет.

Алгоритм

Эта процедура задает способ передачи маршрутизатором LSR сообщения LDP заданного типа указанному партнеру LDP.

A.2.6. Check_Received_Attributes

Описание

Проверка атрибутов, полученных в сообщении Label Mapping или Label Request. Если в число атрибутов входит Hop Count или Path Vector, выполняется проверка наличия петель (Loop Detection). При обнаружении петли передается уведомление Loop Detected по адресу MsgSource.

Параметры

  • MsgSource – партнер LDP, который передал сообщение;
  • MsgType – тип полученного сообщения;
  • RAttributes – атрибуты из сообщения.

Дополнительный контекст

  • LSR Id – уникальное значение LSR Id маршрутизатора LSR;
  • Hop Count – значение поля Hop Count в полученных атрибутах (при его наличии);
  • Path Vector – значение поля Path Vector в полученных атрибутах (при его наличии).

Алгоритм

CRa.1 Значение RAttributes включает Hop Count?

Если нет, переход на CRa.5.

CRa.2 Значение Hop Count превосходит максимально допустимое?

Если да, переход на CRa.6.

CRa.3 Значение RAttributes включает Path Vector?

Если нет, переход на CRa.5.

CRa.4 Path Vector включает LSR Id? или Размер Path Vector превосходит допустимый?

Если да, переход на CRa.6

CRa.5 Возврат кода No Loop Detected.

CRa.6 Значение MsgType равно LabelMapping?

Если да, переход на CRa.8. (See Note 1.)

CRa.7 Выполнить процедуру Send_Notification (MsgSource, Loop Detected).

CRa.8 Возврат кода Loop Detected.

CRa.9 Завершено.

Примечание

  1. Когда проверяемые атрибуты были получены в сообщении Label Mapping, LSR передает уведомление Loop Detected в поле Status Code TLV сообщения Label Release (см. приложение A.1.2. Получение Label Mapping).

A.2.7. Prepare_Label_Request_Attributes

Описание

Эта процедура используется в тех случаях, когда партнеру передается сообщение Label Request, для расчета значений Hop Count и Path Vector, включаемых в сообщение (при их наличии).

Параметры

  • Peer – партнер LDP, которому передается сообщение;
  • FEC – класс FEC, для которого запрашивается метка;
  • RAttributes – атрибуты, которые данный LSR связывает с LSP для FEC;
  • Sattributes – атрибуты для включения в сообщение Label Request.

Дополнительный контекст

  • LSR Id – уникальное значение LSR Id маршрутизатора LSR.

Алгоритм

PRqA.1 Значение Hop Count требуется для партнера Peer? (см. примечание 1) или Значение RAttributes включает Hop Count? или Детектирование петель (Loop Detection) включено на LSR?

Если нет, переход на PRqA.14.

PRqA.2 LSR является входом для FEC?

Если нет, переход на PRqA.6.

PRqA.3 Включить Hop Count = 1 в SAttributes.

PRqA.4 Механизм Loop Detection включен на LSR?

Если нет, переход на PRqA.14.

PRqA.5 LSR поддерживает слияние?

Если да, переход на PRqA.14.

Если нет, переход на PRqA.13.

PRqA.6 RAttributes включает Hop Count?

Если нет, переход на PRqA.8.

PRqA.7 Увеличить в RAttributes значение Hop Count на 1 и скопировать результат в SAttributes (см. примечание 2).

Перейти на PRqA.9.

PRqA.8 Включить Hop Count = 0 (unknown4) в SAttributes.

PRqA.9 Механизм Loop Detection включен на LSR?

Если нет, переход на PRqA.14.

PRqA.10 RAttributes включает Path Vector?

Если да, переход на PRqA.12.

PRqA.11 LSR поддерживает слияние?

Если да, переход на PRqA.14.

Если нет, переход на PRqA.13.

PRqA.12 Добавить LSR Id в начало Path Vector из RAttributes и скопировать результат в Path Vector поля SAttributes.

Перейти на PRqA.14.

PRqA.13 Включить Path Vector размера 1, содержащий LSR Id в поле SAttributes.

PRqA.14 Завершено.

Примечания

  1. Канал к партнеру Peer может требовать включения поля Hop Count в сообщения Label Request (для примера см. [RFC3035] и [RFC3034]).
  2. При подсчете числа интервалов используется арифметика unknown + 1 = unknown.

A.2.8. Prepare_Label_Mapping_Attributes

Описание

Эта процедура используется при подготовке сообщений Label Mapping для расчета значений Hop Count и Path Vector, если они включаются в сообщение.

Параметры

  • Peer – партнер LDP, которому передается сообщение;
  • FEC – класс FEC, для которого запрашивается метка;
  • RAttributes – атрибуты, которые данный LSR связывает с LSP для FEC;
  • Sattributes – атрибуты для включения в сообщение Label Request;
  • IsPropagating – LSR передает сообщение Label Mapping с целью распространение идентичного сообщения от следующего интервала FEC.
  • PrevHopCount – значение Hop Count (при наличии такового), которое данный LSR связывает с LSP для FEC.

Дополнительный контекст

  • LSR Id – уникальное значение LSR Id маршрутизатора LSR.

Алгоритм

PMpA.1 RAttributes включает неизвестные TLV?

Если нет, переход на PMpA.4.

PMpA.2 Требуется установка битов U и F до пересылки этих TLV?

Если нет, переход на PMpA.4.

PMpA.3 Скопировать неизвестные TLV в SAttributes.

PMpA.4 Значение Hop Count требуется для этого партнера? (см. примечание 1) или RAttributes включает Hop Count? или Режим Loop Detection включен на LSR?

Если нет, переход на PMpA.24.

PMpA.5 LSR является выходом для FEC?

Если нет, переход на PMpA.7.

PMpA.6 Включить Hop Count = 1 в SAttributes. Переход на PMpA.24.

PMpA.7 RAttributes содержит Hop Count?

Если нет, переход на PMpA.11.

PMpA.8 LSR входит в краевой набор домена LSR, члены которого на уменьшают значение TTL? и Peer входит в этот домен? (см. примечание 2).

Если нет, переход на PMpA.10.

PMpA.9 Включить Hop Count = 1 в SAttributes. Переход на PMpA.12.

PMpA.10 Увеличить значение Hop Count в RAttributes и скопировать результат в SAttributes (см. примечание 2).

Переход на PMpA.12.

PMpA.11 Включить Hop Count = 0 (unknown) в SAttributes.

PMpA.12 Режим Loop Detection включен на LSR?

Если нет, переход на PMpA.24.

PMpA.13 RAttributes включает Path Vector?

Если да, переход на PMpA.22.

PMpA.14 LSR распространяет полученные сообщения Label Mapping?

Если нет, переход на PMpA.23.

PMpA.15 LSR поддерживает слияние?

Если нет, переход на PMpA.17.

PMpA.16 LSR ранее передавал сообщение Label Mapping для FEC партнеру Peer?

Если нет, переход на PMpA.23.

PMpA.17 RAttributes включает Hop Count?

Если нет, переход на PMpA.24.

PMpA.18 Значение Hop Count в RAttributes =0 (unknown)?

Если да, переход на PMpA.23.

PMpA.19 LSR ранее передавал сообщение Label Mapping для FEC партнеру Peer?

Если нет, переход на PMpA.24.

PMpA.20 Значение Hop Count в RAttributes отличается от PrevHopCount?

Если нет, переход на PMpA.24.

PMpA.21 Значение Hop Count в RAttributes больше PrevHopCount? или PrevHopCount = 0 (unknown)?

Если нет, переход на PMpA.24.

PMpA.22 Добавить LSR Id в начало Path Vector из RAttributes и скопировать результат в SAttributes.

Перейти на PMpA.24.

PMpA.23 Включить Path Vector размером 1, содержащий значение LSR Id, d SAttributes.

PMpA.24 Завершено.

Примечания

  1. Канал к партнеру Peer может требовать включения поля Hop Count в сообщения Label Request (для примера см. [RFC3035] и [RFC3034]).
  2. Если LSR расположен на краю облака LSR, не уменьшающих значение TTL, и распространяет сообщение Label Mapping в восходящем направлении в это облако, он устанавливает Hop Count = 1 и значение Hop Count для прохождения через облако рассчитывается корректно. Это обеспечивает корректное управление значениями TTL для пакетов, которые пересылаются через часть LSP, проходящих сквозь облако.
  3. При подсчете числа интервалов используется арифметика unknown + 1 = unknown.

Адреса редакторов

Loa Andersson

Acreo AB

Isafjordsgatan 22

Kista, Sweden

EMail: loa.andersson@acreo.se

loa@pi.se

Ina Minei

Juniper Networks

1194 N. Mathilda Ave.

Sunnyvale, CA 94089

EMail: ina@juniper.net

Bob Thomas

Cisco Systems, Inc.

1414 Massachusetts Ave

Boxborough, MA 01719

EMail: rhthomas@cisco.com


Перевод на русский язык

Николай Малых

nmalykh@gmail.com

Полное заявление авторских прав

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.


1Non-Broadcast Multi-Access.

3Class of Service.

4Неизвестно.

Please follow and like us:
Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.

Добавить комментарий