RFC 8077 Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)

Internet Engineering Task Force (IETF)                   L. Martini, Ed.
Request for Comments: 8077                                 G. Heron, Ed.
STD: 84                                                            Cisco
Obsoletes: 4447, 6723                                      February 2017
Category: Standards Track
ISSN: 2070-1721

Организация и поддержка псевдопровода с использованием протокола LDP

Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)

PDF

Аннотация

Услуги канального уровня (типа Frame Relay, ATM¹, Ethernet) можно эмулировать в опорных сетях MPLS путем инкапсуляции PDU² канального уровня и передачи их через псевдопровода (PW³). Псевдопровода (ПП) можно также использовать для эмуляции низкоскоростных каналов TDM⁴ и SONET⁵ через сети с поддержкой MPLS. В этом документе описан протокол организации и поддержки псевдопроводов с использованием протокола LDP⁶. Процедуры инкапсуляции Layer 2 PDU описаны в отдельных документах.

Этот документ является заменой RFC 4447 для публикации в качестве стандарта Internet.

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

Этот документ является проектом стандарта (Internet Standards Track).

Документ является результатом работы IETF⁷ и представляет собой согласованное мнение сообщества IETF. Документ был вынесен на публичное рассмотрение и одобрен для публикации IESG⁸. Дополнительная информация о документах BCP представлена в разделе 2 документа RFC 7841.

Информация о текущем статусе этого документа, обнаруженных ошибках и способах обратной связи может быть найдена по ссылке http://www.rfc-editor.org/info/rfc8077.

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

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

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права, этот документ не может быть изменен вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.

1. Введение

В [RFC4619], [RFC4717], [RFC4618] и [RFC4448] описана инкапсуляция PDU канального уровня для передачи через сети с поддержкой MPLS. Этот документ указывает добавление «заголовка псевдопровода», состоящего из поля демультиплексирования, перед инкапсулируемым PDU. Поле демультиплексора псевдопровода (ПП) добавляется перед отправкой пакета в ПП. Когда пакет приходит на удаленную сторону ПП, поле демультиплексирования позволяет получателю определить конкретный ПП, к которому относится пакет. При передаче пакета с одного конца ПП на другой этому пакету может потребоваться прохождение через туннель PSN⁹, для которого будет требоваться добавление перед пакетом дополнительного заголовка.

[RFC4842] и [RFC4553] задают два метода транспортировки цифровых сигналов (эмуляция устройств) TDM через ориентированные на работу с пакетами сети с поддержкой MPLS. Системой передачи для ориентированных на соединения (circuit-oriented) сигналов TDM является SONET[ANSI]/SDH¹⁰[ITUG]. Для поддержки трафика TDM, который включает голосовую связь, передачу данных и услуги выделенных линий ПП должны эмулировать характеристики устройств элементов (payload) SONET/SDH. Сигналы и данные TDM инкапсулируются для передачи через ПП. Демультиплексор ПП и заголовок туннеля PSN помещаются перед этими инкапсулированными данными.

В [RFC4553] описан метод транспортировки низкоскоростных цифровых сигналов TDM (эмуляция устройств TDM) через сети PSN, а в [RFC4842] приведено аналогичное описание для высокоскоростных устройств TDM (SONET/SDH). Для поддержки трафика TDM псевдопровода должны эмулировать характеристики устройств в оригинальных системах T1, E1, T3, E3, SONET или SDH. В [RFC4553] это выполняется путем инкапсуляции произвольного (по постоянного) объема данных TDM в каждый пакет, а также с использованием других методов инкапсуляции структур TDM.

      |<------------- Эмулируемая служба --------------->|
      |                                                  |
      |          |<------ Псевдопровод ------>|          |
      |          |                            |          |
      |Подключен.|    |<-- Туннель PSN ->|    |Подключен.|
      |устройствоV    V                  V    Vустройство|
      V   (AC)   +----+                  +----+   (AC)   V
+-----+    |     | PE1|==================| PE2|     |    +-----+
|     |----------|............PW1.............|----------|     |
| CE1 |    |     |    |                  |    |     |    | CE2 |
|     |----------|............PW2.............|----------|     |
+-----+  ^ |     |    |==================|    |     | ^  +-----+
      ^  |       +----+                  +----+     | |  ^
      |  | Граница провайдера 1  Граница провайдера 2 |  |
      |  |                                            |  |
Граница  |                                            |  Граница
польз. 1 |                                            |  польз. 2
         |                                            |
 Естественный сервис                          Естественный сервис

Рисунок 1. Эталонная модель PWE3

В этом документе задается использование протокола распространения меток MPLS (LDP¹¹) [RFC5036] в качестве протокола для организации и поддержки псевдопроводов. В частности, определены новые TLV, элементы FEC¹², параметры и коды для LDP, позволяющие идентифицировать ПП и сигнализировать их атрибуты. Задано использование конечными точками ПП этих TLV в протоколе LDP для привязки поля демультиплексирования к ПП и способ передачи информации об этой привязке удаленной конечной точке. Заданы также процедуры информирования о смене состояния ПП для передачи дополнительной информации о ПП и освобождения привязок. Эти процедуры предназначены для обеспечения независимости от версии протокола IP, используемого для сигнализации LDP.

В представленном здесь протоколе поле демультиплексирования ПП является меткой MPLS. Таким образом, пакеты, передающиеся с одного конца ПП на другой, являются пакетами MPLS, которые должны передаваться через туннель MPLS. Однако, если конечные точки ПП являются непосредственно смежными и на предпоследнем этапе используется «вталкивание» (popping), туннель MPLS становится не обязательным. Можно использовать туннель PSN любого типа, если через него возможна передача пакетов MPLS. Туннель PSN, сам по себе, может быть MPLS LSP или просто поддерживать передачу пакетов MPLS. Процедуры организации и поддержки туннелей MPLS выходят за рамки этого документа.

+------------------+                           +------------------+
|Эмулируемый сервис|                           |Эмулируемый сервис|
|(напр., TDM, ATM) |<=== Эмулируемый сервис ==>|(напр., TDM, ATM) |
+------------------+                           +------------------+
|  Инкапсуляция    |                           |  Инкапсуляция    |
|  данных          |<===== Псевдопровод ======>|  данных          |
+------------------+                           +------------------+
|PW Demultiplexer  |                           |PW Demultiplexer  |
|   PSN Tunnel,    |<====== Туннель PSN ======>|  PSN Tunnel,     |
| PSN и физический |                           | PSN и физический |
|     уровни       |                           |     уровни       |
+--------+---------+        ___________        +----------+-------+
         |                /             \                 |
         +===============/     PSN       \================+
                         \               /
                          \_____________/

Рисунок 2. Эталонная модель стека протоколов PWE3

Этот документ связан только с организацией и обслуживанием псевдопроводов типа «точка-точка». ПП типа «один со многими» (point-to-multipoint) или «многие с одним» (multipoint-to-point) не рассматриваются.

Связанные с QoS вопросы не рассматриваются в этом документе.

