RFC 4446 IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)

Network Working Group                                         L. Martini
Request for Comments: 4446                            Cisco Systems Inc.
BCP: 116                                                      April 2006
Category: Best Current Practice

Значения, выделенные IANA для эмуляции сквозных псевдопроводов (PWE3)

IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)

PDF

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

Этот документ описывает обретенный опыт (Internet Best Current Practices) для сообщества Internet и служит приглашением к дискуссии в целях дальнейшего развития. Документ может распространяться без ограничений.

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

Copyright (C) The Internet Society (2006).

Аннотация

Этот документ выделяет фиксированные идентификаторы псевдопроводов (ПП) и другие фиксированные значения для протоколов, определенных рабочей группой PWE3¹. В документ также включены детальные инструкции для IANA по выделению значений.

1. Введение

В этом документе описаны многие новые реестры IANA и соответствующие процесс IANA для протоколов, определенных рабочей группой PWE3 IETF. Определенные здесь реестры IANA в основном поделены на три диапазона — значения выделяемые с согласия IETF, в соответствии с [RFC2434], значения, выделяемые по решению экспертов (expert review), в соответствии с [RFC2434] и диапазон значений, выделяемых в порядке очередности запросов для распределения производителями. Отметим, что фирменные типы производителей недопустимо регистрировать для стандартов IETF или расширений, независимо от того, находятся они еще в разработке или уже завершены.

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

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

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

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

3.1. Директивы для экспертного обзора

В этом документе указано выделение значений для нескольких реестров по процедуре Expert review (рецензия эксперта) в соответствии с [RFC2434]. Эксперту следует принимать во внимание следующие аспекты:

• следует избегать дублирования кодовых значений;

• должно быть представлено краткое и четкое описание запрашиваемых для выделения кодов;

• тип запрошенного выделения должен соответствовать диапазону значения в реестре.

Рецензия эксперта должна принимать или отвергать запрос в течение 10 рабочих дней с момента получения этого запроса экспертом.

3.2. Реестр MPLS Pseudowire Type

Агентство IANA организовало реестр типов псевдопроводов MPLS Pseudowire Type. Типы псевдопроводов задаются 15-битовыми значениями. Значения PW Type от 1 до 30 заданы в этом документе, значения 31 – 1024 будут распределяться IANA по процедуре Expert Review, определенной в [RFC2434]. Значения PW Type от 1025 до 4096 и 32767 будут распределяться по с согласия IETF, как описано в [RFC2434]. Типы 4097 – 32766 резервируются для фирменных расширений и будут распределяться IANA по процедуре First Come First Served, определенной в [RFC2434]. При любом распределении значений из этого реестра требуется описание Pseudowire Type. Кроме того, при выделении значений из диапазона фирменных расширений будет требоваться указание компании или человека. Следует также приводить ссылку на документ с описанием типа.

Изначально выделенные значения Pseudowire Type приведены в таблице ниже.

Тип ПП	Описание	Документ
0x0001	Frame Relay DLCI ( Martini Mode )	[FRAME]
0x0002	Транспорт ATM AAL5 SDU VCC	[ATM]
0x0003	Прозрачная транспортировка ячеек ATM	[ATM]
0x0004	Ethernet с тегами	[ATM]
0x0005	Ethernet	[ATM]
0x0006	HDLC	[PPPHDLC]
0x0007	PPP	[PPPHDLC]
0x0008	SONET/SDH Circuit Emulation Service Over MPLS	[CEP]
0x0009	Транспортировка ячеек ATM n-to-one VCC	[ATM]
0x000A	Транспортировка ячеек ATM n-to-one VPC	[ATM]
0x000B	Транспорт IP L2	[RFC3032]
0x000C	Режим ATM one-to-one VCC Cell	[ATM]
0x000D	Режим ATM one-to-one VPC Cell	[ATM]
0x000E	Транспорт ATM AAL5 PDU VCC	[ATM]
0x000F	Режим Frame-Relay Port	[FRAME]
0x0010	SONET/SDH Circuit Emulation over Packet	[CEP]
0x0011	Structure-agnostic E1 over Packet	[SAToP]
0x0012	Structure-agnostic T1 (DS1) over Packet	[SAToP]
0x0013	Structure-agnostic E3 over Packet	[SAToP]
0x0014	Structure-agnostic T3 (DS3) over Packet	[SAToP]
0x0015	Базовый режим CESoPSN	[CESoPSN]
0x0016	Режим TDMoIP AAL1	[TDMoIP]
0x0017	CESoPSN TDM с CAS	[CESoPSN]
0x0018	Режим TDMoIP AAL2	[TDMoIP]
0x0019	Frame Relay DLCI	[FRAME]

