RFC 5586 MPLS Generic Associated Channel

Network Working Group                                      M. Bocci, Ed.
Request for Comments: 5586                             M. Vigoureux, Ed.
Updates: 3032, 4385, 5085                                 Alcatel-Lucent
Category: Standards Track                                 S. Bryant, Ed.
                                                           Cisco Systems
                                                               June 2009

 

Связанный канал MPLS

MPLS Generic Associated Channel

PDF

Статус документа

Данный документ содержит спецификацию протокола, предложенного сообществу Internet, и служит запросом к дискуссии в целях развития протокола. Информацию о статусе данного протокола можно найти в текущей редакции документа “Internet Official Protocol Standards” (STD 1). Документ может распространяться свободно.

Авторские права

Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов. Все права защищены ((c) 2009).

К этому документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно.

Аннотация

Этот документ обобщает применимость заголовков связанных каналов псевдопровода (PW ACH¹), разрешая реализацию канала управления, связанного с MPLS LSP² и MPLS Section в дополнение к MPLS pseudowire. Для идентификации присутствия заголовка ACH в стеке меток данный документ выделяет одну из резервных меток MPLS в качестве GAL³ для использования в качестве механизма исключения по меткам.

1. Введение

Существует потребность в механизмах OAM⁴, пригодных для обнаружения отказов, диагностики, поддержки и других функций на псевдопроводах (PW) и путях с коммутацией по меткам (LSP). Эти функции могут применяться между любыми двумя маршрутизаторами LER/LSR⁵ или T-PE/S-PE⁶ на пути LSP или PW, соответственно [MPLS-TP]. Некоторые из таких функций могут поддерживаться с использованием имеющихся средств типа VCCV⁷ [RFC5085], BFD-MPLS⁸ [BFD-MPLS], LSP-Ping [RFC4379], BFD-VCCV [BFD-VCCV]. Однако были отмечены требования в части усиления этого набора функций поддержки и, в частности, при использовании сетей MPLS для услуг доставки пакетов и операций транспортных сетей [OAM-REQ]. Примеры таких функций включают мониторинг производительности, автоматическую защитную коммутацию, а также поддержку коммуникационных каналов для сигнализации и управления. Такие средства должны быть подходящими и работать одинаково (с операционной точки зрения) для MPLS PW, MPLS LSP и MPLS Section. Они также должны работать в основной полосе (in-band) PW или LSP, чтобы не зависеть от маршрутизации PSN⁹ или пользовательского трафика, зависимость от функций динамического уровня управления недопустима.

VCCV [RFC5085] может использовать ACH¹⁰ для обеспечения связанного с PW канала управления между конечными точками PW, через который будут передаваться сообщения OAM и другие управляющие сообщения. Этот документ обобщает применимость ACH для обеспечения возможности применения того же механизма связанного канала управления, который применяется для Section, LSP и PW. Обобщенный связанный канал управления называется G-ACh¹¹. ACH, описанные в RFC 4385 [RFC4385], могут применяться с дополнительными кодами для поддержки добавочных функций поддержки MPLS через G-ACh.

Обобщение применимости ACH к LSP и Sections также требует метода идентификации пакетов, в которых за ACH следуют не относящиеся к сервису данные (non-service payload). Следовательно, этот документ определяет также механизм исключения на основе меток, который служит для информирования LSR (или LER) о том, что пакет, полученный в LSP или Section, относится к связанному каналу управления. Используемая для этого метка относится к резервным меткам MPLS и обозначается GAL¹². Механизм GAL определен для использования с ACH на LSP и MPLS Section.