На рисунках 1 и 2 приведены эталонные модели, взятые из [RFC3985] и иллюстрирующие поддержку услуг эмуляции PW.

В этом документе PE1¹³ будет определять, как входной маршрутизатор, а PE2 — как выходной. PDU канального уровня могут приниматься на PE1, инкапсулироваться там, транспортироваться и декапсулироваться на PE2, а потом передаваться PE2.

2. Отличия от RFC 4447

Отличия этого документа от предшественника состоят в исправлении незначительных ошибок и опечаток, а также устранения неясностей в тексте, отмеченных в качестве ошибок [RFC4447] или обнаруженных редакторами.

Кроме того, был добавлен параграф 7.3. Повторное согласование управляющего слова с помощью Label Request, отменяющий документ [RFC6723]. Диаграмма с процедурами обработки биты C также была удалена. В параграфе 6.3.2 добавлено примечание, уточняющее принадлежность бита C к упреждающему контролю ошибок FEC.

Добавлена ссылка на [RFC7358] для индикации использования нисходящего режима без запроса (downstream unsolicited mode) для распространения привязок меток PW FEC, независимо от согласованного режима анонсирования меток для сессии LDP.

3. Уровни требований

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

4. Метка PW

Предположим, что нужно транспортировать L2 PDU со входа LSR PE1 на выход LSR PE2 через сеть с поддержкой MPLS и имеется туннель MPLS от PE1 до PE2. Т. е., предполагается, что PE1 может организовать доставку пакета PE2, инкапсулируя его в «заголовок туннеля MPLS» и передавая полученный в результате пакет одному из своих соседей. Туннель MPLS представляет собой MPLS LSP¹⁴, поэтому инкапсуляция в туннель MPLS является способом «вталкивания» метки MPLS.

Предполагается, что через один туннель MPLS может быть организовано множество ПП и это требует поддержки в ядре сети состояния для отдельного псевдопровода. Не предполагается, что туннель MPLS относится с типу «точка-точка», хотя ПП являются именно такими соединениями. Тем не менее, туннель MPLS может быть организован в одну точку из множества других (multipoint to point). Не предполагается, что PE2 может определить туннель MPLS, из которого был передан полученный пакет (например, если туннель MPLS является LSP и используется «выталкивание на предпоследнем интервале» (penultimate hop popping), прибывший на PE2 пакет не содержит информации, идентифицирующей туннель).

Когда устройство PE2 получает пакет через ПП, оно должно быть способно определить, что этот пакет фактически был принят через псевдопровод и связать его с конкретным ПП. PE2 может сделать это, проверяя метку MPLS, которая указана в поле демультиплексирования псевдопровода, как показано на рисунке 2. Назовем ее «меткой PW».

Когда устройство PE1 передает L2 PDU устройству PE2, оно создает пакет MPLS, добавляя в него метку PW и затем создавая первый элемент в стеке меток. Если туннель PSN представляет собой MPLS LSP, устройство PE1 «вталкивает» в пакет другую метку (метка туннеля) в качестве второго элемента стека меток. Метка PW не видна, пока пакет MPLS не достигнет PE2. Устройство PE2 размещает пакет в соответствии с меткой PW.

Если данные в пакете MPLS представляют собой, например, AAL5¹⁵ PDU, метка PW будет в общем случае соответствовать конкретному виртуальному каналу ATM VC¹⁶ на PE2. Т. е.. устройство PE2 должно иметь возможность определить по метке PW выходной интерфейс и значение VPI/VCI¹⁷ для AAL5 PDU. Если данные представляют собой Frame Relay PDU, устройство PE2 должно иметь возможность определить по метке PW выходной интерфейс и значение DLCI¹⁸. Если данные являются кадром Ethernet, устройство PE2 должно иметь возможность определить по метке PW выходной интерфейс и, возможно, идентификатор VLAN. Эти процессы являются односторонними и будут повторяться независимо для двухстороннего режима. При использовании элемента PWid FEC Element требуется выделять одинаковые PW ID и тип PW для обоих направления данного канала. Недопустимо требовать совпадения Group ID (см. ниже) для обоих направления. Транспортируемый кадр может быть изменен при попадании на выходной маршрутизатор. Если заголовок транспортируемого кадра L2 изменяется, такое изменение должно выполняться только на выходном LSR. Отметим, что метка PW всегда должна быть на дне стека меток пакета и метки должны выделяться из пространства меток платформы.

Этот документ не задает метод распространения меток туннеля MPLS и других меток, которые могут присутствовать в стеке над меткой PW. Это может обеспечить любой подходящий метод распространения меток MPLS. Документ задает метод выделения и распространения меток PW. Этот протокол представляет собой LDP, расширенный в соответствии с приведенным ниже описанием. Между конечными точками ПП должна быть организована сессия LDP. Протокол LDP должен обмениваться привязками меток PW FEC в нисходящем направлении без запроса, независимо от согласованного режима анонсирования меток в сессии LDP согласно спецификации [RFC7358]. Следует применять «либеральный режим удержания меток» (liberal label retention) LDP. Однако все процедуры LDP, указанные в [RFC5036] и применимые к данному протоколу, должны быть реализованы.

В соответствии с этим документом принимающий маршрутизатор LSR должен отвечать на сообщение Label Request сообщением Label Mapping для запрошенной метки или сообщением Notification, указывающим причину отказа. Эти процедуры описаны в [RFC5036] (параграфы «3.5.7. Сообщение Label Mapping» и «3.5.8. Сообщение Label Request»). Отметим, что отправка таких откликов является более жестким требованием, чем задано в [RFC5036] и эти отклики требуются для обеспечения корректной работы протокола.

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

Этот документ задает все процедуры, требуемые для организации и поддержки псевдопроводов, которые нужны для предоставления «некоммутируемых» услуг типа «точка-точка», где каждая конечная точка имеет отождествление конечной точки на другом конце ПП. Здесь также заданы механизмы, которые могут применяться для предоставления коммутируемых услуг и поддержки других моделей обслуживания. Однако использование протокольных механизмов для поддержки других моделей и услуг не рассматривается в этом документе.

5. Детали конкретных эмулируемых служб

5.1. Транспорт IP L2

В этом режиме через ПП передаются пакеты IP, инкапсулируемые в соответствии с [RFC3032]. Управляющее слово PW может помещаться между стеком меток MPLS и данными IP. Инкапсуляция пакетов IP для пересылки на устройство присоединения (AC¹⁹) зависит от реализации в части функции естественного обслуживания (NSP²⁰) [RFC3985] и выходит за рамки этого документа.

6. LDP

Привязка метки PW распространяется с использованием нисходящего режима LDP без запроса, описанного в [RFC5036]. Устройства PE будут организовывать сессию LDP, используя механизм Extended Discovery, описанный в параграфах 2.4.2 и 2.5 [RFC5036].

Сообщение LDP Label Mapping содержит FEC TLV, Label TLV и может также включать TLV дополнительных параметров.

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

