Subject: [manet] Fwd: Next step for RSN ?

From: JP Vasseur <[email-masked]>
Date: Wed, 23 May 2007 04:36:29 +0200

FYI - Feel free to register to RSN and provide feed-back if of interest.

Thanks.

JP.

Begin forwarded message:

> From: JP Vasseur <[email-masked]>
> Date: May 23, 2007 4:33:31 AM GMT+02:00
> To: [email-masked]
> Cc: David Culler <[email-masked]>
> Subject: Next step for RSN ?
>
> Dear List members,
>
> Looking at the number of people who registered to this list, there  
> seems to be a strong interest in designing a Routing solution for  
> Sensor Networks. David and I had during the last few months a  
> number of off-line discussions with positive feed-back and support,  
> it is now a good time to use the Mailing List to gauge whether  
> there is a consensus on whether to work on this topic.
>
> David provided an excellent problem statement below. I'd like to  
> add a few comments and get feed-back from the ML members on whether  
> we collectively want to work on this item.
>
> With no doubt, we'll see many other radio networks emerging soon  
> and sensor networks will soon be made links using various layer1/2  
> protocols defined by other SDOs: 802.15.4, Wifi, WiMax but also non  
> wireless links. Such networks will also comprise sensor nodes with  
> a wide range of capabilities, which makes the routing fairly unique  
> in term of requirement. Thus the proposal is to design a IP routing  
> solution specifically for sensor networks, that would of course be  
> independent to the L1/L2 protocol in use (it may be desirable to  
> take into account link layer attributes when calculating a route  
> but the routing process would not be tied up with the link layer).
>
> 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.
>
> What would be a charter proposal ?
>
> First we would need to spend a good amount of time on the routing  
> requirements. David and I posted a first revision of a generic  
> requirement draft (draft-culler-rsn-routing-reqs-00.txt); the next  
> revision will soon be posted accounting for the comments received  
> so far. I would propose to continue to list the generic  
> requirements in this draft and have other application-specific  
> routing requirements drafts discussed in other IDs: for home  
> networking, industrial applications, ... Such approach has been  
> successfully adopted in other WGs.
>
> 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.
>
> Note that we may not be able to satisfy all the requirements, and  
> this might be perfectly acceptable and should be documented.  
> Indeed, we all know that Sensor Networks may significantly differ  
> in term of degree of mobility, link layer reliability/bandwidth,  
> node constraints, ... A very good outcome of this work might be  
> that the newly defined/adapted protocol could satisfy the  
> requirement IDs A, B, D and E but not C.
>
> So please use this list to provide feed-back on whether you would  
> support such initiative and if so your contribution is more than  
> welcome. Note that several people already mentioned some interest  
> and we do expect to see new IDs posted before Chicago.
>
> JP and David.
>
> Begin forwarded message:
>
>> From: "dculler" <[email-masked]>
>> Date: May 23, 2007 1:24:58 AM GMT+02:00
>> To: <[email-masked]>
>> Subject: [RSN] Interest in the Interplay of "routing" and "meshing"
>> Reply-To: [email-masked]
>>
>> Several of the comments on this list have touched on the issue of  
>> different kinds of "multihop routing" in the context of sensor  
>> networks.  Is there interest in working on how these forms of  
>> routing tie together?
>>
>> To make the question more grounded:  Low power radios have  
>> relatively short range.  IEEE 802.15.4 radios are typically 1 mW  
>> transmit power, vs 100 mW for 802.11, and have typical ranges in  
>> 10s to 100 m.  Generally speaking, the power required to  
>> communicate a given distance by radio grows polynomially with  
>> distance.  In typical settings it grows like the cube, but it can  
>> be much worse near the ground or somewhat better with directional  
>> antennas.  The cost to communicate hop-by-hop grows only linearly,  
>> and it offers the potential to route around obstacles and enhance  
>> reliability through "receiver diversity".
>>
>> The question is at what layer(s) in the stack this routing occurs  
>> and how it relates to IP routing more generally.  Most multihop  
>> protocols in the sensor network research community are effectively  
>> at layer2 - they form a single "patch" of homogeneous media.   
>> Logically, they are a subnet, although few of the protocols  
>> address what happens beyond the "patch" of sensor nodes, other  
>> than that some of the nodes are "gateways".  Current industry  
>> standards, such as Zigbee, Zwave, and wirelessHART, are also a  
>> "multihop link", leaving open the question of how nodes within the  
>> sensor patch communicate with nodes outside.
>>
>> 6LoWPAN provides a compressed header format for "mesh routing",  
>> meaning multihop forwarding of packets within the 802.15.4 link.   
>> Such a link is assumed to be formed by a contiguously connected  
>> set of 802.15.4 nodes.  The presence of such "mesh routing"  
>> capabilities does not eliminate the need for layer 3 routing.  If  
>> a 15.4 node communicates with a remote node, say an 802.11 node,  
>> how is routing and forwarding carried out?  If two "LoWPAN  
>> subnets" [sic] happen to be connected by 15.4 nodes, how does 15.4- 
>> to-15.4 routing occur?  The 6LoWPAN header format is, of course, a  
>> general solution for carrying IP over 802.15.4, so it is able to  
>> express these other forms of routing, as well.  In the extreme  
>> case, each individual node is an IP link and all routing is done  
>> at the IP layer.  On the other hand, patches of nodes may want to  
>> function as a logical subnet, even if the wireless multihop  
>> routing is done at the IP layer.  At this point, the concerns  
>> overlap with those addressed in autoconf (cf., draft-ietf-autoconf- 
>> manetarch-01).
>>
>> There is substantial commonality of concerns at the different  
>> layers of multihop routing, but also differences.  It is also  
>> important to separate the process of forming a routing topology  
>> from the process of forwarding packets.  Both of which are  
>> distinct (but not entirely independent of) how power management  
>> (turning on/off the radios) is performed.
>>
>>
>> _______________________________________________
>> RSN mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/rsn
>

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