RFC4611 日本語訳
4611 Multicast Source Discovery Protocol (MSDP) Deployment Scenarios.M. McBride, J. Meylor, D. Meyer. August 2006. (Format: TXT=33230 bytes) (Also BCP0121) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. McBride Request for Comments: 4611 J. Meylor BCP: 121 D. Meyer Category: Best Current Practice August 2006
コメントを求めるワーキンググループM.マックブライドの要求をネットワークでつないでください: 4611J.Meylor BCP: 121D.マイヤーカテゴリ: 最も良い現在の練習2006年8月
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.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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).
このドキュメントはMulticast Sourceディスカバリープロトコル(MSDP)のイントラドメインと相互ドメイン展開のためにプロトコル無党派Multicast Sparse Mode(PIM-SM)に関連して最も良い現在の実務について説明します。
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
1. 序論…2 1.1. BCP、実験プロトコル、および引用規格…3 2. 相互ドメインMSDPじっと見るシナリオ…4 2.1. PIM境界ルータの間をじっと見ます…4 2.2. 非境界ルータの間をじっと見ます…5 2.3. BGPなしでじっと見るMSDP…7 2.4. マルチキャスト交換をじっと見るMSDP…7 3. イントラドメインMSDPじっと見るシナリオ…7 3.1. MSDPとMBGPによって構成されたルータの間をじっと見ます…8 3.2. MSDP同輩はBGP同輩(または、BGP同輩がない)ではありません…8 3.3. 階層的なメッシュは分類されます…9 3.4. MSDPとルート反射鏡…10 3.5. MSDPとAnycast RPs…11 4. セキュリティ問題…11 4.1. SAメッセージをフィルターにかけます…11 4.2. SAメッセージ州の限界…12 5. 承認…12 6. 参照…12 6.1. 標準の参照…12 6.2. 有益な参照…13
McBride, et al. Best Current Practice [Page 1] RFC 4611 MSDP Deployment Scenarios August 2006
マックブライド、他 最も良い現在の練習[1ページ]RFC4611MSDP展開シナリオ2006年8月
1. Introduction
1. 序論
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.
他のドメインに手があいている活発なソースの周りで情報を伝達するのにプロトコル無党派Multicast Sparse Mode(PIM-SM)[RFC4601]ドメインの間でMSDPを使用できます。 そのような場合使用されるMSDPのじっと見るのは、一般に、1〜1にじっと見ていて、MSDP仕様で説明された決定論的な同輩-RPF(Path Forwardingを逆にする)規則を利用します(すなわち、それはメッシュグループを使用しません)。 独身のMSDP同輩の上でPeeringsを集めることができます。 そのような同輩は通常1〜何百peeringsまでそうしたはずです。(peeringsはスケールにおいてBGP peeringsと同様です)。
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.
それぞれのAnycast-RP同輩(IGPの可到達性による)によって勤められながら、MSDPは活発なソースの情報を同期させるのにPIMドメインの中のAnycast Rendezvous Points(Anycast-RPs)[RFC3446]の間でしばしば使用されます。 このシナリオで使用されるMSDPのじっと見ることはMSDPメッシュグループに通常基づいています、10以上が典型的ではありませんが。(どこでも、そこでは、2〜10人の同輩が、与えられたメッシュグループを包括できます)。 また、これらのメッシュグループの同輩のより多くのひとりに、追加1〜1peeringsが外部電源の発見のためのそのPIMドメインの外のMSDP同輩と共にいるかもしれません。 外部の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展開のための現在の最も良い習慣はPIM-SMとマルチプロトコル拡大(MBGP)[RFC4271、RFC2858]を伴うボーダ・ゲイトウェイ・プロトコルを利用します。 このドキュメントはこれらのプロトコルがイントラドメインと相互ドメインAny Source Multicast(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.
トランジットIPプロバイダーは、MSDPを使用することでそれらの上流と同輩マルチキャストネットワークに接続するのによるグローバルなマルチキャストインフラストラクチャの一部になるようにMSDPを通常配備します。
McBride, et al. Best Current Practice [Page 2] RFC 4611 MSDP Deployment Scenarios August 2006
マックブライド、他 最も良い現在の練習[2ページ]RFC4611MSDP展開シナリオ2006年8月
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.
縁のマルチキャストネットワークには、2つの選択が通常あります: MSDPを使用することでそれらのプロバイダのRPを使用するか、それら自身のRPを持って、またはそれらのISPにそれを関連づけるために。 それら自身のRPとMSDPを配備することによって、彼らはプロバイダーのRPに目に見えない内部のマルチキャストグループを使用できます。 これが、プロバイダーへの接続性に関する問題がある場合内部のマルチキャストが、働き続けることができるのを助けるか、またはプロバイダーのRP/MSDPは苦境に陥っています。 最も簡単な場合には、MSDPを配備する必要は全くしばしばあるというわけではありません。そこでは、内部のマルチキャストグループがないのが必要です。
1.1. BCP, Experimental Protocols, and Normative References
1.1. BCP、実験プロトコル、および引用規格
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、このドキュメントは広く配備されたExperimentalプロトコルのために最も良い現在の習慣について説明します。 MSDPの状態(例えばProposed Standardに)を進める計画が全くありません。 この理由は:
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がExperimentalとして分類させられた第一の理由の1つは作業部会がWGが考えたプロトコルへの変更と共に来させたMSDPがそれをより良くしましたが、作成者が展開する理由が全くわからなかったということでした。 これらの変更(例えば、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を作りなおすのに関して達することができませんでした。 その結果、(遍在して)配備されることを記録して、そのドキュメントをExperimentalに動かすために決定を取りました。 Proposed Standardへの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のための交換プロトコルが必要であるというコンセンサスをさらに、減少させました。
McBride, et al. Best Current Practice [Page 3] RFC 4611 MSDP Deployment Scenarios August 2006
マックブライド、他 最も良い現在の練習[3ページ]RFC4611MSDP展開シナリオ2006年8月
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 Editorの方針はそれらが「標準」で「有益である」として知られている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には、Experimentalプロトコルの引用規格があってはいけません。 しかしながら、基本的なExperimentalドキュメント(MSDP)がProposed Standardに進められるために計画されていないので、このドキュメントは特別なケースです。
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作業部会はRFC2026[RFC2026]に記録されるようにVariance Procedureの下で承認を要求しました。 IESGは4週間の追加IETF Last Callの後にVariance Procedureに続いて、コメントと状態を評価して、このドキュメントを承認しました。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Inter-domain MSDP Peering Scenarios
2. 相互ドメインMSDPじっと見るシナリオ
The following sections describe the most common inter-domain MSDP peering possibilities and their deployment options.
以下のセクションは最も一般的な相互ドメインMSDPじっと見ることの可能性と彼らの展開オプションについて説明します。
2.1. Peering between PIM Border Routers
2.1. PIM境界ルータの間をじっと見ます。
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を位置させています。 さらに、ドメインには、それ自身のAutonomous System(AS)番号と1人以上のMBGPスピーカーが通常いるでしょう。 また、ドメインには、複数のMSDPスピーカーがいるかもしれません。 各境界ルータで、MSDPとMBGPは同輩ルータでじっと見ます。 これらの外部のMSDPじっと見る展開は、MBGPのじっと見るのと同じくらい使用することでじっと見るMSDPが直接同じルータからの次のホップ同輩IPアドレスか他のIPアドレスを接続したのを通常構成します。 このタイプの典型的な展開は、他のプロバイダーと共にダイレクトじっと見ることを持っているプロバイダー、交換をじっと見るプロバイダー、または顧客と共にそれらの縁のルータを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:
ダイレクトじっと見ている相互ドメイン環境がうまくいっているために、由来しているRPへのMBGPの最も良い経路における最初のASはMSDPのASがじっと見るのと同じであるべきです。 例と、以下のトポロジーを考えてください:
McBride, et al. Best Current Practice [Page 4] RFC 4611 MSDP Deployment Scenarios August 2006
マックブライド、他 最も良い現在の練習[4ページ]RFC4611MSDP展開シナリオ2006年8月
AS1----AS2----AS4
| /
| /
| /
AS3
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によって溯源されたSource Active(SA)メッセージを受け取ります。 また、AS2はMBGPにAS4と共にじっと見させます。 由来しているRPへの最も良い経路では、AS4からのMBGP最初のホップASはAS2です。 また、送付MSDP同輩のASはAS2です。 この場合、同輩逆Path Forwardingチェック(同輩-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.
MBGP最初のホップASが由来しているRPへの最も良い経路のAS2であり、送付MSDP同輩の起源ASがAS3であるときに、同輩-RPFの故障はこのトポロジーに起こるでしょう。 BGP AS PATH情報へのこの信用はSAパケットの無限のループを防ぎます。
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の間で規制を緩和するでしょう。 私たちがMSDPにAS1<->の間を以下のトポロジーでは、じっと見させる、AS3とAS3<->、AS4:
RP
AS1----AS2----AS3----AS4
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への最も良い経路における最初のASがMSDP同輩と等しくないなら、MSDP同輩-RPFは失敗します。 したがって、AS1はそうすることができません。MSDPはAS3と共にじっと見ます、AS2がAS4 RPへのMBGPの最も良い経路で最初のASであるので。 最新のMSDPと共に、対応するコードを記録してください、とAS1は最も良いAS経路に沿った最も近いASでRPに同輩を選ぶでしょう。 そして、AS1は、SAがAS3から来ると受け入れるでしょう。 ルータへの複数のMSDP同輩が同じASの中にいれば、RPFがじっと見るとき、最も高いIPアドレスをもっている同輩は選ばれています。
2.2. Peering between Non-Border Routers
2.2. 非境界ルータの間をじっと見ます。
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に関しては、また、内部的に彼らの境界ルータに向かってMBGPとMSDP peeringsを維持するのが必要であるので、イントラドメインMSDPスケーラビリティは制限されます。 イントラドメインの中では、境界ルータは次のホップのアナウンサーに由来しているRPに向かってなります。 これは、イントラドメインMSDP peeringsがすべて、境界ルータに向かってMBGP経路を反映して戻すのを必要とします。 外部のMSDP(eMSDP)peeringsは同輩RPFの照合のためにAS経路を当てにされます、内部のMSDP(iMSDP)peeringsが次のホップのアナウンサーを当てにされますが。
McBride, et al. Best Current Practice [Page 5] RFC 4611 MSDP Deployment Scenarios August 2006
マックブライド、他 最も良い現在の練習[5ページ]RFC4611MSDP展開シナリオ2006年8月
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
eMBGP同輩は境界ルータの間で直接通常接されますが、eMSDP同輩がトランジットプロバイダーのASにより深く見つけられるのは、一般的です。 プロバイダー(MSDPじっと見るプレースメントにおける、より多くの柔軟性を望んでいる)は一般的に相互ドメインMSDP peeringsへのそれらのコアネットワークの中のいくつかのひたむきなルータを彼らの顧客に選びます。 これらのコアMSDPルータは、また、プロバイダーのイントラドメインMSDPメッシュグループには通常あって、Anycast RPのために構成されるでしょう。 プロバイダーのASのすべてのマルチキャストルータが静的にAnycast RPアドレスを示すべきです。 静的なRP課題は決定論的な本質によるグループからRPへのマッピングのための最も一般的に使用された方法です。 また、プロバイダーのネットワークの中でRP情報を広めるのに自動RP[RFC4601]、そして/または、メカニズムを写像するBootstrap Router(BSR)[BSR]のダイナミックな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.
これで受け入れられた(マルチホップのじっと見る)環境、私たちが次と、(最新のMSDP仕様について最も近い)を当てにするということであるSAメッセージがないかどうか、RPFのための由来しているRPに向かった最も良い経路のASはチェックします。 MSDP同輩アドレスが境界ルータのMBGP同輩のASと同じASにあるべきです。 MBGPを通してMSDP同輩アドレスの広告を出すべきです。
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.
例えば、以下のダイヤグラムには、R2とR3が顧客R1ルータがR2ルータでじっと見るMBGPであり、R1がR3ルータでじっと見るMSDPであるなら同じAS(または、個人的なAS番号が配備される場合同じASからあるようにAS1において現れなければならない)にあるに違いありません。 MSDP RPFがじっと見るとき、最も高いIPアドレスをもっているMSDP同輩は選ばれるでしょう。 また、R1はMBGPテーブルにR3のMSDP同輩アドレスを持たなければなりません。
+--+ +--+ +--+
|R1|----|R2|----|R3|
+--+ +--+ +--+
AS1 AS2 AS2
+--+ +--+ +--+ |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.
AS1(R1)はR3の見解からの、MBGPです。由来しているRPに向かった最も良い経路の次のAS。 AS1が由来しているRPに向かった最も良い経路の次のAS(最も近い)である限り、RPFは、R1から到着しながら、SAsで成功するでしょう。
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.
対照的に、ただ一つのホップシナリオ、R2(R3の代わりに)と共に、R1と共にじっと見る境界MSDPが接しています、そして、R2のMBGPアドレスはR3のための次のホップのアナウンサーに由来しているRPに向かってなります、そして、R3はそのR2アドレスでじっと見なければなりません。 そのうえ、AS2イントラドメインMSDP同輩は皆、iMSDPが次のホップのMBGP(または、他のIGP)アナウンサーのアドレスでじっと見るのに依存を持っているのでiMBGP(または、他のIGP)peeringsにR2に向かって続く必要があります。
McBride, et al. Best Current Practice [Page 6] RFC 4611 MSDP Deployment Scenarios August 2006
マックブライド、他 最も良い現在の練習[6ページ]RFC4611MSDP展開シナリオ2006年8月
2.3. MSDP Peering without BGP
2.3. BGPなしでじっと見るMSDP
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経路情報を当てにします。 しかしながら、BGPなしでMSDPを配備できます、そして、その結果、いくつかの特別なケースがBGP経路情報に同輩-RPFチェックを実行するという要件が吊しているところにあります。 これらのケースは以下の通りです。
o There is only a single MSDP peer connection.
o 単独のMSDP同輩接続しかありません。
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同輩-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 peeringsが企業の中で使用されると、MSDPデフォルト同輩は、プロバイダーを示す境界ルータで構成される必要があるでしょう。 このように、すべての外部のマルチキャストソースについて学習するでしょう、そして、内部のソースの広告を出すことができます。 唯一の単一のMSDPのじっと見るのがプロバイダー、このスタッブサイトがそうするその時に向かって中古(内部のMSDP peeringsがない)のMSDPデフォルトであったなら、プロバイダーに向かってじっと見てください、そして、同輩-RPFチェックをサボってください。
2.4. MSDP Peering at a Multicast Exchange
2.4. マルチキャスト交換をじっと見るMSDP
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アップデートを共有します。 他のものが直接接続したそれぞれをもっている各プロバイダー意志のMSDPとMBGP同輩はIPアドレスを交換します。 それぞれの交換ルータは、彼らのMSDP同輩からの/にSAsを送るか、または受けるでしょう。 彼らはその時、彼らの顧客とどんなダイレクトプロバイダーpeeringsへの自分達のドメインにもSAsを送ることができるでしょう。
3. Intra-domain MSDP Peering Scenarios
3. イントラドメインMSDPじっと見るシナリオ
The following sections describe the different intra-domain MSDP peering possibilities and their deployment options.
以下のセクションは異なったイントラドメインMSDPじっと見ることの可能性と彼らの展開オプションについて説明します。
McBride, et al. Best Current Practice [Page 7] RFC 4611 MSDP Deployment Scenarios August 2006
マックブライド、他 最も良い現在の練習[7ページ]RFC4611MSDP展開シナリオ2006年8月
3.1. Peering between MSDP- and MBGP-Configured Routers
3.1. MSDPとMBGPによって構成されたルータの間をじっと見ます。
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:
iBGP同輩の次のホップIPアドレスはMSDP同輩-RPFチェックに通常使用されます(また、IGPを使用できます)。 これは相互ドメインBGP/MSDPケースと異なっています。そこでは、AS経路情報が同輩-RPFチェックに使用されます。 この理由で、MSDP同輩接続がMSDP/MBGP同輩が直接接されるか否かに関係なく、内部のMBGP同輩接続と同じでありにIPアドレスに必要です。 うまくいっている展開は以下と同様でしょう:
+----+
| Rb | 3.3.3.3
/ +----+
AS1 AS2 / |
+---+ +--+ / |
|RP1|---------|Ra| |
+---+ +--+ |
1.1.1.1 2.2.2.2 |
\ |
\ |
\ +-----+
| RP2 |
+-----+
+----+ | 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.
RaをもっているどこRP2 MSDPとMBGP同輩、(使用、2.2、.2、.2、)、Rb、(使用、3.3、.3、.3、) MSDP SAアップデートがRP2でRaから到着すると、RP2がMSDP同輩からSAアップデートを受けるのでMSDP RPFが1.1個の.1.1パスがないかどうかチェックする、2.2、.2、.2、また、どれが正しいMBGP次であるかは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.
.1は2.2の次のホップを見せています。RP2がMSDPから同じSAアップデートを受けたらじっと見てください、3.3、.3、.3、1.1のためのMBGPルックアップ、.1、.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が2.2以外のアドレスとしてじっと見るMBGPであるならRaからRP2までのアップデートのときに失敗できるでしょうに。.2 .2 Raで。 イントラドメイン展開にはMSDPがなければなりません、そして、MBGP(または、他のIGP)のじっと見るのはそのマッチを記述します、同輩-RPFチェックをサボる方法が配備されない場合。
3.2. MSDP Peer Is Not BGP Peer (or No BGP Peer)
3.2. MSDP同輩はBGP同輩ではありません。(または、BGP同輩がありません)
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:
これはわずかなルータがMBGPを走ることにさせるのであるか、またはドメインがMBGPを走らないことにさせるのである環境で一般的なMSDPイントラドメイン展開です。 MSDP同輩アドレスが、MBGP同輩アドレスと同じである必要があるという問題がここにあります。 この要件を逃れるために、イントラドメインMSDP RPF規則は以下のtopologiesでリラックスしました:
McBride, et al. Best Current Practice [Page 8] RFC 4611 MSDP Deployment Scenarios August 2006
マックブライド、他 最も良い現在の練習[8ページ]RFC4611MSDP展開シナリオ2006年8月
o By configuring the MSDP peer as a mesh group peer.
o MSDPを構成することによって、メッシュグループがじっと見るとき、じっと見てください。
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同輩-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.
イントラドメインBGPじっと見る要件の周りの一般的な選択は1人以上のMSDP同輩が構成されるとき、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.
RPFにはMSDP RPFへのBGPにじっと見させない周りの仕事への別のオプションが最近の、そして、(現在、広く配備されていません)のルータコードが最新のMSDPドキュメントで完全に言いなりになっている走行であるなら、OSPFのようなIGPを使用することである、-、RIPなど この新しい能力は、法人顧客がMSDP同輩-RPF規則を満たすのにそれらの既存のIGPを使用するのを許容するでしょう。(それはBGPを述べていなくて、それはメッシュグループを経営したがっていません)。
3.3. Hierarchical Mesh Groups
3.3. 階層的なメッシュグループ
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 peeringsの数が減少して、したがって、ルータ負荷は減少できます。 良い階層的なメッシュグループ実現(輪にするのを防ぐもの)は背骨のコアメッシュグループを含みます、そして、これらのコアルータはメッシュグループ集合ルータとして機能します:
[R2]{A,2}
/ \
/ \
/ \
/ \
/ \
/ \
/ \
{A,1}[R1]-------------[R3]{A,3}
A、[R2]2、/\/\/\/\/\/\/\、A、1[R1]-------------[R3]A、3
McBride, et al. Best Current Practice [Page 9] RFC 4611 MSDP Deployment Scenarios August 2006
マックブライド、他 最も良い現在の練習[9ページ]RFC4611MSDP展開シナリオ2006年8月
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.
この例、R1、R2、およびR3に、メッシュグループA(コアメッシュグループ)がMSDPにあります、そして、彼らの葉(または、2番目の層)のためのMSDP集合ルータがグループ1、2、および3を網の目にかけるとき、それぞれが役立ちます。 メッシュグループの同輩から受け取られたSAメッセージがその同じメッシュグループの中で同輩に転送されないので、SAメッセージは輪にされないでしょう。 輪のメッシュグループを接続するtopologiesを作成しないでください。 例えば、上記の例では、2番目の層のメッシュグループ1、2、および3が直接SAメッセージを互いと交換してはいけない、さもなければ、無限のSA輪は現れるでしょう。
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に接続する2つのルータがあったと仮定してください。輪は、同輩の間でそれぞれのメッシュグループを完全に網の目にかけなければならないので、メッシュグループ3とメッシュグループAの間で作成されるでしょう。
3.4. MSDP and Route Reflectors
3.4. MSDPとルート反射鏡
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のアナウンサーは次のホップですか? 次のホップのアナウンサーはMSDP同輩-RPFチェックに通常使用されるアドレスです。 例えば、以下のケースを考えてください:
Ra--------RR
/|\
/ | \
A B C
Ra--------RR/|\ / | \は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はルート反射鏡RRにMSDP SAsを送っています。 ルータのA、B、およびC MSDPもRRと共にじっと見ます。 RRがA、B、およびCにSAを送るとき、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から来たので、意志の同輩-RPFがRa MSDPであるなら失敗するSAは直接Routers A、B、またはCと共にじっと見ます。 適切な展開はRRクライアントMSDPにRRと共にじっと見させることです。 MSDPメッシュグループは、この要件の周りで働くのに使用されるかもしれません。 また、次のASが次のホップのアナウンサーのIPアドレスよりむしろMBGPとMSDP peeringsの間で比べるので、外部のMSDP peeringsはこの要件を防ぐでしょう。
McBride, et al. Best Current Practice [Page 10] RFC 4611 MSDP Deployment Scenarios August 2006
マックブライド、他 最も良い現在の練習[10ページ]RFC4611MSDP展開シナリオ2006年8月
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ドキュメントに従います。(それは、次のホップ(Route Reflector)のAdvertiserと共にじっと見る要件を弛緩します)。 この新しい規則は、次のホップで次のホップのAdvertiserに加えてじっと見ると考慮します。 Raが次のホップ(恐らくBGPの次のホップ自己属性を使用するのによる)であり、ルータA、B、およびCがRaと共にじっと見ていると、上に、例えば、例に、受け取られたSAのものは現在、Raから成功するでしょう。
3.5. MSDP and Anycast RPs
3.5. MSDPとAnycast RPs
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.
複数のRPsとのネットワークは、MSDPメッシュグループ[RFC3446]に関連してAnycast RPメカニズムを使用することによって、RP負荷分割法と冗長を実現できます。 このメカニズムはドメインの中で彼らのドメインの中の数個のRPsを配備するサービスプロバイダーと企業によって使用された一般的な展開のテクニックです。 これらのRPsはLoopbackインタフェースで同じIPアドレスをそれぞれ構成させるでしょう(これをAnycastアドレスにして)。 これらのRPsは互いをもっているMSDP同輩が別々のループバックインタフェースを使用して同じ完全にかみ合っているMSDPメッシュグループの一部です。 また、MSDPのじっと見るのに使用されるこのループバックインタフェースはMBGPのじっと見るのに通常使用されるでしょう。 プロバイダーのドメインの中のすべてのルータがAuto-RP、BSR、または静的なRP課題でAnycast RPアドレスを知るでしょう。 そのドメインの各代表ルータはソース・レジスタを送るでしょう、そして、グループはAnycast RPアドレスにつなぎます。 ユニキャストルーティングは、それらのレジスタを向けて、最も近いAnycast RPにつなぎます。 特定のAnycast RPルータが失敗するなら、ユニキャストルーティングは、その後のレジスタを向けて、最も近いAnycast RPにつなぎます。 そして、そのRPはAnycast MSDPメッシュグループの中でMSDPアップデートをすべての同輩に送るでしょう。 そして、各RPは(from)の外部の顧客とプロバイダーにSAsを送るでしょう(受信してください)。
4. Security Considerations
4. セキュリティ問題
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状態は縁の創作ポイントで局所的に制御されるべきです。 マルチキャストサービス縁の選択しているフィルタリングは、それがSAメッセージ創造におけるソース結果を意図しただけであるのを確実にするのを助けます、そして、このコントロールはコアで関係づけられた州集合問題の見込みを減少させるのを助けます。 さまざまなポイントがローカルの方針がMSDPサービスに適用されるべきであるところにあります。
4.1. Filtering SA Messages
4.1. SAメッセージをフィルターにかけます。
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メッセージが受け取って、進めるのをさせるものをフィルターにかけるべきです。
McBride, et al. Best Current Practice [Page 11] RFC 4611 MSDP Deployment Scenarios August 2006
マックブライド、他 最も良い現在の練習[11ページ]RFC4611MSDP展開シナリオ2006年8月
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.
通常、公正な量の(S、G)状態がそのドメインに地方であることのPIM-SMドメインにあります。 しかしながら、適切なフィルタリングがなければ、これらの地方(S、G)の発表を含むSAメッセージのグローバルなMSDPインフラストラクチャに広告を出すかもしれません。 この例はグローバルなIPマルチキャストアドレスを使用するドメイン局所塗布とRFC1918アドレス[RFC1918]を使用するソースを含んでいます。 MSDPにスケーラビリティを改良して、ドメインのローカル(S、G)の情報のグローバルな目に見えることを避けるために、外部のSAフィルタリストが、周知のドメイン地元筋の不要な創造、推進、およびキャッシュを防ぐのを助けることが勧められます。
4.2. SA Message State Limits
4.2. 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-キャッシュは、限界SHOULDがスパイクを述べるために最終的な安全装置として構成されると述べます。 また、MSDPのじっと見るのが安定状態に達したとき(すなわち、いつじっと見ることを設立して、初期のSA状態を移しましたか)、新しいSA州のエントリーの創造のためのレートリミタを構成するのも望ましいかもしれません。
5. Acknowledgements
5. 承認
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.
作者はこのドキュメントの以前のバージョンの彼らのフィードバックについてペッカSavola、ジョンZwiebel、Swapna Yelamanchi、グレッグShepherd、およびジェイ・フォードに感謝したがっています。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[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):、」 「プロトコル仕様(改訂される)」、RFC4601、2006年8月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter、Y.、李、T.、およびS.野兎、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC4271 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.、マスコウィッツ、B.、Karrenberg、D.、deグルート、G.とE.リア、「個人的なインターネットのためのアドレス配分」BCP5、RFC1918(1996年2月)。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[RFC2858] ベイツ、T.、Rekhter、Y.、チャンドラ、R.、およびD.キャッツ、「BGP-4インチのためのMultiprotocol拡張子、RFC2858、2000年6月。」
McBride, et al. Best Current Practice [Page 12] RFC 4611 MSDP Deployment Scenarios August 2006
マックブライド、他 最も良い現在の練習[12ページ]RFC4611MSDP展開シナリオ2006年8月
[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.
[RFC3446] キム、D.、マイヤー、D.、キルマー、H.、およびD.ファリナッチ、「プロトコルの無党派Multicast(PIM)とMulticast Sourceディスカバリープロトコル(MSDP)を使用するAnycast Rendevous Point(RP)メカニズム」、RFC3446(2003年1月)。
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery
Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618]フェナーとB.とD.マイヤー、「マルチキャストソース発見プロトコル(MSDP)」、RFC3618 2003年10月。
6.2. Informative References
6.2. 有益な参照
[BSR] Fenner, W., et. al., "Bootstrap Router (BSR) Mechanism for
PIM Sparse Mode", Work in Progress, February 2003.
[BSR] etフェナー、W.、アル、「PIMのまばらなモードのためにルータ(BSR)メカニズムを独力で進んでください」、Progress、2月2003日のWork
[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
メール: mcbride@cisco.com
John Meylor Cisco Systems
ジョンMeylorシスコシステムズ
EMail: jmeylor@cisco.com
メール: jmeylor@cisco.com
David Meyer
デヴィッド・マイヤー
EMail: dmm@1-4-5.net
メール: dmm@1-4-5.net
McBride, et al. Best Current Practice [Page 13] RFC 4611 MSDP Deployment Scenarios August 2006
マックブライド、他 最も良い現在の練習[13ページ]RFC4611MSDP展開シナリオ2006年8月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
McBride, et al. Best Current Practice [Page 14]
マックブライド、他 最も良い現在の習慣[14ページ]
一覧
スポンサーリンク
