RFC 5036 LDP Specification | Энциклопедия сетевых протоколов

Please enter banners and links.

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). Документ можно распространять без ограничений.

Тезисы

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

Оглавление

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

1. Обзор LDP

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

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

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

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

LDP связывает класс эквивалентной пересылки (FEC⁶) [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:

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

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

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

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

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

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

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

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

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

Уведомления об ошибках используются для передачи информации о критических ошибках. Если LSR получает от своего партнера сообщение Error Notification для сессии LDP, он завершает эту сессию, закрывая транспортное соединение TCP для нее и отбрасывая отображения меток, полученные в этой сессии.
Сообщения 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 – «адресный префикс⁹». Этот элемент представляет собой адресный префикс, размер которого может меняться от 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, использующий VCI¹⁰ в качестве меток, или интерфейс Frame Relay, который использует значения DLCI¹¹, как метки.Отметим, что использовать пространство меток масштаба интерфейса имеет смысл лишь в тех случаях, когда партнеры 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 по групповому адресу всех маршрутизаторов подсети¹².

Сообщение 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.

Если у 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 определяется похожим способом:

если LSR2 использует необязательный объект Transport Address, A2 будет адресом, который LSR2 анонсирует в этом объекте;
если LSR2 не использует объект Transport Address, A2 будет адресом отправителя, используемым в сообщениях Hello от LSR2.

LSR1 определяет свою роль (активный или пассивный) в организуемой сессии, путем сравнения адресов A1 и A2, как целых чисел без знака. Если A1 > A2, LSR1 будет играть активную роль, в ином случае – пассивную.Процедура сравнения беззнаковых целых чисел A1 и A2 выполняется следующим образом:

Если адреса A1 и A2 относятся к разным семействам, они являются несравнимыми и сессия не создается.
Пусть U1 будет абстрактным целым числом без знака, которое получается в результате трактовки A1, как последовательности байтов, в которой первый байт адреса, указанный в сообщении, является старшим, а последний байт адреса в сообщении – младшим.U2 получается из адреса A2 таким же способом.
Сравниваются значения U1 и U2. Если U1 > U2, то A1 > A2; если U1 < U2, то A1 < A2.

Если 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/VCI¹³ для меток, управляемых ATM, диапазоны DLCI¹⁴ для меток, управляемых 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 в заголовке PDU¹⁵ сообщения Initialization) с Hello-смежностью, созданной при обмене сообщениями Hello.

LSR1 играет пассивную роль:

При получении сообщения Initialization маршрутизатор LSR1 пытается сопоставить LDP Identifier из PDU принятого сообщения со смежностью Hello.
Если соответствие найдено, оно будет определять пространство меток для этой сессии.После этого LSR1 проверяет приемлемость предложенных параметров сессии. Если параметры устраивают, LSR1 передает ответное сообщение Initialization с желаемыми параметрами и сообщение KeepAlive, показывающее приемлемость предложенных LSR2 параметров. Если параметры не подходят, LSR1 передает сообщение Session Rejected/Parameters Error Notification¹⁶ и закрывает соединение TCP.
Если LSR1 не может найти соответствующей Hello-смежности, он передает сообщение Session Rejected/No Hello Error Notification¹⁷ и закрывает соединение TCP.
Если LSR1 получает сообщение KeepAlive в ответ на свое сообщение Initialization, сессия считается открытой с точки зрения LSR1.
Если LSR1 получает сообщение Error Notification, это говорит о том, LSR2 отказался от предложенной сессии, и LSR1 закрывает соединение TCP.

LSR1 играет активную роль:

Если LSR1 получает сообщение Error Notification, это говорит о том, LSR2 отказался от предложенной сессии, и LSR1 закрывает соединение TCP.
При получении сообщения Initialization маршрутизатор LSR1 проверяет приемлемость предложенных параметров сессии. Если параметры устраивают, LSR1 передает сообщение KeepAlive. Если параметры не подходят, LSR1 передает сообщение Session Rejected/Parameters Error Notification и закрывает соединение.
Если LSR1 получает сообщение KeepAlive, это говорит о том, LSR2 принял предложенные параметры сессии.
Если LSR1 получает сообщение Initialization о приемлемости предложенных параметров и сообщение KeepAlive, сессия считается открытой с точки зрения LSR1.Пока сессия LDP не открыта, никакие сообщения, за исключением упомянутых выше, не могут передаваться и правила обработки бита U в сообщениях LDP не могут меняться. При получении любого сообщения, кроме перечисленных выше, в ответ должно быть передано сообщение Shutdown и транспортное соединение должно быть закрыто.

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

