Subject: [RSN] L3 mesh requirements

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Fri, 15 Jun 2007 15:10:22 +0200

Hi:

There is a common need in MANEMO and RSN to define the specific needs
for establishing a Layer 3 mesh network. In both MLs, we have pending
work on listing these requirements, and then explaining how existing
MANET techniques apply or not.

>From there, we can derive what work is needed and how that could be
split between existing and newly created WG(s). There have been many
talks in both ML about these issues. I'm trying here to summarize what I
read so far as mesh characteristics in the form of simple one-liners. 

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.

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. 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...

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. Routing should proactively maintain the path between the
mesh nodes and the sinks, back and forth. 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.

R4) Routing within the mesh also appears in a number of use cases. The
routing requirements might vary depending on the application and might
also depend on the way the mesh is built. For instance, it could
possible to interconnect mesh nodes from the inside of a mesh over a
MANET routing protocol, or via the infrastructure over the mesh protocol
and NEMO. 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.

R5) A mesh network is self-forming and self-healing. This means that the
mesh links are not preexisting like in the wired world and peer
selection must occur to form those links before routing takes place over
them. The list of selected peers must be reevaluated as the conditions
change (movement, interferences, low battery, etc...). 

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 did I miss? Fire at will...

Pascal

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 15 Jun 2007 09:13:49 -0700

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.

> 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".

> 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
 
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.

> 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
 
Check.  Except, that we might want to fiddle with the Agent Advertisements.

> R4) ... The mesh routing protocol should be interoperable with the

 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.

> 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.

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Tue, 19 Jun 2007 18:45:27 +0200

Hello Charlie,

It's just too easy to drag me into solution space. I'll (try to) resist!
Please see inline

>[manemo] mailing list at all.

[Pascal] There's MANEMO history for sure, but also a lot of background,
specifically from 802.11s (which involves AODV for inner routes :) and
802.16J, and 802.15.5, and ISA SP100, and wireless HART, and 6LoWPAN and
RSN at IETF...

>nodes and that infrastructure".

[Pascal] I'd say it depends on which problem you're trying to solve, and
we're specifying just that. 
I based this requirement on mesh and sensor networks as they exist today
or seem to come up in the near future. If you consider a municipal wifi
mesh network or a factory sensor network, both are connected to an
infrastructure and aim specifically at giving connectivity to that
infrastructure. One common goal for RSN and MANEMO is to structure that
access in a standard L3 way as opposed to leaving it to L2 specific or
proprietary solution as they exist today.
Now, what you say makes perfect sense to me and the requirement here is
already opened to the disconnected case. It could be good to apply the
same technology to build disconnected WLCs (Very Very Large Clusters :)
and enable some hierarchical routing. But we need a focus for choosing
the way we optimize things in short term and this seems to be related
with the concept of sink, which in our case interconnects with the
infrastructure.

>to route, but able to do so in a pinch.
[Pascal] Yes, that metric is one of the big items to work on. Teco calls
it UPM. Also the concept of being either a router, a relay (forwarder)
or a mere terminator, and changing roles upon needs. Oups, no solution,
I promised.

>controversy over patent rights.
[Pascal] Ouch! This is a good question for RSN. Could that be a service
that 6LoWPAN provides and RSN uses in LoWPANs but MANEMO doesn't? 

>to every network in the Internet, if we consider a host to be a
"sensor".
[Pascal] I mean as opposed to intra mesh communication. In a city mesh,
people go to their web site. Same as Starbucks in fact: people'd rather
start their VPN before a friendly neighbor invades their system.

> Doesn't this remain to be seen?  What about mesh nodes that are
[Pascal] In RSN, we might very well introduce synchronization between
the nodes to let them sleep. Does not prevent from keeping proactive
routes, mostly when (most of) the sleepers are not doing their routing
themselves, does it?

>Check.  Except, that we might want to fiddle with the Agent
Advertisements.
[Pascal] That's more on the MANEMO side now :) Maybe the BU frequency
can be aware of the mesh frequency? Hopefully MANEMO does not nee to
change NEMO. But maybe it does?
>(hmm... two should be here this year, we think) can be engineered into
a
[Pascal] That's fine :) I could not find a wording to mean 'another
protocol than the mesh protocol itself'. This does not preclude an
elected (modified?) standard MANET protocol to become the mesh
protocol... Also, I hardly believe that there can be 2 mesh protocols.
But maybe there can be a common minimum backplane that does the minimum
trick and which both MANET protocols could benefit from for scaling and
interconnecting via the infrastructure?