3.3. Реестр Interface Parameters Sub-TLV Type

Агентство IANA организовало реестр Pseudowire Interface Parameter Sub-TLV types. Для идентификаторов типов используются 8-битовые значения. Типы 1 – 12 заданы в настоящем документе, типы 13 — 64 распределяются IANA по процедуре Expert Review, описанной в [RFC2434]. Типы 65 – 127 и 255 распределяются по согласованию с IETF, как описано в [RFC2434]. Типы 128 – 254 зарезервированы для фирменных расширений и распределяются IANA по процедуре First Come First Served, описанной в [RFC2434].

Для каждого выделяемого из реестра значения требуется предоставить описание размером до 54 символов.

Для каждого выделяемого значения должно быть указано поле length в одном из приведенных ниже форматов:

• текст вида: «размером до X», где X — десятичное целое число;

• до 3 разных десятичных целых.

Текст «размером до X» предполагает включение размера X.

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

Изначально выделенные значения Pseudowire Interface Parameter Sub-TLV type приведены в таблице ниже.

Идентификатор	Размер	Описание	Документ
0x01	4	MTU интерфейса в октетах	[CRTL]
0x02	4	Максимальное число объединяемых ячеек ATM	[ATM]
0x03	До 82	Необязательная строка описания интерфейса	[CRTL] [RFC2277]
0x04	4	Байты данных CEP/TDM	[CEP] [TDMoIP]
0x05	4	Опции CEP	[CEP]
0x06	4	Запрошенный идентификатор VLAN	[ETH]
0x07	6	Битовая скорость CEP/TDM	[CEP] [TDMoIP]
0x08	4	Размер DLCI	[FRAME]
0x09	4	Индикатор фрагментации	[FRAG]
0x0A	4	Индикатор удержания FCS	[FCS]
0x0B	4/08/12	Опции TDM	[TDMoIP]
0x0C	4	Параметр VCCV	[VCCV]

Отметим, что поле Length определяется, как размер Sub-TLV с учетом полей типа и размера этого Sub-TLV.

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

3.4.1. Индивидуальный идентификатор подключения (AII)

Агентство IANA организовало реестр Attachment Individual Identifier (AII) Type, содержащий 8-битовые значения. Данный документ определяет значение AII Type = 1. Типы 2 – 64 распределяются IANA по процедуре Expert Review, описанной в [RFC2434], 65 – 127 и 255 выделяются по согласованию с IETF, как описано в [RFC2434]. Типы 128 – 254 резервируются для фирменных расширений и распределяются IANA по процедуре First Come First Served, описанной в [RFC2434].

Для каждого выделяемого из реестра значения требуется предоставить описание размером до 54 символов.

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

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

Текущее распределение Initial Attachment Individual Identifier (AII) Type приведено в таблице ниже.

AII Type	Размер	Описание	Документ
0x01	4	32-битовое целое число без знака, с локальной значимостью	[SIG]

3.4.2. Групповой идентификатор подключения (AGI)

Агентство IANA организовало реестр Attachment Group Identifier (AGI) Type, содержащий 8-битовые значения. Данный документ определяет значение AGI Type = 1. Типы 2 – 64 распределяются IANA по процедуре Expert Review, описанной в [RFC2434], 65 – 127 и 255 выделяются по согласованию с IETF, как описано в [RFC2434]. Типы 128 – 254 резервируются для фирменных расширений и распределяются IANA по процедуре First Come First Served [RFC2434].

