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

Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru

L. Andersson RFC-3036, January 2001

1. Обзор LDP

Архитектура MPLS [RFC3031] определяет протокол рассылки меток как набор процедур, с помощью которых один LSR (Label Switched Router) информирует другого о значении меток, используемых для переадресации трафика между ними и через них.

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

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

LDP ставит в соответствие FEC (Forwarding Equivalence Class) [RFC3031] каждому LSP, который он создает. FEC ассоциированный с LSP определяет, какие пакеты должны следовать по этому LSP. LSP прокладываются через сеть так, что каждый LSR обеспечивает стыковку входной метки для FEC с выходной меткой, соответствующей следующему шагу для данного FEC. Дополнительные данные о применении LDP можно найти в [RFC3037].

В данной статье предполагается знакомство с архитектурой MPLS [RFC3031]. Заметим также, что [RFC3031] содержит словарь терминов MPLS.

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

1.1. LDP партнеры

Два LSR, которые используют LDP для обмена информацией о соответствии метка-FEC, называются "LDP партнерами", между которыми реализуется "LDP сессия". LDP сессия позволяет каждому партнеру познакомиться с соответствием меток друг у друга; т.e., протокол является двунаправленным.

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

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

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

Сообщения выявления предоставляют механизм, посредством которого LSR оповещает о своем присутствии в сети посредством периодической посылки сообщения Hello. Оно посылается в виде UDP-пакета на вход LDP-порта всем маршрутизаторам субсети через групповой мультикастинг-адрес. Когда LSR решает установить сессию с другим LSR, опознанным с помощью сообщения Hello, он использует процедуру инициализации LDP с привлечением протокола TCP. При успешном завершении процедуры инициализации, два LSR становятся LDP-партнерами, и могут обмениваться сообщениями анонсирования.

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

Корректная работа LDP требует надежной и упорядоченной доставки сообщений. Чтобы удовлетворить этим требованиям LDP использует в качестве транспортного протокола TCP для сообщений сессий, предупреждений и анонсирования; т.e., для любых обменов кроме механизмов выявления, базирующихся на UDP.

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

Все сообщения LDP имеют общую структуру, которая использует схему кодирования TLV (Type-Length-Value) тип-длина-значение; смотри раздел кодирования "Тип-длина-значение". Значение является объектом, кодируемым по схеме TLV, и может содержать одно или более TLV.

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

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

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

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

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

2. Работа LDP

2.1. FEC

Необходимо точно определить, какие пакеты могут быть поставлены в соответствие каждому LSP. Это делается с помощью FEC-спецификации для каждого LSP. FEC идентифицирует набор пакетов, которые могут быть ассоциированы с данным LSP.

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

Ниже определяются типы элементов FEC. Если потребуется, может быть добавлен новый FEC:

1. Адресный префикс. Этот элемент является адресным префиксом произвольной длины от 0 до полного адреса включительно.
2. Адрес ЭВМ. Этот элемент является полным адресом ЭВМ.

Мы говорим, что определенный адрес согласуется с заданным адресным префиксом, если и только если адрес начинается с этого префикса. Мы также говорим, что определенный пакет соответствует заданному LSP, если и только если LSP имеет адресный префикс FEC элемента, который согласуется с адресом места назначения пакета.

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

1. Если имеется только один LSP, который содержит FEC элемент адреса ЭВМ, идентичный адресу места назначения пакета, тогда пакет ассоциируется с данным LSP.
2. Если имеется несколько LSP, содержащих FEC элемент адреса ЭВМ, который идентичен адресу назначения пакета, тогда пакет ассоциируется с одним из этих LSP. Процедура выбора одного из этих LSP в данном документе не рассматривается.
3. Если пакет в точности соответствует одному LSP, пакет ассоциируется с этим LSP.
4. Если пакет соответствует нескольким LSP, он ассоциируется с LSP, чей префикс длиннее. Если более длинного префикса выявить не удается, пакет ассоциируется с одним из LSP, чей префикс длиннее других. Процедура выбора одного из этих LSP в данном документе не рассматривается.
5. Если известно, что пакет должен пройти через определенный выходной маршрутизатор, и имеется LSP, который имеет элемент FEC адресного префикса, являющийся адресом этого маршрутизатора, тогда пакет ассоциируется с этим LSP. Процедура выбора одного из этих LSP в данном документе не рассматривается.

Целесообразно отметить несколько следствий этих правил:

1. Пакет может быть послан по LSP, чей адресный префикс элемента FEC является адресом выходного маршрутизатора, ТОЛЬКО если нет LSP, согласующихся с адресом места назначения пакета.
2. Пакет может соответствовать двум LSP, одному с FEC элементом адреса ЭВМ, а другому с FEC элементом префикса адреса. В этом случае пакеты ассоциируются всегда со вторым из этих LSP.
3. Пакет, который не соответствует определенному FEC-элементу адреса ЭВМ, не может быть послан по соответствующему LSP, даже если FEC элемент адреса ЭВМ идентифицирует выходной маршрутизатор для данного пакета.

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

Выражение "пространство меток" полезно для обсуждения присвоения и рассылки меток:

1. Пространство меток интерфейса. Входные метки, специфичные для интерфейса, применяются для интерфейсов, которые используют для меток ресурсы интерфейса. Примером такого интерфейса является АТМ-интерфейс, который использует в качестве меток VCI, или интерфейс Frame Relay, который использует в качестве меток DLCI.

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

2. Пространство меток платформы. Входные метки, ориентированные на платформу, используются для интерфейсов, которые совместно используют одни и те же метки.

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

Идентификатор LDP представляет собой 6-октетный код, используемый для идентификации пространства меток LSR. Первые четыре октета идентифицируют LSR и должны быть глобально уникальными, такими как 32-битный идентификатор маршрутизатора, присвоенный LSR. Последние два октета идентифицируют специфическое пространство меток LSR. Последние два октета идентификаторов LDP для ориентированного на платформу пространства меток всегда равны нулю. В данном документе используется следующее представление идентификаторов LDP:

<LSR Id> : <label space id>

напр., lsr 171:0, lsr19:2.

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

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

2.2.3. Сессии LDP

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

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

Для сессий LDP использует TCP, как надежную транспортную среду. Когда нужно несколько LDP сессий между двумя LSR, реализуется по одной 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, позволяет LSRb помечать и коммутировать трафик, поступающий из LSP.

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

2.4. Выявление LDP (Discovery)

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

• Базовый механизм выявления используется для детектирования соседних LSR, которые непосредственно соединены на канальном уровне.
• Расширенный механизм выявления используется для нахождения LSR, которые не имеют непосредственных связей на канальном уровне.

2.4.1. Базовый механизма выявления

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

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

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

2.4.2. Расширенный механизм выявления

Сессии LDP между несвязанными напрямую LSR поддерживаются расширенным механизмом выявления партнеров.

Чтобы запустить расширенный механизм выявления, LSR периодически посылает в LDP адресуемые сообщения Hello (Targeted Hello) по определенным адресам. Адресуемые сообщения Hello посылаются в виде UDР-пакетов, направленных в стандартный порт выявления по специфицированному адресу.

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

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

Один LSR инициирует процесс расширенного выявления в отношении другого LSR, а адресуемый LSR решает, следует ли откликаться или игнорировать данное сообщение адресного Hello. Адресуемый LSR, который решил откликаться, реагирует периодической посылкой адресного Hello LSR-инициатору.

Отклик на адресное Hello идентифицирует сопредельность с потенциальным LDP партнером, достижимым на сетевом уровне, и пространство меток, которое партнер намерен использовать.

2.5. Установление сессий LDP и управление ими
2.5.1. Установление сессии LDP

Обмен сообщениями выявления партнеров между двумя LSR запускает LDP сессию. Сессия формируется в два этапа:

1. Установление транспортного соединения.
2. Инициализация сессии

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

2.5.2. Установление транспортного соединения

Результатом обмена сообщениями Hello является формирование Hello сопредельности для LSR1, которое определяет канал связи (L), и пространства меток LSR1:a и LSR2:b.

1. Если LSR1 не имеет LDP сессии обмена пространствами меток LSR1:a и LSR2:b, он пытается сформировать TCP-соединение для новой LDP сессии с LSR2.

   LSR1 определяет транспортные адреса, которые следует использовать на конце (A1) и на конце LSR2 (A2) TCP-соединения. Адрес A1 определяется следующим образом:

   1. Если LSR1 использует опционный объект, в сообщениях Hello LSR2 он посылает транспортный адрес (TLV), чтобы анонсировать адрес. A1 является адресом, который анонсируется LSR1 через посредство опционного объекта;
   2. Если LSR1 не использует опционный объект транспортного адреса, A1 является адресом отправителя в сообщениях Hello, которые отправляет LSR2.

   Аналогично, адрес A2 определяется как:

   1. Если LSR2 использует опционный объект транспортного адреса, A2 является адресом, который LSR2 анонсирует через посредство опционного объекта;
   2. Если LSR2 не использует опционный объект транспортного адреса, A2 является адресом отправителя в сообщении Hello, полученном от LSR2.
2. LSR1 определяет, будет ли он играть активную или пассивную роль в сессии установления, посредством сравнения адресов A1 и A2, как целых чисел без знака. Если A1 > A2, LSR1 играет активную роль; в противном случае - пассивную.

   Процедура сравнения A1 и A2 реализуется следующим образом:

   1. Если A1 и A2 принадлежат разным адресным семействам, они несравнимы, и сессия не может быть реализована.
   2. Пусть U1 является абстрактным целым числом без знака, полученным от A1 в виде последовательности байт, где байт, полученный первым, является наиболее значимым, а байт, полученный последним, является наименее значимым.

      Пусть U2 является абстрактным целым числом без знака, полученным от A2 аналогичным образом.

   3. Сравниваем U1 с U2. Если U1 > U2, тогда A1 > A2; если U1 < U2, тогда A1 < A2.
3. Если LSR1 является активным, он пытается установить TCP-соединение через стандартный номер порта по адресу A2. Если LSR1 является пассивным, он ждет, пока LSR2 не установит TCP-соединение через стандартный номер порта.

Заметим, что когда LSR посылает сообщение Hello, он выбирает транспортный адрес конца соединения сессии и использует Hello, чтобы анонсировать адрес, либо явно путем включения его в опционный TLV транспортного адреса или неявно, опуская TLV, и используя его в качестве адреса отправителя в сообщении Hello.

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

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

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

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

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

Вообще, когда существует несколько каналов между LSR1 и LSR2 и несколько пространств меток, которые им нужно анонсировать, пассивный LSR не может знать, какое пространство меток следует анонсировать через вновь установленное TCP-соединение, до тех пор пока не получит сообщение инициализации. Сообщение инициализации содержит в себе идентификатор LDP для пространства меток отправителя (активный LSR) и идентификатор LDP для пространства меток получателя (пассивный LSR).

Ожидая сообщение инициализации от своего партнера, пассивный LSR может согласовать пространство меток, которое должно анонсироваться партнером (как это определено идентификатором LDP в заголовке PDU сообщения инициализации), с сопредельностью Hello, сформированной при обмене сообщениями Hello.

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

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

   Далее LSR1 проверяет, являются ли приемлемыми предложенные в сообщении параметры сессии. Если да, LSR1 откликается сообщением инициализации с параметрами, которые он намерен использовать, и сообщением KeepAlive, чтобы сообщить о приемлемости параметров LSR2. Если параметры не приемлемы, LSR1 откликается сообщением об ошибке Session Rejected/Parameters и закрывает TCP-соединение.

3. Если LSR1 не может найти подходящую сопредельность Hello (Hello adjacency), он посылает сообщение об ошибке Session Rejected/No Hello Error и закрывает TCP-соединение.
4. Если в ответ на сообщение инициализации LSR1 получает KeepAlive, сессия с точки зрения LSR1 является рабочей.
5. Если LSR1 получает сообщение об ошибке, LSR2 отклоняет предложенную сессию и LSR1 закрывает TCP-соединение.

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

1. Если LSR1 получает сообщение об ошибке, LSR2 отвергает предложенную сессию, а LSR1 закрывает TCP-соединение.
2. Если LSR1 получает сообщение инициализации, он проверяет, приемлемы ли параметры сессии. Если да, то откликается сообщением KeepAlive. Если параметры сессии не приемлемы, LSR1 посылает сообщение об ошибке Session Rejected/Parameters и закрывает соединение.
3. Если LSR1 получает сообщение KeepAlive, LSR2 воспринял предложенные им параметры сессии.
4. Когда LSR1 получил как приемлемое сообщение инициализации, так и сообщение KeepAlive, сессия с точки зрения LSR1 работоспособна.

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

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

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

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

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

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

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

Таблица переходов между состояниями при инициализации сессии

Состояние	Событие	Новое состояние
NON EXISTENT	Сессия TCP-соединения установлена	INITIALIZED
INITIALIZED	Передача сообщения инициализации (Активная роль)	OPENSENT
	Получение приемлемого сообщения инициализации. (Пассивная роль)	OPENREC
	Действие: Передача сообщения инициализации и KeepAlive
	Получение любого другого сообщения LDP	NON EXISTENT
	Действие: Передача сообщения об ошибке (NAK) и закрытие транспортного соединения
OPENREC	Получение сообщения KeepAlive	OPERATIONAL
	Получение любого другого сообщения LDP	NON EXISTENT
	Действие: Передача сообщения об ошибке (NAK) и закрытие транспортного соединения
OPENSENT	Получение приемлемого сообщения инициализации	OPENREC
	Действие: Передача сообщения KeepAlive
	Получение любого другого сообщения LDP	NON EXISTENT
	Действие: Передача сообщения об ошибке (NAK) и закрытие транспортного соединения
OPERATIONAL	Получение сообщения Shutdown	NON EXISTENT
	Действие: передача сообщения Shutdown и закрытие транспортного соединения
	Получение других сообщений LDP	OPERATIONAL
	Таймаут	NON EXISTENT
	Действие: Передача сообщения завершения и закрытие транспортного соединения

2.5.5. Поддержка сопредельности Hello

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

LDP имеет механизмы выявления необходимости LDP сессии и ее Hello сопредельностей.

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

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 сессию с партнером в любой момент времени. Если LSR принял такое решение, ему следует проинформировать партнера об этом с помощью сообщения Shutdown.

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

Архитектура MPLS [RFC3031] позволяет LSR рассылать данные о соответствии FEC и метки в ответ на прямой запрос другого LSR. Это называется рассылкой меток вниз по течению по запросу (Downstream On Demand). Это также позволяет LSR рассылать метки LSR, которые не запрашивали этого явно. [RFC3031] называет этот метод рассылки меток свободной рассылкой вниз по течению (Unsolicited Downstream); в данном документе этот метод называется Downstream Unsolicited.

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

