Subject: [RSN] Here is the new RL2N Proposed Working Charter

From: JP Vasseur <[email-masked]>
Date: Wed, 21 Nov 2007 15:18:39 -0500

Dear all,

As promised, here is the new proposed Working Group, which reflects the
number of comments/suggestions that we received, the pre-WG consensus, ...

Thanks to Dave Ward (RTD AD) for his input.

Proposed RL2N WG Charter
 
Description of Working Group
 
L2Ns (Low power and Lossy networks) are typically composed of many embedded
devices with limited power, memory, and processing resources interconnected
by a variety of wireless links, such as IEEE 802.15.4, Bluetooth, Low Power
WiFi. 

L2Ns are transitioning to an end-to-end IP-based solution to avoid the
problems of non-interoperable networks interconnected by protocol
translation gateways and proxies. In addition, L2Ns have specific routing
requirements that are not currently met by existing routing protocols, such
as OSPF, IS-IS, AODV, and OLSR. L2N path selection must be designed to take
into consideration the specific power, capabilities, attributes and
functional characteristics of the links and nodes in the network.

There is a wide scope of application areas for L2Ns, including industrial
monitoring, building automation (HVAC, lighting/access control), connected
home, healthcare, environmental monitoring, agricultural, smart cities,
logistics, assets tracking, and refrigeration. The L2N WG will focus on
routing solutions for a subset of these deployment scenarios, namely
industrial, connected home/building and urban applications. The Working
Group will determine the routing requirements for these scenarios.

The Working Group will provide a routing framework for these application
scenarios that provides high reliability in the presence of time varying
loss characteristics and connectivity while permitting low-power operation
with very modest memory and CPU pressure.

The Working Group will pay a particular attention to routing security and
manageability (e.g self managing/configuration) issues, which are
particularly critical for L2Ns.
 
Work Items:
 
- Produce use cases documents for Industrial, Connected Home, Building and
urban application networks. Each document will describe the use case and the
associated routing protocol requirements. The documents will progress in
collaboration with the 6lowpan Working Group (INT area).

- Survey the applicability of existing protocols to L2Ns. The aim of this
document will be to analyze the scaling and characteristics of existing
protocols and identify whether or not they meet the routing requirements of
the L2Ns applications identified above. Existing IGPs, MANET, NEMO, DTN
routing protocols will be part of evaluation.
 
- Specification of routing metrics used in path calculation. This includes
static and dynamic link/nodes attributes required for routing in L2Ns.
 
- Provide an architectural framework for routing and path selection at Layer
3 (Routing for L2N Architecture)
· Decide whether the L2Ns routing protocol require a distributed,
centralized path computation models or both.
· Decide whether the L2N routing protocol requires a hierarchical routing
approach.
 
- Produce a security framework for routing in L2Ns.
 
Goals And Milestones:

April 2008 Submit Use case/Routing requirements for Industrial, Connected
Home, Building and Urban networks applications to the IESG to be considered
as an Informational RFC.
 
August 2008: Submit Routing metrics for L2Ns document to the IESG to be
considered as an Informational RFC.
 
September 2008: Submit first draft of the Routing for L2Ns Architecture
document  (summary of requirements, path computation model,
flat/hierarchy,Š).
 
November 2008: Submit Protocol Survey to the IESG to be considered as an
Informational RFC.

January 2009 Submit Security Framework for L2Ns to the IESG to be considered
as an Informational RFC

February 2009: Submit the Routing for L2Ns Architecture document  (summary
of requirements, metrics and attributes, path selection model) to the IESG
as an Informational RFC.
 
March 2009: Recharter.

Please comment/suggest/...

See you in Vancouver.

JP and David.

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

---

From: Philip Levis <[email-masked]>
Date: Wed, 21 Nov 2007 13:27:29 -0800

> Group will determine the routing requirements for these scenarios.

JP (and Mischa),

