Source Specific Multicast - SSM: What Is the Big Advantage?
Many designers of multicast topologies are looking at Source Specific Multicast, (SSM), as a preferred implementation for the right types of multicast applications. The applications most likely to use SSM are the ones known as one-to-many applications where there is a single source and multiple receivers. Common one-to-many applications are streaming video, streaming audio, and streaming stock ticker information with no multicast feedback control information.
If the receivers needed to become servers at any time, like in a collaborative application, (IE: audio/video conference), SSM would not be a good choice. That environment is called many-to-many, many sources to many receivers. Many-to-many applications create far too many multicast routing trees that use up router resources and are difficult to troubleshoot. Many-to-many applications are better served by ASM, “Any Source Multicast,” or PIM Bi-Directional implementations, but that will be a topic for another blog entry. ASM is the new description for Sparse Mode on the routers and IGMPv2 at the receivers.
The popularity of SSM has grown with the wide acceptance of IGMPv3. IGMPv3 is standard now on Windows PCs for operating systems Windows XP or higher. It is also standard on the latest versions of UNIX, Linux, MAC OS, and some Cable TV set top boxes. IGMPv3 allows the multicast client/receiver to not only specify the multicast group address it wants to receive, like IGMPv2, but also the source address it wants. Therefore, a rendezvous point, (RP), is not necessary like it is for ASM. The RP was always needed to bring the sources and receivers together, but that process is skipped if the receiver knows the source, prior to joining a group address. There are many ways to get the source address imbedded in the receiver’s OS.
SSM has major advantages for single autonomous systems implementations, (source and receivers are in the same AS), and since there is no need to configure an RP then an RP could not be the target of a denial of service attack. However, SSM has even greater advantages for multiple BGP AS implementations. With ASM, multiple BGP AS implementations with multiple RPs and sources in each AS would require using Multicast Source Discovery Protocol, (MSDP), so the RPs in each AS could learn about each other’s sources. MSDP requires advanced multicast configuration and troubleshooting knowledge and is needed for some applications, but if the application is one-to-many as previously stated then SSM can be used and MSDP can be avoided altogether. As long as they have routes to each other, a receiver in one BGP AS can simply specify a source in another BGP AS without involving the RPs first.
Multicast is still not widely used on the Internet backbone, as most ISPs do not have the personnel to configure or troubleshoot multicast. As demand for multicasts services increase, ISPs will hopefully join the party. As they do, I predict they will first support SSM implementations so they do not have to configure or troubleshoot RPs or MSDP.