Subject: [pim] Per-intf (S,G) assert state-machine

From: "James Huang" <[email-masked]>
Date: Wed, 10 Apr 2002 13:10:30 -0700

Hi all,

The per-intf (S,G) assert state-machine will transition from the NoInfo state to the AssertLoser state when it receives a prefered assert with RPTbit clear and AssertTrackingDesired(S,G,I) == TRUE.  Also it will set SPTbit(S,G) to 1 if the Assert message is received from RPF_intf(S).  

My question is "Should the state-machine also start the KeepAliveTimer(S,G) if the Assert message is received from RPF_intf(S)?".  Sptbit set to 1 while KeepAliveTimer not running doesn't seem to be a good state to me.  I have run into a scenario where this problem can cause a black-hole in (S,G) forwarding.

The scenario is as follows:

                               RP:225 *****
                                      * 1 *
                                      *****
                                        |
                                        |  lan1
                                        |
                                      *****         =====  receiver
                                      * 2 *---------= 3 = (192.168.4.6, 
                                      *****   lan2  =====  225.1.1.1)
                                        |                              
                                        |
                               lan3     |  
                      -------------------------------------
                            |                        |
                            |                        |
                     lan6   |                        |
              =====       *****                    *****
              = 8 =-------* 4 *                    * 5 *
              =====       *****                    *****
             receiver       |                        |
           (192.168.4.6,    | lan4              lan5 |
            225.1.1.1)      |                        |
                          =====                    =====
                          = 6 =                    = 7 =
                          =====                    =====
                         source                   receiver (*,225.1.1.1)

(1) host 7 sends a igmp (*,G) join
(2) host 8 sends a igmp (S,G) join
(3) host 3 sends a igmp (S,G) join
(4) host 6 pings 225.1.1.1 a few times
(5) wait until the KeepAliveTimer times out in router 2 and router 4
(6) host 6 pings 225.1.1.1 continuously
(7) host 8 sends a igmp (S,G) leave

Assuming that router 5 will not switch from the PRT tree to the SPT tree when it call CheckSwitchtoSpt(S,G).

After step(7), this has become the classical turn-around router scenario.  However, R4 has also become the (S,G) Assert Winner for lan3.
When R4's Assert timer expires, it will send a periodic Assert(S,G) message.  When R5 receives the Assert message, its per-intf (S,G) Assert state-machine will transition from the NoINfo state to the AssertLoser state.  Also R5 will set SPTbit(S,G) to 1.  This will change AssertTrackingDesired(S,G,I) at R5 to False and so R5's Assert state-machine will be moved back to the NoInfo state.  Setting Sptbit(S,G) to 1 will make PruneDesired(S,G,rpt) at R5 to become true.  So R5 will send a Prune(S,G,rpt) to R2.  When R2 receives the Prune(S,G,rpt) from R5, its inherited_olist(S,G) becomes NULL.  So JoinDesired(S,G) becomes False at R2 and it will send a prune(S,G) to R4.  From now on, R4 will no longer forward (S,G) traffic to lan3 and a black-hole is created.

This problem can be fixed by setting KeepAliveTimer(S,G) at R5 when it receives the Assert(S,G) message from R4.  With this fix, R5 has both SPTbit(S,G) set to 1 and the KeepAliveTimer(S,G) running.  So it will send a Prune(S,G,rpt) to R2 and a Join(S,G) to R4.  This will prevent the black-hole from being created in this scenario.

Regards,
James Huang

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

---

From: "John Zwiebel" <[email-masked]>
Date: Wed, 10 Apr 2002 14:25:25 -0700

FWIW:
If a router is recevinging an IGMPv3 report for a specific
(S,G), I do not believe one should worry about data when
setting the KAT on the last-hop router.  One could argue
that unless S was in the SSM range that only data should
determine the KAT, but then you will have a case where 
state will be deleted and then recreated over and over every
3 minutes for (IMHO) no good reason.  I recognize that for
non-SSM groups routers that are further upstream on the SPT will
delete and reinstall the (S,G) resulting in up to a 60 second
black-hole.  I submit that "if its important" this not happen,
that it is an error for the host to send an IGMPv3 (S,G) report.
However, for most video/audio uses: a) the user seldom joins 
before the source is sending; b) migrating to IGMPv3 and 
(S,G) reports is 'more important' than solving this 'interim
problem'.

If router 5 has (S,G) state, this is -not- a turn-around problem.
Since you have R5 setting the SPT bit R2 does not need to
worry about identifying 'non-atomic' joins (PIM (*,G) joins
without an (S,G,R) prune) with is a requirement to identify
a router as a "turn-around" router.

R5 should not transition to assert loser.  Its IIF is on LAN3
so it should never forward for the source so it should never
participate in an assert (ie only a router that has an interface
in the olist that sees an assert should care here).

R5 does care about the assert because it needs to know when it
can switch from the RPT to the SPT.  Since the IIF to both the
RPT and SPT are the same, the only way it can be -sure- it received
packets on the SPT is if it sees the assert.

