Network Working Group A. Satyanarayana, Ed.
Request for Comments: 5063 R. Rahman, Ed.
Updates: 2961, 3473 Cisco Systems
Category: Standards Track October 2007
Network Working Group A. Satyanarayana, Ed.
Request for Comments: 5063 R. Rahman, Ed.
Updates: 2961, 3473 Cisco Systems
Category: Standards Track October 2007
Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart
GMPLS资源预留协议（RSVP）的扩展
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）。本备忘录的分发不受限制。
Abstract
摘要
This document describes extensions to the Resource Reservation Protocol (RSVP) Graceful Restart mechanisms defined in RFC 3473. The extensions enable the recovery of RSVP signaling state based on the Path message last sent by the node being restarted.
本文档描述了RFC 3473中定义的资源保留协议（RSVP）优雅重启机制的扩展。这些扩展支持根据重新启动的节点上次发送的路径消息恢复RSVP信令状态。
Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. Those mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects.
先前定义的优雅重启机制（也称为节点故障恢复）允许在数据平面在重启过程中保持相关转发状态时，从相邻节点恢复信令状态。这些机制不完全支持入口节点上的信令状态恢复或所有RSVP对象的恢复。
The extensions defined in this document build on the RSVP Hello extensions defined in RFC 3209, and extensions for state recovery on nodal faults defined in RFC 3473. Using these extensions, the restarting node can recover all previously transmitted Path state, including the Explicit Route Object and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node.
本文档中定义的扩展基于RFC 3209中定义的RSVP Hello扩展，以及RFC 3473中定义的节点故障状态恢复扩展。使用这些扩展，重新启动节点可以恢复所有先前传输的路径状态，包括显式路由对象和下游（传出）接口标识符。扩展还可用于在入口节点重新启动后恢复信令状态。
These extensions are not used to create or restore data plane state.
这些扩展不用于创建或恢复数据平面状态。
The extensions optionally support the use of Summary Refresh, defined in RFC 2961, to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more Label Switched Paths (LSPs).
这些扩展可选地支持使用RFC 2961中定义的摘要刷新，以减少当重新启动的节点已在本地恢复一个或多个标签交换路径（LSP）的信令状态时在恢复阶段期间交换的消息数量。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................5
3. Terminology .....................................................5
4. Extensions to Nodal Fault Handling ..............................5
4.1. RecoveryPath Message Format ................................5
4.2. Capability Object ..........................................6
4.2.1. Conformance .........................................7
4.3. Related Procedures .........................................7
4.4. Procedures for the Capability Object .......................8
4.4.1. Procedures for the Downstream Neighbor ..............8
4.4.2. Procedures for the Restarting Node ..................8
4.5. Procedures for the RecoveryPath Message ....................9
4.5.1. Procedures for the Downstream Neighbor ..............9
4.5.2. Procedures for the Restarting Node .................10
4.5.2.1. Path and RecoveryPath Message Procedures ..11
4.5.2.2. Re-Synchronization Procedures .............12
4.5.2.3. Procedures on Expiration of
Recovery Period ...........................13
4.6. Compatibility .............................................13
5. RecoveryPath Summary Refresh ...................................14
5.1. MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects ...........15
5.2. RecoveryPath Srefresh Capable Bit .........................16
5.2.1. Procedures .........................................16
5.2.2. Compatibility ......................................17
5.3. RecoveryPath Summary Refresh Procedures ...................17
5.3.1. Generation of RecoveryPath-Related Srefresh
Messages ...........................................17
5.3.2. RecoveryPath-Related Srefresh Receive
Processing and NACK Generation .....................19
5.3.3. RecoveryPath-Related MESSAGE_ID NACK
Receive Processing .................................19
6. Security Considerations ........................................20
7. Acknowledgments ................................................21
8. IANA Considerations ............................................21
9. Normative References ...........................................22
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................5
3. Terminology .....................................................5
4. Extensions to Nodal Fault Handling ..............................5
4.1. RecoveryPath Message Format ................................5
4.2. Capability Object ..........................................6
4.2.1. Conformance .........................................7
4.3. Related Procedures .........................................7
4.4. Procedures for the Capability Object .......................8
4.4.1. Procedures for the Downstream Neighbor ..............8
4.4.2. Procedures for the Restarting Node ..................8
4.5. Procedures for the RecoveryPath Message ....................9
4.5.1. Procedures for the Downstream Neighbor ..............9
4.5.2. Procedures for the Restarting Node .................10
4.5.2.1. Path and RecoveryPath Message Procedures ..11
4.5.2.2. Re-Synchronization Procedures .............12
4.5.2.3. Procedures on Expiration of
Recovery Period ...........................13
4.6. Compatibility .............................................13
5. RecoveryPath Summary Refresh ...................................14
5.1. MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects ...........15
5.2. RecoveryPath Srefresh Capable Bit .........................16
5.2.1. Procedures .........................................16
5.2.2. Compatibility ......................................17
5.3. RecoveryPath Summary Refresh Procedures ...................17
5.3.1. Generation of RecoveryPath-Related Srefresh
Messages ...........................................17
5.3.2. RecoveryPath-Related Srefresh Receive
Processing and NACK Generation .....................19
5.3.3. RecoveryPath-Related MESSAGE_ID NACK
Receive Processing .................................19
6. Security Considerations ........................................20
7. Acknowledgments ................................................21
8. IANA Considerations ............................................21
9. Normative References ...........................................22
RSVP Graceful Restart is defined in [RFC3473] and uses mechanisms defined in [RFC3209]. When data/forwarding plane state can be retained across the restart of the RSVP agent that established such state, RSVP Graceful Restart provides the ability for the RSVP agent to resynchronize its state based on updates received from its neighboring RSVP agents, and, reconcile such state with the retained data/forwarding plane state. [RFC3209] describes a mechanism, using RSVP Hello messages, to detect the state of an adjacent RSVP agent. [RFC3473] extends this mechanism to advertise the capability of retaining data/forwarding plane state across the restart of a node or a "nodal fault". [RFC3473] also defines the Recovery Label object for use in the Path message of the RSVP neighbor upstream of a restarting node, to indicate that the Path message is for existing data plane state.
RSVP优雅重启在[RFC3473]中定义，并使用[RFC3209]中定义的机制。当数据/转发平面状态可在建立该状态的RSVP代理重新启动期间保留时，RSVP优雅重新启动使RSVP代理能够基于从其相邻RSVP代理接收的更新重新同步其状态，并使该状态与保留的数据/转发平面状态一致。[RFC3209]描述了一种使用RSVP Hello消息检测相邻RSVP代理的状态的机制。[RFC3473]扩展了该机制，以宣传在节点重启或“节点故障”期间保留数据/转发平面状态的能力。[RFC3473]还定义了用于重新启动节点上游RSVP邻居的路径消息中的恢复标签对象，以指示路径消息用于现有数据平面状态。
This document presents extensions to address two aspects of graceful restart not previously supported. The presented extensions enable a restarting node to recover all objects in previously transmitted Path messages, including the Explicit Route Object (ERO), from its downstream neighbors, thus recovering the control plane state. The extensions do not facilitate the recovery or creation of data/forwarding plane state, and can only be used to reestablish control plane state that matches in-place data/forwarding state. The extensions also enable graceful restart of an ingress node that does not preserve full RSVP state across restarts. The presented extensions are equally applicable to LSPs of various switching types as defined in [RFC3471].
本文档提供了扩展，以解决以前不支持的优雅重启的两个方面。所提出的扩展使重新启动节点能够从其下游邻居恢复先前传输的路径消息中的所有对象，包括显式路由对象（ERO），从而恢复控制平面状态。扩展不便于恢复或创建数据/转发平面状态，只能用于重新建立与就地数据/转发状态匹配的控制平面状态。扩展还支持入口节点的优雅重启，该节点不会在重启期间保持完整的RSVP状态。所提供的扩展同样适用于[RFC3471]中定义的各种开关类型的LSP。
Per [RFC3473], a restarting node can distinguish Path messages associated with LSPs being recovered by the presence of the Recovery Label object. To determine the downstream (outgoing) interface and associated label(s), the restarting node must consult the data plane. This may not be possible for all types of nodes. Furthermore, data plane information is not sufficient to reconstruct all previously transmitted Path state. In these cases, the only source of RSVP state is the downstream RSVP neighbor.
根据[RFC3473]，重新启动节点可以通过恢复标签对象的存在来区分与正在恢复的LSP相关联的路径消息。要确定下游（传出）接口和相关标签，重新启动节点必须参考数据平面。这可能不适用于所有类型的节点。此外，数据平面信息不足以重建所有先前传输的路径状态。在这些情况下，RSVP状态的唯一来源是下游RSVP邻居。
For example, when the restarting node is an ingress node, all previously transmitted Path state may need to be recovered. Such Path state may include (but is not restricted to) the Protection object, the Admin Status object, the Session Attribute object, the Notify Request object, and the Sender Tspec object. A restarting transit node may have modified received Path state in its previously transmitted Path message, which cannot be reconstructed internally during recovery.
例如，当重新启动节点是入口节点时，可能需要恢复所有先前传输的路径状态。这种路径状态可以包括（但不限于）保护对象、管理状态对象、会话属性对象、通知请求对象和发送方Tspec对象。重新启动的传输节点可能在其先前传输的路径消息中修改了接收到的路径状态，在恢复期间无法在内部重建。
Another example of state that cannot be completely recovered from the data plane in some cases is the previously transmitted ERO. Recovery of the previously transmitted ERO minimizes subsequent change of downstream LSP state. On a restarting ingress node, the ERO may have been based on configuration or the result of a previous path computation. A restarting transit node may have previously performed some form of path computation as a result of not receiving an ERO or receiving a loose hop in the ERO. In addition to the ERO, the restarting node may have modified other received Path state in its previously transmitted Path state, which cannot be reconstructed internally during recovery.
在某些情况下无法从数据平面完全恢复的状态的另一个示例是先前传输的ERO。恢复先前传输的ERO使下游LSP状态的后续变化最小化。在重新启动入口节点上，ERO可能基于配置或先前路径计算的结果。重新启动的中转节点之前可能已经执行了某种形式的路径计算，这是由于没有接收到ERO或在ERO中接收到松散跳跃。除了ERO之外，重新启动节点可能已经在其先前传输的路径状态中修改了其他接收的路径状态，该路径状态在恢复期间无法在内部重建。
The defined extensions provide a restarting upstream node with all information previously transmitted by the node in Path messages. This is accomplished by the downstream RSVP neighbor sending a new message for every Path message it has previously received from the restarting node, after reestablishing RSVP communication with a restarted node that supports the recovery procedures defined in Section 4.5.2 of this document.
定义的扩展为重新启动的上游节点提供了路径消息中节点先前传输的所有信息。这是通过下游RSVP邻居在与支持本文件第4.5.2节中定义的恢复程序的重启节点重新建立RSVP通信后，为其先前从重启节点收到的每条路径消息发送新消息来实现的。
The new message is called the RecoveryPath message. The message conveys the contents of the last received Path message back to the restarting node. The restarting node can use the RecoveryPath message, along with the state in the received Path message to associate control and data plane state and to validate the forwarding state with the state presented by the neighboring RSVP nodes.
新消息称为RecoveryPath消息。该消息将上次接收到的Path消息的内容传回重新启动节点。重新启动节点可以使用RecoveryPath消息以及接收到的Path消息中的状态来关联控制和数据平面状态，并验证转发状态与相邻RSVP节点呈现的状态。
The restarting node indicates its desire to receive and process the RecoveryPath message by including a new object called the Capability object with the RecoveryPath Desired bit set, in its Hello messages sent to the downstream RSVP neighbor. The downstream RSVP neighbor can indicate its ability to send RecoveryPath messages by including the Capability object with the RecoveryPath Transmit Enabled set in its Hello messages to the restarting node. Thus, both the restarting node and its RSVP neighbor, with the help of the Capability object, can detect if the RecoveryPath message extensions defined in this document can be used to recover signaling state after a restart.
重新启动节点通过在发送给下游RSVP邻居的Hello消息中包含名为Capability对象的新对象（设置了RecoveryPath所需位）来表示其接收和处理RecoveryPath消息的愿望。下游RSVP邻居可以通过在其向重新启动节点发送的Hello消息中包含设置了RecoveryPath Transmit Enabled的Capability对象来指示其发送RecoveryPath消息的能力。因此，在Capability对象的帮助下，重新启动节点及其RSVP邻居都可以检测本文档中定义的RecoveryPath消息扩展是否可用于在重新启动后恢复信令状态。
If the restarting node is a transit node, it will receive a Path message with a Recovery Label object from its upstream RSVP neighbor. In addition, the RecoveryPath message allows such transit nodes to reconstruct any state that was previously dynamically constructed by the node, e.g., ERO sub-objects. If the restarting node is an ingress node, all significant signaling state can be recovered based on the RecoveryPath message.
如果重新启动节点是传输节点，它将从其上游RSVP邻居接收带有恢复标签对象的路径消息。此外，RecoveryPath消息允许此类传输节点重构之前由节点动态构建的任何状态，例如ERO子对象。如果重新启动节点是入口节点，则可以基于RecoveryPath消息恢复所有重要的信令状态。
Selective transmission of the RecoveryPath message is supported by enhancing the Summary Refresh mechanisms defined in [RFC2961]. When Recovery Summary Refresh is supported, the restarting node can select the LSPs for which it would like to receive RecoveryPath messages. This is useful when the restarting node is able to locally recover the signaling state for a subset of the previously active LSPs.
通过增强[RFC2961]中定义的摘要刷新机制，支持RecoveryPath消息的选择性传输。支持恢复摘要刷新时，重新启动节点可以选择要接收其恢复路径消息的LSP。当重新启动节点能够本地恢复先前活动lsp的子集的信令状态时，这是有用的。
Restarting egress nodes, and Resv message processing are not impacted by the presented extensions, see [RFC3473] for details.
重新启动出口节点和Resv消息处理不受提供的扩展的影响，有关详细信息，请参阅[RFC3473]。
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]中所述进行解释。
The reader is assumed to be familiar with the terminology defined in [RFC3209] and [RFC3473].
假定读者熟悉[RFC3209]和[RFC3473]中定义的术语。
Throughout this document, the term "node", when used in the context of a restarting or restarted node, generally refers to the control plane component, which is the signaling controller for a data plane switch.
在本文件中，术语“节点”在重新启动或重新启动节点的上下文中使用时，通常指控制平面组件，它是数据平面交换机的信令控制器。
This section presents the protocol modifications to Section 9 of [RFC3473].
本节介绍对[RFC3473]第9节的协议修改。
The format of a RecoveryPath message is the same as the format of a Path message, as defined in [RFC3473], but uses a new message number (30) so that it can be identified correctly.
RecoveryPath消息的格式与[RFC3473]中定义的Path消息的格式相同，但使用新的消息编号（30），以便正确识别。
<RecoveryPath Message> ::= <Path Message>
<RecoveryPath Message> ::= <Path Message>
The destination address used in the IP header of a RecoveryPath message MUST be the same as the destination address used in the IP header of the corresponding Resv message last generated by the sending node. Except as specified below, all objects in a RecoveryPath message are identical to the objects in the corresponding Path message last received by the sending node.
RecoveryPath消息的IP头中使用的目标地址必须与发送节点上次生成的相应Resv消息的IP头中使用的目标地址相同。除了下面指定的对象外，RecoveryPath消息中的所有对象都与发送节点上次接收到的相应路径消息中的对象相同。
Capability objects are carried in RSVP Hello messages. The Capability object uses Class-Number 134 (of form 10bbbbbb) and C-Type of 1.
能力对象在RSVP Hello消息中携带。能力对象使用类别编号134（形式为10bbbbbb）和C类型1。
The message format of a Hello message is modified to be:
Hello消息的消息格式修改为：
<Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO>
[ <RESTART_CAP> ] [ <CAPABILITY> ]
<Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO>
[ <RESTART_CAP> ] [ <CAPABILITY> ]
The format of a Capability 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(134)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |T|R|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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(134)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |T|R|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RecoveryPath Transmit Enabled (T): 1 bit
恢复路径传输启用（T）：1位
When set (1), indicates that the sending node is enabled to send RecoveryPath messages. Absence of the Capability object MUST be treated as if the T-bit is cleared (0).
设置为（1）时，表示发送节点已启用发送RecoveryPath消息。不存在能力对象必须视为T位已清除（0）。
RecoveryPath Desired (R): 1 bit
所需恢复路径（R）：1位
When set (1), indicates that the sending node desires to receive RecoveryPath messages. Absence of the Capability object MUST be treated as if the R-bit is cleared (0).
设置为（1）时，表示发送节点希望接收RecoveryPath消息。能力对象的缺失必须视为R位被清除（0）。
RecoveryPath Srefresh Capable (S): 1 bit
RecoveryPath Srefresh功能：1位
When set (1), along with the R-bit, indicates that the sending node is capable of receiving and processing Srefresh messages with the RecoveryPath Flag set (1) in the MESSAGE_ID LIST object. Absence of the Capability object MUST be treated as if the S-bit is cleared (0). Related procedures are defined in Section 5.2.1.
当设置为（1）时，与R位一起，表示发送节点能够接收和处理消息_ID LIST对象中设置了RecoveryPath标志（1）的Srefresh消息。不存在Capability对象必须视为S位已清除（0）。第5.2.1节规定了相关程序。
Reserved bits
保留位
Reserved bits MUST be set to zero on transmission and MUST be ignored on receipt.
传输时必须将保留位设置为零，接收时必须忽略保留位。
All nodes supporting the extensions defined in this document MUST be able to transmit, and properly receive and process RecoveryPath messages. All nodes MUST be able to set both the T and R bits. Both the T and R bits SHOULD be set (1) by default. A node MAY allow RecoveryPath message transmission and reception to be independently disabled based on local policy. When RecoveryPath message transmission is disabled, the T-bit MUST be set to zero (0). When RecoveryPath message reception is not desired, the R-bit MUST be set to zero (0).
支持本文档中定义的扩展的所有节点必须能够传输、正确接收和处理RecoveryPath消息。所有节点必须能够设置T和R位。默认情况下，T和R位都应设置为（1）。节点可允许基于本地策略独立禁用RecoveryPath消息传输和接收。当RecoveryPath消息传输被禁用时，T位必须设置为零（0）。当不需要RecoveryPath消息接收时，R位必须设置为零（0）。
Any node that supports the extensions defined in this document and sets the Refresh-Reduction-Capable bit [RFC2961] SHOULD support setting of the S-bit and support the mechanisms defined in Section 5.
支持本文档中定义的扩展并设置可刷新减少位[RFC2961]的任何节点都应支持S位的设置并支持第5节中定义的机制。
This document does not modify existing procedures for sending and receiving RSVP Hello messages, as defined in [RFC3209], and the Restart_Cap object in RSVP Hello messages as defined in [RFC3473]. The procedures for control channel faults are defined in [RFC3473] and are not changed by this document.
本文档不修改[RFC3209]中定义的发送和接收RSVP Hello消息的现有过程，也不修改[RFC3473]中定义的RSVP Hello消息中的Restart_Cap对象。[RFC3473]中定义了控制通道故障的程序，本文件未对其进行更改。
The presented extensions require the use of RSVP Hellos, as defined in [RFC3209], and the use of the Restart_Cap object extension as defined in [RFC3473]. The presented extensions address only "Nodal Faults" as defined in [RFC3473]. Control channel faults are fully addressed in [RFC3473].
所提供的扩展需要使用[RFC3209]中定义的RSVP Hellos，以及[RFC3473]中定义的Restart_Cap对象扩展。所提供的扩展仅解决[RFC3473]中定义的“节点故障”。控制通道故障在[RFC3473]中有详细说明。
Note: There are no changes to the procedures defined in Section 9.5.3 in [RFC3473] (Procedures for the Neighbor of a Restarting node). There are no changes to the procedures defined in Section 9.5.2 in [RFC3473] if the restarting node is an egress node.
注：对[RFC3473]（重启节点邻居程序）第9.5.3节中定义的程序没有任何更改。如果重新启动节点是出口节点，则[RFC3473]第9.5.2节中定义的程序没有变化。
There are no changes to the procedures with respect to the data/forwarding plane as described in [RFC3473]. In particular, a restarting node MUST NOT create data/forwarding plane state as the result of any of the extensions defined in this document.
与[RFC3473]中所述的数据/转发平面相关的程序没有变化。特别是，重新启动节点不得因本文档中定义的任何扩展而创建数据/转发平面状态。
The following sections assume previously defined procedures are followed, except where explicitly modified.
以下各节假定遵循先前定义的过程，除非明确修改。
If a node is capable of sending RecoveryPath messages, it MUST include the Capability object with the RecoveryPath Transmit Enabled (T) bit set (1) in all its Hello messages.
如果节点能够发送RecoveryPath消息，则它必须在其所有Hello消息中包含具有RecoveryPath传输启用（T）位集（1）的Capability对象。
If the downstream RSVP neighbor receives Hello messages from a restarting node, with the Restart_Cap object, as defined in [RFC3473], and with the Capability object with the RecoveryPath Desired (R) bit set (1), it MUST treat the restarting node as capable of receiving and processing RecoveryPath messages as defined in this document.
如果下游RSVP邻居接收到来自重启节点的Hello消息，并带有[RFC3473]中定义的Restart_Cap对象和设置了RecoveryPath所需（R）位（1）的Capability对象，则必须将重启节点视为能够接收和处理本文档中定义的RecoveryPath消息。
If the downstream RSVP neighbor receives a Capability object in a Hello message with the RecoveryPath Desired (R) bit set (1), but without the Restart_Cap object, it MUST process the Hello message as if the RecoveryPath Receive Desired (R) bit is cleared (0) in the Hello message.
如果下游RSVP邻居在Hello消息中接收到设置了RecoveryPath Desired（R）位（1）的Capability对象，但没有Restart_Cap对象，则它必须像在Hello消息中清除RecoveryPath Receive Desired（R）位（0）一样处理Hello消息。
If the downstream RSVP neighbor does not receive the Capability object in Hello messages sent by the restarting node or the RecoveryPath Desired (R) bit is cleared (0) in the Capability object, it MUST treat the restarting node as not capable of supporting the RecoveryPath message procedures defined in this document, and MUST revert to recovery procedures as defined in [RFC3473].
如果下游RSVP邻居未在重启节点发送的Hello消息中接收到Capability对象，或者Capability对象中的RecoveryPath Desired（R）位被清除（0），则必须将重启节点视为无法支持本文档中定义的RecoveryPath消息过程，并且必须恢复到[RFC3473]中定义的恢复程序。
A node that expects to recover RSVP state by the receipt and processing of RecoveryPath messages according to procedures defined in this document, MUST include the Capability object with the RecoveryPath Desired (R) bit set (1) in its RSVP Hello messages to its neighbors. The node MUST also include the Restart_Cap object, as defined in [RFC3473], in all those Hello messages.
根据本文档中定义的过程，希望通过接收和处理RecoveryPath消息来恢复RSVP状态的节点，必须在其向邻居发送的RSVP Hello消息中包含具有RecoveryPath所需（R）位集（1）的Capability对象。该节点还必须在所有这些Hello消息中包含[RFC3473]中定义的Restart_Cap对象。
If the Recovery Time is zero (0) or the restarting node does not support/desire the use of RecoveryPath messages, the RecoveryPath Desired (R) bit MUST be cleared (0) in the Capability object included in Hello messages, or the Capability object MAY be omitted from Hello messages sent by the restarting node.
如果恢复时间为零（0），或者重新启动节点不支持/不希望使用RecoveryPath消息，则必须清除Hello消息中包含的Capability对象中的RecoveryPath Desired（R）位（0），否则可能会从重新启动节点发送的Hello消息中忽略Capability对象。
During the Recovery Period, if the restarting node receives Hello messages from a downstream RSVP neighbor with the RecoveryPath Transmit Enabled (T) bit set (1) in the Capability object and the Restart_Cap object, as defined in [RFC3473], it MUST treat the downstream RSVP neighbor as capable of sending RecoveryPath messages
在恢复期间，如果重新启动节点接收到来自下游RSVP邻居的Hello消息，且在[RFC3473]中定义的Capability对象和Restart_Cap对象中设置了RecoveryPath Transmit Enabled（T）位（1），则必须将下游RSVP邻居视为能够发送RecoveryPath消息
according to procedures defined in Section 4.5.1. If the restarting node expects to recover RSVP state by the receipt and processing of RecoveryPath messages, it MUST follow procedures defined in Section 4.5.2, with the downstream RSVP neighbor.
根据第4.5.1节规定的程序。如果重新启动的节点希望通过接收和处理RecoveryPath消息来恢复RSVP状态，则它必须遵循第4.5.2节中定义的程序，与下游RSVP邻居一起。
During the Recovery Period, if the restarting node receives Hello messages from a downstream RSVP neighbor with the RecoveryPath Transmit Enabled (T) bit cleared (0) in the Capability object, or, with the Capability object not present, it MUST treat the downstream RSVP neighbor as not capable of the RecoveryPath message procedures defined in this document, and, it MUST revert to the recovery procedures defined in [RFC3473] immediately, with the downstream RSVP neighbor.
在恢复期间，如果重新启动节点接收到来自下游RSVP邻居的Hello消息，并且在能力对象中清除了RecoveryPath传输启用（T）位（0），或者在能力对象不存在的情况下，它必须将下游RSVP邻居视为无法执行本文档中定义的RecoveryPath消息过程，并且必须立即与下游RSVP邻居一起恢复到[RFC3473]中定义的恢复过程。
After a downstream RSVP neighbor has detected that its upstream node has restarted, is capable of recovery as defined in [RFC3473], and, is capable of receiving RecoveryPath messages as defined in Section 4.4, the downstream RSVP neighbor MUST send a RecoveryPath message for each LSP associated with the restarting node for which it has sent a Resv message. During the Recovery Period, if the downstream RSVP neighbor detects that the restarting node is not capable of receiving RecoveryPath messages by the absence of the Capability object or the RecoveryPath Desired (R) bit cleared (0) in the Capability object in the restarting node's Hello messages, the downstream RSVP neighbor SHOULD NOT send the RecoveryPath messages to the restarting node.
下游RSVP邻居检测到其上游节点已重新启动后，能够按照[RFC3473]中的定义进行恢复，并且能够接收第4.4节中定义的RecoveryPath消息，下游RSVP邻居必须为与其已发送Resv消息的重新启动节点关联的每个LSP发送RecoveryPath消息。在恢复期间，如果下游RSVP邻居检测到重启节点无法接收RecoveryPath消息，原因是重启节点的Hello消息中的Capability对象中缺少Capability对象或RecoveryPath所需（R）位已清除（0），下游RSVP邻居不应向重新启动节点发送RecoveryPath消息。
The RecoveryPath message is constructed by copying all objects from the last received associated Path message, with the following exceptions:
RecoveryPath消息是通过复制上次收到的关联路径消息中的所有对象来构造的，但以下例外情况除外：
The MESSAGE_ID, MESSAGE_ID_ACK and MESSAGE_ID_NACK objects are not copied. Any MESSAGE_ID, MESSAGE_ID_ACK and MESSAGE_ID_NACK objects used in RecoveryPath messages are generated based on procedures defined in [RFC2961].
未复制消息ID、消息ID确认和消息ID NACK对象。RecoveryPath消息中使用的任何消息ID、消息ID确认和消息ID NACK对象都是根据[RFC2961]中定义的过程生成的。
The Integrity object is not copied. Any Integrity objects used in RecoveryPath messages are generated based on procedures defined in [RFC2747].
未复制完整性对象。RecoveryPath消息中使用的任何完整性对象都是根据[RFC2747]中定义的过程生成的。
The RSVP Hop object is copied from the most recent associated Resv message sent to the restarted node for the LSP being recovered.
RSVP Hop对象是从发送到正在恢复的LSP的重新启动节点的最新关联Resv消息中复制的。
In the sender descriptor, the Recovery Label object MUST be included, with the label value copied from the label value in the Label object in the most recent associated Resv message sent to the restarted node, for the LSP being recovered.
在发送方描述符中，必须包含恢复标签对象，标签值从发送到重新启动节点的最新关联Resv消息中标签对象中的标签值复制，以便恢复LSP。
All other objects from the most recent received Path message MUST be included in the RecoveryPath message.
RecoveryPath消息中必须包含最近收到的Path消息中的所有其他对象。
All RecoveryPath messages SHOULD be sent at least once within approximately 1/2 of the Recovery Time advertised by the restarted neighbor. If there are many LSPs to be recovered by the restarted node, the downstream RSVP neighbor should avoid sending RecoveryPath messages in a short time interval to avoid overloading the restarted node's CPU. Instead, it should spread the messages across 1/2 the Recovery Time interval. The range of Recovery Time is dependent on many factors including, but not limited to, the CPU processing power on the restarting node as well as the upstream and downstream neighbors, the amount of CPU available for processing RSVP recovery procedures, and the implementation specifics that affect the amount of time taken to verify the received recovery state against existing forwarding plane state. Such discussion is out of scope of this document.
所有RecoveryPath消息应在重启邻居通告的恢复时间的大约1/2内至少发送一次。如果重新启动的节点要恢复多个LSP，则下游RSVP邻居应避免在短时间间隔内发送RecoveryPath消息，以避免重新启动的节点的CPU过载。相反，它应该在1/2的恢复时间间隔内传播消息。恢复时间的范围取决于许多因素，包括但不限于重新启动节点以及上游和下游邻居上的CPU处理能力、可用于处理RSVP恢复过程的CPU数量，以及影响根据现有转发平面状态验证接收到的恢复状态所花费的时间量的实现细节。此类讨论超出了本文件的范围。
After sending a RecoveryPath message and during the Recovery Period, the node SHOULD periodically resend the RecoveryPath message until it receives a corresponding response. A corresponding response is a Message ID acknowledgment or a Path message for the LSP the RecoveryPath message represents. Each such resend attempt is at the end of any Message ID rapid retransmissions, if the Message ID mechanism is used. If the Message ID mechanism is not in use, the period between resend attempts SHOULD be such that at least 3 attempts are completed before the expiry of 3/4 the Recovery Time interval. Each such resend attempt MUST treat the RecoveryPath message as a new message and update the MESSAGE_ID object according to procedures defined in [RFC2961]. Note, per [RFC3473], Resv messages are suppressed during this recovery period until a corresponding Path message is received.
发送RecoveryPath消息后，在恢复期间，节点应定期重新发送RecoveryPath消息，直到收到相应的响应。对应的响应是RecoveryPath消息所代表的LSP的消息ID确认或路径消息。如果使用消息ID机制，则每次这样的重发尝试都会在任何消息ID快速重传结束时进行。如果未使用消息ID机制，则重新发送尝试之间的时间间隔应确保在恢复时间间隔的3/4到期之前至少完成3次尝试。每次重新发送尝试都必须将RecoveryPath消息视为新消息，并根据[RFC2961]中定义的过程更新消息\u ID对象。注意，根据[RFC3473]，Resv消息在此恢复期间被抑制，直到收到相应的Path消息。
These procedures apply during the "state recovery process" and "Recovery Period" as defined in Section 9.5.2 of [RFC3473]. Any RecoveryPath message received after the Recovery Period has expired SHOULD be matched against local LSP state. If matching fully resynchronized state is located, the node SHOULD send a Path message downstream. If non-resynchronized or no LSP state matching the RecoveryPath message is located, the restarted node MAY send a PathTear message constructed from the RecoveryPath message to
这些程序适用于[RFC3473]第9.5.2节中定义的“状态恢复过程”和“恢复期”。恢复期到期后收到的任何RecoveryPath消息都应与本地LSP状态匹配。如果找到匹配的完全重新同步状态，则节点应向下游发送路径消息。如果未找到与RecoveryPath消息匹配的未重新同步或LSP状态，则重新启动的节点可以将根据RecoveryPath消息构造的PathTrain消息发送到
expedite the cleanup of unrecovered RSVP and associated forwarding state downstream of the restarted node. The restarting node MUST NOT create data plane or forwarding state to match the received RecoveryPath message.
加快清理重新启动节点下游的未恢复RSVP和相关转发状态。重新启动节点不得创建与接收到的RecoveryPath消息匹配的数据平面或转发状态。
The remaining procedures are broken down into three sub-sections. The term "resynchronized state", originally defined in [RFC3473], is used and modified in these sections. This term refers to LSP state that is fully recovered.
其余程序分为三个小节。本节使用并修改了[RFC3473]中最初定义的术语“重新同步状态”。此术语指完全恢复的LSP状态。
Signaling state may be recovered from sources other than the mechanisms defined in this document. The restarting node SHOULD consider signaling state as resynchronized for all such LSPs and follow corresponding procedures defined below. Further, recovery procedures defined below may be overridden by local policy.
信号状态可以从本文件中定义的机制以外的来源恢复。重新启动节点应该将信号状态视为所有此类LSPs的再同步，并遵循下面定义的相应过程。此外，当地政策可能会覆盖以下定义的恢复程序。
Again, there are no changes to the procedures defined in Section 9.5.2 in [RFC3473] if the restarting node is an egress node.
同样，如果重新启动节点是出口节点，则[RFC3473]第9.5.2节中定义的程序没有变化。
When a node receives a RecoveryPath message during the Recovery Period, the node first checks if it has resynchronized RSVP state associated with the message. If there is resynchronized state, and when both reliable message delivery [RFC2961] is supported and a MESSAGE_ID object is present in the RecoveryPath message, the node MUST follow Message ID acknowledgment procedures, as defined in [RFC2961], and consider the message as processed. If there is resynchronized state and there is no MESSAGE_ID object or reliable message delivery [RFC2961] is not supported, the node SHOULD send a trigger Path message, and, consider the message as processed.
当节点在恢复期间收到RecoveryPath消息时，该节点首先检查是否具有与该消息关联的重新同步RSVP状态。如果存在重新同步状态，并且当支持可靠消息传递[RCF961]和在恢复路径消息中存在MeasAgID ID对象时，节点必须遵循如[RCFC961]中定义的消息ID确认过程，并将消息视为已处理。如果有重新同步状态并且没有消息对象ID或可靠消息传递[RFC961]不被支持，则节点应该发送触发路径消息，并将消息视为已处理。
If a non-resynchronized state is found or the node is the ingress, the node saves the information contained in the RecoveryPath message and continues with processing as defined in Section 4.5.2.2.
如果发现未重新同步状态或节点为入口，则节点将保存RecoveryPath消息中包含的信息，并继续进行第4.5.2.2节中定义的处理。
If no associated RSVP state is found and the node is not the ingress node, the node saves the information contained in the RecoveryPath message for later use.
如果未找到关联的RSVP状态，且该节点不是入口节点，则该节点会保存RecoveryPath消息中包含的信息，以供以后使用。
Note the following modifies Section 9.5.2 of [RFC3473]:
注：以下修改了[RFC3473]第9.5.2节：
When a node receives a Path message during the Recovery Period, the node first locates any RSVP state associated with the message. If resynchronized RSVP state is found, then the node handles this message according to previously defined procedures.
当节点在恢复期间收到Path消息时，该节点首先定位与该消息相关联的任何RSVP状态。如果找到重新同步的RSVP状态，则节点将根据先前定义的过程处理此消息。
If a non-resynchronized state is found, the node saves the information contained in the Path message, including the Recovery_Label object, and continues with processing as defined in Section 4.5.2.2.
如果发现未重新同步状态，则节点将保存路径消息中包含的信息，包括恢复标签对象，并继续进行第4.5.2.2节中定义的处理。
Per [RFC3473], if matching 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.
根据[RFC3473]，如果未找到匹配的RSVP状态，且消息未携带Recovery_标签对象，则节点将其视为新LSP的设置，并根据先前定义的过程进行处理。
If a matching RSVP state is not found and the message carries a Recovery_Label object, the node saves the information contained in the Path message, including the Recovery_Label object for later use.
如果未找到匹配的RSVP状态，并且消息包含Recovery_Label对象，则节点将保存路径消息中包含的信息，包括Recovery_Label对象，以供以后使用。
After receipt of the RecoveryPath message and, for non-ingress LSPs, the corresponding Path message with a Recovery Label object, the restarting node SHOULD locate and associate corresponding forwarding state using the received information. The restarting node associates the corresponding active forwarding plane state from the following signaled information:
在接收到RecoveryPath消息以及（对于非入口LSP）具有恢复标签对象的相应路径消息后，重新启动节点应使用接收到的信息定位并关联相应的转发状态。重新启动节点根据以下信号信息关联相应的活动转发平面状态：
The upstream data interface is recovered from the RSVP HOP object in the received Path message.
上游数据接口从接收到的Path消息中的RSVP HOP对象恢复。
The label on the upstream data interface is recovered from the Recovery Label object in the received Path message. If the LSP is bidirectional, the label for the upstream direction is recovered from the Upstream Label object in the received Path message.
上游数据接口上的标签从接收到的Path消息中的恢复标签对象恢复。如果LSP是双向的，则从接收到的路径消息中的上游标签对象恢复上游方向的标签。
The downstream data interface is recovered from the RSVP HOP object in the received RecoveryPath message.
从接收到的RecoveryPath消息中的RSVP HOP对象恢复下游数据接口。
The label on the downstream data interface is recovered from the Recovery Label object in the received RecoveryPath message. If the LSP is bidirectional, the label for the upstream direction is recovered from the Upstream Label object in the RecoveryPath message.
从接收到的RecoveryPath消息中的Recovery label对象恢复下游数据接口上的标签。如果LSP是双向的，则上游方向的标签将从RecoveryPath消息中的上游标签对象恢复。
If complete forwarding state is located, the restarted node MUST treat the LSP as resynchronized and MUST send a trigger Path message downstream. The Explicit Route object in the Path message SHOULD match the Explicit Route object received in the RecoveryPath message. In addition, the restarted node SHOULD recover state from the other objects received in the RecoveryPath message. Optimally, the resulting Path message should not cause any redundant or unnecessary reprocessing of state along the remaining downstream nodes. Ideally,
如果处于完全转发状态，则重新启动的节点必须将LSP视为重新同步，并且必须向下游发送触发路径消息。路径消息中的显式路由对象应与RecoveryPath消息中接收到的显式路由对象匹配。此外，重新启动的节点应该从RecoveryPath消息中接收的其他对象恢复状态。最佳情况下，生成的Path消息不应导致沿剩余下游节点对状态进行任何冗余或不必要的重新处理。理想的，
except for MESSAGE_ID processing and recovery processing, the transmitted Path message will be treated as a refresh by the downstream RSVP neighbor (and hence, should not trigger any generation of Path messages with changed state further downstream).
除了消息_ID处理和恢复处理外，传输的路径消息将被下游RSVP邻居视为刷新（因此，不应触发任何具有更下游更改状态的路径消息的生成）。
If no forwarding state is located, the node treats the received Path message as a setup request for a new LSP. The outgoing interface and label(s) indicated in the RecoveryPath message SHOULD be reused when possible. All other information contained in the RecoveryPath message MAY also be used. That is, forwarding state MUST NOT be created except after receipt of a Path message from upstream or, at an ingress node, the receipt of a command from the management plane. Further, the forwarding state created is subject to local policy and the information received from downstream in the RecoveryPath message is treated only as advisory.
如果未找到转发状态，则节点将接收到的路径消息视为新LSP的设置请求。如果可能，应重新使用RecoveryPath消息中指示的传出接口和标签。也可以使用RecoveryPath消息中包含的所有其他信息。也就是说，除非从上游接收到路径消息，或者在入口节点接收到来自管理平面的命令，否则不得创建转发状态。此外，创建的转发状态受本地策略的约束，并且在RecoveryPath消息中从下游接收的信息仅被视为建议。
There are several cleanup steps to follow at the end of the Recovery Period. At the end of the Recovery Period, any state that was installed as the result of a received RecoveryPath message that is not resynchronized SHOULD be discarded.
在恢复期结束时，需要执行几个清理步骤。在恢复期结束时，应丢弃因收到未重新同步的RecoveryPath消息而安装的任何状态。
Any Path messages that were received containing a Recovery_Label that has not been resynchronized, MUST be treated as being received during the Recovery Period and processed as per [RFC3473].
接收到的包含未重新同步的Recovery_标签的任何路径消息必须视为在恢复期间收到，并按照[RFC3473]进行处理。
Per [RFC3473], any other state that is not resynchronized during the Recovery Period SHOULD be removed at the end of the Period.
根据[RFC3473]，恢复期间未重新同步的任何其他状态应在恢复期间结束时删除。
This document introduces a new RSVP signaling message called the RecoveryPath message to be generated by the downstream RSVP neighbor of a restarting node. To advertise the capability of sending and receiving RecoveryPath messages, this document introduces the Capability object to be included in Hello messages by a restarting node and its downstream RSVP neighbors.
本文档介绍了一个新的RSVP信令消息，称为RecoveryPath消息，该消息将由重新启动节点的下游RSVP邻居生成。为了宣传发送和接收RecoveryPath消息的功能，本文档介绍了重启节点及其下游RSVP邻居将包含在Hello消息中的capability对象。
If a restarting node does not support the Capability object, it will discard the object, as the Class-Number is of the form 10bbbbbb, and revert to recovery processing as defined in [RFC3473]. The restarting node will not include the Capability object in its Hello messages. Hence, all downstream RSVP neighbors that detect that the restarting node is not capable of supporting the extensions defined in this document will not send the RecoveryPath messages to the restarting node and will revert to recovery processing as defined in [RFC3473].
如果重新启动的节点不支持该功能对象，它将丢弃该对象，因为类号的形式为10bbbbbb，并恢复到[RFC3473]中定义的恢复处理。重新启动节点将不会在其Hello消息中包含Capability对象。因此，检测到重启节点无法支持本文档中定义的扩展的所有下游RSVP邻居将不会向重启节点发送RecoveryPath消息，并将恢复到[RFC3473]中定义的恢复处理。
If a downstream RSVP neighbor does not support the Capability object, it will discard the object received in Hello messages and revert to recovery processing as defined in [RFC3473]. The downstream RSVP neighbor will not include the Capability object in its Hello messages. Hence, the restarting node will detect that the downstream RSVP neighbor is not capable of supporting the extensions defined in this document and will revert to recovery processing as defined in [RFC3473].
如果下游RSVP邻居不支持Capability对象，它将丢弃Hello消息中接收到的对象，并恢复到[RFC3473]中定义的恢复处理。下游RSVP邻居将不在其Hello消息中包含Capability对象。因此，重新启动节点将检测到下游RSVP邻居无法支持本文档中定义的扩展，并将恢复到[RFC3473]中定义的恢复处理。
This section describes a mechanism to control which LSP state is communicated in RecoveryPath messages. This mechanism enhances the Summary Refresh mechanism defined in [RFC2961], and uses the RecoveryPath Srefresh Capable (S) bit in the Capability object, as defined in Section 4.2, carried in the Hello message defined in [RFC3209] and [RFC3473]. The described mechanism is referred to as RecoveryPath Summary Refresh.
本节介绍一种机制，用于控制在RecoveryPath消息中传递哪个LSP状态。此机制增强了[RFC2961]中定义的摘要刷新机制，并在[RFC3209]和[RFC3473]中定义的Hello消息中携带的第4.2节中定义的Capability对象中使用RecoveryPath Srefresh-able位。所描述的机制称为RecoveryPath摘要刷新。
Selective transmission of RecoveryPath messages is controlled much the same way transmission of Path or Resv messages is controlled with standard Summary Refresh, see [RFC2961]. In standard Summary Refresh, an Srefresh message is sent by a node to identify to its neighbor about Path and Resv state that is locally installed and available. The receiver of the Srefresh message can then attempt to locate matching Path and Resv state. If no matching state is found, the receiver can request that the missing state be sent to it by sending an Srefresh NACK to the sender of the Srefresh message. When the Srefresh NACK is received, the corresponding Path or Resv message is sent. MESSAGE_ID information is used to identify Path and Resv state in this process.
RecoveryPath消息的选择性传输与Path或Resv消息的传输受标准摘要刷新控制的方式大致相同，请参见[RFC2961]。在标准摘要刷新中，节点发送Srefresh消息，以向其邻居标识本地安装并可用的路径和Resv状态。然后，Srefresh消息的接收者可以尝试定位匹配的路径和Resv状态。如果没有找到匹配的状态，接收方可以通过向Srefresh消息的发送方发送Srefresh NACK来请求向其发送缺少的状态。当接收到Srefresh NACK时，发送相应的路径或Resv消息。消息ID信息用于标识此过程中的路径和Resv状态。
The mechanism described in this section extends the Summary Refresh process to the Path state that can be represented in RecoveryPath messages. In this case, the Srefresh messages represent previously received Path messages, rather than previously transmitted Path messages. This is the primary difference between standard Summary Refresh and RecoveryPath Summary Refresh described in this section.
本节介绍的机制将摘要刷新过程扩展到可以在RecoveryPath消息中表示的路径状态。在这种情况下，Srefresh消息表示先前接收的路径消息，而不是先前发送的路径消息。这是本节介绍的标准摘要刷新和RecoveryPath摘要刷新之间的主要区别。
When a node restarts, and is capable of supporting the mechanisms described in this section, it includes the Capability object with the RecoveryPath Desired (R) bit set and the RecoveryPath Srefresh Capable (S) bit set in Hello messages it sends to its RSVP neighbors.
当节点重新启动并且能够支持本节中描述的机制时，它将在发送给其RSVP邻居的Hello消息中包含设置了RecoveryPath Desired（R）位和RecoveryPath Srefresh able（S）位的Capability对象。
When a neighbor of the restarting node detects a restart (see [RFC3209]), it detects that the restarted node is capable of receiving RecoveryPath messages, as defined in Section 4.4, and that the restarted node is requesting RecoveryPath Srefresh messages by
当重新启动节点的邻居检测到重新启动（请参见[RFC3209]）时，它检测到重新启动的节点能够接收第4.4节中定义的RecoveryPath消息，并且重新启动的节点通过以下方式请求RecoveryPath Srefresh消息：
the RecoveryPath Srefresh Capable (S) bit set in the Capability object. When such an indication is found, the neighbor generates one or more Srefresh messages. Each message indicates the Path state that can be represented in a RecoveryPath message. Within such Srefresh messages, the Path state that can be represented in RecoveryPath messages is represented using MESSAGE_ID information, and this information is communicated within MESSAGE_ID LIST objects. To indicate that the MESSAGE_ID LIST object is for recovery purposes, a new flag is set in the MESSAGE_ID LIST object. This flag is called the RecoveryPath Flag and is defined below.
在Capability对象中设置的RecoveryPath Srefresh能干位。当发现此类指示时，邻居将生成一条或多条Srefresh消息。每条消息都表示可以在RecoveryPath消息中表示的路径状态。在这些Srefresh消息中，可以在RecoveryPath消息中表示的路径状态是使用MESSAGE_ID信息表示的，并且该信息在MESSAGE_ID LIST对象中进行通信。要指示MESSAGE_ID LIST对象用于恢复目的，将在MESSAGE_ID LIST对象中设置一个新标志。此标志称为RecoveryPath标志，定义如下。
The restarted node can then use the Srefresh message and the MESSAGE_ID LIST object to try to identify matching transmitted Path state. The node identifies local state by matching Epoch and Message ID tuples against Path messages transmitted downstream prior to the restart.
然后，重新启动的节点可以使用Srefresh消息和message_ID LIST对象来尝试识别匹配的传输路径状态。节点通过在重启之前将历元和消息ID元组与下游传输的路径消息相匹配来识别本地状态。
If matching state is located, then the restarted node operates as if a RecoveryPath message has been received, per Section 4.5.2. If no matching state can be located, the restarted node generates a Srefresh NACK, see Section 5.4 of [RFC2961]. The Srefresh NACK is also marked with the new RecoveryPath Flag to indicate that the NACK is related to RecoveryPath messages.
如果找到了匹配状态，则根据第4.5.2节，重新启动的节点将像接收到RecoveryPath消息一样运行。如果找不到匹配状态，重新启动的节点将生成一个Srefresh NACK，请参见[RFC2961]的第5.4节。Srefresh NACK还标记有新的RecoveryPath标志，以指示NACK与RecoveryPath消息相关。
Upon receiving a Srefresh NACK, the downstream node generates a RecoveryPath message for the Path state indicated by each entry in the MESSAGE_ID LIST. The procedures defined in Section 4 above are then followed by the restarted node and the downstream RSVP neighbor.
在接收到Srefresh NACK后，下游节点为消息ID列表中的每个条目所指示的路径状态生成RecoveryPath消息。然后，重新启动的节点和下游RSVP邻居遵循上面第4节中定义的过程。
The MESSAGE_ID ACK/NACK objects and the MESSAGE_ID LIST object, defined in [RFC2961], are updated by this document. A new bit within the existing Flags field of each object is defined. This bit indicates that the object carries MESSAGE_ID information related to Path state that can be recovered using RecoveryPath messages. The same flag value is used in all the objects for consistency.
[RFC2961]中定义的MESSAGE_ID ACK/NACK对象和MESSAGE_ID LIST对象由本文档更新。在每个对象的现有标志字段中定义一个新位。此位表示对象携带与路径状态相关的消息ID信息，可使用RecoveryPath消息恢复该信息。为保持一致性，在所有对象中使用相同的标志值。
MESSAGE_ID_ACK object MESSAGE_ID_NACK object
消息\u ID\u确认对象消息\u ID\u NACK对象
See Section 4.3 of [RFC2961] for definition of other fields.
其他字段的定义见[RFC2961]第4.3节。
MESSAGE_ID LIST object
消息ID列表对象
See Section 5.1 of [RFC2961] for definition of other fields.
其他字段的定义见[RFC2961]第5.1节。
Flags: 8 bits
标志：8位
0x02: RecoveryPath Flag
0x02:RecoveryPath标志
Indicates that the associated object carries MESSAGE_ID information related to one or more Path messages that can be recovered using a RecoveryPath message.
指示关联对象包含与一个或多个路径消息相关的消息ID信息，这些消息可以使用RecoveryPath消息进行恢复。
The Capability object and the RecoveryPath Srefresh Capable (S) bit are defined in Section 4.2.
第4.2节定义了Capability对象和RecoveryPath Srefresh可恢复位。
To support the selective receipt of RecoveryPath messages as defined in this section, a restarting node MUST support the receipt and processing of RecoveryPath messages as defined in Section 4.5.2, and MUST indicate this capability by including the Capability object with the RecoveryPath Desired (R) bit set as defined in Section 4.4.2 in its Hello messages.
要支持选择性接收本节中定义的RecoveryPath消息，重新启动节点必须支持接收和处理第4.5.2节中定义的RecoveryPath消息，并且必须通过包含所需RecoveryPath（R）的capability对象来指示此功能按照第4.4.2节的Hello消息中的定义设置位。
To indicate to an RSVP neighbor that selective transmission of RecoveryPath messages is desired, a node MUST set (1) the S-bit in the Capability object in all Hello messages it sends. When the restarting node does not desire the receipt of RecoveryPath messages (see Section 4.4.2) or the selective transmission mechanism defined in this section, it MUST clear (0) the S-bit in the Capability object if included in Hello messages.
要向RSVP邻居指示需要选择性传输RecoveryPath消息，节点必须在其发送的所有Hello消息中设置（1）Capability对象中的S位。当重新启动节点不希望接收RecoveryPath消息（请参见第4.4.2节）或本节中定义的选择性传输机制时，它必须清除（0）包含在Hello消息中的Capability对象中的S位。
The downstream RSVP neighbor checks the R-bit and the S-bit upon detecting a restart of a node that supports state recovery with RecoveryPath messages. Detection of neighbor restarts with state recovery using RecoveryPath messages is defined in Section 4. If both the R-bit and the S-bit are set, then the procedures defined below in Section 5.3.1 MUST be followed. If the S-bit is cleared, the downstream RSVP neighbor MUST revert to normal procedures defined in Section 4.5.1. If the R-bit is cleared, but the S-bit is set, the
下游RSVP邻居在检测到支持使用RecoveryPath消息进行状态恢复的节点重新启动时检查R位和S位。第4节定义了使用RecoveryPath消息通过状态恢复检测邻居重启。如果同时设置了R位和S位，则必须遵循第5.3.1节中定义的程序。如果S位被清除，下游RSVP邻居必须恢复到第4.5.1节中定义的正常程序。如果清除了R位，但设置了S位，则
downstream RSVP neighbor MUST treat it as if the Capability object was received with the S-bit cleared. See Section 4.4 for handling of Hello messages without the Capability object.
下游RSVP邻居必须将其视为在S位清除的情况下接收到能力对象。有关不带Capability对象的Hello消息的处理，请参见第4.4节。
There are no compatibility issues introduced in the procedures defined in Section 5.2.1.
第5.2.1节中定义的程序中没有引入兼容性问题。
The restarting node will detect that its neighbor does not support selective transmission of RecoveryPath messages when a RecoveryPath message is received prior to the receipt of a Srefresh message containing a MESSAGE_ID LIST object with the RecoveryPath Flag set (1). When this occurs, any received RecoveryPath messages MUST be processed as defined in Section 4.
当在接收到包含设置了RecoveryPath标志（1）的message_ID LIST对象的Srefresh消息之前接收到RecoveryPath消息时，重新启动节点将检测到其邻居不支持选择性传输RecoveryPath消息。发生这种情况时，必须按照第4节中的定义处理任何接收到的RecoveryPath消息。
Related processing occurs in the following logical order:
相关处理按以下逻辑顺序进行：
o Generation of RecoveryPath-related Srefresh messages
o 生成与RecoveryPath相关的Srefresh消息
o RecoveryPath-related Srefresh message receive processing and NACK generation
o RecoveryPath相关的Srefresh消息接收处理和NACK生成
o Message ID NACK receive processing and generation of RecoveryPath messages
o 消息ID NACK接收RecoveryPath消息的处理和生成
o Receive processing of RecoveryPath messages
o 接收RecoveryPath消息的处理
Actual processing MAY result in the above occurring in an interlaced fashion when multiple LSPs are being recovered. Both the restarted node and the downstream RSVP neighbor MUST be able to process in this fashion.
当恢复多个lsp时，实际处理可能导致上述以隔行方式发生。重新启动的节点和下游RSVP邻居都必须能够以这种方式进行处理。
A neighbor of a restarting node generates one or more RecoveryPath-related Srefresh messages when the S-bit is set in the restarted node's Hello messages as described in Section 5.2.1. The procedures for generating an Srefresh message are defined in [RFC2961]. Only modifications to these procedures are described in this section. Also, Srefresh message transmit and receive processing may occur simultaneously during the Recovery Period and are not impacted by the procedures defined in this section.
如第5.2.1节所述，当在重启节点的Hello消息中设置S位时，重启节点的邻居会生成一个或多个与RecoveryPath相关的Srefresh消息。[RFC2961]中定义了生成Srefresh消息的过程。本节仅介绍对这些程序的修改。此外，Srefresh消息传输和接收处理可能在恢复期间同时进行，并且不受本节中定义的过程的影响。
To generate RecoveryPath-related Srefresh messages, a node must identify which Path state can be represented in RecoveryPath messages
要生成与RecoveryPath相关的Srefresh消息，节点必须标识RecoveryPath消息中可以表示的路径状态
and which Srefresh message or messages can be used to carry the related information. As previously mentioned, the Path state that can be represented in RecoveryPath messages is indicated in Srefresh messages using the MESSAGE_ID information from the most recently received Path message associated with the state.
以及哪些Srefresh消息或消息可用于承载相关信息。如前所述，可在RecoveryPath消息中表示的路径状态在Srefresh消息中使用来自与该状态关联的最近接收的路径消息的消息ID信息来指示。
After processing the S-bit as described in Section 5.2.1, the node identifies all state associated with Path messages received from the restarted neighbor. Only a Path state that has not been updated since the restart may be represented in the Srefresh messages. Received Path state containing a MESSAGE_ID object whose Epoch value matches the Epoch received in the most recent Hello message is considered as updated after the upstream neighbor has restarted. Such Path state MUST NOT be represented in the Srefresh messages. Each Srefresh message contains one or more MESSAGE_ID LIST objects. Each such MESSAGE_ID LIST object MUST have the RecoveryPath Flag set (1).
如第5.2.1节所述处理S位后，节点识别与从重启邻居接收的路径消息相关的所有状态。Srefresh消息中只能表示自重新启动以来未更新的路径状态。接收到的路径状态包含一个MESSAGE_ID对象，该对象的历元值与最近的Hello消息中接收到的历元相匹配，该状态在上游邻居重新启动后被视为已更新。这种路径状态不能在Srefresh消息中表示。每个Srefresh邮件包含一个或多个邮件ID列表对象。每个这样的消息\u ID LIST对象必须设置RecoveryPath标志（1）。
Multiple MESSAGE_ID LIST objects MAY be included in order to accommodate multiple Epoch values. The MESSAGE_ID LIST objects represent the identified, non-updated, Path state. A Message_Identifier field created for each identified, non-updated Path state MUST be included in an appropriate MESSAGE_ID LIST object. The Message_Identifier field is created based on the MESSAGE_ID object from the most recently received Path message associated with identified Path state. If any identified Path state does not have an associated MESSAGE_ID object, this state MUST be processed as defined above in Section 4.5.1.
为了容纳多个历元值，可以包括多个MESSAGE_ID LIST对象。MESSAGE_ID LIST对象表示已识别的、未更新的路径状态。为每个已识别、未更新的路径状态创建的消息标识符字段必须包含在相应的消息ID列表对象中。Message_Identifier字段是基于Message_ID对象创建的，该对象来自与已标识路径状态关联的最近接收的路径消息。如果任何已识别的路径状态没有关联的消息ID对象，则必须按照上文第4.5.1节中的定义处理该状态。
The source IP address for the Srefresh message SHOULD be the source IP address in the IP header of the corresponding Resv messages previously sent to the restarted node. The Srefresh message SHOULD be destined to the IP address in the HOP object in the corresponding Path messages. This may result in multiple Srefresh messages being generated. Per [RFC2961], implementations may choose to limit each Srefresh message to the MTU size of the outgoing link, and to not bundle Srefresh messages. RecoveryPath-related Srefresh messages SHOULD be sent using reliable delivery, as defined in [RFC2961].
Srefresh消息的源IP地址应该是先前发送到重新启动节点的相应Resv消息的IP头中的源IP地址。Srefresh消息应该发送到相应路径消息中HOP对象中的IP地址。这可能导致生成多条Srefresh消息。根据[RFC2961]，实现可以选择将每个Srefresh消息限制为传出链路的MTU大小，并且不捆绑Srefresh消息。应使用[RFC2961]中定义的可靠传递发送与RecoveryPath相关的Srefresh消息。
During the Recovery Period, unacknowledged RecoveryPath-related Srefresh messages SHOULD be periodically transmitted. The retransmission algorithm used can be the same algorithm used for retransmitting RecoveryPath messages during the Recovery Period (see Section 4.5.1). Note that prior to each such periodic retransmission, the Srefresh message SHOULD be updated to exclude the Message ID's of Path state that has been updated by the receipt of a Path message.
在恢复期间，应定期发送未确认的与RecoveryPath相关的Srefresh消息。所使用的重传算法可以与恢复期间重传RecoveryPath消息所使用的算法相同（参见第4.5.1节）。注意，在每次这样的周期性重传之前，应更新Srefresh消息以排除已通过接收路径消息而更新的路径状态的消息ID。
To allow sufficient processing time for the restarted node, the downstream RSVP neighbor MAY choose to generate multiple RecoveryPath-related Srefresh messages containing partial but mutually exclusive sets of Message Identifiers spread across 1/4 of the Recovery Time advertised by the restarted node.
为了允许重启节点有足够的处理时间，下游RSVP邻居可以选择生成多个与RecoveryPath相关的Srefresh消息，这些消息包含部分但互斥的消息标识符集，这些消息标识符分布在重启节点公布的恢复时间的1/4上。
5.3.2. RecoveryPath-Related Srefresh Receive Processing and NACK Generation
5.3.2. RecoveryPath相关的Srefresh接收处理和NACK生成
Upon receiving an Srefresh message containing a MESSAGE_ID LIST object with the RecoveryPath Flag set), the restarted node attempts to locate matching previously transmitted Path state. The Epoch in the MESSAGE_ID LIST object, along with each Message Identifier in the object, is used to match against the MESSAGE_ID object in Path messages previously transmitted to the downstream RSVP neighbor. For each Message Identifier in the MESSAGE_ID LIST:
在接收到一条Srefresh消息（该消息包含一个设置了RecoveryPath标志的message_ID LIST对象）后，重新启动的节点将尝试查找匹配的先前传输的路径状态。MESSAGE_ID LIST对象中的历元以及对象中的每个消息标识符用于与先前传输到下游RSVP邻居的路径消息中的MESSAGE_ID对象进行匹配。对于消息ID列表中的每个消息标识符：
If matching transmitted Path state is found, the restarting node treats the corresponding LSP state as having received and processed a RecoveryPath message and perform any further processing necessary as defined in Section 4.5.2. Specifically, it MUST generate a trigger Path message for the LSP as defined in Section 4.5.2.2. The restarted node MAY spread the transmission of such trigger Path messages across 1/2 of the remaining Recovery Period to allow the downstream RSVP neighbor sufficient processing time.
如果找到匹配的传输路径状态，重新启动节点将相应的LSP状态视为已接收并处理RecoveryPath消息，并执行第4.5.2节中定义的任何必要的进一步处理。具体而言，它必须为第4.5.2.2节中定义的LSP生成触发路径消息。重新启动的节点可以在剩余恢复周期的1/2上传播这种触发路径消息的传输，以允许下游RSVP邻居有足够的处理时间。
If matching transmitted Path state is not found, the restarting node MUST generate a MESSAGE_ID NACK as defined in [RFC2961]. Each generated MESSAGE_ID NACK MUST have the RecoveryPath Flag set (1).
如果未找到匹配的传输路径状态，则重新启动节点必须生成[RFC2961]中定义的消息\u ID NACK。每个生成的消息\u ID NACK必须设置RecoveryPath标志（1）。
It is recommended that the restarted node combine multiple such MESSAGE_ID NACKs into a single ACK message, per [RFC2961].
根据[RFC2961]，建议重新启动的节点将多个此类消息_ID nack组合成一条ACK消息。
This section defines the procedures associated with the processing of received MESSAGE_ID NACKs that have the RecoveryPath Flag set (1). Procedures for processing of MESSAGE_ID NACKs without the RecoveryPath Flag present are defined in [RFC2961] and not modified in this document. Processing of MESSAGE_ID NACKs with the RecoveryPath Flag set (1) also follows procedures defined in [RFC2961] unless explicitly modified in this section.
本节定义了与已设置RecoveryPath标志（1）的已接收消息ID NACK的处理相关的过程。[RFC2961]中定义了在不存在RecoveryPath标志的情况下处理消息_ID nack的过程，本文档中未对其进行修改。除非在本节中明确修改，否则使用RecoveryPath标志集（1）处理消息_ID NACKs时也遵循[RFC2961]中定义的过程。
For each MESSAGE_ID NACK with the RecoveryPath Flag set (1), the downstream RSVP neighbor must locate the matching received Path message. If a matching Path message is found, the downstream RSVP
对于设置了RecoveryPath标志（1）的每条消息_ID NACK，下游RSVP邻居必须找到匹配的接收路径消息。如果找到匹配的路径消息，则下游RSVP
neighbor MUST generate a RecoveryPath message as defined in Section 4.5.1. If a matching Path message is not found, the MESSAGE_ID NACK is ignored. An example where this may occur is when the restarted node has already generated an updated Path message after its restart.
邻居必须生成第4.5.1节中定义的RecoveryPath消息。如果未找到匹配的路径消息，则忽略消息_idnack。可能发生这种情况的一个示例是，重新启动的节点在重新启动后已生成更新的路径消息。
This document introduces a new RSVP message that is restricted to one RSVP hop. This document introduces no new security considerations beyond those already addressed for existing RSVP hop-by-hop messages.
本文档介绍了一个新的RSVP消息，该消息仅限于一个RSVP跃点。除了已经针对现有RSVP逐跳消息提出的安全注意事项外，本文档没有引入任何新的安全注意事项。
This document introduces a new RSVP object to be included in RSVP Hello messages. This document introduces no new security considerations beyond those already addressed for existing objects in RSVP Hello messages.
本文档介绍了一个新的RSVP对象，该对象将包含在RSVP Hello消息中。除了RSVP Hello消息中已有对象的安全注意事项外，本文档没有引入其他新的安全注意事项。
This document introduces new procedures to be performed on RSVP agents that neighbor a restarting RSVP agent. In situations where the control plane in general, and the RSVP agent in particular, of a node carrying one or more LSPs is restarted due to external attacks, the procedures introduced in this document provide the ability for the restarting RSVP agent to recover the RSVP state corresponding to the LSPs with the least possible perturbation to the rest of the network. Ideally, only the neighboring RSVP agents should notice the restart and hence need to perform additional processing. This allows for a network with active LSPs to recover LSP state gracefully from an external attack without perturbing the data/forwarding plane state.
本文档介绍了在重新启动RSVP代理的RSVP代理上执行的新过程。在承载一个或多个LSP的节点的控制平面（尤其是RSVP代理）由于外部攻击而重新启动的情况下，本文档中介绍的过程使重新启动的RSVP代理能够恢复与LSP对应的RSVP状态，同时对网络其余部分的干扰最小。理想情况下，只有相邻的RSVP代理才会注意到重启，因此需要执行额外的处理。这允许具有活动LSP的网络从外部攻击中优雅地恢复LSP状态，而不会干扰数据/转发平面状态。
[RFC2747] provides mechanisms to protect against external agents compromising the RSVP signaling state in an RSVP agent. These mechanisms, when used with the new message and procedures introduced in this document, provide the same degree of protection to the restarting RSVP agent against installing compromised signaling state from an external agent during its RSVP signaling state recovery.
[RFC2747]提供了防止外部代理损害RSVP代理中RSVP信令状态的机制。当与本文档中介绍的新消息和过程一起使用时，这些机制为重新启动的RSVP代理提供了相同程度的保护，防止在其RSVP信令状态恢复期间安装来自外部代理的受损信令状态。
Note that the procedures assume a full trust model between RSVP neighbors. That is, although the protocol exchanges before and after restart can be secured, and although it is possible to authenticate the identity of the neighbors, no mechanism is provided to verify that the restart information is correctly mapped from the protocol information exchanged before the restart. This is considered acceptable because a similar trust model is required for normal operation of the protocol.
请注意，这些过程假设RSVP邻居之间存在完全信任模型。也就是说，尽管可以保护重启前后的协议交换，并且尽管可以验证邻居的身份，但没有提供任何机制来验证重启信息是否正确映射自重启前交换的协议信息。这被认为是可以接受的，因为协议的正常运行需要类似的信任模型。
The procedures defined in this document introduce additional processing overhead for the RSVP agents that neighbor a restarting RSVP agent. If an RSVP agent restarts due to external attacks, such
本文档中定义的过程为与重新启动的RSVP代理相邻的RSVP代理引入了额外的处理开销。如果RSVP代理由于外部攻击而重新启动，则
added processing on the neighboring RSVP agents may impact their ability to perform other control plane tasks, including any processing for other LSPs that do not involve the restarting node. Such impact can be minimalized by the restarting RSVP agent using a large enough Recovery Time, so that its neighbors are provided sufficient time to handle the additional processing involved while continuing to perform their other control plane functions normally during the Recovery Period.
在相邻RSVP代理上添加的处理可能会影响其执行其他控制平面任务的能力，包括对不涉及重新启动节点的其他LSP的任何处理。通过使用足够长的恢复时间重新启动RSVP代理，可以将此类影响降至最低，以便为其邻居提供足够的时间来处理所涉及的附加处理，同时在恢复期间继续正常执行其其他控制平面功能。
Note that the procedures defined in this document cannot be used to create false forwarding state. The restarting node that receives a RecoveryPath message that does not match the existing forwarding state MUST NOT create or modify its forwarding state to match. A restarting node SHOULD log such an event or otherwise notify the operator since it might represent an attack.
请注意，本文档中定义的过程不能用于创建假转发状态。接收到与现有转发状态不匹配的RecoveryPath消息的重新启动节点不得创建或修改其转发状态以匹配。重新启动的节点应记录此类事件或通知操作员，因为这可能表示攻击。
The authors would like to thank participants of the CCAMP WG for comments and suggestions. Also thanks to Arthi Ayyangar, Adrian Farrel, Nick Neate, and Pavan Beeram for their helpful comments and feedback.
作者感谢CCAMP工作组的与会者提出的意见和建议。还要感谢阿尔西·艾扬加、阿德里安·法雷尔、尼克·尼特和帕万·比拉姆，感谢他们的宝贵意见和反馈。
Derek Atkins provided useful discussion during SecDir review. Sam Hartman gave careful scrutiny of the security considerations and the potential impact on the RSVP-TE security trust model.
Derek Atkins在SecDir审查期间提供了有用的讨论。Sam Hartman仔细审查了安全考虑因素以及对RSVP-TE安全信任模型的潜在影响。
Adrian Farrel edited the final revisions of this document as it progressed through IESG review.
阿德里安·法雷尔（Adrian Farrel）在IESG审查过程中编辑了本文件的最终修订版。
[RFC2205] defines the Class-Number name space for RSVP objects. The name space is managed by IANA.
[RFC2205]定义RSVP对象的类号名称空间。名称空间由IANA管理。
A new RSVP object using a Class-Number of form 10bbbbbb called the Capability Object is defined in Section 4.2 in this document. The Class-Number is 134.
本文件第4.2节定义了一个新的RSVP对象，该对象使用10bbbbbb形式的类号，称为能力对象。班号是134。
A new RSVP message type called a RecoveryPath message is defined in Section 4.1 of this document. The RSVP message type is 30.
本文档第4.1节定义了一种称为RecoveryPath消息的新RSVP消息类型。RSVP消息类型为30。
This document creates a new name space in the Capability object defined in Section 4.2. The new name space is a 32-bit-wide field. New registrations in this name space are to be allocated by IANA through an IETF Consensus action, per [RFC2434]. IANA also serves as the repository for this name space.
本文档在第4.2节中定义的功能对象中创建一个新的名称空间。新的名称空间是一个32位宽的字段。IANA将根据[RFC2434]通过IETF共识行动分配此名称空间中的新注册。IANA还充当此名称空间的存储库。
Section 4.2 defines the following bits in the 32-bit field of the Capability Object (134):
第4.2节定义了能力对象（134）的32位字段中的以下位：
RecoveryPath Transmit Enabled (T): 1 bit RecoveryPath Desired (R): 1 bit RecoveryPath Srefresh Capable (S): 1 bit
RecoveryPath传输已启用（T）：1位RecoveryPath所需（R）：1位RecoveryPath Srefresh可启用（S）：1位
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，B.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[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., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
Editors' Addresses
编辑地址
Arun Satyanarayana (editor) Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 USA Phone: +1 408 853 3206 EMail: asatyana@cisco.com
Arun Satyanarayana（编辑）思科系统公司170 West Tasman Dr.San Jose，CA 95134美国电话：+1 408 853 3206电子邮件：asatyana@cisco.com
Reshad Rahman (editor) Cisco Systems, Inc. 2000 Innovation Dr. Kanata, Ontario K2K 3E8 Canada Phone: 613 254 3519 EMail: rrahman@cisco.com
Reshad Rahman（编辑）Cisco Systems，Inc.2000加拿大安大略省卡纳塔创新博士K2K 3E8加拿大电话：613 254 3519电子邮件：rrahman@cisco.com
Authors' Addresses
作者地址
Dimitri Papadimitriou Alcatel Francis Wellesplein 1 B-2018 Antwerpen Belgium Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel-lucent.be
Dimitri Papadimitriou Alcatel Francis Wellesplein 1 B-2018比利时安特卫普电话：+32 3 240-8491电子邮件：Dimitri。papadimitriou@alcatel-朗讯
Lou Berger LabN Consulting, L.L.C. Phone: +1 301 468 9228 EMail: lberger@labn.net
Lou Berger LabN Consulting，L.L.C.电话：+1 301 468 9228电子邮件：lberger@labn.net
Anca Zamfir Cisco Systems, Inc. 2000 Innovation Dr. Kanata, Ontario K2K 3E8 Canada Phone: 613 254 3484 EMail: ancaz@cisco.com
安卡·赞菲尔思科系统公司，2000年，安大略省卡纳塔创新博士K2K 3E8加拿大电话：613 254 3484电子邮件：ancaz@cisco.com
Junaid Israr Cisco Systems, Inc. 2000 Innovation Dr. Kanata, Ontario K2K 3E8 Canada Phone: 613 254 3693 EMail: jisrar@cisco.com
Junaid Israr Cisco Systems，Inc.2000安大略省卡纳塔创新博士K2K 3E8加拿大电话：613 254 3693电子邮件：jisrar@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.