RFC 8080 Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC

 

Internet Engineering Task Force (IETF)                           O. Sury
Request for Comments: 8080                                        CZ.NIC
Category: Standards Track                                     R. Edmonds
ISSN: 2070-1721                                                   Fastly
                                                           February 2017

Алгоритм EdDSA для DNSSEC

Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC

PDF

Тезисы

В этом документе описано, как задать ключи и подписи EdDSA1 для защиты DNS (DNSSEC2). Алгоритм EdDSA может применяться с кривыми Ed25519 и Ed448.

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

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

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

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

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

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

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

Оглавление

Исключено в версии HTML.

1. Введение

Механизмы DNSSEC, описанные в [RFC4033], [RFC4034] и [RFC4035], используют криптографические ключи и цифровые подписи для проверки подлинности данных DNS. В настоящее время наиболее популярным алгоритмом защиты является RSA. Стандартизована также заданная GOST [RFC5933] и NIST криптография на основе эллиптических кривых [RFC6605].

В [RFC8032] описана система подписи на основе эллиптических кривых (EdDSA) и рекомендованы две кривые — Ed25519 и Ed448.

В этом документе определяется использование в DNSSEC записей о ресурсах (RR5) DS, DNSKEY и RRSIG с новым алгоритмом подписи EdDSA и предложены на выбор две кривые — Ed25519 и Ed448.

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

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

3. Записи DNSKEY

Открытый ключ Ed25519 представляет собой 32-октетное значение, помещаемое в поле Public Key записей DNSKEY в форме простой битовой строки. Генерация открытого ключа описана в параграфе 5.1.5 [RFC8032].

Открытый ключ Ed448 представляет собой 57-октетное значение, помещаемое в поле Public Key записей DNSKEY в форме простой битовой строки. Генерация открытого ключа описана в параграфе 5.1.5 [RFC8032].

4. Записи RRSIG

Подпись Ed25519 представляет собой 64-октетное значение, помещаемое в поле Signature записей RRSIG в форме простой битовой строки. Алгоритм и проверка подписи Ed25519 описаны в параграфах 5.1.6 и 5.1.7 [RFC8032], соответственно.

Подпись Ed448 представляет собой 114-октетное значение, помещаемое в поле Signature записей RRSIG в форме простой битовой строки. Алгоритм и проверка подписи Ed448 писаны в параграфах 5.1.6 и 5.1.7 [RFC8032], соответственно.

5. Номер алгоритма для записей DS, DNSKEY и RRSIG

Для алгоритма Ed25519 в записях DS, DNSKEY и RRSIG выделен номер 15. Для алгоритма Ed448 в записях DS, DNSKEY и RRSIG выделен номер 16. Эта регистрация полностью определена в разделе «Согласование с IANA».

6. Примеры

6.1. Примеры Ed25519

Private-key-format: v1.2
Algorithm: 15 (ED25519)
PrivateKey: ODIyNjAzODQ2MjgwODAxMjI2NDUxOTAyMDQxNDIyNjI=

example.com. 3600 IN DNSKEY 257 3 15 (
             l02Woi0iS8Aa25FQkUd9RMzZHJpBoRQwAQEX1SxZJA4= )

