2005 г.

Назад: 4.4.25. Спецификация LDP
Оглавление: Телекоммуникационные технологии
Вперёд: 4.4.27. Расширения протокола управления резервированием (RSVP-TE) при обобщенной многопротокольной коммутации по меткам (GMPLS)

1. Введение

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

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

Подобные LSR, или точнее интерфейсы LSR, могут быть отнесены к следующим классам:

1. Интерфейсы, которые распознают границы пакетов/ячеек и могут переадресовать данные с учетом содержимого заголовка пакета/ячейки. Примерами могут служить интерфейсы маршрутизаторов, которые переадресуют данные на основе содержимого промежуточных заголовков, интерфейсы ATM-LSR, которые переадресуют данные на основе VPI/VCI ATM. Такие интерфейсы считаются способными коммутировать пакеты (PSC - Packet-Switch Capable).

2. Интерфейсы, которыеи переадресуют данные на основе циклических временных доменов. Примером такого интерфейса является соединение SONET/SDH. Такие интерфейсы считаются мультиплексирующими по времени (TDM).

3. Интерфейсы, которые переадресуют данные на основе длины волны, на которой данные получены. Примером такого интерфейса является оптические коммутаторы, которые работают на уровне отдельных длин волн. Такие интерфейсы считаются l -переключателями LSC (Lambda Switch Capable).

4. Интерфейсы, которые переадресуют данные на основе положения данных в реальном физическом пространстве. Примером такого интерфейса является оптическое подключение, которое работает на уровне одного (или нескольких) волокон. Такие интерфейсы считаются оптическими переключателями FSC (Fiber-Switch Capable).

Использование концепции вложенных путей с коммутацией по меткам (LSP) позволяет системе масштабировать построение иерархии переадресаций. На верху этой иерархии интерфейсы FSC, далее следуют интерфейсы LSC, затем TDM, и, наконец, PSC. Таким образом, LSP, который имеет на входе и выходе интерфейс PSC, может образовывать цепи вложения с другими LSP, формируя LSP, который начинается и завершается интерфейсом TDM. Этот LSP, в свою очередь, может вкладываться (вместе с другими LSP) в LSP, который начинается и завершается интерфейсом LSC, который в свою очередь вкладывается совместно с другими LSP в LSP, который начинается и завершается интерфейсом FSC. Подробности смотри в [MPLS-HIER RCHY]. Установление LSP, который покрывает только первый класс интерфейсов, определено в [RFC3036, RFC3212, RFC3209]. В данном документе предлагается функциональное описание расширений, которые необходимы для обобщения MPLS в направлении поддержки каждого из четырех классов интерфейсов. Форматы, специфические для протокола определены в [RFC3473] и [RFC3472].

2. Обзор

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

В традиционном управлении трафиком MPLS (TE), каналы, через которые проходит LSP, могут содержать сегменты с разной кодировкой меток. Например, LSP может содержать каналы, соединяющие маршрутизаторы, каналы между маршрутизаторами и ATM-LSR, и каналы между ATM-LSR. Обобщенный MPLS осуществляет расширение функциональности путем включения каналов, где метка кодируется как временной домен, длина волны, или позиция в физическом пространстве. Также как и в традиционном MPLS TE, где не все LSR могут распознавать границы IP-пакетов (напр., ATM-LSR) при переадресации, обобщенный MPLS включает в себя поддержку LSR, которые не распознают границ IP-пакетов. В традиционном MPLS TE LSP, который транспортирует IP, должен начинаться и завершаться в маршрутизаторе. Обобщенный MPLS требует, чтобы LSP начинался и завершался в LSR того же типа. Кроме того, в обобщенном MPLS тип данных, который транспортируется через LSP, может включать в себя SONET/SDH, GE или 10Гбитный Ethernet. Эти изменения традиционного MPLS отражаются в механизме запроса и переноса меток, смотри разделы 3.1 и 3.2. Специальный случай l -переключения, называемого волновой коммутацией, описан в разделе 3.3.

Другим базовым отличием традиционного и не-PSC типа обобщенного LSP MPLS, является то, что полоса пропускания, выделяется для LSP дискретными порциями, смотри раздел 3.1.3. Заметим, что использование FA (Forwarding Adjacencies), смотри [MPLS-HIERARCHY], предоставляет механизм, который может улучшить использование полосы пропускания, когда выделение полосы осуществляется дискретным образом, а также механизм агрегатирования состояния переадресации, что может сократить требуемое число меток.