2.6.1. Режим управления рассылкой меток

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

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

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

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

2.6.1.2. Упорядоченный режим управления рассылкой меток

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

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

Заметим, тот факт, что LSR является выходным для данного FEC, может измениться со временем, в зависимости от состояния сети и конфигурации LSR.

2.6.2. Режим сохранения метки (Retention)

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

2.6.2.1. Консервативный режим сохранения метки

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

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

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

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

2.7. Идентификаторы LDP и адреса следующего шага

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

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

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

Чтобы LSR мог установить соответствие между идентификаторами партнеров LDP и их адресами, LSR передают свои адреса, используя сообщения Address и Withdraw Address (отзыв адреса).

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

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

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

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

1. TLV вектора пути содержит список LSR, через которые проходит сообщение, его содержащее. LSR идентифицируется в списке вектора с помощью уникальных Id LSR, которые являются первыми четырьмя октетами идентификатора его LDP. Когда LSR передает сообщение, содержащее TLV вектора пути, он добавляет в список вектора пути свой идентификатор (Id LSR). LSR, который получает сообщение с вектором пути, содержащим его Id, регистрирует, что сообщение прошло по замкнутому пути (по петле). LDP поддерживает понятие максимально допустимой длины вектора пути. LSR, который детектирует, что вектор пути достиг максимальной длины, поступает также как в случае регистрации петлевого маршрута.
2. TLV числа шагов содержит число LSR, которые сообщение, содержащее его, прошло. Когда LSR пересылает сообщение, содержащее TLV числа шагов, он увеличивает это число на 1. LSR, который регистрирует, что число шагов достигло заданного при конфигурации максимума, ведет себя так, как если бы была зарегистрирована петля. Согласно договоренности число 0 интерпретируется, как неизвестное число шагов. Инкрементирование такого значения сохраняет его величину (unknown =0).

Заметим, что TLV числа шагов и его процедуры используются без TLV вектора пути в ситуации, когда детектирование петель не предусмотрено на уровне конфигурации (смотри [RFC3035] и [RFC3034]).

2.8.1. Сообщение запроса метки

Использование TLV вектора пути и числа шагов предотвращает зацикливание сообщений запросов метки в среде, содержащей LSR, не поддерживающие объединение меток (non-merge).

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

1. Сообщение запроса метки должно включать в себя TLV числа шагов.
2. Если R посылает запрос метки, из-за того, что он является входным, он должен включить в сообщение TLV числа шагов со значением равным 1.
3. Если R посылает запрос метки, как результат получения запроса метки от вышестоящего LSR, и если полученный запрос содержит TLV числа шагов, R должен инкрементировать значение счетчика на 1 и положить результат в TLV числа шагов сообщения запроса метки, передаваемого следующему узлу вдоль маршрута;

Правила, которые управляют использованием TLV вектора пути в сообщениях запроса метки, посылаемых LSR R (детектирование петель активировано) представлены ниже:

1. Если R посылает запрос метки, из-за того, что он является входным, тогда, если R не поддерживает объединение меток, он должен включить TLV вектора длины со значением 1, содержащее его собственный идентификатор LSR Id.
2. Если R посылает запрос метки, как результат получения запроса метки от вышестоящего LSR, тогда, если полученный запрос содержит TLV вектора длины или если R не поддерживает объединение меток, то:

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

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

Если R получает сообщение запроса метки от узла следующего шага с TLV числа шагов, которое превышает сконфигурированный максимум, или с TLV вектора пути, содержащий его собственный Id или который превышает допустимый предел длины, тогда R считает, что запрос метки прошел через петлю.

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

2.8.2. Сообщение присвоения метки (Mapping)

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

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

1. R должен включать TLV числа шагов.
2. Если R является выходным, значение числа шагов должно быть равно 1.
3. Если сообщение присвоения метки посылается в ответ на сообщение, полученное от соседа выше по течению, число шагов должно быть определено следующим образом:
   • Если R входит в набор LSR домена, чьи LSR не выполняют декрементацию TTL (напр., область ATM LSR или домен Frame Relay LSR), а партнер выше по течению находится в этой области, R должен сделать число шагов равным 1, прежде чем пересылать сообщение дальше.
   • В противном случае, R должен инкрементировать число шагов, полученное от соседа, прежде чем пересылать сообщение дальше.
4. Если сообщение присвоения метки посылается с целью дальнейшей рассылки, число шагов должно быть результатом инкрементации значения, известного R из предыдущих сообщений присвоения меток. Заметим, что это значение числа шагов будет неизвестным, если R не получил сообщения о выделении метки от своего соседа.

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

5. Если R является выходным, сообщение выделения метки не обязано содержать TLV вектора пути.
6. Если R посылает сообщение выделения метки с целью дальнейшей рассылки метки, полученной от вышестоящего соседа, тогда:
   • Если R может объединять метки и если R не посылал ранее сообщений присвоения метки партнеру выше по течению, тогда он должен включить TLV вектора маршрута.
   • Если полученное сообщение содержит неизвестное число шагов, тогда R должен включить TLV вектора пути.
   • Если R послал ранее сообщение выделения метки вышестоящему партнеру, тогда он должен включить TLV вектора пути, если полученное сообщение уведомляет об увеличении числа шагов LSP, изменении числа от неизвестного к известному или от известного к неизвестному.

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

   • Если полученное сообщение о выделении метки содержит вектор пути, вектор пути, посылаемый вверх по течению, должен быть результатом добавления к нему идентификатора R Id.
   • Если полученное сообщение не имеет вектора пути, вектор пути, посланный вверх по течению должен иметь длину вектора пути равную 1 и содержать идентификатор R Id.
7. Если сообщение присвоения метки не было послано для распространения вверх по течению, сообщение присвоения метки должно включать вектор пути с длиной 1 и идентификатор R Id.

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

Когда R детектирует петлю, он должен прекратить использование метки для переадресации, отбросить сообщение присвоения метки, и с помощью специального сообщения сигнализировать отправителю о детектировании петли.

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

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

LSR, которые сконфигурированы для детектирования петель, могут не запоминать векторы пути в качестве части состояния LSP.

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

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

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

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

Механизм базируется на применении опции подписи TCP MD5, описанной в [RFC2385] для BGP. Смотри описание хэш-функций MD5 в [RFC1321].

2.9.1. Опция подписи TCP MD5

Следующие выдержки из [RFC2385] характеризуют безопасность, достижимую при использовании опции подписи TCP MD5:

"IESG заявление

Этот документ описывает существующую практику обеспечения безопасности BGP против определенного типа простых атак. Понятно, что система имеет определенные слабости в отношении некоторых атак".

"Аннотация

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

"Введение

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

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

Наконец, не существует процедуры согласования использования этой опции при соединении, скорее это является вопросом политики, использовать данную опцию или нет".

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

Так как данный меморандум был сначала выпущен под другим заголовком, алгоритм MD5 был признан уязвимым для атак поиска столкновений [Dobb], и рассматривался как недостаточно строгий для данного типа соединений".

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

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

На этом выдержки из [RFC2385] завершаются

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

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

1. Использование подписи MD5 для TCP соединений является конфигурируемой опцией LSR.
2. LSR, который использует опцию подписи MD5, конфигурируется с привлечением пароля (совместно используемый секретный ключ) для каждого потенциального партнера LDP.
3. LSR использует алгоритм MD5, как это специфицировано в [RFC2385], чтобы вычислить дайджест MD5 для TCP сегмента, посылаемого партнеру. При этом вычислении используется пароль партнера и сам TCP сегмент.
4. Когда LSR получает TCP сегмент с дайджестом MD5, он проверяет сегмент, вычисляя дайджест MD5 (используя свою запись пароля) и сравнивает вычисленный дайджест с полученным. Если сравнение неудачно, сегмент отбрасывается, а отклик отправителю не посылается.
5. LSR игнорирует сообщения LDP Hello от любого LSR, для которого не был сконфигурирован пароль. Это гарантирует, что LSR устанавливает TCP соединение только с LSR, для которого пароль был задан.

2.10. Рассылка меток для LSP, маршрутизированных явно

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

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

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

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

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

3.1. LDP PDU

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

Версия

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

Длина PDU

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

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

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

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

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

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

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

1. Выявление партнера;
2. Управление сессией;
3. Рассылка меток;
4. Уведомление об ошибках и справочная информация.

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

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

3.3. Кодирование TLV (тип-длина-значение)

LDP использует для кодирования информации, транспортируемой в LDP сообщениях, схему TLV (Type-Length-Value = тип-длина-значение).

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

U бит

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

F бит

Бит переадресации неизвестного TLV. Этот бит используется лишь в случае U=1 и сообщение LDP, содержащее неизвестный TLV, нужно переадресовать. Если F=0, неизвестный TLV не переадресуется вместе содержащим его сообщением; если F=1, неизвестный TLV переадресуется.

Тип

Определяет, как следует интерпретировать поле значение.

Длина

Специфицирует длину поля значение в октетах.

Значение

Строка октетов с длиной, определяемой полем длина, где закодирована информация согласно с содержимым поля тип.

Заметим, что не существует требований по выравниванию для первого октета TLV. Заметим также, что само поле значение может содержать TLV. То есть, TLV могут вкладываться друг в друга.

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

Некоторые TLV, определенные для LDP аналогичны некоторым другим. Например, существует TLV общей метки, TLV метки ATM, и TLV Frame Relay; смотри разделы "TLV общей метки", "TLV метки ATM", и "TLV Frame Relay".

Спецификация присваивает значения типа TLV, таким как TLV метки, из смежного блока 16-битового пространства TLV типа.

3.4. Кодирование TLV для универсальных параметров

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

3.4.1. FEC TLV

Метки связаны с FEC (Forwarding Equivalence Class). FEC представляет собой список из одного или более элементов FEC. TLV FEC кодирует значения FEC. Формат представления FEC показан ниже:

Элементы FEC от 1 до n

Существует несколько типов элементов FEC; смотри раздел "FEC". Кодирование элементов FEC зависит от типа элемента.

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

Значения элемента FEC кодируется следующим образом:

Название элемента FEC	Тип	Значение
Wildcard	0x01	Нет значения; т.e., 0 октетов значения; смотри ниже
Префикс	0x02	Смотри ниже
Адрес ЭВМ	0x03	Полный адрес ЭВМ; смотри ниже

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

Элемент Wildcard FEC

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

Семейство адресов

Двухоктетная величина, содержащая значение из списка кодов семейств адресов (смотри [RFC1700]), которое характеризует семейство адресов для адресного префикса в поле префикс.

PreLen

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

Префикс

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

Элемент FEC адреса ЭВМ имеет формат, описанный ниже:

Семейство адресов

Двухоктетная величина, содержащая значение из списка кодов семейств адресов (смотри [RFC1700]), которое характеризует семейство адресов для адресного префикса в поле префикс.

Длина адреса ЭВМ

Длина адреса ЭВМ в октетах.

Адрес ЭВМ

Адрес, закодированный согласно полю семейство адресов.

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

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

Если он сталкивается с типом элемента FEC, который он не может декодировать, ему следует прервать декодирование FEC TLV, прервать обработку сообщения, содержащего TLV, и послать LDP партнеру уведомление "Unknown FEC" (неизвестный FEC), сигнализируя об ошибке.

3.4.2. TLV метки

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

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

3.4.2.1. TLV типовой метки

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

Метка

Это 20-битовый код метки, как это специфицировано в [RFC3032].

3.4.2.2. TLV меток ATM

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

Res

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

V-биты

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

VPI

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

VCI

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

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

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

Res

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

Len

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

0 = 10 бит DLCI

2 = 23 бит DLCI

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

DLCI

Идентификатор соединения канала данных (Data Link Connection). По вопросам значения меток и их форматов отсылаем в [RFC3034].

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

TLV списка адресов встречаются в сообщениях адреса и отзыва адреса. Их формат представлен ниже:

Семейство адресов

Двухоктетная величина, содержащая код семейства адресов, (смотри [RFC1700]), которая определяет схему кодирования поля адреса.

Адреса

Список адресов из специфицированного семейства. Представление индивидуального адреса зависит от типа семейства адресов.

Следующие представления адресов определены данной версией протокола:

3.4.4. TLV числа шагов

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

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

Значение HC

1 октетное целое число без знака равное числу шагов.

3.4.4.1. Процедуры числа шагов

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

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

1. Если это сообщение запроса метки, R должен инкрементировать полученное значение числа шагов;
2. Если это сообщение присвоения метки, R определяет число шагов следующим образом:

• Если R является одним из пограничных LSR домена, где не производится декрементация TTL, а вышестоящий партнер находится внутри домена, R, преже чем пересылать сообщение, должен сбросить счетчик числа шагов в 1.
• В противном случае, R должен инкрементировать полученное число шагов.

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

По соглашению значение 0 говорит, что число шагов неизвестно. Результатом инкрементации неизвестного числа шагов остается значение 0.

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

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

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

Если сконфигурировано детектирование петель, LSR должен следовать процедурам, рассмотренным в разделе "Детектирование петель".

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

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

Один или более LSR Id

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

3.4.5.1. Процедуры вектора пути

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

3.4.5.1.1. Вектор пути запроса метки

Раздел "детектирование петель" специфицирует ситуации, когда LSR должен включить TLV вектора пути в сообщение запроса метки.

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

LSR должен:

1. Послать сообщение уведомления LSR-отправителю, сигнализируя, что "Обнаружена петля".
2. Не передавать дальше сообщение запроса метки.

Заметим, что сообщение запроса метки с TLV вектора пути переадресуется до тех пор пока:

1. Будет найдена петля,
2. Будет достигнут конец LSP,
3. Будет достигнут верхний предел длины вектора пути или числа шагов. Это обрабатывается как, если бы была детектирована петля пути.

3.4.5.1.2. Вектор пути в случае присвоения метки

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

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

1. Передать LSR-отправителю сообщение освобождения метки (Label Release), несущее в себе TLV статуса, сигнализируя о "Детектировании петли".
2. Не передавать сообщение дальше.
3. Проверить, относится ли сообщение присвоения метки к существующему LSP. Если это так, LSR должен разъединить любые метки выше по течению, которые объединены для области вниз по течению для заданного FEC.

Заметим, что сообщение присвоения метки с TLV вектора расстояния переадресуется до тех пор пока:

1. Не обнаружена петля,
2. Достигнуто начало LSP, или
3. Достигнут максимум вектора пути или числа шагов. Это обрабатывается, как если бы была детектирована петля.

