Network Working Group M. Leelanivas
Request for Comments: 3478 Y. Rekhter
Category: Standards Track Juniper Networks
R. Aggarwal
Redback Networks
February 2003
Network Working Group M. Leelanivas
Request for Comments: 3478 Y. Rekhter
Category: Standards Track Juniper Networks
R. Aggarwal
Redback Networks
February 2003
Graceful Restart Mechanism for Label Distribution Protocol
标签分发协议的优雅重启机制
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes a mechanism that helps to minimize the negative effects on MPLS traffic caused by Label Switching Router's (LSR's) control plane restart, specifically by the restart of its Label Distribution Protocol (LDP) component, on LSRs that are capable of preserving the MPLS forwarding component across the restart.
本文档描述了一种机制，该机制有助于最小化标签交换路由器（LSR）控制平面重启对MPLS流量造成的负面影响，特别是通过重启其标签分发协议（LDP）组件对能够在重启过程中保留MPLS转发组件的LSR造成的负面影响。
The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve forwarding state during LDP restart and those without (although the latter needs to implement only a subset of the mechanism described in this document). Supporting (a subset of) the mechanism described here by the LSRs that can not preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart, but it would minimize the impact if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane and implement the mechanism described here.
本文件中描述的机制适用于所有LSR，包括在LDP重启期间能够保持转发状态的LSR和不具有转发状态的LSR（尽管后者只需要实现本文件中描述的机制的一个子集）。支持LSR在重启期间无法保持其MPLS转发状态的机制（其中的一个子集）不会减少其控制平面重启对MPLS流量造成的负面影响，但如果其邻居能够在重新启动控制平面时保持转发状态，并实现此处描述的机制。
The mechanism makes minimalistic assumptions on what has to be preserved across restart - the mechanism assumes that only the actual MPLS forwarding state has to be preserved; the mechanism does not require any of the LDP-related states to be preserved across the restart.
该机制对重启期间必须保留的内容进行了最低限度的假设——该机制假设只有实际的MPLS转发状态必须保留；该机制不要求在重启过程中保留任何与自民党相关的国家。
The procedures described in this document apply to downstream unsolicited label distribution. Extending these procedures to downstream on demand label distribution is for further study.
本文件中描述的程序适用于下游未经请求的标签分发。将这些程序扩展到下游按需标签分发有待进一步研究。
Specification of Requirements
需求说明
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]中的说明进行解释。
For the sake of brevity in the context of this document, by "the control plane" we mean "the LDP component of the control plane".
为了本文件中的简洁起见，“控制平面”指的是“控制平面的LDP组件”。
For the sake of brevity in the context of this document, by "MPLS forwarding state" we mean either <incoming label -> (outgoing label, next hop)> (non-ingress case), or <FEC->(outgoing label, next hop)> (ingress case) mapping.
为了在本文档的上下文中简洁起见，“MPLS转发状态”指的是<incoming label->（outing label，next hop）>（非入口情况），或<FEC->（outing label，next hop）>（入口情况）映射。
In the case where a Label Switching Router (LSR) could preserve its MPLS forwarding state across restart of its control plane, specifically its LDP component [LDP], it is desirable not to perturb the LSPs going through that LSR (specifically, the LSPs established by LDP). In this document, we describe a mechanism, termed "LDP Graceful Restart", that allows the accomplishment of this goal.
在标签交换路由器（LSR）可以在其控制平面（具体地说是其LDP组件[LDP]）的重新启动期间保持其MPLS转发状态的情况下，希望不干扰通过该LSR的lsp（具体地说，由LDP建立的lsp）。在本文中，我们描述了一种机制，称为“LDP优雅重启”，它允许实现这一目标。
The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve forwarding state during LDP restart and those without (although the latter need to implement only a subset of the mechanism described in this document). Supporting (a subset of) the mechanism described here by the LSRs that can not preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart, but it would minimize the impact if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane and implement the mechanism described here.
本文件中描述的机制适用于所有LSR，包括在LDP重启期间能够保持转发状态的LSR和不具有转发状态的LSR（尽管后者只需要实现本文件中描述的机制的一个子集）。支持LSR在重启期间无法保持其MPLS转发状态的机制（其中的一个子集）不会减少其控制平面重启对MPLS流量造成的负面影响，但如果其邻居能够在重新启动控制平面时保持转发状态，并实现此处描述的机制。
The mechanism makes minimalistic assumptions on what has to be preserved across restart - the mechanism assumes that only the actual MPLS forwarding state has to be preserved. Clearly this is the minimum amount of state that has to be preserved across the restart in order not to perturb the LSPs traversing a restarting LSR. The mechanism does not require any of the LDP-related states to be preserved across the restart.
该机制对重启期间必须保留的内容进行了最低限度的假设——该机制假设只需保留实际的MPLS转发状态。显然，这是在重启过程中必须保持的最小状态量，以避免干扰通过重启LSR的LSP。该机制不要求在重启过程中保留任何与自民党相关的国家。
In the scenario where label binding on an LSR is created/maintained not just by the LDP component of the control plane, but by other protocol components as well (e.g., BGP, RSVP-TE), and the LSR supports restart of the individual components of the control plane that create/maintain label binding (e.g., restart of LDP, but no restart of BGP), the LSR needs to preserve across the restart the information about which protocol has assigned which labels.
在LSR上的标签绑定不仅由控制平面的LDP组件创建/维护，而且还由其他协议组件（例如，BGP、RSVP-TE）创建/维护的场景中，LSR支持重新启动创建/维护标签绑定的控制平面的各个组件（例如，重新启动LDP，但不重新启动BGP），LSR需要在整个重启过程中保留关于哪个协议分配了哪些标签的信息。
The procedures described in this document apply to downstream unsolicited label distribution. Extending these procedures to downstream on demand label distribution is for further study.
本文件中描述的程序适用于下游未经请求的标签分发。将这些程序扩展到下游按需标签分发有待进一步研究。
An LSR indicates that it is capable of supporting LDP Graceful Restart, as defined in this document, by including the Fault Tolerant (FT) Session TLV as an Optional Parameter in the LDP Initialization message. The format of the FT Session TLV is defined in [FT-LDP]. The L (Learn from Network) flag MUST be set to 1, which indicates that the procedures in this document are used. The rest of the FT flags are set to 0 by a sender and ignored on receipt.
LSR表示它能够支持本文档中定义的LDP优雅重启，方法是将容错（FT）会话TLV作为可选参数包含在LDP初始化消息中。FT会话TLV的格式在[FT-LDP]中定义。L（从网络学习）标志必须设置为1，这表示使用了本文档中的程序。其余的FT标志由发送方设置为0，并在收到时忽略。
The value field of the FT Session TLV contains two components that are used by the mechanisms defined in this document: FT Reconnect Timeout, and Recovery Time.
FT会话TLV的值字段包含本文档中定义的机制使用的两个组件：FT重新连接超时和恢复时间。
The FT Reconnect Timeout is the time (in milliseconds) that the sender of the TLV would like the receiver of that TLV to wait after the receiver detects the failure of LDP communication with the sender. While waiting, the receiver SHOULD retain the MPLS forwarding state for the (already established) LSPs that traverse a link between the sender and the receiver. The FT Reconnect Timeout should be long enough to allow the restart of the control plane of the sender of the TLV, and specifically its LDP component to bring it to the state where the sender could exchange LDP messages with its neighbors.
FT Reconnect Timeout是TLV的发送方希望该TLV的接收方在接收方检测到与发送方的LDP通信失败后等待的时间（以毫秒为单位）。在等待时，接收方应为（已建立的）LSP保留MPLS转发状态，该LSP穿过发送方和接收方之间的链路。FT重新连接超时应足够长，以允许重新启动TLV发送方的控制平面，特别是其LDP组件，使其达到发送方可以与其邻居交换LDP消息的状态。
Setting the FT Reconnect Timeout to 0 indicates that the sender of the TLV will not preserve its forwarding state across the restart, yet the sender supports the procedures, defined in Section 3.3, "Restart of LDP communication with a neighbor LSR" of this document, and therefore could take advantage if its neighbor to preserve its forwarding state across the restart.
将FT Reconnect Timeout设置为0表示TLV的发送方不会在重启期间保持其转发状态，但发送方支持本文件第3.3节“重启LDP与邻居LSR的通信”中定义的程序，因此，如果其邻居在重启过程中保持其转发状态，则可以利用此漏洞。
For a restarting LSR, the Recovery Time carries the time (in milliseconds) the LSR is willing to retain its MPLS forwarding state that it preserved across the restart. The time is from the moment the LSR sends the Initialization message that carries the FT Session
对于重新启动的LSR，恢复时间包含LSR愿意在重新启动期间保留其MPLS转发状态的时间（以毫秒为单位）。该时间从LSR发送承载FT会话的初始化消息的时刻开始计算
TLV after restart. Setting this time to 0 indicates that the MPLS forwarding state was not preserved across the restart (or even if it was preserved, is no longer available).
重新启动后的TLV。将此时间设置为0表示MPLS转发状态在重新启动过程中未被保留（或者即使已保留，也不再可用）。
The Recovery Time SHOULD be long enough to allow the neighboring LSR's to re-sync all the LSP's in a graceful manner, without creating congestion in the LDP control plane.
恢复时间应足够长，以允许相邻LSR以优雅的方式重新同步所有LSP，而不会在LDP控制平面中造成拥塞。
An LSR that supports functionality described in this document advertises this to its LDP neighbors by carrying the FT Session TLV in the LDP Initialization message.
支持本文档所述功能的LSR通过在LDP初始化消息中携带FT会话TLV向其LDP邻居播发此消息。
This document assumes that in certain situations, as specified in section 3.1.2, "Egress LSR", in addition to the MPLS forwarding state, an LSR can also preserve its IP forwarding state across the restart. Procedures for preserving an IP forwarding state across the restart are defined in [OSPF-RESTART], [ISIS-RESTART], and [BGP-RESTART].
本文件假设在某些情况下，如第3.1.2节“出口LSR”所述，除MPLS转发状态外，LSR还可以在重启期间保持其IP转发状态。[OSPF-restart]、[ISIS-restart]和[BGP-restart]中定义了在重启期间保持IP转发状态的过程。
After an LSR restarts its control plane, the LSR MUST check whether it was able to preserve its MPLS forwarding state from prior to the restart. If not, then the LSR sets the Recovery Time to 0 in the FT Session TLV the LSR sends to its neighbors.
LSR重新启动其控制平面后，LSR必须检查是否能够在重新启动之前保持其MPLS转发状态。如果没有，则LSR将LSR发送给其邻居的FT会话TLV中的恢复时间设置为0。
If the forwarding state has been preserved, then the LSR starts its internal timer, called MPLS Forwarding State Holding timer (the value of that timer SHOULD be configurable), and marks all the MPLS forwarding state entries as "stale". At the expiration of the timer, all the entries still marked as stale SHOULD be deleted. The value of the Recovery Time advertised in the FT Session TLV is set to the (current) value of the timer at the point in which the Initialization message carrying the FT Session TLV is sent.
如果转发状态已被保留，则LSR启动其内部计时器，称为MPLS转发状态保持计时器（该计时器的值应可配置），并将所有MPLS转发状态条目标记为“过时”。计时器过期时，应删除所有仍标记为过时的条目。在FT会话TLV中公布的恢复时间的值被设置为发送携带FT会话TLV的初始化消息时计时器的（当前）值。
We say that an LSR is in the process of restarting when the MPLS Forwarding State Holding timer is not expired. Once the timer expires, we say that the LSR completed its restart.
我们说，当MPLS转发状态保持计时器未过期时，LSR正在重新启动。一旦计时器过期，我们就说LSR完成了重启。
The following procedures apply when an LSR is in the process of restarting.
当LSR正在重新启动时，以下步骤适用。
If the label carried in the newly received Mapping message is not an Implicit NULL, the LSR searches its MPLS forwarding state for an
如果新接收到的映射消息中携带的标签不是隐式NULL，则LSR将在其MPLS转发状态中搜索标签
entry with the outgoing label equal to the label carried in the message, and the next hop equal to one of the addresses (next hops) received in the Address message from the peer. If such an entry is found, the LSR no longer marks the entry as stale. In addition, if the entry is of type <incoming label, (outgoing label, next hop)> (rather than <FEC, (outgoing label, next hop)>), the LSR associates the incoming label from that entry with the FEC received in the Label Mapping message, and advertises (via LDP) <incoming label, FEC> to its neighbors. If the found entry has no incoming label, or if no entry is found, the LSR follows the normal LDP procedures. (Note that this paragraph describes the scenario where the restarting LSR is neither the egress, nor the penultimate hop that uses penultimate hop popping for a particular LSP. Note also that this paragraph covers the case where the restarting LSR is the ingress.)
输出标签等于消息中携带的标签，下一个跃点等于地址消息中从对等方接收的地址之一（下一个跃点）。如果找到这样的条目，LSR将不再将该条目标记为过时。此外，如果条目的类型为<incoming label，（outing label，next hop）>（而不是<FEC，（outing label，next hop）>），则LSR将来自该条目的传入标签与在标签映射消息中接收的FEC相关联，并（通过LDP）向其邻居播发<incoming label，FEC>。如果找到的条目没有传入标签，或者没有找到条目，则LSR遵循正常LDP过程。（请注意，本段描述了重新启动的LSR既不是出口，也不是为特定LSP使用倒数第二跳弹出的倒数第二跳的场景。还请注意，本段涵盖了重新启动的LSR是入口的情况。）
If the label carried in the Mapping message is an Implicit NULL label, the LSR searches its MPLS forwarding state for an entry that indicates Label pop (means no outgoing label), and the next hop equal to one of the addresses (next hops) received in the Address message from the peer. If such an entry is found, the LSR no longer marks the entry as stale, the LSR associates the incoming label from that entry with the FEC received in the Label Mapping message from the neighbor, and advertises (via LDP) <incoming label, FEC> to its neighbors. If the found entry has no incoming label, or if no entry is found, the LSR follows the normal LDP procedures. (Note that this paragraph describes the scenario where the restarting LSR is a penultimate hop for a particular LSP, and this LSP uses penultimate hop popping.)
如果映射消息中携带的标签是隐式空标签，则LSR将在其MPLS转发状态中搜索一个条目，该条目指示标签pop（表示没有传出标签），并且下一个跃点等于地址消息中从对等方接收的地址之一（下一个跃点）。如果找到这样的条目，则LSR不再将该条目标记为过时，LSR将来自该条目的传入标签与在标签映射消息中从邻居接收到的FEC相关联，并（通过LDP）<incoming label，FEC>向其邻居播发。如果找到的条目没有传入标签，或者没有找到条目，则LSR遵循正常LDP过程。（请注意，本段描述了重新启动LSR是特定LSP的倒数第二个跃点，并且此LSP使用倒数第二个跃点弹出的场景。）
The description in the above paragraph assumes that the restarting LSR generates the same label for all the LSPs that terminate on the same LSR (different from the restarting LSR), and for which the restarting LSR is a penultimate hop. If this is not the case, and the restarting LSR generates a unique label per each such LSP, then the LSR needs to preserve across the restart, not just the <incoming label, (outgoing label, next hop)> mapping, but also the FEC associated with this mapping. In such case, the LSR searches its MPLS forwarding state for an entry that (a) indicates Label pop (means no outgoing label), (b) indicates the next hop equal to one of the addresses (next hops) received in the Address message from the peer, and (c) has the same FEC as the one received in the Label Mapping message. If such an entry is found, the LSR no longer marks the entry as stale, the LSR associates the incoming label from that entry with the FEC received in the Label Mapping message from the neighbor, and advertises (via LDP) <incoming label, FEC> to its neighbors. If the found entry has no incoming label, or if no entry is found, the LSR follows the normal LDP procedures.
上述段落中的描述假设重启LSR为终止于同一LSR（不同于重启LSR）且重启LSR为倒数第二跳的所有LSP生成相同的标签。如果情况并非如此，并且重新启动的LSR为每个这样的LSP生成一个唯一的标签，那么LSR需要在整个重新启动过程中保留，不仅是<incoming label，（outing label，next hop）>映射，而且还保留与该映射相关联的FEC。在这种情况下，LSR在其MPLS转发状态中搜索以下条目：（a）指示标签pop（意味着没有传出标签），（b）指示下一跳等于在地址消息中从对等方接收的地址之一（下一跳），并且（c）具有与在标签映射消息中接收的相同FEC。如果找到这样的条目，则LSR不再将该条目标记为过时，LSR将来自该条目的传入标签与在标签映射消息中从邻居接收到的FEC相关联，并（通过LDP）<incoming label，FEC>向其邻居播发。如果找到的条目没有传入标签，或者没有找到条目，则LSR遵循正常LDP过程。
If an LSR determines that it is an egress for a particular FEC, the LSR is configured to generate a non-NULL label for that FEC, and that the LSR is configured to generate the same (non-NULL) label for all the FECs that share the same next hop and for which the LSR is an egress, the LSR searches its MPLS forwarding state for an entry that indicates Label pop (means no outgoing label), and the next hop equal to the next hop for that FEC. (Determining the next hop for the FEC depends on the type of the FEC. For example, when the FEC is an IP address prefix, the next hop for that FEC is determined from the IP forwarding table.) If such an entry is found, the LSR no longer marks this entry as stale, the LSR associates the incoming label from that entry with the FEC, and advertises (via LDP) <incoming label, FEC> to its neighbors. If the found entry has no incoming label, or if no entry is found, the LSR follows the normal LDP procedures.
如果LSR确定它是特定FEC的出口，则LSR被配置为为为该FEC生成非空标签，并且LSR被配置为为为共享相同下一跳且LSR是出口的所有FEC生成相同（非空）标签，LSR在其MPLS转发状态中搜索一个条目，该条目指示标签pop（表示没有传出标签），并且下一跳等于该FEC的下一跳。（确定FEC的下一个跃点取决于FEC的类型。例如，当FEC是IP地址前缀时，该FEC的下一个跃点由IP转发表确定。）如果找到这样的条目，LSR将不再将该条目标记为过时，LSR将来自该条目的传入标签与FEC关联，并播发（通过LDP）<incoming label，FEC>发送给它的邻居。如果找到的条目没有传入标签，或者如果没有找到条目，LSR将遵循正常的LDP过程。
If an LSR determines that it is an egress for a particular FEC, the LSR is configured to generate a non-NULL label for that FEC, and that the LSR is configured to generate a unique label for each such FEC, then the LSR needs to preserve across the restart, not just the <incoming label, (outgoing label, next hop)> mapping, but also the FEC associated with this mapping. In such case, the LSR would search its MPLS forwarding state for an entry that indicates Label pop (means no outgoing label), and the next hop equal to the next hop for that FEC associated with the entry (Determining the next hop for the FEC depends on the type of the FEC. For example, when the FEC is an IP address prefix, the next hop for that FEC is determined from the IP forwarding table.) If such an entry is found, the LSR no longer marks this entry as stale, the LSR associates the incoming label from that entry with the FEC, and advertises (via LDP) <incoming label, FEC> to its neighbors. If the found entry has no incoming label, or if no entry is found, the LSR follows the normal LDP procedures.
如果LSR确定它是特定FEC的出口，则LSR被配置为为为该FEC生成非空标签，并且LSR被配置为为为每个这样的FEC生成唯一标签，则LSR需要在重启期间保留，而不仅仅是<传入标签，（传出标签，下一跳）>映射，还有与此映射相关联的FEC。在这种情况下，LSR将在其MPLS转发状态中搜索指示标签pop（意味着没有传出标签）的条目，并且下一跳等于与该条目相关联的FEC的下一跳（确定FEC的下一个跃点取决于FEC的类型。例如，当FEC是IP地址前缀时，该FEC的下一个跃点由IP转发表确定。）如果找到这样的条目，LSR将不再将该条目标记为过时，LSR将来自该条目的传入标签与FEC关联，并播发（通过LDP）<incoming label，FEC>发送给它的邻居。如果找到的条目没有传入标签，或者如果没有找到条目，LSR将遵循正常的LDP过程。
If an LSR determines that it is an egress for a particular FEC, and the LSR is configured to generate a NULL (either Explicit or Implicit) label for that FEC, the LSR just advertises (via LDP) such label (together with the FEC) to its neighbors.
如果LSR确定它是特定FEC的出口，并且LSR被配置为为为该FEC生成空（显式或隐式）标签，则LSR仅（通过LDP）向其邻居播发该标签（连同FEC）。
In this section we describe an alternative to the procedures described in Section 3.1, "Procedures for the restarting LSR".
在本节中，我们介绍了第3.1节“LSR重启程序”中所述程序的替代方案。
The procedures described in this section assumes that the restarting LSR has (at least) as many unallocated as allocated labels. The latter form the MPLS forwarding state that the LSR managed to preserve across the restart.
本节中描述的过程假设重新启动的LSR具有（至少）与已分配标签一样多的未分配标签。后者形成了LSR在重启期间设法保持的MPLS转发状态。
After an LSR restarts its control plane, the LSR MUST check whether it was able to preserve its MPLS forwarding state from prior to the restart. If no, then the LSR sets the Recovery Time to 0 in the FT Session TLV the LSR sends to its neighbors.
LSR重新启动其控制平面后，LSR必须检查是否能够在重新启动之前保持其MPLS转发状态。如果否，则LSR在向其邻居发送的FT会话TLV中将恢复时间设置为0。
If the forwarding state has been preserved, then the LSR starts its internal timer, called MPLS Forwarding State Holding timer (the value of that timer SHOULD be configurable), and marks all the MPLS forwarding state entries as "stale". At the expiration of the timer, all the entries still marked as stale SHOULD be deleted. The value of the Recovery Time advertised in the FT Session TLV is set to the (current) value of the timer at the point when the Initialization message carrying the FT Session TLV is sent.
如果转发状态已被保留，则LSR启动其内部计时器，称为MPLS转发状态保持计时器（该计时器的值应可配置），并将所有MPLS转发状态条目标记为“过时”。计时器过期时，应删除所有仍标记为过时的条目。FT会话TLV中公布的恢复时间值设置为发送携带FT会话TLV的初始化消息时计时器的（当前）值。
We say that an LSR is in the process of restarting when the MPLS Forwarding State Holding timer is not expired. Once the timer expires, we say that the LSR completed its restart.
我们说，当MPLS转发状态保持计时器未过期时，LSR正在重新启动。一旦计时器过期，我们就说LSR完成了重启。
While an LSR is in the process of restarting, the LSR creates local label binding by following the normal LDP procedures.
当LSR正在重新启动时，LSR会按照正常LDP过程创建本地标签绑定。
Note that while an LSR is in the process of restarting, the LSR may have not one, but two local label bindings for a given FEC - one that was retained from prior to restart, and another that was created after the restart. Once the LSR completes its restart, the former will be deleted. Both of these bindings though would have the same outgoing label (and the same next hop).
请注意，当LSR处于重新启动过程中时，对于给定的FEC，LSR可能没有一个本地标签绑定，而是有两个本地标签绑定—一个是在重新启动之前保留的，另一个是在重新启动之后创建的。一旦LSR完成重启，前者将被删除。不过，这两个绑定将具有相同的传出标签（和相同的下一跳）。
When an LSR detects that its LDP session with a neighbor went down, and the LSR knows that the neighbor is capable of preserving its MPLS forwarding state across the restart (as was indicated by the FT Session TLV in the Initialization message received from the neighbor), the LSR retains the label-FEC bindings received via that session (rather than discarding the bindings), but marks them as "stale".
当LSR检测到其与邻居的LDP会话中断，并且LSR知道邻居能够在重启期间保持其MPLS转发状态（如从邻居接收的初始化消息中的FT会话TLV所示），LSR将保留通过该会话接收的标签FEC绑定（而不是丢弃绑定），但将其标记为“过时”。
After detecting that the LDP session with the neighbor went down, the LSR tries to re-establish LDP communication with the neighbor following the usual LDP procedures.
在检测到与邻居的LDP会话中断后，LSR尝试按照通常的LDP过程与邻居重新建立LDP通信。
The amount of time the LSR keeps its stale label-FEC bindings is set to the lesser of the FT Reconnect Timeout, as was advertised by the neighbor, and a local timer, called the Neighbor Liveness Timer. If within that time the LSR still does not establish an LDP session with the neighbor, all the stale bindings SHOULD be deleted. The Neighbor
LSR保持其过时标签FEC绑定的时间量设置为FT重新连接超时（由邻居通告）和本地计时器（称为邻居活动计时器）中的较小值。如果在这段时间内，LSR仍未与邻居建立LDP会话，则应删除所有过时的绑定。邻居
Liveness Timer is started when the LSR detects that its LDP session with the neighbor went down. The value of the Neighbor Liveness timer SHOULD be configurable.
当LSR检测到其与邻居的LDP会话中断时，活跃度计时器启动。邻居活跃度计时器的值应该是可配置的。
If the LSR re-establishes an LDP session with the neighbor within the lesser of the FT Reconnect Timeout and the Neighbor Liveness Timer, and the LSR determines that the neighbor was not able to preserve its MPLS forwarding state, the LSR SHOULD immediately delete all the stale label-FEC bindings received from that neighbor. If the LSR determines that the neighbor was able to preserve its MPLS forwarding state (as was indicated by the non-zero Recovery Time advertised by the neighbor), the LSR SHOULD further keep the stale label-FEC bindings, received from the neighbor, for as long as the lesser of the Recovery Time advertised by the neighbor, and a local configurable value, called Maximum Recovery Time, allows.
如果LSR在FT Reconnect Timeout和neighbor Liveness Timer中的较小值内与邻居重新建立LDP会话，并且LSR确定邻居无法保持其MPLS转发状态，则LSR应立即删除从该邻居接收的所有过时标签FEC绑定。如果LSR确定邻居能够保持其MPLS转发状态（如邻居通告的非零恢复时间所示），则LSR应进一步保持从邻居接收的过时标签FEC绑定，只要邻居通告的恢复时间较短，本地可配置值（称为最大恢复时间）允许。
The LSR SHOULD try to complete the exchange of its label mapping information with the neighbor within 1/2 of the Recovery Time, as specified in the FT Session TLV received from the neighbor.
按照从邻居接收的FT会话TLV中的规定，LSR应尝试在恢复时间的1/2内完成与邻居的标签映射信息交换。
The LSR handles the Label Mapping messages received from the neighbor by following the normal LDP procedures, except that (a) it treats the stale entries in its Label Information Base (LIB) as if these entries have been received over the (newly established) session, (b) if the label-FEC binding carried in the message is the same as the one that is present in the LIB, but is marked as stale, the LIB entry is no longer marked as stale, and (c) if for the FEC in the label-FEC binding carried in the message there is already a label-FEC binding in the LIB that is marked as stale, and the label in the LIB binding is different from the label carried in the message, the LSR just updates the LIB entry with the new label.
LSR通过遵循正常LDP过程来处理从邻居接收的标签映射消息，除了（a）它将标签信息库（LIB）中的过时条目视为这些条目是通过（新建立的）会话接收的，（b）如果消息中携带的标签FEC绑定与LIB中存在的标签FEC绑定相同，但标记为陈旧，则LIB条目不再标记为陈旧，并且（c）如果消息中携带的标签FEC绑定中的FEC在LIB中已经存在标记为陈旧的标签FEC绑定，并且LIB绑定中的标签与消息中携带的标签不同，LSR只是用新标签更新LIB条目。
An LSR, once it creates a <label, FEC> binding, SHOULD keep the value of the label in this binding for as long as the LSR has a route to the FEC in the binding. If the route to the FEC disappears, and then re-appears again later, this may result in using a different label value, as when the route re-appears, the LSR would create a new <label, FEC> binding.
LSR一旦创建<label，FEC>绑定，就应该在该绑定中保留标签的值，只要LSR在绑定中有到FEC的路由。如果到FEC的路由消失，然后稍后再次出现，这可能会导致使用不同的标签值，因为当路由重新出现时，LSR将创建一个新的<label，FEC>绑定。
To minimize the potential mis-routing caused by the label change when creating a new <label, FEC> binding, the LSR SHOULD pick up the least recently used label. Once an LSR releases a label, the LSR SHOULD NOT re-use this label for advertising a <label, FEC> binding to a neighbor that supports graceful restart for at least the sum of the FT Reconnect Timeout plus Recovery Time, as advertised by the neighbor to the LSR.
为了在创建新的<label，FEC>绑定时最大限度地减少标签更改导致的潜在错误路由，LSR应选择最近使用最少的标签。一旦LSR释放标签，LSR就不应重复使用此标签来公布与邻居的<label，FEC>绑定，该绑定至少支持FT重新连接超时加上恢复时间的总和，如邻居向LSR公布的。
The security considerations pertaining to the original LDP protocol [RFC3036] remain relevant.
与原始LDP协议[RFC3036]相关的安全注意事项仍然相关。
In addition, LSRs that implement the mechanism described here are subject to to additional denial-of-service attacks as follows:
此外，实现此处所述机制的LSR还可能遭受以下其他拒绝服务攻击：
An intruder may impersonate an LDP peer in order to force a failure and reconnection of the TCP connection, but where the intruder sets the Recovery Time to 0 on reconnection. This forces all labels received from the peer to be released.
入侵者可以模拟LDP对等方，以强制TCP连接失败和重新连接，但入侵者在重新连接时将恢复时间设置为0。这将强制释放从对等方接收的所有标签。
An intruder could intercept the traffic between LDP peers and override the setting of the Recovery Time to be set to 0. This forces all labels received from the peer to be released.
入侵者可以拦截LDP对等方之间的通信，并覆盖将恢复时间设置为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 [LDP].
所有这些攻击都可以通过在LDP对等方之间使用身份验证方案来反击，例如[LDP]中概述的基于MD5的方案。
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-routing 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 Reconnect 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.
在本文档中，会话的有效性可以通过重新连接超时来延长，并且会话可以在此期间重新建立。在重新连接超时过期后，必须将会话视为已失败，并且如上所述，同样的安全问题也适用。
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 at least the sum of Reconnect Timeout plus Recovery Time.
但是，下游LSR可能会在其重新连接超时过期之前将会话声明为失败。这增加了当上游LSR继续使用标签的旧用法传输数据时，下游LSR可能重新分配标签的时间段。为了减少此问题，本文档要求至少在重新连接超时加上恢复时间之和之前，标签不得重复使用。
This section is taken from Section 10.4 of [RFC2026].
本节摘自[RFC2026]第10.4节。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
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已收到关于本文件所含部分或全部规范的知识产权声明。有关更多信息，请查阅在线权利主张列表。
We would like to thank Loa Andersson, Chaitanya Kodeboyina, Ina Minei, Nischal Sheth, Enke Chen, and Adrian Farrel for their contributions to this document.
我们要感谢Loa Andersson、Chaitanya Kodeboyina、Ina Minei、Nischal Sheth、Enke Chen和Adrian Farrel对本文件的贡献。
[LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "Label Distribution Protocol", RFC 3036, January 2001.
[LDP]Andersson，L.，Doolan，P.，Feldman，N.，Fredette，A.和B.Thomas，“标签分发协议”，RFC 3036，2001年1月。
[FT-LDP] Farrel, A., "Fault Tolerance for the Label Distribution Protocol (LDP)", RFC 3479, February 2003.
[FT-LDP]Farrel，A.，“标签分发协议（LDP）的容错”，RFC 3479，2003年2月。
[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月。
[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月。
[OSPF-RESTART] "Hitless OSPF Restart", Work in Progress.
[OSPF-RESTART]“无故障OSPF重启”，工作正在进行中。
[ISIS-RESTART] "Restart signaling for ISIS", Work in Progress.
[ISIS-RESTART]“ISIS的重启信令”，正在进行中。
[BGP-RESTART] "Graceful Restart Mechanism for BGP", Work in Progress.
[BGP-RESTART]“BGP的优雅重启机制”，工作正在进行中。
Manoj Leelanivas Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089
加利福尼亚州桑尼维尔马蒂尔达大道北1194号马诺伊·利拉尼瓦斯·朱尼珀网络公司，邮编94089
EMail: manoj@juniper.net
EMail: manoj@juniper.net
Yakov Rekhter Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089
加利福尼亚州桑尼维尔马蒂尔达大道北1194号雅科夫·雷克特·朱尼珀网络公司，邮编94089
EMail: yakov@juniper.net
EMail: yakov@juniper.net
Rahul Aggarwal Redback Networks 350 Holger Way San Jose, CA 95134
拉胡尔·阿加瓦尔红背网络公司加利福尼亚州圣何塞霍尔格路350号，邮编95134
EMail: rahul@redback.com
EMail: rahul@redback.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编辑功能的资金目前由互联网协会提供。