Multicast Source Discovery Protocol (MSDP)
The Multicast Source Discovery Protocol (MSDP), an inter-domain multicast protocol, enables Rendezvous Points (RPs) in different PIM-SM domains to discover active multicast source information among them. RP is the point in the PIM-SM domain where the source and receivers meet to establish the multicast flow.
MSDP uses TCP port 639 for peering. Without MSDP, RPs in one domain would be unaware of active multicast sources in other domains, preventing the establishment of multicast peer paths across autonomous boundaries.
MSDP is required in PIM-SM Any-Source Multicast (ASM) domain mode, but is not necessary for Source-Specific Multicast (SSM) domain mode. Unlike ASM, SSM does not depend on RPs or inter-domain source discovery. Instead, the network can directly construct multicast forwarding trees based on the explicitly specified source and group.
Service providers whose multicast networks span multiple autonomous systems (AS) use MSDP to establish peering relationships for multicast exchange.
- MSDP speaker: the router within a PIM-SM domain that establishes an MSDP peering session with MSDP peers in other domains
- MSDP peer: the router that establishes a peering session with the MSDB speaker
- MSDP peering session:the TCP connection used for exchanging MSDP control information between peers.
- Source-Active
(SA) message: When an RP in a PIM-SM domain first
discovers a new sender (source), for example, through PIM register messages, it
generates a source-active (SA) message and forwards it to its MSDP peers. RPs that
originate SA messages continue to do so periodically as long as the source is
actively sending data. Although
the
SA message contains several fields, the most significant are:
-
source address (S) of the data source
-
group address (G) to which the source sends
-
IP address of the originating RP
-
- MSDP peer groups: MSDP peer groups are typically created when multiple peers have a set of common operational parameters. Group parameters that are not specifically configured are inherited from the global level.
- MSDP mesh groups: MSDP mesh groups are used to reduce SA flooding primarily in intra-domain configurations. When a number of speakers in an MSDP domain are fully meshed, they can be configured as a mesh group. The originator of the SA message forwards the message to all members of the mesh group. Because of this, forwarding the SA between non-originating members of the mesh group is not necessary.
MSDP procedure
The MSDB operational procedure is referred to as the flood-and-join procedure because the SA messages are flooded across MSDP peers, and only RPs with interested group members join the multicast distribution tree, while others ignore the SA message.
The sequence of events in the MSDB operational procedure is as follows:
- When an RP in a PIM-SM domain first discovers a new sender (source), for example, through PIM register messages, it generates a source-active (SA) message and forwards it to its MSDP peers.
- Each MSDP peer receives and forwards the SA message away from the RP address in a
peer-RPF flooding fashion. The peer-RPF flooding applies to forwarding SA messages.
The Multicast Routing Information Base (MRIB) is examined to determine which peer
toward the originating RP of the SA message is selected. Such a peer is called an
RPF peer. If the MSDP peer receives the SA message from a non-RPF peer toward the
originating RP, it drops the message. Otherwise, it forwards the message to all its
MSDP peers (except the one from which it received the SA message). For additional
rules, see Peer-RPF check.Note: In regular multicast RPF checks, the packet's source address is compared against the interface upon which the packet was received. In PIM-SM with MSDP implementation, the peer-RPF check compares the RP address carried in the SA message against the MSDP peer from which the message was received.
- An MSDP peer that is also an RP for its own domain receives a new SA message, and it determines if any group members within the domain are interested in any group described by an (S,G) entry within the SA message.
-
The RP (the receiving 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.
-
The RP (the receiving RP) triggers an (S,G) join event toward the data source as if a join or prune message addressed to the RP was received. This sets up a branch of the source tree for this domain.
-
Subsequent data packets arrive at the RP by 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. If an RP in a domain receives a PIM join message for a new group G, the RP must trigger an (S,G) join event for each active (S,G) for that group in its SA cache.
Peer-RPF check
Unlike the regular multicast RPF checks, the peer-RPF check stops SA messages from looping. An MSDP router validates SA messages originated from other routers in a deterministic fashion. When the router receives an SA message, it applies a set of rules to validate the SA message, and the first rule that applies determines the peer-RPF neighbor. All SA messages from other routers are rejected. The rules used to validate SA messages originating at Router S received at Router R from Router N are as follows:
- If the Router N and Router S are the same, the message is originated by a direct peer-RPF neighbor and is accepted.
- If Router N is a configured peer or a member of the Router R mesh group, its SA messages are accepted.
- If Router N is the Broader Gateway Protocol (BGP) next hop for the active multicast RPF route to Router S, then Router N is the peer-RPF neighbor, and its Source Active (SA) messages are accepted
- If Router N is an external BGP peer of Router R and the last autonomous system (AS) number in the BGP AS-path to Router S is the same as the AS number of Router N, Router N is the peer-RPF neighbor, and its SA messages are accepted.
- If Router N uses the same next hop as the next hop to Router S, Router N is the peer-RPF neighbor, and its SA messages are accepted.
- If Router N does not fit any of the preceding rules, it is not a peer-RPF neighbor, and its SA messages are rejected.
When a peer is configured as a default peer, all SA messages received from the peer are accepted without performing the preceding peer-RPF check.
MSDP peer scenarios
RFC 4611, Multicast Source Discovery Protocol (MSDP) Deployment Scenarios, describes how protocols interact to deliver intra- and inter-domain ASM services.
Inter-domain peering:
-
peering between PIM border routers (single-hop peering)
-
peering between non-border routers (multi-hop peering)
-
MSDP peering without BGP
-
MSDP peering between mesh groups
-
MSDP peering at a multicast exchange
Intra-domain peering:
-
peering between routers configured for both MSDP and MBGP
-
MSDP peer is not a BGP peer (meaning, no BGP peer)
MSDP configurations
MSDP is configured by enabling msdp.admin-state within the
network-instance.protocols context.
The MSDP (msdp) protocol allows the MSDP parameter configuration
only
in the default network instance type.
Configuring MSDP for a default network-instance
The minimum MSDP configuration requires enabling the
msdp.admin-state parameter under the
network-instance protocols context, configuring at least one
MSDP peer to establish an SA relationship, and setting a local address.
In the following configuration, MSDP is enabled with a standard group (srl_test) containing two peers (10.10.10.104 and 10.10.10.106) and an additional standalone peer (10.20.1.1) set to local address 10.20.1.6.
--{ + candidate shared default }--[ ]--
# info with-context network-instance default protocols msdp
network-instance default {
protocols {
msdp {
admin-state enable
group srl_test {
active-source-limit 50000
mode standard
receive-message-rate {
rate 100
time 300
threshold 5000
}
peer 10.10.10.104 {
}
peer 10.10.10.106 {
}
}
peer 10.20.1.1 {
local-address 10.20.1.6
}
}
}
}