- play_arrow Overview
- play_arrow Managing Group Membership
- play_arrow Configuring IGMP and MLD
- play_arrow Configuring IGMP Snooping
- IGMP Snooping Overview
- Overview of Multicast Forwarding with IGMP Snooping or MLD Snooping in an EVPN-VXLAN Environment
- Configuring IGMP Snooping on Switches
- Example: Configuring IGMP Snooping on Switches
- Example: Configuring IGMP Snooping on EX Series Switches
- Verifying IGMP Snooping on EX Series Switches
- Changing the IGMP Snooping Group Timeout Value on Switches
- Monitoring IGMP Snooping
- Example: Configuring IGMP Snooping
- Example: Configuring IGMP Snooping on SRX Series Devices
- Configuring Point-to-Multipoint LSP with IGMP Snooping
- play_arrow Configuring MLD Snooping
- Understanding MLD Snooping
- Configuring MLD Snooping on an EX Series Switch VLAN (CLI Procedure)
- Configuring MLD Snooping on a Switch VLAN with ELS Support (CLI Procedure)
- Example: Configuring MLD Snooping on EX Series Switches
- Example: Configuring MLD Snooping on SRX Series Devices
- Configuring MLD Snooping Tracing Operations on EX Series Switches (CLI Procedure)
- Configuring MLD Snooping Tracing Operations on EX Series Switch VLANs (CLI Procedure)
- Example: Configuring MLD Snooping on EX Series Switches
- Example: Configuring MLD Snooping on Switches with ELS Support
- Verifying MLD Snooping on EX Series Switches (CLI Procedure)
- Verifying MLD Snooping on Switches
- play_arrow Configuring Multicast VLAN Registration
-
- play_arrow Configuring Multicast Routing Protocols
- play_arrow Connecting Routing Domains Using MSDP
- play_arrow Handling Session Announcements with SAP and SDP
- play_arrow Facilitating Multicast Delivery Across Unicast-Only Networks with AMT
- play_arrow Routing Content to Densely Clustered Receivers with DVMRP
-
- play_arrow Configuring Multicast VPNs
- play_arrow Configuring Draft-Rosen Multicast VPNs
- Draft-Rosen Multicast VPNs Overview
- Example: Configuring Any-Source Draft-Rosen 6 Multicast VPNs
- Example: Configuring a Specific Tunnel for IPv4 Multicast VPN Traffic (Using Draft-Rosen MVPNs)
- Example: Configuring Source-Specific Draft-Rosen 7 Multicast VPNs
- Understanding Data MDTs
- Example: Configuring Data MDTs and Provider Tunnels Operating in Any-Source Multicast Mode
- Example: Configuring Data MDTs and Provider Tunnels Operating in Source-Specific Multicast Mode
- Examples: Configuring Data MDTs
- play_arrow Configuring Next-Generation Multicast VPNs
- Understanding Next-Generation MVPN Network Topology
- Understanding Next-Generation MVPN Concepts and Terminology
- Understanding Next-Generation MVPN Control Plane
- Next-Generation MVPN Data Plane Overview
- Enabling Next-Generation MVPN Services
- Generating Next-Generation MVPN VRF Import and Export Policies Overview
- Multiprotocol BGP MVPNs Overview
- Configuring Multiprotocol BGP Multicast VPNs
- BGP-MVPN Inter-AS Option B Overview
- ACX Support for BGP MVPN
- Example: Configuring MBGP MVPN Extranets
- Understanding Redundant Virtual Tunnel Interfaces in MBGP MVPNs
- Example: Configuring Redundant Virtual Tunnel Interfaces in MBGP MVPNs
- Understanding Sender-Based RPF in a BGP MVPN with RSVP-TE Point-to-Multipoint Provider Tunnels
- Example: Configuring Sender-Based RPF in a BGP MVPN with RSVP-TE Point-to-Multipoint Provider Tunnels
- Example: Configuring Sender-Based RPF in a BGP MVPN with MLDP Point-to-Multipoint Provider Tunnels
- Configuring MBGP MVPN Wildcards
- Distributing C-Multicast Routes Overview
- Exchanging C-Multicast Routes
- Generating Source AS and Route Target Import Communities Overview
- Originating Type 1 Intra-AS Autodiscovery Routes Overview
- Signaling Provider Tunnels and Data Plane Setup
- Anti-spoofing support for MPLS labels in BGP/MPLS IP VPNs (Inter-AS Option B)
- BGP-MVPN SD-WAN Overlay
- play_arrow Configuring PIM Join Load Balancing
- Use Case for PIM Join Load Balancing
- Configuring PIM Join Load Balancing
- PIM Join Load Balancing on Multipath MVPN Routes Overview
- Example: Configuring PIM Join Load Balancing on Draft-Rosen Multicast VPN
- Example: Configuring PIM Join Load Balancing on Next-Generation Multicast VPN
- Example: Configuring PIM Make-Before-Break Join Load Balancing
- Example: Configuring PIM State Limits
-
- play_arrow General Multicast Options
- play_arrow Bit Index Explicit Replication (BIER)
- play_arrow Prevent Routing Loops with Reverse Path Forwarding
- play_arrow Use Multicast-Only Fast Reroute (MoFRR) to Minimize Packet Loss During Link Failures
- play_arrow Enable Multicast Between Layer 2 and Layer 3 Devices Using Snooping
- play_arrow Configure Multicast Routing Options
- play_arrow Controller-Based BGP Multicast Signaling
-
- play_arrow Troubleshooting
- play_arrow Knowledge Base
-
- play_arrow Configuration Statements and Operational Commands
Understanding PIM Source-Specific Mode
PIM source-specific multicast (SSM) uses a subset of PIM sparse mode and IGMP version 3 (IGMPv3) to allow a client to receive multicast traffic directly from the source. PIM SSM uses the PIM sparse-mode functionality to create an SPT between the receiver and the source, but builds the SPT without the help of an RP.
Any Source Multicast (ASM) was the Original Multicast
RFC 1112, the original multicast RFC, supported both many-to-many and one-to-many models. These came to be known collectively as any-source multicast (ASM) because ASM allowed one or many sources for a multicast group's traffic. However, an ASM network must be able to determine the locations of all sources for a particular multicast group whenever there are interested listeners, no matter where the sources might be located in the network. In ASM, the key function of source discovery is a required function of the network itself.
Source Discovery in Sparse Mode vs Dense Mode
Multicast source discovery appears to be an easy process, but in sparse mode it is not. In dense mode, it is simple enough to flood traffic to every router in the whole network so that every router learns the source address of the content for that multicast group. However, the flooding presents scalability and network resource use issues and is not a viable option in sparse mode.
PIM sparse mode (like any sparse mode protocol) achieves the required source discovery functionality without flooding at the cost of a considerable amount of complexity. RP routers must be added and must know all multicast sources, and complicated shared distribution trees must be built to the RPs.
PIM SSM is a Subset of PIM Sparse Mode
PIM SSM is simpler than PIM sparse mode because only the one-to-many model is supported. Initial commercial multicast Internet applications are likely to be available to subscribers (that is, receivers that issue join messages) from only a single source (a special case of SSM covers the need for a backup source). PIM SSM therefore forms a subset of PIM sparse mode. PIM SSM builds shortest-path trees (SPTs) rooted at the source immediately because in SSM, the router closest to the interested receiver host is informed of the unicast IP address of the source for the multicast traffic. That is, PIM SSM bypasses the RP connection stage through shared distribution trees, as in PIM sparse mode, and goes directly to the source-based distribution tree.
Why Use PIM SSM
In an environment where many sources come and go, such as for a videoconferencing service, ASM is appropriate. However, by ignoring the many-to-many model and focusing attention on the one-to-many source-specific multicast (SSM) model, several commercially promising multicast applications, such as television channel distribution over the Internet, might be brought to the Internet much more quickly and efficiently than if full ASM functionality were required of the network.
An SSM-configured network has distinct advantages over a traditionally configured PIM sparse-mode network. There is no need for shared trees or RP mapping (no RP is required), or for RP-to-RP source discovery through MSDP.
PIM SSM is simpler than PIM sparse mode because only the one-to-many model is supported. Initial commercial multicast Internet applications are likely to be available to subscribers (that is, receivers that issue join messages) from only a single source (a special case of SSM covers the need for a backup source). PIM SSM therefore forms a subset of PIM sparse mode. PIM SSM builds shortest-path trees (SPTs) rooted at the source immediately because in SSM, the router closest to the interested receiver host is informed of the unicast IP address of the source for the multicast traffic. That is, PIM SSM bypasses the RP connection stage through shared distribution trees, as in PIM sparse mode, and goes directly to the source-based distribution tree.
PIM Terminology
PIM SSM introduces new terms for many of the concepts in PIM sparse mode. PIM SSM can technically be used in the entire 224/4 multicast address range, although PIM SSM operation is guaranteed only in the 232/8 range (232.0.0/24 is reserved). The new SSM terms are appropriate for Internet video applications and are summarized in Table 1.
Term | Any-Source Multicast | Source-Specific Multicast |
|---|---|---|
Address identifier | G | S,G |
Address designation | group | channel |
Receiver operations | join, leave | subscribe, unsubscribe |
Group address range | 224/4 excluding 232/8 | 224/4 (guaranteed only for 232/8) |
Although PIM SSM describes receiver operations as subscribe and subscriber, the same PIM sparse mode join and leave messages are used by both forms of the protocol. The terminology change distinguishes ASM from SSM even though the receiver messages are identical.
How PIM SSM Works
PIM source-specific multicast (SSM) uses a subset of PIM sparse mode and IGMP version 3 (IGMPv3) to allow a client to receive multicast traffic directly from the source. PIM SSM uses the PIM sparse-mode functionality to create an SPT between the receiver and the source, but builds the SPT without the help of an RP.
By default, the SSM group multicast address is limited to the IP address range from 232.0.0.0 through 232.255.255.255. However, you can extend SSM operations into another Class D range by including the ssm-groups statement at the [edit routing-options multicast] hierarchy level. The default SSM address range from 232.0.0.0 through 232.255.255.255 cannot be used in the ssm-groups statement. This statement is for adding other multicast addresses to the default SSM group addresses. This statement does not override the default SSM group address range.
In a PIM SSM-configured network, a host subscribes to an SSM channel (by means of IGMPv3), announcing a desire to join group G and source S (see Figure 1). The directly connected PIM sparse-mode router, the receiver's DR, sends an (S,G) join message to its RPF neighbor for the source. Notice in Figure 1 that the RP is not contacted in this process by the receiver, as would be the case in normal PIM sparse-mode operations.
The (S,G) join message initiates the source tree and then builds it out hop by hop until it reaches the source. In Figure 2, the source tree is built across the network to Router 3, the last-hop router connected to the source.
Using the source tree, multicast traffic is delivered to the subscribing host (see Figure 3).
Using PIM SSM
You can configure Junos OS to accept any-source multicast (ASM) join messages (*,G) for group addresses that are within the default or configured range of source-specific multicast (SSM) groups. This allows you to support a mix of any-source and source-specific multicast groups simultaneously.
Deploying SSM is easy. You need to configure PIM sparse mode on all router interfaces and issue the necessary SSM commands, including specifying IGMPv3 on the receiver's LAN. If PIM sparse mode is not explicitly configured on both the source and group member interfaces, multicast packets are not forwarded. Source lists, supported in IGMPv3, are used in PIM SSM. As sources become active and start sending multicast packets, interested receivers in the SSM group receive the multicast packets.
To configure additional SSM groups, include the ssm-groups statement at the [edit routing-options multicast] hierarchy level.