RFC 4379 [RFC4379] и BFD-MPLS [BFD-MPLS] определяют сигнальные механизмы, которые позволяют MPLS LSR идентифицировать и обрабатывать пакеты MPLS OAM, инкапсулированные в заголовки IP. Эти сигнальные механизмы базируются, например, на завершении времени жизни (TTL¹³) и/или использовании IP-адреса получателя из блока 127.0.0.0/8 или 0:0:0:0:0:FFFF:127.0.0.0/104 для IPv4 и IPv6, соответственно. Эти механизмы используются по умолчанию для идентификации пакетов MPLS OAM, инкапсулированных в заголовок IP. Однако использование этих механизмов не всегда возможно для некоторых приложений MPLS — например, для MPLS Transport Profile (MPLS-TP) [MPLS-TP], особенно при невозможности использования демультиплексирования по IP. Данный документ определяет механизм, рекомендуемый для идентификации и инкапсуляции MPLS OAM и других управляющих сообщений при недоступности механизмов на базе IP типа тех, которые применяются в [RFC4379] и [BFD-MPLS]. Этот механизм может служить и дополнением к механизмам, основанным на IP.

Отметим, что функции и пакеты управления, описываемые в этом документе, следует понимать в широком смысле, как множество механизмов управления и поддержки, включающее сообщения OAM, APS¹⁴, SCC¹⁵ и MCC¹⁶.

Отметим также, что GAL и ACH в общем случае применимы к MPLS и PW. Данный документ задает общие механизмы и использует MPLS-TP в качестве примера. Применение GAL и ACH к другим конкретным приложениям MPLS выходит за рамки документа.

1.1. Цели

Этот документ определяет механизм, обеспечивающий решение задач технической поддержки для новых приложений MPLS. Предложен базовый механизм организации канала управления, который может использоваться для MPLS LSP и Section, сохраняя совместимость по управлению со связанными каналами PW. Механизм также нормализует использование ACH для PW в транспортном контексте и определяет механизм исключения на основе меток, позволяющий сигнализировать устройствам LER/LSR присутствие ACH под стеком меток.

1.2. Сфера применения

Документ определяет инкапсуляцию заголовков для сообщений связанных каналов управления Section, LSP и PW.

Документ не определяет сигнализацию или согласование возможностей связанного канала между устройствами LER/LSR или PE, а также не определяет работу функций OAM.

Документ не отменяет имеющиеся для MPLS и PW механизмы OAM.

1.3. Уровни требований и терминология

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с RFC 2119 [RFC2119].

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

ACH¹⁷ — заголовок связанного канала.

G-ACh¹⁸ — базовый связанный канал.

GAL — метка базового связанного канала.

Пакет G-ACh — любой пакет, содержащий относящееся к протоколу сообщение, который передается через связанный канал управления PW, LSP или MPLS Section. Примерами могут служить такие протоколы, как OAM, сигнальные коммуникации, управление.

Термины Section и Concatenated Segment (соединенный сегмент) определены в [TP-REQ] как приведено ниже (отметим, что Section и Section Layer Network являются синонимами).

Section Layer Network

Уровень секции представляет собой уровень сервера (MPLS-TP или иная технология), обеспечивающий перенос информации клиента уровня секции между смежными узлами на уровне транспортного пути или транспортного сервиса. Отметим, что G.805 [G805] определяет уровень секции, как один из двух уровней в сети уровня среды передачи. Другим уровнем является уровень физической среды.

Concatenated Segment — сцепленный сегмент

Последовательность связанных между собой соединений, как определено в [G805]. Сцепленный сегмент является непрерывной частью LSP или многосегментного PW, который представляет собой цепочку сегментов и соединяющих их узлов.

2. Заголовок базового связанного канала

VCCV [RFC5085] определяет три типа каналов управления (CC¹⁹), которые могут использоваться для обмена сообщениями OAM через PW. CC Type 1 использует ACH и называется In-band VCCV (VCCV по основному каналу), CC Type 2 использует метки MPLS Router Alert Label для индикации пакетов VCCV и называется Out-of-Band VCCV (VCCV по отдельному каналу), CC Type 3 использует TTL для того, чтобы форсировать обработку пакетов целевым уровнем управления и называется MPLS PW Label with TTL == 1 (метка MPLS PW с TTL = 1).

2.1. Определение

Использование ACH, ранее ограниченное PW, сейчас обобщено для случаев LSP и Section. Отметим, что для PW управляющее слово PWE3 [RFC4385] должно присутствовать в инкапсуляции пользовательских пакетов, когда ACH применяется для реализации связанного канала управления.

ACH использует CC Type 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version|   Reserved    |         Channel Type          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 1. Заголовок связанного канала

