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

From: "James Huang" <[email-masked]>
Date: Wed, 10 Apr 2002 13:04:37 -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

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