[要約] RFC 7891は、明示的な逆経路転送（RPF）ベクトルに関する仕様であり、ネットワークの経路選択におけるセキュリティと信頼性を向上させることを目的としています。
Internet Engineering Task Force (IETF) J. Asghar
Request for Comments: 7891 IJ. Wijnands, Ed.
Category: Standards Track S. Krishnaswamy
ISSN: 2070-1721 A. Karan
Cisco Systems
V. Arya
DIRECTV Inc.
June 2016
Explicit Reverse Path Forwarding (RPF) Vector
明示的リバースパス転送（RPF）ベクトル
Abstract
概要
The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC 5496 can be included in a PIM Join Attribute such that the RPF neighbor is selected based on the unicast reachability of the RPF Vector instead of the source or Rendezvous Point associated with the multicast tree.
RFC 5496で定義されているPIMリバースパス転送（RPF）ベクトルTLVをPIM結合属性に含めることができるため、RPFネイバーは、マルチキャストツリーに関連付けられたソースまたはランデブーポイントではなく、RPFベクトルのユニキャスト到達可能性に基づいて選択されます。 。
This document defines a new RPF Vector Attribute type such that an explicit RPF neighbor list can be encoded in the PIM Join Attribute, thus bypassing the unicast route lookup.
このドキュメントでは、明示的なRPFネイバーリストをPIM結合属性にエンコードできるように、新しいRPFベクトル属性タイプを定義しているため、ユニキャストルートルックアップをバイパスします。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc7891.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7891で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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. Specification of Requirements . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Use of the PIM Explicit RPF Vector . . . . . . . . . . . . . 4
5. Explicit RPF Vector Attribute TLV Format . . . . . . . . . . 5
6. Mixed Vector Processing . . . . . . . . . . . . . . . . . . . 5
7. Conflicting RPF Vectors . . . . . . . . . . . . . . . . . . . 5
8. PIM Asserts . . . . . . . . . . . . . . . . . . . . . . . . . 6
9. Join Suppression . . . . . . . . . . . . . . . . . . . . . . 6
10. Unsupported Explicit Vector Handling . . . . . . . . . . . . 7
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
12. Security Considerations . . . . . . . . . . . . . . . . . . . 7
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
13.1. Normative References . . . . . . . . . . . . . . . . . . 8
13.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
The procedures in [RFC5496] define how an RPF Vector can be used to influence the path selection in the absence of a route to the source. The same procedures can be used to override a route to the source when it exists. It is possible to include multiple RPF Vectors in the list where each router along the path will perform a unicast route lookup on the first Vector in the attribute list. Once the router owning the address of the RPF Vector is reached, following the procedures in [RFC5496], the RPF Vector will be removed from the attribute list. This will result in a 'loosely' routed path that still depends on unicast reachability to the RPF Vector(s).
[RFC5496]の手順では、RPFベクトルを使用して、ソースへのルートがない場合にパス選択に影響を与える方法を定義しています。ソースが存在する場合、同じ手順を使用してソースへのルートをオーバーライドできます。リストに複数のRPFベクトルを含めることができます。パスに沿った各ルーターは、属性リストの最初のベクトルに対してユニキャストルートルックアップを実行します。 RPFベクトルのアドレスを所有するルーターに到達すると、[RFC5496]の手順に従って、RPFベクトルが属性リストから削除されます。これにより、RPFベクトルへのユニキャストの到達可能性に依然依存する「緩やかに」ルーティングされたパスが生成されます。
In some scenarios, the network administrators don't want to rely on the unicast reachability to the RPF Vector address and want to build a path strictly based on the RPF Vectors. In that case, the RPF Vectors represent a list of directly connected PIM neighbors along the path. For these Vectors, the router would not do a route lookup in the unicast routing table. These Vectors are referred to as 'Explicit' RPF Vector addresses. If a router receiving an Explicit RPF Vector does not have a PIM neighbor matching the Explicit RPF Vector address, it does not fall back to loosely routing the Join. Instead, it could process the packet and store the RPF Vector list so that the PIM Join can be sent out as soon as the neighbor comes up. Since the behavior of the Explicit RPF Vector differs from the 'loose' RPF Vector as defined in [RFC5496], a new attribute called the Explicit RPF Vector is defined.
一部のシナリオでは、ネットワーク管理者はRPFベクトルアドレスへのユニキャストの到達可能性に依存せず、RPFベクトルに厳密に基づいてパスを構築したいと考えています。その場合、RPFベクトルは、パスに沿って直接接続されたPIMネイバーのリストを表します。これらのベクターの場合、ルーターはユニキャストルーティングテーブルでルート検索を行いません。これらのベクターは、「明示的な」RPFベクターアドレスと呼ばれます。明示的RPFベクトルを受信するルータに、明示的RPFベクトルアドレスと一致するPIMネイバーがない場合、結合のルーズルーティングにフォールバックしません。代わりに、パケットを処理してRPFベクトルリストを保存し、ネイバーが起動するとすぐにPIM加入を送信できるようにします。 [RFC5496]で定義されているように、Explicit RPF Vectorの動作は「緩い」RPF Vectorとは異なるため、Explicit RPF Vectorと呼ばれる新しい属性が定義されています。
This document defines a new TLV in the PIM Join Attribute message [RFC5384] for specifying the explicit path.
このドキュメントでは、明示的なパスを指定するために、PIM加入属性メッセージ[RFC5384]で新しいTLVを定義しています。
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]で説明されているように解釈されます。
Some broadcast video transport networks use a multicast PIM Live-Live resiliency model for video delivery based on PIM Source-Specific Multicast (PIM-SSM) or PIM Any-Source Multicast (PIM-ASM). Live-Live implies using two active, spatially diverse multicast trees to transport video flows from root to leaf multicast routers. The leaf multicast router receives two copies from the PIM multicast core and will replicate one copy towards the receivers [RFC7431].
一部のブロードキャストビデオトランスポートネットワークは、PIM Source-Specific Multicast（PIM-SSM）またはPIM Any-Source Multicast（PIM-ASM）に基づくビデオ配信にマルチキャストPIM Live-Live復元モデルを使用します。 Live-Liveは、2つのアクティブで空間的に異なるマルチキャストツリーを使用して、ビデオフローをルートマルチキャストルーターからリーフマルチキャストルーターに転送することを意味します。リーフマルチキャストルーターは、PIMマルチキャストコアから2つのコピーを受信し、1つのコピーをレシーバー[RFC7431]に向けて複製します。
One of the requirements of the PIM Live-Live resiliency model is to ensure path diversity of the two active PIM trees in the core such that they do not intersect to avoid a single point of failure. IGP-routed RPF paths of two PIM trees could be routed over the same transit router and create a single point of failure. It is useful to have a way to specify the explicit path along which the PIM Join is propagated.
PIM Live-Live復元力モデルの要件の1つは、コア内の2つのアクティブなPIMツリーのパスの多様性を確保し、それらが交差しないようにして、単一障害点を回避することです。 2つのPIMツリーのIGPでルーティングされたRPFパスは、同じ中継ルーターを介してルーティングされ、単一障害点を作成する可能性があります。 PIM結合が伝播される明示的なパスを指定する方法があると便利です。
How the Explicit RPF Vector list is determined is outside the scope of this document. For example, it may either be manually configured by the network operator or procedures may be implemented on the egress router to dynamically calculate the Vector list based on a link-state database protocol, like OSPF or IS-IS.
明示的RPFベクトルリストの決定方法は、このドキュメントの範囲外です。たとえば、ネットワークオペレーターが手動で構成するか、出口ルーターに手順を実装して、OSPFやIS-ISなどのリンク状態データベースプロトコルに基づいてベクターリストを動的に計算できます。
Due to the fact that the leaf router receives two copies of the multicast stream via two diverse paths, there is no need for PIM to repair the broken path immediately. It is up to the egress router to either wait for the broken path to be repaired or build a new explicit path using a new RPF Vector list. Which method is applied depends very much on how the Vector list was determined initially. Double failures are not considered and are outside the scope of this document.
リーフルータが2つの異なるパスを介してマルチキャストストリームの2つのコピーを受信するため、PIMが壊れたパスをすぐに修復する必要はありません。壊れたパスが修復されるのを待つか、新しいRPFベクトルリストを使用して新しい明示的なパスを構築するかは、出力ルーター次第です。どの方法が適用されるかは、ベクターリストが最初に決定された方法に大きく依存します。二重障害は考慮されておらず、このドキュメントの範囲外です。
This document describes the procedures to carry Explicit RPF Vectors in PIM. It is up to the mechanism(s) that produce the Explicit RPF Vectors to ensure they are correct. Existing mechanisms like [MTRACE-V2] may be used to verify how the PIM tree was built.
このドキュメントでは、PIMで明示的なRPFベクトルを伝送する手順について説明します。明示的なRPFベクトルを生成するメカニズムは、それらが正しいことを確認するためのものです。 [MTRACE-V2]などの既存のメカニズムを使用して、PIMツリーがどのように構築されたかを確認できます。
Figure 1 provides an example multicast join path R4->R3->R6->R5->R2->R1, where the multicast join is explicitly routed to the source hop by hop using the Explicit RPF Vector list. When the R5-R6 link fails, the Join will NOT take an alternate path.
図1に、マルチキャスト結合パスR4-> R3-> R6-> R5-> R2-> R1の例を示します。マルチキャスト結合は、明示的RPFベクトルリストを使用して、ホップごとにソースホップに明示的にルーティングされます。 R5-R6リンクに障害が発生した場合、結合は代替パスを使用しません。
[S]---(R1)--(R2)---(R3)--(R4)---[R]
<--- | | ---
| | | |
| (R5)---(R6) |
- (S,G) Join -
| |
| |
(R7)---(R8)
Figure 1
図1
In comparison, when the procedures specified in [RFC5496] are used, if the R5-R6 link fails, then the Join may be rerouted using the R6-R8-R7 path to reach R5.
対照的に、[RFC5496]で指定された手順を使用すると、R5-R6リンクに障害が発生すると、R6-R8-R7パスを使用してJoinが再ルーティングされ、R5に到達します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.......
Figure 2
図2
F bit: 'Transitive Attribute' bit. The F bit MUST be set to 0. Otherwise, there could be loops.
Fビット：「推移属性」ビット。 Fビットは0に設定する必要があります。それ以外の場合、ループが発生する可能性があります。
E bit: 'End of Attributes' bit. If the E bit is set, then this is the last TLV specified in the list.
Eビット：「属性の終わり」ビット。 Eビットが設定されている場合、これはリストで指定された最後のTLVです。
Type: 4 (Explicit RPF Vector)
タイプ：4（明示的なRPFベクトル）
Length: The length depending on the Address Family (IPv4 or IPv6) of the Encoded-Unicast address.
長さ：エンコードされたユニキャストアドレスのアドレスファミリ（IPv4またはIPv6）に応じた長さ。
Value: Encoded-Unicast address. This SHOULD be a valid IPv4 or IPv6 address of an upstream router.
値：エンコードされたユニキャストアドレス。これは、上流ルーターの有効なIPv4またはIPv6アドレスである必要があります（SHOULD）。
The Explicit RPF Vector Attribute does not impact or restrict the functionality of other RPF Vector Attributes in a PIM Join. It is possible to mix Vectors of different types such that some part of the tree is explicit and other parts are loosely routed. RPF Vectors are processed in the order in which they are specified.
明示的なRPFベクトル属性は、PIM結合の他のRPFベクトル属性の機能に影響を与えたり制限したりしません。ツリーの一部が明示的で、他の部分が緩くルーティングされるように、異なるタイプのベクターを混在させることが可能です。 RPFベクトルは、指定された順序で処理されます。
It is possible that a PIM router has multiple downstream neighbors. If for the same multicast route there is an inconsistency between the Explicit RPF Vector lists provided by the downstream PIM neighbor, the procedures as documented in Section 3.3.3 of [RFC5384] apply.
PIMルータに複数のダウンストリームネイバーがある可能性があります。同じマルチキャストルートの場合、ダウンストリームPIMネイバーによって提供される明示的RPFベクトルリスト間に不整合がある場合、[RFC5384]のセクション3.3.3に記載されている手順が適用されます。
The conflict resolution procedures in Section 3.3.3 of [RFC5384] only apply to attributes of the same Join Attribute type. Join Attributes that have a different type can't be compared because the content of the Join Attribute may have a totally different meaning and/or encoding. This may cause a problem if a mix of Explicit RPF Vectors (this document) and 'loose' RPF Vectors [RFC5496] is received from two or more downstream routers. The order in which the RPF Vectors are encoded may be different, and/or the combination of RPF Vectors may be inconsistent. The procedures in Section 3.3.3 of [RFC5384] would not resolve the conflict. The following procedures MUST be applied to deal with this scenario.
[RFC5384]のセクション3.3.3の競合解決手順は、同じ結合属性タイプの属性にのみ適用されます。タイプが異なる結合属性は、結合属性の内容が完全に異なる意味やエンコーディングを持つ可能性があるため、比較できません。これは、明示的なRPFベクトル（このドキュメント）と「緩い」RPFベクトルの混合[RFC5496]が2つ以上のダウンストリームルーターから受信された場合に問題を引き起こす可能性があります。 RPFベクトルがエンコードされる順序が異なる場合や、RPFベクトルの組み合わせに一貫性がない場合があります。 [RFC5384]のセクション3.3.3の手順では、競合は解決されません。このシナリオに対処するには、次の手順を適用する必要があります。
When a PIM Join with a Join Attribute list is received from a downstream neighbor, the router MUST verify that the order in which the RPF Vector types appear in the PIM Join Attribute list matches what is stored as the Join Attribute list for reaching the source or Rendezvous Point listed in the PIM Join. Once it is determined that the RPF Vector types on the stack are equal, the content of the RPF Vectors MUST be compared ([RFC5384]). If it is determined that there is either a conflict with RPF Vector types or the RPF Vector content, the router uses the RPF Vector stack from the PIM adjacency with the numerically smallest IP address. In the case of IPv6, the link-local address will be used. When two neighbors have the same IP address, either for IPv4 or IPv6, the interface index MUST be used as a tie breaker. It's RECOMMENDED that the router doing the conflict resolution log a message.
ジョイン属性リストを含むPIMジョインがダウンストリームネイバーから受信されると、ルータは、RPMベクトルタイプがPIMジョイン属性リストに表示される順序が、ソースに到達するためのジョイン属性リストとして保存されているものと一致することを確認する必要があります。 PIM参加にリストされているランデブーポイント。スタック上のRPFベクトルタイプが等しいと判断されたら、RPFベクトルの内容を比較する必要があります（[RFC5384]）。 RPFベクトルタイプまたはRPFベクトルコンテンツとの競合があると判断された場合、ルータは、数値的に最小のIPアドレスを持つPIM隣接からのRPFベクトルスタックを使用します。 IPv6の場合、リンクローカルアドレスが使用されます。 IPv4またはIPv6のいずれかで、2つのネイバーが同じIPアドレスを持っている場合、インターフェースインデックスをタイブレーカーとして使用する必要があります。競合解決を行うルーターがメッセージをログに記録することをお勧めします。
Section 3.3.3 of [RFC5496] specifies the procedures for how to deal with PIM Asserts when RPF Vectors are used. The same procedures apply to the Explicit RPF Vector. There is a minor behavioral difference: the route 'metric' that is included in the PIM Assert should be the route metric of the first Explicit RPF Vector address in the list. However, the first Explicit Vector should always be directly connected, so the metric may likely be zero. The metric will therefore not be a tie breaker in the PIM Assert selection procedure.
[RFC5496]のセクション3.3.3は、RPFベクトルが使用されるときにPIMアサートを処理する方法の手順を指定しています。同じ手順が明示的RPFベクトルに適用されます。小さな動作上の違いがあります。PIMアサートに含まれるルート「メトリック」は、リスト内の最初の明示的RPFベクトルアドレスのルートメトリックでなければなりません。ただし、最初の明示的なベクターは常に直接接続されている必要があるため、メトリックがゼロになる可能性があります。したがって、メトリックはPIMアサート選択手順のタイブレーカーにはなりません。
Section 3.3.4 of [RFC5496] specifies the procedures for how to apply Join Suppression when an RPF Vector Attribute is included in the PIM Join. The same procedure applies to the Explicit RPF Vector Attribute. The procedure MUST match against all the Explicit RPF Vectors in the PIM Join before a PIM Join can be suppressed.
[RFC5496]のセクション3.3.4は、RPFベクトル属性がPIM結合に含まれている場合に結合抑制を適用する方法の手順を示しています。同じ手順が、明示的なRPFベクトル属性に適用されます。プロシージャは、PIM結合を抑制する前に、PIM結合のすべての明示的RPFベクトルと一致する必要があります。
The F bit MUST be set to 0 in all Explicit RPF Vectors in case the upstream router receiving the Join does not support the TLV. As described in Section 3.3.2 of [RFC5384], routers that do not understand the type of a particular attribute that has the F bit clear will discard it and continue to process the Join.
Joinを受信する上流のルーターがTLVをサポートしていない場合に備えて、すべてのExplicit RPFベクトルでFビットを0に設定する必要があります。 [RFC5384]のセクション3.3.2で説明されているように、Fビットがクリアされている特定の属性のタイプを理解していないルーターは、それを破棄して、結合の処理を続行します。
This processing is particularly important when the routers that do not support the Explicit RPF TLV are identified as hops in the Explicit RPF list because failing to remove the RPF Vectors could cause upstream routers to send the Join back toward these routers causing loops.
明示的なRPF TLVをサポートしていないルーターが明示的なRPFリストでホップとして識別されている場合、この処理は特に重要です。RPFベクトルの削除に失敗すると、上流のルーターがこれらのルーターに結合を送り返し、ループが発生する可能性があるためです。
As the administrator is manually specifying the path that the Joins need to be sent on, it is recommended that the administrator computes the path to include routers that support the Explicit Vector and check that the state is created correctly on each router along the path. Tools like mtrace can be used for debugging and to ensure that the Join state is setup correctly.
管理者は、Joinを送信する必要があるパスを手動で指定しているため、明示的なベクターをサポートするルーターを含めるようにパスを計算し、パスに沿った各ルーターで状態が正しく作成されていることを確認することをお勧めします。 mtraceなどのツールをデバッグに使用して、結合状態が正しく設定されていることを確認できます。
In the "PIM Join Attribute Types" registry, IANA has assigned the value 4 to the Explicit RPF Vector Attribute.
「PIM結合属性タイプ」レジストリーで、IANAは値4を明示的RPFベクトル属性に割り当てました。
Security of the Explicit RPF Vector Attribute is only guaranteed by the security of the PIM packet, so the security considerations for PIM Join packets as described in PIM-SM [RFC7761] apply here. A malicious downstream node can attempt a denial-of-service attack by sending PIM Join packets with invalid addresses listed in the RPF Vector stack with an intent to stop the propagation of the Joins to the correct upstream node. Another denial-of-service attack would be a malicious downstream node targeting all Joins to a specific node with an intent to overload the bandwidth on that node by making it responsible for forwarding multicast traffic for more streams that it can handle. In order to minimize the risk of a denial-of-service attack from forged PIM Join packets with Explicit RPF Vector stack, it should be used within a single trusted management domain.
明示的RPFベクトル属性のセキュリティは、PIMパケットのセキュリティによってのみ保証されるため、PIM-SM [RFC7761]で説明されているPIM結合パケットのセキュリティに関する考慮事項がここに適用されます。悪意のあるダウンストリームノードは、RPFベクトルスタックにリストされた無効なアドレスを持つPIMジョインパケットを送信して、正しいアップストリームノードへのジョインの伝播を停止することを目的として、サービス拒否攻撃を試みる可能性があります。別のサービス拒否攻撃は、特定のノードへのすべての結合を標的とする悪意のあるダウンストリームノードであり、そのノードが処理できるより多くのストリームのマルチキャストトラフィックの転送を担当することにより、そのノードの帯域幅に過負荷をかける意図があります。明示的なRPFベクトルスタックを使用した偽造PIM結合パケットによるサービス拒否攻撃のリスクを最小限に抑えるには、単一の信頼できる管理ドメイン内で使用する必要があります。
If a router finds that it cannot use the Vector list due to the next hop router not being a PIM neighbor, it may log an error. Also, if a router is receiving two conflicting Vectors, it may log an error. It is up to the mechanisms that produced the Explicit RPF Vector to ensure that the PIM tree is built correctly and to monitor any error logs.
ネクストホップルーターがPIMネイバーではないためにルーターがベクターリストを使用できないことが判明した場合、エラーをログに記録することがあります。また、ルーターが2つの競合するベクターを受信している場合、エラーが記録されることがあります。 PIMツリーが正しく構築されていることを確認し、エラーログを監視するのは、明示的RPFベクトルを生成したメカニズム次第です。
[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>。
[RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol Independent Multicast (PIM) Join Attribute Format", RFC 5384, DOI 10.17487/RFC5384, November 2008, <http://www.rfc-editor.org/info/rfc5384>.
[RFC5384] Boers、A.、Wijnands、I。、およびE. Rosen、「Protocol Independent Multicast（PIM）Join Attribute Format」、RFC 5384、DOI 10.17487 / RFC5384、2008年11月、<http：//www.rfc -editor.org/info/rfc5384>。
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, DOI 10.17487/RFC5496, March 2009, <http://www.rfc-editor.org/info/rfc5496>.
[RFC5496] Wijnands、IJ。、Boers、A。、およびE. Rosen、「The Reverse Path Forwarding（RPF）Vector TLV」、RFC 5496、DOI 10.17487 / RFC5496、2009年3月、<http：//www.rfc- editor.org/info/rfc5496>。
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, <http://www.rfc-editor.org/info/rfc7761>.
[RFC7761] Fenner、B.、Handley、M.、Holbrook、H.、Kouvelas、I.、Parekh、R.、Zhang、Z。、およびL. Zheng、「Protocol Independent Multicast-Sparse Mode（PIM-SM） ：プロトコル仕様（改訂）」、STD 83、RFC 7761、DOI 10.17487 / RFC7761、2016年3月、<http://www.rfc-editor.org/info/rfc7761>。
[MTRACE-V2] Asaeda, H., Meyer, K., and W. Lee, "Mtrace Version 2: Traceroute Facility for IP Multicast", Work in Progress, draft-ietf-mboned-mtrace-v2-13, June 2016.
[MTRACE-V2]浅枝浩、マイヤー、K、W。リー、「Mtraceバージョン2：IPマルチキャスト用Tracerouteファシリティ」、作業中、draft-ietf-mboned-mtrace-v2-13、2016年6月。
[RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B. Decraene, "Multicast-Only Fast Reroute", RFC 7431, DOI 10.17487/RFC7431, August 2015, <http://www.rfc-editor.org/info/rfc7431>.
[RFC7431] Karan、A.、Filsfils、C.、Wijnands、IJ。、Ed。、およびB. Decraene、「マルチキャストのみの高速リルート」、RFC 7431、DOI 10.17487 / RFC7431、2015年8月、<http：// www.rfc-editor.org/info/rfc7431>。
Acknowledgements
謝辞
The authors would like to thank Vatsa Kumar, Nagendra Kumar, and Bharat Joshi for their comments on the document.
この文書に対するコメントを提供してくれたVatsa Kumar、Nagendra Kumar、およびBharat Joshiに感謝します。
Authors' Addresses
著者のアドレス
Javed Asghar Cisco Systems 725, Alder Drive Milpitas, CA 95035 United States
Javed Asghar Cisco Systems 725、Alder Drive Milpitas、CA 95035アメリカ合衆国
Email: jasghar@cisco.com
IJsbrand Wijnands (editor) Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium
IJsbrand Wijnands（編集者）Cisco Systems De Kleetlaan 6a Diegem 1831ベルギー
Email: ice@cisco.com
Sowmya Krishnaswamy Cisco Systems 3750 Cisco Way San Jose, CA 95134 United States
Sowmya Krishnaswamy Cisco Systems 3750 Cisco Way San Jose、CA 95134アメリカ合衆国
Email: sowkrish@cisco.com
Apoorva Karan Cisco Systems 3750 Cisco Way San Jose, CA 95134 United States
Apoorva Karan Cisco Systems 3750 Cisco Way San Jose、CA 95134アメリカ合衆国
Email: apoorva@cisco.com
Vishal Arya DIRECTV Inc. 2230 E Imperial Hwy El Segundo, CA 90245 United States
ゔぃしゃｌ ありゃ ぢれＣＴＶ いんｃ。 ２２３０ え いｍぺりあｌ Ｈｗｙ えｌ せぐんど、 か ９０２４５ うにてｄ Ｓたてｓ
Email: varya@directv.com