example.com. 3600 IN DS 3613 15 2 (
             3aa5ab37efce57f737fc1627013fee07bdf241bd10f3b1964ab55c78e79
             a304b )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 3 3600 (
             1440021600 1438207200 3613 example.com. (
             Edk+IB9KNNWg0HAjm7FazXyrd5m3Rk8zNZbvNpAcM+eysqcUOMIjWoevFkj
             H5GaMWeG96GUVZu6ECKOQmemHDg== )

Private-key-format: v1.2
Algorithm: 15 (ED25519)
PrivateKey: DSSF3o0s0f+ElWzj9E/Osxw8hLpk55chkmx0LYN5WiY=

example.com. 3600 IN DNSKEY 257 3 15 (
             zPnZ/QwEe7S8C5SPz2OfS5RR40ATk2/rYnE9xHIEijs= )

example.com. 3600 IN DS 35217 15 2 (
             401781b934e392de492ec77ae2e15d70f6575a1c0bc59c5275c04ebe80c
             6614c )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 3 3600 (
             1440021600 1438207200 35217 example.com. (
             5LL2obmzdqjWI+Xto5eP5adXt/T5tMhasWvwcyW4L3SzfcRawOle9bodhC+
             oip9ayUGjY9T/rL4rN3bOuESGDA== )

6.2. Примеры Ed448

Private-key-format: v1.2
Algorithm: 16 (ED448)
PrivateKey: xZ+5Cgm463xugtkY5B0Jx6erFTXp13rYegst0qRtNsOYnaVpMx0Z/c5EiA9x
            8wWbDDct/U3FhYWA

example.com. 3600 IN DNSKEY 257 3 16 (
             3kgROaDjrh0H2iuixWBrc8g2EpBBLCdGzHmn+G2MpTPhpj/OiBVHHSfPodx
             1FYYUcJKm1MDpJtIA )

example.com. 3600 IN DS 9713 16 2 (
             6ccf18d5bc5d7fc2fceb1d59d17321402f2aa8d368048db93dd811f5cb2
             b19c7 )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 3 3600 (
             1440021600 1438207200 9713 example.com. (
             Nmc0rgGKpr3GKYXcB1JmqqS4NYwhmechvJTqVzt3jR+Qy/lSLFoIk1L+9e3
             9GPL+5tVzDPN3f9kAwiu8KCuPPjtl227ayaCZtRKZuJax7n9NuYlZJIusX0
             SOIOKBGzG+yWYtz1/jjbzl5GGkWvREUCUA )

Private-key-format: v1.2
Algorithm: 16 (ED448)
PrivateKey: WEykD3ht3MHkU8iH4uVOLz8JLwtRBSqiBoM6fF72+Mrp/u5gjxuB1DV6NnPO
            2BlZdz4hdSTkOdOA

example.com. 3600 IN DNSKEY 257 3 16 (
             kkreGWoccSDmUBGAe7+zsbG6ZAFQp+syPmYUurBRQc3tDjeMCJcVMRDmgcN
             Lp5HlHAMy12VoISsA )

example.com. 3600 IN DS 38353 16 2 (
             645ff078b3568f5852b70cb60e8e696cc77b75bfaaffc118cf79cbda1ba
             28af4 )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 3 3600 (
             1440021600 1438207200 38353 example.com. (
             +JjANio/LIzp7osmMYE5XD3H/YES8kXs5Vb9H8MjPS8OAGZMD37+LsCIcjg
             5ivt0d4Om/UaqETEAsJjaYe56CEQP5lhRWuD2ivBqE0zfwJTyp4WqvpULbp
             vaukswvv/WNEFxzEYQEIm9+xDlXj4pMAMA )

7. Согласование с IANA

Этот документ обновляет реестр IANA Domain Name System Security (DNSSEC) Algorithm Numbers. В реестр добавляются две записи, показанные в таблице.

Номер

15

16

Описание

Ed25519

Ed448

Обозначение

ED25519

ED448

Подпись зоны

+

+

Защита транзакций

*

*

Документ

RFC 8080

RFC 8080

* Стандартизация использования этого алгоритма для защиты транзакций не определена

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

Вопросы безопасности, рассмотренные в [RFC8032] и [RFC7748], сохраняются для использования алгоритмов Ed25519 и Ed448 в DNSSEC.

Алгоритм Ed25519 предназначен для работы с уровнем защиты 128 битов, Ed448 — с уровнем защиты 224 бита. Взломать такую защиту способны достаточно большие квантовые компьютеры. Разумные оценки возможностей традиционных компьютеров говорят о полной безопасности Ed25519. Алгоритм Ed448 предназначен для приложений, где требования к производительности менее высоки и имеется желание обеспечить защиту от аналитических атак на эллиптические кривые.

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

Секретный ключ, используемый для зоны DNSSEC, недопустимо применять для каких-либо других целей. Иначе станут возможными кросс-протокольные и кросс-программные атаки.

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

9.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>.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «DNS Security Introduction and Requirements», RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Resource Records for the DNS Security Extensions», RFC 4034, DOI 10.17487/RFC4034, March 2005, <http://www.rfc-editor.org/info/rfc4034>.

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Protocol Modifications for the DNS Security Extensions», RFC 4035, DOI 10.17487/RFC4035, March 2005, <http://www.rfc-editor.org/info/rfc4035>.

[RFC7748] Langley, A., Hamburg, M., and S. Turner, «Elliptic Curves for Security», RFC 7748, DOI 10.17487/RFC7748, January 2016, <http://www.rfc-editor.org/info/rfc7748>.

[RFC8032] Josefsson, S. and I. Liusvaara, «Edwards-Curve Digital Signature Algorithm (EdDSA)», RFC 8032, DOI 10.17487/RFC8032, January 2017, <http://www.rfc-editor.org/info/rfc8032>.

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

[RFC5933] Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, «Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC», RFC 5933, DOI 10.17487/RFC5933, July 2010, <http://www.rfc-editor.org/info/rfc5933>.

[RFC6605] Hoffman, P. and W. Wijngaards, «Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC», RFC 6605, DOI 10.17487/RFC6605, April 2012, <http://www.rfc-editor.org/info/rfc6605>.


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

Some of the material in this document is copied liberally from [RFC6605].

The authors of this document wish to thank Jan Vcelak, Pieter Lexis, Kees Monshouwer, Simon Josefsson, Paul Hoffman, and others for a review of this document.

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


Ondrej Sury

CZ.NIC

Milesovska 1136/5

Praha 130 00

Czech Republic

Email: ondrej.sury@nic.cz

Robert Edmonds

Fastly

Atlanta, Georgia

United States of America

Email: edmonds@mycre.ws


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

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

nmalykh@gmail.com

1Edwards-curve Digital Security Algorithm.

2DNS Security.

3Internet Engineering Task Force.

4Internet Engineering Steering Group.

5Resource record.




RFC 8013 Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB)

Internet Engineering Task Force (IETF)                  D. Joachimpillai
Request for Comments: 8013                                       Verizon
Category: Standards Track                                  J. Hadi Salim
ISSN: 2070-1721                                        Mojatatu Networks
                                                           February 2017

Протокол ForCES — логические функциональные блоки между FE

Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB)

PDF

Тезисы

В этом документе описано, как расширить топологию логического функционального блока (LFB1) ForCES2 за пределы элемента пересылки (FE3) путем определения класса inter-FE LFB. Этот класс обеспечивает возможность передачи данных и метаданных через FE без изменения спецификации ForCES. Документ фокусируется на сетях Ethernet.

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

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF4 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG5. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

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

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

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

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

Оглавление

Исключено в версии HTML.

1. Введение

В архитектуре ForCES обслуживание пакетов можно смоделировать путем построения графа одного или множества экземпляров LFB. Подробности этого можно найти в спецификации модели ForCES [RFC5812].

Модель ForCES описывает обработку внутри одного элемента пересылки (FE) в терминах логических функциональных блоков (LFB), включая обеспечение элемента управления (CE6) для организации и изменения последовательности обработки и параметров отдельных LFB.

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

С учетом того, что архитектура ForCES inter-LFB требует возможности передавать метаданные между LFB, необходимо определить механизмы расширения имеющихся возможностей и обеспечения передачи метаданных между LFB в разных элементах FE.

В этом документе описано как расширить топологию LFB за пределы элемента FE, т. е. организовать связность между FE без изменения определений ForCES. В качестве среды для соединения элементов FE рассматривается Ethernet.

2. Термины и соглашения

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

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

2.2. Определения

Этот документ использует перечисленные ниже термины, которые определены в нескольких документах ForCES — [RFC3746], [RFC5810], [RFC5811], [RFC5812], [RFC7391], [RFC7408].

Control Element (CE) — элемент управления;
Forwarding Element (FE) — элемент пересылки;
FE Model — модельFE;
LFB (Logical Functional Block) Class — класс (или тип) LFB;
LFB Instance — экземпляр LFB;
LFB Model — модель LFB;
LFB Metadata — метаданные LFB;
ForCES Component — компонента ForCES;
LFB Component — компонента LFB;
ForCES Protocol Layer (ForCES PL) — уровень протокола ForCES;
ForCES Protocol Transport Mapping Layer (ForCES TML) — уровень транспортного отображения ForCES.

3. Проблема и примеры ее проявления

Назначением этого документа является решение вопроса передачи определенных протоколом ForCES метаданных вместе с данными пакета между физическими или виртуальными элементами FE для распределенной обработки LFB.

3.1. Допущения

  • Элементы FE, вовлеченные в inter-FE LFB, относятся к одному элементу сети (NE7) и находятся в одной административно частной сети, что означает их близость.

  • Элементы FE уже соединены между собой через сеть Ethernet. Этот выбор обусловлен широким распространением технологии Ethernet для организации соединений между FE. Для передачи данных и метаданных может быть определен другой транспорт вышележащего (типа UDP over IP) или нижележащего уровня, но эти случаи не рассматриваются в данном документе.

3.2. Простые случаи применения

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

3.2.1. Базовый маршрутизатор IPv4

Образец топологии LFB, представленный на рисунке 1, показывает граф обслуживания для базового сервиса пересылки IPv4 в рамках одного FE. На рисунке в качестве узлов графа показаны классы LFB, а не множество экземпляров класса LFB.

Поскольку целью рисунка 1 является демонстрация передачи данных и метаданных в нисходящем и восходящем направлении на графе экземпляров LFB, на нем не показаны какие-либо порты и упоминаются лишь базовые входные и выходные LFB, а также не указаны исключительные случаи и передача ошибок. Оставлены без внимания и детали Reverse Path Filtering, ECMP, обработки группового трафика и т. п. Иными словами, это не является полной иллюстрацией приложения для пересылки IPv4, более полное описание можно найти в документе, посвященном LFBLibrary [RFC6956].

Вывод входных LFB, попадающий в IPv4 Validator LFB, будет включать пакеты IPv4 и (в зависимости от реализации) те или иные метаданные, типа смещений в разных заголовках, метаданных классификации, сведений о физических и виртуальных портах, данных о туннелировании и т. п. Эти данные совместно будем называть входными метаданными.

Как только проверка пакетов (например, пригодность значений TTL) валидатором IPv4 закончится, он передает пакеты в IPv4 unicast LPM8 LFB.

                 +----+
                 |    |
      Пакет IPv4 |    | Пакет IPv4   +-----+             +---+
  +------------->|    +------------->|     |             |   |
  |  + входные   |    | + входные    |IPv4 | Пакет IPv4  |   |
  |  метаданные  |    | метаданные   |Ucast+------------>|   +--+
  |              +----+              |LPM  |  + входные  |   |  |
+-+-+             IPv4               +-----+  метаданные +---+  |
|   |             Validator                   + NHinfo   IPv4   |
|   |             LFB                                   NextHop |
|   |                                                     LFB   |
|   |                                                           |
|   |                                                Пакет IPv4 |
|   |                                               + {входные  |
+---+                                               + NHdetails}|
Входной                                               метаданные|
 LFB                                +--------+                  |
                                    |Выходной|                  |
                                 <--+        |<-----------------+
                                    |  LFB   |
                                    +--------+

Рисунок 1: Топология LFB базового обслуживания пакетов IPv4.


Блок IPv4 unicast LPM LFB выполняет поиск LPM в таблице IPv4 FIB, используя IP-адрес получателя в качестве ключа поиска. Результатом обычно является селектор следующего интервала пересылки (next-hop) который передается в нисходящем направлении как метаданные.

Блок NextHop LFB получает пакет IPv4 со связанными с ним метаданными данными о следующем интервале NH9. Блок NextHop LFB принимает метаданные NH и выводит из них индекс для поиска в таблице next-с целью нахождения нужной информации о выходе. Результат поиска используется для определения деталей next-hop, которые будут применяться в нисходящем направлении на выходе. Эти данные могут включать любую информацию об отправителе и получателе (в нашем случае адреса MAC10), а также выходной порт11.

Рассмотрение деталей выходного LFB выходит за рамки нашего обсуждения. Достаточно отметить, что в этом блоке или около него пакет IPv4 будет передан в выходной порт (например, физический или виртуальный порт Ethernet).

3.2.1.1. Распределенный базовый маршрутизатор IPv4

На рисунке 2 показано, что топологию LFB маршрутизатора с рисунка 1 можно разделить между двумя элементами FE (например, два контроллера ASIC12). На рисунке 2 изображена топология LFB разделенная между двумя FE после IPv4 unicast LPM LFB.

Некоторые фирменные технологии организации соединений (например, Broadcom HiGig over XAUI [brcm-higig]) позволяют передавать пакет IPv4 и связанные с ним метаданные между IPv4 Unicast LFB и IPv4NextHop LFB через два FE.

Этот документ определяет inter-FE LFB — стандартный механизм для инкапсуляции, генерации, приема и декапсуляции пакетов и связанных с ними метаданных FE через соединения Ethernet.

  FE1
+-------------------------------------------------------------+
|                            +----+                           |
| +----------+               |    |                           |
| | Входной  | Пакет IPv4    |    | Пакет IPv4   +-----+      |
| |  LFB     +-------------->|    +------------->|     |      |
| |          |  + входные    |    | + входные    |IPv4 |      |
| +----------+    метаданные |    |   метаданные |Ucast|      |
|      ^                     +----+              |LPM  |      |
|      |                      IPv4               +--+--+      |
|      |                     Validator              |         |
|                             LFB                   |         |
+---------------------------------------------------|---------+
                                                    |
                                               Пакет IPv4 +
                                            {выходные + NHinfo}
                                                 метаданные
  FE2                                               |
+---------------------------------------------------|---------+
|                                                   V         |
|             +--------+                       +--------+     |
|             | Egress |     Пакет IPv4        | IPv4   |     |
|       <-----+  LFB   |<----------------------+NextHop |     |
|             |        | {входные + NHdetails} | LFB    |     |
|             +--------+     метаданные        +--------+     |
+-------------------------------------------------------------+

Рисунок 2. Расщепление топологии LFB для обслуживания пакетов IPv4.

3.2.2. Произвольная сетевая функция

В этом параграфе будет показан пример произвольной сетевой функции NF13 без какой-либо детализации. Каждая такая функция может включать более одного блока LFB.

  FE1
+-------------------------------------------------------------+
|                            +----+                           |
| +----------+               |    |                           |
| | Network  |   пакет       |NF2 |   пакет      +-----+      |
| | Function +-------------->|    +------------->|     |      |
| |    1     | + метаданные  |    | + метаданные |NF3  |      |
| +----------+   NF1         |    |   NF1/2      |     |      |
|      ^                     +----+              |     |      |
|      |                                         +--+--+      |
|      |                                            |         |
|                                                   |         |
+---------------------------------------------------|---------+
                                                    V

Рисунок 3. Цепочка сетевых функций внутри одного FE.


Пример на рисунке 3 типичен для большинства устройств обработки пакетов, где имеются функции типа глубокой инспекции пакетов (DPI14), NAT, маршрутизации и т. п., соединенных в цепочку для обработки пакетов в потоках.

3.2.2.1. Распределенная произвольная сетевая функция

Цепочку функций на рисунке 3 можно разделить между тремя FE как показано на рисунке 4. Мотивом такого разделения может быть масштабирование или реализация функций в устройствах разных производителей. Конечным результатом будет однотипное обслуживание пакетов разных потоков, проходящих через цепочку.

FE1                        FE2
+----------+               +----+               FE3
| Network  |  пакет        |NF2 |   пакет      +-----+
| Function +-------------->|    +------------->|     |
|    1     |  + метаданные |    | + метаданные |NF3  |
+----------+    NF1        |    |   NF1/2      |     |
     ^                     +----+              |     |
     |                                         +--+--+
                                                  |
                                                  V

Рисунок 4. Цепочка сетевых функций в нескольких FE.


4. Обзор Inter-FE LFB

Требования связности между FE выполняются с помощью определения класса inter-FE LFB. Использование определения стандартного класса LFB предполагает отсуствие изменений, вносимых в архитектуру ForCES в части базовых LFB (FE Protocol или Object LFBs). Это решение было принято после рассмотрения альтернативного варианта, который требовал изменения возможностей FE Object (SupportedLFBs) и компоненты LFBTopology для описания возможностем связности между FE, а также рабочей топологии экземпляров LFB.

4.1. Вставка Inter-FE LFB ne 15

Топология распределенного блока LFB, показанная на рисунке 2, заново представлена на рисунке 5 для демонстрации inter-FE LFB.

Как можно видеть на рисунке 5, та же информация передается между IPv4 unicast LPM LFB и IPv4 NH LFB на выходную сторону inter-FE LFB. Эта информация представлена как множество вводов в выходной экземпляр inter-FE LFB. Каждый ввод представляет уникальный набор информации о выборе.

 FE1
+-------------------------------------------------------------+
| +----------+               +----+                           |
| | Входной  |  Пакет IPv4   |    |  Пакет IPv4  +-----+      |
| |  LFB     +-------------->|    +------------->|     |      |
| |          |  + входные    |    | + входные    |IPv4 |      |
| +----------+    метаданные |    |   метаданные |Ucast|      |
|      ^                     +----+              |LPM  |      |
|      |                      IPv4               +--+--+      |
|      |                     Validator              |         |
|      |                      LFB                   |         |
|      |                              Пакет IPv4 + метаданные |
|      |                                   {ingress + NHinfo} |
|      |                                            |         |
|      |                                       +..--+..+      |
|      |                                       |..| |  |      |
|                                            +-V--V-V--V-+    |
|                                            |  Выходной |    |
|                                            |  Inter-FE |    |
|                                            |   LFB     |    |
|                                            +------+----+    |
+---------------------------------------------------|---------+
                                                    |
                            Кадр Ethernet с         |
                            пакетом IPv4 и метаданными
                            {ingress + NHinfo + Inter-FE info}
 FE2                                                |
+---------------------------------------------------|---------+
|                                                +..+.+..+    |
|                                                |..|.|..|    |
|                                              +-V--V-V--V-+  |
|                                              | Входной   |  |
|                                              | Inter-FE  |  |
|                                              |   LFB     |  |
|                                              +----+------+  |
|                                                   |         |
|                                     Пакет IPv4 + метаданные |
|                                          {ingress + NHinfo} |
|                                                   |         |
|             +--------+                       +----V---+     |
|             |Выходной|     Пакет IPv4        | IPv4   |     |
|       <-----+  LFB   |<----------------------+ NextHop|     |
|             |        |     метаданные        | LFB    |     |
|             +--------+  {ingress+NHdetails}  +--------+     |
+-------------------------------------------------------------+

Рисунок 5. Расщепление сервиса пересылки IPv4 с помощью Inter-FE LFB.


На выходе inter-FE LFB принятый пакет и метаданные используются для выбора деталей инкапсуляции при передаче сообщений в направлении выбранного соседнего FE. Эти детали включают включают в себя указание передающего и принимающего FE (абстрагируются как адреса MAC в соответствии с параграфом 5.2), могут передаваться также метаданные, пришедшие вместе с исходным пакетом IPv4.

На входной стороне inter-FE LFB полученный пакет и связанные с ним метаданные служат для того, чтобы определить продолжение графа. Это включает выбор исходных метаданных и следующего экземпляра класса LFB для продолжения обработки. На рисунке 5 выбран экземпляр IPv4NextHop LFB и метаданные для передачи этому блоку.

Входная сторона inter-FE LFB использует часть переданной информации и передает пакет IPv4 вместе с входными метаданными и NHinfo блоку IPv4NextHop LFB как это делалось раньше на рисунках 1 и 2.

5. Связность Inter-FE Ethernet

В параграфе 5.1 рассмотрены некоторые вопросы, связанные с использованием Ethernet в качестве транспорта, и способы смягчения проблем.

В параграфе 5.2 определен формат данных для передачи через Ethernet. Имеющиеся реализации данной спецификации, работающие на основе Linux Traffic Control [linux-tc], описаны в [tc-ife].

5.1. Проблемы связности Inter-FE Ethernet

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

5.1.1. Проблема MTU

В результате добавления данных к существующим кадрам Ethernet может возникать проблема MTU. Меры предотвращения приведены ниже.

  • Использование больших MTU когда это возможно (например, кадров jumbo).

  • Ограничения объема метаданных, которые могут быть переданы. Наше определение позволяет фильтровать выбранные метаданные для инкапсуляции в кадр, как описано в разделе 6. Рекомендуется определять размер MTU выходного порта так, чтобы обеспечить включение метаданных максимального размера для передачи между FE. В такой конфигурации порт настраивается на «обман» вышележащих уровней путем заявления им значения MTU, которое меньше реального. Установка MTU может быть выполнена с помощью управления ForCES для LFB порта (или иным способом). Фактически при явном определении уровнем управления значения MTU для выходного порта неявно задается объем метаданных, которые можно будет передать. При выборе значения MTU следует быть осторожным — для пакетов IPv4 минимальный размер составляет 64 октета [RFC791], а для IPv6 — 1280 октетов [RFC2460].

5.1.2. Вопросы качества обслуживания

Необработанный (raw) пакет, прибывающий на интерфейс inter-FE LFB (от экземпляра восходящего LFB) может иметь метаданные класса обслуживания (CoS15) показывающие, как следует трактовать пакет с точки зрения качества обслуживания (QoS16).

Результирующий кадр Ethernet будет в конечном итоге (предпочтительно) трактоваться нисходящим LFB (обычно экземпляр LFB для порта) и его маркировка CoS будет выполняться с точки зрения приоритета. Иными словами, наличие inter-FE LFB не меняет семантики CoS.

5.1.3. Проблемы перегрузок

Предполагается, что большая часть проходящего через FE трафика, который использует inter-FE LFB, будет относиться к протоколу IP и в общем случае для него будет поддерживаться контроль насыщения [UDP-GUIDE]. Например, если перегрузка вызовет отбрасывание пакета TCP с дополнительными метаданными ForCES между элементами FE, можно надеяться, что передающий узел TCP отреагирует на это так же, как при отбрасывании пакета в другой точке, где не используется протокол ForCES. Поэтому дополнительные механизмы контроля насыщения между элементами FE не задаются.

Однако рост размера пакетов в результате добавления метаданных ForCES явно потребует дополнительной пропускной способности в каналах между FE по сравнению с передачей того же трафика без метаданных ForCES. Поэтому при использовании инкапсуляции inter-FE следует реализовать организацию трафика.

Кроме того, блоки inter-FE LFB должны разворачиваться только в рамках одной сети (с одним оператором) или в сетях смежных взаимодействующих операторов, где обеспечивается совместное предотвращение перегрузок. Это считается управляемой средой (Controlled Environment) в соответствии с определением параграфа 3.6 [UDP-GUIDE]. Следует принимать дополнительные меры по ограничению влияния трафика с инкапсуляцией inter-FE на иной трафик типа перечисленных ниже:

  • ограничение скорости всего трафика inter-FE LFB на восходящем LFB;

  • управление прерыванием цепей [circuit-b];

  • изоляция трафика inter-FE с помощью выделенных интерфейсов или VLAN.

5.2. Инкапсуляция Inter-FE Ethernet

Инкапсуляция в линии Ethernet показана на рисунке 6, а приводящий к ней процесс описан в разделе 6. Кадр выравнивается по 32-битовой границе.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address                                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address       |   Source MAC Address          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address                                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inter-FE ethertype            | Metadata length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV encoded Metadata ~~~..............~~                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV encoded Metadata ~~~..............~~                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Данные исходного пакета ~~............~~                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 6. Формат пакета.


Назначение полей заголовка Ethernet (рисунок 6) кратко описано ниже.

  • Destination MAC Address используется для указания Destination FEID по политике CE (см. раздел 6).

  • The Source MAC Address используется для указания Source FEID по политике CE ( см. раздел 6).

  • Поле ethertype служит для идентификации кадра как inter-FE LFB (шестнадцатеричное значение ED3E).

  • 16-битовое поле Metadata length указывает общий размер метаданных (включая само поле размера).

  • Один или множество 16-битовых блоков TLV с метаданными следуют за полем Metadata length. Тип TLV указывает идентификатор метаданных. Будут использоваться идентификаторы метаданных ForCES, зарегистрированные в IANA. Все TLV выравниваются по 32-битовой границе. Понятно, что применение 16-битовых TLV ограничивает размер идентификаторов метаданных 16 битами вместо определенных в ForCES 32 битовых идентификаторов компонент при использовании ILV17. Однако на момент публикации этого документа 16-битовое пространство кажется достаточным, а модель TLV выбрана благодаря обеспечиваемой ею экономии 4 байтов на единицу метаданных по сравнению с использованием ILV.

  • Данные исходного пакета размещаются после метаданных, как показано на рисунке 6.

6. Подробное описание Ethernet Inter-FE LFB

Ethernet inter-FE LFB имеет два блока LFB для групп входных портов и три LFB выходных портов (см. рисунок 7).

Блок inter-FE LFB определяет две компоненты, поддерживающие обработку, описанную в параграфе 6.1.

                 +-----------------+
Инкапсулированный|                 |
Inter-FE LFB     |             OUT2+--> Декапсулированный 
---------------->|IngressInGroup   |    пакет + метаданные
Кадр Ethernet    |                 |
                 |                 |
raw-пакет +      |             OUT1+--> Инкапсулированный 
---------------->|EgressInGroup    |    кадр Ethernet
метаданные       |                 |
                 |    EXCEPTIONOUT +--> ExceptionID, пакет
                 |                 |    + метаданные
                 +-----------------+

Рисунок 7. Inter-FE LFB.


6.1. Обработка данных

Экземпляр inter-FE LFB может быть размешен на выходе FE-источника. На рисунке 5 показан пример FE-источника FE1. В таком случае экземпляр inter-FE LFB получает через группу портов EgressInGroup необработанный пакет и связанные с ним метаданные от предшествующих экземпляров LFB. Входная информация служит для выбора способа генерации и инкапсуляции нового кадра. Набор всех вариантов хранится в LFB-компоненте IFETable, описанной ниже. Обработанный инкапсулированный кадр Ethernet передается через OUT1 нисходящему экземпляру LFB при завершении обработки или в порт EXCEPTIONOUT при возникновении отказа.

Экземпляр inter-FE LFB может быть размешен на входе принимающего FE. На рисунке 5 показан пример FE-получателя FE218. В таком случае inter-FE LFB получает через порт LFB в группе IngressInGroup инкапсулированный кадр Ethernet. Успешная обработка пакета будет приводить к отправке raw-пакета и связанных с ним метаданных блоку LFB, подключенному к порту OUT2. При отказе данные передаются в EXCEPTIONOUT.

6.1.1. Выходная обработка

Выходной блок inter-FE LFB получает пакет и связанные с ним метаданные на портоу LFB группы входных портов экземпляра LFB, помеченной EgressInGroup.

Реализация LFB может использовать входной порт LFB (в группе EgressInGroup) для отображения на индекс таблицы, используемый для поиска в IFETable.

Если поиск завершился успехом, соответствующая строка таблицы с данными IFEInfo извлекается в форме кортежа (необязательные IFETYPE и StatId, DSTFE19, SRCFE 20 и необязательные метафильтры). Списки метафильтров определяют «белый» список метаданных для передачи соседенму FE. Блок inter-FE LFB будет выполнять с помощью полученного кортежа перечисленные ниже действия.

  • Увеличение значений счетчиков пакетов и байтов в соответствующей записи IFEStats.

  • При наличии MetaFilterList применяются фильтры ко всем полученным метаданным. Если подходящих данных для передачи в нисходящем направлении не найдено, обработка завершается и пакет вместе с метаданными передается в порт EXCEPTIONOUT с exceptionID = EncapTableLookupFailed [RFC6956].

  • Проверка размера дополнительных данных в заголовке кадре Ethernet и инкапсулированных данных на предмет соответствия MTU. Если размер превышен, увеличивается значение счетчика пакетов с ошибками, а пакет и метаданные передаются в порт EXCEPTIONOUT с exceptionID = EncapTableLookupFailed [RFC6956].

  • Создание заголовка Ethernet.

  • Установка адреса Destination MAC в заголовке Ethernet в соответствии со значением поля DSTFE.

  • Установка адреса Source MAC в заголовке Ethernet в соответствии со значением поля SRCFE.

  • При наличии поля IFETYPE установка для поля ethertype значения из IFETYPE. При отсутствии IFETYPE используется стандартное для inter-FE LFB шестнадцатеричное значение ethertype ED3E.

  • Инкапсуляция всех разрешенных метаданных в TLV с использованием metaID в качестве поля типа в заголовке TLV. Блоки TLV следует выравнивать по 32-битовым границам путем добавления нулей в конце.

  • Обновление размера метаданных с учетом суммарного размера TLV + 2 байта (размер поля Metadata length).

Полученный пакет передается следующему экземпляру LFB, подключенному к LFB-порту OUT1.

Если поиск не дал результата, исходный пакет и связанные с ним метаданные передаются в порт EXCEPTIONOUT с exceptionID = EncapTableLookupFailed [RFC6956]. Отметим, что порт EXCEPTIONOUT LFB является абстракцией и реализация может просто отбрасывать соответствующие пакеты.

6.1.2. Входная обработка

Входящий пакет inter-FE LFB распознается по полю ethertype и опционально по MAC-адресам отправителя и получателя. Соответствующие пакеты отображаются на порт экземпляра LFB в группе IngressInGroup. Запись таблицы IFETable, соответствующая порту экземпляра LFB, может иметь фильтры метаданных. В таком случае входная обработка должна применять эти фильтры в качестве «белого» списка для выделения разрешенных метаданных.

  • Увеличение значений счетчиков пакетов и байтов.

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

  • По завершении обработки всех метаданных экземпляр inter-FE LFB переходит к данным исходного пакета (пропускает заголовок IFE). В этот момент восстанавливается исходный пакет, переданный выходному inter-FE LFB в FE-источнике. Этот пакет вместе с восстановленными метаданными передается в нисходящем направлении следующему экземпляру LFB на графе.

При отказе в процессе обработки на входном или выходном LFB пакет и метаданные передаются в порт EXCEPTIONOUT с соответствующим кодом ошибки. Отметим, что порт EXCEPTIONOUT LFB является абстракцией и реализация может просто отбрасывать соответствующие пакеты, как отмечено выше.

6.2. Компоненты

Имеется две компоненты LFB, к которым обращается CE (см. определения в разделе 8).

Первой компонентой, которая заполняется элементом CE, является массив, называемый таблицей IFETable. Строки массива являются структурами IFEInfo. Каждая структура IFEInfo включает необязательные поля IFETYPE и StatId, MAC-адрес получателя (DSTFE), MAC-адрес отправителя (SRCFE) и необязательный массив разрешенных metaID (MetaFilterList).

Вторая компонента (ID 2) заполняется элементом FE и считывается CE — это индексированный массив, называемый таблицей IFEStats. Каждая строка IFEStats содержит статистические данные в структуре bstats.

Отметим, что StatId указывает связи между IFETable и IFEStats — реализация может создать отображение между строками IFETable и IFEStats, используя поле StatId в соответствующей строке IFETable. В этом случае в строке IFETable должно присутствовать поле StatId. Другие реализации могут отображать строки IFETable на строки IFEStats во время подготовки. Еще одним вариантом реализации является отказ от указания StatId в IFETable и использование строки IFETable в качестве индекса IFEStats. Поэтому поле StatId является необязательным.

6.3. Модель XML для Inter-FE LFB

  <LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.1"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         provides="IFE">
    <frameDefs>
       <frameDef>
           <name>PacketAny</name>
            <synopsis>Произвольный пакет</synopsis>
       </frameDef>
       <frameDef>
           <name>InterFEFrame</name>
           <synopsis>Кадр Ethernet с инкапсулированными данными IFE</synopsis>
       </frameDef>
    </frameDefs>

    <dataTypeDefs>
      <dataTypeDef>
         <name>bstats</name>
         <synopsis>Базовая статистика</synopsis>
      <struct>
          <component componentID="1">
           <name>bytes</name>
           <synopsis>Общее число просмотренных байтов</synopsis>
           <typeRef>uint64</typeRef>
          </component>

          <component componentID="2">
           <name>packets</name>
           <synopsis>Общее число просмотренных пакетов</synopsis>
           <typeRef>uint32</typeRef>
          </component>

          <component componentID="3">
           <name>errors</name>
           <synopsis>Общее число пакетов с ошибками</synopsis>
           <typeRef>uint32</typeRef>
          </component>
      </struct>
     </dataTypeDef>

       <dataTypeDef>
          <name>IFEInfo</name>
          <synopsis>Описание информации строки таблицы IFE</synopsis>
          <struct>
             <component componentID="1">
               <name>IFETYPE</name>
               <synopsis>ethertype для исходящего кадра IFE</synopsis>
               <optional/>
               <typeRef>uint16</typeRef>
             </component>
             <component componentID="2">
               <name>StatId</name>
               <synopsis>Индекс таблицы статистики</synopsis>
               <optional/>
               <typeRef>uint32</typeRef>
             </component>
             <component componentID="3">
               <name>DSTFE</name>
               <synopsis>MAC-адрес получателя целевого FE</synopsis>
               <typeRef>byte[6]</typeRef>
             </component>
             <component componentID="4">
               <name>SRCFE</name>
               <synopsis>MAC-адрес отправителя FE-источника</synopsis>
               <typeRef>byte[6]</typeRef>
             </component>
             <component componentID="5">
               <name>MetaFilterList</name>
               <synopsis>Таблица фильтров разрешенных метаданных</synopsis>
               <optional/>
               <array type="variable-size">
                 <typeRef>uint32</typeRef>
               </array>
              </component>
          </struct>
       </dataTypeDef>
    </dataTypeDefs>

    <LFBClassDefs>
      <LFBClassDef LFBClassID="18">
        <name>IFE</name>
        <synopsis>Этот LFB описаывает параметры связности IFE</synopsis>
        <version>1.0</version>

          <inputPorts>
            <inputPort group="true">
             <name>EgressInGroup</name>
             <synopsis>
                     Группа входных портов на выходной стороне.
                     Она ожидает кадры Ethernet любого типа.
             </synopsis>
             <expectation>
                  <frameExpected>
                  <ref>PacketAny</ref>
                  </frameExpected>
             </expectation>
            </inputPort>

            <inputPort  group="true">
             <name>IngressInGroup</name>
             <synopsis>
                     Группа входных портов на входной стороне.
                     Она ожидает кадры Ethernet с инкапсуляцией interFE.
              </synopsis>
             <expectation>
                  <frameExpected>
                  <ref>InterFEFrame</ref>
                  </frameExpected>
             </expectation>
          </inputPort>
         </inputPorts>

         <outputPorts>
           <outputPort>
             <name>OUT1</name>
             <synopsis>Выходной порт на выходной стороне</synopsis>

             <product>
                <frameProduced>
                  <ref>InterFEFrame</ref>
                </frameProduced>
             </product>
          </outputPort>

          <outputPort>
            <name>OUT2</name>
             <synopsis>Выходной порт на входной стороне</synopsis>
            <product>
               <frameProduced>
                 <ref>PacketAny</ref>
               </frameProduced>
            </product>
         </outputPort>

         <outputPort>
           <name>EXCEPTIONOUT</name>
           <synopsis>Путь обработки исключений</synopsis>
           <product>
              <frameProduced>
                <ref>PacketAny</ref>
              </frameProduced>
              <metadataProduced>
                <ref>ExceptionID</ref>
              </metadataProduced>
           </product>
        </outputPort>
     </outputPorts>

     <components>
        <component componentID="1" access="read-write">
           <name>IFETable</name>
           <synopsis>Таблица всех связей inter-FE</synopsis>
           <array type="variable-size">
              <typeRef>IFEInfo</typeRef>
           </array>
        </component>

       <component componentID="2" access="read-only">
         <name>IFEStats</name>
         <synopsis>Статистика, соответствующая таблице IFETable</synopsis>
         <typeRef>bstats</typeRef>
       </component>
    </components>
   </LFBClassDef>
  </LFBClassDefs>

  </LFBLibrary>

Рисунок 8. Inter-FE LFB XML.

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

Агентство IANA зарегистрировало приведенное в таблице имя класса LFB в субреестре Logical Functional Block (LFB) Class Names and Class Identifiers реестра Forwarding and Control Element Separation (ForCES) <https://www.iana.org/assignments/forces>.

Имя и идентификатор класса LFB

Идентификатор класса LFB

Имя класса LFB

Версия LFB

Описание

Документ

18

IFE

1.0

Блок IFE LFB служит для стандартизации inter-FE LFB в сетевых элементах ForCES

RFC 8013

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

Этот документ включает запрос на выделение нового значения протокола Ethernet, как указано в параграфе 5.2.

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

Элементы FE, вовлеченные в inter-FE LFB, относятся к одному NE и находятся в частной ЛВС Ethernet с единым администрированием. Несмотря на наличие доверия к политике управления и ее трактовке в пути данных, реализациям inter-FE LFB следует поддерживать услуги защиты, обеспечиваемые MACsec21 [ieee8021ae]. Методы MACsec пока недостаточно распространены в традиционном оборудовании для обработки пакетов, хотя они имеются в новых версиях ядра Linux kernel (распространенного достаточно широко) [linux-macsec]. Ожидается, что со временем большинство FE будут поддерживать MACsec.

MACsec обеспечивает услуги защиты типа аутентификации сообщений и необязательной защиты конфиденциальности. Эти услуги можно настраивать вручную или автоматически с помощью MKA22 на основе модели IEEE 802.1x [ieee8021x] EAP23. Ожидается, что реализации FE начнут с использования на уровне управления общих ключей, а затем перейдут к автоматическому управления ключами.

Ниже перечислены механизмы MACsec, которые нужны для inter-FE LFB.

  • Механизмы защиты в масштабе NE для всех элементов FE. После включения защиты в зависимости от выбранного уровня (например, аутентификация и конфиденциальность) эти услуги будут действовать для inter-FE LFB в течение всей сессии.

  • Операторам следует задавать одинаковые правила безопасности для всех участвующих элементов FE в кластере NE. Это обеспечит единообразие действий и позволит избавиться от ненужных сложностей при настройке политики. Иными словами, ключи SAK24 следует распространять заранее. При использовании MKA элементы FE должны идентифицировать себя с помощью ключей CAK25 и их имен CKN26. В качестве метода EAP следует использовать EAP-TLS.

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

Следует отметить, что с учетом приведенных выше вариантов компрометация FE позволит объекту, работающему в этом FE, создавать обманные inter-FE или менять их содержимое, что приведет к нежелательным результатам.

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

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

[ieee8021ae] IEEE, «IEEE Standard for Local and metropolitan area networks Media Access Control (MAC) Security», IEEE 802.1AE-2006, DOI 10.1109/IEEESTD.2006.245590, <http://ieeexplore.ieee.org/document/1678345/>.

[ieee8021x] IEEE, «IEEE Standard for Local and metropolitan area networks — Port-Based Network Access Control.», IEEE 802.1X-2010, DOI 10.1109/IEEESTD.2010.5409813, <http://ieeexplore.ieee.org/document/5409813/>.

[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>.

[RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed., Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and J. Halpern, «Forwarding and Control Element Separation (ForCES) Protocol Specification», RFC 5810, DOI 10.17487/RFC5810, March 2010, <http://www.rfc-editor.org/info/rfc5810>.

[RFC5811] Hadi Salim, J. and K. Ogawa, «SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol», RFC 5811, DOI 10.17487/RFC5811, March 2010, <http://www.rfc-editor.org/info/rfc5811>.

[RFC5812] Halpern, J. and J. Hadi Salim, «Forwarding and Control Element Separation (ForCES) Forwarding Element Model», RFC 5812, DOI 10.17487/RFC5812, March 2010, <http://www.rfc-editor.org/info/rfc5812>.

[RFC7391] Hadi Salim, J., «Forwarding and Control Element Separation (ForCES) Protocol Extensions», RFC 7391, DOI 10.17487/RFC7391, October 2014, <http://www.rfc-editor.org/info/rfc7391>.

[RFC7408] Haleplidis, E., «Forwarding and Control Element Separation (ForCES) Model Extension», RFC 7408, DOI 10.17487/RFC7408, November 2014, <http://www.rfc-editor.org/info/rfc7408>.

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

[brcm-higig] Broadcom, «HiGig», <http://www.broadcom.com/products/ethernet-communication-and-switching/switching/bcm56720>.

[circuit-b] Fairhurst, G., «Network Transport Circuit Breakers», Work in Progress, draft-ietf-tsvwg-circuit-breaker-1527, April 2016.

[linux-macsec] Dubroca, S., «MACsec: Encryption for the wired LAN»28, Netdev 11, Feb 2016.

[linux-tc] Hadi Salim, J., «Linux Traffic Control Classifier-Action Subsystem Architecture»29, Netdev 01, Feb 2015.

[RFC791] Postel, J., «Internet Protocol», STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>.

[RFC2460] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 246030, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.

[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, «Forwarding and Control Element Separation (ForCES) Framework», RFC 3746, DOI 10.17487/RFC3746, April 2004, <http://www.rfc-editor.org/info/rfc3746>.

[RFC6956] Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J. Halpern, «Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library», RFC 6956, DOI 10.17487/RFC6956, June 2013, <http://www.rfc-editor.org/info/rfc6956>.

[tc-ife] Hadi Salim, J. and D. Joachimpillai, «Distributing Linux Traffic Control Classifier-Action Subsystem»31, Netdev 01, Feb 2015.

[UDP-GUIDE] Eggert, L., Fairhurst, G., and G. Shepherd, «UDP Usage Guidelines», Work in Progress32, draft-ietf-tsvwg-rfc5405bis-19, October 2016.

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

Авторы благодарны Joel Halpern и Dave Hood за плодотворные дискуссии. Evangelos Haleplidis много сделал для улучшения этого документа. Alia Atlas был AD-спонсором этого документа и внес множество критических замечаний. Авторы признательны Joel Halpern и Sue Hares, которые в роли рецензентов от Routing Area помогли сформировать содержимое этого документа. David Black приложил значительные усилия по проверке разумности решения в части контроля перегрузок. Russ Housley подготовил обзор Gen-ART, Joe Touch — обзор TSV, а Shucheng LIU (Will) — обзор OPS. Suresh Krishnan помог при рецензировании IESG. Авторы благодарны Stephen Farrell за его усилия по подготовке раздела, посвященного безопасности.

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

Damascane M. Joachimpillai

Verizon

60 Sylvan Rd

Waltham, MA 02451

United States of America

Email: damascene.joachimpillai@verizon.com

Jamal Hadi Salim

Mojatatu Networks

Suite 200, 15 Fitzgerald Rd.

Ottawa, Ontario K2H 9G1

Canada

Email: hadi@mojatatu.com


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

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

nmalykh@gmail.com

1Logical Functional Block.

2Forwarding and Control Element Separation — разделение элементов пересылки и управления.

3Forwarding Element.

4Internet Engineering Task Force.

5Internet Engineering Steering Group.

6Control Element.

7Network Elementю

8Longest-Prefix-Matching — максимальный размер соответствия префикса.

9Next-hop.

10Media Access Control — управление доступом к среде передачи.

11В этом LFB обычно выполняется также декрементирование TTL и пересчет контрольной суммы IP.

12Application-Specific Integrated Circuit — специализированная микросхема.

13Network Function.

14Deep packet inspection.

15Class-of-Service.

16Quality-of-Service.

17Index-Length-Value.

18В оригинале ошибочно сказано FE1, см. http://www.rfc-editor.org/errata/eid5358. Прим. перев.

19Destination MAC address.

20Source MAC address.

21Media Access Control Security.

22MACsec Key Agreement — согласование ключей MACsec.

23Extensible Authentication Protocol — расширяемый протокол аутентификации.

24Security Association Key — ключ защищенной связи.

25Connectivity Association Key — ключ ассоциации связности.

26Connectivity Association Key Name — имя ключа ассоциации связности.

27Работа опубликована в RFC 8084. Прим. перев.

28Статья доступна по ссылке. Прим. перев.

29Статья доступна по ссылке. Прим. перев.

30Этот документ отменен RFC 8200. Прим. перев.

31Статья доступна по ссылке. Прим. перев.

32Работа опубликована в RFC 8085. Прим. перев.




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, ATM1, Ethernet) можно эмулировать в опорных сетях MPLS путем инкапсуляции PDU2 канального уровня и передачи их через псевдопровода (PW3). Псевдопровода (ПП) можно также использовать для эмуляции низкоскоростных каналов TDM4 и SONET5 через сети с поддержкой MPLS. В этом документе описан протокол организации и поддержки псевдопроводов с использованием протокола LDP6. Процедуры инкапсуляции Layer 2 PDU описаны в отдельных документах.

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

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

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

Документ является результатом работы IETF7 и представляет собой согласованное мнение сообщества IETF. Документ был вынесен на публичное рассмотрение и одобрен для публикации IESG8. Дополнительная информация о документах 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 документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

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

Оглавление

Исключено в версии HTML.

1. Введение

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

[RFC4842] и [RFC4553] задают два метода транспортировки цифровых сигналов (эмуляция устройств) TDM через ориентированные на работу с пакетами сети с поддержкой MPLS. Системой передачи для ориентированных на соединения (circuit-oriented) сигналов TDM является SONET[ANSI]/SDH10[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 (LDP11) [RFC5036] в качестве протокола для организации и поддержки псевдопроводов. В частности, определены новые TLV, элементы FEC12, параметры и коды для 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.

В этом документе PE113 будет определять, как входной маршрутизатор, а 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 LSP14, поэтому инкапсуляция в туннель 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 представляют собой, например, AAL515 PDU, метка PW будет в общем случае соответствовать конкретному виртуальному каналу ATM VC16 на PE2. Т. е.. устройство PE2 должно иметь возможность определить по метке PW выходной интерфейс и значение VPI/VCI17 для AAL5 PDU. Если данные представляют собой Frame Relay PDU, устройство PE2 должно иметь возможность определить по метке PW выходной интерфейс и значение DLCI18. Если данные являются кадром 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 для пересылки на устройство присоединения (AC19) зависит от реализации в части функции естественного обслуживания (NSP20) [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). Протокол, используемый для организации псевдопровода, должен позволять узлу на одной стороне идентифицировать узел на другой стороне. Мы используем термин «идентификатор присоединения» или просто AI21 для обозначения поля, которое данный протокол применяет для идентификации узлов. В PWid FEC поле PWid служит в качестве AI. В этом параграфе будет описана более общая форма AI, которая структурирована и может менять размер.

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

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

Идентификатор группы можно рассматривать, как 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);

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

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

Если AGI отличается от null, идентификатор SAI26 состоит из AGI и SAII, а TAI27 — из 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) выбирается локально. В некоторых моделях предоставления VPWS28 значение TAI может быть, например, строкой, указывающей конкретное устройство присоединения (типа ATM3VPI4VCI5), или строкой, связанной в параметрах конфигурации с конкретным устройством присоединения (типа Fred). В VPLS29 значение 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

1Asynchronous Transfer Mode — асинхронный режим передачи.

2Protocol Data Unit — блок данных протокола.

3Pseudowire.

4Time-Division Multiplexing – мультиплексирование с разделением по времени.

5Synchronous Optical NETwork — синхронная оптическая сеть.

6Label Distribution Protocol — протокол распространения меток.

7Internet Engineering Task Force.

8Internet Engineering Steering Group.

9Packet Switched Network — сеть с коммутацией пакетов.

10Synchronous Digital Hierarchy — синхронная цифровая иерархия.

11Label Distribution Protocol.

12Forwarding Equivalence Class — класс эквивалентной пересылки.

13Provider Edge 1.

14Label Switched Path — путь с коммутацией по меткам.

15ATM Adaptation Layer 5 — уровень 5 адаптации ATM.

16Virtual Circuit — виртуальное устройство (канал).

17Virtual Path Identifier/Virtual Circuit Identifier — идентификатор виртуального пути/идентификатор виртуального канала.

18Data Link Connection Identifier — идентификатор соединения на канальном уровне.

19Attachment Circuit.

20Native service processing — естественная для сервиса обработка.

21Attachment Identifier.

22Attachment Group Identifier.

23Attachment Individual Identifier.

24Source Attachment Individual Identifier.

25Target Attachment Individual Identifier.

26Source AI.

27Target AI.

28Virtual Private Wire Service — услуги виртуальных частных проводов.

29Virtual Private LAN Service — услуги виртуальных частных ЛВС.




RFC 8093 Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243

Internet Engineering Task Force (IETF)                       J. Snijders
Request for Comments: 8093                                           NTT
Category: Standards Track                                  February 2017
ISSN: 2070-1721

Прекращение использования значений атрибута BGP Path 30, 31, 129, 241, 242 и 243

Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243

PDF

Тезисы

Этот документ запрашивает агентство IANA отметить атрибуты BGP path со значениями 30, 31, 129, 241, 242 и 243, как отмененные (Deprecated).

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

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

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

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

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

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

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

Оглавление

Исключено в версии HTML.

1. Введение

Было обнаружено, что некоторые значения BGP Path Attribute, используемые в развернутых реализациях BGP, не были выделены агентством IANA для такого применения. Использование незарегистрированных значений BGP Path Attribute может приводить к проблемам при развертывании новых технологий.

Использование незарегистрированных значений было отмечено, когда атрибуту BGP Large Communities [RFC8092] агентством IANA было выделено первоначальное значение 30. Впоследствии было обнаружено, что широко развернутая реализация BGP-4 [RFC4271] включает код, использующий атрибут пути 30, и этот атрибут применяется в стратегии «трактовать, как отозванный» (Treat-as-withdraw) [RFC7606] для маршрутов, содержащих корректный атрибут Large Community, поскольку в нем предполагается другая структура данных. Поскольку эти маршруты отбрасываются, результатом первоначального использования атрибута Large Community стала недоступность использующих его систем для части сети Internet. Для решения возникшей проблемы было запрошено новое значение (Early IANA Allocation).

«Самозахват» значений 30, 31, 129, 241, 242 и 243 был подтвержден разработчиками и анализом исходного кода.

2. Согласование с IANA

Агентство IANA отметило значения 30, 31, 129, 241, 242 и 243, как отозванные (Deprecated) в субреестре BGP Path Attributes реестра Border Gateway Protocol (BGP) Parameters. Метка Deprecated означате, что эти значения не рекомендуется использовать ([IANA-GUIDELINES]).

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

С этим обновлением реестров не связано значимых последствий в части безопасности.

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

[IANA-GUIDELINES] Cotton, M., Leiba, B., and T. Narten, «Guidelines for Writing an IANA Considerations Section in RFCs», Work in Progress, draft-leiba-cotton-iana-5226bis-18, September 2016.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.

[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, «Revised Error Handling for BGP UPDATE Messages», RFC 7606, DOI 10.17487/RFC7606, August 2015, <http://www.rfc-editor.org/info/rfc7606>.

[RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas, I., and N. Hilliard, «BGP Large Communities Attribute», RFC 8092, DOI 10.17487/RFC8092, February 2017, <http://www.rfc-editor.org/info/rfc8092>.

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

Автор выражает свою признательность Marlien Vijfhuizen за помощь в обнаружении захвата значения 30 и Nick Hilliard за редакторские правки.

Адрес автора

Job Snijders

NTT Communications

Theodorus Majofskistraat 100

Amsterdam 1065 SZ

The Netherlands

Email: job@ntt.net


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

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

nmalykh@gmail.com

1Internet Engineering Task Force.

2Internet Engineering Steering Group.




RFC 8092 BGP Large Communities Attribute

Internet Engineering Task Force (IETF)                     J. Heitz, Ed.
Request for Comments: 8092                                         Cisco
Category: Standards Track                               J. Snijders, Ed.
ISSN: 2070-1721                                                      NTT
                                                                K. Patel
                                                                  Arrcus
                                                             I. Bagdonas
                                                                 Equinix
                                                             N. Hilliard
                                                                    INEX
                                                           February 2017

Атрибут BGP Large Communities

BGP Large Communities Attribute

 PDF

Тезисы

Этот документ описывает атрибут BGP Large Communities, расширяющий протокол BGP-4. Атрибут обеспечивает механизм передачи «непрозрачной» (opaque) информации внутри разных пространств имен с целью управления маршрутизацией. Атрибут подходит для всех номеров автономных систем (ASN1), влючай 4-октетные ASN.

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

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

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

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

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

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

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

Оглавление

Исключено в версии HTML.

1. Введение

Реализации BGP [RFC4271] обычно поддерживают язык правил маршрутизации для управления распространением маршрутной информации. Сетевые операторы привязывают группы BGP (community) к маршрутам для связывания с маршрутом определенных свойств. Эти свойства могут включать информацию типа местоположения источника маршрута, спецификации действий правил маршрутизации, которые будут или были применены, и относятся ко всем маршрутам в сообщении BGP Update, включающем атрибут Communities. Поскольку атрибут BGP communities является необязательным переходным атрибутом BGP, группы BGP могут действовать или иным образом применяться в политике маршрутизации других автономных систем (AS) в сети Internet.

BGP Communities является атрибутом переменного размера, содержащим одно или множество четырехоктетных значений, каждое из которых указывает группу [RFC1997]. Общепринятое использование отдельных значения атрибута этого типа включает их разделение 32-битового значения на два 16-битовых слова. Старшее из этих слов трактуется, как номер автономной системы (ASN), а значение младшего определяется локальной политикой оператора AS, указанной старшим словом.

В результате принятия 4-октетных номеров AS [RFC6793] атрибут BGP Communities уже не может использовать описанное выше представление, поскольку 2-октетное слово не позволяет указать 4-октетный ASN. Атрибут BGP Extended Communities [RFC4360] также не подходит для этого. Шестиоктетный размер атрибута Extended Community вступает в противоречие с общепринятой практикой представления 4-октетных ASN в субполях Global Administrator и Local Administrator.

Для решения описанной проблемы данный документ определяет атрибут BGP Large Communities, представляемый в виде неупорядоченного списка из одного или множества 12-октетных значений, каждое из которых включает 4-октетное поле Global Administrator и два 4-октетных поля для определяемых оператором значений, каждое из которых может быть использовано для обозначения свойств или действий, имеющих смысл для оператора AS, присваивающего значения.

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

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

3. Атрибут BGP Large Communities

Этот документ определяет атрибут BGP Large Communities, как необязательный, переходный атрибут пути с переменным размером. Все маршруты с атрибутом BGP Large Communities относятся к группам (communities), указанным в атрибуте.

Каждое значение BGP Large Community представляется 12 октетами, как показано на рисунке.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Global Administrator                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Local Data Part 1                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Local Data Part 2                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Global Administrator

4-октетный идентификатор пространства имен.

Local Data Part 1

4-октетное значение, определенное оператором.

Local Data Part 2

4-октетное значение, определенное оператором.

Поле Global Administrator предназначено для того, чтобы в разных AS можно было определять BGP Large Communities без возникновения конфликтов. В этом поле следует указывать номер автономной системы (ASN), в которой компоненты Local Data Part будут интерпретироваться в соответствии с определением владельца ASN. Использование резервных значений ASN (0 [RFC7607], 65535 и 4294967295 [RFC7300]) в этом поле не рекомендуется.

Порядок размещения 12-октетных значений Large Community Attribute в атрибуте Large Communities не имеет значения и узел BGP может передавать их в любом порядке.

Дубликаты значений BGP Large Community передавать недопустимо. Принимающий узел должен отбрасывать без уведомления избыточные значения BGP Large Community из атрибута BGP Large Communities.

4. Агрегирование

При агрегировании маршрутов результату следует присваивать атрибут BGP Large Communities, который содержит атрибуты BGP Large Communities из всех агрегированных маршрутов.

5. Каноническое представление

Каноническим представлением атрибута BGP Large Communities являются три целых числа без знака в десятичном формате, указываемые в порядке Global Administrator, Local Data 1, Local Data 2. Использование нулей в начале целочисленных значений недопустимо; нулевое значение поля должно представляться одним символом 0. Числа отделяются одно от другого двоеточием — например, 64496:4294967295:2, 64496:0:0.

Атрибут BGP Large Communities следует задавать в каноническом представлении.

6. Обработка ошибок

Обработка ошибок для атрибута BGP Large Communities показана ниже.

  • Атрибут BGP Large Communities нужно считать некорректно сформированным, если размер значения BGP Large Communities Attribute в октетах не кратен 12.

  • Атрибут BGP Large Communities не нужно считать некорректно сформированным по причине наличия в нем дубликатов значение Large Community.

  • Сообщения BGP UPDATE с некорректно сформированным атрибутом BGP Large Communities нужно обрабатывать с использованием модели «трактовать, как отзыв» (treat-as-withdraw), описанной в разделе 2 [RFC7606].

В атрибуте BGP Large Communities поле Global Administrator может содержать любое значение и атрибут BGP Large Communities недопустимо считать некорректно сформированным, если поле Global Administrator содержит невыделенное, нераспределенное или резервное значение ASN.

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

Этот документ не оказывает влияния на вопросы безопасности, связанные с любым другим механизмом BGP Communities. В частности, AS, полагающаяся на атрибут BGP Large Communities передаваемый в BGP, должна доверять всем другим AS в пути, поскольку любая промежуточная AS на пути может добавить, удалить или изменить атрибут BGP Large Communities. Рассмотрение механизмов такого доверия выходит за рамки этого документа.

BGP Large Communities не обеспечивает защиты целостности содержащихся в атрибуте значений. Операторам следует принимать во внимание узлы BGP могут менять значения BGP Large Community Attribute в сообщениях BGP Update. Защита целостности промежуточной обработки атрибутов BGP Large Community в соответствии с выраженной политикой маршрутизации BGP относится к сфере общей защиты BGP и не рассматривается здесь.

Администраторам сетей следует принимать во внимание рекомендации раздела 11 в «BGP Operations and Security» [RFC7454].

8. Согласование с IANA

Агентство IANA выделило значение 32 (LARGE_COMMUNITY) в субреестре BGP Path Attributes реестра Border Gateway Protocol (BGP) Parameters.

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

9.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>.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.

[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, «Revised Error Handling for BGP UPDATE Messages», RFC 7606, DOI 10.17487/RFC7606, August 2015, <http://www.rfc-editor.org/info/rfc7606>.

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

[RFC1997] Chandra, R., Traina, P., and T. Li, «BGP Communities Attribute», RFC 1997, DOI 10.17487/RFC1997, August 1996, <http://www.rfc-editor.org/info/rfc1997>.

[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, «BGP Extended Communities Attribute», RFC 4360, DOI 10.17487/RFC4360, February 2006, <http://www.rfc-editor.org/info/rfc4360>.

[RFC6793] Vohra, Q. and E. Chen, «BGP Support for Four-Octet Autonomous System (AS) Number Space», RFC 6793, DOI 10.17487/RFC6793, December 2012, <http://www.rfc-editor.org/info/rfc6793>.

[RFC7300] Haas, J. and J. Mitchell, «Reservation of Last Autonomous System (AS) Numbers», BCP 6, RFC 7300, DOI 10.17487/RFC7300, July 2014, <http://www.rfc-editor.org/info/rfc7300>.

[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, «BGP Operations and Security», BCP 194, RFC 7454, DOI 10.17487/RFC7454, February 2015, <http://www.rfc-editor.org/info/rfc7454>.

[RFC7607] Kumari, W., Bush, R., Schiller, H., and K. Patel, «Codification of AS 0 Processing», RFC 7607, DOI 10.17487/RFC7607, August 2015, <http://www.rfc-editor.org/info/rfc7607>.

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

Авторы выражают свою признательность Ruediger Volk, Russ White, Acee Lindem, Shyam Sethuram, Jared Mauch, Joel M. Halpern, Jeffrey Haas, Gunter van de Velde, Marco Marzetti, Eduardo Ascenco Reis, Mark Schouten, Paul Hoogsteder, Martijn Schmidt, Greg Hankins, Bertrand Duvivier, Barry O’Donovan, Grzegorz Janoszka, Linda Dunbar, Marco Davids, Gaurab Raj Upadhaya, Jeff Tantsura, Teun Vink, Adam Davenport, Theodore Baschak, Pier Carlo Chiodi, Nabeel Cocker, Ian Dickinson, Jan Baggen, Duncan Lockwood, David Farmer, Randy Bush, Wim Henderickx, Stefan Plug, Kay Rechthien, Rob Shakir, Warren Kumari, Gert Doering, Thomas King, Mikael Abrahamsson, Wesley Steehouwer, Sander Steffann, Brad Dreisbach, Martin Millnert, Christopher Morrow, Jay Borkenhagen, Arnold Nipper, Joe Provo, Niels Bakker, Bill Fenner, Tom Daly, Ben Maddison, Alexander Azimov, Brian Dickson, Peter van Dijk, Julian Seifert, Tom Petch, Tom Scholl, Arjen Zonneveld, Remco van Mook, Adam Chappell, Jussi Peltola, Kristian Larsson, Markus Hauschild, Richard Steenbergen, David Freedman, Richard Hartmann, Geoff Huston, Mach Chen и Alvaro Retana за поддержку, рецензирование и комментарии.

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

Ниже перечислены люди, внесшие существенный вклад в содержимое этого документа.

John Heasley

NTT Communications

Email: heas@shrubbery.net

Adam Simpson

Nokia

Email: adam.1.simpson@nokia.com

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

Jakob Heitz (редактор)

Cisco

170 West Tasman Drive

San Jose, CA 95054

United States of America

Email: jheitz@cisco.com

Job Snijders (редактор)

NTT Communications

Theodorus Majofskistraat 100

Amsterdam 1065 SZ

The Netherlands

Email: job@ntt.net

Keyur Patel

Arrcus, Inc.

Email: keyur@arrcus.com

Ignas Bagdonas

Equinix

80 Cheapside

London EC2V 6EE

United Kingdom

Email: ibagdona.ietf@gmail.com

Nick Hilliard

INEX

4027 Kingswood Road

Dublin 24

Ireland

Email: nick@inex.ie


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

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

nmalykh@gmail.com


1Autonomous System Number.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.