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
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).
著作権（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).
この文書では、プロトコル独立マルチキャストスパースモード（PIM-SM）と一緒には、Multicast Source Discovery Protocol（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
PIMドメイン間のO
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は、一般的に一対一のピアリングであり、そして決定論ピアRPF（転送パスリバース）MSDPの明細書に記載ルール（すなわち、それはメッシュグループを使用していない）を利用します。ピアリングは、単一のMSDPピアに集約することができます。そのようなピアは典型的には1からBGPピアリングに規模が類似しているピアリング数百に有することができます。
o Within a PIM Domain
PIMドメイン内のO
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は、しばしば（IGP到達可能性のおかげで）各エニーキャスト-RPピアによってサービス提供されるアクティブソースについての情報を同期させるために、PIMドメイン内のエニーキャストランデブーポイント（エニーキャスト-RPS）[RFC3446]の間で使用されています。このシナリオで使用ピアリングMSDPは、典型的には、以上10は典型的ではないがどこ2からピアの数十に、所定のメッシュグループを含むことができるMSDPメッシュグループに基づいています。これらのメッシュグループピアの1つ以上はまた、外部ソースの発見のためにそのPIMドメイン外のMSDPピアとの追加の一対一のピアリングを有することができます。外部MSDPピアリングのないエニーキャスト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の展開のための現在のベストプラクティスは、マルチプロトコル拡張（MBGP）[RFC4271、RFC2858]でPIM-SMとボーダーゲートウェイプロトコルを利用しています。この文書では、これらのプロトコルは、ドメイン内およびドメイン間の任意のソースマルチキャスト（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が唯一の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を配備します。
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つの選択肢があります。彼らのインターネットプロバイダのRPを使用する、または自分自身のRPを持つようにし、MSDPを使用してISPに接続します。自分の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が実験的に分類されるために与えられた主な理由の一つは、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の拡張性：私たちはすべてをreadvertising、ハードリミットが何であるか分からないが、あなたは明確に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の再加工に関する到達することはできませんでした。その結果、決定は（遍在し）に配備されており、実験的にその文書を移動するために何を文書化するために取られました。 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.
そのようなソース固有マルチキャストおよび双方向PIM、ならびにIPv6の埋め込みRP技術などのプロトコルの出現O、さらに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における技術のために存在している必要があります）[RFCED] RFCに技術を理解したり、実装するための1のために読み取らなければならないそれらの文書を指定します。このドキュメントを理解するためには、また、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はのBCPは、実験プロトコルへの引用規格を持っていなければならない政策を採用しています。しかし、この文書は、基礎となる実験的文書（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.
RFC 2026 [RFC2026]に記載されているようにMBONEDワーキンググループでは、分散手順の下での承認を要求しています。 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ピアリング展開は、通常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と同じでなければなりません。例として、次のトポロジを考慮してください。
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を持っています。 MBGPは、最初の発信元RPへの最適パスでは、AS2で、AS4からASホップ。送信MSDPピアのASもAS2です。この場合には、ピア・リバースパス転送チェック（ピア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は、最初の発信元RPへの最適パスでは、ASホップときピアRPF障害が、このトポロジで発生するであろう、送信MSDPピアのAS AS2とAS3の原点があります。 BGP ASパス情報にこの依存は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のビット間の規則を緩和します。 < - > AS3とAS3 < - >次のトポロジでは、MSDPはAS1の間でピアリングしてい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は失敗します。 AS2がAS4のRPへのMBGP最高のパスにAS最初であるので、そうAS1は、AS3でないMSDPピアすることができます。最新のMSDPドキュメント準拠したコードを使用すると、AS1はASに沿って最高のRPへのパスとして最も近いピアを選択します。 AS1は、SAのは、AS3から受け付けます。同じAS内のルータに複数の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.
また、彼らの境界ルータに向けて、内部MBGPとMSDPピアリングを維持する必要があるので、MSDPは、境界ルータ間のピアリングのために、ドメイン内MSDPのスケーラビリティが制限されています。ドメイン内の中で、境界ルータは、発信元RPへのネクストホップのアナウンサーになります。これは、すべてのドメイン内のMSDPピアリングバック境界ルータへのMBGPパスを反映する必要があります。内部MSDP（iMSDP）ピアリングは、次のホップのアナウンサーに依拠しながら、外部MSDP（eMSDP）ピアリングは、ピアRPFチェックのためのASパスに依存しています。
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ピアリングのための自社のコア・ネットワーク内のいくつかの専用ルータを選択してください。これらのコアMSDPルータは、典型的には、プロバイダのドメイン内のMSDPメッシュグループになり、エニーキャストRP用に設定すること。プロバイダのAS内のすべてのマルチキャストルータは、静的エニーキャストRPアドレスを指している必要があります。スタティックRPの割り当ては、その決定論的性質のためにグループ-RPマッピングのための最も一般的に用いられている方法です。自動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への最適なパスでAS（最新のMSDP仕様で、または最も近い）の次に依存しています。 MSDPピアアドレスは、境界ルータのMBGPピアのASと同じにする必要があります。 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ルータはMBGPがR2ルータとピアリングされ、R1はR3ルータとピアリングMSDPである場合、R2及びR3は、同じASになければならない（または表示される必要があり、AS1に、であることがあればAS番号民間が展開されている場合には、同じASから）。最大の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）は、発信元RPへの最良のパスのように次のMBGPです。限り、AS1は、次のAS（または最も近い）発信元RPへの最善の道であるとして、RPFはR1から到着したSAに成功します。
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.
対照的に、単一ホップのシナリオで、境界MSDP（代わりR3の）R2がR1の境界とのピアリングと、R2のMBGPアドレスは、発信元RPに向かって、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経路情報にピア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ピアリングはまた、企業内で使用されている場合は、MSDPデフォルトピアは、プロバイダーを指す境界ルータ上で設定する必要があります。このように、すべての外部のマルチキャストソースが学習されますと、内部要因を宣伝することができます。単一のMSDPピアリングは、プロバイダに向けて（何の内部MSDPピアリング）を使用しなかった場合、このスタブサイトは、プロバイダに向けてデフォルトピアをMSDPピア-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アップデートを共有することができます。各プロバイダごと他者とのMSDPとMBGPピアは直接交換のIPアドレスを接続します。各交換ルータはに/彼らのMSDPピアからのSAを受信/送信します。そして、彼らは彼らの顧客との直接のプロバイダのピアリングにそのドメイン全体のSAを転送することができるようになります。
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:
iBGPピアのネクストホップIPアドレスは、典型的には、MSDPピアRPFチェックのために使用される（IGPを使用することもできます）。これは、ASパス情報がピアRPFチェックのために使用されるドメイン間BGP / MSDPの場合、異なります。 MSDPピア接続のIPアドレスがMSDP / MBGPピアが直接接続されているか否かを内部MBGPピア接続と同じであるため、このような理由から、それが必要です。展開を成功には、以下のようになります。
+----+
| 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.
ここで、（2.2.2.2を使用して）RaがRP2 MSDPとMBGPピアおよびRb（3.3.3.3を使用して）を有します。 MSDP SA更新さRaからRP2に到着すると、1.1.1.1を通過するためのMSDP RPFチェックRP2も1.1.1.1の正しいMBGPネクストホップであるMSDPピア2.2.2.2、からSAの更新を受信するためです。
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の更新を受信するとRPFが正しくループを防止し、失敗したので、1.1.1.1用MBGPルックアップは、2.2.2.2のネクストホップを示しています。
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はMBGPをRaに2.2.2.2以外のアドレスにピアリングされた場合は、この展開はまた、RaがからRP2への更新に失敗する可能性があります。ピア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ルールは、次のトポロジに緩和されています。oメッシュグループピアとしてMSDPピアを設定することで。
o By having the MSDP peer be the only MSDP peer.
MSDPピアを持つことでoが唯一のMSDPピアとなります。
o By configuring a default MSDP peer.
デフォルトのMSDPピアを構成することにより、O。
o By peering with the originating RP.
発信元RPとのピアリングすることにより、O。
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ピアリング要件の周りの一般的な選択は、複数のMSDPピアが設定されている場合、MSDPメッシュグループを展開することです。 MSDPメッシュグループが展開されている場合、それらはメッシュグループのピアから受信したときSAメッセージを到着にはRPFチェックはありません。その後、SAメッセージは常にメッシュグループピアから受け入れています。 MSDPメッシュグループがメッシュグループピアから到達する、SAのためのネットワーク内の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にあり、-ISはIS RIPなどこの新機能は、BGPを実行していないと誰MSDPピアRPFルールを満たすために、既存のIGPを使用するために、メッシュグループを実行したくない企業のお客様のためにできるようになります。
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.
この例では、R1、R2、及びR3は、MSDPメッシュ群A（コアメッシュ群）であり、それぞれがMSDP集約そのリーフのためのルータ（または第二層）のメッシュ群としての1、2、および3のでSAメッセージメッシュグループのピアから受信し、その同じメッシュグループ内のピアに転送されない、SAメッセージは、ループではないであろう。ループ内のメッシュグループを接続トポロジを作成しないでください。上記の例では、例えば、第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との間に作成されるコアメッシュ群Aとそのリーフメッシュ群3を接続する2台のルータを持っていたと仮定する。
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 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 SAを転送しています。 RRとルータA、B、及びCもMSDPピア。 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.
SAは、ピアRPFは、あろうRaはMSDPピア場合に次のホップのアナウンサーがRRであるが、SAの更新をRaから来たので、ルータA、B、またはCと直接失敗します。適切な展開はRRとRRクライアントMSDPピアを持つことです。 MSDPメッシュグループは、この要件を回避するために使用することができます。次のASがMBGPとMSDPピアリングとの間で比較されているので、外部MSDPピアリングもむしろ、次のホップのアナウンサーのIPアドレスでは、この要件を防ぐことができます。
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にピアリングしている場合は、上記の例では、例えば、SAのRAの受信は、現在成功します。
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]に関連してエニーキャストRPメカニズムを使用してRPの負荷分散や冗長性を達成することができます。このメカニズムは、そのドメイン内のいくつかのRPを展開し、サービスプロバイダや企業によってドメイン内で使用される一般的な展開手法です。これらのRPは、各ループバックインターフェイス（このエニーキャストアドレスを作成する）に設定した同じIPアドレスを持つことになります。これらRPは別個のループバック・インターフェースを使用して互いにMSDPピアになり、同じフルメッシュMSDPメッシュグループの一部です。 MSDPピアリングのために使用されるこのループバックインターフェイスは、一般的にもMBGPピアリングに使用されます。プロバイダのドメイン内のすべてのルータは、自動RP、BSR、または静的RPの割り当てによってエニーキャストRPアドレスを学習します。ドメイン内の各指定ルータは、ソースレジスタが送信されますと、グループは、エニーキャストRPアドレスに合流します。ユニキャストルーティングは、これらのレジスタを指示し、最寄りのエニーキャストRPに参加します。特定のエニーキャストRPルータに障害が発生した場合は、ユニキャストルーティングは、後続のレジスタを指示し、最寄りのエニーキャストRPに参加します。それRPは、エニーキャストMSDPメッシュグループ内のすべてのピアにMSDPの更新を転送します。各RPは、順方向（から）外部顧客およびプロバイダにSAを（または受信）されます。
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サービスに適用されるべきポイントの様々なものがあります。
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.
典型的には、ドメインに対してローカルである（S、G）PIM-SMドメイン内の状態のかなりの量が存在します。しかし、適切なフィルタリングなしに、これらのローカル（S、G）アナウンスを含むSAメッセージは、グローバルMSDPインフラストラクチャにアドバタイズされてもよいです。この例は、RFC 1918のアドレス[RFC1918]を使用してグローバルIPマルチキャストアドレスとソースを使用して、ドメインローカルなアプリケーションが含まれています。 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.
作者はこのドキュメントの以前のバージョンに彼らのフィードバックのためにペッカSavola、ジョンZwiebel、Swapna Yelamanchi、グレッグ・シェパード、およびジェイフォードに感謝したいと思います。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601]フェナー、B.、ハンドリー、M.、ホルブルック、H.、およびI. Kouvelas、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様（改訂）"、RFC 4601、2006年8月。
[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）"、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.、モスコウィッツ、B.、Karrenberg、D.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.
"BGP-4のためのマルチプロトコル拡張" [RFC2858]ベイツ、T.、Rekhter、Y.、チャンドラ、R.、およびD.カッツ、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.
[RFC3446]キム、D.、マイヤー、D.、キルマー、H.、およびD.ファリナッチ、 "エニーキャストRendevousポイント（RP）プロトコル独立マルチキャスト（PIM）とMulticast Source Discovery Protocol（MSDP）を用いた機構" を、RFC 3446 、2003年1月。
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618]フェナー、B.とD.マイヤー、 "は、Multicast Source Discovery Protocol（MSDP）"、RFC 3618、2003年10月。
[BSR] Fenner, W., et. al., "Bootstrap Router (BSR) Mechanism for PIM Sparse Mode", Work in Progress, February 2003.
[BSR]フェナー、W.、ら。ら、「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
メールアドレス：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
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（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.
この文書では、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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。