На рисунке 1 первый полубайт имеет значение 0001b для индикации канала управления, связанного с PW, LSP или Section. Поле Version имеет значение 0 в соответствии с RFC 4385 [RFC4385]. Биты 8 – 15 заголовка ACH являются резервными и должны устанавливаться в 0 при передачи и игнорироваться на приемной стороне. Биты 16 – 31 используются для представления возможных значений Channel Type (16-битовое поле с сетевым порядком байтов).

Отметим, что VCCV [RFC5085] включает также механизмы согласования для Control Channel и типа Connectivity Verification (т. е., функций OAM) между PE. Предполагается, что аналогичные механизмы будут применяться и для LSP. Такие приложения потребуют разработки дополнительных спецификаций, выходящих за рамки этого документа.

G-ACh недопустимо применять для транспортировки пользовательского трафика.

2.2. Выделение типа канала

Поле Channel Type указывает тип сообщений, которые передаются по связанному каналу управления — например, IPv4 или IPv6, если для передачи сообщений по связанному каналу используется демультиплексирование IP, или OAM и другие функции управления, если демультиплексирование IP не используется. Для связанного канала управления где IP не используется для мультиплексирования, поле Channel Type указывает конкретный протокол, поддерживаемый в связанном канале управления.

Значения Channel Type, используемые в настоящее время для VCCV, заданы в других документах (например, RFC 4446 [RFC4446] и RFC 4385 [RFC4385]). Дополнительные значения Channel Type и связанная с ними функциональность управления может определяться в других документах. Каждый документ, описывающий протокольное решение на основе ACH, должен указывать также применимое для протокола значение поля Channel Type.

Отметим, что эти значения выделяются из реестра PW Associated Channel Type [RFC4446] и данный документ меняет существующие правила с учетом экспериментального уровня. Дополнительная информация приведена в разделе 10.

3. ACH TLV

В некоторых случаях применения обобщенных связанных каналов требуется включение одного или множества ACH TLV для обеспечения дополнительной контекстной информации пакету G-ACh. Одним из применений таких ACH TLV может быть идентификация отправителя и/или предусмотренного получателя для сообщения в связанном канале. Однако использование такой конструкции не ограничивается предоставлением адресной информации и приложениями транспортного уровня.

Если сообщению G-ACh могут предшествовать ACH TLV, они должны быть явно указаны в определении ACH Channel Type. Если определение ACH Channel Type не говорит о возможности присутствия одного или множества ACH TLV перед G-ACh, заголовок ACH TLV Header должен следовать за ACH. Если в конкретном пакете связанного канала не требуется ACH TLV, но Channel Type определяет возможность использования ACH TLV, заголовок ACH TLV Header должен присутствовать с нулевым значением поля размера, показывающим отсутствие ACH TLV.

Если спецификация ACH Channel Type не указывает явно возможность использования ACH TLV, использовать заголовок ACH TLV Header недопустимо.

3.1. Структура данных ACH TLV

В этом параграфе определена и описана структура данных ACH при наличии ACH TLV Header.

На рисунке 2 показана структура данных пакета G-ACh.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ACH                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         ACH TLV Header                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               ~
~                     0 или более ACH TLV                       ~
~                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               ~
~                        G-ACh Message                          ~
~                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2. Данные пакета G-ACh

3.2. Заголовок ACH TLV

Заголовок ACH TLV Header определяет размер следующего за ним множества ACH 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Length               |            Reserved           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 3. Заголовок ACH TLV

Поле Length указывает число октетов в полном наборе TLV, следующем за ACH TLV Header (включая суб-TLV). Нулевой размер показывает, что после заголовка нет ACH TLV. Отметим, что заполнения для набора ACH TLV не требуется.

Поле Reserved предназначено для использования в будущем и должно устанавливаться в 0 при отправке и игнорироваться при получении.

3.3. Объект ACH TLV

После заголовка ACH TLV Header могут следовать ACH 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           TLV Type            |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               ~
~                             Value                             ~
~                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 4. Формат ACH TLV

