Subject: Bidir PIM

From: [email-masked]
Date: Thu, 15 Mar 2001 15:24:41 -0800

Hi all,

     I have some thoughts on Bidir-PIM.

     In draft-ietf-pim-bidir-02.txt and draft-farinacci0bidir-pim-01.txt,
traffic in a bidirectional group will always be forwarded to the RP of that
group. If no receivers are along the way to the RP, the traffic will only be
dropped off at the RP. Traffic will be forwarded to the RP even if there are no
receivers at all or receivers exist only in some subtree covering the source.
This disadvantage of Bidir-PIM can be resolved by using a RP-initiated Prune
mechanism as follows.

   (1) When a RP receives (*,G) traffic from a p-to-p interface iif, and
   olist(G) is NULL or includes only iif, then RP will send a RP-prune(*,G)
   downstream to interface iif.

   (2) When a router receives RP-prune(*,G) from RPF_interface(RP(G)), it will
   remove RPF_interface(RP(G)) from olist(G).

   (3) (*,G) traffic will be forwarded out to olist(G)  -- incoming interface.
   olist(G) is redefined as follows:

      RPF_interface(RP,G) = {
           if (have not received RP_prune(*,G) from RPF_inetrface(RP(G))),
                retrun (RPF_interface(RP(G)));
           else
                return(NULL);
      }

      olist(G) = joins(G) + pim_include(G) + RPF_interface(RP,G);

   (4) When a router R  receives (*,G) traffic from a p-to-p interface iif and
   olist(G) is NULL or includes only iif, R will in turn send a RP-prune(*,G)
   downstream to interface iif.

   (5) When a router (may be RP) receives a join(G) that transitions its per
   interface downstream (*,G) state-machine from NoInfo state to Join state, it
   will check if it should reconnect some downstream interfaces that was
   RP-pruned.  If so, it will send a RP-graft(*,G) to that interface.

   (6) When a router R receives RP-graft(*,G) from a p-to-p RPF_interface(RP(G))
   interface, it will add RPF_interface(RP(G)) back to olist(G) and send a
   RP-graft-ack back to iif.

   (7) Sending of data-driven RP-prune(*,G) messages should be rate-limited.

   (8) In order to remove old RP-pruned states and make the mechanism more
   fail-safe, we can time out RPF_interface(RP) from RP-pruned state.  (*,G)
   traffic will resume going upstream to RP from a source some TIMEOUT seconds
   after it is RP-pruned.  This may initiate another round of RP-pruning
   process.

   (9) Need to define a per-interface downstream (*,G) RP-prune state-machine
   and an upstream (*,G) RP-prune state machine.

   The above mechanism will introduce some data-driven protocol events, but it
   will save wasted bandwidth along the path from a source to the RP.  The
   scheme will only work for p-to-p interface.   In other words, RP-prune
   messages should only be sent downstream along a p-to-p path.

   Regards,
   James C. Huang