Re: [RSN] L3 mesh requirements

[[e-mail]]

Quick comment on something you said, Charlie:

Is [rsn] going to tackle compression?  That would be a great
area for development, and I don't think any other group even
has it in their sights.  Unfortunately, it seems to attract
controversy over patent rights.


FYI, 6lowpan does have provisions for simple header compression in the mesh:

        http://tools.ietf.org/html/draft-ietf-6lowpan-format-13#section-10

-gabriel

----- Original Message ----
From: Charles E. Perkins <[e-mail]>
To: ext Pascal Thubert (pthubert) <[e-mail]>
Cc: [e-mail]; [e-mail]
Sent: Friday, June 15, 2007 6:13:49 PM
Subject: Re: [RSN] L3 mesh requirements


Hello Pascal,

A few comments -- please excuse if I missed the relevant
discussion since I am far behind on [rsn] and not even on the
[manemo] mailing list at all.

ext Pascal Thubert (pthubert) wrote:
> R1) A mesh network is a radio network connected to an infrastructure
> such as the Internet, and aimed at providing Routability between mesh
> nodes and that infrastructure, back and forth and at most times; still,
> the mesh should be able to operate for local communications when
> disconnected from the infrastructure.
>   
 I don't think a mesh has to be connected to the Internet.  Instead, as you
mention, the mesh can work well as a self-contained network, and yet offer
Internet connectivity whenever it is available.  This may be viewed as
intermittent or perhaps even seldom.  So, I would not want to say that
the mesh has to be "aimed at providing Routability between mesh
nodes and that infrastructure".

> R2) Mesh nodes are not all equal. There are wired sinks which connect to
> the infrastructure, fully functional devices (FFD), and reduced
> functional devices (RFD). RFD are characterized by severely limited CPU,
> memory and battery capacity; they should not be involved in routing and
> forwarding but to the bare minimum.

 This can be done if the metric is appropriate and the measurements are
done properly.  So, for instance, a node could indicate that it is unwilling
to route, but able to do so in a pinch.

>  Because radio and battery are
> limited resources everywhere, the amount of control messages should be
> reduced to a minimum and optimized by compression, piggy backing etc...
>   
 
Is [rsn] going to tackle compression?  That would be a great
area for development, and I don't think any other group even
has it in their sights.  Unfortunately, it seems to attract
controversy over patent rights.

> R3) The most common use case is to connect mesh nodes with middleware,
> applications servers and peer nodes located over the infrastructure, via
> mesh sinks.

 I am puzzling over the actual content of this sentence.  It seems to apply
to every network in the Internet, if we consider a host to be a "sensor".

>  Routing should proactively maintain the path between the
> mesh nodes and the sinks, back and forth.

 Doesn't this remain to be seen?  What about mesh nodes that are
tired and want to sleep?

>  It should be possible to avoid
> incremental cost linked to routing to other destinations. Also, the mesh
> protocol should be compatible with NEMO and enable mobile nodes to
> attach to their Home Agents over the mesh without the need of an
> additional MANET protocol.
>   
 
Check.  Except, that we might want to fiddle with the Agent Advertisements.

> R4) ... The mesh routing protocol should be interoperable with the
> standard MANET routing protocols in terms of external routes
> redistributions and so on, but should not depend on a specific instance
> of a MANET protocol being deployed.
>   

 This is debatable.  Especially, if it turns out that a "standard" MANET 
protocol
(hmm... two should be here this year, we think) can be engineered into a 
good
choice for mesh routing.

> R6) Peer selection and routing occur with the objective to reach a sink;
> this is based on Layer 3 information (peer type, reachability, path
> metrics to the sink...) as well as Layer 2 information (RSSI to peer,
> bandwidth, etc...). Because a scanning process might be involved at
> layer 2 to sustain the peer selection mechanism, it is desirable that
> the initial peer list be established in pure listening (monitor) mode.
>   

 What if two non-sensors, that are currently deployed in the field, want to
use the sensor mesh to communicate with each other?  Surely you would
not like to burden the mesh with a whole new set of protocols just because
a couple of people happened to want to make use of it while they are
in the area...  Or, did you want the sinks to be required intermediate nodes
in every peer-to-peer communications?  That could make connectivity even
more expensive in a lot of cases.

Regards,
Charlie P.




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

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