ACH TLV состоит из 16-битового поля Type, за которым следует 16-битовое поле Length, указывающее число октетов в поле Value. Формат и семантика информации в поле Value определяются значением TLV Type, как указано в реестре TLV Type (дополнительная информация приведена в разделе 10). Отметим, что поле Value в ACH TLV может содержать суб-TLV. Для отдельных TLV и суб-TLV заполнение с целью выравнивания не требуется.

4. Обобщенный механизм исключения

Обобщение механизма связанного канала на случаи LSP и Section требует также метода идентификации наличия в пакете с ACH не относящихся к сервису данных. В этом документе указано использование для таких целей специальной метки, названной G-ACh Label (GAL). Для этой метки используется одно из резервных значений, определенных в RFC 3032 [RFC3032]. Агентство IANA выделило для метки GAL значение 13.

Метка GAL обеспечивает сигнал на базе механизма исключений для:

• отличия специфических пакетов (например, G-ACh) от прочих (например, пользовательских);

• индикации наличия ACH непосредственно под стеком меток.

Метки GAL должны использоваться только в тех случаях, когда требуется достижение обеих целей.

4.1. Связи между существующими механизмами MPLS OAM Alert

RFC 4379 [RFC4379] и BFD-MPLS [BFD-MPLS] определяют сигнальные механизмы, которые позволяют MPLS LSR идентифицировать и обрабатывать пакеты MPLS OAM при их инкапсуляции в IP. Эти механизмы основаны, например, на завершении времени жизни (TTL²⁰) и,или использовании IP-адреса получателя из блоков 127.0.0.0/8 или 0:0:0:0:0:FFFF:127.0.0.0/104 для IPv4 и IPv6, соответственно.

Эти механизмы используются по умолчанию для идентификации пакетов MPLS OAM при их инкапсуляции в IP, хотя могут применяться и механизмы, определенные в данном документе.

4.2. Применимость и использование GAL

В MPLS-TP метка GAL должна использоваться с пакетами в G-ACh на LSP, сцепленных сегментах (Concatenated Segment) LSP и с Section, но недопустимо использование этой метки с PW. Метка всегда должна находиться на дне стека меток (т. е., бит S должен быть установлен). Однако для других сред MPLS этот документ не вносит ограничений на расположение метки GAL в стеке и ее применение с PW. Когда метка GAL размещается на дне стека (бит S = 1), за ней всегда должен следовать заголовок ACH.

Метку GAL недопустимо включать в стек меток при транспортировке обычных пользовательских пакетов. При использовании меток GAL недопустимо присутствие в стеке более одной метки.

Принимающему устройству LSR, LER или PE недопустимо пересылать пакеты G-ACh другим узлам на основе метки GAL.

4.2.1. Обработка меток GAL

Поле класса трафика (TC²¹) элемента LSE²², содержащее GAL, следует определению и правилам обработки, заданным в [RFC5462].

Поле времени жизни (TTL) для LSE, включающее метку GAL, следует определению и правилам обработки, заданным в [RFC3443].

4.2.1.1. Пути и сегменты MPLS

На рисунке 5 показаны два устройства LER (A и D) и два LSR (B и C) для данного LSP, организованного от A к D и коммутируемого в B и C.

+---+             +---+             +---+             +---+
| A |-------------| B |-------------| C |-------------| D |
+---+             +---+             +---+             +---+

Рисунок 5. Техническая поддержка через LSP

В этом примере G-ACh существует на LSP между устройствами LER, обозначенными A и D, через коммутаторы LSR, обозначенные B и C. Новые пакеты G-ACh могут инициировать только устройства A и D. Устройства A, B, C и D могут обрабатывать пакеты G-ACh и отвечать на них.

На рисунке 6 показан формат пакета MPLS-TP G-ACh, используемого для LSP.

 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 Label               |  TC |S|       TTL     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  GAL                  |  TC |S|       TTL     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ACH                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  ACH TLV Header (при наличии)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               ~
~                     0 или более ACH TLV                       ~
~                           (при наличии)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               ~
~                         G-ACh Message                         ~
~                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 6. Формат пакета G-ACh для LSP