LDP позволяет включать в каждый набор FEC TLV множество элементов FEC. Для организации и поддержки ПП каждый набор FEC TLV должен включать в точности один элемент FEC.

Базовая спецификация LDP поддерживает несколько типов TLV для меток, включая Generic Label TLV, как описано в параграфе 3.4.2.1 [RFC5036]. Для организации и поддержки ПП должны применяться Generic Label 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  PWid (0x80)  |C|         PW type             |PW info length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Group ID                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           PW ID                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Interface Parameter Sub-TLV                    |
|                              "                                |
|                              "                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.1. Элемент PWid FEC

Элемент PWid FEC может использоваться в тех случаях, когда оба конца псевдопровода снабжены одним 32-битовым идентификатором для этого ПП.

Для этих целей определен новый тип элемента FEC с идентификатором типа 0x80, показанный на рисунке.

Control word bit (C)

Бит C является флагом наличия управляющего слова:

C = 1 – управляющее слово присутствует для этого PW;

C = 0 – PW не имеет управляющего слова.

Дополнительная информация приведена в разделе 7. Управляющее слово.

PW type

15-битовое поле, значение которого представляет тип PW. Выделенные значения представлены в документе «IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)» [RFC4446].

PW info length

Размер полей PW ID и Interface Parameter Sub-TLV в октетах. Нулевое значение представляет все PW, использующие указанный Group ID и говорит об отсутствии PW ID и каких-либо Parameter Sub-TLV.

Group ID

Произвольное 32-битовое значение, представляющее группу PW, использованных для создания групп в пространстве PW. Идентификатор группы (Group ID) предназначен для использования в качестве индекса порта или виртуального туннеля. Для упрощения конфигурации Group ID конкретного PW на входе может быть частью Group ID, выделенного для виртуального туннеля, служащего для транспортировки к выходному маршрутизатору. Идентификаторы групп Group ID очень полезны при передаче шаблонных отзывов меток или шаблонных сообщений Notification удаленным PE при физическом отказе порта.

PW ID

Отличный от нуля 32-битовый идентификатор соединения, который совместно с типом PW указывает конкретный PW. Отметим, что PW ID и тип PW должны совпадать на обеих сторонах ПП.

Interface Parameter Sub-TLV

Этот TLV переменного размера обеспечивает зависимые от интерфейса параметры типа Attachment Circuit MTU.

Отметим, что Interface Parameter Sub-TLV является частью FEC, правила LDP делают невозможным изменение параметров интерфейса после организации ПП. Таким образом, поле параметров интерфейса недопустимо использовать для передачи информации (типа данных о состоянии), которая может изменяться в процессе использования ПП. Для этого следует применять Optional parameter TLV.

Используя PWid FEC, каждая из двух оконечных точек ПП независимо инициирует создание одностороннего LSP. Исходящий и входящий LSP связываются в один псевдопровод, если у них совпадают значения PW ID и тип ПП.

6.2. Обобщенный элемент PWid FEC

Элемент PWid FEC может использоваться, если для PW выделено уникальное 32-битовое значение и это значение предоставлено каждой конечной точке. Обобщенный элемент PWid FEC требует, чтобы конечные точки PW имели уникальные идентификаторы, сами PW идентифицируются парой конечных точек. В дополнение к этому идентификаторы конечных точек структурируются для поддержки приложений, где требуется идентификация удаленных узлов с автоматическим обнаружением, а не статической настройкой конфигурации.

Generalized PWid FEC Element представляет собой FEC типа 0x81.

Обобщенный элемент PWid FEC не содержит ничего, соответствующего Group ID элемента PWid FEC. Функциональность Group обеспечивается отдельным необязательным LDP TLV – PW Group ID TLV, описанным в параграфе 6.2.2.2. Поля параметров интерфейса элемента PWid FEC также отсутствуют, а их функциональность обеспечивается необязательным PW Interface Parameters TLV, описанным в параграфе 6.2.2.1.

6.2.1. Идентификаторы присоединения

Как сказано в [RFC3985], псевдопровод можно рассматривать, как соединение между двумя пересылающими узлами (forwarder). Протокол, используемый для организации псевдопровода, должен позволять узлу на одной стороне идентифицировать узел на другой стороне. Мы используем термин «идентификатор присоединения» или просто AI²¹ для обозначения поля, которое данный протокол применяет для идентификации узлов. В PWid FEC поле PWid служит в качестве AI. В этом параграфе будет описана более общая форма AI, которая структурирована и может менять размер.

С каждым пересылающим в PE должен быть связан AI путем задания в конфигурации или с помощью какого-либо алгоритма. Идентификатор присоединения должен быть уникален в контексте маршрутизатора PE, где размещается пересылающий (Forwarder). Комбинация <IP-адрес маршрутизатора PE, AI> должна быть уникальной в глобальном масштабе.

Зачастую удобно рассматривать множество Forwarder, как членов некой «группы», где PW могут организовываться только между членами этой группы. В таких случаях пересылающих удобно идентифицировать в рамках данной группы и разделять AI на идентификатор группы AGI²² и персональный идентификатор AII²³.

Идентификатор группы можно рассматривать, как VPN-id или идентификатор VLAN — некий атрибут, присущий всем Attachment PW (или пулам), которым разрешено подключение.

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

Как отмечено выше, (двунаправленные) псевдопровода состоят из пары односторонних LSP (по одному для каждого направления). Если конкретный псевдопровод соединяет PE1 с PE2, направление PW от PE1 к PE2 можно обозначить

      <PE1, <AGI, AII1>, PE2, <AGI, AII2>>

а направление PW от PE2 к PE1

      <PE2, <AGI, AII2>, PE1, <AGI, AII1>>

Отметим, что значения AGI должны совпадать на обоих концах, а значения AII в общем случае будут различаться. Таким образом, с точки зрения конкретного PE каждый псевдопровод имеет локальный (Source AII) и удаленный (Target AII) идентификатор. Протокол организации псевдопровода может передавать три приведенных ниже значения:

• идентификатор группы присоединения (AGI);

• индивидуальный идентификатор присоединения источника (SAII²⁴);

• индивидуальный идентификатор присоединения точки назначения (TAII²⁵).

Если AGI отличается от null, идентификатор SAI²⁶ состоит из AGI и SAII, а TAI²⁷ – из TAII вместе с AGI. Если AGI = null, SAII и TAII будут совпадать с SAI и TAI, соответственно.

Интерпретация SAI и TAI определяется локально соответствующей конечной точкой.

Связывание двух однонаправленных LSP в один двухсторонний псевдопровод зависит от SAI и TAI. Каждое приложение и/или модель предоставления, использующие обобщенный Pwid FEC, должны задавать правила для организации такой связи.

6.2.2. Представление обобщенного элемента PWid FEC