3.4.6. TLV статуса

Сообщения уведомления несут в себе TLV статуса, чтобы специфицировать события, о которых уведомляется адресат. Кодирование TLV состояния:

U бит

Должно быть равно нулю, когда TLV статуса послано в сообщении уведомления. Должно быть равно 1, когда TLV статуса послано в другом сообщении.

F бит

Должен быть тем же самым, что и в поле кода статуса.

Код статуса

32-битовое целое без знака, характеризующее событие. Структура кода статуса представлена ниже:

E бит

Бит фатальной ошибки. Если E=1, это уведомление о фатальной ошибке. Если Е=0, это сообщение-рекомендация.

F бит

Бит переадресации. Если F=1, уведомление должно быть переадресовано LSR для следующего или предыдущего шага LSP, ассоциированного с событием, о котором сигнализирует. Если F=0, уведомление не должно переадресовываться.

Статусные данные

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

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

Статусный код 0 сигнализирует об успехе.

ID сообщения

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

Тип сообщения

Если не равно нулю, то это тип сообщения партнера, к которому относится TLV статуса. Если нуль, то TLV статуса не относится ни к какому определенному сообщению партера.

Заметим, что использование TLV статуса не ограничивается сообщениями уведомления. Сообщение, отличное от уведомления может содержать TLV статуса в качестве опционного параметра. Когда сообщение, отличное от уведомления, содержит TLV статуса, U-бит TLV статуса должен равняться 1, чтобы индицировать, что получателю следует молча отбросить TLV, если он не готов его обработать.

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

Все сообщения LDP имеют следующий формат:

U бит

Бит неизвестного сообщения. При получении неизвестного сообщения, если U=0, в качестве отклика отправителю посылается уведомление; если U=1, неизвестное сообщение молча игнорируется.

Тип сообщения

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

Длина сообщения

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

ID сообщения

32-битовый код, используемый для идентификации этого сообщения. Используется LSR-отправителем, чтобы облегчить идентификацию сообщений уведомления. LSR, отправляющий сообщение уведомления в ответ на это сообщение, должен включить этот Id в TLV статуса, транспортируемый данным сообщением; смотри раздел "Сообщение уведомления".

Обязательные параметры

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

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

Опционные параметры

Набор опционных параметров сообщения, имеющий переменную длину.

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

Имя сообщения	Заголовок секции
Уведомление	"Сообщение уведомления"
Hello	" Сообщение Hello "
Инициализация	"Сообщение инициализации"
KeepAlive	"Сообщение KeepAlive "
Адрес	"Сообщение адреса"
Отзыв адреса	"Сообщение отзыва адреса"
Присвоение метки	" Сообщение присвоения метки "
Запрос метки	"Сообщение запроса метки"
Запрос ликвидации метки	"Сообщение запроса ликвидации метки"
Отзыв метки	" Сообщение отзыва метки "
Освобождение метки	"Сообщение освобождения метки"

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

3.5.1. Сообщение уведомления

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

ID сообщения

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

TLV статуса

Индицирует сигнализируемое событие. Кодирование TLV статуса смотри в разделе "TLV статуса".

Опционные параметры

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

Опционный параметр	Тип	Длина	Значение
Расширенный статус	0x0301	4	Смотри ниже
Присланный PDU	0x0302	Переменная	Смотри ниже
Сообщение-отклик	0x0303	Переменная	Смотри ниже

Могут появиться и другие опционные параметры, специфичные для конкретного события.

Расширенный статус

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

Присылаемый PDU

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

Возвращаемое сообщение

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

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

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

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

3.5.1.2. Информирование о событиях с помощью сообщений уведомления

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

3.5.1.2.1. Некорректный PDU или сообщение

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

1. Идентификатор LDP в заголовке PDU неизвестен получателю, или он известен, но этот идентификатор не ассоциирован получателем с партнером LDP для этой сессии. Это фатальная ошибка, сигнализируемая кодом состояния Bad LDP Identifier (некорректный идентификатор).
2. Версия протокола LDP не поддерживается получателем, или он поддерживается, но это не та версия, которая согласована при установлении сессии. Это фатальная ошибка, сигнализируемая кодом статуса Bad Protocol Version (плохой код версии).
3. Поле длины PDU слишком мало (< 14) или слишком велико (> максимальной длины PDU). Это фатальная ошибка, сигнализируемая кодом состояния Bad PDU Length (неверная длина PDU).

   LDP-сообщение некорректно, если:

4. Тип сообщения неизвестен.

   Если тип сообщения < 0x8000 (старший бит = 0) - это ошибка, сигнализируемая кодом статуса Unknown Message Type (неизвестный тип сообщения). Если тип сообщения >= 0x8000 (старший бит = 1), оно молча отбрасывается.

5. Длина сообщения слишком велика, то есть, индицирует, что сообщение занимает места больше, чем отведено в LDP PDU. Это фатальная ошибка, сигнализируемая кодом статуса Bad Message Length (неверная длина сообщения).
6. В сообщении нет одного или более обязательных параметров. Это не фатальная ошибка, сигнализируемая кодом статуса Missing Message Parameters (пропущены обязательные параметры).

3.5.1.2.2. Неизвестный или некорректный TLV

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

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

1. Длина TLV слишком велика, то есть, указывает, что TLV простирается за пределы содержащего его сообщения. Это фатальная ошибка, сигнализируемая кодом статуса Bad TLV Length (неверная длина TLV).
2. Тип TLV не известен.

   Если тип TLV < 0x8000 (старший бит 0), это ошибка, сигнализируемая кодом статуса Unknown TLV (неизвестный TLV).

   Если тип TLV >= 0x8000 (старший бит 1), TLV молча игнорируется.

3. Значение TLV некорректно. Это случается, когда получатель обрабатывает TLV, но не может декодировать значение TLV. Это интерпретируется как ошибка при отправке или получении LSR. Это фатальная ошибка, сигнализируемая кодом статуса Malformed TLV Value (некорректное значение TLV).

3.5.1.2.3. Истечение таймера KeepAlive сессии

Это фатальная ошибка, сигнализируемая кодом статуса KeepAlive Timer Expired (таймер KeepAlive истек).

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

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

3.5.1.2.5. События сообщения инициализации

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

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

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

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

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

3.5.1.2.8. Разные события

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

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

Обмен сообщениями LDP Hello является частью механизма выявления LDP; смотри раздел "Выявление LDP". Формат представления сообщений Hello отображен ниже:

ID сообщения

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

Общие параметры TLV Hello

Специфицирует параметры общие для всех сообщений Hello. Формат представления TLV для общих параметров Hello отображен ниже:

Время удержания (Hold Time).

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

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

Значение 0 означает использование значения по умолчанию, которое равно 15 секундам для канальных Hello и 45 секунд для целевых Hello. Значение 0xffff означает бесконечность.

T, целевое Hello

Значение 1 указывает на то, что это целевое Hello. Значение 0 означает, что данное сообщение является канальным Hello.

R, Посылка целевых Hello по запросу

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

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

Зарезервировано

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

Опционные параметры

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

Транспортный адрес IPv4

Специфицирует адрес IPv4, который следует использовать для посылки LSR, при открытии сессии LDP через TCP-соединение. Если этот опционный TLV отсутствует, следует использовать адрес отправителя IPv4 из UDP-пакетов, несущих сообщение Hello.

Последовательный номер конфигурации

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

Транспортный адрес IPv6

Специфицирует адрес IPv6, который следует использовать для посылки LSR, при открытии сессии LDP через TCP-соединение. Если этот опционный TLV отсутствует, следует использовать адрес отправителя IPv6 из UDP-пакетов, несущих сообщение Hello.

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

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

Мы рекомендуем, чтобы интервал между посылками Hello составлял не более одной трети от времени удержания Hello.

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

1. LSR проверяет, приемлемо ли сообщение Hello. Критерии определения приемлемости Hello зависят от конкретной реализации (примеры критериев смотри ниже).
2. Если Hello неприемлемо, LSR его игнорирует.
3. Если Hello приемлемо, LSR проверяет, имеет ли он сопредельность для отправителя Hello. Если да, то он перезапускает таймер удержания. Если нет, то он формирует сопредельность для Hello отправителя и перезапускает таймер.
4. Если Hello несет в себе какой-либо опционный TLV, LSR обрабатывает его (смотри ниже).
5. Наконец, если LSR не имеет сессий LDP для пространства меток, специфицированного идентификатором LDP в заголовке PDU сообщения Hello, он следует процедурам из раздела "Установление сессии LDP".

Ниже представлены критерии приемлемости для сообщений канального и целевого Hello:

Канальное Hello приемлемо, если интерфейс, через который оно получено, сконфигурирован для коммутации по меткам.

Целевое Hello, поступившее от отправителя с адресом A приемлемо, если:

1. LSR был сконфигурирован для приема целевых Hello, или
2. LSR был сконфигурирован посылать целевые Hello по адресу A.

Далее описано то, как LSR обрабатывает опционные TLV Hello:

Транспортный адрес

LSR ассоциирует специфицированные транспортные адреса с сопредельностью Hello.

Порядковый номер конфигурации

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

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

3.5.3. Сообщение инициализации

Обмен сообщениями инициализации LDP является частью процедуры установления сессии LDP; смотри раздел "Установление сессии LDP ".

Формат сообщения инициализации представлен ниже:

ID сообщения

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

TLV общих параметров сессии

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

Кодирование TLV общих параметров сессии рассмотрено ниже:

Версия протокола

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

Время KeepAlive

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

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

Индицирует тип анонсирования меток. A=0 означает анонсирование Downstream Unsolicited; значение = 1 означает Downstream On Demand.

Если один LSR предлагает Downstream Unsolicited, а другой предлагает Downstream on Demand, правила разрешения конфликта заключаются в следующем:

1. Если сессия сформирована для ATM или Frame Relay с коммутацией по меткам, тогда должен использоваться режим Downstream on Demand.
2. В противном случае, должен использоваться режим Downstream Unsolicited.

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

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

Индицирует, активизировано ли детектирование петель в векторе пути. Значение 0 означает, что детектирование петель заблокировано; значение 1 означает, что детектирование петель активизировано.

PVLim, ограничение вектора пути

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

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

Резерв

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

Макс. длина PDU

Двухоктетное целое без знака, которое предлагает максимально допустимую длину LDP PDU сессии. Значение 255 или меньше специфицирует максимальную длину по умолчанию 4096 октетов.

LSR-приемник должен вычислить максимальную длину PDU для сессии, взяв минимальное из своего значения и предложения партнера. Значение по умолчанию для максимальной длины PDU, использованное до инициализации сессии более не работает.

Если максимальная длина PDU, определенная таким путем, неприемлема для LSR, он должен послать в ответ на сообщение инициализации уведомление о конфликте со значением длины PDU (Session Rejected/Parameters Max PDU Length) и не устанавливать сессию.

Идентификатор LDP получателя

Идентифицирует пространство меток получателя. Этот идентификатор LDP, совместно с идентификатором отправителя в заголовке PDU позволяет получателю согласовать сообщение инициализации с одной из его сопредельностей Hello; смотри раздел "Процедуры сообщения Hello".

Если приемлемых сопредельностей Hello нет, LSR должен послать в ответ на сообщение инициализации сообщение уведомления “Session Rejected/No Hello” и не устанавливать сессию.

Опционные параметры

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

Опционный параметр	Тип	Длина	Значение
Параметры сессии ATM	0x0501	переменная	Смотри ниже
Параметры сессии Frame Relay	0x0502	переменная	Смотри ниже

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

Используется, когда сессия LDP управляет обменом меток для АТМ-канала, для задания специфических параметров ATM-сессии.

M, возможности объединения в ATM

Специфицирует объединение возможностей коммутаторов ATM. В данной спецификации поддерживаются следующие значения:

Величина	Назначение
0	Объединение не поддерживается
1	Поддерживается объединение VP
2	Поддерживается объединение VC
3	Поддерживается объединение VP & VC

Если объединяющие свойства LSR различны, то:

1. необъединяющие и VC-объединяющие LSR могут легко работать совместно.
2. Совместная работа коммутаторов, допускающих объединение VP с коммутаторами, не поддерживающими объединение VP является объектом будущего изучения. Когда LSR отличаются по использованию объединения VP, сессия устанавливается, но объединение VP не используется.
3. Заметим, что если объединение VP используется, входной узел несет ответственность за уникальность выбора VCI в домене LSR (смотри [ATM-VP]).

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

Определяет число компонент диапазона меток ATM, включенных в TLV.

D, использование VC по направлениям

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

Зарезервировано

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

Один или более компонентов диапазона меток ATM

Список компонентов диапазона меток ATM, которые в совокупности специфицируют диапазон меток, поддерживаемый LSR-отправителем.

LSR-приемник должен вычислить пересечение между приемным диапазоном и своим поддерживаемым диапазоном меток. Пересечение представляет собой диапазон, в котором LSR может присваивать и воспринимать метки. LSR не должны устанавливать сессии с соседом, для которого область пересечения диапазонов равна нулю. В этом случае LSR должен в ответ на сообщение инициализации послать сообщение уведомления “Session Rejected/Parameters Label Range” и не устанавливать сессию.

Формат представления компонента диапазона меток для ATM отображен ниже:

Res

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

Минимум VPI (12 бит)

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

Минимум VCI (16 бит)

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

Максимум VPI(12 бит)

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

Максимум VCI (16 бит)

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

Когда партнеры LSR не соединены непосредственно посредством ATM VP, LSR-отправитель должен установить минимум и максимум поля VPI равным 0, а LSR-получатель должен игнорировать минимум и максимум полей VPI.

Спецификации полей компонентов диапазона меток ATM, которые следует использовать VP-объединением LSR, смотри в [ATM-VP].

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

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

M, Возможности объединения в Frame Relay

Специфицирует объединительные возможности коммутатора Frame Relay. В данной спецификации поддерживаются следующие значения:

Объединяющие и не объединяющие LSR Frame Relay могут работать совместно.

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

Специфицирует число компонентов диапазонов меток Frame Relay, включенных в TLV.

D, использование VC по направлениям

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

Зарезервировано

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

Один или более компонентов диапазона меток Frame Relay

Список компонентов диапазона меток Frame Relay, который совместно с диапазоном LSR-отправителя специфицирует диапазон меток.

LSR-получатель должен вычислить пересечение между полученным и своим собственным диапазоном меток. Пересечение является диапазоном, в котором LSR может присваивать и воспринимать метки. LSR не должны устанавливать сессию между соседями, для которых область пересечения равна нулю. В этом случае в ответ на сообщение инициализации LSR должен послать уведомление “Session Rejected/Parameters Label Range” и не устанавливать сессию. Формат представления компонента диапазона меток для Frame Relay рассмотрен ниже:

