О документе
Рабочая группа по сетям L. Martini
Запрос комментариев: 4446 Cisco Systems Inc.
BCP: 116 Апрель 2006
Категория: Лучшая современная практика
Выделения IANA для эмуляции соединения между краями псевдопровода (PWE3)
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 рабочих дней с момента получения им или ею запроса
на экспертную проверку.
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]
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 и поле длины.
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 символов.
Для каждого выделения также ДОЛЖНО (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].
4. Вопросы безопасности
Этот документ определяет только фиксированные идентификаторы, а не протоколы,
используемые для передачи инкапсулированных пакетов через сеть. Каждый такой
протокол может иметь собственный набор проблем безопасности, однако эти проблемы
не затрагиваются определёнными здесь идентификаторами.
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.