Обобщенный MPLS допускает возможность предложения метки вышестоящим узлом, смотри раздел 3.4. Это предложение может быть отвергнуто нижестоящим узлом, за счет увеличения времени установления LSP. Предлагаемая метка представляет ценность, когда LSP устанавливается через определенное оптическое оборудование, где конфигурирование системы коммутации может быть долгим. Например, микрозеркала могут быть подняты или удалены, и это физическое перемещение и последующее установление потребует времени. Если метки и, следовательно, оптическая система коммутации сконфигурированы в обратном порядке (норма), может потребоваться задержать сообщение MAPPING/Resv на десятки миллисекунд на один шаг, для того чтобы установить маршрут переадресации. Предлагаемая метка может быть полезной также при восстановлении в случае отказа узла.

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

В то время как традиционный трафик, формируемый MPLS является однонаправленным, обобщенный MPLS поддерживает установление двунаправленных LSP, смотри раздел 4. Необходимость двунаправленных LSP вызвана не-PSC приложениями. Существует много причин, зачем нужны такие LSP, в частности конкуренция за ресурсы при формировании LSP с привлечением разных сигнальных сессий, и упрощение процедур восстановления при ошибках в случае не-PSC. Двунаправленные LSP имеют также преимущества малой задержки установления канала и малого числа сообщений при реализации этого процесса.

Обобщенный MPLS поддерживает специфические метки для специальных интерфейсов, смотри раздел 6. [RFC-3473] поддерживает также специальные механизмы RSVP для быстрого уведомления об ошибках.

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

Обобщенный MPLS также позволяет использование параметров, специфических для сигнальной технологии. Предполагается, что для всех технологических параметров, при работе с RSVP, в SENDER_TSPEC и других сопряженных объектах, при использовании CR-LDP, применяется формат TLV.

3. Форматы, относящиеся к меткам

Для расширения области применения MPLS в сферу оптики и временных доменов, необходимо несколько новых форм меток. Эти новые формы меток называются "обобщенными метками". Обобщенная метка содержит достаточно информации, чтобы позволить принимающему узлу программировать коммутацию вне зависимости от типа этого соединения.

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

3.1. Обобщенные запросы меток

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

Запрос обобщенной метки содержит параметр кодирования LSP, называемый тип кодирования LSP. Этот параметр указывает тип кодирования, например, SONET/SDH/GigE и т.д., который будет использоваться для данных, ассоциированных с LSP. Тип кодирования LSP характеризует природу LSP, а не природу каналов, через которые он проходит. Канал может поддерживать несколько форматов кодирования, где под поддержкой подразумевается то, что канал может транспортировать и коммутировать сигналы одного или более форматов кодирования в зависимости от доступных ресурсов и емкости канала. Например, рассмотрим LSP с управлением с помощью l -кодирования. Ожидается, что такой LSP не поддерживает электронных преобразований и ничего не известно о модуляции и быстродействии промежуточных узлов. Другие форматы обычно требуют знания структуры кадров и параметров полей.

Запрос обобщенной метки указывает также на тип коммутации, который запрашивается для канала. Это поле в норме согласуется со всеми сегментами LSP.

3.1.1. Необходимая информация

Информация, транспортируемая в обобщенном запросе метки, имеет формат:

Тип кодирования LSP :8 бит

Указывает на запрашиваемый тип кодирования LSP. Ниже представлена таблица возможных значений этого поля:

Значение	Тип
1	Пакет
2	Ethernet
3	ANSI/ETSI PDH
4	Зарезервировано
5	SDH ITU-T G.707 / SONET ANSI T1.105
6	Зарезервировано
7	Цифровой конверт
8	Lambda (оптическое)
9	Волокно
10	Зарезервировано
11	FiberChannel

ANSI PDH и ETSI PDH типы обозначают соответствующие сетевые технологии. DS1 и DS3 являются примерами ANSI PDH LSP. E1 LSP будет ETSI PDH. Тип кодирования Lambda относится к LSP, которые охватывают все длины волн. Тип кодирования волокно (Fiber) относится к LSP, работающим с оптоволоконным портом.

