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

Please enter banners and links.

image_print
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).

Тезисы

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

Оглавление

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

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 Progress2, August 2005.

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

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

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

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

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

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

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

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

[TDMoIP] Stein, Y., Shashoua, R., Insler, R., and M. Anavi, “TDM over IP”, Work in Progress11, 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 Progress12, 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).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

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

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

1Pseudo Wire Edge to Edge — сквозной псевдопровод.

2Работа завершена и опубликована в RFC 5085. Прим. перев.

3Работа завершена и опубликована в RFC 4623. Прим. перев.

4Работа завершена и опубликована в RFC 4720. Прим. перев.

5Работа завершена и опубликована в RFC 4842. Прим. перев.

6Работа завершена и опубликована в RFC 4553. Прим. перев.

7Работа завершена и опубликована в RFC 4619. Прим. перев.

8Работа завершена и опубликована в RFC 4717. Прим. перев.

9Работа завершена и опубликована в RFC 4618. Прим. перев.

10Работа завершена и опубликована в RFC 5086. Прим. перев.

11Работа завершена и опубликована в RFC 5087. Прим. перев.

12Работа завершена и опубликована в RFC 6074. Прим. перев.

Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.

Добавить комментарий

Or