Res

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

Len

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

Len	Биты DLCI
0	10
2	23

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

Минимум DLCI

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

Максимум DLCI

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

Заметим, что для сессий, анонсирующих общие метки, нет TLV общих параметров сессии.

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

Описание общих процедур обработки сообщений инициализации смотри раздел "Установление сессии LDP" и в частности раздел "Инициализация сессии".

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

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

ID сообщения

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

Опционные параметры

Для сообщения KeepAlive не определено опционных параметров.

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

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

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

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

LSR посылает сообщение Address партнеру LDP, чтобы анонсировать его адреса интерфейсов. Кодирование сообщения Address представлено ниже:

ID сообщения

32-битовый код идентифицирующий это сообщение.

TLV списка адресов

Список адресов интерфейсов, анонсированных LSR-отправителем. Кодирование TLV списка адресов описано в разделе " TLV списка адресов".

Опционные параметры

Для сообщения адреса опционные параметры не предусмотрены.

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

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

Когда инициализирована новая LDP сессия, перед тем как послать сообщение присвоения и запроса метки LSR должен анонсировать адреса своих интерфейсов в одном или более сообщениях Address.

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

Всякий раз, когда LSR "деактивирует" ранее анонсированный адрес, ему следует отозвать адрес с помощью сообщения отзыва адреса (Address Withdraw); смотри раздел "Сообщение отзыва адреса".

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

3.5.6. Сообщение отзыва адреса (Address Withdraw)

LSR посылает партнеру LDP сообщение отзыва адреса, чтобы отозвать ранее анонсированные адреса интерфейсов. Формат сообщения отзыва адреса представлен ниже:

ID сообщения

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

TLV списка адресов

Список адресов интерфейсов, подлежащих отзыву, для LSR-отправителя. Кодирование TLV списка адресов специфицировано в разделе "TLV списка адресов".

Опционные параметры

Для сообщения адреса опционные параметры пока не предусмотрены.

3.5.7. Сообщение присвоения метки (Label Mapping)

LSR посылает сообщение присвоения метки (Label Mapping) партнеру LDP, чтобы анонсировать ему ассоциацию FEC-метка. Формат сообщения присвоения метки представлен ниже:

ID сообщения

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

FEC TLV

Специфицирует FEC-компонент анонсируемого ансамбля FEC-метка. Смотри раздел "FEC TLV ".

TLV метки

Специфицирует компонент Label ассоциации FEC-метка. Кодирование смотри в разделе "TLV метки".

Опционные параметры

Это поле переменной длины содержит 0 или более параметров, каждый из которых имеет формат TLV. Опционными параметрами являются:

Опционный параметр	Длина	Значение
TLV ID сообщения запроса метки	4	Смотри ниже
TLV числа шагов	1	Смотри ниже
TLV вектора пути	переменная	Смотри ниже

Кодирование TLV числа шагов и вектора пути можно найти в разделе "Кодирование TLV для параметров общего использования".

ID сообщения запроса метки

Если это сообщение присвоения метки является откликом на сообщение запроса метки, оно должно включать опционный параметр Id сообщения запроса.

Число шагов

Специфицирует полное число LSR-шагов вдоль LSP, установленное сообщением Label. В разделе "Процедуры числа шагов " описано, как работать с этим TLV.

Вектор пути

Сообщает LSR список узлов LSP, сформированный сообщением Label. В разделе "Процедуры вектора пути" описано, как обрабатывать этот TLV.

3.5.7.1. Процедуры сообщения присвоения меток

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

LSR ответственен за взаимную согласованность распределения меток и за информирование партнеров об этом распределении.

LSR, получая сообщения присвоение меток от LSR ниже по течению, для префикса или элемента FEC адреса ЭВМ, не должны использовать метки для переадресации, если только их маршрутная таблица не содержит записи, которая в точности соответствует элементу FEC. Подробности смотри в приложении A "Процедуры рассылки меток LDP ".

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

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

1. LSR распознает новый FEC с помощью маршрутной таблицы, и используется режим анонсирования меток Downstream Unsolicited.
2. LSR получает сообщение запроса от вышестоящего партнера для FEC, присутствующего в маршрутной таблице LSR .
3. Следующий шаг для FEC изменился, и активизировано детектирование петель.
4. Атрибуты соответствия изменились.
5. Отклик на присвоение метки от узла-следующего шага вниз по течению и

1. не было установления соответствия со стороны выше по течению или
2. сконфигурировано детектирование петель или
3. атрибуты соответствия изменились.

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

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

1. LSR распознает новый FEC из маршрутной таблицы, и он является выходным для этого FEC.
2. LSR получает сообщение запроса от вышестоящего партнера для FEC, присутствующего в маршрутной таблице LSR, и LSR является выходным для этого FEC или имеет установленное соответствие для зоны вниз по течению.
3. Следующий шаг для FEC изменился и активизировано детектирование петель.
4. Атрибуты соответствия изменились.
5. Отклик на присвоение метки от узла следующего шага ниже по течению и

1. не сформировано никакого соответствия узлом выше по течению или
2. сконфигурировано детектирование петель или
3. атрибуты соответствия изменились.

3.5.7.1.3. Анонсирование меток вниз по течению по запросу (Downstream on Demand)

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

Эта ситуация активного тупика может быть исключена, если следовать правилу: LSR, работающий в режиме Downstream on Demand, не должен посылать анонсирования установления добровольного соответствия меток (unsolicited mapping). Следовательно, если нижестоящий LSR работает в режиме Downstream on Demand, вышестоящий LSR ответственен за посылку запросов присвоения меток, как это требуется.

3.5.7.1.4. Анонсирование меток Downstream Unsolicited

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

Комбинация режима Downstream Unsolicited и консервативного удержания метки может вести к ситуации, когда 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. Сообщение запроса метки

LSR посылает запрос метки (Label Request) партнеру LDP, чтобы установить соответствие (mapping ) для FEC. Формат сообщения запроса метки представлен ниже:

ID сообщения

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

FEC TLV

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

Опционные параметры

Это поле переменной длины содержит 0 или более параметров, каждый из которых имеет формат TLV. Опционными параметрами являются:

Опционный параметр	Длина	Значение
TLV числа шагов	1	Смотри ниже
TLV вектора пути	переменная	Смотри ниже

Кодирование TLV числа шагов и вектора пути можно найти в разделе "Кодирование TLV параметров общего пользования".

Число шагов

Специфицирует полное число LSR-шагов вдоль LSP, определяется в результате запроса метки . В разделе "Процедуры числа шагов" описано, как обрабатывать эти TLV.

Вектор пути

Специфицирует узлы вдоль LSP. Этот список сформирован посредством сообщения запроса метки. В разделе "Процедуры вектора расстояния" описано, как обрабатывать эти TLV.

3.5.8.1. Процедуры сообщения запроса метки

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

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

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

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

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

LSR-получатель должен реагировать на запрос метки сообщением присвоения метки (Label Mapping) или сообщением уведомления, объясняющим, почему он не может удовлетворить запрос.

Когда FEC, для которого запрошена метка, является префиксным FEC-элементом или FEC-элементом адреса ЭВМ, LSR-приемник использует свою маршрутную таблицу, чтобы определить отклик. Если его маршрутная таблица не содержит ни одного рекорда, в точности соответствующего запрошенному префиксу или адресу ЭВМ, LSR должен реагировать сообщением уведомления об отсутствии маршрута (No Route). ID сообщения запроса метки служит идентификатором для транзакции запроса метки. Когда LSR-получатель откликается присвоением метки (Label Mapping ), сообщение должно включать опционный параметр TLV ID сообщения запроса/отклика, который содержит ID сообщения запроса метки. Заметим, что, так как LSR используют ID запроса метки в качестве идентификаторов транзакции, LSR не должен повторно использовать ID запроса метки до завершения соответствующей транзакции.

Эта версия протокола определяет следующие статусные коды для сообщений уведомления, которые сигнализируют о невозможности реализовать запрос:

Нет маршрута

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

Нет ресурсов меток

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

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

LSR детектировал зацикливание сообщения запроса метки.

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

3.5.9. Сообщение запроса аннулирования метки

Сообщение запроса ликвидации метки может использоваться, чтобы ликвидировать определенное сообщение запроса метки. Формат сообщения запроса ликвидации метки представлен ниже:

ID сообщения

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

TLV FEC

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

TLV сообщения запроса метки

Специфицирует ID сообщения запроса метки, которое следует ликвидировать.

Опционные параметры

Для сообщения Label Abort Req опционные параметры не предусмотрены.

3.5.9.1. Процедуры сообщения запроса ликвидации метки (Label Abort)

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

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

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

Когда LSR получает сообщение запроса ликвидации метки, если он до этого не откликался на ликвидируемый запрос метки или какое-то другое сообщение уведомления, он должен подтвердить ликвидацию откликом Label Request Aborted (запрос метки ликвидирован). Уведомление должно включать TLV ID сообщения запроса метки, который несет ID ликвидированного сообщения запроса метки.

Если LSR получает сообщение запроса ликвидации метки после того, как он отреагировал на запрос метки сообщением присвоения или уведомления, он игнорирует запрос ликвидации.

Если LSR получает сообщение присвоения метки в ответ на сообщение запроса метки, после того как он послал сообщение запроса ликвидации метки, метка в сообщении присвоения (Label Mapping) корректна. LSR может решить использовать метку или освободить ее посредством сообщения Label Release.

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

1. Сообщения уведомления о выполнении ликвидации запроса метки, являющегося подтверждением ликвидации;
2. Сообщения присвоения метки в качестве отклика на аннулированное сообщение запроса;
3. Сообщения уведомления в ответ на аннулированное запроса метки (напр., зарегистрирована петля, нет ресурсов для метки, и т.д.).

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

Заметим, что отклик на запрос ликвидации метки никогда не является "упорядоченным". То есть, отклик не зависит от состояния ниже по течению LSP. LSR, получающий сообщение запроса ликвидации метки, должен обработать его немедленно, несмотря на состояние LSP ниже по течению, реагируя на уведомление ликвидации запроса метки или игнорируя его.

3.5.10. Сообщение отзыва метки

LSR посылает сообщение отзыва метки партнеру LDP, чтобы сигнализировать о том, что партнер не может продолжать использовать ассоциацию FEC-метка, которую LSR ранее анонсировал. Это разрывает соответствие между FEC и метками. Формат сообщения отзыва метки представлен ниже:

ID сообщения

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

TLV FEC

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

Опционные параметры

Это поле переменной длины содержит 0 или более параметров, каждый из которых имеет формат TLV. Опционными параметрами являются:

Опционный параметр	Длина	Значение
TLV метки	переменная	Смотри ниже

Кодирование TLV метки можно найти в разделе " TLV метки".

Метка

Если присутствует, специфицирует отзываемую метку (процедуры смотри ниже).

3.5.10.1. Процедуры сообщения отзыва метки (Label Withdraw)

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

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

TLV FEC специфицирует FEC, для которого следует отозвать метки. Если за FEC не следует никакого TLV метки, все метки, ассоциированные с FEC, должны быть отозваны; в противном случае следует отозвать только метку, специфицированную в опционном TLV метки.

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

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

3.5.11. Сообщение освобождения метки (Label Release)

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

ID сообщения

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

TLV FEC

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

Опционные параметры

Это поле переменной длины содержит 0 или более параметров, каждый из которых соответствует формату TLV. Опционными параметрами являются:

Опционный параметр	Длина	Значение
TLV метки	переменная	Смотри ниже

Кодирование TLV метки можно найти в разделе " TLV метки".

Метка

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

3.5.11.1. Процедуры сообщения освобождения метки (Label Release)

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

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

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

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

TLV FEC может содержать элемент Wildcard FEC; если это так, оно может не содержать других элементов FEC. В этом случае, если сообщение освобождения метки содержит опционное TLV метки, тогда метка должна быть освобождена для всех FEC, с которыми ассоциирована. Если в сообщении освобождения метки нет опционного TLV метки, тогда LSR-отправитель освобождает все метки, ассоциации с которыми он получил от LSR-получателя. Подробности смотри в приложении A "Процедуры рассылки меток LDP ".

3.6. Сообщения и TLV для расширяемости

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

3.6.1. Частные расширения LDP производителя

Частные сообщения и TLV производителя используются для обмена между LSR частной информацией производителя.

3.6.1.1. Частные TLV LDP производителя

Диапазон кодов типа 0x3E00 - 0x3EFF зарезервирован для частных TLV производителя. Формат частных TLV производителя представлен ниже:

U бит

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

Определение того, понятно ли частное сообщение производителя, зависит от типа и обязательного поля ID производителя.

F бит

Бит переадресации неизвестного TLV. Этот бит используется, только когда U=1, а сообщение LDP, содержащее неизвестное TLV, должно быть переадресовано. Если F=0, неизвестное TLV не переадресуется вместе с содержащим его сообщением; если F=1, неизвестное TLV переадресуется вместе с содержащим его сообщением.

Тип

Значение тип лежит в диапазоне 0x3E00 - 0x3EFF. Вместе с типом и Id производителя поле специфицирует, как следует интерпретировать поле данных.

Длина

Специфицирует суммарную длину в октетах идентификатора производителя и поля данных.

Id производителя

ID производителя 802, как это предписано IEEE.

Данные

Остальные октеты после ID производителя в поле значение являются опционными данными, зависящими от производителя.

3.6.1.2. Частные сообщения LDP производителя

Код типа в диапазоне 0x3E00 - 0x3EFF зарезервирован для частных сообщений производителя.

U бит

Бит неизвестного сообщения. При подтверждении неизвестного сообщения, если U=0, отправителю сообщения возвращается уведомление; если U=1, неизвестное сообщение молча игнорируется.

Определение того, будет ли воспринято частное сообщение производителя, базируется на типе сообщения и параметре ID производителя.

Тип сообщения

Код типа сообщения лежит в диапазоне 0x3E00 - 0x3EFF. Вместе с типом сообщения и ID производителя специфицирует то, как будет интерпретироваться сообщение.

Длина сообщения

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

ID сообщения

32-битовый код, используемый для идентификации этого сообщения. Используется LSR-отправителем, чтобы упростить идентификацию уведомлений, которые могут относиться к этому сообщению. LSR, посылающий уведомление, в качестве отклика на это сообщение, будет включать этот Id в сообщение уведомления; смотри раздел "Сообщение уведомления".

ID производителя

ID производителя 802, как это предписано IEEE.

Остальные обязательные параметры