Используется элемент FEC типа 0x81, кодирование которого представлено ниже.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Gen PWid (0x81)|C|         PW Type             |PW info length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   AGI Type    |    Length     |      Value                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    AGI  Value (продолж.)                      ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   AII Type    |    Length     |      Value                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                   SAII  Value (продолж.)                      ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   AII Type    |    Length     |      Value                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                   TAII Value (продолж.)                       ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Этот документ не задает значения полей типа AII и AGI. Эти значения задаются спецификациями конкретных приложений, использующих поля. Агентство IANA выделяет значения для этих параметров с использованием метода, определенного в [RFC4446].

Значения SAII, TAII и AGI просто передаются в форме строк октетов. Байт Length задает размер поля Value. Для передачи пустой строки (null) может устанавливаться Length = 0. Если конкретному приложению не требуются все три элемента, оно должно передавать все три, устанавливая Length = 0 для ненужных элементов.

Поле PW information length учитывает размер элементов SAII, TAII и AGI в октетах. Нулевое значение указывает на все PW, использующие конкретное значение Group ID (указанное в PW Group ID TLV). В этом случае нет ни других полей элементов FEC (AGI, SAII и т. п.), ни PW Interface Parameters TLV.

Отметим, что трактовка конкретного поля, как AGI, SAII или TAII, зависит от порядка следования значений. Поле Type указывает тип AGI, SAII или TAII. При сравнении двух вхождений AGI (или SAII, TAII) значения считаются идентичными, если поля Type, Length и Value совпадают для обоих.

6.2.2.1. PW Interface Parameters TLV

Данный набор TLV должен применяться только при передаче Generalized PWid FEC и задает параметры конкретного интерфейса. Эти параметры (когда они применимы) должны применяться для проверки того, что устройства PE, а также входные и выходные порты на выходах устройств обладают требуемыми возможностями и совместимы друг с другом.

 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|  PW Intf P. TLV (0x096B)  |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type  |    Length     |    Variable Length Value      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Variable Length Value                 |
|                             "                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Более подробное описание этого поля приведено в параграфе 6.4. Interface Parameter Sub-TLV.

6.2.2.2. PW Group ID 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| PW Group ID TLV (0x096C)  |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Value                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PW Group ID представляет собой произвольное 32-битовое значение, которое указывает произвольную группу PW. Это поле служит для создания группы PW — например, PW Group ID можно использовать в качестве индекса порта и назначать всем PW, ведущим в данный порт. Использование PW Group ID позволяет PE передать «шаблонные» отзывы меток или «шаблонные» сообщения Notification для удаления PE при физическом отказе портов.

Примечание. PW Group ID отличается от AGI и не связан с ним.

PW Group ID TLV не является частью FEC и не будет анонсироваться (за исключением анонсов PW FEC). Анонсирование PE может использовать семантику шаблонного отзыва, а удаленные PE должны реализовать поддержку шаблонных сообщений. Эти TLV должны использоваться только при передаче Generalized PWid FEC.

Для ввода шаблонной команду (статус или отзыв):

• устанавливается PW Info Length = 0 в Generalized PWid FEC Element;

• передается только PW Group ID TLV с FEC (без передачи AGI/SAII/TAII).

6.2.3. Сигнальные процедуры

Для того, чтобы устройство PE1 могло начать сигнализацию PE2, PE1 нужно знать адрес удаленного PE2 и TAI. Эта информация может быть задана в конфигурации PE1 или определена динамически с помощью той или иной процедуры автоматического обнаружения.

Выходное устройство PE (PE1), которое знает о входе PE, инициирует организацию соединения путем отправки сообщения Label Mapping на входное устройство PE (PE2). Сообщение Label Mapping содержит FEC TLV с Generalized PWid FEC Element (тип 0x81), содержащий информацию AGI, SAII и TAII.

Затем, когда PE2 получает сообщение Label Mapping, устройство PE2 интерпретирует это сообщение, как запрос на организацию PW, конечная точка которого (в PE2) является пересылающим (Forwarder), указанным TAI. С точки зрения сигнального протокола способ отображения в PE2 значений AI на пересылающих (Forwarder) выбирается локально. В некоторых моделях предоставления VPWS²⁸ значение TAI может быть, например, строкой, указывающей конкретное устройство присоединения (типа ATM3VPI4VCI5), или строкой, связанной в параметрах конфигурации с конкретным устройством присоединения (типа Fred). В VPLS²⁹ значение AGI может быть идентификатором VPN-id, указывающим конкретный экземпляр VPLS.

Если PE2 не может отобразить TAI на одного из своих Forwarder, PE2 отправляет устройству PE1 сообщение Label Release с кодом состояния (Status Code) Unassigned/Unrecognized TAI и на этом обработка Label Mapping завершается.

FEC TLV в сообщении Label Release совпадает с FEC TLV, полученном в сообщении Label Mapping, которое будет «освобождено» (но без TLV с параметрами интерфейса). В общем случае FEC TLV одинаково во всех сообщениях LDP, относящихся к одному PW. В сообщении Label Release это означает, что SAII является AII удаленного партнера, а TAII — локальным AII отправителя.

Если сообщение Label Mapping имеет пригодный идентификатор TAI, устройство PE2 должно принять решение о восприятии этого сообщения. Процедуры принятия такого решения зависят от конкретного типа пересылающего (Forwarder), указанного TAI. Сообщение Label Mapping может быть отвергнуто по причине стандартных ошибок LDP, как описано в [RFC5036].

Если PE2 решает принять сообщение Label Mapping, это устройство должно быть уверено в том, что имеется PW LSP в обратном направлении (PE1–>PE2). Если сигнал о соответствующем PW LSP для этого направления уже был передан, ничего делать не нужно. В противном случае требуется начать такую сигнализацию путем передачи сообщения Label Mapping устройству PE1. Оно похоже на сообщение Label Mapping, полученное от PE2, но SAI и TAI меняются местами.

Таким образом, двухсторонний псевдопровод PW состоит из двух LSP, где FEC одного содержит SAII и TAII в порядке, обратном по сравнению с FEC в другом.

6.3. Сигнализация состояний псевдопровода

6.3.1. Использование сообщений отображения меток

Устройства PE должны передавать сообщения Label Mapping своим партнерам, как только PW настроен и включен административно, независимо от состояния устройства присоединения AC. Метку PW не следует отзывать, пока оператор не отключил псевдопровод административно (или не удалил полностью конфигурацию PW). С использованием описанных в этом параграфе процедур может также поддерживаться простой метод отзыва меток в качестве традиционной сигнализации о состоянии PW и AC. В любом случае при недоступности привязки метки к PW псевдопровод должен рассматриваться, как отключенный (down).

После завершения процедуры согласования статуса PW, если она приводит к использованию метода отзыва меток для обмена информацией о состоянии PW и этот метод не поддерживается одним из PE, данное устройство PE должно передать своему партнеру сообщение Label Release с ошибкой Label Withdraw PW Status Method Not Supported (метод отзыва меток не поддерживается).

Если метод отзыва меток для PW выбран, это приводит к тому, что сообщение Label Mapping будет анонсироваться только при активном устройстве присоединения (AC). Описанные в этом разделе сигнальные процедуры для состояния PW должны быть реализованы полностью.

