Network Working Group M. Jork
Request for Comments: 5443 GENBAND
Category: Informational A. Atlas
British Telecom
L. Fang
Cisco Systems, Inc.
March 2009
Network Working Group M. Jork
Request for Comments: 5443 GENBAND
Category: Informational A. Atlas
British Telecom
L. Fang
Cisco Systems, Inc.
March 2009
LDP IGP Synchronization
LDP-IGP同步
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
In certain networks, there is dependency on the edge-to-edge Label Switched Paths (LSPs) setup by the Label Distribution Protocol (LDP), e.g., networks that are used for Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) applications. For such applications, it is not possible to rely on Internet Protocol (IP) forwarding if the MPLS LSP is not operating appropriately. Blackholing of labeled traffic can occur in situations where the Interior Gateway Protocol (IGP) is operational on a link on which LDP is not. While the link could still be used for IP forwarding, it is not useful for MPLS forwarding, for example, MPLS VPN applications or Border Gateway Protocol (BGP) route-free cores. This document describes a mechanism to avoid traffic loss due to this condition without introducing any protocol changes.
在某些网络中，依赖于标签分发协议（LDP）设置的边到边标签交换路径（LSP），例如，用于多协议标签交换（MPLS）虚拟专用网（VPN）应用的网络。对于这样的应用，如果MPLS LSP不能正常工作，则不可能依赖于因特网协议（IP）转发。当内部网关协议（IGP）在LDP未运行的链路上运行时，可能会发生标记流量的黑洞。虽然该链路仍可用于IP转发，但对于MPLS转发（例如，MPLS VPN应用程序或边界网关协议（BGP）无路由核心）而言，它并不有用。本文档描述了一种在不引入任何协议更改的情况下避免由于这种情况而导致通信量丢失的机制。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Proposed Solution ...............................................3
3. Applicability ...................................................4
4. Interaction with TE Tunnels .....................................5
5. Security Considerations .........................................5
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................6
7. Acknowledgments .................................................6
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Proposed Solution ...............................................3
3. Applicability ...................................................4
4. Interaction with TE Tunnels .....................................5
5. Security Considerations .........................................5
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................6
7. Acknowledgments .................................................6
LDP [RFC5036] establishes MPLS LSPs along the shortest path to a destination as determined by IP forwarding. In a common network design, LDP is used to provide Label Switched Paths throughout the complete network domain covered by an IGP such as Open Shortest Path First (OSPF) [RFC2328] or Intermediate System to Intermediate System (IS-IS) [ISO.10589.1992]; i.e., all links in the domain have IGP as well as LDP adjacencies.
LDP[RFC5036]沿着IP转发确定的到目的地的最短路径建立MPLS LSP。在公共网络设计中，LDP用于在IGP覆盖的整个网络域中提供标签交换路径，例如开放最短路径优先（OSPF）[RFC2328]或中间系统到中间系统（is-is）[ISO.10589.1992]；i、 例如，域中的所有链路都具有IGP和LDP邻接。
A variety of services a network provider may want to deploy over an LDP-enabled network depend on the availability of edge-to-edge label switched paths. In a layer 2 (L2) or layer 3 (L3) VPN scenario, for example, a given Provider-Edge (PE) router relies on the availability of a complete MPLS forwarding path to the other PE routers for the VPNs it serves. This means that all the links along the IP shortest path from one PE router to the other need to have operational LDP sessions, and the necessary label binding must have been exchanged over those sessions. If only one link along the IP shortest path is
网络提供商可能希望在支持LDP的网络上部署的各种服务取决于边到边标签交换路径的可用性。例如，在第2层（L2）或第3层（L3）VPN场景中，给定的提供商边缘（PE）路由器依赖于其服务的VPN到其他PE路由器的完整MPLS转发路径的可用性。这意味着从一个PE路由器到另一个PE路由器的IP最短路径上的所有链路都需要具有可操作的LDP会话，并且必须在这些会话上交换必要的标签绑定。如果沿IP最短路径只有一条链路
not covered by an LDP session, a blackhole exists and services depending on MPLS forwarding will fail. This might be a transient or a persistent error condition. Some of the reasons for this could be:
LDP会话未覆盖，存在黑洞，依赖MPLS转发的服务将失败。这可能是暂时的或持续的错误情况。其中一些原因可能是：
- A configuration error.
- 配置错误。
- An implementation bug.
- 一个实现错误。
- The link has just come up and has an IGP adjacency but LDP has either not yet established an adjacency or session, or has not yet distributed all the label bindings.
- 该链接刚刚出现并具有IGP邻接，但LDP要么尚未建立邻接或会话，要么尚未分发所有标签绑定。
The LDP protocol has currently no way to correct the issue. LDP is not a routing protocol; it cannot re-direct traffic to an alternate IGP path.
自民党协议目前无法纠正这一问题。LDP不是路由协议；它无法将流量重新定向到备用IGP路径。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The problem described above exists because LDP is tied to IP-forwarding decisions but no coupling between the IGP and LDP operational state on a given link exists. If IGP is operational on a link but LDP is not, a potential network problem exists. So the solution described by this document is to discourage a link from being used for IP forwarding as long as LDP is not fully operational.
存在上述问题是因为LDP与IP转发决策相关联，但给定链路上的IGP和LDP操作状态之间不存在耦合。如果IGP在链路上运行，而LDP不运行，则存在潜在的网络问题。因此，本文描述的解决方案是，只要LDP不能完全运行，就不要将链路用于IP转发。
This has some similarity to the mechanism specified in [RFC3137], which allows an OSPF router to advertise that it should not be used as a transit router. One difference is that [RFC3137] raises the link costs on all (stub) router links, while the mechanism described here applies on a per-link basis.
这与[RFC3137]中指定的机制有一些相似之处，该机制允许OSPF路由器通告不应将其用作传输路由器。一个区别是[RFC3137]增加了所有（存根）路由器链路的链路成本，而这里描述的机制适用于每个链路。
In detail: when LDP is not "fully operational" (see below) on a given link, the IGP will advertise the link with maximum cost to avoid any transit traffic over it. In the case of OSPF, this cost is LSInfinity (16-bit value 0xFFFF), as proposed in [RFC3137]. In the case of ISIS, the maximum metric value is 2^24-2 (0xFFFFFE). Indeed, if a link is configured with 2^24-1 (the maximum link metric per [RFC5305]), then this link is not advertised in the topology. It is important to keep the link in the topology to allow IP traffic to use the link as a last resort in case of massive failure.
详细说明：当LDP在给定链路上未“完全运行”（见下文）时，IGP将以最大成本宣传该链路，以避免其上的任何过境流量。在OSPF的情况下，如[RFC3137]中所述，此成本为LSInfinity（16位值0xFFFF）。对于ISIS，最大度量值为2^24-2（0xFFFFFE）。事实上，如果链路配置为2^24-1（根据[RFC5305]的最大链路度量），则该链路不会在拓扑中公布。重要的是要将链路保留在拓扑中，以允许IP流量在发生大规模故障时将链路用作最后手段。
LDP is considered fully operational on a link when an LDP hello adjacency exists on it, a suitable associated LDP session (matching the LDP Identifier of the hello adjacency) is established to the peer at the other end of the link, and all label bindings have been exchanged over the session. At the present time, the latter condition cannot generally be verified by a router and some estimation may have to be used. A simple implementation strategy is to use a configurable hold-down timer to allow LDP session establishment before declaring LDP fully operational. The default timer is not defined in this document due to concerns of the large variations of the Label Information Base (LIB) table size and equipment capabilities. In addition, there is a current work in progress on LDP End-of-LIB as specified in [End-of-LIB], which enables the LDP speaker to signal the completion of its initial advertisement following session establishment. When LDP End-of-LIB is implemented, the configurable hold-down timer is no longer needed. The neighbor LDP session is considered fully operational when the End-of-LIB notification message is received.
当链路上存在LDP hello邻接时，LDP被视为在链路上完全可操作，在链路的另一端向对等方建立合适的关联LDP会话（匹配hello邻接的LDP标识符），并且在会话上交换了所有标签绑定。目前，路由器通常无法验证后一种情况，可能需要进行一些估计。一个简单的实现策略是使用一个可配置的保持计时器，在宣布LDP完全运行之前允许建立LDP会话。由于标签信息库（LIB）表大小和设备功能的巨大变化，本文档中未定义默认计时器。此外，如[LIB结束]中所述，目前正在进行LDP LIB结束的工作，这使得LDP演讲者能够在会话建立后发出初始广告完成的信号。当实现LIB的LDP端时，不再需要可配置的保持计时器。当接收到LIB结束通知消息时，邻居LDP会话被认为是完全可操作的。
This is typically sufficient to deal with the link when it is being brought up. LDP protocol extensions to indicate the complete transmission of all currently available label bindings after a session has come up are conceivable, but not addressed in this document.
这通常足以在打开链接时处理该链接。LDP协议扩展可以指示在会话出现后所有当前可用的标签绑定的完整传输，但本文档中没有涉及。
The mechanism described in this document does not entail any protocol changes and is a local implementation issue.
本文件中描述的机制不涉及任何协议变更，属于本地实现问题。
The problem space and solution specified in this document have also been discussed in an IEEE Communications Magazine paper [LDP-Fail-Rec].
本文件中规定的问题空间和解决方案也在IEEE通信杂志论文[LDP Fail Rec]中进行了讨论。
In general, the proposed procedure is applicable in networks where the availability of LDP-signaled MPLS LSPs and avoidance of blackholes for MPLS traffic are more important than always choosing an optimal path for IP-forwarded traffic. Note however that non-optimal IP forwarding only occurs for a short time after a link comes up or when there is a genuine problem on a link. In the latter case, an implementation should issue network management alerts to report the error condition and enable the operator to address it.
一般来说，该方法适用于LDP信号MPLS LSP的可用性和避免MPLS流量黑洞比始终为IP转发流量选择最佳路径更重要的网络。但是请注意，非最佳IP转发仅在链接出现后或当链接上存在真正问题时，才会在短时间内发生。在后一种情况下，实施应发出网络管理警报，以报告错误情况，并使运营商能够解决该问题。
Example network scenarios that benefit from the mechanism described here are MPLS VPNs and BGP-free core network designs where traffic can only be forwarded through the core when LDP forwarding state is available throughout.
受益于本文所述机制的示例网络场景是MPLS VPN和无BGP的核心网络设计，其中当LDP转发状态在整个网络中可用时，流量只能通过核心转发。
The usefulness of this mechanism also depends on the availability of alternate paths with sufficient bandwidth in the network should one link be assigned to the maximum cost due to the unavailability of LDP service over it.
这种机制的有用性还取决于网络中具有足够带宽的备用路径的可用性，如果一条链路由于其上的LDP服务不可用而被分配到最大成本。
On broadcast links with more than one IGP/LDP peer, the cost-out procedure can only be applied to the link as a whole and not to an individual peer. So a policy decision has to be made whether the unavailability of LDP service to one peer should result in the traffic being diverted away from all the peers on the link.
在具有多个IGP/LDP对等点的广播链路上，成本计算过程只能应用于整个链路，而不能应用于单个对等点。因此，必须做出一项政策决定，即LDP服务对一个对等方不可用是否会导致流量从链路上的所有对等方转移出去。
In some networks, LDP is used in conjunction with RSVP-TE, which sets up traffic-engineered tunnels. The path computation for the TE tunnels is based on the TE link cost that is flooded by the IGP in addition to the regular IP link cost. The mechanism described in this document should only be applied to the IP link cost to prevent unnecessary TE tunnel reroutes.
在一些网络中，LDP与RSVP-TE结合使用，后者建立了流量工程隧道。TE隧道的路径计算基于IGP淹没的TE链路成本以及常规IP链路成本。本文档中描述的机制应仅适用于IP链路成本，以防止不必要的TE隧道重新路由。
In order to establish LDP LSPs across a TE tunnel, a targeted LDP session between the tunnel endpoints needs to exist. This presents a problem very similar to the case of a regular LDP session over a link (the case discussed so far): when the TE tunnel is used for IP forwarding, the targeted LDP session needs to be operational to avoid LDP connectivity problems. Again, raising the IP cost of the tunnel while there is no operational LDP session will solve the problem. When there is no IGP adjacency over the tunnel and the tunnel is not advertised as a link into the IGP, this becomes a local issue of the tunnel headend router.
为了跨TE隧道建立LDP LSP，需要在隧道端点之间存在目标LDP会话。这提出了一个与链路上的常规LDP会话（目前讨论的情况）非常类似的问题：当TE隧道用于IP转发时，目标LDP会话需要可操作以避免LDP连接问题。同样，在没有可操作的LDP会话的情况下提高隧道的IP成本将解决问题。当隧道上没有IGP邻接并且隧道没有作为进入IGP的链路进行广告时，这就成为隧道前端路由器的局部问题。
A Denial-of-Service (DoS) attack that brings down LDP service on a link or prevents it from becoming operational on a link could be one possible cause of LDP-related traffic blackholing. This document does not address how to prevent LDP session failure. The mechanism described here prevents the use of the link where LDP is not operational while IGP is. Assigning the IGP cost to maximum on such a link should not introduce new security threats. The operation is internal to the router to allow LDP and IGP to communicate and react. Making many LDP links unavailable, however, is a security threat that can cause dropped traffic due to limited available network capacity. This may be triggered by operational error or implementation error. These errors are considered general security issues and implementors should follow the current best security practice [MPLS-GMPLS-Sec].
拒绝服务（DoS）攻击导致链路上的LDP服务中断或阻止其在链路上运行，可能是导致LDP相关流量黑洞的一个可能原因。本文件不涉及如何防止LDP会话失败。这里描述的机制防止在IGP不工作时使用LDP不工作的链路。在这样的链路上将IGP成本分配到最大值不应引入新的安全威胁。该操作在路由器内部，允许LDP和IGP进行通信和反应。然而，使许多LDP链路不可用是一种安全威胁，由于可用网络容量有限，可能导致流量下降。这可能由操作错误或实施错误触发。这些错误被视为一般安全问题，实施者应遵循当前的最佳安全实践[MPLS GMPLS Sec]。
[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月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.，“LDP规范”，RFC 5036，2007年10月。
[End-of-LIB] Asati, R., LDP End-of-LIB, Work in Progress, January 2009.
[LIB结尾]Asati，R.，自民党LIB结尾，正在进行的工作，2009年1月。
[ISO.10589.1992] International Organization for Standardization, "Intermediate system to intermediate system intra-domain-routing routine information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO Standard 10589, 1992.
[ISO.10589.1992]国际标准化组织，“与提供无连接模式网络服务的协议一起使用的中间系统到中间系统域内路由例行程序信息交换协议（ISO 8473）”，ISO标准10589，1992。
[LDP-Fail-Rec] Fang, L., Atlas, A., Chiussi, F., Kompella, K., and G. Swallow, "LDP Failure Detection and Recovery", IEEE Communications Magazine, Vol.42, No.10, October 2004.
[LDP Fail Rec]Fang，L.，Atlas，A.，Chiussi，F.，Kompella，K.，和G.Swallow，“LDP故障检测和恢复”，IEEE通信杂志，第42卷，第10期，2004年10月。
[MPLS-GMPLS-Sec] Fang. L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, November 2008.
[MPLS GMPLS Sec]方。L.，编辑，“MPLS和GMPLS网络的安全框架”，正在进行的工作，2008年11月。
[RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. McPherson, "OSPF Stub Router Advertisement", RFC 3137, June 2001.
[RFC3137]Retana，A.，Nguyen，L.，White，R.，Zinin，A.，和D.McPherson，“OSPF存根路由器广告”，RFC 3137，2001年6月。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
[RFC5305]Li，T.和H.Smit，“交通工程的IS-IS扩展”，RFC 5305，2008年10月。
The authors would like to thank Bruno Decraene for his in-depth discussion and comments, Dave Ward for his helpful review and input, and Loa Andersson, Ross Callon, Amanda Baber, Francis Dupont, Donald Eastlake, Russ Housley, Pasi Eronen, Dan Romascanu, Bin Mo, Lan Zheng, Bob Thomas, and Dave Ojemann for their reviews and comments.
作者要感谢Bruno DeClaene的深入讨论和评论，感谢Dave Ward的有益评论和投入，感谢Loa Andersson、Ross Callon、Amanda Baber、Francis Dupont、Donald Eastlake、Russ Housley、Pasi Eronen、Dan Romascanu、Bin Mo、Lan Zheng、Bob Thomas和Dave Ojemann的评论和评论。
Authors' Addresses
作者地址
Markus Jork GENBAND 3 Federal St. Billerica, MA 01821 USA
马库斯·乔克·根班德3联邦圣比勒里加，马萨诸塞州01821
EMail: Markus.Jork@genband.com
EMail: Markus.Jork@genband.com
Alia Atlas British Telecom
英国电信公司
EMail: alia.atlas@bt.com
EMail: alia.atlas@bt.com
Luyuan Fang Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA
陆源方思科系统有限公司，美国马萨诸塞州伯斯堡市比弗布鲁克路300号，邮编01719
EMail: lufang@cisco.com
Phone: 1 (978) 936-1633
EMail: lufang@cisco.com
Phone: 1 (978) 936-1633