Subject: Q on Assert

From: Desikan Saravanan <[email-masked]>
Date: Thu, 12 Nov 1998 17:37:21 -0800

Hi All,

This is a question about the process of asserts.

consider the scenario like this:

                    RouterTop
                        |
                        |   net A
       -------------------------------------------
            |                           |
            |                           |
          AstWinner                  AstLoser
            |                           |
            |                           |
       -------------------------------------------
                        |   net B
                        |
                    RouterDown

RouterTop forwards a multicast stream from S to G on to the net A.
AstWinner and AstLoser are fwding the mcast data to net B.
RouterDown sends a prune upstream directed towards AstLoser
(say its unicast RPF lookup, gives AstLoser, though there are two
 equal cost paths one thro AstWinner and other thro AstLoser).
AstLoser prunes his interface to netB say iLB and starts the prune timer
for 210 seconds specified in the prune pkt.

AstWinner and AstLoser are going to assert for (S,G) and AstWinner wins.
AstWinner sees there is no dnstream nbrs who want
this stream, so he prunes his interface to netB say iWB.
RouterDown starts his assert timer for 180 sec (default value).
so, bcos of this, the mcast stream is not getting fwded out of RouterTop.

After some time, the RouterDown's assert timer times out, he switches
his RPF upstream nbr to AstLoser from AstWinner.
After some time, the AstLoser's prunetimer for iLB times out, he grafts
the interface iLB, but again RouterDown sends a prune upstream to AstLoser.
Again, the tree is cut off from RouterTop.

After some time, the AstWinner's prunetimer for iWB times out, he grafts
the interface iWB, but again RouterDown sends a prune upstream to
AstLoser. (Note, it is not AstWinner).
So, AstWinner keeps sending the mcast stream unncessarily to net B.

This locks gets opened, when the AstLoser's prune timer times out again
which causes AstLoser to fwd data and thus start assert again.

Q:
Are the routers behave correctly as per the spec in this scenario?
If so, Why there is waste of bandwidth during ceratin period?

I feel, one way to unlock the situation, in this case is:
when the RouterDown sends prune upstream, it can send 0.0.0.0 as una,
instead of specifically poiting at AstLoser. this wud cause both
AstWinner and AstLoser to work on the prunes.

Comments please!

Thanks for the patience in reading such a long mail!

Regards
DS

DESIKAN SARAVANAN
Software Engineer, Extreme Networks,
10460, Bandley Dr., Cupertino, CA 95014
(408)863-2941
http://www.extremenetworks.com
mailto:[email-masked]

---

From: Liming Wei <[email-masked]>
Date: Thu, 12 Nov 1998 22:08:40 -0800 (PST)

> X-SMAP-Received-From: outside
> From: Desikan Saravanan <[email-masked]>
> Date: Thu, 12 Nov 1998 17:37:21 -0800
> MIME-Version: 1.0
> X-Mailer: Internet Mail Service (5.5.2232.9)
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> Sender: [email-masked]
> Precedence: bulk
> 
> Hi All,
> 

Just a nit in your wording, the pruned interface expired and turned into
forwarding state. When the word "grafts" is involved, it may sound like
a message was involved. But I understand what you meant.

> So, AstWinner keeps sending the mcast stream unncessarily to net B.

Again, the prune state expired and turned into forward state.
"RouterDown" would not send a prune message by itself, it actually need
a packet to flow to the LAN, causing another assert, and the forwarded
packet eventually will reach a leaf, and if no member exists it will
prune back.

> which causes AstLoser to fwd data and thus start assert again.

Yes, it happens repeatedly.

> If so, Why there is waste of bandwidth during ceratin period?

See above.

> AstWinner and AstLoser to work on the prunes.

Although it is not clear what the benefit it has in this situation,
the spec DOES allows you to do it this way:

  If the unicast routing
  protocol does not store all available equal-cost paths in the  routing
  table,  the  "Address"  field  may  contain  the  address of the wrong
  upstream router. To avoid this  situation,  the  "Address"  field  may
  optionally  be  set  to  0.0.0.0 which means that all upstream routers
  (the ones that have the LAN as an outgoing  interface  for  the  (S,G)
  entry) may process the packet.

-Liming

---

From: [email-masked] (Ravi Shekhar)
Date: Fri, 13 Nov 1998 12:20:58 -0500 (EST)

>RouterDown starts his assert timer for 180 sec (default value).

    In the newer specs, assert-timeout has been changed to be same as 
    prune timeout - 210 seconds. 
    So assert-timeout and prune-timeout will happen at the same time on the 
    absolute clock and the state of the network will be same as the one you
    began with - that is both the routers sending the data at the same time
    as downstream router times out the assert-winner.

    Situations similar to the possibilities you described below could happen 
    under different condition - lets say when prune is sent 10 seconds after 
    assert happens. But that has been pointed out and taken care of in the 
    draft through the fact that prune is sent with the holdtime of 
    "SMALLER VALUE BETWEEN  THE PRUNE  HOLDTIME  THE SYSTEM USES, AND THE 
    REMAINING ASSERT TIMER VALUE BEFORE ITS EXPIRATION", which in the above 
    example will be (210-10 =) 200 seconds.

    This way prune-timeout and assert-timeout are always aligned on the 
    absolute clock. 

    - Ravi Shekhar.