Subject: Re: Bidir PIM

From: [email-masked]
Date: Fri, 16 Mar 2001 11:28:09 -0800

From:  James Huang@MITEL on 03/16/2001 11:28 AM PST
Hi Isidor:

     What I mean is: -)
     If all multicast traffic has to go all the way to the corresponding RP,
then RP has to process all of these packets (either in software or in hardware)

-- James Huang

Isidor Kouvelas <[email-masked]> on 03/16/2001 11:08:05 AM

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

Subject:  Re: Bidir PIM

[email-masked] writes:
>
>
>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

Why do you need to process packets at the RP?

thanks
I

>     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]
>g,
>      [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-nul
>l
>> 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-registe
>r
>>(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 subtr
>e
>>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 fro
>m
>> 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 alon
>g
>> the path to the RP.
>>
>>      With regarding to the pseudo-RP issue, the proposed scheme will only ap
>p
>>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 b
>e
>> >dropped off at the RP. Traffic will be forwarded to the RP even if there ar
>e
>> no
>> >receivers at all or receivers exist only in some subtree covering the sourc
>e
>>.
>> >This disadvantage of Bidir-PIM can be resolved by using a RP-initiated Prun
>e
>> >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 w
>i
>>ll
>> >   remove RPF_interface(RP(G)) from olist(G).
>> >
>> >   (3) (*,G) traffic will be forwarded out to olist(G)  -- incoming interfa
>c
>>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 pe
>r
>> >   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 seco
>n
>>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-machi
>n
>>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
>> >
>> >
>>
>>
>
>
>
>
>
>