Тип коммутации : 8 бит

Указывает на тип коммутации, которая должна осуществляться в заданном канале. Это поле необходимо для каналов, которые анонсируют более одного типа коммутации. Это поле следует связать с одним из значений, анонсированных для соответствующих каналов в описателе возможностей маршрутной коммутации (Switching Capability Descriptor), смотри [GMPLS-RTG]. В настоящее время определены следующие значения:

Значение	Тип
1	Packet-Switch Capable-1 (PSC-1)
2	Packet-Switch Capable-2 (PSC-2)
3	Packet-Switch Capable-3 (PSC-3)
4	Packet-Switch Capable-4 (PSC-4)
51	Layer-2 Switch Capable (L2SC)
100	Time-Division-Multiplex Capable (TDM)
150	Lambda-Switch Capable (LSC)
200	Fiber-Switch Capable (FSC)

Обобщенный PID (G-PID): 16 бит

Идентификатор поля данных, транспортируемых через a LSP, т.е., идентификатор уровня клиента данного LSP. Он используется узлами в конечных точках LSP, и иногда предпоследним узлом. Стандартные значения Ethertype используются для пакета и Ethernet LSP; прочие значения перечислены в таблице:

Значение	Тип	Технология
0	Не определено	Все
1	Зарезервировано
2	Зарезервировано
3	Зарезервировано
4	Зарезервировано
5	Asynchronous mapping of E4	SDH
6	Asynchronous mapping of DS3/T3	SDH
7	Asynchronous mapping of E3	SDH
8	Bit synchronous mapping of E3	SDH
9	Byte synchronous mapping of E3	SDH
10	Asynchronous mapping of DS2/T2	SDH
11	Bit synchronous mapping of DS2/T2	SDH
12	Зарезервировано
13	Asynchronous mapping of E1	SDH
14	Byte synchronous mapping of E1	SDH
15	Byte synchronous mapping of 31 * DS0	SDH
16	Asynchronous mapping of DS1/T1	SDH
17	Bit synchronous mapping of DS1/T1	SDH
18	Byte synchronous mapping of DS1/T1	SDH
19	VC-11 в VC-12	SDH
20	Зарезервировано
21	Зарезервировано
22	DS1 SF Asynchronous	SONET
23	DS1 ESF Asynchronous	SONET
24	DS3 M23 Asynchronous	SONET
25	DS3 C-Bit Parity Asynchronous	SONET
26	VT/LOVC	SDH
27	STS SPE/HOVC	SDH
28	POS - No Scrambling, 16 bit CRC	SDH
29	POS - No Scrambling, 32 bit CRC	SDH
30	POS - Scrambling, 16 bit CRC	SDH
31	POS - Scrambling, 32 bit CRC	SDH
32	ATM mapping	SDH
33	Ethernet	SDH, l , волокно
34	SONET/SDH	l , волокно
35	Зарезервировано (SONET против)	l , волокно
36	Цифровой конверт	l , волокно
37	Lambda	Fiber
38	ANSI/ETSI PDH	SDH
39	Зарезервировано	SDH
40	Протокол доступа к каналу SDH LAPS - X.85 и X.86)	SDH
41	FDDI	SDH, l , волокно
42	DQDB (ETSI ETS 300 216)	FiberChannel
43	FiberChannel-3 (услуги)	FiberChannel+
44	HDLC	SDH
45	Ethernet V2/DIX (only)	SDH, l , волокно
46	Ethernet 802.3 (only)	SDH, l , волокно

3.1.2. Кодирование полосы пропускания

Кодирование полосы пропускания осуществляется 32 битовым числом в формате IEEE для чисел с плавающей запятой (измеряется в байтах в сек). Для беспакетных LSP, полезно определить дискретные величины, чтобы идентифицировать полосу LSP. Некоторые типичные значения для запрошенной полосы перечислены ниже. Дополнительные значения будут определяться по мере необходимости. Значения кодов полосы ассоциируются с протоколами, смотри [RFC3473] и [RFC3472].

