There are two sparse-mode routing protocols:
- Protocol Independent Multicast Sparse Mode (PIM-SM)
- Core-Based Tree (CBT)
This article covers the operation of PIM-SM.
Operation of Protocol Independent Multicast Sparse Mode
PIM-SM works with a completely opposite strategy from that of PIM-DM, although the mechanics of the protocol are not exactly opposite. PIM-SM assumes that no hosts want to receive multicast packets until they specifically ask to receive them. As a result, until a host in a subnet asks to receive multicasts for a particular group, multicasts are never delivered to that subnet.
With PIM-SM, downstream routers must request to receive multicasts using PIM Join messages. Also, after they are receiving those messages, the downstream router must continually send Join messages to the upstream router; otherwise, the upstream router stops forwarding, putting the link in a pruned state. This process is opposite to that used by PIM-DM, in which the default is to flood multicasts, with downstream routers needing to continually send Prunes or State Refresh messages to keep a link in a pruned state.
Similarities Between PIM-DM and PIM-SM
PIM-SM has many similarities to PIM-DM. Like PIM-DM, PIM-SM uses the unicast routing table to perform RPF checks—regardless of what unicast routing protocol populated the table. Like PIM-DM, the “protocol independent” part of the PIM acronym comes from the fact that PIM-SM is not dependent on any particular unicast IP routing protocol.
In addition, PIM-SM also uses the following mechanisms that are used by PIM-DM:
- PIM Neighbor discovery through exchange of Hello messages.
- Recalculation of the RPF interface when the unicast routing table changes.
- Election of a DR on a multiaccess network. The DR performs all IGMP processes when IGMPv1 is in use on the network.
- The use of Prune Overrides on multiaccess networks.
- Use of Assert messages to elect a designated forwarder on a multiaccess network.
Sources Sending Packets to the Rendezvous Point
PIM-SM uses a two-step process to initially deliver multicast packets from a particular source to the hosts wanting to receive packets. Later, the process is improved beyond these initial steps. The steps for the initial forwarding of multicasts with PIM-SM are as follows:
- Sources send the packets to a router called the rendezvous point (RP).
- The RP sends the multicast packets to all routers/hosts that have registered to receive packets for that group. This process uses a shared tree.
In this example, the router near the source (R1) is attempting to register with the RP, but the RP tells R1 not to bother anymore, because no one wants those multicast messages. R1 has not forwarded any of the native multicast messages at this point, in keeping with the PIM-SM strategy of not forwarding multicasts until a host has asked for them.
Joining the Shared Tree
The root-path tree (RPT) is a tree, with the RP at the root that defines over which links multicasts should be forwarded to reach all required routers. One such tree exists for each multicast group that is currently active in the internetwork. So, after the multicast packets sent by each source are forwarded to the RP, the RP uses the RPT for that multicast group to determine where to forward these packets.
PIM-SM routers collectively create the RPT by sending PIM Join messages toward the RP. PIM-SM routers choose to send a Join under two conditions:
- When a PIM-SM router receives a PIM Join message on any interface other than the interface used to route packets toward the RP.
- When a PIM-SM router receives an IGMP Membership Report message from a host on a directly connected subnet
Completion of the Source Registration Process
This section of the article completes the story by showing how an RP reacts to a PIM Register message when the RP knows that some hosts want to receive those multicasts.
When the RP receives a Register message for an active multicast group—in other words, the RP believes that it should forward packets sent to the group—the RP does not send a Register-Stop message. Instead, it reacts to the Register message by deencapsulating the multicast packet and forwarding it.
The behavior of the RP in reaction to the Register message points out the second major function of the Register message. Its main two functions are as follows:
- To allow a router to inform the RP that it has a local source for a particular multicast group.
- To allow a router to forward multicasts to the RP, encapsulated inside a unicast packet, until the registration process is completed
Shared Distribution Tree
If the network has multiple sources for the same group, traffic from all the sources would first travel to the RP and then travel down this shared RPT to all the receivers. Because all sources in the multicast group use a common shared tree, a wildcard notation of (*,G) is used to identify an RPT, where * represents all sources and G represents the multicast group address.
The example below shows the multicast route table entry . On a Cisco router, the show ip mroute command displays the multicast route table entries.
The interpretation of the information shown in the above example is as follows:
The first line shows that the (*,G) entry for the group 126.96.36.199 was created 8 seconds ago, and if the router does not forward group packets using this entry in 2 minutes and 58 seconds, it will expire. Every time R4 forwards a packet, the timer is reset to 3 minutes. This entry was created because R4 received an IGMP Join message from H1.
The RP for this group is 10.1.10.3. The S flag indicates that this group is using the sparse-mode (PIM-SM) routing protocol. The C flag indicates that the router has a directly connected group member for 188.8.131.52.
The incoming interface for this (*,184.108.40.206) entry is s0 and the RPF neighbor is 10.1.6.5. Note that for the SPT, the RPF interface is chosen based on the route to reach the RP, not the route used to reach a particular source.
Group traffic is forwarded out on the Ethernet0 interface. In this example, Ethernet0 was added to the outgoing interface list because an IGMP Report message was received on this interface from H1. This interface has been in the forwarding state for 8 seconds. The Prune timer indicates that if an IGMP Join is not received again on this interface within the next 2 minutes and 52 seconds, it will be removed from the outgoing interface list.