Subject: RE: [RSN] L3 mesh requirements

From: Bernard Tourancheau <[email-masked]>
Date: Tue, 19 Jun 2007 22:39:13 +0200

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.

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.

My 2motes,
Bernard.

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

---

From: JP Vasseur <[email-masked]>
Date: Thu, 21 Jun 2007 17:00:36 -0400

Hi Bernard,

On Jun 19, 2007, at 4:39 PM, Bernard Tourancheau wrote:

> ---------------------------------------------------------------------- 
> --------------------------

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.

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?

As I said other related IDs will be soon follow.

> 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 ;-)

Thanks.

JP.