PIM-SSM stands for Protocol Independent Multicast – Source Specific Multicast. It is a variation of PIM-SM protocol in the way it does not require any of the PIM-SM features such as rendez-vous point and shared trees (related to ASM, Any Source Multicast).
The ASM model is to deliver the packet in a “many-to-many” fashion. With SSM (source specific) it is “one-to-many” fashion, where one identified source sends packets to its receivers.
PIM-SSM uses a dedicated range: 220.127.116.11/8.
If the multicast group is not in this range, PIM-SSM will not work.
PIM-SSM is based upon IGMPv3 (MLDv2 is the IPv6 equivalent). Recall that IGMP (Internet Group Message Protocol) is the protocol used between the hosts and the routers to request and report their membership/subscription to a multicast group. The main modifications brought by IGMPv3 (RFC3376) are done in the “membership query” and the “v3 membership report”. The other requests that were defined with IGMPv1/v2 are still present. The membership query in version 3 allows the specification of a source in the IGMP packet for the selected group. Let’s compare both packet headers:
As you can see it is possible to configure multiple sources for a group with PIM-SSM / IGMPv3.
I see a simple use case for this protocol : imagine a medium-sized LAN environment where you have a video multicast feed to broadcast to IPTV screens (company’s internal news feed for example). Such deployment may not require all the features and the scalability offered by PIM-SM and its rendez-vous points. Hence it requires a more optimized way to transmit the packet than PIM-DM. PIM-SSM could be the way to go! The following diagram explain my idea.
Enough talking, I will use the following topology as lab environment for this PIM-SSM session:
R1 – intermediate router
R2 – multicast source loopback 10
R3 – multicast receiver configured on f0/0
To activate PIM-SSM on a Cisco router, you can do
ip multicast-routing ! ip pim ssm default
The default keyword is to listen for the whole 232/8 range, but you can narrow down the scope using an ACL.
On the interfaces, you need to activate PIM-SM and IGMPv3
R2# interface Loopback10 ip address 10.10.2.2 255.255.255.0 ip pim sparse-mode ip igmp version 3 ! interface FastEthernet0/0 ip address 18.104.22.168 255.255.255.0 ip pim sparse-mode R1# interface FastEthernet0/0 ip address 22.214.171.124 255.255.255.0 ip pim sparse-mode ! interface FastEthernet1/0 ip address 126.96.36.199 255.255.255.0 ip pim sparse-mode R3# interface FastEthernet0/0 ip address 188.8.131.52 255.255.255.0 ip pim sparse-mode ip igmp version 3
Then I force a receiver to join, specifying the source:
interface f0/0 ip igmp join-group 184.108.40.206 source 10.10.2.2
And then try to ping from R2:
R2#ping 220.127.116.11 source 10.10.2.2 repeat 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 18.104.22.168, timeout is 2 seconds: Packet sent with a source address of 10.10.2.2 Reply to request 0 from 22.214.171.124, 164 ms Reply to request 0 from 126.96.36.199, 168 ms Reply to request 1 from 188.8.131.52, 76 ms Reply to request 1 from 184.108.40.206, 76 ms Reply to request 2 from 220.127.116.11, 64 ms Reply to request 2 from 18.104.22.168, 68 ms Reply to request 3 from 22.214.171.124, 76 ms Reply to request 3 from 126.96.36.199, 76 ms Reply to request 4 from 188.8.131.52, 148 ms Reply to request 4 from 184.108.40.206, 152 ms Reply to request 5 from 220.127.116.11, 88 ms Reply to request 5 from 18.104.22.168, 92 ms Reply to request 6 from 22.214.171.124, 128 ms Reply to request 6 from 126.96.36.199, 128 ms Reply to request 7 from 188.8.131.52, 92 ms Reply to request 7 from 184.108.40.206, 92 ms Reply to request 8 from 220.127.116.11, 120 ms Reply to request 8 from 18.104.22.168, 124 ms Reply to request 9 from 22.214.171.124, 124 ms Reply to request 9 from 126.96.36.199, 124 ms