Network Working Group B. Decraene
Request for Comments: 5283 JL. Le Roux
Category: Standards Track France Telecom
I. Minei
Juniper Networks, Inc.
July 2008
Network Working Group B. Decraene
Request for Comments: 5283 JL. Le Roux
Category: Standards Track France Telecom
I. Minei
Juniper Networks, Inc.
July 2008
LDP Extension for Inter-Area Label Switched Paths (LSPs)
用于区域间标签交换路径（LSP）的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）。本备忘录的分发不受限制。
Abstract
摘要
To facilitate the establishment of Label Switched Paths (LSPs) that would span multiple IGP areas in a given Autonomous System (AS), this document describes a new optional Longest-Match Label Mapping Procedure for the Label Distribution Protocol (LDP).
为了便于在给定自治系统（AS）中建立跨越多个IGP区域的标签交换路径（LSP），本文件描述了标签分发协议（LDP）的新可选最长匹配标签映射程序。
This procedure allows the use of a label if the Forwarding Equivalence Class (FEC) Element matches an entry in the Routing Information Base (RIB). Matching is defined by an IP longest-match search and does not mandate an exact match.
如果转发等价类（FEC）元素与路由信息库（RIB）中的条目匹配，则此过程允许使用标签。匹配由IP最长匹配搜索定义，并不要求精确匹配。
Table of Contents
目录
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. Terminology .....................................................2
4. Problem Statement ...............................................3
5. Longest-Match Label Mapping Message Procedure ...................4
6. Application Examples ............................................6
6.1. Inter-Area LSPs ............................................6
6.2. Use of Static Routes .......................................7
7. Caveats for Deployment ..........................................8
7.1. Deployment Considerations ..................................8
7.2. Routing Convergence Time Considerations ....................8
8. Security Considerations .........................................9
9. References ......................................................9
9.1. Normative References .......................................9
9.2. Informative References .....................................9
10. Acknowledgments ...............................................11
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. Terminology .....................................................2
4. Problem Statement ...............................................3
5. Longest-Match Label Mapping Message Procedure ...................4
6. Application Examples ............................................6
6.1. Inter-Area LSPs ............................................6
6.2. Use of Static Routes .......................................7
7. Caveats for Deployment ..........................................8
7.1. Deployment Considerations ..................................8
7.2. Routing Convergence Time Considerations ....................8
8. Security Considerations .........................................9
9. References ......................................................9
9.1. Normative References .......................................9
9.2. Informative References .....................................9
10. Acknowledgments ...............................................11
Link state Interior Gateway Protocols (IGPs) such as OSPF [OSPFv2] and IS-IS [IS-IS] allow the partition of an autonomous system into areas or levels so as to increase routing scalability within a routing domain.
诸如OSPF[OSPFv2]和IS-IS[IS-IS]之类的链路状态内部网关协议（igp）允许将自治系统划分为多个区域或级别，以便提高路由域内的路由可伸缩性。
However, [LDP] recommends that the IP address of the FEC Element should *exactly* match an entry in the IP Routing Information Base (RIB). According to [LDP], section 3.5.7.1 ("Label Mapping Messages Procedures"):
然而，[LDP]建议FEC元素的IP地址应与IP路由信息库（RIB）中的条目完全匹配。根据[LDP]第3.5.7.1节（“标签映射消息程序”）：
An LSR [Label Switching Router] receiving a Label Mapping message from a downstream LSR for a Prefix SHOULD NOT use the label for forwarding unless its routing table contains an entry that exactly matches the FEC Element.
从下游LSR接收前缀标签映射消息的LSR[标签交换路由器]不应使用标签进行转发，除非其路由表包含与FEC元素完全匹配的条目。
Therefore, MPLS LSPs between Label Edge Routers (LERs) in different areas/levels are not set up unless the specific (e.g., /32 for IPv4) loopback addresses of all the LERs are redistributed across all areas.
因此，不同区域/级别的标签边缘路由器（LER）之间的MPLS LSP不会设置，除非所有LER的特定（例如，IPv4为/32）环回地址在所有区域中重新分配。
The problem statement is discussed in section 4. Then, in section 5 we extend the Label Mapping Procedure defined in [LDP] so as to support the setup of contiguous inter-area LSPs while maintaining IP prefix aggregation on the ABRs. This consists of allowing for longest-match-based Label Mapping.
问题陈述将在第4节中讨论。然后，在第5节中，我们扩展了[LDP]中定义的标签映射过程，以便在保持ABR上的IP前缀聚合的同时支持相邻区域间LSP的设置。这包括允许最长的基于匹配的标签映射。
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]中所述进行解释。
IGP Area: OSPF Area or IS-IS level
IGP区域：OSPF区域或IS-IS级别
ABR: OSPF Area Border Router or IS-IS L1/L2 router
ABR:OSPF区域边界路由器或IS-IS L1/L2路由器
LSP: Label Switched Path
标签交换路径
Intra-area LSP: LSP that does not traverse any IGP area boundary.
区域内LSP：不穿过任何IGP区域边界的LSP。
Inter-area LSP: LSP that traverses at least one IGP area boundary.
区域间LSP：至少穿过一个IGP区域边界的LSP。
Provider-based MPLS (Multiprotocol Label Switching) networks are expanding with the success of Layer 3 Virtual Private Networks [L3-VPN] and the new deployments of Layer 2 VPNs ([VPLS-BGP], [VPLS-LDP]). Service providers' MPLS backbones are significantly growing both in terms of density with the addition of Provider Edge (PE) routers to connect new customers and in terms of footprint as traditional Layer 2 aggregation networks may be replaced by IP/MPLS networks. As a consequence many providers need to introduce IGP areas. Inter-area LSPs (that is, LSPs that traverse at least two IGP areas) are required to ensure MPLS connectivity between PEs located in distinct IGP areas.
随着第三层虚拟专用网络[L3-VPN]的成功和第二层VPN（[VPLS-BGP]，[VPLS-LDP]）的新部署，基于提供商的MPLS（多协议标签交换）网络正在扩展。服务提供商的MPLS主干网无论是在密度方面，还是在占地面积方面，都在显著增长，因为传统的第2层聚合网络可能会被IP/MPLS网络所取代，这两个方面都在增加提供商边缘（PE）路由器以连接新客户。因此，许多供应商需要引入IGP区域。需要区域间LSP（即，穿过至少两个IGP区域的LSP），以确保位于不同IGP区域的PE之间的MPLS连接。
To set up the required MPLS LSPs between PEs in different IGP areas, service providers currently have three solutions: 1) LDP with IGP route leaking, 2) BGP [MPLS-BGP] over LDP with MPLS hierarchy, and 3) inter-area RSVP-TE (Resource Reservation Protocol-Traffic Engineering [RSVP-TE]).
为了在不同IGP区域的PE之间建立所需的MPLS LSP，服务提供商目前有三种解决方案：1）具有IGP路由泄漏的LDP，2）具有MPLS层次结构的LDP上的BGP[MPLS-BGP]，以及3）区域间RSVP-TE（资源预留协议流量工程[RSVP-TE]）。
IGP route leaking consists of redistributing all specific PE loopback addresses across area boundaries. As a result, LDP finds in the RIB an exact match for its FEC and sets up the LSP. As a consequence, the potential benefits that a multi-area domain may yield are significantly diminished since a lot of addresses have to be redistributed by ABRs, and the number of IP entries in the IGP Link State Database (LSDB), RIB, and Forwarding Information Base (FIB) maintained by every LSR of the domain (whatever the area/level it belongs to) cannot be minimized.
IGP路由泄漏包括跨区域边界重新分配所有特定PE环回地址。因此，LDP在RIB中找到与其FEC的精确匹配，并设置LSP。因此，多区域域可能产生的潜在好处显著减少，因为许多地址必须由ABR重新分配，并且IGP链路状态数据库（LSDB）、RIB和转发信息库（FIB）中的IP条目数量由域的每个LSR维护（无论它属于哪个区域/级别）都不能最小化。
Service providers may also set up these inter-area LSPs by using MPLS hierarchy with BGP [MPLS-BGP] as a label distribution protocol between areas. The BGP next hop would typically be the ABRs, and the BGP-created LSPs would be nested within intra-area LSPs set up by LDP between PEs and ABRs and between ABRs.
服务提供商还可以通过使用MPLS层次结构和BGP[MPLS-BGP]作为区域之间的标签分发协议来设置这些区域间LSP。BGP下一跳通常是ABR，BGP创建的LSP将嵌套在PEs和ABR之间以及ABR之间由LDP设置的区域内LSP中。
This solution is not adequate for service providers which don't want to run BGP on their provider routers as it requires BGP on all ABRs. In addition, MPLS hierarchy does not allow locally protecting the LSP against ABR failures (IP/LDP Fast Reroute), and hence ensuring sub-50ms recovery upon ABR failure. The resulting convergence time may not be acceptable for stringent Service Level Agreements (SLAs) required for voice or mission-critical applications. Finally, this solution requires a significant migration effort for service providers that started with LDP and IGP route leaking to quickly set up the first inter-area LSPs.
此解决方案不适用于不希望在其提供商路由器上运行BGP的服务提供商，因为它需要在所有ABR上运行BGP。此外，MPLS层次结构不允许本地保护LSP免受ABR故障（IP/LDP快速重路由）的影响，从而确保在ABR故障时进行低于50ms的恢复。对于语音或任务关键型应用程序所需的严格服务级别协议（SLA），由此产生的收敛时间可能不可接受。最后，此解决方案需要服务提供商进行大量迁移工作，从LDP和IGP路由泄漏开始，以快速建立第一个区域间LSP。
Service providers may also set up these inter-area LSPs by using inter-area RSVP-TE [RSVP-TE]. This is a relevant solution when RSVP-TE is already used for setting up intra-area LSPs, and inter-area traffic engineering features are required. In return, this is not a desired solution when LDP is already used for setting up intra-area LSPs, and inter-area traffic engineering features are not required.
服务提供商还可以通过使用区域间RSVP-TE[RSVP-TE]来设置这些区域间LSP。当RSVP-TE已经用于设置区域内LSP，并且需要区域间流量工程功能时，这是一个相关的解决方案。反过来，当LDP已经用于建立区域内LSP，并且不需要区域间流量工程特性时，这不是理想的解决方案。
To avoid the above drawbacks, there is a need for an LDP-based solution that allows setting up contiguous inter-area LSPs while avoiding leaking of specific PE loopback addresses across area boundaries, thereby keeping all the benefits of IGP hierarchy.
为了避免上述缺点，需要基于LDP的解决方案，该解决方案允许建立连续的区域间LSP，同时避免跨区域边界泄漏特定PE环回地址，从而保持IGP层次结构的所有优点。
In that context, this document defines a new LDP Label Mapping Procedure so as to support the setup of contiguous inter-area LSPs while maintaining IP prefix aggregation on the ABRs. This procedure is similar to the one defined in [LDP] but performs an IP longest match when searching the FEC element in the RIB.
在这种情况下，本文件定义了一种新的LDP标签映射程序，以便在保持ABR上的IP前缀聚合的同时支持相邻区域间LSP的设置。该程序类似于[LDP]中定义的程序，但在搜索肋骨中的FEC元素时执行IP最长匹配。
This document defines a new Label Mapping Procedure for [LDP]. It is applicable to IPv4 and IPv6 prefix FEC elements (address families 1 and 2 as per the "Address Family Numbers" registry on the IANA site). It SHOULD be possible to activate/deactivate this procedure by configuration, and it SHOULD be deactivated by default. It MAY be possible to activate it on a per-prefix basis.
本文件为[LDP]定义了一个新的标签映射程序。它适用于IPv4和IPv6前缀FEC元素（IANA站点上“地址系列号”注册表中的地址系列1和2）。应可通过配置激活/停用此程序，且默认情况下应停用此程序。可以根据每个前缀激活它。
With this new Longest-Match Label Mapping Procedure, an LSR receiving a Label Mapping message from a neighbor LSR for a Prefix Address FEC Element FEC1 SHOULD use the label for MPLS forwarding if its routing table contains an entry that matches the FEC Element FEC1 and the advertising LSR is a next hop to reach FEC1. If so, it SHOULD advertise the received FEC Element FEC1 and a label to its LDP peers.
使用这种新的最长匹配标签映射过程，如果从相邻LSR接收前缀地址FEC元素FEC1的标签映射消息的LSR的路由表包含与FEC元素FEC1匹配的条目，并且广告LSR是到达FEC1的下一个跃点，则该LSR应使用该标签进行MPLS转发。如果是这样，它应该向其LDP对等方通告接收到的FEC元素FEC1和标签。
By "matching FEC Element", one should understand an IP longest match. That is, either the LDP FEC element exactly matches an entry in the IP RIB or the FEC element is a subset of an IP RIB entry. There is no match for other cases (i.e., if the FEC element is a superset of a RIB entry, it is not considered a match).
通过“匹配FEC元素”，应该理解IP最长匹配。也就是说，LDP FEC元素完全匹配IP RIB中的条目，或者FEC元素是IP RIB条目的子集。其他情况下不存在匹配（即，如果FEC元素是肋骨入口的超集，则不视为匹配）。
Note that LDP re-advertises to its peers the specific FEC element FEC1, and not the aggregated prefix found in the IP RIB during the longest-match search.
请注意，LDP向其对等方重新播发特定FEC元素FEC1，而不是在最长匹配搜索期间在IP RIB中找到的聚合前缀。
Note that with this Longest-Match Label Mapping Procedure, each LSP established by LDP still strictly follows the shortest path(s) defined by the IGP.
请注意，使用此最长匹配标签映射过程，LDP建立的每个LSP仍然严格遵循IGP定义的最短路径。
FECs selected by this Longest-Match Label Mapping Procedure are distributed in an ordered way. In case of LER failure, the removal of reachability to the FEC occurs using LDP ordered label distribution mode procedures. As defined in [LDP] in section A.1.5, the FEC will be removed in an ordered way through the propagation of Label Withdraw messages. The use of this (un)reachability information by application layers using this MPLS LSP (e.g., [MP-BGP]) is outside the scope of this document.
通过此最长匹配标签映射过程选择的FEC以有序方式分布。在LER故障的情况下，使用LDP有序标签分发模式程序移除FEC的可达性。如第A.1.5节[LDP]中所定义，FEC将通过传播标签撤销消息以有序方式移除。使用此MPLS LSP（例如，[MP-BGP]）的应用层使用此（非）可达性信息超出了本文档的范围。
As per [LDP], LDP already has some interactions with the RIB. In particular, it needs to be aware of the following events:
根据[LDP]，LDP已经与RIB进行了一些互动。特别是，它需要了解以下事件：
- prefix up when a new IP prefix appears in the RIB,
- 当肋骨中出现新的IP前缀时，向上添加前缀，
- prefix down when an existing IP prefix disappears,
- 当现有IP前缀消失时，前缀关闭，
- next-hop change when an existing IP prefix has a new next hop following a routing change.
- 下一跳更改当现有IP前缀在路由更改后具有新的下一跳时。
With this Longest-Match Label Mapping Message Procedure, multiple FECs may be concerned by a single RIB prefix change. The LSR MUST check all the FECs that are a subset of this RIB prefix. So, some LDP reactions following a RIB event are changed:
使用此最长的匹配标签映射消息过程，单个RIB前缀更改可能会涉及多个FEC。LSR必须检查作为该RIB前缀子集的所有FEC。因此，RIB事件后的一些LDP反应发生了变化：
- When a new prefix appears in the RIB, the LSR MUST check if this prefix is a better match for some existing FECs. For example, the FEC elements 192.0.2.1/32 and 192.0.2.2/32 used the IP RIB entry 192.0.2.0/24, and a new more specific IP RIB entry 192.0.2.0/26 appears. This may result in changing the LSR used as next hop and hence the Next Hop Label Forwarding Entry (NHLFE) for this FEC.
- 当RIB中出现新前缀时，LSR必须检查该前缀是否与某些现有FEC更匹配。例如，FEC元素192.0.2.1/32和192.0.2.2/32使用了IP RIB条目192.0.2.0/24，出现了一个新的更具体的IP RIB条目192.0.2.0/26。这可能导致更改用作下一跳的LSR，从而更改该FEC的下一跳标签转发条目（NHLFE）。
- When a prefix disappears in the RIB, the LSR MUST check all FEC elements that are using this RIB prefix as best match. For each FEC, if another RIB prefix is found as best match, LDP MUST use it. This may result in changing the LSR used as next hop and hence the NHLFE for this FEC. Otherwise, the LSR MUST remove the FEC binding and send a Label Withdraw message.
- 当一个前缀在肋骨中消失时，LSR必须检查所有使用该肋骨前缀作为最佳匹配的FEC元素。对于每个FEC，如果发现另一个肋骨前缀最匹配，LDP必须使用它。这可能导致改变用作下一跳的LSR，从而改变该FEC的NHLFE。否则，LSR必须删除FEC绑定并发送标签撤销消息。
- When the next hop of a RIB prefix changes, the LSR MUST change the NHLFE of all the FEC elements using this prefix.
- 当肋骨前缀的下一跳发生变化时，LSR必须使用该前缀改变所有FEC元素的NHLFE。
Future work may define new management objects to the MPLS LDP MIB modules [LDP-MIB] to activate/deactivate this Longest-Match Label Mapping Message Procedure, possibly on a per-prefix basis.
未来的工作可能会为MPLS LDP MIB模块[LDP-MIB]定义新的管理对象，以激活/停用该最长匹配标签映射消息过程，可能是基于每个前缀。
Consider the following example of an autonomous system with one backbone area and two edge areas:
考虑下面的例子，一个具有一个主干区域和两个边缘区域的自治系统：
Area "B"
B区
Level 2 / Backbone area
二级/主干区
+--------------------------+
Area "A" | | Area "C"
| |
Level 1 | | Level 1 / area
| P1 |
+----------+ +-------------+
| | P2 | PE1 | 192.0.2.1/32
| | | |
|PE4 ABR2 ABR1 PE2 | 192.0.2.2/32
| | P3 | |
| | | PE3 | 192.0.2.3/32
+----------+ +-------------+
| |
+--------------------------+
+--------------------------+
Area "A" | | Area "C"
| |
Level 1 | | Level 1 / area
| P1 |
+----------+ +-------------+
| | P2 | PE1 | 192.0.2.1/32
| | | |
|PE4 ABR2 ABR1 PE2 | 192.0.2.2/32
| | P3 | |
| | | PE3 | 192.0.2.3/32
+----------+ +-------------+
| |
+--------------------------+
Figure 1: An IGP domain with two areas attached to the Backbone Area.
图1：一个IGP域，有两个区域连接到主干区域。
Note that this applies equally to IS-IS and OSPF. An ABR refers here either to an OSPF ABR or to an IS-IS L1/L2 node.
请注意，这同样适用于IS-IS和OSPF。这里，ABR指的是OSPF ABR或IS-IS L1/L2节点。
All routers are MPLS enabled, and MPLS connectivity (i.e., an LSP) is required between all PE routers.
所有路由器都支持MPLS，所有PE路由器之间需要MPLS连接（即LSP）。
In the "egress" area "C", the records available are:
在“出口”区域“C”，可用的记录包括：
IGP RIB LDP FEC elements:
192.0.2.1/32 192.0.2.1/32
192.0.2.2/32 192.0.2.2/32
192.0.2.3/32 192.0.2.3/32
IGP RIB LDP FEC elements:
192.0.2.1/32 192.0.2.1/32
192.0.2.2/32 192.0.2.2/32
192.0.2.3/32 192.0.2.3/32
The area border router ABR1 advertises in the backbone area:
- the aggregated IP prefix 192.0.2.0/26 in the IGP
- all the specific IP FEC elements (/32) in LDP
The area border router ABR1 advertises in the backbone area:
- the aggregated IP prefix 192.0.2.0/26 in the IGP
- all the specific IP FEC elements (/32) in LDP
In the "backbone" area "B", the records available are:
在“主干”区域“B”中，可用的记录包括：
IGP RIB LDP FEC elements: 192.0.2.0/26 192.0.2.1/32 192.0.2.2/32 192.0.2.3/32
IGP RIB LDP FEC元件：192.0.2.0/26192.0.2.1/32192.0.2.2/32192.0.2.3/32
The area border router ABR2 advertises in the area "A":
- an aggregated IP prefix 192.0.2.0/24 in the IGP
- all the individual IP FEC elements (/32) in LDP
The area border router ABR2 advertises in the area "A":
- an aggregated IP prefix 192.0.2.0/24 in the IGP
- all the individual IP FEC elements (/32) in LDP
In the "ingress" area "A", the records available are:
在“入口”区域“A”中，可用记录包括：
IGP RIB LDP FEC elements: 192.0.2.0/24 192.0.2.1/32 192.0.2.2/32 192.0.2.3/32
IGP RIB LDP FEC元件：192.0.2.0/24192.0.2.1/32192.0.2.2/32192.0.2.3/32
In this situation, one LSP is established between the ingress PE4 and every egress PE of area C while maintaining IP prefix aggregation on the ABRs.
在这种情况下，在保持abr上的IP前缀聚合的同时，在区域C的入口PE4和每个出口PE之间建立一个LSP。
Consider the following example where a LER is dual-connected to two LSRs:
考虑下面的示例，其中LER是双连接到两个LSRs：
+--------LSR1----
| |
LER |
| |
+--------LSR2----
+--------LSR1----
| |
LER |
| |
+--------LSR2----
Figure 2: LER dual-connected to two LSRs.
图2:LER双重连接到两个LSR。
In some situations, especially on the edge of the network, it is valid to use static IP routes between the LER and the two LSRs. If necessary, the Bidirectional Forwarding Detection protocol [BFD] can be used to quickly detect loss of connectivity.
在某些情况下，尤其是在网络边缘，在LER和两个LSR之间使用静态IP路由是有效的。如有必要，可使用双向转发检测协议[BFD]快速检测连接丢失。
The LDP specification defined in [LDP] would require on the ingress LER the configuration and the maintenance of one IP route per egress LER and per outgoing interface.
[LDP]中定义的LDP规范要求在入口LER上配置和维护每个出口LER和每个输出接口的一条IP路由。
The Longest-Match Label Mapping Procedure described in this document only requires one IP route per outgoing interface.
本文档中描述的最长匹配标签映射过程仅要求每个传出接口有一个IP路由。
LSRs compliant with this document are backward compatible with LSRs that comply with [LDP].
符合本文件的LSR与符合[LDP]的LSR向后兼容。
For the successful establishment of end-to-end MPLS LSPs whose FECs are aggregated in the RIB, this specification must be implemented on all LSRs in all areas where IP aggregation is used. If an LSR on the path does not support this procedure, then the LSP initiated on the egress LSR stops at this non-compliant LSR. There are no other adverse effects.
为了成功建立FEC在RIB中聚合的端到端MPLS LSP，必须在使用IP聚合的所有区域的所有LSR上实施本规范。如果路径上的LSR不支持此过程，则在出口LSR上启动的LSP将停止在此不符合要求的LSR处。没有其他不利影响。
This extension can be deployed incrementally:
此扩展可以增量部署：
- It can be deployed on a per-area or per-routing-domain basis and does not necessarily require an AS-wide deployment. For example, if all specific IP prefixes are leaked in the IGP backbone area and only stub areas use IP aggregation, LSRs in the backbone area don't need to be compliant with this document.
- 它可以在每个区域或每个路由域的基础上部署，并且不一定需要同样广泛的部署。例如，如果所有特定IP前缀在IGP主干区域泄漏，并且只有存根区域使用IP聚合，则主干区域中的LSR不需要符合本文档。
- Within each routing area, LSRs can be upgraded independently, at any time, in any order, and without service disruption. During deployment, if those LSPs are already used, one should only make sure that ABRs keep advertising the specific IP prefixes in the IGP until all LSRs of this area are successfully upgraded. Then, the ABRs can advertise the aggregated prefix only and stop advertising the specific ones.
- 在每个路由区域内，LSR可以在任何时间、以任何顺序独立升级，而不会中断服务。在部署期间，如果已经使用了这些LSP，则只应确保ABR在IGP中不断发布特定IP前缀，直到该区域的所有LSR成功升级。然后，ABR可以只公布聚合前缀，并停止公布特定前缀。
A service provider currently leaking specific LER loopback addresses in the IGP and considering performing IP aggregation on ABR should be aware that this may result in suboptimal routing as discussed in [RFC2966].
当前在IGP中泄漏特定LER环回地址并考虑在ABR上执行IP聚合的服务提供商应注意，这可能会导致[RFC2966]中讨论的次优路由。
IP and MPLS traffic restoration time is based on two factors: the Shortest Path First (SPF) calculation in the control plane and Forwarding Information Base (FIB) / Label FIB (LFIB) update time in the forwarding plane. The SPF calculation scales O(N*Log(N)) where N is the number of Nodes. The FIB/LFIB update scales O(P) where P is the number of modified prefixes. Currently, with most routers implementations, the FIB/LFIB update is the dominant component [IGP-CONV], and therefore the bottleneck that should be addressed in priority. The solution documented in this document reduces the link state database size in the control plane and the number of FIB entries in the forwarding plane. As such, it solves the scaling of
IP和MPLS流量恢复时间基于两个因素：控制平面中的最短路径优先（SPF）计算和转发平面中的转发信息库（FIB）/标签FIB（LFIB）更新时间。SPF计算比例为O（N*Log（N）），其中N是节点数。FIB/LFIB更新缩放为O（P），其中P是修改前缀的数量。目前，对于大多数路由器实施，FIB/LFIB更新是主要组件[IGP-CONV]，因此是应优先解决的瓶颈。本文档中记录的解决方案减少了控制平面中的链路状态数据库大小和转发平面中的FIB条目的数量。因此，它解决了
pure IP routers sharing the IGP with MPLS routers. However, it does not decrease the number of LFIB entries so is not sufficient to solve the scaling of MPLS routers. For this, an additional mechanism is required (e.g., introducing some MPLS hierarchy in LDP). This is out of scope for this document.
纯IP路由器与MPLS路由器共享IGP。但是，它不会减少LFIB条目的数量，因此不足以解决MPLS路由器的扩展问题。为此，需要额外的机制（例如，在LDP中引入一些MPLS层次结构）。这超出了本文档的范围。
Compared to [LDP], for all failures except LER failure (i.e., links, provider routers, and ABRs), the failure notification and the convergence is unchanged. For LER failure, given that the IGP aggregates IP routes on ABRs and no longer advertises specific prefixes, the control plane and more specifically the routing convergence behavior of protocols (e.g., [MP-BGP]) or applications (e.g., [L3-VPN]) may be changed in case of failure of the egress LER node. For protocols and applications which need to track egress LER availability, several solutions can be used, for example:
与[LDP]相比，对于除LER故障之外的所有故障（即链路、提供商路由器和ABR），故障通知和收敛保持不变。对于LER故障，假设IGP在ABR上聚合IP路由并且不再播发特定前缀，则在出口LER节点故障的情况下，可以改变协议（例如，[MP-BGP]）或应用程序（例如，[L3-VPN]）的控制平面和更具体地说路由收敛行为。对于需要跟踪出口可用性的协议和应用程序，可以使用几种解决方案，例如：
- Rely on the LDP ordered label distribution control mode -- as defined in [LDP] -- to know the availability of the LSP toward the egress LER. The egress to ingress propagation time of that unreachability information is expected to be comparable to the IGP (but this may be implementation dependent).
- 依靠LDP有序标签分发控制模式（如[LDP]中所定义），了解LSP对出口LER的可用性。该不可到达性信息的出入口传播时间预计与IGP相当（但这可能取决于实现）。
- Advertise LER reachability in the IGP for the purpose of the control plane in a way that does not create IP FIB entries in the forwarding plane.
- 为了控制平面的目的，在IGP中以不在转发平面中创建IP FIB条目的方式公布LER可达性。
The Longest-Match Label Mapping procedure described in this document does not introduce any change as far as the Security Considerations section of [LDP] is concerned.
就[LDP]的安全注意事项部分而言，本文件中描述的最长匹配标签映射程序没有引入任何更改。
[LDP] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[LDP]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.，“LDP规范”，RFC 5036，2007年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月。
[L3-VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[L3-VPN]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[MP-BGP] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[MP-BGP]Bates，T.，Chandra，R.，Katz，D.，和Y.Rekhter，“BGP-4的多协议扩展”，RFC 4760，2007年1月。
[MPLS-BGP] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.
[MPLS-BGP]Rekhter，Y.和E.Rosen，“在BGP-4中携带标签信息”，RFC 3107，2001年5月。
[IS-IS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[IS-IS]Callon，R.，“OSI IS-IS在TCP/IP和双环境中的路由使用”，RFC1195，1990年12月。
[VPLS-BGP] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007.
[VPLS-BGP]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“使用BGP进行自动发现和信令的虚拟专用局域网服务（VPLS）”，RFC 4761，2007年1月。
[VPLS-LDP] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007.
[VPLS-LDP]Lasserre，M.，Ed.，和V.Kompella，Ed.，“使用标签分发协议（LDP）信令的虚拟专用局域网服务（VPLS）”，RFC 4762，2007年1月。
[RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, October 2000.
[RFC2966]Li，T.，Przygienda，T.，和H.Smit，“具有两级IS-IS的域范围前缀分布”，RFC 2966，2000年10月。
[RSVP-TE] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 5151, February 2008.
[RSVP-TE]Farrel，A.，Ed.，Ayyangar，A.，和JP。Vasseur，“域间MPLS和GMPLS流量工程——资源预留协议流量工程（RSVP-TE）扩展”，RFC 51512008年2月。
[LDP-MIB] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 2004.
[LDP-MIB]Cucchiara，J.，Sjostrand，H.，和J.Luciani，“多协议标签交换（MPLS）管理对象的定义，标签分发协议（LDP）”，RFC 3815，2004年6月。
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", Work in Progress, March 2008.
[BFD]Katz，D.和D.Ward，“双向转发检测”，正在进行的工作，2008年3月。
[IGP-CONV] Francois, P., Filsfils, C., and Evans, J., "Achieving sub-second IGP convergence in large IP networks". ACM SIGCOMM Computer Communications Review, July 2005.
[IGP-CONV]Francois，P.，Filsfils，C.，和Evans，J.，“在大型IP网络中实现亚秒级IGP融合”。ACM SIGCOMM计算机通信评论，2005年7月。
[OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPFv2]Moy，J.，“OSPF版本2”，STD 54，RFC 23281998年4月。
The authors would like to thank Yakov Rekhter, Stefano Previdi, Vach Kompella, Bob Thomas, Clarence Filsfils, Kireeti Kompella, Luca Martini, Sina Mirtorabi, Dave McDysan, Benoit Fondeviole, Gilles Bourdon, and Christian Jacquenet for the useful discussions on this subject, their reviews, and comments.
作者要感谢雅科夫·雷克特、斯蒂法诺·普雷维迪、瓦赫·科佩拉、鲍勃·托马斯、克拉伦斯·菲尔斯菲尔斯、基里蒂·科佩拉、卢卡·马蒂尼、西娜·米尔托拉比、戴夫·麦克迪桑、贝诺特·方德维奥尔、吉勒斯·波登和克里斯蒂安·雅克内特，感谢他们就这一主题进行了有益的讨论、发表了评论和评论。
Authors' Addresses
作者地址
Bruno Decraene France Telecom 38 rue du General Leclerc 92794 Issy Moulineaux cedex 9 France
布鲁诺法国电信公司Leclerc将军街38号92794 Issy Moulineaux cedex 9法国
EMail: bruno.decraene@orange-ftgroup.com
EMail: bruno.decraene@orange-ftgroup.com
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France
Jean-Louis Le Roux法国电信2号，Pierre Marzin大街22307兰尼昂塞德斯法国
EMail: jeanlouis.leroux@orange-ftgroup.com
EMail: jeanlouis.leroux@orange-ftgroup.com
Ina Minei Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089
Ina Minei Juniper Networks 1194 N.Mathilda Ave.Sunnyvale，加利福尼亚州94089
EMail: ina@juniper.net
EMail: ina@juniper.net
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.