>more expensive in a lot of cases.
[Pascal] 802.11s does that reactively. The idea is to recognize that
inner routes are not as traveled and should not be always maintained at
all cost, because most traffic is to the outside anyway. I can see your
smile :) This is not a sure win for reactive, though. We could use Least
Overhead Routing Approach as well. This is how MANEMO presents it at
least. I like the idea to have a somewhere to forward a packet, even if
that's not the best somewhere. That helps separate routing and
forwarding. Also, I'm still confused with aggregation in reactive
protocols, and how we can lookup a prefix, though DYMO has provision to
carry a prefix length.

Good debates ahead!

---

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

Hi,

> nodes and that infrastructure".

Eventually there might even not be any distinction between such  
infrastructure and the current
Internet. I personally think that in a few years from now, we will  
consider things as regular
Internet hosts. From a routing standpoint such L2N (Low Power and  
Lossy Networks) will be
running different IGPs than the usual core routing protocols but this  
is perfectly fine.

> to route, but able to do so in a pinch.

I think that we must make the distinction between nodes constraint  
and node attributes. Current IGPs
do not handle node constraints when computing the shortest path. As  
you pointed out, we may
manipulate the cost of the links attached to a node for example to  
avoid the routing of packets
through that node. Now the ability to consider some node attributes  
to influence the routing decision
(for example, route packets to D through node X because it performs  
data aggregation) although X may not
be on the shortest path to the D is a different issue, not supported  
by the current routing with the
exception of constrained-based routing (e.g. MPLS).

> has it in their sights.

Yes I do think that we need to deal with this issue. Input welcome of  
course.

> Unfortunately, it seems to attract

Patent rights ?

> to every network in the Internet, if we consider a host to be a  

Pascal's point was I think related to the Point to Multipoint and  
Multipoint to Point
traffic pattern nature of most of the sensor networks, as opposed to  
the "more"
any to any nature of the traffic pattern in the Internet (more common  
with peer to peer).

> Doesn't this remain to be seen?  What about mesh nodes that are

Requires sync up.

> Check.  Except, that we might want to fiddle with the Agent  

Pascal, why "compatible" with NEMO ?

> 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.

I also think that this is debatable. Should we need to define a new  
routing protocol, we
should not try to take into account existing protocols. It is a good  
idea to keep them in
mind but without trying to constraint the design to existing  
protocols. Of course, we may
have to then define route redistribution schemes.

>> bandwidth, etc...).

Pascal, as discussed (thus I know that we are on the same page), we  
should define
ways to translate the Layer2 information into new routing metrics  
rather than having
to have inter-layer dependencies. For the list, Pascal and I are  
working on a new ID.

>> Because a scanning process might be involved at

Yes and I think that although the routing protocols should be  
optimized for P2MP
and MP2P, this MUST also support any to any since L2Ns are not just  
Sensor Networks.

Cheers.

JP.

---

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

Hi Pascal,

On Jun 19, 2007, at 12:45 PM, Pascal Thubert ((pthubert)) wrote:

>> I don't think a mesh has to be connected to the Internet.   
>> Instead, as
> you

Can't agree more. No need to argue here that we do not want see the  
explosion of
protocol translation gateways ... we went through that path several  
times during the
last 2 decades.

> with the concept of sink, which in our case interconnects with the

Yes I would just slight soften this statement. Optimize for P2MP/MP2P  
(leaf <-> sink)
with a support for any to any (not all to all).

>
>>
>>> R2) Mesh nodes are not all equal. There are wired sinks which  
>>> connect
> to

I think so although there will certainly be a need for some sort of  
compression at
the routing layer.

> routes, mostly when (most of) the sleepers are not doing their routing

That was also my point in my previous answer.

> MANET
>> into

I really hope not ... that would defeat our goal to design a simple  
solution. We have to bear
in mind that in most deployment scenarios these networks will be self- 
managed. The level of
complexity of having to deal with N>1 routing mesh protocols would  
certainly be an issue.

>> in the area...  Or, did you want the sinks to be required  
>> intermediate
> nodes

Surely.

Cheers.

JP.