I'll reiterate what I said in the meeting: I think we need a  
different term than "smart cities." Interpreted literally, "smart  
cities" encompasses *all* of the other use cases except agricultural,  
and introduces all sorts of other concerns outside our general area  
of interest, such as vehicular networks, traffic control systems, and  
law enforcement.

While densely networked urban areas certainly raise a lot of  
technical issues due to their scale, I feel that we should focus on  
real applications today. It's hard to define application use cases  
for research visions, e.g. general ubiquitous computing. I could just  
be mistaken on this one, but I have yet to hear a clear articulation  
of what a "smart city" is or what technical issues it raises. If the  
issues we want to make sure we keep in mind are outdoor, very large  
scale urban networks, surely there is a more precise application use  
case?

If we can pull out the concrete issues that smart cities introduce  
and define a concrete use case that clearly articulate them, then  
that would be great. But, I mean, is "refrigeration" really on the  
same playing field in terms of scope as "smart cities?"

Phil

---

From: "JACQUENET Christian RD-DDEV-REN" <[email-masked]>
Date: Thu, 22 Nov 2007 14:59:09 +0100

Dear all,

Thanks to Jean-Philippe for posting the updated charter. A couple of
comments inline. 

[snip]

In addition, L2Ns have specific routing requirements that are not
currently met by existing routing protocols, such as OSPF, IS-IS, AODV,
and OLSR. L2N path selection must be designed to take into consideration
the specific power, capabilities, attributes and functional
characteristics of the links and nodes in the network.

CJ: I would agree with the above sentence, especially based upon the
protocol analysis draft that has been posted so far. But there is
another sentence in the "Work Items" section of the charter that
somewhat contradicts this statement, and I would therefore suggest we
fix this, by smoothing this wording a little bit. Maybe something like:
"Preliminary analysis of existing routing protocols such as OPSF, IS-IS,
AODV and OLSR seems to indicate that the L2N-specific requirements are
not addressed by such protocols, but part of the proposed WG charter
will further investigate, as mentioned below."

[snip]
Work Items:
 
- Survey the applicability of existing protocols to L2Ns. The aim of
this document will be to analyze the scaling and characteristics of
existing protocols and identify whether or not they meet the routing
requirements of the L2Ns applications identified above. Existing IGPs,
MANET, NEMO, DTN routing protocols will be part of evaluation.

CJ: I'm fine with this wording, assuming a rewording of the
corresponding statement above (see previous comment).
 
- Specification of routing metrics used in path calculation. This
includes static and dynamic link/nodes attributes required for routing
in L2Ns.

CJ: I would put the above sentence after the following paragraph that
discusses the production of a routing framework. I think I would first
specify the routing framework and then elaborate on the metrics to be
used by the protocol. But that's cosmetics :-)
 
- Provide an architectural framework for routing and path selection at
Layer
3 (Routing for L2N Architecture)
* Decide whether the L2Ns routing protocol require a distributed,
centralized path computation models or both.
* Decide whether the L2N routing protocol requires a hierarchical
routing approach.

Cheers,

Christian.

---

From: "Anders Brandt" <[email-masked]>
Date: Thu, 22 Nov 2007 14:59:42 +0100

Thanks for a productive meeting in Boston.

The charter looks fine to me. I have no additional comments for now.

b.r. Anders

-R-S-N-   -R-L-2-N-    R O L L   ! ! !

-----Original Message-----
From: JP Vasseur [mailto:[email-masked]] 
Sent: 21. november 2007 21:19
To: [email-masked]
Subject: [RSN] Here is the new RL2N Proposed Working Charter

Dear all,

As promised, here is the new proposed Working Group, which reflects the number of comments/suggestions that we received, the pre-WG consensus, ...

Proposed RL2N WG Charter

L2Ns (Low power and Lossy networks) are typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of wireless links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi. 