Набор переменной длины остальных обязательных параметров.

Опционные параметры

Набор переменной длины опционных параметров сообщения.

3.6.2. Экспериментальные расширения LDP

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

1. диапазон кодов тип 0x3F00 0x3FFF зарезервирован для экспериментальных TLV.
2. диапазон кодов тип сообщения 0x3F00 - 0x3FFF зарезервирован для экспериментальных сообщений.
3. Кодирование экспериментальных TLV и сообщений подобно кодированию частных сообщений производителя со следующим отличием.

Экспериментальные TLV и сообщения используют поле экспериментального ID вместо поля ID производителя. Поле ID эксперимента используется с полем тип сообщения, чтобы специфицировать интерпретацию экспериментального TLV или сообщения. Администрирование экспериментальных ID находится в сфере ответственности экспериментаторов.

3.7. Перечень сообщений

Следующие сообщения LDP определены в данной версии протокола.

Имя сообщения	Тип	Заголовок раздела
Notification	0x0001	Сообщение уведомления
Hello	0x0100	Сообщение Hello
Initialization	0x0200	Сообщение инициализации
KeepAlive	0x0201	Сообщение KeepAlive
Address	0x0300	Сообщение Address
Address Withdraw	0x0301	Сообщение отзыва адреса
Label Mapping	0x0400	Сообщение присвоения метки
Label Request	0x0401	Сообщение запроса метки
Label Withdraw	0x0402	Сообщение отзыва метки
Label Release	0x0403	Сообщение освобождения метки
Label Abort Request	0x0404	Сообщение запроса ликвидации метки
Vendor-Private	0x3E00-0x3EFF	Частные расширения LDP производителя
Experimental	0x3F00-0x3FFF	Экспериментальные расширения LDP

3.8. Сводка TLV

Следующие TLV определены в этой версии протокола:

TLV	Тип	Заголовок раздела
FEC	0x0100	TLV FEC
Address List	x0101	TLV списка адресов
Hop Count	x0103	TLV числа шагов
Path Vector	x0104	TLV вектора пути
Generic Label	x0200	TLV общей метки
ATM Label	x0201	TLV метки ATM
Frame Relay Label	x0202	TLV метки Frame Relay
Status	x0300	TLV статуса
Extended Status	x0301	Сообщение уведомления
Returned PDU	x0302	Сообщение уведомления
Returned Message	x0303	Сообщение уведомления
Common Hello	x0400	Параметры сообщения Hello
IPv4 Transport Address	x0401	Сообщение Hello
Configuration	x0402	Порядковый номер сообщения Hello
IPv6 Transport Address	x0403	Сообщение Hello
Common Session	x0500	Параметры сообщения инициализации
ATM Session Parameters	x0501	Сообщение инициализации
Frame Relay Session	x0502	Параметры сообщения инициализации
Label Request	x0600	ID сообщения присвоения метки
Vendor-Private	x3E00-0x3EFF	Частные расширения LDP производителя
Experimental	x3F00-0x3FFF	Экспериментальные расширения LDP

3.9. Сводка кодов статуса

В таблице представлены статусные коды, определенные в данной версии протокола. В колонке "E" представлены значения Е-бита статусного кода, требующие установки; колонка "Статусные данные" содержит 30-битовое поле статусных данных в формате TLV. Заметим, что значение F-бита статусного кода остается на усмотрение LSR, формирующего TLV статуса.

3.10. Стандартные числа

3.10.1. UDP и TCP порты

UDP порт для LDP сообщения Hello имеет номер 646. TCP порт для установления LDP сессии также имеет номер 646.

3.10.2. Неявная метка NULL

Неявная метка NULL (смотри [RFC3031]) представляется как TLV общей метки со значением поля метка, как это специфицировано в [RFC3032].

4. Соображения IANA

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

1. Пространство имен типа сообщения
2. Пространство имен типа TLV
3. Пространство имен типа FEC
4. Пространство имен статусных кодов
5. Пространство имен экспериментальных ID.

4.1. Пространство имен типа сообщения

LDP делит пространство имен для типов сообщений на три диапазона. Далее предлагаются соображения по распоряжению этими диапазонами:

1. Типы сообщений 0x0000 - 0x3DFF. Типы сообщений в этом диапазоне являются частью базового протокола LDP. Типы сообщений в этом диапазоне выделяются в результате консенсуса IETF.
2. Типы сообщений 0x3E00 - 0x3EFF. Типы сообщений в этом диапазоне зарезервированы для частных расширений производителя и являются областью ответственности отдельных производителей (смотри раздел "Частные сообщения производителя LDP"). IANA не вмешивается в распределение пространства типов сообщений в этом диапазоне.
3. Типы сообщений 0x3F00 - 0x3FFF. Типы сообщений в этом диапазоне зарезервированы для экспериментальных расширений и являются областью ответственности отдельных экспериментаторов (смотри разделы "Экспериментальные расширения LDP" и "Пространство имен экспериментальных ID "). IANA не вмешивается в распределение пространства типов сообщений в этом диапазоне; однако, IANA ответственна за распоряжение частью пространства экспериментальных ID (смотри ниже).

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

LDP делит пространство имен для типов TLV на три диапазона. Далее предлагаются соображения по распоряжению этими диапазонами:

1. Типы TLV 0x0000 - 0x3DFF. Типы TLV в этом диапазоне являются частью базового протокола LDP. Типы TLV в этом диапазоне выделяются в результате консенсуса IETF.
2. Типы TLV 0x3E00 - 0x3EFF. Типы TLV в этом диапазоне зарезервированы для расширений производителей и являются областью ответственности отдельных производителей (смотри раздел "Частные TLV производителей"). IANA не вмешивается в распределение пространства типов TLV в этом диапазоне.
3. Типы TLV 0x3F00 - 0x3FFF. Типы TLV в этом диапазоне зарезервированы для экспериментальных расширений и являются областью ответственности отдельных экспериментаторов (смотри разделы "Экспериментальные расширения LDP" и "Пространство имен экспериментальных ID"). IANA не вмешивается в распределение пространства TLV в этом диапазоне; однако, IANA ответственна за распоряжение частью пространства экспериментальных ID пространства имен (смотри ниже).

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

Диапазон типов FEC 0 - 255. Типы FEC в диапазоне 0 - 127 выделяются в результате консенсуса IETF, типы в диапазоне 128 - 191 выделяются по принципу первым пришел - первым обслужен, а типы в диапазоне 192 - 255 зарезервированы для частных применений.

4.4. Пространство имен статусных кодов

Диапазон статусных кодов 0x00000000 - 0x3FFFFFFF. Статусные коды в диапазоне 0x00000000 - 0x1FFFFFFF выделяются в результате консенсуса IETF, коды в диапазоне 0x20000000 - 0x3EFFFFFF выделяются по принципу первым пришел - первым облужен, и коды в диапазоне 0x3F000000 - 0x3FFFFFFF зарезервированы для частного использования.

4.5. Пространство имен экспериментальных ID

Диапазон экспериментальных Id 0x00000000 - 0xffffffff. Экспериментальные Id в диапазоне 0x00000000 - 0xefffffff выделяются по принципу первым пришел - первым обслужен, а экспериментальные Id в диапазоне 0xf0000000 - 0xffffffff зарезервированы для частного использования.

5. Соображения безопасности

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

5.1. Фальсификация

Существует два вида LDP-коммуникаций, которые могут быть объектом атак фальсификации (spoofing).

1. Выявление обменов, реализуемых через UDP.

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

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

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

2. Коммуникационные сессии через TCP.

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

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

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

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

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

5.3. Отказ в обслуживании (DoS)

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

1. Стандартное выявление UDP-порта для LDP

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

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

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

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

2. Стандартный TCP порт для установления сессии LDP

Подобно другим протоколам управления, которые используют TCP, LDP может быть мишенью DoS атак, таких как SYN-атаки. Протокол LDP не более уязвим к этому виду атак, чем другие протоколы управления, используемые совместно с TCP. Угроза таких атак может быть несколько уменьшена посредством следующих мер:

• LSR следует избегать тотального прослушивания (promiscuous) TCP для установления сессий LDP. Ему следует использовать только прослушивание части пакетов с целью выявления партнеров. Это позволяет отбросить пакеты атак.
• Использование опции MD5 до какой-то степени помогает, так как предотвращает прием SYN, если контрольная сумма MD5 сегмента не верна. Однако получатель должен вычислить контрольную сумму, прежде чем он сможет решить отбросить соответствующий сегмент.
• Использование механизмов со списками доступа на границах сети MPLS в режиме, подобном предложенному выше для расширенных Hello, может защитить внутреннюю область от атак извне.

6. Ссылки

