IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)
RFC 4446 определяет фиксированные идентификаторы и другие фиксированные значения протоколов для протоколов, разработанных рабочей группой PWE3. Документ задаёт реестры IANA и правила выделения значений для типов MPLS Pseudowire, подтипов параметров интерфейса, идентификаторов присоединения и кодов состояния pseudowire. Для диапазонов значений установлены процедуры достижения консенсуса IETF, экспертной проверки и выделения в порядке поступления заявок, в том числе для проприетарных расширений поставщиков. Для запросов на выделение определены требования к описаниям, полям длины и сроку рассмотрения экспертами; для диапазонов проприетарных расширений рекомендуется также приводить ссылку на документ.
Рабочая группа по сетям L. Martini
Запрос комментариев: 4446 Cisco Systems Inc.
BCP: 116 Апрель 2006
Категория: Лучшая современная практика
Выделения IANA для эмуляции соединения между краями псевдопровода (PWE3)
Статус этого меморандума
Этот документ определяет Лучшую современную практику Интернета для
интернет-сообщества и запрашивает обсуждение и предложения по
улучшению. Распространение этого меморандума не ограничено.
Уведомление об авторских правах
Авторское право (C) The Internet Society (2006).
Аннотация
Этот документ выделяет фиксированный идентификатор псевдопровода и другие
фиксированные значения протоколов для протоколов, определённых рабочей
группой Pseudo Wire Edge to Edge (PWE3). Подробные указания IANA по
выделению также включены в этот документ.
Содержание
1. Введение .........................................................2
2. Спецификация требований ..........................................2
3. Вопросы IANA .....................................................2
3.1. Директивы экспертной проверки ...............................2
3.2. Тип псевдопровода MPLS ......................................3
3.3. Тип Sub-TLV параметров интерфейса ...........................4
3.4. Идентификаторы присоединения ................................5
3.4.1. Тип индивидуального идентификатора присоединения .....5
3.4.2. Тип группового идентификатора присоединения (AGI) ....5
3.5. Статус псевдопровода ........................................6
3.6. Тип ассоциированного канала PW ..............................6
4. Вопросы безопасности .............................................7
5. Ссылки ...........................................................7
5.1. Нормативные ссылки ..........................................7
5.2. Информативные ссылки ........................................7
Martini Лучшая современная практика [Страница 1]
RFC 4446 Выделения IANA для PWE3 Апрель 2006
1. Введение
Большинство новых реестров IANA и соответствующих процессов выделения
IANA для протоколов, определённых в рабочей группе IETF PWE3, можно
найти в этом документе. Определённые здесь реестры IANA в целом
подразделяются на три основных диапазона: диапазон, выделяемый на основе
консенсуса IETF в соответствии с [RFC2434], диапазон, выделяемый посредством
процесса экспертной проверки в соответствии с [RFC2434], и диапазон,
выделяемый в порядке поступления заявок, который зарезервирован для
проприетарных выделений поставщиков. Обратите внимание, что
проприетарные типы поставщиков НЕ ДОЛЖНЫ (MUST NOT) регистрироваться
для стандартов IETF или их расширений, независимо от того, находятся
ли они ещё в разработке или уже завершены.
2. Спецификация требований
Ключевые слова «ДОЛЖЕН (MUST)», «НЕ ДОЛЖЕН (MUST NOT)», «ДОЛЖЕН
(REQUIRED)», «ДОЛЖЕН (SHALL)», «НЕ ДОЛЖЕН (SHALL NOT)», «СЛЕДУЕТ
(SHOULD)», «НЕ СЛЕДУЕТ (SHOULD NOT)», «СЛЕДУЕТ (RECOMMENDED)»,
«МОЖЕТ (MAY)» и «НЕОБЯЗАТЕЛЬНО (OPTIONAL)» в этом документе должны
интерпретироваться так, как описано в [RFC2119].
3. Вопросы IANA
IANA создала несколько реестров, как описано в следующих абзацах.
Каждый из этих реестров содержит числовые значения, используемые для
идентификации типов данных. В каждом из этих реестров значение 0
зарезервировано и НЕ ДОЛЖНО (MUST NOT) использоваться.
3.1. Директивы экспертной проверки
В настоящем документе процедуры выделения для нескольких реестров
предусматривают процесс экспертной проверки в соответствии с [RFC2434].
Эксперту следует рассмотреть следующие пункты:
* Следует избегать дублирования выделений кодовых точек.
* Следует предоставить краткое, ясное описание запрошенного
выделения кодовой точки.
* Запрошенное выделение типа следует соотнести с конкретным
запрошенным диапазоном значений в реестре.
Эксперт, рассматривающий запрос, ДОЛЖЕН (MUST) одобрить или отклонить
запрос в течение 10 рабочих дней с момента получения им или ею запроса
на экспертную проверку.
Martini Лучшая современная практика [Страница 2]
RFC 4446 Выделения IANA для PWE3 Апрель 2006
3.2. Тип псевдопровода MPLS
IANA создала реестр «MPLS Pseudowire Type». Этот тип имеет 15-битные
значения. Значения PW Type с 1 по 30 определены в настоящем документе,
а значения PW Type с 31 по 1024 должны назначаться IANA с использованием
политики «Expert Review», определённой в [RFC2434]. Значения PW Type
с 1025 по 4096 и 32767 должны выделяться с использованием политики
консенсуса IETF, определённой в [RFC2434]. Значения PW Type с 4097 по
32766 зарезервированы для проприетарных расширений поставщиков и должны
назначаться IANA с использованием политики «First Come First Served»,
определённой в [RFC2434]. Для любого назначения из этого реестра
требуется описание Pseudowire Type. Кроме того, для диапазона
проприетарных расширений поставщиков также требуется указание имени
лица или компании. Также следует предоставить ссылку на документ.
Ниже определены первоначальные выделения значений Pseudowire Type:
Тип PW Описание Ссылка
===================================================================
0x0001 Frame Relay DLCI ( Martini Mode ) [FRAME]
0x0002 Передача ATM AAL5 SDU VCC [ATM]
0x0003 Прозрачная передача ячеек ATM [ATM]
0x0004 Ethernet Tagged Mode [ETH]
0x0005 Ethernet [ETH]
0x0006 HDLC [PPPHDLC]
0x0007 PPP [PPPHDLC]
0x0008 Служба эмуляции каналов SONET/SDH поверх MPLS [CEP]
0x0009 Передача ячеек ATM n-к-одному VCC [ATM]
0x000A Передача ячеек ATM n-к-одному VPC [ATM]
0x000B Передача IP Layer2 [RFC3032]
0x000C Режим ячеек ATM один-к-одному VCC [ATM]
0x000D Режим ячеек ATM один-к-одному VPC [ATM]
0x000E Передача ATM AAL5 PDU VCC [ATM]
0x000F Режим порта Frame-Relay [FRAME]
0x0010 Эмуляция канала SONET/SDH поверх пакетов [CEP]
0x0011 Неструктурированный E1 поверх пакетов [SAToP]
0x0012 Неструктурированный T1 (DS1) поверх пакетов [SAToP]
0x0013 Неструктурированный E3 поверх пакетов [SAToP]
0x0014 Неструктурированный T3 (DS3) поверх пакетов [SAToP]
0x0015 Базовый режим CESoPSN [CESoPSN]
0x0016 Режим TDMoIP AAL1 [TDMoIP]
0x0017 CESoPSN TDM с CAS [CESoPSN]
0x0018 Режим TDMoIP AAL2 [TDMoIP]
0x0019 Frame Relay DLCI [FRAME]
Martini Лучшая современная практика [Страница 3]
RFC 4446 Выделения IANA для PWE3 Апрель 2006
3.3. Тип Sub-TLV параметров интерфейса
IANA должна создать реестр «Pseudowire Interface Parameter Sub-TLV
types». Этот тип имеет 8-битные значения. Типы Sub-TLV с 1 по 12
определены в настоящем документе. Типы Sub-TLV с 13 по 64 должны
назначаться IANA с использованием политики «Expert Review», определённой
в [RFC2434]. Типы Sub-TLV с 65 по 127 и 255 должны выделяться с
использованием политики консенсуса IETF, определённой в [RFC2434].
Значения типов Sub-TLV с 128 по 254 зарезервированы для проприетарных
расширений поставщиков и должны назначаться IANA с использованием
политики «First Come First Served», определённой в [RFC2434].
Любые назначения, запрашиваемые из этого реестра, требуют описания
длиной до 54 символов.
Для каждого выделения также ДОЛЖНО (MUST) быть указано поле длины в
одном из следующих форматов:
- Текст следующего вида: «up to X», где X — десятичное целое число.
- До 3 различных десятичных целых чисел.
Текст «up to X» означает до X включительно.
Кроме того, для диапазона проприетарных расширений поставщиков также
требуется указание имени лица или компании. Также следует предоставить
ссылку на документ.
Ниже определены первоначальные выделения типов Pseudowire Interface
Parameter Sub-TLV:
Параметр Длина Описание Ссылка
ID
========================================================================
0x01 4 MTU интерфейса в октетах [CRTL]
0x02 4 Максимальное число объединённых ячеек ATM [ATM]
0x03 up to 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-Relay [FRAME]
0x09 4 Индикатор фрагментации [FRAG]
0x0A 4 Индикатор сохранения FCS [FCS]
0x0B 4/8/12 Параметры TDM [TDMoIP]
0x0C 4 Параметр VCCV [VCCV]
Обратите внимание, что поле Length определено как длина Sub-TLV,
включая сам тип Sub-TLV и поле длины.
Martini Лучшая современная практика [Страница 4]
RFC 4446 Выделения IANA для PWE3 Апрель 2006
3.4. Идентификаторы присоединения
3.4.1. Тип индивидуального идентификатора присоединения
IANA должна создать реестр «Attachment Individual Identifier
(AII) Type». Этот тип имеет 8-битные значения. Значение AII Type 1
определено в настоящем документе. Значения AII Type с 2 по 64 должны
назначаться IANA с использованием политики «Expert Review», определённой
в [RFC2434]. Значения AII Type с 65 по 127 и 255 должны выделяться с
использованием политики консенсуса IETF, определённой в [RFC2434].
Значения типов AII с 128 по 254 зарезервированы для проприетарных
расширений поставщиков и должны назначаться IANA с использованием
политики «First Come First Served», определённой в [RFC2434].
Любые назначения, запрашиваемые из этого реестра, требуют описания
длиной до 54 символов.
Для каждого выделения также ДОЛЖНО (MUST) быть указано поле длины как
десятичное целое число.
Кроме того, для диапазона проприетарных расширений поставщиков также
требуется указание имени лица или компании. Также следует предоставить
ссылку на документ.
Ниже определены первоначальные выделения типов Attachment Individual
Identifier (AII):
Тип AII Длина Описание Ссылка
=====================================================================
0x01 4 Локальный идентификатор — 32-битное [SIG]
беззнаковое число.
3.4.2. Тип группового идентификатора присоединения (AGI)
IANA должна создать реестр «Attachment Group Identifier (AGI)
Type». Этот тип имеет 8-битные значения. Значение AGI Type 1 определено
в настоящем документе. Значения AGI Type с 2 по 64 должны назначаться
IANA с использованием политики «Expert Review», определённой в
[RFC2434]. Значения AGI Type с 65 по 127 и 255 должны выделяться с
использованием политики консенсуса IETF, определённой в [RFC2434].
Значения типов AGI с 128 по 254 зарезервированы для проприетарных
расширений поставщиков и должны назначаться IANA с использованием
политики «First Come First Served», определённой в [RFC2434].
Любые назначения, запрашиваемые из этого реестра, требуют описания
длиной до 54 символов.
Martini Лучшая современная практика [Страница 5]
RFC 4446 Выделения IANA для PWE3 Апрель 2006
Для каждого выделения также ДОЛЖНО (MUST) быть указано поле длины как
десятичное целое число.
Кроме того, для диапазона проприетарных расширений поставщиков также
требуется указание имени лица или компании. Также следует предоставить
ссылку на документ.
Ниже определены первоначальные выделения типов Attachment Group
Identifier (AGI):
Тип AGI Длина Описание Ссылка
===================================================================
0x01 8 AGI, закодированный как Route Distinguisher [SIG]
3.5. Статус псевдопровода
IANA должна создать реестр «Pseudowire Status Codes». Это битовые
строки длиной 32. Биты статуса с 0 по 4 определены в настоящем
документе. Биты статуса с 5 по 31 должны назначаться IANA с
использованием политики «Expert Review», определённой в [RFC2434].
Любые запросы на выделение из этого реестра требуют описания длиной
до 65 символов.
Первоначальные выделения значений Pseudowire Status Code приведены ниже:
Битовая маска Описание
====================================================================
0x00000000 - Пересылка псевдопровода (сброс всех признаков отказов) [CRTL]
0x00000001 - Псевдопровод не пересылает [CRTL]
0x00000002 - Ошибка приёма локального Attachment Circuit (входящего) [CRTL]
0x00000004 - Ошибка передачи локального Attachment Circuit (исходящего) [CRTL]
0x00000008 - Ошибка приёма локального PW, обращённого к PSN (входящего) [CRTL]
0x00000010 - Ошибка передачи локального PW, обращённого к PSN (исходящего) [CRTL]
Определение «PW Associated Channel Type» см. в [RFC4385].
3.6 Тип ассоциированного канала PW
Определение «PW Associated Channel Type» см. в [RFC4385].
Martini Лучшая современная практика [Страница 6]
RFC 4446 Выделения IANA для PWE3 Апрель 2006
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.
Martini Лучшая современная практика [Страница 7]
RFC 4446 IANA Allocations for PWE3 Апрель 2006
[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
Martini Лучшая современная практика [Страница 8]
RFC 4446 IANA Allocations for PWE3 Апрель 2006
Полное заявление об авторском праве
Авторское право (C) The Internet Society (2006).
Этот документ подпадает под действие прав, лицензий и ограничений,
содержащихся в BCP 78, и, за исключением предусмотренного в нём,
авторы сохраняют все свои права.
Этот документ и содержащаяся в нём информация предоставляются на условиях
"КАК ЕСТЬ", И УЧАСТНИК, ОРГАНИЗАЦИЯ, КОТОРУЮ ОН/ОНА ПРЕДСТАВЛЯЕТ
ИЛИ КОТОРОЙ СПОНСИРУЕТСЯ (ЕСЛИ ТАКОВАЯ ИМЕЕТСЯ), THE INTERNET SOCIETY
И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ,
ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО,
ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИЕ-ЛИБО
ПРАВА, ИЛИ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ
ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.
Интеллектуальная собственность
IETF не занимает позиции относительно действительности или объёма каких-либо
прав интеллектуальной собственности либо иных прав, которые могут быть заявлены
как относящиеся к реализации или использованию технологии, описанной в этом
документе, или относительно того, может ли какая-либо лицензия на такие права
быть доступна или не быть доступна; также она не заявляет, что предприняла
какие-либо независимые усилия для выявления таких прав. Информацию о процедурах
в отношении прав на документы RFC можно найти в BCP 78 и BCP 79.
Копии раскрытий IPR, сделанных Секретариату IETF, и любые заверения о лицензиях,
которые будут предоставлены, либо результат попытки получить общую лицензию
или разрешение на использование таких прав собственности реализаторами или
пользователями этой спецификации можно получить из онлайнового репозитория IPR
IETF по адресу http://www.ietf.org/ipr.
IETF приглашает любую заинтересованную сторону довести до её сведения любые
авторские права, патенты или патентные заявки либо иные права собственности,
которые могут охватывать технологию, которая может потребоваться для реализации
этого стандарта. Просьба направлять информацию в IETF по адресу
ietf-ipr@ietf.org.
Благодарность
Финансирование функции RFC Editor обеспечивается IETF
Administrative Support Activity (IASA).
Martini Лучшая современная практика [Страница 9]
Network Working Group L. Martini
Request for Comments: 4446 Cisco Systems Inc.
BCP: 116 April 2006
Category: Best Current Practice
IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)
Status of This Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document allocates the fixed pseudowire identifier and other
fixed protocol values for protocols that have been defined in the
Pseudo Wire Edge to Edge (PWE3) working group. Detailed IANA
allocation instructions are also included in this document.
Table of Contents
1. Introduction ....................................................2
2. Specification of Requirements ...................................2
3. IANA Considerations .............................................2
3.1. Expert Review Directives ...................................2
3.2. MPLS Pseudowire Type .......................................3
3.3. Interface Parameters Sub-TLV Type ..........................4
3.4. Attachment Identifiers .....................................5
3.4.1. Attachment Individual Identifier Type ...............5
3.4.2. Attachment Group Identifier (AGI) Type ..............5
3.5. Pseudowire Status ..........................................6
3.6. PW Associated Channel Type .................................6
4. Security Considerations .........................................7
5. References ......................................................7
5.1. Normative References .......................................7
5.2. Informative References .....................................7
Martini Best Current Practice [Page 1]
RFC 4446 IANA Allocations for PWE3 April 2006
1. Introduction
Most of the new IANA registries and respective IANA-allocation
processes for protocols defined in the PWE3 IETF working group can be
found in this document. The IANA registries defined here are in
general subdivided into three main ranges: a range to be allocated by
IETF consensus according to [RFC2434], a range to be allocated by the
expert review process according to [RFC2434], and a range to be
allocated on a first come, first served basis that is reserved for
vendor proprietary allocations. Note that vendor proprietary types
MUST NOT be registered for IETF standards or extensions thereof,
whether they are still in development or already completed.
2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. IANA Considerations
IANA has created several registries as described in the following
paragraphs. Each of these registries contains numeric values used to
identify data types. In each of these registries, the value of 0 is
reserved and MUST not be used.
3.1. Expert Review Directives
Throughout this document, allocation procedures for several
registries call for an expert review process according to [RFC2434].
The expert should consider the following points:
* Duplication of code point allocations should be avoided.
* A brief, clear description of the code point allocation
requested should be provided.
* The type allocation requested should be appropriate for the
particular requested value range in the registry.
The expert reviewing the request MUST approve or disapprove the
request within 10 business days from when he or she received the
expert review request.
Martini Best Current Practice [Page 2]
RFC 4446 IANA Allocations for PWE3 April 2006
3.2. MPLS Pseudowire Type
IANA has set up the registry of "MPLS Pseudowire Type". This type
has 15-bit values. PW Type values 1 through 30 are specified in this
document, and PW Type values 31 through 1024 are to be assigned by
IANA, using the "Expert Review" policy defined in [RFC2434]. PW Type
values 1025 through 4096 and 32767 are to be allocated using the IETF
consensus policy defined in [RFC2434]. PW Type values 4097 through
32766 are reserved for vendor-proprietary extensions and are to be
assigned by IANA, using the "First Come First Served" policy defined
in [RFC2434]. A Pseudowire Type description is required for any
assignment from this registry. Additionally, for the vendor-
proprietary extensions range, a citation of a person or company name
is also required. A document reference should also be provided.
Initial Pseudowire Type value allocations are specified below:
PW type Description Reference
===================================================================
0x0001 Frame Relay DLCI ( Martini Mode ) [FRAME]
0x0002 ATM AAL5 SDU VCC transport [ATM]
0x0003 ATM transparent cell transport [ATM]
0x0004 Ethernet Tagged Mode [ETH]
0x0005 Ethernet [ETH]
0x0006 HDLC [PPPHDLC]
0x0007 PPP [PPPHDLC]
0x0008 SONET/SDH Circuit Emulation Service Over MPLS [CEP]
0x0009 ATM n-to-one VCC cell transport [ATM]
0x000A ATM n-to-one VPC cell transport [ATM]
0x000B IP Layer2 Transport [RFC3032]
0x000C ATM one-to-one VCC Cell Mode [ATM]
0x000D ATM one-to-one VPC Cell Mode [ATM]
0x000E ATM AAL5 PDU VCC transport [ATM]
0x000F Frame-Relay Port mode [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 basic mode [CESoPSN]
0x0016 TDMoIP AAL1 Mode [TDMoIP]
0x0017 CESoPSN TDM with CAS [CESoPSN]
0x0018 TDMoIP AAL2 Mode [TDMoIP]
0x0019 Frame Relay DLCI [FRAME]
Martini Best Current Practice [Page 3]
RFC 4446 IANA Allocations for PWE3 April 2006
3.3. Interface Parameters Sub-TLV Type
IANA has to set up the registry of "Pseudowire Interface Parameter
Sub-TLV types". This type has 8-bit values. Sub-TLV types 1 through
12 are specified in this document. Sub-TLV types 13 through 64 are
to be assigned by IANA, using the "Expert Review" policy defined in
[RFC2434]. Sub-TLV types 65 through 127 and 255 are to be allocated
using the IETF consensus policy defined in [RFC2434]. Sub-TLV types
values 128 through 254 are reserved for vendor-proprietary extensions
and are to be assigned by IANA, using the "First Come First Served"
policy defined in [RFC2434].
Any assignments requested from this registry require a description of
up to 54 characters.
For each allocation, a length field MUST also be specified in one of
the following formats:
- Text as follows:"up to X", where X is a decimal integer.
- Up to 3 different decimal integers.
The text "up to X" means up to and including X.
Additionally, for the vendor-proprietary extensions range, a citation
of a person or company name is also required. A document reference
should also be provided.
Initial Pseudowire Interface Parameter Sub-TLV type allocations are
specified below:
Parameter Length Description Reference
ID
========================================================================
0x01 4 Interface MTU in octets [CRTL]
0x02 4 Maximum Number of concatenated ATM cells [ATM]
0x03 up to 82 Optional Interface Description string [CRTL][RFC2277]
0x04 4 CEP/TDM Payload Bytes [CEP][TDMoIP]
0x05 4 CEP options [CEP]
0x06 4 Requested VLAN ID [ETH]
0x07 6 CEP/TDM bit-rate [CEP][TDMoIP]
0x08 4 Frame-Relay DLCI Length [FRAME]
0x09 4 Fragmentation indicator [FRAG]
0x0A 4 FCS retention indicator [FCS]
0x0B 4/8/12 TDM options [TDMoIP]
0x0C 4 VCCV parameter [VCCV]
Note that the Length field is defined as the length of the Sub-TLV,
including the Sub-TLV type and length field itself.
Martini Best Current Practice [Page 4]
RFC 4446 IANA Allocations for PWE3 April 2006
3.4. Attachment Identifiers
3.4.1. Attachment Individual Identifier Type
IANA has to set up the registry of "Attachment Individual Identifier
(AII) Type". This type has 8-bit values. AII Type value 1 is
defined in this document. AII Type values 2 through 64 are to be
assigned by IANA, using the "Expert Review" policy defined in
[RFC2434]. AII Type values 65 through 127 and 255 are to be
allocated using the IETF consensus policy defined in [RFC2434]. AII
types values 128 through 254 are reserved for vendor-proprietary
extensions and are to be assigned by IANA, using the "First Come
First Served" policy defined in [RFC2434].
Any assignments requested from this registry require a description of
up to 54 characters.
For each allocation, a length field MUST also be specified as a
decimal integer.
Additionally, for the vendor-proprietary extensions range, a citation
of a person or company name is also required. A document reference
should also be provided.
Initial Attachment Individual Identifier (AII) Type allocations are
specified below:
AII Type Length Description Reference
=====================================================================
0x01 4 A 32 bit unsigned number local [SIG]
identifier.
3.4.2. Attachment Group Identifier (AGI) Type
IANA has to set up the registry of "Attachment Group Identifier (AGI)
Type". This type has 8-bit values. AGI Type value 1 is defined in
this document. AGI Type values 2 through 64 are to be assigned by
IANA, using the "Expert Review" policy defined in [RFC2434]. AGI
Type values 65 through 127 and 255 are to be allocated using the IETF
consensus policy defined in [RFC2434]. AGI type values 128 through
254 are reserved for vendor-proprietary extensions and are to be
assigned by IANA, using the "First Come First Served" policy defined
in [RFC2434].
Any assignments requested from this registry require a description of
up to 54 characters.
Martini Best Current Practice [Page 5]
RFC 4446 IANA Allocations for PWE3 April 2006
For each allocation, a length field MUST also be specified as a
decimal integer.
Additionally, for the vendor-proprietary extensions range, a citation
of a person or company name is also required. A document reference
should also be provided.
Initial Attachment Group Identifier (AGI) Type allocations are
specified below:
AGI Type Length Description Reference
===================================================================
0x01 8 AGI encoded as Route Distinguisher [SIG]
3.5. Pseudowire Status
IANA has to set up the registry of "Pseudowire Status Codes". These
are bit strings of length 32. Status bits 0 through 4 are defined in
this document. Status bits 5 through 31 are to be assigned by IANA
using the "Expert Review" policy defined in [RFC2434].
Any requests for allocation from this registry require a description
of up to 65 characters.
Initial Pseudowire Status Code value allocations are as follows:
Bit Mask Description
====================================================================
0x00000000 - Pseudowire forwarding (clear all failures) [CRTL]
0x00000001 - Pseudowire Not Forwarding [CRTL]
0x00000002 - Local Attachment Circuit (ingress) Receive Fault [CRTL]
0x00000004 - Local Attachment Circuit (egress) Transmit Fault [CRTL]
0x00000008 - Local PSN-facing PW (ingress) Receive Fault [CRTL]
0x00000010 - Local PSN-facing PW (egress) Transmit Fault [CRTL]
For the definition of the "PW Associated Channel Type" please refer
to [RFC4385].
3.6 PW Associated Channel Type
For the definition of the "PW Associated Channel Type", please refer
to [RFC4385].
Martini Best Current Practice [Page 6]
RFC 4446 IANA Allocations for PWE3 April 2006
4. Security Considerations
This document specifies only fixed identifiers, and not the protocols
used to carry the encapsulated packets across the network. Each such
protocol may have its own set of security issues, but those issues
are not affected by the identifiers specified herein.
5. References
5.1. Normative References
[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. Informative References
[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.
Martini Best Current Practice [Page 7]
RFC 4446 IANA Allocations for PWE3 April 2006
[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.
Author's Address
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112
EMail: lmartini@cisco.com
Martini Best Current Practice [Page 8]
RFC 4446 IANA Allocations for PWE3 April 2006
Full Copyright Statement
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.
Intellectual Property
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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Martini Best Current Practice [Page 9]