L2Ns are transitioning to an end-to-end IP-based solution to avoid the problems of non-interoperable networks interconnected by protocol translation gateways and proxies. In addition, L2Ns have specific routing requirements that are not currently met by existing routing protocols, such as OSPF, IS-IS, AODV, and OLSR. L2N path selection must be designed to take into consideration the specific power, capabilities, attributes and functional characteristics of the links and nodes in the network.

There is a wide scope of application areas for L2Ns, including industrial monitoring, building automation (HVAC, lighting/access control), connected home, healthcare, environmental monitoring, agricultural, smart cities, logistics, assets tracking, and refrigeration. The L2N WG will focus on routing solutions for a subset of these deployment scenarios, namely industrial, connected home/building and urban applications. The Working Group will determine the routing requirements for these scenarios.

The Working Group will provide a routing framework for these application scenarios that provides high reliability in the presence of time varying loss characteristics and connectivity while permitting low-power operation with very modest memory and CPU pressure.

The Working Group will pay a particular attention to routing security and manageability (e.g self managing/configuration) issues, which are particularly critical for L2Ns.
 
Work Items:
 
- Produce use cases documents for Industrial, Connected Home, Building and urban application networks. Each document will describe the use case and the associated routing protocol requirements. The documents will progress in collaboration with the 6lowpan Working Group (INT area).

- Survey the applicability of existing protocols to L2Ns. The aim of this document will be to analyze the scaling and characteristics of existing protocols and identify whether or not they meet the routing requirements of the L2Ns applications identified above. Existing IGPs, MANET, NEMO, DTN routing protocols will be part of evaluation.
 
- Specification of routing metrics used in path calculation. This includes static and dynamic link/nodes attributes required for routing in L2Ns.
 
- Provide an architectural framework for routing and path selection at Layer
3 (Routing for L2N Architecture)
* Decide whether the L2Ns routing protocol require a distributed, centralized path computation models or both.
* Decide whether the L2N routing protocol requires a hierarchical routing approach.

Goals And Milestones:

April 2008 Submit Use case/Routing requirements for Industrial, Connected Home, Building and Urban networks applications to the IESG to be considered as an Informational RFC.
 
August 2008: Submit Routing metrics for L2Ns document to the IESG to be considered as an Informational RFC.
 
September 2008: Submit first draft of the Routing for L2Ns Architecture document  (summary of requirements, path computation model, flat/hierarchy,Š).
 
November 2008: Submit Protocol Survey to the IESG to be considered as an Informational RFC.

January 2009 Submit Security Framework for L2Ns to the IESG to be considered as an Informational RFC

February 2009: Submit the Routing for L2Ns Architecture document  (summary of requirements, metrics and attributes, path selection model) to the IESG as an Informational RFC.
 
March 2009: Recharter.

See you in Vancouver.

JP and David.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 22 Nov 2007 09:02:02 -0500

Hi Christian,

Thanks for your continuous support and constructive comments. See inline,

> From: JACQUENET Christian RD-DDEV-REN <[email-masked]>
> Date: Thu, 22 Nov 2007 14:59:09 +0100
> To: JP Vasseur <[email-masked]>, <[email-masked]>
> Conversation: [RSN] Here is the new RL2N Proposed Working Charter
> Subject: RE: [RSN] Here is the new RL2N Proposed Working Charter
> 
> Dear all,
> 

That makes a lot of sense. We will reword along those lines.

> corresponding statement above (see previous comment).

OK.

> used by the protocol. But that's cosmetics :-)

Yes, cosmetic is fine too ;-)

> - Produce a security framework for routing in L2Ns.

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 22 Nov 2007 09:16:30 -0500

Thanks for your feed-back on the charter.

For you all, we discussed a new potential name ...

RSN - RL2N - ... 

*should* a WG be formed, various proposals were made including ROLL (Routing
Over Low power and Loosy network) = David's idea. I also like this one.

Cheers.

JP.

