Network Working Group Z. Lin
Request for Comments: 3474 New York City Transit
Category: Informational D. Pendarakis
Tellium
March 2003
Network Working Group Z. Lin
Request for Comments: 3474 New York City Transit
Category: Informational D. Pendarakis
Tellium
March 2003
Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON)
通用多协议标签交换（GMPLS）资源预留协议IANA分配文件-自动交换光网络（ASON）的流量工程（RSVP-TE）使用和扩展
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
The Generalized MultiProtocol Label Switching (GMPLS) suite of protocol specifications has been defined to provide support for different technologies as well as different applications. These include support for requesting TDM connections based on Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) as well as Optical Transport Networks (OTNs).
定义了通用多协议标签交换（GMPLS）协议规范套件，以支持不同的技术和不同的应用。其中包括支持基于同步光网络/同步数字体系（SONET/SDH）以及光传输网络（OTN）请求TDM连接。
This document concentrates on the signaling aspects of the GMPLS suite of protocols, specifically GMPLS signaling using Resource Reservation Protocol - Traffic Engineering (RSVP-TE). It proposes additional extensions to these signaling protocols to support the capabilities of an ASON network.
本文档集中于GMPLS协议套件的信令方面，特别是使用资源预留协议-流量工程（RSVP-TE）的GMPLS信令。它提出了对这些信令协议的额外扩展，以支持ASON网络的功能。
This document proposes appropriate extensions towards the resolution of additional requirements identified and communicated by the ITU-T Study Group 15 in support of ITU's ASON standardization effort.
本文件建议适当扩展，以解决ITU-T研究组15为支持ITU ASON标准化工作而确定和传达的额外要求。
Table of Contents
目录
1. Conventions used in this document...............................3
2. Introduction....................................................3
3. Support for Soft Permanent Connection...........................3
4. Support for Call................................................4
4.1 Call Identifier and Call Capability........................4
4.1.1 Call Identifier.....................................4
4.1.2 Call Capability.....................................7
4.2 What Does Current GMPLS Provide............................7
4.3 Support for Call and Connection............................7
4.3.1 Processing Rules....................................8
4.3.2 Modification to Path Message........................8
4.3.3 Modification to Resv Message........................9
4.3.4 Modification to PathTear Message....................9
4.3.5 Modification to PathErr Message....................10
4.3.6 Modification to Notify Message.....................10
5. Support For Behaviors during Control Plane Failures...........11
6. Support For Label Usage.......................................12
7. Support for UNI and E-NNI Signaling Session...................13
8. Additional Error Cases........................................14
9. Optional Extensions for Supporting
Complete Separation of Call and Connection....................15
9.1 Call Capability.........;.................................15
9.2 Complete Separation of Call and
Connection (RSVP-TE Extensions)...........................16
9.2.1 Modification to Path...............................16
9.2.2 Modification to Resv...............................17
9.2.3 Modification to PathTear...........................18
9.2.4 Modification to PathErr............................18
9.2.5 Modification to Notify.............................18
10. Security Considerations.......................................19
11. IANA Considerations...........................................19
11.1 Assignment of New Messages...............................19
11.2 Assignment of New Objects and Sub-Objects................19
11.3 Assignment of New C-Types................................20
11.4 Assignment of New Error Code/Values......................20
12. Acknowledgements..............................................20
13. References....................................................21
13.1 Normative References.....................................21
13.2 Informative References...................................22
14. Intellectual Property.........................................23
15. Contributors Contact Information..............................24
16. Authors' Addresses............................................24
17. Full Copyright Statement......................................25
1. Conventions used in this document...............................3
2. Introduction....................................................3
3. Support for Soft Permanent Connection...........................3
4. Support for Call................................................4
4.1 Call Identifier and Call Capability........................4
4.1.1 Call Identifier.....................................4
4.1.2 Call Capability.....................................7
4.2 What Does Current GMPLS Provide............................7
4.3 Support for Call and Connection............................7
4.3.1 Processing Rules....................................8
4.3.2 Modification to Path Message........................8
4.3.3 Modification to Resv Message........................9
4.3.4 Modification to PathTear Message....................9
4.3.5 Modification to PathErr Message....................10
4.3.6 Modification to Notify Message.....................10
5. Support For Behaviors during Control Plane Failures...........11
6. Support For Label Usage.......................................12
7. Support for UNI and E-NNI Signaling Session...................13
8. Additional Error Cases........................................14
9. Optional Extensions for Supporting
Complete Separation of Call and Connection....................15
9.1 Call Capability.........;.................................15
9.2 Complete Separation of Call and
Connection (RSVP-TE Extensions)...........................16
9.2.1 Modification to Path...............................16
9.2.2 Modification to Resv...............................17
9.2.3 Modification to PathTear...........................18
9.2.4 Modification to PathErr............................18
9.2.5 Modification to Notify.............................18
10. Security Considerations.......................................19
11. IANA Considerations...........................................19
11.1 Assignment of New Messages...............................19
11.2 Assignment of New Objects and Sub-Objects................19
11.3 Assignment of New C-Types................................20
11.4 Assignment of New Error Code/Values......................20
12. Acknowledgements..............................................20
13. References....................................................21
13.1 Normative References.....................................21
13.2 Informative References...................................22
14. Intellectual Property.........................................23
15. Contributors Contact Information..............................24
16. Authors' Addresses............................................24
17. Full Copyright Statement......................................25
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 BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
This document contains the extensions to GMPLS for ASON-compliant networks [G7713.2]. The requirements describing the need for these extensions are provided in [GMPLS-ASON] as well as [ASON-RQTS]. These include:
本文档包含针对ASON兼容网络的GMPLS扩展[G7713.2]。[GMPLS-ASON]和[ASON-RQTS]中提供了描述这些扩展需求的要求。这些措施包括：
- Support for call and connection separation - Support for soft permanent connection - Support for extended restart capabilities - Additional error codes/values to support these extensions
- 支持呼叫和连接分离-支持软永久连接-支持扩展重启功能-支持这些扩展的其他错误代码/值
This document concentrates on the signaling aspects of the GMPLS suite of protocols, specifically GMPLS signaling using RSVP-TE. It introduces extensions to GMPLS RSVP-TE to support the capabilities as specified in the above referenced documents. Specifically, this document uses the messages and objects defined by [RFC2205], [RFC2961], [RFC3209], [RFC3471], [RFC3473], [OIF-UNI1] and [RFC3476] as the basis for the GMPLS RSVP-TE protocol, with additional extensions defined in this document.
本文档集中于GMPLS协议套件的信令方面，特别是使用RSVP-TE的GMPLS信令。它引入了GMPLS RSVP-TE的扩展，以支持上述参考文件中规定的功能。具体而言，本文件使用[RFC2205]、[RFC2961]、[RFC3209]、[RFC3471]、[RFC3473]、[OIF-UNI1]和[RFC3476]定义的消息和对象作为GMPLS RSVP-TE协议的基础，并在本文件中定义了其他扩展。
In the scope of ASON, to support soft permanent connection (SPC) for RSVP-TE, one new sub-type for the GENERALIZED_UNI object is defined. The GENERALIZED_UNI object is defined in [RFC3476] and [OIF-UNI1]. This new sub-type has the same format and structure as the EGRESS_LABEL (the sub-type is the suggested value for the new sub-object):
在ASON范围内，为了支持RSVP-TE的软永久连接（SPC），定义了广义_-UNI对象的一个子类型。[RFC3476]和[OIF-UNI1]中定义了广义_UNI对象。此新子类型的格式和结构与出口标签相同（子类型是新子对象的建议值）：
- SPC_LABEL (Type=4, Sub-type=2)
- SPC_标签（类型=4，子类型=2）
The label association of the permanent ingress segment with the switched segment at the switched connection ingress node is a local policy matter (i.e., between the management system and the switched connection ingress node) and is thus beyond the scope of this document.
永久入口段与交换连接入口节点处的交换段的标签关联是一个本地策略问题（即，在管理系统和交换连接入口节点之间），因此超出了本文档的范围。
The processing of the SPC_LABEL sub-object follows that of the EGRESS_LABEL sub-object [OIF-UNI1]. Note that although the explicit label control described in [RFC3471] and [RFC3473] may provide a mechanism to support specifying the egress label in the context of supporting the GMPLS application, the SPC services support for the ASON model uses the GENERALIZED_UNI object for this extension to help align the model for both switched connection and soft permanent connection, as well as to use the service level and diversity attributes of the GENERALIZED_UNI object.
SPC_标签子对象的处理遵循出口_标签子对象[OIF-UNI1]的处理。注意，尽管[RFC3471]和[RFC3473]中描述的显式标签控制可以提供一种机制，以支持在支持GMPLS应用的上下文中指定出口标签，ASON模型的SPC服务支持使用此扩展的广义_UNI对象来帮助调整交换连接和软永久连接的模型，并使用广义_UNI对象的服务级别和多样性属性。
To support basic call capability (logical call/connection separation), a call identifier is introduced to the RSVP-TE message sets. This basic call capability helps introduce the call model; however, additional extensions may be needed to fully support the canonical call model (complete call/connection separation).
为了支持基本呼叫能力（逻辑呼叫/连接分离），RSVP-TE消息集引入了呼叫标识符。这种基本的呼叫功能有助于引入呼叫模型；但是，可能需要额外的扩展来完全支持规范调用模型（完全调用/连接分离）。
A Call identifier object is used in logical call/connection separation while both the Call identifier object and a Call capability object are used in complete call/connection separation.
调用标识符对象用于逻辑调用/连接分离，而调用标识符对象和调用能力对象用于完全调用/连接分离。
To identify a call, a new object is defined for RSVP-TE. The CALL_ID object carries the call identifier. The value is globally unique (the Class-num is the suggested value for the new object):
为了识别调用，为RSVP-TE定义了一个新对象。CALL_ID对象携带调用标识符。该值是全局唯一的（类num是新对象的建议值）：
CALL_ID (Class-num = 230)
调用ID（类编号=230）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |Class-Num (230)| C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call identifier |
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |Class-Num (230)| C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call identifier |
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the following C-types are defined:
其中定义了以下C类型：
- C-Type = 1 (operator specific): The call identifier contains an operator specific identifier.
- C-Type=1（特定于操作员）：呼叫标识符包含特定于操作员的标识符。
- C-Type = 2 (globally unique): The call identifier contains a globally unique part plus an operator specific identifier.
- C-Type=2（全局唯一）：呼叫标识符包含全局唯一部分加上特定于操作员的标识符。
The following structures are defined for the call identifier:
为调用标识符定义了以下结构：
- Call identifier: generic [Length*8-32]-bit identifier. The number of bits for a call identifier must be multiples of 32 bits, with a minimum size of 32 bits.
- 调用标识符：通用[Length*8-32]-位标识符。呼叫标识符的位数必须是32位的倍数，最小大小为32位。
The structure for the globally unique call identifier (to guarantee global uniqueness) is to concatenate a globally unique fixed ID (composed of country code, carrier code, unique access point code) with an operator specific ID (where the operator specific ID is composed of a source LSR address and a local identifier).
全局唯一呼叫标识符的结构（保证全局唯一性）是将全局唯一固定ID（由国家代码、载波代码、唯一接入点代码组成）与特定于运营商的ID（其中特定于运营商的ID由源LSR地址和本地标识符组成）连接起来。
Therefore, a generic CALL_ID with global uniqueness includes <global ID> (composed of <country code> plus <carrier code> plus <unique access point code>) and <operator specific ID> (composed of <source LSR address> plus <local identifier>). For a CALL_ID that only requires operator specific uniqueness, only the <operator specific ID> is needed, while for a CALL_ID that is required to be globally unique, both <global ID> and <operator specific ID> are needed.
因此，具有全局唯一性的通用呼叫ID包括<global ID>（由<country code>加<carrier code>加<unique access point code>组成）和<operator specific ID>（由<source LSR address>加<local identifier>组成）。对于只需要特定于操作员的唯一性的呼叫标识，只需要<operator specific ID>，而对于需要全局唯一性的呼叫标识，则需要<global ID>和<operator specific ID>。
The <global ID> shall consist of a three-character International Segment (the <country code>) and a twelve-character National Segment (the <carrier code> plus <unique access point code>). These characters shall be coded according to ITU-T Recommendation T.50. The International Segment (IS) field provides a 3 character ISO 3166 Geographic/Political Country Code. The country code shall be based on the three-character uppercase alphabetic ISO 3166 Country Code (e.g., USA, FRA).
<global ID>应包括一个三字符的国际段（国家代码）和一个十二字符的国家段（承运人代码+唯一接入点代码）。这些字符应根据ITU-T建议T.50进行编码。国际段（IS）字段提供3个字符的ISO 3166地理/政治国家代码。国家代码应基于三字符大写字母ISO 3166国家代码（例如，美国、FRA）。
National Segment (NS): The National Segment (NS) field consists of two sub-fields:
国家部分（NS）：国家部分（NS）字段由两个子字段组成：
- the first subfield contains the ITU Carrier Code - the second subfield contains a Unique Access Point Code.
- 第一个子字段包含ITU载波代码-第二个子字段包含唯一的接入点代码。
The ITU Carrier Code is a code assigned to a network operator/service provider, maintained by the ITU-T Telecommunication Service Bureauin association with Recommendation M.1400. This code consists of 1-6 left-justified alphabetic, or leading alphabetic followed by numeric, characters (bytes). If the code is less than 6 characters (bytes), it is padded with a trailing NULL to fill the subfield.
ITU载波代码是分配给网络运营商/服务提供商的代码，由ITU-T电信服务局根据建议M.1400维护。此代码由1-6个左对齐字母或前导字母后跟数字字符（字节）组成。如果代码少于6个字符（字节），则用尾随NULL填充子字段。
The Unique Access Point Code is a matter for the organization to which the country code and ITU carrier code have been assigned, provided that uniqueness is guaranteed. This code consists of 1-6 characters (bytes), trailing NULL, completing the 12-character National Segment. If the code is less than 6 characters, it is padded by a trailing NULL to fill the subfield.
唯一接入点代码由国家代码和国际电联载波代码分配给的组织负责，前提是保证唯一性。该代码由1-6个字符（字节）组成，尾随NULL，完成12个字符的国家段。如果代码少于6个字符，则用尾随NULL填充子字段。
Format of the National Segment
国家部分的格式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITU carrier code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITU carrie dode (cont) | Unique access point code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unique access point code (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITU carrier code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITU carrie dode (cont) | Unique access point code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unique access point code (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Call identifier field for C-Type = 1:
C-Type=1的调用标识符字段的格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |Class-Num (230)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Resv |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source LSR address |
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local identifier (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |Class-Num (230)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Resv |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source LSR address |
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local identifier (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Call identifier field for C-Type = 2:
C-Type=2的调用标识符字段的格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |Class-Num (230)| C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | IS (3 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| NS (12 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source LSR address |
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local identifier (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |Class-Num (230)| C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | IS (3 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| NS (12 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source LSR address |
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local identifier (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In both cases, a "Type" field is defined to indicate the type of format used for the source LSR address. The Type field has the following meaning: For Type=0x01, the source LSR address is 4 bytes For Type=0x02, the source LSR address is 16 bytes For Type=0x03, the source LSR address is 20 bytes For type=0x04, the source LSR address is 6 bytes For type=0x7f, the source LSR address has the length defined by the vendor
在这两种情况下，都定义了一个“类型”字段，以指示用于源LSR地址的格式类型。类型字段具有以下含义：对于类型=0x01，源LSR地址对于类型=0x02为4字节，源LSR地址对于类型=0x03为16字节，源LSR地址对于类型=0x04为20字节，源LSR地址对于类型=0x7f为6字节，源LSR地址的长度由供应商定义
Source LSR address: An address of the LSR controlled by the source network.
源LSR地址：由源网络控制的LSR地址。
Local identifier: A 64-bit identifier that remains constant over the life of the call.
本地标识符：一个64位的标识符，在整个调用过程中保持不变。
Note that if the source LSR address is assigned from an address space that is globally unique, then the operator-specific CALL_ID may also be used to represent a globally unique CALL_ID. However, this is not guaranteed since the source LSR address may be assigned from an operator-specific address space.
请注意，如果源LSR地址是从全局唯一的地址空间分配的，则特定于运营商的CALL_ID也可用于表示全局唯一的CALL_ID。但是，这并不保证，因为源LSR地址可能是从特定于运营商的地址空间分配的。
The call capability feature is provided in Section 10. This is an optional capability. If supported, section 10 extensions must be followed.
第10节提供了呼叫能力功能。这是一个可选功能。如果支持，则必须遵循第10节扩展。
The signaling mechanism defined in [RFC2961], [RFC3209] and [RFC3471] supports automatic connection management; however it does not provide capability to support the call model. A call may be viewed as a special purpose connection that requires a different subset of information to be carried by the messages. This information is targeted to the call controller for the purpose of setting up a call/connection association.
[RFC2961]、[RFC3209]和[RFC3471]中定义的信令机制支持自动连接管理；但是，它不提供支持调用模型的功能。呼叫可以被视为一种特殊用途的连接，它要求消息携带不同的信息子集。此信息以呼叫控制器为目标，用于建立呼叫/连接关联。
Within the context of this document, every call (during steady state) may have one (or more) associated connections. A zero connection call is defined as a transient state, e.g., during a break-before-make restoration event.
在本文档的上下文中，每个调用（在稳定状态期间）可能有一个（或多个）关联连接。零连接调用被定义为一种瞬态，例如，在接通恢复事件之前的中断期间。
In the scope of ASON, to support a logical call/connection separation, a new call identifier is needed as described above. The new GENERALIZED_UNI object is carried by the Path message. The new CALL_ID object is carried by the Path, Resv, PathTear, PathErr, and Notify messages. The ResvConf message is left unmodified. The CALL_ID object (along with other objects associated with a call, e.g., GENERALIZED_UNI) is processed by the call controller, while other objects included in these messages are processed by the connection controller as described in [RFC3473]. Processing of the CALL_ID (and related) object is described in this document.
在ASON的范围内，为了支持逻辑呼叫/连接分离，如上所述，需要一个新的呼叫标识符。新的广义_UNI对象由路径消息携带。新的CALL_ID对象由Path、Resv、pathrear、PathErr和Notify消息携带。ResvConf消息保持不变。CALL_ID对象（以及与呼叫相关的其他对象，例如，广义_UNI）由呼叫控制器处理，而这些消息中包含的其他对象由连接控制器处理，如[RFC3473]中所述。本文档描述了CALL_ID（及相关）对象的处理。
Note: unmodified RSVP message formats are not listed below.
注意：下面未列出未修改的RSVP消息格式。
The following processing rules are applicable for call capability:
以下处理规则适用于呼叫能力：
- For initial calls, the source user MUST set the CALL_ID's C-Type and call identifier value to all-zeros. - For a new call request, the first network node sets the appropriate C-type and value for the CALL_ID. - For an existing call (in case CALL_ID is non-zero) the first network node verifies existence of the call.
- 对于初始呼叫，源用户必须将呼叫ID的C-Type和呼叫标识符值设置为全零。-对于新呼叫请求，第一个网络节点为呼叫标识设置适当的C类型和值。-对于现有呼叫（如果呼叫标识非零），第一个网络节点验证呼叫的存在。
- The CALL_ID object on all messages MUST be sent from the ingress call controller to egress call controller by all other (intermediate) controllers without alteration. Indeed, the Class-Num is chosen such that a node which does not support ASON extensions to GMPLS forwards the object unmodified (value in the range 11bbbbbb). - The destination user/client receiving the request uses the CALL_ID value as a reference to the requested call between the source user and itself. Subsequent actions related to the call uses the CALL_ID as the reference identifier.
- 所有消息上的CALL_ID对象必须由所有其他（中间）控制器从入口呼叫控制器发送到出口呼叫控制器，而不进行更改。实际上，类Num的选择使得不支持到GMPLS的ASON扩展的节点在未修改的情况下转发对象（值在11bbbb范围内）接收请求的目标用户/客户端使用CALL_ID值作为源用户与自身之间请求的调用的引用。与调用相关的后续操作使用调用ID作为引用标识符。
<Path Message> ::= <Common Header>
[ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION>
<RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <CALL_ID> ]
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <GENERALIZED_UNI> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
<Path Message> ::= <Common Header>
[ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION>
<RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <CALL_ID> ]
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <GENERALIZED_UNI> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
The format of the sender descriptor for unidirectional LSPs is not modified by this document.
本文档不修改单向LSP的发送方描述符格式。
The format of the sender descriptor for bidirectional LSPs is not modified by this document.
本文档不修改双向LSP的发送方描述符的格式。
Note that although the GENERALIZED_UNI and CALL_ID objects are optional for GMPLS signaling, these objects are mandatory for ASON-compliant networks, i.e., the Path message MUST include both GENERALIZED_UNI and CALL_ID objects.
注意，尽管通用_UNI和CALL_ID对象对于GMPLS信令是可选的，但是这些对象对于ASON兼容网络是必需的，即路径消息必须同时包括通用_UNI和CALL_ID对象。
<Resv Message> ::= <Common Header>
[ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION>
<RSVP_HOP>
<TIME_VALUES>
[ <CALL_ID> ]
[ <RESV_CONFIRM> ]
<SCOPE>
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<STYLE>
<flow descriptor list>
<Resv Message> ::= <Common Header>
[ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION>
<RSVP_HOP>
<TIME_VALUES>
[ <CALL_ID> ]
[ <RESV_CONFIRM> ]
<SCOPE>
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<STYLE>
<flow descriptor list>
<flow descriptor list> is not modified by this document.
<flow descriptor list>未被本文档修改。
Note that although the CALL_ID object is optional for GMPLS signaling, this object is mandatory for ASON-compliant networks, i.e., the Resv message MUST include the CALL_ID object.
注意，尽管CALL_ID对象对于GMPLS信令是可选的，但是对于ASON兼容网络，该对象是必需的，即，Resv消息必须包括CALL_ID对象。
<PathTear Message> ::= <Common Header>
[ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION>
<RSVP_HOP>
[ <CALL_ID> ]
[ <sender descriptor> ]
<PathTear Message> ::= <Common Header>
[ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION>
<RSVP_HOP>
[ <CALL_ID> ]
[ <sender descriptor> ]
<sender descriptor> ::= (see earlier definition)
<sender descriptor> ::= (see earlier definition)
Note that although the CALL_ID object is optional for GMPLS signaling, this object is mandatory for ASON-compliant networks, i.e., the PathTear message MUST include the CALL_ID object.
注意，尽管CALL_ID对象对于GMPLS信令是可选的，但对于ASON兼容网络，该对象是必需的，即Path催泪消息必须包括CALL_ID对象。
<PathErr Message> ::= <Common Header>
[ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION>
[ <CALL_ID> ]
<ERROR_SPEC>
[ <ACCEPTABLE_LABEL_SET> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
<PathErr Message> ::= <Common Header>
[ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION>
[ <CALL_ID> ]
<ERROR_SPEC>
[ <ACCEPTABLE_LABEL_SET> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
<sender descriptor> ::= (see earlier definition)
<sender descriptor> ::= (see earlier definition)
Note that although the CALL_ID object is optional for GMPLS signaling, this object is mandatory for ASON-compliant networks, i.e., the PathErr message MUST include the CALL_ID object.
请注意，尽管CALL_ID对象对于GMPLS信令是可选的，但对于符合ASON的网络，该对象是必需的，即PathErr消息必须包含CALL_ID对象。
Note that this message may include sessions belonging to several calls.
请注意，此消息可能包括属于多个呼叫的会话。
<Notify message> ::= <Common Header>
[<INTEGRITY>]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<ERROR_SPEC>
<notify session list>
<Notify message> ::= <Common Header>
[<INTEGRITY>]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<ERROR_SPEC>
<notify session list>
<notify session list> ::=
[ <notify session list> ]
<upstream notify session> |
<downstream notify session>
<notify session list> ::=
[ <notify session list> ]
<upstream notify session> |
<downstream notify session>
<upstream notify session> ::= <SESSION>
[ <CALL_ID> ]
[ <ADMIN_STATUS> ]
[<POLICY_DATA>...]
<sender descriptor>
<upstream notify session> ::= <SESSION>
[ <CALL_ID> ]
[ <ADMIN_STATUS> ]
[<POLICY_DATA>...]
<sender descriptor>
<downstream notify session> ::= <SESSION>
[ <CALL_ID> ]
[<POLICY_DATA>...]
<flow descriptor list descriptor>
<downstream notify session> ::= <SESSION>
[ <CALL_ID> ]
[<POLICY_DATA>...]
<flow descriptor list descriptor>
Note that although the CALL_ID object is optional for GMPLS signaling, this object is mandatory for ASON-compliant networks, i.e., the Notify message MUST include the CALL_ID object.
请注意，尽管CALL_ID对象对于GMPLS信令是可选的，但对于ASON兼容网络，该对象是必需的，即Notify消息必须包括CALL_ID对象。
Various types of control plane failures may occur within the network. These failures may impact the control plane as well as the data plane (e.g., in a SDH/SONET network if the control plane transport uses the DCC and a fiber cut occurs, then both the control plane signaling channel and the transport plane connection fails). As described in [RFC3473], current GMPLS restart mechanisms allows support to handle all of these different scenarios, and thus no additional extensions are required.
网络中可能发生各种类型的控制平面故障。这些故障可能会影响控制平面和数据平面（例如，在SDH/SONET网络中，如果控制平面传输使用DCC且发生光纤切断，则控制平面信令信道和传输平面连接都会发生故障）。如[RFC3473]所述，当前的GMPLS重启机制允许支持处理所有这些不同的场景，因此不需要额外的扩展。
In the scope of the ASON model, several procedures may take place in order to support the following control plane behaviors (as per [G7713] and [IPO-RQTS]):
在ASON模型的范围内，为了支持以下控制平面行为（根据[G7713]和[IPO-RQTS]），可能会进行一些程序：
- A control plane node SHOULD provide capability for persistent storage of call and connection state information. This capability allows each control plane node to recover the states of calls/connections after recovery from a signaling controller entity failure/reboot (or loss of local FSM state). Note that although the restart mechanism allows neighbor control plane nodes to automatically recover (and thus infer) the states of calls/connections, this mechanism can also be used for verification of neighbor states, while the persistent storage provides the local recovery of lost state. In this case, per [RFC3473], if during the Hello synchronization the restarting node determines that a neighbor does not support state recovery (i.e., local state recovery only), and the restarting node maintains its state on a per neighbor basis, the restarting node should immediately consider the Recovery as completed. - A control plane node detecting a failure of all control channels between a pair of nodes SHOULD request an external controller (e.g., the management system) for further instructions. The default behavior is to enter into self-refresh mode (i.e., preservation) for the local call/connection states. As an example, possible external instructions may be to remain in self-refresh mode, or to release local states for certain connections. Specific details are beyond the scope of this document. - A control plane node detecting that one (or more) connections cannot be re-synchronized with its neighbor (e.g., due to different states for the call/connection) SHOULD request an external controller (e.g., the management system) for further instructions on how to handle the non-synchronized connection. As an example, possible instructions may be to maintain the current
- 控制平面节点应提供持久存储呼叫和连接状态信息的能力。此功能允许每个控制平面节点在从信令控制器实体故障/重新启动（或本地FSM状态丢失）恢复后恢复呼叫/连接状态。请注意，尽管重启机制允许邻居控制平面节点自动恢复（从而推断）调用/连接的状态，但此机制也可用于验证邻居状态，而持久性存储提供丢失状态的本地恢复。在这种情况下，每一个[RCFC733]，如果在hello同步中，重新启动节点确定邻居不支持状态恢复（即，仅本地状态恢复），并且重新启动节点保持其状态在每个邻居的基础上，重新启动节点应该立即考虑恢复完成。检测到一对节点之间的所有控制通道故障的控制平面节点应向外部控制器（例如，管理系统）请求进一步指示。默认行为是进入本地呼叫/连接状态的自刷新模式（即保存）。例如，可能的外部指令可能是保持自刷新模式，或释放某些连接的本地状态。具体细节超出了本文件的范围。-检测到一个（或多个）连接无法与其邻居重新同步（例如，由于呼叫/连接的不同状态）的控制平面节点应请求外部控制器（例如，管理系统）获取关于如何处理非同步连接的进一步指示。例如，可能的指示可能是保持当前的
local connection states. Specifics of the interactions between the control plane and management plane are beyond the scope of this document. - A control plane node (after recovering from node failure) may lose information on forwarding adjacencies. In this case the control plane node SHOULD request an external controller (e.g., the management system) for information to recover the forwarding adjacency information. Specifics of the interactions between the control plane and management plane are beyond the scope of this document.
本地连接状态。控制平面和管理平面之间的交互细节超出了本文件的范围。-控制平面节点（从节点故障恢复后）可能会丢失有关转发邻接的信息。在这种情况下，控制平面节点应请求外部控制器（例如，管理系统）提供信息，以恢复转发邻接信息。控制平面和管理平面之间的交互细节超出了本文件的范围。
Labels are defined in GMPLS to provide information on the resources used for a particular connection. The labels may range from specifying a particular timeslot, or a particular wavelength, to a particular port/fiber. In the context of the automatic switched optical network, the value of a label may not be consistently the same across a link. For example, the figure below illustrates the case where two GMPLS/ASON-enabled nodes (A and Z) are interconnected across two non-GMPLS/ASON-enabled nodes (B and C; i.e., nodes B and C do not support the ASON capability), where these nodes are all SDH/SONET nodes providing, e.g., a VC-4 service.
GMPLS中定义了标签，以提供特定连接所用资源的信息。标签的范围从指定特定时隙或特定波长到特定端口/光纤。在自动交换光网络的上下文中，标签的值在链路上可能不一致。例如，下图说明了两个启用GMPLS/ASON的节点（A和Z）在两个未启用GMPLS/ASON的节点（B和C；即节点B和C不支持ASON功能）之间互连的情况，其中这些节点都是提供例如VC-4服务的SDH/SONET节点。
+-----+ +-----+
| | +---+ +---+ | |
| A |---| B |---| C |---| Z |
| | +---+ +---+ | |
+-----+ +-----+
+-----+ +-----+
| | +---+ +---+ | |
| A |---| B |---| C |---| Z |
| | +---+ +---+ | |
+-----+ +-----+
Labels have an associated structure imposed on them for local use based on [GMPLS-SDHSONET] and [GMPLS-OTN]. Once the local label is transmitted across an interface to its neighboring control plane node, the structure of the local label may not be significant to the neighbor node since the association between the local and the remote label may not necessarily be the same. This issue does not present a problem in a simple point-to-point connection between two control plane-enabled nodes where the timeslots are mapped 1:1 across the interface. However, in the scope of the ASON, once a non-GMPLS capable sub-network is introduced between these nodes (as in the above figure, where the sub-network provides re-arrangement capability for the timeslots) label scoping may become an issue.
标签具有基于[GMPLS-SDHSONET]和[GMPLS-OTN]的本地使用的相关结构。一旦本地标签通过接口传输到其相邻的控制平面节点，本地标签的结构对于相邻节点可能不重要，因为本地标签和远程标签之间的关联不一定相同。在启用控制平面的两个节点之间的简单点对点连接中，此问题并不存在，其中时间段在接口上以1:1的比例映射。然而，在ASON的范围内，一旦在这些节点之间引入不支持GMPLS的子网（如上图所示，其中子网为时隙提供重新安排能力），标签范围可能成为问题。
In this context, there is an implicit assumption that the data plane connections between the GMPLS capable edges already exist prior to any connection request. For instance node A's outgoing VC-4's timeslot #1 (with SUKLM label=[1,0,0,0,0]) as defined in [GMPLS-SONETSDH]) may be mapped onto node B's outgoing VC-4's timeslot #6
在这种情况下，有一个隐含的假设，即在任何连接请求之前，支持GMPLS的边缘之间的数据平面连接已经存在。例如，[GMPLS-SONETSDH]中定义的节点A的传出VC-4的时隙#1（SUKLM标签为[1,0,0,0]）可以映射到节点B的传出VC-4的时隙#6
(label=[6,0,0,0,0]) may be mapped onto node C's outgoing VC-4's timeslot #4 (label=[4,0,0,0,0]). Thus by the time node Z receives the request from node A with label=[1,0,0,0,0], the node Z's local label and the timeslot no longer corresponds to the received label and timeslot information.
（标签=[6,0,0,0,0]）可以映射到节点C的传出VC-4的时隙4（标签=[4,0,0,0]）。因此，当节点Z从节点A接收到标签为[1,0,0,0,0]的请求时，节点Z的本地标签和时隙不再对应于接收到的标签和时隙信息。
As such to support the general case, the scope of the label value is considered local to a control plane node. A label association function can be used by the control plane node to map the received (remote) label into a locally significant label. The information necessary to allow mapping from a received label value to a locally significant label value may be derived in several ways:
因此，为了支持一般情况，标签值的范围被视为控制平面节点的局部范围。控制平面节点可以使用标签关联功能将接收到的（远程）标签映射为本地有效标签。允许从接收到的标签值映射到本地有效标签值所需的信息可以通过几种方式导出：
- Via manual provisioning of the label association - Via discovery of the label association
- 通过手动设置标签关联-通过发现标签关联
Either method may be used. In the case of dynamic association, this implies that the discovery mechanism operates at the timeslot/label level before the connection request is processed at the ingress node. Note that in the simple case where two nodes are directly connected, no association may be necessary. In such instances, the label association function provides a one-to-one mapping of the received local label values.
两种方法均可使用。在动态关联的情况下，这意味着在入口节点处理连接请求之前，发现机制在时隙/标签级别运行。注意，在两个节点直接连接的简单情况下，可能不需要关联。在这种情况下，标签关联函数提供接收到的本地标签值的一对一映射。
[RFC3476] defines a UNI IPv4 SESSION object used to support the UNI signaling when IPv4 addressing is used. This document introduces three new extensions. These extensions specify support for the IPv4 and IPv6 E-NNI session and IPv6 UNI session. These C-Types are introduced to allow for easier identification of messages as regular GMPLS messages, UNI messages, or E-NNI messages. This is particularly useful if a single interface is used to support multiple service requests.
[RFC3476]定义使用IPv4寻址时用于支持UNI信令的UNI IPv4会话对象。本文档介绍了三个新的扩展。这些扩展指定了对IPv4和IPv6 E-NNI会话以及IPv6 UNI会话的支持。引入这些C类型是为了更容易地将消息识别为常规GMPLS消息、UNI消息或E-NNI消息。如果使用一个接口来支持多个服务请求，这一点尤其有用。
Extensions to SESSION object (Class-num = 1):
- C-Type = 12: UNI_IPv6 SESSION object
- C-TYPE = 15: ENNI_IPv4 SESSION object
- C-Type = 16: ENNI_IPv6 SESSION object
Extensions to SESSION object (Class-num = 1):
- C-Type = 12: UNI_IPv6 SESSION object
- C-TYPE = 15: ENNI_IPv4 SESSION object
- C-Type = 16: ENNI_IPv6 SESSION object
The format of the SESSION object with C-Type = 15 is the same as that for the SESSION object with C-Type = 7. The format of the SESSION object with C-Type = 12 and 16 is the same as that for the SESSION object with C-Type = 8.
C-Type=15的会话对象的格式与C-Type=7的会话对象的格式相同。C-Type=12和16的会话对象的格式与C-Type=8的会话对象的格式相同。
The destination address field contains the address of the downstream controller processing the message. For the case of the E-NNI signaling interface (where eNNI-U represents the upstream controller
目标地址字段包含处理消息的下游控制器的地址。对于E-NNI信令接口（其中eNNI-U代表上游控制器
and eNNI-D represents the downstream controller) the destination address contains the address of eNNI-D. [OIF-UNI1] and [RFC3476] describes the content of the address for UNI_IPv4 SESSION object, which is also applicable for UNI_IPv6 SESSION object.
并且eNNI-D代表下游控制器）目标地址包含eNNI-D的地址[OIF-UNI1]，并且[RFC3476]描述了UNI_IPv4会话对象的地址内容，这也适用于UNI_IPv6会话对象。
In the scope of ASON, the following additional error cases are defined:
在ASON范围内，定义了以下额外的错误情况：
- Policy control failure: unauthorized source; this error is generated when the receiving node determines that a source user/client initiated request for service is unauthorized based on verification of the request (e.g., not part of a contracted service). This is defined in [RFC3476]. - Policy control failure: unauthorized destination; this error is generated when the receiving node determines that a destination user/client is unauthorized to be connected with a source user/client. This is defined in [RFC3476]. - Routing problem: diversity not available; this error is generated when a receiving node determines that the requested diversity cannot be provided (e.g., due to resource constraints). This is defined in [RFC3476]. - Routing problem: service level not available; this error is generated when a receiving node determines that the requested service level cannot be provided (e.g., due to resource constraints). This is defined in [RFC3476]. - Routing problem: invalid/unknown connection ID; this error is generated when a receiving node determines that the connection ID generated by the upstream node is not valid/unknown (e.g., does not meet the uniqueness property). Connection ID is defined in [OIF-UNI1]. - Routing problem: no route available toward source; this error is generated when a receiving node determines that there is no available route towards the source node (e.g., due to unavailability of resources). - Routing problem: unacceptable interface ID; this error is generated when a receiving node determines that the interface ID specified by the upstream node is unacceptable (e.g., due to resource contention). - Routing problem: invalid/unknown call ID; this error is generated when a receiving node determines that the call ID generated by the source user/client is invalid/unknown (e.g., does not meet the uniqueness property). - Routing problem: invalid SPC interface ID/label; this error is generated when a receiving node determines that the SPC interface ID (or label, or both interface ID and label) specified by the upstream node is unacceptable (e.g., due to resource contention).
- 策略控制失败：未经授权的源；当接收节点根据请求的验证确定源用户/客户端发起的服务请求是未经授权的（例如，不是合同服务的一部分）时，会生成此错误。这在[RFC3476]中有定义策略控制失败：未经授权的目的地；当接收节点确定目标用户/客户端未经授权与源用户/客户端连接时，会生成此错误。这在[RFC3476]中有定义路由问题：多样性不可用；当接收节点确定无法提供请求的分集（例如，由于资源限制）时，会生成此错误。这在[RFC3476]中有定义路由问题：服务级别不可用；当接收节点确定无法提供请求的服务级别（例如，由于资源限制）时，会生成此错误。这在[RFC3476]中有定义路由问题：连接ID无效/未知；当接收节点确定上游节点生成的连接ID无效/未知（例如，不满足唯一性属性）时，会生成此错误。连接ID在[OIF-UNI1]中定义路由问题：没有通向源的路由；当接收节点确定没有通向源节点的可用路由时（例如，由于资源不可用），会生成此错误路由问题：接口ID不可接受；当接收节点确定上游节点指定的接口ID不可接受时（例如，由于资源争用），会生成此错误路由问题：无效/未知呼叫ID；当接收节点确定源用户/客户端生成的调用ID无效/未知（例如，不满足唯一性属性）时，会生成此错误路由问题：SPC接口ID/标签无效；当接收节点确定上游节点指定的SPC接口ID（或标签，或接口ID和标签）不可接受时（例如，由于资源争用），会生成此错误。
9. Optional Extensions for Supporting Complete Separation of Call and Connection
9. 支持呼叫和连接完全分离的可选扩展
This section describes the optional and non-normative capability to support complete separation of call and connection. To support complete separation of call and connection, a call capability object is introduced. The capability described in this Appendix is meant to be an optional capability within the scope of the ASON specification. An implementation of the extensions defined in this document include support for complete separation of call and connection, defined in this section.
本节介绍支持完全分离呼叫和连接的可选和非标准功能。为了支持呼叫和连接的完全分离，引入了呼叫能力对象。本附录中描述的功能是ASON规范范围内的可选功能。本文档中定义的扩展的实现包括对本节中定义的呼叫和连接完全分离的支持。
A call capability is used to specify the capabilities supported for a call. For RSVP-TE a new CALL_OPS object is defined to be carried by the Path, Resv, PathTear, PathErr, and Notify messages. The CALL_OPS object also serves to differentiate the messages to indicate a "call-only" call. In the case for logical separation of call and connection, the CALL_OPS object is not needed.
调用功能用于指定调用支持的功能。对于RSVP-TE，新的CALL_OPS对象被定义为由Path、Resv、PATHTRARE、PathErr和Notify消息携带。CALL_OPS对象还用于区分消息以指示“仅呼叫”呼叫。在调用和连接逻辑分离的情况下，不需要call_OPS对象。
The CALL_OPS object is defined as follows (the Class-num is the suggested value for the new object):
CALL_OPS对象的定义如下（Class num是新对象的建议值）：
CALL_OPS (Class-num = 228, C-type = 1)
呼叫操作（类别编号=228，C类型=1）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |Class-Num (228)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Call ops flag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |Class-Num (228)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Call ops flag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Two flags are currently defined for the "call ops flag": 0x01: call without connection 0x02: synchronizing a call (for restart mechanism)
当前为“call ops flag”定义了两个标志：0x01：无连接调用0x02：同步调用（用于重启机制）
A complete separation of call and connection implies that a call (during steady state) may have zero (or more) associated connections. A zero connection call is a steady state, e.g., simply setting up the user end-point relationship prior to connection setup. The following modified messages are used to set up a call. Set up of a connection uses the messages defined in Section 5 above.
调用和连接的完全分离意味着一个调用（在稳定状态下）可能有零个（或更多）关联的连接。零连接调用是一种稳定状态，例如，只需在连接设置之前设置用户端点关系。以下修改的消息用于设置呼叫。连接设置使用上文第5节中定义的消息。
<Path Message> ::= <Common Header>
[ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION>
<RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
<CALL_OPS>
<CALL_ID>
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
<GENERALIZED_UNI>
[ <POLICY_DATA> ... ]
<sender descriptor>
<Path Message> ::= <Common Header>
[ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION>
<RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
<CALL_OPS>
<CALL_ID>
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
<GENERALIZED_UNI>
[ <POLICY_DATA> ... ]
<sender descriptor>
The format of the sender descriptor for unidirectional LSPs is:
单向LSP的发送方描述符格式为：
<sender descriptor> ::= <SENDER_TEMPLATE>
<SENDER_TSPEC>
[ <RECORD_ROUTE> ]
<sender descriptor> ::= <SENDER_TEMPLATE>
<SENDER_TSPEC>
[ <RECORD_ROUTE> ]
The format of the sender descriptor for bidirectional LSPs is:
双向LSP的发送方描述符格式为：
<sender descriptor> ::= <SENDER_TEMPLATE>
<SENDER_TSPEC>
[ <RECORD_ROUTE> ]
<UPSTREAM_LABEL>
<sender descriptor> ::= <SENDER_TEMPLATE>
<SENDER_TSPEC>
[ <RECORD_ROUTE> ]
<UPSTREAM_LABEL>
Note that LABEL_REQUEST, SENDER_TSPEC and UPSTREAM_LABEL are not required for a call; however these are mandatory objects. As such, for backwards compatibility purposes, processing of these objects for a call follows the following rules:
请注意，呼叫不需要标签\u请求、发送方\u TSPEC和上游\u标签；但是，这些是必需的对象。因此，为了向后兼容，调用这些对象的处理遵循以下规则：
- These objects are ignored upon receipt; however, a valid-formatted object (e.g., by using the received valid object in the transmitted message) must be included in the generated message.
- 这些对象在收到时被忽略；但是，生成的消息中必须包含有效的格式化对象（例如，通过在传输的消息中使用接收到的有效对象）。
<Resv Message> ::= <Common Header>
[ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION>
<RSVP_HOP>
<TIME_VALUES>
<CALL_OPS>
<CALL_ID>
[ <RESV_CONFIRM> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<STYLE>
<flow descriptor list>
<Resv Message> ::= <Common Header>
[ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION>
<RSVP_HOP>
<TIME_VALUES>
<CALL_OPS>
<CALL_ID>
[ <RESV_CONFIRM> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<STYLE>
<flow descriptor list>
<flow descriptor list> ::=
<FF flow descriptor list>
| <SE flow descriptor>
<flow descriptor list> ::=
<FF flow descriptor list>
| <SE flow descriptor>
<FF flow descriptor list> ::=
<FLOWSPEC>
<FILTER_SPEC>
[ <RECORD_ROUTE> ]
| <FF flow descriptor list>
<FF flow descriptor>
<FF flow descriptor> ::=
[ <FLOWSPEC> ]
<FILTER_SPEC>
[ <RECORD_ROUTE> ]
<FF flow descriptor list> ::=
<FLOWSPEC>
<FILTER_SPEC>
[ <RECORD_ROUTE> ]
| <FF flow descriptor list>
<FF flow descriptor>
<FF flow descriptor> ::=
[ <FLOWSPEC> ]
<FILTER_SPEC>
[ <RECORD_ROUTE> ]
<SE flow descriptor> ::=
<FLOWSPEC>
<SE filter spec list>
<SE filter spec list> ::=
<SE filter spec>
| <SE filter spec list>
<SE filter spec>
<SE filter spec> ::=
<FILTER_SPEC>
[ <RECORD_ROUTE> ]
<SE flow descriptor> ::=
<FLOWSPEC>
<SE filter spec list>
<SE filter spec list> ::=
<SE filter spec>
| <SE filter spec list>
<SE filter spec>
<SE filter spec> ::=
<FILTER_SPEC>
[ <RECORD_ROUTE> ]
Note that FILTER_SPEC and LABEL are not required for a call; however these are mandatory objects. As such, for backwards compatibility purposes, processing of these objects for a call follows the following rules:
注意，调用不需要过滤器规格和标签；但是，这些是必需的对象。因此，为了向后兼容，调用这些对象的处理遵循以下规则：
- These objects are ignored upon receipt; however, a valid-formatted object (e.g., by using the received valid object in the transmitted message) must be included in the generated message.
- 这些对象在收到时被忽略；但是，生成的消息中必须包含有效的格式化对象（例如，通过在传输的消息中使用接收到的有效对象）。
<PathTear Message> ::= <Common Header>
[ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION>
<RSVP_HOP>
<CALL_OPS>
<CALL_ID>
[ <sender descriptor> ]
<PathTear Message> ::= <Common Header>
[ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION>
<RSVP_HOP>
<CALL_OPS>
<CALL_ID>
[ <sender descriptor> ]
<sender descriptor> ::= (see earlier definition in this section)
<sender descriptor> ::= (see earlier definition in this section)
<PathErr Message> ::= <Common Header>
[ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION>
<CALL_OPS>
<CALL_ID>
<ERROR_SPEC>
[ <POLICY_DATA> ... ]
<sender descriptor>
<sender descriptor> ::= (see earlier definition in this section)
<PathErr Message> ::= <Common Header>
[ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION>
<CALL_OPS>
<CALL_ID>
<ERROR_SPEC>
[ <POLICY_DATA> ... ]
<sender descriptor>
<sender descriptor> ::= (see earlier definition in this section)
<Notify message> ::= <Common Header>
[<INTEGRITY>]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<ERROR_SPEC>
<notify session list>
<Notify message> ::= <Common Header>
[<INTEGRITY>]
[ [<MESSAGE_ID_ACK> |
<MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<ERROR_SPEC>
<notify session list>
<notify session list> ::=
[ <notify session list> ]
<upstream notify session> |
<downstream notify session>
<notify session list> ::=
[ <notify session list> ]
<upstream notify session> |
<downstream notify session>
<upstream notify session> ::= <SESSION>
<CALL_ID>
[ <ADMIN_STATUS> ]
[<POLICY_DATA>...]
<sender descriptor>
<upstream notify session> ::= <SESSION>
<CALL_ID>
[ <ADMIN_STATUS> ]
[<POLICY_DATA>...]
<sender descriptor>
<downstream notify session> ::= <SESSION>
<CALL_ID>
[<POLICY_DATA>...]
<flow descriptor list descriptor>
<downstream notify session> ::= <SESSION>
<CALL_ID>
[<POLICY_DATA>...]
<flow descriptor list descriptor>
This document introduces no new security considerations.
本文档没有引入新的安全注意事项。
There are multiple fields and values defined within this document. IANA administers the assignment of these class numbers in the FCFS space as shown in [see: http://www.iana.org/assignments/rsvp-parameters].
此文档中定义了多个字段和值。IANA管理FCFS空间中这些类别编号的分配，如所示[参见：http://www.iana.org/assignments/rsvp-parameters].
No new messages are defined to support the functions discussed in this document.
没有定义新消息来支持本文档中讨论的功能。
Two new objects are defined:
定义了两个新对象：
- CALL_ID (ASON); this object should be assigned an object identifier of the form 11bbbbbb. A suggested value is 230. Two C-types are defined for this object - C-Type = 1: Operator specific - C-Type = 2: Globally unique
- 呼叫识别码（ASON）；应为该对象分配一个11BBBB格式的对象标识符。建议值为230。为此对象定义了两个C类型-C类型=1:特定于运算符-C类型=2:全局唯一
For the Type field, there is no range restriction, and the entire range 0x00 to 0xff is open for assignment, with 0x00 to 0x7f assignment based on FCFS and 0x80 to 0xff assignment reserved for Private Use. The assignments are defined in this document:
对于类型字段，没有范围限制，整个范围0x00到0xff开放供分配，0x00到0x7f分配基于FCFS，0x80到0xff分配保留供私人使用。本文件中定义了分配：
- Type = 0x01: Source LSR address is 4-bytes - Type = 0x02: Source LSR address is 16-bytes - Type = 0x03: Source LSR address is 20-bytes - Type = 0x04: Source LSR address is 6-bytes - Type = 0x7f: the source LSR address has the length defined by the vendor - CALL_OPS (ASON); this object should be assigned an object identifier of the form 11bbbbbb. The value is 228. One C-type is defined for this object; the value is 1.
- Type=0x01:源LSR地址为4字节-Type=0x02:源LSR地址为16字节-Type=0x03:源LSR地址为20字节-Type=0x04:源LSR地址为6字节-Type=0x7f:源LSR地址的长度由供应商定义-调用操作（ASON）；应为该对象分配一个11BBBB格式的对象标识符。这个值是228。为此对象定义了一个C类型；该值为1。
One new sub-object is defined under the GENERALIZED_UNI object:
在广义_UNI对象下定义了一个子对象：
- SPC_LABEL; this sub-object is part of the GENERALIZED_UNI object, as a sub-type of the EGRESS_LABEL sub-object (which is Type=4). The value is sub-type=2.
- SPC_标签；此子对象是广义_UNI对象的一部分，作为出口标签子对象（类型=4）的子类型。该值为子类型=2。
Three new C-Types are defined for the SESSION object (Class-num = 1):
为会话对象定义了三个新的C类型（类num=1）：
- C-Type = 12 (ASON): UNI_IPv6 SESSION object - C-Type = 15 (ASON): ENNI_IPv4 SESSION object - C-Type = 16 (ASON): ENNI_IPv6 SESSION object
- C-Type=12（ASON）：UNI_IPv6会话对象-C-Type=15（ASON）：ENNI_IPv4会话对象-C-Type=16（ASON）：ENNI_IPv6会话对象
No new error codes are required. The following new error values are defined. Error code 24 is defined in [RFC3209].
不需要新的错误代码。定义了以下新的错误值。[RFC3209]中定义了错误代码24。
24/103 (ASON): No route available toward source
24/104 (ASON): Unacceptable interface ID
24/105 (ASON): Invalid/unknown call ID
24/106 (ASON): Invalid SPC interface ID/label
24/103 (ASON): No route available toward source
24/104 (ASON): Unacceptable interface ID
24/105 (ASON): Invalid/unknown call ID
24/106 (ASON): Invalid SPC interface ID/label
The authors would like to thank Osama Aboul-Magd, Jerry Ash, Sergio Belotti, Greg Bernstein, Adrian Farrel, Nic Larkin, Lyndon Ong, Dimitri Papadimitriou, Bala Rajagopalan, and Yangguang Xu for their comments and contributions to the document.
作者感谢Osama Aboul Magd、Jerry Ash、Sergio Belotti、Greg Bernstein、Adrian Farrel、Nic Larkin、Lyndon Ong、Dimitri Papadimitriou、Bala Rajagopalan和Yangguang Xu对本文件的评论和贡献。
[G8080] ITU-T Rec. G.8080/Y.1304, Architecture for the Automatically Switched Optical Network (ASON), November 2001.
[G8080]ITU-T Rec.G.8080/Y.1304，《自动交换光网络（ASON）体系结构》，2001年11月。
[G7713] ITU-T Rec. G.7713/Y.1704, Distributed Call and Connection Management (DCM), November 2001.
[G7713]ITU-T Rec.G.7713/Y.1704，分布式呼叫和连接管理（DCM），2001年11月。
[G7713.2] DCM Signalling Mechanisms Using GMPLS RSVP-TE, ITU-T G.7713.2, January 2003.
[G7713.2]使用GMPLS RSVP-TE的DCM信令机制，ITU-T G.7713.2，2003年1月。
[OIF-UNI1] UNI 1.0 Signaling Specification, The Optical
Internetworking Forum,
http://www.oiforum.com/public/UNI_1.0_ia.html
[OIF-UNI1] UNI 1.0 Signaling Specification, The Optical
Internetworking Forum,
http://www.oiforum.com/public/UNI_1.0_ia.html
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[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月。
[RFC2205] Braden, R., Editor, Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，编辑，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[RFC2961]Berger，L.，Gan，D.，Swallow，G.，Pan，P.，Tommasi，F.和S.Molendini，“RSVP刷新开销减少扩展”，RFC 29612001年4月。
[RFC3209] Awaduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awaduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (MPLS) - Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.，编辑，“通用多协议标签交换（MPLS）-信令功能描述”，RFC 3471，2003年1月。
[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (MPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，编辑，“通用多协议标签交换（MPLS）信令-资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC3476] Rajagopalan, R., "Label Distribution Protocol (LDP) and Resource ReserVation Protocol (RSVP) Extensions for Optical UNI Signaling", RFC 3476, March 2003.
[RFC3476]Rajagopalan，R.，“光UNI信令的标签分配协议（LDP）和资源预留协议（RSVP）扩展”，RFC 3476，2003年3月。
[ITU-LIAISE] http://www.ietf.org/IESG/LIAISON/ITU-OIF.html
[ITU-LIAISE] http://www.ietf.org/IESG/LIAISON/ITU-OIF.html
[G807] ITU-T Rec. G.807/Y.1301, Requirements For Automatic Switched Transport Networks (ASTN), July 2001
[G807]ITU-T Rec.G.807/Y.1301，《自动交换传输网络（ASTN）的要求》，2001年7月
[IPO-RQTS] Aboul-Magd, O., "Automatic Switched Optical Network (ASON) Architecture and Its Related Protocols", Work in Progress.
[IPO-RQTS]Aboul Magd，O，“自动交换光网络（ASON）架构及其相关协议”，正在进行中。
[GMPLS-ASON] Lin, Z., "Requirements for Generalized MPLS (GMPLS) Usage and Extensions For Automatically Switched Optical Network (ASON)", Work in Progress.
[GMPLS-ASON]Lin，Z，“自动交换光网络（ASON）的通用MPLS（GMPLS）使用和扩展要求”，正在进行中。
[ASON-RQTS] Xue, Y., "Carrier Optical Services Requirements", Work in Progress.
[ASON-RQTS]薛，Y，“载波光服务要求”，正在进行中。
[GMPLS-SDHSONET] Mannie, E., "GMPLS Extensions for SONET and SDH Control", Work in Progress.
[GMPLS-SDHSONET]Mannie，E.“SONET和SDH控制的GMPLS扩展”，正在进行中。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in RFC 2028. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见RFC 2028。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
Sergio Belotti Alcatel Via Trento 30, I-20059 Vimercate, Italy EMail: sergio.belotti@netit.alcatel.it
塞尔吉奥·贝洛蒂·阿尔卡特经意大利维梅卡特市特伦托30号I-20059电子邮件：塞尔吉奥。belotti@netit.alcatel.it
Nic Larkin Data Connection 100 Church Street, Enfield Middlesex EN2 6BQ, UK EMail: npl@dataconnection.com
Nic拉金数据连接100 Church Street，Enfield Middlesex EN2 6BQ，英国电子邮件：npl@dataconnection.com
Dimitri Papadimitriou Alcatel Francis Wellesplein 1, B-2018 Antwerpen, Belgium EMail: Dimitri.Papadimitriou@alcatel.be
Dimitri Papadimitriou Alcatel Francis Wellesplein 1，B-2018比利时安特卫普电子邮件：Dimitri。Papadimitriou@alcatel.be
Yangguang Xu Lucent 1600 Osgood St, Room 21-2A41 North Andover, MA 01845-1043 EMail: xuyg@lucent.com
阳光徐朗讯1600奥斯古德街21-2A41室北安多弗，马萨诸塞州01845-1043电子邮件：xuyg@lucent.com
Zhi-Wei Lin New York City Transit 2 Broadway, Room C3.25 New York, NY 10004
林志伟纽约市交通2号百老汇，纽约州纽约市C3.25室，邮编10004
EMail: zhiwlin@nyct.com
EMail: zhiwlin@nyct.com
Dimitrios Pendarakis Tellium 2 Crescent Place Oceanport, NJ 07757-0901
新泽西州海港新月广场2号Dimitrios Pendarakis Tellium，邮编：07757-0901
EMail: dpendarakis@tellium.com
EMail: dpendarakis@tellium.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。