Спецификация LDP, RSVPTE, GMPLS

Обзор LDP

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

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

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

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

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

LDP-партнеры

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

Обмен сообщениями 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.

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

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

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

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

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

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

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

Работа LDP. FEC

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

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

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

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

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

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

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

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

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

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

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

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

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

Идентификаторы 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.

Сессии LDP

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

LDP транспорт

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поддержка сопредельности 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-сессию путем посылки сообщения уведомления и закрытия транспортного соединения.