BIDIR-PIM overview

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 router 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 router 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 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.

In PIM-SM, an RP must be specified with a real IP address. In BIDIR-PIM, an RP can be specified with a virtual IP address, which is called the "rendezvous point address (RPA)." The link corresponding to the RPA's subnet is called the "rendezvous point link (RPL)." All interfaces connected to the RPL can act as the RPs, and they back up one another.

On a subnet with multiple multicast routers, 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 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 40, without the DF election mechanism, both Router B and Router C can receive multicast packets from Route A. They also can forward the packets to downstream routers on the local subnet. As a result, the RP (Router E) receives duplicate multicast packets.

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

1. The router with a higher metric preference becomes the DF.

2. If the routers have the same metric preference, the router with a lower metric becomes the DF.

3. If the routers have the same metric, the router 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 routers that directly connect to the receivers as leaves. The source-side RPT is also rooted at the RP but takes the routers that directly connect to the sources as leaves. The processes for building these two RPTs are different.

As shown in Figure 41, 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 router.

2. After receiving the message, the router 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 receiver's directly connected router to the RP form an RPT branch. Each router on this branch adds a (*, G) entry to its forwarding table.

After a multicast receiver leaves the multicast group G, the directly connected router multicasts a prune message to all PIM routers 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 router checks the existence of receivers for that multicast group. If no receivers for the multicast group exist, the router continues to forward the prune message to its upstream router.

As shown in Figure 42, 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 routers along the path from the source's directly connected router to the RP constitute an RPT branch. Each router on this branch adds to its forwarding table a (*, G) entry, where the asterisk (*) represents any multicast source.

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.