Для каждого выделяемого из реестра значения требуется предоставить описание размером до 54 символов.

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

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

Текущее распределение Initial Attachment Group Identifier (AGI) Type приведено в таблице ниже.

AGI Type	Размер	Описание	Документ
0x01	8	Идентификатор AGI в форме Route Distinguisher	[SIG]

3.5. Статус псевдопровода

Агентство IANA организовало реестр Pseudowire Status Codes, содержащий битовые строки размером 32 бита. Биты состояния 0 – 4 определены в данном документе. Статусные биты 5 – 31 будут распределяться IANA по процедуре Expert Review, определенной в [RFC2434].

Для каждого выделяемого из реестра значения требуется предоставить описание размером до 65 символов.

Текущие значения кодов Pseudowire Status приведены в таблице.

Битовая маска	Описание	Документ
0x00000000	Pseudowire forwarding (сброс всех отказов)	[CRTL]
0x00000001	Pseudowire Not Forwarding	[CRTL]
0x00000002	Отказ на приеме в локальном устройстве подключения (вход)	[CRTL]
0x00000004	Отказ при передаче в локальном устройстве подключения (выход)	[CRTL]
0x00000008	Отказ на приеме в локальном PSN-facing PW подключения (вход)	[CRTL]
0x00000010	Отказ при передаче в локальном PSN-facing PW подключения (выход)	[CRTL]

3.6. PW Associated Channel Type

Определение PW Associated Channel Type приведено в [RFC4385].

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

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

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

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

[RFC2434] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 2434, October 1998.

[RFC2277] Alvestrand, H., “IETF Policy on Character Sets and Languages”, BCP 18, RFC 2277, January 1998.

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

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

[CRTL] 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, April 2006.

[VCCV] Nadeau, T. and R. Aggarwal, “Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)”, Work in Progress², August 2005.

[FRAG] Malis, A. and M. Townsley, “PWE3 Fragmentation and Reassembly”, Work in Progress³, September 2005.

[FCS] Malis, A., Allan, D., and N. Del Regno, “PWE3 Frame Check Sequence Retention”, Work in Progress⁴, September 2005.

[CEP] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig, “SONET/SDH Circuit Emulation Service Over Packet (CEP)”, Work in Progress⁵.

[SAToP] Vainshtein, A. Ed. and Y. Stein, Ed. “Structure-Agnostic TDM over Packet (SAToP)”, Work in Progress⁶.

[FRAME] Martini, L., Ed. and C. Kawa, “Encapsulation Methods for Transport of Frame Relay Over MPLS Networks”, Work in Progress⁷.

[ATM] Martini, L., Ed., El-Aawar, N., and M. Bocci, Ed., “Encapsulation Methods for Transport of ATM Over MPLS Networks”, Work in Progress⁸.

[PPPHDLC] Martini, L., Rosen, E., Heron, G. and A. Malis, “Encapsulation Methods for Transport of PPP/HDLC Frames Over MPLS Networks”, Work in Progress⁹.

[ETH] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, “Encapsulation Methods for Transport of Ethernet Frames Over MPLS Networks”, RFC 4448, April 2006.

[CESoPSN] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and P. Pate, “Structure-aware TDM Circuit Emulation Service over Packet Switched Network (CESoPSN)”, Work in Progress¹⁰.

[TDMoIP] Stein, Y., Shashoua, R., Insler, R., and M. Anavi, “TDM over IP”, Work in Progress¹¹, February 2005.

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

[SIG] Rosen, E., Luo, W., Davie, B., and V. Radoaca, “Provisioning, Autodiscovery, and Signaling in L2VPNs”, Work in Progress¹², September 2005.

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

Адрес автора

Luca Martini

Cisco Systems, Inc.

9155 East Nichols Avenue, Suite 400

Englewood, CO, 80112

EMail: lmartini@cisco.com

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

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

nmalykh@gmail.com

Полное заявление авторских прав

Copyright (C) The Internet Society (2006).

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

Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

Интеллектуальная собственность

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).

---