Subject: [pim] switchover to native forwarding between RP and source.

From: "[email-masked]" <[email-masked]>
Date: Mon, 30 Sep 2002 07:19:30 -0400 (EDT)

Hi,
I have a doubt. Draft has a policy function to switch to the SPT from the receivers. This policy from my munderstanding might be something like monitoring source data rate or looking for some other information to decide if the SPT should be established or not.

Why does the draft not support such mechanism between RP and source to stop register encapsulation and switch to native forwarding. From my understanding of the pseudocode in the section 4.4.2 the (S, G) entry is to be created at the leading register packet. 
If such mechanism is to be supported then there might be some duplication of multicast data packets before the switchover. For example in the topology below. Am I correct? 

                 (RP)
                   |
                   |
                 (R1)
                   |
                   |
           (Src)---|
                   |(DR)
                 (R2)
                   |
                   |
                  Rx

------------------------------------------------
Changed your e-mail?  Keep your contacts!  Use this free e-mail change of address service from Return Path.  Register now!

---

From: John Zwiebel <[email-masked]>
Date: Mon, 30 Sep 2002 07:47:10 -0700

On Monday, September 30, 2002, at 04:19 AM, [email-masked] wrote:

> Hi,
> I have a doubt. Draft has a policy function to switch to the SPT from 
> the receivers. This policy from my munderstanding might be something 
> like monitoring source data rate or looking for some other information 
> to decide if the SPT should be established or not.
>
> Why does the draft not support such mechanism between RP and source to 
> stop register encapsulation and switch to native forwarding.

If your implementation wishes to do this, there's nothing to stop you 
from doing it.

> From my understanding of the pseudocode in the section 4.4.2 the (S, 
> G) entry is to be created at the leading register packet.
> If such mechanism is to be supported then there might be some 
> duplication of multicast data packets before the switchover. For 
> example in the topology below. Am I correct?

I'm not clear on your question, but yes there are many cases where 
there might be duplicate packets delivered when
switching from an RPT to an SPT.  This should not be a problem.  
Applications that can not deal with duplicate packets
will fail.

FWIW: experience has shown that trying to let a last-hop router monitor 
the rate that data is being forwarded and
then switching to the SPT when it exceeds a configured rate has not 
proven to be all that effective.
It "might" be better to concentrate on bi-dir PIM if you are 
interesting in having receivers remain on the RPT.

>
> (RP)
> |
> |
> (R1)
> |
> |
> (Src)---|
> |(DR)
> (R2)
> |
> |
> Rx
>
>
>
>
> Changed your e-mail? Keep your contacts! Use this free e-mail change 
> of address service from Return Path. Register now! 

_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim

---

From: Pavlin Radoslavov <[email-masked]>
Date: Mon, 30 Sep 2002 11:34:52 -0700

> If your implementation wishes to do this, there's nothing to stop you 

FWIW, I was told exactly same thing when few weeks ago I asked one of
the authors about same question :)

FYI, if you want to do this, then in the pseudo-code of
"packet_arrives_on_rp_tunnel( pkt )" the line 

	restart KeepaliveTimer(S,G)

should be changed to:

	if (( inherited_olist(S,G) != NULL ) AND
	    SwitchToSptDesired(S,G))
            restart KeepaliveTimer(S,G)

(any mistakes in the above modification are mine)

In this particular case, the SPT switch will be triggered only if
the KeepaliveTimer(S,G) is (re)started, hence by controlling when to
restart that timer we can control when to trigger the SPT switch at
the RP.

> > example in the topology below. Am I correct?

In general, the switchover mechanism (regardless of whether is
triggered by the RP or the last-hop router) does not guarantee that
there won't be duplicated, lost, or reordered packets. However, this
is a one-time transient event, and in reality the amount of
duplicated/lost/reordered packets should be very small.

Regards,
Pavlin

---

From: Pavlin Radoslavov <[email-masked]>
Date: Mon, 30 Sep 2002 18:31:26 -0700

> (any mistakes in the above modification are mine)

Correction: the original code

    if( I_am_RP( G ) && outer.dst == RP(G) ) {
        restart KeepaliveTimer(S,G)
        if(( inherited_olist(S,G) == NULL ) OR SPTbit(S,G)) {
            send RegisterStop(S,G) to outer.src
        } else {
            if( ! pkt.NullRegisterBit ) {
                decapsulate and pass the inner packet to the normal
                forwarding path for forwarding on the (*,G) tree.
            }
        }
    } else {
	...

would become:

    if( I_am_RP( G ) && outer.dst == RP(G) ) {
	if (( inherited_olist(S,G) != NULL ) AND
	    SwitchToSptDesired(S,G))
            restart KeepaliveTimer(S,G)
        if(( inherited_olist(S,G) == NULL ) OR SPTbit(S,G)) {
	    restart KeepaliveTimer(S,G)
            send RegisterStop(S,G) to outer.src
        } else {
            if( ! pkt.NullRegisterBit ) {
                decapsulate and pass the inner packet to the normal
                forwarding path for forwarding on the (*,G) tree.
            } else {
		restart KeepaliveTimer(S,G)
	    }
        }
    } else {
	...

I.e., there are two more "restart KeepaliveTimer(S,G)" to compensate
for the conditional restart in the first place.

Note that with the above modification, an (S,G) state may still be
created at the RP even if the sender's bw is below a
threshold. E.g., if the RP has no downstream members for a group,
the RP will create (S,G) with NULL oifs per each active source for
that group. Thus, when new members join, the RP can immediately
send (S,G) Join toward each S and the data will start flowing;
otherwise, no traffic will be received from a source until the
Register Stop timer at its DR expires.

Pavlin