Source Specific Multicast (PIM-SSM)
By stretch | Tuesday, July 27, 2010 at 1:15 a.m. UTC
Traditional multicast forwarding is performed using multicast group addresses. A group address is a single IP address taken from a reserved range (18.104.22.168/4 for IPv4, FF00::/8 for IPv6) to uniquely identify a group of hosts desiring to receive certain traffic. Any host within the multicast domain can be a source for a group, sending traffic to the group's IP address. Each multicast packet sent by the source is replicated by the network infrastructure so that each host belonging to the multicast group receives a copy. Because any host can act a source, this multicast implementation is deemed Any Source Multicast (ASM).
Source-Specific Multicast (SSM), defined in RFC 4607, extends this concept to identify a set of multicast hosts not only by group address but also by source. An SSM group, called a channel, is identified as (S,G) where S is the source address and G is the group address. This is in contrast to the definition of an ASM multicast route written as (*,G). IANA has reserved for SSM the IPv4 address range 22.214.171.124/8 and the IPv6 range FF3x::/32.
SSM brings several important benefits over ASM. Because an SSM channel is defined by both a source and a group address, group addresses can be re-used by multiple sources while keeping channels unique. For instance, the SSM channel (192.168.45.7, 126.96.36.199) is different than (192.168.3.104, 188.8.131.52), and hosts subscribed to one will not receive traffic from the other. This allows for greater flexibility in choosing a multicast group while also protecting against denial of service attacks; hosts will only receive traffic from explicitly requested sources.
One of the biggest advantages SSM holds over ASM is that it does not rely on the designation of a rendezvous point (RP) to establish a multicast tree. Because the source of an SSM channel is always known in advance, multicast trees are efficiently built from channel hosts toward the source (based on the unicast routing topology) without the need for an RP to join a source and shared multicast tree. The corollary of this, which may be undesirable in some multicast implementations, is that the multicast source(s) must be learned in advance via some external method (e.g. manual configuration).
SSM can be implemented using a subset of Protocol Independent Multicast (PIM) derived from PIM sparse mode (PIM-SM), dubbed PIM-SSM.
Once you have PIM-SM running, PIM-SSM is trivial to enable. This is done by specifying a range of addresses for which PIM-SSM will be used. Generally, you will want to enable PIM-SSM for it's default group range (184.108.40.206/8).
Router(config)# ip pim ssm default
An access list can be specified in place of the default range to enable PIM-SSM for a different range if desired.
We also must ensure that IGMPv3 is enabled on interfaces which connect to SSM clients.
Router(config-if)# ip igmp version 3
That's it! Now any requests to join a multicast group within the specified SSM range must specify a source address, and no shared trees will be built for these SSM channels.
About the Author
Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.
Posted in Multicast
July 27, 2010 at 12:24 p.m. UTC
Is this post the fruit of goofing around in the lab, or have you run into SSM in production somewhere? I'm curious whether anyone is actually using SSM, and for what sort of applications?
I've done lots of multicast, and I've never once run into an SSM application.
It doesn't make sense on a trading floor, where clients explicitly don't want to know who the sources of data are. Clients just tune into the stream, and assume that data will appear, and be complete. They don't care about sudden changes in the source IP. Redundancy is handled by the sources keeping tabs on each other, and filling in the gaps if one of their peers fails.
The enterprise IPTV rollout I'm working on now has both software and hardware playback devices. None of these clients is SSM-aware, but it would be super helpful. With SSM you could easily handle funny issues with network television: local news, blacked-out sporting events, etc...
July 27, 2010 at 9:44 p.m. UTC
Chrism you are rite but as for trading point of view once it understood by every network engineer around it will be rilly good addition i guess.
July 28, 2010 at 8:46 p.m. UTC
I ran into an ip telephony system that needed ssm to function. The piece of their callcenter software that let an attendant direct calls to specific extensions needed ssm. ( I believe this was a Nortel system of some kind )
July 28, 2010 at 8:47 p.m. UTC
Nice article Stretch ! I would just add that SSM > ASM because it has been decided to drop some features of ASM that made multicast network very hard to monitor / understand / debug (for example, the RP election...).
@chrism : Some French ISP uses SSM for their IPTV (Alice, for example, did...), but for historical reason, ASM remains in a lot of ISP... It's easy when the ISP owns the box to make the STB get (in http for example) the list of channels and the (S,G) associated to each one.
August 1, 2010 at 8:08 p.m. UTC
I have not worked with SSM within an enterprise environment however have worked with it within an SP core. SSM is used in conjunction with BGP and MDT when providing inter-AS and Intra-AS VPN multicast services. PIM-SM and bidir-PIM are not supported and all transit and edge routers must support SSM.
August 3, 2010 at 8:04 p.m. UTC
SSM is only required in inter-as not intra-as environments. I have seen customers use PIM-SM in their core and run MVPN as well. Although running PIM-SM or DM in your core with MVPN is an awful idea, they should still work.
August 4, 2010 at 5:22 p.m. UTC
In IPv6 environment MLD (multicast listener discovery) is used instead of IGMP.
I think MLD version 2 (RFC3810) is equivalent to IGMPv3 required for SSM, whereas MLD v2 (RFC2710) is functionally equivalent to IGMPv2
August 28, 2010 at 7:28 p.m. UTC
We use it extensively in our ip video networks, sources are multicast out to our edge devices and converted to RF to be sent out to the subscribers. It really works good when you need to use the same group IP and convert over to a different source, both pieces of video equipment can transmit at the same time and a quick change of the source ip on the receiver is all it takes to convert over. I would imagine most video providers use it on everything.
February 16, 2011 at 8:00 a.m. UTC
There is a couple of things Im struggling to get my head around with SSM. I hope someone can help.
Im looking for ways of supporting IPTV broadcasts in an enterprise network.
If a carrier MPLS network does not support SSM or ASM, but the Enterprise routers do support SSM, does SSM still work ? E.G If the ISP doesnt implement SSM, will there be only one data stream between the Host connected (SSM) router and client connected (SSM) router, when there are multiple clients ?
Also is the MS Windows Media Server smart enough to know when clients dont support IGMPv3 and deliver a unicast stream or just block it ?
May 23, 2011 at 8:57 p.m. UTC
Thanks a lot for the information Jeremy, I have also started a Blog Inspired from you all CCIEs. I have read lot of your posts they are very intresting and very helpful. I have my Blog sumankedala.blogspot.com if you find time please let me know if any changes are required, few posts of mine I have collected from other sites and MPLS post I have written. You have helped me a lot with you posts.
April 20, 2012 at 6:35 a.m. UTC
Cool post but the link is dead to the cisco configuration guide.
April 15, 2013 at 7:21 p.m. UTC
excellent post, thanks alot.
May 8, 2014 at 6:06 a.m. UTC
When IGMPv3 host sends a join with "exclude NULL", how does pim router act? Will it send join towards all the neighbors?
March 30, 2016 at 6:09 a.m. UTC
Do we need to configure “ip pim ssm default” only on edge routers(where multicast source and receivers are connected), or all routers within the network.