Network Working Group A. Farrel, Ed.
Request for Comments: 3479 Movaz Networks, Inc.
Category: Standards Track February 2003
Network Working Group A. Farrel, Ed.
Request for Comments: 3479 Movaz Networks, Inc.
Category: Standards Track February 2003
Fault Tolerance for the Label Distribution Protocol (LDP)
标签分发协议（LDP）的容错性
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
IESG Note
IESG注释
This specification includes procedures for failure detection and failover for a TCP connection carrying MPLS LDP control traffic, so that it can be switched to a new TCP connection. It does not provide a general approach to using multiple TCP connections to provide this kind of fault tolerance. The specification lacks adequate guidance for the timer and retry value choices related to the TCP connection fault tolerance procedures. The specification should not serve as a model for TCP connection fault tolerance design for any future document, and users are advised to test configurations based on this specification very carefully for problems such as premature failovers.
本规范包括承载MPLS LDP控制流量的TCP连接的故障检测和故障切换过程，以便可以将其切换到新的TCP连接。它没有提供使用多个TCP连接来提供这种容错的通用方法。该规范对与TCP连接容错过程相关的计时器和重试值选择缺乏足够的指导。本规范不应作为任何未来文档的TCP连接容错设计模型，建议用户根据本规范非常仔细地测试配置，以防出现过早故障切换等问题。
Abstract
摘要
Multiprotocol Label Switching (MPLS) systems will be used in core networks where system downtime must be kept to an absolute minimum. Many MPLS Label Switching Routers (LSRs) may, therefore, exploit Fault Tolerant (FT) hardware or software to provide high availability of the core networks.
多协议标签交换（MPLS）系统将用于核心网络，其中系统停机时间必须保持在绝对最小。因此，许多MPLS标签交换路由器（LSR）可能利用容错（FT）硬件或软件来提供核心网络的高可用性。
The details of how FT is achieved for the various components of an FT LSR, including Label Distribution Protocol (LDP), the switching hardware and TCP, are implementation specific. This document identifies issues in the LDP specification in RFC 3036, "LDP Specification", that make it difficult to implement an FT LSR using the current LDP protocols, and defines enhancements to the LDP specification to ease such FT LSR implementations.
FT LSR的各个组件（包括标签分发协议（LDP）、交换硬件和TCP）如何实现FT的细节是具体实现的。本文件确定了RFC 3036“LDP规范”中LDP规范中的问题，这些问题使得难以使用当前LDP协议实现FT LSR，并定义了LDP规范的增强功能，以简化此类FT LSR实现。
The issues and extensions described here are equally applicable to RFC 3212, "Constraint-Based LSP Setup Using LDP" (CR-LDP).
这里描述的问题和扩展同样适用于RFC 3212，“使用LDP的基于约束的LSP设置”（CR-LDP）。
Table of Contents
目录
1. Conventions and Terminology used in this document..........3
2. Contributing Authors.......................................4
3. Introduction...............................................4
3.1. Fault Tolerance for MPLS..............................4
3.2. Issues with LDP.......................................5
4. Overview of LDP FT Enhancements............................7
4.1. Establishing an FT LDP Session........................8
4.1.1 Interoperation with Non-FT LSRs.................8
4.2. TCP Connection Failure................................9
4.2.1 Detecting TCP Connection Failures...............9
4.2.2 LDP Processing after Connection Failure.........9
4.3. Data Forwarding During TCP Connection Failure........10
4.4. FT LDP Session Reconnection..........................10
4.5. Operations on FT Labels..............................11
4.6. Check-Pointing.......................................11
4.6.1 Graceful Termination...........................12
4.7. Label Space Depletion and Replenishment..............13
4.8. Tunneled LSPs........................................13
5. FT Operations.............................................14
5.1. FT LDP Messages......................................14
5.1.1 Sequence Numbered FT Label Messages............14
5.1.2 FT Address Messages............................15
5.1.3 Label Resources Available Notifications........15
5.2. FT Operation ACKs....................................17
5.3. Preservation of FT State.............................17
5.4. FT Procedure After TCP Failure.......................19
5.4.1 FT LDP Operations During TCP Failure...........20
5.5. FT Procedure After TCP Re-connection.................21
5.5.1 Re-Issuing FT Messages.........................22
6. Check-Pointing Procedures.................................22
6.1 Check-Pointing with the Keepalive Message.............23
6.2 Quiesce and Keepalive.................................23
7. Changes to Existing Messages..............................24
7.1. LDP Initialization Message...........................24
7.2. LDP Keepalive Messages...............................25
7.3. All Other LDP Session Messages.......................25
8. New Fields and Values.....................................26
8.1. Status Codes.........................................26
8.2. FT Session TLV.......................................27
8.3. FT Protection TLV....................................29
8.4. FT ACK TLV...........................................32
8.5. FT Cork TLV..........................................33
9. Example Use...............................................34
1. Conventions and Terminology used in this document..........3
2. Contributing Authors.......................................4
3. Introduction...............................................4
3.1. Fault Tolerance for MPLS..............................4
3.2. Issues with LDP.......................................5
4. Overview of LDP FT Enhancements............................7
4.1. Establishing an FT LDP Session........................8
4.1.1 Interoperation with Non-FT LSRs.................8
4.2. TCP Connection Failure................................9
4.2.1 Detecting TCP Connection Failures...............9
4.2.2 LDP Processing after Connection Failure.........9
4.3. Data Forwarding During TCP Connection Failure........10
4.4. FT LDP Session Reconnection..........................10
4.5. Operations on FT Labels..............................11
4.6. Check-Pointing.......................................11
4.6.1 Graceful Termination...........................12
4.7. Label Space Depletion and Replenishment..............13
4.8. Tunneled LSPs........................................13
5. FT Operations.............................................14
5.1. FT LDP Messages......................................14
5.1.1 Sequence Numbered FT Label Messages............14
5.1.2 FT Address Messages............................15
5.1.3 Label Resources Available Notifications........15
5.2. FT Operation ACKs....................................17
5.3. Preservation of FT State.............................17
5.4. FT Procedure After TCP Failure.......................19
5.4.1 FT LDP Operations During TCP Failure...........20
5.5. FT Procedure After TCP Re-connection.................21
5.5.1 Re-Issuing FT Messages.........................22
6. Check-Pointing Procedures.................................22
6.1 Check-Pointing with the Keepalive Message.............23
6.2 Quiesce and Keepalive.................................23
7. Changes to Existing Messages..............................24
7.1. LDP Initialization Message...........................24
7.2. LDP Keepalive Messages...............................25
7.3. All Other LDP Session Messages.......................25
8. New Fields and Values.....................................26
8.1. Status Codes.........................................26
8.2. FT Session TLV.......................................27
8.3. FT Protection TLV....................................29
8.4. FT ACK TLV...........................................32
8.5. FT Cork TLV..........................................33
9. Example Use...............................................34
9.1. Session Failure and Recovery - FT Procedures.........34
9.2. Use of Check-Pointing With FT Procedures.............37
9.3. Temporary Shutdown With FT Procedures................38
9.4. Temporary Shutdown With FT Procedures
and Check-Pointing...................................40
9.5. Check-Pointing Without FT Procedures.................42
9.6. Graceful Shutdown With Check-Pointing
But No FT Procedures.................................44
10. Security Considerations..................................45
11. Implementation Notes.....................................47
11.1. FT Recovery Support on Non-FT LSRs..................47
11.2. ACK generation logic................................47
11.2.1 Ack Generation Logic When Using
Check-Pointing...............................47
11.3 Interactions With Other Label Distribution
Mechanisms...........................................48
12. Acknowledgments..........................................48
13. Intellectual Property Consideration......................49
14. References...............................................49
14.1. Normative References................................49
14.2. Informative References..............................50
15. Authors' Addresses.......................................50
16. Full Copyright Statement.................................52
9.1. Session Failure and Recovery - FT Procedures.........34
9.2. Use of Check-Pointing With FT Procedures.............37
9.3. Temporary Shutdown With FT Procedures................38
9.4. Temporary Shutdown With FT Procedures
and Check-Pointing...................................40
9.5. Check-Pointing Without FT Procedures.................42
9.6. Graceful Shutdown With Check-Pointing
But No FT Procedures.................................44
10. Security Considerations..................................45
11. Implementation Notes.....................................47
11.1. FT Recovery Support on Non-FT LSRs..................47
11.2. ACK generation logic................................47
11.2.1 Ack Generation Logic When Using
Check-Pointing...............................47
11.3 Interactions With Other Label Distribution
Mechanisms...........................................48
12. Acknowledgments..........................................48
13. Intellectual Property Consideration......................49
14. References...............................................49
14.1. Normative References................................49
14.2. Informative References..............................50
15. Authors' Addresses.......................................50
16. Full Copyright Statement.................................52
Definitions of key words and terms applicable to LDP and CR-LDP are inherited from [RFC3212] and [RFC3036].
适用于LDP和CR-LDP的关键词和术语的定义继承自[RFC3212]和[RFC3036]。
The term "FT Label" is introduced in this document to indicate a label for which some fault tolerant operation is used. A "non-FT Label" is not fault tolerant and is handled as specified in [RFC3036].
本文件中引入术语“FT标签”，表示使用了容错操作的标签。“非FT标签”不具有容错性，按照[RFC3036]中的规定进行处理。
The term "Sequence Numbered FT Label" is used to indicate an FT label which is secured using the sequence number in the FT Protection TLV described in this document.
术语“序列号FT标签”用于表示使用本文件所述FT保护TLV中的序列号固定的FT标签。
The term "Check-Pointable FT Label" is used to indicate an FT label which is secured by using the check-pointing techniques described in this document.
术语“可检查点的FT标签”用于表示通过使用本文档中描述的检查点技术固定的FT标签。
The extensions to LDP specified in this document are collectively referred to as the "LDP FT enhancements".
本文件中规定的LDP扩展统称为“LDP FT增强”。
Within the context of this document, "Check-Pointing" refers to a process of message exchanges that confirm receipt and processing (or secure storage) of specific protocol messages.
在本文件的上下文中，“检查点”指确认接收和处理（或安全存储）特定协议消息的消息交换过程。
When talking about the individual bits in the 16-bit FT Flag Field, the words "bit" and "flag" are used interchangeably.
当谈到16位FT标志字段中的各个位时，“位”和“标志”可互换使用。
In the examples quoted, the following notation is used: Ln : An LSP. For example L1. Pn : An LDP peer. For example P1.
在引用的示例中，使用了以下符号：Ln:LSP。例如L1。请注意：自民党同僚。例如P1。
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 BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
This document was the collective work of several individuals over a period of several years. The text and content of this document was contributed by the editor and the co-authors listed in section 15, "Authors' Addresses".
这份文件是几位个人几年来的集体工作。本文件的文本和内容由第15节“作者地址”中列出的编辑和合著者提供。
High Availability (HA) is typically claimed by equipment vendors when their hardware achieves availability levels of at least 99.999% (five 9s). To implement this, the equipment must be capable of recovering from local hardware and software failures through a process known as fault tolerance (FT).
高可用性（HA）通常由设备供应商在其硬件达到至少99.999%（五个9）的可用性级别时提出。为了实现这一点，设备必须能够通过称为容错（FT）的过程从本地硬件和软件故障中恢复。
The usual approach to FT involves provisioning backup copies of hardware and/or software. When a primary copy fails, processing is switched to the backup copy. This process, called failover, should result in minimal disruption to the Data Plane.
通常的FT方法包括提供硬件和/或软件的备份副本。当主副本失败时，处理将切换到备份副本。这一过程称为故障转移，应将对数据平面的中断降至最低。
In an FT system, backup resources are sometimes provisioned on a one-to-one basis (1:1), sometimes as one-to-many (1:n), and occasionally as many-to-many (m:n). Whatever backup provisioning is made, the system must switch to the backup automatically on failure of the primary, and the software and hardware state in the backup must be set to replicate the state in the primary at the point of failure.
在FT系统中，备份资源有时以一对一（1:1）的方式调配，有时以一对多（1:n）的方式调配，有时以多对多（m:n）的方式调配。无论进行何种备份调配，系统都必须在主设备发生故障时自动切换到备份，并且备份中的软件和硬件状态必须设置为在故障点复制主设备中的状态。
MPLS is a technology that will be used in core networks where system downtime must be kept to an absolute minimum. Many MPLS LSRs may, therefore, exploit FT hardware or software to provide high availability of core networks.
MPLS是一种将用于核心网络的技术，在核心网络中，系统停机时间必须保持在绝对最小。因此，许多MPLS LSR可能利用FT硬件或软件来提供核心网络的高可用性。
In order to provide HA, an MPLS system needs to be able to survive a variety of faults with minimal disruption to the Data Plane, including the following fault types:
为了提供HA，MPLS系统需要能够在对数据平面中断最小的情况下经受住各种故障，包括以下故障类型：
- failure/hot-swap of a physical connection between LSRs.
- LSR之间物理连接的故障/热交换。
- failure/hot-swap of the switching fabric in an LSR.
- LSR中交换结构的故障/热交换。
- failure of the TCP or LDP stack in an LSR.
- LSR中的TCP或LDP堆栈失败。
- software upgrade to the TCP or LDP stacks in an LSR.
- LSR中TCP或LDP堆栈的软件升级。
The first two examples of faults listed above are confined to the Data Plane. Such faults can be handled by providing redundancy in the Data Plane which is transparent to LDP operating in the Control Plane. The last two example types of fault require action in the Control Plane to recover from the fault without disrupting traffic in the Data Plane. This is possible because many recent router architectures separate the Control and Data Planes such that forwarding can continue unaffected by recovery action in the Control Plane.
上面列出的前两个故障示例仅限于数据平面。可以通过在数据平面中提供冗余来处理此类故障，该冗余对在控制平面中操作的LDP是透明的。最后两种示例类型的故障需要在控制平面中执行操作，以便在不中断数据平面中的通信量的情况下从故障中恢复。这是可能的，因为许多最近的路由器架构将控制平面和数据平面分开，这样转发就可以继续，而不受控制平面中恢复操作的影响。
LDP uses TCP to provide reliable connections between LSRs over which they exchange protocol messages to distribute labels and set up LSPs. A pair of LSRs that have such a connection are referred to as LDP peers.
LDP使用TCP在LSR之间提供可靠的连接，通过它们交换协议消息来分发标签和设置LSP。具有这种连接的一对lsr被称为LDP对等点。
TCP enables LDP to assume reliable transfer of protocol messages. This means that some of the messages do not need to be acknowledged (for example, Label Release).
TCP使LDP能够承担协议消息的可靠传输。这意味着一些消息不需要确认（例如，标签发布）。
LDP is defined such that if the TCP connection fails, the LSR should immediately tear down the LSPs associated with the session between the LDP peers, and release any labels and resources assigned to those LSPs.
LDP的定义是，如果TCP连接失败，LSR应立即拆除与LDP对等方之间的会话相关联的LSP，并释放分配给这些LSP的任何标签和资源。
It is notoriously hard to provide a Fault Tolerant implementation of TCP. To do so might involve making copies of all data sent and received. This is an issue familiar to implementers of other TCP applications such as BGP.
众所周知，很难提供TCP的容错实现。要做到这一点，可能需要复制发送和接收的所有数据。这是其他TCP应用程序（如BGP）的实现者所熟悉的问题。
During failover affecting the TCP or LDP stacks, the TCP connection may be lost. Recovery from this position is made worse by the fact that LDP control messages may have been lost during the connection failure. Since these messages are unconfirmed, it is possible that LSP or label state information will be lost.
在影响TCP或LDP堆栈的故障转移期间，TCP连接可能会丢失。由于LDP控制消息可能在连接失败期间丢失，因此从该位置的恢复变得更糟。由于这些消息未经确认，因此可能会丢失LSP或标签状态信息。
This document describes a solution which involves:
本文档描述了一种解决方案，其中包括：
- negotiation between LDP peers of the intent to support extensions to LDP that facilitate recovery from failover without loss of LSPs.
- LDP对等方之间的协商旨在支持对LDP的扩展，以便在不丢失LSP的情况下从故障切换中恢复。
- selection of FT survival on a per LSP/label basis.
- 根据每个LSP/标签选择FT存活率。
- acknowledgement of LDP messages to ensure that a full handshake is performed on those messages either frequently (such as per message) or less frequently as in check-pointing.
- LDP消息的确认，以确保在这些消息上频繁地（如每条消息）或不频繁地（如在检查点中）执行完全握手。
- solicitation of up-to-date acknowledgement (check-pointing) of previous LDP messages to ensure the current state is flushed to disk/NVRAM, with an additional option that allows an LDP partner to request that state is flushed in both directions if graceful shutdown is required.
- 请求先前LDP消息的最新确认（检查点），以确保当前状态刷新到磁盘/NVRAM，如果需要正常关机，LDP合作伙伴还可以使用另一个选项请求在两个方向刷新状态。
- re-issuing lost messages after failover to ensure that LSP/label state is correctly recovered after reconnection of the LDP session.
- 在故障转移后重新发出丢失的消息，以确保在重新连接LDP会话后正确恢复LSP/标签状态。
The issues and objectives described above are equally applicable to CR-LDP.
上述问题和目标同样适用于CR-LDP。
Other objectives of this document are to:
本文件的其他目标是：
- offer backward-compatibility with LSRs that do not implement these extensions to LDP.
- 提供与不实现这些LDP扩展的LSR的向后兼容性。
- preserve existing protocol rules described in [RFC3036] for handling unexpected duplicate messages and for processing unexpected messages referring to unknown LSPs/labels.
- 保留[RFC3036]中描述的现有协议规则，用于处理意外重复消息和处理涉及未知LSP/标签的意外消息。
- avoid full state refresh solutions (such as those present in RSVP: see [RFC2205], [RFC2961], [RFC3209] and [RFC3478]) whether they be continual, or limited to post-failover recovery.
- 避免完全状态刷新解决方案（如RSVP中的解决方案：请参阅[RFC2205]、[RFC2961]、[RFC3209]和[RFC3478]），无论它们是连续的还是仅限于故障转移后恢复。
Note that this document concentrates on the preservation of label state for labels exchanged between a pair of adjacent LSRs when the TCP connection between those LSRs is lost. This is a requirement for Fault Tolerant operation of LSPs, but a full implementation of end-to-end protection for LSPs requires that this be combined with other techniques that are outside the scope of this document.
请注意，本文档集中讨论当一对相邻LSR之间的TCP连接丢失时，如何为这些LSR之间交换的标签保留标签状态。这是LSP容错操作的要求，但全面实施LSP端到端保护要求将其与本文件范围之外的其他技术相结合。
In particular, this document does not attempt to describe how to modify the routing of an LSP or the resources allocated to a label or LSP, which is covered by [RFC3214]. This document also does not
特别是，本文档不试图描述如何修改LSP的路由或分配给标签或LSP的资源，这在[RFC3214]中有所涉及。本文件也不适用
address how to provide automatic layer 2 or layer 3 protection switching for a label or LSP, which is a separate area for study.
说明如何为标签或LSP提供自动第2层或第3层保护切换，这是一个单独的研究领域。
This specification does not preclude an implementation from attempting (or require it to attempt) to use the FT behavior described here to recover from a preemptive failure of a connection on a non-FT system due to, for example, a partial system crash. Note, however, that there are potential issues too numerous to list here - not least the likelihood that the same crash will immediately occur when processing the restored data.
本规范不排除实现尝试（或要求其尝试）使用此处描述的FT行为，以从非FT系统上的连接抢占式故障（例如，由于部分系统崩溃）中恢复。但是，请注意，这里列出的潜在问题太多了，尤其是在处理恢复的数据时，同一崩溃将立即发生的可能性。
The LDP FT enhancements consist of the following main elements, which are described in more detail in the sections that follow.
LDP FT增强功能包括以下主要元素，这些元素将在后面的章节中进行更详细的描述。
- The presence of an FT Session TLV on the LDP Initialization message indicates that an LSR supports some form of protection or recovery from session failure. A flag bit within this TLV (the S bit) indicates that the LSR supports the LDP FT enhancements on this session. Another flag (the C bit) indicates that the check-pointing procedures are to be used.
- LDP初始化消息上存在FT会话TLV表示LSR支持某种形式的保护或会话故障恢复。此TLV中的标志位（S位）表示LSR支持此会话上的LDP FT增强。另一个标志（C位）表示要使用检查点过程。
- An FT Reconnect Flag in the FT Session TLV (the R bit) indicates whether an LSR has preserved FT Label state across a failure of the TCP connection.
- FT会话TLV中的FT Reconnect标志（R位）指示LSR是否在TCP连接故障期间保留了FT标签状态。
- An FT Reconnection Timeout, exchanged on the LDP Initialization message, that indicates the maximum time peer LSRs will preserve FT Label state after a failure of the TCP connection.
- 在LDP初始化消息上交换的FT重新连接超时，指示对等LSR在TCP连接失败后保持FT标签状态的最长时间。
- An FT Protection TLV used to identify operations that affect LDP labels. All LDP messages carrying the FT Protection TLV need to be secured (e.g. to NVRAM) and ACKed to the sending LDP peer so that the state for Sequence Numbered FT Labels can be correctly recovered after LDP session reconnection.
- 一种FT保护TLV，用于识别影响LDP标签的操作。所有携带FT保护TLV的LDP消息都需要进行安全保护（例如到NVRAM）并确认给发送LDP对等方，以便在LDP会话重新连接后可以正确恢复序列号FT标签的状态。
Note that the implementation within an FT system is left open by this document. An implementation could choose to secure entire messages relating to Sequence Numbered FT Labels, or it could secure only the relevant state information.
请注意，本文档对FT系统内的实现保持开放状态。实现可以选择保护与序列号FT标签相关的整个消息，也可以只保护相关的状态信息。
- Address advertisement may also be secured by use of the FT Protection TLV. This enables recovery after LDP session reconnection without the need to re-advertise what may be a very large number of addresses.
- 地址广告也可以使用FT保护TLV进行保护。这可以在LDP会话重新连接后进行恢复，而无需重新公布大量地址。
- The FT Protection TLV may also be used on the Keepalive message to flush acknowledgement of all previous FT operations. This enables a check-point for future recovery, either in mid-session or prior to graceful shutdown of an LDP session. This procedure may also be used to check-point all (that is both FT and non-FT) operations for future recovery.
- FT保护TLV也可用于Keepalive消息，以刷新所有先前FT操作的确认。这为将来的恢复提供了一个检查点，无论是在会话中期还是在LDP会话正常关闭之前。此程序也可用于检查所有（即FT和非FT）操作，以便将来恢复。
In order that the extensions to LDP [RFC3036] described in this document can be used successfully on an LDP session between a pair of LDP peers, they MUST negotiate that the LDP FT enhancements are to be used on the LDP session.
为了在一对LDP对等方之间的LDP会话上成功使用本文档中描述的LDP[RFC3036]扩展，他们必须协商在LDP会话上使用LDP FT增强。
This is done on the LDP Initialization message exchange using a new FT Session TLV. Presence of this TLV indicates that the peer wants to support some form of protection or recovery processing. The S bit within this TLV indicates that the peer wants to support the LDP FT enhancements on this LDP session. The C bit indicates that the peer wants to support the check-pointing functions described in this document. The S and C bits may be set independently.
这是使用新的FT会话TLV在LDP初始化消息交换上完成的。此TLV的存在表示对等方希望支持某种形式的保护或恢复处理。该TLV中的S位表示对等方希望在此LDP会话上支持LDP FT增强。C位表示对等方希望支持本文档中描述的检查点功能。可以独立地设置S和C位。
The relevant LDP FT enhancements MUST be supported on an LDP session if both LDP peers include an FT Session TLV on the LDP Initialization message and have the same setting of the S or C bit.
如果两个LDP对等方在LDP初始化消息上都包含FT会话TLV，并且具有相同的S或C位设置，则LDP会话上必须支持相关的LDP FT增强。
If either LDP Peer does not include the FT Session TLV LDP Initialization message, or if there is no match of S and C bits between the peers, the LDP FT enhancements MUST NOT be used during this LDP session. Use of LDP FT enhancements by a sending LDP peer in these cases MUST be interpreted by the receiving LDP peer as a serious protocol error causing the session to be terminated.
如果任一LDP对等方不包括FT会话TLV LDP初始化消息，或者如果对等方之间的S和C位不匹配，则在此LDP会话期间不得使用LDP FT增强功能。在这些情况下，发送LDP对等方使用LDP FT增强必须被接收LDP对等方解释为导致会话终止的严重协议错误。
An LSR MAY present different FT/non-FT behavior on different TCP connections, even if those connections are successive instantiations of the LDP session between the same LDP peers.
LSR可能在不同的TCP连接上呈现不同的FT/非FT行为，即使这些连接是相同LDP对等方之间LDP会话的连续实例化。
The FT Session TLV on the LDP Initialization message carries the U-bit. If an LSR does not support any protection or recovery mechanisms, it will ignore this TLV. Since such partners also do not include the FT Session TLV, all LDP sessions to such LSRs will not use the LDP FT enhancements.
LDP初始化消息上的FT会话TLV携带U位。如果LSR不支持任何保护或恢复机制，它将忽略此TLV。由于此类合作伙伴也不包括FT会话TLV，因此此类LSR的所有LDP会话都不会使用LDP FT增强功能。
The rest of this document assumes that the LDP sessions under discussion are between LSRs that support the LDP FT enhancements, except where explicitly stated otherwise.
本文件其余部分假设讨论中的LDP会话是在支持LDP FT增强的LSR之间进行的，除非另有明确说明。
TCP connection failures may be detected and reported to the LDP component in a variety of ways. These should all be treated in the same way by the LDP component.
TCP连接故障可以通过多种方式检测并报告给LDP组件。LDP组件应以相同的方式处理这些问题。
- Indication from the management component that a TCP connection or underlying resource is no longer active.
- 管理组件指示TCP连接或基础资源不再处于活动状态。
- Notification from a hardware management component of an interface failure.
- 来自硬件管理组件的接口故障通知。
- Sockets keepalive timeout.
- 套接字保持有效超时。
- Sockets send failure.
- 套接字发送失败。
- New (incoming) Socket opened.
- 新（输入）插座已打开。
- LDP protocol timeout.
- LDP协议超时。
If the LDP FT enhancements are not in use on an LDP session, the action of the LDP peers on failure of the TCP connection is as specified in [RFC3036].
如果LDP FT增强功能未在LDP会话上使用，则LDP对等方在TCP连接失败时的操作如[RFC3036]所述。
All state information and resources associated with non-FT Labels MUST be released on the failure of the TCP connection, including deprogramming the non-FT Label from the switching hardware. This is equivalent to the behavior specified in [RFC3036].
TCP连接发生故障时，必须释放与非FT标签相关的所有状态信息和资源，包括从交换硬件中对非FT标签进行编程。这相当于[RFC3036]中指定的行为。
If the LDP FT enhancements are in use on an LDP session, both LDP peers SHOULD preserve state information and resources associated with FT Labels exchanged on the LDP session. Both LDP peers SHOULD use a timer to release the preserved state information and resources associated with FT-labels if the TCP connection is not restored within a reasonable period. The behavior when this timer expires is equivalent to the LDP session failure behavior described in [RFC3036].
如果LDP FT增强功能在LDP会话上使用，则两个LDP对等方应保留与LDP会话上交换的FT标签相关的状态信息和资源。如果TCP连接未在合理时间内恢复，则两个LDP对等方都应使用计时器释放保留的状态信息和与FT标签相关的资源。此计时器过期时的行为相当于[RFC3036]中描述的LDP会话失败行为。
The FT Reconnection Timeout each LDP peer intends to apply to the LDP session is carried in the FT Session TLV on the LDP Initialization messages. Both LDP peers MUST use the value that corresponds to the lesser timeout interval of the two proposed timeout values from the LDP Initialization exchange, where a value of zero is treated as positive infinity.
每个LDP对等方打算应用于LDP会话的FT重新连接超时在LDP初始化消息上的FT会话TLV中进行。两个LDP对等方必须使用对应于来自LDP初始化交换的两个提议超时值的较小超时间隔的值，其中零的值被视为正无穷大。
An LSR that implements the LDP FT enhancements SHOULD preserve the programming of the switching hardware across a failover. This ensures that data forwarding is unaffected by the state of the TCP connection between LSRs.
实现LDP FT增强功能的LSR应在故障切换过程中保留交换硬件的编程。这确保了数据转发不受LSR之间TCP连接状态的影响。
It is an integral part of FT failover processing in some hardware configurations that some data packets might be lost. If data loss is not acceptable to the applications using the MPLS network, the LDP FT enhancements described in this document SHOULD NOT be used.
在某些硬件配置中，某些数据包可能丢失是FT故障转移处理的一个组成部分。如果使用MPLS网络的应用程序不能接受数据丢失，则不应使用本文档中描述的LDP FT增强功能。
When a new TCP connection is established, the LDP peers MUST exchange LDP Initialization messages. When a new TCP connection is established after failure, the LDP peers MUST re-exchange LDP Initialization messages.
建立新的TCP连接时，LDP对等方必须交换LDP初始化消息。当失败后建立新的TCP连接时，LDP对等方必须重新交换LDP初始化消息。
If an LDP peer includes the FT Session TLV with the S bit set in the LDP Initialization message for the new instantiation of the LDP session, it MUST also set the FT Reconnect Flag according to whether it has been able to preserve label state. The FT Reconnect Flag is carried in the FT Session TLV.
如果LDP对等方包括FT会话TLV，并且在LDP初始化消息中为LDP会话的新实例化设置了S位，则它还必须根据其是否能够保持标签状态来设置FT重新连接标志。FT重新连接标志在FT会话TLV中携带。
If an LDP peer has preserved all state information for previous instantiations of the LDP session, then it SHOULD set the FT Reconnect Flag to 1 in the FT Session TLV. Otherwise, it MUST set the FT Reconnect Flag to 0.
如果LDP对等方保留了LDP会话之前实例化的所有状态信息，则应在FT会话TLV中将FT Reconnect标志设置为1。否则，它必须将FT Reconnect标志设置为0。
If either LDP peer sets the FT Reconnect Flag to 0, or omits the FT Session TLV, both LDP peers MUST release any state information and resources associated with the previous instantiation of the LDP session between the same LDP peers, including FT Label state and Addresses. This ensures that network resources are not permanently lost by one LSR if its LDP peer is forced to undergo a cold start.
如果任一LDP对等方将FT Reconnect标志设置为0，或省略FT会话TLV，则两个LDP对等方必须释放与相同LDP对等方之间的LDP会话的先前实例化相关的任何状态信息和资源，包括FT标签状态和地址。这确保了如果一个LSR的LDP对等机被迫进行冷启动，则该LSR不会永久丢失网络资源。
If an LDP peer changes any session parameters (for example, the label space bounds) from the previous instantiation, the nature of any preserved labels may have changed. In particular, previously allocated labels may now be out of range. For this reason, session reconnection MUST use the same parameters as were in use on the session before the failure. If an LDP peer notices that the parameters have been changed by the other peer, it SHOULD send a Notification message with the 'FT Session parameters changed' status code.
如果LDP对等方更改了先前实例化中的任何会话参数（例如，标签空间边界），则任何保留标签的性质都可能已更改。特别是，以前分配的标签现在可能超出范围。因此，会话重新连接必须使用与故障前会话中使用的参数相同的参数。如果LDP对等方注意到另一对等方已更改参数，则应发送带有“FT会话参数已更改”状态代码的通知消息。
If both LDP peers set the FT Reconnect Flag to 1, both LDP peers MUST use the procedures indicated in this document to complete any label operations on Sequence Numbered FT Labels that were interrupted by the LDP session failure.
如果两个LDP对等方都将FT Reconnect标志设置为1，则两个LDP对等方都必须使用本文档中所述的程序来完成因LDP会话失败而中断的序列号FT标签上的任何标签操作。
If an LDP peer receives an LDP Initialization message with the FT Reconnect Flag set before it sends its own Initialization message, but has retained no information about the previous version of the session, it MUST respond with an Initialization message with the FT Reconnect Flag clear. If an LDP peer receives an LDP Initialization message with the FT Reconnect Flag set in response to an Initialization message that it has sent with the FT Reconnect Flag clear, it MUST act as if no state was retained by either peer on the session.
如果LDP对等方在发送其自己的初始化消息之前接收到设置了FT Reconnect标志的LDP初始化消息，但未保留有关先前版本会话的任何信息，则必须使用清除FT Reconnect标志的初始化消息进行响应。如果LDP对等方接收到设置了FT Reconnect标志的LDP初始化消息，以响应其发送的FT Reconnect标志为clear的初始化消息，则其行为必须如同会话中任一对等方未保留任何状态一样。
Label operations on Sequence Numbered FT Labels are made Fault Tolerant by providing acknowledgement of all LDP messages that affect Sequence Numbered FT Labels. Acknowledgements are achieved by means of sequence numbers on these LDP messages.
通过确认影响序列号FT标签的所有LDP消息，序列号FT标签上的标签操作具有容错性。通过这些LDP消息上的序列号实现确认。
The message exchanges used to achieve acknowledgement of label operations and the procedures used to complete interrupted label operations are detailed in section 5, "FT Operations".
第5节“FT操作”详细说明了用于确认标签操作的消息交换以及用于完成中断标签操作的程序。
Using these acknowledgements and procedures, it is not necessary for LDP peers to perform a complete re-synchronization of state for all Sequence Numbered FT Labels, either on re-connection of the LDP session between the LDP peers or on a timed basis.
使用这些确认和过程，LDP对等方不必在LDP对等方之间的LDP会话重新连接时或在定时的基础上对所有序列编号的FT标签执行完全的状态重新同步。
Check-pointing is a useful feature that allows nodes to reduce the amount of processing that they need to do to acknowledge LDP messages. The C bit in the FT Session TLV is used to indicate that check-pointing is supported.
检查点是一种有用的功能，它允许节点减少确认LDP消息所需的处理量。FT会话TLV中的C位用于指示支持检查点。
Under the normal operation on Sequence Numbered FT Labels, acknowledgments may be deferred during normal processing and only sent periodically. Check-pointing may be used to flush acknowledgement from a peer by including a sequence number on a Keepalive message requesting acknowledgement of that message and all previous messages. In this case, all Sequence Numbered FT Labels are Check-Pointable FT Labels.
在序列号FT标签的正常操作下，在正常处理过程中，确认可能会延迟，并且只能定期发送。通过在请求确认该消息和所有先前消息的Keepalive消息上包括序列号，检查点可用于刷新来自对等方的确认。在这种情况下，所有序列编号的FT标签都是可检查点的FT标签。
If the S bit is not agreed upon, check-pointing may still be used. In this case it is used to acknowledge all messages exchanged between the peers, and all labels are Check-Pointable FT Labels.
如果未就S位达成一致，则仍可使用检查点。在这种情况下，它用于确认对等方之间交换的所有消息，并且所有标签都是可检查点的FT标签。
This offers an approach where acknowledgements need not be sent to every message or even frequently, but are only sent as check-points in response to requests carried on Keepalive messages. Such an approach may be considered optimal in systems that do not show a high degree of change over time (such as targeted LDP sessions) and that are prepared to risk loss of state for the most recent LDP exchanges. More dynamic systems (such as LDP discovery sessions) are more likely to want to acknowledge state changes more frequently so that the maximum amount of state can be preserved over a failure.
这提供了一种方法，在这种方法中，确认不需要发送到每条消息，甚至不需要频繁发送，而只作为检查点发送，以响应Keepalive消息中的请求。在不随时间发生高度变化的系统（如目标LDP会话）中，这种方法可能被认为是最佳的，并且准备为最近的LDP交换冒失去状态的风险。更具动态性的系统（如LDP发现会话）更可能希望更频繁地确认状态更改，以便在故障期间保留最大数量的状态。
Note that an important consideration of this document is that nodes acknowledging messages on a one-for-one basis, nodes deferring acknowledgements, and nodes relying on check-pointing, should all interoperate seamlessly and without protocol negotiation beyond session initialization.
请注意，本文档的一个重要考虑事项是，在一对一的基础上确认消息的节点、延迟确认的节点以及依赖检查点的节点都应该无缝地互操作，并且在会话初始化之后不需要协议协商。
Further discussion of this feature is provided in section 5, "FT Operations".
第5节“FT操作”中对该功能进行了进一步讨论。
A feature that builds on check-pointing is graceful termination.
建立在检查点基础上的功能是优雅终止。
In some cases, such as controlled failover or software upgrade, it is possible for a node to know in advance that it is going to terminate its session with a peer.
在某些情况下，例如受控故障切换或软件升级，节点可能提前知道它将终止与对等方的会话。
In these cases the node that intends terminating the session can flush acknowledgement using a check-point request as described above. The sender SHOULD not send further label or address-related messages after requesting shutdown check-pointing in order to preserve the integrity of its saved state.
在这些情况下，打算终止会话的节点可以使用如上所述的检查点请求刷新确认。在请求关机检查点后，发件人不应再发送与标签或地址相关的消息，以保持其保存状态的完整性。
This, however, only provides for acknowledgement in one direction, and the node that is being terminated also requires verification that it has secured all state sent by its peer. This is achieved by a three-way hand shake of the check-point which is requested by an additional TLV (the Cork TLV) in the Keepalive message.
然而，这仅在一个方向上提供确认，并且被终止的节点还需要验证其已保护其对等方发送的所有状态。这是由Keepalive消息中的附加TLV（软木TLV）请求的检查点的三向握手来实现的。
Further discussion of this feature is provided in section 5, "FT Operations".
第5节“FT操作”中对该功能进行了进一步讨论。
When an LDP peer is unable to satisfy a Label Request message because it has no more available labels, it sends a Notification message carrying the status code 'No label resources'. This warns the requesting LDP peer that subsequent Label Request messages are also likely to fail for the same reason. This message does not need to be acknowledged for FT purposes since Label Request messages sent after session recovery will receive the same response. However, the LDP peer that receives a 'No label resources' Notification stops sending Label Request messages until it receives a 'Label resources available' Notification message. Since this unsolicited Notification might get lost during session failure, it may be protected using the procedures described in this document.
当LDP对等方由于没有更多可用标签而无法满足标签请求消息时，它会发送一条带有状态码“no Label resources”的通知消息。这会警告发出请求的LDP对等方，随后的标签请求消息也可能由于同样的原因失败。由于会话恢复后发送的标签请求消息将收到相同的响应，因此不需要为FT目的确认此消息。但是，接收到“无标签资源”通知的LDP对等方停止发送标签请求消息，直到收到“标签资源可用”通知消息。由于此未经请求的通知可能在会话失败期间丢失，因此可以使用本文档中描述的过程对其进行保护。
An alternative approach allows that an implementation may always assume that labels are available when a session is re-established. In this case, it is possible that it may throw away the 'No label resources' information from the previous incarnation of the session and may send a batch of LDP messages on session re-establishment that will fail and that it could have known would fail.
另一种方法允许实现在重新建立会话时始终假定标签可用。在这种情况下，它可能会丢弃会话的前一个版本中的“无标签资源”信息，并可能在会话重新建立时发送一批LDP消息，这些消息将失败，并且它可能知道会失败。
Note that the sender of a 'Label resources available' Notification message may choose whether to add a sequence number requesting acknowledgement. Conversely, the receiver of 'Label resources available' Notification message may choose to acknowledge the message without actually saving any state.
请注意，“标签资源可用”通知消息的发送方可以选择是否添加请求确认的序列号。相反，“标签资源可用”通知消息的接收者可以选择确认消息而不实际保存任何状态。
This is an implementation choice made possible by making the FT parameters on the Notification message optional. Implementations will interoperate fully if they take opposite approaches, but additional LDP messages may be sent unnecessarily on session recovery.
这是通过使通知消息上的FT参数可选而实现的选择。如果采用相反的方法，实现将完全互操作，但在会话恢复时可能会不必要地发送额外的LDP消息。
The procedures described in this document can be applied to LSPs that are tunnels and to LSPs that are carried by tunnels. Recall that tunneled LSPs are managed by a single LDP session that runs end to end, while the tunnel is managed by a different LDP session for each hop along the path. Nevertheless, a break in one of the sessions that manages the tunnel is likely to correspond with a break in the session that manages the tunneled LSP. This is certainly the case when the LDP exchanges share a failed link, but need not be the case if the LDP messages have been routed along a path that is different from that of the tunnel, or if the failure in the tunnel is caused by an LDP software failure at a transit LSR.
本文件中描述的程序可适用于作为隧道的LSP和由隧道运输的LSP。回想一下，隧道LSP由端到端运行的单个LDP会话管理，而隧道则由路径上每个跃点的不同LDP会话管理。然而，管理隧道的其中一个会话中的中断可能与管理隧道LSP的会话中的中断相对应。当LDP交换机共享故障链路时，当然是这种情况，但如果LDP消息已沿着与隧道路径不同的路径路由，或者如果隧道中的故障是由传输LSR处的LDP软件故障引起的，则不必是这种情况。
In order that the forwarding path of a tunneled LSP be preserved, the forwarding path of the tunnel itself must be preserved. This means that the tunnel must not be torn down if there is any session failure along its path. To achieve this, the label exchanges between each pair of LDP peers along the path of the tunnel must use one of the procedures in this document or in [RFC3478].
为了保留隧道LSP的转发路径，必须保留隧道本身的转发路径。这意味着，如果在隧道路径上出现任何会话失败，则不得拆除隧道。为了实现这一点，沿隧道路径的每对LDP对等点之间的标签交换必须使用本文件或[RFC3478]中的程序之一。
It is perfectly acceptable to mix the restart procedures used for the tunnel and the tunneled LSP. For example, the tunnel could be set up using just check-pointing because it is a stable LSP, but the tunneled LSPs might use full FT procedures so that they can recover active state.
混合使用隧道和隧道LSP的重启程序是完全可以接受的。例如，可以仅使用检查点设置隧道，因为它是一个稳定的LSP，但隧道LSP可能使用完整的FT过程，以便它们可以恢复活动状态。
Lastly, it is permissible to carry tunneled LSPs that do not have FT protection in an LSP that has FT protection.
最后，允许在具有FT保护的LSP中携带不具有FT保护的隧道LSP。
Once an FT LDP session has been established, using the S bit in the FT Session TLV on the Session Initialization message as described in section 4.1, "Establishing an FT LDP Session", both LDP peers MUST apply the procedures described in this section for FT LDP message exchanges.
一旦建立了FT-LDP会话，如第4.1节“建立FT-LDP会话”中所述，在会话初始化消息上使用FT-LDP会话TLV中的S位，两个LDP对等方必须为FT-LDP消息交换应用本节中所述的程序。
If the LDP session has been negotiated to not use the LDP FT enhancements, these procedures MUST NOT be used.
如果LDP会话已协商不使用LDP FT增强功能，则不得使用这些程序。
A label is identified as being a Sequence Numbered FT Label if the initial Label Request or Label Mapping message relating to that label carries the FT Protection TLV.
如果与标签相关的初始标签请求或标签映射消息携带FT保护TLV，则标签被标识为序列号FT标签。
It is a valid implementation option to flag all labels as Sequence Numbered FT Labels. Indeed this may be a preferred option for implementations wishing to use Keepalive messages carrying the FT Protection TLV to achieve periodic saves of the complete label forwarding state.
将所有标签标记为序列编号的FT标签是一个有效的实现选项。实际上，对于希望使用携带FT保护TLV的Keepalive消息来实现完整标签转发状态的周期性保存的实现来说，这可能是一个首选选项。
If a label is a Sequence Numbered FT Label, all LDP messages affecting that label MUST carry the FT Protection TLV so that the state of the label can be recovered after a failure of the LDP session.
如果标签是序列号的FT标签，则影响该标签的所有LDP消息必须携带FT保护TLV，以便在LDP会话失败后恢复标签的状态。
A further valid option is for no labels to be Sequence Numbered FT Labels. In this case, check-pointing using the Keepalive message applies to all messages exchanged on the session.
另一个有效选项是无标签为序列号FT标签。在这种情况下，使用Keepalive消息的检查点适用于会话上交换的所有消息。
The scope of the FT/non-FT status of a label is limited to the LDP message exchanges between a pair of LDP peers.
标签的FT/非FT状态的范围限于一对LDP对等点之间的LDP消息交换。
In Ordered Control, when the message is forwarded downstream or upstream, the TLV may be present or absent according to the requirements of the LSR sending the message.
在有序控制中，当消息被转发到下游或上游时，根据发送消息的LSR的要求，TLV可能存在或不存在。
If a platform-wide label space is used for FT Labels, an FT Label value MUST NOT be reused until all LDP FT peers to which the label was passed have acknowledged the withdrawal of the FT Label, either by an explicit LABEL WITHDRAW/LABEL RELEASE, exchange or implicitly if the LDP session is reconnected after failure but without the FT Reconnect Flag set. In the event that a session is not re-established within the Reconnection Timeout, a label MAY become available for re-use if it is not still in use on some other session.
如果平台范围的标签空间用于FT标签，则在标签传递到的所有LDP FT对等方通过明确的标签撤回/标签释放确认FT标签撤回之前，不得重复使用FT标签值，如果LDP会话在失败后重新连接，但未设置FT Reconnect标志，则进行交换或隐式交换。如果在重新连接超时时间内未重新建立会话，则如果某个标签在其他会话上未继续使用，则该标签可以重新使用。
If an LDP session uses the LDP FT enhancements, both LDP peers MUST secure Address and Address Withdraw messages using FT Operation ACKs, as described below. This avoids any ambiguity over whether an Address is still valid after the LDP session is reconnected.
如果LDP会话使用LDP FT增强功能，则两个LDP对等方必须使用FT操作确认来保护地址和地址撤回消息，如下所述。这避免了在重新连接LDP会话后地址是否仍然有效的任何歧义。
If an LSR determines that an Address message it sent on a previous instantiation of a recovered LDP session is no longer valid, it MUST explicitly issue an Address Withdraw for that address when the session is reconnected.
如果LSR确定它在恢复的LDP会话的前一个实例化上发送的地址消息不再有效，则它必须在会话重新连接时为该地址显式发出地址撤消。
If the FT Reconnect Flag is not set by both LDP peers upon reconnection of an LDP session (i.e. state has not been preserved), both LDP peers MUST consider all Addresses to have been withdrawn. The LDP peers SHOULD issue new Address messages for all their valid addresses, as specified in [RFC3036].
如果在重新连接LDP会话（即尚未保存状态）时，两个LDP对等点没有设置FT重新连接标志，那么两个LDP对等点都必须考虑所有的地址已经撤回。LDP对等方应按照[RFC3036]中的规定，为其所有有效地址发出新地址消息。
In LDP, it is possible that a downstream LSR may not have labels available to respond to a Label Request. In this case, as specified in RFC 3036, the downstream LSR must respond with a Notification - No Label Resources message. The upstream LSR then suspends asking for new labels until it receives a Notification - Label Resources Available message from the downstream LSR.
在LDP中，下游LSR可能没有可用于响应标签请求的标签。在这种情况下，如RFC 3036中所述，下游LSR必须响应通知-无标签资源消息。然后，上游LSR暂停请求新标签，直到收到来自下游LSR的通知-Label Resources Available消息。
When the FT extensions are used on a session, implementations may choose whether or not to secure the label resource state of their peer. This choice impacts the number of LDP messages that will be incorrectly routed to a peer with depleted resources on session re-establishment, but does not otherwise impact interoperability.
在会话上使用FT扩展时，实现可以选择是否保护其对等方的标签资源状态。此选择会影响在会话重建时错误路由到资源耗尽的对等方的LDP消息数量，但不会影响互操作性。
For full preservation of state:
为了充分保护国家：
- The downstream LSR must preserve the label availability state across a failover so that it remembers to send Notification - Label Resources Available when the resources become available.
- 下游LSR必须在故障转移过程中保持标签可用性状态，以便在资源可用时记住发送通知-标签可用资源。
- The upstream LSR must recall the label availability state across failover so that it can optimize not sending Label Requests when it recovers.
- 上游LSR必须跨故障转移调用标签可用性状态，以便在恢复时优化不发送标签请求。
- The downstream LSR must use sequence numbers on Notification - Label Resources Available so that it can check that LSR A has received the message and clear its secured state, or resend the message if LSR A recovers without having received it.
- 下游LSR必须在可用的通知标签资源上使用序列号，以便它可以检查LSR A是否已收到消息并清除其安全状态，或者如果LSR A在未收到消息的情况下恢复，则重新发送消息。
However, the following options also exist:
但是，也存在以下选项：
- The downstream LSR may choose to not include a sequence number on Notification - Label Resources Available. This means that on session re-establishment it does not know what its peer thinks the LSR's resource state is, because the Notification may or may not have been delivered. Such an implementation MUST begin recovered sessions by sending an additional Notification - Label Resources Available to reset its peer.
- 下游LSR可以选择在可用的通知标签资源上不包括序列号。这意味着在会话重新建立时，它不知道其对等方认为LSR的资源状态是什么，因为通知可能已传递，也可能尚未传递。这样的实现必须通过发送一个额外的通知标签资源来重置其对等服务器，从而开始恢复的会话。
- The upstream node may choose not to secure information about its peer's resource state. It would acknowledge a Notification - Label Resources Available, but would not save the information. Such an implementation MUST assume that its peer's resource state has been reset to Label Resources Available when the session is re-established.
- 上游节点可以选择不保护关于其对等方的资源状态的信息。它将确认可用的通知标签资源，但不会保存信息。这样的实现必须假设其对等方的资源状态已重置，以在会话重新建立时标记可用资源。
If the FT Reconnect Flag is not set by both LDP peers upon reconnection of an LDP session (i.e. state has not been preserved), both LDP peers MUST consider the label availability state to have been reset as if the session had been set up for the first time.
如果在重新连接LDP会话（即尚未保存状态）时，两个LDP对等点没有设置FT重新连接标志，那么两个LDP对等体都必须认为标签可用性状态已经被重置，就好像第一次建立会话一样。
Handshaking of FT LDP messages is achieved by use of ACKs. Correlation between the original message and the ACK is by means of the FT Sequence Number contained in the FT Protection TLV, and passed back in the FT ACK TLV. The FT ACK TLV may be carried on any LDP message that is sent on the TCP connection between LDP peers.
FT LDP消息的握手是通过使用ACK实现的。原始消息和ACK之间的相关性通过FT保护TLV中包含的FT序列号实现，并在FT ACK TLV中传回。FT-ACK TLV可以携带在LDP对等方之间的TCP连接上发送的任何LDP消息上。
An LDP peer maintains a separate FT sequence number for each LDP session in which it participates. The FT Sequence number is incremented by one for each FT LDP message (i.e. containing the FT Protection TLV) issued by this LSR on the FT LDP session with which the FT sequence number is associated.
LDP对等方为其参与的每个LDP会话维护一个单独的FT序列号。对于该LSR在与FT序列号相关联的FT LDP会话上发出的每个FT LDP消息（即，包含FT保护TLV），FT序列号增加1。
When an LDP peer receives a message containing the FT Protection TLV, it MUST take steps to secure this message (or the state information derived from processing the message). Once the message is secured, it MUST be ACKed. However, there is no requirement on the LSR to send this ACK immediately.
当LDP对等方收到包含FT保护TLV的消息时，它必须采取措施保护该消息（或从处理该消息中获得的状态信息）。一旦消息得到保护，就必须对其进行确认。但是，LSR不要求立即发送此ACK。
ACKs may be accumulated to reduce the message flow between LDP peers. For example, if an LSR received FT LDP messages with sequence numbers 1, 2, 3, 4, it could send a single ACK with sequence number 4 to ACK receipt, securing of all these messages. There is no protocol reason why the number of ACKs accumulated, or the time for which an ACK is deferred, should not be allowed to become relatively large.
可以累积ack以减少LDP对等方之间的消息流。例如，如果LSR接收到序列号为1、2、3、4的FT LDP消息，它可以向ACK接收发送序列号为4的单个ACK，以保护所有这些消息的安全。累积的ACK数量或ACK延迟的时间不应变得相对较大，这没有协议原因。
ACKs MUST NOT be sent out of sequence, as this is incompatible with the use of accumulated ACKs. Duplicate ACKs (that is two successive messages that acknowledge the same sequence number) are acceptable.
ACK不能按顺序发送，因为这与累计ACK的使用不兼容。重复确认（即确认相同序列号的两条连续消息）是可接受的。
If an LDP peer discovers that its sequence number space for a specific session is full of un-acknowledged sequence numbers (because its partner on the session has not acknowledged them in a timely way), it cannot allocate a new sequence number for any further FT LPD message. It SHOULD send a Notification message with the status code 'FT Seq Numbers Exhausted'.
如果LDP对等方发现其特定会话的序列号空间充满了未确认的序列号（因为其会话伙伴未及时确认），则无法为任何进一步的FT LPD消息分配新序列号。它应该发送一条状态代码为“FT Seq Numbers EXTENDED”的通知消息。
If the LDP FT enhancements are in use on an LDP session, each LDP peer SHOULD NOT release the state information and resources associated with FT Labels exchanged on that LDP session when the TCP connection fails. This is contrary to [RFC3036], but allows label operations on FT Labels to be completed after re-connection of the TCP connection.
如果LDP FT增强在LDP会话上使用，则当TCP连接失败时，每个LDP对等方不应释放与该LDP会话上交换的FT标签相关的状态信息和资源。这与[RFC3036]相反，但允许在重新连接TCP连接后完成FT标签上的标签操作。
Both LDP peers on an LDP session that is using the LDP FT enhancements SHOULD preserve the state information and resources they hold for that LDP session as described below.
使用LDP FT增强功能的LDP会话上的两个LDP对等方应保存其为该LDP会话持有的状态信息和资源，如下所述。
- An upstream LDP peer SHOULD release the resources (in particular bandwidth) associated with a Sequence Numbered FT Label when it initiates a Label Release or Label Abort message for the label. The upstream LDP peer MUST preserve state information for the Sequence Numbered FT Label, even if it releases the resources associated with the label, as it may need to reissue the label operation if the TCP connection is interrupted.
- 上游LDP对等方在为标签启动标签释放或标签中止消息时，应释放与序列号FT标签相关联的资源（尤其是带宽）。上游LDP对等方必须保留序列号FT标签的状态信息，即使它释放与标签相关的资源，因为如果TCP连接中断，它可能需要重新发出标签操作。
- An upstream LDP peer MUST release the state information and resources associated with a Sequence Numbered FT Label when it receives an acknowledgement to a Label Release or Label Abort message that it sent for the label, or when it sends a Label Release message in response to a Label Withdraw message received from the downstream LDP peer.
- 当上游LDP对等方接收到其为标签发送的标签释放或标签中止消息的确认时，或者当其发送标签释放消息以响应从下游LDP对等方接收的标签撤回消息时，必须释放与序列号FT标签相关联的状态信息和资源。
- A downstream LDP peer SHOULD NOT release the resources associated with a Sequence Numbered FT Label when it sends a Label Withdraw message for the label as it has not yet received confirmation that the upstream LDP peer has ceased to send data using the label. The downstream LDP peer MUST NOT release the state information it holds for the label as it may yet have to reissue the label operation if the TCP connection is interrupted.
- 下游LDP对等方在发送标签的标签撤销消息时不应释放与序列号FT标签相关联的资源，因为它尚未收到上游LDP对等方已停止使用标签发送数据的确认。下游LDP对等方不得释放其持有的标签状态信息，因为如果TCP连接中断，它可能还必须重新发出标签操作。
- A downstream LDP peer MUST release the resources and state information associated with a Sequence Numbered FT Label when it receives an acknowledgement to a Label Withdraw message for the label.
- 下游LDP对等方在接收到标签撤销消息的确认时，必须释放与序列号FT标签相关联的资源和状态信息。
- When the FT Reconnection Timeout expires, an LSR SHOULD release all state information and resources from previous instantiations of the (permanently) failed LDP session.
- 当FT重新连接超时过期时，LSR应释放（永久）失败的LDP会话的先前实例化中的所有状态信息和资源。
- Either LDP peer MAY elect to release state information based on its internal knowledge of the loss of integrity of the state information or an inability to pend (or queue) LDP operations (as described in section 5.4.1, "LDP Operations During TCP Failure") during a TCP failure. That is, the peer is not required to wait for the duration of the FT Reconnection Timeout before releasing state; the timeout provides an upper limit on the persistence of state. However, in the event that a peer releases state before the expiration of the Reconnection Timeout, it MUST NOT re-use any label that was in use on the session until the Reconnection Timeout has expired.
- 任一LDP对等方可根据其内部关于状态信息完整性丢失或无法在TCP故障期间挂起（或排队）LDP操作（如第5.4.1节“TCP故障期间的LDP操作”所述）的知识选择释放状态信息。即，对等方在释放状态之前不需要等待FT重新连接超时的持续时间；超时提供了状态持久性的上限。但是，如果对等方在重新连接超时过期之前释放状态，则在重新连接超时过期之前，对等方不得重新使用会话中使用的任何标签。
- When an LSR receives a Status TLV with the E-bit set in the status code, which causes it to close the TCP connection, the LSR MUST release all state information and resources associated with the session. This behavior is mandated because it is impossible for the LSR to predict the precise state and future behavior of the partner LSR that set the E-bit without knowledge of the implementation of that partner LSR.
- 当LSR接收到状态代码中设置了E位的状态TLV，导致其关闭TCP连接时，LSR必须释放与会话相关的所有状态信息和资源。这种行为是强制性的，因为在不知道合作伙伴LSR的实现的情况下，LSR不可能预测设置E位的合作伙伴LSR的精确状态和未来行为。
Note that the 'Temporary Shutdown' status code does not have the E-bit set, and MAY be used during maintenance or upgrade operations to indicate that the LSR intends to preserve state across a closure and re-establishment of the TCP session.
请注意，“临时关闭”状态代码未设置E位，可在维护或升级操作期间使用，以指示LSR打算在TCP会话关闭和重新建立期间保持状态。
- If an LSR determines that it must release state for any single FT Label during a failure of the TCP connection on which that label was exchanged, it MUST release all state for all labels on the LDP session.
- 如果LSR确定在交换标签的TCP连接故障期间必须释放任何单个FT标签的状态，则必须释放LDP会话上所有标签的所有状态。
The release of state information and resources associated with non-FT labels is as described in [RFC3036].
与非FT标签相关的状态信息和资源的发布如[RFC3036]所述。
Note that a Label Release and the acknowledgement to a Label Withdraw may be received by a downstream LSR in any order. The downstream LSR MAY release its resources upon receipt of the first message and MUST release its resources upon receipt of the second message.
注意，下游LSR可以任何顺序接收标签发布和标签撤回确认。下游LSR可以在接收到第一消息时释放其资源，并且必须在接收到第二消息时释放其资源。
When an LSR discovers or is notified of a TCP connection failure it SHOULD start an FT Reconnection Timer to allow a period for re-connection of the TCP connection between the LDP peers.
当LSR发现TCP连接故障或收到TCP连接故障通知时，它应启动FT重新连接计时器，以允许LDP对等点之间的TCP连接重新连接一段时间。
The RECOMMENDED default value for this timer is 5 seconds. During this time, failure must be detected and reported, new hardware may need to be activated, software state must be audited, and a new TCP session must be set up.
此计时器的建议默认值为5秒。在此期间，必须检测并报告故障，可能需要激活新硬件，必须审核软件状态，并且必须设置新的TCP会话。
Once the TCP connection between LDP peers has failed, the active LSR SHOULD attempt to re-establish the TCP connection. The mechanisms, timers and retry counts to re-establish the TCP connection are an implementation choice. It is RECOMMENDED that any attempt to re-establish the connection should take into account the failover processing necessary on the peer LSR, the nature of the network between the LDP peers, and the FT Reconnection Timeout chosen on the previous instantiation of the TCP connection (if any).
LDP对等点之间的TCP连接失败后，活动LSR应尝试重新建立TCP连接。重新建立TCP连接的机制、计时器和重试次数是一种实现选择。建议重新建立连接的任何尝试都应考虑对等LSR上必要的故障转移处理、LDP对等之间的网络性质以及在TCP连接的上一次实例化（如果有）上选择的FT重新连接超时。
If the TCP connection cannot be re-established within the FT Reconnection Timeout period, the LSR detecting this timeout SHOULD release all state preserved for the failed LDP session. If the TCP connection is subsequently re-established (for example, after a further Hello exchange to set up a new LDP session), the LSR MUST set the FT Reconnect Flag to 0 if it released the preserved state information on this timeout event.
如果无法在FT重新连接超时期间重新建立TCP连接，则检测到此超时的LSR应释放为失败的LDP会话保留的所有状态。如果随后重新建立TCP连接（例如，在进一步的Hello交换以建立新的LDP会话之后），如果LSR释放此超时事件的保留状态信息，则必须将FT Reconnect标志设置为0。
If the TCP connection is successfully re-established within the FT Reconnection Timeout, both peers MUST re-issue LDP operations that were interrupted by (that is, un-acknowledged as a result of) the TCP connection failure. This procedure is described in section 5.5, "FT Procedure After TCP Re-connection".
如果在FT重新连接超时时间内成功重新建立TCP连接，则两个对等方必须重新发出因TCP连接故障而中断（即未确认）的LDP操作。第5.5节“TCP重新连接后的FT程序”中描述了该程序。
The Hold Timer for an FT LDP Session (see [RFC3036] section 2.5.5) SHOULD be ignored while the FT Reconnection Timer is running. The hold timer SHOULD be restarted when the TCP connection is re-established.
当FT重新连接计时器运行时，应忽略FT LDP会话的保持计时器（参见[RFC3036]第2.5.5节）。重新建立TCP连接时，应重新启动保持计时器。
When the LDP FT enhancements are in use for an LDP session, it is possible for an LSR to determine that it needs to send an LDP message to an LDP peer, but that the TCP connection to that peer is currently down. These label operations affect the state of FT Labels preserved for the failed TCP connection, so it is important that the state changes are passed to the LDP peer when the TCP connection is restored.
当LDP FT增强用于LDP会话时，LSR可以确定它需要向LDP对等方发送LDP消息，但到该对等方的TCP连接当前已断开。这些标签操作会影响为失败的TCP连接保留的FT标签的状态，因此在恢复TCP连接时，将状态更改传递给LDP对等方非常重要。
If an LSR determines that it needs to issue a new FT LDP operation to an LDP peer to which the TCP connection is currently failed, it MUST pend the operation (e.g. on a queue) and complete that operation with the LDP peer when the TCP connection is restored, unless the label operation is overridden by a subsequent additional operation during the TCP connection failure (see section 5.5, "FT Procedure After TCP Re-connection").
如果LSR确定需要向TCP连接当前失败的LDP对等方发出新的FT LDP操作，则必须挂起该操作（例如在队列上），并在恢复TCP连接时与LDP对等方完成该操作，除非在TCP连接故障期间，标签操作被后续附加操作覆盖（参见第5.5节“TCP重新连接后的FT程序”）。
If, during TCP Failure, an LSR determines that it cannot pend an operation which it cannot simply fail (for example, a Label Withdraw, Release or Abort operation), it MUST NOT attempt to re-establish the previous LDP session. The LSR MUST behave as if the Reconnection Timer expired and release all state information with respect to the LDP peer. An LSR may be unable (or unwilling) to pend operations; for instance, if a major routing transition occurred while TCP was inoperable between LDP peers, it might result in excessively large numbers of FT LDP Operations. An LSR that releases state before the expiration of the Reconnection Timeout MUST NOT re-use any label that was in use on the session until the Reconnection Timeout has expired.
如果在TCP失败期间，LSR确定它不能挂起不能简单失败的操作（例如，标签撤消、释放或中止操作），则它不得尝试重新建立以前的LDP会话。LSR必须表现为重新连接计时器已过期，并释放LDP对等方的所有状态信息。LSR可能无法（或不愿意）暂停运营；例如，如果在LDP对等方之间TCP不可用时发生主要路由转换，则可能会导致FT LDP操作数量过多。在重新连接超时过期之前释放状态的LSR在重新连接超时过期之前不得重新使用会话中使用的任何标签。
In ordered operation, received FT LDP operations that cannot be correctly forwarded because of a TCP connection failure MAY be processed immediately (provided sufficient state is kept to forward the label operation) or pended for processing when the onward TCP connection is restored and the operation can be correctly forwarded upstream or downstream. Operations on existing FT Labels SHOULD NOT be failed during TCP session failure.
在有序操作中，由于TCP连接故障而无法正确转发的收到的FT LDP操作可以立即处理（前提是保持足够的状态转发标签操作）或在恢复前向TCP连接且操作可以正确地向上游或下游转发时等待处理。在TCP会话失败期间，对现有FT标签的操作不应失败。
It is RECOMMENDED that Label Request operations for new FT Labels not be pended awaiting the re-establishment of TCP connection that is awaiting recovery at the time the LSR determines that it needs to issue the Label Request message. Instead, such Label Request operations SHOULD be failed and, if necessary, a notification message containing the 'No LDP Session' status code sent upstream.
建议在LSR确定需要发出标签请求消息时，在等待恢复的TCP连接重新建立之前，不要挂起新FT标签的标签请求操作。相反，这样的标签请求操作应该失败，如有必要，向上游发送包含“无LDP会话”状态码的通知消息。
Label Requests for new non-FT Labels MUST be rejected during TCP connection failure, as specified in [RFC3036].
按照[RFC3036]中的规定，在TCP连接失败期间，必须拒绝新非FT标签的标签请求。
The FT operation handshaking described above means that all state changes for Sequence Numbered FT Labels and Address messages are confirmed or reproducible at each LSR.
上述FT操作握手意味着序列号FT标签和地址消息的所有状态变化在每个LSR处被确认或再现。
If the TCP connection between LDP peers fails but is re-connected within the FT Reconnection Timeout, and both LSRs have indicated they will be re-establishing the previous LDP session, both LDP peers on the connection MUST complete any label operations for Sequence Numbered FT Labels that were interrupted by the failure and re-connection of the TCP connection.
如果LDP对等点之间的TCP连接失败，但在FT重新连接超时内重新连接，并且两个LSR都表示将重新建立上一个LDP会话，连接上的两个LDP对等方必须完成因TCP连接故障和重新连接而中断的序列号FT标签的任何标签操作。
The procedures for FT Reconnection Timeout MAY have been invoked as a result of either LDP peer being unable (or unwilling) to pend operations which occurred during the TCP Failure (as described in section 5.4.1, "LDP Operations During TCP Failure").
FT重新连接超时程序可能是由于LDP对等方无法（或不愿）挂起TCP故障期间发生的操作（如第5.4.1节“TCP故障期间的LDP操作”所述）而调用的。
If, for any reason, an LSR has been unable to pend operations with respect to an LDP peer, as described in section 5.4.1, "LDP Operations During TCP Failure", the LSR MUST set the FT Reconnect Flag to 0 on re-connection to that LDP peer indicating that no FT state has been preserved.
如第5.4.1节“TCP故障期间的LDP操作”所述，如果出于任何原因，LSR无法挂起LDP对等机的操作，则LSR必须在重新连接到该LDP对等机时将FT Reconnect标志设置为0，以指示未保留FT状态。
Label operations are completed using the following procedure.
使用以下步骤完成标签操作。
Upon restoration of the TCP connection between LDP peers, any LDP messages for Sequence Numbered FT Labels that were lost because of the TCP connection failure are re-issued. The LDP peer that receives a re-issued message processes the message as if received for the first time.
在恢复LDP对等点之间的TCP连接后，将重新发出因TCP连接故障而丢失的序列号FT标签的所有LDP消息。接收到重新发布的消息的LDP对等方处理该消息，如同第一次接收到该消息一样。
"Net-zero" combinations of messages need not be re-issued after re-establishment of the TCP connection between LDP peers. This leads to the following rules for re-issuing messages that are not ACKed by the LDP peer on the LDP Initialization message exchange after re-connection of the TCP session.
在LDP对等点之间重新建立TCP连接后，无需重新发布消息的“净零”组合。这将导致在重新连接TCP会话后，在LDP初始化消息交换上重新发出LDP对等方未确认的消息的以下规则。
- A Label Request message MUST be re-issued unless a Label Abort would be re-issued for the same Sequence Numbered FT Label.
- 必须重新发出标签请求消息，除非为相同序列号的FT标签重新发出标签中止。
- A Label Mapping message MUST be re-issued unless a Label Withdraw message would be re-issued for the same Sequence Numbered FT Label.
- 必须重新发布标签映射消息，除非为相同序列号的FT标签重新发布标签撤销消息。
- All other messages on the LDP session that were sent and carried the FT Protection TLV MUST be re-issued if an acknowledgement was not previously been received.
- 如果之前未收到确认，则必须重新发布LDP会话上发送并承载FT保护TLV的所有其他消息。
Any FT Label operations that were pended (see section 5.4.1, "LDP Operations During TCP Failure") during the TCP connection failure MUST also be issued upon re-establishment of the LDP session, except where they form part of a "net-zero" combination of messages according to the above rules.
在TCP连接故障期间挂起的任何FT标签操作（参见第5.4.1节“TCP故障期间的LDP操作”）也必须在重新建立LDP会话时发出，除非它们根据上述规则构成消息“净零”组合的一部分。
The determination of "net-zero" FT Label operations according to the above rules MAY be performed on pended messages prior to the re-establishment of the TCP connection in order to optimize the use of queue resources. Messages that were sent to the LDP peer before the TCP connection failure, or pended messages that were paired with them, MUST NOT be subject to such optimization until an FT ACK TLV is received from the LDP peer. This ACK allows the LSR to identify which messages were received by the LDP peer prior to the TCP connection failure.
根据上述规则的“净零”FT标签操作的确定可以在重新建立TCP连接之前对挂起的消息执行，以便优化队列资源的使用。在TCP连接失败之前发送到LDP对等方的消息，或与其配对的挂起消息，在从LDP对等方接收到FT ACK TLV之前，不得进行此类优化。此ACK允许LSR识别在TCP连接失败之前LDP对等方接收的消息。
Check-Pointing can be selected independently from the FT procedures described above by using the C bit in the FT Session TLV on the Session Initialization message. Note, however, that check-pointing is an integral part of the FT procedures. Setting the S and the C bit will achieve the same function as setting just the S bit.
通过在会话初始化消息上使用FT会话TLV中的C位，可以独立于上述FT过程选择检查点。但是，请注意，检查点是FT程序的一个组成部分。设置S和C位将实现与仅设置S位相同的功能。
If the C bit is set, but the S bit is not set, no label is a Sequence Numbered FT Label. Instead, all labels are Check-Pointable FT Labels. Check-Pointing is used to synchronize all label exchanges. No message, apart from the check-point request and acknowledgement, carries an active sequence number. (Note that the Session Initialization message may carry a sequence number to confirm that the check-point is still in place).
如果设置了C位，但未设置S位，则无标签是序列编号的FT标签。相反，所有标签都是可检查点的FT标签。检查点用于同步所有标签交换。除了检查点请求和确认之外，没有任何消息携带活动序列号。（请注意，会话初始化消息可能带有一个序列号，以确认检查点仍然存在）。
It is an implementation matter to decide the ordering of received messages and check-point requests to ensure that check-point acknowledgements are secured.
决定接收到的消息和检查点请求的顺序是一个实现问题，以确保检查点确认是安全的。
If the S and C bits are both set, or only the S bit is set, check-pointing applies only to Sequence Numbered FT Labels and to address messages.
如果同时设置了S和C位，或仅设置了S位，则检查点仅适用于序列号FT标签和地址消息。
The set of all messages check-pointed in this way is called the Check-Pointable Messages.
以这种方式检查指向的所有消息集称为可检查指向的消息。
If an LSR receives a FT Protection TLV on a Keepalive message, this is a request to flush the acknowledgements for all previously received Check-Pointable Messages on the session.
如果LSR在Keepalive消息上接收到FT Protection TLV，则这是一个请求，用于刷新会话上以前接收到的所有可检查点消息的确认。
As soon as the LSR has completed securing the Check-Pointable Messages (or state changes consequent on those messages) received before the Keepalive, it MUST send an acknowledgement to the sequence number of the Keepalive message.
一旦LSR完成保护在Keepalive之前收到的可检查点消息（或这些消息导致的状态更改），它必须向Keepalive消息的序列号发送确认。
In the case where the FT procedures are in use and acknowledgements have been stored up, this may occur immediately upon receipt of the Keepalive.
如果正在使用FT程序并且已存储确认，则在收到Keepalive后可能会立即发生这种情况。
An example message flow showing this use of the Keepalive message to perform a periodic check-point of state is shown in section 9.2, "Use of Check-Pointing With FT Procedures".
第9.2节“通过FT程序使用检查点”中显示了使用Keepalive消息执行定期状态检查点的示例消息流。
An example message flow showing the use of check-pointing without the FT procedures is shown in section 9.5, "Check-Pointing Without FT Procedures".
第9.5节“不带FT程序的检查点”中显示了显示不带FT程序的检查点使用的示例消息流。
If the Keepalive Message also contains the FT Cork TLV, this indicates that the peer LSR wishes to quiesce the session prior to a graceful restart.
如果Keepalive消息还包含FT Cork TLV，则表示对等LSR希望在正常重新启动之前停止会话。
It is RECOMMENDED that upon receiving a Keepalive with the FT CORK TLV, an LSR should cease to send any further label or address related messages on the session until it has been disconnected and reconnected, other than messages generated while processing and securing previously unacknowledged messages received from the peer requesting the quiesce. It should also attempt to complete this processing and return a Keepalive with the FT ACK TLV as soon as possible in order to allow the session to be quiesced.
建议在收到FT CORK TLV的Keepalive后，LSR应停止在会话上发送任何进一步的标签或地址相关消息，直到其断开并重新连接，而不是在处理和保护从请求暂停的对等方接收的先前未确认的消息时生成的消息。它还应尝试尽快完成此处理并返回FT ACK TLV的Keepalive，以便使会话停止。
An example message flow showing this use of the FT Cork TLV to achieve a three-way handshake of state synchronization between two LDP peers is given in section 9.4, "Temporary Shutdown With FT Procedures and Check-Pointing".
第9.4节“使用FT程序和检查点临时关机”中给出了一个示例消息流，显示了使用FT-Cork TLV实现两个LDP对等方之间状态同步的三方握手。
The LDP FT enhancements add the following optional parameters to a LDP Initialization message:
LDP FT增强功能将以下可选参数添加到LDP初始化消息中：
Optional Parameter Length Value
可选参数长度值
FT Session TLV 4 See Below FT ACK TLV 4 See Below
FT会话TLV 4见下文FT ACK TLV 4见下文
The encoding for these TLVs is found in Section 8, "New Fields and Values".
这些TLV的编码见第8节“新字段和值”。
FT Session TLV If present, specifies the FT behavior of the LDP session.
FT会话TLV（如果存在）指定LDP会话的FT行为。
FT ACK TLV If present, specifies the last FT message that the sending LDP peer was able to secure prior to the failure of the previous instantiation of the LDP session. This TLV is only present if the FT Reconnect flag is set in the FT Session TLV, in which case this TLV MUST be present.
FT ACK TLV（如果存在）指定发送LDP对等方在LDP会话上一次实例化失败之前能够保护的最后一条FT消息。只有在FT会话TLV中设置了FT Reconnect标志时，此TLV才存在，在这种情况下，此TLV必须存在。
The LDP FT enhancements add the following optional parameters to a LDP Keepalive message:
LDP FT增强功能向LDP Keepalive消息添加以下可选参数：
Optional Parameter Length Value
可选参数长度值
FT Protection TLV 4 See below FT Cork TLV 0 See below FT ACK TLV 4 See below
FT保护TLV 4见下文FT软木TLV 0见下文FT ACK TLV 4见下文
The encoding for these TLVs is found in Section 8, "New Fields and Values".
这些TLV的编码见第8节“新字段和值”。
FT Protection TLV If present, specifies the FT Sequence Number for the LDP message. When present on a Keepalive message, this indicates a solicited flush of the acknowledgements to all previous LDP messages containing sequence numbers and issued by the sender of the Keepalive on the same session.
FT保护TLV（如果存在）指定LDP消息的FT序列号。当在Keepalive消息上出现时，这表示请求刷新对所有先前LDP消息（包含序列号）的确认，并由Keepalive的发送方在同一会话上发出。
FT Cork TLV Indicates that the remote LSR wishes to quiesce the LDP session. See section 5, "FT Operations", for the recommended action in such cases.
FT Cork TLV表示远程LSR希望停止LDP会话。有关此类情况下的建议措施，请参见第5节“FT操作”。
FT ACK TLV If present, specifies the most recent FT message that the sending LDP peer has been able to secure.
FT ACK TLV（如果存在）指定发送LDP对等方能够保护的最新FT消息。
The LDP FT enhancements add the following optional parameters to all other message types that flow on an LDP session after the LDP Initialization message
LDP FT增强功能将以下可选参数添加到LDP初始化消息之后LDP会话上的所有其他消息类型中
Optional Parameter Length Value
可选参数长度值
FT Protection TLV 4 See below FT ACK TLV 4 See below
FT保护TLV 4见下文FT ACK TLV 4见下文
The encoding for these TLVs is found in section 8, "New Fields and Values".
这些TLV的编码见第8节“新字段和值”。
FT Protection TLV If present, specifies the FT Sequence Number for the LDP message.
FT保护TLV（如果存在）指定LDP消息的FT序列号。
FT ACK TLV If present, identifies the most recent FT LDP message ACKed by the sending LDP peer.
FT ACK TLV（如果存在）标识发送LDP对等方确认的最新FT LDP消息。
The following new status codes are defined to indicate various conditions specific to the LDP FT enhancements. These status codes are carried in the Status TLV of a Notification message.
定义了以下新状态代码，以指示LDP FT增强功能特定的各种条件。这些状态代码包含在通知消息的状态TLV中。
The "E" column is the required setting of the Status Code E-bit; the "Status Data" column is the value of the 30-bit Status Data field in the Status Code TLV.
“E”列是状态代码E位的必要设置；“状态数据”列是状态代码TLV中30位状态数据字段的值。
Note that the setting of the Status Code F-bit is at the discretion of the LSR originating the Status TLV. However, it is RECOMMENDED that the F-bit is not set on Notification messages containing status codes except 'No LDP Session' because the duplication of messages SHOULD be restricted to being a per-hop behavior.
注意，状态代码F位的设置由发起状态TLV的LSR决定。但是，建议不要在包含状态码的通知消息上设置F位，除了“无LDP会话”，因为消息的复制应限制为每跳行为。
Status Code E Status Data
状态代码E状态数据
No LDP Session 0 0x0000001A Zero FT seqnum 1 0x0000001B Unexpected TLV / 1 0x0000001C Session Not FT Unexpected TLV / 1 0x0000001D Label Not FT Missing FT Protection TLV 1 0x0000001E FT ACK sequence error 1 0x0000001F Temporary Shutdown 0 0x00000020
无LDP会话0 0x0000001A零FT序列号1 0x0000001B意外TLV/1 0x0000001C会话不FT意外TLV/1 0x0000001D标签不FT缺少FT保护TLV 1 0x0000001E FT确认序列错误1 0x0000001F临时关机0 0x00000020
FT Seq Numbers Exhausted 1 0x00000021 FT Session parameters / 1 0x00000022 changed Unexpected FT Cork TLV 1 0x00000023
FT Seq编号用尽1 0x00000021 FT会话参数/1 0x00000022更改意外的FT Cork TLV 1 0x00000023
The 'Temporary Shutdown' status code SHOULD be used in place of the 'Shutdown' status code (which has the E-bit set) if the LSR that is shutting down wishes to inform its LDP peer that it expects to be able to preserve FT Label state and return to service before the FT Reconnection Timer expires.
如果正在关闭的LSR希望通知其LDP对等方其希望能够保持FT标签状态并在FT重新连接计时器到期前恢复服务，则应使用“临时关闭”状态代码代替“关闭”状态代码（已设置E位）。
LDP peers can negotiate whether the LDP session between them supports FT extensions by using a new OPTIONAL parameter, the FT Session TLV, on LDP Initialization Messages.
通过在LDP初始化消息上使用新的可选参数FT session TLV，LDP对等方可以协商它们之间的LDP会话是否支持FT扩展。
The FT Session TLV is encoded as follows.
FT会话TLV编码如下。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| FT Session TLV (0x0503) | Length (= 12) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT Reconnect Timeout (in milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| FT Session TLV (0x0503) | Length (= 12) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT Reconnect Timeout (in milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recovery Time (in milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FT Flags FT Flags: A 16 bit field that indicates various attributes the FT support on this LDP session. This field is formatted as follows:
FT Flags FT Flags：一个16位字段，指示FT在此LDP会话上支持的各种属性。此字段的格式如下所示：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |S|A|C|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |S|A|C|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R: FT Reconnect Flag. Set to 1 if the sending LSR has preserved state and resources for all FT-labels since the previous LDP session between the same LDP peers, and is otherwise set to 0. See section 5.4, "FT Procedures After TCP Failure", for details of how this flag is used.
R:FT重新连接标志。如果发送LSR自相同LDP对等方之间的上一个LDP会话以来保留了所有FT标签的状态和资源，则设置为1，否则设置为0。有关如何使用此标志的详细信息，请参见第5.4节“TCP故障后的FT程序”。
If the FT Reconnect Flag is set, the sending LSR MUST include an FT ACK TLV on the LDP Initialization message.
如果设置了FT Reconnect标志，则发送LSR必须在LDP初始化消息中包含FT ACK TLV。
S: Save State Flag. Set to 1 if the use of the FT Protection TLV is supported on messages other than the KeepAlive message used for check-pointing (see the C bit). I.e., the S bit indicates that some label on the session may be a Sequence Numbered FT Label.
S:保存州标志。如果在用于检查点的KeepAlive消息以外的消息上支持使用FT保护TLV，则设置为1（请参见C位）。即，S位表示会话上的一些标签可能是序列号的FT标签。
A: All-Label Protection Required Set to 1 if all labels on the session MUST be treated as Sequence Numbered FT Labels. This removes from a node the option of
答：如果会话上的所有标签都必须被视为序列号FT标签，则需要的所有标签保护设置为1。这将从节点中删除以下选项：
treating some labels as FT Labels and some labels as non-FT Labels.
将某些标签视为FT标签，将某些标签视为非FT标签。
Passing this information may be considered helpful to a peer since it may allow it to make optimizations in its processing.
传递此信息可能被认为对对等方有帮助，因为它可能允许对等方在处理过程中进行优化。
The A bit only has meaning if the S bit is set.
只有设置了S位时，A位才有意义。
C: Check-Pointing Flag. Set to 1 to indicate that the check-Pointing procedures in this document are in use.
C:检查指向标志。设置为1表示正在使用本文档中的检查点过程。
If the S bit is also set to 1 then the C bit indicates that check-pointing is applied only to Sequence Numbered FT Labels.
如果S位也设置为1，则C位表示检查点仅应用于序列编号的FT标签。
If the S bit is set to 0 (zero) then the C bit indicates that check-pointing applies to all labels - all labels are Check-Pointable FT Labels.
如果S位设置为0（零），则C位表示检查点适用于所有标签-所有标签都是可检查点的FT标签。
L: Learn From Network Flag. Set to 1 if the Fault Recovery procedures of [RFC3478] are to be used to re-learn state from the network.
L:学习网络标志。如果要使用[RFC3478]的故障恢复程序从网络重新学习状态，则设置为1。
It is not valid for all of the S, C and L bits to be zero.
并非所有S、C和L位都为零。
It is not valid for both the L and either the S or C bits to be set to 1.
L位和S位或C位都设置为1是无效的。
All other bits in this field are currently reserved and SHOULD be set to zero on transmission and ignored upon receipt.
此字段中的所有其他位当前保留，传输时应设置为零，接收时忽略。
The following table summarizes the settings of these bits.
下表总结了这些位的设置。
S A C L Comments
=========================
0 x 0 0 Invalid
0 0 0 1 See [RFC3478]
0 1 0 1 Invalid
0 x 1 0 Check-Pointing of all labels
0 x 1 1 Invalid
1 0 0 0 Full FT on selected labels
1 1 0 0 Full FT on all labels
1 x 0 1 Invalid
1 x 1 0 Same as (S=1,A=x,C=0,L=0)
1 x 1 1 Invalid.
S A C L Comments
=========================
0 x 0 0 Invalid
0 0 0 1 See [RFC3478]
0 1 0 1 Invalid
0 x 1 0 Check-Pointing of all labels
0 x 1 1 Invalid
1 0 0 0 Full FT on selected labels
1 1 0 0 Full FT on all labels
1 x 0 1 Invalid
1 x 1 0 Same as (S=1,A=x,C=0,L=0)
1 x 1 1 Invalid.
FT Reconnection Timeout If the S bit or C bit in the FT Flags field is set, this indicates the period of time the sending LSR will preserve state and resources for FT Labels exchanged on the previous instantiation of an FT LDP session that has recently failed. The timeout is encoded as a 32-bit unsigned integer number of milliseconds.
FT重新连接超时如果在FT Flags字段中设置了S位或C位，则表示发送LSR将为最近失败的FT LDP会话的上一次实例化中交换的FT标签保留状态和资源的时间段。超时被编码为32位无符号整数毫秒数。
A value of zero in this field means that the sending LSR will preserve state and resources indefinitely.
此字段中的值为零表示发送LSR将无限期地保留状态和资源。
See section 4.4 for details of how this field is used.
有关如何使用此字段的详细信息，请参见第4.4节。
If the L bit is set to 1 in the FT Flags field, the meaning of this field is defined in [RFC3478].
如果FT Flags字段中的L位设置为1，则该字段的含义在[RFC3478]中定义。
Recovery Time The Recovery Time only has meaning if the L bit is set in the FT Flags. The meaning is defined in [RFC3478].
恢复时间只有在FT标志中设置了L位时，恢复时间才有意义。定义见[RFC3478]。
LDP peers use the FT Protection TLV to indicate that an LDP message contains an FT label operation.
LDP对等方使用FT保护TLV来指示LDP消息包含FT标签操作。
The FT Protection TLV MUST NOT be used in messages flowing on an LDP session that does not support the LDP FT enhancements. Its presence in such messages SHALL be treated as a protocol error by the receiving LDP peer which SHOULD send a Notification message with the 'Unexpected TLV Session Not FT' status code. LSRs that do not recognize this TLV SHOULD respond with a Notification message with the 'Unknown TLV' status code.
FT保护TLV不得用于不支持LDP FT增强功能的LDP会话上的消息流中。接收LDP对等方应将其在此类消息中的存在视为协议错误，LDP对等方应发送带有“意外TLV会话非FT”状态码的通知消息。不识别此TLV的LSR应以“未知TLV”状态代码的通知消息进行响应。
The FT Protection TLV MAY be carried on an LDP message transported on the LDP session after the initial exchange of LDP Initialization messages. In particular, this TLV MAY optionally be present on the following messages:
FT保护TLV可以在初始交换LDP初始化消息之后在LDP会话上传输的LDP消息上承载。具体而言，该TLV可选择性地出现在以下消息中：
- Label Request Messages in downstream on-demand distribution mode.
- 在下游按需分发模式下标记请求消息。
- Label Mapping messages in downstream unsolicited mode.
- 下游未经请求模式下的标签映射消息。
- Keepalive messages used to request flushing of acknowledgement of all previous messages that contained this TLV.
- Keepalive消息用于请求刷新包含此TLV的所有以前的消息的确认。
If a label is to be a Sequence Numbered FT Label, then the Protection TLV MUST be present:
如果标签是序列编号的FT标签，则保护TLV必须存在：
- on the Label Request message in downstream on-demand distribution mode.
- 在下游按需分发模式下的标签请求消息上。
- on the Label Mapping message in in downstream unsolicited distribution mode.
- 在下游未经请求的分发模式中的标签映射消息上。
- on all subsequent messages concerning this label.
- 关于此标签的所有后续消息。
Here 'subsequent messages concerning this label' means any message whose Label TLV specifies this label or whose Label Request Message ID TLV specifies the initial Label Request message.
此处“关于此标签的后续消息”指其标签TLV指定此标签或其标签请求消息ID TLV指定初始标签请求消息的任何消息。
If a label is not to be a Sequence Numbered FT Label, then the Protection TLV MUST NOT be present on any of these messages that relate to the label. The presence of the FT TLV on a message relating to a non-FT Label SHALL be treated as a protocol error by the receiving LDP peer which SHOULD send a notification message with the 'Unexpected TLV Label Not FT' status code.
如果标签不是序列号的FT标签，则保护TLV不得出现在与标签相关的任何消息上。接收LDP对等方应将与非FT标签相关的消息上存在FT TLV视为协议错误，LDP对等方应发送带有“意外TLV标签非FT”状态码的通知消息。
Where a Label Withdraw or Label Release message contains only an FEC TLV and does not identify a single specific label, the FT TLV should be included in the message if any label affected by the message is a Sequence Numbered FT Label. If there is any doubt as to whether an FT TLV should be present, it is RECOMMENDED that the sender add the TLV.
如果标签撤回或标签释放消息仅包含FEC TLV，且未识别单个特定标签，则如果受消息影响的任何标签是序列号FT标签，则应将FT TLV包含在消息中。如果对是否应存在FT TLV有任何疑问，建议发送方添加TLV。
When an LDP peer receives a Label Withdraw Message or Label Release message that contains only a FEC, it SHALL accept the FT TLV if it is present regardless of the FT status of the labels that it affects.
当LDP对等方接收到仅包含FEC的标签撤销消息或标签释放消息时，无论其影响的标签的FT状态如何，如果FT TLV存在，则LDP对等方应接受FT TLV。
If an LDP session is an FT session as determined by the presence of the FT Session TLV, with the S bit set on the LDP Initialization messages, the FT Protection TLV MUST be present on all Address messages on the session.
如果LDP会话是由FT会话TLV的存在确定的FT会话，并且LDP初始化消息上设置了S位，则FT保护TLV必须出现在会话上的所有地址消息上。
If the session is an FT session, the FT Protection TLV may also optionally be present:
如果会话是FT会话，则FT保护TLV也可以选择性地存在：
- on Notification messages on the session that have the status code 'Label Resources Available'.
- 会话上状态代码为“Label Resources Available”（标签资源可用）的通知消息。
- on Keepalive messages.
- 在Keepalive消息上。
The FT Protection TLV is encoded as follows.
FT保护TLV编码如下。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| FT Protection (0x0203) | Length (= 4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| FT Protection (0x0203) | Length (= 4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FT Sequence Number The sequence number for this Sequence Numbered FT Label operation. The sequence number is encoded as a 32-bit unsigned integer. The initial value for this field on a new LDP session is 0x00000001 and is incremented by one for each FT LDP message issued by the sending LSR on this LDP session. This field may wrap from 0xFFFFFFFF to 0x00000001.
FT序列号此序列号FT标签操作的序列号。序列号编码为32位无符号整数。新LDP会话上此字段的初始值为0x00000001，对于发送LSR在此LDP会话上发出的每个FT LDP消息，此字段的值将增加1。此字段可以从0xFFFFFF换行到0x00000001。
This field MUST be reset to 0x00000001 if either LDP peer does not set the FT Reconnect Flag upon re-establishment of the TCP connection.
如果重新建立TCP连接时任一LDP对等方未设置FT Reconnect标志，则必须将此字段重置为0x00000001。
See section 5.2, "FT Operation Acks" for details of how this field is used.
有关如何使用此字段的详细信息，请参见第5.2节“FT操作确认”。
The special use of 0x00000000 is discussed in the section 8.4, "FT ACK TLV" below.
0x00000000的特殊用途在下面第8.4节“FT ACK TLV”中讨论。
If an LSR receives an FT Protection TLV on a session that does not support the FT LDP enhancements, it SHOULD send a Notification message to its LDP peer containing the 'Unexpected TLV, Session Not FT' status code. LSRs that do not recognize this TLV SHOULD respond with a Notification message with the 'Unknown TLV' status code.
如果LSR在不支持FT LDP增强功能的会话上收到FT保护TLV，则应向其LDP对等方发送包含“意外TLV，会话非FT”状态代码的通知消息。不识别此TLV的LSR应以“未知TLV”状态代码的通知消息进行响应。
If an LSR receives an FT Protection TLV on an operation affecting a label that it believes is a non-FT Label, it SHOULD send a Notification message to its LDP peer containing the 'Unexpected TLV, Label Not FT' status code.
如果LSR在影响其认为是非FT标签的标签的操作上收到FT保护TLV，则应向其LDP对等方发送包含“意外TLV，标签不是FT”状态代码的通知消息。
If an LSR receives a message without the FT Protection TLV affecting a label that it believes is a Sequence Numbered FT Label, it SHOULD send a Notification message to its LDP peer containing the 'Missing FT Protection TLV' status code.
如果LSR接收到的消息没有FT保护TLV影响其认为是序列号FT标签的标签，则应向其LDP对等方发送包含“缺失FT保护TLV”状态代码的通知消息。
If an LSR receives an FT Protection TLV containing a zero FT Sequence Number, it SHOULD send a Notification message to its LDP peer containing the 'Zero FT Seqnum' status code.
如果LSR接收到包含零FT序列号的FT保护TLV，则应向其LDP对等方发送包含“零FT Seqnum”状态代码的通知消息。
LDP peers use the FT ACK TLV to acknowledge FT Label operations.
LDP对等方使用FT ACK TLV确认FT标签操作。
The FT ACK TLV MUST NOT be used in messages flowing on an LDP session that does not support the LDP FT enhancements. Its presence on such messages SHALL be treated as a protocol error by the receiving LDP peer.
FT ACK TLV不得用于不支持LDP FT增强功能的LDP会话上的消息流中。接收LDP对等方应将其出现在此类消息上视为协议错误。
The FT ACK TLV MAY be present on any LDP message exchanged on an LDP session after the initial LDP Initialization messages. It is RECOMMENDED that the FT ACK TLV be included in all FT Keepalive messages in order to ensure that the LDP peers do not build up a large backlog of unacknowledged state information.
FT-ACK TLV可以出现在初始LDP初始化消息之后在LDP会话上交换的任何LDP消息上。建议在所有FT Keepalive消息中包括FT ACK TLV，以确保LDP对等方不会积累大量未确认的状态信息。
The FT ACK TLV is encoded as follows.
FT ACK TLV编码如下。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| FT ACK (0x0504) | Length (= 4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT ACK Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| FT ACK (0x0504) | Length (= 4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT ACK Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FT ACK Sequence Number The sequence number for the most recent FT label message that the sending LDP peer has received from the receiving LDP peer and secured against failure of the LDP session. It is not necessary for the sending peer to have fully processed the message before ACKing it. For example, an LSR MAY ACK a Label Request message as soon as it has securely recorded the message, without waiting until it can send the Label Mapping message in response.
FT ACK序列号发送LDP对等方已从接收LDP对等方接收到的最新FT标签消息的序列号，该序列号可防止LDP会话失败。发送端无需在确认消息之前完全处理该消息。例如，LSR可以在安全地记录了标签请求消息后立即确认该消息，而无需等待直到它能够发送标签映射消息作为响应。
ACKs are cumulative. Receipt of an LDP message containing an FT ACK TLV with an FT ACK Sequence Number of 12 is treated as the acknowledgement of all messages from 1 to 12 inclusive (assuming the LDP session started with a sequence number of 1).
ACK是累积的。接收包含FT ACK序列号为12的FT ACK TLV的LDP消息被视为确认从1到12（包括1到12）的所有消息（假设LDP会话以序列号1开始）。
This field MUST be set to 0 if the LSR sending the FT ACK TLV has not received any FT label operations on this LDP session. This applies to LDP sessions, to new LDP peers or after an LSR determines that it must drop all state for a failed TCP connection.
如果发送FT ACK TLV的LSR在此LDP会话上未收到任何FT标签操作，则此字段必须设置为0。这适用于LDP会话、新的LDP对等方或LSR确定必须删除失败TCP连接的所有状态后。
See section 5.2, "FT Operation Acks" for details of how this field is used.
有关如何使用此字段的详细信息，请参见第5.2节“FT操作确认”。
If an LSR receives an FT ACK TLV that contains an FT ACK Sequence Number that is less than the previously received FT ACK Sequence Number (remembering to take account of wrapping), it SHOULD send a Notification message to its LDP peer containing the 'FT ACK Sequence Error' status code.
如果LSR接收到的FT ACK TLV包含的FT ACK序列号小于先前接收到的FT ACK序列号（记住要考虑包装），则应向其LDP对等方发送包含“FT ACK序列错误”状态码的通知消息。
LDP peers use the FT Cork TLV on FT Keepalive messages to indicate that they wish to quiesce the LDP session prior to a controlled shutdown and restart, for example during control-plane software upgrade.
LDP对等方使用FT Keepalive消息上的FT Cork TLV来表示他们希望在受控关机和重启之前（例如在控制平面软件升级期间）停止LDP会话。
The FT Cork TLV is encoded as follows.
FT Cork TLV编码如下。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| FT Cork (0x0505) | Length (= 0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| FT Cork (0x0505) | Length (= 0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Upon receipt of a Keepalive message with the FT Cork TLV and the FT Protection TLV, an LSR SHOULD perform the following actions:
收到带有FT Cork TLV和FT Protection TLV的Keepalive消息后，LSR应执行以下操作：
- Process and secure any messages from the peer LSR that have sequence numbers less than (accounting for wrap) that contained in the FT Protection TLV on the Keepalive message.
- 处理并保护来自对等LSR的任何消息，这些消息的序列号小于Keepalive消息上FT保护TLV中包含的序列号（考虑包裹）。
- Send a Keepalive message back to the peer containing the FT Cork TLV and the FT ACK TLV specifying the FT ACK sequence number equal to that in the original Keepalive message (i.e. ACKing all messages up to that point).
- 向对等方发送一条Keepalive消息，其中包含FT Cork TLV和FT ACK TLV，并指定与原始Keepalive消息中相同的FT ACK序列号（即，在该点之前确认所有消息）。
- If this LSR has not yet received an FT ACK to all the messages it has sent containing the FT Protection TLV, then also include an FT Protection TLV on the Keepalive sent to the peer LSR. This tells the remote peer that the local LSR has saved state prior to quiesce but is still awaiting confirmation that the remote peer has saved state.
- 如果此LSR尚未收到其发送的包含FT保护TLV的所有消息的FT ACK，则还应在发送给对等LSR的Keepalive上包含FT保护TLV。这会告诉远程对等方本地LSR在静止之前已保存状态，但仍在等待远程对等方已保存状态的确认。
- Cease sending any further state changing messages on this LDP session until it has been disconnected and recovered.
- 停止在此LDP会话上发送任何进一步的状态更改消息，直到其断开连接并恢复。
On receipt of a Keepalive message with the FT Cork TLV and an FT ACK TLV that acknowledges the previously sent Keepalive that carried the FT Cork TLV, an LSR knows that quiesce is complete. If the received Keepalive also carries the FT Protection TLV, the LSR must respond with a further Keepalive to complete the 3-way handshake. It SHOULD
在收到带有FT Cork TLV的Keepalive消息和确认先前发送的带有FT Cork TLV的Keepalive的FT ACK TLV后，LSR知道静止已完成。如果接收到的Keepalive也带有FT保护TLV，则LSR必须用另一个Keepalive进行响应，以完成3路握手。它应该
now send a "Temporary Shutdown" Notification message, disconnect the TCP session and perform whatever control plane actions required this session shutdown.
现在发送“临时关闭”通知消息，断开TCP会话，并执行会话关闭所需的任何控制平面操作。
An example of such a 3-way handshake for controlled shutdown is given in section section 9.4, "Temporary Shutdown With FT Procedures and Check-Pointing".
第9.4节“带FT程序和检查点的临时停堆”中给出了受控停堆的此类三向握手示例。
If an LSR receives a message that should not carry the FT Cork TLV, or if the FT Cork TLV is used on a Keepalive message without one of the FT Protection or FT ACK TLVs present, it SHOULD send a Notification message to its LDP peer containing the 'Unexpected FT Cork TLV' status code.
如果LSR接收到不应携带FT-Cork TLV的消息，或者如果FT-Cork TLV用于Keepalive消息而没有FT-Protection或FT-ACK TLV，则LSR应向其LDP对等方发送包含“意外FT-Cork TLV”状态代码的通知消息。
Consider two LDP peers, P1 and P2, implementing LDP over a TCP connection that connects them, and the message flow shown below.
考虑两个LDP对等点P1和P2，在连接它们的TCP连接上实现LDP，以及下面显示的消息流。
The parameters shown on each message below are as follows:
下面每条消息上显示的参数如下：
message (label, senders FT sequence number, FT ACK number)
消息（标签、发送者FT序列号、FT确认号）
A "-" for FT ACK number means that the FT ACK TLV is not included on that message. "n/a" means that the parameter in question is not applicable to that type of message.
FT ACK编号的“-”表示该消息中不包括FT ACK TLV。“n/a”表示相关参数不适用于该类型的消息。
In the diagrams below, time flows from top to bottom. The relative position of each message shows when it is transmitted. See the notes for a description of when each message is received, secured for FT or processed.
在下图中，时间从上到下流动。每条信息的相对位置显示其传输时间。有关接收、保护或处理每条消息的时间说明，请参阅注释。
notes P1 P2
===== == ==
(1) Label Request(L1,27,-)
--------------------------->
Label Request(L2,28,-)
--------------------------->
(2) Label Request(L3,93,27)
<---------------------------
(3) Label Request(L1,123,-)
-------------------------->
Label Request(L2,124,-)
-------------------------->
notes P1 P2
===== == ==
(1) Label Request(L1,27,-)
--------------------------->
Label Request(L2,28,-)
--------------------------->
(2) Label Request(L3,93,27)
<---------------------------
(3) Label Request(L1,123,-)
-------------------------->
Label Request(L2,124,-)
-------------------------->
(4) Label Mapping(L1,57,-)
<--------------------------
Label Mapping(L1,94,28)
<---------------------------
(5) Label Mapping(L2,58,-)
<--------------------------
Label Mapping(L2,95,-)
<---------------------------
(6) Address(n/a,29,-)
--------------------------->
(7) Label Request(L4,30,-)
--------------------------->
(8) Keepalive(n/a,-,94)
--------------------------->
(9) Label Abort(L3,96,-)
<---------------------------
(10) ===== TCP Session lost =====
:
(11) : Label Withdraw(L1,59,-)
: <--------------------------
:
(12) === TCP Session restored ===
(4) Label Mapping(L1,57,-)
<--------------------------
Label Mapping(L1,94,28)
<---------------------------
(5) Label Mapping(L2,58,-)
<--------------------------
Label Mapping(L2,95,-)
<---------------------------
(6) Address(n/a,29,-)
--------------------------->
(7) Label Request(L4,30,-)
--------------------------->
(8) Keepalive(n/a,-,94)
--------------------------->
(9) Label Abort(L3,96,-)
<---------------------------
(10) ===== TCP Session lost =====
:
(11) : Label Withdraw(L1,59,-)
: <--------------------------
:
(12) === TCP Session restored ===
LDP Init(n/a,n/a,94)
--------------------------->
LDP Init(n/a,n/a,29)
<---------------------------
(13) Label Request(L4,30,-)
--------------------------->
(14) Label Mapping(L2,95,-)
<---------------------------
Label Abort(L3,96,30)
<---------------------------
(15) Label Withdraw(L1,97,-)
<---------------------------
LDP Init(n/a,n/a,94)
--------------------------->
LDP Init(n/a,n/a,29)
<---------------------------
(13) Label Request(L4,30,-)
--------------------------->
(14) Label Mapping(L2,95,-)
<---------------------------
Label Abort(L3,96,30)
<---------------------------
(15) Label Withdraw(L1,97,-)
<---------------------------
Notes:
======
Notes:
======
(1) Assume that the LDP session has already been initialized. P1 issues 2 new Label Requests using the next sequence numbers.
(1) 假设LDP会话已经初始化。P1使用下一个序列号发出2个新标签请求。
(2) P2 issues a Label Request to P1. At the time of sending this request, P2 has secured the receipt of the label request for L1 from P1, so it includes an ACK for that message.
(2) P2向P1发出标签请求。在发送该请求时，P2已确保从P1接收到L1的标签请求，因此它包括该消息的ACK。
(3) P2 processes the Label Requests for L1 and L2 and forwards them downstream. Details of downstream processing are not shown in the diagram above.
(3) P2处理L1和L2的标签请求，并将它们转发到下游。上图中未显示下游处理的详细信息。
(4) P2 receives a Label Mapping from downstream for L1, which it forwards to P1. It includes an ACK to the Label Request for L2, as that message has now been secured and processed.
(4) P2从下游接收L1的标签映射，并将其转发给P1。它包括对L2的标签请求的确认，因为该消息现在已经得到保护和处理。
(5) P2 receives the Label Mapping for L2, which it forwards to P1. This time it does not include an ACK as it has not received any further messages from P1.
(5) P2接收L2的标签映射，并将其转发给P1。这一次它不包括ACK，因为它没有从P1接收到任何进一步的消息。
(6) Meanwhile, P1 sends a new Address Message to P2.
(6) 同时，P1向P2发送新地址消息。
(7) P1 also sends a fourth Label Request to P2
(7) P1还向P2发送第四个标签请求
(8) P1 sends a Keepalive message to P2, on which it includes an ACK for the Label Mapping for L1, which is the latest message P1 has received and secured at the time the Keepalive is sent.
(8) P1向P2发送Keepalive消息，其中包括L1标签映射的ACK，这是P1在发送Keepalive时接收并保护的最新消息。
(9) P2 issues a Label Abort for L3.
(9) P2为L3发出标签中止。
(10) At this point, the TCP session goes down.
（10） 此时，TCP会话将停止。
(11) While the TCP session is down, P2 receives a Label Withdraw Message for L1, which it queues.
（11） TCP会话关闭时，P2接收L1的标签撤消消息，并将其排队。
(12) The TCP session is reconnected and P1 and P2 exchange LDP Initialization messages on the recovered session, which include ACKS for the last message each peer received and secured prior to the failure.
（12） TCP会话被重新连接，P1和P2在恢复的会话上交换LDP初始化消息，其中包括每个对等方在故障之前接收并保护的最后一条消息的ACK。
(13) From the LDP Init exchange, P1 determines that it needs to re-issue the Label request for L4.
（13） 从LDP Init交换中，P1确定需要重新发出L4的标签请求。
(14) Similarly, P2 determines that it needs to re-issue the Label Mapping for L2 and the Label Abort.
（14） 类似地，P2确定需要重新发布L2的标签映射和标签中止。
(15) P2 issues the queued Label Withdraw to P1.
（15） P2向P1发出队列标签RECURN。
notes P1 P2
===== == ==
(1) Label Request(L1,27,-)
--------------------------->
Label Request(L2,28,-)
--------------------------->
(2) Label Request(L3,93,-)
<---------------------------
(3) Label Request(L1,123,-)
-------------------------->
Label Request(L2,124,-)
-------------------------->
(4) Label Mapping(L1,57,-)
<--------------------------
Label Mapping(L1,94,-)
<---------------------------
(5) Label Mapping(L2,58,-)
<--------------------------
Label Mapping(L2,95,-)
<---------------------------
(6) Address(n/a,29,-)
--------------------------->
(7) Label Request(L4,30,-)
--------------------------->
(8) Keepalive(n/a,31,-)
--------------------------->
(9) Keepalive(n/a,-,31)
<---------------------------
(10) Keepalive(n/a,59,124)
<---------------------------
(11) Keepalive(n/a,-,59)
--------------------------->
Notes:
======
notes P1 P2
===== == ==
(1) Label Request(L1,27,-)
--------------------------->
Label Request(L2,28,-)
--------------------------->
(2) Label Request(L3,93,-)
<---------------------------
(3) Label Request(L1,123,-)
-------------------------->
Label Request(L2,124,-)
-------------------------->
(4) Label Mapping(L1,57,-)
<--------------------------
Label Mapping(L1,94,-)
<---------------------------
(5) Label Mapping(L2,58,-)
<--------------------------
Label Mapping(L2,95,-)
<---------------------------
(6) Address(n/a,29,-)
--------------------------->
(7) Label Request(L4,30,-)
--------------------------->
(8) Keepalive(n/a,31,-)
--------------------------->
(9) Keepalive(n/a,-,31)
<---------------------------
(10) Keepalive(n/a,59,124)
<---------------------------
(11) Keepalive(n/a,-,59)
--------------------------->
Notes:
======
Notes (1) through (7) are as in the previous example except note that no acknowledgements are piggy-backed on reverse direction messages. This means that at note (8) there are deferred acknowledgements in both directions on both links.
注释（1）到（7）与前一个示例相同，但请注意，反向消息上不支持任何确认。这意味着在注释（8）中，在两个链路的两个方向上都有延迟确认。
(8) P1 wishes to synchronize state with P2. It sends a Keepalive message containing an FT Protection TLV with sequence number 31. Since it is not interested in P2's perception of the state that it has stored, it does not include an FT ACK TLV.
(8) P1希望将状态与P2同步。它发送一条Keepalive消息，其中包含序列号为31的FT保护TLV。因为它对P2对其存储的状态的感知不感兴趣，所以它不包括FT ACK TLV。
(9) P2 responds at once with a Keepalive acknowledging the sequence number on the received Keepalive. This tells P1 that P2 has preserved all state/messages previously received on this session.
(9) P2立即以Keepalive响应，确认接收到的Keepalive上的序列号。这告诉P1 P2保留了以前在此会话上收到的所有状态/消息。
(10) The downstream node wishes to synchronize state with P2. It sends a Keepalive message containing an FT Protection TLV with sequence number 59. P3 also takes this opportunity to get up to date with its acknowledgements to P2 by including an FT ACK TLV acknowledging up to sequence number 124.
（10） 下游节点希望与P2同步状态。它发送一条Keepalive消息，其中包含序列号为59的FT保护TLV。P3还借此机会通过包括FT ACK TLV确认序列号124来更新其对P2的确认。
(11) P2 responds at once with a Keepalive acknowledging the sequence number on the received Keepalive.
（11） P2立即以Keepalive响应，确认接收到的Keepalive上的序列号。
notes P1 P2
===== == ==
(1) Label Request(L1,27,-)
--------------------------->
Label Request(L2,28,-)
--------------------------->
(2) Label Request(L3,93,27)
<---------------------------
(3) Label Request(L1,123,-)
-------------------------->
Label Request(L2,124,-)
-------------------------->
(4) Label Mapping(L1,57,-)
<--------------------------
Label Mapping(L1,94,28)
<---------------------------
(5) Label Mapping(L2,58,-)
<--------------------------
Label Mapping(L2,95,-)
<---------------------------
(6) Address(n/a,29,-)
--------------------------->
(7) Label Request(L4,30,-)
--------------------------->
(8) Keepalive(n/a,-,94)
--------------------------->
(9) Label Abort(L3,96,-)
<---------------------------
notes P1 P2
===== == ==
(1) Label Request(L1,27,-)
--------------------------->
Label Request(L2,28,-)
--------------------------->
(2) Label Request(L3,93,27)
<---------------------------
(3) Label Request(L1,123,-)
-------------------------->
Label Request(L2,124,-)
-------------------------->
(4) Label Mapping(L1,57,-)
<--------------------------
Label Mapping(L1,94,28)
<---------------------------
(5) Label Mapping(L2,58,-)
<--------------------------
Label Mapping(L2,95,-)
<---------------------------
(6) Address(n/a,29,-)
--------------------------->
(7) Label Request(L4,30,-)
--------------------------->
(8) Keepalive(n/a,-,94)
--------------------------->
(9) Label Abort(L3,96,-)
<---------------------------
(10) Notification(Temporary shutdown)
--------------------------->
===== TCP Session shutdown =====
:
(11) : Label Withdraw(L1,59,-)
: <--------------------------
:
===== TCP Session restored =====
(12) LDP Init(n/a,n/a,94)
--------------------------->
LDP Init(n/a,n/a,29)
<---------------------------
(13) Label Request(L4,30,-)
--------------------------->
(14) Label Mapping(L2,95,-)
<---------------------------
Label Abort(L3,96,30)
<---------------------------
(15) Label Withdraw(L1,97,-)
<---------------------------
(10) Notification(Temporary shutdown)
--------------------------->
===== TCP Session shutdown =====
:
(11) : Label Withdraw(L1,59,-)
: <--------------------------
:
===== TCP Session restored =====
(12) LDP Init(n/a,n/a,94)
--------------------------->
LDP Init(n/a,n/a,29)
<---------------------------
(13) Label Request(L4,30,-)
--------------------------->
(14) Label Mapping(L2,95,-)
<---------------------------
Label Abort(L3,96,30)
<---------------------------
(15) Label Withdraw(L1,97,-)
<---------------------------
Notes:
======
Notes:
======
Notes are as in the previous example except as follows.
注释与上一示例相同，但如下所示。
(10) P1 needs to upgrade the software or hardware that it is running. It issues a Notification message to terminate the LDP session, but sets the status code as 'Temporary shutdown' to inform P2 that this is not a fatal error, and P2 should maintain FT state. The TCP connection may also fail during the period that the LDP session is down (in which case it will need to be re-established), but it is also possible that the TCP connection will be preserved.
（10） P1需要升级正在运行的软件或硬件。它发出通知消息终止LDP会话，但将状态代码设置为“临时关闭”，以通知P2这不是致命错误，P2应保持FT状态。在LDP会话关闭期间，TCP连接也可能会失败（在这种情况下，需要重新建立），但TCP连接也可能会被保留。
notes P1 P2
===== == ==
(1) Label Request(L1,27,-)
--------------------------->
Label Request(L2,28,-)
--------------------------->
(2) Label Request(L3,93,-)
<---------------------------
Label Request(L1,123,-)
-------------------------->
Label Request(L2,124,-)
-------------------------->
Label Mapping(L1,57,-)
<--------------------------
(3) Label Mapping(L1,94,-)
<---------------------------
Label Mapping(L2,58,-)
<--------------------------
Label Mapping(L2,95,-)
<---------------------------
(4) Address(n/a,29,-)
--------------------------->
(5) Label Request(L4,30,-)
--------------------------->
(6) Keepalive(n/a,31,95) * with FT Cork TLV *
--------------------------->
(7) Label Abort(L3,96,-)
<---------------------------
(8) Keepalive(n/a,97,31) * with FT Cork TLV *
<---------------------------
(9) Keepalive(n/a,-,97) * with FT Cork TLV *
--------------------------->
(10) Notification(Temporary shutdown)
--------------------------->
===== TCP Session shutdown =====
:
: Label Withdraw(L1,59,-)
: <--------------------------
:
===== TCP Session restored =====
(11) LDP Init(n/a,n/a,96)
--------------------------->
LDP Init(n/a,n/a,31)
<---------------------------
Label Withdraw(L1,97,-)
<---------------------------
notes P1 P2
===== == ==
(1) Label Request(L1,27,-)
--------------------------->
Label Request(L2,28,-)
--------------------------->
(2) Label Request(L3,93,-)
<---------------------------
Label Request(L1,123,-)
-------------------------->
Label Request(L2,124,-)
-------------------------->
Label Mapping(L1,57,-)
<--------------------------
(3) Label Mapping(L1,94,-)
<---------------------------
Label Mapping(L2,58,-)
<--------------------------
Label Mapping(L2,95,-)
<---------------------------
(4) Address(n/a,29,-)
--------------------------->
(5) Label Request(L4,30,-)
--------------------------->
(6) Keepalive(n/a,31,95) * with FT Cork TLV *
--------------------------->
(7) Label Abort(L3,96,-)
<---------------------------
(8) Keepalive(n/a,97,31) * with FT Cork TLV *
<---------------------------
(9) Keepalive(n/a,-,97) * with FT Cork TLV *
--------------------------->
(10) Notification(Temporary shutdown)
--------------------------->
===== TCP Session shutdown =====
:
: Label Withdraw(L1,59,-)
: <--------------------------
:
===== TCP Session restored =====
(11) LDP Init(n/a,n/a,96)
--------------------------->
LDP Init(n/a,n/a,31)
<---------------------------
Label Withdraw(L1,97,-)
<---------------------------
Notes:
======
Notes:
======
This example operates much as the previous one. However, at (1), (2), (3), (4) and (5), no acknowledgements are made.
此示例的操作与前一个示例相同。然而，在第（1）、（2）、（3）、（4）和（5）条中，未做出任何确认。
At (6), P1 determines that graceful shutdown is required and sends a Keepalive acknowledging all previously received messages and itself containing an FT Protection TLV number and the FT Cork TLV.
在（6）处，P1确定需要正常关机，并发送Keepalive，确认之前接收到的所有消息以及包含FT保护TLV编号和FT Cork TLV的自身。
The Label abort at (7) crosses with this Keepalive, so at (8) P2 sends a Keepalive that acknowledges all messages received so far, but also includes the FT Protection and FT Cork TLVs to indicate that there are still messages outstanding to be acknowledged.
（7）处的标签abort与此Keepalive交叉，因此（8）处的P2发送一个Keepalive，确认迄今为止收到的所有消息，但还包括FT保护和FT Cork TLV，以指示仍有未完成的消息需要确认。
P1 is then able to complete the 3-way handshake at (9) and close the TCP session at (10).
然后，P1能够在（9）处完成三向握手，并在（10）处关闭TCP会话。
Upon recovery at (11), there are no messages to be re-sent because the KeepAlives flushed the acknowledgements. The only messages sent after recovery is the Label Withdraw that was pended during the TCP session failure.
在（11）处恢复时，没有要重新发送的消息，因为KeepAlives刷新了确认。恢复后发送的唯一消息是TCP会话失败期间挂起的标签撤消。
notes P1 P2
===== == ==
(1) Label Request(L1)
--------------------------->
(2) Label Request(L2)
<---------------------------
Label Request(L1)
-------------------------->
Label Mapping(L1)
<--------------------------
(3) Label Mapping(L1)
<---------------------------
(4) Keepalive(n/a,12,-)
--------------------------->
(5) Label Request(L3)
--------------------------->
(6) Keepalive(n/a,-,12)
<---------------------------
Label Request(L3)
-------------------------->
Label Mapping(L3)
<--------------------------
(7) Label Mapping(L3)
<---------------------------
===== TCP Session failure =====
:
:
:
===== TCP Session restored =====
(8) LDP Init(n/a,n/a,23)
--------------------------->
LDP Init(n/a,n/a,12)
<---------------------------
(9) Label Request(L3)
--------------------------->
Label Request(L3)
-------------------------->
Label Mapping(L3)
<--------------------------
(10) Label Mapping(L3)
<---------------------------
(11) Label Request(L2)
<---------------------------
notes P1 P2
===== == ==
(1) Label Request(L1)
--------------------------->
(2) Label Request(L2)
<---------------------------
Label Request(L1)
-------------------------->
Label Mapping(L1)
<--------------------------
(3) Label Mapping(L1)
<---------------------------
(4) Keepalive(n/a,12,-)
--------------------------->
(5) Label Request(L3)
--------------------------->
(6) Keepalive(n/a,-,12)
<---------------------------
Label Request(L3)
-------------------------->
Label Mapping(L3)
<--------------------------
(7) Label Mapping(L3)
<---------------------------
===== TCP Session failure =====
:
:
:
===== TCP Session restored =====
(8) LDP Init(n/a,n/a,23)
--------------------------->
LDP Init(n/a,n/a,12)
<---------------------------
(9) Label Request(L3)
--------------------------->
Label Request(L3)
-------------------------->
Label Mapping(L3)
<--------------------------
(10) Label Mapping(L3)
<---------------------------
(11) Label Request(L2)
<---------------------------
Notes:
======
Notes:
======
(1), (2) and (3) show label distribution without FT sequence numbers.
（1） ，（2）和（3）显示不带FT序列号的标签分布。
(4) A check-Point request from P1. It carries the sequence number of the check-point request.
(4) 来自P1的检查点请求。它携带检查点请求的序列号。
(5) P1 immediately starts a new label distribution request.
(5) P1立即启动新的标签分发请求。
(6) P2 confirms that it has secured all previous transactions.
(6) P2确认其已担保所有以前的交易。
(7) The subsequent (un-acknowledged) label distribution completes.
(7) 随后的（未确认的）标签分发完成。
(8) The session fails and is restarted. Initialization messages confirm the sequence numbers of the secured check-points.
(8) 会话失败并重新启动。初始化消息确认安全检查点的序列号。
(9) P1 recommences the unacknowledged label distribution request.
(9) P1重新开始未确认的标签分发请求。
(10) P2 recommences an unacknowledged label distribution request.
（10） P2重新开始未确认的标签分发请求。
notes P1 P2
===== == ==
(1) Label Request(L1)
--------------------------->
(2) Label Request(L2)
<---------------------------
Label Request(L1)
-------------------------->
Label Mapping(L1)
<--------------------------
(3) Label Mapping(L1)
<---------------------------
(4) Keepalive(n/a,12,23) * With Cork TLV *
--------------------------->
(5) :
:
:
(6) Keepalive(n/a,24,12) * With Cork TLV *
<---------------------------
(7) Keepalive(n/a,-,24) * With Cork TLV *
--------------------------->
(8) Notification(Temporary shutdown)
--------------------------->
===== TCP Session failure =====
:
:
:
===== TCP Session restored =====
(9) LDP Init(n/a,n/a,24)
--------------------------->
LDP Init(n/a,n/a,12)
<---------------------------
(10) Label Request(L3)
--------------------------->
Label Request(L3)
-------------------------->
Label Mapping(L3)
<--------------------------
(11) Label Mapping(L3)
<---------------------------
(12) Label Mapping(L2)
--------------------------->
notes P1 P2
===== == ==
(1) Label Request(L1)
--------------------------->
(2) Label Request(L2)
<---------------------------
Label Request(L1)
-------------------------->
Label Mapping(L1)
<--------------------------
(3) Label Mapping(L1)
<---------------------------
(4) Keepalive(n/a,12,23) * With Cork TLV *
--------------------------->
(5) :
:
:
(6) Keepalive(n/a,24,12) * With Cork TLV *
<---------------------------
(7) Keepalive(n/a,-,24) * With Cork TLV *
--------------------------->
(8) Notification(Temporary shutdown)
--------------------------->
===== TCP Session failure =====
:
:
:
===== TCP Session restored =====
(9) LDP Init(n/a,n/a,24)
--------------------------->
LDP Init(n/a,n/a,12)
<---------------------------
(10) Label Request(L3)
--------------------------->
Label Request(L3)
-------------------------->
Label Mapping(L3)
<--------------------------
(11) Label Mapping(L3)
<---------------------------
(12) Label Mapping(L2)
--------------------------->
Notes:
======
Notes:
======
(1), (2) and (3) show label distribution without FT sequence numbers.
（1） ，（2）和（3）显示不带FT序列号的标签分布。
(4) A check-point request from P1. It carries the sequence number of the check-point request and a Cork TLV.
(4) 来自P1的检查点请求。它携带检查点请求的序列号和软木TLV。
(5) P1 has sent a Cork TLV so quieces.
(5) P1已经发送了一个软木TLV，因此安静。
(6) P2 confirms the check-point and continues the three-way handshake by including a Cork TLV itself.
(6) P2确认检查点，并通过包括软木TLV本身来继续三方握手。
(7) P1 completes the three-way handshake. All operations have now been check-pointed and the session is quiesced.
(7) P1完成三方握手。现在，所有操作都已被选中，会话将停止。
(8) The session is gracefully shut down.
(8) 会话将正常关闭。
(9) The session recovers and the peers exchange the sequence numbers of the last secured check-points.
(9) 会话恢复，对等方交换最后一个安全检查点的序列号。
(10) P1 starts a new label distribution request.
（10） P1启动一个新的标签分发请求。
(11) P1 continues processing a previously received label distribution request.
（11） P1继续处理先前接收到的标签分发请求。
The LDP FT enhancements inherit similar security considerations to those discussed in [RFC3036].
LDP FT增强继承了[RFC3036]中讨论的类似安全注意事项。
The LDP FT enhancements allow the re-establishment of a TCP connection between LDP peers without a full re-exchange of the attributes of established labels, which renders LSRs that implement the extensions specified in this document vulnerable to additional denial-of-service attacks as follows:
LDP FT增强功能允许在LDP对等点之间重新建立TCP连接，而无需完全重新交换已建立标签的属性，这使得实现本文档中指定扩展的LSR容易受到以下附加拒绝服务攻击：
- An intruder may impersonate an LDP peer in order to force a failure and reconnection of the TCP connection, but where the intruder does not set the FT Reconnect Flag upon re-connection. This forces all FT labels to be released.
- 入侵者可以模拟LDP对等方，以强制TCP连接失败和重新连接，但入侵者在重新连接时未设置FT Reconnect标志。这将强制释放所有FT标签。
- Similarly, an intruder could set the FT Reconnect Flag on re-establishment of the TCP session without preserving the state and resources for FT labels.
- 类似地，入侵者可以在重新建立TCP会话时设置FT Reconnect标志，而不保留FT标签的状态和资源。
- An intruder could intercept the traffic between LDP peers and override the setting of the FT Label Flag to be set to 0 for all labels.
- 入侵者可以拦截LDP对等方之间的通信，并覆盖所有标签的FT标签标志设置为0。
All of these attacks may be countered by use of an authentication scheme between LDP peers, such as the MD5-based scheme outlined in [RFC3036].
所有这些攻击都可以通过在LDP对等方之间使用身份验证方案（例如[RFC3036]中概述的基于MD5的方案）来反击。
Alternative authentication schemes for LDP peers are outside the scope of this document, but could be deployed to provide enhanced security to implementations of LDP and the LDP FT enhancements.
LDP对等点的替代身份验证方案不在本文档的范围内，但可以进行部署，以为LDP和LDP FT增强的实现提供增强的安全性。
As with LDP, a security issue may exist if an LDP implementation continues to use labels after expiration of the session that first caused them to be used. This may arise if the upstream LSR detects the session failure after the downstream LSR has released and re-used the label. The problem is most obvious with the platform-wide label space and could result in mis-forwarding of data to other than intended destinations and it is conceivable that these behaviors may be deliberately exploited to either obtain services without authorization or to deny services to others.
与LDP一样，如果LDP实现在第一次使用标签的会话到期后继续使用标签，则可能存在安全问题。如果上游LSR在下游LSR释放并重新使用标签后检测到会话失败，则可能会出现这种情况。该问题在平台范围的标签空间中最为明显，可能会导致将数据错误转发到预期目的地以外的其他目的地，可以想象，这些行为可能被故意利用，以未经授权获取服务或拒绝向其他人提供服务。
In this document, the validity of the session may be extended by the FT Reconnection Timeout, and the session may be re-established in this period. After the expiry of the Reconnection Timeout, the session must be considered to have failed and the same security issue applies as described above.
在本文件中，可通过FT重新连接超时来延长会话的有效性，并可在此期间重新建立会话。在重新连接超时过期后，必须将会话视为已失败，并且如上所述，同样的安全问题也适用。
However, the downstream LSR may declare the session as failed before the expiration of its Reconnection Timeout. This increases the period during which the downstream LSR might reallocate the label while the upstream LSR continues to transmit data using the old usage of the label. To reduce this issue, this document requires that labels not be re-used until the Reconnection Timeout has expired.
但是，下游LSR可能会在其重新连接超时过期之前将会话声明为失败。这增加了当上游LSR继续使用标签的旧用法传输数据时，下游LSR可能重新分配标签的时间段。为了减少此问题，本文档要求在重新连接超时过期之前不要重新使用标签。
A further issue might apply if labels were re-used prior to the expiration of the FT Reconnection Timeout, but this is forbidden by this document.
如果在FT重新连接超时过期之前重新使用标签，则可能会出现另一个问题，但本文档禁止这样做。
The issue of re-use of labels extends to labels managed through other mechanisms including direct configuration through management applications and distribution through other label distribution protocols. Avoiding this problem may be construed as an implementation issue (see below), but failure to acknowledge it could result in the mis-forwarding of data between LSPs established using some other mechanism and those recovered using the methods described in this document.
标签的重用问题扩展到通过其他机制管理的标签，包括通过管理应用程序直接配置和通过其他标签分发协议分发。避免此问题可能会被解释为一个实施问题（见下文），但如果不承认此问题，可能会导致使用其他机制建立的LSP与使用本文档中描述的方法恢复的LSP之间的数据错误转发。
In order to take full advantage of the FT capabilities of LSRs in the network, it may be that an LSR that does not itself contain the ability to recover from local hardware or software faults still needs to support the LDP FT enhancements described in this document.
为了充分利用网络中LSR的FT能力，可能本身不具备从本地硬件或软件故障中恢复能力的LSR仍然需要支持本文档中描述的LDP FT增强功能。
Consider an LSR, P1, that is an LDP peer of a fully Fault Tolerant LSR, P2. If P2 experiences a fault in the hardware or software that serves an LDP session between P1 and P2, it may fail the TCP connection between the peers. When the connection is recovered, the LSPs/labels between P1 and P2 can only be recovered if both LSRs were applying the FT recovery procedures to the LDP session.
考虑一个LSR，P1，这是一个完全容错的LSR，P2的LDP对等点。如果P2在为P1和P2之间的LDP会话提供服务的硬件或软件中出现故障，则可能导致对等方之间的TCP连接失败。恢复连接时，只有当两个LSR都对LDP会话应用FT恢复过程时，P1和P2之间的LSP/标签才能恢复。
FT ACKs SHOULD be returned to the sending LSR as soon as is practicable in order to avoid building up a large quantity of unacknowledged state changes at the LSR. However, immediate one-for-one acknowledgements would waste bandwidth unnecessarily.
FT确认应尽快返回给发送LSR，以避免在LSR上建立大量未确认的状态更改。然而，即时的一对一确认将不必要地浪费带宽。
A possible implementation strategy for sending ACKs to FT LDP messages is as follows:
向FT-LDP消息发送ack的可能实现策略如下：
- An LSR secures received messages in order and tracks the sequence number of the most recently secured message, Sr.
- LSR按顺序保护接收到的消息，并跟踪最近受保护消息Sr的序列号。
- On each LDP KeepAlive that the LSR sends, it attaches an FT ACK TLV listing Sr.
- 在LSR发送的每个LDP KeepAlive上，它附加一个FT ACK TLV清单Sr。
- Optionally, the LSR may attach an FT ACK TLV to any other LDP message sent between Keepalive messages if, for example, Sr has increased by more than a threshold value since the last ACK sent.
- 可选地，LSR可以将FT-ACK TLV附加到在Keepalive消息之间发送的任何其他LDP消息，例如，如果自上次发送ACK以来Sr增加了超过阈值。
This implementation combines the bandwidth benefits of accumulating ACKs while still providing timely ACKs.
此实现结合了累积ack的带宽优势，同时仍然提供及时的ack。
If check-pointing is in use, the LSRs need not be concerned with sending ACKs in such a timely manner.
如果正在使用检查点，则LSR不必关心以如此及时的方式发送ACK。
Check-points are solicitations for acknowledgements conveyed as a sequence number in an FT Protection TLV on a Keepalive message. Such check-point requests could be issued on a timer, after a significant amount of change, or before controlled shutdown of a session.
检查点是对在Keepalive消息上FT保护TLV中作为序列号传输的确认的请求。此类检查点请求可以在大量更改之后或会话受控关闭之前在计时器上发出。
The use of check-pointing may considerably simplify an implementation since it does not need to track the sequence numbers of all received LDP messages. It must, however, still ensure that all received messages (or the consequent state changes) are secured before acknowledging the sequence number on the Keepalive.
由于不需要跟踪所有接收到的LDP消息的序列号，因此使用检查点可以大大简化实现。但是，在确认Keepalive上的序列号之前，它必须确保所有接收到的消息（或随后的状态更改）都是安全的。
This approach may be considered optimal in systems that do not show a high degree of change over time (such as targeted LDP sessions) and that are prepared to risk loss of state for the most recent LDP exchanges. More dynamic systems (such as LDP discovery sessions) are more likely to want to acknowledge state changes more frequently so that the maximum amount of state can be preserved over a failure.
在不随时间发生高度变化（如目标LDP会话）且准备为最近的LDP交换冒失去状态风险的系统中，这种方法可能被认为是最佳的。更具动态性的系统（如LDP发现会话）更可能希望更频繁地确认状态更改，以便在故障期间保留最大数量的状态。
Many LDP LSRs also run other label distribution mechanisms. These include management interfaces for configuration of static label mappings, other distinct instances of LDP, and other label distribution protocols. The last example includes the traffic engineering label distribution protocol that is used to construct tunnels through which LDP LSPs are established.
许多LDP LSR还运行其他标签分发机制。这些包括用于配置静态标签映射的管理接口、LDP的其他不同实例以及其他标签分发协议。最后一个示例包括流量工程标签分发协议，该协议用于构建建立LDP LSP的隧道。
As with re-use of individual labels by LDP within a restarting LDP system, care must be taken to prevent labels that need to be retained by a restarting LDP session or protocol component from being used by another label distribution mechanism since that might compromise data security amongst other things.
与LDP在重新启动的LDP系统内重复使用单个标签一样，必须注意防止需要由重新启动的LDP会话或协议组件保留的标签被另一标签分发机制使用，因为这可能会危及数据安全。
It is a matter for implementations to avoid this issue through the use of techniques such as a common label management component or segmented label spaces.
实现需要通过使用诸如通用标签管理组件或分段标签空间等技术来避免此问题。
The work in this document is based on the LDP ideas expressed by the authors of [RFC3036].
本文件中的工作基于[RFC3036]作者表达的LDP思想。
The ACK scheme used in this document was inspired by the proposal by David Ward and John Scudder for restarting BGP sessions now included in [BGP-RESTART].
本文件中使用的ACK方案受到David Ward和John Scudder关于重新启动BGP会话的建议的启发，该建议现已包含在[BGP-RESTART]中。
The authors would also like to acknowledge the careful review and comments of Nick Weeds, Piers Finlayson, Tim Harrison, Duncan Archer, Peter Ashwood-Smith, Bob Thomas, S. Manikantan, Adam Sheppard, Alan Davey, Iftekhar Hussain and Loa Andersson.
作者还想感谢Nick Weeds、Piers Finlayson、Tim Harrison、Duncan Archer、Peter Ashwood Smith、Bob Thomas、S.Manikantan、Adam Sheppard、Alan Davey、Iftekhar Hussain和Loa Andersson的仔细审查和评论。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information, consult the online list of claimed rights.
IETF已收到关于本文件所含部分或全部规范的知识产权声明。有关更多信息，请查阅在线权利主张列表。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification, RFC 3036, January 2001.
[RFC3036]Andersson，L.，Doolan，P.，Feldman，N.，Fredette，A.和B.Thomas，“LDP规范，RFC 3036，2001年1月。
[RFC3478] Leelanivas, M., Rekhter, Y. and R. Aggrawal, "Graceful Restart Mechanism for Label Distribution Protocol", RFC 3478, February 2003.
[RFC3478]Leelanivas，M.，Rekhter，Y.和R.Agrawal，“标签分发协议的优雅重启机制”，RFC 3478，2003年2月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）——第1版，功能规范”，RFC 22052997年9月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tomassi, F. and S. Molendini, "RSVP Refresh Reduction Extensions", RFC 2961, April 2001.
[RFC2961]Berger，L.，Gan，D.，Swallow，G.，Pan，P.，Tomassi，F.和S.Molendini，“RSVP刷新减少扩展”，RFC 29612001年4月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.和G.Swallow，“LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
[RFC3212]Jamoussi，B.，Andersson，L.，Callon，R.，Dantu，R.，Wu，L.，Doolan，P.，Worster，T.，Feldman，N.，Fredette，A.，Girish，M.，Gray，E.，Heinanen，J.，Kilty，T.和A.Malis，“使用LDP的基于约束的LSP设置”，RFC 3212，2002年1月。
[RFC3214] Ash, G., Lee, Y., Ashwood-Smith, P., Jamoussi, B., Fedyk, D., Skalecki, D. and L. Li, "LSP Modification Using CR-LDP", RFC 3214, January 2001.
[RFC3214]Ash，G.，Lee，Y.，Ashwood Smith，P.，Jamoussi，B.，Fedyk，D.，Skalecki，D.和L.Li，“使用CR-LDP的LSP改性”，RFC 32142001年1月。
[BGP-RESTART] Sangli, S., et al., Graceful Restart Mechanism for BGP, Work in Progress.
[BGP-RESTART]Sangli，S.等人，BGP的优雅重启机制，正在进行中。
Adrian Farrel (editor) Movaz Networks, Inc. 7926 Jones Branch Drive, Suite 615 McLean, VA 22102
阿德里安·法雷尔（编辑）莫瓦兹网络公司，地址：弗吉尼亚州麦克莱恩615室琼斯支路7926号，邮编：22102
Phone: +1 703-847-1867
EMail: afarrel@movaz.com
Phone: +1 703-847-1867
EMail: afarrel@movaz.com
Paul Brittain Data Connection Ltd. Windsor House, Pepper Street, Chester, Cheshire CH1 1DF, UK
Paul Brittain数据连接有限公司，英国柴郡切斯特胡椒街温莎大厦CH1 1DF
Phone: +44-(0)20-8366-1177
EMail: pjb@dataconnection.com
Phone: +44-(0)20-8366-1177
EMail: pjb@dataconnection.com
Philip Matthews Hyperchip 1800 Rene-Levesque Blvd W Montreal, Quebec H3H 2H2 Canada
Philip Matthews Hyperchip 1800 Rene Levesque大道西蒙特利尔，魁北克H3H 2H2加拿大
Phone: +1 514-906-4965
EMail: pmatthews@hyperchip.com
Phone: +1 514-906-4965
EMail: pmatthews@hyperchip.com
Eric Gray
埃里克·格雷
EMail: ewgray@GraIyMage.com
EMail: ewgray@GraIyMage.com
Jack Shaio Vivace Networks 2730 Orchard Parkway San Jose, CA 95134
Jack Shaio Vivace Networks加利福尼亚州圣何塞市果园大道2730号，邮编95134
Phone: +1 408 432 7623
EMail: jack.shaio@vivacenetworks.com
Phone: +1 408 432 7623
EMail: jack.shaio@vivacenetworks.com
Toby Smith Laurel Networks, Inc. 1300 Omega Drive Pittsburgh, PA 15205
托比·史密斯·劳雷尔网络公司，宾夕法尼亚州匹兹堡市欧米茄大道1300号，邮编15205
EMail: tob@laurelnetworks.com
EMail: tob@laurelnetworks.com
Andrew G. Malis Vivace Networks 2730 Orchard Parkway San Jose, CA 95134
加利福尼亚州圣何塞市果园公园路2730号，安德鲁·G·马里斯·维瓦塞网络公司，邮编95134
Phone: +1 408 383 7223
EMail: andy.malis@vivacenetworks.com
Phone: +1 408 383 7223
EMail: andy.malis@vivacenetworks.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。