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

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

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

Рис. 12.26.

ID сообщения

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

FEC TLV

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

TLV метки

Специфицирует компонент Label ассоциации FEC-метка.

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

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

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

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

Число шагов

Специфицирует полное число LSR-шагов вдоль LSP, установленное сообщением Label.

Вектор пути

Сообщает LSR список узлов LSP, сформированный сообщением Label.

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

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

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

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

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

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

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

Анонсирование меток вниз по течению по запросу (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 ответственен за посылку запросов присвоения меток, как это требуется.

Анонсирование меток 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 является единственным.

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

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

Рис. 12.27.

ID сообщения

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

FEC TLV

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

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

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

Число шагов

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

Вектор пути

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

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

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

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

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

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

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

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

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

Рис. 12.28.

ID сообщения

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

TLV FEC

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

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

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

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

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

Процедуры сообщения запроса ликвидации метки (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-сообщения для запроса метки до тех пор, пока он не получит от своего партнера:

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

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

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

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

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

Рис. 12.29.

ID сообщения

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

TLV FEC

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

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

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

Метка

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

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

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

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

ID сообщения

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

Рис. 12.30.

TLV FEC

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

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

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

Метка

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

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

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

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

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

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