Subject: RE: The Assert Mechanism: Part 2 :)

From: "Shekhar, Ravi" <[email-masked]>
Date: Tue, 26 Oct 1999 16:34:23 -0400

I raised this question of data looping earlier
(http://netweb.usc.edu/pim/mail-archive/pim/archive.98.12). 
And I recvd two different answers indicating two different ways 
to handle it if I understood it right.

One was what Helmy pointed out and this is covered in 3.4:

           1 Forward the packet to the oif list for that entry,
             excluding the subnet containing S, and restart the Entry-
             timer if the matching entry is (S,G).  Optionally, the
             (S,G) Entry-timer may be restarted by periodic checking of
             the matching packet count. 

C gets data from RP in this case.

The other answer was from Dino, and as I understood it, it suggested 
that since all the routers(not just DR) attached to the subnet are already 
getting the data directly, they might as well create <S, G>SPT entry and 
send a prune for <S, G> towards RP. C gets data directly in this case.  
I dont think this is documented in the draft.

Is there preferred way of doing it?

- Ravi Shekhar.

> -----Original Message-----
> From: helmy [mailto:[email-masked]]
> Sent: Tuesday, October 26, 1999 2:48 PM
> To: Mohit Talwar (Exchange)
> Cc: [email-masked]
> Subject: Re: The Assert Mechanism: Part 2 :)
> 
> 
> If I remember correctly, I have studied Register looping in 
> my research
> and added a rule that a packet is never forwarded back onto 
> the LAN from
> which is originated, i.e., C should never forward the packets 
> onto the LAN
> to which S is attached.
> 
> On Tue, 26 Oct 1999, Mohit Talwar (Exchange) wrote:
> 
> > hi all,   
> > 
> > i think there is a rule missing from section 3.5.1 (Sending 
> Asserts) 
> > which will prevent the assert mechanism from stopping duplicates
> > downstream.
> > 
> > consider the following topology...
> > 
> >                                                     
> >                             +---+               
> >                             | A |               
> >                             +---+               
> >                               .                  
> >                               .                  
> >                               .                  
> >             +-+-+                           +-+-+
> >             | B |                           | C |
> >             +-+-+                           +-+-+            
> >               |                               |               
> > ----------+---------------------------------------+----------
> >           |                                       | 
> >           S                                     +---+
> >                                                 | D |
> >                                                 +-+-+
> >                                                   | 
> >                                                   R
> > 
> > A is the RP
> > B is the DR on the LAN
> > C is the RPF towards A for D
> > R is a receiver
> > S is a source
> > 
> > now consider the following sequence of events...
> > R joins a group G
> > D creates (*,G) state and sends the join on the LAN with C 
> as the target
> > C create (*,G) state and forwards the join upstream towards A
> > ---
> > S (source) starts sending data
> > B creates (S,G) state and sends the data packet in a register to A
> > D receives the data packet on the right incoming interface 
> and forwards it
> > to R.
> > C receives the data packet on an interface in its OIL (outgoing 
> > interface list) and sends an assert.  however the assert is ignored 
> > by both B and D since none of them have the interface in 
> their matching 
> > OILs.  hence C would not create an (S,G,RPT) tree entry and 
> delete the 
> > interface from its OIL.
> > ---
> > the register is de-encapsulated by A and sent downstream 
> towards C.  
> > C will eventually forward this data packet on the LAN which 
> again succeeds
> > the 
> > incoming interface check at D and is forwarded to R.
> > 
> > R keeps getting dups of each data packet sent by S to G!
> > 
> > i think the solution is to modify section 3.5.1 thus...
> > 
> > "
> >    The following Assert rules are provided when a multicast 
> packet is
> >    received on an outgoing multi-access interface "I" of an existing
> >    active (S,G), (*,G) or (*,*,RP) entry:
> > 
> >    0. if the source of the data packet is a local, directly 
> connected
> >       the router and the matching entry is (*,G), or (*,*,RP), the 
> >       router creates a (S,G)RPT-bit entry.  Otherwise, no 
> new entry is 
> >       created in response to the Assert.  the router should 
> then delete 
> >       the interface from the entry and restart the entry-timer.
> > "
> > 
> > basically the router should behave as if it lost the
> > assert election when the source is directly connected.
> > 
> > thanx,
> > mohit.
> > 
>

---

From: helmy <[email-masked]>
Date: Wed, 27 Oct 1999 21:30:36 -0700 (PDT)

Hi Mohit,

	About 3 years ago or so, Deborah and I conducted a systematic
testing of PIM through the "stress" methodology and unveiled some design
errors (some relating to correctness, other to robustness or performance),
on the Assert, Join/Prune and Register mechanisms in PIM-SM.
	This specific bug for register looping (that you alluded to) was
detected, and fixes were suggested to it (as well as others) with the aid
of the stress tools we've developed, and these fixes were added to the
latest spec then.
	[Back then we sometimes argued if the bugs we found were so
essoteric that they may not show up in reality.. look at us almost 3 years
down the road, it actually showed up :-)

	We have published our results in a paper titled 'Simulation-based 
'STRESS' Testing Case Study: A Multicast Routing Protocol', and you can
find the reports on-line either through my web page
	http://netweb.usc.edu/ahelmy/resume.html
	Deborah's web page 
	catarina.usc.edu/estrin

	[the figures should show on the printout, but they may not work
for Win-based ghostscript software!]

	or through the technical reports page for the cs dept
	www.usc.edu/dept/cs/technical_reports.html

	We are extending our systematic testing methodology to be more
automated and complete, and we have applied our latest test generation
algorithm (called fault-oriented test generation) to PIM-DM and got some
interesting results. You can also find our results in a paper titled
'Fault-oriented Test Generation for Multicast Routing Protocol Design'
available through the same web sites as above.

Thanks for your comments,

Regards,
-Ahmed	

> hi ahmed,
> 
> u r right,
> 
> i looked at the technical report and u do indeed talk about this
> case, and a few others. 

> could u do me a favor and send me an unzipped copy of the 
> report.  the one i got from the web refused to show the figures.
> 
> i think that the spec should say something about issues discussed
> by you in the report.  maybe i'll bring that point up next.
> 
> mohit.
> 
> >Sent: Tuesday, October 26, 1999 11:48 AM
> >If I remember correctly, I have studied Register looping in my research
> >> i think there is a rule missing from section 3.5.1 (Sending Asserts) 
> >> the register is de-encapsulated by A and sent downstream towards C.  
> >>    The following Assert rules are provided when a multicast packet is
> >>    0. if the source of the data packet is a local, directly connected