Отметим, что возможно туннелирование LSP через другой LSP (например, при наличии туннеля MPLS между B и C) и по этой причине в стеке могут присутствовать другие LSE.

Для передачи сообщения G-ACh по связанному с LSP каналу управления LER (A) генерирует сообщение G-ACh, перед которым может быть добавлен (prepend) заголовок ACH TLV Header и подходящие ACH TLV. Затем добавляется ACH, в который «вталкивается» GAL LSE. В заключении в результирующий пакет «вталкивается» метка LSP Label LSE.

• Для поля TTL в GAL LSE должно устанавливаться значение не менее 1. Точное значение TTL зависит от приложения. Определение и правила обработки приведены в параграфе 4.2.1.

• Бит S в GAL должен устанавливаться в соответствии с положением метки в стеке (см. параграф 4.2).

• Установка поля TC в GAL зависит от приложения. Определение и правила обработки приведены в параграфе 4.2.1.

Устройствам LSR недопустимо изменять сообщения G-ACh, ACH или GAL в направлении целевого получателя.

Примечание. Это обусловлено тем, что после отправки пакета G-ACh в LSP ни один узел не видит его, пока не завершится TTL для метки LSP или метка GAL не будет раскрыта при выталкивании метки LSP из стека. Если это происходит у целевого получателя, например, указанного адресом в ACH TLV, может быть выполнена обработка, указанная ниже. Если же это происходит в другом месте, но узел согласен обрабатывать пакеты на данном канале ACH, обработка пакета выходит за рамки этого документа.

При получении помеченного пакета целевому адресату после проверки полей LSP Label и GAL LSE следует передать весь пакет подходящему средству обработки.

4.2.1.2. MPLS Section

На рисунке 7 показан пример MPLS Section.

+---+             +---+
| A |-------------| Z |
+---+             +---+

Рисунок 7. Техническая поддержка MPLS Section

По отношению к MPLS Section канал G-ACh существует между A и Z. Только A и Z могут помещать, извлекать и обрабатывать пакеты в этом G-ACh.

На рисунке 8 показан формат пакета G-ACh при использовании MPLS Section. Метка GAL может указывать механизм исключения для управляющего канала без привязки к конкретному LSP, обеспечивая возможность связанных с поддержкой коммуникаций через конкретный канал, соединяющий два LSR. В этом случае GAL является единственной меткой в стеке.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  GAL                  |  TC |S|       TTL     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             ACH                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  ACH TLV Header (при наличии)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               ~
~                     0 или более ACH TLV                       ~
~                         (при наличии)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               ~
~                         G-ACh message                         ~
~                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Рисунок 8. Формат пакета G-ACh для MPLS Section.

Для отправки сообщения G-ACh в управляющий канал, связанный с Section, головной (head-end) LSR (A) в этой секции (Section) создает сообщение G-ACh, перед которым от может поместить ACH TLV Header и подходящие ACH TLV. После этого LSR добавляет ACH с в заключение выталкивает (push) GAL LSE.

• Поле TTL в GAL должно иметь значение не меньше 1. Точное значение TTL зависит от приложения. Определение и правила обработки приведены в параграфе 4.2.1.

• Бит S в GAL должен устанавливаться в соответствии с положением в стеке меток (см. параграф 4.2).

• Значение поля TC в GAL зависит от приложения. Определение и правила обработки даны в параграфе 4.2.1.

Промежуточным узлам MPLS Section недопустимо изменять сообщение G-ACh, ACH и GAL в направлении оконечного (tail-end) LSR (Z). При получении пакета G-ACh оконечному LSR (Z) после проверки полей GAL LSE следует передать пакет целиком подходящему модулю обработки.

4.3. Связь с RFC 3429

В RFC 3429 [RFC3429] описано выделение одного из резервных значений меток, определенных в RFC 3032 [RFC3032], в качестве метки OAM Alert, которая применяется на пользовательском уровне (user-plane) функций MPLS OAM для идентификации пакетов MPLS OAM. Для этого использовано значение 14.

Следовательно, данный документ и RFC 3429 [RFC3429] описывают выделение резервных значений меток с близкими целями. Обоснование выделения новой метки из резерва приведено ниже.

