Subject: Re: [RSN] Next step for RSN ?

From: JP Vasseur <[email-masked]>
Date: Sat, 14 Jul 2007 09:06:24 -0400

Dear Alexanndru,

http://www.ietf.org/internet-drafts/draft-culler-rl2n-routing- 
reqs-01.txt may help you understand the specifics of L2Ns.

Thanks.

JP.

On May 24, 2007, at 7:17 PM, Philip Levis wrote:

> On May 24, 2007, at 7:34 AM, Alexandru Petrescu wrote:
>
>> Hi JP, I've received this on the MANEMO list but I'm replying here.
>>
>> I have some comments, more like against forming the RSN work, but
>> I'm ok with all other opinions too :-)
>>
>> One is that I generally don't really see why routing for sensor  
>> networks
>> is different than other networks.  Or maybe that it is generally too
>> early for that.
>
> Routing for sensornets is different than other networks because  
> they operate under different constraints. The two major differences  
> are:
>
> 1) Nodes are energy-limited.
> 2) One repercussion of 1) is that nodes are state-limited.
>
> You can take existing routing approaches, such as AODV, DYMO, GPSR,  
> etc. and apply them to sensor networks. Users have done so.  
> Practice has shown, however, that they don't work that well and  
> generally aren't a very good fit. Instead, working versions of  
> these protocols typically constrain the protocol. For example, the  
> AODV implementation for sensor nodes[1] supports routing to a  
> single destination.  High densities, combined with slow radios (a  
> product of energy concerns), make flooding discovery such as AODV's  
> tricky to get right, especially without some kind of scoping.  
> Fundamentally, links behave differently during a flood than during  
> unicast flows due to the correlations in packet transmissions.
>
> David summarized many of the implications of 2) very well in a  
> message to the 6lowpan list. In the context of routing, having each  
> node store up to O(n) state is generally unfeasible. Capping the  
> routing state to some value R obviously has problems if you need R 
> +1 routes. Achieving scalable unicast communication within a state- 
> limited wireless network is a very active area of research. Right  
> now, the state of the art (S4, presented at NSDI in March, which  
> uses compact routing) requires O(sqrt(n)) state. Achieving this,  
> however, requires embedding a little bit more information in a  
> routing packet besides the destination address.
>
> Phil
>
> [1] tinyos-1.x/contrib/hsn/tos/lob/AODV.nc from http:// 
> sourceforge.net/cvs/?group_id=28656

_______________________________________________
RSN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rsn

---

From: JP Vasseur <[email-masked]>
Date: Sat, 14 Jul 2007 09:18:25 -0400

Hi Pascal,

On May 24, 2007, at 9:45 AM, Pascal Thubert ((pthubert)) wrote:

> Hi JP:
>
> Please see inline:
>
> It looks fairly obvious that a network made of N "mesh-under"  
> routing protocols is very unlikely to satisfy an end to end path  
> constraint and would be fairly complex to manage and tune. We all  
> remember the issue of IP routing over ATM PVCs routed by PNNI.  
> Think of this with N "Mesh-under" routing protocols. That said,  
> this is not to say that we exclude the use of "mesh-under"  
> solutions, but we propose to define a IP-based routing protocol.
>
> Pascal => I agree there's a lot of value to federate over IP the  
> various approaches that are defined for mesh-under.

Indeed.

>
> The second step would consist of making a survey on the existing  
> routing protocols and see whether (1) they could be used as such  
> (2) they should be adapted (for instance, see whether AODV or OLR  
> or RIP could be made energy efficient, could support some form of  
> constrained based routing, ...) or (3) we should design a new  
> generic new protocol.
>
> Pascal => One aspect of this could be to consider the features that  
> mesh and sensor networks have deployed and why, and then see if  
> there is a need to generalize the approach at layer 3. For  
> instance, offline routing is popular in WSNs while not the  
> prominent model in IP or MANET.
>

Good point indeed (see TSMP, ...). There is a bit of off-line at the  
IETF for MPLS but indeed not that much on IP. On the goal of the RSN  
WG (should it be formed) would precisely to evaluate the pros/cons of  
all approach and supporting a mix approach might be an option.  
Anyway, food for future thoughts.

Back to the protocol survey, a very first draft is available and  
requires much more work.

Folks from MANET would be very welcome to provide feed-back/comments/ 
suggestions/...

> Pascal => Another specificity could be to work on a tighter  
> integration with the radio and a more specific abstraction for L3.  
> I know we have that barrier at IETF against L2 related activities.  
> Yet, if the radio model provides such things as beacons, then it  
> could be beneficial to define a routing protocol that can take  
> advantage of the beacons. At the moment, IP is carried in data  
> frames only.

I agree that we need an L2 abstraction layer since RF links in  
particular are quite specifics and their characteristics must be  
known by the routing protocol when they influence the routing  
decision, as stated
in draft-culler-rl2n-routing-reqs-01. By the way, you and I have the  
action plan to produce that ID ;-)

Back to your example on beacon, I would personally prefer to maintain  
a clear separation between
layer to keep the L2 agnostic nature of routing. Why not defining  
local inter-layer mechanism (out of the
standardization scope) as we do with many other media ?

>
> Pascal => We'll also have to work out the relationship with MANEMO.  
> My understanding is that MANEMO is for bigger boxes (routers  
> really) and has strong mobility and global reachability  
> constraints. That makes it pretty different in the objectives.  
> OTOH, there seems to be value to keep sharing views and ideas  
> between the groups, should they form.

You are 100% right. One option might be to concentrate all routing  
function in one place or to clearly differentiate the routing  
objective. We do need to avoid any overlap. We (RSN) should provide  
feed-back
to MANET (I just assigned an action item to myself ;-)) and vice versa.

Thanks.

JP.

> Pascal