Whether or not the SPT-bit is set the (S,G) KAT should be updated
anytime R5 forwards a packet.  Since the only time one should see an
assert on LAN3 is when there is a data packet, the KAT should be
running.

Finally, even though the SPT-bit is not set on R5, there is no
reason it should not be sending an (S,G) join toward the source
and overriding any actions of R2 that might cause a black-hole.

The only thing the SPT-bit should do is enable sending an (S,G,R)
prune from R5.

HOWEVER, if you want to implement updating the KAT when you see 
the assert, you start the KAT, I doubt it will cause any
interoperability
problems.  

Just be sure that you don't assert when you see an assert.  Only 
send an assert when you actually see data on an interface in the
Olist. 

> -----Original Message-----
> From: James Huang [mailto:[email-masked]] 
> Sent: Wednesday, April 10, 2002 1:05 PM
> To: [email-masked]
> Cc: Reuben Sivan; Junyu Mai
> Subject: [pim] Per-intf (S,G) assert state-machine
> 
> 
> Hi all,
> 
> The per-intf (S,G) assert state-machine will transition from 
> the NoInfo state to the AssertLoser state when it receives a 
> prefered assert with RPTbit clear and 
> AssertTrackingDesired(S,G,I) == TRUE.  Also it will set 
> SPTbit(S,G) to 1 if the Assert message is received from RPF_intf(S).  
> 
> My question is "Should the state-machine also start the 
> KeepAliveTimer(S,G) if the Assert message is received from 
> RPF_intf(S)?".  Sptbit set to 1 while KeepAliveTimer not 
> running doesn't seem to be a good state to me.  I have run 
> into a scenario where this problem can cause a black-hole in 
> (S,G) forwarding.
> 
> After step(7), this has become the classical turn-around 
> router scenario.  However, R4 has also become the (S,G) 
> Assert Winner for lan3.
> When R4's Assert timer expires, it will send a periodic 
> Assert(S,G) message.  When R5 receives the Assert message, 
> its per-intf (S,G) Assert state-machine will transition from 
> the NoINfo state to the AssertLoser state.  Also R5 will set 
> SPTbit(S,G) to 1.  This will change 
> AssertTrackingDesired(S,G,I) at R5 to False and so R5's 
> Assert state-machine will be moved back to the NoInfo state.  
> Setting Sptbit(S,G) to 1 will make PruneDesired(S,G,rpt) at 
> R5 to become true.  So R5 will send a Prune(S,G,rpt) to R2.  
> When R2 receives the Prune(S,G,rpt) from R5, its 
> inherited_olist(S,G) becomes NULL.  So JoinDesired(S,G) 
> becomes False at R2 and it will send a prune(S,G) to R4.  
> From now on, R4 will no longer forward (S,G) traffic to lan3 
> and a black-hole is created.
> 
> This problem can be fixed by setting KeepAliveTimer(S,G) at 
> R5 when it receives the Assert(S,G) message from R4.  With 
> this fix, R5 has both SPTbit(S,G) set to 1 and the 
> KeepAliveTimer(S,G) running.  So it will send a 
> Prune(S,G,rpt) to R2 and a Join(S,G) to R4.  This will 
> prevent the black-hole from being created in this scenario.
> 
>  
> Regards,
> James Huang
>

---

From: "James Huang" <[email-masked]>
Date: Wed, 10 Apr 2002 15:14:40 -0700

See my comment below.

Regards,
James Huang

> From: John Zwiebel [mailto:[email-masked]]
> Sent: Wednesday, April 10, 2002 2:25 PM
> To: James Huang; [email-masked]
> Subject: RE: [pim] Per-intf (S,G) assert state-machine
> 
> 
> 
> FWIW:

After step(5), (S,G) KAT at R5 will time out.  So JoinDesired(S,G) will 
become FALSE.  So R5 will not update (S,G) KAT when it receives (S,G) traffic 
and JoinDesired(S,G) will remain FALSE.  After step(7) where host3 sends a igmp leave, 
it will become the classical turn-around router scenario except that R4 will also become
the AssertWinner in lan3 and will periodically send Assert(S,G) messages. The blackhole 
will be created the next time R4 sends the Assert(S,G) message.

> in the olist that sees an assert should care here).

After step (5) in my email, KeepAliveTimer(S,G) in R2, R4, and R5
will time out.  So JoinDesired(S,G) becomes FALSE at R5 and it will set its SPTbit
to 0. Now AssertTrackingDesired(S,G,I) become TRUE at R5, so R5 will track (S,G) asserts.

> packets on the SPT is if it sees the assert.

When R5 receives the periodic Assert(S,G) message sent by R4, it will set 
its SPTbit(S,G) back to 1. 

> assert on LAN3 is when there is a data packet, the KAT should be

(S,G) KAT at R5 is not updated by (S,G) traffic because after step(5) (S,G) KAT 
will time out, JoinDesired(S,G) will become FALSE.  So R5 will not update (S,G) KAT
when it receives (S,G) traffic.
 
> the assert, you start the KAT, I doubt it will cause any

I beleive what I saw is a problem in the current spec. I want to make sure 
the spec gets updated if my observation is correct.