• В отличие от механизмов, описанных и упоминаемых в RFC 3429 [RFC3429], сообщения G-ACh не будут размещаться сразу после GAL и будут находиться за заголовком связанного канала ACH, который, сам по себе, размещается после дна стека меток.

• Множество функций управления, которые могут работать в контексте G-ACh, шире набора функций OAM, упоминаемых в RFC 3429 [RFC3429].

• Было отмечено, что имеющиеся реализации и развернутые системы используют OAM Alert Label в соответствии с RFC 3429 [RFC3429]. Следовательно, нет возможности изменить выделение, предназначение или применение OAM Alert Label. Тем не менее, рекомендуется впредь не разрабатывать и не специфицировать расширений OAM на основе OAM Alert Label (Label 14).

5. Совместимость

Процедуры обработки пакетов, принятых с непригодной входящей меткой, заданы в RFC 3031 [RFC3031].

Устройства LER, LSR или PE должны отбрасывать принятые пакеты связанного канала, в которых были вытолкнуты все метки MPLS или PW при выполнении любого из приведенных ниже условий.

• Неспособность обработать пакеты с типом (Channel Type), указанным заголовком ACH принятого пакета.

• Пакет не помечен средствами, не входящими в данную спецификацию, для отправки устройству LSR, LER или PE, которое будет обрабатывать пакеты связанного канала для Channel Type, указанного заголовком ACH в принятом пакете.

• Пакет получен с типом Experimental Channel Type, который в настоящее время запрещен.

• Если ACH указывает присутствие GAL и первый полубайт ACH в принятом пакете отличается от 0001b.

• Версия заголовка ACH не распознана.

В дополнение устройства LER, LSR или PE могут увеличивать значение счетчика ошибок, а также могут генерировать уведомление на уровне системы и/или протокола SNMP²³.

6. Вопросы насыщения

Вопросы насыщения, рассмотренные в RFC 5085 [RFC5085], применимы и здесь.

7. Основные авторы

Редакторы благодарны George Swallow, David Ward и Rahul Aggarwal за значительный вклад в разработку этого документа.

George Swallow

Cisco Systems

Email: swallow@cisco.com

David Ward

Cisco Systems

Email: dward@cisco.com

Rahul Aggarwal

Juniper Networks

Email: rahul@juniper.net

8. Благодарности

Редакторы выражают признательность Sami Boutros, Italo Busi, Marc Lasserre, Lieven Levrau и Siva Sivabalan за вклад в работу.

Авторы также благодарят Malcolm Betts (ITU-T Study Group 15) и всех членов объединенных команд MPLS Interoperability Design Team в IETF и MPLS-TP Ad Hoc Team в ITU-T, вовлеченных в определение и спецификацию транспортного профиля MPLS.

9. Вопросы безопасности

Проблемы безопасности для связанного канала управления рассмотрены RFC 4385 [RFC4385]. Дополнительное рассмотрение вопросов безопасности должно включать в соответствующие спецификации типов связанных каналов.

В RFC 5085 [RFC5085] рассмотрены вопросы безопасности, связанные с уровнем данных (data plane). Это рассмотрение применимо и к G-ACh, независимо от использования GAL или только ACH.

10. Взаимодействие с IANA

Агентство IANA выделило метку 13 для GAL из блока резервных меток в реестре Multiprotocol Label Switching Architecture (MPLS) Label Values.

Значения Channel Type для Associated Channel Header выделены из реестра IANA PW Associated Channel Type [RFC4446]. Выделение значений из реестра PW Associated Channel Type в настоящее время осуществляется с согласия IETF (процедура IETF Review в [RFC5226]). Такой способ выделения был выбран на основе согласованного мнения членов рабочей группы PWE3 о том, что механизмы связанных каналов для псевдопроводов должны рецензироваться IETF с выделением кодов лишь для тех механизмов, которые согласуются с архитектурой и требованиями PWE3.

