Subject: [6lowpan] Re: [RSN] L3 mesh requirements

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

Hi Bernard,

On Jul 9, 2007, at 5:50 PM, Bernard Tourancheau wrote:

>
> Le 21 juin 07 à 23:00, JP Vasseur a écrit :
>
>> Hi Bernard,
>>
>> On Jun 19, 2007, at 4:39 PM, Bernard Tourancheau wrote:
>>
>>> Hello all,
>>> A few comments, probably very naive, I did not read entirely the  
>>> archive.
>>>
>>> Other wireless networks do not have the strong energy constraint,  
>>> memory constraint, ... that sensors have. Thus lowpan deserves a  
>>> different perspective to reflect its physical reality. Routing  
>>> will be hierarchical because of the different capabilities of  
>>> each nodes.
>>> We may "classify them by their routing resources ?:
>>>
>>> Type		| Capability						Fonctional Device
>>> -------------------------------------------------------------------- 
>>> ----------------------------
>>> leaf nodes,	| send/recv								veryRFD?
>>> hop nodes, 	| send/recv/fwd+treatment?					RFD?
>>> bridge nodes.  | send/recv/fwd/multi-cast/treatment 			FFD?
>>> gateway nodes| send/recv/fwd/multi-cast/treatment + "always" up 	 
>>> veryFFD?
>>>
>>> We may associate L3 to only FFDs ? The L2 forwarding is not  
>>> mandatory, automatic and blind, somehow it defines a cluster,  
>>> representing the first stage of the hierarchy.
>>>
>>
>> At this stage, we've been working on the requirements. As pointed  
>> out in a previous email, it may not be a good
>> idea to take the superset of all the requirements of L2Ns (again  
>> let's try to use that terminology to refer to Low Power
>> and Lossy Networks, which includes Sensor Networks but is not  
>> restricted to it).
>>
>> Why ?
>>
>> Because they drastically differ ... thus this may lead to trying  
>> to design a routing protocols satisfying conflicting requirements
>> if we want to indeed design a network for light footprint nodes.  
>> Thus the proposed approach is to have (in addition to the
>> generic ID above), several applications specific requirements  
>> documents and define the protocol as a set of loadable
>> components.
>>
>> I know that two IDs are in the works:
>> 	(1) Home Automation
>> 	(2) Industrial application
>>
>> We would probably need to have another one for healthcare.
> Hi JP,
> I agree with your points.
> ID classes could be defined for severals needs: for weather  
> forecast, for aerospace, for automotive, for electrical/gaz/sewage/ 
> water grid, for environement temperature, ...

Yes, for the time being we'll try to focus on a few ones since in  
this area it is "easy"
to get the work diluted but also to end up with a such a sparse  
ranges of requirements
that no single protocol could satisfy all of them. At the end, we may  
very end up having
a solution of "some" of these applications, which in my opinion would  
be perfectly
acceptable, considering that today there is NO IP solution for L2Ns.

>>
>> Back to your point, in a second step, we may decide to classify  
>> nodes by category although I personally prefer to use
>> nodes attributes to provide a better granularity, to be discussed  
>> with the group of course. Then the routing design will
>> follow.
>>
>> At this point, I think that it is crucial to carefully analyze the  
>> requirements ... although I know that we are all tempted to
>> jump into the protocol design discussion.
>>
>> Would you want to provide comments to http://www.ietf.org/internet- 
>> drafts/draft-culler-rsn-routing-reqs-00.txt?
> This is interesting and of course "the" very good start !!!. I  
> would add sections about broadcast and multicast that will be a  
> requirement for L2N, at least for weak-up, alarm, data  
> collection, ... all the event-based control of these devices, not  
> speaking about neighbor discovery, announcement, routing set-up, etc.
> I am also wandering about the possibility for a device to have  
> several addresses or a range of addresses, for instance one for  
> each sensing collector.

We briefly introduced the notion of "Groupcast" in the home  
automation ID. Neighbor
discovery, ... would typically be addresses by 6lowpan but the  
routing protocol would
of course have to support it.

Feed-back from 6lowpan ?

>>
>> As I said other related IDs will be soon follow.
>>
>>> About mobility or slow mobility:
>>> Are we sure this is a requirement for our targets ? As long a  
>>> connection exist no problem, its physical strength or the  
>>> forwarding path can vary due to slow mobility, energy level or  
>>> environment movements. When some connection is lost, let call it  
>>> broken link. A new connection in another forwarding cluster needs  
>>> dhcp style renegociation.
>>
>> See this is why we need application specific IDs. If it turns out  
>> that mobility is not a strong requirements it would be good to know
>> it before making the assumption that it is required, although in  
>> this particular case I think it is ;-)
> Ok, my point here was that for RFDs, mobility may not have the  
> strong IP meaning but just "disconnected" or less connected  
> meanings. I am not sure RFDs should spend energy dealing with  
> complex mobility protocols.

Absolutely. The routing protocol would have to be flexible enough to  
not activate some
of the routing function on the most constrained node.

Cheers.

JP.

> Cheers,
> Bernard.
>>
>> Thanks.
>>
>> JP.
>>
>>>
>>> My 2motes,
>>> Bernard.
>>>
>>>
>>> _______________________________________________
>>> RSN mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/rsn

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