Subject: Re: Bidir PIM

From: [email-masked]
Date: Fri, 16 Mar 2001 10:51:01 -0800

From:  James Huang@MITEL on 03/16/2001 10:51 AM PST
Lorenzo:

     "No data-drivern events" is a nice feature to have, but it is achieved at
the price of :
     (1) wasted bandwidth along the path from the sources to the RP, and
     (2) wasted packet processing power at the RP

     To solve the problem, it does require sensing traffic from the source.  But
"traffic sensing" will only apply to group's that have been pruned from the RP.
And it  will only happen at those lowest level DF routers which have receivers
for the group downstream and have received RP-prune from upstream.     This kind
of traffic sensing only requires us to maintain a keepalive timer in the (*,G)
state at the interface toward the traffic source.   It does not seem to be a
difficult thing to do either in software or in hardware!

Regards,
James Huang

Lorenzo Vicisano <[email-masked]> on 03/15/2001 06:33:25 PM

To:   James Huang/USA/Mitel@Mitel
cc:   Isidor Kouvelas <[email-masked]>, [email-masked], [email-masked],
      [email-masked]

Subject:  Re: Bidir PIM

James,

Unless we did something drastic, any mechanism we could come up with
would require sensing traffic from the source (at least in the 1-st
hop router), hence giving up to a nice feature of bidir (no data-driven
events). Also it would require group state in source-only branches ...

The drastic thing we could do would be a multi hop extension of MSNIP
(draft-ietf-idmr-msnip-00.txt). What I'm thinking of is a hop-by-hop
receiver-presence discovery initiated by the source in the direction of
the RP. This would not require routers to handle data-driven events and
would create state only on demand.

not sure we want to go down this path however..

     Lorenzo

> From:  James Huang@MITEL on 03/15/2001 05:35 PM PST
> Hi Isidor:
>
>      Flood and prune toward the RP may not be as bad as it sounds. Flooding w
>ill
> only happen along a single path toward the RP.  If flood and prune is
> unacceptable, we can do without it by using a hop-by-hop multicast bidir-null
> regitser message (destination address = 224.0.0.13) as follows:
>
>      (1) A router R that has received RP-prune from its RPF_intf(RP) but has
>not
> sent RP_prune downstream will periodically send multicast bidir-null-register
>(G)
> upstream toward the RP.  It will do so as long as there exists active source
>for
> G downstream and its RPF_intf(RP(G)) stays pruned.  Router R has both sender(
>s)
> and receiver(s) for G downtream and receivers for G  only exist in the subtre
>e
> rooted at R.
>
>      (2) bidir-null-register message(G)  will be multicast hop by hop toward
>the
> RP.  When a router which is the DF(RP(G)) on a link receives the message from
> the link, it will in turn send the message upstream toward teh RP.
> Bidir-null-message is used to refresh the pruned state for G in routers along
> the path to the RP.
>
>      With regarding to the pseudo-RP issue, the proposed scheme will only app
>ly
> to p-to-p interface.
>
>
> -- James C. Huang
>
>
>
>
>
>
> Isidor Kouvelas <[email-masked]> on 03/15/2001 03:28:09 PM
>
> To:   James Huang/USA/Mitel@Mitel
> cc:   [email-masked], [email-masked], [email-masked],
>       [email-masked], [email-masked]
>
> Subject:  Re: Bidir PIM
>
>
>
>
> We were considering something similar. The problem is that in order
> for the RP to maintain the prune state alive, it needs to know if there
> are still active sources for the group. Otherwise it wont know when to
> time out the state.
> Two solutions for this problem are:
> - Use something like the SM null-register mechanism (not perfect as the
>   RP does not know on which interface the prune state must be refreshed)
> - Allow the traffic to flood and prune periodcally towards the RP
>   (as you propose below).
> Both have significant drawbacks.
>
> One of the *most* important benefits of bidir PIM is that it has no
> data-driven events, an advantage that must be sacrificed at least at
> the RP to make any mechanism like this work.
>
> Also note that for bidir PIM to work, the router corresponding to the
> RP address does not actually have to exist. The RP may just be a
> routable IP address on a LAN.
>
> thanks
> I
>
>
> [email-masked] writes:
> >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 wi
>ll
> >   remove RPF_interface(RP(G)) from olist(G).
> >
> >   (3) (*,G) traffic will be forwarded out to olist(G)  -- incoming interfac
>e.
> >   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 a
>nd
> >   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 secon
>ds
> >   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-machin
>e
> >   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
> >
> >
>
>

---

From: Lorenzo Vicisano <[email-masked]>
Date: Fri, 16 Mar 2001 11:01:03 -0800

> "traffic sensing" will only apply to group's that have been pruned from the R

to prune them (in the direction of the source) you first have to
sense the traffic.

> difficult thing to do either in software or in hardware!

everything is feasible.. at a price.

	Lorenzo

---

From: Isidor Kouvelas <[email-masked]>
Date: Fri, 16 Mar 2001 11:08:05 -0800

>     (2) wasted packet processing power at the RP

Why do you need to process packets at the RP?

thanks
I