Тип сигнала	Скорость обмена	Значение (байт/сек) (IEEE плавающий формат)
DS0	0.064 Mbps (Мбит/с)	0x45FA0000
DS1	1.544 Mbps	0x483C7A00
E1	2.048 Mbps	0x487A0000
DS2	6.312 Mbps	0x4940A080
E2	8.448 Mbps	0x4980E800
Ethernet	10.00 Mbps	0x49989680
E3	34.368 Mbps	0x4A831A80
DS3	44.736 Mbps	0x4AAAA780
STS-1	51.84 Mbps	0x4AC5C100
Fast Ethernet	100.00 Mbps	0x4B3EBC20
E4	139.264 Mbps	0x4B84D000
FC-0 133M		0x4B7DAD68
OC-3 FC-0/STM-1	155.52 Mbps	0x4B9450C0
FC-0 266M		0x4BFDAD68
FC-0 531M		0x4C7D3356
OC-12/STM-4	622.08 Mbps	0x4C9450C0
GigE	1000.00 Mbps	0x4CEE6B28
FC-0 1062M		0x4CFD3356
OC-48/STM-16	2488.32 Mbps	0x4D9450C0
OC-192/STM-64	9953.28 Mbps	0x4E9450C0
10GigE-LAN	10000.00 Mbps	0x4E9502F9
OC-768/STM-256	39813.12 Mbps	0x4F9450C0

3.2. Обобщенная метка

Обобщенная метка расширяет функциональность традиционной метки, допуская представление не только меток, которые транспортируются соответствующими информационными пакетами, но также меток, которые идентифицируют временные домены, длины волн, или пространственное мультиплексирование по положению. Например, обобщенная метка может содержать данные, которые представляют (a) одно волокно из пучка, (b) один волновой диапазон в волокне, (c) одну длину волны из диапазона (или волокна), или (d) набор временных доменов для заданной длины волны (или волокна). Метка может также нести данные о базовой метке MPLS, метке Frame Relay, или метке ATM (VCI/VPI).

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

Обобщенная метка несет в себе лишь метку одного уровня, т.е., она не является неиерархическим объектом. Когда требуется несколько уровней меток (LSP внутри LSP), каждый LSP должен быть сформирован отдельно, смотри [MPLS-HIERARCHY]. Каждый TLV-объект обобщенной метки несет в себе параметр метки переменной длины.

3.2.1. Необходимая информация

Метка : переменная длина

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

3.2.1.1. Метки длины волны и порта

Некоторые конфигурации переключения волокон FSC и l -переключение LSC используют несколько каналов/соединений, контролируемых одним управляющим каналом. В таких случаях метка ассоциируется с информационным каналом, используемым в LSP. Заметим, что этот случай не тождественен варианту применения [MPLS-BUNDLE]. Метка в случае работы с коммутацией портов и длин волн имеет длину 32 бита.

Метка :32 бит

Указывает на порт/волокно или длину волны, которая должна использоваться, с позиции отправителя объекта TLV. Значения, используемые в этом поле, имеют значение только для соседей, и получатель может оказаться вынужден преобразовать полученное значение. Значения могут конфигурироваться или динамически определяться с помощью протокола [LMP].

3.2.1.2. Прочие метки

Базовые метки MPLS и Frame Relay кодируются с выравниванием по правому полю в 32 бита (4 октета). Метки ATM кодируются посредством VPI, выровненными по правому полю в битах 0-15, а VCI выравниваются по правому полю в битах 16-31.

3.3. Коммутация по длине волны

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

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

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

3.3.1. Необходимая информация

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

Id диапазона длин волн : 32 бит.

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

Начальная метка : 32 бит

Указывает на идентификатор канала наинизшей длины волны, образующей диапазон, берется из TLV-объекта отправителя.

Конечная метка : 32 бит

Указывает на идентификатор канала наибольшей длины волны, образующей диапазон, берется из TLV-объекта отправителя.

Идентификаторы канала устанавливаются либо при конфигурации, либо протокольными средствами, такими как LMP [LMP]. Они обычно используются как параметр обобщенной метки PSC и LSC.

3.4. Предложенная метка

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

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

Информация, содержащаяся в предлагаемой метке, идентична содержащейся в обобщенной метке.

3.5. Набор меток

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

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

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

Использование набора меток является опционным, если его нет, можно использовать все метки из допустимого диапазона. Концептуально отсутствие набора меток предполагает применение набора меток {U}, к которому относятся все допустимые метки.

