PIM-SM overview

PIM-DM uses the flood-and-prune cycles to build SPTs for multicast data forwarding. Although an SPT has the shortest paths from the multicast source to the receivers, it is built with a low efficiency and is not suitable for large- and medium-sized networks.

PIM-SM uses the pull mode for multicast forwarding, and it is suitable for large- and medium-sized networks with sparsely and widely distributed multicast group members.

The basic implementation of PIM-SM is as follows:

• PIM-SM assumes that no hosts need multicast data. In the PIM-SM mode, a host must express its interest in the multicast data for a multicast group before the data is forwarded to it. PIM-SM implements multicast forwarding by building and maintaining rendezvous point trees (RPTs). An RPT is rooted at a router that has been configured as the rendezvous point (RP) for a multicast group. The multicast data to the group is forwarded by the RP to the receivers along the RPT.

• When a receiver host joins a multicast group, the receiver-side designated router (DR) sends a join message to the RP for the multicast group. The path along which the message goes hop by hop to the RP forms a branch of the RPT.

• When a multicast source sends multicast data to a multicast group, the source-side DR must register the multicast source with the RP by unicasting register messages to the RP. The multicast source stops sending until it receives a register-stop message from the RP. When the RP receives the register message, it triggers the establishment of an SPT. Then, the multicast source sends subsequent multicast packets along the SPT to the RP. After reaching the RP, the multicast packet is duplicated and delivered to the receivers along the RPT.

Multicast data is replicated wherever the RPT branches, and this process automatically repeats until the multicast data reaches the receivers.

PIM-SM uses the same neighbor discovery mechanism as PIM-DM does. For more information, see "Neighbor discovery."

On a shared-media LAN like Ethernet, only a DR forwards the multicast data. A DR is required in both the source-side network and receiver-side network. A source-side DR acts on behalf of the multicast source to send register messages to the RP. The receiver-side DR acts on behalf of the receiver hosts to send join messages to the RP.

PIM-DM does not require a DR. However, if IGMPv1 runs on any shared-media LAN in a PIM-DM domain, a DR must be elected to act as the IGMPv1 querier for the LAN. For more information about IGMP, see "Configuring IGMP."

	IMPORTANT: IGMP must be enabled on the device that acts as the receiver-side DR. Otherwise, the receiver hosts attached to the DR cannot join any multicast groups.

As shown in Figure 25, the DR election process is as follows:

1. The routers on the shared-media LAN send hello messages to one another. The hello messages contain the priority for DR election. The router with the highest DR priority is elected as the DR.

2. The router with the highest IP address wins the DR election under one of following conditions:

   • All the routers have the same DR election priority.

   • A router does not support carrying the DR-election priority in hello messages.

If the DR fails, its PIM neighbor lifetime expires and the other routers will initiate to elect a new DR.

An RP is the core of a PIM-SM domain. For a small-sized, simple network, one RP is enough for multicast forwarding throughout the network. In this case, you can specify a static RP on each router in the PIM-SM domain. However, in a PIM-SM network that covers a wide area, a huge amount of multicast data is forwarded by the RP. To lessen the RP burden and optimize the topological structure of the RPT, you can configure multiple candidate-RPs (C-RPs) in a PIM-SM domain. The bootstrap mechanism is used to dynamically elect RPs from multiple C-RPs. An elected RP provides services for a different multicast group. For this purpose, you must configure a bootstrap router (BSR). A BSR serves as the administrative core of a PIM-SM domain. A PIM-SM domain has only one BSR, but can have multiple candidate-BSRs (C-BSRs) so that, if the BSR fails, a new BSR can be automatically elected from the C-BSRs and avoid service interruption.

	NOTE: An RP can provide services for multiple multicast groups, but a multicast group only uses one RP. A device can act as a C-RP and a C-BSR at the same time.

As shown in Figure 26, each C-RP periodically unicasts its advertisement messages (C-RP-Adv messages) to the BSR. An advertisement message contains the address of the advertising C-RP and the multicast group range to which it is designated. The BSR collects these advertisement messages and organizes the C-RP information into an RP-set, which is a database of mappings between multicast groups and RPs. The BSR encapsulates the RP-set information in the bootstrap messages (BSMs) and floods the BSMs to the entire PIM-SM domain.

