Network Working Group L. Martini
Request for Comments: 4446 Cisco Systems Inc.
BCP: 116 April 2006
Category: Best Current Practice
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)
用于伪线边到边仿真（PWE3）的IANA分配
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).
版权所有（C）互联网协会（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.
本文档为伪线边缘到边缘（PWE3）工作组中定义的协议分配固定伪线标识符和其他固定协议值。本文件还包括详细的IANA分配说明。
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
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
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.
PWE3 IETF工作组中定义的协议的大多数新IANA注册和相应IANA分配过程可在本文件中找到。此处定义的IANA注册一般分为三个主要范围：根据[RFC2434]由IETF协商一致分配的范围，根据[RFC2434]由专家评审程序分配的范围，以及根据先到先得原则分配的范围，该范围保留给供应商专有分配。请注意，供应商专有类型不得注册为IETF标准或其扩展，无论它们是否仍在开发中或已完成。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
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.
IANA已经创建了几个注册中心，如以下段落所述。每个注册表都包含用于标识数据类型的数值。在每个注册表中，0的值都是保留的，不能使用。
Throughout this document, allocation procedures for several registries call for an expert review process according to [RFC2434]. The expert should consider the following points:
在本文件中，几个登记处的分配程序要求按照[RFC2434]进行专家审查。专家应考虑以下几点：
* 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.
审查请求的专家必须在收到专家审查请求后的10个工作日内批准或不批准请求。
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.
IANA已经建立了“MPLS伪线类型”注册表。此类型有15位值。本文件规定了PW类型值1至30，IANA将使用[RFC2434]中定义的“专家评审”政策分配PW类型值31至1024。PW类型值1025至4096和32767将使用[RFC2434]中定义的IETF共识策略进行分配。PW类型值4097到32766保留给供应商专有扩展，由IANA使用[RFC2434]中定义的“先到先得”策略分配。此注册表中的任何分配都需要伪导线类型描述。此外，对于供应商专有扩展范围，还需要引用个人或公司名称。还应提供文件参考。
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]
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]
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].
IANA必须设置“伪线接口参数子TLV类型”的注册表。此类型具有8位值。本文件规定了子TLV类型1至12。IANA将使用[RFC2434]中定义的“专家评审”政策分配子TLV类型13至64。子TLV类型65至127和255将使用[RFC2434]中定义的IETF共识策略进行分配。子TLV类型值128到254保留给供应商专有扩展，由IANA使用[RFC2434]中定义的“先到先得”策略分配。
Any assignments requested from this registry require a description of up to 54 characters.
从该注册表请求的任何分配都需要最多54个字符的描述。
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.
- 文本如下：“最多X”，其中X是十进制整数。-最多3个不同的十进制整数。
The text "up to X" means up to and including X.
文本“最多X”指最多X，包括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:
初始伪线接口参数子TLV类型分配指定如下：
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]
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.
请注意，长度字段定义为子TLV的长度，包括子TLV类型和长度字段本身。
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].
IANA必须设置“附件个人标识符（AII）类型”的注册表。此类型具有8位值。本文档中定义了所有类型值1。IANA将使用[RFC2434]中定义的“专家评审”政策分配所有类型值2至64。使用[RFC2434]中定义的IETF共识策略分配所有类型值65至127和255。所有类型值128到254保留给供应商专有扩展，由IANA使用[RFC2434]中定义的“先到先得”策略分配。
Any assignments requested from this registry require a description of up to 54 characters.
从该注册表请求的任何分配都需要最多54个字符的描述。
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）类型分配：
AII Type Length Description Reference
=====================================================================
0x01 4 A 32 bit unsigned number local [SIG]
identifier.
AII Type Length Description Reference
=====================================================================
0x01 4 A 32 bit unsigned number local [SIG]
identifier.
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].
IANA必须设置“附件组标识符（AGI）类型”的注册表。此类型具有8位值。AGI类型值1在本文档中定义。IANA将使用[RFC2434]中定义的“专家评审”政策分配AGI类型值2至64。AGI类型值65到127和255将使用[RFC2434]中定义的IETF共识策略进行分配。AGI类型值128到254保留给供应商专有扩展，由IANA使用[RFC2434]中定义的“先到先得”策略分配。
Any assignments requested from this registry require a description of up to 54 characters.
从该注册表请求的任何分配都需要最多54个字符的描述。
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）类型分配：
AGI Type Length Description Reference
===================================================================
0x01 8 AGI encoded as Route Distinguisher [SIG]
AGI Type Length Description Reference
===================================================================
0x01 8 AGI encoded as Route Distinguisher [SIG]
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].
IANA必须建立“伪线路状态代码”的注册表。这些是长度为32的位字符串。本文档中定义了状态位0到4。IANA将使用[RFC2434]中定义的“专家评审”政策分配状态位5至31。
Any requests for allocation from this registry require a description of up to 65 characters.
来自此注册表的任何分配请求都需要最多65个字符的描述。
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]
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].
有关“PW相关信道类型”的定义，请参考[RFC4385]。
For the definition of the "PW Associated Channel Type", please refer to [RFC4385].
有关“PW相关信道类型”的定义，请参考[RFC4385]。
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.
本文档仅指定固定标识符，而不是用于在网络上传输封装数据包的协议。每个这样的协议可以具有其自己的一组安全问题，但是这些问题不受本文指定的标识符的影响。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277]Alvestrand，H.，“IETF字符集和语言政策”，BCP 18，RFC 2277，1998年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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.
[CRTL]Martini，L.，Ed.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月。
[VCCV] Nadeau, T. and R. Aggarwal, "Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)", Work in Progress, August 2005.
[VCCV]Nadeau，T.和R.Aggarwal，“伪线虚拟电路连接验证（VCCV）”，正在进行的工作，2005年8月。
[FRAG] Malis, A. and M. Townsley, "PWE3 Fragmentation and Reassembly", Work in Progress, September 2005.
[FRAG]Malis，A.和M.Townsley，“PWE3碎片化和重组”，正在进行的工作，2005年9月。
[FCS] Malis, A., Allan, D., and N. Del Regno, "PWE3 Frame Check Sequence Retention", Work in Progress, September 2005.
[FCS]Malis，A.，Allan，D.，和N.Del Regno，“PWE3帧检查序列保留”，正在进行的工作，2005年9月。
[CEP] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig, "SONET/SDH Circuit Emulation Service Over Packet (CEP)", Work in Progress.
[CEP]Malis，A.，Pate，P.，Cohen，R.，Ed.，和D.Zelig，“SONET/SDH分组电路仿真服务（CEP）”，正在进行中。
[SAToP] Vainshtein, A. Ed. and Y. Stein, Ed. "Structure-Agnostic TDM over Packet (SAToP)", Work in Progress.
Vainstein，A.Ed.和Y.Stein，Ed.“数据包上的结构不可知TDM（SAToP）”，正在进行中。
[FRAME] Martini, L., Ed. and C. Kawa, "Encapsulation Methods for Transport of Frame Relay Over MPLS Networks", Work in Progress.
[FRAME]Martini，L.，Ed.和C.Kawa，“MPLS网络上帧中继传输的封装方法”，正在进行中。
[ATM] Martini, L., Ed., El-Aawar, N., and M. Bocci, Ed., "Encapsulation Methods for Transport of ATM Over MPLS Networks", Work in Progress.
[ATM]Martini，L.，Ed.，El Aawar，N.，和M.Bocci，Ed.“通过MPLS网络传输ATM的封装方法”，正在进行中。
[PPPHDLC] Martini, L., Rosen, E., Heron, G. and A. Malis, "Encapsulation Methods for Transport of PPP/HDLC Frames Over MPLS Networks", Work in Progress.
[PPPHDLC]Martini，L.，Rosen，E.，Heron，G.和A.Malis，“通过MPLS网络传输PPP/HDLC帧的封装方法”，正在进行中。
[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.
[ETH]Martini，L.，Rosen，E.，El Aawar，N.，和G.Heron，“通过MPLS网络传输以太网帧的封装方法”，RFC 4448，2006年4月。
[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.
[CESoPSN]Vainstein，A.，Ed.，Sasson，I.，Metz，E.，Frost，T.，和P.Pate，“分组交换网络上的结构感知TDM电路仿真服务（CESoPSN）”，正在进行中。
[TDMoIP] Stein, Y., Shashoua, R., Insler, R., and M. Anavi, "TDM over IP", Work in Progress, February 2005.
[TDMoIP]Stein，Y.，Shashoua，R.，Insler，R.，和M.Anavi，“IP上的TDM”，正在进行的工作，2005年2月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[SIG] Rosen, E., Luo, W., Davie, B., and V. Radoaca, "Provisioning, Autodiscovery, and Signaling in L2VPNs", Work in Progress, September 2005.
[SIG]Rosen，E.，Luo，W.，Davie，B.，和V.Radoaca，“L2VPN中的资源调配、自动发现和信令”，正在进行的工作，2005年9月。
[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.
[RFC4385]Bryant，S.，Swallow，G.，Martini，L.，和D.McPherson，“用于MPLS PSN的伪线仿真边到边（PWE3）控制字”，RFC 43852006年2月。
Author's Address
作者地址
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112
卢卡·马蒂尼·思科系统公司，地址：科罗拉多州恩格尔伍德东尼科尔斯大道9155号400室，邮编：80112
EMail: lmartini@cisco.com
EMail: lmartini@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。