3.5.1. Необходимая информация

Набор меток состоит из одной или более объектов Label_Set/TLV. Каждый объект/TLV содержит один или более элементов набора меток. Каждый элемент воспринимается как идентификатор субканала и имеет тот же формат, что и обобщенная метка. Информация в наборе меток имеет формат:

Действие :8 бит

0 - включающий список

Указывает, что объект/TLV содержит один или более субканальных элементов, которые включены в набор меток.

1 - исключающий список

Указывает, что объект/TLV содержит один или более субканальных элементов, которые исключены из набора меток.

2 - включающий диапазон

Указывает, что объект/TLV содержит диапазон меток. Объект/TLV содержит два субканальных элемента. Первый элемент указывает на начало диапазона. Второй элемент указывает на конец диапазона. Значение нуль говорит о том, что соответствующая часть диапазона не имеет ограничения.

3 - исключающий диапазон

Указывает, что объект/TLV содержит диапазон меток, которые исключены из набора меток. Объект/TLV содержит два субканальных элемента. Первый элемент указывает на начало диапазона. Второй - на конец диапазона. Значение нуль говорит о том, что соответствующая часть диапазона не имеет ограничения.

Зарезервировано :10 бит

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

Тип метки : 14 бит

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

Субканал:

Субканал представляет метку (длина волны, волокно...), которая может быть присвоена. Это поле имеет тот же формат, что описан для меток в разделе 3.2.

4. Двунаправленные LSP

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

В норме для установления двунаправленного LSP при использовании [RFC3209] или [RFC3212] должны быть независимо сформированы два однонаправленных маршрута. Этот подход имеет следующие недостатки:

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

• Избыточность управления в два раза больше чем в случае однонаправленных LSP. Это связано с тем, что нужно генерировать отдельные управляющие сообщения (напр., Path и Resv) для обоих сегментов двунаправленного LSP.

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

• Труднее предоставить хороший интерфейс для оборудования SONET/SDH, которое может базироваться на двунаправленных пошаговых маршрутах.

• Двунаправленные оптические LSP (или световоды) рассматриваются в качестве требования большинством сетевых сервис-провайдеров.

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

4.1. Необходимая информация

Для двунаправленных LSP, надо выделить две метки. Установление двунаправленного LSP отмечается наличием объекта/TLV метки для маршрута вверх по течению в соответствующем сигнальном сообщении. Вышестоящая метка имеет тот же формат, что и обобщенная метка, смотри раздел 3.2.

4.2. Разрешение конфликтов

Конфликты для меток могут происходить между двумя запросами установления двунаправленных LSP, которые направлены в противоположных направлениях. Этот конфликт происходит, когда обе стороны выделяют одни и те же ресурсы (метки) в одно и то же время. Если нет ограничений на использование меток в двунаправленных LSP и если ресурсы являются альтернативными, тогда оба узла передадут разные метки вверх по течению и конфликта не будет. Однако если имеется ограничение на метки, которые могут быть использованы для двунаправленных LSP (например, если они должны быть физически связаны с одной и той же интерфейсной I/O картой), или если нет более доступных ресурсов, тогда конфликт должен разрешаться другими средствами. Чтобы разрешить конфликт, узел с более высоким значением ID выиграет соревнование и он должен послать сообщение PathErr/NOTIFICATION с указанием "Routing problem/Label allocation failure" (проблема с маршрутизацией/отказ присвоения метки). После получения такого сигнала ошибки, узел должен попытаться выделить другую метку для сегмента выше по течению (и другую предлагаемую метку, если таковая используется) в двунаправленном маршруте. Однако если других ресурсов нет, узел должен начать стандартную процедуру обработки ошибки.

Чтобы уменьшить вероятность конфликта, можно ввести правило, когда узел с более низким ID никогда не предлагает меток для сегмента ниже по течению и всегда воспринимает предлагаемую метку от вышестоящего узла с более высоким значением ID. Кроме того, так как метки пересылаться посредством LMP, может использоваться альтернативное правило, узел с более высоким номером может присваивать метки, начиная с верхнего края диапазона меток, в то время как узел с меньшим номером использует метки нижнего конца диапазона меток. Этот механизм усилит любой алгоритм кластеризации, который может быть использован для оптимизации полосы частот (или длин волн). Особым случаем, на который следует обратить внимание при использовании RSVP и поддержке этого подхода, является то, что ID соседнего узла может быть неизвестно при посылке исходного сообщения Path. Когда такое происходит, узлу следует предложить метку, выбранную из доступного пространства меток случайным образом.