> From: Anders Brandt <[email-masked]>
> Date: Thu, 22 Nov 2007 14:59:42 +0100
> As promised, here is the new proposed Working Group, which reflects the number
> of comments/suggestions that we received, the pre-WG consensus, ...
> 
> devices with limited power, memory, and processing resources interconnected by
> a variety of wireless links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi.
> 
> problems of non-interoperable networks interconnected by protocol translation
> gateways and proxies. In addition, L2Ns have specific routing requirements
> that are not currently met by existing routing protocols, such as OSPF, IS-IS,
> AODV, and OLSR. L2N path selection must be designed to take into consideration
> the specific power, capabilities, attributes and functional characteristics of
> the links and nodes in the network.
> 
> 
> industrial, connected home/building and urban applications. The Working Group
> will determine the routing requirements for these scenarios.
> 
> 
> scenarios that provides high reliability in the presence of time varying loss
> characteristics and connectivity while permitting low-power operation with
> very modest memory and CPU pressure.
> 
> 
> manageability (e.g self managing/configuration) issues, which are particularly
> critical for L2Ns.
>  
> Work Items:
>  
> Home, Building and Urban networks applications to the IESG to be considered as
> an Informational RFC.
>  
> document  (summary of requirements, path computation model, flat/hierarchy,Š).
>  
> February 2009: Submit the Routing for L2Ns Architecture document  (summary of
> requirements, metrics and attributes, path selection model) to the IESG as an
> Informational RFC.
>  
> March 2009: Recharter.
>  
>

---

From: "JACQUENET Christian RD-DDEV-REN" <[email-masked]>
Date: Thu, 22 Nov 2007 15:18:55 +0100

Roll's very cool indeed :-)

Keep rockin' ;-)

Cheers,

Christian.

-----Message d'origine-----
De : JP Vasseur [mailto:[email-masked]] 
Envoyé : jeudi 22 novembre 2007 15:17
À : Anders Brandt; [email-masked]
Objet : Re: [RSN] Here is the new RL2N Proposed Working Charter

RSN - RL2N - ... 

*should* a WG be formed, various proposals were made including ROLL (Routing Over Low power and Loosy network) = David's idea. I also like this one.

Cheers.

JP.

> As promised, here is the new proposed Working Group, which reflects 
> the number of comments/suggestions that we received, the pre-WG consensus, ...
> 
> L2Ns (Low power and Lossy networks) are typically composed of many 
> embedded devices with limited power, memory, and processing resources 
> interconnected by a variety of wireless links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi.
> 
> translation gateways and proxies. In addition, L2Ns have specific 
> routing requirements that are not currently met by existing routing 
> protocols, such as OSPF, IS-IS, AODV, and OLSR. L2N path selection 
> must be designed to take into consideration the specific power, 
> capabilities, attributes and functional characteristics of the links and nodes in the network.
> 
> 
> There is a wide scope of application areas for L2Ns, including 
> industrial monitoring, building automation (HVAC, lighting/access 
> control), connected home, healthcare, environmental monitoring, 
> agricultural, smart cities, logistics, assets tracking, and 
> refrigeration. The L2N WG will focus on routing solutions for a subset 
> of these deployment scenarios, namely industrial, connected 
> home/building and urban applications. The Working Group will determine the routing requirements for these scenarios.
> 
> 
> The Working Group will provide a routing framework for these 
> application scenarios that provides high reliability in the presence 
> of time varying loss characteristics and connectivity while permitting 
> low-power operation with very modest memory and CPU pressure.
> 
> 
> The Working Group will pay a particular attention to routing security 
> and manageability (e.g self managing/configuration) issues, which are 
> - Produce use cases documents for Industrial, Connected Home, Building 
> and urban application networks. Each document will describe the use 
> case and the associated routing protocol requirements. The documents 
> will progress in collaboration with the 6lowpan Working Group (INT area).
> 
> 
> includes static and dynamic link/nodes attributes required for routing in L2Ns.
>  
> April 2008 Submit Use case/Routing requirements for Industrial, 
> Connected Home, Building and Urban networks applications to the IESG 
> to be considered as an Informational RFC.
>  
> September 2008: Submit first draft of the Routing for L2Ns 
> Architecture document  (summary of requirements, path computation model, flat/hierarchy,Š).
>  
> February 2009: Submit the Routing for L2Ns Architecture document  
> (summary of requirements, metrics and attributes, path selection 
> model) to the IESG as an Informational RFC.
>  
> March 2009: Recharter.
>  
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 22 Nov 2007 16:41:56 +0100