6.3.2. Сигнализация состояния ПП

Устройства PE используют LDP TLV для индикации своего состояния удаленным партнерам. PW Status TLV содержит больше информации, нежели простое сообщение Label Withdraw.

Формат PW Status 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|     PW Status (0x096A)    |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Status Code                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Status Code представляет собой 4-октетное битовое поле, описанное в документе IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3) [RFC4446]. Поле Length указывает размер поля Status Code в октетах (4).

Каждый бит поля Status Code может устанавливаться индивидуально для индикации множества аспектов состояния в один прием. Каждый бит может сбрасываться путем отправки соответствующего сообщения Notification, в котором нужный бит сброшен. Младший бит (PW Not Forwarding) служит лишь индикатором общего отказа при возникновении события link-down (канал отключен), для которого ни один из остальных битов не подходит.

Status TLV доставляют удаленному партнеру PW в сообщении LDP Notification, как описано в [RFC5036]. Формат сообщения Notification с PW Status показан ниже.

 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|   Notification (0x0001)     |      Message Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Message ID                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Status (TLV)                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      PW Status TLV                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           PWid FEC TLV или Generalized ID FEC TLV             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                PW Group ID TLV (необязательно)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

В Status TLV устанавливают код состояния 0x00000028 (PW status) для индикации последующего состояния PW. Поскольку такое уведомление не относится к какому-либо конкретному сообщению, в поле Message ID устанавливается 0.

В PW FEC TLV не следует включать Interface Parameter Sub-TLV, поскольку они игнорируются в контексте данного сообщения. Однако PW FEC TLV должен включать бит C, когда это применимо, в качестве части FEC. Когда устройство присоединения в PE сталкивается с ошибкой, использование сообщений PW Notification позволяет PE передать одно «шаблонное» (wildcard) сообщение о состоянии, используя PW FEC TLV лишь с Group ID для обозначения того, что данное изменение состояния относится ко всем соединениям затронутым PW. Такое сообщение о состоянии содержит PW FEC TLV только с Group ID или Generalized FEC TLV только с PW Group ID TLV.

Как упоминалось выше, поле Group ID в PWid FEC Element или PW Group ID TLV, используемое с Generalized PWid FEC Element, может служить для передачи уведомления о состоянии для всех произвольных наборов PW. Эта процедура является необязательной и, если она реализована, сообщению LDP Notification следует соответствовать приведенному далее описанию. Если используется PWid FEC Element, в поле размера информации PW устанавливается 0, поле PW ID отсутствует и Interface Parameter Sub-TLV не указываются. Если используется Generalized FEC Element, значение AGI, SAII и TAII отсутствуют, в поле размера информации PW указывается 0, включается PW Group ID TLV, а PW Interface Parameters TLV опускается. В данном документе это называется «шаблонной процедурой уведомления о состоянии PW» и от всех реализаций PE, использующих такое решение, требуется воспринимать такие сообщение Notification, но не требуется передавать их.

6.3.3. Процедуры согласования состояний ПП

При первоначальной организации PW устройства PE должны попытаться согласовать использование PW Status TLV. Для этого PE, поддерживающее PW Status TLV, должно его включить в начальное сообщение Label Mapping после PW FEC и Interface Parameter Sub-TLV. PW Status 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                 PWid FEC или Generalized PWid FEC             +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Interface Parameters                    |
|                              "                                |
|                              "                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Generic Label (0x0200)    |      Length                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Label                                                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|     PW Status (0x096A)    |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Status Code                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Если PW Status TLV включается в начальное сообщение Label Mapping для PW, а сообщение Label Mapping от удаленного PE для этого PW не включает PW Status TLV или удаленное устройство PE не поддерживает PW Status TLV, PW будет использовать отзыв меток для сигнализации смены состояний PW. Отметим, что если PW Status TLV не поддерживается удаленным партнером, тот будет автоматически игнорировать его, поскольку в TLV устанавливается бит I (игнорировать). Следовательно, PW Status TLV не будет присутствовать в соответствующих анонсах FEC от удаленного партнера LDP, что обеспечивает в точности описанное выше поведение.

Если PW Status TLV не присутствует после FEC TLV в начальном сообщении PW Label Mapping, полученном PE, значит PW Status TLV не будет использоваться и оба устройства PE, поддерживающих псевдопровод вернутся к процедуре отзыва меток для сигнализации об изменении состояния.

Если процесс согласования привел к использованию PW Status TLV, реальный статус PW определяется PW Status TLV переданным в начальном сообщении PW Label Mapping. Последующие изменения состояния PW будут отражаться в сообщениях Notification.

6.4. Interface Parameter Sub-TLV

Это поле задает параметры конкретного интерфейса. Когда это применимо, поле должно применяться для проверки возможности взаимодействия устройств PE, а также входных выходных и выходных портов на них. Структура поля показана ниже.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type  |    Length     |    Variable Length Value      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Variable Length Value                 |
|                             "                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Значения Sub-TLV Type для параметров интерфейсов заданы в документе «IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)» [RFC4446].

• Тип Interface MTU

  2-октетное значение, указывающее MTU в октетах. Это максимальный размер блока (без учета издержек инкапсуляции) передаваемого выходным пакетным интерфейсом, который будет передавать декапсулированный PDU, полученный от сети с поддержкой MPLS. Это параметр относится только к PW, транспортирующим пакеты и требуется для PW этого типа. Если значения параметра для разных направлений конкретного PW не совпадают, включать такой PW недопустимо.

• Тип Optional Interface Description

  Эта произвольная (и необязательная) строка описания интерфейса служит для передачи понятной человеку строки, описывающей интерфейс с удаленным PE. Параметр является необязательным и применим для всех типов PW. Размер строки описания может составлять от 0 до 80 октетов. Предназначенный для человека текст должен представляться в кодировке UTF-8 с использованием принятого по умолчанию языка (Default Language) [RFC2277].

6.5. Процедуры отзыва меток LDP

Как указано выше, поле Group ID в PWid FEC Element или PW Group ID TLV используемом с Generalized PWid FEC Element, может служить для отзыва всех меток PW связанных с конкретной группой PW. Эта процедура является необязательной и (если она реализована) для сообщения LDP Label Withdraw следует использовать приведенные ниже правила. Если используется PWid FEC Element в поле размера информации PW указывается значение 0, поле PW ID не присутствует, отсутствуют также Interface Parameter Sub-TLV и Label TLV. Если используется Generalized FEC Element, поля AGI, SAII и TAII не присутствуют, в поле размера информации PW устанавливается значение 0, включается PW Group ID TLV, а PW Interface Parameters TLV и Label TLV отсутствуют. В данном документе это называется «шаблонной процедурой отзыва» и от всех PE, реализующих такое решение, требуется воспринимать такие сообщения об отзыве, но не требуется передавать их. Отметим, что PW Group ID TLV применимо только для PW, использующих Generalized ID FEC Element, а Group ID применимо только для PWid FEC Element.

