RFC 5082 The Generalized TTL Security Mechanism (GTSM)

Network Working Group                                            V. Gill
Request for Comments: 5082                                    J. Heasley
Obsoletes: 3682                                                 D. Meyer
Category: Standards Track                                 P. Savola, Ed.
                                                            C. Pignataro
                                                            October 2007

 

Обобщенный механизм защиты на базе TTL (GTSM)

The Generalized TTL Security Mechanism (GTSM)

PDF

Статус документа

В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Тезисы

Использование значений времени жизни TTL1 (IPv4) или счетчика интервалов Hop Limit (IPv6) для проверки того, что пакет происходит от смежного узла на соединительном канале используется многими новыми протоколами. В этом документе обобщается данный метод. Документ заменяет собой экспериментальный RFC 3682.

Оглавление

Исключено в версии HTML.

1. Введение

Обобщенный механизм защиты на базе TTL (GTSM2) разработан для защиты базирующейся на протоколе IP инфраструктуры управления маршрутизаторами от атак, основанных на перегрузке CPU. Хотя использование криптографических методов может защитить инфраструктуру маршрутизации (например, BGP [RFC4271], [RFC4272]) от широкого класса атак, многие атаки, нацеленные на перегрузку CPU, можно предотвратить с помощью простого механизма, описываемого в этом документе. Отметим, что такой же метод используется для защиты от других атак, направленных на истощение ресурсов, включающих процессоры маршрутизаторов, таких как атаки с перегрузкой шины подключения процессорной платы.

Работа GTSM основана на том, что в большинстве протоколов партнерские отношения организуются между смежными маршрутизаторами. Т. е. в большинстве случаев партнеры соединены напрямую между их интерфейсами или, в худшем случае, используют для соединения петлевые интерфейсы (loopback) со статическими маршрутами. Поскольку подмена3 TTL считается почти невозможной, механизм основанный на ожидаемом значении TTL, может обеспечивать простую и достаточно отказоустойчивую защиту от атак на инфраструктуру, основанных на использовании обманных пакетов, передаваемых извне. Отметим, однако, что GTSM не является заменой механизмов аутентификации. В частности, этот метод не обеспечивает защиты от внутренних атак, связанных с доступом к каналам (например, с использованием обманных пакетов или повторным использованием собранных пакетов).

Механизм GTSM одинаково применим к TTL (IPv4) и Hop Limit (IPv6). Более того, с точки зрения GTSM семантика TTL и Hop Limit идентична. Поэтому в оставшейся части документа термин «TTL» используется для обозначения как TTL, так и Hop Limit.

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с [RFC2119].

2. Базовые допущения GTSM

Работа GTSM основана на нескольких допущениях, перечисленных ниже.

  1. Большая часть партнерских отношений организуется между соседними (смежными) маршрутизаторами.

  2. Сервис-провайдеры могут использовать или не использовать строгую входную фильтрацию [RFC3704] на недоверенных каналах. Если требуется максимальная защита, такая фильтрация нужна (см. параграф 2.2).

  3. Использование GTSM является необязательным и может настраивается на уровне отдельных пар партнеров.

  4. Оба маршрутизатора-партнера поддерживают GTSM.

  5. Маршрутизатор поддерживает метод разделения ресурсов (очередей, квот на обработку) для разных типов трафика.

Отметим, что в этом документе не описываются дополнительные ограничения, которые маршрутизаторы могут применять к пакетам, не соответствующим правилам фильтрации GTSM, типа отбрасывания пакетов, не соответствующих ни одной из заданных в конфигурации сессий, и ограничение скорости для остальных пакетов. Этот документ также не предполагает способов разделения ресурсов, поскольку такие способы зависят от оборудования и реализации.

Однако возможность предотвращения DoS-атак4 основана на допущении о классификации пакетов и разделении их путей до того, как пакет начнет использовать дефицитный ресурс системы. На практике четкая GTSM со скоростью среды передачи обеспечивает наибольшую устойчивость систем к DoS-атакам.

2.1. Согласование GTSM

В этом документе предполагается, что при использовании существующих протоколов GTSM будет вручную настраиваться для каждой пары протокольных партнеров. Т. е., не предполагается и не определяется способов автоматического согласования GTSM, типа определенных в RFC 3392 [RFC3392].

Если новый протокол разрабатывается со встроенной поддержкой GTSM, рекомендуется всегда использовать этот механизм для передачи пакетов и проверки полученных пакетов (механизм GTSM всегда включен, см., например, [RFC2461]). Однако, если требуется динамическое согласование GTSM, протокольные сообщения, используемые для такого согласования, должны аутентифицироваться с использованием других механизмов защиты для предотвращения DoS-атак.

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

2.2. Оценка изощренности атак

В этом документе предполагается, что атакующий достаточно изощрен и имеет доступ к точке, откуда он может передавать трафик управления в протокольный сеанс и этот трафик похож на нормальный трафик управления (т. е. пакеты имеют корректные для данной сессии адреса отправителя и получателя).

Предполагается также, что каждый маршрутизатор на пути между атакующим и объектом атаки корректно уменьшает значение TTL (естественно, что при компрометации пути или смежного партнера, ситуация ухудшается).

Для обеспечения максимальной защиты следует использовать фильтрацию пакетов на входе до того, как пакет начнет использовать дефицитный ресурс. В противном случае атакующий, подключенный непосредственно к интерфейсу, сможет нарушить работу защищенной с помощью GTSM сессии на этом или другом интерфейсе. Интерфейсы, для которых такая фильтрация не настроена (например, магистральные каналы) предполагаются недоступными для таких атак (т. е. расположенными в доверенной среде).

В качестве конкретного примера такого интерфейса мы полагаем, что туннель не имеет «черного хода», который позволил внедрять пакеты протокола с подставным TTL в защищенную GTSM сессию с непосредственно подключенным соседом. Предполагается, что 1) нет туннелируемых пакетов, адресованных маршрутизатору, 2) туннели, завершающиеся на маршрутизаторе, считаются защищенными, а конечные точки — доверенными, 3) декапсуляция туннеля включает предотвращение подмены адреса отправителя [RFC3704], 4) поддерживающие GTSM сессии не позволяют протокольным пакетам приходить из туннеля.

Поскольку основные преимущества партнерства реализуются между смежными маршрутизаторами, мы можем установить для пакетов протокола значение TTL = 255 (максимальное значение для IP) и отбрасывать пакеты протокола, которые приходят от партнера со значением TTL не равным 255.

GTSM можно отключить для отдельных приложений типа маршрутных серверов или иных случаев партнерства через несколько интервалов маршрутизации. В этом случае атака, ведущаяся через скомпрометированное соединение, может полностью нарушить партнерство через это соединение.

3. Процедуры GTSM

Если механизм GTSM не встроен в протокол и используется в качестве дополнения (например, для BGP, LDP или MSDP), его не следует включать по умолчанию для того, чтобы обеспечивалась совместимость с не измененными вариантами протоколов. Однако, если протокол определяет встроенное динамическое согласование для GTSM, партнер может предложить использование GTSM, которое будет включено при согласии обоих партнеров.

Если механизм GTSM включен для протокольного сеанса, к процедурам передачи и приема пакетов IP добавляются перечисленные ниже действия.

При передаче пакетов.

  • Поле TTL во всех пакетах IP, используемых для передачи сообщений, связанных с защищенной GTSM сессией протокола, должно иметь значение 255. Это требование относится также к сообщениям ICMP, связанным с обработкой ошибок.

  • В некоторых вариантах архитектуры значение TTL для пакетов управления декрементируется модулем пересылки. Для сеансов со включенной защитой GTSM значения TTL недопустимо уменьшать.

При получении пакетов.

  • Этап идентификации пакетов GTSM связывает каждый принятый пакет, который адресован уровню управления, с одной из трех категорий доверия:

  • Unknown (неизвестный) — пакеты, которые невозможно связать ни с одной зарегистрированной сессией, поддерживающей GTSM, и, следовательно, GTSM не может определить уровень риска, связанного с таким пакетом;

  • Trusted (доверенный) — пакет идентифицирован, как относящийся к одной из поддерживающих GTSM сессий, и значение TTL лежит в допустимом диапазоне;

  • Dangerous (опасный) — пакет идентифицирован, как относящийся к одной из поддерживающих GTSM сессий, но значение TTL не относится к допустимому диапазону и, следовательно, GTSM предполагает наличие риска того, что пакет может быть обманным.

  • Точные правила, применимые к пакетам разных категорий, не постулируются в этом документе и предполагаются настраиваемыми. Возможность настройки очевидно требуется (в частности) для сопутствующих пакетов (сообщений ICMP об ошибках). Следует отметить, что фрагментация может ограничивать объем информации, которая может быть доступна для классификации пакетов.

  • Однако, по умолчанию каждой реализации:

  • следует обеспечить отсутствие конкуренции за доступ к ресурсам между пакетами категории Dangerous и пакетами категории Trusted или Unknown;

  • недопустимо отбрасывать (в процессе обработки GTSM) пакеты категории Trusted или Unknown;

  • можно отбрасывать пакеты категории Dangerous.

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

Использование TTL для защиты BGP рассматривалось множеством авторов, включая Paul Traina и Jon Stewart. Ryan McDowell предложил похожую идею. Steve Bellovin, Jay Borkenhagen, Randy Bush, Alfred Hoenes, Vern Paxon, Robert Raszuk и Alex Zinin предоставили полезные отклики на ранние версии этого документа. David Ward представил обобщение исходной идеи, связанной с BGP. Alex Zinin, Alia Atlas и John Scudder предоставили множество откликов для новой версии документа. Во время процедуры IETF Last Call и после нее были получены полезные комментарии от Francis Dupont, Sam Hartman, Lars Eggert и Ross Callon.

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

GTSM представляет собой простую процедуру, которая защищает протокольные сессии, организованные на одном интервале пересылки (single-hop), за исключением ситуаций, когда партнер скомпрометрирован. В частности, этот метод не обеспечивает защиты против широкого класса атак on-the-wire (с прямым подключением к линии), для которых требуются более изощренные механизмы.

5.1. Обманые TTL (Hop Limit)

Описанный здесь подход основан на наблюдении, что значение TTL (или Hop Limit) 255 не так просто подделать, поскольку по мере прохождения пакета по пути к адресату каждый маршрутизатор будет уменьшать значение TTL. В результате, при получении пакета маршрутизатором пригодность пакета IP проверить нельзя, но можно определить число маршрутизаторов, через которые он прошел (в предположении, что ни один из маршрутизаторов на этом пути не был скомпрометирован для подмены значений TTL).

Отметим однако, что хотя создание пакетов с определенным значением TTL (по прибытии), происходящих из произвольной точки, сложно (но возможно), создать пакеты с TTL 255 при отсутствии непосредственного соединения невозможно (опять-таки в предположении отсутствия скомпрометрированных соседей с непосредственным соединением и туннелей до декапсулятора, а также работы промежуточных маршрутизаторов в соответствии с RFC 791 [RFC0791]).

5.2. Туннелированные пакеты

Защита при любом методе туннелирования зависит от сложности аутентификации на конечных точках туннеля, а также от способа защиты туннелируемых пакетов «в полете». Однако эти механизмы выходят за рамки данного документа.

Сложность подделки пакетов с TTL 255 можно преодолеть, если для этих пакетов и самого туннеля не обеспечивается защиты целостности (т. е. нижележащий уровень скомпрометирован).

Когда пакет туннелируется непосредственно к протокольному партнеру (т. е. этот партнер является декапсулятором туннеля), GTSM обеспечивает ограниченную защиту, которая зависит от целостности туннеля.

Если протокольная смежность организована через туннель и сам туннель представляется защищенным (т. е. нижележащая инфраструктура представляется защищенной, а туннель обеспечивает защиту от подделок для ключей и криптографических средств), GTSM может применяться для обнаружения протокольных пакетов, отправленных из точки, не являющейся другим концом туннеля. В дополнение к этому GTSM может помочь предотвратить атаки из-за соседнего маршрутизатора, если протокольный партнер получает пакеты для защищенной с помощью GTSM сессии извне туннеля.

Когда конечная точка туннеля декапсулирует протокольный пакет и потом пересылает пакет IP протокольному партнеру, значение TTL уменьшается как описано выше. Это означает, что декапсулятор туннеля с точки зрения защищенного с помощью GTSM протокольного партнера является предпоследним узлом. В результате проверка GTSM защищает от атакующих, которые инкапсулируют пакеты для ваших партнеров. Однако имеются особые случаи , когда соединение между декапсулятором туннеля и протокольным партнером не включает интервал пересылки (hop) IP, где значение TTL уменьшается (например, туннелирование на канальном уровне, мост и т. п.). В архитектуре IPsec [RFC4301] еще одним примером служит использование устройств BITW5 [BITW].

5.2.1. Туннелирование IP по протоколу IP

Пакеты протокола могут туннелироваться через IP непосредственно протокольному партнеру или декапсулятору (конечная точка туннеля), который пересылается that пакеты подключенному к нему непосредственно протокольному партнеру. Примерами туннелирования IP по протоколу IP являются IP-in-IP [RFC2003], GRE [RFC2784] и разные формы IPv6-in-IPv4 (например, [RFC4213]). Здесь возможны два варианта, которые проиллюстрированы ниже.

       Партнер ----------- Маршрутизатор конечной точки туннеля и партнер
       TTL=255     [туннель]  [TTL=255 на входе]
                              [TTL=255 при обработке]

       Партнер ----------- Маршрутизатор конечной точки туннеля ----- Партнер на канале
       TTL=255    [туннель] [TTL=255 на входе]                        [TTL=254 на входе]
                            [TTL=254 на выходе]

В обоих случаях инкапсулятор (исходная точка туннеля) является (предполагаемым) отправителем. Значение TTL во вложенной дейтаграмме IP может быть установлено в 255, поскольку RFC 2003 задает приведенное ниже поведение.

При инкапсуляции дейтаграммы значение TTL во внутреннем заголовке IP уменьшается на 1, если туннелирование осуществляется, как часть пересылки дейтаграммы. В противном случае значение TTL во внутреннем заголовке при инкапсуляции не меняется.

В первом случае инкапсулируемых пакет туннелируется напрямую протокольному партнеру (конечная точка туннеля) и, следовательно, значение TTL в принятых протокольным партнером пакетах может быть любым, включая 255.

Во втором случае инкапсулированный пакет туннелируется декапсулятору (конечная точка туннеля), который потом пересылает пакет непосредственно подключенному к нему протокольному партнеру. Для туннелей IP-in-IP документ RFC 2003 задает описанное ниже поведение декапсулятора.

Значение TTL во внутреннем заголовке IP не меняется при декапсуляции. Если после декапсуляции во внутреннем заголовке TTL = 0, декапсулятор должен отбросить дейтаграмму. Если после декапсуляции дейтаграмма пересылается через один из сетевых интерфейсов декапсулятора, значение TTL будет уменьшаться в результате обычной пересылки IP. Дополнительная информация о работе с полем TTL приведена в параграфе 4.4.

Аналогично для туннелей GRE документ RFC 2784 задает указанное ниже поведение.

Когда конечная точка туннеля декапсулирует пакет GRE, в который вложен пакет IPv4, адрес получателя из заголовка пакета IPv4 должен использоваться для дальнейшей пересылки пакета, а значение TTL в заголовке вложенного пакета должно быть декрементировано.

Следовательно, значение TTL в заголовке внутреннего пакета IP, видимое декапсулятору, может быть произвольным (в частности, 255). Если декапсулятор является и протокольным партнером, ему можно будет доставить пакет с TTL 255 (первый случая). Если же декапсулятор должен переслать протокольный пакет непосредственно подключенному к нему партнеру, значение TTL будет уменьшено (второй случай).

5.2.2. Туннелирование IP через MPLS

Протокольные пакеты могут также туннелироваться партнерам через MPLS LSP6 как показано ниже.

       Партнер    --------   Завершающий LSP маршрутизатор и партнер
       TTL=255    MPLS LSP   [TTL=x на входе]

MPLS LSP может работать в режиме туннелирования Uniform или Pipe. Обработка TTL для этих режимов описана RFC 3443 [RFC3443], который обновляет RFC 3032 [RFC3032] в части обработки TTL в сетях MPLS. В RFC 3443 описана обработка TTL в режимах Uniform и Pipe, которые, в свою очередь, могут использовать или не использовать PHP7. Обработка TTL в этих случаях дает разные результаты, поэтому они анализируются раздельно в параграфах 3.1- 3.3 RFC 3443.

Основное различие в плане обработки TTL между режимами Uniform и Pipe на завершающем LSP узле состоит в способе определения входящего значения TTL (iTTL). Для LSP в режиме Uniform iTTL будет принимать значение поля TTL из заголовка инкапсуляции (popped MPLS header), а для LSP в режиме Pipe iTTL будет принимать значение поля TTL из инкапсулированного заголовка.

Для Uniform LSP в RFC 3443 сказано, что на входе:

Для каждой вытолкнутой метки в режиме Uniform значение TTL копируется из расположенного непосредственно ниже пакета IP/метки.

С этого момента внутреннее значение TTL (т. е. TTL в туннелируемой дейтаграмме IP) не содержит осмысленной информации и на краевом узле или в процессе PHP входное значение TTL (iTTL) будет равно TTL из вытолкнутого заголовка MPLS (параграф 3.1 в RFC 3443). Следовательно для Uniform LSP с несколькими (более 1) интервалами пересылки TTL на входе (iTTL) будет меньше 255 (x <= 254) и описанная в разделе 3 проверка даст отрицательный результат.

Трактовка TTL идентична для Short Pipe LSP без PHP и Pipe LSP (только без PHP). Для этих случаев в RFC 3443 сказано:

«Для каждой вталкиваемой (pushed) метки в режиме Pipe или Short Pipe в поле TTL устанавливается значение, заданное оператором. Во многих реализациях по умолчанию установлено значение 255.»

В этих моделях трактовка пересылки на выходе основана на туннелированных, а не инкапсулированных пакетах. Входное значение TTL (iTTL) является значением поля TTL из видимого (exposed) заголовка, т. е. TTL туннелируемой дейтаграммы TTL. Следовательно, значение TTL в протокольных пакетах, видимое в точке завершения LSP, может быть произвольным (включая 255). Если завершающий LSP маршрутизатор является и протокольным партнером, протокольные пакеты могут доставляться с TTL 255 (x = 255).

Для Short Pipe LSP с PHP значение TTL в туннелируемых пакетах не меняется после операции PHP. Поэтому в данном случае применимы те же выводы, которые были сделаны для Short Pipe LSP без PHP и Pipe Model LSP (только без PHP). Для Short Pipe LSP значение TTL на выходе не зависит от применения PHP.

В заключение отметим, что проверка GTSM возможна для пакетов IP, туннелируемых через Pipe LSP, но не через Uniform LSP. Кроме того, доставка протокольному партнеру пакетов протокола с TTL 255 невозможна, если завершающему LSP маршрутизатору требуется пересылать пакеты непосредственно подключенному к нему протокольному партнеру. Если пакет пересылает, выходное значение TTL (oTTL) определяется путем уменьшения iTTL на 1.

5.3. Атаки из канала

Как было описано в разделе 2, атакующий, подключившийся напрямую к одному из интерфейсов, может нарушить работу защищенной с помощью GTSM сессии на том же или другом интерфейсе (подменив адрес партнера GTSM), если на интерфейсе не используется входной фильтрации. В результате интерфейсам без такой защиты приходится просто доверять в части отсутствия атак с их стороны.

5.4. Вопросы, связанные с фрагментированием

