IPv6 BIDIR-PIM

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

IPv6 BIDIR-PIM addresses the problem. Derived from IPv6 PIM-SM, IPv6 BIDIR-PIM builds and maintains a bidirectional RPT, which is rooted at the RP and connects the IPv6 multicast sources and the receivers. Along the bidirectional RPT, the IPv6 multicast sources send IPv6 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.

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

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

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

IPv6 BIDIR-PIM uses the same RP discovery mechanism as IPv6 PIM-SM does. For more information, see "RP discovery." In IPv6 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, IPv6 BIDIR-PIM uses a designated forwarder (DF) election mechanism to elect a unique DF on each subnet. Only the DFs can forward IPv6 multicast data to the RP.

DF election is not necessary for an RPL.

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

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

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

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

3. If the devices have the same metric, the device with the 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 IPv6 multicast sources as leaves. The processes for building these two RPTs are different.

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

1. When a receiver wants to join the IPv6 multicast group G, it uses an MLD 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 IPv6 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 IPv6 multicast group G, the directly connected device multicasts a prune message to all IPv6 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 IPv6 multicast group. If no receivers for the IPv6 multicast group exist, the device continues to forward the prune message to its upstream device.

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

1. When an IPv6 multicast source sends multicast packets to the IPv6 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 a (*, G) entry to its forwarding table.

After a bidirectional RPT is built, the IPv6 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 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 IPv6 multicast source to the receiver are directly forwarded by the node, instead of by the RP.