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

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

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

Рис. 12.7.

Метка

Это 20-битовый код метки, как это специфицировано в [RFC-3032]. Размещается в 4-октетном поле.

TLV меток ATM

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

Рис. 12.8.

Res

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

V-биты

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

VPI

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

VCI

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

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

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

Рис. 12.9.

Res

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

Len

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

0 = 10 бит DLCI

2 = 23 бит DLCI

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

DLCI

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

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

TLV списка адресов встречаются в сообщениях адреса и отзыва адреса.

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

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

Адреса

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

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

TLV числа шагов

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

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

Рис. 12.11.

Значение HC

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

LSR должен:

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

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

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

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

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

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

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

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

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

TLV статуса

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

Рис. 12.13.

U бит

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

F бит

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

Код статуса

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

E бит

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

F бит

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

Рис. 12.14.

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

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

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

ID сообщения

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

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

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

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

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

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

U бит

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

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

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

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

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

ID сообщения

Рис. 12.15.

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

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

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

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

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

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

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

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

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

ID сообщения

Рис. 12.16.

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

TLV статуса

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  Если тип сообщения < 0x8000 ( старший бит = 0 ) — это ошибка, сигнализируемая кодом статуса Unknown Message Type (неизвестный тип сообщения). Если тип сообщения >= 0x8000 ( старший бит = 1 ), оно молча отбрасывается.
• длина сообщения слишком велика, то есть, индицирует, что сообщение занимает места больше, чем отведено в LDP PDU. Это фатальная ошибка, сигнализируемая кодом статуса Bad Message Length (неверная длина сообщения);
• в сообщении нет одного или более обязательных параметров. Это не фатальная ошибка, сигнализируемая кодом статуса Missing Message Parameters (пропущены обязательные параметры).