Multicast Source Discovery Protocol (MSDP) is a protocol designed to address the interconnection among multiple PIM-SM multicast domains. The goal of this protocol is to help a multicast domain to discover information about multicast sources located in other PIM-SM multicast domains.
MSDP is a fundamental piece in an inter-domain multicast solution. The applicability of MSDP is limited to the Any Source Multicast (ASM) model with PIM-SM as the intra-domain multicast routing protocol. Another important applicability point to consider is that MSDP is designed to work with IPv4, and there is not an IPv6 version.
Let’s start first with a brief introduction to the problem solved by MSDP, followed by a simple example of an Interdomain multicast case using MSDP and some important MSDP design considerations.
In the ASM model with PIM-SM, the receiver Designated Router (DR) sends joins messages to the RP in response to the receiver interest in receiving some group G. This results in the construction of a shared tree from the RP to the receivers. When a source starts transmitting, the source DR registers to the RP, letting know its presence and starting the process of data flow down the shared tree to the receivers. The point here is that the RP is the central point of the PIM-SM multicast domain that obtains all the information about the interested receivers and all the active sources.
For several reasons (security, efficiency, etc.), the network administration may decide to split up the multicast domain in two different PIM-SM domains. After that, the RP in different multicast domains will be isolated and they won’t have access to multicast source information from any other domains. MSDP solves the problem of source discovery between isolated multicast domains.
The figure shows two PIM-SM domains in two different AS. MSDP may be used in this scenario to provide an inter-domain multicast solution. With MSDP, remote RP can discover active multicast sources in other domains, enabling multicast traffic delivery to the interested local receivers.
A brief explanation of the pictured steps:
- Receiver joins to (*,G).
- MSDP peering in place, with MBGP in parallel to ensure peer-RPF check PASS.
- Source appears and registers to its local RP.
- MSDP shares information about sources with peers via MSDP SA messages.
- Remote RP joins the source (S,G) and starts delivering multicast traffic via shared tree to interested receivers.
- Remote FHR (LHR in the data path) may decide to join the Source if the SPT switchover is enabled, resulting in inter-domain optimal multicast data flow.
The MSDP peering is established between routers to share multicast source information (TCP 639). The peering is usually configured between RP devices, but any other router can be a MSDP peer too. Once the source is discovered PIM-SM mechanisms allows multicast users in one domain to receive multicast data from sources located in remote domains.
MSDP brings some other important functionalities with it, like Anycast RP. Anycast RP provides redundancy and load sharing functionality to high availability scenarios. Basically, it allows several RP in the same domain to share the same IP address. Setting up MSDP peers between RP, the multicast sources register… and the multicast receivers join... to the closest RP, ending up in a load balanced with RP redundancy scenario.
Reverse Path Forwarding Rules
MSDP peers must follow the peer-RPF forwarding rues to avoid MSDP SA message looping conditions.
In some cases, the peer-RPF check may be avoided. This should happen in the following cases:
- The MSDP peer is the Originating RP of the MSDP SA message.
- The MSDP peer is a mesh-group peer (in this case the receiver device doesn’t forward the MSDP SA message to any other mesh group member).
- The MSDP peer is configured as the default MSDP peer.
- The MSDP peer is the one and only MSDP peer configured.
When MSDP is used in combination with MBGP to ensure peer-RPF check pass, the following rules apply:
Sending MSDP peer
Condition to pass the peer-RPF check
MSDP peer address == BGP peer address
First AS in the path to RP == MSDP peer AS
Not a BGP peer
First AS in the path to RP == Sending MSDP peer AS
In the RPF calculation is important to consider the preference of the different routing tables:
- Static Mroute
The multicast routing information base (MRIB) is always checked before the unicast RIB (URIB). If there is no path on any table to the MSDP peer, then the peer-RPF will fail and the MSDP SA message will be discarded.
MSDP mesh groups help to reduce the number of MSDP SA messages that circulates among MSDP peers. It’s basically a MSDP optimization mechanism to reduce the control traffic transported by the network.
MSDP peers are configured in full-mesh configuration and its members can be in the same or in different multicast domains as well on the same or different AS.
The peer-RPF check for mesh group members is a bit different than in a nonmember. After the reception of the MSDP SA message, the source of the peer is checked:
- If the MSDP peer is an outsider, then perform a peer-RPF check. If the check PASS, then forward the message to all mesh group members; else drop.
- If the MSDP peer is a mesh group member, then accept the MSDP SA message without peer-RPF check (and do not forward the message to any other member of the mesh group).
Interdomain multicast within an AS
This is one of the typical MSDP use cases. Two PIM-SM multicast domains administratively isolated within the same AS.
In this case, as each RP has only one MSDP peer, the IBGP session to perform the peer-RPF check is optional. The MSDP SA messages are automatically accepted without any check (see RPF rules section).
Interdomain multicast among different AS
In this case the source information is distributed among different multicast domains, some of them in the same AS and some in remote AS. In this case MSDP in combination with MBGP in parallel could be used.
The MBGP parallel the MSDP peer relationships to ensure the RPF check success.
MSDP enabled remote source discovery and opened the possibility to modularize and isolate different multicast domains that may or not be spread among autonomous systems. Let’s review some of the design advantages derived from using MSDP:
- Modularity & isolation: a network may be designed with different PIM-SM domains, each one independent from each other from the functionality point of view. As each domain uses its own RP, local sources and interested receivers can work independently. Modularity and isolation between modules can help in case of failure contention and clear choke points between modules reduce the Mean Time to Repair (MTTR).
- Security: from the security point of view, the network administration can decide if the multicast source information of one domain is shared or not with other domains within their own AS or with remote AS.
- Efficiency: interested receivers within a multicast domain can signal their interest in receiving information about a multicast group to their local RP. This way, the state of the network is kept lower and distributed among multicast domains.
Last but not least, MSDP applications like Anycast RP provide for redundancy and load-balancing functionality to RP deployments. Anycast RP is available for IPv4 and IPv6, but MSDP it’s not, so in IPv6 scenarios an extension of PIM should be used to provide that kind of functionality.
I hope you find it useful