Network Working Group D. Li
Request for Comments: 5495 J. Gao
Category: Informational Huawei
A. Satyanarayana
Cisco
S. Bardalai
Fujitsu
March 2009
Network Working Group D. Li
Request for Comments: 5495 J. Gao
Category: Informational Huawei
A. Satyanarayana
Cisco
S. Bardalai
Fujitsu
March 2009
Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Procedures
资源预留协议-流量工程（RSVP-TE）优雅重启过程的说明
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
The Hello message for the Resource Reservation Protocol (RSVP) has been defined to establish and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) participating in a Multiprotocol Label Switching (MPLS) traffic-engineered (TE) network. The Hello message has been extended for use in Generalized MPLS (GMPLS) networks for state recovery of control channel or nodal faults.
资源预留协议（RSVP）的Hello消息被定义为建立和维护参与多协议标签交换（MPLS）流量工程（TE）网络的标签交换路由器（LSR）的基本信令节点邻接。Hello消息已扩展用于广义MPLS（GMPLS）网络，用于控制信道或节点故障的状态恢复。
The GMPLS protocol definitions for RSVP also allow a restarting node to learn which label it previously allocated for use on a Label Switched Path (LSP).
RSVP的GMPLS协议定义还允许重新启动的节点了解其先前分配用于标签交换路径（LSP）的标签。
Further RSVP protocol extensions have been defined to enable a restarting node to recover full control plane state by exchanging RSVP messages with its upstream and downstream neighbors.
已定义了进一步的RSVP协议扩展，以使重新启动的节点能够通过与其上游和下游邻居交换RSVP消息来恢复完全控制平面状态。
This document provides an informational clarification of the control plane procedures for a GMPLS network when there are multiple node failures, and describes how full control plane state can be recovered in different scenarios where the order in which the nodes restart is different.
本文档提供了当存在多个节点故障时GMPLS网络控制平面程序的信息说明，并描述了如何在节点重启顺序不同的不同场景中恢复完全控制平面状态。
This document does not define any new processes or procedures. All protocol mechanisms are already defined in the referenced documents.
本文件未定义任何新流程或程序。所有协议机制已在参考文件中定义。
Table of Contents
目录
1. Introduction ....................................................3
2. Existing Procedures for Single Node Restart .....................4
2.1. Procedures Defined in RFC 3473 .............................4
2.2. Procedures Defined in RFC 5063 .............................5
3. Multiple Node Restart Scenarios .................................6
4. RSVP State ......................................................7
5. Procedures for Multiple Node Restart ............................7
5.1. Procedures for the Normal Node .............................8
5.2. Procedures for the Restarting Node .........................8
5.2.1. Procedures for Scenario 1 ...........................8
5.2.2. Procedures for Scenario 2 ...........................9
5.2.3. Procedures for Scenario 3 ..........................11
5.2.4. Procedures for Scenario 4 ..........................12
5.2.5. Procedures for Scenario 5 ..........................12
5.3. Consideration of the Reuse of Data Plane Resources ........12
5.4. Consideration of Management Plane Intervention ............13
6. Clarification of Restarting Node Procedure .....................13
7. Security Considerations ........................................15
8. Acknowledgments ................................................16
9. References .....................................................17
9.1. Normative References ......................................17
9.2. Informative References ....................................17
1. Introduction ....................................................3
2. Existing Procedures for Single Node Restart .....................4
2.1. Procedures Defined in RFC 3473 .............................4
2.2. Procedures Defined in RFC 5063 .............................5
3. Multiple Node Restart Scenarios .................................6
4. RSVP State ......................................................7
5. Procedures for Multiple Node Restart ............................7
5.1. Procedures for the Normal Node .............................8
5.2. Procedures for the Restarting Node .........................8
5.2.1. Procedures for Scenario 1 ...........................8
5.2.2. Procedures for Scenario 2 ...........................9
5.2.3. Procedures for Scenario 3 ..........................11
5.2.4. Procedures for Scenario 4 ..........................12
5.2.5. Procedures for Scenario 5 ..........................12
5.3. Consideration of the Reuse of Data Plane Resources ........12
5.4. Consideration of Management Plane Intervention ............13
6. Clarification of Restarting Node Procedure .....................13
7. Security Considerations ........................................15
8. Acknowledgments ................................................16
9. References .....................................................17
9.1. Normative References ......................................17
9.2. Informative References ....................................17
The Hello message for the Resource Reservation Protocol (RSVP) has been defined to establish and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) participating in a Multiprotocol Label Switching (MPLS) traffic-engineered (TE) network [RFC3209]. The Hello message has been extended for use in Generalized MPLS (GMPLS) networks for state recovery of control channel or nodal faults through the exchange of the Restart_Cap Object [RFC3473].
资源预留协议（RSVP）的Hello消息已定义为建立和维护参与多协议标签交换（MPLS）流量工程（TE）网络的标签交换路由器（LSR）的基本信令节点邻接[RFC3209]。Hello消息已被扩展，以便在通用MPLS（GMPLS）网络中使用，通过交换Restart_Cap对象[RFC3473]来恢复控制通道或节点故障的状态。
The GMPLS protocol definitions for RSVP [RFC3473] also allow a restarting node to learn which label it previously allocated for use on a Label Switched Path (LSP) through the Recovery_Label Object carried on a Path message sent to a restarting node from its upstream neighbor.
RSVP[RFC3473]的GMPLS协议定义还允许重启节点通过从其上游邻居发送到重启节点的路径消息中携带的Recovery_label对象，了解其先前分配用于标签交换路径（LSP）的标签。
Further RSVP protocol extensions have been defined [RFC5063] to perform graceful restart and to enable a restarting node to recover full control plane state by exchanging RSVP messages with its upstream and downstream neighbors. State previously transmitted to the upstream neighbor (principally, the downstream label) is recovered from the upstream neighbor on a Path message (using the
已经定义了进一步的RSVP协议扩展[RFC5063]，以执行正常重启，并使重启节点能够通过与其上游和下游邻居交换RSVP消息来恢复完全控制平面状态。先前传输到上游邻居（主要是下游标签）的状态通过路径消息从上游邻居恢复（使用
Recovery_Label Object as described in [RFC3473]). State previously transmitted to the downstream neighbor (including the upstream label, interface identifiers, and the explicit route) is recovered from the downstream neighbor using a RecoveryPath message.
[RFC3473]中所述的恢复标签对象。使用RecoveryPath消息从下游邻居恢复先前传输到下游邻居的状态（包括上游标签、接口标识符和显式路由）。
[RFC5063] also extends the Hello message to exchange information about the ability to support the RecoveryPath message.
[RFC5063]还扩展了Hello消息，以交换有关支持RecoveryPath消息的能力的信息。
The examples and procedures in [RFC3473] and [RFC5063] focus on the description of a single node restart when adjacent network nodes are operative. Although the procedures are equally applicable to multi-node restarts, no detailed explanation is provided for such a case.
[RFC3473]和[RFC5063]中的示例和步骤重点介绍了相邻网络节点工作时单节点重启的说明。尽管这些程序同样适用于多节点重启，但对于这种情况没有提供详细的解释。
This document provides an informational clarification of the control plane procedures for a GMPLS network when there are multiple node failures, and describes how full control plane state can be recovered in different scenarios where the order in which the nodes restart is different.
本文档提供了当存在多个节点故障时GMPLS网络控制平面程序的信息说明，并描述了如何在节点重启顺序不同的不同场景中恢复完全控制平面状态。
This document does not define any new processes or procedures. All protocol mechanisms already defined in [RFC3473] and [RFC5063] are definitive.
本文件未定义任何新流程或程序。[RFC3473]和[RFC5063]中已经定义的所有协议机制都是确定的。
This section documents for information the existing procedures defined in [RFC3473] and [RFC5063]. Those documents are definitive, and the description here is non-normative. It is provided for informational clarification only.
本节记录了[RFC3473]和[RFC5063]中定义的现有程序的信息。这些文件是确定的，此处的描述是非规范性的。本文件仅供信息澄清之用。
In the case of nodal faults, the procedures for the restarting node and the procedures for the neighbor of a restarting node are applied to the corresponding nodes. These procedures, described in [RFC3473], are summarized as follows:
在节点故障的情况下，重新启动节点的程序和重新启动节点的邻居的程序应用于相应的节点。[RFC3473]中描述的这些程序总结如下：
For the Restarting Node:
对于重新启动节点：
1) Tells its neighbors that state recovery is supported using the Hello message.
1) 通知其邻居使用Hello消息支持状态恢复。
2) Recovers its RSVP state with the help of a Path message, received from its upstream neighbor, that carries the Recovery_Label Object.
2) 借助于从其上游邻居接收的路径消息恢复其RSVP状态，该消息携带Recovery_Label对象。
3) For bidirectional LSPs, uses the Upstream_Label Object on the received Path message to recover the corresponding RSVP state.
3) 对于双向LSP，使用接收到的路径消息上的上游_标签对象来恢复相应的RSVP状态。
4) If the corresponding forwarding state in the data plane does not exist, the node treats this as a setup for a new LSP. If the forwarding state in the data plane does exist, the forwarding state is bound to the LSP associated with the message, and the related forwarding state should be considered as valid and refreshed. In addition, if the node is not the tail-end of the LSP, the incoming label on the downstream interface is retrieved from the forwarding state on the restarting node and set in the Upstream_Label Object in the Path message sent to the downstream neighbor.
4) 如果数据平面中不存在相应的转发状态，则节点将其视为新LSP的设置。如果数据平面中确实存在转发状态，则转发状态将绑定到与消息关联的LSP，并且相关的转发状态应视为有效并刷新。此外，如果节点不是LSP的尾端，则从重新启动节点上的转发状态检索下游接口上的传入标签，并在发送给下游邻居的路径消息中的上游_标签对象中设置。
For the Neighbor of a Restarting Node:
对于重新启动节点的邻居：
1) Sends a Path message with the Recovery_Label Object containing a label value corresponding to the label value received in the most recently received corresponding Resv message.
1) 发送带有Recovery_Label对象的路径消息，该对象包含与最近接收的相应Resv消息中接收到的标签值相对应的标签值。
2) Resumes refreshing Path state with the restarting node.
2) 通过重新启动节点恢复刷新路径状态。
3) Resumes refreshing Resv state with the restarting node.
3) 通过重新启动节点恢复刷新Resv状态。
A new message is introduced in [RFC5063] called the RecoveryPath message. This message is sent by the downstream neighbor of a restarting node to convey the contents of the last received Path message back to the restarting node.
[RFC5063]中引入了一条称为RecoveryPath消息的新消息。该消息由重启节点的下游邻居发送，以将最后接收到的路径消息的内容传回重启节点。
The restarting node will receive the Path message with the Recovery_Label Object from its upstream neighbor and/or the RecoveryPath message from its downstream neighbor. The full RSVP state of the restarting node can be recovered from these two messages.
重新启动节点将从其上游邻居接收带有Recovery_标签对象的路径消息和/或从其下游邻居接收RecoveryPath消息。可以从这两条消息中恢复重新启动节点的完整RSVP状态。
The following state can be recovered from the received Path message:
可以从收到的Path消息中恢复以下状态：
o Upstream data interface (from RSVP_Hop Object)
o 上游数据接口（来自RSVP_-Hop对象）
o Label on the upstream data interface (from Recovery_Label Object)
o 上游数据接口上的标签（从恢复\u标签对象）
o Upstream label for bidirectional LSP (from Upstream_Label Object)
o 双向LSP的上游标签（来自上游标签对象）
The following state can be recovered from the received RecoveryPath message:
可以从收到的RecoveryPath消息中恢复以下状态：
o Downstream data interface (from RSVP_Hop Object)
o 下游数据接口（来自RSVP_-Hop对象）
o Label on the downstream data interface (from Recovery_Label Object)
o 下游数据接口上的标签（从恢复标签对象）
o Upstream direction label for bidirectional LSP (from Upstream_Label Object)
o 双向LSP的上游方向标签（来自上游标签对象）
The other objects originally exchanged on Path and Resv messages can be recovered from the regular Path and Resv refresh messages, or from the RecoveryPath.
最初在Path和Resv消息上交换的其他对象可以从常规Path和Resv刷新消息中恢复，也可以从RecoveryPath中恢复。
We define the following terms for the different node types:
我们为不同的节点类型定义以下术语：
Restarting - The node has restarted. Communication with its neighbor nodes is restored, and its RSVP state is under recovery.
重新启动-节点已重新启动。与其邻居节点的通信已恢复，其RSVP状态正在恢复中。
Delayed Restarting - The node has restarted, but the communication with a neighbor node is interrupted (for example, the neighbor node needs to restart).
延迟重新启动-节点已重新启动，但与邻居节点的通信中断（例如，邻居节点需要重新启动）。
Normal - The normal node is the fully operational neighbor of a restarting or delayed restarting node.
正常-正常节点是重新启动或延迟重新启动节点的完全运行邻居。
There are five scenarios for multi-node restart. We will focus on the different positions of a restarting node. As shown in Figure 1, an LSP starts from Node A, traverses Nodes B and C, and ends at Node D.
多节点重启有五种方案。我们将重点介绍重新启动节点的不同位置。如图1所示，LSP从节点A开始，穿过节点B和C，并在节点D结束。
+-----+ Path +-----+ Path +-----+ Path +-----+
| PSB |------->| PSB |------->| PSB |------->| PSB |
| | | | | | | |
| RSB |<-------| RSB |<-------| RSB |<-------| RSB |
+-----+ Resv +-----+ Resv +-----+ Resv +-----+
Node A Node B Node C Node D
+-----+ Path +-----+ Path +-----+ Path +-----+
| PSB |------->| PSB |------->| PSB |------->| PSB |
| | | | | | | |
| RSB |<-------| RSB |<-------| RSB |<-------| RSB |
+-----+ Resv +-----+ Resv +-----+ Resv +-----+
Node A Node B Node C Node D
Figure 1: Two Neighbor Nodes Restart
图1：两个相邻节点重新启动
1) A restarting node with downstream delayed restarting node. For example, in Figure 1, Nodes A and D are normal nodes, Node B is a restarting node, and Node C is a delayed restarting node.
1) 具有下游延迟重新启动节点的重新启动节点。例如，在图1中，节点A和D是正常节点，节点B是重启节点，节点C是延迟重启节点。
2) A restarting node with upstream delayed restarting node. For example, in Figure 1, Nodes A and D are normal nodes, Node B is a delayed restarting node, and Node C is a restarting node.
2) 具有上游延迟重新启动节点的重新启动节点。例如，在图1中，节点A和D是正常节点，节点B是延迟重启节点，节点C是重启节点。
3) A restarting node with downstream and upstream delayed restarting nodes. For example, in Figure 1, Node A is a normal node, Nodes B and D are delayed restarting nodes, and Node C is a restarting node.
3) 具有下游和上游延迟重启节点的重启节点。例如，在图1中，节点A是正常节点，节点B和D是延迟重启节点，节点C是重启节点。
4) A restarting ingress node with downstream delayed restarting node. For example, in Figure 1, Node A is a restarting node and Node B is a delayed restarting node. Nodes C and D are normal nodes.
4) 具有下游延迟重启节点的重启入口节点。例如，在图1中，节点A是重启节点，节点B是延迟重启节点。节点C和D是正常节点。
5) A restarting egress node with upstream delayed restarting node. For example, in Figure 1, Nodes A and B are normal nodes, Node C is a delayed restarting node, and Node D is a restarting node.
5) 具有上游延迟重启节点的重启出口节点。例如，在图1中，节点A和B是正常节点，节点C是延迟重启节点，节点D是重启节点。
If the communication between two nodes is interrupted, the upstream node may think the downstream node is a delayed restarting node, or vice versa.
如果两个节点之间的通信中断，则上游节点可能认为下游节点是延迟重启节点，反之亦然。
Note that if multiple nodes that are not neighbors are restarted, the restart procedures could be applied as multiple separated restart procedures that are exactly the same as the procedures described in [RFC3473] and [RFC5063]. Therefore, these scenarios are not described in this document. For example, in Figure 1, Node A and Node C are normal nodes, and Node B and Node D are restarting nodes; therefore, Node B could be restarted through Node A and Node C, while Node D could be restarted through Node C separately.
请注意，如果重新启动多个非相邻节点，则重新启动过程可以作为多个单独的重新启动过程应用，这些过程与[RFC3473]和[RFC5063]中描述的过程完全相同。因此，本文档中不描述这些场景。例如，在图1中，节点A和节点C是正常节点，节点B和节点D是重启节点；因此，节点B可以通过节点A和节点C重新启动，而节点D可以分别通过节点C重新启动。
For each scenario, the RSVP state that needs to be recovered at the restarting nodes are the Path State Block (PSB) and Resv State Block (RSB), which are created when the node receives the corresponding Path message and Resv message.
对于每个场景，需要在重启节点恢复的RSVP状态是路径状态块（PSB）和Resv状态块（RSB），它们是在节点接收到相应的路径消息和Resv消息时创建的。
According to [RFC2209], how to construct the PSB and RSB is really an implementation issue. In fact, there is no requirement to maintain separate PSB and RSB data structures. In GMPLS, there is a much closer tie between Path and Resv state so it is possible to combine the information into a single state block (the LSP state block). On the other hand, if point-to-multipoint is supported, it may be convenient to maintain separate upstream and downstream state. Note that the PSB and RSB are not upstream and downstream state since the PSB is responsible for receiving a Path from upstream and sending a Path to downstream.
根据[RFC2209]，如何构造PSB和RSB实际上是一个实现问题。事实上，不需要维护单独的PSB和RSB数据结构。在GMPLS中，路径和Resv状态之间有着更紧密的联系，因此可以将信息组合成单个状态块（LSP状态块）。另一方面，如果支持点对多点，则可以方便地保持单独的上游和下游状态。请注意，PSB和RSB不是上游和下游状态，因为PSB负责从上游接收路径并向下游发送路径。
Regardless of how the RSVP state is implemented, on recovery there are two logical pieces of state to be recovered and these correspond to the PSB and RSB.
无论RSVP状态是如何实现的，在恢复时都有两个逻辑状态块要恢复，它们对应于PSB和RSB。
In this document, all the nodes are assumed to have the graceful restart capabilities that are described in [RFC3473] and [RFC5063].
在本文档中，假设所有节点都具有[RFC3473]和[RFC5063]中所述的优雅重启功能。
When the downstream normal node detects its neighbor restarting, it must send a RecoveryPath message for each LSP associated with the restarting node for which it has previously sent a Resv message and which has not been torn down.
当下游正常节点检测到其邻居重新启动时，它必须为与重新启动节点关联的每个LSP发送RecoveryPath消息，该重新启动节点之前已为其发送Resv消息，但尚未拆除。
When the upstream normal node detects its neighbor restarting, it must send a Path message with a Recovery_Label Object containing a label value corresponding to the label value received in the most recently received corresponding Resv message.
当上游正常节点检测到其邻居重新启动时，它必须发送一条路径消息，其中包含一个Recovery_Label对象，该对象包含一个标签值，该标签值与最近接收到的相应Resv消息中接收到的标签值相对应。
This document does not modify the procedures for the normal node, which are described in [RFC3473] and [RFC5063].
本文档不修改[RFC3473]和[RFC5063]中描述的普通节点的程序。
This document does not modify the procedures for the restarting node, which are described in [RFC3473] and [RFC5063].
本文档不修改[RFC3473]和[RFC5063]中描述的重新启动节点的步骤。
After the restarting node restarts, it starts a Recovery Timer. Any RSVP state that has not been resynchronized when the Recovery Timer expires should be cleared.
重新启动节点重新启动后，将启动恢复计时器。恢复计时器过期时未重新同步的任何RSVP状态都应清除。
At the restarting node (Node B in the example), full resynchronization with the upstream neighbor (Node A) is possible because Node A is a normal node. The upstream Path information is recovered from the Path message received from Node A. Node B also recovers the upstream Resv information (that it had previously sent to Node A) from the Recovery_Label Object carried in the Path message received from Node A, but, obviously, some information (like the Recorded_Route Object) will be missing from the new Resv message generated by Node B and cannot be supplied until the downstream delayed restarting node (Node C) restarts and sends a Resv.
在重新启动节点（示例中的节点B）处，可以与上游邻居（节点A）完全重新同步，因为节点A是正常节点。上游路径信息从从节点A接收的路径消息中恢复。节点B还从从从节点A接收的路径消息中携带的恢复标签对象中恢复上游Resv信息（它以前发送给节点A），但显然，一些信息（如记录的路由对象）将从节点B生成的新Resv消息中丢失，并且在下游延迟重新启动节点（节点C）重新启动并发送Resv之前无法提供。
After the upstream Path information and upstream Resv information have been recovered by Node B, the normal refresh procedure with upstream Node A should be started.
在节点B恢复了上游路径信息和上游Resv信息之后，应该开始与上游节点A的正常刷新过程。
As per [RFC5063], the restarting node (Node B) would normally expect to receive a RecoveryPath message from its downstream neighbor (Node C). It would use this to recover the downstream Path information, and would subsequently send a Path message to its downstream neighbor and receive a Resv message. But in this scenario, because the downstream neighbor has not restarted yet, Node B detects the communication with
根据[RFC5063]，重启节点（节点B）通常期望从其下游邻居（节点C）接收RecoveryPath消息。它将使用它来恢复下游路径信息，随后将向其下游邻居发送路径消息并接收Resv消息。但在这种情况下，由于下游邻居尚未重新启动，节点B检测到与的通信
Node C is interrupted and must wait before resynchronizing with its downstream neighbor.
节点C被中断，必须等待与下游邻居重新同步。
In this case, the restarting node (Node B) follows the procedures in Section 9.3 of [RFC3473] and may run a Restart Timer to wait for the downstream neighbor (Node C) to restart. If its downstream neighbor (Node C) has not restarted before the timer expires, the corresponding LSPs may be torn down according to local policy [RFC3473]. Note, however, that the Restart Time value suggested in [RFC3473] is based on the previous Hello message exchanged with the node that has not restarted yet (Node C). Since this time value is unlikely to be available to the restarting node (Node B), a configured time value must be used if the timer is operated.
在这种情况下，重新启动节点（节点B）遵循[RFC3473]第9.3节中的程序，并可运行重新启动计时器以等待下游邻居（节点C）重新启动。如果其下游邻居（节点C）在计时器到期之前未重新启动，则可根据本地策略[RFC3473]拆除相应的LSP。但是，请注意，[RFC3473]中建议的重新启动时间值基于与尚未重新启动的节点（节点C）交换的先前Hello消息。由于重新启动节点（节点B）不太可能使用此时间值，因此，如果计时器运行，则必须使用配置的时间值。
The RSVP state must be reconciled with the retained data plane state if the cross-connect information can be retrieved from the data plane. In the event of any mismatches, local policy will dictate the action that must be taken, which could include:
如果可以从数据平面检索交叉连接信息，则RSVP状态必须与保留的数据平面状态一致。如果出现任何不匹配，当地政策将规定必须采取的行动，包括：
- reprogramming the data plane
- 重新编程数据平面
- sending an alert to the management plane
- 向管理平面发送警报
- tearing down the control plane state for the LSP
- 正在拆除LSP的控制平面状态
In the case that the delayed restarting node never comes back and a Restart Timer is not used to automatically tear down LSPs, the LSPs can be tidied up through the control plane using a PathTear from the upstream node (Node A). Note that if Node C restarts after this operation, the RecoveryPath message that it sends to Node B will not be matched with any state on Node B and will receive a PathTear as its response, resulting in the teardown of the LSP at all downstream nodes.
如果延迟的重新启动节点从未返回，并且重新启动计时器未用于自动拆除LSP，则可以使用来自上游节点（节点a）的路径撕裂通过控制平面清理LSP。请注意，如果节点C在此操作后重新启动，则它发送给节点B的RecoveryPath消息将不会与节点B上的任何状态匹配，并将收到PathTrain作为其响应，从而导致在所有下游节点上拆除LSP。
In this case, the restarting node (Node C) can recover full downstream state from its downstream neighbor (Node D), which is a normal node. The downstream Path state can be recovered from the RecoveryPath message, which is sent by Node D. This allows Node C to send a Path refresh message to Node D, and Node D will respond with a Resv message from which Node C can reconstruct the downstream Resv state.
在这种情况下，重新启动节点（节点C）可以从其下游邻居（节点D）恢复完全下游状态，后者是正常节点。下游路径状态可以从节点D发送的RecoveryPath消息中恢复。这允许节点C向节点D发送路径刷新消息，节点D将使用Resv消息进行响应，节点C可以从中重建下游Resv状态。
After the downstream Path information and downstream Resv information have been recovered in Node C, the normal refresh procedure with downstream Node D should be started.
在节点C中恢复了下游路径信息和下游Resv信息之后，应该启动与下游节点D的正常刷新过程。
The restarting node would normally expect to resynchronize with its upstream neighbor to re-learn the upstream Path and Resv state, but in this scenario, because the upstream neighbor (Node B) has not restarted yet, the restarting node (Node C) detects that the communication with upstream neighbor (Node B) is interrupted. The restarting node (Node C) follows the procedures in Section 9.3 of [RFC3473] and may run a Restart Timer to wait for the upstream neighbor (Node B) to restart. If its upstream neighbor (Node B) has not restarted before the Restart Timer expires, the corresponding LSPs may be torn down according to local policy [RFC3473]. Note, however, that the Restart Time value suggested in [RFC3473] is based on the previous Hello message exchanged with the node that has not restarted yet (Node B). Since this time value is unlikely to be available to the restarting node (Node C), a configured time value must be used if the timer is operated.
重新启动的节点通常期望与其上游邻居重新同步以重新学习上游路径和Resv状态，但在这种情况下，由于上游邻居（节点B）尚未重新启动，重新启动的节点（节点C）检测到与上游邻居（节点B）的通信中断。重新启动节点（节点C）遵循[RFC3473]第9.3节中的程序，并可运行重新启动计时器以等待上游邻居（节点B）重新启动。如果其上游邻居（节点B）在重启计时器到期之前未重启，则可根据本地策略[RFC3473]拆除相应的LSP。但是，请注意，[RFC3473]中建议的重启时间值基于与尚未重启的节点（节点B）交换的先前Hello消息。由于重新启动节点（节点C）不太可能使用此时间值，因此，如果计时器运行，则必须使用配置的时间值。
Note that no Resv message is sent to the upstream neighbor (Node B), because it has not restarted.
请注意，没有向上游邻居（节点B）发送Resv消息，因为它尚未重新启动。
The RSVP state must be reconciled with the retained data plane state if the cross-connect information can be retrieved from the data plane.
如果可以从数据平面检索交叉连接信息，则RSVP状态必须与保留的数据平面状态一致。
In the event of any mismatches, local policy will dictate the action that must be taken, which could include:
如果出现任何不匹配，当地政策将规定必须采取的行动，包括：
- reprogramming the data plane
- 重新编程数据平面
- sending an alert to the management plane
- 向管理平面发送警报
- tearing down the control plane state for the LSP
- 正在拆除LSP的控制平面状态
In the case that the delayed restarting node never comes back and a Restart Timer is not used to automatically tear down LSPs, the LSPs cannot be tidied up through the control plane using a PathTear from the upstream node (Node A), because there is no control plane connectivity to Node C from the upstream direction. There are two possibilities in [RFC3473]:
在延迟重新启动节点永不回来且重新启动计时器未用于自动拆除LSP的情况下，无法使用来自上游节点（节点a）的路径撕裂通过控制平面整理LSP，因为没有从上游方向到节点C的控制平面连接。[RFC3473]中有两种可能性：
- Management action may be taken at the restarting node to tear the LSP. This will result in the LSP being removed from Node C and a PathTear being sent downstream to Node D.
- 可以在重新启动节点处采取管理操作来撕裂LSP。这将导致从节点C删除LSP，并向下游节点D发送路径撕裂。
- Management action may be taken at any downstream node (for example, Node D), resulting in a PathErr message with the Path_State_Removed flag set being sent to Node C to tear the LSP state.
- 可以在任何下游节点（例如，节点D）处采取管理操作，从而将带有Path_State_Removed标志集的PathErr消息发送到节点C以撕裂LSP状态。
Note that if Node B restarts after this operation, the Path message that it sends to Node C will not be matched with any state on Node C and will be treated as a new Path message, resulting in LSP setup. Node C should use the labels carried in the Path message (in the Upstream_Label Object and in the Recovery_Label Object) to drive its label allocation, but may use other labels according to normal LSP setup rules.
请注意，如果节点B在此操作后重新启动，则它发送给节点C的路径消息将与节点C上的任何状态不匹配，并将被视为新的路径消息，从而导致LSP设置。节点C应该使用路径消息中携带的标签（在上游_标签对象和恢复_标签对象中）来驱动其标签分配，但可以根据正常LSP设置规则使用其他标签。
In this example, the restarting node (Node C) is isolated. Its upstream and downstream neighbors have not restarted.
在此示例中，重新启动节点（节点C）是隔离的。其上下游邻国尚未重启。
The restarting node (Node C) follows the procedures in Section 9.3 of [RFC3473] and may run a Restart Timer for each of its neighbors (Nodes B and D). If a neighbor has not restarted before its Restart Timer expires, the corresponding LSPs may be torn down according to local policy [RFC3473]. Note, however, that the Restart Time values suggested in [RFC3473] are based on the previous Hello message exchanged with the nodes that have not restarted yet. Since these time values are unlikely to be available to the restarting node (Node C), a configured time value must be used if the timer is operated.
重新启动节点（节点C）遵循[RFC3473]第9.3节中的程序，并可为其每个邻居（节点B和D）运行重新启动计时器。如果邻居在其重新启动计时器到期之前未重新启动，则可根据本地策略[RFC3473]拆除相应的LSP。但是，请注意，[RFC3473]中建议的重启时间值基于之前与尚未重启的节点交换的Hello消息。由于这些时间值不太可能对重新启动节点（节点C）可用，因此如果操作计时器，则必须使用配置的时间值。
During the Recovery Time, if the upstream delayed restarting node has restarted, the procedure for scenario 1 can be applied.
在恢复期间，如果上游延迟重启节点已重启，则可以应用场景1的过程。
During the Recovery Time, if the downstream delayed restarting node has restarted, the procedure for scenario 2 can be applied.
在恢复期间，如果下游延迟重启节点已重启，则可以应用场景2的过程。
In the case that neither delayed restarting node ever comes back and a Restart Timer is not used to automatically tear down LSPs, management intervention is required to tidy up the control plane and the data plane on the node that is waiting for the failed device to restart.
如果延迟重新启动的节点都没有返回，并且没有使用重新启动计时器自动拆除LSP，则需要管理干预来整理等待故障设备重新启动的节点上的控制平面和数据平面。
If the downstream delayed restarting node restarts after the cleanup of LSPs at Node C, the RecoveryPath message from Node D will be responded to with a PathTear message. If the upstream delayed restarting node restarts after the cleanup of LSPs at Node C, the Path message from Node B will be treated as a new LSP setup request, but the setup will fail because Node D cannot be reached; Node C will respond with a PathErr message. Since this happens to Node B during its restart processing, it should follow the rules of [RFC5063] and tear down the LSP.
如果下游延迟重新启动节点在清理节点C上的LSP后重新启动，则来自节点D的RecoveryPath消息将用PathTear消息响应。如果上游延迟重启节点在节点C清理LSP后重新启动，则来自节点B的Path消息将被视为新的LSP设置请求，但设置将失败，因为无法到达节点D；节点C将响应一条PathErr消息。由于这种情况在节点B的重启处理过程中发生，因此它应该遵循[RFC5063]的规则并拆除LSP。
When the ingress node (Node A) restarts, it does not know which LSPs it caused to be created. Usually, however, this information is retrieved from the management plane or from the configuration requests stored in non-volatile form in the node in order to recover the LSP state.
当入口节点（节点A）重新启动时，它不知道它导致创建了哪些LSP。然而，通常从管理平面或从以非易失性形式存储在节点中的配置请求检索该信息，以便恢复LSP状态。
Furthermore, if the downstream node (Node B) is a normal node, according to the procedures in [RFC5063], the ingress will receive a RecoveryPath message and will understand that it was the ingress of the LSP.
此外，如果下游节点（节点B）是正常节点，则根据[RFC5063]中的过程，入口将接收RecoveryPath消息，并将理解它是LSP的入口。
However, in this scenario, the downstream node is a delayed restarting node, so Node A must either rely on the information from the management plane or stored configuration, or it must wait for Node B to restart.
然而，在此场景中，下游节点是延迟重启的节点，因此节点a必须依赖于来自管理平面或存储配置的信息，或者必须等待节点B重启。
In the event that Node B never restarts, management plane intervention is needed at Node A to clean up any LSP control plane state restored from the management plane or from local configuration, and to release any data plane resources.
如果节点B从未重新启动，则需要在节点A处进行管理平面干预，以清除从管理平面或本地配置恢复的任何LSP控制平面状态，并释放任何数据平面资源。
In this scenario, the egress node (Node D) restarts, and its upstream neighbor (Node C) has not restarted. In this case, the egress node may have no control plane state relating to the LSPs. It has no downstream neighbor to help it and no management plane or configuration information, although there will be data plane state for the LSP. The egress node must simply wait until its upstream neighbor restarts and gives it the information in Path messages carrying Recovery_Label Objects.
在此场景中，出口节点（节点D）重新启动，其上游邻居（节点C）尚未重新启动。在这种情况下，出口节点可能没有与lsp相关的控制平面状态。它没有下游邻居来帮助它，也没有管理平面或配置信息，尽管LSP将有数据平面状态。出口节点必须简单地等待其上游邻居重新启动，并在承载恢复标签对象的路径消息中为其提供信息。
Fundamental to the processes described above is an understanding that data plane resources may remain in use (allocated and cross-connected) when control plane state has not been fully resynchronized because some control plane nodes have not restarted.
上述过程的基础是理解，当控制平面状态由于一些控制平面节点尚未重新启动而未完全重新同步时，数据平面资源可能仍在使用（分配和交叉连接）。
It is assumed that these data plane resources might be carrying traffic and should not be reconfigured except through application of operator-configured policy, or as a direct result of operator action.
假设这些数据平面资源可能正在承载流量，不应重新配置，除非通过应用操作员配置的策略，或作为操作员操作的直接结果。
In particular, new LSP setup requests from the control plane or the management plane should not be allowed to use data plane resources
特别是，不应允许来自控制平面或管理平面的新LSP设置请求使用数据平面资源
that are still in use. Specific action must first be taken to release the resources.
仍在使用的。必须首先采取具体行动释放资源。
The management plane must always retain the ability to control data plane resources and to override the control plane. In this context, the management plane must always be able to release data plane resources that were previously in place for use by control-plane-established LSPs. Further, the management plane must always be able to instruct any control plane node to tear down any LSP.
管理平面必须始终保持控制数据平面资源和覆盖控制平面的能力。在这种情况下，管理平面必须始终能够释放以前由控制平面建立的LSP使用的数据平面资源。此外，管理平面必须始终能够指示任何控制平面节点拆除任何LSP。
Operators should be aware of the risks of misconnection that could be caused by careless manipulation from the management plane of in-use data plane resources.
操作员应意识到由于管理层对在用数据平面资源的不小心操作而可能导致的错误连接风险。
According to the current graceful restart procedure [RFC3473], after a node restarts its control plane, it needs its upstream node to send a PATH message with a recovery label in order to synchronize its RSVP state. If the restarted control plane becomes operational quickly, the upstream node may not detect the restarting of the downstream node and, therefore, may send a PATH message without a recovery label, causing errors and unwanted connection deletion.
根据当前的优雅重启过程[RFC3473]，节点重启其控制平面后，需要其上游节点发送带有恢复标签的路径消息，以便同步其RSVP状态。如果重新启动的控制平面很快开始工作，则上游节点可能检测不到下游节点的重新启动，因此可能发送没有恢复标签的路径消息，从而导致错误和不必要的连接删除。
N1 N2
| |
| X (Restart start)
| HELLO |
|--------------->|
| |
| SRefresh |
|--------------->|
| |
| HELLO |
|--------------->|
| |
| X (Restart complete)
| SRefresh |
|--------------->|
| NACK |
|<---------------|
| Path without |
| recovery label |
|--------------->|
| X (resource allocation failed because the
| | resources are in use)
| PathErr |
|<---------------|
| PathTear |
|--------------->|
X(LSP deletion) X (LSP deletion)
| |
N1 N2
| |
| X (Restart start)
| HELLO |
|--------------->|
| |
| SRefresh |
|--------------->|
| |
| HELLO |
|--------------->|
| |
| X (Restart complete)
| SRefresh |
|--------------->|
| NACK |
|<---------------|
| Path without |
| recovery label |
|--------------->|
| X (resource allocation failed because the
| | resources are in use)
| PathErr |
|<---------------|
| PathTear |
|--------------->|
X(LSP deletion) X (LSP deletion)
| |
Figure 2: Message Flow for Accidental LSP Deletion
图2：意外删除LSP的消息流
The sequence diagram above depicts one scenario where the LSP may get deleted.
上面的序列图描述了LSP可能被删除的一个场景。
In this sequence, N1 does not detect Hello failure and continues sending SRefreshes, which may get NACK'ed by N2 once restart completes because there is no Path state corresponding to the SRefresh message. This NACK causes a Path refresh message to be generated, but there is no Recovery_Label because N1 does not yet detect that N2 has restarted, as Hello exchanges have not yet started. The Path message is treated as "new" and fails to allocate the resources because they are still in use. This causes a PathErr message to be generated, which may lead to the teardown of the LSP.
在此序列中，N1未检测到Hello故障并继续发送SRefresh，一旦重启完成，可能会被N2拒绝，因为没有与SRefresh消息对应的路径状态。此NACK导致生成路径刷新消息，但没有恢复标签，因为N1尚未检测到N2已重新启动，因为Hello交换尚未启动。Path消息被视为“新”消息，无法分配资源，因为它们仍在使用中。这会导致生成PathErr消息，这可能导致LSP的拆卸。
To resolve the aforementioned problem, the following procedures, which are implicit in [RFC3473] and [RFC5063], should be followed. These procedures work together with the recovery procedures documented in [RFC3473]. Here, it is assumed that the restarting
要解决上述问题，应遵循[RFC3473]和[RFC5063]中隐含的以下步骤。这些程序与[RFC3473]中记录的恢复程序一起工作。这里，假设重新启动
node and the neighboring node(s) support the Hello extension as documented in [RFC3209] as well as the recovery procedures documented in [RFC3473].
节点和相邻节点支持[RFC3209]中记录的Hello扩展以及[RFC3473]中记录的恢复过程。
After a node restarts its control plane, it should ignore and silently drop all RSVP-TE messages (except Hello messages) it receives from any neighbor to which no HELLO session has been established.
在节点重新启动其控制平面后，它应该忽略并静默删除它从没有建立Hello会话的任何邻居接收的所有RSVP-TE消息（Hello消息除外）。
The restarting node should follow [RFC3209] to establish Hello sessions with its neighbors, after its control plane becomes operational.
在其控制平面开始工作后，重新启动节点应遵循[RFC3209]与邻居建立Hello会话。
The restarting node resumes processing of RSVP-TE messages sent from each neighbor to which the Hello session has been established.
重新启动节点恢复处理从已建立Hello会话的每个邻居发送的RSVP-TE消息。
This document clarifies the procedures defined in [RFC3473] and [RFC5063] to be performed on RSVP agents that neighbor one or more restarting RSVP agents. It does not introduce any new procedures and, therefore, does not introduce any new security risks or issues.
本文件澄清了[RFC3473]和[RFC5063]中定义的程序，这些程序将在与一个或多个重新启动的RSVP代理相邻的RSVP代理上执行。它不会引入任何新的程序，因此也不会引入任何新的安全风险或问题。
In the case of the control plane in general, and the RSVP agent in particular, where one or more nodes carrying one or more LSPs are restarted due to external attacks, the procedures defined in [RFC5063] and described in this document provide the ability for the restarting RSVP agents to recover the RSVP state in each restarting node corresponding to the LSPs, with the least possible perturbation to the rest of the network. These procedures can be considered to provide mechanisms by which the GMPLS network can recover from physical attacks or from attacks on remotely controlled power supplies.
对于一般的控制平面，尤其是RSVP代理，由于外部攻击，承载一个或多个LSP的一个或多个节点被重新启动时，[RFC5063]中定义的程序本文档中描述的和提供了重新启动RSVP代理恢复与LSP对应的每个重新启动节点中的RSVP状态的能力，对网络其余部分的干扰最小。这些程序可被视为提供了GMPLS网络可以从物理攻击或远程控制电源攻击中恢复的机制。
The procedures described are such that only the neighboring RSVP agents should notice the restart of a node, and hence only they 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 and without propagating the error condition in the control or data plane. In other words, the effect of the restart (which might be the result of an attack) does not spread into the network.
所描述的过程使得只有相邻的RSVP代理应该注意到节点的重新启动，因此只有它们需要执行额外的处理。这使得具有活动LSP的网络能够从外部攻击中优雅地恢复LSP状态，而不会干扰数据/转发平面状态，也不会在控制平面或数据平面中传播错误条件。换句话说，重启的影响（可能是攻击的结果）不会扩散到网络中。
Note that concern has been expressed about the vulnerability of a restarting node to false messages received from its neighbors. For example, a restarting node might receive a false Path message with a
请注意，有人对重新启动的节点容易受到来自其邻居的错误消息的攻击表示担忧。例如，重新启动的节点可能会收到带有
Recovery_Label Object from an upstream neighbor, or a false RecoveryPath message from its downstream neighbor. This situation might arise in one of four cases:
来自上游邻居的Recovery_标签对象，或来自其下游邻居的错误RecoveryPath消息。这种情况可能出现在以下四种情况之一：
- The message is spoofed and does not come from the neighbor at all.
- 消息是伪造的，根本不是来自邻居。
- The message has been modified as it was traveling from the neighbor.
- 消息在从邻居发送时已被修改。
- The neighbor is defective and has generated a message in error.
- 邻居有缺陷，已生成错误消息。
- The neighbor has been subverted and has a "rogue" RSVP agent.
- 邻居已被颠覆，并有一个“流氓”RSVP代理。
The first two cases may be handled using standard RSVP authentication and integrity procedures [RFC3209], [RFC3473]. If the operator is particularly worried, the control plane may be operated using IPsec [RFC4301], [RFC4302], [RFC4835], [RFC4306], and [RFC2411].
前两种情况可使用标准RSVP认证和完整性程序[RFC3209]、[RFC3473]进行处理。如果操作员特别担心，可以使用IPsec[RFC4301]、[RFC4302]、[RFC4835]、[RFC4306]和[RFC2411]操作控制平面。
Protection against defective or rogue RSVP implementations is generally hard-to-impossible. Neighbor-to-neighbor authentication and integrity validation is, by definition, ineffective in these situations. For example, if a neighbor node sends a Resv during normal LSP setup, and if that message carries a Generalized_Label Object carrying an incorrect label value, then the receiving LSR will use the supplied value and the LSP will be set up incorrectly. Alternatively, if a Path message is modified by an upstream LSR to change the destination and explicit route, there is no way for the downstream LSR to detect this, and the LSP may be set up to the wrong destination. Furthermore, the upstream LSR could disguise this fact by modifying the recorded route reported in the Resv message. Thus, these issues are in no way specific to the restart case, do not cause any greater or different problems from the normal case, and do not warrant specific security measures applicable to restart scenarios.
针对缺陷或恶意RSVP实现的保护通常很难实现。根据定义，邻居对邻居身份验证和完整性验证在这些情况下是无效的。例如，如果邻居节点在正常LSP设置期间发送Resv，并且如果该消息包含带有不正确标签值的广义_标签对象，则接收LSR将使用提供的值，并且LSP将设置不正确。或者，如果上游LSR修改路径消息以改变目的地和显式路由，则下游LSR无法检测到这一点，并且LSP可能被设置到错误的目的地。此外，上游LSR可以通过修改Resv消息中报告的记录路由来掩盖这一事实。因此，这些问题并非特定于重启情况，不会导致任何与正常情况更大或不同的问题，也不保证适用于重启场景的特定安全措施。
Note that the RSVP Policy_Data Object [RFC2205] provides a scope by which secure end-to-end checks could be applied. However, very little definition of the use of this object has been made to date.
请注意，RSVP Policy_数据对象[RFC2205]提供了一个可以应用安全端到端检查的范围。然而，迄今为止，对该物体的用途几乎没有作出定义。
See [MPLS-SEC] for a wider discussion of security in MPLS and GMPLS networks.
有关MPLS和GMPLS网络中安全性的更广泛讨论，请参见[MPLS-SEC]。
We would like to thank Adrian Farrel, Dimitri Papadimitriou, and Lou Berger for their useful comments.
我们要感谢Adrian Farrel、Dimitri Papadimitriou和Lou Berger的有用评论。
[RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules", RFC 2209, September 1997.
[RFC2209]Braden，R.和L.Zhang，“资源预留协议（RSVP）——第1版消息处理规则”，RFC 2209，1997年9月。
[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月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC5063] Satyanarayana, A., Ed., and R. Rahman, Ed., "Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart", RFC 5063, October 2007.
[RFC5063]Satyanarayana，A.，Ed.，和R.Rahman，Ed.，“GMPLS资源预留协议（RSVP）优雅重启的扩展”，RFC 5063，2007年10月。
[MPLS-SEC] Fang, L., "Security Framework for MPLS and GMPLS Networks", Work in Progress, November 2008.
[MPLS-SEC]方，L.，“MPLS和GMPLS网络的安全框架”，正在进行的工作，2008年11月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC2411]Thayer，R.，Doraswamy，N.，和R.Glenn，“IP安全文档路线图”，RFC 24111998年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]考夫曼，C.，编辑，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.
[RFC4835]Manral，V.“封装安全有效载荷（ESP）和身份验证头（AH）的密码算法实现要求”，RFC 4835，2007年4月。
Authors' Addresses
作者地址
Dan Li Huawei Technologies F3-5-B R&D Center, Huawei Base, Shenzhen 518129, China
中国深圳华为基地华为技术F3-5-B研发中心，邮编：518129
Phone: +86 755 28970230
EMail: danli@huawei.com
Phone: +86 755 28970230
EMail: danli@huawei.com
Jianhua Gao Huawei Technologies F3-5-B R&D Center, Huawei Base, Shenzhen 518129, China
高建华华为技术有限公司F3-5-B研发中心，华为基地，深圳518129
Phone: +86 755 28972902
EMail: gjhhit@huawei.com
Phone: +86 755 28972902
EMail: gjhhit@huawei.com
Arun Satyanarayana Cisco Systems 170 West Tasman Dr San Jose, CA 95134, USA
Arun Satyanarayana思科系统170西塔斯曼博士圣何塞，加利福尼亚州95134，美国
Phone: +1 408 853-3206
EMail: asatyana@cisco.com
Phone: +1 408 853-3206
EMail: asatyana@cisco.com
Snigdho C. Bardalai Fujitsu Network Communications 2801 Telecom Parkway Richardson, Texas 75082, USA
Snigdho C.Bardalai Fujitsu Network Communications美国德克萨斯州理查森电信大道2801号，邮编75082
Phone: +1 972 479 2951
EMail: snigdho.bardalai@us.fujitsu.com
Phone: +1 972 479 2951
EMail: snigdho.bardalai@us.fujitsu.com