Network Working Group B. Fenner, Ed.
Request for Comments: 3618 D. Meyer, Ed.
Category: Experimental October 2003
Network Working Group B. Fenner, Ed.
Request for Comments: 3618 D. Meyer, Ed.
Category: Experimental October 2003
Multicast Source Discovery Protocol (MSDP)
多播源发现协议（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.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
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.
多播源发现协议（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
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
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
o 域的RP上没有第三方资源依赖关系
PIM-SM domains can rely on their own RPs only.
PIM-SM域只能依赖自己的RPs。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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连接组成，在该连接中交换控制信息。每个域都有一个或多个到此虚拟拓扑的连接。
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.
o RP的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，它将丢弃消息。否则，它会将消息转发给所有MSDP对等方（从中接收SA消息的那个除外）。
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.
当MSDP对等方（也是其自己域的RP）接收到新SA消息时，它会确定域内是否有任何组成员对SA消息中的（源、组）或（S、G）条目描述的任何组感兴趣。也就是说，RP检查带有非空传出接口列表的（*，G）条目；这意味着域中的某些系统对该组感兴趣。在这种情况下，RP向数据源触发一个（S，G）连接事件，就好像接收到了一条发送给RP本身的连接/删除消息一样。这将设置源树到此域的分支。随后的数据包通过该树分支到达RP，并沿着域内的共享树向下转发。如果叶路由器选择加入源树，它们可以根据现有的PIM-SM约定选择加入源树。最后，如果域中的RP接收到新组G的PIM Join消息，则RP应为其SA缓存中该组的每个活动（S，G）触发（S，G）Join事件。
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.
这个过程被亲切地命名为flood and join，因为如果任何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缓存用于减少风暴，并通过不转发SA来执行此操作，除非SA在缓存中或是MSDP扬声器将首次缓存的新SA数据包。SA缓存还通过以每个SA播发计时器间隔不超过两次且每个SA播发周期不少于1次的周期从缓存播发来减少风暴。
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消息的RPs就会定期这样做。有一个SA播发计时器，覆盖RP可能播发的源。[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公布期）内传播定期SA消息（即公布其为RP的活动源的消息）的生成。配置MSDP进程时，RP启动SA播发计时器。当计时器过期时，RP将计时器重置为[SA播发周期]秒，并开始播发其活动源。活动源以以下方式进行广告：RP将其活动源打包到SA消息中，直到生成可发送的最大MSDP数据包或没有其他源，然后发送消息。该过程在SA广告期内周期性地重复，以便广告RP的所有来源。请注意，由于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状态计时器。当MSDP对等方最初收到（S，G）-SA消息时，（S，G）-SA状态计时器启动。如果在（S，G）-SA状态计时器到期之前收到另一条（S，G）-SA消息，则计时器将重置为[SG状态周期]。[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
当对等方的传输连接建立时，保持计时器被初始化为[HoldTime Period]，当接收到任何MSDP消息时，保持计时器被重置为[HoldTime Period]。最后，计时器被激活
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.
对等方的传输连接关闭时删除。[保持时间段]必须至少为3秒。[HoldTime Period]的建议值为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传输连接，连接的每一方都会发送一条KeepAlive消息并设置一个KeepAlive计时器。如果KeepAlive计时器过期，本地系统将发送KeepAlive消息并重新启动其KeepAlive计时器。
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.
当对等方出现时，KeepAlive计时器设置为[KeepAlive Period]。每次向对等方发送MSDP消息时，计时器将重置为[KeepAlive Period]，并在计时器过期时重置。
Finally, the KeepAlive timer is deleted when the peer's transport connection is closed.
最后，当对等方的传输连接关闭时，KeepAlive计时器被删除。
[KeepAlive-Period] MUST be less than [HoldTime-Period], and MUST be at least one second. The recommended value for [KeepAlive-Period] is 60 seconds.
[KeepAlive Period]必须小于[HoldTime Period]，并且必须至少为1秒。[KeepAlive Period]的建议值为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.
具有较低IP地址的MSDP对等方使用ConnectRetry计时器从非活动状态转换为连接状态。每个对等机有一个计时器，[ConnectRetry Period]应设置为30秒。当MSDP扬声器试图主动打开与对等方的TCP连接时，计时器初始化为[ConnectRetry Period]（参见第15节，事件E2，动作A2）。当计时器过期时，对等方重试连接，计时器重置为[ConnectRetry Period]。如果连接转换为已建立状态或对等方已取消配置，则会删除该连接。
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，并且只有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
随着互联网上（S，G）对数量的增加，RP可能需要过滤SA消息中描述的源。此外，过滤可以作为一种策略使用，同时可以减少状态。传输域中的MSDP对等方不应筛选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.
消息或flood and join模型不能保证源在整个Internet上都是已知的（即，通过传输域进行SA过滤可能会导致不必要的连接缺失）。一般来说，应使用MBGP[RFC2858]表示策略。这将导致MSDP消息按所需方向流动，否则对等RPF将失败。管理范围[RFC2365]边界处发生异常。特别是，a（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寄存器封装的分组一样。也就是说，如果数据包已经通过接口到达源，那么该数据包将被丢弃。否则，如果传出接口列表为非空，则相应地转发数据包。注意，在进行数据封装时，实现必须限制封装数据包的时间。
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时，例如使用Anycast RP，可以在路由域中使用该方法。只要所有RPs都具有互连的MSDP拓扑，每个RPs都可以了解活动源以及其他域中的RPs。
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的internet转发SA消息。与转发数据包时使用的RPF检查（通常将数据包的源地址与接收数据包的接口进行比较）不同，对等RPF检查将SA消息中携带的RP地址与接收消息的MSDP对等方进行比较。
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邻居，则接受由R发起并由X从N接收的SA消息，否则将丢弃该消息。
MPP(R,N) MP(N,X)
R ---------....-------> N ------------------> X
SA(S,G,R) SA(S,G,R)
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之间的MSDP对等。MPP（R，N）是介于R和N之间的MSDP对等路径（零个或多个MSDP对等），例如，MPP（R，N）=MP（R，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是X相对于R if的RPF邻居
(i). N == R (X has an MSDP peering with R).
（i） 。N==R（X与R有一个MSDP对等）。
(ii). N is the eBGP NEXT_HOP of the Peer-RPF route for R.
(ii)。N是R的对等RPF路由的下一跳eBGP。
(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]).
(iii)。R的对等RPF路由通过距离向量或路径向量路由协议（例如BGP、RIP、DVMRP）学习，N是为R播发对等RPF路由的邻居（例如，N是R的路由的iBGP广告商），或者如果R的路由通过链路状态协议（例如OSPF[RFC2328]）学习，则N是R的IGP下一跳或IS-IS[RFC1142]）。
(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.
(四)。N位于最接近的AS中，位于通向R的最佳路径中。如果多个MSDP对等方位于最接近的AS中，则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.
（i） 。如果网格组M的成员R从同时也是网格组M成员的MSDP对等方接收SA消息，则R接受SA消息并将其转发给不属于网格组M的所有对等方。R不得将SA消息转发给网格组M的其他成员。
(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.
(ii)。如果网格组M的成员R从不是网格组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作为其传输协议。在对等关系中，一个MSDP对等方侦听已知端口639上的新TCP连接。另一端主动连接到此端口。IP地址较高的对等方将侦听。这种连接建立算法避免了呼叫冲突。因此，不需要调用冲突过程。然而，应该注意的是，这种方法的缺点是启动时间完全取决于活动端及其连接重试计时器；无源侧无法建立连接。
An MSDP peer starts in the DISABLED state. MSDP peers establish peering sessions according to the following state machine:
MSDP对等机在禁用状态下启动。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 \______/
--------------->+----------+
/ | 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）使用E2启用MSDP对等）自己的IP地址<P的IP地址E3）自己的IP地址>P的IP地址E4）TCP已建立（主动端）E5）TCP已建立（被动端）E6）连接重试计时器已过期E7）使用P禁用MSDP对等（例如，当自己的地址更改时）E8）保持计时器已过期E9）检测到MSDP TLV格式错误E10）检测到任何其他错误
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）为对等分配资源P比较自己和对等方的IP地址A2）TCP主动打开将ConnectRetry计时器设置为[ConnectRetry Period]A3）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) 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
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.
以下特定于对等方的事件可以在已建立状态下发生，它们不会导致状态转换。为每个事件列出了适当的操作。
*) 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
*) 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
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的定期传输->每次发送源活动TLV时将KeepAlive Timer设置为[KeepAlive Period]*）MSDP了解到新的活动内部源（例如，为新源接收的PIM-SM寄存器）：->发送源活动TLV->将KeepAlive Timer设置为[KeepAlive Period]*）SG状态计时器已过期（每个缓存条目一个计时器）：
-> 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 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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位）描述值字段的格式。
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)
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
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 | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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源活动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是8个八位字节（对于前两个32位量）加上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).
Entry Count是RP address字段后面的z条目的计数（如上所述）。这使得来自同一域的多个（S，G）可以有效地编码为同一RP地址。包含封装数据的SA消息的条目计数通常为1（即，对于表示封装数据包的（S，G），仅包含单个条目）。
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 Len与源地址关联的路由前缀长度。此字段必须以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.
当且仅当[KeepAlive Period]秒内没有向对等方发送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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
消息的长度为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.
如果收到带有TLV格式错误的MSDP消息，则应与该对等方重置会话。从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主要用于两种部署场景：
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对等通常是一对一对等，并利用本规范中描述的确定性对等RPF规则（即，不使用网格组）。对等可以聚合在单个MSDP对等上，通常从一个到数百个，规模与BGP对等相似，但不一定一致。
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还用于PIM域内的任意广播RP[RFC3446]之间，以同步关于每个任意广播RP对等方所服务的活动源的信息（凭借IGP可达性）。此场景中使用的MSDP对等通常基于MSDP网格组，其中两个到几十个对等可以组成给定的网格组，但不典型的情况是超过十个。然后，一个或多个网状组对等方还可以与该PIM域之外的msdp对等方进行额外的一对一对等，如场景A所述，以发现外部源。无外部MSDP对等的anycast 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
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。IETF关于标准跟踪和认证权利的程序信息
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.
与标准相关的文件可在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.
编辑们要感谢原始作者Dino Farinaci、Yakov Rehkter、Peter Lothberg、Hank Kilmer和Jermey Hall对MSDP规范的原始贡献。此外，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 Erikson、Thomas Erikson、Dave Thaler和Ravi Shekhar提供了有用且富有成效的设计反馈和评论。无趾埃克特、伦纳德·朱利亚诺、迈克·麦克布莱德、大卫·迈耶、约翰·梅洛、佩卡·萨沃拉、伊珊·吴和斯瓦普娜·耶拉曼奇为文件的最终版本做出了贡献。
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筛选器和限制与MSDP一起使用，以限制将在RPs[DEPLOY]之间传递的源和组。例如，这些过滤和限制功能可能包括不应使用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.
本文档创建了一个名为“MSDP TLV Values”的新名称空间，IANA将对其进行管理。第12.2节规定了最初的七个MSDP TLV值。以下两节介绍了分配新MSDP TLV值的规则。
MSDP TLV values in the range [8,200] (inclusive) are to be allocated using an IESG Approval or Standards Action process [RFC2434].
使用IESG批准或标准行动流程[RFC2434]分配范围为[8200]（含）的MSDP TLV值。
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]Oran，D.，编辑，“OSI IS-IS域内路由协议”，RFC1142，1990年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，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]Bates，T.，Rekhter，Y.，Chandra，R.和D.Katz，“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.，Farinaci，D.，Helmy，A.，Thaler，D.，Deering，S.，Handley，M.，Jacobson，V.，Lin，C.，Sharma，P.和L.Wei，“协议独立多播-稀疏模式（PIM-SM）：协议规范”，RFC 2362，1998年6月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[RFC2365]Meyer，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]Kim，D.，Meyer，D.，Kilmer，H.和D.Farinaci，“使用协议独立多播（PIM）和多播源发现协议（MSDP）的任意广播集合点（RP）机制”，RFC 3446，2003年1月。
[DEPLOY] McBride, M., Meylor, J. and D. Meyer, "Multicast Source Discovery Protocol (MSDP) Deployment Scenarios", Work in Progress, July 2003.
[DEPLOY]McBride，M.，Meylor，J.和D.Meyer，“多播源发现协议（MSDP）部署场景”，正在进行的工作，2003年7月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.和R.Canetti，“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]Cheng，P.和R.Glenn，“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号研究所，邮编94025
EMail: fenner@research.att.com
EMail: fenner@research.att.com
David Meyer
大卫·梅耶尔
EMail: dmm@1-4-5.net
EMail: 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编辑功能的资金目前由互联网协会提供。