Network Working Group V. Jain, Ed.
Request for Comments: 4951 Riverstone Networks
Category: Standards Track August 2007
Network Working Group V. Jain, Ed.
Request for Comments: 4951 Riverstone Networks
Category: Standards Track August 2007
Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover"
第2层隧道协议（L2TP）“故障转移”的故障转移扩展
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
Layer 2 Tunneling Protocol (L2TP) is a connection-oriented protocol that has a shared state between active endpoints. Some of this shared state is vital for operation, but may be volatile in nature, such as packet sequence numbers used on the L2TP Control Connection. When failure of one side of a control connection occurs, a new control connection is created and associated with the old connection by exchanging information about the old connection. Such a mechanism is not intended as a replacement for an active fail over with some mirrored connection states, but as an aid for those parameters that are particularly difficult to have immediately available. Protocol extensions to L2TP defined in this document are intended to facilitate state recovery, providing additional resiliency in an L2TP network, and improving a remote system's layer 2 connectivity.
第二层隧道协议（L2TP）是一种面向连接的协议，在活动端点之间具有共享状态。某些共享状态对操作至关重要，但本质上可能是不稳定的，例如L2TP控制连接上使用的数据包序列号。当控制连接的一侧发生故障时，将创建一个新的控制连接，并通过交换有关旧连接的信息将其与旧连接关联。这种机制并不是用来替代具有某些镜像连接状态的主动故障切换，而是用来帮助那些特别难以立即获得的参数。本文档中定义的L2TP协议扩展旨在促进状态恢复，在L2TP网络中提供额外的弹性，并改进远程系统的第2层连接。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Abbreviations ..............................................5
1.3. Specification of Requirements ..............................5
2. Overview ........................................................5
3. Failover Protocol ...............................................7
3.1. Failover Capability Negotiation ............................7
3.2. Failover Recovery Procedure ................................7
3.2.1. Recovery Tunnel Establishment .......................8
3.2.2. Control Channel Reset ..............................10
3.2.3. Data Channel Reset .................................10
3.3. Session State Synchronization .............................11
4. New Control Messages ...........................................12
4.1. Failover Session Query ....................................13
4.2. Failover Session Response .................................13
5. New Attribute Value Pairs ......................................14
5.1. Failover Capability AVP ...................................14
5.2. Tunnel Recovery AVP .......................................15
5.3. Suggested Control Sequence AVP ............................16
5.4. Failover Session State AVP ................................17
6. Configuration Parameters .......................................18
7. IANA Considerations ............................................19
8. Security Considerations ........................................19
9. Acknowledgements ...............................................19
10. Contributors ..................................................20
11. References ....................................................20
11.1. Normative References .....................................20
11.2. Informative References ...................................20
Appendix A ........................................................21
Appendix B ........................................................23
Appendix C ........................................................24
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Abbreviations ..............................................5
1.3. Specification of Requirements ..............................5
2. Overview ........................................................5
3. Failover Protocol ...............................................7
3.1. Failover Capability Negotiation ............................7
3.2. Failover Recovery Procedure ................................7
3.2.1. Recovery Tunnel Establishment .......................8
3.2.2. Control Channel Reset ..............................10
3.2.3. Data Channel Reset .................................10
3.3. Session State Synchronization .............................11
4. New Control Messages ...........................................12
4.1. Failover Session Query ....................................13
4.2. Failover Session Response .................................13
5. New Attribute Value Pairs ......................................14
5.1. Failover Capability AVP ...................................14
5.2. Tunnel Recovery AVP .......................................15
5.3. Suggested Control Sequence AVP ............................16
5.4. Failover Session State AVP ................................17
6. Configuration Parameters .......................................18
7. IANA Considerations ............................................19
8. Security Considerations ........................................19
9. Acknowledgements ...............................................19
10. Contributors ..................................................20
11. References ....................................................20
11.1. Normative References .....................................20
11.2. Informative References ...................................20
Appendix A ........................................................21
Appendix B ........................................................23
Appendix C ........................................................24
The goal of this document is to aid the overall resiliency of an L2TP endpoint by introducing extensions to RFC 2661 [L2TPv2] and RFC 3931 [L2TPv3] that will minimize the recovery time of the L2TP layer after a failover, while minimizing the impact on its performance. Therefore, it is assumed that the endpoint's overall architecture is also supportive in the resiliency effort.
本文档的目标是通过引入对RFC 2661[L2TPv2]和RFC 3931[L2TPv3]的扩展来帮助L2TP端点的总体恢复能力，这将最大限度地减少故障切换后L2TP层的恢复时间，同时最大限度地降低对其性能的影响。因此，假设端点的总体架构也支持恢复工作。
To ensure proper operation of an L2TP endpoint after a failover, the associated information of the control connection and sessions between them must be correct and consistent. This includes both the configured and dynamic information. The configured information is assumed to be correct and consistent after a failover, otherwise the tunnels and sessions would not have been setup in the first place.
为了确保L2TP终结点在故障切换后正常运行，控制连接和它们之间会话的关联信息必须正确且一致。这包括配置信息和动态信息。假定配置的信息在故障转移后是正确和一致的，否则隧道和会话将不会首先设置。
The dynamic information, which is also referred to as stateful information, changes with the processing of the tunnel's control and data packets. Currently, the only such information that is essential to the tunnel's operation is its sequence numbers. For the tunnel control channel, the inconsistencies in its sequence numbers can result in the termination of the entire tunnel. For tunnel sessions, the inconsistency in its sequence numbers, when used, can cause significant data loss, which gives the perception of a "service loss" to the end user.
动态信息（也称为有状态信息）随隧道控制和数据包的处理而变化。目前，对隧道运营至关重要的唯一此类信息是其序列号。对于隧道控制信道，其序列号的不一致可能导致整个隧道的终止。对于隧道会话，其序列号的不一致性在使用时可能会导致严重的数据丢失，这给最终用户带来了“服务丢失”的感觉。
Thus, an optimal resilient architecture that aims to minimize "service loss" after a failover, must make provisions for the tunnel's essential stateful information, i.e., its sequence numbers. Currently, there are two options available: the first option is to ensure that the backup endpoint is completely synchronized with the active endpoint, with respect to the control and data sessions sequence numbers. The other option is to reestablish all the tunnels and their sessions after a failover. The drawback of the first option is that it adds significant performance and complexity impact to the endpoint's architecture, especially as tunnel and session aggregation increases. The drawback of the second option is that it increases the "service loss" time, especially as the architecture scales.
因此，旨在将故障切换后的“服务损失”降至最低的最佳弹性体系结构必须为隧道的基本状态信息（即其序列号）做出规定。目前，有两个选项可用：第一个选项是确保备份端点与活动端点在控制和数据会话序列号方面完全同步。另一个选项是在故障转移后重新建立所有隧道及其会话。第一个选项的缺点是，它对端点的体系结构增加了显著的性能和复杂性影响，特别是在隧道和会话聚合增加的情况下。第二个选项的缺点是它增加了“服务损失”时间，尤其是随着体系结构的扩展。
To alleviate the above-mentioned drawbacks of the current options, this document introduces a mechanism to bring the dynamic stateful information of a tunnel to a correct and consistent state after a failure. The proposed mechanism defines the recovery of tunnels and sessions that were in an established state prior to the failure.
为了缓解当前选项的上述缺点，本文介绍了一种机制，用于在发生故障后使隧道的动态状态信息处于正确和一致的状态。建议的机制定义了故障前处于已建立状态的隧道和会话的恢复。
Endpoint: L2TP control connection endpoint, i.e., either LAC or LNS (also known as LCCE in [L2TPv3]).
端点：L2TP控制连接端点，即LAC或LNS（在[L2TPv3]中也称为LCCE）。
Active Endpoint: An endpoint that is currently providing service.
活动端点：当前正在提供服务的端点。
Backup Endpoint: A redundant endpoint standing by for the active endpoint that has its database of active tunnels and sessions in sync with its active endpoint.
备份终结点：备用于活动终结点的冗余终结点，其活动隧道和会话数据库与其活动终结点同步。
Failed Endpoint: The endpoint that was the active endpoint at the time of the failure.
Failed Endpoint：失败时为活动终结点的终结点。
Recovery Endpoint: The endpoint that initiates the failover protocol to recover from the failure of an active endpoint.
Recovery Endpoint：启动故障转移协议以从活动终结点的故障中恢复的终结点。
Remote Endpoint: The endpoint that peers with active endpoint before failure and with recovery endpoint after failure.
远程终结点：失败前与活动终结点对等，失败后与恢复终结点对等的终结点。
Failover: The action of a backup endpoint taking over the service of an active endpoint. This could be due to administrative action or failure of the active endpoint.
故障转移：备份终结点接管活动终结点服务的操作。这可能是由于管理操作或活动终结点失败造成的。
Old Tunnel: A control connection that existed before failure and is subjected to recovery upon failover.
旧隧道：失败前存在的控制连接，在故障转移时进行恢复。
Recovery Tunnel: A new control connection established only to recover an old tunnel.
恢复隧道：仅为恢复旧隧道而建立的新控制连接。
Recovered Tunnel: After an old tunnel's control connection and sessions are restored using the mechanism described in this document, it is referred to as a Recovered Tunnel.
恢复的隧道：使用本文档中描述的机制恢复旧隧道的控制连接和会话后，它被称为恢复的隧道。
Control Channel Failure: Failure of the component responsible for establishing/maintaining tunnels and sessions at an endpoint.
控制通道故障：负责在端点建立/维护隧道和会话的组件故障。
Data Channel Failure: Failure of the component responsible for forwarding the L2TP encapsulated data.
数据通道故障：负责转发L2TP封装数据的组件出现故障。
LAC L2TP Access Concentrator LNS L2TP Network Server LCCE L2TP Control Connection Endpoint AVP Attribute Value Pair SCCRQ Start-Control-Connection-Request SCCRP Start-Control-Connection-Reply ZLB Zero Length Body Message
LAC L2TP访问集中器LNS L2TP网络服务器LCCE L2TP控制连接端点AVP属性值对SCCRQ启动控制连接请求SCCRP启动控制连接回复ZLB零长度正文消息
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 following diagram depicts the redundancy architecture and pertaining entities used to describe the failover protocol:
下图描述了用于描述故障切换协议的冗余体系结构和相关实体：
+--------------+
| L2TP active |
+----------+ ----| endpoint (A) |
| L2TP | / +--------------+
| endpoint |----------------------/
| (R) | \ +--------------+
+----------+ \ | L2TP backup |
----| endpoint (B) |
+--------------+
+--------------+
| L2TP active |
+----------+ ----| endpoint (A) |
| L2TP | / +--------------+
| endpoint |----------------------/
| (R) | \ +--------------+
+----------+ \ | L2TP backup |
----| endpoint (B) |
+--------------+
Active and backup endpoints may reside on the same device, however, they are not required to be that way. On other hand, some devices may not have a standby module altogether, in which case the failed endpoint, after reset, can become the recovery endpoint to recover from its prior failure.
活动端点和备份端点可以驻留在同一设备上，但是，不需要这样做。另一方面，一些设备可能没有完全的备用模块，在这种情况下，故障端点在重置后可以成为恢复端点，以便从先前的故障中恢复。
Therefore, in the above diagram, upon A's (active endpoint's) failure:
因此，在上图中，当A（活动端点）发生故障时：
- Endpoint A would be called the failed endpoint.
- 端点A将被称为失败的端点。
- If B is present, then it would become the recovery endpoint and also an active endpoint.
- 如果存在B，则它将成为恢复端点，同时也是活动端点。
- If B is not present, then A could become the recovery endpoint after it restarts, provided it saved the information about active tunnels/sessions in some persistent storage.
- 如果B不存在，则A可以在重新启动后成为恢复端点，前提是它将有关活动隧道/会话的信息保存在某些持久性存储中。
- R does not initiate the failover protocol; rather it waits for a failure indication from recovery endpoint.
- R不启动故障转移协议；而是等待来自恢复端点的故障指示。
This document assumes that the actual detection of a failure in the backup endpoint is done in an implementation-specific way. It also assumes that failure detection by the backup endpoint is faster than the L2TP control channel timeout between the active and remote endpoints. Typically, active and backup endpoints reside on the same physical device, allowing fast and reliable failure detection without the need to communicate between these endpoints over the network.
本文档假设备份端点中的实际故障检测是以特定于实现的方式完成的。它还假设备份端点的故障检测速度快于活动端点和远程端点之间的L2TP控制通道超时。通常，活动和备份端点位于同一物理设备上，允许快速可靠的故障检测，而无需在这些端点之间通过网络进行通信。
Similarly, an active endpoint that acts also as a backup endpoint can easily start the recovery once it has rebooted. However, when the active and backup endpoints reside in separate devices, there is a need for communication between them in order to detect failures. As a solution for such situations, additional failure detection protocols, e.g., [BFD-MULTIHOP], may be needed.
类似地，同时充当备份端点的活动端点可以在重新启动后轻松启动恢复。但是，当活动和备份端点位于不同的设备中时，需要在它们之间进行通信以检测故障。作为此类情况的解决方案，可能需要额外的故障检测协议，例如[BFD-MULTIHOP]。
A device could have three kinds of failures:
设备可能有三种故障：
i) Control Channel Failure
i) 控制通道故障
ii) Data Channel Failure
ii）数据通道故障
iii) Control and Data Channel Failure
iii）控制和数据通道故障
The protocol described in this document specifies the recovery in conditions i) and iii). It is perceived that not much (stateful information) could be recovered via a control protocol exchange in case of ii).
本文件中描述的协议规定了条件i）和条件iii）中的恢复。人们认为，在ii）的情况下，通过控制协议交换可以恢复的（有状态信息）不多。
The failover protocol consists of three phases:
故障切换协议包括三个阶段：
1) Failover Capability Negotiation: An active endpoint and a remote endpoint exchange failover capabilities and attributes to be used during the recovery process.
1) 故障转移能力协商：活动终结点和远程终结点交换恢复过程中要使用的故障转移能力和属性。
2) Failover Recovery: A recovery endpoint establishes a new L2TP control connection (called recovery tunnel) for every old tunnel that it wishes to recover. The recovery tunnel serves three purposes:
2) 故障转移恢复：恢复端点为希望恢复的每个旧隧道建立新的L2TP控制连接（称为恢复隧道）。回收隧道有三个用途：
- It identifies the old tunnel that is being recovered.
- 它标识正在恢复的旧隧道。
- It provides a means of authentication and a three-way handshake to ensure both ends agree on the failover for the specified old tunnel.
- 它提供了一种身份验证和三方握手的方法，以确保两端都同意指定旧隧道的故障切换。
- It could exchange the Ns and Nr values to be used in the recovered tunnel.
- 它可以交换Ns和Nr值，以便在恢复的隧道中使用。
Upon establishing the recovery tunnel, two endpoints reset the control and data channel(s) on the recovered tunnel using the procedures described in Section 3.2.2 and Section 3.2.3, respectively. The recovery tunnel could be torn down after that, and sessions that were established resume traffic.
建立恢复隧道后，两个端点分别使用第3.2.2节和第3.2.3节中描述的程序重置恢复隧道上的控制和数据通道。之后，恢复隧道可能会被拆除，建立的会话将恢复通信。
3) Session State Synchronization: The session state synchronization process occurs on the recovered or the old tunnel and allows the two endpoints to agree on the state of the various sessions in the tunnel after failover. The inconsistency, which could arise due to the failure, is handled in the following manner: first, the two endpoints silently clear the sessions that were not in the established state. Then, they utilize Failover Session Query (FSQ) and Failover Session Response (FSR) on the recovered tunnel to obtain the state of sessions as known to the peer endpoint and clear the sessions accordingly.
3) 会话状态同步：会话状态同步过程发生在已恢复或旧的隧道上，并允许两个端点在故障切换后就隧道中各个会话的状态达成一致。可能由于失败而产生的不一致性将通过以下方式处理：首先，两个端点以静默方式清除未处于已建立状态的会话。然后，它们利用恢复隧道上的故障转移会话查询（FSQ）和故障转移会话响应（FSR）来获取对等端点已知的会话状态，并相应地清除会话。
The protocol consists of three steps describing specifications during the life of a control connection - before and after failover.
该协议由三个步骤组成，分别描述了控制连接生命周期内（故障切换之前和之后）的规范。
The active and remote endpoints exchange the Failover Capability attribute-value pair (AVP) in Start-Control-Connection-Request (SCCRQ) and Start-Control-Connection-Reply (SCCRP) during control connection establishment as a part of the normal (before failover) operation. The Failover Capability AVP, defined in Section 5.1, allows an endpoint to specify if it is control and/or data channel failover capable and the time allowed for the recovery for the tunnel.
作为正常（故障转移前）操作的一部分，活动和远程端点在控制连接建立期间交换启动控制连接请求（SCCRQ）和启动控制连接回复（SCCRP）中的故障转移能力属性值对（AVP）。第5.1节中定义的故障切换功能AVP允许端点指定其是否能够进行控制和/或数据通道故障切换，以及允许恢复隧道的时间。
The Failover Recovery Procedure described in this section is performed only if there was a control channel failure. The selection of the tunnels to be recovered is implementation specific.
仅当发生控制通道故障时，才会执行本节中描述的故障切换恢复过程。待恢复隧道的选择取决于具体实施。
The Failover Recovery Procedure consists of following three steps, which are described in detail in the subsections below:
故障转移恢复过程由以下三个步骤组成，下面各小节将详细介绍这三个步骤：
- Recovery tunnel establishment
- 回收隧道设施
- Control channel reset
- 控制通道复位
- Data channel reset
- 数据通道复位
The recovery endpoint establishes a new control connection, called recovery tunnel, for every old tunnel it wishes to recover. The purpose of the recovery tunnel is solely to recover the corresponding old tunnel. There is a one to one relationship between recovery tunnel and recovered/old tunnel
恢复端点为希望恢复的每个旧隧道建立一个新的控制连接，称为恢复隧道。恢复隧道的目的仅是恢复相应的旧隧道。恢复隧道和恢复/旧隧道之间存在一对一的关系
Recovery tunnel establishment considerations:
恢复隧道建设注意事项：
- An LCCE MUST follow the procedures described in [L2TPv2] or [L2TPv3] to establish the recovery tunnel.
- LCCE必须遵循[L2TPv2]或[L2TPv3]中所述的程序来建立恢复通道。
- The recovery tunnel MUST use the same L2TP version (and establishment procedures) that was used for the old tunnel.
- 恢复隧道必须使用与旧隧道相同的L2TP版本（和建立程序）。
- The SCCRQ for Recovery tunnel MUST include the Tunnel Recovery AVP, defined in Section 5.2, to identify the old tunnel that is being recovered.
- 恢复隧道的SCCRQ必须包括第5.2节中定义的隧道恢复AVP，以识别正在恢复的旧隧道。
- The recovery tunnel MUST NOT include the Failover Capability AVP in its SCCRQ or SCCRP messages.
- 恢复隧道不得在其SCCRQ或SCCRP消息中包含故障切换功能AVP。
- An endpoint SHOULD NOT send any message other than the following on the recovery tunnel: SCCRQ, SCCRP, SCCCN, StopCCN, HELLO, ZLB, and ACK ([L2TPv3] only).
- 端点不应在恢复隧道上发送以下消息以外的任何消息：SCCRQ、SCCRP、SCCCN、StopCCN、HELLO、ZLB和ACK（仅限[L2TPv3]）。
- An endpoint MUST NOT use any old Tunnel ID for the recovery tunnel. The old tunnels MUST be valid until the recovery process concludes.
- 终结点不得为恢复隧道使用任何旧的隧道ID。在恢复过程结束之前，旧隧道必须有效。
- An endpoint MUST use the Tie Breaker AVP (Section 4.4.3 [L2TPv2]) or Control Connection Tie Breaker AVP (Section 5.4.3 [L2TPv3]) in the setup of the recovery tunnel to ensure that only a single recovery tunnel (when both endpoints have simultaneous failover) is established to recover an old tunnel. The tunnel that wins the tie is used to decide the suggested Ns and Nr values on the recovered tunnel. Therefore, the endpoint that loses the tie, should reset the Ns and Nr values (Section 3.2.2) as if it were a remote endpoint. Appendix B illustrates the double failover scenario.
- 端点必须在恢复隧道的设置中使用连接断开器AVP（第4.4.3节[L2TPv2]）或控制连接断开器AVP（第5.4.3节[L2TPv3]），以确保仅建立一个恢复隧道（当两个端点同时进行故障切换时）来恢复旧隧道。赢得平局的隧道用于确定恢复隧道上的建议Ns和Nr值。因此，失去连接的端点应重置Ns和Nr值（第3.2.2节），就像它是远程端点一样。附录B说明了双故障切换场景。
- Tie Breaker AVP processing: The scope of a tie breaker AVP's action for recovery and non recovery tunnels must be independent, and is defined as follows:
- 联络线断路器AVP处理：联络线断路器AVP对恢复和非恢复隧道的作用范围必须是独立的，定义如下：
o When Tie Breaker AVP is used in a non recovery tunnel, the scope of the tie breaker AVP's action MUST only be within non recovery tunnels. Therefore, losing a tie against a non recovery tunnel MUST NOT result in termination of any recovery tunnel.
o 当在非恢复隧道中使用联络线断路器AVP时，联络线断路器AVP的作用范围必须仅在非恢复隧道内。因此，失去与非恢复隧道的连接不得导致任何恢复隧道终止。
o When a Tie Breaker AVP is used in a recovery tunnel, the scope of tie breaker AVP's action is further restricted to the recovery tunnel(s) for a single tunnel to be recovered. Thus, an implementation MUST apply the tie breaker received in a recovery tunnel only to those tunnels that are a) recovery tunnels, and b) associated with the same tunnel to be recovered. It MUST NOT impact the operation of non-recovery tunnels and recovery tunnels associated with other old tunnels to be recovered.
o 当在回收隧道中使用联络线断路器AVP时，联络线断路器AVP的作用范围进一步限于单个待回收隧道的回收隧道。因此，实施必须仅将恢复隧道中接收到的连接断路器应用于a）恢复隧道和b）与待恢复的同一隧道相关的隧道。不得影响非恢复隧道和与其他待恢复旧隧道相关的恢复隧道的运行。
Upon getting an SCCRQ with a Tunnel Recovery AVP, an endpoint validates the Recover Tunnel ID and the Recover Remote Tunnel ID and responds with an SCCRP. It MUST terminate the recovery tunnel if:
在获得带有隧道恢复AVP的SCCRQ后，端点将验证恢复隧道ID和恢复远程隧道ID，并使用SCCRP进行响应。在以下情况下，必须终止恢复通道：
- The Recover Tunnel ID or the Recover Remote Tunnel ID is unknown.
- 恢复隧道ID或恢复远程隧道ID未知。
- The active or remote endpoint (prior to failover) had not indicated that it was failover capable.
- 活动或远程终结点（在故障转移之前）未指示其具有故障转移能力。
- The L2TP version of recovery tunnel is different from the version used in the old tunnel.
- L2TP版本的恢复隧道与旧隧道中使用的版本不同。
If the remote endpoint accepts the SCCRQ, it SHOULD include the Suggested Control Sequence AVP, defined in Section 5.3, in the SCCRP message.
如果远程端点接受SCCRQ，则应在SCCRP消息中包含第5.3节中定义的建议控制序列AVP。
Authentication considerations:
认证注意事项：
- To authenticate a peer endpoint during recovery tunnel establishment, an endpoint MUST follow the procedure described in either [L2TPv2] Section 5.1.1 or [L2TPv3] Section 4.3. It MUST use the same secret that was used to authenticate the old tunnel.
- 要在恢复隧道建立期间对对等端点进行身份验证，端点必须遵循[L2TPv2]第5.1.1节或[L2TPv3]第4.3节中描述的过程。它必须使用用于验证旧隧道的相同密码。
- Not being able to authenticate could be a reason to terminate the recovery tunnel.
- 无法进行身份验证可能是终止恢复隧道的一个原因。
- For L2TPv3 tunnels, a recovery tunnel MUST use the Control Message authentication (i.e., exchange the nonce values), as described in [L2TPv3] Section 4.3, if the old tunnel was configured to do control message authentication. An L2TPv3
- 对于L2TPv3隧道，如果旧隧道配置为执行控制消息身份验证，则恢复隧道必须使用控制消息身份验证（即交换nonce值），如[L2TPv3]第4.3节所述。L2TPv3
recovered tunnel MUST reset its nonce values (both endpoints) to the nonce values exchanged in the recovery tunnel.
恢复的隧道必须将其nonce值（两个端点）重置为恢复隧道中交换的nonce值。
For any reason, if the recovery endpoint could not establish the recovery tunnel, then it MUST silently clear the old tunnel and sessions within, concluding that the recovery process has failed.
无论出于何种原因，如果恢复端点无法建立恢复隧道，则它必须以静默方式清除旧隧道和其中的会话，从而得出恢复过程已失败的结论。
Any control packet received on the recovered tunnel before control channel reset (Section 3.2.2) MUST be silently discarded.
在控制信道重置（第3.2.2节）之前，在恢复的隧道上接收到的任何控制数据包都必须以静默方式丢弃。
Control channel reset allows new control messages to be sent and received over the recovered tunnel.
控制通道重置允许通过恢复的隧道发送和接收新的控制消息。
Control channel reset procedure:
控制通道复位程序：
- An endpoint SHOULD flush the transmit/receive windows and reset the control channel sequence numbers (i.e., Ns and Nr values) on the recovered tunnel. The control channel on the recovery endpoint is reset upon getting a valid SCCRP on the recovery tunnel, whereas the control channel on the remote endpoint is reset upon getting a valid SCCCN on the recovery tunnel. If the recovery endpoint did not receive the Suggested Control Sequence (SCS) AVP in the SCCRP then it MUST reset the Ns and Nr values to zero. If the remote endpoint opted to not send the SCS AVP then it MUST reset the Ns and Nr values to zero. Either endpoint can tear down the recovery tunnel after the control channel reset procedure is complete.
- 端点应刷新发送/接收窗口，并重置恢复隧道上的控制信道序列号（即Ns和Nr值）。恢复终结点上的控制通道在恢复隧道上获得有效的SCCRP时重置，而远程终结点上的控制通道在恢复隧道上获得有效的SCCCN时重置。如果恢复终点未收到SCCRP中的建议控制序列（SCS）AVP，则必须将Ns和Nr值重置为零。如果远程端点选择不发送SCS AVP，则必须将Ns和Nr值重置为零。控制通道重置过程完成后，任一端点都可以拆除恢复通道。
- An endpoint MUST prevent the establishment of new sessions until it has cleared (or marked for clearance) the sessions that were not in an established state, i.e., until after Step I, Section 3.3 is complete.
- 端点必须阻止建立新会话，直到其清除（或标记为清除）未处于已建立状态的会话，即直到步骤i第3.3节完成。
A data channel reset procedure is applicable only for the sessions using sequence numbers. For L2TPv3 data channel, the terms Nr and Ns in this document are used to mean "expected sequence number" and "sequence number", respectively.
数据通道重置程序仅适用于使用序列号的会话。对于L2TPv3数据信道，本文档中的术语Nr和Ns分别表示“预期序列号”和“序列号”。
Data channel reset procedure:
数据通道复位程序：
- The recovery endpoint sets the Ns value to zero.
- 恢复端点将Ns值设置为零。
- The remote endpoint (recovery endpoint's peer) continues to use the Ns values it was using previously.
- 远程终结点（恢复终结点的对等方）继续使用以前使用的Ns值。
- To reset Nr values during failover, if an endpoint receives 'n' out of order but in sequence packets, then it MUST set the Nr value based on the Ns value of the incoming packets, as suggested in Appendix C of [L2TPv3]. The value of 'n' SHOULD be configurable.
- 要在故障切换期间重置Nr值，如果端点接收到顺序不正确但顺序有序的数据包，则必须根据传入数据包的Ns值设置Nr值，如[L2TPv3]附录C中所建议。“n”的值应该是可配置的。
- If one of the endpoints does not exhibit the capability (indicated in 'D' bit in the Failover Capability AVP) to reset the Nr value, then data channels using sequence numbers are considered non recoverable. Those sessions SHOULD be torn down by the recovery endpoint by sending a Call-Disconnect-Notify (CDN).
- 如果其中一个端点不具备重置Nr值的能力（故障转移能力AVP中的“D”位指示），则使用序列号的数据通道被视为不可恢复。恢复端点应通过发送呼叫断开通知（CDN）中断这些会话。
- For data-channel-only failure, two endpoints MAY use the session state query/response mechanism on the control channel to synchronize the state of sessions as described in Section 3.3 below.
- 对于仅数据通道故障，两个端点可以使用控制通道上的会话状态查询/响应机制来同步会话状态，如下面第3.3节所述。
If a control channel failure happens when a session was being established or torn down, then it is possible for an endpoint to consider a session in an established state while its peer considers the same session non existent. Two such situations occur when failure on an endpoint occurs immediately after sending:
如果在建立或拆除会话时发生控制信道故障，那么端点可以考虑处于已建立状态的会话，而其对等端认为不存在相同会话。当端点在发送后立即发生故障时，会出现两种情况：
- A CDN message that never made it to the peer.
- 从未发送到对等方的CDN消息。
- An ICCN message that never made it to the peer.
- 从未发送给对等方的ICCN消息。
The following mechanism MUST be used to identify and clear the sessions that exists on an endpoint, but not on its peer:
必须使用以下机制来识别和清除端点上存在的会话，而不是其对等端上存在的会话：
Step I: For control channel failure, after the recovery tunnel is established, the sessions that were not in an established state MUST be silently cleared (i.e., without sending a CDN message) by each endpoint.
步骤一：对于控制通道故障，在恢复隧道建立后，每个端点必须以静默方式清除未处于建立状态的会话（即，不发送CDN消息）。
Step II: Both endpoints MAY identify the sessions that might have been in inconsistent states, perhaps based on data channel inactivity. FSQ and FSR messages have been introduced to synchronize session state at any given point during the life of a session between two endpoints. These messages are used when one endpoint determines or suspects in an implementation specific manner that its session state could be inconsistent with that of its peer's.
第二步：两个端点都可以识别可能处于不一致状态的会话，可能是基于数据通道不活动。引入了FSQ和FSR消息，以便在两个端点之间的会话生命周期中的任何给定点同步会话状态。当一个端点以特定于实现的方式确定或怀疑其会话状态可能与其对等方的会话状态不一致时，将使用这些消息。
Step III: An endpoint sends a Failover Session Query (FSQ) message to query the state of sessions as known to its peer. An FSQ message
步骤三：端点发送故障转移会话查询（FSQ）消息，以查询其对等方已知的会话状态。FSQ消息
contains one Failover Session State (FSS) AVP, defined in Section 5.4, for each session it wishes to query. Multiple FSS AVPs could be included in one FSQ message. An FSQ message MUST include at least one FSS AVP. An endpoint MAY send another FSQ message before getting a response for its previous FSQs.
包含一个故障转移会话状态（FSS）AVP，在第5.4节中定义，用于它希望查询的每个会话。一条FSQ消息中可以包含多个FSS AVP。FSQ消息必须至少包含一个FSS AVP。端点可以在获得其先前FSQ的响应之前发送另一个FSQ消息。
An inconsistency about a session's existence during failover could result in an endpoint selecting the same Session ID for a new session. In such a situation, it would send an ICRQ for an already established session. Therefore, before all sessions are synchronized using an FSQ/FSR mechanism, if endpoint receives an ICRQ for a session in an established state, then it MUST respond to such an ICRQ with a CDN. The CDN message must set Assigned/Local Session ID AVP ([L2TPv2] Section 4.4.4, [L2TPv3] Section 5.4.4) to its local Session ID and clear the session that it considered established. Use of a least recently used Session ID for the new sessions could help reduce this symptom during failover.
故障转移期间会话存在的不一致可能导致端点为新会话选择相同的会话ID。在这种情况下，它将为已经设立的届会发送一份红十字国际委员会。因此，在使用FSQ/FSR机制同步所有会话之前，如果端点接收到处于已建立状态的会话的ICRQ，那么它必须使用CDN响应这样的ICRQ。CDN消息必须将分配/本地会话ID AVP（[L2TPv2]第4.4.4节，[L2TPv3]第5.4.4节）设置为其本地会话ID，并清除其认为已建立的会话。为新会话使用最近最少使用的会话ID有助于在故障切换期间减少此症状。
When an endpoint receives an FSQ message, it MUST ensure that for each FSS AVP in the FSQ message, it includes an FSS AVP in the Failover Session Response (FSR) message. An endpoint could respond to multiple FSQs using one FSR message, or it could respond one FSQ with multiple FSRs. FSSs are not required to be responded in the same order in which they were received. For each FSS AVP received in FSQ messages, an endpoint MUST validate the Remote Session ID and determine if it is paired with the Session ID specified in the message. If an FSS AVP is not valid (i.e., session is non-existing or it is paired with different remote Session ID), then the Session ID field in the FSS AVP in the FSR MUST be set to zero. When session is discovered to be pairing with mismatching Session ID, the local session MUST not be cleared, but rather marked stale, to be queried later using an FSQ message. Appendix C presents an example dialogue between two endpoints with mismatching Session IDs.
当端点接收到FSQ消息时，它必须确保对于FSQ消息中的每个FSS AVP，它在故障转移会话响应（FSR）消息中包含一个FSS AVP。端点可以使用一条FSR消息响应多个FSQ，也可以使用多个FSR响应一个FSQ。FSS无需按照接收顺序进行响应。对于在FSQ消息中接收到的每个FSS AVP，端点必须验证远程会话ID，并确定它是否与消息中指定的会话ID配对。如果FSS AVP无效（即，会话不存在或与不同的远程会话ID配对），则FSR中FSS AVP中的会话ID字段必须设置为零。当发现会话与不匹配的会话ID配对时，不能清除本地会话，而是将其标记为stale，以便稍后使用FSQ消息查询。附录C给出了会话ID不匹配的两个端点之间的对话示例。
When responding to an FSQ with an FSR message, the Remote Session ID in the FSS AVP of the FSR message is always set to the received value of the Session ID in the FSS AVP of the FSQ message.
当使用FSR消息响应FSQ时，FSR消息的FSS AVP中的远程会话ID始终设置为FSQ消息的FSS AVP中会话ID的接收值。
When an endpoint receives an FSR message, for each FSS AVP it MUST use the Remote Session ID field to identify the local session and silently (without sending a CDN) clear the session if the Session ID in the AVP was zero. Otherwise, it MUST consider the session to be in an established state and recovered.
当端点接收到FSR消息时，对于每个FSS AVP，它必须使用远程会话ID字段来标识本地会话，并且如果AVP中的会话ID为零，则以静默方式（不发送CDN）清除会话。否则，它必须考虑会话处于已建立状态并恢复。
This document introduces two new messages that could be sent over an established/recovered control connection.
本文档介绍了两条可通过已建立/恢复的控制连接发送的新消息。
The Failover Session Query (FSQ) control message is used by an endpoint during the recovery process to query the state of various sessions. It triggers a response from the peer, which contains the requested state of various sessions.
故障转移会话查询（FSQ）控制消息由端点在恢复过程中用于查询各种会话的状态。它触发来自对等方的响应，其中包含各种会话的请求状态。
This control message is encoded as follows:
此控制消息的编码如下所示：
Vendor ID = 0 (IETF) Attribute Type = 21
供应商ID=0（IETF）属性类型=21
The following AVPs MUST be present in the FSQ control message:
以下AVP必须出现在FSQ控制信息中：
Message Type Failover Session State
消息类型故障转移会话状态
The following AVPs MAY be present in the FSQ control message:
FSQ控制消息中可能存在以下AVP：
Random Vector Message digest ([L2TPv3] tunnels only)
随机向量消息摘要（仅限[L2TPv3]隧道）
Other AVPs MUST NOT be sent in this control message and SHOULD be ignored on receipt.
其他AVP不得在此控制消息中发送，在收到时应忽略。
The M-bit on the Message Type AVP for this control message MUST be set to 0.
此控制消息的消息类型AVP上的M位必须设置为0。
The Failover Session Response (FSR) control message is used by an endpoint during the recovery process to respond with the local state of various sessions. It is sent as a response to an FSQ message. An endpoint MAY choose to respond to an FSQ message with multiple FSR messages.
故障转移会话响应（FSR）控制消息由端点在恢复过程中使用，以响应各种会话的本地状态。它作为对FSQ消息的响应发送。端点可以选择使用多个FSR消息响应FSQ消息。
This control message is encoded as follows:
此控制消息的编码如下所示：
Vendor ID = 0 (IETF) Attribute Type = 22
供应商ID=0（IETF）属性类型=22
The following AVPs MUST be present in the FSR control message:
以下AVP必须出现在FSR控制信息中：
Message Type Failover Session State
消息类型故障转移会话状态
The following AVPs MAY be present in the FSR control message:
FSR控制消息中可能存在以下AVP：
Random Vector Message digest ([L2TPv3] tunnels only)
随机向量消息摘要（仅限[L2TPv3]隧道）
Other AVPs MUST NOT be sent in this control message and SHOULD be ignored on receipt.
其他AVP不得在此控制消息中发送，在收到时应忽略。
The M-bit on the Message Type AVP for this control message MUST be set to 0.
此控制消息的消息类型AVP上的M位必须设置为0。
The following sections contain a list of new L2TP AVPs defined in this document.
以下部分包含本文档中定义的新L2TP AVP列表。
The Failover Capability AVP, Attribute Type 76, indicates the capabilities of an endpoint required for the recovery process. The AVP format is defined as follows:
故障转移能力AVP属性类型76表示恢复过程所需的端点的能力。AVP格式定义如下：
Failover Capability AVP
故障转移能力AVP
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 76 | Reserved |D|C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recovery Time (in milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 76 | Reserved |D|C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recovery Time (in milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The AVP MAY be hidden (the H-bit set to 0 or 1). The AVP is not mandatory (the M-bit MUST be set to 0).
AVP可以隐藏（H位设置为0或1）。AVP不是强制性的（M位必须设置为0）。
The C bit governs the failover capability for the control channel. When the C bit is set, it indicates that the endpoint can recover from a control channel failure using the procedure described in Section 3.2.2.
C位控制控制通道的故障切换能力。设置C位时，表示端点可以使用第3.2.2节中描述的程序从控制通道故障中恢复。
When the C bit is not set, it indicates that the endpoint cannot recover from a control channel failover. In this case, the D bit MUST be set. Note that a control channel failover in this case would be fatal for the tunnel and all associated data channels.
未设置C位时，表示端点无法从控制通道故障切换中恢复。在这种情况下，必须设置D位。请注意，在这种情况下，控制通道故障切换对于隧道和所有相关数据通道都是致命的。
The D bit governs the failover capability for data channels that use sequence numbers. Data channels that do not use sequence numbers do not need help to recover from a data channel failure.
D位控制使用序列号的数据通道的故障切换能力。不使用序列号的数据通道不需要帮助从数据通道故障中恢复。
When the D bit is set, it indicates that the endpoint is capable of resetting Nr value of data channels using the procedure described in Section 3.2.3 Data Channel reset procedure.
设置D位时，表示端点能够使用第3.2.3节数据通道重置程序中描述的程序重置数据通道的Nr值。
When the D bit is not set, it indicates that the endpoint cannot recover data channels that use sequence numbers. In the case of a failure, such data channels would be lost.
未设置D位时，表示端点无法恢复使用序列号的数据通道。如果发生故障，这些数据通道将丢失。
The Failover Capability AVP MUST NOT be sent with C bit and D bit cleared.
故障转移功能AVP不能在清除C位和D位的情况下发送。
The Recovery Time, applicable only when the C bit is set, is the time in milliseconds an endpoint asks its peer to wait before assuming the recovery process has failed. This timer starts when an endpoint's control channel timeout ([L2TPv2] Section 5.8, [L2TPv3] Section 4.2) is started, and is not stopped (before expiry) until an endpoint successfully authenticates its peer during recovery. A value of zero does not mean that failover will not occur, it means no additional time is requested from the peer. The timer is also stopped if a control channel message is acknowledged by the peer in the situation when there was no failover, but the loss of the control channel message was a temporary phenomenon.
恢复时间（仅在设置了C位时适用）是端点在假定恢复过程失败之前要求其对等方等待的时间（以毫秒为单位）。此计时器在端点的控制通道超时（[L2TPv2]第5.8节，[L2TPv3]第4.2节）启动时启动，并且在端点在恢复期间成功验证其对等方之前不会停止（在到期之前）。值为零并不意味着不会发生故障转移，它意味着不会向对等方请求额外的时间。如果对等方在没有故障切换的情况下确认了控制通道消息，但控制通道消息丢失是一种临时现象，则计时器也会停止。
This AVP MUST NOT be included in any control message other than SCCRQ and SCCRP messages.
除SCCRQ和SCCRP消息外，此AVP不得包含在任何控制消息中。
The Tunnel Recovery AVP, Attribute Type 77, indicates that a sender would like to recover the tunnel identified in this AVP due to a failure. The AVP format is defined as follows:
隧道恢复AVP属性类型77表示由于故障，发送方希望恢复此AVP中标识的隧道。AVP格式定义如下：
Tunnel Recovery AVP for L2TPv3 tunnels:
L2TPv3隧道的隧道恢复AVP：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 77 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recover Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recover Remote Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 77 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recover Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recover Remote Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tunnel Recovery AVP for L2TPv2 tunnels:
L2TPv2隧道的隧道恢复AVP：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 77 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Recover Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Recover Remote Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 77 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Recover Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Recover Remote Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP MUST not be hidden (the H-bit is set to 0). The AVP is mandatory (the M-bit is set to 1).
不得隐藏此AVP（H位设置为0）。AVP是必需的（M位设置为1）。
The Recover Tunnel ID encodes the local Tunnel ID that an endpoint wants recovered. The Recover Remote Tunnel ID encodes the remote Tunnel ID corresponding to the old tunnel.
恢复隧道ID对端点希望恢复的本地隧道ID进行编码。恢复远程隧道ID对与旧隧道对应的远程隧道ID进行编码。
This AVP MUST NOT be included in any control message other than the SCCRQ message when establishing a Recovery Tunnel.
在建立恢复隧道时，此AVP不得包含在SCCRQ消息以外的任何控制消息中。
The Suggested Control Sequence (SCS) AVP, Attribute Type 78, specifies the Ns and Nr values to for the recovered tunnel. This AVP is included in an SCCRP message of a recovery tunnel by remote endpoint. The AVP format is defined as follows:
建议的控制序列（SCS）AVP，属性类型78，指定要恢复的隧道的Ns和Nr值。远程端点将此AVP包含在恢复隧道的SCCRP消息中。AVP格式定义如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 78 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suggested Ns | Suggested Nr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 78 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suggested Ns | Suggested Nr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP MAY be hidden (the H-bit set to 0 or 1). The AVP is not mandatory (the M-bit is set to 0).
此AVP可能被隐藏（H位设置为0或1）。AVP不是强制性的（M位设置为0）。
This is an optional AVP, suggesting Ns and Nr values to be used by the recovery endpoint. If this AVP is present in an SCCRP message during recovery tunnel establishment, the recovery endpoint MUST set the Ns and Nr values of the recovered tunnel to the respective suggested values. When this AVP is not sent in an SCCRP or not present in an incoming SCCRP, the Ns and Nr values for the recovered tunnel are set to zero. Use of this AVP helps avoid the interference in the recovered tunnel's control channel with old control packets.
这是一个可选的AVP，建议恢复端点使用Ns和Nr值。如果在恢复隧道建立期间SCCRP消息中存在此AVP，则恢复端点必须将恢复隧道的Ns和Nr值设置为相应的建议值。当此AVP未在SCCRP中发送或在传入SCCRP中不存在时，已恢复隧道的Ns和Nr值设置为零。使用此AVP有助于避免恢复的隧道控制信道中旧控制数据包的干扰。
This AVP MUST NOT be included in any control message other than the SCCRP message when establishing a Recovery Tunnel.
在建立恢复隧道时，此AVP不得包含在SCCRP消息以外的任何控制消息中。
The Failover Session State (FSS) AVP, Attribute Type 79, is used to query the state of a session from the peer end to clear the sessions that otherwise would remain in an undefined state after failover. The AVP format is defined as follows:
故障转移会话状态（FSS）AVP属性类型79用于从对等端查询会话的状态，以清除故障转移后将保持在未定义状态的会话。AVP格式定义如下：
FSS AVP format for L2TPv3 sessions:
L2TPv3会话的FSS AVP格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 79 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 79 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FSS AVP format for L2TPv2 sessions:
L2TPv2会话的FSS AVP格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 79 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Remote Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type 79 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Remote Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP MAY be hidden (the H-bit set to 0 or 1). The AVP is mandatory (the M-bit is set to 1).
此AVP可能被隐藏（H位设置为0或1）。AVP是必需的（M位设置为1）。
The Session ID identifies the local Session ID that the sender had assigned, for which it would like to query the state on its peer. A Remote Session Id is the remote Session ID for the same session.
会话ID标识发送方已分配的本地会话ID，发送方希望在对等方上查询其状态。远程会话Id是同一会话的远程会话Id。
An FSS AVP MUST NOT be used in any message other than FSQ and FSR messages.
FSS AVP不得用于除FSQ和FSR消息以外的任何消息中。
An L2TP endpoint MAY expose the following configuration parameters to be specified for control connections:
L2TP端点可以公开以下要为控制连接指定的配置参数：
- Control Channel Failover Capability: Failover Capability AVP (Section 5.1), C bit.
- 控制通道故障切换能力：故障切换能力AVP（第5.1节），C位。
- Data Channel Failover Capability: Failover Capability AVP (Section 5.1), D bit.
- 数据通道故障切换能力：故障切换能力AVP（第5.1节），D位。
- Recovery Time: Failover Capability AVP (Section 5.1).
- 恢复时间：故障切换能力AVP（第5.1节）。
The L2TP MIB defined in [L2TPv2-MIB] and [L2TPv3-MIB], defines a number of objects that may be used for monitoring the status L2TP nodes, but is seldom used for configuration purposes. It is expected that the above mentioned parameters will be configured by using a Command Line Interface (CLI) or other proprietary mechanism.
[L2TPv2 MIB]和[L2TPv3 MIB]中定义的L2TP MIB定义了许多对象，这些对象可用于监视L2TP节点的状态，但很少用于配置目的。预计将使用命令行界面（CLI）或其他专有机制配置上述参数。
Asynchronous notifications for failover and recovery events may be sent by L2TP nodes to network management applications, but the specification of the protocol and format to be used for these notifications is out of the scope of this document.
L2TP节点可能会向网络管理应用程序发送故障转移和恢复事件的异步通知，但用于这些通知的协议和格式的规范不在本文档的范围内。
This document defines the following values assigned by IANA.
本文件定义了IANA分配的以下值。
- Four Control Message Attribute Value Pairs (Section 10.1 [L2TPv3]):
- 四个控制消息属性值对（第10.1节[L2TPv3]）：
Failover Capability : 76 Tunnel Recovery : 77 Suggested Control Sequence : 78 Failover Session State : 79
故障转移能力：76隧道恢复：77建议的控制顺序：78故障转移会话状态：79
- Two Message Type (Attribute Type 0) Values (Section 10.2 [L2TPv3]):
- 两个消息类型（属性类型0）值（第10.2节[L2TPv3]）：
Failover Session Query : 21 Failover Session Response : 22
故障转移会话查询：21故障转移会话响应：22
A spoofed failover request (SCCRQ with Tunnel Recovery AVP) on behalf of an endpoint might cause a control channel termination if authentication measures mentioned in Section 3.2.1 are not used.
如果未使用第3.2.1节中提到的身份验证措施，则代表端点的伪造故障转移请求（带隧道恢复AVP的SCCRQ）可能会导致控制通道终止。
Even if the authentication measures (as described in Section 3.2.1) were used, it is still possible to learn an identity of an operational tunnel from an endpoint by issuing it spoofed failover requests that fail the authentication procedure. The probability of succeeding with a spoofed failover request is 1 in (2^16 - 1) for [L2TPv2] and 1 in (2^32 - 1) for [L2TPv3]. The discovered identity of an operational tunnel could then be misused to send control messages for a possible hindrance to the control connection. Typically, control messages that are outside the endpoint's receive window are discarded. However, if Suggested Control Sequence AVP (Section 5.3) is not used during the actual failover process, the sequence numbers might be reset to zero, thereby making the receive window predictable. To improve security under such circumstances, an endpoint may be configured with the possible set of recovery endpoints that could recover a tunnel, and use of Suggested Control Sequence AVP when recovering a tunnel.
即使使用了身份验证措施（如第3.2.1节所述），也可以通过发出使身份验证过程失败的伪造故障转移请求，从端点了解运行隧道的标识。[L2TPv2]成功执行伪造故障转移请求的概率为1 in（2^16-1），而[L2TPv3]成功执行伪造故障转移请求的概率为1 in（2^32-1）。然后，发现的正在运行的隧道的标识可能会被误用以发送控制消息，从而可能阻碍控制连接。通常，端点的接收窗口之外的控制消息将被丢弃。但是，如果在实际故障切换过程中未使用建议的控制序列AVP（第5.3节），则序列号可能会重置为零，从而使接收窗口可预测。为了提高这种情况下的安全性，端点可以配置有可能恢复隧道的恢复端点集，并在恢复隧道时使用建议的控制序列AVP。
Leo Huber provided suggestions to help define the failover concept. Mark Townsley, Carlos Pignataro, and Ignacio Goyret reviewed the document and provided valuable suggestions.
Leo Huber提供了帮助定义故障转移概念的建议。马克·汤斯利、卡洛斯·皮格纳塔罗和伊格纳西奥·戈雷特审查了该文件，并提出了宝贵的建议。
Paul Howard Juniper Networks Vipin Jain Riverstone Networks Sam Henderson Cisco Systems Keyur Parikh Harris Corporations
保罗·霍华德·朱尼珀网络公司Vipin Jain Riverstone网络公司山姆·亨德森思科系统公司Keyur Parikh Harris公司
[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月。
[L2TPv2] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[L2TPv2]汤斯利，W.，瓦伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.，和B.帕尔特，“第二层隧道协议“L2TP”，RFC 26611999年8月。
[L2TPv3] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[L2TPv3]Lau，J.，Townsley，M.，和I.Goyret，“第二层隧道协议-版本3（L2TPv3）”，RFC 39312005年3月。
[L2TPv2-MIB] Caves, E., Calhoun, P., and R. Wheeler, "Layer Two Tunneling Protocol "L2TP" Management Information Base", RFC 3371, August 2002.
[L2TPv2 MIB]Caves，E.，Calhoun，P.和R.Wheeler，“第二层隧道协议”L2TP“管理信息库”，RFC 3371，2002年8月。
[L2TPv3-MIB] Nadeau, T. and K. Koushik, "Layer Two Tunneling Protocol (version 3) Management Information Base", Work in Progress, August 2006.
[L2TPv3 MIB]Nadeau，T.和K.Koushik，“第二层隧道协议（第3版）管理信息库”，正在进行的工作，2006年8月。
[BFD-MULTIHOP] Katz, D. and D. Ward, "BFD for Multihop Paths", Work in Progress, March 2007.
[BFD-MULTIHOP]Katz，D.和D.Ward，“多跳路径的BFD”，正在进行的工作，2007年3月。
Description below outlines the failover protocol operation for an example tunnel. The failover protocol does not preclude an endpoint from recovering multiple tunnels in parallel. It also allows an endpoint to send multiple FSQs, each including multiple FSS AVPs, to recover quickly.
下面的说明概述了示例隧道的故障切换协议操作。故障转移协议不排除端点并行恢复多个隧道。它还允许端点发送多个FSQ，每个FSQ包括多个FSS AVP，以便快速恢复。
Failover Capability Negotiation (Section 3.1):
故障转移能力协商（第3.1节）：
Endpoint Peer
(assigned tid = x, failover capable)
SCCRQ --------------------------------------> validate SCCRQ
Endpoint Peer
(assigned tid = x, failover capable)
SCCRQ --------------------------------------> validate SCCRQ
(assigned tid = y, failover capable)
validate <-------------------------------------- send SCCRP
SCCRP, etc.
(assigned tid = y, failover capable)
validate <-------------------------------------- send SCCRP
SCCRP, etc.
.... <after tunnel gets created, sessions are established> ....
.... <after tunnel gets created, sessions are established> ....
< This Node fails >
<此节点失败>
The Recovery endpoint establishes the recovery tunnel (Section 3.2.1). Initiate recovery tunnel establishment for the old tunnel 'x':
恢复端点建立了恢复通道（第3.2.1节）。启动旧隧道“x”的恢复隧道建立：
Recovery Endpoint Peer
恢复端点对等
(assigned tid = z, Recovery AVP)
SCCRQ -----------------------------------> Detects failover
(recover tid = x, recover remote tid = y) validate SCCRQ
(assigned tid = z, Recovery AVP)
SCCRQ -----------------------------------> Detects failover
(recover tid = x, recover remote tid = y) validate SCCRQ
(Suggested Control Sequence AVP, Suggested Ns/Nr = 3/100)
validate <----------------------------------- send SCCRP
SCCRP (recover tid = y, recover remote tid = x)
reset Ns = 3, Nr = 100
on the recovered tunnel
(Suggested Control Sequence AVP, Suggested Ns/Nr = 3/100)
validate <----------------------------------- send SCCRP
SCCRP (recover tid = y, recover remote tid = x)
reset Ns = 3, Nr = 100
on the recovered tunnel
SCCCN -----------------------------------> validate and reset
Ns = 100, Nr = 3 on
the recovered tunnel
SCCCN -----------------------------------> validate and reset
Ns = 100, Nr = 3 on
the recovered tunnel
Terminate the recovery tunnel
终止恢复隧道
tid = 'z'
StopCCN --------------------------------------> Cleanup 'w'
tid = 'z'
StopCCN --------------------------------------> Cleanup 'w'
Session states are synchronized both endpoints may send FSQs and cleanup stale sessions (Section 3.3)
会话状态是同步的。两个端点都可以发送FSQ和清除过时会话（第3.3节）
(FSS AVP for sessions s1, s2, s3..)
send FSQ -------------------------------------> compute the state
of sessions in FSQ
(FSS AVP for sessions s1, s2, s3..)
send FSQ -------------------------------------> compute the state
of sessions in FSQ
(FSS AVP for sessions s1, s2, s3...)
deletes <-------------------------------------- send FSR
stale sessions, if any
(FSS AVP for sessions s1, s2, s3...)
deletes <-------------------------------------- send FSR
stale sessions, if any
(FSS AVP for sessions s7, s8, s9...)
compute <-------------------------------------- send FSQ
the sate of
sessions in FSQ
(FSS AVP for sessions s7, s8, s9...)
compute <-------------------------------------- send FSQ
the sate of
sessions in FSQ
(FSS AVP for sessions s7, s8, s9...)
send FSR --------------------------------------> delete stale
sessions, if any
(FSS AVP for sessions s7, s8, s9...)
send FSR --------------------------------------> delete stale
sessions, if any
This section shows an example dialogue to illustrate double failure recovery. The notable difference, as described in Section 3.2.1, in the procedure from single failover scenario is the use of a tie breaker by one of the recovery endpoints to use the recovery tunnel established by its peer (also a recovery endpoint) as a recovery tunnel.
本节显示了一个示例对话，以说明双故障恢复。如第3.2.1节所述，在单一故障切换场景的过程中，一个恢复端点使用连接断路器将其对等方（也是恢复端点）建立的恢复隧道用作恢复隧道，这是一个显著的区别。
Recovery endpoint Recovery endpoint
恢复终结点恢复终结点
(assume old tid = A) (assume old tid = B)
（假设旧tid=A）（假设旧tid=B）
Recovery AVP = (A, B)
SCCRQ -----------------------+
(with tie (recovery tunnel 'C') |
breaker |
AVP) |
Recovery AVP = (B, A) |
+- valid <--------------------------- Send SCCRQ
| SCCRQ (recovery tunnel 'D') | (with tie breaker AVP)
| This endpoint |
| loses tie; |
| Discards tunnel 'C' +--> Valid SCCRQ
| This endpoint wins tie;
| Discards SCCRQ
|
| (may include SCS AVP)
+->Send SCCRP -------------------------> Validate SCCRP
Reset 'B';
Set Ns, Nr values --+
|
|
|
Validate SCCN <---------------------- Send SCCN -------+
Reset 'A';
Set Ns, Nr values
Recovery AVP = (A, B)
SCCRQ -----------------------+
(with tie (recovery tunnel 'C') |
breaker |
AVP) |
Recovery AVP = (B, A) |
+- valid <--------------------------- Send SCCRQ
| SCCRQ (recovery tunnel 'D') | (with tie breaker AVP)
| This endpoint |
| loses tie; |
| Discards tunnel 'C' +--> Valid SCCRQ
| This endpoint wins tie;
| Discards SCCRQ
|
| (may include SCS AVP)
+->Send SCCRP -------------------------> Validate SCCRP
Reset 'B';
Set Ns, Nr values --+
|
|
|
Validate SCCN <---------------------- Send SCCN -------+
Reset 'A';
Set Ns, Nr values
FSQs and FSRs for the old tunnel (A, B) are exchanged on the recovered tunnel by both endpoints.
旧隧道（A、B）的FSQ和FSR由两个端点在恢复的隧道上交换。
Session ID mismatch could not be a result of failure on one of the endpoints. However, failover session recovery procedure could exacerbate the situation, resulting into a permanent mismatch in Session IDs between two endpoints. The dialogue below outlines the behavior described in Section 3.3, Step III to handle such situations gracefully.
会话ID不匹配不能是某个终结点失败的结果。但是，故障转移会话恢复过程可能会加剧这种情况，导致两个端点之间的会话ID永久不匹配。下面的对话概述了第3.3节第三步中描述的优雅处理此类情况的行为。
Recovery endpoint Remote endpoint
恢复终结点远程终结点
(assume a mismatch) (assume a mismatch)
Sid = A, Remote Sid = B Sid = B, Remote Sid = C
Sid = C, Remote Sid = D
(assume a mismatch) (assume a mismatch)
Sid = A, Remote Sid = B Sid = B, Remote Sid = C
Sid = C, Remote Sid = D
FSS AVP (A, B)
send FSQ -------------------------> No (B, A) pair exist;
rather (B, C) exist.
If it clears B then peer doesn't
know if C is stale on other end.
FSS AVP (A, B)
send FSQ -------------------------> No (B, A) pair exist;
rather (B, C) exist.
If it clears B then peer doesn't
know if C is stale on other end.
Instead if it marks B stale and queries the session state via FSQ, C would be cleared on the other end.
相反，如果它将B标记为stale并通过FSQ查询会话状态，则另一端的C将被清除。
FSS AVP (0, A)
Clears A <-------------------------- send FSR
FSS AVP (0, A)
Clears A <-------------------------- send FSR
... some time later ...
... 过了一段时间。。。
FSS AVP (B, C)
No (C,B) <-------------------------- send FSQ
Mark C Stale
FSS AVP (B, C)
No (C,B) <-------------------------- send FSQ
Mark C Stale
FSS AVP (0, B)
Send FSR --------------------------> Clears B
FSS AVP (0, B)
Send FSR --------------------------> Clears B
Author Information
作者信息
Vipin Jain Riverstone Networks 5200 Great America Parkway Santa Clara, CA 95054 EMail: vipinietf@yahoo.com
Vipin Jain Riverstone Networks 5200大美洲大道圣克拉拉，加利福尼亚州95054电子邮件：vipinietf@yahoo.com
Paul W. Howard Juniper Networks 10 Technology Park Drive Westford, MA 01886 EMail: phoward@juniper.net
Paul W.Howard Juniper Networks 10 Technology Park Drive Westford，马萨诸塞州01886电子邮件：phoward@juniper.net
Sam Henderson Cisco Systems 7025 Kit Creek Rd. PO Box 14987 Research Triangle Park, NC 27709 EMail: samh@cisco.com
Sam Henderson Cisco Systems 7025 Kit Creek路邮政信箱14987北卡罗来纳州三角研究园27709电子邮件：samh@cisco.com
Keyur Parikh Harris Corporation 4393 Digitalway Mason, OH 45040 EMail: kparikh@harris.com
Keyur Parikh Harris Corporation 4393 Digitalway Mason，俄亥俄州45040电子邮件：kparikh@harris.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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。