BIDIR-PIM

In some many-to-many applications, such as a multi-side video conference, multiple receivers of a multicast group might be interested in the multicast data from multiple multicast sources. With PIM-DM or PIM-SM, each device along the SPT must create an (S, G) entry for each multicast source, consuming a lot of system resources.

BIDIR-PIM addresses the problem. Derived from PIM-SM, BIDIR-PIM builds and maintains a bidirectional RPT, which is rooted at the RP and connects the multicast sources and the receivers. Along the bidirectional RPT, the multicast sources send multicast data to the RP, and the RP forwards the data to the receivers. Each device along the bidirectional RPT needs to maintain only one (*, G) entry, saving system resources.

BIDIR-PIM is suitable for a network with dense multicast sources and receivers.

BIDIR-PIM mechanisms include neighbor discovery, RP discovery, DF election, and bidirectional RPT building.

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

BIDIR-PIM uses the same RP discovery mechanism as PIM-SM does. For more information, see "RP discovery." In BIDIR-PIM, an RPF interface is the interface toward an RP, and an RPF neighbor is the address of the next hop to the RP.

On a subnet with multiple multicast devices, duplicate multicast packets might be forwarded to the RP. To address this issue, BIDIR-PIM uses a designated forwarder (DF) election mechanism to elect a unique DF for each RP on a subnet. Only the DFs can forward multicast data to the RP.

DF election is not necessary for an RPL.

As shown in Figure 48, without the DF election mechanism, both Device B and Device C can receive multicast packets from Route A. They also can forward the packets to downstream devices on the local subnet. As a result, the RP (Device E) receives duplicate multicast packets.

With the DF election mechanism, once receiving the RP information, Device B and Device C multicast a DF election message to all PIM devices (224.0.0.13) to initiate a DF election process. The election message carries the RP's address, and the route preference and the metric of the unicast route or static multicast route to the RP. A DF is elected as follows:

1. The device with a higher route preference becomes the DF.

2. If the devices have the same route preference, the device with a lower metric becomes the DF.

3. If the devices have the same metric, the device with a higher IP address becomes the DF.

A bidirectional RPT comprises a receiver-side RPT and a source-side RPT. The receiver-side RPT is rooted at the RP and takes the devices that directly connect to the receivers as leaves. The source-side RPT is also rooted at the RP but takes the devices that directly connect to the sources as leaves. The processes for building these two RPTs are different.

As shown in Figure 49, the process for building a receiver-side RPT is the same as the process for building an RPT in PIM-SM:

1. When a receiver wants to join the multicast group G, it uses an IGMP message to inform the directly connected device.

2. After receiving the message, the device sends a join message, which is forwarded hop by hop to the RP for the multicast group.

3. The devices along the path from the receiver's directly connected device to the RP form an RPT branch. Each device on this branch adds a (*, G) entry to its forwarding table.

After a receiver host leaves the multicast group G, the directly connected device multicasts a prune message to all PIM devices on the subnet. The prune message goes hop by hop along the reverse direction of the RPT to the RP. After receiving the prune message, an upstream node removes the interface that connects to the downstream node from the outgoing interface list. At the same time, the upstream device checks the existence of receivers for that multicast group. If no receivers for the multicast group exist, the device continues to forward the prune message to its upstream device.

As shown in Figure 50, the process for building a source-side RPT is relatively simple:

1. When a multicast source sends multicast packets to the multicast group G, the DF in each subnet unconditionally forwards the packets to the RP.

2. The devices along the path from the source's directly connected device to the RP constitute an RPT branch. Each device on this branch adds to its forwarding table a (*, G) entry.

After a bidirectional RPT is built, the multicast sources send multicast traffic to the RP along the source-side RPT. Then, the RP forwards the traffic to the receivers along the receiver-side RPT.

	IMPORTANT: If a receiver and a multicast source are at the same side of the RP, the source-side RPT and the receiver-side RPT might meet at a node before reaching the RP. In this case, the multicast packets from the multicast source to the receiver are directly forwarded by the node, instead of by the RP.