Как уже было отмечено, фрагментирование может ограничить объем данных, доступных для классификации. Поскольку фрагменты IP (кроме первых) не содержат информации уровня 4, очевидна невозможность связать их с зарегистрированной сессией GTSM. В соответствии с процедурами принимающего протокола, описанными в разделе 3, фрагменты IP, не являющиеся начальными, будут вероятней всего отнесены к типу Unknown. А поскольку для обработки пакета IP требуется собрать его из фрагментов, конечным результатом в сессии GTSM будет трактовка собранного пакета, как Unknown.

В принципе, реализация может запомнить значения TTL всех полученных фрагментов. После этого при сборке пакета проверяется соответствие TTL каждого фрагмента требуемому значению для связанной сессии с поддержкой GTSM. В очевидном общем случае когда реализация не проверяет все фрагменты, вполне возможно объединение легитимного первого фрагмента (который прошел проверку GTSM) с поддельными последующими фрагментами с допущением того, что целостность принятого пакета не проверена и не защищена. Если проверка выполняется при сборке для всех фрагментов и неких фрагмент не прошел проверку GTSM для сессии с поддержкой GTSM, собранный в результате пакет считается «опасным и недоверенным» (Dangerous-trustworthiness) с соответствующей этому обработкой.

Кроме того для сборки требуется дождаться получения всех фрагментов и это делает неприменимым докушение п. 5 в параграфе 2 — классификация не являющихся первыми фрагментов может оказаться невозможной по причине нехватки системных ресурсов, поскольку фрагменты потребуется буферизовать, а потом обработать с участием CPU. Т. е. в тех случаях, когда классификация не может быть выполнена с нужной детализацией, отличные от начальных фрагменты в сессиях с поддержкой GTSM не будут использовать разные пулы ресурсов.

Следовательно, для обеспечения на практике защиты от атак с применением фрагментов оператору может потребоваться ограничить скорость приема или отбросить все полученные фрагменты. В таких случаях настоятельно рекомендуется для защищенных GTSM протоколов предотвращать фрагментацию и сборку путем ручной настройки MTU с использованием адаптивных измерений типа PMTUD8 или иных доступных методов [RFC1191], [RFC1981] или [RFC4821].

5.5. Протокольные сессии с промежуточной пересылкой (Multi-Hop)

GTSM может обеспечить некоторую (трудно оцениваемую количественно) степень защиты при использовании в протокольных сессиях с промежуточной пересылкой (multi-hop, см. Приложение A). Чтобы избежать сложностей с количественной оценкой защиты и связанной с этим применимости метода здесь описан только вариант без промежуточной пересылки (single-hop), поскольку для него проще разобраться с защитой.

6. Заявление о применимости

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

GTSM не обеспечивает защиты от атакующих, которые расположены защищаемых узлов, как их легитимные партнеры. Например, если легитимные партнеры располагаются на расстоянии в один интервал пересылки (hop), GTSM не сможет обеспечить защиты от атакующих с непосредственно подключенных к тому же интерфейсу устройств (см. параграф 2.2).

Для соединений с промежуточной пересылкой (multi-hop) применимость GTSM требует дополнительных экспериментов и оценки защиты. Предполагается, что механизм GTSM будет пригоден для случаев наличия промежуточной пересылки, если топология соединения между партнерами известна и не меняется, а промежуточные сети (между партнерами) являются доверенными.

6.1. Совместимость с ранними версиями

RFC 3682 [RFC3682] не задает способов обработки «связанных сообщений» (ошибки ICMP). Данная спецификация задает установку и проверку TTL=255 для таких пакетов, как и для пакетов основного протокола.

Установка TTL=255 в пакетах связанных сообщение не создает проблем для реализаций RFC 3682.

Требование установки TTL=255 в пакетах связанных сообщений может оказывать влияние на реализации RFC 3682 в зависимости от используемого такой реализацией по умолчанию значения TTL (в некоторых принято 255, а в других — 64). Связанные сообщения второй категории реализаций RFC 3682 (не 255) будут считаться опасными (Dangerous) и обрабатываться в соответствии с разделом 3. Это не создает существенных проблем, поскольку протоколы не зависят от связанных сообщений (например, для разрыва сессии применяется протокольный обмен, а не TCP-RST) и доставка связанных сообщений не считается надежной. Связанные сообщения, как таковые, обычно служат для оптимизации и сокращения тайм-аутов keepalive. Тем не менее, вспомогательные сообщения обеспечивают важный вектор атак (например, позволяя сбрасывать сессии), предлагаемое ограничение представляет обоснованным.

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

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

[RFC0791] Postel, J., «Internet Protocol», STD 5, RFC 791, September 1981.

[RFC2003] Perkins, C., «IP Encapsulation within IP», RFC 2003, October 1996.

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

[RFC2461] Narten, T., Nordmark, E., and W. Simpson, «Neighbor Discovery for IP Version 6 (IPv6)», RFC 2461, December 1998.