[ATM-VP]	N. Feldman, B. Jamoussi, S. Komandur, A, Viswanathan, T Worster, "MPLS using ATM VP Switching", Work in Progress.
[CRLDP]	L. Andersson, A. Fredette, B. Jamoussi, R. Callon, P. Doolan, N. Feldman, E. Gray, J. Halpern, J. Heinanen T. E. Kilty, A. G. Malis, M. Girish, K. Sundell, P. Vaananen, T. Worster, L. Wu, R. Dantu, "Constraint-Based LSP Setup using LDP", Work in Progress.
[DIFFSERV]	Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[IANA]	Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998
[RFC1321]	Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, April 1992
[RFC1483]	Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993
[RFC2328]	Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.RFC1700] Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", STD 2, RFC 1700, October 1994
[RFC1771]	Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995
[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997
[RFC2205]	Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997
[RFC2385]	Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998
[RFC2702]	Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering over MPLS", RFC 2702, September 1999
[RFC3031]	Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001
[RFC3032]	Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001
[RFC3034]	Conta, A., Doolan, P. and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001
[RFC3035]	Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E., Swallow, G. and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001.
[RFC3037]	Thomas, B. and E. Gray, "LDP Applicability", RFC 3037, January 2001

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

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

1. Получение сообщения запроса метки;
2. Получение сообщения присвоения метки;
3. Получение сообщения запроса ликвидации метки;
4. Получение сообщения освобождения метки;
5. Получение сообщения отзыва метки;
6. Распознание нового FEC;
7. Детектирование изменения FEC следующего шага;
8. Получение сообщения уведомления / аннулирован запрос метки;
9. Получение сообщения уведомления / нет ресурсов для метки;
10. Получение сообщения уведомления / Нет маршрута;
11. Получение сообщения уведомления / детектирована петля;
12. Получение сообщения уведомления / для метки есть ресурсы;
13. Детектирование доступности локальных ресурсов для метки;
14. LSR решает не использовать коммутацию по метке для данного FEC;
15. Таймаут для отложенного запроса метки.

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

1. Краткое изложение. Описание того, как реагирует LSR на события.
2. Контекст. Список элементов относящихся к части алгоритма спецификации. (Смотри 3.)
3. Алгоритм. Алгоритм отклика LSR на событие.

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

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

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

1. Независимое управление Downstream Unsolicited , называемое в [RFC3031] PushUnconditional .
2. Упорядоченное управление Downstream Unsolicited? называемое в [RFC 3031] PushConditional.
3. Независимое управление Downstream On Demand, называемое в [RFC 3031] PulledUnconditional.
4. Упорядоченное управление Downstream On Demand, называемое в [RFC 3031] PulledConditional.
   1. Процедура отзыва метки, которая выполняется нижерасположенным LSR, чтобы определить, когда отзывать ассоциацию FEC-метка, разосланную ранее LDP партнерами. Архитектура определяет процедуру отзыва метки. Всякий раз, когда LSR разрывает ассоциацию метки и FEC, он должен отозвать ассоциацию FEC-метка для всех партнеров LDP, которым ранее была разослана эта информация.
   2. Процедура запроса метки, которая выполняется вышестоящим LSR , чтобы определить, когда явно запросить, чтобы нижестоящий LSR связал метку с FEC . Архитектура определяет три процедуры запроса метки:
5. Никаких запросов. LSR никогда не посылает запросов метки.
6. Запросить, когда нужно. LSR запрашивает метку, когда она ему требуется.
7. Запрос на запрос. Эта процедура используется LSR без поддержки объединения. LSR запрашивает метку, когда он получает такой запрос, в дополнение к случаям, когда он нуждается в ней сам.
   1. Процедура освобождения метки, которая выполняется вышестоящим LSR , чтобы определить, когда освободить полученную ранее ассоциацию метки с FEC. Архитектура определяет две процедуры освобождения меток:
8. Консервативное сохранение (retention) метки, называемое освобождение при замене (Release On Change) [RFC3031].
9. Свободное сохранение метки, называемое никакого освобождения при замене (No Release On Change) [RFC3031].
   1. Процедура использования метки (Label Use ), которая выполняется LSR, чтобы определить, когда начать использование переадресации для ассоциации FEC-метка. Архитектура определяет три процедуры использования метки:
10. Немедленное использование (Use Immediate). LSR немедленно использует для переадресации, метку, полученную от узла следующего шага для заданного FEC.
11. Использование, если нет петель. LSR использует для переадресации пакетов FEC-метку, полученную от узла следующего шага для данного FEC, если только заранее известно, что это не приведет к зацикливаниям.
12. Использование, если не обнаружена петля. Эта процедура аналогична немедленному использованию, если только LSR не обнаружил петель в LSP. Использование метки будет продолжаться до тех пор, пока не изменится следующий шаг для FEC.
    1. Процедура Label No Route (называемая в [RFC3031] Label Not Available [метка недоступна]), которая выполняется вышестоящим LSR, чтобы определить, как реагировать на уведомление об отсутствии маршрута от нижестоящего LSR в ответ на запрос FEC-метки. Архитектура спецификации определяет две процедуры Label No Route:
13. Повторная попытка запроса. LSR должен выдать запрос метки позднее.
14. Никаких повторов запроса. LSR должен полагать, что нижестоящий LSR предоставит метку, когда у вышестоящего LSR имеется узел следующего шага и он не должен повторно посылать запрос.

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

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

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

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

A.1.1. Запрос получения метки

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

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

1. Cообщение уведомления запрашивающему LSR, объясняющее, почему не может быть присвоена метка для данного FEC;
2. Передача сообщения присвоения метки для FEC запрашивающему LSR;
3. Передача узлу следующего шага запроса метки для FEC;
4. Инсталляция меток для переадресации пакетов LSR.

   Контекст:

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

1. MsgSource. LDP-партнер, который посылает сообщение.
2. FEC. FEC, специфицированный в сообщении.
3. RAttributes. Атрибуты, полученные в сообщении. Например, число шагов, вектор пути.
4. SAttributes. Атрибуты, подлежащие включению в сообщение запроса метки, и передаваемые узлу следующего шага FEC.
5. StoredHopCount. Число шагов, если таковые имеются, записанные ранее для FEC.

Алгоритм:

LRq.1	Исполняемая процедура Check_Received_Attributes (MsgSource, LabelRequest, RAttributes). Если детектирована петля, goto LRq.13.
LRq.2	Имеется следующий шаг для FEC? Если нет, goto LRq.5.
LRq.3	Является ли MsgSource следующим шагом? Если нет, goto LRq.6.
LRq.4	Исполняется процедура Send_Notification (MsgSource, Loop Detected). Goto LRq.13
LRq.5	Исполняется процедура Send_Notification (MsgSource, No Route). Goto LRq.13.
LRq.6	LSR получил запрос метки для FEC от MsgSource? Если нет, goto LRq.8. (Смотри замечание 1.)
LRq.7	Является ли запрос метки задублированным? Если да, Goto LRq.13. (Смотри замечание 2.)
LRq.8	Записать запрос метки для FEC, полученный от MsgSource и пометить его, как ожидающий.
LRq.9	LSR выполняет процедуру рассылки метки:

Для независимого управления в режиме Downstream Unsolicited ИЛИ
Для независимого управления в режиме Downstream On Demand

1. Получил ли LSR и сохранил ли метку от узла следующего шага для FEC?.

   Если да, установить переадресацию на IsPropagating.

   Если нет, установить переадресацию на NotPropagating.

2. Исполняемая процедура

   Prepare_Label_Mapping_Attributes(MsgSource, FEC, RAttributes, SAttributes, Propagating, StoredHopCount).

3. Исполнить процедуру Send_Label (MsgSource, FEC, SAttributes).
4. Является ли LSR выходным для FEC? ИЛИ

Получил ли LSR и сохранил ли метку от узла следующего шага для FEC?

Если да, goto LRq.11. Если нет, goto LRq.10.

Для упорядоченного управления в режиме Downstream Unsolicited ИЛИ

для упорядоченного управления в режиме Downstream On Demand

1. Является ли LSR выходным для FEC? ИЛИ

   Получил ли LSR и сохранил ли метку от узла следующего шага для FEC? (Смотри замечание 3.) Если нет, goto LRq.10.

2. Исполняемая процедура

   Prepare_Label_Mapping_Attributes(MsgSource,FEC,RAttributes,SAttributes,IsPropagating,StoredHopCount)

3. Исполнить процедуру Send_Label(MsgSource, FEC, SAttributes).

Goto LRq.11.

LRq.10

LSR выполнить процедуру запроса метки:

Если запрос запрещен

1. Goto LRq.13.

Для режима запрос по необходимости ИЛИ

для режима запрос на запрос

1. Исполнить процедуру Prepare_Label_Request_Attributes (Next Hop, FEC,RAttributes, SAttributes);
2. Исполнить процедуру Send_Label_Request (Next Hop, FEC, SAttributes).

Goto LRq.13.

LRq.11	Послал ли LSR успешно метку для FEC в MsgSource? Если нет, goto LRq.13. (Смотри замечание 4.)
LRq.12	LSR выполнить процедуру Label Use.

Для немедленного использования ИЛИ
для применения, если петля не детектирована

1. Инсталлировать метку, посланную MsgSource и метку из узла следующего шага (если LSR не является выходным) для выполнения переадресации.

LRq.13 DONE

Замечания:

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

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

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

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

3. Если LSR не поддерживает объединение меток, такая проверка потерпит неудачу.
4. Процедура Send_Label может потерпеть неудачу из-за недостатка ресурсов для меток, в таком случае LSR не должен выполнять процедуру Label Use.

A.1.2. Присвоение меток

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

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

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

Контекст:

1. LSR. LSR, обрабатывающий события.
2. MsgSource. LDP-партнер, который посылает сообщение.
3. FEC. Специфицированный в сообщении FEC.
4. Метка. Специфицированная в сообщении метка.
5. PrevAdvLabel. Метка для FEC, если имеется, ранее анонсированная вышестоящим партнером.
6. StoredHopCount. Число шагов ранее записанное для FEC.
7. RAttributes. Атрибуты, полученные с сообщением. Напр., число шагов, вектор пути.
8. SAttributes должны быть включены в сообщение присвоения метки, если имеются, то пересылаются вышестоящим партнерам.

Алгоритм:

LMp.1	Соответствует ли полученная метка запросу метки FEC, посланному ранее MsgSource. Если нет, goto LMp.3.
LMp.2	Стереть запись запроса метки FEC.
LMp.3	Выполнить процедуру Check_Received_Attributes (MsgSource, LabelMapping, RAttributes). Если не зарегистрировано петель, goto LMp.9.
LMp.4	Получил ли LSR от MsgSource метку для FEC? (Смотри замечание 1.) Если нет, goto LMp.8. (Смотри замечание 2.)
LMp.5	Соответствует ли требованиям метка, полученная ранее от MsgSource (т.e., метка полученная в сообщении)? (Смотри замечание 3) Если нет, goto LMp.8. (Смотри замечание 4.)
LMp.6	Стереть ассоциацию метки для FEC, полученную ранее от MsgSource.
LMp.7	Удалить метку из таблицы маршрутизации. (Смотри замечание 5.) Goto LMp.33.
LMp.8	Исполнить процедуру Send_Message (MsgSource, Label Release, FEC, Label, Loop Detected Status code). Goto LMp.33.
LMp.9	Получил ли LSR ранее ассоциацию метки и FEC от MsgSource для рассматриваемого LSP? (Смотри замечание 6.) Если нет, goto LMp.11.
LMp.10	Соответствует ли метка, полученная ранее от MsgSource, метке в сообщении? (Смотри замечание 3.) Если нет, goto LMp.32. (Смотри замечание 4.)
LMp.11	Определить следующий шаг для FEC.
LMp.12	Является ли MsgSource следующим шагом для FEC? Если да, goto LMp.14.
LMp.13	LSR выполнить процедуру освобождения метки:

Для консервативного сохранения меток:

1. Goto LMp.32.

Для свободного сохранения меток:

1. Записать ассоциацию метки и FEC и RAttributes, полученные от MsgSource.

Goto LMp.33.

LMp.14	Является ли LSR входным для FEC? Если нет, goto LMp.16.
LMp.15	Начать использование метки для переадресации пакетов.
LMp.16	Запись ассоциации метка-FEC и RAttributes были получены от MsgSource.
LMp.17	Продолжить итерацию через LMp.31 для каждого партнера. (Смотри замечание 7).
LMp.18	Послал ли ранее LSR ассоциацию метки и FEC партнерам LSP? (Смотри замечание 8.) Если да, goto LMp.22.
LMp.19	Используется ли LSR режим упорядоченного управления рассылкой меток Downstream Unsolicited? Если нет, goto LMp.28.
LMp.20	Исполнить процедуру Prepare_Label_Mapping_Attributes Peer,FEC,RAttributes,SAttributes, IsPropagating, StoredHopCount).
LMp.21	Исполнить процедуру Send_Message (Peer, Label Mapping, FEC, PrevAdvLabel, SAttributes). Goto LMp.28
LMp.22	Продолжить итерацию через LMp.27 для каждой ассоциации метки и FEC, посланной ранее партнеру.
LMp.23	Являются ли RAttributes в полученной ассоциации метки взаимно согласующимися с ранее посланными партнеру? Если да, продолжить итерацию через LMp.22 для следующей метки. (Смотри замечание 9.)
LMp.24	Выполнить процедуру Prepare_Label_Mapping_Attributes(Peer, FEC, RAttributes, SAttributes, IsPropagating, StoredHopCount).
LMp.25	Исполнить процедуру Send_Message(Peer, Label Mapping, FEC, PrevAdvLabel, SAttributes). (Смотри замечание 10.)
LMp.26	Обновить запись ассоциации метки с FEC, посланную ранее партнеру, включить новые атрибуты.
LMp.27	Завершить итерацию через LMp.22.
LMp.28	Имеет ли LSR какие-либо запросы метки для FEC от партнера, помеченные как ожидающие? Если нет, goto LMp.30.
LMp.29	LSR выполнить процедуру рассылки метки:

Для независимого управления в режиме Downstream Unsolicited ИЛИ

Для упорядоченного управления в режиме Downstream unsolicited

1. Процедура исполнения

   Prepare_Label_Mapping_Attributes(Peer, FEC, RAttributes, SAttributes, IsPropagating, UnknownHopCount).

2. Выполнить процедуру Send_Label (Peer, FEC, SAttributes). Если процедура терпит неудачу, продолжить итерацию для следующего партнера с LMp.17.
3. Если нет ожидающих запросов для партнера goto LMp.30. (Смотри замечание 11.)

Для независимого управления в режиме Downstream On Demand ИЛИ
Для упорядоченного управления в режиме Downstream On Demand

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

LMp.30

LSR выполняет процедуру Label Use:

Для немедленного использования ИЛИ
для использования, когда нет детектированных петель

1. Продолжить итерацию через шаг 3 для каждой ассоциации метки и FEC, посланных ранее партнеру.
2. Начать применение метки, полученной и посланной партеру, для переадресации пакетов.
3. Завершить итерацию с шага 1.
4. Goto LMp.31.

LMp.31	Завершить итерацию через LMp.17. Goto LMp.33.
LMp.32	Исполнить процедуру Send_Message (MsgSource, Label Release, FEC, Label).
LMp.33	DONE.

Замечания:

1. Если LSR способен объединять метки, он должен получить как минимум одну ассоциацию метки и FEC для рассматриваемого LSP. В случае без объединения может быть получено много ассоциаций меток для FEC.
2. Если LSR детектировал петлю и он ранее не получил от MsgSource ассоциацию метки и FEC, он просто освобождает метку.
3. Соответствует ли метка, полученная в сообщении, какой-либо одной или более ассоциаций, идентифицированных на предыдущем шаге (LMp.4 или LMp.9)?
4. Добровольная ассоциация с разными метками от одного и того же партнера будет пытаться установить коммутацию по меткам для нескольких путей, которая не поддерживается в данной версии LDP.
5. Если метка не используется для целей коммутации, шаг LMp.7 не имеет значения.
6. Если полученное сообщение присвоения метки, соответствует запросу шага LMp.1, тогда (по определению) LSR не получил ранее ассоциации метки и FEC. Если LSR объединяет полученные сверху метки для рассматриваемого LSP, тогда должна быть получена, по крайней мере, одна ассоциация. В случае без объединения, могут быть несколько ассоциаций меток для заданного FEC, по одной для каждого LSP.
7. LMp.17 итерация включает MsgSource, для того чтобы обработать случай, когда LSR работает в режиме упорядоченного управления Downstream Unsolicited. Упорядоченное управление предотвращает анонсирование метки LSR для FEC, до тех пор пока не получит ассоциацию метки с FEC от узла следующего шага (MsgSource).
8. Если LSR объединяет LSP, он может иметь ранее посланные ассоциации меток и FEC до одного или более партеров. Если LSR не может объединять метки, он может посылать ассоциации меток LSP по большей части до одного LSR.
9. При этом тестировании рассматривается атрибут детектирования петель в векторе пути. Если полученный RAttributes включает в себя вектор пути, и ранее партнеру вектор пути не посылался, или если полученный вектор пути не согласуется с аналогичным вектором, посланным ранее партнеру, тогда атрибуты считаются несогласованными. Заметим, что от LSR не требуется запоминание полученного вектора пути, после того как он переслал вектор в сообщении ассоциации метки. Если LSR не запоминает вектор пути, у него нет способа проверить взаимную согласованность вновь полученного вектора пути. Это означает, что когда бы LSR ни получал сообщение, содержащее вектор пути, он должен всегда передавать его дальше.
10. Шаги с LMp.22 по LMp.27 имеют дело с ситуацией, которая может иметь место, когда LSR использует независимое управление и получает метки со стороны нижерасположенного партнера, после этого он посылает эти сообщения вверх по течению. В этой ситуации LSR следует передавать любые изменения атрибутов, таких как число шагов, вверх. Если сконфигурировано детектирование петель, передаваемые атрибуты должны содержать вектор пути.
11. LSR, работающий в режиме Downstream Unsolicited, должен обработать любое приходящее сообщение запроса метки. Если имеются отложенные запросы метки, переходим в режим Downstream on Demand, для того чтобы удовлетворить отложенные запросы.

A.1.3. Получение запроса ликвидации метки (Label Abort Request)

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

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

Контекст:

1. LSR. LSR, обрабатывающий события.
2. MsgSource. LDP партнер, который посылает сообщение.
3. FEC. FEC, специфицированный в сообщении.
4. RequestMessageID. ID сообщения запроса метки, подлежащего ликвидации.
5. Next Hop. Следующий шаг для FEC.

Алгоритм:

LAbR.1	Согласуется ли сообщение с полученным ранее запросом метки от MsgSource? (Смотри замечание 1.) Если нет, goto LAbR.12.
LAbR.2	Среагировал ли LSR на ранее полученный запрос метки? Если да, goto LAbR.12.
LAbR.3	Исполнить процедуру Send_ Message(MsgSource, Notification, Label Request Aborted, TLV), где TLV характеризует ID сообщения запроса метки, полученное в сообщение запроса ликвидации метки.
LAbR.4	Имеется ли у LSR сообщение запроса метки для FEC? Если да, goto LAbR.7
LAbR.5	Имеет ли LSR ассоциацию метки и FEC? Если нет, goto LAbR.11
LAbR.6	Сгенерировать событие: От MsgSource получено сообщение освобождения метки для FEC. (Смотри замечание 2.) Goto LAbR.11.
LAbR.7	Объединяет ли LSR метки LSP для FEC? Если нет, goto LAbR.9.
LAbR.8	Отличаются ли вышестоящие партнеры от MsgSource, который запросил метку для FEC? Если да, goto LAbR.11.
LAbR.9	Исполнить процедуру Send_Message(Next Hop, Label Abort Request, FEC, TLV), где TLV характеризует ID сообщения запроса метки, используемой LSR в сообщении запроса метки.
LAbR.10	Записать, что запрос ликвидации метки для FEC в ожидании.
LAbR.11	Стереть запись запроса метки для FEC от MsgSource.
LAbR.12	DONE

Замечания:

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

A.1.4. Получение Label Release (освобождение метки)

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

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

Контекст:

1. LSR. LSR, обрабатывающий события.
2. MsgSource. Партнер LDP, который посылает сообщение.
3. Метка. Метка, специфицированная в сообщении.
4. FEC. FEC, специфицированный в сообщении.

Алгоритм:

LRl.1	Удалить MsgSource из записи партнеров, где хранится метка для заданного FEC. (Смотри замечание 1.)
LRl.2	Соответствует ли сообщение сообщению отзыва метки для FEC, посланной ранее MsgSource? Если нет, goto LRl.4
LRl.3	Ликвидировать запись для отзываемой метки, посланную ранее MsgSource.
LRl.4	Способен ли LSR объединять метки для этого FEC? Если нет, goto LRl.6. (Смотри замечание 2.)
LRl.5	Имеет ли LSR метку, ранее анонсированную для этого FEC другим партнерам? Если да, goto LRl.10.
LRl.6	Является ли LSR выходным для этого FEC? Если да, goto LRl.10
LRl.7	Имеется ли следующий шаг для FEC? И Имеет ли LSR, полученную ранее от узла следующего шага ассоциацию метка-FEC? Если нет, goto LRl.10.
LRl.8	Сконфигурирован ли LSR для переадресации запросов освобождения метки? Если нет, goto LRl.10. (Смотри замечание 3.)
LRl.9	Исполнить процедуру Send_Message (Next Hop, Label Release, FEC, Label from Next Hop).
LRl.10	Удалить метку из MsgSourceи не использовать ее для переадресаций пакетов.
LRl.11	Содержит ли кто-то из партнеров ассоциацию метки и FEC? Если да, goto LRl.13.
LRl.12	Освободить метку.
LRl.13	DONE.

Замечания:

1. Если LSR использует режим рассылки меток Downstream Unsolicited, он не должен повторно анонсировать MsgSource ассоциацию метка-FEC до тех пор, пока MsgSource не запросит этого.
2. Шаги с LRl.4 по LRl.8 служат для определения, следует ли LSR передавать запрос об освобождении метки дальше партнерам ниже по течению (LRl.9).
3. Если LRl.8 достигнут, ни один LSR выше по течению не содержит ассоциации метки с данным FEC, и LSR получает ассоциацию метка-FEC от узла следующего шага. LSR может передавать запрос освобождения метки узлу следующего шага. Путем передачи запросов освобождения метки LSR освобождает ресурсы для меток. Поступая так, он также увеличивает задержку восстановления LSP.

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

A.1.5. Получение Label Withdraw (отзыв метки)

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

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

Контекст:

1. LSR. LSR, обрабатывающий события.
2. MsgSource. LDP партнер, который посылает сообщение.
3. Label. Метка, специфицированная в сообщении.
4. FEC. FEC, специфицированная в сообщении.

Алгоритм:

LWd.1	Удалить метку из таблицы переадресации. (Смотри замечание 1.)
LWd.2	Исполнить процедуру Send_Message(MsgSource, Label Release, FEC, Label)
LWd.3	Имеет ли LSR полученную ранее от MsgSource и сохраненную ассоциацию метка-FEC? Если нет, goto LWd.13.
LWd.4	Уничтожить ассоциацию метка-FEC, полученную ранее от MsgSource.
LWd.5	Использует ли LSR упорядоченное управление? Если да, goto LWd.8.
LWd.6	Использует ли MsgSource анонсирование меток в режиме Downstream On Demand? Если нет, goto LWd.13.
LWd.7	Генерировать событие: Рапознавание нового FEC. Goto LWd.13. (Смотри замечание 2.)
LWd.8	Продолжить итерацию через LWd.12 для каждого партнера, отличного от MsgSource.
LWd.9	Послал ли LSR ранее партнеру ассоциацию метка-FEC? Если нет, продолжить итерацию для следующего партнера через LWd.8.
LWd.10	Согласуется ли метка, посланная ранее партнеру, с отзываемой меткой? Если нет, продолжить итерацию для следующего партнера черезt LWd.8. (Смотри замечание 3.)
LWd.11	Исполнить процедуру Send_Label_Withdraw(Peer, FEC, Метка посланная ранее партнеру).
LWd.12	Закончить итерацию через LWd.8.
LWd.13	DONE

Замечания:

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

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

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

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

1. Передача ассоциации метка-FEC одному или более партнерам LDP;
2. Передача запроса метки для FEC узлу следующего шага;
3. Любая из этих операций может реализоваться, когда LSR получает ассоциацию метка-FEC от узла следующего шага.

   Контекст:

4. LSR. LSR, обрабатывающий события.
5. FEC. Вновь распознанный FEC.
6. Next Hop. Следующий шаг для FEC.
7. InitAttributes. Атрибуты, которые должны быть сопряжены с новым FEC. (Смотри замечание 1).
8. SAttributes. Атрибуты, которые должны быть включены в ассоциацию метки или в сообщение запроса метки, если они имеются, то посылаются партнеру.
9. StoredHopCount. Число шагов, сопряженное с ассоциацией метка-FEC, (если имеется) полученное ранее от узла следующего шага.

Алгоритм:

FEC.1 Выполнение LSR процедуры рассылки меток:

Для независимого управления в режиме Downstream Unsolicited

1. Осуществить итерацию через шаг 5 для каждого из партнеров.
2. Получил ли LSR ранее и сохранил ли ассоциацию метка-FEC от узла следующего шага? Если да, установить флаг рассылки равным IsPropagating. Если нет, - установить равным NotPropagating.
3. Исполнить процедуру Prepare_Label_Mapping_Attributes(Peer, FEC, InitAttributes, SAttributes, Propagating, Unknown hop count(0)).
4. Исполнить процедуру Send_Label (Peer, FEC, SAttributes)
5. Завершить итерацию через шаг 1. Goto FEC.2.
6. Для упорядоченного управления в режиме Downstream Unsolicited

1. Выполнить итерацию через шаг 5 для каждого из партнеров.
2. Является ли LSR выходным для этого FEC? ИЛИ получил ли LSR ранее от узла следующего шага и сохранил ли ассоциацию метка-FEC?
   Если нет, продолжить итерацию для следующего партнера.
3. Исполнить процедуру Prepare_ Label_ Mapping_Attributes( Peer, FEC, InitAttributes, SAttributes, Propagating, StoredHopCount).
4. Исполнить процедуру Send_Label (Peer, FEC, SAttributes)
5. Завершить итерацию в точке 1. Goto FEC.2.

Для независимого управления в режиме Downstream On Demand ИЛИ

Для упорядоченного управления в режиме Downstream On Demand

1. Goto FEC.2. (Смотри замечание 2.)

FEC.2	Получил ли LSR ранее от узла следующего шага и сохранил ли ассоциацию метка-FEC? Если да, goto FEC.5
FEC.3	Является ли следующим шагом партнер LDP? Если нет, Goto FEC.6
FEC.4	LSR выполняет процедуру запроса метки:

В отсутствии запросов

1. Goto FEC.6

Для запроса, когда необходимо ИЛИ

для запроса по запросу

1. Исполнить процедуру Prepare_Label_Request_Attributes(Next Hop, FEC, InitAttributes, SAttributes);
2. Исполнить процедуру Send_Label_Request (Next Hop, FEC, SAttributes).

Goto FEC.6.

FEC.5	Генерировать событие: От узла следующего шага получена ассоциация метки. (Смотри замечание 3.)
FEC.6	DONE.

Замечания:

1. Примером атрибута, который может быть частью InitAttributes, является атрибут спецификации желательных характеристик LSP, таких как класс услуг ( CoS). (Заметим, что в то время как текущая версия LDP не специфицирует атрибут CoS, это могут делать расширения).

   Заметим, что InitAttributes не включают в себя известное число шагов или вектор пути.

2. LSR, использующий режим рассылки меток Downstream On Demand, пошлет метку, только если он ранее получил запрос метки, помеченный как ожидающий. LSR не будет иметь таких ждущих запросов, так как он реагирует на любой запрос метки для неизвестного FEC путем посылки запрашивающему LSR уведомления No Route (нет маршрута) и отбрасыванием такого запроса; смотри LRq.3
3. Если LSR имеет метку для данного FEC от узла следующего шага, он должен вести себя так, как если бы он только что получил метку от узла следующего шага. Это происходит в случае работы в режиме свободного удержания метки.

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

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

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

1. Удаление из таблицы маршрутизации метки, соответствующей старому значению следующего шага для FEC;
2. Передача сообщений присвоения метки для FEC одному или более партнерам LDP;
3. Передача запроса метки новому узлу следующего шага для заданного FEC;
4. Любая операция, которая может иметь место, когда LSR получает ассоциацию метка-FEC из узла следующего шага.

   Контекст:

5. LSR. LSR, обрабатывающий событие.
6. FEC. FEC, для которого изменился следующий шаг.
7. New Next Hop. Новый следующий шаг для данного FEC.
8. Old Next Hop. Предыдущий следующий шаг для FEC.
9. OldLabel. Метка, (если имеется) ранее полученная от старого узла следующего шага.
10. CurAttributes. Атрибуты, если имеются, ассоциированные в настоящее время с данным FEC.
11. SAttributes. Атрибуты, подлежащие включению в сообщение запроса метки, (если имеются), которые надо послать новому узлу следующего шага.

Алгоритм :

NH.1	Получал ли LSR ранее от старого узла следующего шага и сохранил ли ассоциацию метка-FEC? Если нет, goto NH.6.
NH.2	Удалить метку из маршрутной таблицы. (Смотри замечание 1.)
NH.3	Использует ли LSR свободное сохранение меток? Если да, goto NH.6.
NH.4	Исполнить процедуру Send_Message(Old Next Hop, Label Release, OldLabel).
NH.5	Удалить ассоциацию метка-FEC, ранее полученную от старого узла следующего шага.
NH.6	Имеет ли LSR ожидающий запрос метки со старым значением следующего шага? Если нет, goto NH.10.
NH.7	Использует ли LSR консервативное сохранение меток? Если нет, goto NH.10.
NH.8	Исполнить процедуру Send_ Message(Old Next Hop, Label Abort Request, FEC, TLV), где TLV является ID запроса метки, который несет в себе ID ожидающего запроса метки.
NH.9	Записать запрос ликвидации метки для FEC как ожидающий для старого узла следующего шага.
NH.10	Имеется новый следующий шаг для данного FEC? Если нет, goto NH.16.
NH.11	Получил ли ранее LSR от нового узла следующего шага ассоциацию метка-FEC? Если нет, goto NH.13.
NH.12	Генерировать событие: Получена ассоциация метки от нового узла следующего шага. Goto NH.20. (Смотри замечание 2.)
NH.13	Использует ли LSR анонсирование Downstream on Demand? ИЛИ Использует ли узел следующего шага анонсирование Downstream on Demand? ИЛИ Использует ли LSR консервативное сохранение меток? Смотри замечание 3.) Если да, goto NH.14. Если нет, goto NH.20.
NH.14	Исполнить процедуру Prepare_Label_Request_Attributes(следующий шаг, FEC, CurAttributes, SAttributes)
NH.15	Исполнить процедуру Send_Label_Request(New Next Hop, FEC, SAttributes). (Смотри замечание 4.) Goto NH.20.
NH.16	Продолжить итерацию через NH.19 для следующего партнера
NH.17	Послал ли LSR ранее партнеру ассоциацию метка-FEC? Если нет, продолжить итерацию для следующего партера через NH.16.
NH.18	Исполнить процедуру Send_Label_Withdraw(Peer, FEC, Label previously sent to Peer).
NH.19	Завершить итерацию через NH.16.
NH.20	DONE

Замечания:

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

A.1.8. Получение уведомления/запрос метки аннулирован (Label Request Aborted)

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

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

Контекст:

1. LSR. LSR, обрабатывающий событие.
2. FEC. FEC, для которого запрашивалась метка.
3. RequestMessageID. ID сообщения запроса метки, который следует ликвидировать.
4. MsgSource. LDP партнер, который послал сообщение уведомления.

Алгоритм :

LRqA.1	Соответствует ли уведомление запросу метки для заданного FEC, который надлежит удалить? (Смотри примечание 1). Если нет, goto LRqA.3.
LRqA.2	Записать, что запрос метки для данного FEC удален.
LRqA.3	DONE

Замечания:

1. LSR использует FEC и Request Message ID, чтобы локализовать свою запись, если она имеется, о ликвидируемом запросе метки.

A.1.9. Получение уведомления / Нет ресурсов для метки

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

Когда LSR получает от LDP-партнера уведомление No Label Resources (нет ресурсов для метки), он прекращает посылать партнеру сообщения запросов метки до тех пор, пока не получит от партнера уведомление Label Resources Available (ресурсы имеются).

Контекст:

1. LSR. LSR, который обрабатывает событие.
2. FEC. FEC, для которого запрашивалась метка.
3. MsgSource. LDP-партнер, который послал уведомление.

Алгоритм:

NoRes.1	Стереть запись о запросе метки для FEC, посланный по адресу MsgSource
NoRes.2	Нужна запись ассоциации метка-FEC от MsgSource, но нет ресурсов для метки
NoRes.3	Установить статусную запись, индицирующую, что он не в порядке, чтобы послать MsgSource запрос метки.
NoRes.4	DONE

A.1.10. Получение уведомления / Нет пути

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

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

Контекст:

1. LSR. LSR, обрабатывающий события.
2. FEC. FEC, для которого была запрошена метка.
3. Атрибуты. Атрибуты, ассоциированные с запросом метки.
4. MsgSource. LDP-партер, который послал сообщение уведомления.

Алгоритм:

NoNH.1	Стереть запись о запросе метки для FEC, посланном в MsgSource.
NoNH.2	LSR выполняет процедуру Label No Route (нет пути для метки).

Для запросов без дублирования

1. Goto NoNH.3.

Для повторного запроса

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

NoNH.3 DONE.

A.1.11. Получение уведомления / детектирование петли

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

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

Контекст:

Смотри "Получение уведомления / нет пути".

Алгоритм:

Смотри " Получение уведомления / нет пути"

Замечания:

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

A.1.12. Получение уведомления / ресурсы для метки доступны

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

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

Контекст:

1. LSR. LSR, обрабатывающий событие.
2. MsgSource. LDP-партнер, который послал сообщение уведомления.
3. SAttributes. Атрибуты, запомненные с отложенным запросом метки.

Алгоритм:

Res.1	Установить статусную запись в состояние, указывающее на возможность отправки MsgSource запроса метки.
Res.2	Начать итерацию через Res.6 для каждой записи ассоциации метка-FEC, необходимой MsgSource, для которой нет ресурсов.
Res.3	Является ли MsgSource следующим шагом для FEC? Если нет, goto Res.5.
Res.4	Исполнить процедуру Send_Label_Request(MsgSource, FEC, SAttributes) Если процедура не прошла, прервать итерацию.
Res.5	Стереть запись о том, что нет ресурсов для ассоциации метка-FEC, нужной MsgSource.
Res.6	Завершить итерацию в точке Res.2
Res.7	DONE.