Based on the information in the RP-set, all routers in the network can select an RP for a specific multicast group based on the following rules:

1. The C-RP that is designated to a smallest group range wins.

2. If the C-RPs are designated to the same group range, the C-RP with the highest priority wins.

3. If the C-RPs have the same priority, the C-RP with the largest hash value wins. The hash value is calculated through the hash algorithm.

4. If the C-RPs have the same hash value, the C-RP with the highest IP address wins.

As shown in Figure 27, the process of building an RPT is as follows:

1. When a receiver wants to join the multicast group G, it uses an IGMP message to inform the receiver-side DR.

2. After getting the receiver information, the DR sends a join message, which is forwarded hop by hop to the RP for the multicast group.

3. The routers along the path from the DR to the RP form an RPT branch. Each router on this branch adds to its forwarding table a (*, G) entry, where the asterisk (*) represents any multicast source. The RP is the root of the RPT, and the DR is a leaf of the RPT.

When the multicast data addressed to the multicast group G reaches the RP, the RP forwards the data to the DR along the established RPT, and finally to the receiver.

When a receiver is no longer interested in the multicast data addressed to the multicast group G, the receiver-side DR sends a prune message. The prune message goes hop by hop along the RPT to the RP. After receiving the prune message, the upstream node deletes the interface that connects to this downstream node from the outgoing interface list. It also determines whether it has receivers for that multicast group. If not, the router continues to forward the prune message to its upstream router.

The multicast source uses the registration process to inform an RP of its presence.

As shown in Figure 28, the multicast source registers with the RP as follows:

1. The multicast source S sends the first multicast packet to the multicast group G. When receiving the multicast packet, the source-side DR encapsulates the packet in a PIM register message and unicasts the message to the RP.

2. After the RP receives the register message, it decapsulates the register message and forwards the register message down to the RPT. Meanwhile, it sends an (S, G) source-specific join message toward the multicast source. The routers along the path from the RP to the multicast source constitute an SPT branch. Each router on this branch creates an (S, G) entry in its forwarding table.

3. The subsequent multicast data from the multicast source are forwarded to the RP along the established SPT. When the multicast data reaches the RP along the SPT, the RP forwards the data to the receivers along the RPT. Meanwhile, it unicasts a register-stop message to the source-side DR to prevent the DR from unnecessarily encapsulating the data.

In a PIM-SM domain, only one RP and one RPT provide services for a specific multicast group. Before the switchover to SPT occurs, the source-side DR encapsulates all multicast data addressed to the multicast group in register messages and sends them to the RP. After receiving these register messages, the RP decapsulates them and forwards them to the receivers-side DR along the RPT.

Switchover to SPT has the following weaknesses:

• Encapsulation and decapsulation are complex on the source-side DR and the RP.

• The path for a multicast packet might not be the shortest one.

• The RP might be overloaded by multicast traffic bursts.

To eliminate these weaknesses, PIM-SM allows an RP or the receiver-side DR to initiate the switchover to SPT.

• The RP initiates the switchover to SPT:

  After receiving the first (S, G) multicast packet, the RP sends an (S, G) source-specific join message toward the multicast source immediately. The routers along the path from the RP to the multicast source constitute an SPT. The subsequent multicast packets are forwarded to the RP along the SPT without being encapsulated into register messages.

  For more information about the switchover to SPT initiated by the RP, see "Multicast source registration."

• The receiver-side DR initiates the switchover to SPT:

  After receiving the first (S, G) multicast packet, the receiver-side DR initiates the switchover to SPT immediately, as follows:

  1. The receiver-side DR sends an (S, G) source-specific join message toward the multicast source. The routers along the path create an (S, G) entry in their forwarding table to constitute an SPT branch.

  2. When the multicast packets reach the router where the RPT and the SPT branches, the router drops the multicast packets that travel along the RPT. It then sends a prune message with the RP bit to the RP.

  3. After receiving the prune message, the RP forwards it toward the multicast source (supposed only one receiver exists). Thus, the switchover to SPT is completed. The subsequent multicast packets travel along the SPT from the multicast source to the receiver hosts.

With the switchover to SPT, PIM-SM builds SPTs more economically than PIM-DM does.

PIM-SM uses the same assert mechanism as PIM-DM does. For more information, see "Assert."