Network Working Group D. Kim
Request for Comments: 3446 Verio
Category: Informational D. Meyer
H. Kilmer
D. Farinacci
Procket Networks
January 2003
Anycast Rendevous Point (RP) mechanism using
Protocol Independent Multicast (PIM)
and Multicast Source Discovery Protocol (MSDP)
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document describes a mechanism to allow for an arbitrary number of Rendevous Points (RPs) per group in a single shared-tree Protocol Independent Multicast-Sparse Mode (PIM-SM) domain.
この文書では、単一の共有ツリープロトコル独立マルチキャスト - スパースモード（PIM-SM）ドメイン内のグループ当たりランデブーポイント（RPS）の任意の数を可能にするメカニズムを説明しています。
PIM-SM, as defined in RFC 2362, allows for only a single active RP per group, and as such the decision of optimal RP placement can become problematic for a multi-regional network deploying PIM-SM.
PIM-SMは、RFC 2362で定義されるように、グループごとに1つだけアクティブRPが可能になり、最適なRPの配置のような決定として、PIM-SMを展開する多地域ネットワークの問題となることができます。
Anycast RP relaxes an important constraint in PIM-SM, namely, that there can be only one group to RP mapping can be active at any time. The single mapping property has several implications, including traffic concentration, lack of scalable register decapsulation (when using the shared tree), slow convergence when an active RP fails, possible sub-optimal forwarding of multicast packets, and distant RP dependencies. These properties of PIM-SM have been demonstrated in native continental or inter-continental scale multicast deployments. As a result, it is clear that ISP backbones require a mechanism that allows definition of multiple active RPs per group in a single PIM-SM domain. Further, any such mechanism should also address the issues addressed above.
エニーキャストRPは、RPマッピングへの唯一のグループが任意の時点でアクティブにできるのがあり得ること、すなわち、PIM-SMに重要な制約を緩和します。単一のマッピングプロパティは、トラフィック濃度、スケーラブルレジスタデカプセル化の欠如（共有ツリーを使用して）、遅い収束アクティブRPに障害が発生し、マルチキャストパケットの可能な準最適の転送、および遠隔RPの依存関係を含むいくつかの意味を有します。 PIM-SMのこれらの特性は、ネイティブの大陸や大陸間規模マルチキャスト展開で実証されています。その結果、ISPのバックボーンは、単一PIM-SMドメイン内のグループごとに複数のアクティブのRPの定義を可能にするメカニズムを必要とすることは明らかです。さらに、どのようなメカニズムは、上記の対処の問題に対処する必要があります。
The mechanism described here is intended to address the need for better fail-over (convergence time) and sharing of the register decapsulation load (again, when using the shared-tree) among RPs in a domain. It is primarily intended for applications within those networks using MBGP, Multicast Source Discovery Protocol [MSDP] and PIM-SM protocols, for native multicast deployment, although it is not limited to those protocols. In particular, Anycast RP is applicable in any PIM-SM network that also supports MSDP (MSDP is required so that the various RPs in the domain maintain a consistent view of the sources that are active). Note however, a domain deploying Anycast RP is not required to run MBGP. Finally, a general requirement of the Anycast RP scheme is that the anycast address MUST NOT be used as the RP address in the RP's SA messages.
ドメイン内のRP間でより良いフェイルオーバー（収束時間）の必要性に対処するために意図され、ここで説明したメカニズムとレジスタカプセル化解除の負荷の分担（再び、共有ツリーを使用して）。これは主に、それはこれらのプロトコルに限定されるものではないが、ネイティブマルチキャスト展開のため、MBGP、マルチキャストソース発見プロトコル[MSDP]とPIM-SMプロトコルを使用してこれらのネットワーク内のアプリケーションを対象としています。具体的には、エニーキャストRPはまた、MSDP（ドメイン内のさまざまなRPがアクティブであるソースの一貫したビューを維持するようにMSDPが必要とされる）をサポートする任意のPIM-SMネットワークにも適用可能です。しかし注意し、エニーキャストRPを展開ドメインはMBGPを実行する必要はありません。最後に、エニーキャストRPスキームの一般的な要件は、エニーキャストアドレスはRPのSAメッセージ内のRPアドレスとして使用されてはならないことです。
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined in BCP 14, RFC 2119 [RFC2119].
キーワードは、MAY、OPTIONAL、必須、推奨、、、、BCP 14、RFC 2119 [RFC2119]で定義されるように解釈されるべきではないべきでないものとものとしてはいけませんしなければなりません。
The anycast RP solution provides a solution for both fast fail-over and shared-tree load balancing among any number of active RPs in a domain.
エニーキャストRPソリューションは、両方の高速フェイルオーバーおよびドメイン内のアクティブなRPは、任意の数の間で共有ツリーの負荷分散をするためのソリューションを提供します。
While PIM-SM allows for multiple RPs to be defined for a given group, only one group to RP mapping can be active at a given time. A traditional deployment mechanism for balancing register decapsulation load between multiple RPs covering the multicast group space is to split up the 224.0.0.0/4 space between multiple defined RPs. This is an acceptable solution as long as multicast traffic remains low, but has problems as multicast traffic increases, especially because the network operator defining group space split between RPs does not always have a priori knowledge of traffic distribution between groups. This can be overcome via periodic reconfigurations, but operational considerations cause this type of solution to scale poorly.
PIM-SMは、特定のグループのために定義される複数のRPを可能にしながら、RPマッピングへの唯一のグループは、所与の時間にアクティブにできます。マルチキャストグループ・スペースをカバーする複数のRP間でレジスタデカプセル化負荷のバランスをとるための伝統的な展開機構は、複数の定義されたRP間224.0.0.0/4スペースを分割することです。これは、マルチキャストトラフィックをRP間グループ空間分割を定義するネットワークオペレータは常にグループ間のトラフィック分布の先験的な知識を持っていない、特にため、低いままであるが、マルチキャストトラフィックが増加するなどの問題を有している限り、許容される溶液です。これは、定期的な再構成を経由して克服することができますが、操作上の考慮事項がこのタイプのソリューションが不十分拡大させます。
When a single RP serves a given multicast group, all joins to that group will be sent to that RP regardless of the topological distance between the RP and the sources and receivers. Initial data will be sent towards the RP also until configured the shortest path tree switch threshold is reached, or the data will always be sent towards the RP if the network is configured to always use the RP rooted shared tree. This holds true even if all the sources and the receivers are in any given single region, and RP is topologically distant from the sources and the receivers. This is an artifact of the dynamic nature of multicast group members, and of the fact that operators may not always have a priori knowledge of the topological placement of the group members.
単一RPが所与のマルチキャスト・グループを提供していたときに、すべてのそのグループに加入に関わらずRPと情報源と受信機との間の位相的距離のRPに送信されます。初期データもRPに向けて送信されます設定されるまでの最短経路ツリースイッチのしきい値に達している、またはネットワークは常にRP根づい共有ツリーを使用するように設定されている場合、データは常にRPに向けて送信されます。すべてのソースおよびレシーバは、任意の単一の領域にあり、RPは送信元と受信から位相幾何学的に離れている場合にもこれが当てはまります。これは、マルチキャストグループメンバーの動的な性質の、演算子は常にグループメンバーのトポロジカル配置の事前の知識を持たないかもしれないという事実のアーティファクトです。
Taken together, these effects can mean that (for example) although all the sources and receivers of a given group are in Europe, they are joining towards the RP in the USA and the data will be traversing a relatively expensive pipe(s) twice, once to get to RP, and back down the RP rooted tree again, creating inefficient use of expensive resources.
まとめると、これらの効果は、特定のグループのすべてのソースとレシーバがヨーロッパであるが（例えば）彼らは二回、比較的高価なパイプ（複数可）を通過され、米国およびデータでRPの方に参加していることを意味することができ、高価な資源の非効率的な使用を作成し、一度RPを取得するために、そして再びRP根付いた木を下にバックアップ。
As outlined above, a single active RP per group may cause local sources and receivers to become dependent on a topologically distant RP. In addition, when multiple RPs are configured, there can be considerable convergence delay involved in switching to the backup RP. This delay may exist independent of the toplogical location of the primary and backup RPs.
上記で概説したように、グループごとに単一のアクティブRPは、ローカルソース及び受信機が位相的遠いRPに依存になることができます。複数のRPが設定されている場合に加えて、バックアップRPへの切り替えに関与するかなりの収束遅延が存在し得ます。この遅延は、プライマリとバックアップのRPのtoplogical位置とは無関係に存在してもよいです。
Given the problem set outlined above, a good solution would allow an operator to configure multiple RPs per group, and distribute those RPs in a topologically significant manner to the sources and receivers.
上記で概説した問題のセットを与え、良い解決策は、オペレータがグループごとに複数のRPを設定し、ソースとレシーバにトポロジー的に有意な様式でそれらのRPを配布することを可能にします。
All the RPs serving a given group or set of groups are configured with an identical anycast address, using a numbered interface on the RPs (frequently a logical interface such as a loopback is used). RPs then advertise group to RP mappings using this interface address. This will cause group members (senders) to join (register) towards the topologically closest RP. RPs MSDP peer with each other using an address unique to each RP. Since the anycast address is not a unique address (by definition), a router MUST NOT choose the anycast unicast address as the router ID, as this can prevent peerings and/or adjacencies from being established.
すべてのRP所定のグループにサービスを提供するか、グループのセットは、（しばしば、ループバックなどの論理インタフェースが使用されている）のRP上の番号付きインターフェイスを使用して、同じエニーキャストアドレスが設定されています。 RPは、このインターフェイスのアドレスを使用してRPマッピングにグループを宣伝します。これは、グループメンバー（送信者）は、位相的に最も近いRPに向けて（登録）に参加するようになります。 RPはMSDPは各RPに一意のアドレスを使用して互いにピア。エニーキャストアドレスは（定義）固有のアドレスではないので、これは確立されているから、ピアリングおよび/または隣接することを防止することができるよう、ルータは、ルータIDとしてエニーキャストユニキャストアドレスを選択してはなりません。
In summary then, the following steps are required:
その後、要約すると、以下の手順が必要です。
The first step is to create the set of group-to-anycast-RP-address mappings to be used in the domain. Each RP participating in an anycast RP set must be configured with a consistent set of group to RP address mappings. This mapping will be used by the non-RP routers in the domain.
最初のステップは、ドメインで使用するグループ・ツー・エニーキャスト-RPアドレスマッピングのセットを作成することです。エニーキャストRPセットに参加している各RPは、RPアドレスマッピングへのグループの一貫したセットを設定する必要があります。このマッピングは、ドメイン内の非RPルータで使用されます。
The next step is to configure each RP for the group range with the anycast RP address. If a dynamic mechanism, such as auto-RP or the PIMv2 bootstrap mechanism, is being used to advertise group to RP mappings, the anycast IP address should be used for the RP address.
次のステップは、エニーキャストRPアドレスを持つグループの範囲について各RPを設定することです。このような自動RPまたはPIMv2のブートストラップ機構として動的機構は、RPマッピングにグループを宣伝するために使用されている場合、エニーキャストIPアドレスがRPアドレスに使用されるべきです。
3.1.3. Configure MSDP peerings between each of the anycast RPs in the set
3.1.3. セットでエニーキャストのRPのそれぞれの間でMSDPピアリングを設定します
Unlike the group to RP mapping advertisements, MSDP peerings must use an IP address that is unique to the endpoints; that is, the MSDP peering endpoints MUST use a unicast rather than anycast address. A general guideline is to follow the addressing of the BGP peerings, e.g., loopbacks for iBGP peering, physical interface addresses for eBGP peering. Note that the anycast address MUST NOT be used as the RP address in SA messages (as this would case the peer-RPF check to fail).
RPマッピング広告へのグループとは異なり、MSDPピアリングは、エンドポイントに固有のIPアドレスを使用する必要があります。つまり、MSDPピアリングエンドポイントは、ユニキャストではなく、エニーキャストアドレスを使用する必要があります。一般的なガイドラインは、BGPピアリングのアドレッシング従うことで、例えば、iBGPのピアリング、のeBGPピアリングのための物理インターフェイスアドレスのループバック。 （これが失敗するピアRPFチェックをケースと同じように）エニーキャストアドレスは、SAメッセージ内のRPアドレスとして使用してはいけないことに注意してください。
3.1.4. Configure the non-RP's with the group-to-anycast-RP-address mappings
3.1.4. 非RPのは、グループ・ツー・エニーキャスト-RP-アドレスのマッピングを設定します
Finally, each non-RP router must learn the set of group to RP mappings. This could be done via static configuration, auto-RP, or by PIMv2 bootstrap mechanism.
最後に、各非RPルータがRPマッピングへのグループのセットを学ばなければなりません。これは、またはPIMv2のブートストラップメカニズムによって静的な設定、自動RPを経由して行うことができます。
3.1.5. Ensure that the anycast IP address is reachable by all routers in the domain
3.1.5. エニーキャストIPアドレスは、ドメイン内のすべてのルータによって到達可能であることを確認してください
This is typically accomplished by causing each RP to inject the /32 into the domain's IGP.
これは、典型的には、各RPは、ドメインのIGPに/ 32を注入させることにより達成されます。
Each MSDP peer receives and forwards the message away from the RP address in a "peer-RPF flooding" fashion. The notion of peer-RPF flooding is with respect to forwarding SA messages [MSDP]. The BGP routing tables are examined to determine which peer is the next hop towards the originating RP of the SA message. Such a peer is called an "RPF peer". See [MSDP] for details of the Peer-RPF check.
各MSDPピアは離れて、「ピアRPFフラッディング」ファッションでRPアドレスからメッセージを受信して転送します。ピアRPFフラッディングの概念は、SAメッセージ[MSDP]の転送に関するものです。 BGPルーティングテーブルは、SAメッセージの発信元RPに向かって次のホップであるピアを決定するために調べられます。このようなピアは、「RPFピア」と呼ばれています。ピアRPFチェックの詳細については、[MSDP]を参照してください。
It should be noted that using MSDP in this way forces the creation of (S,G) state along the path from the receiver to the source. This state may not be present if a single RP was used and receivers were forced to stay on the shared tree.
なお、このようにMSDPを使用してソースに受信機からのパスに沿って（S、G）ステートの作成を強制的ことに留意すべきです。単一のRPを使用し、受信機は共有ツリーに滞在することを余儀なくされた場合には、この状態は存在しないかもしれません。
Since the solution described here makes heavy use of anycast addressing, care must be taken to avoid spoofing. In particular unicast routing and PIM RPs must be protected.
ここで説明するソリューションは、エニーキャストアドレッシングを多用しているので、注意がなりすましを避けるようにしなければなりません。具体的にはユニキャストルーティングおよびPIM RPは保護されなければなりません。
Both internal and external unicast routing can be weakly protected with keyed MD5 [RFC1828], as implemented in an internal protocol such as OSPF [RFC2328] or in BGP [RFC2385]. More generally, IPSEC [RFC2401] could be used to provide protocol integrity for the unicast routing system.
例えばOSPF [RFC2328]として、またはBGP [RFC2385]に内部プロトコルに実装され、内部および外部のユニキャストルーティングが弱く、キー付きMD5 [RFC1828]で保護することができます。より一般的には、IPSEC [RFC2401]はユニキャストルーティングシステムのためのプロトコルの完全性を提供するために使用することができます。
While not a security issue, it is worth noting that if unicast routing is unstable, then the actual RP that source or receiver is using will be subject to the same instability.
セキュリティ上の問題はないが、ユニキャストルーティングが不安定である場合、ソース又は受信機が使用している実際のRPは、同じ不安定性の対象となることは注目に値します。
The mechanisms described in [RFC2362] should be used to provide protocol message integrity protection and group-wise message origin authentication.
[RFC2362]で説明されたメカニズムは、プロトコルメッセージの完全性保護およびグループごとのメッセージ発信元認証を提供するために使用されるべきです。
As is the the case for BGP, MSDP peers can be protected using keyed MD5 [RFC1828].
BGPの場合のように、MSDPピアは、鍵付きMD5 [RFC1828]を使用して保護することができます。
John Meylor, Bill Fenner, Dave Thaler and Tom Pusateri provided insightful comments on earlier versions for this idea.
ジョンMeylor、ビルフェナー、デーブターラーとトムPusateriはこのアイデアのための以前のバージョンで洞察に満ちたコメントを提供しました。
This memo is a product of the MBONE Deployment Working Group (MBONED) in the Operations and Management Area of the Internet Engineering Task Force. Submit comments to <mboned@ns.uoregon.edu> or the authors.
このメモはインターネットエンジニアリングタスクフォースの運用と管理領域におけるMBONE展開ワーキンググループ（MBONED）の製品です。 <mboned@ns.uoregon.edu>や作者へのコメントを提出してください。
[MSDP] D. Meyer and B. Fenner, Editors, "Multicast Source Discovery Protocol (MSDP)", Work in Progress.
[MSDP] D.マイヤーとB.フェナー、エディターズ、 "は、Multicast Source Discovery Protocol（MSDP）" が進行中で働いています。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, August 1995.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1995年8月。
[RFC1828] Metzger, P. and W. Simpson, "IP Authentication using Keyed MD5", RFC 1828, August 1995.
[RFC1828]メッツガー、P.とW.シンプソン、 "鍵付きMD5を使用してIP認証"、RFC 1828、1995年8月。
[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月。
[RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[RFC2362] Estrin、D.、ファリナッチ、D.、Helmy、A.、ターラー、D.、デアリング、S.、ハンドレー、M.、ヤコブソン、V.、劉、C.、シャルマ、P.、およびL.魏、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様"、RFC 2362、1998年6月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernanの、A.、 "TCP MD5署名オプションを使用してBGPセッションの保護"、RFC 2385、1998年8月。
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
[RFC2403] Madson、C.とR.グレン、 "ESPおよびAH内のHMAC-MD5-96の使用"、RFC 2403、1998年11月。
Dorian Kim Verio, Inc. EMail: dorian@blackrose.org
ドリアンキム・ベリオ、株式会社Eメール：dorian@blackrose.org
Hank Kilmer EMail: hank@rem.com
ハンク・キルマーEメール：hank@rem.com
Dino Farinacci Procket Networks EMail: dino@procket.com
ディノファリナッチProcket NetworksのEメール：dino@procket.com
David Meyer EMail: dmm@maoz.com
デビッド・マイヤー電子メール：dmm@maoz.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。