[要約] RFC 3446は、PIMとMSDPを使用したAnycast Rendevous Point（RP）メカニズムについての規格です。このRFCの目的は、マルチキャスト通信におけるRPの選択と管理を改善することです。
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)
Anycast Rendevous Point（RP）プロトコル独立マルチキャスト（PIM）およびマルチキャストソースディスカバリープロトコル（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.
Copyright（c）The Internet Society（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.
RFC 2362で定義されているPIM-SMは、グループごとに1つのアクティブRPのみを可能にするため、PIM-SMを展開する多領域ネットワークで最適なRP配置の決定が問題になる可能性があります。
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.
Anycast RPは、PIM-SMの重要な制約をリラックスさせます。つまり、RPマッピングのグループがいつでもアクティブになる可能性があるということです。単一のマッピングプロパティには、トラフィック濃度、スケーラブルなレジスタの脱カプセル化の欠如（共有ツリーを使用する場合）の欠如、アクティブな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.
ここで説明するメカニズムは、ドメイン内のRPS間で、より良いフェイルオーバー（収束時間）とレジスタ脱カプセル化負荷の共有（再び共有ツリーを使用する場合）の共有の必要性に対処することを目的としています。主に、MBGP、マルチキャストソース発見プロトコル[MSDP]、およびPIM-SMプロトコルを使用したネットワーク内のアプリケーションを対象としていますが、それらのプロトコルに限定されません。特に、Anycast RPは、MSDPもサポートするPIM-SMネットワークに適用できます（MSDPが必要なため、ドメイン内のさまざまなRPがアクティブなソースの一貫したビューを維持します）。ただし、MBGPを実行するためにAnycast RPを展開するドメインは必要ありません。最後に、Anycast RPスキームの一般的な要件は、Anycastアドレスを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].
キーワードは、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.
Anycast 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マッピングまでのグループは1つだけです。マルチキャストグループスペースをカバーする複数の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はソースおよびレシーバーからトポロジカルに離れています。これは、マルチキャストグループメンバーの動的な性質のアーティファクトであり、オペレーターがグループメンバーのトポロジカル配置に関する先験的な知識を常に持っているとは限らないという事実です。
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に参加しており、データは比較的高価なパイプを2回通過することを意味する可能性があります。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のトップロジカルな位置とは無関係に存在する可能性があります。
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.
特定のグループまたは一連のグループを提供するすべてのRPSは、RPS上の番号付きインターフェイスを使用して、同一のAnycastアドレスで構成されます（多くの場合、ループバックなどの論理インターフェイスが使用されます）。RPSは、このインターフェイスアドレスを使用してグループをRPマッピングに宣伝します。これにより、グループメンバー（送信者）がトポロジカルに最も近いRPに参加（登録）します。各RPに固有のアドレスを使用して、RPS MSDPピアを互いにピアします。Anycastアドレスは（定義上）一意のアドレスではないため、ルーターはRouter IDとしてAnycast Unicastアドレスを選択してはなりません。これにより、ピアリングや隣接が確立されるのを防ぐことができます。
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-Addressマッピングのセットを作成することです。Anycast 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.
次のステップは、Anycast RPアドレスでグループ範囲の各RPを構成することです。Auto-RPやPimv2 Bootstrapメカニズムなどの動的メカニズムがグループをRPマッピングに宣伝するために使用されている場合、ANYCAST IPアドレスをRPアドレスに使用する必要があります。
3.1.3. Configure MSDP peerings between each of the anycast RPs in the set
3.1.3. セット内の各aycast RPSの間に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のピアリングエンドポイントは、AnycastアドレスではなくUnicastを使用する必要があります。一般的なガイドラインは、BGPピーリングのアドレス指定に従うことです。たとえば、IBGPピアリングのループバック、EBGPピアリングの物理インターフェイスアドレス。Anycastアドレスは、SAメッセージのRPアドレスとして使用してはならないことに注意してください（PEER-RPFが失敗するようにチェックする場合があるため）。
3.1.4. Configure the non-RP's with the group-to-anycast-RP-address mappings
3.1.4. グループからアニカスト-RP-Addressマッピングで非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マッピングに学習する必要があります。これは、静的構成、Auto-RP、またはPIMV2ブートストラップメカニズムを介して実行できます。
3.1.5. Ensure that the anycast IP address is reachable by all routers in the domain
3.1.5. ドメイン内のすべてのルーターがAnycast IPアドレスに到達できることを確認してください
This is typically accomplished by causing each RP to inject the /32 into the domain's IGP.
これは通常、各RPが /32をドメインのIGPに注入することによって達成されます。
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ピアは、「PEER-RPF洪水」ファッションでRPアドレスからメッセージを受信して転送します。Peer-RPF洪水の概念は、SAメッセージ[MSDP]の転送に関するものです。BGPルーティングテーブルを調べて、どのピアがSAメッセージの発生RPに向けた次のホップであるかを判断します。このようなピアは「RPFピア」と呼ばれます。PEER-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.
ここで説明するソリューションはAnycastアドレス指定を頻繁に使用しているため、スプーフィングを避けるために注意する必要があります。特に、ユニキャストルーティングとPIM RPSを保護する必要があります。
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.
John Meylor、Bill Fenner、Dave Thaler、Tom 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. Meyer and B. Fenner、編集者、「マルチキャストソースディスカバリープロトコル（MSDP）」、Work in Progress。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, August 1995.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1995年8月。
[RFC1828] Metzger, P. and W. Simpson, "IP Authentication using Keyed MD5", RFC 1828, August 1995.
[RFC1828] Metzger、P。およびW. Simpson、「Keyed 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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Farinacci、D.、Helmy、A.、Thaler、D.、Deering、S.、Handley、M.、Jacobson、V.、Liu、C.、Sharma、P。and L.Wei、「プロトコル独立マルチキャストスパールモード（PIM-SM）：プロトコル仕様」、RFC 2362、1998年6月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、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. Glenn、「ESPおよびAH内のHMAC-MD5-96の使用」、RFC 2403、1998年11月。
Dorian Kim Verio, Inc. EMail: dorian@blackrose.org
Dorian Kim Verio、Inc。メール：dorian@blackrose.org
Hank Kilmer EMail: hank@rem.com
Hank Kilmerメール：hank@rem.com
Dino Farinacci Procket Networks EMail: dino@procket.com
Dino Farinacci Procket Networksメール：dino@procket.com
David Meyer EMail: dmm@maoz.com
David Meyerメール：dmm@maoz.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。