Hello Balajee,
I apologize for answering lately here. I hope this response still reaches you.
Topology: Source-R1-RP-R2-Receiver. You mean to say if another source is added to R2 in the above diagram, it can not send multicast traffic towards RP since it is a shared tree and already receiving traffic.
Yes, this is true. You see, in PIM-SM, there are very strict rules on where a packet may be received and through which interfaces the packet may be replicated. The Reverse Path Forwarding rule in PIM-SM says that a router will process only such those multicast packets that come either through the interface back to RP, or through the interface back to the sender of the packet (depending on which tree this router joined). In addition, these packets will be replicated out only those interface that have received PIM Joins for the particular group from the downstream neighbors. Note the strong directionality: the packet must come over the RPF interface (that has sent PIM Join back to either RP or the source), otherwise it is dropped, and the packet must be sent out the interfaces that have received the PIM Join themselves. In other words, multicast traffic flows in the opposite direction of PIM Joins in PIM-SM. This is what makes the distribution trees constructed by PIM-SM uni-directional - the rules of their construction and their usage.
In your scenario, if another source was added to R2 and started sending multicast traffic, a separate distribution tree would need to be constructed for it. The traffic can not flow through the existing distribution tree that was constructed towards R2 as a receiver.
Does this explain sufficiently why trees in PIM-SM are unidirectional? Please feel welcome to ask further!
Also, how it is addressed in bidder pim?
The Bidir-PIM actually behaves quite similarly to the Spanning Tree Protocol. In Bidir-PIM, each connected segment elects exactly one router called Designated Forwarder (DF). This is very similar to STP where each connected segment has exactly one Designated port, and other ports on this segment are either Root ports or blocked ports.
Imagine now what would happen in STP if a Designated port on a segment received a broadcast. The switch in which this Designated port resides would pick up this broadcast, replicate it through all other Designated ports (i.e. onto other segments - other switches may have their Root ports on them) and its Root port (yet another segment on which there may also be another switches having their Root ports). Sending the broadcast through the Root port can be called as forwarding the broadcast upstream (towards the root bridge) while propagating it through Designated ports can be called as forwarding the broadcast downstream (away from the root bridge). If you visualize this process, you can see that the this process of receiving a broadcast on a Designated port and forwarding it all other Designated ports plus the Root port accomplishes, among others, the task of getting the broadcast upstream to the root bridge. The root bridge will of course receive the broadcast through one of its Designated ports and replicate it out its other Designated ports, sending the broadcast downstream to the rest of the network that has not received it yet. Here, other switches will receive the broadcast on their Root ports and will replicate it out all Designated ports, and so on.
So if we sum this up, a broadcast received on a Designated port will be forwarded upstream via the Root port (and also possibly downstream if the switch has other Designated ports - note the bidirectionality here!). A broadcast received on a Root port will be forwarded downstream via Designated ports. There is just one spanning tree constructed in the network, yet this tree is fully bidirectional and allows any node to receive and send the broadcast any time, and the broadcast will be delivered all over the spanning tree.
The Bidir-PIM is very similar. The Designated Forwarder (DF) is responsible for forwarding a multicast packet onto the segment in the downstream direction, and picking up multicasts from the segment and forwarding them towards the Rendezvous Point in the upstream direction. Other routers on the segment which are not DFs are similar to Root ports - they may pick up the multicast from this segment and forward it out their own interfaces on other segments for which they are DFs.
More precisely, assume that a router receives a multicast packet. The RPF verification is also performed here: the packet must either come in through an RPF interface towards the RP, in which case it is a downstream traveling packet, or it must come in through an interface on which the router is a DF, meaning that this packet is an upstream traveling packet. Packet coming in through any other interface is silently dropped. Now, the router takes the packet and forwards it all other interfaces on which it is a DF (the downstream direction), and in addition, if the packet was an upstream packet, it will be also forwarded through the RPF interface towards the RP. Notice the bidirectionality here - a packet can be replicated both into downstream and upstream direction within the single tree.
The described algorithm is slightly simplified - it does not take PIM or IGMP Joins into account. It would result into all multicast being just flooded all over the network. In reality, the downstream traffic is flooded only through a subset of interfaces on which the router is the DF and which have received a PIM or IGMP Join. This limits the flooding only to a set of interfaces that have subscribed receivers.
I understand that this is not an easy topic to digest. You are more than welcome to ask further!
Best regards,
Peter
