Skip to main content

Multicast - MSDP (8)

The Problem: Multicast Across Different Internet Companies

In a single network, PIM Sparse Mode uses a Rendezvous Point (RP) as a central meeting place to connect sources and receivers.

However, when multiple Internet Service Providers (ISPs) or separate companies (domains) need to share multicast traffic (like a live video stream across the global internet), building one giant shared tree across the entire internet is impossible. ISPs cannot share control of their core routers with competitors due to security, management, and scalability boundaries.

image.png

The Solution: Multicast Source Discovery Protocol (MSDP)

Instead of forcing everyone to share one massive tree, MSDP allows each internet domain to run its own independent PIM-SM network with its own local RP.

The internet domains then connect to each other using interdomain source trees (SPTs) instead of shared trees. The only remaining challenge is letting an RP in one domain know that a source has started broadcasting inside a completely different domain. MSDP acts as the announcer between these RPs.

Core MSDP Mechanics and Rules

  • PIM-SM Only: MSDP depends entirely on RPs knowing about local sources and receivers, meaning it only functions alongside PIM Sparse Mode.

  • TCP Connection Sessions: MSDP peers (the RPs of different domains) connect and talk to each other over reliable TCP connections (User Datagram Protocol/UDP encapsulation is an option).

  • Source-Active (SA) Messages: When a local source starts transmitting, the local RP creates a Source-Active (SA) message listing the Source IP and Group IP (S, G). This message is sent to all MSDP peers every 60 seconds as long as the source stays active.

  • Peer-RPF Check (Loop Prevention): To prevent SA messages from looping endlessly around the internet, an RP performs a strict Peer-RPF check when an SA message arrives. The router inspects its BGP/MP-BGP routing tables to see if the message arrived from the true next-hop path back to the originating RP.

    • Pass: The message is processed and flooded downstream to other MSDP peers.

    • Fail: The message is instantly dropped.

    • Exception: Stub domains (networks with only a single exit path to the internet) skip this check because loops are physically impossible there.

  • SA Caching: RPs can optionally store received SA messages in a local cache. This drastically reduces join latency. When a local receiver joins a group, the RP can check its cache to find the source immediately instead of waiting up to 60 seconds for the next periodic SA advertisement. Non-caching RPs can query caching RPs within the same domain.

The Complete Step-by-Step Interdomain Workflow

The following steps and images illustrate the exact lifecycle of an interdomain multicast stream across five PIM-SM domains (A through E):

Step 1: The Receiver Signals Interest

A host in Domain E wants to watch a stream. It sends an IGMP report to its local last-hop router. The last-hop router sends a standard PIM (*, G) join up to the Domain E RP, building a local shared tree branch inside Domain E.

image.png

Step 2: The Source Goes Active

A source server inside Domain B begins transmitting data. Its local first-hop router catches the packets and sends a standard PIM Register message to the Domain B RP. The Domain B RP now knows a source is live.

Step 3: The MSDP Announcement Floods the Internet

The Domain B RP originates an (S, G) Source-Active (SA) message and sends it over TCP to its MSDP peers. The message floods from domain to domain. If an identical SA message arrives at Domain C from a suboptimal path, it fails the Peer-RPF check and is dropped, ensuring loop-free delivery until a valid copy safely reaches Domain E's RP.

image.png

Step 4: The Remote RP Connects the Dots

The Domain E RP receives the SA message. It scans its multicast routing table and realizes it has an active (*, G) shared tree waiting for that exact group.

Step 5: Building the Interdomain Source Tree

Domain E's RP fires a standard PIM (S, G) join out toward the source's domain. This join message travels hop-by-hop across the internet using Multiprotocol BGP (MP-BGP) tables to find the shortest path back to the source. This builds a native interdomain Source Tree (SPT) across the internet.

image.png

Step 6: Traffic Flows Natively

Multicast data flows natively along the new internet-wide SPT from the source directly to Domain E's RP. From there, the RP pushes the data down its local shared tree branch to the waiting receiver host.

image.png

Step 7: The Final SPT Switchover Shortcut

By default, the PIM traffic threshold on the last-hop router is set to 0. The moment the very first multicast data packet hits the last-hop router in Domain E, the router triggers an immediate SPT switchover. It sends a direct PIM (S, G) join across the internet straight to the source, completely bypassing Domain E's RP to establish the shortest, lowest-latency path possible.

image.png

How This Design Meets ISP Architecture Requirements

ISPs use a combination of three distinct protocols to cleanly deliver global interdomain multicast:

  • PIM-SM: Provides an explicit pull/join protocol, ensuring traffic is only sent to networks that actively request it, maximizing bandwidth efficiency.

  • MP-BGP (Multiprotocol BGP): Allows ISPs to use their existing, trusted unicast BGP routing infrastructure and tools to safely calculate loop-free paths for multicast traffic.

  • MSDP: Provides maximum deployment flexibility. It guarantees that competing networks never have to share a central Rendezvous Point, allowing each domain to maintain independent control over its own internal RP placement.

Back to top