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
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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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）の使用は、MPLS対応のネットワークを介して、マルチキャストツリーを構築するPIMを可能にする、属性への参加について説明し、そのネットワークのIGPは、のソースへのルートを持っていない場合でも、木。
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が順番にコアルータは、ディストリビューションツリーのルートの方に参加メッセージを送ることができなければならないことを意味グループ、のためにJoinメッセージを処理できなければならないことを意味します。ツリーのルートは、ネットワークの境界の外にある場合（例えば、異なる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の新しいTLVがメッセージ[RFC5384]を属性に参加定義します。これは、ネットワークの出口点を識別する単一のベクターから成ります。
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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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分散経路です。したがって、それはなく、コアの端部にはよく知られています。エッジルータ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.
コアルータは、ツリーの建設に参加できるようにするには、エッジ2ルータがPIMの「RPFベクトル（フォワーディングリバースパス）」PIMにTLVは、属性に参加[RFC5384]が参加しています。この例では、RPFベクトルTLVは、2つの転送PIMは、エッジ1.各中間コアルータに向けて参加エッジ1エッジのIPアドレスが含まれていますし、すなわちRPFベクトルTLVに含まれているアドレスにそのRPFチェック[RFC4601]（、エッジ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-分散ルートを見つけるの例では、「BGPネクストホップ」が、エッジ1エッジ2であり、ルックアップソース、すなわち、コア2への次のホップを見つけるために1 Edgeに経路。
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.
エッジ2は、PIMは、コア2に参加し送信すると、それはエッジ1コア2のアドレスを指定するベクトル属性を含み、そしてそれに続くコアルータは、代わりに転送しようとする（すなわち、エッジ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は上流送信された参加時に渡されます。ベクトル属性を受け取るルータはそのルータが送信元へのルートを持ってしまった場合でも、それを使用しなければならないことに注意してください。当然のベクトル属性MAYを破棄ルータが新しいベクター属性を挿入します。 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ではなく、ソースに向けたよりも、ベクトルに向けて送信されている参加した場合は、アサートメッセージは、Vectorへのメトリックの代わりに、ソースにメトリックを持っていなければなりません。アサートメッセージは、しかし、属性フィールドを持っていないとベクトルを言及していません。
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.
ルータがアサート・メッセージを受信した結果として、特定のマルチキャストツリーにその上流隣接を変更することができます。しかし、ベクター属性は、そのネイバーが元の上流隣接と異なる場合、アサート処理の結果として選択される上流の隣人に参加PIMに送ってはいけません。ベクターの到達可能性のみがそのIGPのベクトルに到達可能性をアドバタイズルータによって保証されています。アサート勝者は上流の本当の好適ネクストホップではない場合、アサート勝者がベクトルへのパスを知らない可能性があります。最悪の場合にアサート勝者はアサートが勝ったのと同じインターフェイス上にあるベクトルへのルートを持っています。つまり、そのインターフェイスに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.
ルータは、PIMは、特定のマルチキャスト状態のため上流のLANインタフェースに参加受信した場合、その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.
Sは、スタックの最下部ビット。このビットがセットされている場合、これは、スタック内の最後のTLVです。
Type The Vector Attribute type is 0.
ベクトルの属性タイプが0で入力してください。
Length Length depending on Address Family of Encoded-Unicast address.
エンコード・ユニキャストアドレスのアドレスファミリに応じて、長さの長さ。
Value Encoded-Unicast address.
バリューエンコード・ユニキャストアドレス。
IANA has assigned the value 0 to the RPF Vector in the "PIM Join Attribute Types" registry.
IANAは、「PIM参加属性タイプ」レジストリに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.
PIM-SM [RFC4601]で説明したようにRPFベクトル属性のセキュリティーのみPIMパケットのセキュリティが保証するので、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.
作者は、ドキュメントに関するコメントについては、このトピックと蘇海陽上の彼らの初期のアイデアをヤコフ・レックターとディーノファリナッチに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]フェナー、B.、ハンドリー、M.、ホルブルック、H.、およびI. Kouvelas、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様（改訂）"、RFC 4601、2006年8月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]ホルブルック、H.、およびB.カイン、 "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]ハンドレー、M.、Kouvelas、I.、スピークマン、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]ボーア人は、A.、Wijnands、I.、およびE.ローゼンは、RFC 5384、2008年11月 "プロトコル独立マルチキャスト（PIM）は、属性のフォーマットに参加します"。
Authors' Addresses
著者のアドレス
IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium
IJsbrand Wijnandsシスコシステムズ株式会社Kleetlaan 6aはディーゲム1831ベルギー
EMail: ice@cisco.com
メールアドレス：ice@cisco.com
Arjen Boers Cisco Systems, Inc. Avda. Diagonal, 682 Barcelona 08034 Spain
アリエン・ボーア人シスコシステムズ、株式会社星Avda。対角、682バルセロナ08034スペイン
EMail: aboers@cisco.com
メールアドレス：aboers@cisco.com
Eric Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, Ma 01719
エリック・ローゼンシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、馬01719
EMail: erosen@cisco.com
メールアドレス：erosen@cisco.com