> >                                * 2 *---------= 3 =  (92.168.4.6,

---

From: "John Zwiebel" <[email-masked]>
Date: Wed, 10 Apr 2002 16:01:00 -0700

First: I should complement you on clearly stating
the problem.

Basically, if the KAT is expired on R5, (S,G) state
should have been deleted.  All of the other problems
go away.

Also, IGMPv3 and SSM behavior will cause you problems
if you don't take into account the differences, which
should be easy to overcome.

> After step(5), (S,G) KAT at R5 will time out.  

If the KAT has expired, why does (S,G) state exist on
R5?  It should have been deleted.  If "JoinDesired"
is false, why are you maintaining (S,G) state in that
router?  

Then when the next mpacket is received on the (*,G)
R5 should create (S,G) state and trigger a join toward
the source.

FWIW: an implementation -may- choose to keep (S,G)
state on a router that just sees packets going by and
if I had my way, it would.  In such a case JoinDesired"
would be FALSE as you suggest, but then (*,G) would 
also be FALSE.

> So R5 will not update (S,G) KAT when it 
> receives (S,G) traffic 

The -only- way R3 can become a turnaround router is if R5
is configured to never join to the shortest-path.  Anything
else is -not- a turnaround router.  Since I invented the
term, I should know.  ;-)

Also FWIW: the asserts that will happen in this topology
will be between the RPT and the SPT.  I do not believe
the spec recommends sending a periodic assert in such a
case, and even if it does -- I wouldn't.  Doing so doesn't
buy you anything.

> R5 will track (S,G) asserts.

Again, if the KAT has expired, (S,G) state should not exist on
R5 so nothing else matters.

> its SPTbit(S,G) back to 1. 

If the KAT expired on R5 why didn't it expire on R4?  And
why is R4 sending an assert for a source that has expired.

Perhaps its the IGMPv3 report that is causing the problem?
Since you are apparently updating state on R4 because of that
report.  Mixing SSM and standard PIM is going to get you 
into trouble in this case.

Sending the periodic assert shouldn't update the (S,G) on
R5 so again, why is R5 maintaing that state.

---

From: "James Huang" <[email-masked]>
Date: Wed, 10 Apr 2002 16:26:55 -0700

Hi John,

In my company's pim-sm implementaion, (S,G) in R5 is not deleted after 
its KAT expires because the Upstream (S,G,rpt) state-machine is in the 
NotPruned state (instead of the RPTNotJoined(G) state).  Is it O.K. to 
delete the (S,G) entry in this case (KAT expired, all downstream intf 
are in the NoInfo state, the Upstream (S,G) state-machine is in the NotJoined 
state, the Register state-machine is in the NoInfo state, and the 
Upstream (S,G,rpt) state-machine is in the NotPruned state)?

Another issue is even if R5 deleted its (S,G) entry, its AssertTrackingDesired(S,G,I)
is still TRUE (RPF_intf(RP) == I AND JoinDesired(*,G) == TRUE AND SPTbit(S,G) == FALSE).
So when it receives a Assert(S,G) message from R4, it will recreate the (S,G) entry and
the problem will still occur.
 
Thanks,
James Huang

> Sent: Wednesday, April 10, 2002 4:01 PM

---

From: "John Zwiebel" <[email-masked]>
Date: Wed, 10 Apr 2002 17:31:57 -0700

> Upstream (S,G,rpt) state-machine is in the NotPruned state)?

FWIW: if the KAT is expired should alone cause you to delete state.
Nothing else should matter for maintaining (S,G) state.  (S,G,R)
state is, however, updated by receipt of the (S,G,R) prune.  It 
may not be clear in the spec, but it is the Expiry Timer in 4.4.4
page 33.

NOTE: you -may- want to update the KAT when you just see a packet
on an interface rather than forward it. (Hint, hint -- wink, wink)

> AND SPTbit(S,G) == FALSE).

If you delete the (S,G) why are you maintaining this other state?

> the problem will still occur.

In 'standard PIM' (S,G) is created by:
  -- data
  -- and (S,G) join

nothing else.

In 'standard PIM' (S,G) KAT is updated by data -- nothing else.

In SSM-PIM (S,G) KAT is updated by (S,G) joins -- nothing else.

Note that the conflict between standard and SSM PIM does not
prevent reliable delivery of data.  However it -may- result in
a blackhole of up to 60 seconds if the receiver joins more than 
3 minutes before the source starts sending and you are using 
'standard PIM' in your network.

So to repeat my latest "kick", -ALL- multicast sources should
advertise their source address in -ALL- sdp sessions so that
an IGMPv3 capable receiver can join directly to the source.  
There may be some exceptions to this in the enterprise environment
or in some special applications.

Just to be clear, yes I am advocating that -receivers- be provided
the option to use SSM over standard PIM in -all- multicast group
ranges.   HOWEVER, networks should still be configured to support
SSM only in the 232/8 range.

The sooner SSM is deployed the sooner we can scrap MSDP.  It is
imperitive MSDP be 'decommissioned' for use between ISPs before
the use of multicast becomes too great in the internet.