Subject: SPT bit in (S,G) entry

From: "Jyotheeswara Rao Kurma" <[email-masked]>
Date: Wed, 11 Apr 2001 14:52:10 +0500

Hi All:

  I have some questions on setting/clearing the SPT bit in the (S,G)
  entry.

Case 1 : At the DR of sender. When this bit is set/cleared ?
I guess it is always set (to 1) because DR always wants to join SPT 
with RP. 

Other alternative is after receiving (S,G) join from RP. I feel the 
first approach is better.

Case 2 : At any Intermediate routers 

after the SPT switch procees has started, and multicast packets start 
arriving in both directions, one path down the RP tree and another down 
the SP tree. Then this bit is set till then it will be zero.

Case 3 : At RP.

I guess there is no damage to the functionality, even if we set SPT bit 
after receiving the first Register packet, (i.e while creating the (S,G)
entry itself.) Because RP must join the SP tree, if it has some 
receives down the RP tree. 

Otherway way is to set this bit, when native multicast packets start
arriving from this Source.( without register encapsulation )

If anyone differs from my argument, please let me know.
Thanks,
Jyotheesh

---

From: Mark Handley <[email-masked]>
Date: Wed, 11 Apr 2001 09:51:04 -0700

>  I have some questions on setting/clearing the SPT bit in the (S,G)

All the rules for setting/clearing the SPT bit are in section 4.2.1 of
draft-ietf-pim-sm-v2-new-02:

     Thus, when a packet arrives, the (S,G) SPTbit is updated as follows:

     void
     Update_SPTbit(S,G,iif) {
       if ( iif == RPF_interface(S)
             AND JoinDesired(S,G) == TRUE
             AND ( DirectlyConnected(S) == TRUE
                   OR RPF_interface(S) != RPF_interface(RP)
                   OR inherited_olist(S,G,rpt) == NULL
                   OR RPF'(S,G) == RPF'(*,G) ) ) {
          Set SPTbit(S,G) to TRUE
       }
     }

     Additionally a router sets SPTbit(S,G) to TRUE when it sees an
     Assert(S,G) on RPF_interface(S).

     ...

     The SPT bit is cleared in the (S,G) upstream state machine (see Section
     4.4.7) when JoinDesired(S,G) becomes FALSE.

>first approach is better.

At the DR:
  The forwarding rules set the KeepaliveTimer(S,G).
  The register tunnel is included in immediate_olist(S,G) (see 4.3.1)

Thus
  iif == RPF_interface(S)
  JoinDesired(S,G) == TRUE (if we're register encapsulating, 
                            or received a Join(S,G): one of these 
                            is usually true)
  DirectlyConnected(S) == TRUE

So SPTbit(S,G) will be set, even before the RP joins to the source.

If there are no receivers at the RP, then the RP will send
RegisterStop (which removes the register tunnel), and won't join back
to the source.  In this case JoinDesired(S,G) becomes false at the DR,
and SPTbit is cleared.  The SPT state is however kept around by the
KeepaliveTimer.

>the SP tree. Then this bit is set till then it will be zero.

When an (S,G) data packet arrives on RPF_interface(S):

iif == RPF_interface(S)

JoinDesired(S,G) == TRUE  (at these intermediate routers)

One of the four conditions applies that indicates either:
  - the packet definitely arrived on the SPT not the RPT, or
  - we're never going to be able to tell, so switch anyway.

There's one exception: in the case where 
   RPF_interface(S) == RPF_interface(RP)
   AND RPF'(S,G) != RPF'(*,G)
then we'd have to look at the MAC address of data packets to decide,
which we'd rather not do, so in this case we wait for the Assert(S,G)
from RPF'(S,G) to tell us for certain what happened, and to trigger
the setting of SPTbit.

>arriving from this Source.( without register encapsulation )

You definitely do the latter, not the former.  The standard SPTbit
rules handle this.

Note that at the RP, RegisterStop is sent when a register-encapsulated
packet arrives and SPTbit is TRUE, so setting it prematurely will
cause a (hopefully temporary) blackhole until the RP has completed
it's join back to the sender.

Hopefully this helps: basically the rules in 4.2.1 are all you ever
need (assuming we got them right!).

Cheers,
	Mark