Network Working Group L. Berger, Editor
Request for Comments: 3473 Movaz Networks
Category: Standards Track January 2003
Network Working Group L. Berger, Editor
Request for Comments: 3473 Movaz Networks
Category: Standards Track January 2003
Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions
广义多协议标签交换（GMPLS）信令资源预留协议业务工程（RSVP-TE）扩展
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) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) 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 RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents.
本文档描述了支持通用MPLS所需的多协议标签交换（MPLS）资源预留协议-流量工程（RSVP-TE）信令的扩展。广义MPLS扩展了MPLS控制平面，以涵盖时分（例如，同步光网络和同步数字体系、SONET/SDH）、波长（光lambda）和空间交换（例如，输入端口或光纤到输出端口或光纤）。本文档提供了扩展的RSVP-TE特定描述。通用功能说明可在单独的文档中找到。
Table of Contents
目录
1. Introduction .............................................. 2
2. Label Related Formats .................................... 3
2.1 Generalized Label Request Object ........................ 3
2.2 Bandwidth Encoding ...................................... 4
2.3 Generalized Label Object ................................ 5
2.4 Waveband Switching ...................................... 5
2.5 Suggested Label ......................................... 6
2.6 Label Set ............................................... 7
3. Bidirectional LSPs ........................................ 8
3.1 Procedures .............................................. 9
3.2 Contention Resolution ................................... 9
4. Notification .............................................. 9
4.1 Acceptable Label Set Object ............................. 10
4.2 Notify Request Objects .................................. 10
1. Introduction .............................................. 2
2. Label Related Formats .................................... 3
2.1 Generalized Label Request Object ........................ 3
2.2 Bandwidth Encoding ...................................... 4
2.3 Generalized Label Object ................................ 5
2.4 Waveband Switching ...................................... 5
2.5 Suggested Label ......................................... 6
2.6 Label Set ............................................... 7
3. Bidirectional LSPs ........................................ 8
3.1 Procedures .............................................. 9
3.2 Contention Resolution ................................... 9
4. Notification .............................................. 9
4.1 Acceptable Label Set Object ............................. 10
4.2 Notify Request Objects .................................. 10
4.3 Notify Message .......................................... 12
4.4 Removing State with a PathErr message ................... 14
5. Explicit Label Control .................................... 15
5.1 Label ERO subobject ..................................... 15
5.2 Label RRO subobject ..................................... 16
6. Protection Object ......................................... 17
6.1 Procedures .............................................. 18
7. Administrative Status Information ......................... 18
7.1 Admin Status Object ..................................... 18
7.2 Path and Resv Message Procedures ........................ 18
7.3 Notify Message Procedures ............................... 20
8. Control Channel Separation ................................ 21
8.1 Interface Identification ................................ 21
8.2 Errored Interface Identification ........................ 23
9. Fault Handling ............................................ 25
9.1 Restart_Cap Object ...................................... 25
9.2 Processing of Restart_Cap Object ........................ 26
9.3 Modification to Hello Processing to Support
State Recovery .......................................... 26
9.4 Control Channel Faults .................................. 27
9.5 Nodal Faults ............................................ 27
10. RSVP Message Formats and Handling ......................... 30
10.1 RSVP Message Formats ................................... 30
10.2 Addressing Path and PathTear Messages ................. 32
11. Acknowledgments ........................................... 32
12. Security Considerations ................................... 33
13. IANA Considerations ....................................... 34
13.1 IANA Assignments ....................................... 35
14. Intellectual Property Considerations ...................... 36
15. References ................................................ 37
15.1 Normative References ................................... 37
15.2 Informative References ................................. 38
16. Contributors .............................................. 38
17. Editor's Address .......................................... 41
18. Full Copyright Statement .................................. 42
4.3 Notify Message .......................................... 12
4.4 Removing State with a PathErr message ................... 14
5. Explicit Label Control .................................... 15
5.1 Label ERO subobject ..................................... 15
5.2 Label RRO subobject ..................................... 16
6. Protection Object ......................................... 17
6.1 Procedures .............................................. 18
7. Administrative Status Information ......................... 18
7.1 Admin Status Object ..................................... 18
7.2 Path and Resv Message Procedures ........................ 18
7.3 Notify Message Procedures ............................... 20
8. Control Channel Separation ................................ 21
8.1 Interface Identification ................................ 21
8.2 Errored Interface Identification ........................ 23
9. Fault Handling ............................................ 25
9.1 Restart_Cap Object ...................................... 25
9.2 Processing of Restart_Cap Object ........................ 26
9.3 Modification to Hello Processing to Support
State Recovery .......................................... 26
9.4 Control Channel Faults .................................. 27
9.5 Nodal Faults ............................................ 27
10. RSVP Message Formats and Handling ......................... 30
10.1 RSVP Message Formats ................................... 30
10.2 Addressing Path and PathTear Messages ................. 32
11. Acknowledgments ........................................... 32
12. Security Considerations ................................... 33
13. IANA Considerations ....................................... 34
13.1 IANA Assignments ....................................... 35
14. Intellectual Property Considerations ...................... 36
15. References ................................................ 37
15.1 Normative References ................................... 37
15.2 Informative References ................................. 38
16. Contributors .............................................. 38
17. Editor's Address .......................................... 41
18. Full Copyright Statement .................................. 42
Generalized MPLS extends MPLS from supporting packet (PSC) interfaces and switching to include support of three new classes of interfaces and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and Fiber-Switch (FSC). A functional description of the extensions to MPLS signaling needed to support the new classes of interfaces and switching is provided in [RFC3471]. This document presents RSVP-TE specific formats and mechanisms needed to support all four classes of interfaces.
广义MPLS将MPLS从支持分组（PSC）接口和交换扩展到支持三类新的接口和交换：时分复用（TDM）、Lambda交换机（LSC）和光纤交换机（FSC）。[RFC3471]中提供了支持新型接口和交换所需的MPLS信令扩展的功能描述。本文档介绍了支持所有四类接口所需的RSVP-TE特定格式和机制。
[RFC3471] should be viewed as a companion document to this document. The format of this document parallels [RFC3471]. In addition to the other features of Generalized MPLS, this document also defines RSVP-TE specific features to support rapid failure notification, see Sections 4.2 and 4.3.
[RFC3471]应视为本文件的配套文件。本文件的格式与[RFC3471]相似。除了通用MPLS的其他功能外，本文件还定义了RSVP-TE特定功能，以支持快速故障通知，请参见第4.2节和第4.3节。
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]中所述进行解释。
This section defines formats for a generalized label request, a generalized label, support for waveband switching, suggested label and label sets.
本节定义了通用标签请求、通用标签、波段切换支持、建议标签和标签集的格式。
A Path message SHOULD contain as specific an LSP (Label Switched Path) Encoding Type as possible to allow the maximum flexibility in switching by transit LSRs. A Generalized Label Request object is set by the ingress node, transparently passed by transit nodes, and used by the egress node. The Switching Type field may also be updated hop-by-hop.
路径消息应尽可能包含特定的LSP（标签交换路径）编码类型，以允许通过传输LSR进行最大程度的灵活切换。通用标签请求对象由入口节点设置，由传输节点透明传递，并由出口节点使用。交换类型字段也可以逐跳更新。
The format of a Generalized Label Request object 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (19)| C-Type (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (19)| C-Type (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
有关参数的说明，请参见[RFC3471]。
A node processing a Path message containing a Generalized Label Request must verify that the requested parameters can be satisfied by the interface on which the incoming label is to be allocated, the node itself, and by the interface on which the traffic will be transmitted. The node may either directly support the LSP or it may use a tunnel (FA), i.e., another class of switching. In either case, each parameter must be checked.
处理包含通用标签请求的路径消息的节点必须验证所请求的参数是否可以由要分配传入标签的接口、节点本身以及将在其上传输流量的接口来满足。节点可以直接支持LSP，也可以使用隧道（FA），即另一类交换。无论哪种情况，都必须检查每个参数。
Note that local node policy dictates when tunnels may be used and when they may be created. Local policy may allow for tunnels to be dynamically established or may be solely administratively controlled. For more information on tunnels and processing of ER hops when using tunnels see [MPLS-HIERARCHY].
请注意，本地节点策略规定了何时可以使用隧道以及何时可以创建隧道。当地政策可能允许动态建立隧道，也可能仅受行政控制。有关隧道和使用隧道时ER跃点处理的更多信息，请参阅[MPLS-HIERARCHY]。
Transit and egress nodes MUST verify that the node itself and, where appropriate, that the interface or tunnel on which the traffic will be transmitted can support the requested LSP Encoding Type. If encoding cannot be supported, the node MUST generate a PathErr message, with a "Routing problem/Unsupported Encoding" indication.
中转和出口节点必须验证节点本身以及（在适当情况下）将传输流量的接口或隧道是否支持请求的LSP编码类型。如果不支持编码，则节点必须生成带有“路由问题/不支持编码”指示的PathErr消息。
Nodes MUST verify that the type indicated in the Switching Type parameter is supported on the corresponding incoming interface. If the type cannot be supported, the node MUST generate a PathErr message with a "Routing problem/Switching Type" indication.
节点必须验证相应的传入接口是否支持Switching type参数中指示的类型。如果不支持该类型，则节点必须生成带有“路由问题/切换类型”指示的PathErr消息。
The G-PID parameter is normally only examined at the egress. If the indicated G-PID cannot be supported then the egress MUST generate a PathErr message, with a "Routing problem/Unsupported L3PID" indication. In the case of PSC and when penultimate hop popping (PHP) is requested, the penultimate hop also examines the (stored) G-PID during the processing of the Resv message. In this case if the G-PID is not supported, then the penultimate hop MUST generate a ResvErr message with a "Routing problem/Unacceptable label value" indication. The generated ResvErr message MAY include an Acceptable Label Set, see Section 4.1.
G-PID参数通常仅在出口处检查。如果指示的G-PID不受支持，则出口必须生成一条PathErr消息，并带有“路由问题/不支持的L3PID”指示。在PSC的情况下，当请求倒数第二个跃点弹出（PHP）时，倒数第二个跃点还在处理Resv消息期间检查（存储的）G-PID。在这种情况下，如果不支持G-PID，则倒数第二个跃点必须生成带有“路由问题/不可接受标签值”指示的ResvErr消息。生成的ResvErr消息可能包括可接受的标签集，请参见第4.1节。
When an error message is not generated, normal processing occurs. In the transit case this will typically result in a Path message being propagated. In the egress case and PHP special case this will typically result in a Resv message being generated.
未生成错误消息时，将进行正常处理。在传输情况下，这通常会导致传播路径消息。在出口情况和PHP特殊情况下，这通常会导致生成Resv消息。
Bandwidth encodings are carried in the SENDER_TSPEC and FLOWSPEC objects. See [RFC3471] for a definition of values to be used for specific signal types. These values are set in the Peak Data Rate field of Int-Serv objects, see [RFC2210]. Other bandwidth/service related parameters in the object are ignored and carried transparently.
带宽编码在SENDER_TSPEC和FLOWSPEC对象中进行。有关用于特定信号类型的值的定义，请参见[RFC3471]。这些值在Int Serv对象的峰值数据速率字段中设置，请参见[RFC2210]。对象中的其他带宽/服务相关参数将被忽略并透明地携带。
The format of a Generalized Label object 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (16)| C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (16)| C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters and encoding of labels.
有关参数和标签编码的说明，请参见[RFC3471]。
The Generalized Label travels in the upstream direction in Resv messages.
通用标签在Resv消息中沿上游方向移动。
The presence of both a generalized and normal label object in a Resv message is a protocol error and should treated as a malformed message by the recipient.
Resv消息中同时存在通用和普通标签对象是协议错误，收件人应将其视为格式错误的消息。
The recipient of a Resv message containing a Generalized Label verifies that the values passed are acceptable. If the label is unacceptable then the recipient MUST generate a ResvErr message with a "Routing problem/MPLS label allocation failure" indication.
包含通用标签的Resv消息的收件人验证传递的值是否可接受。如果标签不可接受，则收件人必须生成带有“路由问题/MPLS标签分配失败”指示的ResvErr消息。
Waveband switching uses the same format as the generalized label, see section 2.2. Waveband Label uses C-Type (3),
波段切换使用与通用标签相同的格式，见第2.2节。波段标签使用C型（3），
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (16)| C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (16)| C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Waveband Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
有关参数的说明，请参见[RFC3471]。
The procedures defined in Section 2.3.1 apply to waveband switching. This includes generating a ResvErr message with a "Routing problem/MPLS label allocation failure" indication if any of the label fields are unrecognized or unacceptable.
第2.3.1节中定义的程序适用于波段切换。这包括如果任何标签字段无法识别或不可接受，则生成带有“路由问题/MPLS标签分配失败”指示的ResvErr消息。
Additionally, when a waveband is switched to another waveband, it is possible that the wavelengths within the waveband will be mirrored about a center frequency. When this type of switching is employed, the start and end label in the waveband label object MUST be flipped before forwarding the label object with the new waveband Id. In this manner an egress/ingress LSR which receives a waveband label which has these values inverted, knows that it must also invert its egress association to pick up the proper wavelengths.
此外，当一个波段切换到另一个波段时，该波段内的波长可能会围绕中心频率进行镜像。当采用这种类型的切换时，在转发带有新波段Id的标签对象之前，必须翻转波段标签对象中的起始标签和结束标签。以这种方式，一个出口/入口LSR接收一个倒置了这些值的波段标签，知道它还必须反转其出口关联以拾取适当的波长。
This operation MUST be performed in both directions when a bidirectional waveband tunnel is being established.
当建立双向波段隧道时，必须在两个方向上执行此操作。
The format of a Suggested_Label object is identical to a generalized label. It is used in Path messages. A Suggested_Label object uses Class-Number 129 (of form 10bbbbbb) and the C-Type of the label being suggested.
建议的标签对象的格式与通用标签相同。它用于路径消息中。建议的_标签对象使用类别号129（形式为10bbbbbb）和建议标签的C类型。
Errors in received Suggested_Label objects MUST be ignored. This includes any received inconsistent or unacceptable values.
必须忽略收到的建议标签对象中的错误。这包括收到的任何不一致或不可接受的值。
Per [RFC3471], if a downstream node passes a label value that differs from the suggested label upstream, the upstream LSR MUST either reconfigure itself so that it uses the label specified by the downstream node or generate a ResvErr message with a "Routing
根据[RFC3471]，如果下游节点传递的标签值与建议的上游标签不同，则上游LSR必须重新配置自身，以便使用下游节点指定的标签，或生成带有“路由”的ResvErr消息
problem/Unacceptable label value" indication. Furthermore, an ingress node SHOULD NOT transmit data traffic using a suggested label until the downstream node passes a corresponding label upstream.
问题/不可接受的标签值”指示。此外，入口节点不应使用建议的标签传输数据流量，直到下游节点通过相应的上游标签。
The Label_Set object uses Class-Number 36 (of form 0bbbbbbb) and the C-Type of 1. It is used in Path messages.
Label_Set对象使用类号36（形式为0BBB）和C类型1。它用于路径消息中。
The format of 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (36)| C-Type (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (36)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved | Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel N |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label Type: 14 bits
标签类型：14位
Indicates the type and format of the labels carried in the object. Values match the C-Type of the appropriate RSVP_LABEL object. Only the low order 8 bits are used in this field.
指示对象中包含的标签的类型和格式。值与相应RSVP_标签对象的C类型匹配。此字段中仅使用低阶8位。
See [RFC3471] for a description of other parameters.
有关其他参数的说明，请参见[RFC3471]。
A Label Set is defined via one or more Label_Set objects. Specific labels/subchannels can be added to or excluded from a Label Set via Action zero (0) and one (1) objects respectively. Ranges of labels/subchannels can be added to or excluded from a Label Set via Action two (2) and three (3) objects respectively. When the Label_Set objects only list labels/subchannels to exclude, this implies that all other labels are acceptable.
标签集是通过一个或多个标签集对象定义的。可以分别通过操作零（0）和一（1）个对象向标签集添加或从标签集中排除特定标签/子通道。标签/子通道的范围可以分别通过操作两（2）和三（3）个对象添加到标签集中或从标签集中排除。当“标签集对象”仅列出要排除的标签/子通道时，这意味着所有其他标签都是可接受的。
The absence of any Label_Set objects implies that all labels are acceptable. A Label Set is included when a node wishes to restrict the label(s) that may be used downstream.
没有任何标签集对象意味着所有标签都是可接受的。当节点希望限制可在下游使用的标签时，将包括标签集。
On reception of a Path message, the receiving node will restrict its choice of labels to one which is in the Label Set. Nodes capable of performing label conversion may also remove the Label Set prior to forwarding the Path message. If the node is unable to pick a label from the Label Set or if there is a problem parsing the Label_Set objects, then the request is terminated and a PathErr message with a "Routing problem/Label Set" indication MUST be generated. It is a local matter if the Label Set is stored for later selection on the Resv or if the selection is made immediately for propagation in the Resv.
在接收路径消息时，接收节点将其标签选择限制为标签集中的标签。能够执行标签转换的节点还可以在转发路径消息之前移除标签集。如果节点无法从标签集拾取标签，或者解析标签集对象时出现问题，则请求将终止，并且必须生成带有“路由问题/标签集”指示的PathErr消息。如果存储标签集以供以后在Resv上选择，或者如果立即进行选择以在Resv中传播，则这是一个局部问题。
On reception of a Path message, the Label Set represented in the message is compared against the set of available labels at the downstream interface and the resulting intersecting Label Set is forwarded in a Path message. When the resulting Label Set is empty, the Path must be terminated, and a PathErr message, and a "Routing problem/Label Set" indication MUST be generated. Note that intersection is based on the physical labels (actual wavelength/band values) which may have different logical values on different links, as a result it is the responsibility of the node to map these values so that they have a consistent physical meaning, or to drop the particular values from the set if no suitable logical label value exists.
在接收到路径消息时，将消息中表示的标签集与下游接口处的可用标签集进行比较，并在路径消息中转发生成的相交标签集。当生成的标签集为空时，必须终止路径，并生成PathErr消息和“路由问题/标签集”指示。注意，交叉点基于物理标签（实际波长/波段值），这些物理标签在不同链路上可能具有不同的逻辑值，因此，节点有责任映射这些值，以便它们具有一致的物理含义，或者，如果不存在合适的逻辑标签值，则从集合中删除特定值。
When processing a Resv message at an intermediate node, the label propagated upstream MUST fall within the Label Set.
在中间节点处理Resv消息时，向上游传播的标签必须位于标签集内。
Note, on reception of a Resv message a node that is incapable of performing label conversion has no other choice than to use the same physical label (wavelength/band) as received in the Resv message. In this case, the use and propagation of a Label Set will significantly reduce the chances that this allocation will fail.
注意，在接收到Resv消息时，不能执行标签转换的节点除了使用在Resv消息中接收到的相同物理标签（波长/频带）之外别无选择。在这种情况下，标签集的使用和传播将显著减少分配失败的机会。
Bidirectional LSP setup is indicated by the presence of an Upstream Label in the Path message. An Upstream_Label object has the same format as the generalized label, see Section 2.3. The Upstream_Label object uses Class-Number 35 (of form 0bbbbbbb) and the C-Type of the label being used.
双向LSP设置由路径消息中的上游标签表示。上游标签对象的格式与通用标签相同，请参见第2.3节。上游_标签对象使用类号35（形式为0bbb）和所用标签的C类型。
The process of establishing a bidirectional LSP follows the establishment of a unidirectional LSP with some additions. To support bidirectional LSPs an Upstream_Label object is added to the Path message. The Upstream_Label object MUST indicate a label that is valid for forwarding at the time the Path message is sent.
建立双向LSP的过程在建立带有一些附加的单向LSP之后进行。为了支持双向LSP，在路径消息中添加了一个上游标签对象。上游标签对象必须指示在发送路径消息时可有效转发的标签。
When a Path message containing an Upstream_Label object is received, the receiver first verifies that the upstream label is acceptable. If the label is not acceptable, the receiver MUST issue a PathErr message with a "Routing problem/Unacceptable label value" indication. The generated PathErr message MAY include an Acceptable Label Set, see Section 4.1.
当接收到包含上游标签对象的路径消息时，接收方首先验证上游标签是否可接受。如果标签不可接受，则接收方必须发出带有“路由问题/不可接受标签值”指示的PathErr消息。生成的PathErr消息可能包括可接受的标签集，请参见第4.1节。
An intermediate node must also allocate a label on the outgoing interface and establish internal data paths before filling in an outgoing upstream label and propagating the Path message. If an intermediate node is unable to allocate a label or internal resources, then it MUST issue a PathErr message with a "Routing problem/MPLS label allocation failure" indication.
中间节点还必须在输出接口上分配标签，并在填充输出上游标签和传播路径消息之前建立内部数据路径。如果中间节点无法分配标签或内部资源，则必须发出带有“路由问题/MPLS标签分配失败”指示的PathErr消息。
Terminator nodes process Path messages as usual, with the exception that the upstream label can immediately be used to transport data traffic associated with the LSP upstream towards the initiator.
终止节点像往常一样处理路径消息，但上游标签可立即用于将与LSP上游相关联的数据通信量传输到启动器。
When a bidirectional LSP is removed, both upstream and downstream labels are invalidated and it is no longer valid to send data using the associated labels.
删除双向LSP时，上游和下游标签都将失效，并且使用关联标签发送数据不再有效。
There are two additional contention resolution related considerations when controlling bidirectional LSP setup via RSVP-TE. The first is that for the purposes of RSVP contention resolution, the node ID is the IP address used in the RSVP_HOP object. The second is that a 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.
当通过RSVP-TE控制双向LSP设置时，还有两个额外的与争用解决方案相关的注意事项。首先，为了解决RSVP争用问题，节点ID是RSVP_-HOP对象中使用的IP地址。第二个问题是，在发送初始路径消息时，邻居的节点ID可能未知。出现这种情况时，节点应建议从可用标签空间中随机选择标签。
This section covers several notification related extensions. The first extension defines the Acceptable Label Set object to support Notification on Label Error, per [RFC3471]. The second and third extensions enable expedited notification of failures and other events to nodes responsible for restoring failed LSPs. (The second extension, the Notify Request object, identifies where event
本节介绍几个与通知相关的扩展。根据[RFC3471]，第一个扩展定义了可接受的标签集对象，以支持标签错误通知。第二个和第三个扩展支持向负责恢复故障LSP的节点快速通知故障和其他事件。（第二个扩展名，Notify请求对象，标识事件发生的位置。）
notifications are to be sent. The third extension, the Notify message, provides for general event notification.) The final notification related extension allows for the removal of Path state on handling of PathErr messages.
将发送通知。第三个扩展名Notify message提供一般事件通知。）与通知相关的最终扩展名允许在处理PathErr消息时删除路径状态。
Acceptable_Label_Set objects use a Class-Number 130 (of form 10bbbbbb). The remaining contents of the object, including C-Type, have the identical format as the Label_Set object, see Section 2.6.
可接受的标签集合对象使用类编号130（形式为10BBBB）。对象的其余内容（包括C-Type）的格式与标签集对象的格式相同，请参见第2.6节。
Acceptable_Label_Set objects may be carried in PathErr and ResvErr messages. The procedures for defining an Acceptable Label Set follow the procedures for defining a Label Set, see Section 2.6.1. Specifically, an Acceptable Label Set is defined via one or more Acceptable_Label_Set objects. Specific labels/subchannels can be added to or excluded from an Acceptable Label Set via Action zero (0) and one (1) objects respectively. Ranges of labels/subchannels can be added to or excluded from an Acceptable Label Set via Action two (2) and three (3) objects respectively. When the Acceptable_Label_Set objects only list labels/subchannels to exclude, this implies that all other labels are acceptable.
PathErr和ResvErr消息中可能包含可接受的标签集对象。定义可接受标签集的程序遵循定义标签集的程序，见第2.6.1节。具体而言，可接受标签集是通过一个或多个可接受标签集对象定义的。可以分别通过操作零（0）和一（1）个对象将特定标签/子通道添加到可接受的标签集中或从中排除。标签/子通道的范围可以分别通过操作两（2）和三（3）个对象添加到可接受的标签集中或从中排除。如果可接受的标签集对象仅列出要排除的标签/子通道，这意味着所有其他标签都是可接受的。
The inclusion of Acceptable_Label_Set objects is optional. If included, the PathErr or ResvErr message SHOULD contain a "Routing problem/Unacceptable label value" indication. The absence of Acceptable_Label_Set objects does not have any specific meaning.
包含可接受的标签集对象是可选的。如果包含，PathErr或ResvErr消息应包含“路由问题/不可接受的标签值”指示。缺少可接受的标签集对象没有任何特定含义。
Notifications may be sent via the Notify message defined below. The Notify Request object is used to request the generation of notifications. Notifications, i.e., the sending of a Notify message, may be requested in both the upstream and downstream directions.
通知可以通过下面定义的通知消息发送。Notify Request对象用于请求生成通知。可以在上游和下游方向上请求通知，即发送通知消息。
The Notify Request Object may be carried in Path or Resv Messages, see Section 7. The Notify_Request Class-Number is 195 (of form 11bbbbbb). The format of a Notify Request is:
Notify请求对象可以在Path或Resv消息中携带，请参见第7节。Notify_请求类别编号为195（表格11BBBB）。通知请求的格式为：
o IPv4 Notify Request Object
o IPv4通知请求对象
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 (1) | C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Notify Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (1) | C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Notify Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Notify Node Address: 32 bits
IPv4通知节点地址：32位
The IP address of the node that should be notified when generating an error message.
生成错误消息时应通知的节点的IP地址。
o IPv6 Notify Request Object
o IPv6通知请求对象
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 (2) | C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Notify Node Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (2) | C-Type (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Notify Node Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Notify Node Address: 16 bytes
IPv6通知节点地址：16字节
The IP address of the node that should be notified when generating an error message.
生成错误消息时应通知的节点的IP地址。
If a message contains multiple Notify_Request objects, only the first object is meaningful. Subsequent Notify_Request objects MAY be ignored and SHOULD NOT be propagated.
如果消息包含多个Notify_请求对象，则只有第一个对象有意义。随后的Notify_请求对象可能会被忽略，不应传播。
A Notify Request object may be inserted in Path or Resv messages to indicate the address of a node that should be notified of an LSP failure. As previously mentioned, notifications may be requested in both the upstream and downstream directions. Upstream notification is indicated via the inclusion of a Notify Request Object in the corresponding Path message. Downstream notification is indicated via the inclusion of a Notify Request Object in the corresponding Resv message.
可以在Path或Resv消息中插入Notify Request对象，以指示应被通知LSP故障的节点的地址。如前所述，可以在上游和下游方向上请求通知。上游通知通过在相应的路径消息中包含Notify请求对象来指示。下游通知通过在相应的Resv消息中包含Notify请求对象来指示。
A node receiving a message containing a Notify Request object SHOULD store the Notify Node Address in the corresponding state block. If the node is a transit node, it SHOULD also included a Notify Request object in the outgoing Path or Resv message. The outgoing Notify Node Address MAY be updated based on local policy.
接收包含Notify请求对象的消息的节点应将Notify节点地址存储在相应的状态块中。如果该节点是传输节点，则它还应在传出路径或Resv消息中包含Notify请求对象。可以基于本地策略更新传出通知节点地址。
Note that the inclusion of a Notify Request object does not guarantee that a Notify message will be generated.
请注意，包含Notify请求对象并不保证将生成Notify消息。
The Notify message provides a mechanism to inform non-adjacent nodes of LSP related events. Notify messages are normally generated only after a Notify Request object has been received. The Notify message differs from the currently defined error messages (i.e., PathErr and ResvErr messages) in that it can be "targeted" to a node other than the immediate upstream or downstream neighbor and that it is a generalized notification mechanism. The Notify message does not replace existing error messages. The Notify message may be sent either (a) normally, where non-target nodes just forward the Notify message to the target node, similar to ResvConf processing in [RFC2205]; or (b) encapsulated in a new IP header whose destination is equal to the target IP address. Regardless of the transmission mechanism, nodes receiving a Notify message not destined to the node forward the message, unmodified, towards the target.
Notify消息提供了一种机制，用于将LSP相关事件通知非相邻节点。通知消息通常仅在收到通知请求对象后生成。Notify消息与当前定义的错误消息（即PathErr和ResvErr消息）的不同之处在于，它可以“定向”到除直接上游或下游邻居之外的节点，并且它是一种通用的通知机制。通知消息不会替换现有的错误消息。通知消息可以（a）正常发送，其中非目标节点只是将通知消息转发给目标节点，类似于[RFC2205]中的ResvConf处理；或者（b）封装在目的地等于目标IP地址的新IP报头中。无论传输机制如何，接收到非目的地为节点的通知消息的节点都会将未经修改的消息转发到目标。
To support reliable delivery of the Notify message, an Ack Message [RFC2961] is used to acknowledge the receipt of a Notify Message. See [RFC2961] for details on reliable RSVP message delivery.
为了支持Notify消息的可靠传递，Ack消息[RFC2961]用于确认收到Notify消息。有关可靠RSVP消息传递的详细信息，请参阅[RFC2961]。
The Notify message is a generalized notification message. The IP destination address is set to the IP address of the intended receiver. The Notify message is sent without the router alert option. A single Notify message may contain notifications being sent, with respect to each listed session, both upstream and downstream.
通知消息是一个通用通知消息。IP目标地址设置为预期接收器的IP地址。发送通知消息时不使用路由器警报选项。单个Notify消息可能包含针对每个列出的会话（上游和下游）发送的通知。
The Notify message has a Message Type of 21. The Notify message format is as follows:
通知消息的消息类型为21。通知消息格式如下：
<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> [ <ADMIN_STATUS> ]
[<POLICY_DATA>...]
<sender descriptor>
<upstream notify session> ::= <SESSION> [ <ADMIN_STATUS> ]
[<POLICY_DATA>...]
<sender descriptor>
<downstream notify session> ::= <SESSION> [<POLICY_DATA>...]
<flow descriptor list>
<downstream notify session> ::= <SESSION> [<POLICY_DATA>...]
<flow descriptor list>
The ERROR_SPEC object specifies the error and includes the IP address of either the node that detected the error or the link that has failed. See ERROR_SPEC definition in [RFC2205]. The MESSAGE_ID and related objects are defined in [RFC2961] and are used when [RFC2961] is supported.
ERROR_SPEC对象指定错误，并包括检测到错误的节点或失败的链接的IP地址。请参阅[RFC2205]中的错误规格定义。消息_ID和相关对象在[RFC2961]中定义，并在支持[RFC2961]时使用。
Notify messages are most commonly generated at nodes that detect an error that will trigger the generation of a PathErr or ResvErr message. If a PathErr message is to be generated and a Notify Request object has been received in the corresponding Path message, then a Notify message destined to the recorded node SHOULD be generated. If a ResvErr message is to be generated and a Notify Request object has been received in the corresponding Resv message, then a Notify message destined to the recorded node SHOULD be generated. As previously mentioned, a single error may generate a Notify message in both the upstream and downstream directions. Note that a Notify message MUST NOT be generated unless an appropriate Notify Request object has been received.
通知消息通常在检测到将触发生成PathErr或ResvErr消息的错误的节点上生成。如果要生成PathErr消息，并且在相应的Path消息中接收到Notify Request对象，则应生成发送到记录节点的Notify消息。如果要生成ResvErr消息，并且在相应的Resv消息中已接收到Notify Request对象，则应生成目的地为记录节点的Notify消息。如前所述，单个错误可在上游和下游方向上生成通知消息。请注意，除非收到适当的Notify请求对象，否则不得生成Notify消息。
When generating Notify messages, a node SHOULD attempt to combine notifications being sent to the same Notify Node and that share the same ERROR_SPEC into a single Notify message. The means by which a node determines which information may be combined is implementation dependent. Implementations may use event, timer based or other approaches. If using a timer based approach, the implementation SHOULD allow the user to configure the interval over which notifications are combined. When using a timer based approach, a default "notification interval" of 1 ms SHOULD be used. Notify messages SHOULD be delivered using the reliable message delivery mechanisms defined in [RFC2961].
生成通知消息时，节点应尝试将发送到同一通知节点且共享相同错误规范的通知合并到单个通知消息中。节点确定可以组合哪些信息的方法取决于实现。实现可以使用事件、基于计时器或其他方法。如果使用基于计时器的方法，则实现应允许用户配置组合通知的时间间隔。使用基于计时器的方法时，应使用1 ms的默认“通知间隔”。应使用[RFC2961]中定义的可靠消息传递机制传递通知消息。
Upon receiving a Notify message, the Notify Node SHOULD send a corresponding Ack message.
在接收到Notify消息后，Notify节点应发送相应的Ack消息。
The PathErr message as defined in [RFC2205] is sent hop-by-hop to the source of the associated Path message. Intermediate nodes may inspect this message, but take no action upon it. In an environment where Path messages are routed according to an IGP and that route may change dynamically, this behavior is a fine design choice.
[RFC2205]中定义的PathErr消息逐跳发送到相关路径消息的源。中间节点可以检查此消息，但不对其执行任何操作。在根据IGP路由路径消息且路由可能动态更改的环境中，此行为是一个很好的设计选择。
However, when RSVP is used with explicit routes, it is often the case that errors can only be corrected at the source node or some other node further upstream. In order to clean up resources, the source must receive the PathErr and then either send a PathTear (or wait for the messages to timeout). This causes idle resources to be held longer than necessary and increases control message load. In a situation where the control plane is attempting to recover from a serious outage, both the message load and the delay in freeing resources hamper the ability to rapidly reconverge.
然而，当RSVP与显式路由一起使用时，通常情况下只能在源节点或更上游的某个其他节点处更正错误。为了清理资源，源必须接收PathErr，然后发送PathTear（或等待消息超时）。这会导致空闲资源的保留时间超过必要时间，并增加控制消息负载。在控制平面试图从严重中断中恢复的情况下，消息负载和释放资源的延迟都会妨碍快速重新聚合的能力。
The situation can be greatly improved by allowing state to be removed by intermediate nodes on certain error conditions. To facilitate this a new flag is defined in the ERROR_SPEC object. The two currently defined ERROR_SPEC objects (IPv4 and IPv6 error spec objects) each contain a one byte flag field. Within that field two flags are defined. This specification defines a third flag, 0x04, Path_State_Removed.
通过允许中间节点在某些错误条件下删除状态，可以极大地改善这种情况。为了方便这一点，在ERROR_SPEC对象中定义了一个新标志。当前定义的两个错误规范对象（IPv4和IPv6错误规范对象）均包含一个单字节标志字段。在该字段中定义了两个标志。本规范定义了第三个标志0x04，即路径状态已删除。
The semantics of the Path_State_Removed flag are simply that the node forwarding the error message has removed the Path state associated with the PathErr. By default, the Path_State_Removed flag is always set to zero when generating or forwarding a PathErr message. A node which encounters an error MAY set this flag if the error results in the associated Path state being discarded. If the node setting the flag is not the session endpoint, the node SHOULD generate a corresponding PathTear. A node receiving a PathErr message containing an ERROR_SPEC object with the Path_State_Removed flag set MAY also remove the associated Path state. If the Path state is removed the Path_State_Removed flag SHOULD be set in the outgoing PathErr message. A node which does not remove the associated Path state MUST NOT set the Path_State_Removed flag. A node that receives an error with the Path_State_Removed flag set to zero MUST NOT set this flag unless it also generates a corresponding PathTear message.
Path_State_Removed标志的语义只是转发错误消息的节点删除了与PathErr关联的路径状态。默认情况下，在生成或转发PathErr消息时，Path_State_Removed标志始终设置为零。遇到错误的节点可以设置此标志，如果该错误导致丢弃关联的路径状态。如果设置标志的节点不是会话端点，则该节点应生成相应的PathTear。接收到包含错误规范对象的PathErr消息的节点（设置了Path\u State\u Removed标志）也可以删除关联的路径状态。如果路径状态已删除，则应在传出PathErr消息中设置Path_state_removed标志。未移除关联路径状态的节点不得设置路径状态移除标志。接收到错误且Path_State_Removed标志设置为零的节点不得设置此标志，除非它还生成相应的Path催泪消息。
Note that the use of this flag does not result in any interoperability incompatibilities.
请注意，使用此标志不会导致任何互操作性不兼容。
The Label ERO (Explicit Route Object) and RRO (Record Route Object) subobjects are defined to support Explicit Label Control. Note that the Label RRO subobject was defined in [RFC3209] and is being extended to support bidirectional LSPs.
定义标签ERO（显式路由对象）和RRO（记录路由对象）子对象以支持显式标签控制。请注意，标签RRO子对象在[RFC3209]中定义，并且正在扩展以支持双向LSP。
The Label ERO subobject is defined as follows:
标签ERO子对象定义如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length |U| Reserved | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length |U| Reserved | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of L, U and Label parameters.
有关L、U和标签参数的说明，请参见[RFC3471]。
Type
类型
3 Label
3标签
Length
长
The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is always divisible by 4.
长度包含子对象的总长度（字节），包括类型和长度字段。长度总是可以被4整除。
C-Type
C型
The C-Type of the included Label Object. Copied from the Label Object.
包含的标签对象的C类型。从标签对象复制。
The Label subobject follows a subobject containing the IP address, or the interface identifier [RFC3477], associated with the link on which it is to be used. Up to two label subobjects may be present, one for the downstream label and one for the upstream label. The following SHOULD result in "Bad EXPLICIT_ROUTE object" errors:
标签子对象位于包含IP地址或接口标识符[RFC3477]的子对象之后，该子对象与要在其上使用的链接关联。最多可以存在两个标签子对象，一个用于下游标签，一个用于上游标签。以下情况应导致“错误的显式路由对象”错误：
o If the first label subobject is not preceded by a subobject containing an IP address, or an interface identifier [RFC3477], associated with an output link.
o 如果第一个标签子对象前面没有包含与输出链接关联的IP地址或接口标识符[RFC3477]的子对象。
o For a label subobject to follow a subobject that has the L-bit set
o 使标签子对象跟随具有L位集的子对象
o On unidirectional LSP setup, for there to be a label subobject with the U-bit set
o 在单向LSP设置中，将有一个带有U位集的标签子对象
o For there to be two label subobjects with the same U-bit values
o 有两个标签子对象具有相同的U位值
To support the label subobject, a node must check to see if the subobject following its associate address/interface is a label subobject. If it is, one subobject is examined for unidirectional LSPs and two subobjects for bidirectional LSPs. If the U-bit of the subobject being examined is clear (0), then value of the label is copied into a new Label_Set object. This Label_Set object MUST be included on the corresponding outgoing Path message.
要支持标签子对象，节点必须检查其关联地址/接口后面的子对象是否为标签子对象。如果是，则检查一个子对象是否为单向LSP，检查两个子对象是否为双向LSP。如果正在检查的子对象的U位为清除（0），则标签的值将复制到新的标签集对象中。此标签集对象必须包含在相应的传出路径消息中。
If the U-bit of the subobject being examined is set (1), then value of the label is label to be used for upstream traffic associated with the bidirectional LSP. If this label is not acceptable, a "Bad EXPLICIT_ROUTE object" error SHOULD be generated. If the label is acceptable, the label is copied into a new Upstream_Label object. This Upstream_Label object MUST be included on the corresponding outgoing Path message.
如果正在检查的子对象的U位被设置为（1），则标签的值是用于与双向LSP相关联的上游业务的标签。如果此标签不可接受，则应生成“错误的显式路由对象”错误。如果标签可接受，则将标签复制到新的上游标签对象中。此上游标签对象必须包含在相应的传出路径消息中。
After processing, the label subobjects are removed from the ERO.
处理后，标签子对象将从ERO中删除。
Note an implication of the above procedures is that the label subobject should never be the first subobject in a newly received message. If the label subobject is the the first subobject an a received ERO, then it SHOULD be treated as a "Bad strict node" error.
注意：上述过程的一个含义是，标签子对象永远不应该是新接收消息中的第一个子对象。如果标签子对象是接收到的ERO的第一个子对象，则应将其视为“错误严格节点”错误。
Procedures by which an LSR at the head-end of an LSP obtains the information needed to construct the Label subobject are outside the scope of this document.
LSP前端的LSR获取构造标签子对象所需信息的过程不在本文档范围内。
The Label RRO subobject is defined as follows:
标签RRO子对象定义如下：
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 |U| Flags | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |U| Flags | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of U and Label parameters.
有关U和标签参数的说明，请参见[RFC3471]。
Type
类型
3 Label
3标签
Length
长
See [RFC3209].
见[RFC3209]。
Flags
旗帜
See [RFC3209].
见[RFC3209]。
C-Type
C型
The C-Type of the included Label Object. Copied from the Label Object.
包含的标签对象的C类型。从标签对象复制。
Label RRO subobjects are included in RROs as described in [RFC3209]. The only modification to usage and processing from [RFC3209] is that when labels are recorded for bidirectional LSPs, label ERO subobjects for both downstream and upstream labels MUST be included.
标签RRO子对象包含在RRO中，如[RFC3209]所述。[RFC3209]对使用和处理的唯一修改是，当为双向LSP记录标签时，必须包括下游和上游标签的标签ERO子对象。
The use of the Protection Object is optional. The object is included to indicate specific protection attributes of an LSP. The Protection Object uses Class-Number 37 (of form 0bbbbbbb).
保护对象的使用是可选的。包含该对象是为了指示LSP的特定保护属性。保护对象使用类别编号37（形式为0BBB）。
The format of the Protection Object 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (37)| C-Type (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (37)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
有关参数的说明，请参见[RFC3471]。
Transit nodes processing a Path message containing a Protection Object MUST verify that the requested protection can be satisfied by the outgoing interface or tunnel (FA). If it cannot, the node MUST generate a PathErr message, with a "Routing problem/Unsupported Link Protection" indication.
处理包含保护对象的路径消息的传输节点必须验证传出接口或隧道（FA）是否能够满足请求的保护。如果不能，则节点必须生成一条PathErr消息，并带有“路由问题/不支持的链接保护”指示。
Administrative Status Information is carried in the Admin_Status object. The object provides information related to the administrative state of a particular LSP. The information is used in two ways. In the first, the object is carried in Path and Resv messages to indicate the administrative state of an LSP. In the second, the object is carried in a Notification message to request that the ingress node change the administrative state of an LSP.
管理状态信息包含在Admin_Status对象中。该对象提供与特定LSP的管理状态相关的信息。这些信息有两种用途。在第一种情况下，对象携带在Path和Resv消息中，以指示LSP的管理状态。在第二种情况下，在通知消息中携带该对象以请求入口节点改变LSP的管理状态。
The use of the Admin_Status Object is optional. It uses Class-Number 196 (of form 11bbbbbb).
使用Admin_Status对象是可选的。它使用类别号196（表格11BBBB）。
The format of the Admin_Status Object is:
Admin_Status对象的格式为：
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(196)| C-Type (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(196)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of parameters.
有关参数的说明，请参见[RFC3471]。
The Admin_Status object is used to notify each node along the path of the status of the LSP. Status information is processed by each node based on local policy and then propagated in the corresponding outgoing messages. The object may be inserted in either Path or Resv messages at the discretion of the ingress (for Path messages) or egress (for Resv messages) nodes. The absence of the object is equivalent to receiving an object containing values all set to zero (0).
Admin_Status对象用于通知路径上的每个节点LSP的状态。状态信息由每个节点根据本地策略进行处理，然后在相应的传出消息中传播。根据入口（对于路径消息）或出口（对于Resv消息）节点的判断，可以将对象插入路径或Resv消息中。缺少该对象相当于接收一个包含所有设置为零（0）的值的对象。
Transit nodes receiving a non-refresh Path or Resv message containing an Admin_Status object, update their local state, take any appropriate local action based on the indicated status and then propagate the received Admin_Status object in the corresponding outgoing Path or Resv message. If the values of an Admin_Status object received in a Resv message differs from the values received in a Path message then, with one exception, no local action should be taken but the values should still be propagated. The one case where values received in the Resv message should result in local action is when both the received R and D bits are set, i.e., are one (1).
接收包含Admin_状态对象的非刷新路径或Resv消息的传输节点，更新其本地状态，根据指示的状态采取任何适当的本地操作，然后在相应的传出路径或Resv消息中传播接收到的Admin_状态对象。如果在Resv消息中接收到的Admin_Status对象的值与在Path消息中接收到的值不同，则除了一个例外，不应采取任何本地操作，但仍应传播这些值。在Resv消息中接收到的值应导致本地操作的一种情况是当接收到的R和D位都被设置时，即为一（1）。
Edge nodes receiving a non-refresh Path or Resv message containing an Admin_Status object, also update their local state and take any appropriate local action based on the indicated status. When an Admin Status object is received with the R bit set, the receiving edge node should reflect the received values in a corresponding outgoing message. Specifically, if an egress node receives a Path message with the R bit of the Admin_Status object set and the node has previously issued a Resv message corresponding to the Path message, the node SHOULD send an updated Resv message containing an Admin_Status object with the same values set, with the exception of the R bit, as received in the corresponding Path message. Furthermore, the egress node SHOULD also ensure that subsequent Resv messages sent by the node contain the same Admin Status Object.
接收到包含Admin_Status对象的非刷新路径或Resv消息的边缘节点也会更新其本地状态，并根据指示的状态采取任何适当的本地操作。当使用设置的R位接收管理状态对象时，接收边缘节点应在相应的传出消息中反映接收到的值。具体地说，如果出口节点接收到设置了Admin_状态对象的R位的Path消息，并且该节点之前已经发出了与Path消息相对应的Resv消息，则该节点应发送更新的Resv消息，其中包含设置了相同值的Admin_状态对象，但R位除外，在相应的路径消息中接收。此外，出口节点还应确保节点发送的后续Resv消息包含相同的管理状态对象。
Additionally, if an ingress node receives a Resv message with the R bit of the Admin_Status object set, the node SHOULD send an updated Path message containing an Admin_Status object with the same values set, with the exception of the R bit, as received in the corresponding Resv message. Furthermore, the ingress node SHOULD also ensure that subsequent Path messages sent by the node contain the same Admin Status Object.
此外，如果入口节点接收到设置了Admin_Status对象的R位的Resv消息，则该节点应发送一条更新的路径消息，其中包含一个Admin_Status对象，该对象的值设置与相应的Resv消息中接收到的值相同（R位除外）。此外，入口节点还应确保节点发送的后续路径消息包含相同的管理状态对象。
In some circumstances, particularly optical networks, it is useful to set the administrative status of an LSP before tearing it down. In such circumstances the procedure SHOULD be followed when deleting an LSP from the ingress:
在某些情况下，尤其是在光纤网络中，在拆除LSP之前设置LSP的管理状态非常有用。在这种情况下，从入口删除LSP时应遵循以下程序：
1. The ingress node precedes an LSP deletion by inserting an Admin Status Object in a Path message and setting the Reflect (R) and Delete (D) bits.
1. 入口节点通过在路径消息中插入Admin Status对象并设置Reflect（R）和Delete（D）位，在LSP删除之前进行操作。
2. Transit and egress nodes process the Admin Status Object as described above. (Alternatively, the egress MAY respond with a PathErr message with the Path_State_Removed flag set, see section 4.4.)
2. 传输和出口节点如上所述处理管理状态对象。（或者，出口可以使用设置了Path_State_Removed标志的PathErr消息进行响应，请参见第4.4节。）
3. Upon receiving the Admin Status Object with the Delete (D) bit set in the Resv message, the ingress node sends a PathTear message downstream to remove the LSP and normal RSVP processing takes place.
3. 当接收到在Resv消息中设置了Delete（D）位的Admin Status对象时，入口节点向下游发送pathtreal消息以移除LSP，并进行正常的RSVP处理。
In such circumstances the procedure SHOULD be followed when deleting an LSP from the egress:
在这种情况下，从出口删除LSP时应遵循以下程序：
1. The egress node indicates its desire for deletion by inserting an Admin Status Object in a Resv message and setting the Reflect (R) and Delete (D) bits.
1. 出口节点通过在Resv消息中插入Admin Status对象并设置Reflect（R）和Delete（D）位来指示其删除愿望。
2. Transit nodes process the Admin Status Object as described above.
2. 传输节点如上所述处理管理状态对象。
3. Upon receiving the Admin Status Object with the Delete (D) bit set in the Resv message, the ingress node sends a PathTear message downstream to remove the LSP and normal RSVP processing takes place.
3. 当接收到在Resv消息中设置了Delete（D）位的Admin Status对象时，入口节点向下游发送pathtreal消息以移除LSP，并进行正常的RSVP处理。
It is possible that some nodes along an LSP will not support the Admin Status Object. In the case of a non-supporting transit node, the object will pass through the node unmodified and normal processing can continue. In the case of a non-supporting egress node, the Admin Status Object will not be reflected back in the Resv Message. To support the case of a non-supporting egress node, the ingress SHOULD only wait a configurable period of time for the updated Admin Status Object in a Resv message. Once the period of time has elapsed, the ingress node sends a PathTear message. By default this period of time SHOULD be 30 seconds.
LSP上的某些节点可能不支持Admin Status对象。在不支持传输节点的情况下，对象将在未修改的情况下通过该节点，并且可以继续正常处理。在不支持出口节点的情况下，管理状态对象不会反映回Resv消息中。为了支持不支持出口节点的情况，入口应仅等待Resv消息中更新的管理状态对象的可配置时间段。一段时间过后，入口节点将发送一条PathTear消息。默认情况下，此时间段应为30秒。
Intermediate and egress nodes may trigger the setting of administrative status via the use of Notify messages. To accomplish this, an intermediate or egress node generates a Notify message with the corresponding upstream notify session information. The Admin Status Object MUST be included in the session information, with the appropriate bit or bits set. The Reflect (R) bit MUST NOT be set. The Notify message may be, but is not required to be, encapsulated, see Section 4.3.
中间和出口节点可通过使用通知消息触发管理状态的设置。为了实现这一点，中间或出口节点生成具有相应上游通知会话信息的通知消息。管理状态对象必须包含在会话信息中，并设置适当的位。不得设置反射（R）位。Notify消息可以封装，但无需封装，见第4.3节。
An ingress node receiving a Notify message containing an Admin Status Object with the Delete (D) bit set, SHOULD initiate the deletion procedure described in the previous section. Other bits SHOULD be propagated in an outgoing Path message as normal.
入口节点接收到包含管理员状态对象且设置了删除（D）位的Notify消息时，应启动上一节中描述的删除过程。其他位应按正常方式在传出路径消息中传播。
Some special processing is required in order to cover the case of nodes that do not support the Admin Status Object and other error conditions. Specifically, a node that sends a Notify message containing an Admin Status Object with the Down (D) bit set MUST verify that it receives a corresponding Path message with the Down (D) bit set within a configurable period of time. By default this period of time SHOULD be 30 seconds. If the node does not receive such a Path message, it SHOULD send a PathTear message downstream and either a ResvTear message or a PathErr message with the Path_State_Removed flag set upstream.
需要进行一些特殊处理，以涵盖不支持Admin Status对象和其他错误条件的节点的情况。具体而言，发送包含设置了Down（D）位的管理状态对象的Notify消息的节点必须验证它是否在可配置的时间段内接收到设置了Down（D）位的相应路径消息。默认情况下，此时间段应为30秒。如果节点未接收到此类Path消息，则应向下游发送PathTear消息，并向上游发送ResvTear消息或设置了Path_State_Removed标志的PathErr消息。
This section provides the protocol specific formats and procedures to required support a control channel not being in-band with a data channel.
本节提供了协议特定格式和程序，以支持不在数据通道频带内的控制通道。
The choice of the data interface to use is always made by the sender of the Path message. The choice of the data interface is indicated by the sender of the Path message by including the data channel's interface identifier in the message using a new RSVP_HOP object sub-type. For bidirectional LSPs, the sender chooses the data interface in each direction. In all cases but bundling, the upstream interface is implied by the downstream interface. For bundling, the path sender explicitly identifies the component interface used in each direction. The new RSVP_HOP object is used in Resv message to indicate the downstream node's usage of the indicated interface(s).
要使用的数据接口的选择始终由Path消息的发送者进行。数据接口的选择由Path消息的发送方通过使用新的RSVP_-HOP对象子类型在消息中包括数据通道的接口标识符来指示。对于双向LSP，发送方选择每个方向的数据接口。在除捆绑之外的所有情况下，上游接口由下游接口暗示。对于捆绑，路径发送器明确标识每个方向上使用的组件接口。新的RSVP_HOP对象用于Resv消息中，以指示下游节点对所指示接口的使用。
The format of the IPv4 IF_ID RSVP_HOP Object is:
IPv4 IF_ID RSVP_HOP对象的格式为：
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 (3) | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Next/Previous Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (3) | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Next/Previous Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the IPv6 IF_ID RSVP_HOP Object is:
IPv6 IF_ID RSVP_HOP对象的格式为：
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 (3) | C-Type (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Next/Previous Hop Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (3) | C-Type (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Next/Previous Hop Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC2205] for a description of hop address and handle fields. See [RFC3471] for a description of parameters and encoding of TLVs.
有关跃点地址和句柄字段的说明，请参见[RFC2205]。有关TLV的参数和编码说明，请参见[RFC3471]。
An IF_ID RSVP_HOP object is used in place of previously defined RSVP_HOP objects. It is used on links where there is not a one-to-one association of a control channel to a data channel, see [RFC3471]. The Hop Address and Logical Interface Handle fields are used per standard RSVP [RFC2205].
使用IF_ID RSVP_HOP对象代替先前定义的RSVP_HOP对象。它用于控制通道与数据通道之间没有一对一关联的链路，请参见[RFC3471]。跃点地址和逻辑接口句柄字段根据标准RSVP[RFC2205]使用。
TLVs are used to identify the data channel(s) associated with an LSP. For a unidirectional LSP, a downstream data channel MUST be indicated. For bidirectional LSPs, a common downstream and upstream data channel is normally indicated. In the special case where a bidirectional LSP that traverses a bundled link, it is possible to specify a downstream data channel that differs from the upstream data channel. Data channels are specified from the viewpoint of the sender of the Path message. The IF_ID RSVP_HOP object SHOULD NOT be used when no TLVs are needed.
TLV用于识别与LSP关联的数据通道。对于单向LSP，必须指示下游数据通道。对于双向LSP，通常指示一个公共的下行和上行数据信道。在穿越捆绑链路的双向LSP的特殊情况下，可以指定不同于上游数据信道的下游数据信道。从路径消息的发送者的角度指定数据通道。如果不需要TLV，则不应使用IF_ID RSVP_HOP对象。
A node receiving one or more TLVs in a Path message saves their values and returns them in the HOP objects of subsequent Resv messages sent to the node that originated the TLVs.
在路径消息中接收一个或多个TLV的节点保存其值，并在发送到发起TLV的节点的后续Resv消息的跃点对象中返回这些值。
Note, the node originating an IF_ID object MUST ensure that the selected outgoing interface, as specified in the IF_ID object, is consistent with an ERO. A node that receives an IF_ID object SHOULD check whether the information carried in this object is consistent with the information carried in a received ERO, and if not it MUST send a PathErr Message with the error code "Routing Error" and error value of "Bad Explicit Route Object" toward the sender. This check CANNOT be performed when the initial ERO subobject is not the incoming interface.
注意，发起IF_ID对象的节点必须确保IF_ID对象中指定的选定传出接口与ERO一致。接收IF_ID对象的节点应检查此对象中携带的信息是否与接收到的ERO中携带的信息一致，如果不一致，则必须向发送方发送一条错误代码为“路由错误”且错误值为“错误显式路由对象”的PathErr消息。当初始ERO子对象不是传入接口时，无法执行此检查。
There are cases where it is useful to indicate a specific interface associated with an error. To support these cases the IF_ID ERROR_SPEC Objects are defined.
在某些情况下，指示与错误关联的特定接口很有用。为了支持这些情况，定义了IF_ID ERROR_SPEC对象。
The format of the IPv4 IF_ID ERROR_SPEC Object is:
IPv4 IF\u ID ERROR\u SPEC对象的格式为：
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 (6) | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Error Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (6) | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Error Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the IPv6 IF_ID ERROR_SPEC Object is:
IPv6 IF\u ID ERROR\u SPEC对象的格式为：
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 (6) | C-Type (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Error Node Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num (6) | C-Type (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Error Node Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Error Code | Error Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC2205] for a description of address, flags, error code and error value fields. See [RFC3471] for a description of parameters and encoding of TLVs.
有关地址、标志、错误代码和错误值字段的说明，请参见[RFC2205]。有关TLV的参数和编码说明，请参见[RFC3471]。
Nodes wishing to indicate that an error is related to a specific interface SHOULD use the appropriate IF_ID ERROR_SPEC Object in the corresponding PathErr or ResvErr message. IF_ID ERROR_SPEC Objects SHOULD be generated and processed as any other ERROR_SPEC Object, see [RFC2205].
希望指示错误与特定接口相关的节点应在相应的PathErr或ResvErr消息中使用适当的IF_ID error_SPEC对象。如果_ID ERROR_SPEC对象应作为任何其他ERROR_SPEC对象生成和处理，请参阅[RFC2205]。
The handling of two types of control communication faults is described in this section. The first, referred to as nodal faults, relates to the case where a node losses its control state (e.g., after a restart) but does not loose its data forwarding state. In the second, referred to as control channel faults, relates to the case where control communication is lost between two nodes. The handling of both faults is supported by the Restart_Cap object defined below and require the use of Hello messages.
本节描述了两种控制通信故障的处理。第一种被称为节点故障，与节点失去其控制状态（例如，重启后）但没有失去其数据转发状态的情况有关。在第二种情况中，称为控制信道故障，涉及两个节点之间的控制通信丢失的情况。下面定义的Restart_Cap对象支持处理这两个故障，并且需要使用Hello消息。
Note, the Restart_Cap object MUST NOT be sent when there is no mechanism to detect data channel failures independent of control channel failures.
注意，当没有独立于控制通道故障检测数据通道故障的机制时，不得发送Restart_Cap对象。
Please note this section is derived from [PAN-RESTART].
请注意，本节源自[PAN-RESTART]。
The Restart_Cap Object is carried in Hello messages.
Restart_Cap对象包含在Hello消息中。
The format of the Restart_Cap Object is:
Restart_Cap对象的格式为：
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(131)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Restart Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recovery Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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(131)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Restart Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recovery Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Restart Time: 32 bits
重新启动时间：32位
Restart Time is measured in milliseconds. Restart Time SHOULD be set to the sum of the time it takes the sender of the object to restart its RSVP-TE component (to the point where it can exchange RSVP Hello with its neighbors) and the communication channel that is used for RSVP communication. A value of 0xffffffff indicates that the restart of the sender's control plane may occur over an indeterminate interval and that the operation of its data plane is unaffected by control plane failures. The method used to ensure continued data plane operation is outside the scope of this document.
重新启动时间以毫秒为单位。Restart Time（重新启动时间）应设置为对象的发送方重新启动其RSVP-TE组件（到可以与其邻居交换RSVP Hello）所需的时间和用于RSVP通信的通信信道的时间之和。0xFFFFFF值表示发送方控制平面的重新启动可能在不确定的时间间隔内发生，并且其数据平面的操作不受控制平面故障的影响。用于确保数据平面持续运行的方法不在本文件范围内。
Recovery Time: 32 bits
恢复时间：32位
The period of time, in milliseconds, that the sender desires for the recipient to re-synchronize RSVP and MPLS forwarding state with the sender after the re-establishment of Hello synchronization. A value of zero (0) indicates that MPLS forwarding state was not preserved across a particular reboot.
在重新建立Hello同步后，发送方希望接收方与发送方重新同步RSVP和MPLS转发状态的时间段（以毫秒为单位）。值为零（0）表示MPLS转发状态在特定重新启动期间未保留。
Nodes supporting state recovery advertise this capability by carrying the Restart_Cap object in Hello messages. Such nodes MUST include the Restart_Cap object in all Hello messages. (Note that this includes Hello messages containing ACK objects.) Usage of the special case Recovery Time values is described in greater detail below.
支持状态恢复的节点通过在Hello消息中携带Restart_Cap对象来宣传此功能。此类节点必须在所有Hello消息中包含Restart_Cap对象。（注意，这包括包含ACK对象的Hello消息。）下面将更详细地描述特殊情况恢复时间值的用法。
When a node receives a Hello message with the Restart_Cap object, it SHOULD record the values of the parameters received.
当节点接收到带有Restart_Cap对象的Hello消息时，它应该记录接收到的参数值。
When a node determines that RSVP communication with a neighbor has been lost, and the node previously learned that the neighbor supports state recovery, the node SHOULD wait at least the amount of time indicated by the Restart Time indicated by the neighbor before invoking procedures related to communication loss. A node MAY wait a different amount of time based on local policy or configuration information.
当节点确定与邻居的RSVP通信已丢失，且该节点先前获悉该邻居支持状态恢复时，该节点应至少等待邻居指示的重启时间所指示的时间量，然后再调用与通信丢失相关的过程。节点可以根据本地策略或配置信息等待不同的时间。
During this waiting period, all Hello messages MUST be sent with a Dst_Instance value set to zero (0), and Src_Instance should be unchanged. While waiting, the node SHOULD also preserve the RSVP and MPLS forwarding state for (already) established LSPs that traverse the link(s) between the node and the neighbor. In a sense with respect to established LSPs the node behaves as if it continues to receive periodic RSVP refresh messages from the neighbor. The node MAY clear RSVP and forwarding state for the LSPs that are in the process of being established when their refresh timers expire. Refreshing of Resv and Path state SHOULD be suppressed during this waiting period.
在此等待期间，发送所有Hello消息时必须将Dst_实例值设置为零（0），并且Src_实例应保持不变。在等待时，节点还应为（已经）建立的LSP保留RSVP和MPLS转发状态，这些LSP穿过节点和邻居之间的链路。从某种意义上讲，对于已建立的LSP，节点的行为就像它继续从邻居接收定期RSVP刷新消息一样。当LSP的刷新计时器过期时，节点可以清除正在建立的LSP的RSVP和转发状态。在此等待期间，应禁止刷新Resv和路径状态。
During this waiting period, the node MAY inform upstream nodes of the communication loss via a PathErr and/or upstream Notify message with "Control Channel Degraded State" indication. If such notification has been sent, then upon restoration of the control channel the node
在此等待期间，节点可通过带有“控制信道降级状态”指示的PathErr和/或upstream Notify消息通知上游节点通信丢失。如果已发送此类通知，则在恢复控制通道时，节点
MUST inform other nodes of the restoration via a PathErr and/or upstream Notify message with "Control Channel Active State" indication. (Specific error codes have been assigned by IANA.)
必须通过带有“控制通道活动状态”指示的PathErr和/或upstream Notify消息通知其他节点恢复。（IANA已指定具体的错误代码。）
When a new Hello message is received from the neighbor, the node must determine if the fault was limited to the control channel or was a nodal fault. This determination is based on the Src_Instance received from the neighbor. If the value is different than the value that was received from the neighbor prior to the fault, then the neighbor should be treated as if it has restarted. Otherwise, the the fault was limited control channel. Procedures for handling each case are described below.
当从邻居接收到新的Hello消息时，节点必须确定故障是限于控制信道还是节点故障。此确定基于从邻居接收的Src_实例。如果该值与故障前从邻居处接收到的值不同，则应将邻居视为已重新启动。否则，故障被限制在控制通道内。处理每个案件的程序如下所述。
In the case of control channel faults, the node SHOULD refresh all state shared with the neighbor. Summary Refreshes [RFC2961] with the ACK_Desired flag set SHOULD be used, if supported. Note that if a large number of messages are need, some pacing should be applied. All state SHOULD be refreshed within the Recovery time advertised by the neighbor.
在控制通道故障的情况下，节点应刷新与邻居共享的所有状态。如果支持，应使用带有ACK_所需标志集的摘要刷新[RFC2961]。请注意，如果需要大量消息，则应应用一些调整。所有状态都应在邻居公布的恢复时间内刷新。
Recovering from nodal faults uses one new object and other existing protocol messages and objects.
从节点故障恢复使用一个新对象和其他现有协议消息和对象。
The Recovery_Label object is used during the nodal fault recovery process. The format of a Recovery_Label object is identical to a generalized label. A Recovery_Label object uses Class-Number 34 (of form 0bbbbbbb) and the C-Type of the label being suggested.
在节点故障恢复过程中使用Recovery_标签对象。恢复标签对象的格式与通用标签相同。Recovery_Label对象使用类号34（形式为0BBB）和建议标签的C类型。
After a node restarts its control plane, a node that supports state recovery SHOULD check whether it was able to preserve its MPLS forwarding state. If no forwarding state from prior to the restart was preserved, then the node MUST set the Recovery Time to 0 in the Hello message the node sends to its neighbors.
节点重新启动其控制平面后，支持状态恢复的节点应检查是否能够保持其MPLS转发状态。如果在重新启动之前没有保留任何转发状态，则节点必须在向其邻居发送的Hello消息中将恢复时间设置为0。
If the forwarding state was preserved, then the node initiates the state recovery process. The period during which a node is prepared to support the recovery process is referred to as the Recovery Period. The total duration of the Recovery Period is advertised by the recovering node in the Recovery Time parameter of the Restart_Cap object. The Recovery Time MUST be set to the duration of the
如果转发状态被保留，则节点将启动状态恢复过程。节点准备支持恢复过程的时间段称为恢复时间段。恢复期间的总持续时间由恢复节点在Restart_Cap对象的恢复时间参数中公布。恢复时间必须设置为恢复的持续时间
Recovery Period in all Hello messages sent during the Recovery Period. State that is not resynchronized during the Recovery Period SHOULD be removed at the end of the Period.
恢复期间发送的所有Hello消息中的恢复期间。恢复期间未重新同步的状态应在恢复期间结束时删除。
Note that if during Hello synchronization the restarting node determines that a neighbor does not support state recovery, and the restarting node maintains its MPLS forwarding state on a per neighbor basis, the restarting node should immediately consider the Recovery Period with that neighbor completed. Forwarding state may be considered to be maintained on a per neighbor basis when per interface labels are used on point-to-point interfaces.
注意，如果在hello同步期间，重新启动节点确定邻居不支持状态恢复，并且重新启动节点在每个邻居基础上保持其MPLS转发状态，则重新启动节点应该立即考虑邻居完成的恢复周期。当在点到点接口上使用每接口标签时，转发状态可能被视为在每邻居的基础上保持。
When a node receives a Path message during the Recovery Period, the node first checks if it has an RSVP state associated with the message. If the state is found, then the node handles this message according to previously defined procedures.
当节点在恢复期间收到Path消息时，该节点首先检查其是否具有与该消息关联的RSVP状态。如果找到状态，则节点将根据先前定义的过程处理此消息。
If the RSVP state is not found, and the message does not carry a Recovery_Label object, the node treats this as a setup for a new LSP, and handles it according to previously defined procedures.
如果未找到RSVP状态，且消息未携带Recovery_Label对象，则节点将其视为新LSP的设置，并根据先前定义的过程进行处理。
If the RSVP state is not found, and the message carries a Recovery_Label object, the node searches its MPLS forwarding table (the one that was preserved across the restart) for an entry whose incoming interface matches the Path message and whose incoming label is equal to the label carried in the Recovery_Label object.
如果未找到RSVP状态，并且消息带有Recovery_标签对象，则节点将搜索其MPLS转发表（在重新启动过程中保留的表），以查找其传入接口与Path消息匹配且其传入标签等于Recovery_标签对象中所带标签的条目。
If the MPLS forwarding table entry is not found, the node treats this as a setup for a new LSP, and handles it according to previously defined procedures.
如果未找到MPLS转发表条目，则节点将其视为新LSP的设置，并根据先前定义的过程进行处理。
If the MPLS forwarding table entry is found, the appropriate RSVP state is created, the entry is bound to the LSP associated with the message, and related forwarding state should be considered as valid and refreshed. Normal Path message processing should also be conducted. When sending the corresponding outgoing Path message the node SHOULD include a Suggested_Label object with a label value matching the outgoing label from the now restored forwarding entry. The outgoing interface SHOULD also be selected based on the forwarding entry. In the special case where a restarting node also has a restating downstream neighbor, a Recovery_Label object should be used instead of a Suggested_Label object.
如果找到MPLS转发表条目，将创建相应的RSVP状态，该条目将绑定到与消息关联的LSP，并且相关的转发状态应视为有效并刷新。还应进行正常路径消息处理。发送相应的传出路径消息时，节点应包括一个建议的\u标签对象，其标签值与现在恢复的转发条目中的传出标签相匹配。还应根据转发条目选择传出接口。在特殊情况下，如果重新启动的节点还具有正在重新启动的下游邻居，则应使用恢复标签对象，而不是建议的标签对象。
Additionally, for bidirectional LSPs, the node extracts the label from the UPSTREAM_LABEL object carried in the received Path message, and searches its MPLS forwarding table for an entry whose outgoing
此外，对于双向lsp，节点从接收到的路径消息中携带的上游标签对象提取标签，并在其MPLS转发表中搜索其出站的条目
label is equal to the label carried in the object (in the case of link bundling, this may also involved first identifying the appropriate incoming component link).
标签等于对象中携带的标签（在链接绑定的情况下，这可能还涉及首先识别适当的传入组件链接）。
If the MPLS forwarding table entry is not found, the node treats this as a setup for a new LSP, and handles it according to previously defined procedures.
如果未找到MPLS转发表条目，则节点将其视为新LSP的设置，并根据先前定义的过程进行处理。
If the MPLS forwarding table entry is found, the entry is bound to the LSP associated with the Path message, and the entry should be considered to be re-synchronized. In addition, if the node is not the tail-end of the LSP, the corresponding outgoing Path messages is sent with the incoming label from that entry carried in the UPSTREAM_LABEL object.
如果找到MPLS转发表条目，则该条目将绑定到与Path消息关联的LSP，并且该条目应被视为已重新同步。此外，如果节点不是LSP的尾端，则相应的传出路径消息将与来自上游标签对象中携带的条目的传入标签一起发送。
During the Recovery Period, Resv messages are processed normally with two exceptions. In the case that a forwarding entry is recovered, no new label or resource allocation is required while processing the Resv message. The second exception is that ResvErr messages SHOULD NOT be generated when a Resv message with no matching Path state is received. In this case the Resv message SHOULD just be silently discarded.
在恢复期间，正常处理Resv消息，但有两个例外。在恢复转发条目的情况下，处理Resv消息时不需要新标签或资源分配。第二个例外是，当接收到没有匹配路径状态的Resv消息时，不应生成ResvErr消息。在这种情况下，Resv消息应该被悄悄地丢弃。
The following specifies the procedures that apply when the node reestablishes communication with the neighbor's control plane within the Restart Time, the node determines (using the procedures defined in Section 5 of [RFC3209]) that the neighbor's control plane has restarted, and the neighbor was able to preserve its forwarding state across the restart (as was indicated by a non-zero Recovery Time carried in the Restart_Cap object of the RSVP Hello messages received from the neighbor). Note, a Restart Time value of 0xffffffff indicates an infinite Restart Time interval.
以下规定了当节点在重启时间内与邻居的控制平面重新建立通信时适用的程序，节点确定（使用[RFC3209]第5节中定义的程序）邻居的控制平面已重启，并且邻居能够在重启过程中保持其转发状态（如从邻居接收的RSVP Hello消息的restart_Cap对象中携带的非零恢复时间所示）。注意，重新启动时间值0xFFFFFF表示无限的重新启动时间间隔。
Upon detecting a restart with a neighbor that supports state recovery, a node SHOULD refresh all Path state shared with that neighbor. The outgoing Path messages MUST include a Recovery_Label object containing a label value corresponding to the label value received in the most recently received corresponding Resv message. All Path state SHOULD be refreshed within approximately 1/2 of the Recovery time advertised by the restarted neighbor. If there are many LSP's going through the restarting node, the neighbor node should avoid sending Path messages in a short time interval, as to avoid unnecessary stressing the restarting node's CPU. Instead, it should spread the messages across 1/2 the Recovery Time interval.
当检测到与支持状态恢复的邻居重新启动时，节点应刷新与该邻居共享的所有路径状态。传出路径消息必须包含一个Recovery_Label对象，该对象包含一个标签值，该标签值与最近接收的相应Resv消息中接收到的标签值相对应。所有路径状态都应在重启邻居通告的恢复时间的大约1/2内刷新。如果有许多LSP通过重启节点，则邻居节点应避免在短时间间隔内发送路径消息，以避免对重启节点的CPU造成不必要的压力。相反，它应该在1/2的恢复时间间隔内传播消息。
After detecting a restart of a neighbor that supports state recovery, all Resv state shared with the restarting node MUST NOT be refreshed until a corresponding Path message is received. This requires suppression of normal Resv and Summary Refresh processing to the neighbor during the Recovery Time advertised by the restarted neighbor. As soon as a corresponding Path message is received a Resv message SHOULD be generated and normal state processing SHOULD be re-enabled.
检测到支持状态恢复的邻居重新启动后，在收到相应的路径消息之前，不得刷新与重新启动节点共享的所有Resv状态。这需要在重新启动的邻居通告的恢复时间内抑制对邻居的正常Resv和摘要刷新处理。收到相应的Path消息后，应立即生成Resv消息，并应重新启用正常状态处理。
This message summarizes RSVP message formats and handling as modified by GMPLS.
此消息总结了经GMPLS修改的RSVP消息格式和处理。
This section presents the RSVP message related formats as modified by this document. Where they differ, formats for unidirectional LSPs are presented separately from bidirectional LSPs. Unmodified formats are not listed. Again, MESSAGE_ID and related objects are defined in [RFC2961].
本节介绍本文件修改的RSVP消息相关格式。在不同之处，单向LSP的格式与双向LSP的格式是分开的。未修改的格式未列出。同样，在[RFC2961]中定义了消息ID和相关对象。
The format of a Path message is as follows:
Path消息的格式如下所示：
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <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>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
The format of the sender description for unidirectional LSPs is:
单向LSP的发送方说明格式为：
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]
The format of the sender description for bidirectional LSPs is:
双向LSP的发送方描述格式为：
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]
<UPSTREAM_LABEL>
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]
<UPSTREAM_LABEL>
The format of a PathErr message is as follows:
PathErr消息的格式如下所示：
<PathErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <ERROR_SPEC>
[ <ACCEPTABLE_LABEL_SET> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>
<PathErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <ERROR_SPEC>
[ <ACCEPTABLE_LABEL_SET> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>
The format of a Resv message is as follows:
Resv消息的格式如下所示：
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <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>
[ <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>未被本文档修改。
The format of a ResvErr message is as follows:
ResvErr消息的格式如下所示：
<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<ERROR_SPEC> [ <SCOPE> ]
[ <ACCEPTABLE_LABEL_SET> ... ]
[ <POLICY_DATA> ... ]
<STYLE> <error flow descriptor>
<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<ERROR_SPEC> [ <SCOPE> ]
[ <ACCEPTABLE_LABEL_SET> ... ]
[ <POLICY_DATA> ... ]
<STYLE> <error flow descriptor>
The modified Hello message format is:
修改后的Hello消息格式为：
<Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO>
[ <RESTART_CAP> ]
<Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO>
[ <RESTART_CAP> ]
RSVP was designed to handle dynamic (non-explicit) path changes and non RSVP hops along the path. To this end, the Path, PathTear and ResvConf messages carry the destination address of the session in the IP header. In generalized signaling, routes are usually explicitly signaled. Further, hops that cannot allocate labels cannot exist in the path of an LSP. A further difference with traditional RSVP is that at times, an RSVP message may travel out of band with respect to an LSP's data channel.
RSVP设计用于处理动态（非显式）路径更改和沿路径的非RSVP跳数。为此，Path、PATHTRARE和ResvConf消息在IP报头中携带会话的目标地址。在通用信令中，路由通常是显式信令的。此外，无法分配标签的跃点不能存在于LSP的路径中。与传统RSVP的另一个区别是，有时，RSVP消息可能会相对于LSP的数据信道在带外传输。
When a node is sending a Path, PathTear or ResvConf message to a node that it knows to be adjacent at the data plane (i.e., along the path of the LSP), it SHOULD address the message directly to an address associated with the adjacent node's control plane. In this case the router-alert option SHOULD not be included.
当节点向其知道在数据平面（即沿着LSP的路径）相邻的节点发送Path、PATHTRARE或ResvConf消息时，它应该将消息直接寻址到与相邻节点的控制平面相关联的地址。在这种情况下，不应包括路由器警报选项。
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 and Dimitrios Pendarakis. Portions of Section 4 are based on suggestions and text proposed by Adrian Farrel.
许多人提出了宝贵的意见和建议，包括伊戈尔·布莱斯金、阿德里安·法雷尔和迪米特里奥斯·潘达拉基斯。第4节的部分内容基于Adrian Farrel提出的建议和文本。
The security considerations section is based on text provided by Steven Bellovin.
安全注意事项部分基于Steven Bellovin提供的文本。
RSVP message security is described in [RFC2747] and provides message integrity and node authentication. For hop-by-hop messages, this document introduces no other new security considerations.
[RFC2747]中描述了RSVP消息安全性，并提供消息完整性和节点身份验证。对于逐跳消息，本文档不引入其他新的安全注意事项。
This document introduces the ability to send a Notify message in a non-hop-by-hop fashion. This precludes RSVP's hop-by-hop integrity and authentication model. In the case where RSVP is generating end-to-end messages and the same level of security provided by [RFC2747] is desired, the standard IPSEC based integrity and authentication can be used. Alternatively, the sending of no-hop-by-hop Notify messages can be disabled.
本文档介绍了以非逐跳方式发送通知消息的功能。这排除了RSVP的逐跳完整性和身份验证模型。如果RSVP正在生成端到端消息，并且需要[RFC2747]提供相同级别的安全性，则可以使用标准的基于IPSEC的完整性和身份验证。或者，可以禁用不逐跳发送通知消息。
When using IPSEC to provide message authentication, the following apply:
使用IPSEC提供消息身份验证时，以下情况适用：
Selectors The selector is identified by RSVP messages exchanged between a pair of non-adjacent nodes. The nodes are identified by the source and destination IP address of the inner IP header used on Notify messages.
选择器选择器由一对非相邻节点之间交换的RSVP消息标识。节点由Notify消息上使用的内部IP头的源IP地址和目标IP地址标识。
Mode In this application, transport mode is the proper choice. The information being communicated is generally not confidential, so encryption need not be used. Either AH [RFC2402] or ESP [RFC2406] MAY be used; if ESP is used, the sender's IP address MUST be checked against the IP address asserted in the key management exchange.
模式在此应用中，运输模式是正确的选择。所传递的信息通常不保密，因此不需要使用加密。可以使用AH[RFC2402]或ESP[RFC2406]；如果使用ESP，则必须对照密钥管理交换中声明的IP地址检查发送方的IP地址。
Key Management To permit replay detection, an automated key management system SHOULD be used, most likely IKE [RFC2409]. Configured keys MAY be used.
密钥管理为了允许重播检测，应使用自动密钥管理系统，最有可能是IKE[RFC2409]。可以使用配置的密钥。
Security Policy Messages MUST NOT be accepted except from nodes that are not known to the recipient to be authorized to make such requests.
除了收件人不知道有权发出此类请求的节点之外，不得接受安全策略消息。
Identification Shared keys mechanisms should be adequate for initial deployments and smaller networks. For larger-scale deployments, certificate-based IKE should be supported. Whatever scheme is used, it must tie back to a source IP address in some fashion.
标识共享密钥机制应足以用于初始部署和较小的网络。对于大规模部署，应支持基于证书的IKE。无论使用什么方案，它都必须以某种方式绑定到源IP地址。
Availability Many routers and switches already support IPSEC. For cases where IPSEC is unavailable and security is required, Notify messages MUST be sent hop-by-hop.
可用性许多路由器和交换机已经支持IPSEC。对于IPSEC不可用且需要安全性的情况，必须逐跳发送通知消息。
IANA assigns values to RSVP protocol parameters. Within the current document multiple objects are defined. Each of these objects contain C-Types. This section defines the rules for the assignment of the related C-Type values. This section uses the terminology of BCP 26 "Guidelines for Writing an IANA Considerations Section in RFCs" [BCP26].
IANA为RSVP协议参数赋值。在当前文档中定义了多个对象。每个对象都包含C类型。本节定义了相关C型值的分配规则。本节使用BCP 26“在RFCs中编写IANA注意事项部分的指南”[BCP26]的术语。
As per [RFC2205], C-Type is an 8-bit number that identifies the function of an object. All possible values except zero are available for assignment.
根据[RFC2205]，C-Type是一个8位数字，用于标识对象的功能。除零以外的所有可能值都可用于赋值。
The assignment of C-Type values of the objects defined in this document fall into three categories. The first category inherit C-Types from the Label object, i.e., object class number 16 [RFC3209]. IANA is requested to institute a policy whereby all C-Type values assign for the Label object are also assigned for the following objects:
本文档中定义的对象的C类型值的分配分为三类。第一类继承标签对象的C类型，即对象类编号16[RFC3209]。IANA被要求制定一项政策，根据该政策，为标签对象分配的所有C类型值也将分配给以下对象：
o Suggested_Label (Class-Num 129) o Upstream_Label (Class-Num 35) o Recovery_Label (Class-Num 34)
o 建议的\u标签（类别编号129）o上游\u标签（类别编号35）o恢复\u标签（类别编号34）
The second category of objects follow independent policies. Specifically, following the policies outlined in [BCP26], C-Type values in the range 0x00 - 0x3F are allocated through an IETF Consensus action, values in the range 00x40 - 0x5F are allocated as First Come First Served, and values in the range 0x60 - 0x7F are reserved for Private Use. This policy applies to the following objects.
第二类对象遵循独立的策略。具体而言，按照[BCP26]中概述的策略，0x00-0x3F范围内的C型值通过IETF一致行动分配，00x40-0x5F范围内的值分配为先到先得，0x60-0x7F范围内的值保留供私人使用。此策略适用于以下对象。
o Label_Set (Class-Num 36) o Notify_Request (Class-Num 195) o Protection (Class-Num 37) o Admin Status (Class-Num 196) o Restart_Cap (Class-Num 131)
o 标签设置（类别编号36）通知请求（类别编号195）保护（类别编号37）管理状态（类别编号196）重启上限（类别编号131）
The assignment of C-Type values for the remaining object, the Acceptable_Label_Set object, follows the assignment of C-Type values of the Label_Set object. IANA will institute a policy whereby all C-Type values assigned for the Label_Set object are also assigned for the Acceptable_Label_Set object.
剩余对象（可接受的_Label_Set对象）的C类型值的赋值遵循Label_Set对象的C类型值的赋值。IANA将制定一项政策，根据该政策，为标签集对象分配的所有C类型值也将分配给可接受的标签集对象。
This section summarizes values used in this document that have been assigned by IANA.
本节总结了IANA分配的本文件中使用的值。
---------------------------------------------------------------------
Message Types
---------------------------------------------------------------------
Message Types
o Notify message (Message type = 21)
o 通知消息（消息类型=21）
---------------------------------------------------------------------
Class Types
---------------------------------------------------------------------
Class Types
o RSVP_HOP (C-Num 3) - IPv4 IF_ID RSVP_HOP (C-type = 3) - IPv6 IF_ID RSVP_HOP (C-type = 4)
o RSVP_-HOP（C-Num 3）-IPv4 IF_-ID RSVP_-HOP（C-type=3）-IPv6 IF_-ID RSVP_-HOP（C-type=4）
o ERROR_SPEC (C-Num 6) - IPv4 IF_ID ERROR_SPEC (C-type = 3) - IPv6 IF_ID ERROR_SPEC (C-type = 4)
o 错误规格（C-Num 6）-IPv4如果ID错误规格（C-type=3）-IPv6如果ID错误规格（C-type=4）
o LABEL_REQUEST (Class-Num 19) - Generalized_Label_Request (C-Type = 4)
o 标签请求（类别编号19）-通用标签请求（C-Type=4）
o RSVP_LABEL (Class-Num = 16) - Generalized_Label (C-Type = 2) - Waveband_Switching_Label C-Type (C-Type = 3)
o RSVP_标签（类别编号=16）-通用_标签（C型=2）-波段_切换_标签C型（C型=3）
---------------------------------------------------------------------
New Class-Nums, C-Types inherited from Label object (same as CNum16)
---------------------------------------------------------------------
New Class-Nums, C-Types inherited from Label object (same as CNum16)
o RECOVERY_LABEL Class-Num of form 0bbbbbbb (= 34) o SUGGESTED_LABEL Class-Num of form 10bbbbbb (= 129) o UPSTREAM_LABEL Class-Num of form 0bbbbbbb (= 35)
o 恢复\表格0BBBBB（=34）的标签类别数量o建议\表格10bbbbbb（=129）的标签类别数量o表格0BBBBB（=35）的上游\标签类别数量
---------------------------------------------------------------------
New Class-Nums
---------------------------------------------------------------------
New Class-Nums
o LABEL_SET Class-Num of form 0bbbbbbb (= 36) - Type 1 (C-Type = 1) o ACCEPTABLE_LABEL_SET Class-Num of form 10bbbbbb (= 130) - Type 1 Acceptable_Label_Set (C-type from label_set cnum) o NOTIFY_REQUEST Class-Num of form 11bbbbbb (= 195) - IPv4 Notify Request (C-Type = 1) - IPv6 Notify Request (C-Type = 2) o PROTECTION Class-Num of form 0bbbbbbb (= 37) - Type 1 (C-Type = 1)
o 表格0bbbbbbb（=36）的标签集类别编号-1类（C-Type=1）o表格10BBBBBBB（=130）的可接受标签集类别编号-1类可接受标签集（C-Type来自标签集cnum）o表格11BBBBBBB（=195）的通知请求类别编号-IPv4通知请求（C-Type=1）-IPv6通知请求（C-Type=2）o表格0bbbbbbb的保护类别编号（=37）-1型（C型=1）
o ADMIN STATUS Class-Num of form 11bbbbbb (= 196) - Type 1 (C-Type = 1) o RESTART_CAP Class-Num of form 10bbbbbb (= 131) - Type 1 (C-Type = 1) --------------------------------------------------------------------- ERO/RRO subobject types
o 表格11bbbbbb（=196）的管理状态类别编号-1类（C-Type=1）o表格10BBBBBBBB（=131）的重新启动\u CAP类别编号-1类（C-Type=1）--------------------------------------------------------------------------------------ERO/RRO子对象类型
o Label ERO subobject Type 3 - Label
o 标签ERO子对象类型3-标签
o Label RRO subobject Type 3 - Label --------------------------------------------------------------------- Error codes
o 标签RRO子对象类型3-标签--------------------------------------------------------------------错误代码
o "Routing problem/Label Set" (value = 11)
o "Routing problem/Switching Type" (value = 12)
(duplicate code 13 dropped)
o "Routing problem/Unsupported Encoding" (value = 14)
o "Routing problem/Unsupported Link Protection" (value = 15)
o "Notify Error/Control Channel Active State" (value = 4)
o "Notify Error/Control Channel Degraded State" (value = 5)
---------------------------------------------------------------------
o "Routing problem/Label Set" (value = 11)
o "Routing problem/Switching Type" (value = 12)
(duplicate code 13 dropped)
o "Routing problem/Unsupported Encoding" (value = 14)
o "Routing problem/Unsupported Link Protection" (value = 15)
o "Notify Error/Control Channel Active State" (value = 4)
o "Notify Error/Control Channel Degraded State" (value = 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月。
[RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReserVation Protocol -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.（编辑），Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源保留协议——第1版功能规范”，RFC 22052997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210]Wroclawski，J.，“RSVP与IETF集成服务的使用”，RFC 2210，1997年9月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2401, November 1998.
[RFC2402]Kent，S.和R.Atkinson，“IP认证头”，RFC 2401，1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2401, November 1998.
[RFC2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2401，1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC2747] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]Baker，F.，Lindell，B.和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月。
[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] 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月。
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.，编辑，“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource Reservation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477]Kompella，K.和Y.Rekhter，“资源预留协议中未编号链路的信令-流量工程（RSVP-TE）”，RFC 3477，2003年1月。
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[BCP26]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[MPLS-HIERARCHY] Kompella, K. and Y. Rekhter, "LSP Hierarchy with MPLS TE", Work in Progress.
[MPLS-HIERARCHY]Kompella，K.和Y.Rekhter，“具有MPLS TE的LSP层次结构”，正在进行中。
[PAN-RESTART] Pan, P., et. al., "Graceful Restart Mechanism for RSVP-TE", Work in Progress.
[PAN-RESTART]PAN，P.等人，“RSVP-TE的优雅重启机制”，正在进行中。
[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月。
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
Greg Bernstein电子邮件：gregb@grotto-网络
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
Fong Liaw Solas Research, LLC
Fong Liaw Solas研究有限责任公司
EMail: fongliaw@yahoo.com
EMail: fongliaw@yahoo.com
Eric Mannie Independent Consultant 2 Avenue de la Folle Chanson 1050 Brussels Belgium
Eric Mannie独立顾问，比利时布鲁塞尔富勒香松大道2号1050
EMail: eric_mannie@hotmail.com
EMail: eric_mannie@hotmail.com
Ping Pan Ciena 10480 Ridgeview Court Cupertino, CA 95014
平盘西纳10480加利福尼亚州库比蒂诺里奇维尤法院，邮编95014
Phone: 408-366-4700 EMail: ppan@ciena.com
电话：408-366-4700电子邮件：ppan@ciena.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
Vishal Sharma Metanoia，Inc.加利福尼亚州山景城别墅街1600号352单元，邮编94041-1174
Phone: +1 650-386-6723
EMail: v.sharma@ieee.org
Phone: +1 650-386-6723
EMail: 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编辑功能的资金目前由互联网协会提供。