[要約] RFC 6754は、プロトコルに依存しないマルチキャストECMPリダイレクトの仕様を定義しています。その目的は、マルチキャストトラフィックの負荷分散と冗長性を向上させることです。
Internet Engineering Task Force (IETF) Y. Cai
Request for Comments: 6754 Microsoft
Category: Standards Track L. Wei
ISSN: 2070-1721 H. Ou
Cisco Systems, Inc.
V. Arya
S. Jethwani
DIRECTV Inc.
October 2012
Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect
Protocol Independent Multicast Equal-Cost Multipath（ECMP）Redirect
Abstract
概要
A Protocol Independent Multicast (PIM) router uses the Reverse Path Forwarding (RPF) procedure to select an upstream interface and router in order to build forwarding state. When there are equal-cost multipaths (ECMPs), existing implementations often use hash algorithms to select a path. Such algorithms do not allow the spread of traffic among the ECMPs according to administrative metrics. This usually leads to inefficient or ineffective use of network resources. This document introduces the ECMP Redirect, a mechanism to improve the RPF procedure over ECMPs. It allows ECMP selection to be based on administratively selected metrics, such as data transmission delays, path preferences, and routing metrics.
Protocol Independent Multicast（PIM）ルーターは、Reverse Path Forwarding（RPF）手順を使用して、転送状態を構築するために上流のインターフェイスとルーターを選択します。等コストマルチパス（ECMP）がある場合、既存の実装では、ハッシュアルゴリズムを使用してパスを選択することがよくあります。このようなアルゴリズムでは、管理メトリックに従ってECMP間でトラフィックを分散させることはできません。これは通常、ネットワークリソースの非効率的または非効率的な使用につながります。このドキュメントでは、ECMPを介してRPF手順を改善するメカニズムであるECMPリダイレクトを紹介します。 ECMPの選択は、データ送信遅延、パス設定、ルーティングメトリックなど、管理上選択されたメトリックに基づくことができます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc6754.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6754で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Protocol Specification . . . . . . . . . . . . . . . . . . . . 6
5.1. Sending ECMP Redirect . . . . . . . . . . . . . . . . . . 6
5.2. Receiving ECMP Redirect . . . . . . . . . . . . . . . . . 7
5.3. Transient State . . . . . . . . . . . . . . . . . . . . . 7
5.4. Interoperability . . . . . . . . . . . . . . . . . . . . . 8
5.5. Packet Format . . . . . . . . . . . . . . . . . . . . . . 8
5.5.1. PIM ECMP Redirect Hello Option . . . . . . . . . . . . 8
5.5.2. PIM ECMP Redirect Format . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
A PIM router uses the RPF procedure to select an upstream interface and a PIM neighbor on that interface to build forwarding state. When there are equal-cost multipaths (ECMPs) upstream, existing implementations often use hash algorithms to select a path. Such algorithms do not allow the spread of traffic among the ECMP according to administrative metrics. This usually leads to inefficient or ineffective use of network resources. This document introduces the ECMP Redirect, a mechanism to improve the RPF procedure over ECMP. It allows ECMP selection to be based on administratively selected metrics, such as data transmission delays, path preferences, and routing metrics, or a combination of metrics.
PIMルータはRPF手順を使用して、アップストリームインターフェイスとそのインターフェイス上のPIMネイバーを選択し、転送状態を構築します。等コストマルチパス（ECMP）アップストリームがある場合、既存の実装では、ハッシュアルゴリズムを使用してパスを選択することがよくあります。このようなアルゴリズムでは、管理メトリックに従ってECMP間でトラフィックを分散させることはできません。これは通常、ネットワークリソースの非効率的または非効率的な使用につながります。このドキュメントでは、ECMP経由でRPF手順を改善するメカニズムであるECMPリダイレクトを紹介します。 ECMPの選択は、データ送信遅延、パス設定、ルーティングメトリック、またはメトリックの組み合わせなど、管理上選択されたメトリックに基づくことができます。
ECMPs are frequently used in networks to provide redundancy and to increase available bandwidth. A PIM router selects a path in the ECMP based on its own implementation-specific choice. The selection is a local decision. One way is to choose the PIM neighbor with the highest IP address; another is to pick the PIM neighbor with the best hash value over the destination and source addresses.
ECMPはネットワークで頻繁に使用され、冗長性を提供し、使用可能な帯域幅を増やします。 PIMルーターは、独自の実装固有の選択に基づいてECMP内のパスを選択します。選択はローカルの決定です。 1つの方法は、最大のIPアドレスを持つPIMネイバーを選択することです。もう1つは、宛先アドレスと送信元アドレスでハッシュ値が最も良いPIMネイバーを選択することです。
While implementations supporting ECMP have been deployed widely, the existing RPF selection methods have weaknesses. The lack of administratively effective ways to allocate traffic over alternative paths is a major issue. For example, there is no straightforward way to tell two downstream routers to select either the same or different RPF neighbor routers for the same traffic flows.
ECMPをサポートする実装は広く展開されていますが、既存のRPF選択方法には弱点があります。代替パスにトラフィックを割り当てるための管理上効果的な方法の欠如は、大きな問題です。たとえば、同じトラフィックフローに対して同じまたは異なるRPFネイバールータを選択するように2つのダウンストリームルータに指示する簡単な方法はありません。
With the ECMP Redirect mechanism introduced here, the upstream routers use a PIM ECMP Redirect message to instruct the downstream routers on how to tiebreak among the upstream neighbors. The PIM ECMP Redirect message conveys the tiebreak information based on metrics selected administratively.
ここで紹介するECMPリダイレクトメカニズムにより、上流ルーターはPIM ECMPリダイレクトメッセージを使用して、上流ルーター間でタイブレークする方法を下流ルーターに指示します。 PIM ECMPリダイレクトメッセージは、管理上選択されたメトリックに基づいてタイブレーク情報を伝えます。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document uses terms defined in [RFC4601] to describe actions taken by PIM routers.
このドキュメントでは、[RFC4601]で定義されている用語を使用して、PIMルーターによって実行されるアクションについて説明します。
The following terms have special significance for ECMP Redirect:
次の用語は、ECMPリダイレクトにとって特別な意味を持っています。
o Equal-Cost Multipath (ECMP). In this document, the term "ECMP" refers to parallel, single-hop, equal-cost links between adjacent nodes.
o 等コストマルチパス（ECMP）。このドキュメントでは、「ECMP」という用語は、隣接ノード間の並列、シングルホップ、等コストのリンクを指します。
o ECMP Bundle. An ECMP bundle is a set of PIM-enabled interfaces on a router, where all interfaces belonging to the same bundle share the same routing metric. The next hops for the ECMP are all one hop away.
o ECMPバンドル。 ECMPバンドルは、ルーター上のPIM対応インターフェースのセットであり、同じバンドルに属するすべてのインターフェースが同じルーティングメトリックを共有します。 ECMPのネクストホップはすべて1ホップです。
There can be one or more ECMP bundles on any router, while one individual interface can only belong to a single bundle. ECMP bundles are created on a router via configuration.
ルーターには1つ以上のECMPバンドルが存在できますが、1つの個別のインターフェースは単一のバンドルにのみ属することができます。 ECMPバンドルは、構成を介してルーター上に作成されます。
o RPF. RPF stands for Reverse Path Forwarding.
o RPF。 RPFは、Reverse Path Forwardingの略です。
o Upstream. Towards the root of the multicast forwarding tree. An upstream router refers to a router that is forwarding, or potentially capable of forwarding, data packets onto interfaces in an ECMP bundle.
o 上流の。マルチキャスト転送ツリーのルートに向かって。アップストリームルーターとは、ECMPバンドルのインターフェイスにデータパケットを転送する、または転送できる可能性のあるルーターを指します。
When there are multiple routers forwarding packets onto interfaces in the ECMP bundle, all these routers are called upstream routers.
ECMPバンドルのインターフェイスにパケットを転送する複数のルーターがある場合、これらのすべてのルーターは上流ルーターと呼ばれます。
o Downstream. Away from the root of the multicast forwarding tree. A downstream router is a router that uses an interface in the ECMP bundle as an RPF interface for a multicast forwarding entry.
o 下流。マルチキャスト転送ツリーのルートから離れています。ダウンストリームルータは、ECMPバンドルのインターフェイスをマルチキャスト転送エントリのRPFインターフェイスとして使用するルータです。
The existing PIM Assert mechanism allows the upstream router to detect the existence of multiple forwarders for the same multicast flow onto the same downstream interface. The upstream router sends a PIM Assert message containing a routing metric for the downstream routers to use for tiebreaking among the multiple upstream forwarders on the same RPF interface.
既存のPIMアサートメカニズムにより、アップストリームルータは、同じダウンストリームインターフェイスへの同じマルチキャストフローに対する複数のフォワーダの存在を検出できます。アップストリームルータは、ダウンストリームルータが同じRPFインターフェイス上の複数のアップストリームフォワーダ間のタイブレイクに使用するルーティングメトリックを含むPIMアサートメッセージを送信します。
With ECMP interfaces between the downstream and upstream routers, the PIM ECMP Redirect mechanism works in a similar way, but extends the ability to resolve the selection of forwarders among different interfaces in the ECMP.
ダウンストリームルータとアップストリームルータ間のECMPインターフェイスを使用すると、PIM ECMPリダイレクトメカニズムは同様に機能しますが、ECMPの異なるインターフェイス間でフォワーダの選択を解決する機能が拡張されます。
When a PIM router downstream of the ECMP interfaces creates a new (*,G) or (S,G) entry, it will populate the RPF interface and RPF neighbor information according to the rules specified by [RFC4601]. This router will send its initial PIM Joins to that RPF neighbor.
ECMPインターフェースの下流にあるPIMルーターが新しい（*、G）または（S、G）エントリーを作成すると、[RFC4601]で指定されたルールに従ってRPFインターフェースとRPFネイバー情報が入力されます。このルータは、そのRPFネイバーに最初のPIM加入を送信します。
When the RPF neighbor router receives the Join message and finds that the receiving interface is one of the ECMP interfaces, it will check if the same flow is already being forwarded out of another ECMP interface. If so, this RPF neighbor router will send a PIM ECMP Redirect message onto the interface the Join was received on. The PIM ECMP Redirect message contains the address of the desired RPF neighbor, an Interface ID [RFC6395], and the other parameters used as tiebreakers. In essence, a PIM ECMP Redirect message is sent by an upstream router to notify downstream routers to redirect PIM Joins to the new RPF neighbor via a different interface. When the downstream routers receive this message, they SHOULD trigger PIM Joins toward the new RPF neighbor specified in the packet.
RPFネイバールータがJoinメッセージを受信し、受信インターフェイスがECMPインターフェイスの1つであることを検出すると、同じフローがすでに別のECMPインターフェイスから転送されているかどうかを確認します。その場合、このRPFネイバールータは、加入が受信されたインターフェイスにPIM ECMPリダイレクトメッセージを送信します。 PIM ECMPリダイレクトメッセージには、目的のRPFネイバーのアドレス、インターフェイスID [RFC6395]、およびタイブレーカーとして使用されるその他のパラメーターが含まれています。本質的に、PIM ECMP Redirectメッセージは上流のルーターによって送信され、下流のルーターにPIM Joinを別のインターフェイスを介して新しいRPFネイバーにリダイレクトするよう通知します。ダウンストリームルータはこのメッセージを受信すると、パケットで指定された新しいRPFネイバーへのPIM加入をトリガーする必要があります（SHOULD）。
This PIM ECMP Redirect message has similar functions as the existing PIM Assert message:
このPIM ECMPリダイレクトメッセージには、既存のPIMアサートメッセージと同様の機能があります。
1. It is sent by an upstream router.
1. 上流のルーターから送信されます。
2. It is used to influence the RPF selection by downstream routers.
2. これは、ダウンストリームルータによるRPF選択に影響を与えるために使用されます。
3. A tiebreaker metric is used.
3. タイブレーカーメトリックが使用されます。
However, the existing Assert message is used to select an upstream router within the same multi-access network (such as a LAN), while the Redirect message is used to select both a network and an upstream router.
ただし、既存のAssertメッセージは同じマルチアクセスネットワーク（LANなど）内の上流ルーターを選択するために使用され、Redirectメッセージはネットワークと上流ルーターの両方を選択するために使用されます。
One advantage of this design is that the control messages are only sent when there is a need to "rebalance" the traffic. This reduces the amount of control traffic.
この設計の利点の1つは、トラフィックを「再調整」する必要がある場合にのみ制御メッセージが送信されることです。これにより、制御トラフィックの量が減少します。
The use of ECMP Redirect applies to shared trees or source trees built with procedures described in [RFC4601]. The use of ECMP Redirect in PIM Dense Mode [RFC3973] or in Bidirectional PIM [RFC5015] is not considered in this document.
ECMPリダイレクトの使用は、[RFC4601]で説明されている手順で構築された共有ツリーまたはソースツリーに適用されます。 PIM高密度モード[RFC3973]または双方向PIM [RFC5015]でのECMPリダイレクトの使用は、このドキュメントでは考慮されていません。
The enhancement described in this document can be applicable to a number of scenarios. For example, it allows a network operator to use ECMPs and have the ability to perform load splitting based on bandwidth. To do this, the downstream routers perform RPF selection with bandwidth, instead of IP addresses, as a tiebreaker. The ECMP Redirect mechanism assures that all downstream routers select the desired network link and upstream router whenever possible. Another example is for a network operator to impose a transmission delay limit on certain links. The ECMP Redirect mechanism provides a means for an upstream router to instruct a downstream router to choose a different RPF path.
このドキュメントで説明する拡張機能は、さまざまなシナリオに適用できます。たとえば、ネットワークオペレーターはECMPを使用でき、帯域幅に基づいて負荷分割を実行できます。これを行うために、ダウンストリームルーターはタイブレーカーとしてIPアドレスではなく帯域幅を使用してRPF選択を実行します。 ECMPリダイレクトメカニズムは、すべてのダウンストリームルーターが、可能な場合はいつでも目的のネットワークリンクとアップストリームルーターを選択することを保証します。別の例は、ネットワークオペレーターが特定のリンクに送信遅延制限を課すことです。 ECMPリダイレクトメカニズムは、アップストリームルータがダウンストリームルータに異なるRPFパスを選択するように指示する手段を提供します。
This specification does not dictate the scope of applications of this mechanism.
この仕様は、このメカニズムの適用範囲を規定するものではありません。
ECMP Redirects are sent by an upstream router in a rate-limited fashion, under either of the following conditions:
ECMPリダイレクトは、次のいずれかの条件下で、レート制限された方法で上流ルーターから送信されます。
o It detects a PIM Join on a non-desired outgoing interface.
o 不要な発信インターフェイスでPIM加入を検出します。
o It detects multicast traffic on a non-desired outgoing interface.
o 不要な発信インターフェイス上のマルチキャストトラフィックを検出します。
In both cases, an ECMP Redirect is sent to the non-desired interface. An outgoing interface is considered "non-desired" when:
どちらの場合も、ECMPリダイレクトが不要なインターフェイスに送信されます。次の場合、発信インターフェイスは「不要」と見なされます。
o The upstream router is already forwarding the same flow out of another interface belonging to the same ECMP bundle.
o アップストリームルータは、同じECMPバンドルに属する別のインターフェイスから同じフローをすでに転送しています。
o The upstream router is not yet forwarding the flow out any interfaces of the ECMP bundle, but there is another interface with more desired attributes.
o 上流ルーターはまだECMPバンドルのどのインターフェースからもフローを転送していませんが、より望ましい属性を持つ別のインターフェースがあります。
An upstream router MAY choose not to send ECMP Redirects if it becomes aware that some of the downstream routers are unreachable via some links in ECMP bundle.
上流ルーターは、ECMPバンドルの一部のリンク経由で到達できない下流ルーターがあることを認識した場合、ECMPリダイレクトを送信しないことを選択してもよい（MAY）。
An upstream router uses the Neighbor Address or the Interface ID field in the ECMP Redirect message to indicate the interface it wants traffic to be directed to. This Neighbor Address MUST be associated with an interface in the same ECMP bundle as the ECMP Redirect message's outgoing interface. If the Interface ID field is ignored, this Neighbor Address field uniquely identifies a LAN and an upstream router to which a downstream router SHOULD redirect its Join messages, and an ECMP Redirect message MUST be discarded if the Neighbor Address field in the message does not match the cached neighbor address.
アップストリームルータは、ECMPリダイレクトメッセージのネイバーアドレスまたはインターフェイスIDフィールドを使用して、トラフィックの送信先となるインターフェイスを示します。このネイバーアドレスは、ECMPリダイレクトメッセージの発信インターフェイスと同じECMPバンドル内のインターフェイスに関連付けられている必要があります。 Interface IDフィールドが無視される場合、このNeighbor Addressフィールドは、LANとダウンストリームルータがそのJoinメッセージをリダイレクトするアップストリームルータを一意に識別し、メッセージ内のNeighbor Addressフィールドが一致しない場合は、ECMP Redirectメッセージを破棄する必要があります。キャッシュされたネイバーアドレス。
The Interface ID field is used in IPv4 when one or more RPF neighbors in the ECMP bundle are unnumbered, or in IPv6 where link-local addresses are in use. For other IPv4 usage, this field is zeroed when sent, and ignored when received. If the Router ID part of the Interface ID is zero, the field MUST be ignored. See [RFC6395] for details of its assignment and usage in PIM Hellos. If the Interface ID is not ignored, the receiving router of this message MUST use the Interface ID, instead of Neighbor Address, to identify the new RPF neighbor. Additionally, an ECMP Redirect message MUST be discarded if the Interface ID field in the message does not match the cached Interface ID.
インターフェイスIDフィールドは、ECMPバンドルの1つ以上のRPFネイバーが番号付けされていない場合のIPv4、またはリンクローカルアドレスが使用されているIPv6で使用されます。他のIPv4の使用法では、このフィールドは送信時にゼロになり、受信時に無視されます。インターフェイスIDのルーターID部分がゼロの場合、フィールドは無視する必要があります。 PIM Hellosでの割り当てと使用法の詳細については、[RFC6395]を参照してください。インターフェイスIDが無視されない場合、このメッセージの受信ルータは、ネイバーアドレスの代わりにインターフェイスIDを使用して、新しいRPFネイバーを識別する必要があります。さらに、メッセージのインターフェイスIDフィールドがキャッシュされたインターフェイスIDと一致しない場合は、ECMPリダイレクトメッセージを破棄する必要があります。
When a downstream router receives an ECMP Redirect, and detects that the desired RPF path from its upstream router's point of view is different from its current one, it should choose to join the newly suggested path and prune from the current path. The exact order of such actions is implementation specific.
ダウンストリームルータがECMPリダイレクトを受信し、アップストリームルータの観点からの望ましいRPFパスが現在のものと異なることを検出した場合、新しく提案されたパスに参加し、現在のパスからプルーニングすることを選択する必要があります。そのようなアクションの正確な順序は実装固有です。
If a downstream router receives multiple ECMP Redirects sent by different upstream routers, it SHOULD use the Preference, Metric, or other fields as specified below as the tiebreakers to choose the most preferred RPF interface and neighbor. The tiebreak procedure is the same as that used in PIM Assert processing described by [RFC4601].
ダウンストリームルータが異なるアップストリームルータによって送信された複数のECMPリダイレクトを受信する場合、タイブレーカとして以下に指定されているように、プリファレンス、メトリック、またはその他のフィールドを使用して、最も優先されるRPFインターフェイスとネイバーを選択する必要があります。タイブレーク手順は、[RFC4601]で説明されているPIMアサート処理で使用される手順と同じです。
If an upstream router receives an ECMP Redirect, it SHOULD NOT change its forwarding behavior even if the ECMP Redirect makes it a less preferred RPF neighbor on the receiving interface.
上流ルーターがECMPリダイレクトを受信する場合、ECMPリダイレクトによって受信インターフェースで優先度の低いRPFネイバーになったとしても、その転送動作を変更してはなりません（SHOULD NOT）。
During a transient network outage with a single link cut in an ECMP bundle, a downstream router may lose connection to its RPF neighbor and the normal ECMP Redirect operation may be interrupted temporarily. In such an event, the following actions are RECOMMENDED.
ECMPバンドルで1つのリンクが切断された一時的なネットワーク停止中に、ダウンストリームルータがRPFネイバーへの接続を失い、通常のECMPリダイレクト操作が一時的に中断される場合があります。そのような場合、以下のアクションが推奨されます。
The downstream router SHOULD select a new RPF neighbor. Among all ECMP upstream routers, the preferred selection is the one on the LAN that the previous RPF neighbor resided on.
ダウンストリームルーターは新しいRPFネイバーを選択する必要があります（SHOULD）。すべてのECMPアップストリームルータの中で、優先される選択は、前のRPFネイバーが常駐していたLAN上のものです。
If there is no upstream router reachable on the LAN that the previous RPF neighbor resided on, the downstream router will select a new RPF neighbor on a different LAN. Among all ECMP upstream routers, the one that served as RPF neighbor before the link failure is preferred. Such a router can be identified by the Router ID, which is part of the Interface ID in the PIM ECMP Redirect Hello option.
以前のRPFネイバーが存在していたLANに到達可能なアップストリームルータがない場合、ダウンストリームルータは別のLAN上の新しいRPFネイバーを選択します。すべてのECMPアップストリームルータの中で、リンク障害の前にRPFネイバーとして機能したルータが推奨されます。このようなルーターは、PIM ECMP Redirect HelloオプションのインターフェイスIDの一部であるルーターIDで識別できます。
During normal ECMP Redirect operations, when PIM Joins for the same (*,G) or (S,G) are received on a different LAN, an upstream router will send ECMP Redirect to prune the non-preferred LAN. Such ECMP Redirects during partial network outage can be suppressed if the upstream router decides that the non-preferred PIM Join is from a router that is not reachable via the preferred LAN. This check can be performed by retrieving the downstream router's Router ID, using the source address in the PIM Join, and searching neighbors on the preferred LAN for one with the same Router ID.
通常のECMPリダイレクト操作中に、同じ（*、G）または（S、G）のPIM加入が別のLANで受信されると、上流ルーターはECMPリダイレクトを送信して非優先LANをプルーニングします。上流のルーターが非優先PIM加入が優先LAN経由で到達できないルーターからのものであると判断した場合、部分的なネットワーク停止中のこのようなECMPリダイレクトを抑制できます。このチェックは、ダウンストリームルータのルータIDを取得し、PIMジョインのソースアドレスを使用して、同じルータIDを持つものを優先LANのネイバーから検索することで実行できます。
If a PIM router supports this specification, it MUST send the PIM ECMP Redirect Hello Option in its PIM Hello messages.
PIMルーターがこの仕様をサポートする場合、PIM HelloメッセージでPIM ECMP Redirect Hello Optionを送信する必要があります。
A PIM router sends ECMP Redirects on an interface only when it detects that all neighbors on that interface have sent this Hello option. If a PIM router detects that any of its neighbors on an ECMP bundle does not support this Hello option, it SHOULD NOT send ECMP Redirects to interfaces in that bundle; however, it SHOULD still process any ECMP Redirects received from interfaces in that same bundle.
PIMルーターは、そのインターフェイスのすべてのネイバーがこのHelloオプションを送信したことを検出した場合にのみ、インターフェイスでECMPリダイレクトを送信します。 PIMルーターは、ECMPバンドルのネイバーのいずれかがこのHelloオプションをサポートしていないことを検出した場合、そのバンドルのインターフェースにECMPリダイレクトを送信してはなりません（SHOULD NOT）。ただし、同じバンドル内のインターフェイスから受信したECMPリダイレクトは引き続き処理する必要があります（SHOULD）。
If a PIM router does not support this specification, it will ignore the PIM ECMP Redirect Hello Options and ECMP Redirects in the PIM packets that it receives.
PIMルーターがこの仕様をサポートしていない場合、PIMルーターは、受信したPIMパケットのPIM ECMPリダイレクトHelloオプションとECMPリダイレクトを無視します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 32 | Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ECMP Redirect Hello Option
図1：ECMPリダイレクトHelloオプション
Type: 32
タイプ：32
Length: 0
長さ：0
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+- ............ Interface ID ........... -+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-- ... Metric ... -+-+-+-+-+-+-+-+-+
| |
+- .. Metric .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
Figure 2: ECMP Redirect Message Format
図2：ECMPリダイレクトメッセージの形式
PIM Ver: See Section 4.9 in [RFC4601].
PIM Ver：[RFC4601]のセクション4.9をご覧ください。
Type: 11
タイプ：11
Reserved: See Section 4.9 in [RFC4601].
予約済み：[RFC4601]のセクション4.9をご覧ください。
Checksum: See Section 4.9 in [RFC4601].
チェックサム：[RFC4601]のセクション4.9をご覧ください。
Group Address (64 or 160 bits): Encoded-Group address as specified in Section 4.9.1 of [RFC4601].
グループアドレス（64ビットまたは160ビット）：[RFC4601]のセクション4.9.1で指定されているエンコードグループアドレス。
Source Address (48 or 144 bits): Encoded-Unicast address as specified in Section 4.9.1 of [RFC4601].
送信元アドレス（48または144ビット）：[RFC4601]のセクション4.9.1で指定されている、エンコードされたユニキャストアドレス。
Neighbor Address (32 or 128 bits): Address of desired upstream neighbor where the downstream receiver redirects PIM Joins.
ネイバーアドレス（32または128ビット）：ダウンストリームレシーバーがPIM加入をリダイレクトする、目的のアップストリームネイバーのアドレス。
Interface ID (64 bits): See [RFC6395] for details.
インターフェイスID（64ビット）：詳細については、[RFC6395]を参照してください。
Preference (8 bits): The first tiebreaker when ECMP Redirects from multiple upstream routers are compared against each other. A numerically smaller value is preferred. A reserved value (15) is used to indicate the metric value following the Preference field is a Network Time Protocol (NTP) timestamp, encoded in the format specified in [RFC5905], taken at the moment the sending router started to forward out of this interface.
設定（8ビット）：複数の上流ルーターからのECMPリダイレクトが互いに比較されるときの最初のタイブレーカー。数値的に小さい値が推奨されます。予約済みの値（15）は、Preferenceフィールドに続くメトリック値が、[RFC5905]で指定された形式でエンコードされたネットワークタイムプロトコル（NTP）タイムスタンプであることを示すために使用されます。インターフェース。
Metric (64 bits): The second tiebreaker if the Preference values are the same. A numerically smaller value is preferred. This Metric can contain path parameters defined by users. When the Preference and Metric values are the same, the Neighbor Address or Interface ID field is used as the third tiebreaker, depending on which field is used to identify the RPF neighbor; the bigger value wins.
メトリック（64ビット）：設定値が同じ場合の2番目のタイブレーカー。数値的に小さい値が推奨されます。このメトリックには、ユーザーが定義したパスパラメータを含めることができます。 PreferenceとMetricの値が同じ場合、RPFネイバーの識別に使用されるフィールドに応じて、3番目のタイブレーカーとしてNeighbor AddressまたはInterface IDフィールドが使用されます。大きな値が優先されます。
A PIM-Hello Option Type (32) has been assigned to the PIM ECMP Redirect Hello Option.
PIM-Helloオプションタイプ（32）がPIM ECMPリダイレクトHelloオプションに割り当てられました。
In the PIM Message Types registry created by [RFC6166], a PIM Message Type (11) has been assigned to the ECMP Redirect message.
[RFC6166]によって作成されたPIMメッセージタイプレジストリでは、PIMメッセージタイプ（11）がECMPリダイレクトメッセージに割り当てられています。
Security of the ECMP Redirect is only guaranteed by the security of the PIM packet; the security considerations for PIM Assert packets as described in [RFC4601] apply here. Spoofed ECMP Redirect packets may cause the downstream routers to send PIM Joins to an undesired upstream router and trigger more ECMP Redirect messages. Security considerations for PIM packets described in [RFC4601] also apply to the new Hello option defined here.
ECMPリダイレクトのセキュリティは、PIMパケットのセキュリティによってのみ保証されます。 [RFC4601]で説明されているPIMアサートパケットのセキュリティに関する考慮事項がここに適用されます。スプーフィングされたECMPリダイレクトパケットにより、ダウンストリームルーターがPIMジョインを不要なアップストリームルーターに送信し、より多くのECMPリダイレクトメッセージをトリガーする可能性があります。 [RFC4601]で説明されているPIMパケットのセキュリティに関する考慮事項は、ここで定義されている新しいHelloオプションにも適用されます。
The authors would like to thank Apoorva Karan for helping with the original idea, and Eric Rosen, Isidor Kouvelas, Toerless Eckert, Stig Venaas, Jeffrey Zhang, Bill Atwood, and Adrian Farrel for their review comments.
著者は、元のアイデアを支援してくれたApoorva Karanに感謝し、レビューコメントを提供してくれたEric Rosen、Isidor Kouvelas、Toerless Eckert、Stig Venaas、Jeffrey Zhang、Bill Atwood、Adrian Farrelに感謝します。
[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月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601] Fenner、B.、Handley、M.、Holbrook、H。、およびI. Kouvelas、「Protocol Independent Multicast-Sparse Mode（PIM-SM）：Protocol Specification（Revised）」、RFC 4601、2006年8月。
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.
[RFC3973] Adams、A.、Nicholas、J。、およびW. Siadak、「Protocol Independent Multicast-Dense Mode（PIM-DM）：Protocol Specification（Revised）」、RFC 3973、2005年1月。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[RFC5015] Handley、M.、Kouvelas、I.、Speakman、T。、およびL. Vicisano、「Bidirectional Protocol Independent Multicast（BIDIR-PIM）」、RFC 5015、2007年10月。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905] Mills、D.、Martin、J.、Ed。、Burbank、J。、およびW. Kasch、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、2010年6月。
[RFC6166] Venaas, S., "A Registry for PIM Message Types", RFC 6166, April 2011.
[RFC6166] Venaas、S。、「A Registry for PIM Message Types」、RFC 6166、2011年4月。
[RFC6395] Gulrajani, S. and S. Venaas, "An Interface Identifier (ID) Hello Option for PIM", RFC 6395, October 2011.
[RFC6395] Gulrajani、S。およびS. Venaas、「An Interface Identifier（ID）Hello Option for PIM」、RFC 6395、2011年10月。
Authors' Addresses
著者のアドレス
Yiqun Cai Microsoft 1065 La Avenida Mountain View, CA 94043 USA
Y IグループCAI Microsoft 1065 LA av EN IDAマウンテンビュー、CA 94043米国
EMail: yiqunc@microsoft.com
Liming Wei Cisco Systems, Inc. Tasman Drive San Jose, CA 95134 USA
Liming Wei Cisco Systems、Inc. Tasman Drive San Jose、CA 95134 USA
EMail: lwei@cisco.com
Heidi Ou Cisco Systems, Inc. Tasman Drive San Jose, CA 95134 USA
Heidi Ou Cisco Systems、Inc. Tasman Drive San Jose、CA 95134 USA
EMail: hou@cisco.com
Vishal Arya DIRECTV Inc. 2230 E Imperial Hwy El Segundo, CA 90245 USA
ゔぃしゃｌ ありゃ ぢれＣＴＶ いんｃ。 ２２３０ え いｍぺりあｌ Ｈｗｙ えｌ せぐんど、 か ９０２４５ うさ
EMail: varya@directv.com
Sunil Jethwani DIRECTV Inc. 2230 E Imperial Hwy El Segundo, CA 90245 USA
Sunil Jethwani DIRECTV Inc. 2230 E Imperial Hwy El Segundo、CA 90245 USA
EMail: sjethwani@directv.com