Interface Parameter Sub-TLV или TLV недопустимо включать в какие-либо сообщения LDP PW Label Withdraw или Label Release. Шаблонное сообщение Label Release должно включать только Group ID или PW Group ID TLV. Сообщение Label Release, инициируемое маршрутизатором PE, всегда должно включать PW ID.

7. Управляющее слово

7.1. Типы PW, для которых управляющее слово ТРЕБУЕТСЯ

В сообщениях Label Mapping, передаваемых для организации таких PW, должно устанавливаться C=1. При получении для одного из таких типов PW сообщения Label Mapping с C=0, должно передаваться сообщение Label Release с кодом состояния Illegal C-bit. В этом случае PW не будет включен (разрешен).

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

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

Если система не способна передавать и принимать управляющее слово в PW тех типов, для которых это слово не является обязательным, она ведет себя в точности так, будто она настроена использование управляющего слова NOT PREFERRED.

Если сообщение Label Mapping для PW уже получено, но для этого PW еще не было передано сообщения Label Mapping, выполняется приведенная ниже процедура.

1. Если в полученном сообщении Label Mapping установлено C=0, передается сообщение Label Mapping с with C=0; управляющее слово не используется.

2. Если в полученном сообщении Label Mapping установлено C=1 и PW локально настроен на предпочтение управляющего слова, передается сообщение Label Mapping с with C=1; используется управляющее слово.

3. Если в полученном сообщении Label Mapping установлено C=1 и PW локально настроен так, что использование управляющего слова не является предпочтительным, полученное сообщение Label Mapping, по сути не принимается во внимание для PW (т. е., сразу выполняется следующий абзац).

Если сообщение Label Mapping для PW еще не было получено (или в полученном Label Mapping установлено C=1 и локальная конфигурация предпочитает не использовать управляющее слово или это слово не поддерживается), передается сообщение Label Mapping, в котором бит C соответствует локально настроенному режиму предпочтения для управляющего слова (т. е. C=1, если локально отдается предпочтение управляющему слову и C=0, если локальное предпочтение для управляющего слова не используется или управляющее слово не поддерживается).

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

1. Сообщение Label Mapping с таким же значением бита C, какое было указано в переданном сообщении Label Mapping. Организация PW на этом завершается и применяется управляющее слово, если C=1.

2. Сообщение Label Mapping с C=1, но переданное сообщение Label Mapping содержало C=0. В этом случае принятое сообщение Label Mapping игнорируется и продолжается ожидание следующего управляющего сообщения для данного PW.

3. Сообщение Label Mapping с C=0, но в отправленном сообщении Label Mapping было указано C=1. В этом случае передается сообщение Label Withdraw с кодом состояния Wrong C-bit и вслед за ним — сообщение Label Mapping с C=0. Организация PW на этом завершается и управляющее слово не применяется.

4. Сообщение Label Withdraw с кодом Wrong C-bit, которое трактуется, как обычное сообщение Label Withdraw, но без передачи отклика на него. Продолжается ожидание следующего управляющего сообщения для этого PW.

Если в любой момент после приема сообщения Label Mapping получено соответствующее сообщение Label Withdraw или Release, предпринимаются те же действия, что и при получении Label Withdraw или Release в любой другой момент.

Если обе точки хотят использовать управляющее слово, описанная процедура приведет к такому результату. Если любая из конечных точек не хочет или не поддерживает использование управляющего слова, процедура приведет к отказу от его применения. Если одна из точек предпочитает использовать управляющее слово, а другая нет, предпочитающая не использовать управляющее слово точка не имеет какого-либо дополнительного протокола для отказа — она просто передает сообщение Label Mapping с C=0.

7.3. Повторное согласование управляющего слова с помощью Label Request

Возможно, что после завершения описанной выше процедуры согласования бита C для PW локальное устройство PE сменит свои предпочтения в части управляющего слова. Следовательно, процедура согласования управляющего слова выполняется заново, как описано ниже.

1. Если локальное устройство PE ранее передало сообщение Label Mapping, оно должно отправить сообщение Label Withdraw удаленному PE и ждать от того сообщения Label Release.

2. Локальное устройство PE должно передать сообщение Label Release удаленному PE для конкретной метки, связанной с FEC, анонсированным для данного PW.

   Примечание. Два предшествующих этапа с сообщениями Label Release и Label Withdraw не требуется выполнять в каком-либо определенном порядке.

3. Локальное устройство PE должно передать сообщение Label Request партнерскому PE а потом должно дождаться от того сообщения Label Mapping, содержащего текущие предпочтения удаленного PE в части использования управляющего слова.

После того, как удаленное устройство PE успешно обработало сообщения Label Withdraw и Label Release, оно будет сбрасывать состояние машины согласования бита C и использовать (или не использовать) управляющее слово в соответствии с локальным предпочтением.

С этого момента локальное и удаленное устройства PE будут следовать процедурам согласования бита C, описанным в предыдущем параграфе.

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

7.4. Дополнительные вопросы

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

7.4.1. Анонсы меток

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

Эта предосторожность нужна для предотвращения «перезапуска» маршрутизатором пересылки пакетов с нумерацией с 1 при получении сообщения Label Mapping , связывающего тот же FEC с той же меткой, если в сети еще остаются старые паркеты с номерами от 1 до 32768. Например, если имеется пакет с порядковым номером n из интервала [1, 32768], находящийся в сети, распределяющий (disposition) маршрутизатор может получить этот пакет уже после повторного анонса метки. Поскольку метка была освобождена другим (imposition) маршрутизатором, распределяющему маршрутизатору следует ожидать прибытия пакета с порядковым номером 1. Получение пакета с номером n будет приводить к возможности отбрасывания распределяющим маршрутизатором до n пакетов, пока не будет получен пакет с номером n+1. Возможным вариантом предотвращения таких ситуаций является анонсирование распределяющим маршрутизатором другой метки PW или достаточно продолжительное ожидание перед повторным анонсированием освобожденной ранее метки. Эта проблема возникает лишь при обработке входных номеров на распределяющем (выходном — disposition) маршрутизаторе.

7.4.2. Освобождение метки

В ситуации, когда входной (imposition) маршрутизатор ждет перезапуска рассылки пакетов с нумерацией с 1, маршрутизатору нужно 1) отправить распределяющему (disposition) маршрутизатору сообщение Label Release и 2) отправить ему же сообщение Label Request. При поддержке упорядочения анонсирование метки PW в отклике на сообщение Label Request должно также принимать во внимание вопросы, рассмотренные выше (параграф 7.4.1 «Анонсы меток»).

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

8.1. Тип LDP TLV

В этом документе задано несколько новых типов LDP TLV. Агентство IANA уже поддерживает реестр TLV Type Name Space, определенный в RFC 5036. Приведенные ниже значения были назначены из упомянутого реестра.

Тип TLV	Описание
0x096A	PW Status TLV
0x096B	PW Interface Parameters TLV
0x096C	PW Group ID TLV

8.2. Коды состояний LDP