[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, «Generic Routing Encapsulation (GRE)», RFC 2784, March 2000.

[RFC3392] Chandra, R. and J. Scudder, «Capabilities Advertisement with BGP-4», RFC 3392, November 2002.

[RFC3443] Agarwal, P. and B. Akyol, «Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks», RFC 3443, January 2003.

[RFC4213] Nordmark, E. and R. Gilligan, «Basic Transition Mechanisms for IPv6 Hosts and Routers», RFC 4213, October 2005.

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

[RFC4301] Kent, S. and K. Seo, «Security Architecture for the Internet Protocol», RFC 4301, December 2005.

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

[BITW] «Thread: ‘IP-in-IP, TTL decrementing when forwarding and BITW’ on int-area list, Message-ID: <Pine.LNX.4.64.0606020830220.12705@netcore.fi>», June 2006, <http://www1.ietf.org/mail-archive/web/int-area/current/msg00267.html>.

[RFC1191] Mogul, J. and S. Deering, «Path MTU discovery», RFC 1191, November 1990.

[RFC1981] McCann, J., Deering, S., and J. Mogul, «Path MTU Discovery for IP version 6», RFC 1981, August 1996.

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

[RFC3682] Gill, V., Heasley, J., and D. Meyer, «The Generalized TTL Security Mechanism (GTSM)», RFC 3682, February 2004.

[RFC3704] Baker, F. and P. Savola, «Ingress Filtering for Multihomed Networks», BCP 84, RFC 3704, March 2004.

[RFC4272] Murphy, S., «BGP Security Vulnerabilities Analysis», RFC 4272, January 2006.

[RFC4821] Mathis, M. and J. Heffner, «Packetization Layer Path MTU Discovery», RFC 4821, March 2007.

Приложение A. Multi-Hop GTSM

Примечание. Это приложение не является нормативной частью спецификации.

Основным применением GTSM являются непосредственные соединения между партнерами. GTSM можно использовать для сессий с промежуточными узлами пересылки, где получатели будут проверять отличие значения TTL от 255 на заданное число промежуточных устройств. Поскольку применимость такого варианта менее очевидна и не столь понятно его влияние на защиту, этот случай не включен в спецификацию.

Приложение B. Отличия от RFC 3682

  • Статус поднят до уровня Standards Track (RFC 3682 имел статус Experimental).

  • Добавлен текст о применимости GTSM и использовании новых и существующих протоколов.

  • Ограничена область действия сессиями без промежуточных узлов (без multi-hop).

  • Явно указано, что связанные сообщения (ошибки ICMP) также должны передаваться и проверяться на наличие TTL=255. Вопросы совместимости с прежней версией рассмотрены в параграфе 6.1.

  • Приведены разъяснения в части фрагментирования, использования туннелей и влияния входных фильтров.

  • Внесены многочисленные редакторские правки для улучшения и прояснения текста.

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

Vijay Gill

EMail: vijay@umbc.edu

John Heasley

EMail: heas@shrubbery.net

David Meyer

EMail: dmm@1-4-5.net

Pekka Savola (editor)

Espoo

Finland

EMail: psavola@funet.fi

Carlos Pignataro

EMail: cpignata@cisco.com

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

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

nmalykh@protocols.ru

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

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.

1Time to Live.

2Generalized TTL Security Mechanism.

3В оригинале — spoofing. Прим. перев.

4Denial-of-service — отказ в обслуживании.

5Bump-in-the-Wire — букв., «утолщение в проводе» — шифратор на канальном или физическом уровне, включаемый просто в разрыв сетевого кабеля.

6Label Switched Path — путь с коммутацией по меткам.

7Penultimate hop popping — выталкивание на предпоследнем интервале.

8Path MTU Discovery — определение MTU для пути.




RFC 5036 Часть 2

Часть 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Неизвестно.




RFC 5036 LDP Specification

Network Working Group                              L. Andersson, Ed.
Request for Comments: 5036                                  Acreo AB
Obsoletes: 3036                                        I. Minei, Ed.
Category: Standards Track                           Juniper Networks
                                                      B. Thomas, Ed.
                                                 Cisco Systems, Inc.
                                                        October 2007

 

Спецификация LDP

LDP Specification

PDF

Статус документа

Этот документ содержит проект стандартного протокола Internet для сообщества Internet и служит приглашением к дискуссии в целях развития и совершенствования протокола. Информацию о текущем состоянии стандартизации протокола можно найти в документе Internet Official Protocol Standards (STD 1). Документ можно распространять без ограничений.

Тезисы

Архитектура многопротокольной коммутации по меткам (MPLS1) описана в RFC 3031. Базовая концепция MPLS заключается в том, что два маршрутизатора с коммутацией по меткам (LSR2) должны согласовать между собой толкование меток, используемых для пересылки трафика между маршрутизаторами и через них (транзит). Для согласования служит набор процедур, который называют протоколом распространения меток. С помощью этого протокола каждый LSR информирует других о созданных им связках меток. В данном документе определен набор процедур — протокол LDP3, с помощью которых маршрутизаторы LSR распространяют метки для поддержки пересылки MPLS по путям с обычной маршрутизацией.

Оглавление

Исключено из версии HTML

1. Обзор LDP

Архитектура MPLS [RFC3031] определяет протокол распространения меток, как набор процедур, посредством которых маршрутизатор LSR информирует другой маршрутизатор о значениях меток, используемых для пересылки трафика между маршрутизаторами и через них.

Архитектура MPLS не предполагает использования единственного протокола распространения меток. Фактически стандартизировано множество таких протоколов. Существующие протоколы были расширены для того, чтобы с их помощью можно было распространять метки. Были также определены новые протоколы, явно предназначенные для распространения меток. В архитектуре MPLS приведено рассмотрение некоторых аспектов выбора протокола распространения меток для отдельных приложений MPLS типа TE4 [RFC2702].

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

Протокол LDP предназначен для распространения меток. Он представляет собой набор процедур и сообщений, с помощью которых маршрутизаторы LSR организуют пути с коммутацией по меткам (LSP5) через сеть за счет отображения маршрутной информации сетевого уровня непосредственно на коммутируемые пути канального уровня. Конечные точки LSP могут располагаться на смежных маршрутизаторах (сравнимо с поэтапной пересылкой IP) или на выходных узлах сети, обеспечивающей коммутацию на всех промежуточных узлах.

LDP связывает класс эквивалентной пересылки (FEC6) [RFC3031] с каждым создаваемым LSP. Класс FEC, связанный с LSP, задает, какие пакеты будут «отображаться» на данный LSP. При прохождении LSP через сеть каждый LSR «сращивает» входящую метку для FEC с исходящей меткой, которую выделил для данного FEC следующий маршрутизатор.

Дополнительную информацию о применимости протокола LDP можно найти в [RFC3037].

Данный документ предполагает (но не требует) знакомства читателя с архитектурой MPLS [RFC3031]. Отметим, что [RFC3031] включает глоссарий терминов, связанных с MPLS.

1.1. Партнеры LDP

Пару маршрутизаторов LSR, использующих протокол LDP для обмена информацией о связывании меток с FEC, будем называть партнерами LDP (LDP Peer) относительно такой информации, а протокольное взаимодействие между партнерами будем называть «сессией LDP». Одна сессия LDP позволяет каждому из партнеров узнать отображения, выполненные другим партнером, т. е. протокол является двусторонним.

1.2. Обмен сообщениями LDP

Существует 4 категории сообщений LDP:

  1. сообщения об обнаружении (Discovery) используются для анонсирования и поддержки присутствия LSR в сети;
  2. сеансовые сообщения (Session) служат для организации, поддержки и завершения сеансов обмена между партнерами LDP;
  3. анонсы (Advertisement) используются для создания, изменения и удаления отображений FEC на метки;
  4. уведомления (Notification) служат для передачи дополнительной информации и сведений об ошибках.

Сообщения Discovery обеспечивают механизм, с помощью которого LSR показывает свое присутствие в сети, передавая периодически сообщения Hello. Эти сообщения передаются в форме пакетов UDP на порт LDP с групповым адресом all routers on this subnet7 в поле получателя. Когда LSR намеревается организовать сеанс взаимодействия с другим LSR, найденным с помощью сообщения Hello, он использует процедуру инициализации LDP по протоколу TCP. После успешного завершения процедуры инициализации два LSR становятся партнерами LDP и могут обмениваться анонсами.

Запрос метки или анонсирование отображения метки партнеру определяется в основном локально маршрутизатором LSR. В общем случае LSR запрашивает отображение метки у соседнего LSR, когда такое отображение нужно, и анонсирует отображение метки соседнему LSR, когда желает, чтобы тот использовал эту метку.

Для корректной работы LDP требуется надежная и упорядоченная доставка сообщений. Для выполнения этих требований LDP использует транспортный протокол TCP для сообщений Session, Advertisement и Notification, а протокол UDP применяется только для сообщений Discovery.

1.3. Структура сообщения LDP

Все сообщения LDP имеют однотипную структуру, основанную на формате TLV8 (см. параграф 3.3. Представление TLV). Часть Value объекта в формате TLV может содержать один или множество элементов TLV.

1.4. Обработка ошибок LDP

Информация об ошибках LDP и других событиях передается партнеру LDP в сообщениях Notification.

Существует два типа сообщений LDP Notification.

  1. Уведомления об ошибках используются для передачи информации о критических ошибках. Если LSR получает от своего партнера сообщение Error Notification для сессии LDP, он завершает эту сессию, закрывая транспортное соединение TCP для нее и отбрасывая отображения меток, полученные в этой сессии.
  2. Сообщения Advisory Notification служат для передачи информации о состоянии сессии или статусе некоторых сообщений, полученных ранее от партнера.

1.5. Расширяемость LDP и совместимость с будущими версиями

В будущем к протоколу LDP могут быть добавлены новые функции. Очевидно, что для новой функциональности будут применяться новые сообщения и типы объектов (TLV). Может оказаться желательным развертывание реализаций с новыми сообщениями и TLV в существующих сетях таким образом, чтобы более старые реализации просто не распознавали новинки. Хотя и невозможно сделать все новые расширения совместимыми со старыми версиями, некоторое упреждающее планирование может упростить внесение новых возможностей. В данной спецификации определены правила обработки новых сообщений и новых типов TLV с учетом этих обстоятельств.

1.6. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с [RFC2119].

2. Работа LDP

2.1. Классы FEC

Требуется точно указать, какие пакеты могут отображаться на каждый LSP. Это осуществляется путем задания спецификации FEC для каждого LSP. Класс FEC идентифицирует множество пакетов IP, которые могут быть отображены на данный LSP.

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

Данная спецификация определяет единственный тип элементов FEC — «адресный префикс9». Этот элемент представляет собой адресный префикс, размер которого может меняться от 0 до полного размера адреса, включительно.

При необходимости в других спецификациях могут быть определены дополнительные элементы FEC.

В оставшейся части этого параграфа приведены правила, которые будут использоваться для отображения пакетов на LSP, организуемые с помощью элементов Address Prefix FEC.

Мы говорим, что некий адрес «соответствует» некому адресному префиксу тогда и только тогда, когда этот адрес начинается с данного префикса. Мы говорим также, что некий пакет соответствует LSP тогда и только тогда, когда данный LSP имеет элемент Address Prefix FEC, соответствующий адресу получателя пакета. Применительно к конкретному пакету и конкретному LSP будем называть элемент Address Prefix FEC, который соответствует пакету, «соответствующим префиксом».

Процедура отображения конкретного пакета на конкретный LSP использует рассмотренные ниже правила, каждое из которых применяется по очереди, пока пакет не будет отображен на LSP.

  • Если пакет соответствует в точности одному LSP, он отображается на данный LSP.
  • Если пакет соответствует множеству LSP, он отображается на тот LSP, который имеет наиболее длинный соответствующий префикс. Если среди LSP нет одного с самым длинным префиксом, пакет отображается на один из множества LSP, имеющих самые длинные соответствия префиксов. Процедура выбора одного из LSP с соответствующими префиксами одного размера выходит за пределы данного документа.
  • Если известно, что пакет должен пройти через конкретный выходной маршрутизатор и имеется LSP с элементом Address Prefix FEC, который точно (/32) соответствует адресу данного маршрутизатора, пакет отображается на этот LSP. Процедура получения такой информации выходит за пределы данного документа.

Процедура определения необходимости прохождения пакета через конкретный выходной маршрутизатор выходит за пределы данной спецификации. В качестве примера укажем, что при использовании алгоритма маршрутизации по состояниям каналов можно получить нужную информацию из базы данных о состояниях каналов. В случае использования BGP информацию можно получить из атрибута BGP next hop в маршруте для данного пакета.

2.2. Пространства меток, идентификаторы, сессии и транспорт

2.2.1. Пространства меток

Понятие «пространства меток» полезно при обсуждении присваивания и распространения меток. Используется два типа пространств меток.

  • Пространство меток интерфейса. Связанные с интерфейсом входящие метки применяются для интерфейсов, которые используют ресурсы интерфейса для меток. Примером такого интерфейса может служить управляемый по меткам интерфейс ATM, использующий VCI10 в качестве меток, или интерфейс Frame Relay, который использует значения DLCI11, как метки.Отметим, что использовать пространство меток масштаба интерфейса имеет смысл лишь в тех случаях, когда партнеры LDP напрямую соединены через этот интерфейс и метки будут применяться только для трафика, передаваемого через этот интерфейс.
  • Пространство меток платформы. Входящие метки в масштабе всей платформы используются для интерфейсов, которые могут разделять общие метки.

2.2.2. Идентификаторы LDP

Идентификатор LDP представляет собой 6-октетное значение, которое идентифицирует пространство меток LSR. Первые 4 октета идентифицируют маршрутизатор LSR и должны быть уникальными в глобальном масштабе. Этому условию удовлетворяет 32-битовое значение Router Id, присвоенное LSR. Два последних октета идентифицируют пространство меток в данном LSR. Эти два октета LDP Identifier для пространства меток платформы всегда имеют нулевые значения. В данной спецификации используется представление идентификаторов LDP в виде:
<LSR Id>:<label space id>

например, lsr171:0, lsr19:2.

Отметим, что LSR, которые поддерживает и анонсирует множество пространств меток, использует для каждого из таких пространств свое значение LDP Identifier.

Ситуация, когда LSR требуется анонсировать партнеру более одного пространства меток и, следовательно, использовать множество идентификаторов LDP, возникает при наличии у LSR двух ATM-соединений с партнером и использовании пространства меток в масштабе интерфейса. Другим примером может служить LSR, соединенный с партнером через интерфейсы Ethernet (пространство меток в масштабе платформы) и ATM.

2.2.3. Сессии LDP

Сеансы LDP организуются между парой LSR для поддержки обмена метками.

Когда LSR использует LDP для анонсирования множества пространств меток другому LSR, для каждого из пространств меток создается своя сессия LDP.

2.2.4. Транспорт LDP

LDP использует протокол TCP в качестве гарантированного транспорта для поддержки сессий.

Если между парой LSR требуется организовать множество сессий LDP, организуется одно соединение (сессия) TCP на каждую сессию LDP.

2.3. Сессии LDP между LSR, не соединенными напрямую

Сессии LDP между маршрутизаторами LSR, не соединенными между собой непосредственно на канальном уровне, в некоторых ситуациях могут оказаться желательными.

В качестве примера рассмотрим задачу построения трафика для случая, когда LSRa передает трафик, соответствующий некому критерию, по пути LSP, не подключенному непосредственно к LSRb, вместо пересылки такого трафика по пути с обычной маршрутизацией.

Путь между LSRa и LSRb будет включать один или множество промежуточных маршрутизаторов LSR (LSR1,…LSRn). Сессия LDP между LSRa и LSRb будет позволять маршрутизатору LSRb помечать коммутируемый трафик, приходящий по LSP от LSRa, благодаря возможности анонсирования маршрутизатором LSRb используемых для этого меток маршрутизатору LSRa.

В такой ситуации LSRa будет использовать для трафика, пересылаемого в LSP для маршрутизатора LSRb, две метки — первая метка будет получена от промежуточного маршрутизатора LSR1 и служит для пересылки трафика по пути LSP от LSRa к LSRb, вторая метка будет получена от LSRb для того, чтобы тот мог помечать коммутируемый трафик, приходящий на LSP.

LSRa сначала добавляет в стек метку, полученную через сеанс LDP с маршрутизатором LSRb (меняя верхнюю метку в стеке меток пакета, если пакет был помечен, или вталкивая метку в стек непомеченного пакета). После этого в стек помещается метка для LSP, полученная от LSR1.

2.4. LDP Discovery

Обнаружение LDP (LDP Discovery) представляет собой механизм, который позволяет маршрутизаторам LSR находить потенциальных партнеров LDP. Обнаружение избавляет от необходимости явно настраивать пары LSR для коммутации по меткам.

Существует два варианта механизма обнаружения:

  • основной механизм (Basic Discovery) используется для обнаружения соседних LSR, с которыми есть непосредственное соединение на канальном уровне;
  • расширенный механизм (Extended Discovery) используется для нахождения LSR, с которыми нет прямого соединения на канальном уровне.

2.4.1. Основной механизм обнаружения

Для включения на интерфейсе механизма LDP Basic Discovery маршрутизатор LSR периодически шлет сообщения LDP Link Hello через этот интерфейс. Сообщения LDP Link Hello передаются в форме пакетов UDP, направляемых в стандартный порт LDP по групповому адресу всех маршрутизаторов подсети12.

Сообщение LDP Link Hello, переданное LSR, содержит идентификатор LDP для пространства меток, которое LSR предполагает использовать на этом интерфейсе, и может содержать дополнительную информацию.

Получение сообщения LDP Link Hello через некий интерфейс показывает наличие смежности (Hello adjacency) с потенциальным партнером LDP, доступным через этот интерфейс на канальном уровне, а также пространство меток, которое партнер предлагает использовать для данного интерфейса.

2.4.2. Расширенный механизм обнаружения

Сессии LDP между LSR, не соединенными напрямую, поддерживаются с помощью механизма LDP Extended Discovery.

Для включения LDP Extended Discovery маршрутизатор LSR периодически шлет сообщения LDP Targeted Hello по конкретному адресу. Сообщения LDP Targeted Hello передаются в форме пакетов UDP направленных в стандартный порт LDP по заданному адресу.

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

Механизм Extended Discovery отличается от Basic Discovery в следующем:

  • сообщение Targeted Hello передается по конкретному адресу вместо группового адреса всех маршрутизаторов подсети;
  • механизм Basic Discovery является симметричным, а Extended Discovery — асимметричным.Маршрутизатор LSR инициирует процедуру Extended Discovery с интересующим его LSR, а тот самостоятельно принимает решение об ответе на сообщение Targeted Hello или игнорировании его. LSR, решивший ответить на приветствие, выполняет это путем периодической отправки сообщений Targeted Hello инициировавшему обмен маршрутизатору LSR.

Получение сообщения LDP Targeted Hello показывает наличие смежности (Hello adjacency) с потенциальным партнером LDP, доступным на сетевом уровне, а также пространство меток, которое партнер предлагает использовать.

2.5. Организация и поддержка сессий LDP

2.5.1. Организация сеанса LDP

Обмен сообщениями LDP Discovery Hello между парой LSR включает процесс организации сессии LDP, состоящий из двух этапов:

  • организация транспортного соединения;
  • инициализация сессии.

Далее описана организация сессии LDP между маршрутизаторами LSR1 и LSR2 с точки зрения LSR1. Предполагается, что при обмене сообщениями Hello было задано пространство меток LSR1:a для маршрутизатора LSR1 и LSR2:b — для LSR2.

2.5.2. Организация транспортного соединения

Обмен сообщениями Hello приводит к организации Hello-смежности на LSR1, которая служит для связывания канала L с пространствами меток LSR1:a и LSR2:b.

  1. Если у LSR1 еще нет сеанса LDP для обмена пространствами меток LSR1:a и LSR2:b, он пытается организовать соединение TCP для новой LDP-сессии с LSR2.LSR1 определяет транспортные адреса, которые будут использоваться на его стороне (A1) и на стороне LSR2 (A2) для соединения TCP. Адрес A1 определяется следующим образом:
    1. если LSR1 использует необязательный объект Transport Address (TLV) в сообщениях Hello, передаваемых LSR2 для анонсирования адреса, A1 будет адресом, который LSR1 анонсирует в этом необязательном объекте;
    2. если LSR1 не использует объект Transport Address, A1 будет адресом отправителя, используемым в сообщениях Hello для LSR2.

    Адрес A2 определяется похожим способом:

    1. если LSR2 использует необязательный объект Transport Address, A2 будет адресом, который LSR2 анонсирует в этом объекте;
    2. если LSR2 не использует объект Transport Address, A2 будет адресом отправителя, используемым в сообщениях Hello от LSR2.
  1. LSR1 определяет свою роль (активный или пассивный) в организуемой сессии, путем сравнения адресов A1 и A2, как целых чисел без знака. Если A1 > A2, LSR1 будет играть активную роль, в ином случае — пассивную.Процедура сравнения беззнаковых целых чисел A1 и A2 выполняется следующим образом:
    • Если адреса A1 и A2 относятся к разным семействам, они являются несравнимыми и сессия не создается.
    • Пусть U1 будет абстрактным целым числом без знака, которое получается в результате трактовки A1, как последовательности байтов, в которой первый байт адреса, указанный в сообщении, является старшим, а последний байт адреса в сообщении — младшим.U2 получается из адреса A2 таким же способом.
    • Сравниваются значения U1 и U2. Если U1 > U2, то A1 > A2; если U1 < U2, то A1 < A2.
  1. Если LSR1 является активным, он пытается инициировать соединение TCP через стандартный порт LDP по адресу A2. Если LSR1 является пассивным, он ждет вызова от LSR2 для организации соединения TCP через стандартный порт LDP.

Отметим, что маршрутизатор LSR при передаче сообщения Hello выбирает транспортный адрес для своей стороны сеансового соединения и использует сообщение Hello для анонсирования этого адреса (явно в необязательном параметре Transport Address TLV или неявно в качестве адреса отправителя сообщения Hello).

LSR должен задавать один и тот же транспортный адрес во всех сообщениях Hello, анонсирующих одно пространство меток. Это обеспечивает гарантию того, что два LSR, связанные множеством отношений Hello-смежности и использующие одни и те же пространства меток, будут играть одинаковую роль (активный-пассивный) во всех отношениях смежности.

2.5.3. Инициализация сессии

После того, как LSR1 и LSR2 организовали транспортное соединение, они согласуют параметры сессии путем обмена сообщениями LDP Initialization. Согласуемые параметры включают версию протокола LDP, метод распространения меток, значения таймеров, диапазоны VPI/VCI13 для меток, управляемых ATM, диапазоны DLCI14 для меток, управляемых Frame Relay и т. п.

Согласование завершает процесс организации сессии LDP между LSR1 и LSR2 для анонсирования пространств меток LSR1:a и LSR2:b.

Ниже описана процедура инициализации с точки зрения маршрутизатора LSR1.

Если LSR1 играет активную роль, он после организации соединения инициирует согласование параметров сессии путем передачи сообщения Initialization маршрутизатору LSR2. Если LSR1 является пассивным, он ждет, пока LSR2 инициирует согласование параметров сессии.

В общем случае при наличии между LSR1 и LSR2 множества соединений и анонсирования каждым маршрутизатором множества пространств меток, пассивный маршрутизатор LSR не может знать, какое из пространств меток анонсировать через вновь созданное соединение TCP, пока не будет получено сообщение LDP Initialization. Это сообщение содержит значения LDP Identifier для пространств меток передающей (активный LSR) и приемной (пассивный LSR) стороны.

В ожидании сообщения Initialization от партнера пассивный маршрутизатор LSR может сопоставить пространство меток, которое будет анонсироваться партнером (определяется значением LDP Identifier в заголовке PDU15 сообщения Initialization) с Hello-смежностью, созданной при обмене сообщениями Hello.

  1. LSR1 играет пассивную роль:
    1. При получении сообщения Initialization маршрутизатор LSR1 пытается сопоставить LDP Identifier из PDU принятого сообщения со смежностью Hello.
    2. Если соответствие найдено, оно будет определять пространство меток для этой сессии.После этого LSR1 проверяет приемлемость предложенных параметров сессии. Если параметры устраивают, LSR1 передает ответное сообщение Initialization с желаемыми параметрами и сообщение KeepAlive, показывающее приемлемость предложенных LSR2 параметров. Если параметры не подходят, LSR1 передает сообщение Session Rejected/Parameters Error Notification16 и закрывает соединение TCP.
    3. Если LSR1 не может найти соответствующей Hello-смежности, он передает сообщение Session Rejected/No Hello Error Notification17 и закрывает соединение TCP.
    4. Если LSR1 получает сообщение KeepAlive в ответ на свое сообщение Initialization, сессия считается открытой с точки зрения LSR1.
    5. Если LSR1 получает сообщение Error Notification, это говорит о том, LSR2 отказался от предложенной сессии, и LSR1 закрывает соединение TCP.
  1. LSR1 играет активную роль:
    1. Если LSR1 получает сообщение Error Notification, это говорит о том, LSR2 отказался от предложенной сессии, и LSR1 закрывает соединение TCP.
    2. При получении сообщения Initialization маршрутизатор LSR1 проверяет приемлемость предложенных параметров сессии. Если параметры устраивают, LSR1 передает сообщение KeepAlive. Если параметры не подходят, LSR1 передает сообщение Session Rejected/Parameters Error Notification и закрывает соединение.
    3. Если LSR1 получает сообщение KeepAlive, это говорит о том, LSR2 принял предложенные параметры сессии.
    4. Если LSR1 получает сообщение Initialization о приемлемости предложенных параметров и сообщение KeepAlive, сессия считается открытой с точки зрения LSR1.Пока сессия LDP не открыта, никакие сообщения, за исключением упомянутых выше, не могут передаваться и правила обработки бита U в сообщениях LDP не могут меняться. При получении любого сообщения, кроме перечисленных выше, в ответ должно быть передано сообщение Shutdown и транспортное соединение должно быть закрыто.

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

LSR должны экспоненциально снижать частоту попыток организации сессии в ситуациях, когда их сообщения Initialization отвергаются с помощью NAK18. Рекомендуется также, чтобы LSR при обнаружении такой ситуации предпринимал действия по уведомлению оператора.

Попытка повторной организации сессии после отвергнутого (NAK) сообщения Initialization должна предприниматься не ранее, чем через 15 секунд, а для последующих попыток задержка должна расти с максимальным значением задержки не менее 2 минут. Конкретным действием по организации сессии, которое должно задерживаться, является организация транспортного соединения активным маршрутизатором LSR.

Заторможенная последовательность Initialization NAK может не прекратиться, пока оператор не изменит конфигурацию одного из LSR. После внесения требуемых изменений больше не нужно тормозить последующие попытки организации сессии (до получения Initialization NAK).

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

2.5.4. Инициализация машины состояний

Для описания процесса согласования сессии LDP удобно использовать модель машины состояний. Определим для машины состояний LDP пять возможных состояний и представим поведение этой машины в форме таблицы и диаграммы переходов. Отметим, что сообщение Shutdown реализуется в форме сообщения Notification, со значением Status TLV, показывающим критическую ошибку.

Таблица состояний при инициализации сеанса

Состояние

Событие

Новое состояние

NON EXISTENT

Организация соединения TCP

INITIALIZED

INITIALIZED

Передача сообщения Initialization (активный)

OPENSENT

Получение приемлемого сообщения Initialization (пассивный)

Действие: Передача сообщений Initialization и KeepAlive

OPENREC

Прием любого другого сообщения LDP

Действие: Передача сообщения Error Notification (NAK) и разрыв транспортного соединения

NON EXISTENT

OPENREC

Прием сообщения KeepAlive

OPERATIONAL

Прием любого другого сообщения LDP

Действие: Передача сообщения Error Notification (NAK) и разрыв транспортного соединения

NON EXISTENT

OPENSENT

Получение приемлемого сообщения Initialization

Действие: Передача сообщения KeepAlive

OPENREC

Прием любого другого сообщения LDP

Действие: Передача сообщения Error Notification (NAK) и разрыв транспортного соединения

NON EXISTENT

OPERATIONAL

Прием сообщения Shutdown

Действие: Передача сообщения Shutdown и разрыв транспортного соединения

NON EXISTENT

Прием любого другого сообщения LDP

OPERATIONAL

Таймаут

Действие: Передача сообщения Shutdown и разрыв транспортного соединения

NON EXISTENT

                           +------------+
                           |            |
             +------------>|NON EXISTENT|<--------------------+
             |             |            |                     |
             |             +------------+                     |
             | Сеансовое      |    ^                          |
             |   соединение   |    |                          |
             |   организовано |    | Прием любого сообщ. LDP, |
             |                V    | кроме Init или таймаут   |
             |            +-----------+                       |
Прием другого|            |           |                       |
сообщения или|            |INITIALIZED|                       |
   таймаут / |        +---|           |-+                     |
Передача NAK |        |   +-----------+ |                     |
             |        |   (пассивный)   | (активный)          |
             |        | Прием подходящ. | Передача сообщения  |
             |        | сооб. Init /    | Init                |
             |        | Передача Init   |                     |
             |        | Перед. KeepAlive|                     |
             |        V                 V                     |
             |   +-------+        +--------+                  |
             |   |       |        |        |                  |
             +---|OPENREC|        |OPENSENT|----------------->|
             +---|       |        |        | Прием другого    |
             |   +-------+        +--------+ сооб. или таймаут|
Прием        |        ^                |     Tx NAK msg       |
KeepAlive    |        |                |                      |
             |        |                | Прием подходящего    |
             |        |                | сообщения Init /     |
             |        +----------------+ Передача KeepAlive   |
             |                                                |
             |      +-----------+                             |
             +----->|           |                             |
                    |OPERATIONAL|                             |
                    |           |---------------------------->+
                    +-----------+    Прием сообщения Shutdown
          Прочие        |   ^            или Timeout /
          сообщения LDP |   |       Передача сообщения Shutdown
                        |   |
                        +---+

Диаграмма состояний при инициализации сессии LDP

2.5.5. Поддержка Hello-смежности

Сессия LDP с партнером включает одно или множество отношений Hello-смежности. Множество отношений смежности присутствует в тех случаях, когда пара LSR соединена множеством каналов с общими пространствами меток (например, множество соединений PPP между парой маршрутизаторов). В такой ситуации сообщения Hello, передаваемые LSR для каждого из каналов, содержат одинаковые значения LDP Identifier.

LDP включает механизмы мониторинга сессий LDP и Hello-смежности.

LDP использует обычные сообщения LDP Discovery Hello для индикации намерения партнера использовать пространство меток, указанное в сообщении Hello. LSR поддерживает таймер удержания для каждой Hello-смежности, значение которого сбрасывается при получении нового сообщения Hello, соответствующего данной смежности. Если отсчет таймера завершается до получения соответствующего сообщения Hello от партнера, LDP считает, что партнер более не желает коммутировать по меткам с использованием данного пространства меток для этого канала (адресата в случае Targeted Hello) или канал разорван. После этого LSR удаляет отношение Hello-смежности. При удалении последнего отношения Hello-смежности для сессии LDP маршрутизатор LSR разрывает сессию LDP, передавая сообщение Notification и закрывая транспортное соединение.

2.5.6. Поддержка сессий LDP

LDP включает механизмы мониторинга целостности сессии LDP.

LDP использует получение обычных LDP PDU в транспортном соединении сессии для мониторинга целостности сеанса. LSR поддерживает для каждой сессии с партнером таймер KeepAlive, который сбрасывается при получении LDP PDU в этой сессии. Если отсчет таймера KeepAlive завершается до получения от партнера LDP PDU, маршрутизатор LSR считает, что транспортное соединение не работает должным образом или на стороне партнера возник отказ в работе, после чего разрывает сессию LDP путем закрытия транспортного соединения.

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

LSR может принять решение о разрыве сессии LDP со своим партнером в любой момент. В этом случае партнеру просто передается сообщение Shutdown.

2.6. Распространение меток и управление ими

Архитектура MPLS [RFC3031] позволяет LSR распространять информацию о связывании меток с классом FEC в ответ на явный запрос со стороны другого LSR. Этот процесс называется нисходящим распространением меток по запросу19. Можно также распространять информацию о связывании меток маршрутизаторам LSR, которые явно не запрашивали ее. В [RFC3031] такой метод называется незапрошенным нисходящим распространением20.

Оба метода распространения меток могут одновременно использоваться в одной сети. Однако для любой конкретной сессии LDP каждый LSR должен знать используемый партнером метод распространения меток, чтобы избежать ситуаций, когда один партнер использует Downstream Unsolicited, предполагая, что другой поступает так же (см. параграф 3.5.7.1.3. Нисходящее анонсирование меток по запросам).

2.6.1. Режим управления LSP

Поведение на начальном этапе организации LSP определяется выбором независимого21 или согласованного22 режима управления LSP. LSR может поддерживать оба типа управления (параметр конфигурации).

2.6.1.1. Независимое управление

При независимом управлении LSP каждый LSR может анонсировать отображение меток своим соседям в любой желаемый момент. Например, при работе в режиме Downstream on Demand с независимым управлением LSR может незамедлительно ответить на запрос об отображении меток без ожидания такого отображения от следующего интервала маршрутизации (next hop). При независимом управлении в режиме Downstream Unsolicited маршрутизатор LSR может анонсировать отображение меток для FEC своим соседям, как только он будет готов к коммутации по меткам для данного FEC.

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

2.6.1.2. Согласованное управление

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

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

  1. FEC указывает непосредственно на этот LSR (включая непосредственно подключенные к нему интерфейсы);
  2. маршрутизатор следующего интервала для этого FEC находится за пределами сети с коммутацией по меткам;
  3. элементы FEC достижимы при пересечении границы домена маршрутизации (другая область OSPF, другая автономная система [RFC2328] [RFC4271]).

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

2.6.2. Режим удержания меток

Архитектура MPLS [RFC3031] вводит понятие режима удержания меток. Удержанием называют поддержку LSR привязок меток для FEC, полученных от соседа, который не является следующим интервалом для данного FEC.

2.6.2.1. Консервативное удержание меток

В режиме анонсирования Downstream Unsolicited анонсы отображения меток для всех маршрутов могут быть получены от всех партнерских LSR. При использовании консервативного удержания меток23, анонсируемые привязки меток удерживаются только в тех случаях, когда они будут применяться для пересылки пакетов (т. е. при получении привязок от маршрутизатора, который является корректным следующим интервалом в соответствии с таблицей маршрутизации). При работа в режиме Downstream on Demand маршрутизатор LSR будет запрашивать отображения меток только у маршрутизаторов LSR следующего интервала в соответствии с его таблицей маршрутизации. Поскольку режим Downstream on Demand используется прежде всего для сохранения меток (например, в коммутаторах ATM с ограниченным пространством кросс-соединений), с этим режимом обычно применяется консервативное удержание меток.

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

2.6.2.2. Либеральное удержание меток

В режиме анонсирования Downstream Unsolicited анонсы отображения меток для всех маршрутов могут быть получены от всех LDP-партнеров. При либеральном удержании каждое отображение меток, полученное от партнерского LSR, сохраняется (удерживается), независимо от того, является ли этот LSR следующим интервалом для анонсируемого отображения. В режиме анонсирования Downstream on Demand с либеральным удержанием меток LSR может запрашивать отображения меток для всех известных префиксов от всех партнерских LSR. Отметим, однако, что режим Downstream on Demand обычно используется устройствами LSR типа коммутаторов ATM, для которых рекомендуется применять консервативное удержание.

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

2.6.3. Режим анонсирования меток

Каждый интерфейс LSR настраивается для работы в режиме анонсирования Downstream Unsolicited или Downstream on Demand. Маршрутизаторы LSR обмениваются информацией о режимах анонсирования в процессе инициализации. Основным различием между нисходящим анонсированием по запросам и без запросов является то, какой из LSR принимает на себя ответственность за инициирование запроса и анонсирования отображений.

2.7. Идентификаторы LDP и адреса Next Hop

LSR поддерживает полученные от других маршрутизаторов метки в базе данных LIB24. При работе в режиме Downstream Unsolicited запись LIB для адресного префикса связывает с префиксом набор пар (идентификатор LDP, метка) — одна пара для каждого партнера, анонсирующего метку для данного префикса.

При изменении следующего интервала для префикса LSR должен отыскать метку, анонсируемую новым маршрутизатором следующего интервала, в своей базе LIB для использования этой метки при пересылке. Для поиска метки LSR должен иметь возможность отображения адреса следующего интервала для адресного префикса на идентификатор LDP.

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

Для обеспечения возможности отображения между идентификатором LDP и адресом партнера маршрутизаторы LSR анонсируют свои адреса с использованием сообщений Address и Withdraw Address.

LSR передает сообщение Address для анонсирования партнеру своего адреса, а для отзыва ранее анонсированного адреса LSR передает сообщение Withdraw Address.

2.8. Детектирование петель

Детектирование петель25 является конфигурационной опцией, которая обеспечивает механизм нахождения замкнутых LSP и предотвращения зацикливания сообщений Label Request в присутствии LSR без поддержки слияния меток.

Механизм детектирования петель использует параметры Path Vector и Hop Count (TLV), передаваемые в сообщениях Label Request и Label Mapping. Механизм основан на рассмотренных ниже базовых свойствах этих TLV.

  • Path Vector TLV содержит список LSR, через которые прошло содержащее параметр сообщение. LSR идентифицируются в списке Path Vector своими уникальными идентификаторами (LSR Id), которые представляют собой 4 первых октета значения LDP Identifier. Когда LSR распространяет26 сообщение, содержащее Path Vector TLV, он добавляет свое значение LSR Id в список Path Vector. Маршрутизатор LSR, получивший сообщение со значением Path Vector, содержащим LSR Id этого маршрутизатора, делает вывод о том, что сообщение прошло по замкнутому пути (петле). Протокол LDP поддерживает максимально допустимую длину Path Vector — маршрутизатор LSR, обнаруживший, что значение Path Vector достигло предельной длины рассматривает этот факт, как обнаружение петли.
  • Hop Count TLV содержит счетчик маршрутизаторов LSR, через которые прошло данное сообщение. Когда LSR распространяет сообщение с Hop Count TLV, он увеличивает значение счетчика на 1. LSR, который обнаруживает, что значение Hop Count достигло заданного в конфигурации максимума, рассматривает этот факт, как обнаружение петли. По соглашению нулевое значение счетчика интерпретируется, как неизвестное число интервалов. Инкрементирование неизвестного числа интервалов ведет к тому, что значение сохраняется неизвестным (0)27.

Процедуры детектирования петель LDP описаны в последующих параграфах. В этих (и только в этих) параграфах термин «должен» трактуется, как «должен, если включено детектирование петель». Эти параграфы описывают сообщения, которые должны переносить параметры Path Vector и Hop Count. Отметим, что Hop Count TLV и процедуры для работы с этим параметром используются без Path Vector TLV в тех случаях, когда детектирование петель не задано в конфигурации (см. [RFC3035] и [RFC3034]).

2.8.1. Сообщение Label Request

Использование Path Vector TLV и Hop Count TLV предотвращают «зацикливание» сообщений Label Request в средах, включающих LSR без поддержки слияния меток.

Правила использования Hop Count TLV в сообщениях Label Request LSR-маршрутизатором R со включенным детектированием петель имеют следующий вид:

  • сообщение Label Request должно включать Hop Count TLV;
  • если R передает сообщение Label Request потому, что он является входом FEC, это сообщение должно включать Hop Count TLV со значением счетчика 1;
  • если R передает сообщение Label Request в результате получения Label Request от восходящего LSR и этот запрос содержит Hop Count TLV, маршрутизатор R должен увеличить значение счетчика на 1 и передать полученное значение счетчика в Hop Count TLV следующему интервалу пути доставки сообщения Label Request.

Правила использования Path Vector TLV в сообщениях Label Request LSR-маршрутизатором R со включенным детектированием петель имеют следующий вид:

  • если R передает сообщение Label Request потому, что он является входом FEC, и R не поддерживает слияния меток, это сообщение должно включать Path Vector TLV размером 1, содержащее LSR Id данного маршрутизатора;
  • если R передает сообщение Label Request в результате получения Label Request от восходящего LSR и этот запрос содержит Path Vector TLV или R не поддерживает слияния меток:

R должен добавить свое значение LSR Id в Path Vector и должен передать полученный в результате параметр Path Vector на следующий интервал доставки сообщения Label Request. Если сообщение Label Request не содержит Path Vector TLV, маршрутизатор R должен включить Path Vector TLV размером 1 со своим идентификатором LSR Id.

Отметим, что в случаях, когда R получает сообщение Label Request для некого FEC и уже отправил сообщение Label Request для данного FEC на следующий интервал, но еще не получил на это сообщение отклика и желает объединить недавно полученное сообщение Label Request со ждущим ответа запросом метки, маршрутизатор R не распространяет недавно полученное сообщение Label Request на следующий интервал.

Если R получает сообщение Label Request от следующего интервала и в этом сообщении имеется Hop Count TLV со значением счетчика, превышающим заданный максимум, Path Vector TLV, включающий LSR Id данного маршрутизатора, или превышающий заданный максимальный размер, R делает вывод о том, что данное сообщение Label Request оказалось в петле.

Когда R детектирует петлю, он должен передать сообщение Loop Detected Notification отправителю сообщения Label Request, отбросив последнее.

2.8.2. Сообщение Label Mapping

Использование Path Vector TLV и Hop Count TLV в сообщениях Label Mapping обеспечивает механизм детектирования и устранения петель в LSP. Когда LSR получает сообщение Label Mapping от маршрутизатора следующего интервала, это сообщение распространяется в восходящем направлении, как описано ниже, пока не будет достигнут входной LSR или обнаружена петля.

Правила использования Hop Count TLV в сообщениях Label Mapping, передаваемых LSR-маршрутизатором R при включенном режиме детектирования петель, имеют вид:

  • R должен включать Hop Count TLV;
  • если R является выходным, значение счетчика должно быть равным 1;
  • если сообщение Label Mapping передается для распространения сообщения Label Mapping, полученного от следующего интервала, восходящему партнеру, значение счетчика должно устанавливаться как следующим образом:
  • если R является членом краевого набора LSR домена, в котором маршрутизаторы LSR не уменьшают значение TTL (например, домен ATM LSR или Frame Relay LSR) и восходящий партнер находится в этом домене, R должен сбросить значение счетчика в 1 прежде, чем распространять сообщение;
  • в остальных случаях R должен увеличить значение счетчика на 1 перед дальнейшим распространением сообщения;
  • если сообщение Label Mapping передается не для распространения Label Mapping, значение счетчика должно быть результатом увеличения на 1 текущего, известного R, значения счетчика интервалов, полученного из предыдущих сообщений Label Mapping. Отметим, что это значение счетчика не будет известно, если R не получал сообщений Label Mapping от следующего интервала.

Любое сообщение Label Mapping может включать Path Vector TLV. Правила обязательного использования Path Vector TLV в сообщениях Label Mapping, передаваемых LSR R при включенном детектировании петель, имеют следующий вид:

  • если R является выходным, в сообщение Label Mapping не должно включаться Path Vector TLV;
  • если R передает сообщение Label Mapping для распространения сообщения Label Mapping, полученного от партнера, который является следующим интервалом в восходящем направлении:
  • если R поддерживает слияние меток и не отправлял ранее сообщений Label Mapping восходящему партнеру, он должен включить в сообщение Path Vector TLV;
  • если полученное сообщение содержит неизвестное значение счетчика интервалов, R должен включить в сообщение Path Vector TLV;
  • если R ранее передавал восходящему партнеру сообщение Label Mapping, он должен включить Path Vector TLV; если полученное сообщение говорит об увеличении счетчика интервалов LSP, неизвестное значение счетчика заменяется известным, а известное — неизвестным.

Если в соответствии с приведенными выше правилами R должен включать Path Vector TLV в сообщение Label Mapping значение параметра определяется следующим образом:

  • Если полученное сообщение Label Mapping включает Path Vector, поле Path Vector, передаваемое в восходящем направлении, должно быть результатом добавления LSR Id маршрутизатора R к полученному полю Path Vector.
  • Если в полученном сообщении нет поля Path Vector, передаваемое в восходящем направлении поле Path Vector должно иметь размер 1 и содержать значение LSR Id маршрутизатора R.
  • Если сообщение Label Mapping передается не для распространения полученного сообщения Label Mapping в восходящем направлении, это сообщение должно включать поле Path Vector размера 1, содержащее LSR Id маршрутизатора R.Если R получает от следующего интервала сообщение Label Mapping со значением Hop Count TLV, которое превышает заданный конфигурацией максимум, или полем Path Vector TLV, содержащим его значение LSR Id или превосходящим допустимый размер, R делает вывод о наличии петли в соответствующем LSP.Когда маршрутизатор R детектирует петлю, он должен прекратить использование метки для пересылки, отбросить сообщение Label Mapping и сигнализировать о состоянии Loop Detected отправителю сообщения Label Mapping.

2.8.3. Обсуждение

Если в домене MPLS желательно использовать детектирование петель, эту функцию следует включить на всех LSR домена MPLS, поскольку в противном случае механизм Loop Detection не будет работать корректно и может давать ложные срабатывания или пропускать имеющиеся петли.

Для LSR, настроенных на поддержку Loop Detection, не предполагается сохранение полей Path Vector, как части состояния LSP.

Отметим, что в сети, где используются только LSR без поддержки слияния меток, поля Path Vector передаются в нисходящем направлении от входа к выходу и не передаются в восходящем направлении. Даже при поддержке слияния меток поля Path Vector не требуется передавать в восходящем направлении вдоль путей LSP, о которых известно, что они достигают выхода. Когда LSR сталкивается с изменением следующего интервала, ему нужно передавать Path Vector в восходящем направлении лишь в тех случаях, когда он не может сказать на основании счетчика интервалов, что изменение следующего интервала не приводит к возникновению петли.

В случае согласованного распространения меток сообщения Label Mapping распространяются от выхода в направлении входа, естественным образом создавая Path Vector вдоль пути. При независимом распространении меток LSR может создавать сообщение Label Mapping для FEC до получения Label Mapping от нисходящего партнера для данного FEC. В этом случае последующие сообщения Label Mapping для FEC, полученные от нисходящего партнера, трактуются, как обновление атрибутов LSP, и в восходящем направлении должно передаваться сообщение Label Mapping. В соответствии с этим рекомендуется настраивать детектирование петель в комбинации с согласованным распространением меток, чтобы минимизировать число сообщений Label Mapping об обновлениях.

2.9. Аутентичность и целостность сообщений LDP

В этом разделе описан механизм защиты от подставных сегментов TCP в потоке данных сеансов LDP. Использование этого механизма должно поддерживаться в форме конфигурационной опции.

Механизм защиты базируется на использовании цифровых подписей (сигнатур) TCP MD5, описанных в [RFC2385] для использования в BGP [RFC4271]. Спецификация функции хэширования MD5 приведена в [RFC1321]. С точки зрения завершенности стандарта данный документ опирается на [RFC2385] точно так же, как это делается в [RFC4271]. Объяснение этого дано в [RFC4278].

2.9.1. Сигнатуры TCP MD5

Приведенные ниже фрагменты28 [RFC2385] очерчивают свойства защиты, обеспечиваемой за счет использования сигнатур TCP MD5.

Замечание IESG

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

Тезисы

В этом документе описывается расширение TCP для повышения уровня безопасности протокола BGP. Документ определяет новую опцию TCP для передачи цифровой подписи (digest) MD5 [RFC1321] в сегментах TCP. Такая подпись служит сигнатурой сегмента, включающей информацию, известную только конечным точкам соединения. Поскольку протокол BGP использует транспорт TCP, применение этой опции описанным в документе способом существенно снижает уровень риска для некоторых типов атак на BGP.

Введение

Основным мотивом добавления этой опции является стремление обеспечить протоколу BGP средства самозащиты против вставки обманных сегментов TCP в поток данных через соединение. Особую важность имеют случаи сброса (reset) соединений TCP.

Для обмана соединения в случае использования описанной здесь схемы атакующему нужно не только предсказать порядковые номера TCP, но и узнать пароль, включенный в цифровую подпись MD5. Этот пароль не передается в потоке соединения и реальная форма пароля определяется приложением. Пароль даже может быть сменен во время работы соединения, если эта замена согласована обеими сторонами (отметим, что для некоторых реализаций TCP смена пароля может приводить к возникновению проблем при повторе передачи).

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

MD5 в качестве алгоритма хэширования

К моменту выпуска первого варианта этого документа (он имел другое название) в алгоритме MD5 была обнаружена уязвимость для атак с целью поиска коллизий [Dobb] и возникли сомнения в его достаточной надежности для предлагаемого здесь использования.

В данном документе по-прежнему указывается алгоритм MD5, однако, в силу того, что опция уже используется на практике, в нее не включено поле типа алгоритма, чтобы впоследствии можно было заменить алгоритм без смены номера опции. В исходном документе также не было задано поле типа, поскольку оно потребовало бы по крайней мере 1 байта и полный размер опции стал бы не менее 19 байтов (которые могли бы дополняться до 20 реализациями TCP), что могло бы оказаться неприемлемым с учетом ограниченности размера заголовка.

Это не мешает разработке аналогичных опций с использованием другого алгоритма хэширования (например, SHA-1). Поскольку большинство реализаций дополняют 18 байтов опции до 20, не возникает проблем с определением новой опции, включающей поле типа алгоритма.

Однако рассмотрение этих вопросов требует подготовки отдельного документа.

Конец цитаты из [RFC2385].

2.9.2. Использование опции TCP MD5 Signature в LDP

LDP использует опцию TCP MD5 Signature следующим образом:

  • Опция MD5 Signature используется для TCP-соединений LDP, как конфигурационная опция LSR.
  • LSR, использующий MD5 Signature, настраивается с паролем (разделяемый секрет) для каждого потенциального партнера LDP.
  • LSR применяет алгоритм MD5 в соответствии с [RFC2385] для расчета цифровых подписей MD5 сегментов TCP, передаваемых партнеру. При расчете цифровой подписи используется пароль партнера и сегмент TCP.
  • Когда LSR получает сегмент TCP с сигнатурой MD5, он заново рассчитывает сигнатуру MD5 (используя свою копию пароля) и сравнивает полученное значение с принятой сигнатурой. При наличии расхождений сегмент отбрасывается без уведомления отправителя.
  • LSR игнорирует сообщения LDP Hello от любых LSR, для которых ему не известен пароль. Это позволяет LSR организовывать TCP-соединения LDP только с маршрутизаторами LSR, для которых пароль задан.

2.10. Распространение меток для LSP с явной маршрутизацией

Предполагается, что построение трафика29 [RFC2702] будет одним из важных применений MPLS. Поддержка построения трафика в MPLS использует явно маршрутизируемые LSP, которые не следуют нормально (поэтапно) маршрутизируемым путям, определяемым протоколами маршрутизации по адресу получателя. CR-LDP [CRLDP] определяет расширение LDP для использования протокола LDP с целью организации явно маршрутизируемых LSP.

3. Спецификация протокола

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

Обмен сообщениями LDP реализуется путем передачи модулей данных протокола (LDP PDU30) через TCP-соединения сеансов LDP.

Каждый LDP PDU может содержать одно или множество сообщений LDP. Отметим, что сообщения в LDP PDU могут быть не связаны между собой. Например, в одном PDU может содержаться сообщение, анонсирующее связывание метки с FEC для нескольких классов FEC, сообщение, запрашивающее связки с метками для некоторых других FEC, и сообщение Notification с информацией о том или ином событии.

3.1. LDP PDU

Каждый LDP PDU имеет заголовок LDP, за которым следует одно или множество сообщений LDP.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Version                      |         PDU Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         LDP Identifier                        |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Заголовок LDP включает поля:

Version — версия

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

PDU Length — размер PDU

Двухоктетное целое число, задающее общий размер PDU в октетах без учета полей Version и PDU Length.

Максимально допустимое значение PDU Length согласуется при инициализации сеанса LDP. До завершения инициализации размер ограничен значением 4096 байта.

LDP Identifier — идентификатор PDU

Шестиоктетное поле, уникально идентифицирующее пространство меток передающего LSR, к которому этот PDU имеет отношение. Первые 4 октета идентифицируют LSR и должны быть уникальными в глобальном масштабе. В качестве этой части идентификатора следует использовать 32-битовый идентификатор маршрутизатора (Router Id), присвоенный LSR. Эта часть идентификатора используется также для детектирования петель. Два оставшихся октета идентифицируют пространство меток в рамках LSR. Для пространства меток масштаба платформы следует использовать нулевое значение этих октетов.

Отметим, что для первого октета LDP PDU не требуется выравнивание по границе.

3.2. Процедуры LDP

LDP определяет сообщения, TLV и процедуры для нескольких типов действий:

  • обнаружение партнеров;
  • управление сессией;
  • распространение меток;
  • уведомления об ошибках и другая информация.

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

Процедуры распространения меток сложны и их достаточно трудно описать полно, последовательно и однозначно, как набор спецификаций отдельных сообщений и TLV.

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

3.3. Представление TLV

LDP использует формат TLV для представления информации, передаваемой в сообщениях LDP.

LDP TLV кодируется, как двухоктетное поле, в котором 14 битов служат для задания типа и 2 бита задают поведение LSR при получении неизвестного типа, далее следует 2-октетное поле размера и поле Value переменной длины.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F|        Type               |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                             Value                             |
   ~                                                               ~
   |                                                               |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

U-bit

Флаг обработки неизвестных TLV. При получении неизвестного TLV со сброшенным (0) битом U должно возвращаться уведомление инициатору сообщения и все сообщение должно игнорироваться. Если U=1, неизвестный TLV должен игнорироваться, а остальная часть сообщения обрабатывается, как обычно. В последующих параграфах, определяющих TLV, задается значение U-бита.

F-bit

Флаг пересылки неизвестных TLV. Этот флаг имеет значение только для сообщений с установленным флагом U, содержащих неизвестный TLV. Если F=0, неизвестный TLV не пересылается с содержащим его сообщением, а при установленном флаге (F=1) неизвестный TLV пересылается с содержащим его сообщением. В последующих параграфах, определяющих TLV, указывается значение бита F. При установке обоих флагов U и F TLV может распространяться через узлы, не понимающие данный TLV, как неинтерпретируемые данные.

Type — тип

Определяет интерпретацию поля Value.

Length — размер

Указывает размер поля Value в октетах.

Value — значение

Строка размером Length октетов, представляющая информацию, которая интерпретируется в соответствии со значением поля Type.

Отметим, что для первого октета TLV не предъявляется требований по выравниванию.

Отметим также, что поле Value само может содержать TLV (т. е., TLV могут быть вложенными).

Схема представления TLV является весьма общей. В принципе все, что появляется в LDP PDU, можно представить в форме TLV. Однако данная спецификация не применяет схему TLV во всех случаях. Эта схема не используется там, где общность не требуется, а применение этой схемы привело бы к нерациональному расходу пространства. Это обычно возникает в ситуациях, когда тип значения известен заранее (например, по его положению в сообщении или «объемлющем» TLV), а размер значения фиксирован или легко определяется из самого значения.

Некоторые TLV, определенные для LDP, похожи друг на друга. Например, имеются Generic Label TLV, ATM Label TLV, и Frame Relay TLV (см. параграфы 3.4.2.1. TLV меток общего назначения, 3.4.2.2. TLV меток ATM , 3.4.2.3. TLV для меток Frame Relay ).

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

Спецификация выделяет значения типов для соответствующих TLV (таких, как TLV меток) из непрерывного пространства 16-битовых номеров типа TLV.

В параграфе 3.8. Список TLV перечислены TLV, определенные для этой версии протокола, и указаны параграфы данного документа, в которых описаны соответствующие TLV.

3.4. Представление TLV для параметров общего назначения

Существует несколько параметров, используемых множеством сообщений LDP. В этом параграфе описано представление таких параметров в форме TLV.

3.4.1. FEC TLV

Метки привязываются к классам эквивалентной пересылки (FEC31). FEC представляет собой список из одного или множества элементов FEC. FEC TLV представляет компоненты FEC.

Формат FEC TLV показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0| FEC (0x0100)              |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        FEC Element 1                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        FEC Element n                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

FEC Element 1 — FEC Element n

Имеется несколько типов элементов FEC (см. параграф 2.1. Классы FEC). Представление элементов FEC зависит от их типа.

Значение FEC Element представляется, как 1-октетное поле, задающее тип элемента, и поле переменного размера, содержащее зависимое от типа значение элемента. Отметим, что, несмотря на зависимость кодирования элементов FEC от типа, их представление является одним из случаев, когда стандартное кодирование LDP TLV не используется.

Кодирование значений FEC Element имеет вид:

Имя типа FEC Element Тип Значение
Wildcard 0x01 Нет значения (0 октетов), см. ниже.
Prefix 0x02 См. ниже.

Отметим, что данная версия LDP поддерживает использование множества FEC Element в одном FEC только для сообщений Label Mapping. Использование множества элементов FEC в сообщениях других типов не разрешается для этой версии и требует дальнейшего изучения.

Wildcard FEC Element

Для использования только в сообщениях Label Withdraw и Label Release. Показывает, что отзыв/освобождение будет применяться ко всем FEC, связанным с меткой в следующем TLV для метки. Этот элемент должен быть единственным элементом FEC в FEC TLV.

Prefix FEC Element

Представление Prefix FEC Element показано на рисунке.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Prefix (2)   |     Address Family            |     PreLen    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Prefix                                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Address Family

Двухоктетное поле, содержащее значение из числа ADDRESS FAMILY NUMBER, определенных в [ASSIGNED_AF], которое представляет семейство адресов для префикса в поле Prefix.

PreLen

Однооктетное целое число без знака, показывающее размер в битах следующего за ним адресного префикса. Нулевой размер указывает на префикс, который соответствует всем адресам (получатель, используемый по умолчанию). В этом случае поле Prefix содержит 0 октетов (пусто).

Prefix

Адресный префикс, кодируемый в соответствии со значением поля Address Family. Размер префикса в битах задается полем PreLen, для префикса используется дополнение нулями с целью выравнивания по границе байта.

3.4.1.1. Процедуры FEC

Если декодирующий FEC TLV маршрутизатор LSR встречает FEC Element с неподдерживаемым значением Address Family, ему следует остановить декодирование FEC TLV, прервать обработку сообщения, содержащего TLV, и передать уведомление Unsupported Address Family своему партнеру LDP для сигнализации ошибки.

Если встречается FEC Element, тип которого не удается декодировать, следует прекратить декодирование FEC TLV, прервать обработку сообщения, содержащего TLV, и передать уведомление Unknown FEC своему партнеру LDP для сигнализации ошибки.

3.4.2. TLV для меток

Label TLV используется для представления меток. Структуры Label TLV передаются в сообщениях, используемых для анонсирования, запроса, освобождения и отзыва отображений меток.

Существует несколько типов Label TLV, которые могут появляться в ситуациях, требующих использования Label TLV.

3.4.2.1. TLV меток общего назначения

LSR использует Generic Label TLV для представления меток, применяемых на каналах, где метки не зависят от технологии нижележащего уровня. Примерами таких каналов могут служить PPP и Ethernet.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0| Generic Label (0x0200)    |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Label                                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Label

20-битовое значение метки помещается в 4-октетное поле, как показано на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Label                             |                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Дополнительную информацию можно найти в [RFC3032].

3.4.2.2. TLV меток ATM

LSR используют ATM Label TLV для представления меток, применяемых на каналах ATM.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0| ATM Label (0x0201)        |         Length                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Res| V |          VPI          |         VCI                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Res

Это поле является резервным. При передаче должно устанавливаться нулевое значение, на приемной стороне поле должно игнорироваться.

V

Двухбитовый индикатор типа коммутации. Значение 00 говорит, что значимы оба значения VPI и VCI. Если V = 01, значимость имеет только VPI, при V = 10 — только VCI.

VPI

Идентификатор виртуального пути. Если значение VPI имеет размер менее 12 битов, его следует выравнивать по правому краю поля, дополняя слева нулями.

VCI

Идентификатор виртуального канала. Если значение VCI имеет размер менее 16 битов, его следует выравнивать по правому краю поля, а свободные биты слева должны устанавливаться в 0. Если флаг V задает коммутацию только по виртуальным путям, это поле должно игнорироваться получателем и устанавливаться в 0 отправителем.

3.4.2.3. TLV для меток Frame Relay

LSR используют Frame Relay Label TLV для представления меток, применяемых на каналах Frame Relay.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0| Frame Relay Label (0x0202)|       Length                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Reserved    |Len|                     DLCI                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Res

Это поле является резервным. При передаче должно устанавливаться нулевое значение, на приемной стороне поле должно игнорироваться.

Len

Это поле задает число битов идентификатора DLCI. Поддерживается два варианта значения поля:

0 = размер DLCI равен 10 битам;

2 = размер DLCI равен 23 битам.

Значения 1 и 3 являются резервными.

DLCI

Идентификатор соединения на канальном уровне.

10-битовые значения DLCI представляются, как показано на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0| Frame Relay Label (0x0202)|       Length                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Reserved    |Len|            0            |    10-bit DLCI    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Представление 23-битовых DLCI показано на рисунке ниже.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0| Frame Relay Label (0x0202)|       Length                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Reserved    |Len|              23-bit DLCI                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Дополнительную информацию можно найти в [RFC3034].

3.4.3. TLV для списка адресов

Структура Address List TLV появляется в сообщениях Address и Address Withdraw.

Формат TLV показан на рисунке, поля описаны ниже.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0| Address List (0x0101)     |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Address Family            |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   |                        Addresses                              |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Address Family

Двухоктетное поле, содержащее значение из списка ADDRESS FAMILY NUMBERS в документе [ASSIGNED_AF], которое указывает тип адреса в поле Addresses.

Addresses

Список адресов заданного полем Address Family типа. Представление адресов зависит от значения поля Address Family.

Представление адресов, определенное данной спецификацией, показано в таблице.

Address Family Представление адреса
IPv4 Все 4 октета адреса IPv4
IPv6 Все 16 октетов адреса IPv6

3.4.4. TLV для счетчика интервалов

Структура Hop Count TLV появляется в необязательном поле сообщений, передаваемых при организации LSP. Она служит для учета числа интервалов LSR на пути LSP при организации последнего.

Отметим, что процедуры организации LSP, проходящих через сети ATM и Frame Relay, требуют использования Hop Count TLV (см. [RFC3035] и [RFC3034]).

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0| Hop Count (0x0103)        |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     HC Value  |
   +-+-+-+-+-+-+-+-+

HC Value

Однооктетное целое число без знака, содержащее значение счетчика интервалов.

3.4.4.1. Процедуры подсчета интервалов

При организации LSP маршрутизатор R может получить сообщение Label Mapping или Label Request для LSP, которое содержит Hop Count TLV. В таком случае следует записать значение счетчика.

Если LSR R распространяет сообщение Label Mapping для LSP своему восходящему партнеру или сообщение Label Request — нисходящему для продолжения процедуры организации LSP, необходимо определять значение счетчика интервалов для включения в распространяемое сообщение, как показано ниже:

  • для сообщение Label Request маршрутизатор R должен увеличить значение счетчика на 1;
  • для сообщений Label Mapping маршрутизатор R определяет значение счетчика следующим образом:
    • если R является членом множества краевых LSR домена, в котором LSR не увеличивают значение TTL, и восходящий партнер входит в этот домен, маршрутизатор R должен сбросить значение счетчика в 1 перед дальнейшим распространением сообщения;
    • в остальных случаях R должен увеличить значение счетчика на 1.

Первому LSR в LSP (входной для сообщения Label Request, выходной для Label Mapping) следует установить для счетчика интервалов значение 1.

По договоренности, значение 0 говорит о неизвестном значении счетчика интервалов. В результате инкрементирования неизвестного значения счетчика оно сохраняется неизвестным (0).

Использование неизвестного значения счетчика существенно снижает объем сигнальной информации при использовании режима независимого управления. При создании нового LSP каждый LSR начинает с неизвестного значения счетчика. Добавление LSR с неизвестным значением счетчика приводит к тому, что значение счетчика сохраняется неизвестным. При добавлении в LSP выходного маршрутизатора LSR распространяет обновление значения счетчика в восходящем направлении с помощью сообщений Label Mapping.

Если не использовать неизвестное значение счетчика, то при каждом добавлении LSR в путь LSP потребуется распространять обновление значения счетчика в восходящем направлении, если новый LSR расположен ближе к выходу, чем остальные LSR. Эти обновления бесполезны, поскольку они не отражают значение счетчика на выходе пути.

С точки зрения входного узла неизвестное значение счетчика интервалов не говорит о том, что пакет, направленный в LSP будет попадать на выход. Это означает лишь, что обновление счетчика интервалов от выходного узла еще не достигло входного узла.

Если LSR получает сообщение с Hop Count TLV, он должен проверить значение счетчика интервалов, чтобы определить, не превосходит ли это значение допустимого конфигурацией максимума. Если значение счетчика превышает дозволенное, маршрутизатор должен сделать вывод о том, что сообщение прошло через петлю и передать его отправителю уведомление о наличии петли (Loop Detected).

Если включен режим Loop Detection, маршрутизатор LSR должен следовать процедурам, описанным в параграфе 2.8. Детектирование петель.

3.4.5. TLV для вектора пути

Path Vector TLV используется вместе с Hop Count TLV в сообщениях Label Request и Label Mapping для реализации необязательного механизма LDP Loop Detection (см. параграф 2.8. Детектирование петель). При его использовании в сообщениях Label Request записывается путь в форме списка LSR, через которые проходит запрос. Для сообщений Label Mapping записывается набор LSR, через которые проходит анонс метки для организации LSP. Формат структуры показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0| Path Vector (0x0104)      |        Length                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            LSR Id 1                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            LSR Id n                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

LSR Id

Список идентификаторов LSR, показывающий путь, по которому проходит сообщение. Каждое значение LSR Id в списке представляет собой 4 первых октета (router-id) идентификатора LDP для соответствующего LSR. Такая идентификация LSR обеспечивает однозначное распознавание маршрутизатора в пределах сети.

3.4.5.1. Процедуры Path Vector

Структура Path Vector TLV передается в сообщениях Label Mapping и Label Request при включенном режиме Loop Detection.

3.4.5.1.1. Path Vector в сообщении Label Request

В параграфе 2.8. Детектирование петель указаны ситуации, когда LSR должен включать Path Vector TLV в сообщения Label Request.

LSR, получивший Path Vector в сообщении Label Request, должен выполнить процедуры, описанные в параграфе 2.8. Детектирование петель.

Если LSR обнаруживает петлю, он должен отвергнуть сообщение Label Request. LSR в таких случаях также должен:

  1. отправить передающему LSR сообщение с сигналом Loop Detected;
  2. не распространять дальше сообщение Label Request.

Отметим, что сообщение Label Request с Path Vector TLV пересылается, пока не будет выполнено одно из условий:

  1. обнаружена петля;
  2. достигнут выход LSP;
  3. достигнут максимальный размер Path Vector или максимальное значение счетчика Hop Count (это трактуется, как обнаружение петли).
3.4.5.1.2. Path Vector в сообщении Label Mapping

В параграфе 2.8. Детектирование петель указаны ситуации, когда LSR должен включать Path Vector TLV в сообщения Label Mapping.

LSR, получивший Path Vector в сообщении Label Mapping, должен выполнить процедуры, описанные в параграфе 2.8. Детектирование петель.

Если LSR обнаруживает петлю, он должен отвергнуть сообщение Label Mapping, чтобы предотвратить пересылку метки, связанной с петлей. LSR в таких случаях также должен:

  1. отправить сообщение Label Release, содержащее Status TLV (сигнал Loop Detected) передавшему исходное сообщение маршрутизатору LSR;
  2. не распространять дальше сообщение Label Mapping;
  3. проверить, что сообщение Label Mapping относится к существующему LSP; при положительном результате проверки LSR должен отсоединить все восходящие метки, которые соединены с нисходящей меткой для FEC.

Отметим, что сообщение Label Mapping с Path Vector TLV пересылается, пока не будет выполнено одно из условий:

  1. обнаружена петля;
  2. достигнут вход LSP;
  3. достигнут максимальный размер Path Vector или максимальное значение счетчика Hop Count (это трактуется, как обнаружение петли).

3.4.6. Status TLV

Сообщения Notification используют Status TLV для указания событий, к которым относятся сигналы.

Представление Status TLV показано на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F| Status (0x0300)           |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Status Code                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Message Type             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

U

Для этого флага следует устанавливать значение 0, когда Status TLV передается в сообщении Notification. При передаче Status TLV в сообщениях других типов для флага следует задавать значение 1.

F

Этот флаг следует использовать так же, как одноименный флаг в поле Status Code (см. ниже).

Status Code

32-битовое целое число без знака, указывающее код события, о котором передается сигнал. Структура поля кода показана на рисунке справа.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E|F|                 Status Data                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

E

Флаг критической ошибки. Если этот флаг установлен (1), сообщение относится к критическим сигналам Error Notification. При сброшенном (0) флаге — это Advisory Notification.

F

Флаг управления пересылкой. При установленном (1) флаге уведомление следует пересылать LSR следующего или предыдущего интервала LSP (если он есть), связанному с событием, о котором говорит сигнал. При сброшенном (0) флаге уведомление не следует пересылать.

Status Data

30-битовое целое число без знака, показывающее информацию о состоянии.

Эта спецификация определяет коды состояния (32-битовое целое число без знака с описанным выше представлением).

Значение Status Code = 0 говорит об успешном выполнении.

Message ID

Отличное от нуля 32-битовое целое число, идентифицирующее сообщение партнера, на которое указывает Status TLV. Нулевое значение говорит о том, что сообщение партнера не идентифицировано.

Message Type

Отличное от нуля значение показывает тип партнерского сообщения, к которому относится Status TLV. При нулевом значении Status TLV не указывает на какой-либо конкретный тип сообщения.

Отметим, что использование Status TLV не ограничено сообщениями Notification. Сообщения других типов могут включать Status TLV в качестве необязательного параметра. При передаче в сообщениях, отличных от Notification, для поля U в Status TLV следует устанавливать значение 1, показывающее, что получателю следует отбросить данный TLV без уведомления, если он не может его обработать.

3.5. Сообщения LDP

Формат сообщения LDP показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|   Message Type              |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                     Mandatory Parameters                      |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                     Optional Parameters                       |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

U

Флаг неизвестного сообщения. При получении неизвестного сообщения со сброшенным флагом U отправителю этого сообщения передается уведомление; если же в неизвестном сообщении установлен флаг U, такое сообщение просто игнорируется. В последующих параграфах, определяющих сообщения, указывается значение бита U.

Message Type

Идентифицирует тип сообщения.

Message Length

Показывает суммарный размер полей Message ID, Mandatory Parameters и Optional Parameters в октетах.

Message ID

32-битовое значение, служащее для идентификации данного сообщения. Это поле используется передающим LSR для идентификации сообщений Notification, которые могут относиться к данному сообщению. Маршрутизатору LSR, передающему сообщение Notification в ответ на данное сообщение, следует включить это значение Message ID в Status TLV, передаваемое в сообщении Notification (см. параграф 3.5.1. Сообщение Notification).

Mandatory Parameters

Набор обязательных параметров сообщения (переменный размер). Для некоторых сообщений параметры могут не требоваться.

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

Optional Parameters

Набор необязательных параметров (переменный размер). Для многих сообщений необязательные параметры не применяются.

Для сообщений с необязательными параметрами эти параметры могут указываться в произвольном порядке.

Отметим, что для первого октета сообщения LDP выравнивание не требуется и в конце сообщения не используется заполнение — т. е., параметры могут заканчиваться на границе нечетного байта.

В таблице показаны типы сообщений, определенные для текущей версии LDP.

Имя сообщения Заголовок раздела
Notification Сообщение Notification
Hello Сообщение Hello
Initialization Сообщение Initialization
KeepAlive Сообщение KeepAlive
Address Сообщение Address
Address Withdraw Сообщение Address Withdraw
Label Mapping Сообщение Label Mapping
Label Request Сообщение Label Request
Label Abort Request Сообщение Label Abort Request
Label Withdraw Сообщение Label Withdraw
Label Release Сообщение Label Release

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

Некоторые из приведенных в таблице сообщений могут быть связаны с другими сообщениями — например, Label Mapping, Label Request, Label Withdraw и Label Release.

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

Спецификация выделяет значения типа для связанных сообщений (таких, как Label) из непрерывного блока 16-битового пространства номеров типов сообщений.

3.5.1. Сообщение Notification

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

Формат сообщения Notification показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Notification (0x0001)     |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Status (TLV)                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Optional Parameters                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Message ID

32-битовый идентификатор сообщения.

Status TLV

Указывает событие, о котором сигнализирует данное сообщение. Представление StatusTLV описано в параграфе 3.4.6. Status TLV.

Optional Parameters

Это поле переменного размера содержит 0 или более параметров в формате TLV. В таблице справа показаны базовые необязательные параметры, которые могут включаться в любые сообщения Notification.

Необязательный параметр Тип Размер Значение
Extended Status 0x0301 4 См. ниже
Returned PDU 0x0302 переменный См. ниже
Returned Message 0x0303 переменный См. ниже

Для конкретных событий, о которых сигнализируют сообщения Notification, могут использоваться другие необязательные параметры, описанные в соответствующих параграфах.

Extended Status

4-октетное значение расширенного кода состояния представляет информацию о состоянии, служащую дополнением к сведениям, содержащимся в поле Status Code сообщения Notification.

Returned PDU

LSR использует этот параметр для возврата части LDP PDU отправившему его маршрутизатору LSR. Значение этого TLV представляет собой заголовок PDU и то количество данных PDU после заголовка, которое соответствует условию, о котором сигнализирует сообщение Notification.

Returned Message

LSR использует этот параметр для возврата части LDP PDU отправившему его маршрутизатору LSR. Значение этого TLV представляет собой поля типа и размера сообщения, а также следующие за ними данные в объеме, соответствующем условию, о котором сигнализирует сообщение Notification.

3.5.1.1. Процедуры для сообщений Notification

Если LSR сталкивается с условиями, когда требуется уведомить партнера (консультация или информация об ошибке), партнеру передается сообщение Notification, содержащее поле Status TLV, которое представляет передаваемую информацию и может включать дополнительные TLV с расширенной информацией об условиях.

Если условие связано с критической ошибкой, об этой ошибке будет говорить значение Status Code в сообщении Notification. В таких случаях после передачи сообщения Notification маршрутизатору LSR следует прервать сессию LDP путем закрытия транспортного соединения TCP и отбросить все данные о состоянии, связанные с этой сессией, включая все привязки меток к FEC, полученные в этой сессии.

Когда LSR получает сообщение Notification со значением Status Code, показывающим критическую ошибку, ему следует незамедлительно прервать сессию LDP путем разрыва соединения TCP и отбросить все связанные с этой сессией состояния, включая все привязки меток к FEC, полученные в этой сессии.

Приведенное выше требование не относится к обработке сообщения Shutdown в процедуре инициализации сессии. Когда LSR получает сообщение Shutdown в процессе инициализации сессии, ему следует передать сообщение Shutdown и закрыть транспортное соединение.

3.5.1.2. События, о которых сигнализируют сообщения Notification

Для более наглядного описания события, о которых сообщается с помощью сообщений Notification, делятся на несколько категорий.

3.5.1.2.1. PDU или сообщение с некорректным форматом

LDP PDU с некорректным форматом или сообщения, являющиеся частью механизма LDP Discovery, отбрасываются без уведомления.

LDP PDU полученные через соединение TCP для сессии LDP, считаются некорректными по форме, если:

  • значение LDP Identifier в заголовке PDU не известно получателю или известный получателю идентификатор не является значением LDP Identifier, связанным с партнером LDP для этой сессии LDP; такая ошибка является критической и указывается значением Bad LDP Identifier в поле Status Code;
  • версия протокола LDP не поддерживается получателем или не совпадает с версией, согласованной на этапе организации сессии; такая ошибка является критической и указывается значением Bad Protocol Version в поле Status Code;
  • значение поля PDU Length слишком мало (< 14) или слишком велико (превышает максимальный размер PDU); такая ошибка является критической и указывается значением Bad PDU Length в поле Status Code; максимальный размер PDU определяется с соответствии с параграфом 3.5.3. Сообщение Initialization.

Сообщение LDP считается некорректным по форме, если:

  • значение Message Type не известно:если значение Message Type < 0x8000 (старший бит равен 0), такая ошибка указывается значением Unknown Message Type в поле Status Code;сообщения с Message Type 0x8000 (старший бит равен 1) отбрасываются без уведомления;
  • значение Message Length слишком велико (т. е. указывает, что сообщение выходит за пределы содержащего его LDP PDU; такая ошибка является критической и указывается значением Bad Message Length в поле Status Code;
  • значение Message Length слишком мало (т. е. меньше минимального возможного значения компоненты); такая ошибка является критической и указывается значением Bad Message Length в поле Status Code;
  • в сообщении отсутствует один или несколько обязательных параметров (Mandatory Parameter); такая ошибка не является критической и указывается значением Missing Message Parameters в поле Status Code.
3.5.1.2.2. Неизвестные или некорректные по форме TLV

Некорректные по форме TLV в сообщениях LDP, являющихся частью механизма LDP Discovery, обрабатываются путем отбрасывания содержащего такие TLV без уведомления отправителя.

TLV, содержащиеся в сообщении LDP, полученном через соединение TCP для сессии LDP, считаются некорректными по форме, если:

  • значение TLV Length слишком велико (т. е., указывает, что TLV выходит за пределы сообщения); такая ошибка считается критической и указывается значением Bad TLV Length в поле Status Code;
  • тип TLV не известен:если поле типа TLV имеет значение < 0x8000 (старший бит равен 0), такая ошибка указывается значением Unknown TLV в поле Status Code;если значение типа TLV 0x8000 (старший бит равен h1), TLV отбрасывается без уведомления;
  • поле TLV Value некорректно по форме; это относится к случаям, когда принимающая сторона обрабатывает TLV, но не может декодировать поле TLV Value; причиной таких ситуаций могут служить программные ошибки32 на приемном или передающем LSR; такие ошибки являются критическими и указываются значением Malformed TLV Value в поле Status Code.
3.5.1.2.3. Завершение отсчета сеансового таймера KeepAlive

Это критическая ошибка, указываемая значением KeepAlive Timer Expired в поле Status Code.

3.5.1.2.4. Односторонний разрыв сессии

Это критическая ошибка, указываемая значением Shutdown в поле Status Code. Сообщение Notification может включать также Extended Status TLV с объяснением причин разрыва сессии to (Shutdown). Передающий маршрутизатор LSR разрывает сессию сразу же после передачи сообщения Notification.

3.5.1.2.5. События, связанные с сообщением Initialization

Согласование на этапе инициализации сессии (см. параграф 2.5.3. Инициализация сессии) может завершаться отказом, если полученные в сообщении Initialization параметры сессии не приемлемы. Это критическая ошибка. Конкретное значение поля Status Code зависит от параметра, оказавшегося неприемлемым, возможные значения определены в параграфе 3.5.3. Сообщение Initialization.

3.5.1.2.6. События, вызываемые другими сообщениями

Не только сообщения Initialization могут вызывать события, о которых требуется уведомлять партнеров LDP с помощью сообщений Notification. Такие события и значения Status Code в сообщениях Notification описаны в параграфах, где рассматриваются соответствующие сообщения.

3.5.1.2.7. Внутренние ошибки

Реализация LDP может обладать способностью детектировать специфичные для нее проблемные ситуации. Когда такие ситуации препятствуют корректному взаимодействию с партнером, реализации следует (по возможности) использовать для оповещения партнера значение Internal Error в поле Status Code. Ошибки этого типа относятся к критическим.

3.5.1.2.8. Прочие события

Ряд событий не относится ни к одной из рассмотренных выше категорий. В настоящей версии протокола такие события не определены.

3.5.2. Сообщение Hello

Сообщения LDP Hello передаются, как часть механизма LDP Discovery (см. параграф 2.4. LDP Discovery).

Формат сообщений Hello показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Hello (0x0100)            |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Common Hello Parameters TLV               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Optional Parameters                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Message ID

32-битовое значение, служащее идентификатором данного сообщения.

Common Hello Parameters TLV

Задает параметры, являющиеся общими для всех сообщений Hello. Формат этого поля показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0| Common Hello Parms(0x0400)|      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Hold Time                |T|R| Reserved                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Hold Time

Время удержания Hello в секундах. LSR поддерживает запись сообщений Hello, полученных от потенциальных партнеров (см. параграф 3.5.2.1. Процедуры для сообщений Hello). Значение Hold Time в сообщении Hello задает время, в течение которого передающий маршрутизатор LSR будет поддерживать свою запись о полученных сообщениях Hello от принимающего LSR без получения последующего Hello.

Пара LSR согласует время удержания для сообщений Hello друг от друга. Каждый из маршрутизаторов предлагает свое значение. Используется меньшее из двух значений, предложенных в соответствующих сообщениях Hello.

Нулевое значение указывает использование принятого по умолчанию времени удержания, которое составляет 15 секунд для сообщений Link Hello и 45 секунд — для Targeted Hello. Значение 0xffff задает бесконечное удержание.

T, направленное приветствие

Значение 1 говорит о том, что данное сообщение Hello является Targeted Hello. Нулевое значение поля указывает на Link Hello.

R, запрос на передачу направленных приветствий

Значение 1 служит для запроса у получателя периодической отправки сообщенй Targeted Hello отправителю данного сообщения Hello. Значение 0 показывает отсутствие такого запроса.

Маршрутизатор LSR, инициирующий механизм Extended Discovery, устанавливает R=1. Если R=1, принимающий сообщение LSR проверяет, настроен ли он на передачу сообщений Targeted Hello отправителю Hello в ответ на сообщения Hello с таким запросом. Если в конфигурации отправка сообщений не задана, запрос игнорируется. Если конфигурация включает отправку сообщений Targeted Hellos, данный запрос инициирует периодическую отправку соответствующих сообщений отправителю Hello.

Reserved

Это резервное поле. При передаче в нем должно устанавливаться нулевое значение, а на приемной стороне значение поля должно игнорироваться.

Optional Parameters

Это поле переменного размера в сообщении Hello может содержать параметры, представляемые в формате TLV. Необязательные параметры, определенные для данной версии протокола, показаны в таблице справа.

Параметр Тип Размер Значение
IPv4 Transport Address 0x0401 4 См. ниже
Configuration Sequence Number 0x0402 4 См. ниже
IPv6 Transport Address 0x0403 16 См. ниже

IPv4 Transport Address

Задает адрес IPv4, который будет использоваться для передающего маршрутизатора LSR при организации соединения TCP для сессии LDP. Если этот необязательный параметр отсутствует, следует использовать адрес IPv4 отправителя пакета UDP, содержащего сообщение Hello.

Configuration Sequence Number

Задает 4-октетный порядковый номер (целое число без знака), идентифицирующий конфигурационное состояние передающего LSR. Это значение используется принимающим LSR для детектирования смены конфигурации на стороне передающего LSR.

IPv6 Transport Address

Задает адрес IPv6, который будет использоваться для передающего маршрутизатора LSR при организации соединения TCP для сессии LDP. Если этот необязательный параметр отсутствует, следует использовать адрес IPv6 отправителя пакета UDP, содержащего сообщение Hello.

3.5.2.1. Процедуры для сообщений Hello

Маршрутизатор LSR, получающий сообщения Hello от другого LSR, организует отношения Hello-смежности, соответствующие сообщениям Hello. LSR поддерживает таймер удержания для Hello-смежности, который запускается заново всякий раз при получении сообщения Hello, соответствующего данной Hello-смежности. Если отсчет таймера для Hello-смежности завершается, LSR разрывает отношения Hello-смежности (см. параграфы 2.5.5. Поддержка Hello-смежности и 2.5.6. Поддержка сессий LDP).

Рекомендуется передавать сообщения Hello с интервалом не более одной трети значения времени удержания Hello.

LSR обрабатывает полученные сообщения LDP Hello следующим образом:

  1. LSR проверяет возможность восприятия Hello. Критерии допустимости восприятия зависят от реализации (ниже приведен пример таких критериев).
  2. Если сообщение Hello неприемлемо, LSR игнорирует его.
  3. Если сообщение Hello приемлемо, LSR проверяет наличие Hello-смежности с отправителем этого сообщения. При наличии смежности перезапускается таймер удержания. Если смежность еще не организована, она создается и запускается таймер удержания.
  4. Если сообщение Hello содержит дополнительные TLV, LSR обрабатывает их (см. ниже).
  5. В заключение, если LSR не имеет сессии LDP для пространства меток, заданного полем LDP Identifier в заголовке PDU для сообщения Hello, выполняются процедуры, описанные в параграфе 2.5.1. Организация сеанса LDP.

Ниже приведен пример критериев приемлемости для сообщений Link Hello и Targeted Hello.

Сообщение Link Hello считается приемлемым, если интерфейс, через который оно было получено, настроен на коммутацию по меткам.

Сообщение Targeted Hello от отправителя с адресом A считается приемлемым, если выполняется любое из условий:

  • LSR настроен на восприятие сообщений Targeted Hello;
  • LSR настроен на передачу сообщений Targeted Hello в адрес A.

Ниже описана обработка маршрутизатором LSR сообщений Hello с дополнительными TLV.

Transport Address

LSR связывает указанный транспортный адрес с Hello-смежностью.

Configuration Sequence Number

Необязательный параметр Configuration Sequence Number используется передающим маршрутизатором LSR для информирования принимающего LSR об изменении своей конфигурации. Когда принимающий LSR, играющий роль активного в процессе организации сеанса LDP, обнаруживает изменение конфигурации на стороне передающего LSR, он может сбросить увеличение периода повтора попыток соединения с передающим LSR, если таковое было начато (см. параграф 2.5.3. Инициализация сессии).

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

3.5.3. Сообщение Initialization

Сообщения LDP Initialization используются на этапе организации сеанса LDP (см. параграф 2.5.1. Организация сеанса LDP).

Формат сообщения показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Initialization (0x0200)   |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Common Session Parameters TLV             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Optional Parameters                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Message ID

32-битовое значение, служащее для идентификации данного сообщения.

Common Session Parameters TLV

Указывает значения, предложенные передающим LSR для параметров, которые должны согласовываться в каждой сессии LDP.

Представление общих параметров сессии (Common Session Parameters TLV) показано на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0| Common Sess Parms (0x0500)|      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Protocol Version              |      KeepAlive Time           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|D|  Reserved |     PVLim     |      Max PDU Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Receiver LDP Identifier                       |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++

Protocol Version

2-октетное целое число без знака, указывающее номер версии протокола. Данная спецификация определяет протокол LDP версии 1.

KeepAlive Time

2-октетное целое число без знака, которое показывает предложенное передающим LSR значение KeepAlive Time (в секундах). Принимающий маршрутизатор LSR должен рассчитать значение KeepAlive Timer, используя меньшее из двух значений (предложенное им и полученное в PDU) KeepAlive Time. Выбранное значение KeepAlive Time показывает максимальное число секунд, которое может разделять прием двух последовательных PDU от партнера LDP в TCP-соединении протокольной сесси. Таймер KeepAlive сбрасывается при получении каждого PDU.

A, дисциплина анонсирования меток

Показывает тип анонса метки (Label advertisement). Значение 0 говорит о незапрошенном нисходящем анонсе (Downstream Unsolicited); значение 1 говорит о нисходящем анонсировании по запросу (Downstream On Demand).

Если один LSR предлагает Downstream Unsolicited, а другой — Downstream on Demand, выбор осуществляется по следующим правилам:

  • если сессия организована для управляемого по меткам соединения ATM или Frame Relay, должен использоваться режим Downstream on Demand;
  • в остальных случаях должен использоваться режим Downstream Unsolicited.

Если определенная описанным способом дисциплина анонсирования меток неприемлема для LSR, этот маршрутизатор должен отправить сообщение Session Rejected/Parameters Advertisement Mode Notification в ответ на сообщение Initialization и отказаться от организации сессии.

D, детектирование петель

Показывает возможность детектирования перетель (Loop Detection) на базе векторов пути (Path Vector). Значение 0 говорит о том, что механизм Loop Detection отключен, а значение 1 означает возможность детектирования петель.

PVLim, максимальный размер вектора пути

Заданный в конфигурации максимальный размер Path Vector. Если детектирование петель запрещено (D = 0), это поле должно иметь значение 0. Если процедуры Loop Detection будут требовать от LSR передачи Path Vector с превышающим заданный предел размером, LSR будет вести себя, как при обнаружении петли для соответствующего FEC.

Если для части сети разрешен механизм Loop Detection, для всех LSR в этой части сети рекомендуется устанавливать одинаковое значение Path Vector Limit. Несмотря на то, что знание партнерского значения Path Vector Limit не будет менять поведения LSR, это значений позволит LSR предупредить оператора о возможной некорректности конфигурации.

Reserved

Это поле является резервным. На передающей стороне значения поля должно устанавливаться в 0, а на приемной — игнорироваться.

Max PDU Length

2-октетное целое число без знака, предлагающее максимально допустимый размер LDP PDU для данной сессии. Значения, не превышающие 255, говорят об использовании принятого по умолчанию максимума — 4096 октетов.

На принимающей стороне LSR должен определять максимальный размер PDU для сессии, как меньшее из двух (своего и партнерского) значений Max PDU Length. До завершения инициализации сессии используется принятый по умолчанию максимальный размер PDU.

Если определенный, как указано выше, максимальный размер PDU не приемлем для LSR, тот должен передать сообщение Session Rejected/Parameters Max PDU Length Notification в ответ на сообщение Initialization и отказаться от организации сеанса.

Receiver LDP Identifier

Идентифицирует пространство меток получателя. Этот идентификатор LDP вместе с идентификатором LDP на стороне отправителя (в заголовке PDU) позволяет получателю найти соответствие между сообщением Initialization и одной из Hello-смежностей (см. параграф 3.5.2.1. Процедуры для сообщений Hello).

Если соответствия с Hello-смежностью не найдено, LSR должен отправить сообщение Session Rejected/No Hello Notification в ответ на сообщение Initialization и отказаться от организации сеанса.

Optional Parameters

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

Параметр Тип Размер Значение
ATM Session Parameters 0x0501 Перем. См. ниже
Frame Relay Session Parameters 0x0502 Перем. См. ниже

Параметры сессии ATM

Используются в тех случаях, когда сессия LDP служит для управления обменом метками на канале ATM для задания специфичных для ATM параметров сессии. Формат параметра показан на рисунке.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|0|   ATM Sess Parms (0x0501) |      Length                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | M |   N   |D|                        Reserved                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 ATM Label Range Component 1                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                                                               ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 ATM Label Range Component N                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M, возможности слияния меток в ATM

Показывает возможности слияния, поддерживае-мые коммутатором ATM. Определенные в настоя-щей версии специфика-ции значения параметра показаны в таблице справа.

Если параметры слияния маршрутизаторов LSR различаются:

  • LSR, не поддерживающий слияния, может свободно обмениваться метками с LSR, поддерживающими слияние VC.
  • Значение

    Смысл
    0 Слияние не поддерживается
    1 Поддерживается слияние VP
    2 Поддерживается слияние VC
    3 Поддерживается слияние VP и VC

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

Отметим, что при использовании слияния VP входной узел принимает на себя ответственность за обеспечение уникальности выбранного значения VCI в масштабе домена LSR.

N, число компонент диапазона меток

Задает число ATM Label Range Component, включенных в TLV.

D, направление VC

Нулевое значение флага говорит о двухстороннем VC, позволяющем LSR (в рамках данного VPI) поддерживать использование значения VCI в качестве метки для обоих направлений независимо. Значение 1 указывает на односторонний VC, когда данное значение VCI (в рамках данного VPI) может применяться для отображения меток только в одном направлении. Когда один или оба партнера указывают однонаправленный характер VC, оба LSR используют одностороннее выделение меток VC для канала. Маршрутизаторы LSR сравнивают свои значения LDP Identifier, как целые числа без знака. LSR с большим значением LDP Identifier может выделять только нечетные значения VCI в своем диапазоне VPI/VCI для использования в качестве меток. Система с меньшим значением LDP Identifier может выделять только четные значения VCI в своем диапазоне VPI/VCI для использования в качестве меток.

Reserved

Это поле является резервным. На передающей стороне значения поля должно устанавливаться в 0, а на приемной — игнорироваться.

Одно или несколько полей ATM Label Range Component

Список ATM Label Range Component, которые совместно задают диапазон меток (Label range) поддерживаемых передающим LSR.

Принимающий маршрутизатор LSR должен определять пересечение между полученным диапазоном меток и своим диапазоном. Пересечение представляет собой диапазон меток, которые LSR может выделять и воспринимать. Для маршрутизаторов LSR недопустима организация сессий с соседями, для которых пересечение диапазонов меток является пустым (NULL). В таких случаях LSR должен передать сообщение Session Rejected/Parameters Label Range Notification в ответ на сообщение Initialization и продолжать организацию сеанса.

Представление компонент диапазона меток ATM показано на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Res  |    Minimum VPI        |      Minimum VCI              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Res  |    Maximum VPI        |      Maximum VCI              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Res

Это поле является резервным. На пере-дающей стороне значения поля должно устанавливаться в 0, а на приемной — игнорироваться.

Minimum VPI (12 битов)

Это 12-битовое поле задает нижнюю границу диапазона идентификаторов виртуальных путей (VPI), который поддерживается на коммутатором. Если размер VPI меньше 12 битов, его следует дополнить недостающим количеством нулей слева.

Minimum VCI (16 битов)

Это 16-битовое поле задает нижнюю границу диапазона идентификаторов виртуальных соединений (VCI), который поддерживается на коммутатором. Если размер VCI меньше 16 битов, его следует дополнить недостающим количеством нулей слева.

Maximum VPI (12 битов)

Это 12-битовое поле задает верхнюю границу диапазона идентификаторов виртуальных путей (VPI), который поддерживается на коммутатором. Если размер VPI меньше 12 битов, его следует дополнить недостающим количеством нулей слева.

Maximum VCI (16 битов)

Это 16-битовое поле задает верхнюю границу диапазона идентификаторов виртуальных соединений (VCI), который поддерживается на коммутатором. Если размер VCI меньше 16 битов, его следует дополнить недостающим количеством нулей слева.

Когда LSR соединяются не напрямую с помощью ATM VP, передающему маршрутизатору LSR следует установить для полей Minimum VPI и Maximum VPI значение 0, а принимающий LSR должен игнорировать значения полей Minimum VPI и Maximum VPI.

Параметры сессии Frame Relay

Используются в тех случаях, когда сессия LDP служит для управления обменом метками на канале Frame Relay для задания специфичных для Frame Relay параметров сессии. Формат параметра показан на рисунке справа.

M, возможности слияния Frame Relay

Показывает возможности слияния в коммутаторе Frame Relay. Определенные настоящей спецификацией значения показаны в таблице.

Значение

Смысл
0 Слияние не поддерживается
1 Слияние поддерживается

 

Маршрутизаторы Frame Relay LSR, поддерживающие и не поддерживающие слияния меток могут быть полностью интероперабельны.

N, число компонент диапазона меток

Задает число Frame Relay Label Range Component, включенных в TLV.

D, направление VC

Нулевое значение флага говорит о двухстороннем VC, позволяющем LSR поддерживать использование значения DLCI в качестве метки для обоих направлений независимо. Значение 1 указывает на односторонний VC, когда данное значение DLCI может применяться для отображения меток только в одном направлении. Когда один или оба партнера указывают однонаправленный характер VC, оба LSR используют одностороннее выделение меток VC для канала. Маршрутизаторы LSR сравнивают свои значения LDP Identifier, как целые числа без знака. LSR с большим значением LDP Identifier может выделять только нечетные значения DLCI в своем диапазоне меток. Система с меньшим значением LDP Identifier может выделять только четные значения DLCI в своем диапазоне меток.

Reserved

Это поле является резервным. На пере-дающей стороне значения поля должно устанавливаться в 0, а на приемной — игнорироваться.

Одно или несколько полей Frame Relay Label Range

Спосок значений Frame Relay Label Range Component, которые совместно задают диапазон меток, поддерживаемый передающим LSR.

Принимающий маршрутизатор LSR должен определять пересечение между полученным диапазоном меток и своим диапазоном. Пересечение представляет собой диапазон меток, которые LSR может выделять и воспринимать. Для маршрутизаторов LSR недопустима организация сессий с соседями, для которых пересечение диапазонов меток является пустым (NULL). В таких случаях LSR должен передать сообщение Session Rejected/Parameters Label Range Notification в ответ на сообщение Initialization и продолжать организацию сеанса.

Формат представления Frame Relay Label Range Component показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Reserved    |Len|                     Minimum DLCI            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Reserved        |                     Maximum DLCI            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Reserved

Это поле является резервным. На пере-дающей стороне значения поля должно устанавливаться в 0, а на приемной — игнорироваться.

Len

Это поле задает размер DLCI в битах. Поддерживаемые значения показаны в таблице.

Len Размер DLCI
0 10
2 23

Значения 1 и 3 зарезервированы.

Minimum DLCI

Это 23-битовое поле задает нижнюю границу блока идентификаторов канала данных (DLCI) который поддерживается коммутатором. Значение DLCI следует выравнивать по правому краю, дополняя при необходимости нулями слева.

Maximum DLCI

Это 23-битовое поле задает верхнюю границу блока идентификаторов канала данных (DLCI) который поддерживается коммутатором. Значение DLCI следует выравнивать по правому краю, дополняя при необходимости нулями слева.

Отметим, что Generic Session Parameters TLV не определяются для сессий, анонсирующих метки общего назначения (Generic Label).

3.5.3.1. Процедуры для сообщений Initialization

См. параграфы 2.5.1. Организация сеанса LDP и 2.5.4. Инициализация машины состояний, где приведено общее описание процедур обработки сообщений Initialization.

3.5.4. Сообщение KeepAlive

LSR передает сообщения KeepAlive для мониторинга целостности транспортного соединения сессии LDP.

Формат сообщения показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   KeepAlive (0x0201)        |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Optional Parameters                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Message ID

32-битовое значение, используемое для идентификации сообщений.

Optional Parameters

Для сообщений KeepAlive дополнительные параметры не определены.

3.5.4.1. Процедуры для сообщений KeepAlive

Механизм KeepAlive Timer, описанный в параграфе 2.5.6. Поддержка сессий LDP, сбрасывает сеансовый таймер KeepAlive при получении каждого LDP PDU в соединении TCP для данной сессии. Сообщения KeepAlive позволяют обеспечить сброс таймера KeepAlive в тех случаях, когда у LSR нет информации для передачи партнеру LDP.

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

3.5.5. Сообщение Address

LSR передает сообщения Address своему партнеру LDP для анонсирования адресов своих интерфейсов.

Формат сообщения показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Address (0x0300)          |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                     Address List TLV                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Optional Parameters                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Message ID

32-битовое значение, используемое для идентификации сообщений.

Address List TLV

Список адресов интерфейсов, которые будут анонсироваться передающим маршрутизатором LSR. Формат представления Address List TLV описан в параграфе 3.4.3. TLV для списка адресов.

Optional Parameters

Для сообщений Address дополнительные параметры не определены.

3.5.5.1. Процедуры для сообщений Address

Маршрутизатор LSR, получивший сообщение Address, использует адреса из этого сообщения для своей базы данных по отображениям между идентификаторами LDP и адресами следующих маршрутизаторов (см. параграф 2.7. Идентификаторы LDP и адреса Next Hop).

При организации нового сеанса LDP до передачи сообщений Label Mapping или Label Request маршрутизатору LSR следует анонсировать адреса своих интерфейсов с помощью одного или нескольких сообщений Address.

Когда LSR «активизирует» новый адрес интерфейса, ему следует анонсировать этот адрес в сообщении Address.

Когда LSR «деактивирует» анонсированный ранее интерфейс, ему следует отозвать этот адрес с помощью сообщения Address Withdraw (см. параграф 3.5.6. Сообщение Address Withdraw).

Если LSR не поддерживает семейство адресов, указанное в Address List TLV, ему следует передать сообщение Unsupported Address Family Notification для сигнализации об ошибке и прервать дальнейшую обработку сообщения.

LSR может повторно анонсировать адрес (A) без явного отзыва этого адреса. Если получатель уже имеет привязку для этого адреса (LSR, A), ему не следует предпринимать никаких дополнительных действий.

LSR может отозвать адрес (A), который не был анонсирован ранее. Если получатель видит отзыв адреса, для которого у него нет привязки (LSR, A), ему не следует предпринимать никаких дополнительных действий.

3.5.6. Сообщение Address Withdraw

LSR передает сообщение Address Withdraw своему партнеру LDP для отзыва анонсированных ранее адресов своих интерфейсов.

Формат сообщения Address Withdraw показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Address Withdraw (0x0301) |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                     Address List TLV                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Optional Parameters                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Message ID

32-битовое значение, используемое для идентификации сообщений.

Address List TLV

Список адресов интерфейсов маршрутизатора, которые отзываются передающим сообщение LSR. Представление Address List TLV описано в параграфе 3.4.3. TLV для списка адресов.

Optional Parameters

Для сообщений Address Withdraw дополнительные параметры не определены.

3.5.6.1. Процедуры для сообщений Address Withdraw

См. параграф 3.5.5.1. Процедуры для сообщений Address.

3.5.7. Сообщение Label Mapping

LSR передает сообщения Label Mapping своему партнеру LDP для анонсирования ему привязки FEC к меткам.

Формат сообщения Label Mapping показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Label Mapping (0x0400)    |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     FEC TLV                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Label TLV                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Optional Parameters                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Message ID

32-битовое значение, используемое для идентификации сообщений.

FEC TLV

Задает FEC-компоненту анонсируемой связки FEC-Label. Представление FEC TLV описано в параграфе 3.4.1. FEC TLV.

Label TLV

Задает Label-компоненту анонсируемой связки FEC-Label. Представление Label TLV описано в параграфе 3.4.2. TLV для меток.

Optional Parameters

Это поле переменного размера может содержать параметры в формате TLV. Набор поддерживаемых параметров показан в таблице.

Параметр Размер Значение
Label Request Message ID TLV 4 См. ниже
Hop Count TLV 1 См. ниже
Path Vector TLV перем. См. ниже

Представление Hop Count TLV и Path Vector TLV описано в параграфе 3.4. Представление TLV для параметров общего назначения.

Label Request Message ID

Если сообщение Label Mapping является откликом на сообщение Label Request, оно должно включать дополнительный параметр Label Request Message ID. Значением этого параметра является поле Message ID из соответствующего сообщения Label Request.

Hop Count

Задает общее число интервалов LSR на пути LSP, организуемом с помощью сообщения Label. Обработка этого поля описана в параграфе 3.4.4.1. Процедуры подсчета интервалов.

Path Vector

Задает маршрутизаторы LSR в пути LSP, организуемом с помощью этого сообщения Label. Обработка этого поля описана в параграфе 3.4.5.1. Процедуры Path Vector.

3.5.7.1. Процедуры для сообщений Label Mapping

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

Маршрутизатор LSR отвечает за корректность распространяемого отображения меток и контроль наличия этих отображений у его партнеров.

Маршрутизатору LSR, получившему сообщение Label Mapping от нисходящего LSR для некого префикса (Prefix), не следует использовать метку для пересылки, пока в его таблице маршрутизации нет записи, которая точно соответствует элементу FEC (FEC Element).

Более подробная информация приведена ниже (Приложение A. Процедуры распространения меток LDP).

3.5.7.1.1. Независимое управление отображением

Если LSR настроен на независимое управление, сообщение об отображении меток передается этим LSR при возникновении любого из перечисленных ниже условий:

  1. LSR распознает новый класс FEC через таблицу пересылки и метки анонсируются в режиме Downstream Unsolicited;
  2. LSR получает сообщение Request от восходящего партнера для FEC, имеющегося в таблице пересылки LSR;
  3. следующий интервал для FEC меняется на другого партнера LDP и включено детектирование петель;
  4. изменяются атрибуты отображения;
  5. принимается отображение от следующего интервала в нисходящем направлении И выполняется любое из условий:
    1. восходящее отображение не было создано;
    2. включено детектирование петель;
    3. атибуты отображения изменились.
3.5.7.1.2. Упорядоченное управление отображением

Если LSR работает в режиме упорядоченного управления (Ordered Control), сообщение Mapping передается нисходящими LSR при выполнении любого из перечисленных ниже условий:

  1. LSR распознает новый класс FEC через таблицу пересылки и является выходным для данного FEC;
  2. LSR получает сообщение Request от восходящего партнера для FEC, имеющегося в таблице пересылки LSR и этот LSR является выходным для данного FEC или имеет нисходящее отображение для данного FEC$
  3. следующий интервал для FEC меняется на другого партнера LDP и включено детектирование петель;
  4. изменяются атрибуты отображения;
  5. принимается отображение от следующего интервала в нисходящем направлении И выполняется любое из условий:
    1. восходящее отображение не было создано;
    2. включено детектирование петель;
    3. атибуты отображения изменились.
3.5.7.1.3. Нисходящее анонсирование меток по запросам

В общем случае восходящий маршрутизатор LSR отвечает за запрашивание отображений меток при работе в режиме Downstream on Demand. Однако, если не соблюдать некоторые правила, могут возникать ситуации, когда два соседних LSR с разными режимами анонсирования могут вызывать «блокировку», при которой все работает корректно, но распространения меток не происходит. В качестве примера рассмотрим два LSR (Ru и Rd), где Ru является восходящим LSR, Rd — нисходящим LSR для некого FEC. Пусть Ru работает в режиме Downstream Unsolicited, Rd — в режиме Downstream on Demand. В этом случае Rd может предполагать, Ru будет запрашивать отображение меток, когда оно потребуется, а Ru может предполагать, что Rd будет анонсировать метку, если захочет, чтобы Ru ее использовал. В такой ситуации метки от Rd к Ru просто не будут распространяться.

Описанной блокировки можно избежать, если выполнять приведенное здесь правило — маршрутизатору LSR, работающему в режиме Downstream on Demand, не следует полагаться на передачу анонсов отображений без запроса. Следовательно, если нисходящий LSR работает в режиме Downstream on Demand, восходящий LSR является ответственным за запрашивание требуемых меток.

3.5.7.1.4. Нисходящее анонсирование меток без запроса

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

Комбинация режима анонсирования без запроса (Downstream Unsolicited) с консервативным удержанием меток (Conservative Label retention) может приводить к возникновению ситуаций, когда LSR будет освобождать метку для FEC, который позднее потребуется. Например, если LSR Rd анонсирует маршрутизатору LSR Ru метку для FEC, по отношению к которому не является следующим интервалом для Ru, маршрутизатор Ru будет освобождать эту метку. Если на Ru следующий интервал для FEC будет в последствии изменен на Rd, возникнет потребность в освобожденной ранее метке.

Для предотвращения проблем в таких ситуациях Ru может явно запросить метку при возникновении необходимости в ней или Rd может периодически повторять анонсирование метки маршрутизатору Ru. Во многих случаях Ru будет знать, когда ему нужна метка от Rd. Например, при смене следующего интервала для FEC на Rd. Однако могут возникать ситуации, когда Ru не знает о такой необходимости. Например, Rd может попытаться организовать LSP с нестандартными свойствами. Принуждение Ru к явному запрашиванию метки в такой ситуации потребует поддержки информации о состоянии для потенциальных LSP с нестандартными свойствами.

В тех случаях, когда Ru знает о потребности в метке, он несет ответственность за явный запрос метки с помощью сообщения Label Request. В ситуациях, когда Ru может не знать о потребности в метке, Rd отвечает за периодическое реанонсирование метки маршрутизатору Ru.

Для этой версии протокола LDP единственная ситуация, когда Ru знает о потребности в метке для FEC от Rd, возникает в случае, где Rd является следующим интервалом для FEC, Ru не имеет метки от Rd, а LSP для FEC является одним из тех, которые могут быть организованы с использованием TLV, определенных в этом документе.

3.5.8. Сообщение Label Request

LSR передает сообщения Label Request партнеру LDP для запроса у того информации о привязке (отображении) метки для FEC.

Формат сообщения Label Request показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Label Request (0x0401)    |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     FEC TLV                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Optional Parameters                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Message ID

32-битовое значение, используемое для идентификации сообщений.

FEC TLV

Класс FEC, для которого запрашивается метка. Представление этого поля описано в параграфе 3.4.1. FEC TLV.

Optional Parameters

Это поле переменной длины может содержать параметры, представленные в форме TLV. Список доаполнительных параметров приведен в таблице.

Параметр Размер Значение
Hop Count TLV 1 См. ниже
Path Vector TLV перем. См. ниже

Представление Hop Count TLV и Path Vector TLV описано в параграфе 3.4. Представление TLV для параметров общего назначения.

Hop Count

Задает число интервалов LSR на пути LSP, который будет организован с помощью сообщения Label Request. Обработка этого TLV описана в параграфе 3.4.4.1. Процедуры подсчета интервалов.

Path Vector

Задает маршрутизаторы LSR, через которые будет организован путь LSP33 с помощью сообщения Label Request. Обработка этого TLV описана в параграфе 3.4.5.1. Процедуры Path Vector.

3.5.8.1. Процедуры для сообщений Label Request

Сообщения Label Request используются восходящим LSR для явного запрашивания от нисходящего LSR выделения и анонсирования метки для FEC.

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

  1. LSR распознает новый класс FEC через таблицу пересылки, следующим интервалом является партнер LDP и данный LSR еще не имеет отображения от следующего интервала для данного FEC;
  2. следующий интервал для FEC меняется, а данный LSR еще не имеет отображения от следующего интервала для данного FEC34;
  3. LSR получает сообщение Label Request для FEC от своего восходящего партнера LDP, следующим интервалом для FEC является партнер LDP, а данный LSR еще не имеет отображения от следующего интервала35.

Принимающему LSR следует отвечать на сообщение Label Request сообщением Label Mapping для запрошенной метки или сообщением Notification, говорящим о невозможности выполнения запроса.

Когда FEC, для которого запрашивается метка, является Prefix FEC Element, принимающий LSR использует свою таблицу маршрутизации для определения отклика. Если его таблица маршрутизации не содержит записи, точно соответствующей запрошенному префиксу, LSR должен отвечать сообщением No Route Notification.

Поле Message ID в сообщениях Label Request служит идентификатором транзакции для запроса метки. Когда принявший сообщение LSR отвечает сообщением Label Mapping, последнее должно включать дополнительный параметр Label Request/Returned Message ID TLV, который содержит значение Message ID из сообщения Label Request. Отметим, что по причине использования маршрутизаторами LSR поля Message ID из сообщения Label Request в качестве идентификатора транзакции, LSR не следует повторно использовать значение идентификатора, указанное в сообщении Label Request, до завершения транзакции.

Данная версия протокола определяет перечисленные ниже коды (Status Code) для сообщений Notification, говорящих о невозможности выполнения запроса.

No Route

FEC, для которого была запрошена метка, включает FEC Element, для которого LSR не имеет маршрута.

No Label Resources

LSR не может обеспечить метку по причине нехватки ресурсов. Когда ресурсы станут доступными, LSR должен уведомить запрашивавший метку маршрутизатор LSR с помощью сообщения Notification, содержащего код состояния Label Resources Available.

Маршрутизатору LSR, получившему отклик No Label Resources в ответ на сообщение Label Request, недопустимо вводить новые запросы Label Request, пока он не получит сообщение Notification с кодом состояния Label Resources Available.

Loop Detected

LSR обнаружил «зацикливание» сообщения Label Request (петлю).

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

3.5.9. Сообщение Label Abort Request

Сообщения Label Abort Request могут служить для прерывания обработки сообщений Label Request.

Формат сообщения Label Abort Request показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Label Abort Req (0x0404)  |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     FEC TLV                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Label Request Message ID TLV              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Optional Parameters                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Message ID

32-битовое значение, используемое для идентификации сообщений.

FEC TLV

Указывает FEC, для которого прерывается обработка Label Request.

Label Request Message ID TLV

Задает идентификатор сообщения Label Request, для которого прерывается обработка.

Optional Parameters

Для сообщений Label Abort Request дополнительные параметры не определены.

3.5.9.1. Процедуры для сообщений Label Abort Request

LSR Ru может отправить сообщение Label Abort Request для прерывания обработки отправленного ранее маршрутизатору LSR Rd сообщения Label Request для FEC при следующих обстоятельствах:

  1. следующий интервал на Ru для класса FEC был изменен с LSR Rd на LSR X;
  2. Ru не является входным LSR, не поддерживает слияние и также получил сообщение Label Abort Request для FEC от восходящего партнера Y;
  3. Ru не является входным LSR, поддерживает слияние и получил сообщение Label Abort Request для FEC от восходящего партнера Y, который был единственным (последним) восходящим LSR, запросившим метку для FEC.

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

Когда LSR получает сообщение Label Abort Request и у него имеется сообщение Label Request, в ответ на которое еще не было отправлено сообщение Label Mapping или Notification, он должен подтвердить прерывание транзакции с помощью сообщения Label Request Aborted Notification. Сообщение Notification должно включать поле Label Request Message ID TLV, содержащее значение Message ID из прерываемого запроса Label Request.

Если LSR получает сообщение Label Abort Request Message после отправки сообщения Label Mapping или Notification в ответ на соответствующий запрос Label Request, он просто игнорирует запрос на прерывание.

Если LSR получает сообщение Label Mapping в ответ на сообщение Label Request после того, как он отправил запрос Label Abort Request для прерывания Label Request, метка, принятая в сообщении Label Mapping, остается корректной. LSR может по своему усмотрению принять решение об использовании метки или ее освобождении с помощью сообщения Label Release.

LSR, прерывающий обработку сообщения Label Request не может повторно использовать значение Message ID для сообщений Label Request, пока он не получит от своего партнера одно из сообщений:

  • Label Request Aborted Notification с подтверждением прерывания обработки;
  • Label Mapping в ответ на сообщение Label Request, для которого запрошено прерывание;
  • Notification в ответ на сообщение Label Request, для которого запрошено прерывание (например, с кодом Loop Detected, No Label Resources и т. п.).

Для защиты от запоздало работающих партнеров или некорректных реализаций LSR может использовать тайм-аут повторного использования идентификаторов. Время ожидания следует делать достаточно большим (несколько минут). По истечении времени ожидания при отсутствии отклика от партнера LSR может повторно использовать значение Message ID в сообщении Label Request; в таких случаях ему следует также отбрасывать все записи о незавершенных сообщениях Label Request и Label Abort.

Отметим, что отклики на сообщения Label Abort Request никогда не бывают «упорядоченными». Т. е. отклик не зависит от нисходящего состояния LSP, организация которого прерывается. Маршрутизатор LSR, получивший сообщение Label Abort Request, должен незамедлительно обработать его, независимо от состояния LSP в нисходящем направлении, отвечая сообщением Label Request Aborted Notification или игнорируя запрос на прерывание, если это допустимо.

3.5.10. Сообщение Label Withdraw

LSR передает сообщения Label Withdraw своему партнеру LDP для информирования того о том, что партнер больше не может использовать указанное отображение FEC-label, которое данный LSR анонсировал ранее. Это используется для разрыва связок между FEC и метками.

Формат сообщения показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Label Withdraw (0x0402)   |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     FEC TLV                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Label TLV (optional)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Optional Parameters                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Message ID

32-битовое значение, используемое для идентификации сообщений.

FEC TLV

Идентифицирует класс FEC, для которого отзывается отображениеFEC-label.

Optional Parameters

Это поле переменного размера может содержать параметры в форме TLV. Список дополнительных параметров приведен в таблице.

Параметр Размер Значение
Label TLV перем. См. ниже

 Формат Label TLV описан в параграфе 3.4.2. TLV для меток.

Label

При наличии этого параметра он указывает отзываемую метку (см. описание процедур ниже).

3.5.10.1. Процедуры для сообщений Label Withdraw

LSR передает сообщение Label Withdraw при выполнении следующих условий:

  1. данный LSR больше не распознает ранее известный класс FEC, для которого он анонсировал метку;
  2. LSR в одностороннем порядке (например, в соответствии с конфигурацией) принял решение больше не коммутировать метки для FEC с отзываемым отображением.

FEC TLV задает класс FEC, для которого метка отзывается. Если за указанием класса не следует Label TLV, отзываться будут все метки, связанные с этим FEC, в остальных случаях отзывается только метка, заданная Label TLV.

FEC TLV может содержать шаблон Wildcard FEC Element — в таких случаях других FEC Element присутствовать не может. В этом случае если сообщение Label Withdraw содержит необязательное поле Label TLV, метка будет отзываться для всех FEC, соответствующих шаблону. Если поле Label TLV отсутствует в сообщении Label Withdraw, это означает, что передающий LSR отзывает все метки, анонсированные ранее принимающим LSR.

Маршрутизатор LSR, получивший сообщение Label Withdraw, должен ответить на него сообщением Label Release.

Приложение A. Процедуры распространения меток LDP содержит дополнительную информацию о процедурах отзыва меток.

3.5.11. Сообщение Label Release

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

Формат сообщения Label Release Message показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   Label Release (0x0403)   |      Message Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     FEC TLV                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Label TLV (optional)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Optional Parameters                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Message ID

32-битовое значение, используемое для идентификации сообщений.

FEC TLV

Идентифицирует класс FEC, для которого освобождается отображение FEC-label.

Optional Parameters

Это поле переменного размера может содержать параметры в форме TLV. Список дополнительных параметров приведен в таблице.

Параметр Размер Значение
Label TLV перем. См. ниже

Представление Label TLV описано в параграфе 3.4.2. TLV для меток.

Label

При наличии этого поля оно указывает освобождаемую метку (см. описание процедур ниже).

3.5.11.1. Процедуры для сообщений Label Release

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

Маршрутизатор LSR должен передавать сообщение Label Release при выполнении любого из приведенных ниже условий:

  1. маршрутизатор LSR, который передал отображение метки, больше не является следующим интервалом для отображаемого класса FEC, а LSR настроен на консервативное удержание;
  2. маршрутизатор LSR получил отображение метки от LSR, который не является следующим интервалом для FEC, а LSR настроен на консервативное удержание;
  3. маршрутизатор LSR получил сообщение Label Withdraw.

Отметим, что если LSR настроен на «либеральный режим», сообщение об освобождении меток не будет передаваться в указанных выше случаях (1) и (2). В таких случаях восходящий LSR сохраняет все неиспользуемые метки и может незамедлительно начать их последующее использование, если нисходящий партнер станет следующим интервалом для FEC.

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

FEC TLV может содержать шаблон Wildcard FEC Element; в этом случае других FEC Element не может быть включено. Если сообщение Label Release с шаблоном класса содержит дополнительное поле Label TLV, указанная им метка освобождается для всех FEC, соответствующих классу. Если параметр Label TLV не задан в сообщении Label Release, передающий LSR освобождает все отображения меток, полученные ранее от принимающего сообщение LSR.

Приложение A. Процедуры распространения меток LDP содержит дополнительную информацию о процедурах освобождения меток.

3.6. Сообщения и TLV для расширений

Поддержка расширений LDP включает правила для флагов U и F, которые указывают LSR способы обработки неизвестных TLV и сообщений.

В этом разделе описаны TLV и сообщения для фирменных (vendor-private) и экспериментальных расширений.

3.6.1. Расширения LDP Vendor-Private

Фирменные TLV и сообщения служат для передачи между LSR специфичной для производителя информации.

3.6.1.1. LDP Vendor-Private TLV

Диапазон значений поля Type от 0x3E00 до 0x3EFF зарезервирован для фирменных (vendor-private) TLV.

Формат сообщения показан на рисунке.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F|    Type (0x3E00-0x3EFF)   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Vendor ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           Data....                            |
   ~                                                               ~
   |                                                               |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

U

Флаг неизвестного TLV. При получении неизвестного TLV, если U=0, в ответ должно передаваться уведомление, а полученное сообщение должно игнорироваться. Если U=1, неизвестный параметр TLV игнорируется, а остальная часть сообщения обрабатывается, как обычно.

Трактовка сообщения vendor-private определяется полем Type и обязательным полем Vendor ID.

Реализации, поддерживающие фирменные TLV, должны поддерживать доступный для пользователя интерфейс настройки конфигурации, который позволяет задать принудительную установку флага U во всех передаваемых фирменных TLV; это требование можно выполнить за счет доступного пользователю конфигурационного интерфейса, предотвращающего передачу фирменных TLV, в которых флаг U не установлен.

F

Флаг пересылки неизвестных TLV. Этот флаг имеет значение только при установленном бите U и пересылается сообщение, содержащее неизвестное поле TLV. Если F =0, неизвестное поле не пересылается в содержащем его сообщении, а при F=1 неизвестное поле TLV пересылается в сообщении.

Type

Значение типа из диапазона 0x3E00 — 0x3EFF. Поля Type и Vendor ID совместно определяют интерпретацию поля Data.

Length

Указывает суммарный размер полей Vendor ID и Data в октетах.

Vendor ID

Значение 802 для Vendor ID выделенное IEEE.

Data

Остальная часть поля Value после Vendor ID содержит дополнительные данные, трактовка которых определяется производителем.

3.6.1.2. Сообщение LDP Vendor-Private

Значение поля Type в диапазоне 0x3E00 — 0x3EFF зарезервированы для сообщений Vendor-Private.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|    Msg Type (0x3E00-0x3EFF) |      Message Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Message ID                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Vendor ID                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +                                                               +
   |                     Remaining Mandatory Parameters            |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                     Optional Parameters                       |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

U

Флаг неизвестного сообщения. При получении неизвестного сообщения с U=0 отправителю возвращается уведомление, а при U=1 неизвестное сообщение игнорируется без уведомления.

Трактовка сообщений Vendor-Private определяется значениями полей Msg Type и Vendor ID.

Реализации, поддерживающие сообщения Vendor-Private, должны поддерживать доступный пользователю интерфейс для управления принудительной установкой флага U в передаваемых сообщениях Vendor-Private. Это требование может быть выполнено за счет доступного пользователю конфигурационного интерфейса, который позволяет предотвратить передачу сообщений Vendor-Private c U=0.

Msg Type

Значение Type в диапазоне 0x3E00 — 0x3EFF. Поля Msg Type и Vendor ID совместно определяют интерпретацию сообщения.

Message Length

Указывает суммарный размер полей Message ID, Vendor ID, Remaining Mandatory Parameters и Optional Parameters в октетах.

Message ID

32-битовое целое число, служащее для идентификации сообщения. Это поле применяется передающим LSR для сопоставления с сообщениями Notification, которые могут быть связаны с данным сообщением. Маршрутизатор LSR, передающий сообщение Notification в ответ на фирменное сообщение будет включать в уведомление значение поля Message ID (см. параграф 3.5.1. Сообщение Notification).

Vendor ID

Значение 802 для Vendor ID выделенное IEEE.

Remaining Mandatory Parameters

Набор обязательных параметров сообщения (переменный размер).

Optional Parameters

Набор дополнительных параметров сообщения (переменный размер).

3.6.2. Экспериментальные расширения LDP

Поддержка экспериментов в LDP похожа на поддержку фирменных расширений. Отличия перечислены ниже.

  • для экспериментальных TLV зарезервированы значения поля Type в диапазоне от 0x3F00 до 0x3FFF;
  • для экспериментов зарезервированы значения Message Type в диапазоне от 0x3F00 до 0x3FFF;
  • формат экспериментальных TLV и сообщений похож на формат фирменных расширений с перечисленными ниже отличиями:экспериментальные TLV и сообщения используют поле Experiment ID взамен поля Vendor ID; поле Experiment ID используется с полем Type или Message Type, определяющим интерпретацию экспериментального TLV или сообщения.За управление значениями Experiment ID отвечает экспериментатор.

3.7. Список сообщений

Список сообщений LDP, определенных в данной версии протокола, приведен в таблице.

Сообщение

Тип Описание
Notification 0x0001 213.5.1. Сообщение Notification
Hello 0x0100 3.5.2. Сообщение Hello
Initialization 0x0200 3.5.3. Сообщение Initialization
KeepAlive 0x0201 3.5.4. Сообщение KeepAlive
Address 0x0300 3.5.5. Сообщение Address
Address Withdraw 0x0301 3.5.6. Сообщение Address Withdraw
Label Mapping 0x0400 3.5.7. Сообщение Label Mapping
Label Request 0x0401 3.5.8. Сообщение Label Request
Label Withdraw 0x0402 3.5.10. Сообщение Label Withdraw
Label Release 0x0403 3.5.11. Сообщение Label Release
Label Abort Request 0x0404 3.5.9. Сообщение Label Abort Request
Vendor-Private 0x3E00-0x3EFF 3.6.1.2. Сообщение LDP Vendor-Private
Experimental 0x3F00-0x3FFF 3.6.2. Экспериментальные расширения LDP

3.8. Список TLV

Список TLV, определенных в данной версии протокола, приведен в таблице.

TLV

Тип Описание
FEC 0x0100 3.4.1. FEC TLV
Address List 0x0101 3.4.3. TLV для списка адресов
Hop Count 0x0103 3.4.4. TLV для счетчика интервалов
Path Vector 0x0104 3.4.5. TLV для вектора пути
Generic Label 0x0200 3.4.2.1. TLV меток общего назначения
ATM Label 0x0201 3.4.2.2. TLV меток ATM
Frame Relay Label 0x0202 3.4.2.3. TLV для меток Frame Relay
Status 0x0300 3.4.6. Status TLV
Extended Status 0x0301 3.5.1. Сообщение Notification
Returned PDU 0x0302 3.5.1. Сообщение Notification
Returned Message 0x0303 3.5.1. Сообщение Notification
Common Hello Parameters 0x0400 3.5.2. Сообщение Hello
IPv4 Transport Address 0x0401 3.5.2. Сообщение Hello
Configuration Sequence Number 0x0402 3.5.2. Сообщение Hello
IPv6 Transport Address 0x0403 3.5.2. Сообщение Hello
Common Session Parameters 0x0500 3.5.3. Сообщение Initialization
ATM Session Parameters 0x0501 3.5.3. Сообщение Initialization
Frame Relay Session Parameters 0x0502 3.5.3. Сообщение Initialization
Label Request Message ID 0x0600 3.5.7. Сообщение Label Mapping
Vendor-Private 0x3E00-0x3EFF 3.6.1.2. Сообщение LDP Vendor-Private
Experimental 0x3F00-0x3FFF 3.6.2. Экспериментальные расширения LDP

3.9. Список кодов состояния

Список кодов состояния (Status Code), определенных в данной версии протокола, приведен в таблице.

В колонке E показано значение, требуемое для бита E в поле Status Code; Колонка «Данные состояния» содержит значение 30-битового поля Status Data в Status Code TLV. Отметим, что установка флага F в поле Status Code определяется LSR, передающим Status TLV.

Код состояния E Данные состояния Описание
Success 0 0x00000000 3.4.6. Status TLV
Bad LDP Identifier 1 0x00000001 3.5.1.2. События, о которых сигнализируют сообщения Notification
Bad Protocol Version 1 0x00000002 3.5.1.2. События, о которых сигнализируют сообщения Notification
Bad PDU Length 1 0x00000003 3.5.1.2. События, о которых сигнализируют сообщения Notification
Unknown Message Type

0

0x00000004 3.5.1.2. События, о которых сигнализируют сообщения Notification
Bad Message Length

1

0x00000005 3.5.1.2. События, о которых сигнализируют сообщения Notification
Unknown TLV

0

0x00000006 3.5.1.2. События, о которых сигнализируют сообщения Notification
Bad TLV Length

1

0x00000007 3.5.1.2. События, о которых сигнализируют сообщения Notification
Malformed TLV Value

1

0x00000008 3.5.1.2. События, о которых сигнализируют сообщения Notification
Hold Timer Expired

1

0x00000009 3.5.1.2. События, о которых сигнализируют сообщения Notification
Shutdown

1

0x0000000A 3.5.1.2. События, о которых сигнализируют сообщения Notification
Loop Detected

0

0x0000000B 2.8. Детектирование петель
Unknown FEC

0

0x0000000C 3.4.1.1. Процедуры FEC
No Route

0

0x0000000D 3.5.8. Сообщение Label Request
No Label Resources

0

0x0000000E 3.5.8. Сообщение Label Request
Label Resources/Available

0

0x0000000F 3.5.8. Сообщение Label Request
Session Rejected/No Hello

1

0x00000010 2.5.3. Инициализация сессии
Session Rejected/Parameters Advertisement Mode

1

0x00000011 2.5.3. Инициализация сессии
Session Rejected/Parameters Max PDU Length

1

0x00000012 2.5.3. Инициализация сессии
Session Rejected/Parameters Label Range

1

0x00000013 2.5.3. Инициализация сессии
KeepAlive Timer Expired

1

0x00000014 3.5.1.2. События, о которых сигнализируют сообщения Notification
Label Request Aborted

0

0x00000015 3.5.9. Сообщение Label Abort Request
Missing Message Parameters

0

0x00000016 3.5.1.2. События, о которых сигнализируют сообщения Notification
Unsupported Address Family

0

0x00000017 3.4.1.1. Процедуры FEC, 3.5.5.1. Процедуры для сообщений Address
Session Rejected/Bad KeepAlive Time

1

0x00000018 2.5.3. Инициализация сессии
Internal Error

1

0x00000019 3.5.1.2. События, о которых сигнализируют сообщения Notification

3.10. Общепринятые значения

3.10.1. Порты UDP и TCP

Для сообщений LDP Hello используется порт UDP 646.

Для организованных сеансов LDP используется порт TCP 646.

3.10.2. Неявная NULL-метка

Метка Implicit NULL определена в [RFC3031] следующим образом36:

Метка Implicit NULL представляет собой метку специального назначения, которую LSR может связать с адресным префиксом. Если LSR Ru из своего отображения ILM определяет, что помеченный пакет P необходимо переслать маршрутизатору Rd, но Rd распространяет для соответствующего адресного префикса метку Implicit NULL, то вместо замены верхней метки в стеке Ru просто выталкивает метку из стека и пересылает пакет Rd.

Неявная NULL-метка представляется в LDP, как Generic Label TLV с полем Label=3 в соответствии с определением [RFC3032].


1Multiprotocol Label Switching.

2Label Switching Router.

3Label Distribution Protocol.

4Traffic Engineering — построение трафика.

5Label Switched Path.

6Forwarding Equivalence Class.

7Все маршрутизаторы данной подсети — 224.0.0.2. Прим. перев.

8Type-Length-Value — тип, размер, значение.

9Address Prefix FEC element.

10Virtual Channel Identifier — идентификатор виртуального канала.

11Data Link Connection Identifier — иденткификатор соединения на канальном уровне.

12Групповой адрес all routers on this subnet — 224.0.0.2. Прим. перев.

13Virtual Path Identifier/Virtual Channel Identifier — идентификаторы виртуального пути и виртуального соединения.

14Data Link Connection Identifier — идентификатор соединения на канальном уровне.

15Protocol Data Unit — блок данных протокола. Прим. перев.

16Сессия отвергнута / Индикация ошибок в параметрах.

17Сессия отвергнута / Индикация отсутствия ошибок в сообщении Hello.

18Отказ. Прим. перев.

19Downstream On Demand.

20Unsolicited Downstream. В оригинале данного документа используется термин Downstream Unsolicited. Прим. перев.

21Independent LSP Control.

22Ordered LSP Control.

23Conservative Label retention.

24Label Information Base — база информации о метках.

25Loop Detection.

26Генерирует и отправляет свое сообщение или пересылает чужое. Прим. перев.

27Объяснение этой кажущейся странности приведено в параграфе 3.4.4.1. Процедуры подсчета интервалов. Прим. перев.

28Документ цитируется по переводу RFC 2385, опубликованному на сайте www.protocols.ru. Прим. перев.

29Traffic Engineering.

30Protocol data unit.

31Forwarding Equivalence Class.

32В оригинале используется термин bug. Прим. перев.

33В оригинале ошибочно указано LSR. Прим. перев.

34Отметим, что если LSR уже имеет ожидающее отклика сообщение для нового следующего интервала, ему не следует отправлять дополнительное сообщение Label Request в ответ на смену следующего интервала.

35Отметим, что в результате того, что LSR без поддержки слияния должен организовывать отдельный LSP для каждого восходящего партнера, запрашивающего метку, он должен передавать отдельное сообщение Label Request для каждого такого партнера. Следствием этого является то, что не поддерживающий слияния LSR может иметь множество сообщений Label Request для данного FEC, ожидающих завершения обработки.

36Ниже представлен фрагмент перевода RFC 3031, опубликованного на сайте www.protocols.ru. Прим. перев.

Часть 2