Subject: Re: Bidir PIM

From: [email-masked]
Date: Thu, 15 Mar 2001 17:35:05 -0800

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 will
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 subtree
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 apply
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 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
>
>

---

From: Lorenzo Vicisano <[email-masked]>
Date: Thu, 15 Mar 2001 18:33:25 -0800

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: Christoph Reichert <[email-masked]>
Date: Fri, 16 Mar 2001 14:48:22 +0100

> events). Also it would require group state in source-only branches ... 

Another drastic thing would be to change the multicast service model :-)

Wouldn't it make things like this easier when send-only members also
have to join the group (in send-only mode).

And what is the problem with state in send-only branches, when state in
receive-only branches is ok ?

chris

---

From: Lorenzo Vicisano <[email-masked]>
Date: Fri, 16 Mar 2001 09:55:16 -0800

> have to join the group (in send-only mode).

this would be much more drastic :-)
... and would require changing all the applications for them to
be able to send at all.

> receive-only branches is ok ?

I agree, not a big problem, unless it's an application with much
more (low-rate) senders than receivers.. which is foreseeable.

	Lorenzo 

> > >      Flood and prune toward the RP may not be as bad as it sounds. Floodi
>ng w
> > >ill
> > >      (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-regi
>ster
> > >(G)
> > > upstream toward the RP.  It will do so as long as there exists active sou
>rce 
> > >for
> > > G downstream and its RPF_intf(RP(G)) stays pruned.  Router R has both sen
>der(
> > >s)
> > > and receiver(s) for G downtream and receivers for G  only exist in the su
>btre
> > >e
> > > rooted at R.
> > > 
> > >      (2) bidir-null-register message(G)  will be multicast hop by hop tow
>ard 
> > >the
> > >      With regarding to the pseudo-RP issue, the proposed scheme will only
> app
> > >ly
> > > to p-to-p interface.
> > > 
> > > 
> > > -- James C. Huang
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > >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 so
>urce
> > >.
> > > >   (2) When a router receives RP-prune(*,G) from RPF_interface(RP(G)), i
>t wi
> > >ll
> > > >   (3) (*,G) traffic will be forwarded out to olist(G)  -- incoming inte
>rfac
> > >e.
> > > >   (4) When a router R  receives (*,G) traffic from a p-to-p interface i
>if a
> > >nd
> > > >   olist(G) is NULL or includes only iif, R will in turn send a RP-prune
>(*,G
> > >)
> > > >   interface downstream (*,G) state-machine from NoInfo state to Join st
>ate,
> > > it
> > > >   traffic will resume going upstream to RP from a source some TIMEOUT s
>econ
> > >ds
> > > >   (9) Need to define a per-interface downstream (*,G) RP-prune state-ma
>chin
> > >e
> > > >   The above mechanism will introduce some data-driven protocol events, 
>but 
> > >it

---

From: Christoph Reichert <[email-masked]>
Date: Fri, 16 Mar 2001 19:46:14 +0100

> ... and would require changing all the applications for them to

During a transition period, first hop routers would do it data-driven
as befor.

> more (low-rate) senders than receivers.. which is foreseeable.

Ok, but for app's with much more receivers than (low-rate) senders,
building a tree is acceptable, right :-) ?

I still do not understand why creating receiver state is ok,
when creating sender state is not.

When it is forseeable that a group only has a few receivers, but many
senders, than using an application level RP and unicasting to it
might be a better design.

chris

---

From: Lorenzo Vicisano <[email-masked]>
Date: Fri, 16 Mar 2001 10:56:29 -0800

> building a tree is acceptable, right :-) ?

unavoidable...

> might be a better design.

this a possible solution in a different realm..

	Lorenzo