В этом документе задано несколько новых кодов состояний LDP. Агентство IANA уже поддерживает реестр Status Code Name Space, определенный в RFC 5036. Ниже приведены значения новых кодов.

Диапазон/значение	E	Описание	Документ
0x00000024	0	Недопустимый бит C	[RFC8077]
0x00000025	0	Неверный бит C	[RFC8077]
0x00000026	0	Несовместимая скорость	[RFC8077]
0x00000027	0	Некорректная конфигурация CEP-TDM	[RFC8077]
0x00000028	0	Статус PW	[RFC8077]
0x00000029	0	Базовая конфигурационная ошибка	[RFC8077]
0x0000002A	0	Статус отзыва метки PW	[RFC8077]
0x0000002B	0	Метод не поддерживается	[RFC8077]

8.3. Пространство имен типов FEC

Этот документ использует два новых типа элементов FEC (0x80 и 0x81) из реестра Forwarding Equivalence Class (FEC) Type Name Space для протокола распространения меток (LDP) [RFC5036].

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

Этот документ задает расширения LDP, которые нужны для организации и поддержки псевдопроводов. Цель организации псевдопроводов состоит в обеспечении возможности инкапсуляции кадров канального уровня (Layer 2) в MPLS и передачи с одного конца псевдопровода на другой. Следовательно, вопросы безопасности должны принимать во внимание как уровень данных, так и уровень управления.

9.1. Безопасность данных

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

• Проверка MPLS PDU;

• подмена (обманка) MPLS PDU;

• изменение MPLS PDU;

• защита протокола MPLS PSN;

• защита Access Circuit (устройство доступа);

• предотвращение DoS-атак на маршрутизаторы PE.

Существует мнение, что при использовании MPLS PSN для обеспечения псевдопроводов защита должна быть не хуже обеспечиваемой естественными протоколами канального уровня, которые эмулируются с помощью комбинации MPLS/PW. Это означает, что сеть с поддержкой MPLS следует защитить (изолировать) от возможности внесения пакетов извне. Чтобы предотвратить возможность внесения нежелательных пакетов важно пресечь несанкционированный физический доступ к PSN, а также несанкционированный административный доступ к отдельным элементам сети.

Как отмечено выше, сетям с поддержкой MPLS не следует воспринимать пакеты MPLS со своих внешних интерфейсов (т. е. интерфейсов к устройствам CE или сетям других провайдеров), если метка верхнего уровня в пакете не распространялась правомерно в систему, из которой был получен пакет. Если интерфейс, с которого принят пакет, ведет в сеть другого сервис-провайдера (а не пользователя), требуется наличии соответствующих отношений доверия, включая доверие к тому, что этот провайдер также обеспечивает подобающие меры защиты.

Тремя основными проблемами безопасности при использовании сети с поддержкой MPLS в качестве транспорта для PW являются обманные пакеты (spoofing), изменение и просмотр пакетов. Во-первых, существует вероятность того, что устройство PE принимающее PW PDU будет получать PDU, которые будут казаться отправленными PE, передающим PW в сеть PSN, но реально не будут передаваться PE, являющимся исходной точкой PW (т. е. указанная инкапсуляция сама по себе не позволяет декапсулятору проверить подлинность инкапсулятора). Вторая проблема связана с возможностью изменения PW PDU в интервале между входом в PSN и выходом из PSN (т. е. указанная инкапсуляция сама по себе не позволяет декапсулятору проверить целостность пакетов). Третья проблема связана с возможностью просмотра содержимого PDU в процессе передачи через сеть PSN (т. е. спецификация инкапсуляции не обеспечивает защиты конфиденциальности). Практическая важность этих проблем зависит от требований безопасности приложений, трафик которых передается через туннель, и от качества защиты в сети PSN.

9.2. Безопасность управления

Общее рассмотрение вопросов безопасности, связанных с использованием LDP, приведено в разделе 5 [RFC5036]. Это рассмотрение применимо и при использовании LDP для организации ПП.

Псевдопровод соединяет два устройства Attachment Circuits. Важно быть уверенным в том, что не принимаются соединения LDP из произвольных мест а к локальному устройству присоединения нет возможности подключиться с произвольного удаленного Attachment Circuit. Следовательно, входящие запросы сеансов LDP недопустимо воспринимать, пока нет уверенности в том, что IP-адрес отправителя является адресом «подходящего» партнера LDP. Множество подходящих партнеров может быть заранее указано в конфигурации (в виде списка адресов IP или комбинаций адрес-маска) или определено динамически с помощью доверенного протокола автоматического обнаружения (обычно при отсутствии должного доверия к протоколу автоматического обнаружения список найденных партнеров не может считаться доверенным).

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

Опция аутентификации LDP MD5, описанная в параграфе 2.9 [RFC5036], должна быть реализована и для повышения надежности защиты ее нужно использовать. Это обеспечит целостность и аутентификацию сообщений LDP, а также снизит вероятность использования подставных адресов отправителей. Применение опции MD5 не обеспечивает защиты конфиденциальности, но для управляющих сообщений LDP приватность обычно не имеет существенного значения. Опция MD5 на основе заранее известного общего ключа (pre-shared key) не обеспечивает достаточно защиты от атак с повторным использованием пакетов (replay attack). Кроме того, этот вариант использования опции может существенно усложнить развертывание системы в тех случаях, когда нужные партнеры определяются протоколом автоматического обнаружения.

При использовании Generalized PWid FEC Element возможны ситуации, когда отдельный партнер LDP может быть в списке подходящих, но при этом не иметь права на подключение к конкретному устройству присоединения (Attachment Circuit), указанному конкретным экземпляром Generalized PWid FEC Element. Однако, исходя из того, что этот партнер является одним из подходящих (см. выше), это будет приводить скорей к конфигурационным ошибкам, нежели к проблемам защиты. Тем не менее, для PE может оказаться целесообразным связать каждое из своих локальных устройств присоединения с набором подходящих партнеров, а не просто связывать таких партнеров с PE в целом.

10. Взаимодействие и развертывание

В параграфе 2.2 [RFC6410] заданы 4 требования, которым должны удовлетворять стандарты Internet. В этом разделе показано, насколько данный документ соответствует этим требованиям.

Технология псевдопроводов была развернута впервые в 2001 году и получила широкое распространение у множества операторов. В [RFC7079] приведены результаты исследования (опроса) реализаций PW с акцентом на применение управляющих слов. В [EANTC] приведены результаты открытого теста решений разных производителей оборудования MPLS и Carrier Ethernet, в котором проверялись псевдопровода Ethernet, ATM и TDM.

Найденные в [RFC4447] ошибки в основном являются редакционными и исправлены в настоящем документе.

Все возможности данной спецификации были реализованы множеством производителей.

IETF не было заявлено каких-либо претензий в части прав интеллектуальной собственности применительно к данному документу, RFC 4447, RFC 6723 и предварительным документам (Internet-Drafts), приведшим к RFC 4447 и RFC 6723.

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

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

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., “LDP Specification”, RFC 5036, DOI 10.17487/RFC5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.