I like it too... It rocks :)

Pascal

>From: Jean Philippe Vasseur (jvasseur)
>Sent: Thursday, November 22, 2007 3:17 PM
>To: Anders Brandt; [email-masked]
>Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter
>

---

From: JP Vasseur <[email-masked]>
Date: Mon, 26 Nov 2007 11:32:25 -0500

Hi Phil,

The text had not been updated everywhere: the term "urban network" is now
consistently used in the new proposed charter.
http://www.employees.org/~jvasseur/

Are we in sync?

Cheers.

JP.

> From: Philip Levis <[email-masked]>
> Date: Wed, 21 Nov 2007 13:27:29 -0800
> To: JP Vasseur <[email-masked]>
> Cc: <[email-masked]>
>> industrial

---

From: Philip Levis <[email-masked]>
Date: Mon, 26 Nov 2007 09:56:30 -0800

> http://www.employees.org/~jvasseur/

SYN + ACK!

One nit:

The Working Group will pay a particular attention to routing ->
The Working Group will pay particular attention to routing

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 28 Nov 2007 14:10:34 +0100

Hi JP:

Thanks a bunch for this charter. I'll try not to rephrase what was already discussed with Christian, Anders, Philip and Misha. 

There's an additional item I'd wish to see either in ROLL or 6LoWPAN and I do not know exactly where it belongs, maybe both. The question is whether we need to and can document how RFC 4294 applies for sensors, and M2M devices in general, whether they act as hosts or as routers. 

I've seen IPv6 presented as a Pandora box that drags just too much stuff to be incorporated in a sensory device. For instance, at the moment, SP100.11a endorses 6LoWPAN formats but it's not so clear at all that IPv6 itself is mandated. A clear spec with well-documented implementation could be a formidable tool to despond to Fear, Uncertainty and Defiance.

So maybe we do not need DHCP (a MAY in RFC 4294) and maybe can do without multicast at all if ND is supported some other way (such as suggested in: http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router-00.txt). Maybe NULL encryption and authentication is enough etc, etc...
 
Being able to define one minimum set and maybe a few other profiles for the use cases that we selected could help tremendously. 

Otherwise I find the charter real well written and easy to digest. From the MANEMO experience, I expect that some arguments about the relative applicability of existing MANET protocols will be difficult to prove without some good simulation work running agreed-upon scenarios.

Finally, I'm a bit confused that it seems that both IPv4 and IPv6 seem supported. Ipv4 comes with a lot of overhead like DHCP. I suggest that when trouble comes and things can not be done in a common fashion for both IP protocols, hen we prioritize IPv6.

Unfortunately, I can not make it to Vancouver, but I do feel that the work is really needed so please count my vote in for the adoption of the WG.

Cheers,

Pascal

>Sent: Wednesday, November 21, 2007 9:19 PM
>To: [email-masked]

---

From: JP Vasseur <[email-masked]>
Date: Wed, 28 Nov 2007 08:29:48 -0500

Hi Pascal,

Thanks for the feed-back and support - in line,

> From: "Pascal Thubert (pthubert)" <[email-masked]>
> Date: Wed, 28 Nov 2007 08:10:34 -0500
> To: "Jean Philippe Vasseur (jvasseur)" <[email-masked]>
> Cc: <[email-masked]>, 6lowpan <[email-masked]>
> Thanks a bunch for this charter. I'll try not to rephrase what was already
> discussed with Christian, Anders, Philip and Misha.
> 
> There's an additional item I'd wish to see either in ROLL or 6LoWPAN and I do
> not know exactly where it belongs, maybe both. The question is whether we need
> to and can document how RFC 4294 applies for sensors, and M2M devices in
> general, whether they act as hosts or as routers.
> 
> I've seen IPv6 presented as a Pandora box that drags just too much stuff to be
> incorporated in a sensory device. For instance, at the moment, SP100.11a
> endorses 6LoWPAN formats but it's not so clear at all that IPv6 itself is
> mandated. A clear spec with well-documented implementation could be a
> formidable tool to despond to Fear, Uncertainty and Defiance.
> 
> So maybe we do not need DHCP (a MAY in RFC 4294) and maybe can do without
> multicast at all if ND is supported some other way (such as suggested in:
> http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router-00.tx
> t). Maybe NULL encryption and authentication is enough etc, etc...
>  
> Being able to define one minimum set and maybe a few other profiles for the
> use cases that we selected could help tremendously.

I cannot agree more but this certainly belongs more to 6lowpan if they want
to work on this item. If a RL2N WG gets formed, we should contribute to this
work for the routing aspects.

> 
> Otherwise I find the charter real well written and easy to digest. From the
> MANEMO experience, I expect that some arguments about the relative
> applicability of existing MANET protocols will be difficult to prove without
> some good simulation work running agreed-upon scenarios.

This is indeed a key work item. The work has started in the protocol
overview draft (still more work is undoubtedly required).

> 
> Finally, I'm a bit confused that it seems that both IPv4 and IPv6 seem
> supported. Ipv4 comes with a lot of overhead like DHCP. I suggest that when
> trouble comes and things can not be done in a common fashion for both IP
> protocols, hen we prioritize IPv6.
> 

It is indeed important to have a RL2N solution for both v4 *and* v6, I do
not think that we should try to "prioritize" between the two.

> Unfortunately, I can not make it to Vancouver,

Too bad ... But should a WG be formed, I hope that we'll have you contribute
to this work.

but I do feel that the work is
> really needed so please count my vote in for the adoption of the WG.

Will do.

Thanks.

JP.

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Thu, 29 Nov 2007 11:28:42 +0900

Dear Pascal and JP,

I'm very happy to see the same thought of me on RFC 4294.
I agree on JP that this work is more on 6LoWPAN in general
and RL2N (or ROLL - I like this idea ^^) can check it in routing
perspective, if any.

I once discussed with Carsten about the necessity of this issue.
I've discussed this matter with some other Korean developers from
sensor node companies. We quite agreed on the necessity, and I and my
colleagues already proposed this work as korean domestic standard
first. The proposal has been accepted, and korean experts will start
to discuss it more to develop domestic standard. It must be great if
we can discuss it with IETF experts as well.

Pascal, I think it would be good if we can check each other's
profiling and collaborate to make one profile based on them. :)

-eunsook "eunah" kim

---

From: "Dominik Kaspar" <[email-masked]>
Date: Thu, 29 Nov 2007 13:56:58 +0900

How about "Routing Over Faulty Links"? *rofl*

Dominik

---

From: Bernard Tourancheau <[email-masked]>
Date: Thu, 29 Nov 2007 20:53:19 +0100

Hi all,

I would like to propose some help in the 2nd item which is doing  
survey work by giving some inputs concerning the ANA6 proposal from  
the Ad-Hoc world.
I will also follow and participate to items 3 and 4.

Best regards,
Bernard Tourancheau.
--
LIP, ENS-Lyon, France.

Le 21 nov. 07 à 21:18, JP Vasseur a écrit :

> the
> embedded
> routing
> application
> includes
> Connected
> Architecture
> flat/hierarchy,…).
> (summary