Пример конфликта между двумя узлами (PXC 1 и PXC 2) показан на рис. 1. В этом примере PXC 1 присваивает метку для сегмента выше по течению для канала, соответствующего локальному BCId=2 (локальный BCId=7 для PXC 2), и посылает предлагаемую метку для канала, соответствующего локальному BCId=1 (локальный BCId=6 для PXC 2). Одновременно PXC 2 присваивает метку для сегмента выше по течению для канала, соответствующего его локальному BCId=6 (локальный BCId=1 для PXC 1) и посылает предлагаемую метку для канала, соответствующего его локальному BCId=7 (локальный BCId=2 для PXC 1). Если нет ограничения на метки, которые можно использовать для двунаправленных LSP и если имеются альтернативные ресурсы, тогда PXC 1 и PXC 2 передадут разные метки вверх по течению и конфликт разрешится естественным образом (смотри рис. 2). Однако, если имеются ограничения для меток, используемых в двунаправленных LSP (например, если они должны быть физически подключены к одной I/O карте), тогда конфликт должен быть разрешен с привлечением ID узла (смотри рис. 3).

Рис. 1 . Конфликт меток

В этом примере PXC 1 присваивает метку для сегмента выше по течению, используя BCId=2 (BCId=7 для PXC 2) и рекомендуемую метку, используя BCId=1 (BCId=6 для PXC 2). Одновременно PXC 2 присваивает метку для сегмента выше по течению, используя BCId=6 (BCId=1 для PXC 1) и рекомендуемую метку, используя BCId=7 (BCId=2 для PXC 1).

Рис. 2 . Разрешение конфликта меток без ограничений ресурсов

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

Рис. 3 . Разрешение конфликта меток посредством ограничений ресурсов

В этом примере, метки 1,2 и 3,4 для PXC 1 (метки 6,7 и 8,9 для PXC 2, соответственно) должны использоваться одним и тем же двусторонним соединением. Так как PXC 2 имеет больший ID узла, он выигрывает соревнование и PXC 1 должен использовать другой набор меток.

5. Уведомление об ошибках в метках

