[要約] RFC 5496は、逆パス転送（RPF）ベクトルTLVに関する仕様であり、BGPプロトコルで使用される。その目的は、ネットワークの経路選択において、正しい逆パスを特定するための情報を提供することである。
Network Working Group IJ. Wijnands
Request for Comments: 5496 A. Boers
Category: Standards Track E. Rosen
Cisco Systems, Inc.
March 2009
The Reverse Path Forwarding (RPF) Vector TLV
逆パス転送（RPF）ベクトルTLV
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
This document describes a use of the Protocol Independent Multicast (PIM) Join Attribute as defined in RFC 5384, which enables PIM to build multicast trees through an MPLS-enabled network, even if that network's IGP does not have a route to the source of the tree.
このドキュメントでは、RFC 5384で定義されているプロトコル独立マルチキャスト（PIM）結合属性の使用について説明します。これにより、PIMはMPLS対応ネットワークを介してマルチキャストツリーを構築できます。木。
Table of Contents
目次
1. Introduction ....................................................2
2. Specification of Requirements ...................................3
3. Use of the RPF Vector TLV .......................................3
3.1. Attribute and Shared Tree Joins ............................4
3.2. Attribute and Bootstrap Messages ...........................4
3.3. The Vector Attribute .......................................4
3.3.1. Inserting a Vector Attribute in a Join ..............4
3.3.2. Processing a Received Vector Attribute ..............5
3.3.3. Vector Attribute and Asserts ........................5
3.3.4. Vector Attribute and Join Suppression ...............6
4. Vector Attribute TLV Format .....................................6
5. IANA Considerations .............................................7
6. Security Considerations .........................................7
7. Acknowledgments .................................................7
8. Normative References ............................................7
It is sometimes convenient to distinguish the routers of a particular network into two categories: "edge routers" and "core routers". The edge routers attach directly to users or to other networks, but the core routers attach only to other routers of the same network. If the network is MPLS-enabled, then any unicast packet that needs to travel outside the network can be "tunneled" via MPLS from one edge router to another. To handle a unicast packet that must travel outside the network, an edge router needs to know which of the other edge routers is the best exit point from the network for that packet's destination IP address. The core routers, however, do not need to have any knowledge of routes that lead outside the network; as they handle only tunneled packets, they only need to know how to reach the edge routers and the other core routers.
特定のネットワークのルーターを「エッジルーター」と「コアルーター」の2つのカテゴリに区別するのが便利な場合があります。エッジルーターはユーザーまたは他のネットワークに直接接続しますが、コアルーターは同じネットワークの他のルーターにのみ取り付けられます。ネットワークがMPLS対応の場合、ネットワークの外を移動する必要があるユニキャストパケットは、あるエッジルーターから別のエッジルーターにMPLSを介して「トンネル」することができます。ネットワークの外を移動しなければならないユニキャストパケットを処理するには、エッジルーターがそのパケットの宛先IPアドレスのネットワークからの最適な出口ポイントである他のエッジルーターのどれを知る必要があります。ただし、コアルーターは、ネットワークの外側をリードするルートの知識を持つ必要はありません。トンネルパケットのみを処理するため、エッジルーターと他のコアルーターに到達する方法を知る必要があります。
Consider, for example, the case where the network is an Autonomous System (AS), the edge routers are External Border Gateway Protocol (EBGP) speakers, the core routers may be said to constitute a "BGP-free core". The edge routers distribute BGP routes to each other, but not to the core routers.
たとえば、ネットワークが自律システム（AS）である場合、エッジルーターが外部ボーダーゲートウェイプロトコル（EBGP）スピーカーである場合、コアルーターは「BGPフリーコア」を構成すると言えます。エッジルーターはBGPルートを互いに分配しますが、コアルーターには分配されません。
However, when multicast packets are considered, the strategy of keeping the core routers free of "external" routes is more problematic. When using PIM Sparse-Mode (PIM-SM) [RFC4601], PIM Source-Specific Mode (PIM-SSM) [RFC4607], or Bidirectional PIM (BIDIR-PIM) [RFC5015] to create a multicast distribution tree for a particular multicast group, one wants the core routers to be full participants in the PIM protocol, so that multicasting can be done efficiently in the core. This means that the core routers must be able to correctly process PIM Join messages for the group, which in turn means that the core routers must be able to send the Join messages towards the root of the distribution tree. If the root of the tree lies outside the network's borders (e.g., is in a different AS), and the core routers do not maintain routes to external destinations, then the PIM Join messages cannot be processed, and the multicast distribution tree cannot be created.
ただし、マルチキャストパケットを考慮すると、コアルーターを「外部」ルートのない状態に保つ戦略には、より問題があります。PIMスパースモード（PIM-SM）[RFC4601]、PIMソース固有のモード（PIM-SSM）[RFC4607]、または双方向PIM（Bidir-PIM）[RFC5015]を使用して、特定のマルチカスト用のマルチキャスト分布ツリーを作成する場合グループは、コアルーターがPIMプロトコルの完全な参加者になることを望んでいるため、マルチキャストをコアで効率的に実行できるようにします。これは、コアルーターがグループのPIM結合メッセージを正しく処理できる必要があることを意味します。これにより、コアルーターは結合メッセージを配布ツリーのルートに向けて送信できる必要があります。ツリーの根がネットワークの境界の外側にある場合（たとえば、別のASにあります）、コアルーターが外部宛先へのルートを維持しない場合、PIM結合メッセージは処理できず、マルチキャスト配布ツリーを作成できません。
In order to allow PIM to work properly in an environment where the core routers do not maintain external routes, a PIM extension is needed. When an edge router sends a PIM Join message into the core, it MUST include in that message a "Vector" that specifies the IP address of the next edge router along the path to the root of the multicast distribution tree. The core routers can then process the Join message by sending it towards the specified edge router (i.e., toward the Vector). In effect, the Vector serves as an attribute, within a particular network, for the root of the tree.
コアルーターが外部ルートを維持しない環境でPIMが適切に機能するようにするには、PIM拡張が必要です。エッジルーターがPIM結合メッセージをコアに送信する場合、そのメッセージに、マルチキャスト配布ツリーのルートへのパスに沿って次のエッジルーターのIPアドレスを指定する「ベクトル」を含める必要があります。コアルーターは、指定されたエッジルーター（つまり、ベクトルに向かって）に送信することにより、結合メッセージを処理できます。実際、ベクトルは、ツリーのルートに対して、特定のネットワーク内の属性として機能します。
This document defines a new TLV in the PIM Join Attribute message [RFC5384]. It consists of a single Vector that identifies the exit point of the network.
このドキュメントでは、PIM Join属性メッセージ[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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
Before a router can start forwarding multicast packets, it is necessary to build a forwarding tree by sending PIM Joins hop-by-hop. Each router in the path creates a forwarding state and propagates the Join towards the root of the forwarding tree. The building of this tree is receiver driven. See Figure 1.
ルーターがマルチキャストパケットの転送を開始する前に、PIMがホップバイホップで結合することにより、転送ツリーを構築する必要があります。パス内の各ルーターは、転送状態を作成し、転送ツリーのルートに向かって結合を伝播します。このツリーの建物はレシーバー駆動型です。図1を参照してください。
------------------ BGP -----------------
| |
[S]---( Edge 1)--(Core 1)---( Core )--(Core 2)---( Edge 2 )---[R]
<--- (S,G) Join
Figure 1
図1
In this example, the two edge routers are BGP speakers. The core routers are not BGP speakers and do not have any BGP distributed routes. The route to S is a BGP distributed route; hence, it is known to the edge but not to the core. The Edge 2 router determines the interface leading to S, and sends a PIM Join to the upstream router. In this example, though, the upstream router is a core router, with no route to S. Without the PIM extensions specified in this document, the core router cannot determine where the send the Join, so the tree cannot be constructed.
この例では、2つのエッジルーターはBGPスピーカーです。コアルーターはBGPスピーカーではなく、BGP分散ルートはありません。SへのルートはBGP分散ルートです。したがって、それはエッジに知られていますが、コアではありません。Edge 2ルーターは、Sにつながるインターフェイスを決定し、上流のルーターにPIM結合を送信します。ただし、この例では、上流のルーターはコアルーターであり、このドキュメントで指定されているPIM拡張機能がない場合、Sへのルートはありません。コアルーターは、結合の送信先を決定できないため、ツリーを構築できません。
To allow the core router to participate in the construction of the tree, the Edge 2 router includes an "RPF (Reverse Path Forwarding) Vector" TLV in the PIM Join Attribute [RFC5384] of the PIM Join. In this example, the RPF Vector TLV will contain the IP address of Edge 1. Edge 2 forwards the PIM Join towards Edge 1. Each intermediate core router does its RPF check [RFC4601] on the address contained in the RPF Vector TLV (i.e., on the IP address of Edge 1), instead of doing the RPF check on the address S. This allows the tree to be constructed.
コアルーターがツリーの構築に参加できるようにするために、Edge 2ルーターには、PIM結合のPIM Join属性[RFC5384]の「RPF（逆パス転送）ベクトル」TLVが含まれます。この例では、RPFベクトルTLVにはEdge 1のIPアドレスが含まれます。Edge2PIM結合をEdge 1に向けてPIMを前に進めます。各中間コアルーターは、RPFベクターTLV（つまり、Edge 1）のIPアドレスで、アドレスSでRPFチェックを実行する代わりに、ツリーを構築できます。
In the example above, we build a source tree to illustrate the attribute behavior. Use of the attribute is, however, not restricted to the construction of source trees. It may also be used to construct a shared tree. In this case, the RPF Vector TLV contains the IP address of a Rendezvous Point (RP). Procedures defined in this document for (S,G) Joins are equally applicable to (*,G) and (*,*,RP) Joins unless otherwise noted.
上記の例では、属性の動作を説明するソースツリーを構築します。ただし、属性の使用は、ソースツリーの構築に限定されません。また、共有ツリーの構築に使用することもできます。この場合、RPFベクトルTLVには、ランデブーポイント（RP）のIPアドレスが含まれています。（s、g）結合のこのドキュメントで定義されている手順は、特に明記しない限り（*、g）および（*、*、rp）に等しく適用できます。
There is no way to carry an RPF Vector TLV in a Bootstrap Router (BSR) bootstrap message. The procedures in this document do not define a way for BSR messages to be forwarded across a core in which the BSP IP address is not routable.
ブートストラップルーター（BSR）ブートストラップメッセージにRPFベクターTLVを運ぶ方法はありません。このドキュメントの手順では、BSRメッセージがBSP IPアドレスがルーティングできないコアに転送される方法を定義するものではありません。
In the example of Figure 1, when the Edge 2 router looks up the route to the source of the multicast distribution tree, it will find a BGP-distributed route whose "BGP next-hop" is Edge 1. Edge 2 then looks up the route to Edge 1 to find the next hop to the source, namely Core 2.
図1の例では、エッジ2ルーターがマルチキャスト分布ツリーのソースへのルートを検索すると、「BGP Next-Hop」がEdge 2であるBGP分配ルートを見つけます。エッジ1へのルート1つのソースへの次のホップ、つまりCore 2を見つけます。
When Edge 2 sends a PIM Join to Core 2, it includes a Vector Attribute specifying the address of Edge 1. Core 2, and subsequent core routers, will forwarding the Join along the Vector (i.e., towards Edge 1) instead of trying to forward it towards S.
Edge 2がCore 2にPIM結合を送信すると、Edge 1のアドレスを指定するVector属性が含まれます。Core2およびその後のCore Routersのアドレスを指定し、ベクトルに沿って結合を転送します（つまり、Edge 1に向かって）転送しようとする代わりにそれはSに向かって
Whether an attribute is actually needed depends on whether the Core routers have a route to the source of the multicast tree. How the Edge router knows whether or not this is the case (and thus how the Edge router determines whether or not to insert an attribute field) is outside the scope of this document.
属性が実際に必要であるかどうかは、コアルーターにマルチキャストツリーのソースへのルートがあるかどうかによって異なります。エッジルーターがこれが事実であるかどうか（したがって、エッジルーターが属性フィールドを挿入するかどうかを決定する方法）をどのように知っているかが、このドキュメントの範囲外です。
When processing a received PIM Join that contains a Vector Attribute, a router MUST first check to see if the Vector IP address is one of its own IP addresses. If so, the Vector Attribute is discarded, and not passed further upstream. Otherwise, the Vector Attribute is used to find the route to the source, and is passed along when a PIM Join is sent upstream. Note that a router that receives a Vector Attribute MUST use it, even if that router happens to have a route to the source. A router that discards a Vector Attribute MAY of course insert a new Vector Attribute. This would typically happen if a PIM Join needed to pass through a sequence of Edge routers, each pair of which is separated by a core that does not have external routes. In the absence of periodic refreshment, Vectors expire along with the corresponding (S,G) state.
ベクトル属性を含む受信PIM結合を処理する場合、ルーターは最初にベクトルIPアドレスが独自のIPアドレスの1つであるかどうかを確認する必要があります。その場合、ベクトル属性は破棄され、さらに上流に通過しません。それ以外の場合、ベクトル属性はソースへのルートを見つけるために使用され、PIM結合が上流に送信されると渡されます。ベクトル属性を受信するルーターは、そのルーターがたまたまソースへのルートを持っている場合でも、それを使用する必要があることに注意してください。ベクトル属性を破棄するルーターは、もちろん新しいベクトル属性を挿入できます。これは通常、PIM結合がエッジルーターのシーケンスを通過する必要がある場合に発生します。各ペアは、外部ルートのないコアによって分離されます。定期的な軽食がない場合、ベクターは対応する（s、g）状態とともに期限切れになります。
A PIM Assert message includes the routing protocol's "metric" to the source of the tree. This information is used in the selection of the Assert winner. If a PIM Join is being sent towards a Vector, rather than towards the source, the Assert message MUST have the metric to the Vector instead of the metric to the source. The Assert message however does not have an attribute field and does not mention the Vector.
PIMアサートメッセージには、ツリーのソースへのルーティングプロトコルの「メトリック」が含まれています。この情報は、アサート勝者の選択に使用されます。PIM結合がソースに向かってではなくベクトルに向かって送信されている場合、アサートメッセージは、ソースのメトリックではなくベクトルにメトリックを持たなければなりません。ただし、アサートメッセージには属性フィールドがなく、ベクトルについて言及していません。
A router may change its upstream neighbor on a particular multicast tree as the result of receiving Assert messages. However, a Vector Attribute MUST NOT be sent in a PIM Join to an upstream neighbor that is chosen as the result of Assert processing, if that neighbor is different than the original upstream neighbor. Reachability of the Vector is only guaranteed by the router that advertises reachability to the Vector in its IGP. If the Assert winner upstream is not the real preferred next-hop, it is possible that the Assert winner does not know the path to the Vector. In the worst case the Assert winner has a route to the Vector that is on the same interface where the Assert was won. That will point the RPF interface to that interface and will result in the O-list being NULL. The Vector Attribute therefore MUST NOT be inserted if the RPF neighbor was chosen via an Assert process and the RPF neighbor is different from the RPF neighbor that would have been selected via the local routing table. In all other cases, the Vector MUST be included in the Join message.
ルーターは、アサートメッセージを受信した結果として、特定のマルチキャストツリーで上流の隣人を変更する場合があります。ただし、その隣人が元の上流の隣人とは異なる場合、アサート処理の結果として選択される上流の隣人にピム結合にベクトル属性を送信してはなりません。ベクトルの到達可能性は、IGPのベクトルへの到達可能性を宣伝するルーターによってのみ保証されます。Assert Winner Upstreamが本当の好みの次のホップではない場合、ASSTの勝者がベクトルへのパスを知らない可能性があります。最悪の場合、アサートの勝者には、アサートが獲得されたのと同じインターフェイス上にあるベクトルへのルートがあります。これにより、RPFインターフェイスがそのインターフェイスを指し、Oリストがnullになります。したがって、RPF隣接がアサートプロセスを介して選択され、RPF隣接がローカルルーティングテーブルを介して選択されていたRPF隣接とは異なる場合、ベクトル属性を挿入してはなりません。他のすべての場合、ベクトルを結合メッセージに含める必要があります。
If a router receives a PIM Join on the upstream LAN interface for a particular multicast state, Join suppression may be applied if that PIM Join is targeted to the same upstream neighbor. Which router(s) will suppress their PIM Join is dependent on timing and is unpredictable. Downstream routers on a LAN MAY include different RPF Vectors in the PIM Joins. Therefore, an upstream router on that LAN may receive and use different RPF Vectors over time to reach the destination (depending on which downstream router(s) suppressed their Join). To make the upstream router behavior more predictable, the RPF Vector address MUST be used as additional condition to the Join suppression logic. Only if the RPF Vector in the PIM Join matches the RPF Vector in the multicast state, the suppression logic is applied. It is also possible to disable Join suppression on that LAN.
ルーターが特定のマルチキャスト状態の上流LANインターフェイスでPIM結合を受信した場合、そのPIM結合が同じ上流の隣人を対象とする場合、結合抑制が適用される場合があります。どのルーターがPIM結合を抑制するかはタイミングに依存し、予測不可能です。LAN上の下流ルーターには、PIM結合に異なるRPFベクターが含まれる場合があります。したがって、そのLAN上の上流のルーターは、目的地に到達するために時間の経過とともに異なるRPFベクターを受信および使用する場合があります（どの下流ルーターが結合を抑制したかに応じて）。上流のルーターの動作をより予測可能にするには、RPFベクトルアドレスを結合抑制ロジックに追加の条件として使用する必要があります。PIM結合のRPFベクトルがマルチキャスト状態のRPFベクトルと一致する場合にのみ、抑制ロジックが適用されます。また、そのLANの抑制の結合を無効にすることも可能です。
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|S| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.......
F bit Forward Unknown TLV. If this bit is set, the TLV is forwarded regardless of whether the router understands the Type. If the TLV is known, the F bit is ignored.
fビットフォワード不明のtlv。このビットが設定されている場合、ルーターがタイプを理解しているかどうかに関係なく、TLVは転送されます。TLVがわかっている場合、Fビットは無視されます。
S bit Bottom of Stack. If this bit is set, then this is the last TLV in the stack.
スタックのビットボトム。このビットが設定されている場合、これはスタック内の最後のTLVです。
Type The Vector Attribute type is 0.
タイプベクトル属性タイプは0です。
Length Length depending on Address Family of Encoded-Unicast address.
エンコードされたUnicastアドレスの住所ファミリに応じて長さの長さ。
Value Encoded-Unicast address.
値エンコード-Unicastアドレス。
IANA has assigned the value 0 to the RPF Vector in the "PIM Join Attribute Types" registry.
IANAは、「PIM Join属性タイプ」レジストリのRPFベクトルに値0を割り当てました。
Security of the 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 [RFC4601] apply here.
RPFベクトル属性のセキュリティは、PIMパケットのセキュリティによってのみ保証されるため、PIM-SM [RFC4601]に記載されているようにPIM結合パケットのセキュリティに関する考慮事項がここに適用されます。
The authors would like to thank Yakov Rekhter and Dino Farinacci for their initial ideas on this topic and Su Haiyang for the comments on the document.
著者は、Yakov RekhterとDino Farinacciがこのトピックに関する最初のアイデアと、文書に関するコメントについてはSu Haiyangに感謝したいと思います。
[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（改訂）、RFC 4601、2006年8月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607] Holbrook、H。およびB. Cain、「IP用のソース固有のマルチキャスト」、RFC 4607、2006年8月。
[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、「双方向プロトコル独立マルチキャスト（Bidir-PIM）」、RFC 5015、2007年10月。
[RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol Independent Multicast (PIM) Join Attribute Format", RFC 5384, November 2008.
[RFC5384] Boers、A.、Wijnands、I。、およびE. Rosen、「プロトコル独立マルチキャスト（PIM）結合属性形式」、RFC 5384、2008年11月。
Authors' Addresses
著者のアドレス
IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium
IJSBRAND Wijnands Cisco Systems、Inc。de Kleetlaan 6a Diegem 1831ベルギー
EMail: ice@cisco.com
Arjen Boers Cisco Systems, Inc. Avda. Diagonal, 682 Barcelona 08034 Spain
Arjen Boers Cisco Systems、Inc。AVDA。斜め、682バルセロナ08034スペイン
EMail: aboers@cisco.com
Eric Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, Ma 01719
エリック・ローゼン・シスコ・システムズ、1414マサチューセッツ・アベニュー・ボックスボロー、マサチューセッツ州01719
EMail: erosen@cisco.com