Subject: [Roll] An alternative to RPL

From: Mukul Goyal <[email-masked]>
Date: Sun, 26 Jul 2009 20:53:53 -0500 (CDT)

Hi all,

Please see a new draft describing an alternate routing solution for LLN:

http://www.cs.uwm.edu/~mukul/draft-goyal-roll-dv-01.txt

This solution allows optimal (or good quality) routes to be achieved to any destination in the LLN (and not just the LBRs as in RPL). Both multipoint-to-point and point-to-point traffic can use this solution.

In this solution, only routers in the vicinity of existing routes maintain state about a destination once the route discovery is done. 

The solution uses the loop correction strategy I described in an earlier email combined with data packet based loop detection.

I will submit this draft to IETF repository once it allows me to do so (right now I can't submit a new draft).

Thanks
Mukul

---

From: [email-masked]
Date: Wed, 29 Jul 2009 16:42:33 -0500

Mukal,

Attached are my comments on your submission.  In total, I like the 
approach.  The idea of monitoring and repairing loops rather than 
architecturally disallowing loops is simple and seems effective. 

I can't say I completely understood the entire draft.  I think a few well 
placed examples would help.  Also there seems to be cases (see p7) where 
you temporally eliminate route discovery requests.  Not sure why this is 
needed. 

Following are my detailed comments.

p4: Routing domains

I am not sure why we would want to define routing domains.  This is extra 
configuration effort that doesn't necessarily add any value.  I wouldn't 
know a priori how to define the logical entities.

p5:#4:Routing Table

The neighbor discovery process is different than 6LoWPANs.  Can't we build 
the neighbor lists using 6LoWPAN ND algorithms?

p7:bullet 6

I don't understand why we would build a list of all unreachable 
destinations.

Mukul Goyal <[email-masked]> 
Sent by: [email-masked]
07/26/2009 08:54 PM

To
roll <[email-masked]>
cc

Subject
[Roll] An alternative to RPL

Hi all,

This solution allows optimal (or good quality) routes to be achieved to 
any destination in the LLN (and not just the LBRs as in RPL). Both 
multipoint-to-point and point-to-point traffic can use this solution.

In this solution, only routers in the vicinity of existing routes maintain 
state about a destination once the route discovery is done. 

The solution uses the loop correction strategy I described in an earlier 
email combined with data packet based loop detection.

I will submit this draft to IETF repository once it allows me to do so 
(right now I can't submit a new draft).

Thanks
Mukul 
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll