Subject: [Roll] Discussion on draft

From: Philip Levis <[email-masked]>
Date: Thu, 27 Mar 2008 20:43:12 -0700

I'd like to start a discussion on draft-levis-roll-overview-protocols.  
In particular, Section 5.8 has a table of several existing protocols  
and their properties. This table is really going to be critical in  
ROLL's assessment of existing technologies and protocols, so we want  
to make sure that

1) It has the relevant data points to compare (protocols/rows)
2) It distills what the important properties are(columns)
3) It accurately captures the properties of the values in question  
(cells are accurate)

Let's start with 1), as it's probably the simplest. Are there any  
protocols that we should be including that aren't there? Trying to  
cover every single minor protocol tweak is a recipe for disaster, but  
protocols that differ significantly from those currently there, either  
in mechanism or in properties, are important to include.

Phil
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 28 Mar 2008 08:52:10 +0100

Hi Phil,
Maybe this raised before, but I miss a category of "xxx" protocols,
sometimes referred as "mesh" protocols.
"Mesh" is not pure MANET, as MANET routing protocols typically provide paths
within the MANET. "Mesh" protocols provide paths between nodes and a
backbone network.
MANET protocols can provide paths to the backbone also. The other way is not
always true, "mesh" protocols do typically not provide paths between nodes
or at least this is the second priority.
Maybe the draft only discuss existing IETF protocols (e.g. RFC exists or WG
is chartered), but I think the "mesh" type of protocols is worth mentioning.
Regards, Teco

> -----Oorspronkelijk bericht-----
> Van: [email-masked] [mailto:[email-masked]] Namens
> Philip Levis
> Verzonden: vrijdag 28 maart 2008 4:43
> Aan: [email-masked]; manet manet
> Onderwerp: [manet] Discussion on draft
> 
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 28 Mar 2008 09:20:24 +0100

That's a very interesting point. 

For most applications I know of in sensor networks, there is a concept
of manager, gateway or backbone router that acts as a sink for the
sensor network. If that's how we characterize a mesh network then this
is clearly a typical situation. 

Another very typical thing is that when the network grows large,
multiple sinks are deployed and can be interconnected by a high speed
backbone that is of a different nature than the sensor network (the rock
for our roll :)

Things get more complex when multiple sinks are available and the
questions are like:
- which is the best suited sink for a given flow
- do we load balance flows over sinks?
- should a given flow be routed internally (route inside) the sensor
network or via sinks and backbone (route around)?
- what about mobility for handheld reader?
- what about reservation for typical sensor data publish subscribe
flows?

Seems to me that the first thing to focus on is manage the routes to the
sink and rely on route around. On a second phase and if flows demand so,
we can consider optimizing the routing inside but then we must be very
careful because the core of the ROLL network can rapidly saturate.

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
Teco Boot
>Sent: vendredi 28 mars 2008 08:52
>To: 'Philip Levis'
>Cc: [email-masked]
>Subject: Re: [Roll] [manet] Discussion on draft
>
>Hi Phil,

---

From: Philip Levis <[email-masked]>
Date: Fri, 28 Mar 2008 08:26:31 -0700

> is chartered), but I think the "mesh" type of protocols is worth  

Teco,

You're right; currently, the document only addresses existing IETF  
protocols. Basically, if there isn't a suitable solution already  
within the IETF corpus, then ROLL may need to add one (to the corpus).  
If that's the case, the follow-up question whether such a protocol  
would be an RFC-based specification of an existing, open protocol.  
Coming from the academic side, for example, there are plenty of  
protocols, but few meet the requirements (in terms of functionality,  
interoperability, etc.) of something that could be presented as an RFC.

I'm not sure I'd agree with your definition of the distinction of  
"mesh" protocols (I generally consider them to be ANET protocols, that  
is, ad-hoc but not necessarily mobile), but I understand the  
distinction you're making, and
that's more important than debating terminology.

Which protocols are you thinking of?

Phil

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 28 Mar 2008 17:01:24 +0100

Phil,

I swapped subject from manet to roll, for fitting my (and others) mail
rules.
On (fixed)ANET, my experience is that obstacles may move. For MESH and MANET
protocols, the trigger for recomputing paths is not that important.
On existing protocols, discussed in IETF, we had MANEMO (MANET for NEMO). I
have published NEMO for MANET, which is tailored for Autoconf as it builds a
path between MANET Router and Border Router (sink) using NEMO. Before
Dublin, I will split the proposal and refine the related parts for Autoconf.
These drafts do not describe routing anymore. I plan to work on the MESH
routing part starting second half this year, depending on the outcome in
Autoconf WG.

Maybe add a section on MESH, describing that currently IETF is not working
on this? And that a couple of personal drafts are published. 

I still wonder why IETF is ignoring MESH, as I think it makes sense to solve
the problem at L3. Heterogeneous media are difficult to manage at L2.

Regards, Teco

> Van: Philip Levis [mailto:[email-masked]]
> Verzonden: vrijdag 28 maart 2008 16:27
> Aan: Teco Boot
> CC: [email-masked]
> Onderwerp: Re: [manet] Discussion on draft
>

---

From: Kris Pister <[email-masked]>
Date: Fri, 28 Mar 2008 09:09:52 -0700

Teco - I'm not sure how you define mesh, so forgive me if I'm missing 
the point.
It's true that most of the mesh work in sensor networks to date has been 
to a single data sink.  But there are also lots of examples in the 
literature in which local networking doesn't involve a gateway or 
backbone.  This local networking is sometimes used for "distributed 
signal processing" (a very loaded phrase), and local feedback control 
loops.  It's the feedback control that I think is starting to see real 
commercial traction.
For industrial markets, I'm surprised that people are already starting 
to talk about local meshes for feedback control loops.  I thought that 
it would take longer for them to get comfortable with the technology, 
but some at least are ready now.  In many cases, this *requires* a local 
mesh, since the latency requirements effectively prohibit going through 
a backbone - if the sensor and actuator are close, there are probably 
fewer hops to get between them than to get to the backbone.

ksjp

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 28 Mar 2008 17:40:05 +0100

Hi Phil:

MANEMO was an effort that lead to a number of preBOF that were quite
successful. MANEMO and ROLL had very similar objectives but MANEMO
started in the wrong area (Internet) and with a scope that was not
specific enough (more generic L3 mesh for sensors, cities and disaster
recovery). Most of all, a draft like yours was missing to convince the
A-Ds that there was actual work to do apart from pointing at the usual
suspects from the MANET WG.

Seems to me that ROLL is doing the right thing for all of these matters;
and if you add to the picture the strong requirement drafts that we
already have, I'm very impressed with the WG and its leadership. 

In any case there is no RFC'ed solution for MANEMO that you can refer in
your draft. There were solution drafts that were advanced enough though:

http://tools.ietf.org/html/draft-thubert-tree-discovery-06 . TD is a
simple distance-vecteur to locate a sink and establish a graph to/from
that sink

http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing-header-07
enables source route along the TD graph till routing states are
established. This enables fast movements and cases when no routing at
all is desired above TD.

http://tools.ietf.org/html/draft-thubert-nina-02 . NINA (AKA bubbles)
sets routing states along the tree; this is all optimized for mesh to
sink. An additional component could be added to improve inner mesh
routing as Kris discusses on this thread. For instance, 802.11s is using
AODV for that purpose.

I hope this helps,

Pascal

Teco Boot
>Sent: vendredi 28 mars 2008 17:01
>To: 'Philip Levis'
>Cc: [email-masked]
>Subject: Re: [Roll] [roll] Discussion on draft
>
>Phil,
>
>> > always true, "mesh" protocols do typically not provide paths
between
>> > nodes

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 28 Mar 2008 18:27:11 +0100

Hi,

I do not know how to define mesh. I think it is a diffuse term. I tried to
define something in draft-boot-manet-nemo-analysis-01.txt (section 4.2).

On using shortcuts in a tree structure, Pascal posted already on this.
See also slide 11 on
http://www.inf-net.nl/IETF69%20-%20Autoconf%20MANEMO%20scenarios%20and%20req
uirements.pdf
I described the congested link avoidance problem in
draft-boot-manet-nemo-analysis-01.txt, section 6.4. Both MANET and NEMO has
the problem. An integrated MANET and NEMO (or whatever) mechanism should
select a direct path or a path using the backbone. This is not that easy,
what is the selection criteria?

Presentation on NEMO for MANET:
http://www.inf-net.nl/IETF70%20-%20Autoconf-nemo4manet.pdf

Material is also on IETF webside, but packed in CDrom images!

Teco.

> Van: Kris Pister [mailto:[email-masked]]
> Verzonden: vrijdag 28 maart 2008 17:10
> Aan: Teco Boot
> CC: [email-masked]
> Onderwerp: Re: [Roll] [manet] Discussion on draft
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 28 Mar 2008 18:31:02 +0100

Hi Kris:

I think that Teco means that finding a path inside the mesh might be a
second priority vs. finding the way to the sink. By Priority I mean that
intra mesh routing might:

- require less optimized and well maintained path then the routing to
the sinks
- have an on-demand flavor to maintain only certain routes as opposed to
any to any
- be used only for certain applications such as closed loop as opposed
to bulk data
- be scoped to limit the number of radio hops and default to route
around

The mesh strategy is to default to the backbone and then do some route
optimization. MANET alone does not have route around.

Pascal

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
Kris Pister
>Sent: vendredi 28 mars 2008 17:10
>To: Teco Boot
>Cc: [email-masked]

---

From: Philip Levis <[email-masked]>
Date: Fri, 28 Mar 2008 10:53:45 -0700

> your draft. There were solution drafts that were advanced enough  

Given the clear relevance of MANEMO, including it in the draft seems  
like a good idea, even if there is not an RFC. It is, after all, in  
the IETF corpus. What I'm leery of is starting to include protocols  
that are completely outside that corpus. A discussion of them might be  
a very useful document, I'd put it outside the scope of this  
particular draft, which examines existing IETF solutions.

Phil

---

From: JP Vasseur <[email-masked]>
Date: Fri, 28 Mar 2008 18:29:00 -0400

Hi,

I think that it is worth clarifying that ROLL is about routing over low
power and loosy networks. Referring to:

""Mesh" protocols provide paths between nodes and a backbone network.
MANET protocols can provide paths to the backbone also. The other way
is not always true, "mesh" protocols do typically not provide paths between
Nodes or at least this is the second priority."

There is no such notion of "between nodes and a backbone network". We need
to get a routing solution between nodes. Traffic patterns are important and
discussed in the requirements documents. We may indeed want to get a
solution optimized for some traffic patterns (P2MP versus Any-to-Any) of
course.

Thanks.

JP.

> From: "Pascal Thubert (pthubert)" <[email-masked]>
> Date: Fri, 28 Mar 2008 09:20:24 +0100
> To: Teco Boot <[email-masked]>, Philip Levis <[email-masked]>
> Cc: <[email-masked]>
> Conversation: [Roll] [manet] Discussion on draft

---

From: JP Vasseur <[email-masked]>
Date: Fri, 28 Mar 2008 18:29:16 -0400

> From: Philip Levis <[email-masked]>
> Date: Fri, 28 Mar 2008 08:26:31 -0700
> To: Teco Boot <[email-masked]>
> Cc: <[email-masked]>

Right, and that is the point of this document.

> interoperability, etc.) of something that could be presented as an RFC.

It is premature to have that discussion before we know whether or not we
could use an existing IETF protocol (with or without extensions) but
clearly, the solution will have to be an RFC-based specification, which does
mean that we could not be inspired by previous work of course.

> that's more important than debating terminology.

Right, what matters for the time being is to first have an agreement on the
evaluation metrics and their associated weight in light of the requirement
documents.

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 28 Mar 2008 18:30:29 -0400

Hi Teco,

Thanks for all your input here but I just wanted to remind you that we
should not try to restart a MANEMO discussion here but rather focus on
(1) the requirements documents according to our charter, and then (2) move
to the protocol survey in light of these requirements.

Cheers,

JP.

> From: Teco Boot <[email-masked]>
> Date: Fri, 28 Mar 2008 18:27:11 +0100
> To: 'Kris Pister' <[email-masked]>
> Cc: <[email-masked]>
>> is not

---

From: Kris Pister <[email-masked]>
Date: Sun, 30 Mar 2008 15:53:29 -0700

I'm not 100% sure that I know what a mesh is, but I know a lot of things 
that it's not.
A tree, for example, is not a mesh, despite what the Zigbee 
specification defines (mesh = any multi-hop network).
When I use google to look for "mesh" images, I get what I expect meshes 
to look like (some racier than others :) ).
In a LLN, at least from an industrial process automation perspective, 
mesh means a digraph with path redundancy at every hop.  Networks look 
like very small hammocks, with the two supporting eye-bolts as the 
source and destination.

ksjp

Teco Boot wrote:
>>> "Mesh" is not pure MANET, as MANET routing protocols typically
>>>       
>> provide paths
>>     
>>> always true, "mesh" protocols do typically not provide paths between
>>>       
>> nodes
>>     
>>> Maybe the draft only discuss existing IETF protocols (e.g. RFC exists
>>>       
>> or WG
>>     
>>> is chartered), but I think the "mesh" type of protocols is worth
>>>       
>> mentioning.
>>     
>>> Regards, Teco
>>>
>>>
>>>       
>>>> I'd like to start a discussion on draft-levis-roll-overview-
>>>>         
>> protocols.
>>     
>>>> cover every single minor protocol tweak is a recipe for disaster,
>>>>         
>> but
>>     
>>>> protocols that differ significantly from those currently there,
>>>>         
>> either
>>

---

From: Kris Pister <[email-masked]>
Date: Sun, 30 Mar 2008 16:02:05 -0700

Teco Boot wrote:
> [...]
I don't like tree structures, and I don't like the idea that 
mote-to-mote communication is a shortcut in some bigger picture.  The 
transport between A and Z is going to have its own QoS, and it's own L2 
resources dedicated to it, so it really should be thought of as a 
completely separate graph.
> http://www.inf-net.nl/IETF69%20-%20Autoconf%20MANEMO%20scenarios%20and%20req
I can guess at what HA, BR, MR, and H mean, but that doesn't look like a 
mesh to me.
> what is the selection criteria?
For most LLN applications and motes, it's not a congestion problem but 
rather a question of satisfying QoS while respecting the power and 
energy restristions on the various motes along the path.  These can be 
be cast as congestion problems, but not isomorphically I think.
ksjp

---

From: Kris Pister <[email-masked]>
Date: Sun, 30 Mar 2008 16:14:36 -0700

> - require less optimized and well maintained path then the routing to
I'm not sure that I follow.  I think that most of the mote-to-mote 
traffic (at least in industrial) is likely to be either control-related, 
or human query/response, both of which are generally going to be more 
demanding of network resources than regular data reporting.
> - have an on-demand flavor to maintain only certain routes as opposed to
I certainly agree that any-to-any is not a common requirement.  Human 
interaction is likely to be fairly short-term and on-demand, but control 
loops will be long term (not on-demand? not sure of the definition).
> - be scoped to limit the number of radio hops and default to route
I think that you have a mental picture of the network that might be 
different from mine.  Picture a multi-square-kilometer refinery, most of 
which is a tank farm.  A few hundred motes will give you a nice reliable 
mesh in that environment, but it might be 5-10 hops across.  Local 
feedback loops and mobile workers will tend to be only one or two hops.  
The backbone will be in the refinery proper, many hops away.  Even 
there, powered infrastructure will typically be several hops away.  So 
hopping to/from the powered infrastructure will in general be more 
costly than the direct route.
> optimization. [...]
I completely disagree.  That's the ISA vision of a mesh, where in 
Company X's ideal future they have managed to convince everyone to put a 
WiFi AP every 50 meters over many square kilometers.  I just don't see 
it going that way in industrial.  It's a more plausible picture in 
building automation or home automation though.
ksjp
>> It's true that most of the mesh work in sensor networks to date has
>>     
> been
>   
>> but some at least are ready now.  In many cases, this *requires* a
>>     
> local
>   
>>>> I'd like to start a discussion on
>>>>         
> draft-levis-roll-overview-protocols.
>

---

From: "Mischa Dohler" <[email-masked]>
Date: Mon, 31 Mar 2008 12:14:56 +0200

Dear Phil, dear all,

Sorry to start a new thread but my email does not quite fit into recent
discussions.

I and my colleagues at France Telecom support Phil's initiative of
identifying the right set of protocols. However, personally, I am not quite
sure why only link-state and distance-vector based protocols are listed. 

WSNs not only offer but also require different approaches - this had also
been stated in recent discussions and we would like some canonical versions
of these protocols to feature in the overview draft. 

My colleague Thomas Watteyne (cc'ed) has summarized some approaches based on
"virtual/relative/approximate coordinates" (many terms for the same idea) as
follows:
- First, there is a set of propositions which infer the nodes "approximate
coordinates" from a set of location aware anchor nodes. (Greedy) geographic
routing protocols can then run on top of these coordinates, although the
delivery ratio is rather low.
- "Relative coordinates" can be inferred from a set of location-unaware
anchor nodes. Coordinates are in fact a vector of distances (e.g. in hops)
to these anchors. Protocols such as Vcap (infocom'06) and Gspring (ICNP'07)
function this way. The good news is that delivery ratios on those relative
coordinates are higher than if the same nodes knew their real coordinates
(!). Drawback is that they need some sort of initialization, identification
of the anchor nodes. Also, coordinate refreshing procedures seem not to be
published.
- Recently, the use of completely virtual coordinates has been proposed.
These coordinates are randomly initialized when a node is booted. Whenever a
node sends a message, it updates its virtual coordinate as a function of its
neighbors' ones. A near-greedy geographic routing protocol is then used on
top of these coordinates. Simulation results show that the network converges
to a state where path length in number of hops exceeds the optimal one by a
few percent. 

Whilst these approaches may not be of use for industrial or home automation,
we are pretty sure that they are vital for urban applications as network
lifetimes are significantly increased.

Regards,
Mischa.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Philip Levis
Sent: Friday, March 28, 2008 4:43 AM
To: [email-masked]; manet manet
Subject: [Roll] Discussion on draft

Phil

---

From: Philip Levis <[email-masked]>
Date: Mon, 31 Mar 2008 09:36:12 -0700

> sure why only link-state and distance-vector based protocols are  

Because they are existing IETF protocols with RFCs.

> of these protocols to feature in the overview draft.

The purpose of this draft is to survey IETF protocols, so that we can  
then judge how best to move forward towards defining a protocol for  
WSNs. Its purpose is expressly *not* to survey research, other  
standards body, and custom protocols. That would be part of a next  
step, if the WG reaches consensus that existing solutions are  
insufficient.

> of the anchor nodes. Also, coordinate refreshing procedures seem not  

All of these results are from high-level simulators which use a unit- 
disk model for radio connectivity. Their claims therefore need to be  
taken with a grain of salt. Among other things, they do not consider  
any kind of temporal dynamics.

There is a long literature of coordinate embedding approaches for  
wireless as well as wired networks. Just in the past few years, before  
the two you cite above, there is GEM (SenSys '03), Vivaldi (SIGCOMM  
'04), and BVR (NSDI '05). When it comes to scalable routing  
approaches, the state of the art in research today is S4 (NSDI '07),  
which uses compact routing techniques to ensure O(sqrt(n)) routing  
state with a maximum routing stretch of 3 and, in simulation and  
simple testbed experiments, an observed average routing stretch of  
1.1. Recent work on compact routing has shown there is a fundamental  
tradeoff between routing state and stretch; while geometric or  
coordinate approaches enable nodes to have O(1) routing state, their  
stretch is unbounded.

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 31 Mar 2008 20:27:12 +0200

Hi Kris:

I think we lost sync here. We were discussing Phil's draft and comparing
routing strategies inside the Low-power Lossy Network. I did not attend
to discuss whether there is a backbone and what that backbone is made
of, WIFI mesh or else. The disconnect might have come from the word
mesh, and yes I know what you are talking about but please let's not get
there now.

So let me please recap:

First, on-demand means that you establish a path because you find that
you need it. On-demand is very practical when you have constraints to
place like class 0 because you can qualify the route that you want to
build and build specifically what you want. On-demand was designed with
host routes in mind and for that reason it plays well at layer 2 (Token
Ring test frame, 802.11s AODV etc...) though it has already one major
application at layer 3 for voice, since RSVP is also an on-demand
protocol.

In this thread, I was saying that the "any to any" optimized routing
strategy that we find in proactive routing (OSPF, OLSR, etc...) spends a
lot of energy computing LLN internal routes that we will never need and
we seem to agree on that part. On the other end of the spectrum, full
on-demand strategies (DYMO, DSR, AODV...) are reactive even for routes
that we need in all configurations.

So I was advocating the mesh strategy that is proactive for the routes
to the sink and on-demand for the LLN internal routes. It is a specific
'mixed' strategy that recognizes the flows that we really have in
sensors as opposed to the generic problem that other manet 'mixed'
strategies can address.

And I was pointing the cool side that if a need pops up (like this guy
with his handheld) an unoptimized route exists to start with even if
that means going to the sink and back. A better route can be established
if the flows are characterized to require it; this is what I called
optimizing the route.

I hope my point is clearer now,

Pascal
>From: Kris Pister [mailto:[email-masked]]
>Sent: lundi 31 mars 2008 01:15
>To: Pascal Thubert (pthubert)
>Cc: Teco Boot; [email-masked]
between

---

From: Kris Pister <[email-masked]>
Date: Mon, 31 Mar 2008 11:59:42 -0700

ok, I think that we're back in sync.  My version of your recap:
The early deployments in industrial are all around getting data back to 
one or more sinks.  Increasingly over time, these sinks will be a part 
of a backbone (today they're often fragmented/isolated).  This function 
is likely to always be an important function of the network.
On-demand internal routes will become more prevalent over time.  Some of 
the on-demand routes will last for years/decades.  Internal routes will 
often be the most critical, optimized and well-maintained (I think that 
this was where I lost sync: with your statement that they might be less 
optimized and less well maintained).

So I agree that a good strategy is to be pro-active in routing to sinks, 
and responding to internal on-demand requests with optimized internal 
mesh routes.

ksjp

Pascal Thubert (pthubert) wrote:
>>> I think that Teco means that finding a path inside the mesh might be
>>>       
> a
>   
>>> second priority vs. finding the way to the sink. By Priority I mean
>>>       
> that
>   
>> traffic (at least in industrial) is likely to be either
>>     
> control-related,
>   
>>> - have an on-demand flavor to maintain only certain routes as opposed
>>>       
> to
>   
>>> any to any
>>>
>>>       
>> interaction is likely to be fairly short-term and on-demand, but
>>     
> control
>   
>>> - be used only for certain applications such as closed loop as
>>>       
> opposed
>   
>>> to bulk data
>> different from mine.  Picture a multi-square-kilometer refinery, most
>>     
> of
>   
>> which is a tank farm.  A few hundred motes will give you a nice
>>     
> reliable
>   
>>> The mesh strategy is to default to the backbone and then do some
>>>       
> route
>   
>>> optimization. [...]
>>>
>>>       
>> Company X's ideal future they have managed to convince everyone to put
>>     
> a
>   
>>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>>>         
> Of
>   
>>> Kris Pister
>>>
>>>       
>>>> Teco - I'm not sure how you define mesh, so forgive me if I'm
>>>>         
> missing
>   
>>>> the point.
>>>> signal processing" (a very loaded phrase), and local feedback
>>>>         
> control
>   
>>>> loops.  It's the feedback control that I think is starting to see
>>>>         
> real
>   
>>>> commercial traction.
>>>> For industrial markets, I'm surprised that people are already
>>>>         
> starting
>   
>>>> to talk about local meshes for feedback control loops.  I thought
>>>>         
> that
>   
>>>> it would take longer for them to get comfortable with the
>>>>         
> technology,
>   
>>>> mesh, since the latency requirements effectively prohibit going
>>>>         
> through
>   
>>>> a backbone - if the sensor and actuator are close, there are
>>>>         
> probably
>   
>>>>> within the MANET. "Mesh" protocols provide paths between nodes and
>>>>>           
> a
>   
>>>>> backbone network.
>>>>> MANET protocols can provide paths to the backbone also. The other
>>>>>           
> way
>   
>>> is not
>>>
>>>       
>>>>> Maybe the draft only discuss existing IETF protocols (e.g. RFC
>>>>>           
> exists
>   
>>> or WG
>>>
>>>       
>>>>>> In particular, Section 5.8 has a table of several existing
>>>>>>             
> protocols
>   
>>>>>> ROLL's assessment of existing technologies and protocols, so we
>>>>>>             
> want
>   
>>>>>> to make sure that
>>>>>>

---

From: JP Vasseur <[email-masked]>
Date: Mon, 31 Mar 2008 15:04:56 -0400

Hi,

Few comments here:

From: Kris Pister <[email-masked]>
Date: Mon, 31 Mar 2008 11:59:42 -0700
To: "Pascal Thubert (pthubert)" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [Roll] [manet] Discussion on draft

ok, I think that we're back in sync.  My version of your recap:
The early deployments in industrial are all around getting data back to one
or more sinks.  Increasingly over time, these sinks will be a part of a
backbone (today they're often fragmented/isolated).  This function is likely
to always be an important function of the network.

JP> Which means that you need both in the requirement document.

On-demand internal routes will become more prevalent over time.  Some of the
on-demand routes will last for years/decades.  Internal routes will often be
the most critical, optimized and well-maintained (I think that this was
where I lost sync: with your statement that they might be less optimized and
less well maintained).

JP> Just make sure to stay solution-agnostic in the requirement document.

So I agree that a good strategy is to be pro-active in routing to sinks, and
responding to internal on-demand requests with optimized internal mesh
routes.

ksjp

---

From: Kris Pister <[email-masked]>
Date: Mon, 31 Mar 2008 14:29:07 -0700

JP Vasseur wrote:
> [...]
> The early deployments in industrial are all around getting data back 
> to one or more sinks.  Increasingly over time, these sinks will be a 
> part of a backbone (today they're often fragmented/isolated).  This 
> function is likely to always be an important function of the network.
>
They're both in there. e.g. " Most low power and lossy network systems 
[in industrial] in the near future will be for low frequency data 
collection."
"The routing protocol MUST support multiple paths (a tree-based solution 
is not sufficient)."
"Thus, the routing protocol for L2Ns MUST support multi-topology routing 
(e.g especially critical for critical control applications)."
>
> On-demand internal routes will become more prevalent over time.  Some 
> of the on-demand routes will last for years/decades.  Internal routes 
> will often be the most critical, optimized and well-maintained (I 
> think that this was where I lost sync: with your statement that they 
> might be less optimized and less well maintained).
>
I think that we're largely solution-agnostic in -00, but a lot of people 
of appropriately complained about the repeated references to L2.  I'm 
not trying to make this a HART-like document, or an ISA100-like 
document, so I'll yank all of the slotted-link and 15.4-specific stuff 
out of there.  At the same time, I think that there are important 
underlying issues here that require some clever thinking at layer 3 to 
deal with what's going on in layer 2, and relate both to what layer 4 needs.
Zach's email from 11/29 asked if routing metrics can serve as enough of 
an L2 abstraction, or if we need some kind of interactive relationship.  
I don't know the answer to that question, but I'd sure like to hear some 
good ideas.

ksjp

---

From: JP Vasseur <[email-masked]>
Date: Mon, 31 Mar 2008 18:23:51 -0400

Hi Kris,

See JP2>

From: Kris Pister <[email-masked]>
Date: Mon, 31 Mar 2008 14:29:07 -0700
To: JP Vasseur <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [Roll] industrial requirements (was...)

JP Vasseur wrote: 
>  Re: [Roll] [manet] Discussion on draft [...]
> The early deployments in industrial are all around getting data back to one or
> more sinks.  Increasingly over time, these sinks will be a part of a backbone
> (today they're often fragmented/isolated).  This function is likely to always
> be an important function of the network.
>  
They're both in there. e.g. " Most low power and lossy network systems [in
industrial] in the near future will be for low frequency data collection."
"The routing protocol MUST support multiple paths (a tree-based solution is
not sufficient)."
"Thus, the routing protocol for L2Ns MUST support multi-topology routing
(e.g especially critical for critical control applications)."
> 
> JP2> Multi-topology routing is different though: it refers to the ability to
> support multiple topologies (e.g., one for low latency, one for high
> bandwidth): is this what you want ?
> 
> the most critical, optimized and well-maintained (I think that this was where
> I lost sync: with your statement that they might be less optimized and less
> well maintained).
>  
I think that we're largely solution-agnostic in -00, but a lot of people of
appropriately complained about the repeated references to L2.  I'm not
trying to make this a HART-like document, or an ISA100-like document, so
I'll yank all of the slotted-link and 15.4-specific stuff out of there.  At
the same time, I think that there are important underlying issues here that
require some clever thinking at layer 3 to deal with what's going on in
layer 2, 

JP2> The following WG item should help you there:
Nov 2008          Submit Routing metrics for LLNs document to the IESG to be
considered as a Proposed Standard.
Link routing metric could be derived from the layer-2 characteristics.

and relate both to what layer 4 needs.
Zach's email from 11/29 asked if routing metrics can serve as enough of an
L2 abstraction, or if we need some kind of interactive relationship.  I
don't know the answer to that question, but I'd sure like to hear some good
ideas.

JP2> For sure, we¹ll need to have some discussions on this in the document
referenced above. I tend to suggest to first progress on the requirements
documents though.

Thanks,

Cheers.

JP.

ksjp

---

From: "Telemaco Melia (tmelia)" <[email-masked]>
Date: Tue, 1 Apr 2008 10:35:48 +0200

HI all,
 
Sorry to jump in the middle of this discussion but I would like to
clarify the difference between multi path routing and multi topology
routing.
The former is the ability to maintain, mainly for reliability purposes,
different routing paths between a source and destination.
The latter, as stated by JP, refers to the ability to maintain multiple
topologies for different purposes.
Correct?
 
Would it also be correct to assume that between a source a destination
you might have several paths depending on the metric you are
considering:
- reliability
- low latency
- bandwidth
- ...
 
If yes then I guess the text of section 5.1 and 5.7 should be clarified.

What do you think?

Cheers
Telemaco

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jean Philippe Vasseur (jvasseur)
Sent: Tuesday, April 01, 2008 12:24 AM
To: Kris Pister
Cc: [email-masked]
Subject: Re: [Roll] industrial requirements (was...)

Hi Kris,

See JP2>

________________________________

JP Vasseur wrote: 

	Re: [Roll] [manet] Discussion on draft [...]
	The early deployments in industrial are all around getting data
back to one or more sinks.  Increasingly over time, these sinks will be
a part of a backbone (today they're often fragmented/isolated).  This
function is likely to always be an important function of the network.

	
	JP2> Multi-topology routing is different though: it refers to
the ability to support multiple topologies (e.g., one for low latency,
one for high bandwidth): is this what you want ?
	
	On-demand internal routes will become more prevalent over time.
Some of the on-demand routes will last for years/decades.  Internal
routes will often be the most critical, optimized and well-maintained (I
think that this was where I lost sync: with your statement that they
might be less optimized and less well maintained).
	 
	JP> Just make sure to stay solution-agnostic in the requirement
document.

deal with what's going on in layer 2, 

JP2> The following WG item should help you there:
Nov 2008          Submit Routing metrics for LLNs document to the IESG
to be considered as a Proposed Standard.
Link routing metric could be derived from the layer-2 characteristics.

JP2> For sure, we'll need to have some discussions on this in the
document referenced above. I tend to suggest to first progress on the
requirements documents though.

Thanks,

Cheers.

JP.

ksjp

________________________________

---

From: "Mischa Dohler" <[email-masked]>
Date: Tue, 1 Apr 2008 10:52:39 +0200

Phil: "Its purpose is expressly *not* to survey research, other  
standards body, and custom protocols."

Mischa: Ok, we will kick in later then.

(Phil: "All of these results are from high-level simulators which use a
unit-disk model for radio connectivity. Their claims therefore need to be  
taken with a grain of salt. Among other things, they do not consider  
any kind of temporal dynamics."

Mischa: We are very aware of this and our approaches do not consider unit
disk and also cater for high network dynamicity - and - they work very well.

Phil: "Recent work on compact routing has shown there is a fundamental  
tradeoff between routing state and stretch; while geometric or  
coordinate approaches enable nodes to have O(1) routing state, their  
stretch is unbounded."

Mischa: Ok, thanks for pointing this out.)

-----Original Message-----
From: Philip Levis [mailto:[email-masked]] 
Sent: Monday, March 31, 2008 6:36 PM
To: [email-masked]
Cc: [email-masked]; 'manet manet'; [email-masked]
Subject: Re: [Roll] Discussion on draft

Phil