Network Working Group L. Berger, Editor Request for Comments: 3471 Movaz Networks Category: Standards Track January 2003
Описание сигнальных функций GMPLS
Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description
Статус документа
В этом документе содержится проект стандарта для протокола Internet, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа “Internet Official Protocol Standards” (STD 1). Документ может распространяться без ограничений.
Авторские права
Copyright (C) The Internet Society (2003). All Rights Reserved.
Аннотация
Этот документ описывает расширение сигнализации MPLS1 для поддержки GMPLS2. Обобщенная MPLS расширяет средства управления MPLS для поддержки систем с временным (например, SONET/SDH3), частотным (длины оптических волн) и пространственным (например, разделение направлений передачи по волокнам) мультиплексированием. Документ представляет функциональные описания расширений. Специфические для протоколов форматы и механизмы, а также технологические детали рассматриваются в отдельных документах.
Оглавление
Исключено в версии HTML.
1. Введение
Архитектура MPLS [RFC3031] была определена для поддержки пересылки данных на основе меток. В этой архитектуре предполагается, что маршрутизаторы LSR4 поддерживают средства коммутации, способные (a) распознавать границы пакетов и ячеек, а также (b) обрабатывать заголовки пакетов (LSR, распознающие границы пакетов) или ячеек (LSR, распознающие границы ячеек).
Исходная архитектура недавно была расширена путем включения LSR, средства коммутации которых не распознают границ ни пакетов, ни ячеек и, следовательно, не могут пересылать данные на основе информации из заголовков. К таким LSR относятся, в частности, устройства, принимающие решения о пересылке на основе данных о временных интервалах, длинах волн или физических портах.
С учетом сказанного выше, LSR или, более точно, интерфейсы LSR можно разделить на несколько классов.
-
Интерфейсы, способные распознавать границы пакетов или ячеек и пересылать данные на основе содержимого их заголовков. Примерами могут служить интерфейсы маршрутизаторов, пересылающие данные на основе содержимого shim-заголовков или интерфейсы ATM-LSR, пересылающие данные на основе ATM VPI/VCI. Такие интерфейсы называют PSC5.
-
Интерфейсы, пересылающие данные на основе информации из специального временного интервала, периодически повторяющегося в потоке данных. Примерами таких интерфейсов могут служить интерфейсы кросс-коннекторов SONET/SDH. Этот тип интерфейсов обозначают аббревиатурой TDM6.
-
Интерфейсы, пересылающие данные на основе длины волны, на которой были приняты эти данные. Примером могут служить интерфейсы оптических кросс-коннекторов, которые могут работать на уровне отдельных длин волн. Для интерфейсов этого типа используется аббревиатура LSC7.
-
Интерфейсы, пересылающие данные на основе их реального размещения в пространстве. Примером могут служить интерфейсы оптических кросс-коннекторов, работающие на уровне отдельных волокон или групп волокон. Для обозначения таких интерфейсов служит аббревиатура FSC8.
Использование вложенных LSP9 обеспечивает масштабирование систем за счет построения иерархии пересылки. На верхнем уровне этой иерархии размещаются интерфейсы FSC, ниже следуют LSC, затем – TDM и далее – PSC. В этом случае LSP, начинающийся и завершающийся на интерфейсе PSC, может быть вложен (вместе с другими LSP) в LSP, который начинается и завершается интерфейсами TDM. Этот LSP, в свою очередь, может быть вложен (вместе с другими LSP) в LSP, начинающийся и завершающийся на интерфейсах LSC, который, в своею очередь, может быть вложен (вместе с другими LSP) в LSP, началом и завершением которого являются интерфейсы FSC. Иерархии LSP подробно описаны в [MPLS-HIERARCHY].
Организация LSP, проходящих только через интерфейсы первого класса, определена в [RFC3036, RFC3212, RFC3209]. Данный документ представляет функциональное описание расширений, требуемых для обобщения средств управления MPLS с целью поддержки всех четырех классов интерфейсов. В документе приводятся только определения и форматы, независимые от протоколов сигнализации. Специфичные для протоколов форматы определены в [RFC3473] и [RFC3472]. Технологические детали также выходят за рамки настоящего документа и рассматриваются в отдельных документах типа [GMPLS-SONET].
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [RFC2119].
2. Обзор
Обобщенная коммутация GMPLS отличается от традиционной MPLS поддержкой множества типов коммутации (TDM, диапазон длин волн, волокно/порт). Поддержка множества типов коммутации в GMPLS привела к расширению некоторых базовых функций традиционной коммутации MPLS, а в некоторых случаях — к добавлению новых функций. Эти изменения и дополнения влияют на базовые свойства LSP – выделение меток и обмен ими, однонаправленность LSP, распространение ошибок, данные для синхронизации между входом и выходом.
В традиционной организации трафика MPLS каналы, через которые проходят LSP, могут быть разнотипными с разным представлением меток. Например, LSP может включать каналы между множеством маршрутизаторов, каналы между маршрутизаторами и ATM-LSR, а также каналы между ATM-LSR. GMPLS расширяет это, добавляя представление меток в форме временных интервалов, длин волн, положения в реальном физическом пространстве. Как и в традиционной MPLS TE, где не все LSR способны распознавать границы пакетов (IP) (например, ATM-LSR) на уровне пересылки, обобщенная MPLS включает поддержку LSR, которые не способны распознавать границы пакетов (IP) на своих уровнях пересылки. В традиционной MPLS TE передающий трафик IP путь LSP начинается и завершается на маршрутизаторах. GMPLS расширяет эту трактовку, требуя лишь, чтобы LSP начинались и завершались на похожих типах LSR. Кроме того в обобщенной MPLS набор типов передаваемых через LSP данных расширяется за счет добавления SONET/SDH, 1Gb или 10Gb Ethernet и т. п. Эти отличия от традиционной MPLS отразились на способах запроса меток и обмена ими в GMPLS (см. параграфы 3.1 и 3.2). Специальные случаи коммутации длин волн (Lambda) и диапазонов (Waveband) описаны в параграфе 3.3.
Другим фундаментальным различием между традиционными LSP и неспособными коммутировать пакеты (non-PSC) GMPLS LSP является то, что полоса для LSP может выделяться только дискретными блоками (см. параграф 3.1.3). Число меток на каналах без PSC будет (значительно) меньше числа меток на каналах PSC. Отметим, что использование FA10 (см. [MPLS-HIERARCHY]) обеспечивает механизм, способный повысить эффективность использования полосы каналов в тех случаях, когда полоса может выделяться только дискретными блоками, а также механизм агрегирования состояний пересылки, позволяющий снизить число требуемых меток.
GMPLS обеспечивает вышестоящим (upstream) узлам предлагать метки (см. параграф 3.4). Такое предложение может быть переопределено нижестоящим (downstream) узлом, но в некоторых случаях за это придется расплачиваться временем на организацию LSP. Предложенные метки ценны при организации LSP через некоторые типы оптического оборудования, где возможны существенные (по сравнению с электрическими средами) временные издержки на настройку коммутации. Например, может потребоваться настройка положения микрозеркал, связанная с их перемещением и последующей юстировкой. Если метки и, следовательно, машина коммутации настроены для обратного направления (норма), может потребоваться задержка сообщения в десятки миллисекунд на интервал пересылки для организации применимого пути пересылки. Предложенные метки ценны также для случаев восстановления после отказов узлов.
GMPLS расширяется понятием ограничения диапазона меток, которые может выбирать нижележащий узел (см. параграф 3.5). В GMPLS входной или другой узел восходящего направления может ограничить множество меток, которые могут применяться на одном интервале LSP или на всем пути LSP. Эта функция пришла из оптических систем, где возникают ситуации ограничения используемых на пути длин волн неким множеством или даже одним значением. Это требование обусловлено тем, что часть оборудования может генерировать только небольшой набор длин волн, которые способно переключать промежуточное оборудование, или тем, что это оборудование совсем не может коммутировать по длине волны и способно лишь переключить трафик в другие волокна.
В то время, как традиционная организация трафика MPLS (и даже LDP) работает в одном направлении, GMPLS поддерживает организацию двухсторонних LSP (см. раздел 4). Потребность в двухсторонних LSP обусловлена приложениями, не поддерживающими PSC. Существует много причин, по которым могут требоваться такие LSP, в частности, возможная борьба за ресурсы при создании встречных односторонних LSP с помощью раздельных сигнальных сессий или упрощение процедур восстановления для случаев отсутствия поддержки PSC. Двухсторонние LSP также сокращают временные издержки на организацию пути и требуемого для этого число сообщений.
GMPLS поддерживает использование конкретной метки на конкретном интерфейсе (см. раздел 6). [RFC3473] также поддерживает механизмы RSVP для быстрого уведомления об отказах.
GMPLS формализует возможное разделение каналов управления и передачи данных 9см. Раздел 9). Такая поддержка особенно важна для технологий, которые не позволяют передавать данные и управляющий трафик по одному каналу.
GMPLS также разрешает включать в сигнализацию специфические параметры технологии. Цель этого заключается в передаче специфических параметров технологии в SENDER_TSPEC и других связанных объектах при использовании RSVP, а также в Traffic Parameters TLV при использовании CR-LDP. Форматы специфических для технологий параметров будут определяться по мере необходимости. Пример таких определений имеется в [GMPLS-SONET].
3. Связанные с метками форматы
Для расширения MPLS на оптические и TDM-устройства требуется несколько новых форм «меток». Совокупность этих новых форм называют обобщенными метками (generalized label). Обобщенные метки содержат информацию, которая позволяет принимающему узлу запрограммировать кросс-соединение, независимо от типа такого соединения, чтобы корректно соединиться с входным сегментом пути. В этом разделе описаны запрос обобщенной метки, собственно метка, поддержка коммутации диапазонов, предложенные метки и наборы меток.
Отметим, что обобщенные метки не содержат поля типа, поскольку передающим и принимающим такие метки устройствам тип канала известен. При этом предполагается, что узлам известен из контекста тип меток, которые они могут получить.
3.1. Запрос обобщенной метки
Сообщения Generalized Label Request поддерживают обмен характеристиками, которые требуются для поддержки запрашиваемого LSP. Эти характеристики включают представление и содержимое LSP. Отметим, что эти характеристики могут использоваться промежуточными узлами (например, для поддержки определения предпоследнего интервала).
В Generalized Label Request передается параметр представления LSP, называемый LSP Encoding Type. Этот параметр указывает тип представления (например, SONET/SDH/GigE и т. п.), который будет использоваться для данных, связанных с этим LSP. LSP Encoding Type показывает природу LSP, а не природу каналов, через которые этот LSP проходит. Канал может поддерживать множество форматов представления в том смысле, что канал может передавать и коммутировать сигнал с одним или множеством из этих форматов в зависимости от доступности ресурсов и емкости данного канала. В качестве примера рассмотрим LSP для которого указано lambda-представление. Предполагается, что такой LSP будет поддерживаться без электрических преобразований, но не делается каких-либо предположений о типах модуляции и скоростях на промежуточных устройствах. Другие форматы обычно требуют информации о кадрировании и поля параметров разбиты на тип кадрирования и скорость, как показано ниже.
Generalized Label Request также указывает тип коммутации, запрашиваемый для канала. Это поле обычно совпадает для всех каналов в составе LSP.
3.1.1. Требуемая информация
Формат сообщения Generalized Label Request показан на рисунке.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Enc. Type |Switching Type | G-PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LSP Encoding Type – 8 битов
Указывает представление запрашиваемого LSP. Возможные значения поля и их смысл указаны в таблице.
-
Значение
Тип
1
Пакеты
2
Ethernet
3
ANSI/ETSI PDH
4
Резерв
5
SDH ITU-T G.707 / SONET ANSI T1.105
6
Резерв
7
Digital Wrapper
8
Lambda (оптика)
9
Fiber (волокна)
10
Резерв
11
FiberChannel
Типы ANSI PDH и ETSI PDH обозначают соответствующие сетевые технологии – DS1 и DS3 являются примерами ANSI PDH LSP, а E1 LSP – ETSI PDH. Тип Lambda указывает LSP для всего диапазона длин волн, тип Fiber относится к LSP, которые включают оптические порты целиком.
Switching Type – 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)
Generalized PID (G-PID) – 16 битов
Идентификатор данных, передаваемых через этот LSP (например, идентификатор клиентского уровня данного LSP). Идентификатор используется конечными точками и узлами LSP, а в некоторых случаях — предпоследним интервалом. Для пакетных и Ethernet LSP используются стандартные значения Ethertype, прочие указаны в таблице.
-
Значение
Тип
Технология
0
Неизвестен
Все
1
Резерв
2
Резерв
3
Резерв
4
Резерв
5
Асинхронное отображение E4
SDH
6
Асинхронное отображение DS3/T3
SDH
7
Асинхронное отображение E3
SDH
8
Синхронное битовое отображение E3
SDH
9
Синхронное байтовое отображение E3
SDH
10
Асинхронное отображение DS2/T2
SDH
11
Синхронное битовое отображение DS2/T2
SDH
12
Резерв
13
Асинхронное отображение E1
SDH
14
Синхронное байтовое отображение E1
SDH
15
Синхронное байтовое отображение 31 * DS0
SDH
16
Асинхронное отображение DS1/T1
SDH
17
Синхронное битовое отображение DS1/T1
SDH
18
Синхронное байтовое отображение DS1/T1
SDH
19
VC-11 в VC-12
SDH
20
Резерв
21
Резерв
22
Асинхронный DS1 SF
SONET
23
Асинхронный DS1 ESF
SONET
24
Асинхронный DS3 M23
SONET
25
Асинхронный DS3 с четностью C-Bit
SONET
26
VT/LOVC
SDH
27
STS SPE/HOVC
SDH
28
POS — без скрэмблирования, CRC 16 битов
SDH
29
POS — без скрэмблирования, CRC 32 бита
SDH
30
POS — со скрэмблированием, CRC 16 битов
SDH
31
POS — со скрэмблированием, CRC 32 бита
SDH
32
Отображение ATM
SDH
33
Ethernet
SDH, лямбда, волокно
34
SONET/SDH
Лямбда, волокно
35
Резерв (запрещено для SONET)
Лямбда, волокно
36
Digital Wrapper
Лямбда, волокно
37
Лямбда
Волокно
38
ANSI/ETSI PDH
SDH
39
Резерв
SDH
40
Протокол доступа к каналу (LAP) SDH (X.85 и X.86)
SDH
41
FDDI
SDH, лямбда, волокно
42
DQDB (ETSI ETS 300 216)
SDH
43
FiberChannel-3 (службы)
FiberChannel
44
HDLC
SDH, лямбда, волокно
45
Только Ethernet V2/DIX
SDH, лямбда, волокно
46
Только Ethernet 802.3
SDH, лямбда, волокно
3.1.2. Представление полосы
Пропускная способность представляется 32-битовым числом с плавающей запятой в формате IEEE (в байтах за секунду). Для непакетных LSP полезно определять дискретные значения, указывающие пропускную способность LSP. Некоторые типовые значения для запрашиваемой полосы представлены в таблице (значения являются рекомендуемыми). По мере необходимости будут определяться новые значения. Представление полосы передается в зависимости от протокола (см. [RFC3473] и [RFC3472]).
|
Тип сигнала |
Битовая скорость (Мбит/с) |
Значение (байт/с) (IEEE Floating point) |
|
DS0 |
0,064 |
0x45FA0000 |
|
DS1 |
1,544 |
0x483C7A00 |
|
E1 |
2,048 |
0x487A0000 |
|
DS2 |
6,312 |
0x4940A080 |
|
E2 |
8,448 |
0x4980E800 |
|
Ethernet |
10,00 |
0x49989680 |
|
E3 |
34,368 |
0x4A831A80 |
|
DS3 |
44,736 |
0x4AAAA780 |
|
STS-1 |
51,84 |
0x4AC5C100 |
|
Fast Ethernet |
100,00 |
0x4B3EBC20 |
|
E4 |
139,264 |
0x4B84D000 |
|
FC-0 133M |
0x4B7DAD68 |
|
|
OC-3/STM-1 |
155,52 |
0x4B9450C0 |
|
FC-0 266M |
0x4BFDAD68 |
|
|
FC-0 531M |
0x4C7D3356 |
|
|
OC-12/STM-4 |
622,08 |
0x4C9450C0 |
|
GigE |
1000,00 |
0x4CEE6B28 |
|
FC-0 1062M |
0x4CFD3356 |
|
|
OC-48/STM-16 |
2488,32 |
0x4D9450C0 |
|
OC-192/STM-64 |
9953,28 |
0x4E9450C0 |
|
10GigE-LAN |
10000,00 |
0x4E9502F9 |
|
OC-768/STM-256 |
39813,12 |
0x4F9450C0 |
3.2. Обобщенная метка
Обобщенные метки (Generalized Label) являются расширением традиционных меток, которое позволяет представлять не только метки, перемещающиеся вместе с пакетами данных, но и метки, идентифицирующие временные интервалы, длины волн или позиции при пространственном мультиплексировании. Например, Generalized Label может переносить метку, которая представляет (a) отдельное волокно в кабеле, (b) одну длину волны в волокне, (c) одну длину волны в диапазоне (или волокне), (d) группу временных интервалов для одной длины волны (или волокна). Она может также передавать метку, представляющую обычную метку MPLS, Frame Relay или ATM (VCI/VPI).
Обобщенная метка не только идентифицирует «класс», к которому относится метка, но и неявно обеспечивает возможности мультиплексирования на канале, где эта метка используется.
Generalized Label переносит только метку одного уровня (иерархия не поддерживается). Если требуется множество уровней (LSP внутри LSP) пути LSP должны организовываться независимо (см. [MPLS-HIERARCHY]).
Каждый объект/TLV Generalized Label имеет параметр Label переменного размера.
3.2.1. Требуемая информация
Передаваемая в Generalized Label имеет вид:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label – переменный размер
Данные метки, интерпретация которых зависит от типа канала, на котором используется метка.
3.2.1.1. Метки порта и длины волны
Некоторые конфигурации коммутации волокон (FSC) и длин волн (LSC) используют множество каналов данных/соединений, находящихся под контролем одного канала управления. В таких случаях для LSP используются метки, идентифицирующие канал данных/соединение. Отметим, что этот случай не совпадает с использованием [MPLS-BUNDLE].
Информация передается в метке (Port and Wavelength), формат которой показан ниже:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label – 32 бита
Указывает используемый порт/волокно или длину волны с точки зрения отправителя объекта/TLV. Значения этого поля значимы только в контексте соседей и получателю может потребоваться преобразование полученного значения в локально значимое. Значения могут задаваться в конфигурации или определяться динамически с помощью протоколов типа [LMP].
3.2.1.2. Прочие метки
Метки GMPLS и Frame Relay представляются 32-битовыми (4 октета) значениями с выравниванием по правому краю. Метки ATM представляются выравниваемыми по правому краю значениями VPI (биты 0 – 15) и VCI (биты 16 – 31).
3.3. Коммутация диапазонов
Специальным случаем коммутации длин волн (lambda) является коммутация диапазонов. Диапазон представляет собой набор длин вол, который может быть целиком переключен в другой диапазон длин волн. Такая коммутация может быть удобна для оптических кроссов, поскольку позволяет переключить множество длин волн разом. Это может обеспечить снижение уровня дисторсии для отдельных длин волн, а также позволяет сделать более точным разделение по отдельным длинам волн. Для поддержки этого специального случая определена метка Waveband.
Коммутация диапазонов создает новый уровень иерархии меток, поэтому она трактуется так же, как другие метки вышележащего уровня.
С точки зрения протокола MPLS метки длин волн и диапазонов отличаются лишь тем, что диапазон может быть разделен на несколько длин волн, а длина волны может быть «поделена» только с помощью меток статистического или временного мультиплексирования.
3.3.1. Требуемая информация
Для коммутации диапазон используется тот же формат, который был описан для обобщенной метки в параграфе 3.2.1.
В контексте коммутации диапазонов длин волн формат обобщенной метки имеет вид, показанный ниже.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Waveband Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Waveband Id – 32 бита
Идентификатор диапазона длин волн. Значение выбирается отправителем и используется во всех последующих сообщениях, связанных с данной меткой.
Start Label – 32 бита
Указывает идентификатор канала наименьшей длины волны диапазона с точки зрения объекта/TLV отправителя.
End Label – 32 бита
Указывает идентификатор канала наибольшей длины волны диапазона с точки зрения объекта/TLV отправителя.
Идентификаторы каналов задаются в конфигурации или с помощью протоколов типа LMP [LMP]. Эти идентификаторы обычно применяются в параметре Label обобщенных меток одного PSC и LSC.
3.4. Предложенные метки
Предложенные метки (Suggested Label) служат для передачи нижележащим узлам меток, предпочитаемых вышестоящими. Это позволяет узлу восходящего направления начинать настройку своего оборудования с выбором метки, которая будет предлагаться, до передачи этой метки узлу нисходящего направления. Такая предварительная настройка весьма желательна для систем, в которых организация метки в устройствах может занимать достаточно много времени. Предварительная настройка позволяет ускорить процесс, что может быть важно при восстановлении работоспособности, когда может потребоваться срочная организация дополнительных LSP в результате отказа в сети.
Использование Suggested Label обеспечивает лишь оптимизацию. Если нижележащий узел передает наверх другую метку, LSR восходящего направления перестраивается с учетом этой метки, сохраняя управление метками за узлом нисходящего направления. Отметим, что передача передача предлагаемой метки не предполагает доступности этой метки для использования. В частности, входному узлу не следует передавать трафик с использованием предложенной метки, пока нижележащий узел не передаст эту метку наверх.
Информация в предлагаемых метках идентична информации в обобщенных метках. Отметим, что значения поля Label в предлагаемых метках даются с точки зрения объекта /TLV отправителя.
3.5. Набор меток
Наборы меток (Label Set) применяются для ограничения числа меток, выбираемых нижележащим узлом, неким множеством приемлемых меток. Это ограничение используется на уровне интервала пересылки (hop).
Опишем 4 случая, когда применение Label Set будет полезным для оптического домена. К первому случаю относятся ситуации, когда оконечное оборудование может использовать для передачи лишь небольшой набор длин волн или диапазонов. Вторым является случай наличия цепочки интерфейсов, не способных преобразовывать длину волны (не поддерживающие CI) и требующих сквозного использования одной длины волны на группе интервалов пересылки или даже на всем пути. В третьем случае имеется потребность в ограничении числа выполняемых преобразования длины волны с целью снижения уровня искажений оптических сигналов. Последним является случай, когда на разных концах одного соединения поддерживаются разные наборы длин волн.
Label Set используется для ограничения наборов меток, которые могут применяться на конкретном пути LSP между двумя партнерами. Получатель Label Set должен ограничить свой выбор меток в соответствии с полученным набором. Как м отдельные метки, Label Set может применяться на множестве интервалов. В этом случае каждый узел генерирует свой исходящий Label Set, возможно на основе Label Set и с учетом возможностей оборудования. Предполагается, что этот случай будет нормой для устройств с интерфейсами без поддержки преобразования длин волн (CI-incapable).
Использование Label Set не является обязательным. При отсутствии такого набора могут применяться из числа приемлемых. Концептуально, отсутствие Label Set эквивалентно получения набора {U}, содержащего все приемлемые метки.
3.5.1. Требуемая информация
Набор меток состоит из одного или множества объектов/TLV Label_Set, содержащих по одному или более элементов Label Set. Элемент называется идентификатором субканала и его формат совпадает с форматом обобщенной метки.
Label_Set включает:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action | Reserved | Label Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subchannel 1 | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subchannel N | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Action (действие) – 8 битов
0 – Inclusive List — список включения
Показывает, что объект/TLV содержит один или множество элементов субканалов, включенных в Label Set.
1 – Exclusive List — список исключения
Показывает, что объект/TLV содержит один или множество элементов субканалов, исключенных из Label Set.
2 – Inclusive Range — диапазон включения
Показывает, что объект/TLV содержит диапазон меток. Объект/TLV включает два элемента субканалов — первый задает начало, второй — конец диапазона. Нулевое значение элемента указывает на отсутствие привязки для соответствующей границы.
3 – Exclusive Range — диапазон исключения
Показывает, что объект/TLV содержит диапазон меток, исключенных из Label Set. Объект/TLV включает два элемента субканалов — первый задает начало, второй — конец диапазона. Нулевое значение элемента указывает на отсутствие привязки для соответствующей границы.
Reserved – 10 битов
Резервное поле, которое должно устанавливаться в 0 при передаче и игнорироваться на приеме.
Label Type (тип метки) – 14 битов
Указывает тип и формат меток, передаваемых в объекте /TLV. Значения зависят от сигнального протокола.
Subchannel (субканал) – субканал
Два субканала представляют метку (длину волны, волокно, …), которая может быть выделена. Это поле имеет такой же формат, как указано для меток в параграфе 3.2.
Отметим, что отображение субканала на идентификатор локального канала (например, длину волны) имеет локальную значимость.
4. Двухсторонние LSP
В этом разделе определяется прямая поддержка двухсторонних LSP. Поддержка определяется для LSP, имеющих для обоих направлений одинаковые требования по организации трафика, включая совместное использование для данных и сигнализации (fate sharing), защиту и восстановление, маршрутизаторы LSR и требования к ресурсам (например, задержка и ее вариации). Далее в этом разделе термином «инициатор» (initiator) будет обозначаться узел, который начал организацию LSP, а термином «завершение» (terminator) — узел, являющийся целью данного LSP. Отметим, что для двухсторонних имеется лишь один инициатор и одно завершение.
Обычно для организации двухстороннего LSP при использовании [RFC3209] или [RFC3212] сначала должны независимо создаваться два односторонних пути. Такая модель имеет ряд недостатков.
-
Задержка организации двухсторонних LSP равна времени кругового обхода сигнальных сообщений плюс время передачи сигнала от инициатора к завершающему узлу. В результате растет не только задержка организации LSP, но и задержка обнаружения ошибок при организации (двойное время передачи сигналов между инициатором и завершением). Эти задержки особенно важны при создании LSP в процессе восстановления.
-
Издержки, связанные с управлением, возрастают вдвое по сравнению с односторонним LSP. Это обусловлено тем, что управляющие соединения (например, Path и Resv) должны независимо генерироваться для обоих сегментов двухстороннего LSP.
-
Размещение ресурсов в раздельных сегментах осложняет выбор маршрута. Возникает также вероятность дополнительной конкуренции при выделении ресурсов, снижающая шансы успешной организации двухстороннего соединения.
-
Сложнее обеспечить «чистый» интерфейс для оборудования SONET/SDH, на котором может быть основана поинтервальная защита пути с помощью коммутации.
-
Двухсторонние оптические LSP (lightpath) становятся требованием для многих операторов оптических сетей.
При двухсторонних LSP нисходящий и восходящий путь передачи данных (т. е., от инициатора к завершению и обратно) организуются с использованием одного набора сигнальных сообщений. Это ускоряет организацию до одного периода кругового обхода сигнальных сообщений плюс время на их обработку, а также снижает сигнальные издержки, поскольку число требуемых сообщений будет таким же, как для односторонних LSP.
4.1. Требуемая информация
Для двухсторонних LSP должны выделяться две метки. Организация двухстороннего LSP указывается присутствием объекта/TLV Upstream Label в соответствующем сигнальном сообщении. Формат Upstream Label совпадает с форматом обобщенной метки (параграф 3.2).
4.2. Устранение конфликтов
Могут возникать конфликты из-за выделения меток между двумя двухсторонними LSP, организуемыми в противоположных направлениях. Это происходит в тех случаях, когда обе стороны выделяют одни и те же ресурсы (метки) фактически в одно время. Если нет каких-либо ограничений на использование меток для двухсторонних LSP и имеются дополнительные ресурсы, оба узла будут передавать в восходящем направлении разные метки и конфликта не произойдет. Однако при наличии ограничений на использование меток для двухсторонних LSP (например, они должны быть физически связаны с одной платой ввода-вывода) или отсутствии дополнительных ресурсов требуется разрешение конфликтной ситуации иными средствами. Для устранения конфликта преимущество отдается узлу с большим значением идентификатора (node ID) и этот узел должен передать сообщение PathErr/NOTIFICATION с индикацией ошибки Routing problem/Label allocation failure (проблема маршрутизации или отказ при выделении метки). Получившему такое сообщение узлу следует попытаться выделить другую метку Upstream (и другую Suggested Label, при использовании предлагаемых меток) для двухстороннего пути. Однако при отсутствии доступных ресурсов узел должен выполнить стандартную обработку ошибок.
Для снижения вероятности конфликта можно ввести правило, в соответствии с которым узел с меньшим значением ID никогда не будет предлагать метку в нисходящем направлении и всегда воспринимать Suggested Label от узла восходящего направления с большим ID. Кроме того, поскольку обмен метками может происходить с использованием LMP, можно дополнительно ввести локальное правило (по отношению к меткам с большими номерами из набора меток узла), по которому узел с большим номером может выбирать метки со старшего края диапазона меток, а узел с меньшим номером — с младшего. Этот механизм позволяет усилить алгоритмы плотной упаковки, которые могут применяться для оптимизации диапазонов или длин волн. Следует отметить особый случай использования RSVP с поддержкой этого решения — идентификатор соседнего узла может быть не известен при отправке первоначального сообщения Path. В такой ситуации узлу следует предлагать случайно выбранную метку из числа доступных.
Пример конфликта между двумя узлами (PXC 1 и PXC 2) показан на рисунке 1. В этом примере PXC 1 выделяет метку Upstream Label для канала, соответствующего локальному идентификатору BCId=2 (локальный BCId=7 на PXC 2) и отправляет Suggested Label для канала, соответствующего локальному BCId=1 (локальный BCId=6 на PXC 2). Одновременно PXC 2 выделяет метку Upstream Label для канала, соответствующего его локальному BCId=6 (локальный BCId=1 на PXC 1) и передает Suggested Label для канала, соответствующего его локальному BCId=7 (локальный BCId=2 на PXC 1). Если нет ограничений на метки, которые могут использоваться для двухсторонних LSP и имеются дополнительные ресурсы оба узла PXC 1 и PXC 2 будут передавать в восходящем направлении разные метки и конфликт будет устранен (рисунок 2). Однако при наличии ограничений на метки, которые могут применяться для двухсторонних LSP (например, если они должны быть физически привязаны к одной плате ввода-вывода), потребуется устранение конфликта с использованием идентификатора узла (рисунок 3).
+------------+ +------------+ + PXC 1 + + PXC 2 + + + SL1,UL2 + + + 1 +------------------------>+ 6 + + + UL1, SL2 + + + 2 +<------------------------+ 7 + + + + + + + + + + 3 +------------------------>+ 8 + + + + + + 4 +<------------------------+ 9 + +------------+ +------------+
Рисунок 1. Конфликт меток
В этом примере PXC 1 выделяет метку Upstream Label, используя BCId=2 (BCId=7 на PXC 2), и метку Suggested Label, используя BCId=1 (BCId=6 на PXC 2). Одновременно PXC 2 выделяет метку Upstream Label, используя BCId=6 (BCId=1 на PXC 1), и Suggested Label, используя BCId=7 (BCId=2 на PXC 1).
+------------+ +------------+ + PXC 1 + + PXC 2 + + + UL2 + + + 1 +------------------------>+ 6 + + + UL1 + + + 2 +<------------------------+ 7 + + + + + + + L1 + + + 3 +------------------------>+ 8 + + + L2 + + + 4 +<------------------------+ 9 + +------------+ +------------+
Рисунок 2. Устранение конфликта при неограниченных ресурсах.
В этом случае нет ограничения на метки, используемые для двухсторонних соединений и конфликта не возникает.
+------------+ +------------+ + PXC 1 + + PXC 2 + + + UL2 + + + 1 +------------------------>+ 6 + + + L2 + + + 2 +<------------------------+ 7 + + + + + + + L1 + + + 3 +------------------------>+ 8 + + + UL1 + + + 4 +<------------------------+ 9 + +------------+ +------------+
Рисунок 3. Устранение конфликта при ограниченных ресурсах.
В этом случае должны использоваться метки 1,2 и 3,4 на PXC 1 (метки 6,7 и 8,9 на PXC 2, соответственно) для одного двухстороннего соединения. Поскольку узел PXC 2 имеет большее значение идентификатора, ему отдается преимущество и узел PXC 1 должен поменять используемый набор меток.
5. Уведомление о Label Error
В традиционной MPLS и GMPLS возникают ситуации, приводящие к сообщениям о неприемлемом значении метки (Unacceptable label value), как описано в [RFC3209], [RFC3472] и [RFC3473]. При возникновении таких ситуаций для узла, генерирующего такое сообщение может оказаться полезным указание вызвавшей ошибку метки. Для этого в GMPLS обеспечивается возможность передачи дополнительных данных поле Acceptable Label Set, включаемое в подходящее протокольное сообщение об ошибке (см. [RFC3472] и [RFC3473]).
Формат Acceptable Label Set идентичен формату Label Set, описанному в параграфе 3.5.1.
6. Явное управление метками
В традиционной MPLS интерфейсы, используемые LSP могут контролироваться через явные маршруты (например, ERO или ER-Hop). Это позволяет включать конкретный узел/интерфейс и завершать LSP на конкретном выходном интерфейсе выходного LSR. Этот интерфейс может иметь адрес, но это не обязательно (unnumbered) [MPLS-UNNUM].
Возникают случаи, когда семантика наличия явных маршрутов не обеспечивает полной информации для достаточного контроля LS. Это происходит, если инициатор LSP пожелает выбрать метку, используемую на канале. Проблема, в частности, связана с тем, что ERO и ER-Hop не поддерживают субобъектов явных меток. Примером желательности такого механизма будет случай «сращивания» двух LSP, когда «голова» одного пути присоединяется к «хвосту» другого. Возникновение таких ситуаций достаточно очевидно для каналов без поддержки PSC.
Для решения этой проблемы предназначен субобъект ERO/ER Hop.
6.1. Требуемая информация
Label Explicit и Record Routes содержат:
L — 1 бит
Этот бит должен иметь значение 0.
U — 1 бит
Этот бит указывает направление метки — значение 0 применяется для меток нисходящего направления, 1 — для восходящего. Бит применяется только для двухсторонних LSP.
Label — переменный размер
Это поле идентифицирует используемую метку. Формат поля идентичен формату поля Label в Generalized Label, описанному в параграфе 3.2.1.
Размещение и порядок этих полей зависит от протокола сигнализации.
7. Информация о защите
Информация о защите (Protection Information) передается в новом объекте/TLV и служит для указания связанных с соединением атрибутов защиты запрошенного LSP. Использование Protection Information для конкретного LSP является не обязательным. Protection Information в настоящее время указывает желаемый тип защиты LSP. Если запрошен конкретный тип (например, 1+1 или 1:N), запрос на организацию соединения обрабатывается лишь в том случае, когда этот уровень защиты может быть обеспечен. Отметим, что возможности защиты каналов могут анонсироваться в маршрутизации (см. [GMPLS-RTG]). Алгоритмы расчета путем принимают информацию о защите во внимание при поиске пути для организации LSP.
Protection Information также показывает является данный LSP основным или вторичным. Вторичный LSP служит резервным путем для основного LSP. Ресурсы вторичного LSP не используются, пока на основном пути не возникает отказ. Выделенные для вторичного LSP ресурсы могут использоваться другими LSP, пока на основном для этого пути LSP не возникает отказов. В момент возникновения отказа на основном LSP все использованные ресурсы вторичного LSP должны быть возвращены и переданы для резервного пути.
7.1. Требуемая информация
В Protection Information передаются следующие данные:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved | Link Flags| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Secondary (S) – 1 бит
Установка этого флага показывает, что запрашиваемый LSP является вторичным LSP.
Reserved – 25 битов
Это поле является резервным. Оно должно содержать нулевое значение при передаче и должно игнорироваться на приемной стороне. Транзитным узлам следует передавать эти биты в неизменном виде.
Link Flags – 6 битов
Флаги, показывающие желаемый тип защиты канала. Как отмечено выше, возможности защиты канала могут анонсироваться в протоколы маршрутизации. Нулевое значение поля показывает допустимость любого типа защиты (включая ее отсутствие). Допускается установка множества битов поля для индикации набора желаемых типов защиты. При установке множества флагов и доступности разных типов защиты выбор конкретного типа определяется локальной политикой.
Определены следующие флаги:
0x20 Enhanced
Указывает, что следует использовать на канальном уровне схему защиты, которая более надежна, чем Dedicated 1+1 (например, 4 волокна BLSR/MS-SPRING).
0x10 Dedicated 1+1
Указывает, что для поддержки LSP следует использовать схему защиты с выделенным соединением канального уровня 1+1.
0x08 Dedicated 1:1
Указывает, что для поддержки LSP следует использовать схему защиты с выделенным соединением канального уровня 1:1.
0x04 Shared
Указывает, что для поддержки LSP следует использовать схему защиты с разделяемым соединением канального уровня (например, 1:N).
0x02 Unprotected
Показывает, что для LSP не следует использовать какую-либо защиту на канальном уровне.
0x01 Extra Traffic
Показывает, что для LSP следует использовать каналы, которые служат для защиты другого (основного) трафика. Такие LSP могут разрываться при возникновении необходимости передачи через канал первичного защищаемого трафика.
8. Информация об административном статусе
Данные Administrative Status Information передаются в новом объекте/TLV и используются в настоящее время двумя способами. Во-первых, они показывают административный статус конкретного LSP. Путь может находиться в состоянии up (активен) или down (не активен), а также в режиме тестирования (testing) или удаления. Предпринимаемые узлом действия, основанные на состоянии пути, определяются локально. Примером таких действий может служить подавление сигналов тревоги для LSP в состоянии down или testing, а также информирование о связанных с соединением сигналах, имеющих приоритет не выше Non service affecting (без воздействия на сервис).
Второй вариант использования Administrative Status Information связан с индикацией запросов на установку административного состояния LSP. Информация всегда транслируется входному узлу, который действует по запросу.
Различия в применении зависят от протокола и более подробно описаны в [RFC3473] и [RFC3472]. Применение Administrative Status Information для конкретного LSP не является обязательным.
8.1. Требуемая информация
Информация, передаваемая в Administrative Status Information, показана ниже.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Reserved |T|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reflect (R) — 1 бит
Установленный бит говорит, что граничному узлу следует вернуть объект/TLV в подходящем для этого сообщении. Этот флаг недопустимо устанавливать в запросах смены состояния (например, сообщениях Notify).
Reserved — 28 битов
Резервное поле, которое должно устанавливаться в 0 при передаче и должно игнорироваться при получении. Транзитным узлам следует передавать это поле в неизменном виде.
Testing (T) — 1 бит
Установленный бит показывает, что следует выполнить локальные действия, связанные с режимом тестирования.
Administratively down (A) — 1 бит
Установленный флаг показывает, что следует выполнить локальные действия, связанные с режимом административного отключения.
Deletion in progress (D) — 1 бит
Установленный флаг показывает, что следует выполнить локальные действия, связанные с разборкой LSP. Граничные узлы могут использовать этот флаг для контроля за разрывом соединений.
9. Разделение каналов управления
Концепция канала управления, отдельного от сигнализации, передаваемой в канале данных, была введена в MPLS вместе с группировкой соединений (bundling) в [MPLS-BUNDLE]. В GMPLS разделение каналов данных и управления может быть обусловлено многими факторами, включая группировку и другие случаи, когда каналы данных не могут передаваться вместе с управляющей информацией в основной полосе. В этом разделе рассматриваются два тесно связанных вопроса — идентификация каналов данных в сигнализации и обработка отказов в каналах управления, не влияющих на каналы данных.
9.1. Идентификация интерфейсов
В традиционной MPLS имеется неявная взаимно-однозначная связь между каналами данных и управления. Когда имеется такая связь, не нужно дополнительной или специальной информации для того, чтобы связать транзакцию по созданию конкретного LSP с конкретным каналом данных (эта информация неявно представлена в канале управления, через который передаются сигнальные сообщения).
В тех случаях, когда явно нет взаимно-однозначной связи между каналом данных и каналом управления, в сигнализации требуется передать дополнительную информацию, идентифицирующую канал данных, для которого будет осуществляться управление. GMPLS поддерживает явную идентификацию каналов данных с помощью идентификаторов интерфейсов. GMPLS позволяет использовать множество схем идентификации интерфейсов, включая адреса IPv4 и IPv6, индексы интерфейсов (см. [MPLS-UNNUM]) и компоненты интерфейсов (организуются путем настройки или с помощью протоколов типа [LMP]). Во всех случаях выбор интерфейса указывается узлом восходящего направления с использованием адресов и идентификатором, применяемых вышестоящим узлом.
9.1.1. Требуемая информация
Информация, передаваемая в Interface_ID, показана ниже.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLV ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Для каждого TLV используется показанный ниже формат.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length – 16 битов
Показывает общий размер TLV (4 + размер поля Value) в октетах. Для полей Value, размер которых не кратен 4, должно использоваться дополнение нулями для выравнивания по 4-октетной границе.
Type – 16 битов
Указывает тип идентифицируемого интерфейса. Определенные значения показаны ниже.
-
Тип
Размер
Формат
Описание
1
8
Адрес IPv4
IPv4
2
20
Адрес IPv6
IPv6
3
12
См. ниже IF_INDEX
Индекс интерфейса
4
12
См. ниже COMPONENT_IF_DOWNSTREAM
Компонентный интерфейс
5
12
См. ниже COMPONENT_IF_UPSTREAM
Компонентный интерфейс
Для типов 3 – 5 поле Value имеет формат, показанный ниже.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Address – 32 бита
Поле IP Address может передавать IP-адрес канала или IP-адрес, связанный с маршрутизатором, где связанный адрес представляет собой значение, передаваемое в поле адреса маршрутизатора TLV маршрутизации.
Interface ID – 32 бита
Для типа 3 поле Interface ID содержит идентификатор интерфейса.
Для типов 4 и 5 поле Interface ID указывает собранный компонентный канал. Может использоваться специальное значение 0xFFFFFFFF для индикации того, что одна и та же метка применима ко всем компонентным каналам.
9.2. Обработка отказов
Для случая независимых каналов данных и управления требуется обрабатывать два новых случая отказов. К первому случаю относятся неполадки в канале или других местах, ограничивающие возможности соседних узлов в части передачи управляющих сообщений. При этом соседние узлы не способны к обмену управляющими сообщениями в течение достаточно продолжительного интервала времени. После восстановления связи нижележащий сигнальный протокол должен показать, что узлы поддерживали свои состояния во время отказа. Сигнальный протокол должен также обеспечить синхронизацию между узлами состояний, изменившихся во время отказа.
Второй случай связан с отказом уровня управления на узле после которого следует перезагрузка с потерей значительной части информации о состоянии. В этом случае оба узла (нисходящего и восходящего направления) должны синхронизировать свою информацию о состоянии с перезагруженным узлом. Для выполнения такой синхронизации перезагружаемому узлу нужно сохранить некоторую информацию типа отображения входящих меток на исходящие.
Оба случая обрабатываются в зависимости от протокола 9см. [RFC3473] и [RFC3472]).
Отметим, что описанное выше относится лишь к ситуациям, когда имеются механизмы независимого обнаружения отказов на каналах данных и каналах управления.
10. Благодарности
Этот документ является результатом работы множества людей и представляет собой композицию из многих документов, опубликованных ранее и посвященных той же теме.
Были получены полезные комментарии и предложения от многих людей, включая Igor Bryskin, Adrian Farrel, Ben Mack-Crane, Dimitri Papadimitriou, Fong Liaw и Juergen Heiles. Некоторые разделы документа основаны на тексте, представленном Fong Liaw.
11. Вопросы безопасности
Этот документ не порождает новых вопросов безопасности по сравнению с отмеченными в [RFC3212] и [RFC3209], которые к соответствующим определяемым протоколами формам GMPLS (см. [RFC3473] и [RFC3472]).
12. Согласование с IANA
IANA будет администрировать выделение новых значений в пространствах имен, определенных в данном документе. В этом параграфе используется терминология BCP 26 «Guidelines for Writing an IANA Considerations Section in RFCs» [BCP26].
В данном документе определены следующие пространства имен:
-
LSP Encoding Type – 8 битов;
-
Switching Type – 8 битов;
-
Generalized PID (G-PID) – 16 битов;
-
Action – 8 битов;
-
Interface_ID Type – 16 битов.
Все новые значения следует выделять по процедуре IETF Consensus или документировать в спецификации.
LSP Encoding Type — допустимы значения от 1 до 255 (включительно), данный документ определяет значения 1 – 11.
Switching Type — допустимы значения от 1 до 255 (включительно), данный документ определяет значения 1 – 4, 100, 150 и 200.
Generalized PID (G-PID) — допустимы значения от 0 до 1500 (включительно), данный документ определяет значения 0 – 46.
Action — допустимы значения от 1 до 255 (включительно), данный документ определяет значения 0 – 3.
Interface_ID Type — допустимы значения от 1 до 65535 (включительно), данный документ определяет значения 1 – 5.
13. Интеллектуальная собственность
Текст этого раздела взят из параграфа 10.4 работы [RFC2026].
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF’s procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
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. and B. Thomas, “LDP Specification”, RFC 303611, January 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and 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. and A. Malis, “Constraint-Based LSP Setup using LDP”, RFC 3212, January 2002.
[RFC3472] Ashwood-Smith, P. and 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 Progress12.
[GMPLS-SONET] Ashwood-Smith, P., et al., “GMPLS – SONET / SDH Specifics”, Work in Progress.
[LMP] Lang, et al., “Link Management Protocol”, Work in Progress13.
[MPLS-BUNDLE] Kompella, K., Rekhter, Y. and L. Berger, “Link Bundling in MPLS Traffic Engineering”, Work in Progress14.
[MPLS-HIERARCHY] Kompella, K. and Y. Rekhter, “LSP Hierarchy with MPLS TE”, Work in Progress15.
[RFC2026] Bradner, S., “The Internet Standards Process – Revision 3,” BCP 9, RFC 2026, October 1996.
[RFC2434] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 2434, October 1998.
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon, “Multiprotocol label switching Architecture”, RFC 3031, January 2001.
15. Разработчики
Peter Ashwood-Smith
Nortel Networks Corp.
P.O. Box 3511 Station C,
Ottawa, ON K1Y 4H7
Canada
Phone: +1 613 763 4534
EMail: petera@nortelnetworks.com
Ayan Banerjee
Calient Networks
5853 Rue Ferrari
San Jose, CA 95138
Phone: +1 408 972-3645
EMail: abanerjee@calient.net
Lou Berger
Movaz Networks, Inc.
7926 Jones Branch Drive
Suite 615
McLean VA, 22102
Phone: +1 703 847-1801
EMail: lberger@movaz.com
Greg Bernstein
EMail: gregb@grotto-networking.com
John Drake
Calient Networks
5853 Rue Ferrari
San Jose, CA 95138
Phone: +1 408 972 3720
EMail: jdrake@calient.net
Yanhe Fan
Axiowave Networks, Inc.
200 Nickerson Road
Marlborough, MA 01752
Phone: + 1 774 348 4627
EMail: yfan@axiowave.com
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
EMail: kireeti@juniper.net
Jonathan P. Lang
EMail: jplang@ieee.org
Eric Mannie
Independent Consultant
2 Avenue de la Folle Chanson
1050 Brussels
Belgium
EMail: eric_mannie@hotmail.com
Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Phone: +1 732 923 4237
Fax: +1 732 923 9804
EMail: braja@tellium.com
Yakov Rekhter
Juniper Networks, Inc.
EMail: yakov@juniper.net
Debanjan Saha
EMail: debanjan@acm.org
Vishal Sharma
Metanoia, Inc.
1600 Villa Street, Unit 352
Mountain View, CA 94041-1174
Phone: +1 650-386-6723
EMail: v.sharma@ieee.org
George Swallow
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Phone: +1 978 244 8143
EMail: swallow@cisco.com
Z. Bo Tang
EMail: botang01@yahoo.com
16. Адрес редактора
Lou Berger
Movaz Networks, Inc.
7926 Jones Branch Drive
Suite 615
McLean VA, 22102
Phone: +1 703 847-1801
EMail: lberger@movaz.com
Перевод на русский язык
Николай Малых
17. Полное заявление авторских прав
Copyright (C) The Internet Society (2003). Все права защищены.
Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.
Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.
Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.
Подтверждение
Финансирование функция RFC Editor обеспечено Internet Society.
1Multi-Protocol Label Switching — многопротокольная коммутация по меткам.
2Generalized MPLS — обобщенная MPLS.
3Synchronous Optical Network, Synchronous Digital Hierarchy.
4Label Switching Router — маршрутизатор с коммутацией по меткам.
5Packet-Switch Capable — способные коммутировать пакеты.
6Time-Division Multiplex Capable — поддерживающие мультиплексирование с разделением по времени.
7Lambda Switch Capable — способные коммутировать по длине волны (лямбда).
8Fiber-Switch Capable — способные коммутировать волокна.
9Label Switched Path — путь с коммутацией по меткам.
10Forwarding Adjacency – смежность по пересылке.
13Работа завершена и опубликована в RFC 4204. Прим. перев.
14Работа завершена и опубликована в RFC 4201. Прим. перев.
15Работа завершена и опубликована в RFC 4206. Прим. перев.
