[要約] RFC 7431は、マルチキャスト専用の高速切り替えに関する標準仕様です。その目的は、ネットワークの障害時にマルチキャストトラフィックの中断を最小限に抑えることです。
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（mLDP）などのマルチキャストルーティングプロトコルを簡単に拡張することで機能します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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).
マルチキャストビデオトラフィックとビデオオンデマンドトラフィックの両方でサービス保証を向上させるために、さまざまなソリューションが開発および導入されています。これらのソリューションのほとんどは、1つまたは複数の障害が発生したネットワーク要素（リンク、ノード、またはパスの障害）の周りに代替パスを見つけることを目的としています。
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からのパケットは破棄されます。 UMHの決定はPIMとmLDPで異なり、セクション4で説明されています。プライマリ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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
MoFRR: Multicast-only Fast Reroute.
MoFRR：マルチキャストのみの高速リルート。
ECMP: Equal-Cost Multipath.
ECMP：等コストマルチパス。
mLDP: Multipoint Label Distribution Protocol.
mLDP：Multipoint Label Distribution Protocol。
PIM: Protocol Independent Multicast.
PIM：Protocol Independent Multicast。
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.
マージポイント：2つの分岐アップストリームパスを介してマルチキャストストリームに参加するルーター。
RPF: Reverse Path Forwarding.
RPF：リバースパス転送。
RP: Rendezvous Point.
RP：ランデブーポイント。
LSP: Label Switched Path.
LSP：ラベルスイッチドパス。
LSR: Label Switching Router.
LSR：ラベルスイッチングルーター。
BFD: Bidirectional Forwarding Detection.
BFD：双方向転送検出。
IGP: Interior Gateway Protocol.
IGP：Interior Gateway Protocol。
MVPN: Multicast Virtual Private Network.
MVPN：マルチキャスト仮想プライベートネットワーク。
POP: Point Of Presence, an access point into the network.
POP：Point Of Presence、ネットワークへのアクセスポイント。
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の基本的な考え方は、最大の冗長性を得るために、マージポイントルータが2つの分岐するアップストリームパスを介してマルチキャストツリーに参加することです。この代替上流の決定は、セクション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.
障害に対する堅牢性を最大にするために、2つのパスは可能な限り多様である必要があります。理想的には、それらは上流でマージするべきではありません。トポロジは最大の冗長性を保証する場合があります。それを実施するために、追加の構成または手法が必要な場合もあります。ネットワークトポロジに応じた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.
マージポイントルーターは、パケット転送の重複を避けるために、一度に1つのアップストリームパスのみを受け入れて転送する必要があります。プライマリおよびセカンダリ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がソースへの2つの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拡張が有効になっていない場合と同じである必要があります（SHOULD）。
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.
3つ以上のECMPパスが存在する場合、1つがプライマリとして選択され、もう1つがセカンダリUMHとして選択されます。プライマリとセカンダリの選択は、ローカルの決定です。 IGPリンクステートトポロジからの情報を利用して、この選択を最適化し、プライマリパスとセカンダリパスが最大に分岐し、同じアップストリームノードにつながらないようにすることができます。 MoFRRは、結合されるUMHパスの数を制限しないことに注意してください。実装では、設定された数のパスを使用できます。
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 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).
このルールの理由を説明するために、図3の例を考えてみましょう。PE1とPE2の2つのプロバイダーエッジルーターがマルチキャストツリーのIGMP要求を受信した場合、両方のルーターのプレーンのプライマリパスとセカンダリパスに参加します。隣接するPEに。レシーバーが同時に離れた場合、PEはセカンダリパス結合を介して互いにリフレッシュするため、PE1およびPE2のマルチキャストツリーが削除されない可能性があります（セカンダリパス結合はプライマリ結合と区別できないことに注意してください）。 。
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を選択します。 UMHを決定する手順は、PIMとmLDPで異なります。
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選択は、Reverse Path Forwarding（RPF）手順とも呼ばれます。送信元アドレスまたはランデブーポイント（RP）[RFC4601]のいずれかでのユニキャストルートルックアップに基づいて、PIM Join / Prunesを送信し、マルチキャストパケットを受け入れるためのアップストリームインターフェイスが選択されます。パケットが受信されるインターフェイスは、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.
2つのパスが確立されたら、次のステップは、プライマリパスの障害を検出して、バックアップパスに切り替えるタイミングを知ることです。これはローカルの問題ですが、このセクションではいくつかの可能性を探ります。
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.
2番目のオプションは、プライマリストリームとセカンダリストリームで受信したパケットを比較し、そのうちの1つだけを転送することです。どのインターフェイスで受信したかに関係なく、最初のストリームを受信します。 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.
3番目のオプションは、特定のデータストリームの既知の最小パケットレートを想定しています。この時間枠内にプライマリRPFでパケットが受信されない場合、ルータはプライマリパス障害と見なし、セカンダリRPFインターフェイスに切り替えます。 50ミリ秒の切り替えは、高速ストリーム（たとえば、SDビデオに約3ミリ秒の連続したパケット間ギャップがあるIPTV）で可能ですが、一般的に、遅延はマルチキャストストリームのレートに依存します。
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.
4番目のオプションは、IGP収束速度の大幅な改善を活用します。ソースへのプライマリパスがIGPによって取り消されると、MoFRR対応ルーターはバックアップパスに切り替わり、UMHはセカンダリUMHに変更されます。セカンダリパスはすでに配置されており、プライマリパスから切り離されていると仮定すると、収束時間には、新しいツリーを構築するために必要な時間が含まれないため、より小さくなります。 1秒未満から200ミリ秒までの切り替えが可能です。
MoFRR applicability is topology dependent. The applicability is the same as LFA FRR, which is discussed in [RFC6571].
MoFRRの適用性はトポロジに依存します。適用可能性は、[RFC6571]で説明されているLFA FRRと同じです。
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）ルーターで有効になっていることが示されているため、テクノロジを展開する方法の1つを示しています。
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：2平面ネットワーク設計
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に完全に接続されていないプライマリプレーンとセカンダリプレーンの2つのプレーンがあります。この2プレーン設計は、コアネットワークの単一点障害を排除するため、サービスプロバイダーネットワークでは一般的です。 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 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.
MoFRRがこれに追加する唯一の変更は、PEルーターがセカンダリECMP UMHへのセカンダリパスに参加するSとマークされたリンクです。この結果、各PEルータは同じストリームの2つのコピーを受信します。1つはプライマリプレーンから、もう1つはセカンダリプレーンから受信します。通常のUMH動作の結果として、プライマリパスを介して受信されたマルチキャストストリームが受け入れられ、ダウンストリームレシーバーに転送されます。セカンダリ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デバイスからソースに向かう2つのECMPパスがあり、1つはプライマリプレーンに沿って、もう1つはセカンダリプレーンに沿っている単純なケースです。トポロジが非対称またはリングである場合、この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の2番目、3番目、4番目のオプションを参照してください。）
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チャネルに対応するマルチキャストツリーは、バックボーンと配信トポロジを非常に密にカバーしています。その結果、セカンダリパスは、アグリゲーションレベルで通常のマルチキャストツリー（つまり、MoFRR拡張なしのPIMまたはmLDPによってシグナリングされたツリー）に移植されるため、配布リンクまたはバックボーンのいずれにも追加の容量を要求しません。セカンダリパスは、重複することなく、通常使用される容量を使用するだけです。これは、バックアップパスがすでにプライマリ/ノーマルツリーを伝送するリンク/ノードをまたぐ場合に容量要件を複製することが多い従来のFRRメカニズムとは異なり、したがって、2倍の容量が必要です。
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には、ソースへの2つのECMP分離パスがあります。各ECMPパスは、ネットワークの分離プレーンを使用します。
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には、ソースへの（接続されたプレーンを介した）単一の最短パスが1つあります。図2のようなECMPはありません。ただし、各PEが他のプレーンのPEへの独立したセカンダリパスを提供するため（独立パスを介して）、MoFRRの利点を提供する方法は明らかにあります。
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.
この場合、セカンダリネイバーとしてECMPパスを使用するだけでは信頼できないため、MoFRRセカンダリネイバー選択プロセスを拡張する必要があります。この拡張は非ECMPモードMoFRRと呼ばれ、セクション3.2で説明されています。
Source
/ \
Plane1 Plane2
| |
A1 A2
| |
PE1----PE2
Figure 3: PEs Are Connected in Pairs to Dual-Plane Backbone
図3：PEはペアでデュアルプレーンバックボーンに接続されています
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 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.
セクション6で述べたように、MoFRRはデュアルプレーントポロジで最適に機能します。 MoFRRが非デュアルプレーンネットワークに適用されている場合、セカンダリパスが、プライマリパスに影響を与えたのと同じ障害の影響を受ける可能性があります。その場合、バックアップパスがパケットの損失や重複なしに中断のないトラフィックフローを提供するという保証はありません。
The previous section has described two very frequent designs (Figures 2 and 3) which provide maximum MoFRR benefits.
前のセクションでは、MoFRRのメリットを最大化する2つの非常に頻繁な設計（図2および3）について説明しました。
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が同じツリーの2つのばらばらのブランチを構築する能力をシミュレートできます。このシミュレーションは、数百の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.
多くのサービスプロバイダーは、PEがマルチキャストソースへの分離したパスを持つようにトポロジを考案しています。 MoFRRは、PIMまたはmLDPプロトコルを変更せずに、これらの分離したパスの存在を活用します。したがって、相互運用性テストは必要ありません。このようなトポロジでは、MoFRRはPEデバイスにのみ展開する必要があります。各PEデバイスは1つずつ有効にできます。
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.
このドキュメントのすべての例は、PEデバイスでのMoFRRの適用性を示していますが、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は、データセンターのネットワーク構成で人気があります。低コストのイーサネットの登場とルーターのポート密度の増加により、メッシュ接続はかつてないほど多くなっています。データセンターで3レベルのアクセス、ディストリビューション、およびコアレイヤーを使用する場合、レイヤーを接続する多くの安価な帯域幅があります。これは、複数のレイヤーで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.
プライマリとセカンダリのデータパスに沿ってすべてのリンクで1つのパケットのみが転送されるため、冗長コストが削減され、リンク上でデータの重複がなくなり、非常に小さなコストでメークビフォアブレイクプロテクションが提供されます。
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。、編、およびA. Zinin、編、「IP Fast Rerouteの基本仕様：ループフリー代替」、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、「Protocol Independent Multicast-Sparse Mode（PIM-SM）：Protocol Specification（Revised）」、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.、and B. Thomas、 "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths" 、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] Filsfils、C。、編、Francois、P。、編、Shand、M.、Decraene、B.、Uttaro、J.、Leymann、N。、およびM. Horneffer、「Loop-Free Alternate（ LFA）Applicability in Service Provider（SP）Networks」、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コンセプトの起源についてDino Farinacci、John Zwiebel、およびGreg Shepherdを特に認めたいと思います。
Contributors
貢献者
Below is a list of the contributors in alphabetical order:
以下は、貢献者のアルファベット順のリストです。
Dino Farinacci Email: farinacci@gmail.com
Dino Farinacciメール：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ベルギーEメール：wim.henderickx@alcatel-lucent.com
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 Deutsche Telekom 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 Holger Way San Jose、CA 95134 United States Email：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 Cisco Way San Jose、CA 95134アメリカ合衆国
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 Belgium
Email: cfilsfil@cisco.com
IJsbrand Wijnands (editor) Cisco Systems, Inc. De Kleetlaan 6a Diegem 1831 Belgium
IJsbrand Wijnands（編集者）Cisco Systems、Inc. De Kleetlaan 6a Diegem 1831ベルギー
Email: ice@cisco.com
Bruno Decraene Orange 38-40 rue du General Leclerc Issy Moulineaux Cedex 9, 92794 France
Bruno Decraene Orange 38-40 rue du General Leclerc Issy Moulineaux Cedex 9、92794 France
Email: bruno.decraene@orange.com