Однако возникло требование (см. [OAM-REQ]) обеспечить возможность экспериментальной оптимизации или расширений OAM и других протоколов управления, работающих на связанных каналах, без привлечения процесса стандартизации IETF. Это позволит предотвратить использование для таких экспериментов кодов, выделенных в процессе стандартизации IETF, и защитить установленное оборудование от возможной непреднамеренной перегрузки кодами. Для поддержки этой потребности агентство IANA изменило схему распределения кодов для PW Associated Channel Type, как показано ниже:

0 – 32751 : IETF Review

32760 – 32767 : Experimental

Коды из выделенного для экспериментов диапазона должны использоваться в соответствии с рекомендациями RFC 3692 [RFC3692]. Функции, использующие экспериментальные коды G-ACh, по умолчанию должны быть отключены. Значение Channel Type, применяемое для такой экспериментальной функции OAM, должно быть настраиваемым, а также должны быть приняты меры по обеспечению использования во взаимодействующих функциях OAM разных значений Channel Type.

Значение	Описание	Следующий TLV	Документ
0x21	ACH передается в пакете IPv4	нет	[RFC4385]
	ACH передается в пакете IPv6	нет	[RFC4385]

Рисунок 9. Реестр типов каналов PW.

Реестр PW Associated Channel Type был обновлен путем включения колонки, указывающей наличие следующего за ACH заголовка ACH TLV header (да/нет). В настоящее время выделены два кода ACH Channel Type и для обоих заголовки ACH TLV не используются. Таким образом, для нового формата реестра PW Channel Type агентство IANA создало новый реестр Associated Channel Header TLV Registry. Значения в из этого реестра выделяются на основании рецензии IETF. В реестре должна указываться приведенная ниже информация. Изначально реестр пуст.

Имя	Тип	Размер в октетах	Описание	Документ

Рисунок 10. Реестр ACH TLV.

11. Литература

11.1. Нормативные документы

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, “Multiprotocol Label Switching Architecture”, RFC 3031, January 2001.

[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, “MPLS Label Stack Encoding”, RFC 3032, January 2001.

[RFC3443] Agarwal, P. and B. Akyol, “Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks”, RFC 3443, January 2003.

[RFC3692] Narten, T., “Assigning Experimental and Testing Numbers Considered Useful”, BCP 82, RFC 3692, January 2004.

[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, “Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN”, RFC 4385, February 2006.

[RFC4446] Martini, L., “IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)”, BCP 116, RFC 4446, April 2006.

[RFC5085] Nadeau, T. and C. Pignataro, “Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires”, RFC 5085, December 2007.

[RFC5226] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 5226, May 2008.

[RFC5462] Andersson, L. and R. Asati, “Multiprotocol Label Switching (MPLS) Label Stack Entry: “EXP” Field Renamed to “Traffic Class” Field”, RFC 5462, February 2009.

11.2. Дополнительная литература

[BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, “BFD For MPLS LSPs”, Work in Progress²⁴, June 2008.

[BFD-VCCV] Nadeau, T. and C. Pignataro, “Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)”, Work in Progress²⁵, May 2009.

[G805] International Telecommunication Union, “Generic Functional Architecture of Transport Networks”, ITU-T G.805, March 2000.

[MPLS-TP] Bocci, M., Bryant, S., and L. Levrau, “A Framework for MPLS in Transport Networks”, Work in Progress²⁶, November 2008.

[OAM-REQ] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., “Requirements for OAM in MPLS Transport Networks”, Work in Progress²⁷, March 2009.

[RFC3429] Ohta, H., “Assignment of the ‘OAM Alert Label’ for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions”, RFC 3429, November 2002.

[RFC4379] Kompella, K. and G. Swallow, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures”, RFC 4379, February 2006.

[TP-REQ] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, “MPLS-TP Requirements”, Work in Progress²⁸, May 2009.

Адреса авторов

Matthew Bocci (редактор)

Alcatel-Lucent

Voyager Place, Shoppenhangers Road

Maidenhead, Berks SL6 2PJ

UK

EMail: matthew.bocci@alcatel-lucent.com

Martin Vigoureux (редактор)

Alcatel-Lucent

Route de Villejust

Nozay, 91620

France

EMail: martin.vigoureux@alcatel-lucent.com

Stewart Bryant (редактор)

Cisco Systems

EMail: stbryant@cisco.com

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru