Internet Engineering Task Force (IETF) A. Karan
Request for Comments: 7431 C. Filsfils
Category: Informational IJ. Wijnands, Ed.
ISSN: 2070-1721 Cisco Systems, Inc.
B. Decraene
Orange
August 2015
Internet Engineering Task Force (IETF) A. Karan
Request for Comments: 7431 C. Filsfils
Category: Informational IJ. Wijnands, Ed.
ISSN: 2070-1721 Cisco Systems, Inc.
B. Decraene
Orange
August 2015
Multicast-Only Fast Reroute
仅组播快速重路由
Abstract
摘要
As IPTV deployments grow in number and size, service providers are looking for solutions that minimize the service disruption due to faults in the IP network carrying the packets for these services. This document describes a mechanism for minimizing packet loss in a network when node or link failures occur. Multicast-only Fast Reroute (MoFRR) works by making simple enhancements to multicast routing protocols such as Protocol Independent Multicast (PIM) and Multipoint LDP (mLDP).
随着IPTV部署数量和规模的增长，服务提供商正在寻找解决方案，以尽量减少由于承载这些服务的数据包的IP网络中的故障而造成的服务中断。本文档描述了当节点或链路发生故障时，将网络中的数据包丢失降至最低的机制。仅多播快速重路由（MoFRR）通过对多播路由协议（如协议独立多播（PIM）和多点LDP）进行简单的增强而工作。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7431.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7431.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
1.2. Terminology ................................................3
2. Basic Overview ..................................................4
3. Determination of the Secondary UMH ..............................5
3.1. ECMP-Mode MoFRR ............................................5
3.2. Non-ECMP-Mode MoFRR ........................................5
4. Upstream Multicast Hop Selection ................................6
4.1. PIM ........................................................6
4.2. mLDP .......................................................6
5. Detecting Failures ..............................................6
6. MoFRR Applicability to Dual-Plane Topology ......................7
7. Other Topologies ...............................................10
8. Capacity Planning for MoFRR ....................................11
9. PE Nodes .......................................................11
10. Other Applications ............................................11
11. Security Considerations .......................................12
12. References ....................................................12
12.1. Normative References .....................................12
12.2. Informative References ...................................12
Acknowledgments ...................................................13
Contributors ......................................................13
Authors' Addresses ................................................14
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
1.2. Terminology ................................................3
2. Basic Overview ..................................................4
3. Determination of the Secondary UMH ..............................5
3.1. ECMP-Mode MoFRR ............................................5
3.2. Non-ECMP-Mode MoFRR ........................................5
4. Upstream Multicast Hop Selection ................................6
4.1. PIM ........................................................6
4.2. mLDP .......................................................6
5. Detecting Failures ..............................................6
6. MoFRR Applicability to Dual-Plane Topology ......................7
7. Other Topologies ...............................................10
8. Capacity Planning for MoFRR ....................................11
9. PE Nodes .......................................................11
10. Other Applications ............................................11
11. Security Considerations .......................................12
12. References ....................................................12
12.1. Normative References .....................................12
12.2. Informative References ...................................12
Acknowledgments ...................................................13
Contributors ......................................................13
Authors' Addresses ................................................14
Different solutions have been developed and deployed to improve service guarantees, both for multicast video traffic and Video on Demand traffic. Most of these solutions are geared towards finding an alternate path around one or more failed network elements (link, node, or path failures).
已经开发和部署了不同的解决方案，以改进多播视频流量和视频点播流量的服务保证。这些解决方案中的大多数都是为了在一个或多个发生故障的网络元素（链路、节点或路径故障）周围找到备用路径。
This document describes a mechanism for minimizing packet loss in a network when node or link failures occur. Multicast-only Fast Reroute (MoFRR) works by making simple changes to the way selected routers use multicast protocols such as PIM and mLDP. No changes to the protocols themselves are required. With MoFRR, in many cases, multicast routing protocols don't necessarily have to depend on or have to wait on unicast routing protocols to detect network failures; see Section 5.
本文档描述了当节点或链路发生故障时，将网络中的数据包丢失降至最低的机制。仅组播快速重路由（MoFRR）的工作原理是对选定路由器使用多播协议（如PIM和mLDP）的方式进行简单更改。不需要对协议本身进行任何更改。使用MoFRR，在许多情况下，多播路由协议不必依赖或等待单播路由协议来检测网络故障；见第5节。
On a Merge Point, MoFRR logic determines a primary Upstream Multicast Hop (UMH) and a secondary UMH and joins the tree via both simultaneously. Data packets are received over the primary and secondary paths. Only the packets from the primary UMH are accepted and forwarded down the tree; the packets from the secondary UMH are discarded. The UMH determination is different for PIM and mLDP and explained in Section 4. When a failure is detected on the path to the primary UMH, the repair occurs by changing the secondary UMH into the primary and the primary into the secondary. Since the repair is local, it is fast -- greatly improving convergence times in the event of node or link failures on the path to the primary UMH.
在合并点上，MoFRR逻辑确定主上行多播跃点（UMH）和次UMH，并通过两者同时连接树。通过主路径和辅助路径接收数据包。只有来自主UMH的数据包被接受并沿着树向下转发；来自辅助UMH的分组被丢弃。对于PIM和mLDP，UMH的确定不同，并在第4节中进行了解释。当在主UMH的路径上检测到故障时，通过将辅助UMH更改为主UMH，将主UMH更改为辅助UMH来进行修复。由于修复是本地的，所以速度很快——在主UMH路径上发生节点或链路故障时，大大缩短了收敛时间。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
MoFRR: Multicast-only Fast Reroute.
MoFRR：仅多播快速重路由。
ECMP: Equal-Cost Multipath.
ECMP：等成本多路径。
mLDP: Multipoint Label Distribution Protocol.
mLDP：多点标签分发协议。
PIM: Protocol Independent Multicast.
PIM：独立于协议的多播。
UMH: Upstream Multicast Hop. A candidate next-hop that can be used to reach the root of the tree.
UMH：上行多播跳。可用于到达树根的候选下一跳。
tree: Either a PIM (S,G)/(*,G) tree or an mLDP Point-to-Multipoint (P2MP) or Multipoint-to-Multipoint (MP2MP) LSP.
树：PIM（S，G）/（*，G）树或mLDP点对多点（P2MP）或多点对多点（MP2MP）LSP。
OIF: Outgoing interface. An interface used to forward multicast packets down the tree towards the receivers. Either a PIM (S,G)/(*,G) tree or an mLDP P2MP or MP2MP LSP.
OIF：输出接口。用于将多播数据包沿树向下转发到接收器的接口。PIM（S，G）/（*，G）树或mLDP P2MP或MP2MP LSP。
LFA: Loop-Free Alternate as defined in [RFC5286]. In unicast Fast Reroute, this is an alternate next-hop that can be used to reach a unicast destination without using the protected link or node.
LFA：在[RFC5286]中定义的无回路备用。在单播快速重路由中，这是一个备用下一跳，可用于到达单播目的地，而无需使用受保护的链路或节点。
Merge Point: A router that joins a multicast stream via two divergent upstream paths.
合并点：通过两条不同的上行路径连接多播流的路由器。
RPF: Reverse Path Forwarding.
反向路径转发。
RP: Rendezvous Point.
交会点。
LSP: Label Switched Path.
标签交换路径。
LSR: Label Switching Router.
标签交换路由器。
BFD: Bidirectional Forwarding Detection.
双向转发检测。
IGP: Interior Gateway Protocol.
IGP：内部网关协议。
MVPN: Multicast Virtual Private Network.
MVPN：多播虚拟专用网络。
POP: Point Of Presence, an access point into the network.
POP：存在点，进入网络的接入点。
The basic idea of MoFRR is for a Merge Point router to join a multicast tree via two divergent upstream paths in order to get maximum redundancy. The determination of this alternate upstream is defined in Section 3.
MoFRR的基本思想是合并点路由器通过两条不同的上行路径连接多播树，以获得最大冗余。第3节规定了该备选上游的确定。
In order to maximize robustness against any failure, the two paths should be as diverse as possible. Ideally, they should not merge upstream. Sometimes the topology guarantees maximal redundancy; other times additional configuration or techniques are needed to enforce it. See Section 6 for more discussion on the applicability of MoFRR depending on the network topology.
为了最大限度地提高对任何故障的鲁棒性，这两条路径应尽可能多样化。理想情况下，它们不应该合并到上游。有时拓扑结构保证最大冗余；其他时候，需要额外的配置或技术来实施它。有关MoFRR的适用性（取决于网络拓扑）的更多讨论，请参见第6节。
A Merge Point router should only accept and forward on one of the upstream paths at a time in order to avoid duplicate packet
合并点路由器一次只能接受和转发一条上行路径，以避免重复数据包
forwarding. The selection of the primary and secondary UMH is done by the MoFRR logic and normally based on unicast routing to find loop-free candidates. This is described in Section 4.
转发。主UMH和辅助UMH的选择由MoFRR逻辑完成，通常基于单播路由来查找无环路候选。第4节对此进行了描述。
Note, the impact of an additional amount of data on the network is mitigated when tree membership is densely populated. When a part of the network has redundant data flowing, join latency for new joining members is reduced because it's likely a tree Merge Point is not far away.
注意，当树成员密集时，网络上额外数据量的影响会减轻。当网络的一部分具有冗余数据流时，新加入成员的加入延迟会减少，因为很可能树合并点就在不远处。
The secondary UMH is a Loop-Free Alternate (LFA) as per [RFC5286].
次级UMH是符合[RFC5286]的无环路备用（LFA）。
If the IGP installs two ECMP paths to the source, then as per [RFC5286] the LFA is a primary next-hop. If the multicast tree is enabled for ECMP-mode MoFRR, the router installs the paths as primary and secondary UMHs. Before the failure, only packets received from the primary UMH path are processed, while packets received from the secondary UMH are dropped.
如果IGP将两条ECMP路径安装到源，则根据[RFC5286]，LFA是主下一跳。如果为ECMP模式MoFRR启用多播树，路由器将路径安装为主UMH和辅助UMH。在发生故障之前，仅处理从主UMH路径接收的数据包，而丢弃从辅助UMH路径接收的数据包。
The selected primary UMH SHOULD be the same as if the MoFRR extension were not enabled.
所选主UMH应与未启用MoFRR扩展时相同。
If more than two ECMP paths exist, one is selected as primary and another as secondary UMH. The selection of the primary and secondary is a local decision. Information from the IGP link-state topology could be leveraged to optimize this selection such that the primary and secondary paths are maximal divergent and don't lead to the same upstream node. Note that MoFRR does not restrict the number of UMH paths that are joined. Implementations may use as many paths as are configured.
If more than two ECMP paths exist, one is selected as primary and another as secondary UMH. The selection of the primary and secondary is a local decision. Information from the IGP link-state topology could be leveraged to optimize this selection such that the primary and secondary paths are maximal divergent and don't lead to the same upstream node. Note that MoFRR does not restrict the number of UMH paths that are joined. Implementations may use as many paths as are configured.translate error, please retry
A router X configured for non-ECMP-mode MoFRR for a multicast tree joins a primary path to its primary UMH and a secondary path to its LFA UMH. In order to prevent control-plane loops, a router MUST stop joining the secondary UMH if this UMH is the only member in the OIF list.
为多播树的非ECMP模式MoFRR配置的路由器X将主路径连接到其主UMH，将辅助路径连接到其LFA UMH。为了防止控制平面循环，如果辅助UMH是OIF列表中的唯一成员，则路由器必须停止加入辅助UMH。
To illustrate the reason for this rule, let's consider the example in Figure 3. If two Provider Edge routers, PE1 and PE2, have received an IGMP request for a multicast tree, they will both join the primary path on their plane and a secondary path to the neighbor PE. If their receivers leave at the same time, it's possible for the
为了说明这个规则的原因，让我们考虑图3中的例子。如果两个提供商边缘路由器（PE1和PE2）已收到多播树的IGMP请求，则它们都将在其平面上加入主路径，并加入到相邻PE的辅助路径。如果他们的接受者同时离开，那么
multicast tree on PE1 and PE2 to never get deleted, as the PEs refresh each other via the secondary path joins (remember that a secondary path join is not distinguishable from a primary join).
PE1和PE2上的多播树永远不会被删除，因为PEs通过次路径连接彼此刷新（请记住，次路径连接与主连接无法区分）。
An Upstream Multicast Hop (UMH) is a candidate next-hop that can be used to reach the root of the tree. This is normally based on unicast routing to find loop-free candidate(s). With MoFRR procedures, we select a primary and a backup UMH. The procedures for determining the UMH are different for PIM and mLDP.
上行多播跳（UMH）是可用于到达树根的候选下一跳。这通常基于单播路由来查找无循环候选。使用MoFRR过程，我们选择一个主UMH和一个备份UMH。对于PIM和mLDP，确定UMH的程序不同。
The UMH selection in PIM is also known as the Reverse Path Forwarding (RPF) procedure. Based on a unicast route lookup on either the source address or Rendezvous Point (RP) [RFC4601], an upstream interface is selected for sending the PIM Joins/Prunes AND accepting the multicast packets. The interface the packets are received on is used to pass or fail the RPF check. If packets are received on an interface that was not selected as the primary by the RPF procedure, the packets are discarded.
PIM中的UMH选择也称为反向路径转发（RPF）过程。基于源地址或集合点（RP）[RFC4601]上的单播路由查找，选择上游接口以发送PIM连接/修剪并接受多播分组。接收数据包的接口用于通过或失败RPF检查。如果在RPF过程未选择为主接口的接口上接收到数据包，则丢弃这些数据包。
The UMH selection in mLDP also depends on unicast routing, but the difference from PIM is that the acceptance of multicast packets is based on MPLS labels and is independent of the interface on which the packet is received. Using the procedures as defined in [RFC6388], an upstream Label Switching Router (LSR) is elected. The upstream LSR that was elected for a Label Switched Path (LSP) gets a unique local MPLS label allocated. Multicast packets are only forwarded if the MPLS label matches the MPLS label that was allocated for that LSP's (primary) upstream LSR.
mLDP中的UMH选择也取决于单播路由，但与PIM的区别在于，多播数据包的接受基于MPLS标签，并且与接收数据包的接口无关。使用[RFC6388]中定义的程序，选择上游标签交换路由器（LSR）。为标签交换路径（LSP）选择的上游LSR获得分配的唯一本地MPLS标签。仅当MPLS标签与为该LSP（主）上游LSR分配的MPLS标签匹配时，才会转发多播数据包。
Once the two paths are established, the next step is detecting a failure on the primary path to know when to switch to the backup path. This is a local issue, but this section explores some possibilities.
一旦建立了这两条路径，下一步就是检测主路径上的故障，以知道何时切换到备份路径。这是一个局部问题，但本节探讨了一些可能性。
The first (and simplest) option is to detect the failure of the local interface as it's done for unicast Fast Reroute. Detection can be performed using the loss of signal or the loss of probing packets (e.g., BFD). This option can be used in combination with the other options as documented below. Just like for unicast fast reroute, 50 msec switchover is possible.
第一个（也是最简单的）选项是检测本地接口的故障，就像单播快速重路由一样。可以使用信号丢失或探测包丢失（例如，BFD）来执行检测。此选项可与下文所述的其他选项结合使用。就像单播快速重路由一样，50毫秒的切换也是可能的。
A second option consists of comparing the packets received on the primary and secondary streams but only forwarding one of them -- the first one received, no matter which interface it is received on. Zero packet loss is possible for RTP-based streams.
第二个选项包括比较主流和次流上接收到的数据包，但只转发其中一个数据包——即接收到的第一个数据包，而不管它在哪个接口上接收。对于基于RTP的流，零数据包丢失是可能的。
A third option assumes a minimum known packet rate for a given data stream. If a packet is not received on the primary RPF within this time frame, the router assumes primary path failure and switches to the secondary RPF interface. 50 msec switchover may be possible for high-rate streams (e.g., IPTV where SD video has a continuous inter-packet gap of about 3 msec), but in general the delay is dependent on the rate of the multicast stream.
第三个选项假定给定数据流的最小已知分组速率。如果在此时间范围内主RPF上未接收到数据包，路由器将假定主路径故障并切换到辅助RPF接口。50毫秒的切换对于高速率流（例如，IPTV，其中SD视频具有约3毫秒的连续分组间间隙）是可能的，但是通常延迟取决于多播流的速率。
A fourth option leverages the significant improvements of the IGP convergence speed. When the primary path to the source is withdrawn by the IGP, the MoFRR-enabled router switches over to the backup path, and the UMH is changed to the secondary UMH. Since the secondary path is already in place, and assuming it is disjoint from the primary path, convergence times would not include the time required to build a new tree and hence are smaller. Sub-second to sub-200 msec switchover should be possible.
第四个选项利用IGP收敛速度的显著改进。当IGP撤回到源的主路径时，启用MoFRR的路由器切换到备份路径，UMH更改为辅助UMH。由于次路径已经就位，并且假设它与主路径不相交，收敛时间将不包括构建新树所需的时间，因此较小。应可进行亚秒至亚200毫秒的切换。
MoFRR applicability is topology dependent. The applicability is the same as LFA FRR, which is discussed in [RFC6571].
MoFRR的适用性取决于拓扑。适用性与LFA FRR相同，在[RFC6571]中进行了讨论。
The following section will discuss MoFRR applicability to dual-plane network topologies.
以下部分将讨论MoFRR对双平面网络拓扑的适用性。
MoFRR works best in dual-planes topologies as illustrated in the figures below. MoFRR may be enabled on any router in the network. In the figures below, MoFRR is shown enabled on the Provider Edge (PE) routers to illustrate one way in which the technology may be deployed.
MoFRR在双平面拓扑中工作得最好，如下图所示。MoFRR可以在网络中的任何路由器上启用。在下图中，MoFRR显示为在提供商边缘（PE）路由器上启用，以说明部署该技术的一种方式。
S
P / \ P
/ \
^ G1 R1 ^
P / \ P
/ \
G2----------R2 ^
| \ | \ P
^ | \ | \
P | G3----------R3
| | | |
| | | | ^
G4---|------R4 | P
^ \ | \ |
P \ | \ |
G5----------R5
^ | | ^
P | | P
| |
Gi Ri
\ \__ ^ /|
\ \ S1/ | ^
^ \ ^\ / |P2
P1 \ S2\_/__ |
\ / \|
PE1 PE2
S
P / \ P
/ \
^ G1 R1 ^
P / \ P
/ \
G2----------R2 ^
| \ | \ P
^ | \ | \
P | G3----------R3
| | | |
| | | | ^
G4---|------R4 | P
^ \ | \ |
P \ | \ |
G5----------R5
^ | | ^
P | | P
| |
Gi Ri
\ \__ ^ /|
\ \ S1/ | ^
^ \ ^\ / |P2
P1 \ S2\_/__ |
\ / \|
PE1 PE2
P = Primary path S = Secondary path
P=主路径S=辅助路径
Figure 1: Two-Plane Network Design
图1：双平面网络设计
The topology has two planes, a primary plane and a secondary plane that are fully disjoint from each other all the way into the POPs. This two-plane design is common in service provider networks as it eliminates single point of failures in their core network. The links marked P indicate the normal (primary) path of how the PIM Joins flow from the POPs towards the source of the network. Multicast streams, especially for the densely watched channels, typically flow along both the planes in the network anyway.
拓扑有两个平面，一个主平面和一个次平面，它们在整个POP中完全不相交。这种双平面设计在服务提供商网络中很常见，因为它消除了核心网络中的单点故障。标记为P的链路表示PIM连接如何从POP流向网络源的正常（主要）路径。多播流，特别是对于密集监视的信道，通常无论如何都沿着网络中的两个平面流动。
The only change MoFRR adds to this is on the links marked S where the PE routers join a secondary path to their secondary ECMP UMH. As a result of this, each PE router receives two copies of the same stream, one from the primary plane and the other from the secondary plane. As a result of normal UMH behavior, the multicast stream
MoFRR对此的唯一更改是在标记为S的链路上，PE路由器将辅助路径加入到其辅助ECMP UMH。因此，每个PE路由器接收相同流的两个副本，一个来自主平面，另一个来自次平面。由于正常的UMH行为，多播流
received over the primary path is accepted and forwarded to the downstream receivers. The copy of the stream received from the secondary UMH is discarded.
通过主路径接收的数据被接受并转发给下游接收机。从辅助UMH接收的流的副本被丢弃。
When a router detects a routing failure on the path to its primary UMH, it will switch to the secondary UMH and accept packets for that stream. If the failure is repaired, the router may switch back. The primary and secondary UMHs have only local context and not end-to-end context.
当路由器在其主UMH的路径上检测到路由故障时，它将切换到辅助UMH并接受该流的数据包。如果故障得到修复，路由器可能会重新切换。主要和次要UMH只有本地上下文，而没有端到端上下文。
As one can see, MoFRR achieves the faster convergence by pre-building the secondary multicast tree and receiving the traffic on that secondary path. The example discussed above is a simple case where there are two ECMP paths from each PE device towards the source, one along the primary plane and one along the secondary. In cases where the topology is asymmetric or is a ring, this ECMP nature does not hold, and additional rules have to be taken into account to choose when and where to join the secondary path.
可以看出，MoFRR通过预先构建二级多播树并在该二级路径上接收流量来实现更快的收敛。上面讨论的示例是一个简单的情况，其中从每个PE设备到源有两条ECMP路径，一条沿着主平面，另一条沿着次平面。在拓扑不对称或是环的情况下，ECMP性质不成立，在选择何时何地加入辅助路径时，必须考虑其他规则。
MoFRR is appealing in such topologies for the following reasons:
MoFRR在此类拓扑中具有吸引力，原因如下：
1. Ease of deployment and simplicity: the functionality is only required on the PE devices, although it may be configured on all routers in the topology. Furthermore, each PE device can be enabled separately; there is no need for network-wide coordination in order to deploy MoFRR. Interoperability testing is not required as there are no PIM or mLDP protocol changes.
1. 易于部署且简单：该功能仅在PE设备上需要，尽管可以在拓扑中的所有路由器上配置。此外，每个PE设备可以单独启用；部署MoFRR不需要网络范围的协调。互操作性测试不需要，因为没有PIM或mLDP协议更改。
2. End-to-end failure detection and recovery: any failure along the path from the source to the PE can be detected and repaired with the secondary disjoint stream. (See the second, third, and fourth options in Section 5.)
2. 端到端故障检测和恢复：从源到PE的路径上的任何故障都可以通过二次不相交流进行检测和修复。（请参见第5节中的第二、第三和第四个选项。）
3. Capacity efficiency: as illustrated in the previous example, the multicast trees corresponding to IPTV channels cover the backbone and distribution topology in a very dense manner. As a consequence, the secondary path grafts onto the normal multicast trees (i.e., trees signaled by PIM or mLDP without the MoFRR extension) at the aggregation level and hence does not demand any extra capacity either on the distribution links or in the backbone. The secondary path simply uses the capacity that is normally used, without any duplication. This is different from conventional FRR mechanisms that often duplicate the capacity requirements when the backup path crosses links/nodes that already carry the primary/normal tree, and thus twice as much capacity is required.
3. 容量效率：如前一示例所示，与IPTV信道相对应的多播树以非常密集的方式覆盖主干和分发拓扑。因此，次路径在聚合级别上嫁接到正常多播树（即，由PIM或mLDP发出信号的树，没有MoFRR扩展），因此不需要在分发链路或主干上的任何额外容量。辅助路径只使用通常使用的容量，没有任何重复。这与传统的FRR机制不同，传统FRR机制在备份路径穿过已承载主/普通树的链路/节点时通常会重复容量需求，因此需要两倍的容量。
4. Loop-free: the secondary path join is sent on an ECMP disjoint path. By definition, the neighbor receiving this request is closer to the source and hence will not cause a loop.
4. 无循环：次要路径连接在ECMP不相交路径上发送。根据定义，接收此请求的邻居距离源较近，因此不会导致循环。
The topology we just analyzed is very frequent and can be modeled as per Figure 2. The PE has two ECMP disjoint paths to the source. Each ECMP path uses a disjoint plane of the network.
我们刚才分析的拓扑非常频繁，可以按照图2进行建模。PE有两条到源的ECMP不相交路径。每个ECMP路径使用一个不相交的网络平面。
Source
/ \
Plane1 Plane2
| |
A1 A2
\ /
PE
Source
/ \
Plane1 Plane2
| |
A1 A2
\ /
PE
Figure 2: PE is Dual-Homed to Dual-Plane Backbone
图2:PE是双主双平面主干
Another frequent topology is described in Figure 3. PEs are grouped by pairs. In each pair, each PE is connected to a different plane. Each PE has one single shortest-path to a source (via its connected plane). There is no ECMP like in Figure 2. However, there is clearly a way to provide MoFRR benefits as each PE can offer a disjoint secondary path to the PE in the other plane (via the disjoint path).
图3描述了另一种常见拓扑。PE按对分组。在每对中，每个PE连接到不同的平面。每个PE都有一条到源的最短路径（通过其连接平面）。没有如图2所示的ECMP。然而，显然有一种方法可以提供MoFRR好处，因为每个PE可以向另一个平面中的PE提供不相交的二次路径（通过不相交路径）。
The MoFRR secondary neighbor selection process needs to be extended in this case as one cannot simply rely on using an ECMP path as secondary neighbor. This extension is referred to as non-ECMP-mode MoFRR and is described in Section 3.2.
在这种情况下，需要扩展MoFRR次邻居选择过程，因为不能简单地依赖使用ECMP路径作为次邻居。该扩展称为非ECMP模式MoFRR，并在第3.2节中描述。
Source
/ \
Plane1 Plane2
| |
A1 A2
| |
PE1----PE2
Source
/ \
Plane1 Plane2
| |
A1 A2
| |
PE1----PE2
Figure 3: PEs Are Connected in Pairs to Dual-Plane Backbone
图3：PEs成对连接到双平面主干
As mentioned in Section 6, MoFRR works best in dual-plane topologies. If MoFRR is applied to non-dual-plane networks, it's possible that the secondary path is affected by the same failure that affected the
如第6节所述，MoFRR在双平面拓扑中工作得最好。如果MoFRR应用于非双平面网络，则次路径可能会受到影响网络的相同故障的影响
primary path. In that case, there is no guarantee that the backup path will provide an uninterrupted traffic flow of packets without loss or duplication.
主路径。在这种情况下，无法保证备份路径将提供不间断的数据包流量而不会丢失或重复。
The previous section has described two very frequent designs (Figures 2 and 3) which provide maximum MoFRR benefits.
上一节描述了两种非常常见的设计（图2和图3），它们提供了最大的MoFRR效益。
Designers with topologies different than Figures 2 and 3 can still benefit from MoFRR, thanks to the use of capacity planning tools.
由于使用了容量规划工具，拓扑结构不同于图2和图3的设计师仍然可以从MoFRR中获益。
Such tools are able to simulate the ability of each PE to build two disjoint branches of the same tree. This simulation could be for hundreds of PEs and hundreds of sources.
这些工具能够模拟每个PE构建同一棵树的两个不相交分支的能力。该模拟可用于数百个PE和数百个源。
This allows an assessment of the MoFRR protection coverage of a given network, for a set of sources.
这允许对一组源的给定网络的MoFRR保护范围进行评估。
If the protection coverage is deemed insufficient, the designer can use such a tool to optimize the topology (add links, change IGP metrics).
如果认为保护范围不足，设计者可以使用此类工具优化拓扑（添加链接、更改IGP指标）。
Many Service Providers devise their topology such that PEs have disjoint paths to the multicast sources. MoFRR leverages the existence of these disjoint paths without any PIM or mLDP protocol modification. Interoperability testing is thus not required. In such topologies, MoFRR only needs to be deployed on the PE devices. Each PE device can be enabled one by one.
许多服务提供商设计了他们的拓扑结构，使得PEs具有到多播源的不相交路径。MoFRR利用这些不相交路径的存在，而无需任何PIM或mLDP协议修改。因此不需要进行互操作性测试。在这种拓扑中，MoFRR只需要部署在PE设备上。每个PE设备都可以逐个启用。
While all the examples in this document show the MoFRR applicability on PE devices, it is clear that MoFRR could be enabled on aggregation or core routers.
虽然本文档中的所有示例都显示了MoFRR在PE设备上的适用性，但很明显，MoFRR可以在聚合或核心路由器上启用。
MoFRR can be popular in data center network configurations. With the advent of lower-cost Ethernet and increasing port density in routers, there is more meshed connectivity than ever before. When using a three-level access, distribution, and core layers in a data center, there is a lot of inexpensive bandwidth connecting the layers. This will lend itself to more opportunities for ECMP paths at multiple layers. This allows for multiple layers of redundancy protecting link and node failure at each layer with minimal redundancy cost.
MoFRR在数据中心网络配置中非常流行。随着低成本以太网的出现和路由器端口密度的增加，网状连接比以往任何时候都要多。在数据中心中使用三级访问、分发和核心层时，有大量廉价的带宽连接这些层。这将为多层ECMP路径提供更多机会。这允许多个冗余层，以最小的冗余成本保护每一层的链路和节点故障。
Redundancy costs are reduced because only one packet is forwarded at every link along the primary and secondary data paths so there is no duplication of data on any link thereby providing make-before-break protection at a very small cost.
冗余成本降低，因为在主数据路径和辅助数据路径上的每个链路上只转发一个数据包，因此任何链路上都没有数据重复，从而以非常小的成本提供先通后断保护。
A MoFRR router only accepts packets from the primary path and discards packets from the secondary path. For that reason, management applications (like ping and mtrace) will not work when verifying the secondary path.
MoFRR路由器只接受来自主路径的数据包，而丢弃来自次路径的数据包。因此，在验证辅助路径时，管理应用程序（如ping和mtrace）将无法工作。
The MoFRR principle may be applied to MVPNs.
MoFRR原则可适用于MVPN。
There are no security considerations for this design other than what is already in the main PIM specification [RFC4601] and mLDP specification [RFC6388].
除了主PIM规范[RFC4601]和mLDP规范[RFC6388]中已有的内容外，本设计没有其他安全考虑事项。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC5286] Atlas, A., Ed., and A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, DOI 10.17487/RFC5286, September 2008, <http://www.rfc-editor.org/info/rfc5286>.
[RFC5286]Atlas，A.，Ed.，和A.Zinin，Ed.，“IP快速重路由的基本规范：无环路交替”，RFC 5286，DOI 10.17487/RFC5286，2008年9月<http://www.rfc-editor.org/info/rfc5286>.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, DOI 10.17487/RFC4601, August 2006, <http://www.rfc-editor.org/info/rfc4601>.
[RFC4601]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 4601，DOI 10.17487/RFC4601，2006年8月<http://www.rfc-editor.org/info/rfc4601>.
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, <http://www.rfc-editor.org/info/rfc6388>.
[RFC6388]Wijnands，IJ.，Ed.，Minei，I.，Ed.，Kompella，K.和B.Thomas，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，RFC 6388，DOI 10.17487/RFC6388，2011年11月<http://www.rfc-editor.org/info/rfc6388>.
[RFC6571] Filsfils, C., Ed., Francois, P., Ed., Shand, M., Decraene, B., Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks", RFC 6571, DOI 10.17487/RFC6571, June 2012, <http://www.rfc-editor.org/info/rfc6571>.
[RFC6571]费斯菲尔斯，C.，Ed.，弗朗索瓦，P.，Ed.，尚德，M.，德雷恩，B.，乌塔罗，J.，莱曼，N.，和M.霍内弗，“服务提供商（SP）网络中的无环路备用（LFA）适用性”，RFC 6571，DOI 10.17487/RFC6571，2012年6月<http://www.rfc-editor.org/info/rfc6571>.
Acknowledgments
致谢
Thanks to Dave Oran and Alvaro Retana for their review and comments on this document.
感谢Dave Oran和Alvaro Retana对本文件的审查和评论。
The authors would like to especially acknowledge Dino Farinacci, John Zwiebel, and Greg Shepherd for the genesis of the MoFRR concept.
作者特别感谢迪诺·法里纳奇、约翰·兹维贝尔和格雷格·谢泼德对MoFRR概念的起源。
Contributors
贡献者
Below is a list of the contributors in alphabetical order:
以下是按字母顺序排列的贡献者列表：
Dino Farinacci Email: farinacci@gmail.com
Dino Farinaci电子邮件：farinacci@gmail.com
Wim Henderickx Alcatel-Lucent Copernicuslaan 50 Antwerp 2018 Belgium Email: wim.henderickx@alcatel-lucent.com
Wim Henderickx Alcatel-Lucent Copernicuslaan 50安特卫普2018比利时电子邮件：Wim。henderickx@alcatel-朗讯网
Uwe Joorde Deutsche Telekom Dahlweg 100 D-48153 Muenster Germany Email: Uwe.Joorde@telekom.de
Uwe Joorde Deutsche Telekom Dahlweg 100 D-48153 Muenster Germany电子邮件：Uwe。Joorde@telekom.de
Nicolai Leymann Deutsche Telekom Winterfeldtstrasse 21 Berlin 10781 Germany Email: N.Leymann@telekom.de
Nicolai Leymann德意志电信公司Winterfeldtstrasse 21柏林10781德国电子邮件：N。Leymann@telekom.de
Jeff Tantsura Ericsson 300 Holger Way San Jose, CA 95134 United States Email: jeff.tantsura@ericsson.com
Jeff Tantsura Ericsson加利福尼亚州圣何塞霍尔格大道300号，邮编95134美国电子邮件：Jeff。tantsura@ericsson.com
Authors' Addresses
作者地址
Apoorva Karan Cisco Systems, Inc. 3750 Cisco Way San Jose, CA 95134 United States
Apoorva Karan Cisco Systems，Inc.美国加利福尼亚州圣何塞市思科大道3750号，邮编95134
Email: apoorva@cisco.com
Email: apoorva@cisco.com
Clarence Filsfils Cisco Systems, Inc. De kleetlaan 6a Diegem BRABANT 1831 Belgium
Clarence Filsfils Cisco Systems，Inc.De kleetlaan 6a Diegem BRABANT 1831比利时
Email: cfilsfil@cisco.com
Email: cfilsfil@cisco.com
IJsbrand Wijnands (editor) Cisco Systems, Inc. De Kleetlaan 6a Diegem 1831 Belgium
IJsbrand Wijnands（编辑）思科系统公司De Kleetlaan 6a Diegem 1831比利时
Email: ice@cisco.com
Email: ice@cisco.com
Bruno Decraene Orange 38-40 rue du General Leclerc Issy Moulineaux Cedex 9, 92794 France
法国莱克莱尔将军街38-40号布鲁诺·德雷恩·奥兰治，邮编92794
Email: bruno.decraene@orange.com
Email: bruno.decraene@orange.com