Subject: [Roll] [Fwd: Re: [Fwd: thoughts on RPL -01]]

From: Thomas Watteyne <[email-masked]>
Date: Wed, 23 Sep 2009 17:54:06 -0700

Dear WG,
As per JP Vasseur's suggestion, please find our thoughts on RPL -01.
Thomas

-------- Original Message --------
Subject: 	Re: [Fwd: thoughts on RPL -01]
Date: 	Tue, 22 Sep 2009 21:59:34 +0200
From: 	JP Vasseur <[email-masked]>
To: 	Kris Pister <[email-masked]>
CC: 	[email-masked], Thomas Watteyne 
<[email-masked]>
References: 	<[email-masked]>

Excellent feed-back, as expected from
[...]
Thomas, please send on the ROLL ML.

Cheers.

JP.

On Sep 22, 2009, at 5:22 PM, Kris Pister wrote:

> I asked Thomas, chief implementer in my UCB lab, to share his thoughts 
> on implementing RPL.
>
> ksjp
>
> -------- Original Message --------
> Subject: 	thoughts on RPL -01
> Date: 	Mon, 21 Sep 2009 22:59:59 -0700
> From: 	Thomas Watteyne <[email-masked]>
> To: 	Kris Pister <[email-masked]>
>
>
>
> Kris,
>
> All by all, I believe ROLL is going in the right direction. The DT has 
> successfully kept focus on collection networks, for which a 
> gradient-based solution makes perfect sense. I came to this conclusion 
> last summer after deploying an 86-node “urban” network, running an 
> RPL-like single DAG network with hop count as a gradient metric, and 
> two distinct sinks. http://senseandsensitivity.rd.francetelecom.com/ 
> provides an interface to the database filled with the data collected 
> and shows the topology, path length and many other performance 
> measurements. I have an implementation of the same protocol stack 
> which runs on 1kB RAM eZ430-RF2500 motes, proving the extreme 
> simplicity of this approach. Similar deployments (including to some 
> extent Phil Levis’ CTP) have shown that gradient-based solutions is 
> simple and that it copes with the dynamic nature of the networks we 
> deal with. Long live DAGs. 
>
> That being said, while RPL has started off a sane basis, it has gained 
> so much weight it is becoming unmanageably heavy (-01 currently 
> features 88 pages, compared to the 39 page RIP v2). As it stands, this 
> protocol is too complex to be adopted or simply implemented. There 
> seems to be an unhealthy urge of expliciting every possibility, for 
> use cases which look very theoretical. When trying to please all the 
> requirements, MANET-type constraints are pointing their nose. I 
> believe that RPL should focus primarily on collection, with simple 
> source routing enabling outward traffic. Please, no more.
>
> There are some technical aspects I feel uncomfortable with:
> - Nodes are asked to use many timers to enforce correct execution 
> order. This calls for race conditions. I believe that inconsistencies 
> in the DAG structure (aka transient loops) should be tolerated, as 
> they are ironed away by Trickle driven updates.
> - Nodes in the network are asked to maintain lots of state, sometimes 
> coordinated between nodes. One example is that neighbor nodes are 
> grouped into four different lists, some of which need to be 
> held-up/hold-down, while the node transitions to one DAG which 
> (hopefully) features better performances. 
>
> Yet, I see many opportunities to simplify RPL, such as:
> - Simplifying the DAG structure. Multiple DAGs can be maintained 
> throughout the network, each DAG having its own set of LBR’s and/or 
> OCP. The catch is that all nodes participate in all DAGs at the same 
> time, therefore maintaining multipath ranks, one for each DAG. This 
> avoids the need for nodes to change DAGs, and RA’s can be propagated 
> throughout the network, updating all DAGs at the same time. Depending 
> on its content, a node then decides to send a packet on one of the 
> available DAGs. Nodes maintain state for each DAG (i.e. the node’s 
> rank, plus the ones of its neighbors), which seems to be less than the 
> state -01 requires.
> - Simplifying the forwarding engine. A node knows the rank of its 
> neighbors, which it maintains through the regular exchange of 
> RA-DIO’s. It sets its rank to min(neighbor_rank+cost_to_neighbor), and 
> orders its neighbors by increasing rank. It tries each neighbor in 
> that order, while refraining to send to neighbors which have an equal 
> or higher rank.
>
> I am looking forward to hearing your comments. I would be very happy 
> to work on simplifying RPL, as I am convinced that is has the base 
> ingredients to make it a highly acclaimed networking dish.
>
> Thomas
>