Network Working Group B. Fenner, Ed.
Request for Comments: 3618 D. Meyer, Ed.
Category: Experimental October 2003
Multicast Source Discovery Protocol (MSDP)
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
The Multicast Source Discovery Protocol (MSDP) describes a mechanism to connect multiple IP Version 4 Protocol Independent Multicast Sparse-Mode (PIM-SM) domains together. Each PIM-SM domain uses its own independent Rendezvous Point (RP) and does not have to depend on RPs in other domains. This document reflects existing MSDP implementations.
Multicast Source Discovery Protocol（MSDP）は、複数のIPバージョン4プロトコル独立マルチキャストスパースモード（PIM-SM）が一緒ドメインに接続するためのメカニズムを説明しています。各PIM-SMドメインは独自の独立したランデブーポイント（RP）を使用し、他のドメインのRPに依存する必要はありません。この文書では、既存のMSDPの実装を反映しています。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Timers. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. SA-Advertisement-Timer . . . . . . . . . . . . . . . . . 5
5.2. SA-Advertisement-Timer Processing. . . . . . . . . . . . 5
5.3. SA Cache Timeout (SA-State Timer). . . . . . . . . . . . 5
5.4. Peer Hold Timer. . . . . . . . . . . . . . . . . . . . . 5
5.5. KeepAlive Timer. . . . . . . . . . . . . . . . . . . . . 6
5.6. ConnectRetry Timer . . . . . . . . . . . . . . . . . . . 6
6. Intermediate MSDP Peers . . . . . . . . . . . . . . . . . . . 6
7. SA Filtering and Policy . . . . . . . . . . . . . . . . . . . 6
8. Encapsulated Data Packets . . . . . . . . . . . . . . . . . . 7
9. Other Scenarios . . . . . . . . . . . . . . . . . . . . . . . 7
10. MSDP Peer-RPF Forwarding. . . . . . . . . . . . . . . . . . . 7
10.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 7
10.1.1. Multicast RPF Routing Information Base. . . . . 8
10.1.2. Peer-RPF Route. . . . . . . . . . . . . . . . . 8
10.1.3. Peer-RPF Forwarding Rules . . . . . . . . . . . 8
10.2. MSDP mesh-group semantics . . . . . . . . . . . . . . . 9
11. MSDP Connection State Machine . . . . . . . . . . . . . . . . 9
11.1. Events. . . . . . . . . . . . . . . . . . . . . . . . . 10
11.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . 10
11.3. Peer-specific Events. . . . . . . . . . . . . . . . . . 11
11.4. Peer-independent Events . . . . . . . . . . . . . . . . 11
12. Packet Formats. . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. MSDP TLV format . . . . . . . . . . . . . . . . . . . . 12
12.2. Defined TLVs. . . . . . . . . . . . . . . . . . . . . . 12
12.2.1. IPv4 Source-Active TLV. . . . . . . . . . . . . 13
12.2.2. KeepAlive TLV . . . . . . . . . . . . . . . . . 14
13. MSDP Error Handling . . . . . . . . . . . . . . . . . . . . . 15
14. SA Data Encapsulation . . . . . . . . . . . . . . . . . . . . 15
15. Applicability Statement . . . . . . . . . . . . . . . . . . . 15
15.1. Between PIM Domains . . . . . . . . . . . . . . . . . . 15
15.2. Between Anycast-RPs . . . . . . . . . . . . . . . . . . 15
16. Intellectual Property . . . . . . . . . . . . . . . . . . . . 15
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
18. Security Considerations . . . . . . . . . . . . . . . . . . . 16
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
19.1. Allocated TLV Range . . . . . . . . . . . . . . . . . . 17
19.2. Experimental TLV Range. . . . . . . . . . . . . . . . . 17
20. References. . . . . . . . . . . . . . . . . . . . . . . . . . 17
20.1. Normative References. . . . . . . . . . . . . . . . . . 17
20.2. Informative References. . . . . . . . . . . . . . . . . 18
21. Editors' Addresses. . . . . . . . . . . . . . . . . . . . . . 18
22. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 19
The Multicast Source Discovery Protocol (MSDP) describes a mechanism to connect multiple PIM Sparse-Mode (PIM-SM) [RFC2362] domains together. Each PIM-SM domain uses its own independent RP(s) and does not have to depend on RPs in other domains. Advantages of this approach include:
マルチキャストソース発見プロトコル（MSDP）を一緒ドメイン複数PIMスパースモード（PIM-SM）[RFC2362]を接続するためのメカニズムを説明しています。各PIM-SMドメインは独自の独立したRP（複数可）を使用し、他のドメインのRPに依存する必要はありません。このアプローチの利点は次のとおりです。
o No Third-party resource dependencies on a domain's RP
ドメインのRPにはサードパーティのリソースの依存関係O
PIM-SM domains can rely on their own RPs only.
PIM-SMドメインは独自のRPのみに頼ることができます。
o Receiver only Domains
Oレシーバのみドメイン
Domains with only receivers get data without globally advertising group membership.
レシーバーのみが配置されているドメインは、グローバルグループのメンバーシップを広告することなくデータを取得します。
Note that MSDP may be used with protocols other than PIM-SM, but such usage is not specified in this memo.
MSDPは、PIM-SM以外のプロトコルで使用することができるが、そのような使用はこのメモで指定されていないことに留意されたいです。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
MSDP-speaking routers in a PIM-SM domain have a MSDP peering relationship with MSDP peers in another domain. The peering relationship is made up of a TCP connection in which control information is exchanged. Each domain has one or more connections to this virtual topology.
PIM-SMドメイン内のMSDP圏のルータは、別のドメインのMSDPピアとのMSDPピアリング関係を持っています。ピアリング関係は、情報が交換されて制御するTCPコネクションで構成されています。各ドメインは、この仮想トポロジに1つまたは複数の接続を持っています。
The purpose of this topology is to allow domains to discover multicast sources from other domains. If the multicast sources are of interest to a domain which has receivers, the normal source-tree building mechanism in PIM-SM will be used to deliver multicast data over an inter-domain distribution tree.
このトポロジの目的は、ドメインが他のドメインからマルチキャスト送信元を発見できるようにすることです。マルチキャストソースは、レシーバを持つドメインに関心がある場合、PIM-SMの通常のソースツリー構築メカニズムは、ドメイン間ディストリビューション・ツリー上のマルチキャストデータを配信するために使用されます。
When an RP in a PIM-SM domain first learns of a new sender, e.g., via PIM register messages, it constructs a "Source-Active" (SA) message and sends it to its MSDP peers. All RPs, which intend to originate or receive SA messages, must establish MSDP peering with other RPs, either directly or via an intermediate MSDP peer. The SA message contains the following fields:
PIM-SMドメイン内のRPは、最初のPIM登録メッセージを介して、新しい送信者、例えばを学習するとき、それは「ソース・アクティブ」（SA）メッセージを構築し、そのMSDPピアに送信します。 SAメッセージを発信または受信しようとするすべてのRPは、直接又は中間MSDPピアを経由して、他のRPとのピアリングMSDPを確立する必要があります。 SAメッセージには、次のフィールドがあります。
o Source address of the data source.
データソースのOソースアドレス。
o Group address the data source sends to.
Oグループは、データソースがに送信取り組みます。
o IP address of the RP.
RPのO IPアドレス。
Note that an RP that isn't a DR on a shared network SHOULD NOT originate SA's for directly connected sources on that shared network; it should only originate in response to receiving Register messages from the DR.
共有ネットワーク上のDRでないRPは、共有ネットワーク上に直接接続されているソースのSAのを発するべきではないことに注意してください。それが唯一のDRからの登録メッセージを受信することに応答して発信すべきです。
Each MSDP peer receives and forwards the message away from the RP address in a "peer-RPF flooding" fashion. The notion of peer-RPF flooding is with respect to forwarding SA messages. The Multicast RPF Routing Information Base (MRIB) is examined to determine which peer towards the originating RP of the SA message is selected. Such a peer is called an "RPF peer". See section 13 for the details of peer-RPF forwarding.
各MSDPピアは離れて、「ピアRPFフラッディング」ファッションでRPアドレスからメッセージを受信して転送します。ピアRPF洪水の概念はSAメッセージを転送に関するものです。マルチキャストRPFルーティング情報ベース（MRIB）が選択されたSAメッセージの発信元RPに向かってピアを決定するために調べられます。このようなピアは、「RPFピア」と呼ばれています。ピアRPF転送の詳細については、セクション13を参照。
If the MSDP peer receives the SA from a non-RPF peer towards the originating RP, it will drop the message. Otherwise, it forwards the message to all its MSDP peers (except the one from which it received the SA message).
MSDPピアは、発信元RPへの非RPFピアからのSAを受信した場合、それはメッセージをドロップします。それ以外の場合は（それがSAメッセージを受信し、そこからのものを除く）すべてのMSDPピアにメッセージを転送します。
When an MSDP peer which is also an RP for its own domain receives a new SA message, it determines if there are any group members within the domain interested in any group described by an (Source, Group), or (S,G) entry within the SA message. That is, the RP checks for a (*,G) entry with a non-empty outgoing interface list; this implies that some system in the domain is interested in the group. In this case, the RP triggers a (S,G) join event towards the data source as if a Join/Prune message was received addressed to the RP itself. This sets up a branch of the source-tree to this domain. Subsequent data packets arrive at the RP via this tree branch, and are forwarded down the shared-tree inside the domain. If leaf routers choose to join the source-tree they have the option to do so according to existing PIM-SM conventions. Finally, if an RP in a domain receives a PIM Join message for a new group G, the RP SHOULD trigger a (S,G) join event for each active (S,G) for that group in its SA cache.
また、独自のドメインのRPでMSDPピアは、新しいSAメッセージを受信すると、（ソース、グループ）によって記載される任意のグループに興味を持ってドメイン内の任意のグループメンバーが存在するか否かを判断する、または（S、G）エントリSAメッセージ内。すなわち、空でない発信インターフェイスリストと（*、G）エントリのRPチェックです。これは、ドメイン内のいくつかのシステムがグループに興味があることを意味します。この場合、RPは（S、G）参加/プルーンメッセージは、RP自身宛受信されたかのようにデータ・ソースに向かってイベントへの参加をトリガします。これは、このドメインへの送信元ツリーの枝を設定します。後続のデータパケットは、この木の枝を経由してRPに到着すると、ドメイン内の共有ツリーを下に転送されます。リーフルータは、送信元ツリーに加入することを選択した場合、彼らは既存のPIM-SMの規則に従ってそうするオプションがあります。ドメイン内のRPは、PIMは、新しいグループGのためのメッセージを受信した場合参加最後に、RPは（S、G）は、そのSAキャッシュにそのグループの各アクティブな（S、G）のためのイベントに参加トリガします。
This procedure has been affectionately named flood-and-join because if any RP is not interested in the group, they can ignore the SA message. Otherwise, they join a distribution tree.
どのRPがグループに興味を持っていない場合、彼らはSAメッセージを無視することができますので、この手順では、愛情を込めて洪水と-参加と命名されました。それ以外の場合は、ディストリビューションツリーに参加します。
A MSDP speaker MUST cache SA messages. Caching allows pacing of MSDP messages as well as reducing join latency for new receivers of a group G at an originating RP which has existing MSDP (S,G) state. In addition, caching greatly aids in diagnosis and debugging of various problems.
MSDPスピーカーは、SAメッセージをキャッシュしなければなりません。キャッシングは、MSDPメッセージのペーシングならびにMSDP（S、G）ステートを既存た発信元RPにグループGの新しい受信機のための待ち時間を結合還元を可能にします。また、キャッシュが大きく、様々な問題の診断およびデバッグに役立ちます。
An MSDP speaker must provide a mechanism to reduce the forwarding of new SA's. The SA-cache is used to reduce storms and performs this by not forwarding SA's unless they are in the cache or are new SA packets that the MSDP speaker will cache for the first time. The SA-cache also reduces storms by advertising from the cache at a period of no more than twice per SA-Advertisement-Timer interval and not less than 1 time per SA Advertisement period.
MSDPスピーカーは、新しいSAのの転送を削減するためのメカニズムを提供しなければなりません。 SA-キャッシュは嵐を削減するために使用し、それらがキャッシュ内にあるか、MSDPスピーカーが初めてキャッシュする新しいSAパケットでない限り、SAのを転送しないことによってこれを行います。 SA-キャッシュもこれ以上のSA-広告・タイマー間隔ではなくSA広告期間につき1時間未満あたり2倍以上の周期でキャッシュから広告によって嵐を低減します。
The main timers for MSDP are: SA-Advertisement-Timer, SA Cache Entry timer, Peer Hold Timer, KeepAlive timer, and ConnectRetry timer. Each is considered below.
MSDPのための主なタイマーは、次のとおりです。SA-広告・タイマー、SAキャッシュエントリタイマー、タイマー、キープアライブタイマー、および接続リトライタイマを持ちピア。それぞれが以下と考えられています。
RPs which originate SA messages do so periodically as long as there is data being sent by the source. There is one SA-Advertisement-Timer covering the sources that an RP may advertise. [SA-Advertisement-Period] MUST be 60 seconds. An RP MUST not send more than one periodic SA message for a given (S,G) within an SA Advertisement interval. Originating periodic SA messages is required to keep announcements alive in caches. Finally, an originating RP SHOULD trigger the transmission of an SA message as soon as it receives data from an internal source for the first time. This initial SA message may be in addition to the periodic sa-message forwarded in that first 60 seconds for that (S,G).
SAメッセージを発信RPは限りソースによって送信されたデータがあるように、定期的に行います。 RPは、広告を掲載するソースをカバーする1 SA-広告タイマーがあります。 [SA-広告-期間] 60秒でなければなりません。 RPはSA広告期間内に与えられた（S、G）のための複数の周期的なSAメッセージを送信してはなりません。定期的なSAメッセージを発信することは、キャッシュに生きアナウンスを維持するために必要とされます。最後に、発信元RPはすぐに、それは最初に内部ソースからデータを受信するようにSAメッセージの送信をトリガします。この最初のSAメッセージは、（S、G）のために、その最初の60秒で転送周期SAメッセージに加えてもよいです。
An RP MUST spread the generation of periodic SA messages (i.e., messages advertising the active sources for which it is the RP) over its reporting interval (i.e., SA-Advertisement-Period). An RP starts the SA-Advertisement-Timer when the MSDP process is configured. When the timer expires, an RP resets the timer to [SA-Advertisement-Period] seconds, and begins the advertisement of its active sources. Active sources are advertised in the following manner: An RP packs its active sources into an SA message until the largest MSDP packet that can be sent is built or there are no more sources, and then sends the message. This process is repeated periodically within the SA-Advertisement-Period in such a way that all of the RP's sources are advertised. Note that since MSDP is a periodic protocol, an implementation SHOULD send all cached SA messages when a connection is established. Finally, the timer is deleted when the MSDP process is de-configured.
RPは、定期的なSAメッセージ（すなわち、それがRPであるため、アクティブソースをアドバタイズメッセージ）その報告間隔にわたって（すなわち、SA-広告ピリオド）の生成を広げなければなりません。 MSDPプロセスが設定されている場合、RPはSA-広告タイマーを開始します。タイマーが満了すると、RPは[SA-広告-期間]秒にタイマーをリセットし、そのアクティブなソースの広告を開始します。アクティブなソースは、次のように宣伝されています。そして、内蔵されて送信またはそれ以上のソースが存在しない、とすることができ、最大MSDPパケットがメッセージを送信するまで、RPはSAメッセージにそのアクティブなソースをパックします。このプロセスは、RPのソースのすべてが広告を出しているような方法で、SA-広告-期間内に周期的に繰り返されます。 MSDPは、定期的なプロトコルであるため、接続が確立されると、実装はキャッシュされているすべてのSAメッセージを送るべきであることに注意してください。 MSDPプロセスが非構成されている場合、最後に、タイマーが削除されます。
Each entry in an SA Cache has an associated SA-State Timer. A (S,G)-SA-State-Timer is started when an (S,G)-SA message is initially received by an MSDP peer. The timer is reset to [SG-State-Period] if another (S,G)-SA message is received before the (S,G)-SA-State Timer expires. [SG-State-Period] MUST NOT be less than [SA-Advertisement-Period] + [SA-Hold-Down-Period].
SAキャッシュ内の各エントリは、関連するSAステートタイマーを持っています。 （S、G）-SAメッセージが最初MSDPピアによって受信されると（S、G）-SAステートタイマをスタートさせます。タイマーは、別の（S、G）場合[SGステート期間]にリセットさ-SA（S、G）-SAステートタイマが満了する前にメッセージが受信されます。 [SGは、ステート期間] [SA-広告-期間] + [SA-ホールドダウン期間]以上でなければなりません。
The Hold Timer is initialized to [HoldTime-Period] when the peer's transport connection is established, and is reset to [HoldTime-Period] when any MSDP message is received. Finally, the timer is deleted when the peer's transport connection is closed. [HoldTime-Period] MUST be at least three seconds. The recommended value for [HoldTime-Period] is 75 seconds.
ホールドタイマは、ピアの転送接続が確立され、そして任意MSDPメッセージが受信された[たHoldTime-期間]にリセットされ、[たHoldTime-期間]に初期化されます。ピアのトランスポート接続がクローズされたときに最後に、タイマーが削除されます。 [のHoldTime-期間] 3秒以上でなければなりません。 [のHoldTime-期間]の推奨値は75秒です。
Once an MSDP transport connection is established, each side of the connection sends a KeepAlive message and sets a KeepAlive timer. If the KeepAlive timer expires, the local system sends a KeepAlive message and restarts its KeepAlive timer.
MSDPのトランスポート接続が確立されると、接続のそれぞれの側は、キープアライブメッセージを送信し、キープアライブタイマーを設定します。キープアライブタイマーが満了した場合は、ローカルシステムがキープアライブメッセージを送信し、そのキープアライブタイマーを再起動します。
The KeepAlive timer is set to [KeepAlive-Period] when the peer comes up. The timer is reset to [KeepAlive-Period] each time an MSDP message is sent to the peer, and reset when the timer expires.
ピアが起動したときキープアライブタイマーは、[キープアライブ-期間]に設定されています。タイマーは、[キープアライブ-期間] MSDPメッセージをピアに送信されるたびにリセットされ、タイマが満了したときにリセットされます。
Finally, the KeepAlive timer is deleted when the peer's transport connection is closed.
ピアのトランスポート接続がクローズされたときに最後に、キープアライブタイマーが削除されます。
[KeepAlive-Period] MUST be less than [HoldTime-Period], and MUST be at least one second. The recommended value for [KeepAlive-Period] is 60 seconds.
[キープアライブ-期間] [たHoldTime-期間]未満でなければならない、少なくとも1つの第2なければなりません。 [キープアライブ-期間]の推奨値は60秒です。
The ConnectRetry timer is used by the MSDP peer with the lower IP address to transition from INACTIVE to CONNECTING states. There is one timer per peer, and the [ConnectRetry-Period] SHOULD be set to 30 seconds. The timer is initialized to [ConnectRetry-Period] when an MSDP speaker attempts to actively open a TCP connection to its peer (see section 15, event E2, action A2 ). When the timer expires, the peer retries the connection and the timer is reset to [ConnectRetry-Period]. It is deleted if either the connection transitions into ESTABLISHED state or the peer is de-configured.
接続リトライタイマは、接続状態にINACTIVEから移行するために、より低いIPアドレスでMSDPピアで使用されています。そこピアごとにタイマーがあり、かつ[ConnectRetry-期間は30秒に設定する必要があります。タイマーがに初期化される[ConnectRetry-期間] MSDPスピーカーが積極的にそのピアへのTCP接続を開こうとすると（セクション15を参照してください、イベントE2、アクションA2）。タイマが満了すると、ピアは接続を再試行タイマが[ConnectRetry-期間]にリセットされます。 ESTABLISHED状態またはピアに接続遷移が非構成されているいずれかの場合には削除されます。
Intermediate MSDP speakers do not originate periodic SA messages on behalf of sources in other domains. In general, an RP MUST only originate an SA for a source which would register to it, and ONLY RPs may originate SA messages. Intermediate MSDP speakers MAY forward SA messages received from other domains.
中級MSDPスピーカーは、他のドメイン内のソースの代わりに、定期的なSAメッセージを発信しません。一般的に、RPは、それだけに登録しますソースのSAを発信する必要があり、そしてONLY RPはSAメッセージを発信します。中級MSDPスピーカーは、他のドメインから受信したSAメッセージを転送することができます。
As the number of (S,G) pairs increases in the Internet, an RP may want to filter which sources it describes in SA messages. Also, filtering may be used as a matter of policy which at the same time can reduce state. MSDP peers in transit domains should not filter SA messages or the flood-and-join model can not guarantee that sources will be known throughout the Internet (i.e., SA filtering by transit domains may cause undesired lack of connectivity). In general, policy should be expressed using MBGP [RFC2858]. This will cause MSDP messages to flow in the desired direction and peer-RPF fail otherwise. An exception occurs at an administrative scope [RFC2365] boundary. In particular, a SA message for a (S,G) MUST NOT be sent to peers which are on the other side of an administrative scope boundary for G.
インターネットに（S、G）ペアの数が増加するように、RPは、SAメッセージで説明ソースしたフィルタを適用することができます。また、フィルタリングは、同時に状態を低減することができるポリシーの問題として使用することができます。トランジットドメインでMSDPピアはSAメッセージをフィルタリングするべきではないか、洪水と-参加モデルは、ソースが（すなわち、トランジットドメインによってSAフィルタリングは、接続の望ましくない欠如を引き起こす可能性が）インターネットを通じて知られているであろうことを保証することはできません。一般に、ポリシーはMBGP [RFC2858]を使用して表現されるべきです。これは、MSDPメッセージが所望の方向に流れることになりますと、ピアRPFは、それ以外の場合は失敗します。例外は、管理範囲[RFC2365]の境界で起こります。特に、（S、G）のためのSAメッセージはG.の管理範囲の境界の他方の側にあるピアに送ってはいけません
The RP MAY encapsulate multicast data from the source. An interested RP may decapsulate the packet, which SHOULD be forwarded as if a PIM register encapsulated packet was received. That is, if packets are already arriving over the interface toward the source, then the packet is dropped. Otherwise, if the outgoing interface list is non-null, the packet is forwarded appropriately. Note that when doing data encapsulation, an implementation MUST bound the time during which packets are encapsulated.
RPは、ソースからのマルチキャストデータをカプセル化することができます。興味のRPは、PIMレジスタカプセル化されたパケットを受信したかのように転送すべきパケットをデカプセル化してもよいです。これは、パケットがすでにソースに向けたインタフェースを介して到着している場合、そのパケットは廃棄され、です。発信インターフェイスリストが非nullの場合それ以外の場合は、パケットを適切に転送されます。データのカプセル化を行う場合、実装は、パケットがカプセル化されている間の時間を拘束しなければならないことに注意してください。
This allows for small bursts to be received before the multicast tree is built back toward the source's domain. For example, an implementation SHOULD encapsulate at least the first packet to provide service to bursty sources.
マルチキャストツリーをバック元のドメインに向けて構築される前に、小さなバーストが受信されることを可能にします。例えば、実装は、少なくともバーストソースにサービスを提供する最初のパケットをカプセル化するべきです。
MSDP is not limited to deployment across different routing domains. It can be used within a routing domain when it is desired to deploy multiple RPs for the same group ranges such as with Anycast RP's. As long as all RPs have a interconnected MSDP topology, each can learn about active sources as well as RPs in other domains.
MSDPは、異なるルーティングドメイン間での展開に限定されるものではありません。同じグループのための複数のRPを展開することが望まれる場合には、ルーティングドメイン内で使用することができるようなエニーキャストRPのと同様の範囲です。限り、すべてのRPが相互接続MSDPトポロジーを持っているように、それぞれが他のドメイン内のアクティブソースなどのRPについて学ぶことができます。
The MSDP Peer-RPF Forwarding rules are used for forwarding SA messages throughout an MSDP enabled internet. Unlike the RPF check used when forwarding data packets, which generally compares the packet's source address against the interface upon which the packet was received, the Peer-RPF check compares the RP address carried in the SA message against the MSDP peer from which the message was received.
MSDPピアRPF転送ルールは、MSDP有効にインターネットを通じてSAメッセージを転送するために使用されています。一般的にパケットを受信した際にインタフェースに対するパケットの送信元アドレスとを比較し、データパケットを転送するときに使用RPFチェックとは異なり、ピアRPFチェックは、メッセージがあったからMSDPピアに対してSAメッセージで運ばれたRPアドレスを比較します受け取りました。
The following definitions are used in the description of the Peer-RPF Forwarding Rules:
以下の定義はピアRPF転送ルールの説明で使用されています。
The Multicast RPF Routing Information Base (MRIB) is the multicast topology table. It is typically derived from the unicast routing table or from other routing protocols such as multi-protocol BGP [RFC2858].
マルチキャストRPFルーティング情報ベース（MRIB）マルチキャストトポロジーテーブルです。それは、典型的には、ユニキャストルーティングテーブルから、またはそのようなマルチプロトコルBGP [RFC2858]などの他のルーティングプロトコルから導出されます。
The Peer-RPF route is the route that the MRIB chooses for a given address. The Peer-RPF route for a SA's originating RP is used to select the peer from which the SA is accepted.
ピアRPFルートは、MRIBが所与のアドレスの選択経路です。 SAの発信元RPのためのピアRPFルートはSAが受理されたピアを選択するために使用されます。
An SA message originated by R and received by X from N is accepted if N is the peer-RPF neighbor for X, and is discarded otherwise.
NがXのピア・RPF隣人であり、そうでなければ廃棄される場合NからXによりRによって発信および受信SAメッセージが受け入れられます。
MPP(R,N) MP(N,X)
R ---------....-------> N ------------------> X
SA(S,G,R) SA(S,G,R)
MP(N,X) is an MSDP peering between N and X. MPP(R,N) is an MSDP peering path (zero or more MSDP peers) between R and N, e.g., MPP(R,N) = MP(R, A) + MP(A, B) + MP(B, N). SA(S,G,R) is an SA message for source S on group G originated by an RP R.
MP（N、X）は、N及びX. MPP（R、N）との間にピアリングMSDPであるRとN、例えば、MPP（R、N）= MP（Rとの間のMSDPピアリング経路（ゼロ以上MSDPピア）であります、A）+ MP（A、B）+ MP（B、N）。 SA（S、G、R）は、RP R.によって発信群G上のソースSのSAメッセージであります
The peer-RPF neighbor N is chosen deterministically, using the first of the following rules that matches. In particular, N is the RPF neighbor of X with respect to R if
ピアRPF隣人Nに一致する次のルールの最初を使用して、決定論的に選択されます。具体的には、Nは、場合Rに対してXのRPF隣人であります
(i). N == R (X has an MSDP peering with R).
（私）。 N == R（XはRとピアリングMSDPを有しています）。
(ii). N is the eBGP NEXT_HOP of the Peer-RPF route for R.
（ⅱ）。 NはRのピア・RPF経路のeBGP NEXT_HOPあります
(iii). The Peer-RPF route for R is learned through a distance-vector or path-vector routing protocol (e.g., BGP, RIP, DVMRP) and N is the neighbor that advertised the Peer-RPF route for R (e.g., N is the iBGP advertiser of the route for R), or N is the IGP next hop for R if the route for R is learned via a link-state protocol (e.g., OSPF [RFC2328] or IS-IS [RFC1142]).
（ハ）。 RのためのピアRPFルートは距離ベクトルまたはパスベクトルルーティングプロトコル（例えば、BGP、RIP、DVMRP）を介して学習され、NはR（例えば、ピア・RPFルートをアドバタイズ隣人であり、Nは、iBGPのありますRのための経路がリンクステートプロトコル（例えば、OSPF [RFC2328]を介して学習または[RFC1142]-ISである場合にRのルートの広告主）、またはN）は、R用のIGPネクストホップです。
(iv). N resides in the closest AS in the best path towards R. If multiple MSDP peers reside in the closest AS, the peer with the highest IP address is the rpf-peer.
（ⅳ）。複数のMSDPピアが最も近いASに存在する場合、NはR.への最適なパスのように最も近い内に存在する、最大のIPアドレスを持つピアはRPFピアです。
(v). N is configured as the static RPF-peer for R.
（V）。 NがRのスタティックRPFピアとして構成されています
MSDP peers, which are NOT in state ESTABLISHED (i.e., down peers), are not eligible for peer RPF consideration.
状態（すなわち、ピア下）確立されていないMSDPピアは、ピアRPF考慮の対象外です。
An MSDP mesh-group is a operational mechanism for reducing SA flooding, typically in an intra-domain setting. In particular, when some subset of a domain's MSDP speakers are fully meshed, they can be configured into a mesh-group.
MSDPメッシュグループは通常、ドメイン内の設定では、SAの洪水を減少させるための操作メカニズムです。ドメインのMSDPスピーカーのいくつかのサブセットが完全に噛み合っているとき特に、彼らはメッシュグループに設定することができます。
Note that mesh-groups assume that a member doesn't have to forward an SA to other members of the mesh-group because the originator will forward to all members. To be able for the originator to forward to all members (and to have each member also be a potential originator), the mesh-group must be a full mesh of MSDP peering among all members.
メッシュグループはメンバーが発信者がすべてのメンバーに転送されますので、メッシュグループの他のメンバーにSAを転送する必要がないことを前提としています。創始すべてのメンバーに転送する（および各メンバーは、潜在的な発信元も持っている）のためにできるようにするために、メッシュグループは、すべてのメンバーの間でMSDPピアリングのフルメッシュでなければなりません。
The semantics of the mesh-group are as follows:
次のようにメッシュグループの意味は以下のとおりです。
(i). If a member R of a mesh-group M receives a SA message from an MSDP peer that is also a member of mesh-group M, R accepts the SA message and forwards it to all of its peers that are not part of mesh-group M. R MUST NOT forward the SA message to other members of mesh-group M.
（私）。メッシュグループMのメンバーRはまた、メッシュグループMのメンバーであるMSDPピアからのSAメッセージを受信した場合、Rは、SAメッセージを受け入れ、転送し、メッシュグループの一部ではないすべてのピアにM. Rは、メッシュグループMの他のメンバーへのSAメッセージを転送してはいけません
(ii). If a member R of a mesh-group M receives an SA message from an MSDP peer that is not a member of mesh-group M, and the SA message passes the peer-RPF check, then R forwards the SA message to all members of mesh-group M and to any other msdp peers.
（ⅱ）。メッシュグループのメンバーRは、MはメッシュグループMのメンバーではないMSDPピアからのSAメッセージを受信し、SAメッセージがピアRPFチェックを通過し、次いでRは、すべてのメンバーにSAメッセージを転送する場合メッシュグループMおよび他のMSDPピアに。
MSDP uses TCP as its transport protocol. In a peering relationship, one MSDP peer listens for new TCP connections on the well-known port 639. The other side makes an active connect to this port. The peer with the higher IP address will listen. This connection establishment algorithm avoids call collision. Therefore, there is no need for a call collision procedure. It should be noted, however, that the disadvantage of this approach is that the startup time depends completely upon the active side and its connect retry timer; the passive side cannot cause the connection to be established.
MSDPは、そのトランスポートプロトコルとしてTCPを使用しています。ピアリング関係では、1つのMSDPピアは、他の側は、このポートに接続し、アクティブになり、well-knownポート639で新しいTCP接続を待機します。高いIPアドレスを持つピアは耳を傾けます。この接続確立アルゴリズムは、コールの衝突を避けることができます。そのため、コール衝突手続きは必要ありません。この方法の欠点は、起動時間は、アクティブ側とその接続の再試行タイマー時に完全に依存することであることに留意すべきです。パッシブ側は、接続が確立させることができません。
An MSDP peer starts in the DISABLED state. MSDP peers establish peering sessions according to the following state machine:
MSDPピアはDISABLED状態で起動します。 MSDPピアは、次のステートマシンに応じたピアリングセッションを確立します。
--------------->+----------+
/ | DISABLED |<----------
| ------>+----------+ \
| / |E1->A1 |
| | | |
| | V |E7->A7
| | +----------+ E3->A3 +--------+
| | | INACTIVE |------->| LISTEN |
| | +----------+ +--------+
| | E2->A2| ^ |E5->A5
| | | | |
| |E7->A6 V |E6 |
| \ +------------+ |
| ------| CONNECTING | |
| +------------+ |
E7->A8 | |E4->A4 |
E8->A8 | | |
E9->A8 | V |
\ +-------------+ /
--------------| ESTABLISHED |<---------
+-------------+
| ^
| |
E10->A9 \______/
E1) Enable MSDP peering with P E2) Own IP address < P's IP address E3) Own IP address > P's IP address E4) TCP established (active side) E5) TCP established (passive side) E6) ConnectRetry timer expired E7) Disable MSDP peering with P (e.g., when one's own address is changed) E8) Hold Timer expired E9) MSDP TLV format error detected E10) Any other error detected
E1）P E2とのピアリングMSDP）自身のIPアドレス<PのIPアドレスE3）自分のIPアドレス> PのIPアドレスE4設立）TCP確立（アクティブ側）E5）TCP（パッシブ側）E6）接続リトライタイマは、E7を期限切れ）を無効にMSDPを有効にしますMSDP TLV形式エラーが検出されたその他のエラー））はE10を検出P（例えば、自分のアドレスが変更されたとき）E8）とのピアリングタイマーはE9期限切れホールド
A1) Allocate resources for peering with P Compare one's own and peer's IP addresses A2) TCP active OPEN Set ConnectRetry timer to [ConnectRetry-Period] A3) TCP passive OPEN (listen)
A1）[ConnectRetry-期間] A3）TCPパッシブOPEN（聞く）に自分自身を比較Pとのピアリングのためのリソースを割り当て、ピアのIPは、アドレスA2）TCPアクティブオープンセット接続リトライタイマ
A4) Delete ConnectRetry timer Send KeepAlive TLV Set KeepAlive timer to [KeepAlive-Period] Set Hold Timer to [HoldTime-Period] A5) Send KeepAlive TLV Set KeepAlive timer to [KeepAlive-Period] Set Hold Timer to [HoldTime-Period] A6) Abort TCP active OPEN attempt Release resources allocated for peering with P A7) Abort TCP passive OPEN attempt Release resources allocated for peering with P A8) Close the TCP connection Release resources allocated for peering with P A9) Drop the packet
A4は）へ[KeepAliveの-期間]を設定ホールドタイマーにキープアライブTLVの設定キープアライブタイマーを送る接続リトライタイマを削除[のHoldTime-期間] A5）[たHoldTime-期間] A6に[キープアライブ-期間]を設定ホールドタイマーにキープアライブTLVの設定キープアライブタイマーを送ります）中止TCP P A7とのピアリング用に割り当てられたアクティブなOPEN試みリリースリソース）P A8とのピアリング用に割り当てられた中止TCPパッシブOPEN試みリリースリソース）P A9とのピアリング用に割り当てられたTCPコネクションリリースリソースを閉じます）は、パケットをドロップします
The following peer-specific events can occur in the ESTABLISHED state, they do not cause a state transition. Appropriate actions are listed for each event.
次ピア固有のイベントがESTABLISHED状態で発生する可能性があり、彼らは状態遷移が発生することはありません。適切なアクションをイベントごとに記載されています。
*) KeepAlive timer expired: -> Send KeepAlive TLV -> Set KeepAlive timer to [KeepAlive-Period] *) KeepAlive TLV received: -> Set Hold Timer to [HoldTime-Period] *) Source-Active TLV received: -> Set Hold Timer to [HoldTime-Period] -> Run Peer-RPF Forwarding algorithm -> Set KeepAlive timer to [KeepAlive-Period] for those peers the Source-Active TLV is forwarded to -> Send information to PIM-SM -> Store information in cache
*）キープアライブタイマーが満了： - >キープアライブTLVを送信する - >キープアライブTLVが受信*）[キープアライブ-期間]に設定キープアライブタイマー： - [のHoldTime-期間]へ>を設定ホールドタイマ*）ソースアクティブTLVは受信： - >を設定します> PIM-SMに情報を送る - - ソース・アクティブTLVが転送されたこれらのピアのために[キープアライブ-期間]に>設定キープアライブタイマー - > [ファイル名を指定して実行のピアRPF転送アルゴリズム - [のHoldTime-期間]にホールドタイマー>店舗情報キャッシュ内
There are also a number of events that affect more than one peering session, but still require actions to be performed on a per-peer basis.
そこに複数のピアリングセッションに影響を与えるイベントの数もありますが、まだアクションがピアごとに実行する必要があります。
*) SA-Advertisement-Timer expired: -> Start periodic transmission of Source-Active TLV(s) -> Set KeepAlive timer to [KeepAlive-Period] each time a Source-Active TLV is sent *) MSDP learns of a new active internal source (e.g., PIM-SM register received for a new source): -> Send Source-Active TLV -> Set KeepAlive timer to [KeepAlive-Period] *) SG-State-Timer expired (one timer per cache entry):
*）SA-広告タイマーの期限が切れて： - >ソース・アクティブTLV（S）の周期的な送信開始 - [キープアライブ-期間]に>設定キープアライブタイマーをソース・アクティブTLVが送信されるたび*）MSDPは、新しいアクティブを知ります内部ソース（例えば、PIM-SMレジスタは、新しいソースの受信）： - >ソース・アクティブTLV送信 - [キープアライブ-期間]に>設定キープアライブタイマーを*）SG-ステート・タイマ）（キャッシュエントリごとに1つのタイマー期限切れ：
-> Implementation specific, typically mark the cache entry for deletion
- >実装固有の、一般的に削除用のキャッシュエントリをマーク
MSDP messages are encoded in TLV format. If an implementation receives a TLV whose length exceeds the maximum TLV length specified below, the TLV SHOULD be accepted. Any additional data, including possible next TLV's in the same message, SHOULD be ignored, and the MSDP session should not be reset.
MSDPメッセージは、TLV形式でエンコードされています。インプリメンテーションは、その長さ以下の指定された最大TLVの長さを超えたTLVを受信した場合、TLVが受け入れられるべきです。可能な次のTLVの同じメッセージに含めて任意の追加データは、無視されるべきである、とMSDPセッションがリセットされるべきでありません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (8 bits) Describes the format of the Value field.
タイプ（8ビット）は、Valueフィールドのフォーマットを記述します。
Length (16 bits) Length of Type, Length, and Value fields in octets. Minimum length required is 4 octets, except for Keepalive messages. The maximum TLV length is 9192.
長さ（16ビット）のオクテットでタイプ、長さ、および値フィールドの長さ。必要な最小の長さはキープアライブメッセージを除き、4つのオクテットです。最大TLVの長さは9192です。
Value (variable length) Format is based on the Type value. See below. The length of the value field is Length field minus 3. All reserved fields in the Value field MUST be transmitted as zeros and ignored on receipt.
値（可変長）フォーマットは、タイプ値に基づいています。下記参照。値フィールドの長さは、長さフィールドマイナス値フィールド3.すべての予約済みフィールドはゼロとして送信され、受信時に無視しなければなりませんです。
The following TLV Types are defined:
以下のTLVタイプが定義されています。
Code Type
===================================================
1 IPv4 Source-Active
2 IPv4 Source-Active Request
3 IPv4 Source-Active Response
4 KeepAlive
5 Reserved (Previously: Notification)
Each TLV is described below.
各TLVは以下の通りです。
In addition, the following TLV Types are assigned but not described in this memo:
また、以下のTLVタイプが割り当てられているが、このメモで説明されていません。
Code Type
====================================================
6 MSDP traceroute in progress
7 MSDP traceroute reply
The maximum size SA message that can be sent is 9192 octets. The 9192 octet size does not include the TCP, IP, layer-2 headers.
送信可能な最大サイズのSAメッセージは9192オクテットです。 9192オクテットサイズはTCP、IP、レイヤ2ヘッダが含まれていません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | x + y | Entry Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Sprefix Len | \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \
| Group Address | ) z
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
| Source Address | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type IPv4 Source-Active TLV is type 1.
入力したIPv4のsource-active TLVはタイプ1です。
Length x Is the length of the control information in the message. x is 8 octets (for the first two 32-bit quantities) plus 12 times Entry Count octets.
長さxは、メッセージ内の制御情報の長さです。 Xは、（最初の2つの32ビット量のために）8つのオクテットプラス12倍エントリ数オクテットです。
Length y If 0, then there is no data encapsulated. Otherwise an IPv4 packet follows and y is the value of the total length field in the header of the encapsulated IP packet. If there are multiple (S,G) entries in an SA message, only the last entry may have encapsulated data and it must reflect the source and destination addresses in the header of the encapsulated IP packet.
長さyが0の場合は、カプセル化されたデータが存在しません。そうでない場合にIPv4パケットは、以下、yはカプセル化されたIPパケットのヘッダ内の全長フィールドの値です。 SAメッセージに複数の（S、G）エントリがある場合、最後のエントリは、データをカプセル化している可能性があり、それがカプセル化されたIPパケットのヘッダに送信元アドレスと宛先アドレスを反映しなければなりません。
Entry Count Is the count of z entries (note above) which follow the RP address field. This is so multiple (S,G)s from the same domain can be encoded efficiently for the same RP address. An SA message containing encapsulated data typically has an entry count of 1 (i.e., only contains a single entry, for the (S,G) representing the encapsulated packet).
エントリカウントは、RPアドレスフィールドに続くzのエントリ（上記の注意）の数です。これは、同じRPアドレスを効率的に符号化することができるのと同じドメインからの（S、G）は複数あります。カプセル化されたデータを含むSAメッセージは、典型的には、（カプセル化されたパケットを表し、すなわち、唯一の（S、Gのために、単一のエントリを含む）1）のエントリ数を有しています。
RP Address The address of the RP in the domain the source has become active in.
RPソースがアクティブになっていたドメインにRPのアドレス。
Reserved The Reserved field MUST be transmitted as zeros and MUST be ignored by a receiver.
予約予約フィールドはゼロとして送信しなければならなくて、受信機で無視しなければなりません。
Sprefix Len The route prefix length associated with source address. This field MUST be transmitted as 32 (/32).
Sprefixレン送信元アドレスに関連付けられた経路プレフィックス長。このフィールドは32（/ 32）として送信されなければなりません。
Group Address The group address the active source has sent data to.
当社グループは、アクティブなソースがにデータを送信したグループアドレス。
Source Address The IP address of the active source.
ソースは、アクティブな送信元のIPアドレス。
Multiple (S,G) entries MAY appear in the same SA and can be batched for efficiency at the expense of data latency. This would typically occur on intermediate forwarding of SA messages.
複数（S、G）エントリは、同じSAに表示され、データ待ち時間を犠牲にして効率をバッチ処理することができます。これは通常、SAメッセージの中間転送に起こるであろう。
A KeepAlive TLV is sent to an MSDP peer if and only if there were no MSDP messages sent to the peer within [KeepAlive-Period] seconds. This message is necessary to keep the MSDP connection alive.
[キープアライブ-期間]秒以内にピアに送信されませMSDPメッセージがなかった場合にのみ場合KeepAliveのTLVは、MSDPピアに送信されます。このメッセージは、生きているMSDP接続を維持することが必要です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length of the message is 3 octets which encompasses the one octet Type field and the two octet Length field.
メッセージの長さが1つのオクテットのタイプフィールド及び2つのオクテットの長さフィールドを含む3つのオクテットです。
If an MSDP message is received with a TLV format error, the session SHOULD be reset with that peer. MSDP messages with other errors, such as unrecognized type code, received from MSDP peers, SHOULD be silently discarded and the session SHOULD not be reset.
MSDPメッセージは、TLV形式エラーで受信された場合、セッションはそのピアにリセットされるべきです。そのような認識されていないタイプのコードのような他のエラーとMSDPメッセージは、MSDPピアから受信し、静かに捨てられるべきであり、セッションがリセットされるべきではありません。
As discussed earlier, TCP encapsulation of data in SA messages MAY be supported for backwards compatibility with legacy MSDP peers.
先に述べたように、SAメッセージ内のデータのTCPカプセル化は、レガシーMSDPピアとの後方互換性のためにサポートされるかもしれません。
MSDP is used primarily in two deployment scenarios:
MSDPは、2つの展開シナリオで主に使用されます。
MSDP can be used between PIM 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 rules described in this spec (i.e., does not use mesh-groups). Peerings can be aggregated on a single MSDP peer, typically from one to hundreds of peerings, similar in scale, although not necessarily consistent, with BGP peerings.
MSDPは、他のドメインで利用可能なアクティブなソースに関する情報を伝達するためにPIMドメイン間で使用することができます。このような場合に使用されるMSDPピアリングは、一のピアリングに一般に1であり、この仕様（すなわち、メッシュグループを使用していない）に記載決定的ピアRPFルールを利用します。ピアリングは、BGPピアリングと、ものの必ずしも一致しない、典型的には1からのスケールで同様のピアリング、数百、単一のMSDPピアに集約することができます。
MSDP is also used between 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 then also have additional one-to-one peering with msdp peers outside that PIM domain as described in scenario A, 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つ以上は、その後も、一対一の付加的な外部ソースの発見のために、シナリオAで説明したようにそのPIMドメインの外部MSDPピアとのピアリングを有していてもよいです。外部MSDPピアリングのないエニーキャストRP-ためMSDPは、有効なデプロイメントオプションと共通です。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
The editors would like to thank the original authors, Dino Farinacci, Yakov Rehkter, Peter Lothberg, Hank Kilmer, and Jermey Hall for their original contribution to the MSDP specification. In addition, Bill Nickless, John Meylor, Liming Wei, Manoj Leelanivas, Mark Turner, John Zwiebel, Cristina Radulescu-Banu, Brian Edwards, Selina Priestley, IJsbrand Wijnands, Tom Pusateri, Kristofer Warell, Henning Eriksson, Thomas Eriksson, Dave Thaler, and Ravi Shekhar provided useful and productive design feedback and comments. Toerless Eckert, Leonard Giuliano, Mike McBride, David Meyer, John Meylor, Pekka Savola, Ishan Wu, and Swapna Yelamanchi contributed to the final version of the document.
編集者は、MSDP仕様に元の貢献のためにオリジナルの作者、ディノファリナッチ、ヤコフRehkter、ピーター・ロスバーグ、ハンク・キルマー、およびJermeyホールに感謝したいと思います。また、ビルNickless、ジョンMeylor、黎明魏、ManojさんLeelanivas、マーク・ターナー、ジョンZwiebel、クリスティーナRadulescu - バヌ、ブライアン・エドワーズ、セリーナ・プリーストリー、IJsbrand Wijnands、トムPusateri、クリストファーWarell、ヘニング・エリクソン、トーマス・エリクソン、デーブターラー、そして、ラヴィシェカールは便利かつ生産的なデザインのフィードバックやコメントを提供しました。 Toerlessエッカート、レオナルドジュリアーノ、マイク・マクブライド、デヴィッド・メイヤー、ジョンMeylor、ペッカSavola、イシャン呉、およびSwapna Yelamanchiは、文書の最終版に貢献しました。
An MSDP implementation MUST implement Keyed MD5 [RFC2385] to secure control messages, and MUST be capable of interoperating with peers that do not support it. However, if one side of the connection is configured with Keyed MD5 and the other side is not, the connection SHOULD NOT be established.
MSDPの実装では、制御メッセージを確保するためにキー付きMD5 [RFC2385]を実装しなければならない、とそれをサポートしていないピアとの相互運用が可能でなければなりません。接続の一方の側は鍵付きMD5で構成されており、他の側ではない場合は、接続が確立されるべきではありません。
In addition, to mitigate state explosion during denial of service and other attacks, SA filters and limits SHOULD be used with MSDP to limit the sources and groups that will be passed between RPs [DEPLOY]. These filtering and limiting functions may include, for example, access lists of source or group addresses which should not be propagated to other domains using MSDP, the absolute highest acceptable number of SA-state entries or a rate-limit of for the creation of new SA-state entries after the connection has been established.
加えて、サービス及び他の妨害攻撃中状態爆発を緩和するために、SAフィルタおよび制限はのRP [DEPLOY]との間を通過するソースとグループを制限するためにMSDPして使用する必要があります。これらのフィルタリングおよび制限機能は、例えば、新規の作成にMSDP、SA-状態エントリの絶対最高許容数またはレート制限を使用して、他のドメインに伝播されるべきではないソースまたはグループアドレスのアクセスリストを含んでいてもよいです接続が確立された後にSA-状態エントリ。
If follow-on work is done in this area, a more robust integrity mechanism, such as HMAC-SHA1 [RFC2104, RFC2202] ought to be employed.
後続の作業はこの領域で行われている場合は、そのようなHMAC-SHA1 [RFC2104、RFC2202]などのより強固な整合性のメカニズムは、採用されるべきです。
This document creates a new namespace called "MSDP TLV Values" that the IANA will manage. The initial seven MSDP TLV values are specified in Section 12.2. The following two sections describe the rules for allocating new MSDP TLV values.
このドキュメントは、IANAが管理する「MSDP TLV値」と呼ばれる新しい名前空間を作成します。最初の7つのMSDP TLV値は、セクション12.2で指定されています。次の2つのセクションでは、新しいMSDP TLV値を割り当てるためのルールを記述します。
MSDP TLV values in the range [8,200] (inclusive) are to be allocated using an IESG Approval or Standards Action process [RFC2434].
範囲[8,200]（両端を含む）でMSDP TLV値はIESG承認または標準アクションプロセス[RFC2434]を使用して割り当てが行われます。
TLV values in the range [201,255] (inclusive) are allocated for experimental use.
範囲[201255]（含む）にTLV値は、実験的使用のために割り当てられます。
[RFC1142] Oran, D., Ed., "OSI IS-IS Intra-domain Routing Protocol", RFC 1142, February 1990.
[RFC1142]オラン、D.、エド。、RFC 1142、1990年2月 "OSIは、イントラドメインルーティングプロトコルIS-IS"。
[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月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[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のためのマルチプロトコルの拡張"、RFC 2858、2000年6月。
[RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Lin, C., Sharma, P. and L. Wei, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[RFC2362] Estrin、D.、ファリナッチ、D.、Helmy、A.、ターラー、D.、デアリング、S.、ハンドレー、M.、ヤコブソン、V.、リン、C.、シャルマ、P.、およびL.魏、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様"、RFC 2362、1998年6月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[RFC2365]マイヤー、D.、 "管理スコープのIPマルチキャスト"、BCP 23、RFC 2365、1998年7月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernanの、A.、 "TCP MD5署名オプションを使用してBGPセッションの保護"、RFC 2385、1998年8月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC3446] Kim, D., Meyer, D., Kilmer, H. and D. Farinacci, "Anycast Rendezvous Point (RP) Mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)", RFC 3446, January 2003.
[RFC3446]キム、D.、マイヤー、D.、キルマー、H.およびD.ファリナッチ、RFC 3446 "プロトコル独立マルチキャスト（PIM）とMulticast Source Discovery Protocol（MSDP）を使用したエニーキャストランデブーポイント（RP）メカニズム"、 2003年1月。
[DEPLOY] McBride, M., Meylor, J. and D. Meyer, "Multicast Source Discovery Protocol (MSDP) Deployment Scenarios", Work in Progress, July 2003.
[DEPLOY]マクブライド、M.、Meylor、J.およびD.マイヤー、 "マルチキャストソース発見プロトコル（MSDP）展開シナリオ"、進歩、2003年7月ワーク。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、ベラー、M。およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", RFC 2202, September 1997.
[RFC2202]チェン、P.およびR.グレン、 "HMAC-MD5とHMAC-SHA-1のテストケース"、RFC 2202、1997年9月。
Bill Fenner AT&T Labs -- Research 75 Willow Road Menlo Park, CA 94025
ビルフェナーAT＆T研究所 - 研究75ウィローロードメンロパーク、CA 94025
EMail: fenner@research.att.com
メールアドレス：fenner@research.att.com
David Meyer
デビッド・マイヤー
EMail: dmm@1-4-5.net
メールアドレス：dmm@1-4-5.net
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。