[要約] RFC 4611は、Multicast Source Discovery Protocol（MSDP）の展開シナリオに関する情報を提供する。その目的は、MSDPの使用方法と展開に関するガイダンスを提供し、ネットワーク管理者が効果的にMSDPを導入できるようにすることである。
Network Working Group M. McBride
Request for Comments: 4611 J. Meylor
BCP: 121 D. Meyer
Category: Best Current Practice August 2006
Multicast Source Discovery Protocol (MSDP) Deployment Scenarios
マルチキャストソースディスカバリープロトコル（MSDP）展開シナリオ
Status of This Memo
本文書の位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document describes best current practices for intra-domain and inter-domain deployment of the Multicast Source Discovery Protocol (MSDP) in conjunction with Protocol Independent Multicast Sparse Mode (PIM-SM).
このドキュメントでは、プロトコルに依存しないマルチキャストスパースモード（PIM-SM）と組み合わせて、マルチキャストソースディスカバリープロトコル（MSDP）のドメイン内およびドメイン間展開のための最良の現在のプラクティスについて説明します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. BCP, Experimental Protocols, and Normative References ......3
2. Inter-domain MSDP Peering Scenarios .............................4
2.1. Peering between PIM Border Routers .........................4
2.2. Peering between Non-Border Routers .........................5
2.3. MSDP Peering without BGP ...................................7
2.4. MSDP Peering at a Multicast Exchange .......................7
3. Intra-domain MSDP Peering Scenarios .............................7
3.1. Peering between MSDP- and MBGP-Configured Routers ..........8
3.2. MSDP Peer Is Not BGP Peer (or No BGP Peer) .................8
3.3. Hierarchical Mesh Groups ...................................9
3.4. MSDP and Route Reflectors .................................10
3.5. MSDP and Anycast RPs ......................................11
4. Security Considerations ........................................11
4.1. Filtering SA Messages .....................................11
4.2. SA Message State Limits ...................................12
5. Acknowledgements ...............................................12
6. References .....................................................12
6.1. Normative References ......................................12
6.2. Informative References ....................................13
MSDP [RFC3618] is used primarily in two deployment scenarios:
MSDP [RFC3618]は、主に2つの展開シナリオで使用されます。
o Between PIM Domains
o PIMドメイン間
MSDP can be used between Protocol Independent Multicast Sparse Mode (PIM-SM) [RFC4601] domains to convey information about active sources available in other domains. MSDP peering used in such cases is generally one-to-one peering, and utilizes the deterministic peer-RPF (Reverse Path Forwarding) rules described in the MSDP specification (i.e., it does not use mesh-groups). Peerings can be aggregated on a single MSDP peer. Such a peer can typically have from one to hundreds of peerings, which is similar in scale to BGP peerings.
MSDPは、プロトコル独立したマルチキャストスパースモード（PIM-SM）[RFC4601]ドメイン間で使用して、他のドメインで利用可能なアクティブソースに関する情報を伝えることができます。このような場合に使用されるMSDPピアリングは、一般に1対1のピアリングであり、MSDP仕様で説明されている決定論的PEER-RPF（リバースパス転送）ルールを利用します（つまり、メッシュグループを使用しません）。ピアリングは、単一のMSDPピアに集約できます。このようなピアは通常、1つから数百のピーリングを持つことができます。
o Within a PIM Domain
o PIMドメイン内
MSDP is often used between Anycast Rendezvous Points (Anycast-RPs) [RFC3446] within a PIM domain to synchronize information about the active sources being served by each Anycast-RP peer (by virtue of IGP reachability). MSDP peering used in this scenario is typically based on MSDP mesh groups, where anywhere from two to tens of peers can comprise a given mesh group, although more than ten is not typical. One or more of these mesh-group peers may also have additional one-to-one peerings with MSDP peers outside that PIM domain for discovery of external sources. MSDP for anycast-RP without external MSDP peering is a valid deployment option and common.
MSDPは、PIMドメイン内のAnycast Rendezvous Points（AnyCast-RPS）[RFC3446）の間でよく使用され、各Anycast-RPピアが提供するアクティブソースに関する情報を同期させます（IGPの到達可能性により）。このシナリオで使用されるMSDPピアリングは、通常、MSDPメッシュグループに基づいており、2から数十のピアが特定のメッシュグループを構成できますが、10以上は典型的ではありません。これらのメッシュグループのピアの1つ以上は、外部ソースを発見するために、そのPIMドメインの外にMSDPピアを備えた追加の1対1のピアリングを持っている場合があります。外部MSDPピアリングなしのanyCast-RPのMSDPは、有効な展開オプションであり、共通です。
Current best practice for MSDP deployment utilizes PIM-SM and the Border Gateway Protocol with multi-protocol extensions (MBGP) [RFC4271, RFC2858]. This document outlines how these protocols work together to provide an intra-domain and inter-domain Any Source Multicast (ASM) service.
MSDP展開の現在のベストプラクティスは、Multi-Protocol拡張機能（MBGP）[RFC4271、RFC2858]を備えたPIM-SMおよびBorder Gateway Protocolを利用しています。このドキュメントでは、これらのプロトコルがどのように連携してドメイン内およびドメイン間の任意のソースマルチキャスト（ASM）サービスを提供する方法を概説しています。
The PIM-SM specification assumes that SM operates only in one PIM domain. MSDP is used to enable the use of multiple PIM domains by distributing the required information about active multicast sources to other PIM domains. Due to breaking the Internet multicast infrastructure down to multiple PIM domains, MSDP also enables the possibility of setting policy on the visibility of the groups and sources.
PIM-SM仕様は、SMが1つのPIMドメインでのみ動作することを前提としています。MSDPは、アクティブなマルチキャストソースに関する必要な情報を他のPIMドメインに配布することにより、複数のPIMドメインの使用を有効にするために使用されます。インターネットのマルチキャストインフラストラクチャを複数のPIMドメインに分解するため、MSDPは、グループとソースの可視性に関するポリシーを設定する可能性も可能にします。
Transit IP providers typically deploy MSDP to be part of the global multicast infrastructure by connecting to their upstream and peer multicast networks using MSDP.
Transit IPプロバイダーは通常、MSDPを使用して上流およびピアマルチキャストネットワークに接続することにより、MSDPをグローバルマルチキャストインフラストラクチャの一部に展開します。
Edge multicast networks typically have two choices: to use their Internet providers' RP, or to have their own RP and connect it to their ISP using MSDP. By deploying their own RP and MSDP, they can use internal multicast groups that are not visible to the provider's RP. This helps internal multicast be able to continue to work in the event that there is a problem with connectivity to the provider or that the provider's RP/MSDP is experiencing difficulties. In the simplest cases, where no internal multicast groups are necessary, there is often no need to deploy MSDP.
Edgeマルチキャストネットワークには通常、インターネットプロバイダーのRPを使用するか、独自のRPを使用してMSDPを使用してISPに接続するという2つの選択肢があります。独自のRPとMSDPを展開することにより、プロバイダーのRPに見えない内部マルチキャストグループを使用できます。これにより、内部マルチキャストは、プロバイダーへの接続に問題がある場合、またはプロバイダーのRP/MSDPが困難を経験している場合に、引き続き作業を行うことができます。内部マルチキャストグループが必要ない最も簡単な場合、MSDPを展開する必要はないことがよくあります。
This document describes the best current practice for a widely deployed Experimental protocol, MSDP. There is no plan to advance the MSDP's status (for example, to Proposed Standard). The reasons for this include:
このドキュメントでは、広く展開されている実験プロトコルであるMSDPの最良の現在のプラクティスについて説明しています。MSDPのステータスを前進させる計画はありません（たとえば、提案された標準）。これの理由は次のとおりです。
o MSDP was originally envisioned as a temporary protocol to be supplanted by whatever the IDMR working group produced as an inter-domain protocol. However, the IDMR WG (or subsequently, the BGMP WG) never produced a protocol that could be deployed to replace MSDP.
o MSDPはもともと、IDMRワーキンググループがドメイン間プロトコルとして生成したものに取って代わる一時的なプロトコルとして想定されていました。ただし、IDMR WG（またはその後、BGMP WG）は、MSDPを置き換えるために展開できるプロトコルを作成しませんでした。
o One of the primary reasons given for MSDP to be classified as Experimental was that the MSDP Working Group came up with modifications to the protocol that the WG thought made it better but that implementors didn't see any reasons to deploy. Without these modifications (e.g., UDP or GRE encapsulation), MSDP can have negative consequences to initial packets in datagram streams.
o MSDPが実験として分類される主な理由の1つは、MSDPワーキンググループがWGが考えたプロトコルの変更を考え出したことでした。これらの変更（UDPやGREのカプセル化など）がなければ、MSDPはデータグラムストリームの初期パケットにマイナスの結果をもたらす可能性があります。
o Scalability: Although we don't know what the hard limits might be, readvertising everything you know every 60 seconds clearly limits the amount of state you can advertise.
o スケーラビリティ：厳しい制限が何であるかはわかりませんが、60秒ごとに知っているすべてを読み取り、宣伝できる状態の量を明確に制限します。
o MSDP reached nearly ubiquitous deployment as the de facto standard inter-domain multicast protocol in the IPv4 Internet.
o MSDPは、IPv4インターネットでの事実上の標準標準のドメイン間マルチキャストプロトコルとして、ほぼユビキタスな展開に達しました。
o No consensus could be reached regarding the reworking of MSDP to address the many concerns of various constituencies within the IETF. As a result, a decision was taken to document what is (ubiquitously) deployed and to move that document to Experimental. While advancement of MSDP to Proposed Standard was considered, for the reasons mentioned above, it was immediately discarded.
o IETF内のさまざまな選挙区の多くの懸念に対処するために、MSDPの再加工に関してはコンセンサスに達することはできませんでした。その結果、（遍在的に）展開されているものを文書化し、そのドキュメントを実験的に移動するという決定が下されました。提案された標準へのMSDPの進歩が考慮されましたが、上記の理由により、すぐに廃棄されました。
o The advent of protocols such as source-specific multicast and bi-directional PIM, as well as embedded RP techniques for IPv6, have further reduced consensus that a replacement protocol for MSDP for the IPv4 Internet is required.
o ソース固有のマルチキャストや双方向PIMなどのプロトコルの出現、およびIPv6の埋め込みRPテクニックは、IPv4インターネットのMSDPの交換プロトコルが必要であるというコンセンサスをさらに減らしました。
The RFC Editor's policy regarding references is that they be split into two categories known as "normative" and "informative". Normative references specify those documents that must be read for one to understand or implement the technology in an RFC (or whose technology must be present for the technology in the new RFC to work) [RFCED]. In order to understand this document, one must also understand both the PIM and MSDP documents. As a result, references to these documents are normative.
参照に関するRFCエディターのポリシーは、それらが「規範」および「有益」として知られる2つのカテゴリに分割されることです。規範的参照は、RFCでテクノロジーを理解または実装するために読む必要があるドキュメントを指定します（または、新しいRFCのテクノロジーが機能するためにテクノロジーが存在する必要があります）[RFCED]。このドキュメントを理解するには、PIMドキュメントとMSDPドキュメントの両方を理解する必要があります。その結果、これらのドキュメントへの言及は規範的です。
The IETF has adopted the policy that BCPs must not have normative references to Experimental protocols. However, this document is a special case in that the underlying Experimental document (MSDP) is not planned to be advanced to Proposed Standard.
IETFは、BCPSが実験プロトコルへの規範的な参照を持っていてはならないというポリシーを採用しています。ただし、このドキュメントは、基礎となる実験文書（MSDP）が提案された標準に進む予定ではないという特別なケースです。
The MBONED Working Group has requested approval under the Variance Procedure as documented in RFC 2026 [RFC2026]. The IESG followed the Variance Procedure and, after an additional 4 week IETF Last Call, evaluated the comments and status, and has approved this document.
MBONEDワーキンググループは、RFC 2026 [RFC2026]に記録されているように、分散手順に基づく承認を要求しています。IESGは分散手順に従い、さらに4週間のIETF最後の呼び出しの後、コメントとステータスを評価し、このドキュメントを承認しました。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
The following sections describe the most common inter-domain MSDP peering possibilities and their deployment options.
次のセクションでは、最も一般的なドメイン間MSDPピアリングの可能性とその展開オプションについて説明します。
In this case, the MSDP peers within the domain have their own RP located within a bounded PIM domain. In addition, the domain will typically have its own Autonomous System (AS) number and one or more MBGP speakers. The domain may also have multiple MSDP speakers. Each border router has an MSDP and MBGP peering with its peer routers. These external MSDP peering deployments typically configure the MBGP peering and MSDP peering using the same directly connected next hop peer IP address or other IP address from the same router. Typical deployments of this type are providers who have a direct peering with other providers, providers peering at an exchange, or providers who use their edge router to MSDP/MBGP peer with customers.
この場合、ドメイン内のMSDPピアは、境界付きPIMドメイン内に独自のRPがあります。さらに、ドメインには通常、独自の自律システム（AS）数と1つ以上のMBGPスピーカーがあります。ドメインには、複数のMSDPスピーカーがある場合があります。各ボーダールーターには、ピアルーターを備えたMSDPとMBGPのピアリングがあります。これらの外部MSDPピアリング展開は通常、同じ直接接続された次のホップピアIPアドレスまたは同じルーターからその他のIPアドレスを使用して、MBGPピアリングとMSDPピアリングを構成します。このタイプの典型的な展開は、他のプロバイダーと直接ピアリングをしているプロバイダー、交換を覗き込んでいるプロバイダー、または顧客とのMSDP/MBGPピアにエッジルーターを使用するプロバイダーです。
For a direct peering inter-domain environment to be successful, the first AS in the MBGP best path to the originating RP should be the same as the AS of the MSDP peer. As an example, consider the following topology:
直接的なピアリングドメイン間環境を成功させるには、MBGPの最初のASが発生するRPへの最良のパスでは、MSDPピアと同じでなければなりません。例として、次のトポロジーを検討してください。
AS1----AS2----AS4
| /
| /
| /
AS3
In this case, AS4 receives a Source Active (SA) message, originated by AS1, from AS2. AS2 also has an MBGP peering with AS4. The MBGP first hop AS from AS4, in the best path to the originating RP, is AS2. The AS of the sending MSDP peer is also AS2. In this case, the peer-Reverse Path Forwarding check (peer-RPF check) passes, and the SA message is forwarded.
この場合、AS4はAS2からAS1によって発信されるソースアクティブ（SA）メッセージを受信します。AS2には、AS4でMBGPピアリングもあります。AS4からのMBGPの最初のホップは、発生RPへの最良のパスでAS2です。送信中のMSDPピアの時点でもAS2です。この場合、ピアリバースパス転送チェック（PEER-RPFチェック）が通過し、SAメッセージが転送されます。
A peer-RPF failure would occur in this topology when the MBGP first hop AS, in the best path to the originating RP, is AS2 and the origin AS of the sending MSDP peer is AS3. This reliance upon BGP AS PATH information prevents endless looping of SA packets.
Router code, which has adopted the latest rules in the MSDP document, will relax the rules between AS's a bit. In the following topology, we have an MSDP peering between AS1<->AS3 and AS3<->AS4:
MSDPドキュメントで最新のルールを採用したルーターコードは、ASの間のルールを少し緩和します。次のトポロジでは、AS1 <-> AS3とAS3 <-> AS4の間にMSDPのピアリングがあります。
RP
AS1----AS2----AS3----AS4
If the first AS in best path to the RP does not equal the MSDP peer, MSDP peer-RPF fails. So AS1 cannot MSDP peer with AS3, since AS2 is the first AS in the MBGP best path to AS4 RP. With the latest MSDP document compliant code, AS1 will choose the peer in the closest AS along best AS path to the RP. AS1 will then accept SA's coming from AS3. If there are multiple MSDP peers to routers within the same AS, the peer with the highest IP address is chosen as the RPF peer.
RPへの最良のパスがMSDPピアと等しくない最初のパスが失敗します。AS1はAS2でAS3でMSDPピアを使用することはできません。AS2はMBGP AS4 RPへのベストパスのように最初です。最新のMSDPドキュメントに準拠したコードを使用すると、AS1はRPへのパスとして最高のように最も近いピアを選択します。AS1は、SAがAS3から来ることを受け入れます。同じものと同じルーターに複数のMSDPピアがある場合、最高のIPアドレスを持つピアがRPFピアとして選択されます。
For MSDP peering between border routers, intra-domain MSDP scalability is restricted because it is necessary to also maintain MBGP and MSDP peerings internally towards their border routers. Within the intra-domain, the border router becomes the announcer of the next hop towards the originating RP. This requires that all intra-domain MSDP peerings mirror the MBGP path back towards the border router. External MSDP (eMSDP) peerings rely upon AS path for peer RPF checking, while internal MSDP (iMSDP) peerings rely upon the announcer of the next hop.
ボーダールーター間のMSDPピーアリングの場合、Domain内MSDPのスケーラビリティは、MBGPおよびMSDPピーリングをボーダールーターに向けて内部的に維持する必要があるため制限されています。ドメイン内では、Border Routerが起源のRPに向けた次のホップのアナウンサーになります。これには、すべてのドメイン内MSDPピーリングがMBGPパスをボーダールーターに向かって反映する必要があります。外部MSDP（EMSDP）ピーリングは、ピアRPFチェックのパスとして依存していますが、内部MSDP（IMSDP）ピーリングは次のホップのアナウンサーに依存しています。
While the eMBGP peer is typically directly connected between border routers, it is common for the eMSDP peer to be located deeper into the transit provider's AS. Providers, which desire more flexibility in MSDP peering placement, commonly choose a few dedicated routers within their core networks for the inter-domain MSDP peerings to their customers. These core MSDP routers will also typically be in the provider's intra-domain MSDP mesh group and be configured for Anycast RP. All multicast routers in the provider's AS should statically point to the Anycast RP address. Static RP assignment is the most commonly used method for group-to-RP mapping due to its deterministic nature. Auto-RP [RFC4601] and/or the Bootstrap Router (BSR) [BSR] dynamic RP mapping mechanisms could also be used to disseminate RP information within the provider's network
埋め込みピアは通常、ボーダールーター間で直接接続されていますが、EMSDPピアが輸送プロバイダーのASの奥深くに配置されることが一般的です。MSDPピアリング配置の柔軟性を希望するプロバイダーは、一般に、ドメイン間MSDPピーリングのコアネットワーク内にいくつかの専用ルーターを顧客に選択します。これらのコアMSDPルーターは、通常、プロバイダーのドメイン内MSDPメッシュグループにも含まれ、Anycast RP用に構成されます。プロバイダーのすべてのマルチキャストルーターは、Anycast RPアドレスを静的に指す必要があります。静的RP割り当ては、その決定論的性質のため、グループ間マッピングに最も一般的に使用される方法です。Auto-RP [RFC4601]および/またはブートストラップルーター（BSR）[BSR]動的RPマッピングメカニズムを使用して、プロバイダーのネットワーク内のRP情報を広めることもできます。
For an SA message to be accepted in this (multi-hop peering) environment, we rely upon the next (or closest, with latest MSDP spec) AS in the best path towards the originating RP for the RPF check. The MSDP peer address should be in the same AS as the AS of the border router's MBGP peer. The MSDP peer address should be advertised via MBGP.
この（マルチホップピアリング）環境でSAメッセージを受け入れるためには、RPFチェックの発生RPへの最適なパスのように、次の（または最新のMSDP仕様を使用）に依存しています。MSDPピアアドレスは、Border RouterのMBGPピアと同じである必要があります。MSDPのピアアドレスは、MBGPを介して宣伝する必要があります。
For example, in the diagram below, if customer R1 router is MBGP peering with the R2 router and if R1 is MSDP peering with the R3 router, then R2 and R3 must be in the same AS (or must appear, to AS1, to be from the same AS in the event that private AS numbers are deployed). The MSDP peer with the highest IP address will be chosen as the MSDP RPF peer. R1 must also have the MSDP peer address of R3 in its MBGP table.
たとえば、以下の図では、顧客R1ルーターがR2ルーターでMBGPピーリングであり、R1がR3ルーターでMSDPのピアリングの場合、R2とR3は同じ（またはAS1に表示される必要があります）プライベートAs Numbersが展開されている場合と同じ）。最高のIPアドレスを持つMSDPピアは、MSDP RPFピアとして選択されます。R1は、MBGPテーブルにR3のMSDPピアアドレスも搭載する必要があります。
+--+ +--+ +--+
|R1|----|R2|----|R3|
+--+ +--+ +--+
AS1 AS2 AS2
From R3's perspective, AS1 (R1) is the MBGP next AS in the best path towards the originating RP. As long as AS1 is the next AS (or closest) in the best path towards the originating RP, RPF will succeed on SAs arriving from R1.
R3の観点から見ると、AS1（R1）は次のMBGPです。AS1が次のAS（または最も近い）である限り、RPから到着したSASでRPFが成功します。
In contrast, with the single hop scenario, with R2 (instead of R3) border MSDP peering with R1 border, R2's MBGP address becomes the announcer of the next hop for R3, towards the originating RP, and R3 must peer with that R2 address. Moreover, all AS2 intra-domain MSDP peers need to follow iMBGP (or other IGP) peerings towards R2 since iMSDP has a dependence upon peering with the address of the MBGP (or other IGP) announcer of the next hop.
対照的に、R1ボーダーでR2（R3の代わりに）ボーダーMSDPのピアリングを伴うシングルホップシナリオでは、R2のMBGPアドレスがR3の次のホップのアナウンサーとなり、R3のR3がそのR2アドレスでピアになります。さらに、すべてのAS2ドメイン内MSDPピアは、IMSDPが次のホップのMBGP（または他のIGP）アナウンサーのアドレスを覗き込むことに依存しているため、R2に対するIMBGP（または他のIGP）のピアリングに従う必要があります。
In this case, an enterprise maintains its own RP and has an MSDP peering with its service provider but does not BGP peer with them. MSDP relies upon BGP path information to learn the MSDP topology for the SA peer-RPF check. MSDP can be deployed without BGP, however, and as a result, there are some special cases where the requirement to perform a peer-RPF check on the BGP path information is suspended. These cases are:
この場合、エンタープライズは独自のRPを維持し、サービスプロバイダーとのMSDPの覗き見を持っていますが、BGPのピアはありません。MSDPは、SAピアRPFチェックのMSDPトポロジを学習するためにBGPパス情報に依存しています。ただし、MSDPはBGPなしで展開できます。その結果、BGPパス情報でPEER-RPFチェックを実行するための要件が停止される特別なケースがいくつかあります。これらのケースは次のとおりです。
o There is only a single MSDP peer connection.
o
o A default peer (default MSDP route) is configured.
o デフォルトのピア（デフォルトのMSDPルート）が構成されています。
o The originating RP is directly connected.
o 発生RPは直接接続されています。
o A mesh group is used.
o メッシュグループが使用されます。
o An implementation is used that allows for an MSDP peer-RPF check using an IGP.
o IGPを使用してMSDP PEER-RPFチェックを可能にする実装が使用されます。
An enterprise will typically configure a unicast default route from its border router to the provider's border router and then MSDP peer with the provider's MSDP router. If internal MSDP peerings are also used within the enterprise, then an MSDP default peer will need to be configured on the border router that points to the provider. In this way, all external multicast sources will be learned, and internal sources can be advertised. If only a single MSDP peering was used (no internal MSDP peerings) towards the provider, then this stub site will MSDP default peer towards the provider and skip the peer-RPF check.
エンタープライズは通常、ボーダールーターからプロバイダーのボーダールーターまでのユニキャストデフォルトルートを構成し、プロバイダーのMSDPルーターでMSDPピアを構成します。内部MSDPピーリングがエンタープライズ内で使用されている場合、MSDPデフォルトピアをプロバイダーを指すBorder Routerで構成する必要があります。このようにして、すべての外部マルチキャストソースが学習され、内部ソースを宣伝できます。プロバイダーに向けて単一のMSDPピアリング（内部MSDPピーリングがない）のみが使用された場合、このスタブサイトはプロバイダーに向かってMSDPデフォルトピアを使用し、PEER-RPFチェックをスキップします。
Multicast exchanges allow multicast providers to peer at a common IP subnet (or by using point-to-point virtual LANs) and share MSDP SA updates. Each provider will MSDP and MBGP peer with each others directly connected exchange IP address. Each exchange router will send/receive SAs to/from their MSDP peers. They will then be able to forward SAs throughout their domain to their customers and any direct provider peerings.
マルチキャスト交換により、マルチキャストプロバイダーは、一般的なIPサブネット（またはポイントツーポイント仮想LANを使用する）を覗き見し、MSDP SAの更新を共有できます。各プロバイダーは、直接接続されたExchange IPアドレスとMSDPおよびMBGPピアを互いにピアにします。各Exchangeルーターは、MSDPピアにSASを送信/受信します。その後、彼らはドメイン全体でSASを顧客や直接プロバイダーの覗き見に転送することができます。
The following sections describe the different intra-domain MSDP peering possibilities and their deployment options.
次のセクションでは、さまざまなドメイン内MSDPピアリングの可能性とその展開オプションについて説明します。
The next hop IP address of the iBGP peer is typically used for the MSDP peer-RPF check (IGP can also be used). This is different from the inter-domain BGP/MSDP case, where AS path information is used for the peer-RPF check. For this reason, it is necessary for the IP address of the MSDP peer connection to be the same as the internal MBGP peer connection whether or not the MSDP/MBGP peers are directly connected. A successful deployment would be similar to the following:
+----+
| Rb | 3.3.3.3
/ +----+
AS1 AS2 / |
+---+ +--+ / |
|RP1|---------|Ra| |
+---+ +--+ |
1.1.1.1 2.2.2.2 |
\ |
\ |
\ +-----+
| RP2 |
+-----+
where RP2 MSDP and MBGP peers with Ra (using 2.2.2.2) and with Rb (using 3.3.3.3). When the MSDP SA update arrives on RP2 from Ra, the MSDP RPF check for 1.1.1.1 passes because RP2 receives the SA update from MSDP peer 2.2.2.2, which is also the correct MBGP next hop for 1.1.1.1.
ここで、RP2 MSDPおよびMBGPピア（2.2.2.2を使用）およびRB（3.3.3.3を使用）を使用します。RP2がRP2からRP2に到着すると、RP2がMSDP PEER 2.2.2.2からSAアップデートを受信するため、MSDP RPF Checkは1.1.1.1をパスします。
When RP2 receives the same SA update from MSDP peer 3.3.3.3, the MBGP lookup for 1.1.1.1 shows a next hop of 2.2.2.2, so RPF correctly fails, preventing a loop.
RP2がMSDPピア3.3.3.3から同じSAアップデートを受信すると、1.1.1.1のMBGP検索が2.2.2.2の次のホップを示しているため、RPFは正しく障害を発揮し、ループを防ぎます。
This deployment could also fail on an update from Ra to RP2 if RP2 was MBGP peering to an address other than 2.2.2.2 on Ra. Intra-domain deployments must have MSDP and MBGP (or other IGP) peering addresses that match, unless a method to skip the peer-RPF check is deployed.
RP2がRAの2.2.2.2以外のアドレスにMBGPを覗き込んでいた場合、この展開はRAからRP2への更新でも失敗する可能性があります。ドメイン内の展開には、PEER-RPFチェックをスキップする方法が展開されない限り、一致するMSDPおよびMBGP（または他のIGP）のピアリングアドレスが必要です。
This is a common MSDP intra-domain deployment in environments where few routers are running MBGP or where the domain is not running MBGP. The problem here is that the MSDP peer address needs to be the same as the MBGP peer address. To get around this requirement, the intra-domain MSDP RPF rules have been relaxed in the following topologies: o By configuring the MSDP peer as a mesh group peer.
これは、MBGPを実行しているルーターがほとんどない環境、またはドメインがMBGPを実行していない環境での一般的なMSDP展開です。ここでの問題は、MSDPピアアドレスがMBGPピアアドレスと同じである必要があることです。この要件を回避するために、ドメイン内のMSDP RPFルールは、次のトポロジーで緩和されています。OMSDPピアをメッシュグループピアとして構成することにより。
o By having the MSDP peer be the only MSDP peer.
o MSDPピアを唯一のMSDPピアにすることにより。
o By configuring a default MSDP peer.
o デフォルトのMSDPピアを構成します。
o By peering with the originating RP.
o 起源のRPを覗くことによって。
o By relying upon an IGP for MSDP peer-RPF.
o MSDP PEER-RPFのIGPに依存することにより。
The common choice around the intra-domain BGP peering requirement, when more than one MSDP peer is configured, is to deploy MSDP mesh groups. When an MSDP mesh group is deployed, there is no RPF check on arriving SA messages when they are received from a mesh group peer. Subsequently, SA messages are always accepted from mesh group peers. MSDP mesh groups were developed to reduce the amount of SA traffic in the network since SAs, which arrive from a mesh group peer, are not flooded to peers within that same mesh group. Mesh groups must be fully meshed.
複数のMSDPピアが構成されている場合、ドメイン内BGPピアリング要件をめぐる一般的な選択は、MSDPメッシュグループを展開することです。MSDPメッシュグループが展開されると、メッシュグループのピアから受信されたときにSAメッセージの到着に関するRPFチェックはありません。その後、SAメッセージは常にメッシュグループのピアから受け入れられます。MSDPメッシュグループは、メッシュグループピアから到着するSASが同じメッシュグループ内のピアに浸水しないため、ネットワーク内のSAトラフィックの量を減らすために開発されました。メッシュグループは完全にメッシュ化する必要があります。
If recent (but not currently widely deployed) router code is running that is fully compliant with the latest MSDP document, another option, to work around not having BGP to MSDP RPF peer, is to RPF using an IGP like OSPF, IS-IS, RIP, etc. This new capability will allow for enterprise customers, who are not running BGP and who don't want to run mesh groups, to use their existing IGP to satisfy the MSDP peer-RPF rules.
最近の（現在広く展開されていない）ルーターコードが実行されている場合、最新のMSDPドキュメントである別のオプションに完全に準拠している場合、MSDP RPFピアからBGPを持たないことを回避することは、OSPFなどのIGPを使用してRPFを使用することです。RIPなど。この新しい機能により、BGPを実行しておらず、メッシュグループを実行したくないエンタープライズ顧客が既存のIGPを使用してMSDP Peer-RPFルールを満たすことができます。
Hierarchical mesh groups are occasionally deployed in intra-domain environments where there are a large number of MSDP peers. Allowing multiple mesh groups to forward to one another can reduce the number of MSDP peerings per router (due to the full mesh requirement) and hence reduce router load. A good hierarchical mesh group implementation (one that prevents looping) contains a core mesh group in the backbone, and these core routers serve as mesh group aggregation routers:
階層メッシュグループは、多数のMSDPピアがあるドメイン内環境に展開されることがあります。複数のメッシュグループが互いに転送できるようにすることで、ルーターごとのMSDPピーリングの数を減らすことができます（メッシュ要件全体のため）。優れた階層メッシュグループの実装（ループを防ぐ）には、バックボーンにコアメッシュグループが含まれており、これらのコアルーターはメッシュグループ集約ルーターとして機能します。
[R2]{A,2}
/ \
/ \
/ \
/ \
/ \
/ \
/ \
{A,1}[R1]-------------[R3]{A,3}
In this example, R1, R2, and R3 are in MSDP mesh group A (the core mesh group), and each serves as MSDP aggregation routers for their leaf (or second tier) mesh groups 1, 2, and 3. Since SA messages received from a mesh group peer are not forwarded to peers within that same mesh group, SA messages will not loop. Do not create topologies that connect mesh groups in a loop. In the above example, for instance, second-tier mesh groups 1, 2, and 3 must not directly exchange SA messages with each other or an endless SA loop will occur.
Redundancy between mesh groups will also cause a loop and is subsequently not available with hierarchical mesh groups. For instance, assume that R3 had two routers connecting its leaf mesh group 3 with the core mesh group A. A loop would be created between mesh group 3 and mesh group A because each mesh group must be fully meshed between peers.
メッシュグループ間の冗長性もループを引き起こし、その後、階層メッシュグループでは使用できません。たとえば、R3には、各メッシュグループがピア間で完全にメッシュ化される必要があるため、メッシュグループ3とメッシュグループAの間にループが作成されます。
BGP requires all iBGP speakers that are not route-reflector clients or confederation members be fully meshed to prevent loops. In the route reflector environment, MSDP requires that the route reflector clients peer with the route reflector since the router reflector (RR) is the BGP announcer of the next hop towards the originating RP. The RR is not the BGP next hop, but is the announcer of the BGP next hop. The announcer of the next hop is the address typically used for MSDP peer-RPF checks. For example, consider the following case:
BGPには、ルートリフレクターのクライアントではないすべてのIBGPスピーカーまたは連合メンバーがループを防ぐために完全にメッシュ化される必要があります。ルートリフレクター環境では、MSDPはルーターリフレクター（RR）が発生するRPに向けた次のホップのBGPアナウンサーであるため、ルートリフレクタークライアントがルートリフレクターとピアをピアでピアすることを要求しています。RRはBGPの次のホップではありませんが、BGP Next Hopのアナウンサーです。次のホップのアナウンサーは、通常MSDP PEER-RPFチェックに使用されるアドレスです。たとえば、次のケースを検討してください。
Ra--------RR
/|\
/ | \
A B C
Ra is forwarding MSDP SAs to the route reflector RR. Routers A, B, and C also MSDP peer with RR. When RR forwards the SA to A, B, and C, these RR clients will accept the SA because RR is the announcer of the next hop to the originating RP address.
RAはMSDP SASをルートリフレクターRRに転送しています。ルーターA、B、およびCもRRを備えたMSDPピアです。RRがSAをA、B、およびCに転送すると、RRが発信されるRPアドレスの次のホップのアナウンサーであるため、これらのRRクライアントはSAを受け入れます。
An SA will peer-RPF fail if Ra MSDP peers directly with Routers A, B, or C because the announcer of the next hop is RR but the SA update came from Ra. Proper deployment is to have RR clients MSDP peer with the RR. MSDP mesh groups may be used to work around this requirement. External MSDP peerings will also prevent this requirement since the next AS is compared between MBGP and MSDP peerings, rather than the IP address of the announcer of the next hop.
次のホップのアナウンサーはRRであるが、SAアップデートはRAから来たため、RA MSDPがルーターA、B、またはCで直接ピアを使用すると、SAはRPFが失敗します。適切な展開とは、RRクライアントMSDPピアをRRと一緒にすることです。MSDPメッシュグループは、この要件を回避するために使用できます。また、外部MSDPピーリングは、次のホップのアナウンサーのIPアドレスではなく、MBGPとMSDPピーリングの間で比較される次の要件以降のこの要件を防ぎます。
Some recent MSDP implementations conform to the latest MSDP document, which relaxes the requirement of peering with the Advertiser of the next hop (the Route Reflector). This new rule allows for peering with the next hop, in addition to the Advertiser of the next hop. In the example above, for instance, if Ra is the next hop (perhaps due to using BGP's next hop self attribute), and if routers A, B, and C are peering with Ra, the SA's received from Ra will now succeed.
いくつかの最近のMSDP実装は、次のホップ（ルートリフレクター）の広告主との覗き込みの要件を緩和する最新のMSDPドキュメントに準拠しています。この新しいルールは、次のホップの広告主に加えて、次のホップで覗くことができます。上記の例では、たとえば、RAが次のホップである場合（おそらくBGPの次のホップセルフ属性を使用したため）、ルーターA、B、およびCがRAで覗き込んでいる場合、RAから受け取ったSAは成功します。
A network with multiple RPs can achieve RP load sharing and redundancy by using the Anycast RP mechanism in conjunction with MSDP mesh groups [RFC3446]. This mechanism is a common deployment technique used within a domain by service providers and enterprises that deploy several RPs within their domains. These RPs will each have the same IP address configured on a Loopback interface (making this the Anycast address). These RPs will MSDP peer with each other using a separate loopback interface and are part of the same fully meshed MSDP mesh group. This loopback interface, used for MSDP peering, will typically also be used for the MBGP peering. All routers within the provider's domain will learn of the Anycast RP address through Auto-RP, BSR, or a static RP assignment. Each designated router in the domain will send source registers and group joins to the Anycast RP address. Unicast routing will direct those registers and joins to the nearest Anycast RP. If a particular Anycast RP router fails, unicast routing will direct subsequent registers and joins to the nearest Anycast RP. That RP will then forward an MSDP update to all peers within the Anycast MSDP mesh group. Each RP will then forward (or receive) the SAs to (from) external customers and providers.
複数のRPを備えたネットワークは、MSDPメッシュグループ[RFC3446]と組み合わせてAnycast RPメカニズムを使用することにより、RPの負荷共有と冗長性を実現できます。このメカニズムは、ドメイン内に複数のRPを展開するサービスプロバイダーおよび企業によってドメイン内で使用される一般的な展開手法です。これらのRPSには、それぞれループバックインターフェイスで構成された同じIPアドレスがあります（これをAnycastアドレスにします）。これらのRPSは、個別のループバックインターフェイスを使用して互いにMSDPピアを継承し、同じ完全にメッシュ化されたMSDPメッシュグループの一部です。MSDPピアリングに使用されるこのループバックインターフェイスは、通常、MBGPピアリングにも使用されます。プロバイダーのドメイン内のすべてのルーターは、Auto-RP、BSR、または静的RP割り当てを介してAnycast RPアドレスを学習します。ドメイン内の指定された各ルーターは、ソースレジスタを送信し、グループ結合はAnycast RPアドレスに結合します。ユニキャストルーティングは、これらのレジスタを指示し、最寄りのAnycast RPに結合します。特定のAnycast RPルーターが失敗した場合、ユニキャストルーティングは後続のレジスタを導き、最寄りのAnycast RPに結合します。そのRPは、MSDPアップデートをAnyCast MSDP Meshグループ内のすべてのピアに転送します。各RPは、SASを外部の顧客とプロバイダーに（または）転送（または受信）します。
An MSDP service should be secured by explicitly controlling the state that is created by, and passed within, the MSDP service. As with unicast routing state, MSDP state should be controlled locally, at the edge origination points. Selective filtering at the multicast service edge helps ensure that only intended sources result in SA message creation, and this control helps to reduce the likelihood of state-aggregation related problems in the core. There are a variety of points where local policy should be applied to the MSDP service.
MSDPサービスは、MSDPサービスによって作成され、内部で渡される状態を明示的に制御することにより、MSDPサービスを保護する必要があります。ユニキャストルーティング状態と同様に、MSDP状態は、エッジオリジネーションポイントでローカルで制御する必要があります。マルチキャストサービスエッジでの選択的フィルタリングは、意図されたソースのみがSAメッセージの作成をもたらすことを保証するのに役立ち、この制御はコアの状態凝集関連の問題の可能性を減らすのに役立ちます。MSDPサービスにローカルポリシーを適用する必要があるさまざまなポイントがあります。
The process of originating SA messages should be filtered to ensure that only intended local sources are resulting in SA message origination. In addition, MSDP speakers should filter which SA messages get received and forwarded.
SAメッセージの発信プロセスをフィルタリングして、意図したローカルソースのみがSAメッセージの発信をもたらすことを確認する必要があります。さらに、MSDPスピーカーは、どのSAメッセージが受信され、転送されるかをフィルタリングする必要があります。
Typically, there is a fair amount of (S,G) state in a PIM-SM domain that is local to the domain. However, without proper filtering, SA messages containing these local (S,G) announcements may be advertised to the global MSDP infrastructure. Examples of this include domain-local applications that use global IP multicast addresses and sources that use RFC 1918 addresses [RFC1918]. To improve on the scalability of MSDP and to avoid global visibility of domain local (S,G) information, an external SA filter list is recommended to help prevent unnecessary creation, forwarding, and caching of well-known domain local sources.
通常、ドメインに局所的なPIM-SMドメインには、かなりの量の（s、g）状態があります。ただし、適切なフィルタリングがなければ、これらのローカル（s、g）の発表を含むSAメッセージは、グローバルMSDPインフラストラクチャに宣伝される場合があります。この例には、グローバルIPマルチキャストアドレスとRFC 1918アドレスを使用するソース[RFC1918]を使用するドメインローカルアプリケーションが含まれます。MSDPのスケーラビリティを改善し、ドメインローカル（S、G）情報のグローバルな可視性を回避するために、不必要な作成、転送、およびよく知られているドメインローカルソースのキャッシュを防ぐのに役立つ外部SAフィルターリストが推奨されます。
Proper filtering on SA message origination, receipt, and forwarding will significantly reduce the likelihood of unintended and unexpected spikes in MSDP state. However, an SA-cache state limit SHOULD be configured as a final safeguard to state spikes. When an MSDP peering has reached a stable state (i.e., when the peering has been established and the initial SA state has been transferred), it may also be desirable to configure a rate limiter for the creation of new SA state entries.
SAメッセージの発信、領収書、および転送の適切なフィルタリングは、MSDP状態の意図的で予期しないスパイクの可能性を大幅に減らします。ただし、SAキャッシュ状態の制限は、スパイクの最終的なセーフガードとして構成する必要があります。MSDPピアリングが安定した状態に達したとき（つまり、ピアリングが確立され、最初のSA状態が転送されたとき）、新しいSA状態エントリを作成するためのレートリミッターを構成することも望ましい場合があります。
The authors would like to thank Pekka Savola, John Zwiebel, Swapna Yelamanchi, Greg Shepherd, and Jay Ford for their feedback on earlier versions of this document.
著者は、この文書の以前のバージョンに関するフィードバックについて、ペッカ・サヴォラ、ジョン・ズウィエベル、スワプナ・イェラマンチ、グレッグ・シェパード、ジェイ・フォードに感謝したいと思います。
[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月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、De Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[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月。
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[RFC2858] Bates、T.、Rekhter、Y.、Chandra、R。、およびD. Katz、「BGP-4のマルチプロトコル拡張」、RFC 2858、2000年6月。
[RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)", RFC 3446, January 2003.
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618] Fenner、B。およびD. Meyer、「マルチキャストソースディスカバリープロトコル（MSDP）」、RFC 3618、2003年10月。
[BSR] Fenner, W., et. al., "Bootstrap Router (BSR) Mechanism for PIM Sparse Mode", Work in Progress, February 2003.
[BSR] Fenner、W.、et。al。、「PIMスパースモードのブートストラップルーター（BSR）メカニズム」、2003年2月、進行中の作業。
[RFCED] http://www.rfc-editor.org/policy.html
[rfced] http://www.rfc-editor.org/policy.html
Authors' Addresses
著者のアドレス
Mike McBride Cisco Systems
マイクマクブライドシスコシステム
EMail: mcbride@cisco.com
John Meylor Cisco Systems
John Meylor Cisco Systems
EMail: jmeylor@cisco.com
David Meyer
デビッド・マイヤー
EMail: dmm@1-4-5.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。