Существуют случаи в традиционном MPLS и в GMPLS, которые вызывают сообщения об ошибке, содержащие уведомление "Unacceptable label value" (неприемлемое значение метки), смотри [RFC3209], [RFC3472] и [< раздел смотри меток, набору обычному идентичен меток приемлемых набора Формат [RFC3473]. и [RFC3472] ошибке, об сообщении протокольном специальном соответствующем в транспортируется набор Приемлемый меток). (приемлемый Set" Label "Acceptable помощью с информации такой передачи возможность вводит GMPLS случая, этого покрытия Для приемлемы. быть могут метки какие указать, полезно быть, может ошибки, сообщение генерирующего узла, для происходит, такое Когда>

6. Прямое управление по меткам

В традиционном MPLS, интерфейсы, используемые LSP могут управляться через определенный маршрут, т.е., ERO или ER-Hop. Это допускает включение определенных узлов/интерфейсов, и завершение LSP в конкретном выходном интерфейсе выходного LSR. Где могут нумероваться интерфейсы, смотри в [MPLS-UNNUM].

Существуют случаи, когда существующая явная семантика маршрута не предоставляет достаточно информации для управления LSP на желательном уровне. Это происходит в случае, когда LSP-инициатор хочет выбрать метку, используемую каналом. Точнее проблема заключается в том, что ERO и ER-Hop не поддерживают явных субобъектов меток. Примером, где желателен такой механизм, является случай, где имеется два LSP, которые должны быть связаны друг с другом, т.е., где конец первого LSP нужно связать с началом второго LSP. Этот последний случай, вероятно, следует использовать в не-PSC классах каналов. Чтобы покрыть этот случай, введен Label ERO subobject/ER Hop.

6.1. Необходимая информация

Явная метка (Label Explicit) и запись маршрутов содержит:

L:1 бит Этот бит должен быть равен 0.

U:1 бит Этот бит указывает направление метки. Оно равно 0 для метки сегмента вниз по течению. Оно равно 1 для метки противоположного направления и используется только для двунаправленных LSP.

Метка : переменная

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

7. Защитная информация

Защитная информация транспортируется в новом объекте/TLV. Она используется для описания атрибутов защиты канала запрошенного LSP. Использование информации защиты для конкретного LSP является опционным. Защитная информация указывает на желательный тип защиты канала LSP. Если запрошен конкретный тип защиты, т.е., 1+1, или 1:N, тогда запрос соединения обрабатывается, только если запрашиваемый тип защиты может быть реализованa. Заметим, что возможности защиты канала могут анонсироваться в ходе маршрутизации, смотри [GMPLS-RTG]. Алгоритмы расчета маршрута могут учитывать эту информацию при формировании LSP.

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

7.1. Необходимая информация

Следующие данные содержатся в полях защитной информации:

Вторичный (S):1 бит

Когда равен 1, указывает, что запрошенный LSP является вторичным.

Зарезервировано :25 бит

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

Флаги канала :6 бит

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

Определены следующие флаги:

0x20 Улучшенная

Указывает на то, что следует использовать, ту схему защиты, которая более надежна, чем 1+1, напр., 4 волокна BLSR/MS-SPRING.

0x10 Выделенная 1+1

Указывает, что для LSP следует использовать выделенную схему защиты канального уровня, т.е., защиту 1+1.

0x08 Выделенная 1:1

Указывает, что для LSP следует использовать выделенную схему защиты канального уровня, т.е., 1:1.

0x04 Совместная

Указывает, что для LSP следует использовать совместную схему защиты канального уровня, такую как 1:N.

0x02 Незащищено

Указывает, что LSP не должен использовать средства защиты.

0x01 Дополнительный трафик

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

8. Информация административного состояния

Административная статусная информация транспортируется в новом объекте/TLV. Эта информация используется в настоящее время двумя способами. В первом информация характеризует административное состояние, сопряженное с определенным LSP. В таком применении, административная статусная информация отображает состояние LSP. Индикация состояния включает в себя "up" или "down", если система находится в режиме тестирования, и если маршрут ликвидируется. Действия, предпринимаемые узлом, базируются на локальных статусных характеристиках. Примером действия, которое может быть предпринято, является запрет уведомления о сигнале тревоги, когда LSP находится в состоянии "down" или в тестовом режиме, или сообщение уведомления о тревоге, связанное с соединением, имеющем приоритет равный или меньше чем "Non service affecting" (не влияет на обслуживание).

Во втором способе использование административной статусной информации, может означать запрос установления состояния LSP. Эта информация всегда относится к входному узлу, который обрабатывает запрос. Подробности смотри в [RFC3473] и [RFC3472]. Использование административной статусной информации для конкретного LSP является опционным.

8.1. Необходимая информация

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

Отражение (R):1 бит

Когда бит равен 1, это указывает, что крайний узел должен вернуть объект/TLV назад в соответствующем сообщении. Этот бит не должен устанавливаться в случае запроса изменения состояния, т.е., в сообщениях уведомления.

Зарезервировано :28 бит

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

Тестирование (T):1 бит

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

Административно выключено (A): 1 бит

Когда бит равен 1, это указывает, что локальные действия относятся к состоянию "выключено административно".

Аннулирование в процессе (D): 1 бит

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

9. Разделение каналов управления

Концепция канала управления отличается от концепции канала данных, введенной MPLS в связи с объединением каналов, смотри [MPLS-BUNDLE]. В GMPLS разделение каналов данных и управления может быть связано с несколькими факторами. Сюда относится объединение каналов и другие случаи, такие как информационные каналы, которые не могут транспортировать управляющие данные.

9.1. Идентификация интерфейса

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

В случаях, где нет явной ассоциации каналов данных и управления, необходимо передавать дополнительную информацию, чтобы идентифицировать определенный канал данных, который требует управления. GMPLS поддерживает явную идентификацию канала данных, предоставляя ID интерфейса. GMPLS допускает использование нескольких схем идентификации интерфейсов, включая адреса IPv4 или IPv6, индексы интерфейсов (смотри [MPLS-UNNUM]) и составные интерфейсы (установленные посредством конфигурирования или протокола, такого как [LMP]). Во всех случаях выбор информационного интерфейса индицируется вышестоящим узлом с помощью адресов и идентификаторов.

9.1.1. Необходимая информация

В Interface_ID содержится TLV, которые имеют следующий формат:

Длина : 16 бит

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

Тип :16 бит

Указывает тип идентифицируемого интерфейса. Определены следующие значения:

Тип	Длина	Формат	Описание
1	8	IPv4 Addr.	IPv4
2	20	IPv6 Addr.	IPv6
3	12	см. ниже	IF_INDEX (индекс интерфейса)
4	12	см. ниже	COMPONENT_IF_DOWNSTREAM (Составной интерфейс)
5	12	см. ниже	COMPONENT_IF_UPSTREAM (Составной интерфейс)

Для типов 3, 4 и 5 поле значение имеет формат:

IP-адрес : 32 бита

Поле IP-адрес может включать IP-адрес канала или IP-адрес соответствующего маршрутизатора, содержащийся в TLV адреса маршрутизатора.

ID интерфейса :32 бита. Для 3-го типа применения, ID интерфейса несет в себе идентификатор интерфейса.

Для типов 4 и 5, ID интерфейса указывает на составной канал. Специальное значение 0xFFFFFFFF может быть использовано для обозначения того, что одна и та же метка служит для всех компонентов канала.

9.2. Обработка отказов

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

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

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

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

В данном документе не вводится никаких дополнительных мер безопасности за исключением рассмотренных в [RFC3212] или [RFC3209]. Соображения безопасности, упомянутые в [RFC3212] или [RFC3209], относятся к специфическим протокольным формам GMPLS, смотри [RFC3473] и [RFC3472].

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

IANA ответственна за присвоения новых значений для пространства имен, определенных в этом документе. В этом разделе используется терминология [BCP26].

В данном документе определены следующие наборы имен:

• Тип кодирования LSP: 8 бит

• Тип коммутации:8 бит

• Обобщенный PID (G-PID): 16 бит

• Действие: 8 бит

• Тип Interface_ID :16 бит

Тип кодирования LSP - допустимый диапазон 1-255. В данном документе определены значения 1-11.

Тип коммутации - допустимый диапазон 1-255. В данном документе определены значения 1-4, 100, 150 и 200.

Обобщенный PID (G-PID) - допустимый диапазон 0-1500. В данном документе определены значения 0-46.

Действие - допустимый диапазон 0-255. В данном документе определены значения 0-3.

Тип Interface_ID - допустимый диапазон 1-65535. В данном документе определены значения 1-5.

14. Ссылки

14.1. Нормативные ссылки

[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997.
[RFC3036]	Andersson, L., Doolan, P., Feldman, N., Fredette, A. и B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3209]	Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. и G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3212]	Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T. и A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
[RFC3472]	Ashwood-Smith, P. и L. Berger, Editors, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003.
[RFC3473]	Berger, L., Editor "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

14.2. Информационные ссылки

[GMPLS-RTG]	Kompella, K., et al., "Routing Extensions in Support of Generalized MPLS", Work in Progress.
[GMPLS-SONET]	Ashwood-Smith, P., et al., "GMPLS - SONET/SDH Specifics", Work in Progress.
[LMP]	Lang, et al., "Link Management Protocol", Work in Progress.
[MPLS-BUNDLE]	Kompella, K., Rekhter, Y. и L. Berger, "Link Bundling in MPLS Traffic Engineering", Work in Progress.
[MPLS-HIERARCHY]	Kompella, K. и Y. Rekhter, "LSP Hierarchy with MPLS TE", Work in Progress.
[RFC2026]	Bradner, S., "The Internet Standards Process --Revision 3," BCP 9, RFC 2026, October 1996.
[RFC2434]	Narten, T. и H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998./td>
[RFC3031]	Rosen, E., Viswanathan, A. и R. Callon, "Multiprotocol label switching Architecture", RFC 3031, January 2001.

Назад: 4.4.25. Спецификация LDP
Оглавление: Телекоммуникационные технологии
Вперёд: 4.4.27. Расширения протокола управления резервированием (RSVP-TE) при обобщенной многопротокольной коммутации по меткам (GMPLS)