[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, “MPLS Label Stack Encoding”, RFC 3032, DOI 10.17487/RFC3032, January 2001, <http://www.rfc-editor.org/info/rfc3032>.

[RFC4446] Martini, L., “IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)”, BCP 116, RFC 4446, DOI 10.17487/RFC4446, April 2006, <http://www.rfc-editor.org/info/rfc4446>.

[RFC7358] Raza, K., Boutros, S., Martini, L., and N. Leymann, “Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs)”, RFC 7358, DOI 10.17487/RFC7358, October 2014, <http://www.rfc-editor.org/info/rfc7358>.

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

[RFC2277] Alvestrand, H., “IETF Policy on Character Sets and Languages”, BCP 18, RFC 2277, DOI 10.17487/RFC2277, January 1998, <http://www.rfc-editor.org/info/rfc2277>.

[RFC3985] Bryant, S., Ed., and P. Pate, Ed., “Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture”, RFC 3985, DOI 10.17487/RFC3985, March 2005, <http://www.rfc-editor.org/info/rfc3985>.

[RFC4842] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig, “Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)”, RFC 4842, DOI 10.17487/RFC4842, April 2007, <http://www.rfc-editor.org/info/rfc4842>.

[RFC4553] Vainshtein, A., Ed., and YJ. Stein, Ed., “Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)”, RFC 4553, DOI 10.17487/RFC4553, June 2006, <http://www.rfc-editor.org/info/rfc4553>.

[RFC4619] Martini, L., Ed., Kawa, C., Ed., and A. Malis, Ed., “Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks”, RFC 4619, DOI 10.17487/RFC4619, September 2006, <http://www.rfc-editor.org/info/rfc4619>.

[RFC4717] Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N., Brayley, J., and G. Koleyni, “Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks”, RFC 4717, DOI 10.17487/RFC4717, December 2006, <http://www.rfc-editor.org/info/rfc4717>.

[RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis, “Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks”, RFC 4618, DOI 10.17487/RFC4618, September 2006, <http://www.rfc-editor.org/info/rfc4618>.

[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, “Encapsulation Methods for Transport of Ethernet over MPLS Networks”, RFC 4448, DOI 10.17487/RFC4448, April 2006, <http://www.rfc-editor.org/info/rfc4448>.

[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, “Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)”, RFC 4447, DOI 10.17487/RFC4447, April 2006, <http://www.rfc-editor.org/info/rfc4447>.

[RFC6410] Housley, R., Crocker, D., and E. Burger, “Reducing the Standards Track to Two Maturity Levels”, BCP 9, RFC 6410, DOI 10.17487/RFC6410, October 2011, <http://www.rfc-editor.org/info/rfc6410>.

[RFC6723] Jin, L., Ed., Key, R., Ed., Delord, S., Nadeau, T., and S. Boutros, “Update of the Pseudowire Control-Word Negotiation Mechanism”, RFC 6723, DOI 10.17487/RFC6723, September 2012, <http://www.rfc-editor.org/info/rfc6723>.

[RFC7079] Del Regno, N., Ed., and A. Malis, Ed., “The Pseudowire (PW) and Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results”, RFC 7079, DOI 10.17487/RFC7079, November 2013, <http://www.rfc-editor.org/info/rfc7079>.

[ANSI] American National Standards Institute, “Telecommunications – Synchronous Optical Network (SONET) – Basic Description Including Multiplex Structures, Rates, and Formats”, ANSI T1.105, October 1995.

[ITUG] International Telecommunications Union, “Network node interface for the synchronous digital hierarchy (SDH)”, ITU-T Recommendation G.707, May 1996.

[EANTC] European Advanced Networking Test Center, “MPLS and Carrier Ethernet: Service – Connect – Transport. Public Multi-Vendor Interoperability Test”, February 2009.

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

Авторы благодарят участников работы Vach Kompella, Vanson Lim, Wei Luo, Himanshu Shah и Nick Weeds. Авторы также выражают свою признательность разработчикам RFC 6723, чьи результаты были включены в этот документ, – Lizhong Jin, Raymond Key, Simon Delord, Tom Nadeau и Sami Boutros.

Участники работы

Ниже перечислены авторы и участники разработки RFC 4447. Они указаны здесь с целью отметить их вклад в подготовку данного документа.

Nasser El-Aawar

Level 3 Communications, LLC.

1025 Eldorado Blvd.

Broomfield, CO 80021

United States of America

Email: nna@level3.net

Eric C. Rosen

Cisco Systems, Inc.

1414 Massachusetts Avenue

Boxborough, MA 01719

United States of America

Email: erosen@cisco.com

Dan Tappan

Cisco Systems, Inc.

1414 Massachusetts Avenue

Boxborough, MA 01719

United States of America

Email: tappan@cisco.com

Toby Smith

Google

6425 Penn Ave. #700

Pittsburgh, PA 15206

United States of America

Email: tob@google.com

Dimitri Vlachos

Riverbed Technology

Email: dimitri@riverbed.com

Jayakumar Jayakumar

Cisco Systems Inc.

3800 Zanker Road, MS-SJ02/2

San Jose, CA 95134

United States of America

Email: jjayakum@cisco.com

Alex Hamilton,

Cisco Systems Inc.

485 East Tasman Drive, MS-SJC07/3

San Jose, CA 95134

United States of America

Email: tahamilt@cisco.com

Steve Vogelsang

ECI Telecom

Omega Corporate Center

1300 Omega Drive

Pittsburgh, PA 15205

United States of America

Email: stephen.vogelsang@ecitele.com

John Shirron

ECI Telecom

Omega Corporate Center

1300 Omega Drive

Pittsburgh, PA 15205

United States of America

Email: john.shirron@ecitele.com

Andrew G. Malis

Verizon

60 Sylvan Rd.

Waltham, MA 02451

United States of America

Email: andrew.g.malis@verizon.com

Vinai Sirkay

Reliance Infocomm

Dhirubai Ambani Knowledge City

Navi Mumbai 400 709

India

Email: vinai@sirkay.com

Vasile Radoaca

Nortel Networks

600 Technology Park

Billerica MA 01821

United States of America

Email: vasile@nortelnetworks.com

Chris Liljenstolpe

149 Santa Monica Way

San Francisco, CA 94127

United States of America

Email: ietf@cdl.asgaard.org

Dave Cooper

Global Crossing

960 Hamlin Court

Sunnyvale, CA 94089

United States of America

Email: dcooper@gblx.net

Kireeti Kompella

Juniper Networks

1194 N. Mathilda Ave

Sunnyvale, CA 94089

United States of America

Email: kireeti@juniper.net

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

Luca Martini (редактор)

Cisco Systems, Inc.

1899 Wynkoop Street, Suite 600

Denver, CO 80202

United States of America

Email: lmartini@monoski.com

Giles Heron (редактор)

Cisco Systems

10 New Square

Bedfont Lakes

Feltham

Middlesex

TW14 8HA

United Kingdom

Email: giheron@cisco.com

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

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

nmalykh@gmail.com