Network Working Group L. Berger, Editor
Request for Comments: 3471 Movaz Networks
Category: Standards Track January 2003
Network Working Group L. Berger, Editor
Request for Comments: 3471 Movaz Networks
Category: Standards Track January 2003
Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description
通用多协议标签交换（GMPLS）信令功能描述
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes extensions to Multi-Protocol Label Switching (MPLS) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents.
本文档描述了支持通用MPLS所需的多协议标签交换（MPLS）信令的扩展。广义MPLS扩展了MPLS控制平面，以涵盖时分（例如，同步光网络和同步数字体系、SONET/SDH）、波长（光lambda）和空间交换（例如，输入端口或光纤到输出端口或光纤）。本文档介绍了扩展的功能描述。协议特定的格式和机制以及技术特定的细节在单独的文档中指定。
Table of Contents
目录
1. Introduction ............................................... 2
2. Overview .................................................. 3
3. Label Related Formats ..................................... 6
3.1 Generalized Label Request ............................... 6
3.2 Generalized Label ....................................... 11
3.3 Waveband Switching ...................................... 12
3.4 Suggested Label ......................................... 13
3.5 Label Set ............................................... 14
4. Bidirectional LSPs ......................................... 16
4.1 Required Information .................................... 17
4.2 Contention Resolution ................................... 17
5. Notification on Label Error ................................ 20
6. Explicit Label Control ..................................... 20
6.1 Required Information .................................... 21
1. Introduction ............................................... 2
2. Overview .................................................. 3
3. Label Related Formats ..................................... 6
3.1 Generalized Label Request ............................... 6
3.2 Generalized Label ....................................... 11
3.3 Waveband Switching ...................................... 12
3.4 Suggested Label ......................................... 13
3.5 Label Set ............................................... 14
4. Bidirectional LSPs ......................................... 16
4.1 Required Information .................................... 17
4.2 Contention Resolution ................................... 17
5. Notification on Label Error ................................ 20
6. Explicit Label Control ..................................... 20
6.1 Required Information .................................... 21
7. Protection Information ..................................... 21
7.1 Required Information .................................... 22
8. Administrative Status Information .......................... 23
8.1 Required Information .................................... 24
9. Control Channel Separation ................................. 25
9.1 Interface Identification ................................ 25
9.2 Fault Handling .......................................... 27
10. Acknowledgments ............................................ 27
11. Security Considerations .................................... 28
12. IANA Considerations ........................................ 28
13. Intellectual Property Considerations ....................... 29
14. References ................................................. 29
14.1 Normative References ................................... 29
14.2 Informative References ................................. 30
15. Contributors ............................................... 31
16. Editor's Address ........................................... 33
17. Full Copyright Statement ................................... 34
7. Protection Information ..................................... 21
7.1 Required Information .................................... 22
8. Administrative Status Information .......................... 23
8.1 Required Information .................................... 24
9. Control Channel Separation ................................. 25
9.1 Interface Identification ................................ 25
9.2 Fault Handling .......................................... 27
10. Acknowledgments ............................................ 27
11. Security Considerations .................................... 28
12. IANA Considerations ........................................ 28
13. Intellectual Property Considerations ....................... 29
14. References ................................................. 29
14.1 Normative References ................................... 29
14.2 Informative References ................................. 30
15. Contributors ............................................... 31
16. Editor's Address ........................................... 33
17. Full Copyright Statement ................................... 34
The Multiprotocol Label Switching (MPLS) architecture [RFC3031] has been defined to support the forwarding of data based on a label. In this architecture, Label Switching Routers (LSRs) were assumed to have a forwarding plane that is capable of (a) recognizing either packet or cell boundaries, and (b) being able to process either packet headers (for LSRs capable of recognizing packet boundaries) or cell headers (for LSRs capable of recognizing cell boundaries).
多协议标签交换（MPLS）体系结构[RFC3031]已定义为支持基于标签的数据转发。在该架构中，假设标签交换路由器（lsr）具有能够（a）识别分组或小区边界的转发平面，以及（b）能够处理分组报头（对于能够识别分组边界的lsr）或小区报头（对于能够识别小区边界的lsr）。
The original architecture has recently been extended to include LSRs whose forwarding plane recognizes neither packet, nor cell boundaries, and therefore, can't forward data based on the information carried in either packet or cell headers. Specifically, such LSRs include devices where the forwarding decision is based on time slots, wavelengths, or physical ports.
最初的体系结构最近被扩展到包括LSR，其转发平面既不识别分组，也不识别小区边界，因此不能基于分组或小区报头中携带的信息转发数据。具体地，此类lsr包括转发决策基于时隙、波长或物理端口的设备。
Given the above, LSRs, or more precisely interfaces on LSRs, can be subdivided into the following classes:
鉴于上述情况，LSR或更准确地说，LSR上的接口可细分为以下类别：
1. Interfaces that recognize packet/cell boundaries and can forward data based on the content of the packet/cell header. Examples include interfaces on routers that forward data based on the content of the "shim" header, interfaces on (Asynchronous Transfer Mode) ATM-LSRs that forward data based on the ATM VPI/VCI. Such interfaces are referred to as Packet-Switch Capable (PSC).
1. 识别数据包/小区边界并可根据数据包/小区报头的内容转发数据的接口。示例包括路由器上基于“垫片”报头内容转发数据的接口，以及（异步传输模式）ATM LSR上基于ATM VPI/VCI转发数据的接口。这种接口称为包交换能力（PSC）。
2. Interfaces that forward data based on the data's time slot in a repeating cycle. An example of such an interface is an interface on a SONET/SDH Cross-Connect. Such interfaces are referred to as Time-Division Multiplex Capable (TDM).
2. 根据重复周期中数据的时隙转发数据的接口。这种接口的一个例子是SONET/SDH交叉连接上的接口。这种接口称为时分多路复用（TDM）。
3. Interfaces that forward data based on the wavelength on which the data is received. An example of such an interface is an interface on an Optical Cross-Connect that can operate at the level of an individual wavelength. Such interfaces are referred to as Lambda Switch Capable (LSC).
3. 根据接收数据的波长转发数据的接口。这种接口的一个例子是光交叉连接上的接口，它可以在单个波长的水平上工作。这种接口称为Lambda交换机功能（LSC）。
4. Interfaces that forward data based on a position of the data in the real world physical spaces. An example of such an interface is an interface on an Optical Cross-Connect that can operate at the level of a single (or multiple) fibers. Such interfaces are referred to as Fiber-Switch Capable (FSC).
4. 根据数据在现实世界物理空间中的位置转发数据的接口。这种接口的一个例子是光交叉连接上的接口，它可以在单个（或多个）光纤的水平上运行。这种接口称为光纤交换机能力（FSC）。
Using the concept of nested Label Switched Paths (LSPs) allows the system to scale by building a forwarding hierarchy. At the top of this hierarchy are FSC interfaces, followed by LSC interfaces, followed by TDM interfaces, followed by PSC interfaces. This way, an LSP that starts and ends on a PSC interface can be nested (together with other LSPs) into an LSP that starts and ends on a TDM interface. This LSP, in turn, can be nested (together with other LSPs) into an LSP that starts and ends on an LSC interface, which in turn can be nested (together with other LSPs) into an LSP that starts and ends on a FSC interface. See [MPLS-HIERARCHY] for more information on LSP hierarchies.
使用嵌套标签交换路径（LSP）的概念，允许系统通过构建转发层次结构进行扩展。在这个层次结构的顶部是FSC接口，接着是LSC接口，接着是TDM接口，接着是PSC接口。这样，可以将在PSC接口上开始和结束的LSP（与其他LSP一起）嵌套到在TDM接口上开始和结束的LSP中。反过来，此LSP可以（与其他LSP一起）嵌套到LSC接口上开始和结束的LSP中，而LSP又可以（与其他LSP一起）嵌套到FSC接口上开始和结束的LSP中。有关LSP层次结构的更多信息，请参阅[MPLS-HIERARCHY]。
The establishment of LSPs that span only the first class of interfaces is defined in [RFC3036, RFC3212, RFC3209]. This document presents a functional description of the extensions needed to generalize the MPLS control plane to support each of the four classes of interfaces. Only signaling protocol independent formats and definitions are provided in this document. Protocol specific formats are defined in [RFC3473] and [RFC3472]. Technology specific details are outside the scope of this document and will be specified in technology specific documents, such as [GMPLS-SONET].
[RFC3036、RFC3212、RFC3209]中定义了仅跨第一类接口的LSP的建立。本文档介绍了将MPLS控制平面概括为支持四类接口中的每一类所需的扩展的功能描述。本文件仅提供与信令协议无关的格式和定义。[RFC3473]和[RFC3472]中定义了特定于协议的格式。技术特定细节不在本文件范围内，将在技术特定文件中规定，如[GMPLS-SONET]。
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]中所述进行解释。
Generalized MPLS differs from traditional MPLS in that it supports multiple types of switching, i.e., the addition of support for TDM, lambda, and fiber (port) switching. The support for the additional
广义MPLS与传统MPLS的不同之处在于它支持多种类型的交换，即增加了对TDM、lambda和光纤（端口）交换的支持。对附加条款的支持
types of switching has driven generalized MPLS to extend certain base functions of traditional MPLS and, in some cases, to add functionality. These changes and additions impact basic LSP properties, how labels are requested and communicated, the unidirectional nature of LSPs, how errors are propagated, and information provided for synchronizing the ingress and egress.
交换的类型促使广义MPLS扩展了传统MPLS的某些基本功能，并在某些情况下增加了功能。这些更改和添加会影响基本LSP属性、标签的请求和通信方式、LSP的单向性、错误的传播方式以及为同步入口和出口提供的信息。
In traditional MPLS Traffic Engineering, links traversed by an LSP can include an intermix of links with heterogeneous label encodings. For example, an LSP may span links between routers, links between routers and ATM-LSRs, and links between ATM-LSRs. Generalized MPLS extends this by including links where the label is encoded as a time slot, or a wavelength, or a position in the real world physical space. Just like with traditional MPLS TE, where not all LSRs are capable of recognizing (IP) packet boundaries (e.g., an ATM-LSR) in their forwarding plane, generalized MPLS includes support for LSRs that can't recognize (IP) packet boundaries in their forwarding plane. In traditional MPLS TE an LSP that carries IP has to start and end on a router. Generalized MPLS extends this by requiring an LSP to start and end on similar type of LSRs. Also, in generalized MPLS the type of a payload that can be carried by an LSP is extended to allow such payloads as SONET/SDH, or 1 or 10Gb Ethernet. These changes from traditional MPLS are reflected in how labels are requested and communicated in generalized MPLS, see Sections 3.1 and 3.2. A special case of Lambda switching, called Waveband switching is also described in Section 3.3.
在传统的MPLS流量工程中，LSP所穿越的链路可以包括具有异构标签编码的链路的混合。例如，LSP可以跨越路由器之间的链路、路由器和ATM lsr之间的链路以及ATM lsr之间的链路。广义MPLS通过将标签编码为时隙、波长或真实世界物理空间中的位置的链接扩展了这一点。与传统MPLS TE一样，并非所有LSR都能够识别其转发平面中的（IP）数据包边界（例如ATM-LSR），通用MPLS包括对无法识别其转发平面中的（IP）数据包边界的LSR的支持。在传统的MPLS TE中，承载IP的LSP必须在路由器上开始和结束。广义MPLS通过要求LSP在类似类型的LSR上开始和结束来扩展这一点。此外，在通用MPLS中，可以由LSP承载的有效负载类型被扩展以允许诸如SONET/SDH或1或10Gb以太网之类的有效负载。传统MPLS的这些变化反映在通用MPLS中标签的请求和通信方式上，见第3.1节和第3.2节。第3.3节还描述了一种特殊的Lambda开关，称为波段开关。
Another basic difference between traditional and non-PSC types of generalized MPLS LSPs, is that bandwidth allocation for an LSP can be performed only in discrete units, see Section 3.1.3. There are also likely to be (much) fewer labels on non-PSC links than on PSC links. Note that the use of Forwarding Adjacencies (FA), see [MPLS-HIERARCHY], provides a mechanism that may improve bandwidth utilization, when bandwidth allocation can be performed only in discrete units, as well as a mechanism to aggregate forwarding state, thus allowing the number of required labels to be reduced.
传统和非PSC类型的广义MPLS LSP之间的另一个基本区别是，LSP的带宽分配只能在离散单元中执行，见第3.1.3节。非PSC链接上的标签也可能（远）少于PSC链接上的标签。注意，转发邻接（FA）的使用（参见[MPLS-HIERARCHY]）提供了一种机制，当带宽分配只能在离散单元中执行时，该机制可以提高带宽利用率，以及一种聚合转发状态的机制，从而允许减少所需标签的数量。
Generalized MPLS allows for a label to be suggested by an upstream node, see Section 3.4. This suggestion may be overridden by a downstream node but, in some cases, at the cost of higher LSP setup time. The suggested label is valuable when establishing LSPs through certain kinds of optical equipment where there may be a lengthy (in electrical terms) delay in configuring the switching fabric. For example micro mirrors may have to be elevated or moved, and this physical motion and subsequent damping takes time. If the labels and hence switching fabric are configured in the reverse direction (the
通用MPLS允许上游节点建议标签，见第3.4节。此建议可能会被下游节点覆盖，但在某些情况下，会以较高的LSP设置时间为代价。当通过某些类型的光学设备建立LSP时，建议的标签很有价值，因为在配置交换结构时可能会有很长的（电气方面的）延迟。例如，微镜可能必须升高或移动，而这种物理运动和随后的阻尼需要时间。如果标签和交换结构的配置方向相反（
norm) the MAPPING/Resv message may need to be delayed by 10's of milliseconds per hop in order to establish a usable forwarding path. The suggested label is also valuable when recovering from nodal faults.
norm）映射/Resv消息可能需要每跳延迟10毫秒，以便建立可用的转发路径。当从节点故障中恢复时，建议的标签也很有价值。
Generalized MPLS extends on the notion of restricting the range of labels that may be selected by a downstream node, see Section 3.5. In generalized MPLS, an ingress or other upstream node may restrict the labels that may be used by an LSP along either a single hop or along the whole LSP path. This feature is driven from the optical domain where there are cases where wavelengths used by the path must be restricted either to a small subset of possible wavelengths, or to one specific wavelength. This requirement occurs because some equipment may only be able to generate a small set of the wavelengths that intermediate equipment may be able to switch, or because intermediate equipment may not be able to switch a wavelength at all, being only able to redirect it to a different fiber.
广义MPLS扩展了限制下游节点可能选择的标签范围的概念，见第3.5节。在通用MPLS中，入口或其他上游节点可以限制LSP沿着单个跳或整个LSP路径使用的标签。此功能是从光学领域驱动的，在某些情况下，路径使用的波长必须限制为可能波长的一小部分，或限制为一个特定波长。出现这种要求是因为一些设备可能只能产生中间设备可以切换的一小部分波长，或者因为中间设备可能根本无法切换波长，只能将其重定向到不同的光纤。
While traditional traffic engineered MPLS (and even LDP) are unidirectional, generalized MPLS supports the establishment of bidirectional LSPs, see Section 4. The need for bidirectional LSPs comes from non-PSC applications. There are multiple reasons why such LSPs are needed, particularly possible resource contention when allocating reciprocal LSPs via separate signaling sessions, and simplifying failure restoration procedures in the non-PSC case. Bidirectional LSPs also have the benefit of lower setup latency and lower number of messages required during setup.
虽然传统的流量工程MPLS（甚至LDP）是单向的，但广义MPLS支持建立双向LSP，见第4节。对双向LSP的需求来自非PSC应用程序。需要这样的LSP有多种原因，特别是在通过单独的信令会话分配互惠LSP时可能存在的资源争用，以及在非PSC情况下简化故障恢复过程。双向LSP还具有设置延迟较低和设置过程中所需消息数较少的优点。
Generalized MPLS supports the communication of a specific label to use on a specific interface, see Section 6. [RFC3473] also supports an RSVP specific mechanism for rapid failure notification.
通用MPLS支持在特定接口上使用特定标签的通信，见第6节。[RFC3473]还支持特定于RSVP的快速故障通知机制。
Generalized MPLS formalizes possible separation of control and data channels, see Section 9. Such support is particularly important to support technologies where control traffic cannot be sent in-band with the data traffic.
广义MPLS将控制通道和数据通道的可能分离形式化，见第9节。这种支持对于支持控制流量不能和数据流量一起在频带内发送的技术尤其重要。
Generalized MPLS also allows for the inclusion of technology specific parameters in signaling. The intent is for all technology specific parameters to be carried, when using RSVP, in the SENDER_TSPEC and other related objects, and when using CR-LDP, in the Traffic Parameters TLV. Technology specific formats will be defined on an as needed basis. For an example definition, see [GMPLS-SONET].
通用MPLS还允许在信令中包含特定于技术的参数。目的是在使用RSVP时，在发送方_TSPEC和其他相关对象中，以及在使用CR-LDP时，在流量参数TLV中，携带所有特定于技术的参数。将根据需要定义特定于技术的格式。有关示例定义，请参见[GMPLS-SONET]。
To deal with the widening scope of MPLS into the optical and time domain, several new forms of "label" are required. These new forms of label are collectively referred to as a "generalized label". A generalized label contains enough information to allow the receiving node to program its cross connect, regardless of the type of this cross connect, such that the ingress segments of the path are properly joined. This section defines a generalized label request, a generalized label, support for waveband switching, suggested label and label sets.
为了应对MPLS向光域和时域的扩展，需要几种新形式的“标签”。这些新形式的标签统称为“通用标签”。通用标签包含足够的信息，以允许接收节点对其交叉连接进行编程，而不管该交叉连接的类型如何，以便正确连接路径的入口段。本节定义了通用标签请求、通用标签、对波段切换的支持、建议的标签和标签集。
Note that since the nodes sending and receiving the new form of label know what kinds of link they are using, the generalized label does not contain a type field, instead the nodes are expected to know from context what type of label to expect.
请注意，由于发送和接收新形式标签的节点知道它们使用的链接类型，因此通用标签不包含类型字段，而是希望节点从上下文中知道所需的标签类型。
The Generalized Label Request supports communication of characteristics required to support the LSP being requested. These characteristics include LSP encoding and LSP payload. Note that these characteristics may be used by transit nodes, e.g., to support penultimate hop popping.
通用标签请求支持所需特征的通信，以支持所请求的LSP。这些特性包括LSP编码和LSP有效负载。请注意，这些特性可由传输节点使用，例如，用于支持倒数第二跳弹出。
The Generalized Label Request carries an LSP encoding parameter, called LSP Encoding Type. This parameter indicates the encoding type, e.g., SONET/SDH/GigE etc., that will be used with the data associated with the LSP. The LSP Encoding Type represents the nature of the LSP, and not the nature of the links that the LSP traverses. A link may support a set of encoding formats, where support means that a link is able to carry and switch a signal of one or more of these encoding formats depending on the resource availability and capacity of the link. For example, consider an LSP signaled with "lambda" encoding. It is expected that such an LSP would be supported with no electrical conversion and no knowledge of the modulation and speed by the transit nodes. Other formats normally require framing knowledge, and field parameters are broken into the framing type and speed as shown below.
通用标签请求携带一个称为LSP编码类型的LSP编码参数。此参数表示将与LSP相关数据一起使用的编码类型，例如SONET/SDH/GigE等。LSP编码类型表示LSP的性质，而不是LSP所经过的链路的性质。链路可以支持一组编码格式，其中支持意味着链路能够根据链路的资源可用性和容量携带和切换这些编码格式中的一种或多种的信号。例如，考虑用“lambda”编码表示的LSP。预计这样的LSP将在没有电转换和不知道传输节点的调制和速度的情况下得到支持。其他格式通常需要框架知识，字段参数分为框架类型和速度，如下所示。
The Generalized Label Request also indicates the type of switching that is being requested on a link. This field normally is consistent across all links of an LSP.
通用标签请求还指示链路上请求的交换类型。该字段通常在LSP的所有链路上保持一致。
The information carried in a Generalized Label Request is:
通用标签请求中包含的信息为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LSP Encoding Type: 8 bits
LSP编码类型：8位
Indicates the encoding of the LSP being requested. The following shows permitted values and their meaning:
指示正在请求的LSP的编码。以下显示了允许值及其含义：
Value Type
----- ----
1 Packet
2 Ethernet
3 ANSI/ETSI PDH
4 Reserved
5 SDH ITU-T G.707 / SONET ANSI T1.105
6 Reserved
7 Digital Wrapper
8 Lambda (photonic)
9 Fiber
10 Reserved
11 FiberChannel
Value Type
----- ----
1 Packet
2 Ethernet
3 ANSI/ETSI PDH
4 Reserved
5 SDH ITU-T G.707 / SONET ANSI T1.105
6 Reserved
7 Digital Wrapper
8 Lambda (photonic)
9 Fiber
10 Reserved
11 FiberChannel
The ANSI PDH and ETSI PDH types designate these respective networking technologies. DS1 and DS3 are examples of ANSI PDH LSPs. An E1 LSP would be ETSI PDH. The Lambda encoding type refers to an LSP that encompasses a whole wavelengths. The Fiber encoding type refers to an LSP that encompasses a whole fiber port.
ANSI PDH和ETSI PDH类型分别指定了这些网络技术。DS1和DS3是ANSI PDH LSP的示例。E1 LSP将是ETSI PDH。Lambda编码类型是指包含整个波长的LSP。光纤编码类型是指包含整个光纤端口的LSP。
Switching Type: 8 bits
开关类型：8位
Indicates the type of switching that should be performed on a particular link. This field is needed for links that advertise more than one type of switching capability. This field should map to one of the values advertised for the corresponding link in the routing Switching Capability Descriptor, see [GMPLS-RTG].
指示应在特定链路上执行的切换类型。此字段用于通告多种类型交换能力的链路。此字段应映射到路由交换能力描述符中相应链路的公布值之一，请参阅[GMPLS-RTG]。
The following are currently defined values:
以下是当前定义的值：
Value Type
----- ----
1 Packet-Switch Capable-1 (PSC-1)
2 Packet-Switch Capable-2 (PSC-2)
3 Packet-Switch Capable-3 (PSC-3)
4 Packet-Switch Capable-4 (PSC-4)
51 Layer-2 Switch Capable (L2SC)
100 Time-Division-Multiplex Capable (TDM)
150 Lambda-Switch Capable (LSC)
200 Fiber-Switch Capable (FSC)
Value Type
----- ----
1 Packet-Switch Capable-1 (PSC-1)
2 Packet-Switch Capable-2 (PSC-2)
3 Packet-Switch Capable-3 (PSC-3)
4 Packet-Switch Capable-4 (PSC-4)
51 Layer-2 Switch Capable (L2SC)
100 Time-Division-Multiplex Capable (TDM)
150 Lambda-Switch Capable (LSC)
200 Fiber-Switch Capable (FSC)
Generalized PID (G-PID): 16 bits
广义PID（G-PID）：16位
An identifier of the payload carried by an LSP, i.e., an identifier of the client layer of that LSP. This is used by the nodes at the endpoints of the LSP, and in some cases by the penultimate hop. Standard Ethertype values are used for packet and Ethernet LSPs; other values are:
LSP承载的有效载荷的标识符，即，该LSP的客户端层的标识符。这被LSP端点处的节点使用，并且在某些情况下被倒数第二个跃点使用。标准Ethertype值用于分组和以太网LSP；其他值包括：
Value Type Technology
----- ---- ----------
0 Unknown All
1 Reserved
2 Reserved
3 Reserved
4 Reserved
5 Asynchronous mapping of E4 SDH
6 Asynchronous mapping of DS3/T3 SDH
7 Asynchronous mapping of E3 SDH
8 Bit synchronous mapping of E3 SDH
9 Byte synchronous mapping of E3 SDH
10 Asynchronous mapping of DS2/T2 SDH
11 Bit synchronous mapping of DS2/T2 SDH
12 Reserved
13 Asynchronous mapping of E1 SDH
14 Byte synchronous mapping of E1 SDH
15 Byte synchronous mapping of 31 * DS0 SDH
16 Asynchronous mapping of DS1/T1 SDH
17 Bit synchronous mapping of DS1/T1 SDH
18 Byte synchronous mapping of DS1/T1 SDH
19 VC-11 in VC-12 SDH
20 Reserved
21 Reserved
22 DS1 SF Asynchronous SONET
23 DS1 ESF Asynchronous SONET
24 DS3 M23 Asynchronous SONET
25 DS3 C-Bit Parity Asynchronous SONET
26 VT/LOVC SDH
27 STS SPE/HOVC SDH
28 POS - No Scrambling, 16 bit CRC SDH
29 POS - No Scrambling, 32 bit CRC SDH
30 POS - Scrambling, 16 bit CRC SDH
31 POS - Scrambling, 32 bit CRC SDH
32 ATM mapping SDH
33 Ethernet SDH, Lambda, Fiber
34 SONET/SDH Lambda, Fiber
35 Reserved (SONET deprecated) Lambda, Fiber
36 Digital Wrapper Lambda, Fiber
37 Lambda Fiber
Value Type Technology
----- ---- ----------
0 Unknown All
1 Reserved
2 Reserved
3 Reserved
4 Reserved
5 Asynchronous mapping of E4 SDH
6 Asynchronous mapping of DS3/T3 SDH
7 Asynchronous mapping of E3 SDH
8 Bit synchronous mapping of E3 SDH
9 Byte synchronous mapping of E3 SDH
10 Asynchronous mapping of DS2/T2 SDH
11 Bit synchronous mapping of DS2/T2 SDH
12 Reserved
13 Asynchronous mapping of E1 SDH
14 Byte synchronous mapping of E1 SDH
15 Byte synchronous mapping of 31 * DS0 SDH
16 Asynchronous mapping of DS1/T1 SDH
17 Bit synchronous mapping of DS1/T1 SDH
18 Byte synchronous mapping of DS1/T1 SDH
19 VC-11 in VC-12 SDH
20 Reserved
21 Reserved
22 DS1 SF Asynchronous SONET
23 DS1 ESF Asynchronous SONET
24 DS3 M23 Asynchronous SONET
25 DS3 C-Bit Parity Asynchronous SONET
26 VT/LOVC SDH
27 STS SPE/HOVC SDH
28 POS - No Scrambling, 16 bit CRC SDH
29 POS - No Scrambling, 32 bit CRC SDH
30 POS - Scrambling, 16 bit CRC SDH
31 POS - Scrambling, 32 bit CRC SDH
32 ATM mapping SDH
33 Ethernet SDH, Lambda, Fiber
34 SONET/SDH Lambda, Fiber
35 Reserved (SONET deprecated) Lambda, Fiber
36 Digital Wrapper Lambda, Fiber
37 Lambda Fiber
38 ANSI/ETSI PDH SDH 39 Reserved SDH 40 Link Access Protocol SDH SDH (LAPS - X.85 and X.86) 41 FDDI SDH, Lambda, Fiber 42 DQDB (ETSI ETS 300 216) SDH 43 FiberChannel-3 (Services) FiberChannel 44 HDLC SDH 45 Ethernet V2/DIX (only) SDH, Lambda, Fiber 46 Ethernet 802.3 (only) SDH, Lambda, Fiber
38 ANSI/ETSI PDH SDH 39保留SDH 40链路接入协议SDH SDH（LAPS-X.85和X.86）41 FDDI SDH，Lambda，光纤42 DQDB（ETSI ETS 300 216）SDH 43光纤通道-3（服务）光纤通道44 HDLC SDH 45以太网V2/DIX（仅）SDH，Lambda，光纤46以太网802.3（仅）SDH，Lambda，光纤
Bandwidth encodings are carried in 32 bit number in IEEE floating point format (the unit is bytes per second). For non-packet LSPs, it is useful to define discrete values to identify the bandwidth of the LSP. Some typical values for the requested bandwidth are enumerated below. (These values are guidelines.) Additional values will be defined as needed. Bandwidth encoding values are carried in a per protocol specific manner, see [RFC3473] and [RFC3472].
带宽编码以32位的IEEE浮点格式进行（单位为每秒字节数）。对于非分组LSP，定义离散值以识别LSP的带宽是有用的。下面列举了请求带宽的一些典型值。（这些值是指导原则。）将根据需要定义附加值。带宽编码值以特定于协议的方式进行，请参见[RFC3473]和[RFC3472]。
Signal Type (Bit-rate) Value (Bytes/Sec)
(IEEE Floating point)
-------------- --------------- ---------------------
DS0 (0.064 Mbps) 0x45FA0000
DS1 (1.544 Mbps) 0x483C7A00
E1 (2.048 Mbps) 0x487A0000
DS2 (6.312 Mbps) 0x4940A080
E2 (8.448 Mbps) 0x4980E800
Ethernet (10.00 Mbps) 0x49989680
E3 (34.368 Mbps) 0x4A831A80
DS3 (44.736 Mbps) 0x4AAAA780
STS-1 (51.84 Mbps) 0x4AC5C100
Fast Ethernet (100.00 Mbps) 0x4B3EBC20
E4 (139.264 Mbps) 0x4B84D000
FC-0 133M 0x4B7DAD68
OC-3/STM-1 (155.52 Mbps) 0x4B9450C0
FC-0 266M 0x4BFDAD68
FC-0 531M 0x4C7D3356
OC-12/STM-4 (622.08 Mbps) 0x4C9450C0
GigE (1000.00 Mbps) 0x4CEE6B28
FC-0 1062M 0x4CFD3356
OC-48/STM-16 (2488.32 Mbps) 0x4D9450C0
OC-192/STM-64 (9953.28 Mbps) 0x4E9450C0
10GigE-LAN (10000.00 Mbps) 0x4E9502F9
OC-768/STM-256 (39813.12 Mbps) 0x4F9450C0
Signal Type (Bit-rate) Value (Bytes/Sec)
(IEEE Floating point)
-------------- --------------- ---------------------
DS0 (0.064 Mbps) 0x45FA0000
DS1 (1.544 Mbps) 0x483C7A00
E1 (2.048 Mbps) 0x487A0000
DS2 (6.312 Mbps) 0x4940A080
E2 (8.448 Mbps) 0x4980E800
Ethernet (10.00 Mbps) 0x49989680
E3 (34.368 Mbps) 0x4A831A80
DS3 (44.736 Mbps) 0x4AAAA780
STS-1 (51.84 Mbps) 0x4AC5C100
Fast Ethernet (100.00 Mbps) 0x4B3EBC20
E4 (139.264 Mbps) 0x4B84D000
FC-0 133M 0x4B7DAD68
OC-3/STM-1 (155.52 Mbps) 0x4B9450C0
FC-0 266M 0x4BFDAD68
FC-0 531M 0x4C7D3356
OC-12/STM-4 (622.08 Mbps) 0x4C9450C0
GigE (1000.00 Mbps) 0x4CEE6B28
FC-0 1062M 0x4CFD3356
OC-48/STM-16 (2488.32 Mbps) 0x4D9450C0
OC-192/STM-64 (9953.28 Mbps) 0x4E9450C0
10GigE-LAN (10000.00 Mbps) 0x4E9502F9
OC-768/STM-256 (39813.12 Mbps) 0x4F9450C0
The Generalized Label extends the traditional label by allowing the representation of not only labels which travel in-band with associated data packets, but also labels which identify time-slots, wavelengths, or space division multiplexed positions. For example, the Generalized Label may carry a label that represents (a) a single fiber in a bundle, (b) a single waveband within fiber, (c) a single wavelength within a waveband (or fiber), or (d) a set of time-slots within a wavelength (or fiber). It may also carry a label that represents a generic MPLS label, a Frame Relay label, or an ATM label (VCI/VPI).
广义标签扩展了传统标签，不仅允许表示与相关数据包在频带内传输的标签，还允许表示标识时隙、波长或空分复用位置的标签。例如，通用标签可以携带表示（a）束中的单个光纤，（b）光纤中的单个波段，（c）波段（或光纤）中的单个波长，或（d）波长（或光纤）中的一组时隙的标签。它还可以携带表示通用MPLS标签、帧中继标签或ATM标签（VCI/VPI）的标签。
A Generalized Label does not identify the "class" to which the label belongs. This is implicit in the multiplexing capabilities of the link on which the label is used.
通用标签不标识标签所属的“类”。这隐含在使用标签的链路的多路复用功能中。
A Generalized Label only carries a single level of label, i.e., it is non-hierarchical. When multiple levels of label (LSPs within LSPs) are required, each LSP must be established separately, see [MPLS-HIERARCHY].
通用标签只包含一个标签级别，即它是非层次的。当需要多级标签（LSP中的LSP）时，必须单独建立每个LSP，请参见[MPLS-HIERARCHY]。
Each Generalized Label object/TLV carries a variable length label parameter.
每个通用标签对象/TLV都带有一个可变长度的标签参数。
The information carried in a Generalized Label is:
通用标签中包含的信息为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label: Variable Length
标签：可变长度
Carries label information. The interpretation of this field depends on the type of the link over which the label is used.
携带标签信息。此字段的解释取决于使用标签的链接类型。
Some configurations of fiber switching (FSC) and lambda switching (LSC) use multiple data channels/links controlled by a single control channel. In such cases the label indicates the data channel/link to be used for the LSP. Note that this case is not the same as when [MPLS-BUNDLE] is being used.
光纤交换（FSC）和lambda交换（LSC）的某些配置使用由单个控制信道控制的多个数据信道/链路。在这种情况下，标签指示用于LSP的数据通道/链路。请注意，这种情况与使用[MPLS-BUNDLE]时不同。
The information carried in a Port and Wavelength label is:
端口和波长标签中包含的信息为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label: 32 bits
标签：32位
Indicates port/fiber or lambda to be used, from the perspective of the sender of the object/TLV. Values used in this field only have significance between two neighbors, and the receiver may need to convert the received value into a value that has local significance. Values may be configured or dynamically determined using a protocol such as [LMP].
从对象/TLV的发送方的角度指示要使用的端口/光纤或lambda。此字段中使用的值仅在两个相邻值之间具有重要性，并且接收器可能需要将接收到的值转换为具有局部重要性的值。可以使用诸如[LMP]的协议来配置或动态确定值。
Generic MPLS labels and Frame Relay labels are encoded right justified aligned in 32 bits (4 octets). ATM labels are encoded with the VPI right justified in bits 0-15 and the VCI right justified in bits 16-31.
通用MPLS标签和帧中继标签以32位（4个八位字节）进行右对齐编码。ATM标签编码时，VPI右对齐位为0-15，VCI右对齐位为16-31。
A special case of lambda switching is waveband switching. A waveband represents a set of contiguous wavelengths which can be switched together to a new waveband. For optimization reasons it may be desirable for an optical cross connect to optically switch multiple wavelengths as a unit. This may reduce the distortion on the individual wavelengths and may allow tighter separation of the individual wavelengths. The Waveband Label is defined to support this special case.
lambda开关的一种特殊情况是波段开关。一个波段代表一组连续的波长，这些波长可以一起切换到一个新的波段。出于优化原因，可能希望光学交叉连接以光学方式切换多个波长作为一个单元。这可以减少各个波长上的失真，并且可以允许更紧密地分离各个波长。波段标签的定义是为了支持这种特殊情况。
Waveband switching naturally introduces another level of label hierarchy and as such the waveband is treated the same way all other upper layer labels are treated.
波段切换自然引入了标签层次的另一个层次，因此，波段的处理方式与所有其他上层标签的处理方式相同。
As far as the MPLS protocols are concerned there is little difference between a waveband label and a wavelength label except that semantically the waveband can be subdivided into wavelengths whereas the wavelength can only be subdivided into time or statistically multiplexed labels.
就MPLS协议而言，波段标签和波长标签之间几乎没有区别，除了在语义上波段可以细分为波长，而波长只能细分为时间或统计复用标签。
Waveband switching uses the same format as the generalized label, see section 3.2.1.
波段切换使用与通用标签相同的格式，见第3.2.1节。
In the context of waveband switching, the generalized label has the following format:
在波段切换的情况下，通用标签具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Waveband Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Waveband Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Waveband Id: 32 bits
波段Id:32位
A waveband identifier. The value is selected by the sender and reused in all subsequent related messages.
波段标识符。该值由发件人选择，并在所有后续相关消息中重复使用。
Start Label: 32 bits
起始标签：32位
Indicates the channel identifier of the lowest value wavelength making up the waveband, from the object/TLV sender's perspective.
从对象/TLV发送方的角度指示组成波段的最低值波长的通道标识符。
End Label: 32 bits
结束标签：32位
Indicates the channel identifier of the highest value wavelength making up the waveband, from the object/TLV sender's perspective.
从对象/TLV发送方的角度指示组成波段的最高值波长的通道标识符。
Channel identifiers are established either by configuration or by means of a protocol such as LMP [LMP]. They are normally used in the label parameter of the Generalized Label one PSC and LSC.
通过配置或通过诸如LMP[LMP]的协议建立信道标识符。它们通常用于广义标签PSC和LSC的标签参数。
The Suggested Label is used to provide a downstream node with the upstream node's label preference. This permits the upstream node to start configuring its hardware with the proposed label before the label is communicated by the downstream node. Such early configuration is valuable to systems that take non-trivial time to establish a label in hardware. Such early configuration can reduce
建议的标签用于向下游节点提供上游节点的标签首选项。这允许上游节点在下游节点传送标签之前，开始使用所提议的标签配置其硬件。对于需要花费大量时间在硬件中建立标签的系统来说，这种早期配置是很有价值的。这样的早期配置可以减少
setup latency, and may be important for restoration purposes where alternate LSPs may need to be rapidly established as a result of network failures.
设置延迟，对于恢复目的可能很重要，因为网络故障可能需要快速建立备用LSP。
The use of Suggested Label is only an optimization. If a downstream node passes a different label upstream, an upstream LSR reconfigures itself so that it uses the label specified by the downstream node, thereby maintaining the downstream control of a label. Note, the transmission of a suggested label does not imply that the suggested label is available for use. In particular, an ingress node should not transmit data traffic on a suggested label until the downstream node passes a label upstream.
建议标签的使用只是一种优化。如果下游节点向上游传递不同的标签，则上游LSR将自身重新配置，以便使用下游节点指定的标签，从而保持标签的下游控制。注意，传送建议标签并不意味着建议标签可供使用。特别是，入口节点不应在建议的标签上传输数据流量，直到下游节点通过上游标签。
The information carried in a suggested label is identical to a generalized label. Note, values used in the label field of a suggested label are from the object/TLV sender's perspective.
建议标签中包含的信息与通用标签相同。注意，建议标签的标签字段中使用的值来自对象/TLV发送者的角度。
The Label Set is used to limit the label choices of a downstream node to a set of acceptable labels. This limitation applies on a per hop basis.
标签集用于将下游节点的标签选择限制为一组可接受的标签。此限制适用于每跳。
We describe four cases where a Label Set is useful in the optical domain. The first case is where the end equipment is only capable of transmitting on a small specific set of wavelengths/bands. The second case is where there is a sequence of interfaces which cannot support wavelength conversion (CI-incapable) and require the same wavelength be used end-to-end over a sequence of hops, or even an entire path. The third case is where it is desirable to limit the amount of wavelength conversion being performed to reduce the distortion on the optical signals. The last case is where two ends of a link support different sets of wavelengths.
我们描述了四种情况，其中标签集在光学领域是有用的。第一种情况是，终端设备仅能够在一小组特定波长/频带上进行传输。第二种情况是，存在一系列接口，这些接口不支持波长转换（CI-unable），并且要求在一系列跳上，甚至在整个路径上，端到端使用相同的波长。第三种情况是希望限制正在执行的波长转换量以减少光信号上的失真。最后一种情况是链路的两端支持不同的波长组。
Label Set is used to restrict label ranges that may be used for a particular LSP between two peers. The receiver of a Label Set must restrict its choice of labels to one which is in the Label Set. Much like a label, a Label Set may be present across multiple hops. In this case each node generates its own outgoing Label Set, possibly based on the incoming Label Set and the node's hardware capabilities. This case is expected to be the norm for nodes with conversion incapable (CI-incapable) interfaces.
标签集用于限制可用于两个对等方之间特定LSP的标签范围。标签集的接收者必须将其标签选择限制为标签集中的标签。与标签非常相似，标签集可以跨多个跃点出现。在这种情况下，每个节点生成自己的传出标签集，可能基于传入标签集和节点的硬件功能。这种情况预计将成为具有无法转换（CI）接口的节点的规范。
The use of Label Set is optional, if not present, all labels from the valid label range may be used. Conceptually the absence of a Label Set implies a Label Set whose value is {U}, the set of all valid labels.
标签集的使用是可选的，如果不存在，则可以使用有效标签范围内的所有标签。从概念上讲，缺少标签集意味着标签集的值为{U}，即所有有效标签的集合。
A label set is composed of one or more Label_Set objects/TLVs. Each object/TLV contains one or more elements of the Label Set. Each element is referred to as a subchannel identifier and has the same format as a generalized label.
标签集由一个或多个标签集对象/TLV组成。每个对象/TLV包含标签集的一个或多个元素。每个元素称为子通道标识符，其格式与通用标签相同。
The information carried in a Label_Set is:
标签集合中包含的信息为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved | Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel N |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved | Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel N |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Action: 8 bits
动作：8位
0 - Inclusive List
0-包含列表
Indicates that the object/TLV contains one or more subchannel elements that are included in the Label Set.
指示对象/TLV包含标签集中包含的一个或多个子通道元素。
1 - Exclusive List
1-独家名单
Indicates that the object/TLV contains one or more subchannel elements that are excluded from the Label Set.
指示对象/TLV包含从标签集中排除的一个或多个子通道元素。
2 - Inclusive Range
2-包含范围
Indicates that the object/TLV contains a range of labels. The object/TLV contains two subchannel elements. The first element indicates the start of the range. The second element indicates the end of the range. A value of zero indicates that there is no bound on the corresponding portion of the range.
指示对象/TLV包含一系列标签。对象/TLV包含两个子通道元素。第一个元素表示范围的开始。第二个元素表示范围的结束。值为零表示范围的相应部分上没有边界。
3 - Exclusive Range
3-专用范围
Indicates that the object/TLV contains a range of labels that are excluded from the Label Set. The object/TLV contains two subchannel elements. The first element indicates the start of the range. The second element indicates the end of the range. A value of zero indicates that there is no bound on the corresponding portion of the range.
指示对象/TLV包含从标签集中排除的标签范围。对象/TLV包含两个子通道元素。第一个元素表示范围的开始。第二个元素表示范围的结束。值为零表示范围的相应部分上没有边界。
Reserved: 10 bits
保留：10位
This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt.
此字段是保留的。传输时必须将其设置为零，接收时必须忽略。
Label Type: 14 bits
标签类型：14位
Indicates the type and format of the labels carried in the object/TLV. Values are signaling protocol specific.
指示对象/TLV中携带的标签的类型和格式。值是特定于信令协议的。
Subchannel:
子频道：
The subchannel represents the label (wavelength, fiber ... ) which is eligible for allocation. This field has the same format as described for labels under section 3.2.
子信道表示符合分配条件的标签（波长、光纤…）。该字段的格式与第3.2节中标签的格式相同。
Note that subchannel to local channel identifiers (e.g., wavelength) mappings are a local matter.
注意，子信道到本地信道标识符（例如，波长）的映射是本地问题。
This section defines direct support of bidirectional LSPs. Support is defined for LSPs that have the same traffic engineering requirements including fate sharing, protection and restoration, LSRs, and resource requirements (e.g., latency and jitter) in each direction. In the remainder of this section, the term "initiator" is used to refer to a node that starts the establishment of an LSP and the term "terminator" is used to refer to the node that is the target of the LSP. Note that for bidirectional LSPs, there is only one "initiator" and one "terminator".
本节定义了对双向LSP的直接支持。支持定义为具有相同流量工程需求的LSP，包括命运共享、保护和恢复、LSR以及每个方向的资源需求（例如延迟和抖动）。在本节的其余部分中，术语“发起方”用于指开始建立LSP的节点，术语“终止方”用于指作为LSP的目标的节点。请注意，对于双向LSP，只有一个“启动器”和一个“终止器”。
Normally to establish a bidirectional LSP when using [RFC3209] or [RFC3212] two unidirectional paths must be independently established. This approach has the following disadvantages:
通常，在使用[RFC3209]或[RFC3212]时，要建立双向LSP，必须独立建立两条单向路径。这种方法有以下缺点：
* The latency to establish the bidirectional LSP is equal to one round trip signaling time plus one initiator-terminator signaling transit delay. This not only extends the setup latency for successful LSP establishment, but it extends the worst-case
* 建立双向LSP的延迟等于一个往返信令时间加上一个发起方-终止方信令传输延迟。这不仅延长了成功建立LSP的设置延迟，而且还延长了最坏情况
latency for discovering an unsuccessful LSP to as much as two times the initiator-terminator transit delay. These delays are particularly significant for LSPs that are established for restoration purposes.
发现不成功LSP的延迟高达启动器终止器传输延迟的两倍。这些延迟对于为恢复目的而建立的LSP尤其重要。
* The control overhead is twice that of a unidirectional LSP. This is because separate control messages (e.g., Path and Resv) must be generated for both segments of the bidirectional LSP.
* 控制开销是单向LSP的两倍。这是因为必须为双向LSP的两个段生成单独的控制消息（例如，Path和Resv）。
* Because the resources are established in separate segments, route selection is complicated. There is also additional potential race for conditions in assignment of resources, which decreases the overall probability of successfully establishing the bidirectional connection.
* 由于资源建立在不同的路段上，因此路线选择非常复杂。在资源分配中还存在额外的潜在竞争条件，这降低了成功建立双向连接的总体概率。
* It is more difficult to provide a clean interface for SONET/SDH equipment that may rely on bidirectional hop-by-hop paths for protection switching.
* 为SONET/SDH设备提供干净的接口更加困难，因为SONET/SDH设备可能依赖双向逐跳路径进行保护切换。
* Bidirectional optical LSPs (or lightpaths) are seen as a requirement for many optical networking service providers.
* 双向光LSP（或光路）被视为许多光网络服务提供商的需求。
With bidirectional LSPs both the downstream and upstream data paths, i.e., from initiator to terminator and terminator to initiator, they are established using a single set of signaling messages. This reduces the setup latency to essentially one initiator-terminator round trip time plus processing time, and limits the control overhead to the same number of messages as a unidirectional LSP.
通过双向LSP，下游和上游数据路径，即从发起方到终止方以及从终止方到发起方，使用一组信令消息建立它们。这将设置延迟减少到一个启动器-终止器往返时间加上处理时间，并将控制开销限制为与单向LSP相同的消息数。
For bidirectional LSPs, two labels must be allocated. Bidirectional LSP setup is indicated by the presence of an Upstream Label object/TLV in the appropriate signaling message. An Upstream Label has the same format as the generalized label, see Section 3.2.
对于双向LSP，必须分配两个标签。双向LSP设置通过在适当的信令消息中存在上游标签对象/TLV来指示。上游标签的格式与通用标签相同，见第3.2节。
Contention for labels may occur between two bidirectional LSP setup requests traveling in opposite directions. This contention occurs when both sides allocate the same resources (labels) at effectively the same time. If there is no restriction on the labels that can be used for bidirectional LSPs and if there are alternate resources, then both nodes will pass different labels upstream and there is no contention. However, if there is a restriction on the labels that can be used for the bidirectional LSPs (for example, if they must be physically coupled on a single I/O card), or if there are no more resources available, then the contention must be resolved by other
标签争用可能发生在两个双向LSP设置请求之间，这两个请求的方向相反。当双方同时有效地分配相同的资源（标签）时，就会发生这种争用。如果对可用于双向LSP的标签没有限制，并且存在备用资源，则两个节点将向上游传递不同的标签，并且没有争用。然而，如果对可用于双向LSP的标签有限制（例如，如果它们必须物理耦合在单个I/O卡上），或者如果没有更多可用资源，则必须由其他方解决争用
means. To resolve contention, the node with the higher node ID will win the contention and it MUST issue a PathErr/NOTIFICATION message with a "Routing problem/Label allocation failure" indication. Upon receipt of such an error, the node SHOULD try to allocate a different Upstream label (and a different Suggested Label if used) to the bidirectional path. However, if no other resources are available, the node must proceed with standard error handling.
方法要解决争用，具有较高节点ID的节点将赢得争用，并且它必须发出带有“路由问题/标签分配失败”指示的PathErr/通知消息。在收到此类错误后，节点应尝试向双向路径分配不同的上游标签（以及不同的建议标签，如果使用）。但是，如果没有其他可用资源，则节点必须继续执行标准错误处理。
To reduce the probability of contention, one may impose a policy that the node with the lower ID never suggests a label in the downstream direction and always accepts a Suggested Label from an upstream node with a higher ID. Furthermore, since the labels may be exchanged using LMP, an alternative local policy could further be imposed such that (with respect to the higher numbered node's label set) the higher numbered node could allocate labels from the high end of the label range while the lower numbered node allocates labels from the low end of the label range. This mechanism would augment any close packing algorithms that may be used for bandwidth (or wavelength) optimization. One special case that should be noted when using RSVP and supporting this approach is that the neighbor's node ID might not be known when sending an initial Path message. When this case occurs, a node should suggest a label chosen at random from the available label space.
为了降低争用的概率，可以施加一种策略，即具有较低ID的节点从不在下游方向上建议标签，并且总是接受来自具有较高ID的上游节点的建议标签。此外，由于可以使用LMP交换标签，因此可以进一步施加替代本地策略，使得（对于编号较高的节点的标签集），编号较高的节点可以从标签范围的高端分配标签，而编号较低的节点可以从标签范围的低端分配标签。此机制将增强任何可能用于带宽（或波长）的密排算法优化。当使用RSVP并支持此方法时，应注意的一个特殊情况是，在发送初始路径消息时，邻居的节点ID可能未知。当出现这种情况时，节点应建议从可用标签空间中随机选择标签。
An example of contention between two nodes (PXC 1 and PXC 2) is shown in Figure 1. In this example PXC 1 assigns an Upstream Label for the channel corresponding to local BCId=2 (local BCId=7 on PXC 2) and sends a Suggested Label for the channel corresponding to local BCId=1 (local BCId=6 on PXC 2). Simultaneously, PXC 2 assigns an Upstream Label for the channel corresponding to its local BCId=6 (local BCId=1 on PXC 1) and sends a Suggested Label for the channel corresponding to its local BCId=7 (local BCId=2 on PXC 1). If there is no restriction on the labels that can be used for bidirectional LSPs and if there are alternate resources available, then both PXC 1 and PXC 2 will pass different labels upstream and the contention is resolved naturally (see Fig. 2). However, if there is a restriction on the labels that can be used for bidirectional LSPs (for example, if they must be physically coupled on a single I/O card), then the contention must be resolved using the node ID (see Fig. 3).
图1显示了两个节点（PXC1和PXC2）之间的争用示例。在此示例中，PXC 1为对应于本地BCId=2（PXC 2上的本地BCId=7）的信道分配上游标签，并为对应于本地BCId=1（PXC 2上的本地BCId=6）的信道发送建议标签。同时，PXC 2为对应于其本地BCId=6（PXC 1上的本地BCId=1）的信道分配上游标签，并为对应于其本地BCId=7（PXC 1上的本地BCId=2）的信道发送建议标签。如果对可用于双向LSP的标签没有限制，并且如果有备用资源可用，则PXC 1和PXC 2都将向上游传递不同的标签，并且争用自然得到解决（见图2）。然而，如果对可用于双向lsp的标签存在限制（例如，如果它们必须在单个I/O卡上物理耦合），则必须使用节点ID来解决争用（参见图3）。
+------------+ +------------+
+ PXC 1 + + PXC 2 +
+ + SL1,UL2 + +
+ 1 +------------------------>+ 6 +
+ + UL1, SL2 + +
+ 2 +<------------------------+ 7 +
+ + + +
+ + + +
+ 3 +------------------------>+ 8 +
+ + + +
+ 4 +<------------------------+ 9 +
+------------+ +------------+
Figure 1. Label Contention
+------------+ +------------+
+ PXC 1 + + PXC 2 +
+ + SL1,UL2 + +
+ 1 +------------------------>+ 6 +
+ + UL1, SL2 + +
+ 2 +<------------------------+ 7 +
+ + + +
+ + + +
+ 3 +------------------------>+ 8 +
+ + + +
+ 4 +<------------------------+ 9 +
+------------+ +------------+
Figure 1. Label Contention
In this example, PXC 1 assigns an Upstream Label using BCId=2 (BCId=7 on PXC 2) and a Suggested Label using BCId=1 (BCId=6 on PXC 2). Simultaneously, PXC 2 assigns an Upstream Label using BCId=6 (BCId=1 on PXC 1) and a Suggested Label using BCId=7 (BCId=2 on PXC 1).
在本例中，PXC 1使用BCId=2（PXC 2上的BCId=7）分配上游标签，并使用BCId=1（PXC 2上的BCId=6）分配建议标签。同时，PXC 2使用BCId=6（PXC 1上的BCId=1）分配上游标签，并使用BCId=7（PXC 1上的BCId=2）分配建议标签。
+------------+ +------------+
+ PXC 1 + + PXC 2 +
+ + UL2 + +
+ 1 +------------------------>+ 6 +
+ + UL1 + +
+ 2 +<------------------------+ 7 +
+ + + +
+ + L1 + +
+ 3 +------------------------>+ 8 +
+ + L2 + +
+ 4 +<------------------------+ 9 +
+------------+ +------------+
+------------+ +------------+
+ PXC 1 + + PXC 2 +
+ + UL2 + +
+ 1 +------------------------>+ 6 +
+ + UL1 + +
+ 2 +<------------------------+ 7 +
+ + + +
+ + L1 + +
+ 3 +------------------------>+ 8 +
+ + L2 + +
+ 4 +<------------------------+ 9 +
+------------+ +------------+
Figure 2. Label Contention Resolution without resource restrictions
图2。无资源限制的标签争用解决方案
In this example, there is no restriction on the labels that can be used by the bidirectional connection and there is no contention.
在本例中，双向连接可以使用的标签没有限制，也没有争用。
+------------+ +------------+
+ PXC 1 + + PXC 2 +
+ + UL2 + +
+ 1 +------------------------>+ 6 +
+ + L2 + +
+ 2 +<------------------------+ 7 +
+ + + +
+ + L1 + +
+ 3 +------------------------>+ 8 +
+ + UL1 + +
+ 4 +<------------------------+ 9 +
+------------+ +------------+
+------------+ +------------+
+ PXC 1 + + PXC 2 +
+ + UL2 + +
+ 1 +------------------------>+ 6 +
+ + L2 + +
+ 2 +<------------------------+ 7 +
+ + + +
+ + L1 + +
+ 3 +------------------------>+ 8 +
+ + UL1 + +
+ 4 +<------------------------+ 9 +
+------------+ +------------+
Figure 3. Label Contention Resolution with resource restrictions
图3。具有资源限制的标签争用解决方案
In this example, labels 1,2 and 3,4 on PXC 1 (labels 6,7 and 8,9 on PXC 2, respectively) must be used by the same bidirectional connection. Since PXC 2 has a higher node ID, it wins the contention and PXC 1 must use a different set of labels.
在此示例中，PXC 1上的标签1,2和3,4（分别为PXC 2上的标签6,7和8,9）必须由同一双向连接使用。由于PXC 2具有更高的节点ID，因此它将赢得竞争，PXC 1必须使用一组不同的标签。
There are cases in traditional MPLS and in GMPLS that result in an error message containing an "Unacceptable label value" indication, see [RFC3209], [RFC3472] and [RFC3473]. When these cases occur, it can be useful for the node generating the error message to indicate which labels would be acceptable. To cover this case, GMPLS introduces the ability to convey such information via the "Acceptable Label Set". An Acceptable Label Set is carried in appropriate protocol specific error messages, see [RFC3472] and [RFC3473].
传统MPLS和GMPLS中存在导致包含“不可接受标签值”指示的错误消息的情况，请参阅[RFC3209]、[RFC3472]和[RFC3473]。当出现这些情况时，生成错误消息的节点可以指示哪些标签是可以接受的。为了解决这种情况，GMPLS引入了通过“可接受标签集”传达此类信息的能力。可接受的标签集包含在相应的协议特定错误消息中，请参阅[RFC3472]和[RFC3473]。
The format of an Acceptable Label Set is identical to a Label Set, see section 3.5.1.
可接受标签集的格式与标签集的格式相同，见第3.5.1节。
In traditional MPLS, the interfaces used by an LSP may be controlled via an explicit route, i.e., ERO or ER-Hop. This enables the inclusion of a particular node/interface, and the termination of an LSP on a particular outgoing interface of the egress LSR. Where the interface may be numbered or unnumbered, see [MPLS-UNNUM].
在传统MPLS中，LSP使用的接口可以通过显式路由（即ERO或ER-Hop）来控制。这使得能够包括特定节点/接口，并且在出口LSR的特定输出接口上终止LSP。如果接口可以编号或不编号，请参阅[MPLS-UNNUM]。
There are cases where the existing explicit route semantics do not provide enough information to control the LSP to the degree desired. This occurs in the case when the LSP initiator wishes to select a
在某些情况下，现有的显式路由语义无法提供足够的信息来将LSP控制到所需的程度。当LSP启动器希望选择一个
label used on a link. Specifically, the problem is that ERO and ER-Hop do not support explicit label sub-objects. An example case where such a mechanism is desirable is where there are two LSPs to be "spliced" together, i.e., where the tail of the first LSP would be "spliced" into the head of the second LSP. This last case is more likely to be used in the non-PSC classes of links.
链接上使用的标签。具体而言，问题在于ERO和ER Hop不支持显式标签子对象。需要这种机制的示例情况是，存在两个要“拼接”在一起的LSP，即，第一LSP的尾部将“拼接”到第二LSP的头部。最后一种情况更可能用于非PSC类的链路。
To cover this case, the Label ERO subobject / ER Hop is introduced.
为了涵盖这种情况，引入了标签ERO子对象/ER Hop。
The Label Explicit and Record Routes contains:
标签显式和记录路由包含：
L: 1 bit
L:1位
This bit must be set to 0.
此位必须设置为0。
U: 1 bit
U:1位
This bit indicates the direction of the label. It is 0 for the downstream label. It is set to 1 for the upstream label and is only used on bidirectional LSPs.
此位指示标签的方向。下游标签为0。上游标签设置为1，仅用于双向LSP。
Label: Variable
标签：变量
This field identifies the label to be used. The format of this field is identical to the one used by the Label field in Generalized Label, see Section 3.2.1.
此字段标识要使用的标签。该字段的格式与通用标签中标签字段使用的格式相同，见第3.2.1节。
Placement and ordering of these parameters are signaling protocol specific.
这些参数的位置和顺序是特定于信令协议的。
Protection Information is carried in a new object/TLV. It is used to indicate link related protection attributes of a requested LSP. The use of Protection Information for a particular LSP is optional. Protection Information currently indicates the link protection type desired for the LSP. If a particular protection type, i.e., 1+1, or 1:N, is requested, then a connection request is processed only if the desired protection type can be honored. Note that the protection capabilities of a link may be advertised in routing, see [GMPLS-RTG]. Path computation algorithms may take this information into account when computing paths for setting up LSPs.
保护信息携带在新对象/TLV中。它用于指示所请求LSP的链路相关保护属性。对特定LSP使用保护信息是可选的。保护信息当前指示LSP所需的链路保护类型。如果请求特定的保护类型，即1+1或1:N，则仅当可以满足所需的保护类型时，才会处理连接请求。请注意，链路的保护功能可能会在路由中公布，请参阅[GMPLS-RTG]。在计算用于设置LSP的路径时，路径计算算法可以考虑该信息。
Protection Information also indicates if the LSP is a primary or secondary LSP. A secondary LSP is a backup to a primary LSP. The resources of a secondary LSP are not used until the primary LSP
保护信息还指示LSP是主LSP还是辅助LSP。辅助LSP是主LSP的备份。辅助LSP的资源在主LSP启动之前不会被使用
fails. The resources allocated for a secondary LSP MAY be used by other LSPs until the primary LSP fails over to the secondary LSP. At that point, any LSP that is using the resources for the secondary LSP MUST be preempted.
失败。分配给次要LSP的资源可被其他LSP使用，直到主要LSP故障转移到次要LSP为止。此时，任何正在使用辅助LSP资源的LSP都必须被抢占。
The following information is carried in Protection Information:
保护信息中包含以下信息：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Secondary (S): 1 bit
辅助：1位
When set, indicates that the requested LSP is a secondary LSP.
设置时，表示请求的LSP是辅助LSP。
Reserved: 25 bits
保留：25位
This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. These bits SHOULD be pass through unmodified by transit nodes.
此字段是保留的。传输时必须将其设置为零，接收时必须忽略。这些位应在传输节点未修改的情况下通过。
Link Flags: 6 bits
链接标志：6位
Indicates desired link protection type. As previously mentioned, protection capabilities of a link may be advertised in routing. A value of 0 implies that any, including no, link protection may be used. More than one bit may be set to indicate when multiple protection types are acceptable. When multiple bits are set and multiple protection types are available, the choice of protection type is a local (policy) decision.
指示所需的链路保护类型。如前所述，链路的保护能力可以在路由中公布。值为0表示可以使用任何（包括否）链路保护。可设置多个位，以指示何时可接受多种保护类型。当设置了多个位且有多个保护类型可用时，保护类型的选择是本地（策略）决策。
The following flags are defined:
定义了以下标志：
0x20 Enhanced
0x20增强型
Indicates that a protection scheme that is more reliable than Dedicated 1+1 should be used, e.g., 4 fiber BLSR/MS-SPRING.
表明应使用比专用1+1更可靠的保护方案，例如4光纤BLSR/MS-SPRING。
0x10 Dedicated 1+1
0x10专用1+1
Indicates that a dedicated link layer protection scheme, i.e., 1+1 protection, should be used to support the LSP.
指示应使用专用链路层保护方案（即1+1保护）来支持LSP。
0x08 Dedicated 1:1
0x08专用1:1
Indicates that a dedicated link layer protection scheme, i.e., 1:1 protection, should be used to support the LSP.
指示应使用专用链路层保护方案（即1:1保护）来支持LSP。
0x04 Shared
0x04共享
Indicates that a shared link layer protection scheme, such as 1:N protection, should be used to support the LSP.
指示应使用共享链路层保护方案（如1:N保护）来支持LSP。
0x02 Unprotected
0x02未受保护
Indicates that the LSP should not use any link layer protection.
指示LSP不应使用任何链路层保护。
0x01 Extra Traffic
0x01额外流量
Indicates that the LSP should use links that are protecting other (primary) traffic. Such LSPs may be preempted when the links carrying the (primary) traffic being protected fail.
指示LSP应使用保护其他（主）通信量的链路。当承载被保护的（主要）业务的链路发生故障时，这种lsp可以被抢占。
Administrative Status Information is carried in a new object/TLV. Administrative Status Information is currently used in two ways. In the first, the information indicates administrative state with respect to a particular LSP. In this usage, Administrative Status Information indicates the state of the LSP. State indications include "up" or "down", if it is in a "testing" mode, and if deletion is in progress. The actions taken by a node based on a state local decision. An example action that may be taken is to inhibit alarm reporting when an LSP is in "down" or "testing" states, or to report alarms associated with the connection at a priority equal to or less than "Non service affecting".
管理状态信息携带在新对象/TLV中。管理状态信息目前有两种使用方式。在第一种情况下，该信息指示关于特定LSP的管理状态。在此用法中，管理状态信息指示LSP的状态。状态指示包括“向上”或“向下”，如果处于“测试”模式，以及如果正在删除。节点根据状态本地决策采取的操作。可采取的示例行动是，当LSP处于“关闭”或“测试”状态时，禁止报警报告，或以等于或小于“不影响服务”的优先级报告与连接相关的报警。
In the second usage of Administrative Status Information, the information indicates a request to set an LSP's administrative state. This information is always relayed to the ingress node which acts on the request.
在管理状态信息的第二种用法中，该信息指示设置LSP的管理状态的请求。此信息始终中继到根据请求进行操作的入口节点。
The different usages are distinguished in a protocol specific fashion. See [RFC3473] and [RFC3472] for details. The use of Administrative Status Information for a particular LSP is optional.
以特定于协议的方式区分不同的用法。详见[RFC3473]和[RFC3472]。对特定LSP使用管理状态信息是可选的。
The following information is carried in Administrative Status Information:
管理状态信息中包含以下信息：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reflect (R): 1 bit
反射（R）：1位
When set, indicates that the edge node SHOULD reflect the object/TLV back in the appropriate message. This bit MUST NOT be set in state change request, i.e., Notify, messages.
设置后，指示边缘节点应在适当的消息中反映对象/TLV。不得在状态更改请求（即通知消息）中设置此位。
Reserved: 28 bits
保留：28位
This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. These bits SHOULD be pass through unmodified by transit nodes.
此字段是保留的。传输时必须将其设置为零，接收时必须忽略。这些位应在传输节点未修改的情况下通过。
Testing (T): 1 bit
测试（T）：1位
When set, indicates that the local actions related to the "testing" mode should be taken.
设置时，表示应采取与“测试”模式相关的本地操作。
Administratively down (A): 1 bit
管理下行（A）：1位
When set, indicates that the local actions related to the "administratively down" state should be taken.
设置时，表示应采取与“管理性关闭”状态相关的本地操作。
Deletion in progress (D): 1 bit
正在删除（D）：1位
When set, indicates that that the local actions related to LSP teardown should be taken. Edge nodes may use this flag to control connection teardown.
设置时，表示应采取与LSP拆卸相关的本地操作。边缘节点可以使用此标志控制连接断开。
The concept of a control channel being different than a data channel being signaled was introduced to MPLS in connection with link bundling, see [MPLS-BUNDLE]. In GMPLS, the separation of control and data channel may be due to any number of factors. (Including bundling and other cases such as data channels that cannot carry in-band control information.) This section will cover the two critical related issues: the identification of data channels in signaling and handling of control channel failures that don't impact data channels.
与链路捆绑相关的MPLS引入了控制信道不同于发送信号的数据信道的概念，参见[MPLS-BUNDLE]。在GMPLS中，控制通道和数据通道的分离可能是由许多因素造成的。（包括捆绑和其他情况，如无法携带带内控制信息的数据通道）。本节将讨论两个关键相关问题：信令中数据通道的识别和不影响数据通道的控制通道故障的处理。
In traditional MPLS there is an implicit one-to-one association of a control channel to a data channel. When such an association is present, no additional or special information is required to associate a particular LSP setup transaction with a particular data channel. (It is implicit in the control channel over which the signaling messages are sent.)
在传统的MPLS中，控制通道与数据通道之间存在一对一的隐式关联。当存在这种关联时，将特定LSP设置事务与特定数据通道关联不需要额外或特殊信息。（它隐含在发送信令消息的控制信道中。）
In cases where there is not an explicit one-to-one association of control channels to data channels it is necessary to convey additional information in signaling to identify the particular data channel being controlled. GMPLS supports explicit data channel identification by providing interface identification information. GMPLS allows the use of a number of interface identification schemes including IPv4 or IPv6 addresses, interface indexes (see [MPLS-UNNUM]) and component interfaces (established via configuration or a protocol such as [LMP]). In all cases the choice of the data interface is indicated by the upstream node using addresses and identifiers used by the upstream node.
在没有控制信道与数据信道的显式一对一关联的情况下，有必要在信令中传递附加信息以识别被控制的特定数据信道。GMPLS通过提供接口标识信息支持显式数据通道标识。GMPLS允许使用多种接口标识方案，包括IPv4或IPv6地址、接口索引（见[MPLS-UNNUM]）和组件接口（通过配置或协议（如[LMP]）。在所有情况下，数据接口的选择由上游节点使用上游节点使用的地址和标识符来指示。
The following information is carried in Interface_ID:
接口_ID中包含以下信息：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where each TLV has the following format:
其中，每个TLV具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: 16 bits
长度：16位
Indicates the total length of the TLV, i.e., 4 + the length of the value field in octets. A value field whose length is not a multiple of four MUST be zero-padded so that the TLV is four-octet aligned.
表示TLV的总长度，即4+值字段的长度（以八位字节为单位）。长度不是四的倍数的值字段必须加零，以便TLV与四个八位组对齐。
Type: 16 bits
类型：16位
Indicates type of interface being identified. Defined values are:
指示要标识的接口类型。定义值为：
Type Length Format Description
--------------------------------------------------------------------
1 8 IPv4 Addr. IPv4
2 20 IPv6 Addr. IPv6
3 12 See below IF_INDEX (Interface Index)
4 12 See below COMPONENT_IF_DOWNSTREAM (Component interface)
5 12 See below COMPONENT_IF_UPSTREAM (Component interface)
Type Length Format Description
--------------------------------------------------------------------
1 8 IPv4 Addr. IPv4
2 20 IPv6 Addr. IPv6
3 12 See below IF_INDEX (Interface Index)
4 12 See below COMPONENT_IF_DOWNSTREAM (Component interface)
5 12 See below COMPONENT_IF_UPSTREAM (Component interface)
For types 3, 4 and 5 the Value field has the format:
对于类型3、4和5，值字段的格式为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Address: 32 bits
IP地址：32位
The IP address field may carry either an IP address of a link or an IP address associated with the router, where associated address is the value carried in a router address TLV of routing.
IP地址字段可以携带链路的IP地址或与路由器关联的IP地址，其中关联地址是路由的路由器地址TLV中携带的值。
Interface ID: 32 bits
接口ID:32位
For type 3 usage, the Interface ID carries an interface identifier.
对于类型3使用，接口ID带有接口标识符。
For types 4 and 5, the Interface ID indicates a bundled component link. The special value 0xFFFFFFFF can be used to indicate the same label is to be valid across all component links.
对于类型4和5，接口ID表示捆绑组件链接。特殊值0xFFFFFF可用于指示相同标签在所有组件链接中有效。
There are two new faults that must be handled when the control channel is independent of the data channel. In the first, there is a link or other type of failure that limits the ability of neighboring nodes to pass control messages. In this situation, neighboring nodes are unable to exchange control messages for a period of time. Once communication is restored the underlying signaling protocol must indicate that the nodes have maintained their state through the failure. The signaling protocol must also ensure that any state changes that were instantiated during the failure are synchronized between the nodes.
当控制通道独立于数据通道时，必须处理两个新故障。在第一种情况下，链路或其他类型的故障限制了相邻节点传递控制消息的能力。在这种情况下，相邻节点在一段时间内无法交换控制消息。一旦通信恢复，底层信令协议必须指示节点在故障期间保持其状态。信令协议还必须确保在故障期间实例化的任何状态更改在节点之间同步。
In the second, a node's control plane fails and then restarts and losses most of its state information. In this case, both upstream and downstream nodes must synchronize their state information with the restarted node. In order for any resynchronization to occur the node undergoing the restart will need to preserve some information, such as its mappings of incoming to outgoing labels.
在第二种情况下，节点的控制平面发生故障，然后重新启动并丢失大部分状态信息。在这种情况下，上游和下游节点都必须将其状态信息与重新启动的节点同步。为了进行任何重新同步，正在重新启动的节点需要保留一些信息，例如传入到传出标签的映射。
Both cases are addressed in protocol specific fashions, see [RFC3473] and [RFC3472].
这两种情况都以特定于协议的方式处理，请参见[RFC3473]和[RFC3472]。
Note that these cases only apply when there are mechanisms to detect data channel failures independent of control channel failures.
请注意，这些情况仅适用于存在独立于控制通道故障检测数据通道故障的机制的情况。
This document is the work of numerous authors and consists of a composition of a number of previous documents in this area.
本文件是众多作者的作品，由该领域以前的许多文件组成。
Valuable comments and input were received from a number of people, including Igor Bryskin, Adrian Farrel, Ben Mack-Crane, Dimitri Papadimitriou, Fong Liaw and Juergen Heiles. Some sections of this document are based on text proposed by Fong Liaw.
许多人都提出了宝贵的意见和建议，包括伊戈尔·布莱斯金、阿德里安·法雷尔、本·麦克·克雷恩、迪米特里·帕帕迪米特里欧、方·廖和尤尔根·海尔斯。本文件的某些章节基于Fong Liaw提出的文本。
This document introduce no new security considerations to either [RFC3212] or [RFC3209]. The security considerations mentioned in [RFC3212] or [RFC3209] apply to the respective protocol specific forms of GMPLS, see [RFC3473] and [RFC3472].
本文件未向[RFC3212]或[RFC3209]引入新的安全注意事项。[RFC3212]或[RFC3209]中提到的安全注意事项适用于GMPLS的相应协议特定形式，请参见[RFC3473]和[RFC3472]。
The IANA will administer assignment of new values for namespaces defined in this document. This section uses the terminology of BCP 26 "Guidelines for Writing an IANA Considerations Section in RFCs" [BCP26].
IANA将为本文档中定义的名称空间管理新值的分配。本节使用BCP 26“在RFCs中编写IANA注意事项部分的指南”[BCP26]的术语。
This document defines the following namespaces:
本文档定义了以下名称空间：
o LSP Encoding Type: 8 bits o Switching Type: 8 bits o Generalized PID (G-PID): 16 bits o Action: 8 bits o Interface_ID Type: 16 bits
o LSP编码类型：8位o切换类型：8位o通用PID（G-PID）：16位o动作：8位o接口ID类型：16位
All future assignments should be allocated through IETF Consensus action or documented in a Specification.
所有未来的任务应通过IETF协商一致行动分配或记录在规范中。
LSP Encoding Type - valid value range is 1-255. This document defines values 1-11.
LSP编码类型-有效值范围为1-255。本文件定义了值1-11。
Switching Type - valid value range is 1-255. This document defines values 1-4, 100, 150 and 200.
开关类型-有效值范围为1-255。本文件定义了值1-4、100、150和200。
Generalized PID (G-PID) - valid value range is 0-1500. This document defines values 0-46.
广义PID（G-PID）-有效值范围为0-1500。本文档定义了值0-46。
Action - valid value range is 0-255. This document defines values 0-3.
操作-有效值范围为0-255。本文档定义了值0-3。
Interface_ID Type - valid value range is 1-65535. This document defines values 1-5.
接口ID类型-有效值范围为1-65535。本文件定义了值1-5。
This section is taken from Section 10.4 of [RFC2026].
本节摘自[RFC2026]第10.4节。
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 BCP-11. 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在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从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执行董事。
[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月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036]Andersson，L.，Doolan，P.，Feldman，N.，Fredette，A.和B.Thomas，“LDP规范”，RFC 3036，2001年1月。
[RFC3209] Awduche, 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]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
[RFC3212]Jamoussi，B.，Andersson，L.，Callon，R.，Dantu，R.，Wu，L.，Doolan，P.，Worster，T.，Feldman，N.，Fredette，A.，Girish，M.，Gray，E.，Heinanen，J.，Kilty，T.和A.Malis，“使用LDP的基于约束的LSP设置”，RFC 3212，2002年1月。
[RFC3472] Ashwood-Smith, P. and L. Berger, Editors, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003.
[RFC3472]Ashwood Smith，P.和L.Berger，编辑，“通用多协议标签交换（GMPLS）信令-基于约束的路由标签分发协议（CR-LDP）扩展”，RFC 3472，2003年1月。
[RFC3473] Berger, L., Editor "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，编辑“通用多协议标签交换（GMPLS）信令-资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[GMPLS-RTG] Kompella, K., et al., "Routing Extensions in Support of Generalized MPLS", Work in Progress.
[GMPLS-RTG]Kompella，K.等人，“支持通用MPLS的路由扩展”，正在进行中。
[GMPLS-SONET] Ashwood-Smith, P., et al., "GMPLS - SONET / SDH Specifics", Work in Progress.
[GMPLS-SONET]Ashwood Smith，P.等人，“GMPLS-SONET/SDH规范”，正在进行的工作。
[LMP] Lang, et al., "Link Management Protocol", Work in Progress.
[LMP]Lang等人，“链路管理协议”，正在进行中。
[MPLS-BUNDLE] Kompella, K., Rekhter, Y. and L. Berger, "Link Bundling in MPLS Traffic Engineering", Work in Progress.
[MPLS-BUNDLE]Kompella，K.，Rekhter，Y.和L.Berger，“MPLS流量工程中的链路捆绑”，正在进行中。
[MPLS-HIERARCHY] Kompella, K. and Y. Rekhter, "LSP Hierarchy with MPLS TE", Work in Progress.
[MPLS-HIERARCHY]Kompella，K.和Y.Rekhter，“具有MPLS TE的LSP层次结构”，正在进行中。
[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月。
[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月。
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol label switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
Peter Ashwood-Smith Nortel Networks Corp. P.O. Box 3511 Station C, Ottawa, ON K1Y 4H7 Canada
Peter Ashwood Smith Nortel Networks Corp.邮政信箱3511加拿大渥太华C站K1Y 4H7
Phone: +1 613 763 4534
EMail: petera@nortelnetworks.com
Phone: +1 613 763 4534
EMail: petera@nortelnetworks.com
Ayan Banerjee Calient Networks 5853 Rue Ferrari San Jose, CA 95138
加利福尼亚州圣何塞法拉利街5853号阿扬·班纳吉·卡里昂网络公司，邮编95138
Phone: +1 408 972-3645
EMail: abanerjee@calient.net
Phone: +1 408 972-3645
EMail: abanerjee@calient.net
Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102
Lou Berger Movaz Networks，Inc.地址：弗吉尼亚州麦克莱恩市琼斯支路615号7926室，邮编：22102
Phone: +1 703 847-1801
EMail: lberger@movaz.com
Phone: +1 703 847-1801
EMail: lberger@movaz.com
Greg Bernstein
格雷格·伯恩斯坦
EMail: gregb@grotto-networking.com
EMail: gregb@grotto-networking.com
John Drake Calient Networks 5853 Rue Ferrari San Jose, CA 95138
约翰·德雷克·卡林特网络公司，加利福尼亚州圣何塞法拉利路5853号，邮编95138
Phone: +1 408 972 3720
EMail: jdrake@calient.net
Phone: +1 408 972 3720
EMail: jdrake@calient.net
Yanhe Fan Axiowave Networks, Inc. 200 Nickerson Road Marlborough, MA 01752
延河Fan Axiowave Networks，Inc.马萨诸塞州马尔伯勒尼克松路200号，邮编01752
Phone: + 1 774 348 4627
EMail: yfan@axiowave.com
Phone: + 1 774 348 4627
EMail: yfan@axiowave.com
Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089
Kireeti Kompella Juniper Networks，Inc.加利福尼亚州桑尼维尔市马蒂尔达大道北1194号，邮编94089
EMail: kireeti@juniper.net
EMail: kireeti@juniper.net
Jonathan P. Lang EMail: jplang@ieee.org
Jonathan P.Lang电子邮件：jplang@ieee.org
Eric Mannie Independent Consultant 2 Avenue de la Folle Chanson 1050 Brussels Belgium EMail: eric_mannie@hotmail.com
Eric Mannie独立顾问2 Avenue de la Folle Chanson 1050比利时布鲁塞尔电子邮件：Eric_mannie@hotmail.com
Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901
巴拉·拉贾戈帕兰Tellium，Inc.新泽西州海洋港901号新月广场2号邮政信箱07757-0901
Phone: +1 732 923 4237
Fax: +1 732 923 9804
EMail: braja@tellium.com
Phone: +1 732 923 4237
Fax: +1 732 923 9804
EMail: braja@tellium.com
Yakov Rekhter Juniper Networks, Inc.
雅科夫·雷克特·朱尼珀网络公司。
EMail: yakov@juniper.net
EMail: yakov@juniper.net
Debanjan Saha EMail: debanjan@acm.org
德班詹·萨哈电子邮件：debanjan@acm.org
Vishal Sharma Metanoia, Inc. 1600 Villa Street, Unit 352 Mountain View, CA 94041-1174 Phone: +1 650-386-6723 EMail: v.sharma@ieee.org
Vishal Sharma Metanoia，Inc.加利福尼亚州山景城352单元别墅街1600号94041-1174电话：+1 650-386-6723电子邮件：v。sharma@ieee.org
George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824
乔治斯沃诺思科系统公司，马萨诸塞州切姆斯福德阿波罗大道250号，邮编01824
Phone: +1 978 244 8143
EMail: swallow@cisco.com
Phone: +1 978 244 8143
EMail: swallow@cisco.com
Z. Bo Tang EMail: botang01@yahoo.com
Z.Bo Tang电子邮件：botang01@yahoo.com
Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102
Lou Berger Movaz Networks，Inc.地址：弗吉尼亚州麦克莱恩市琼斯支路615号7926室，邮编：22102
Phone: +1 703 847-1801
EMail: lberger@movaz.com
Phone: +1 703 847-1801
EMail: lberger@movaz.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编辑功能的资金目前由互联网协会提供。