A.1.13. Детектирование доступности ресурсов локальной метки

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

После того как LSR послал LDP-партнеру уведомление No Label Resources, когда ресурсы оказываются доступными, он посылает соответствующее уведомление (Label Resources Available) каждому из партнеров.

Контекст:

1. LSR. LSR, обрабатывающий событие.
2. Атрибуты. Атрибуты, записанные в отложенном сообщении присвоения метки.

Алгоритм:

ResA.1	Начать итерацию через ResA.4 для каждого партнера, которому LSR посылал ранее уведомление No Label Resources (Нет ресурсов для метки).
ResA.2	Исполнить процедуру Send_Notification(Peer, Label Resources Available)
ResA.3	Стереть запись о том, что ранее было послано партнеру уведомление No Label Resources.
ResA.4	Завершить итерацию в точке ResA.1
ResA.5	Начать итерацию через ResA.8 для каждой записи ассоциации метка-FEC, необходимой для партнера, когда нет ресурсов. (Смотри замечание 1.)
ResA.6	Исполнить процедуру Send_Label(Peer, FEC, Attributes). Если процедура не прошла, прервать итерацию.
ResA.7	Очистить запись ассоциации метка-FEC, которая нужна, но для этого нет ресурсов.
ResA.8	Завершить итерацию в точке ResA.5
ResA.9	DONE.

Замечания:

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

A.1.14. LSR решает не переадресовывать пакеты по метке для данного FEC

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

LSR может в одностороннем порядке решить прекратить использование ассоциации метка-FEC для коммутации пакетов. LSR, который делает это, должен послать партнеру сообщение отзыва метки для FEC (label withdraw).

Контекст:

1. Партнер. Партнер.
2. FEC. FEC.
3. PrevAdvLabel. Метка для FEC, ранее анонсированная для партнера.

Алгоритм:

NoLS.1	Исполнить процедуру Send_Label_Withdraw(Peer, FEC, PrevAdvLabel). (Смотри замечание 1.)
NoLS.2	DONE

Замечания:

1. LSR может удалить метку из таблицы маршрутизации в результате выполнения освобождения метки в ответ на запрос отзыва.

A.1.15. Истечение таймаута отложенного запроса метки

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

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

Контекст:

1. LSR. LSR, обрабатывающий событие.
2. FEC. FEC, ассоциированный с событием таймаута.
3. Партнер. LDP-партнер, ассоциированный с событием таймаута.
4. Атрибуты. Атрибуты, запомненные вместе с сообщением отложенного запроса метки.

Алгоритм:

TO.1	Извлечь запись отложенного запроса метки.
TO.2	Является ли партнер узлом следующего шага для FEC? Если нет, goto TO.4.
TO.3	Исполнить процедуру Send_Label_Request(Peer, FEC).
TO.4	DONE.

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

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

A.2.1. Send_Label

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

Процедура Send_ Label, если возможно, присваивает метку для LDP партнерf, и посылает партнеру ассоциацию метка-FEC. Если LSR не может присвоить метку, и если он имеет отложенный запрос метки от партнера, он посылает LDP-партнеру уведомление No Label Resources (нет ресурсов для метки).

Параметры:

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

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

4. LSR. LSR, выполняющий процедуру.
5. Метка. Присвоенная метка, посланная партнеру.

Алгоритм:

SL.1	Должен ли LSR присвоить метку? Если нет, goto SL.9.
SL.2	Присвоить метку и связать ее с FEC.
SL.3	Ввести метку в таблицу маршрутизации.
SL.4	Исполнить процедуру Send_Message(Peer, Label Mapping, FEC, Label, Attributes).
SL.5	Записать ассоциацию метка-FEC и атрибуты, посланные партнеру.
SL.6	Имеет ли LSR запись запроса метки от партнера, помеченную, как отложенная? Если нет, goto SL.8.
SL.7	Стереть запись отложенного запроса метки партнера
SL.8	Вернуть флаг успеха.
SL.9	Имеет ли LSR запрос метки для FEC от партнера, помеченный как отложенный? Если нет, goto SL.13.
SL.10	Исполнить процедуру Send_Notification(Peer, No Label Resources).
SL.11	Стереть запись отложенного запроса метки, поступившего от партнера.
SL.12	Запись уведомления No Label Resources послана партнеру. Goto SL.14.
SL.13	Нужна запись присвоения метки для FEC и атрибуты для партнера, но нет ресурсов для метки. (Смотри замечание 1.)
SL.14	Вернуть флаг неудачи.

Замечания:

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

A.2.2. Send_Label_Request

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

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

Параметры:

1. Партнер. LDP-партнер, которому следует послать запрос метки.
2. FEC. FEC, для которого послан запрос метки.
3. Атрибуты. Атрибуты, подлежащие включению в запрос метки. Например, число шагов, вектор пути.

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

4. LSR. LSR, выполняющий процедуру.

Алгоритм:

SLRq.1	Был ли ранее послан партнеру запрос метки для FEC и помечен ли он как неисполненный? Если да, вернуть флаг успеха. (Смотри замечание 1.)
SLRq.2	Свидетельствует ли статусная запись о готовности послать запросы метки набору партнеров? Если нет, goto SLRq.6
SLRq.3	Исполнить процедуру Send_Message(Peer, Label Request, FEC, Attributes).
SLRq.4	Запись запроса метки для FEC была послана партнеру и помечена как нереализованная.
SLRq.5	Вернуть флаг успеха
SLRq.6	Отложить запрос метки путем записи ассоциации метка- FEC и необходимых атрибутов от партнера в ситуации, когда ресурсов для метки нет.
SLRq.7	Вернуть флаг неудачи.

Замечания:

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

A.2.3. Send_Label_Withdraw

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

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

Параметры:

1. Партнер. LDP партнер, которому должно быть послано сообщение отзыва метки.
2. FEC. FEC, для которого должна быть отозвана метка.
3. Метка. Метка, подлежащая отзыву.

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

4. LSR. LSR, выполняющий процедуру.

Алгоритм:

SWd.1	Исполнить процедуру Send_Message(Peer, Label Withdraw, FEC, Label)
SWd.2	Запись отзыва метки для FEC была помечена как нереализованная и послана партнеру.

A.2.4. Send_Notification

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

LSR использует процедуру Send_ Notification, чтобы послать LDP-партнеру сообщение уведомления.

Параметры:

1. Партнер. LDP-партнер, которому посылается уведомление.
2. Статус. Статусный код, подлежащий включению в сообщение уведомления.

Алгоритм:

SNt.1

Исполнить процедуру Send_Message(Peer, Notification, Status)

A.2.5. Send_Message

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

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

Параметры:

1. Peer. LDP партнер, которому надо послать сообщение.
2. Message Type. Тип сообщения, которое нужно послать.
3. Дополнительное содержимое сообщения . . . .

Алгоритм:

Эта процедура является средством, с помощью которого LSR отправляет LDP-сообщение специфицированного типа специфицированному LDP-партнеру.

A.2.6. Check_Received_Attributes

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

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

Параметры:

1. MsgSource. LDP партнер, который посылает сообщение.
2. MsgType. Тип полученного сообщения.
3. RAttributes. Атрибуты в сообщении.

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

1. LSR Id. Уникальный Id данного LSR.
2. Hop Count. Число шагов, если таковые имеются в полученных атрибутах.
3. Path Vector. Вектор пути, если таковой имеется в полученных атрибутах.

Алгоритм:

CRa.1	Включает ли в себя RAttributes число шагов? Если нет, goto CRa.5.
CRa.2	Превышает ли число шагов максимально допустимый порог? Если да, goto CRa.6.
CRa.3	Включает ли в себя RAttributes вектор пути? Если нет, goto CRa.5.
CRa.4	Включает ли в себя вектор пути Id LSR? ИЛИ превышает ли длина вектора пути максимально допустимый порог? Если да, goto CRa.6
CRa.5	Прислать в ответ No Loop Detected (петель не зарегистрировано).
CRa.6	Является ли MsgType (тип сообщения) LabelMapping? Если да, goto CRa.8. (Смотри замечание 1.)
CRa.7	Исполнить процедуру Send_Notification(MsgSource, Loop Detected)
CRa.8	Прислать флаг обнаружения петли
CRa.9	DONE

Замечания:

1. Когда проверяемые атрибуты получены в сообщении присвоения метки, LSR посылает уведомление об обнаружении петли в TLV статусного кода сообщения об освобождении метки. Смотри раздел "Получение присвоения метки".

A.2.7. Prepare_Label_Request_Attributes

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

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

Параметры:

1. Peer. LDP-партнер, которому должно быть послано сообщение.
2. FEC. FEC, для которого нужно послать запрос метки.
3. RAttributes. Атрибуты, которые этот LSR ассоциирует с LSP для FEC.
4. SAttributes. Атрибуты, которые следует включить в сообщение запроса метки.

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

5. LSR Id. Уникальный Id данного LSR.

Алгоритм :

PRqA.1	Нужно ли число шагов данному партнеру (Смотри замечание 1.)? ИЛИ Содержат ли RAttributes число шагов? ИЛИ Сконфигурировано ли на данном LSR детектирование петель? Если нет, goto PRqA.14.
PRqA.2	Является ли LSR входным для FEC? Если нет, goto PRqA.6.
PRqA.3	Включить число шагов 1 в SAttributes.
PRqA.4	Сконфигурировано ли на данном LSR детектирование петель? Если нет, goto PRqA.14.
PRqA.5	Способен ли LSR объединять метки? Если да, goto PRqA.14. Если нет, goto PRqA.13.
PRqA.6	Включают ли RAttributes в себя число шагов? Если нет, goto PRqA.8.
PRqA.7	Инкрементировать число шагов в RAttributes и копировать полученное значение в SAttributes. (Смотри замечание 2.) Goto PRqA.9.
PRqA.8	Включить число шагов = unknown 0) в SAttributes.
PRqA.9	Сконфигурировано ли на данном LSR детектирование петель? Если нет, goto PRqA.14.
PRqA.10	Имеют ли RAttributes вектор пути? Если да, goto PRqA.12.
PRqA.11	Способен ли LSR объединять метки? Если да, goto PRqA.14. Если нет, goto PRqA.13.
PRqA.12	Добавить Id LSR в начало вектора пути из RAttributes и скопировать результат в SAttributes. Goto PRqA.14.
PRqA.13	Включить вектор пути с длиной 1, содержащий Id LSR в SAttributes.
PRqA.14	DONE.

Замечания:

1. Канал с партнером может требовать, чтобы число шагов было включено в запрос метки; смотри, например [RFC3035] и [RFC3034].
2. Для арифметики числа шагов, unknown + 1 = unknown.

A.2.8. Prepare_Label_Mapping_Attributes

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

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

Параметры:

1. Peer. LDP-партнер, которому посылается сообщение.
2. FEC. FEC, для которого посылается запрос метки.
3. RAttributes. Атрибуты, которые этот LSR ассоциирует с LSP для FEC.
4. SAttributes. Атрибуты, подлежащие включению в сообщение присвоения метки.
5. IsPropagating. LSR посылает сообщение присвоения метки, чтобы реализовать рассылку метки, которую он получил от узла следующего шага для заданного FEC.
6. PrevHopCount. Число шагов, которые LSR ассоциирует с LSP для FEC.

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

7. LSR Id. Уникальный Id данного LSR.

Алгоритм:

PMpA.1	Нужно ли число шагов для данного партнера (смотри замечание 1.)? ИЛИ Включает ли RAttributes число шагов? ИЛИ Сконфигурировано ли на данном LSR детектирование петель? Если нет, goto PMpA.21.
PMpA.2	Является ли LSR выходным для FEC? Если нет, goto PMpA.4.
PMpA.3	Включить число шагов 1 в SAttributes. Goto PMpA.21.
PMpA.4	Имеет ли RAttributes число шагов? Если нет, goto PMpA.8.
PMpA.5	Является ли LSR краевым для домена, чьи LSR не осуществляют декрементацию TTL И Находится ли партнер в этом домене (Смотри замечание 2). Если нет , goto PMpA.7.
PMpA.6	Включить число шагов 1 в SAttributes. Goto PMpA.9.
PMpA.7	Инкрементировать число шагов RAttributes и скопировать результат в SAttributes. Смотри замечание 2. Goto PMpA.9.
PMpA.8	Включить число шагов = unknown (0) в SAttributes.
PMpA.9	Сконфигурировано ли на данном LSR детектирование петель? Если нет, goto PMpA.21.
PMpA.10	Имеют ли RAttributes вектор пути? Если да, goto PMpA.19.
PMpA.11	Пересылает ли LSR полученные данные о присвоенных метках? Если нет , goto PMpA.20.
PMpA.12	Поддерживает ли LSR объединение меток? Если нет, goto PMpA.14.
PMpA.13	Посылал ли LSR партнеру ранее сообщение присвоения метки для FEC? Если нет, goto PMpA.20.
PMpA.14	Включает ли RAttributes число шагов? Если нет, goto PMpA.21.
PMpA.15	Равно ли число шагов в Rattributes unknown (0)? Если да, goto PMpA.20.
PMpA.16	Посылал ли LSR ранее партнеру сообщение присвоения метки для FEC? Если нет goto PMpA.21.
PMpA.17	Отличается ли число шагов в RAttributes от PrevHopCount? Если нет goto PMpA.21.
PMpA.18	Является ли число шагов в RAttributes > PrevHopCount? ИЛИ Является ли PrevHopCount unknown(0) Если нет, goto PMpA.21.
PMpA.19	Добавить Id LSR в начало вектора пути из RAttributes и скопировать результат в SAttributes. Goto PMpA.21.
PMpA.20	Включить вектор пути длиной 1, содержащий Id LSR в SAttributes.
PMpA.21	DONE.

Замечания:

1. Канал до партнера может требовать, чтобы число шагов было включено в сообщения присвоения метки; например, смотри [RFC3035] и [RFC3034].
2. Если LSR является пограничным для облака LSR, которые не выполняют декрементацию TTL и он осуществляет пересылку сообщений присвоения меток вверх по течению в этом облаке, он устанавливает число шагов равным 1, так что число шагов через облако оказывается вычисленным верно. Это гарантирует правильное управление TTL для пакетов переадресуемых через область LSP, которая проходит через облако.
3. Для арифметики числа шагов, unknown + 1 = unknown.

Назад: 4.4.24. RSVP-TE: расширение RSVP для LSP-туннелей
Оглавление: Телекоммуникационные технологии
Вперёд: 4.4.26. Обобщенная мультипротокольная коммутация по меткам (GMPLS)