LSR должны экспоненциально снижать частоту попыток организации сессии в ситуациях, когда их сообщения Initialization отвергаются с помощью NAK¹⁸. Рекомендуется также, чтобы 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
OPENREC	Прием любого другого сообщения LDP Действие: Передача сообщения Error Notification (NAK) и разрыв транспортного соединения	NON EXISTENT
OPENSENT	Получение приемлемого сообщения Initialization Действие: Передача сообщения KeepAlive	OPENREC
OPENSENT	Прием любого другого сообщения 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. Этот процесс называется нисходящим распространением меток по запросу¹⁹. Можно также распространять информацию о связывании меток маршрутизаторам LSR, которые явно не запрашивали ее. В [RFC3031] такой метод называется незапрошенным нисходящим распространением²⁰.

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

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

Поведение на начальном этапе организации LSP определяется выбором независимого²¹ или согласованного²² режима управления 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 при выполнении любого из условий:

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

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

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

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

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

В режиме анонсирования Downstream Unsolicited анонсы отображения меток для всех маршрутов могут быть получены от всех партнерских LSR. При использовании консервативного удержания меток²³, анонсируемые привязки меток удерживаются только в тех случаях, когда они будут применяться для пересылки пакетов (т. е. при получении привязок от маршрутизатора, который является корректным следующим интервалом в соответствии с таблицей маршрутизации). При работа в режиме 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 поддерживает полученные от других маршрутизаторов метки в базе данных LIB²⁴. При работе в режиме Downstream Unsolicited запись LIB для адресного префикса связывает с префиксом набор пар (идентификатор LDP, метка) – одна пара для каждого партнера, анонсирующего метку для данного префикса.

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

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

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

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

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

Детектирование петель²⁵ является конфигурационной опцией, которая обеспечивает механизм нахождения замкнутых 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 распространяет²⁶ сообщение, содержащее 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)²⁷.

Процедуры детектирования петель 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

Приведенные ниже фрагменты²⁸ [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 с явной маршрутизацией

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

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

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

Обмен сообщениями LDP реализуется путем передачи модулей данных протокола (LDP PDU³⁰) через 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

Метки привязываются к классам эквивалентной пересылки (FEC³¹). 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

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

Двухбитовый индикатор типа коммутации. Значение 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 в таких случаях также должен:

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

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

обнаружена петля;
достигнут выход LSP;
достигнут максимальный размер 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 в таких случаях также должен:

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

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

обнаружена петля;
достигнут вход LSP;
достигнут максимальный размер 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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Этот флаг следует использовать так же, как одноименный флаг в поле 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                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Флаг управления пересылкой. При установленном (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.

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; причиной таких ситуаций могут служить программные ошибки³² на приемном или передающем 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 следующим образом:

LSR проверяет возможность восприятия Hello. Критерии допустимости восприятия зависят от реализации (ниже приведен пример таких критериев).
Если сообщение Hello неприемлемо, LSR игнорирует его.
Если сообщение Hello приемлемо, LSR проверяет наличие Hello-смежности с отправителем этого сообщения. При наличии смежности перезапускается таймер удержания. Если смежность еще не организована, она создается и запускается таймер удержания.
Если сообщение Hello содержит дополнительные TLV, LSR обрабатывает их (см. ниже).
В заключение, если 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

Одно или несколько полей 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

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

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

Формат представления 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

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 при возникновении любого из перечисленных ниже условий:

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

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

3.5.7.1.2. Упорядоченное управление отображением

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

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

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

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, через которые будет организован путь LSP³³ с помощью сообщения Label Request. Обработка этого TLV описана в параграфе 3.4.5.1. Процедуры Path Vector.

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

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

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

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

Принимающему 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 при следующих обстоятельствах:

следующий интервал на Ru для класса FEC был изменен с LSR Rd на LSR X;
Ru не является входным LSR, не поддерживает слияние и также получил сообщение Label Abort Request для FEC от восходящего партнера Y;
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 при выполнении следующих условий:

данный LSR больше не распознает ранее известный класс FEC, для которого он анонсировал метку;
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

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

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

Label

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

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

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

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

маршрутизатор LSR, который передал отображение метки, больше не является следующим интервалом для отображаемого класса FEC, а LSR настроен на консервативное удержание;
маршрутизатор LSR получил отображение метки от LSR, который не является следующим интервалом для FEC, а LSR настроен на консервативное удержание;
маршрутизатор 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....                            |
   ~                                                               ~
   |                                                               |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Трактовка сообщения vendor-private определяется полем Type и обязательным полем Vendor ID.

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

Флаг пересылки неизвестных 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=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] следующим образом³⁶:

Метка 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, опубликованному на сайте 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, опубликованного на сайте protocols.ru. Прим. перев.

Часть 2