Subject: [Roll] ROLL re-chartering

From: JP Vasseur <[email-masked]>
Date: Wed, 11 Feb 2009 09:08:00 +0100

Dear WG,

As indicated in a previous email, the protocol survey I-D will be send  
for publication this week (after posting of the last revision  
incorporating several useful comments).

As promised please find below the new proposed charter to be submitted  
to the IESG for approval. In the hope of getting quickly re-chartered  
thanks to let us know if you have any comment by the ned of this week.  
The new charter is pretty straightforward.

Thanks to Dave Ward for his comments and guidance.

Description of Working Group:

Low power and Lossy networks (LLNs) are typically composed of many
embedded devices with limited power, memory, and processing resources
interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth,
Low Power WiFi or other low power PLC (Powerline Communication) links.  
LLNs are transitioning to an end-to-end IP-based
  solution to avoid the problem of non-interoperable networks
interconnected by protocol translation gateways and proxies. LLNs have  
specific characteristics:
-       LLNs operate with a hard, very small bound on state,
-       In most cases, LLN need to be optimized for energy saving,
-       Typical traffic patterns are not simply unicast flows,
-       In most cases, LLNs need to be effective with very small  
packet sizes,
-       LLN routing protocols have to be very careful when trading off  
efficiency for generality; many LLN nodes do not have resources to  
waste.

These unique properties lead to unique routing requirements that may  
not met by
  existing routing protocols, such as OSPF, IS-IS, AODV and OLSR. For
example 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.

The Working Group is focused on routing issues for LLN

There is a wide scope of application areas for LLNs, including
  industrial monitoring, building automation (HVAC, lighting, access
control, fire), connected home, healthcare, environmental monitoring,
urban sensor networks sensor networks, assets tracking, refrigeration.
The Working Group will only focus on routing solutions for a subset of
these. It will focus on industrial, connected home, building and urban
  sensor networks and specify the set of routing requirements for
  these scenarios.

The Working Group focuses only on IPv6 only routing architectural
  framework for these application scenarios. The Framework will take  
into consideration various
  aspects including high reliability in the presence of time varying  
loss
  characteristics and connectivity while permitting low-power operation
  with very modest memory and CPU pressure in networks potentially
comprising a very large number (several thousands) of nodes.
The Working Group will explore aspects of mobility within a single LLN
(if any) in the routing requirement creation.

The Working Group will pay particular attention to routing security and
manageability (e.g., self configuration) issues. It will also need to
  consider the transport characteristic the routing protocol messages  
will
  experience. Mechanisms that protect an LLN from congestion collapse or
  that establish some degree of fairness between concurrent  
communication
sessions are out of scope of the Working Group. It is expected that
  upper-layer applications utilizing LLNs define appropriate mechanisms.

Work Items:

- Specification of routing metrics used in path calculation. This
includes static and dynamic link/node attributes required for routing in
LLNs.

- Provide an architectural framework for routing and path selection at
  Layer 3 (Routing for LLN Architecture) that addresses such issues as
whether LLN routing protocols require a distributed and/or centralized
  path computation models, whether additional hierarchy is necessary and
how it is applied. Manageability will be considered with each approach,
  along with various trade-offs for maintaining low power operation,
  including the presence of non-trivial loss and networks with a very
  large number of nodes.

- Produce a routing security framework for routing in LLNs.

- Protocol work: In light of the application specific routing  
requirements, the Working Group will either specify a new protocol and/ 
or will select an existing routing protocol (with the appropriate  
extensions in cooperation with the relevant Working Group).

- Documentation of applicability statement of ROLL routing protocols.

Goals and Milestones:

Done   Submit Routing requirements for Industrial applications to the  
IESG to be considered as an Informational RFC.
Done   Submit  Routing requirements for Connected Home networks  
applications to the IESG to be considered as an Informational RFC.
Done   Submit Routing requirements for Building applications to the  
IESG to be considered as an Informational RFC.
Done   Submit Routing requirements for Urban networks applications to  
the IESG to be considered as an Informational RFC.
July 2009    Submit Routing metrics for LLNs document to the IESG to  
be considered as a Proposed Standard.
* Feb 2009   Submit Protocol Survey to the IESG to be considered as an  
Informational RFC.
April 2009   Submit Security Framework to the IESG to be considered as  
an Informational RFC
May 2009     Submit the Routing for LLNs Architecture document to the  
IESG as an Informational RFC.
July 2009    Submit first draft of ROLL routing protocol specification  
as Proposed Standard.
Nov 2009     Submit first draft of the MIB module of the ROLL routing  
protocol specification.
Dec 2009     Submit the ROLL routing protocol specification to the  
IESG as Proposed Standard.
Jan 2010     Submit the MIB module of the ROLL routing protocol  
specification to the IESG as Proposed Standard.
Jan 2010     Evaluate WG progress, recharter or close.

PS: I marked * the Milestones that will be "This Week" and before  
submitting to the IESG for re-chartering.

Thanks.

JP and David.

---

From: JP Vasseur <[email-masked]>
Date: Wed, 11 Feb 2009 09:10:32 +0100

On Feb 11, 2009, at 9:08 AM, JP Vasseur wrote:

> Dear WG,
>
> As indicated in a previous email, the protocol survey I-D will be  
> send for publication this week (after posting of the last revision  
> As promised please find below the new proposed charter to be  
> submitted to the IESG for approval. In the hope of getting quickly  
> re-chartered thanks to let us know if you have any comment by the  
> ned of this week. The new charter is pretty straightforward.
>
> Low Power WiFi or other low power PLC (Powerline Communication)  
> links. LLNs are transitioning to an end-to-end IP-based
> interconnected by protocol translation gateways and proxies. LLNs  
> have specific characteristics:
> -       LLN routing protocols have to be very careful when trading  
> off efficiency for generality; many LLN nodes do not have resources  
> to waste.
>
> requirements, the Working Group will either specify a new protocol  
> and/or will select an existing routing protocol (with the  
> appropriate extensions in cooperation with the relevant Working  
> Group).
>
> Done   Submit Routing requirements for Industrial applications to  
> Done   Submit Routing requirements for Urban networks applications  
> to the IESG to be considered as an Informational RFC.
> * Feb 2009   Submit Protocol Survey to the IESG to be considered as  
> an Informational RFC.
> April 2009   Submit Security Framework to the IESG to be considered  
> as an Informational RFC
> May 2009     Submit the Routing for LLNs Architecture document to  
> the IESG as an Informational RFC.
> July 2009    Submit first draft of ROLL routing protocol  
> specification as Proposed Standard.
> Nov 2009     Submit first draft of the MIB module of the ROLL  
> routing protocol specification.
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: [email-masked]
Date: Wed, 11 Feb 2009 08:42:33 -0600

JP, David,

Looks good.  Comments interlaced below:

JP Vasseur <[email-masked]> 
Sent by: [email-masked]
02/11/2009 02:08 AM

To
ROLL WG <[email-masked]>
cc
"David E. Culler" <[email-masked]>
Subject
[Roll] ROLL re-chartering

Dear WG,

Low power and Lossy networks (LLNs) are typically composed of many
embedded devices with limited power, memory, and processing resources
interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth,
Low Power WiFi or other low power PLC (Powerline Communication) links. 
I would like to more explicitly note 'wired' sensor networks.  While PLC 
is a specific instance of a wired network, traditional wired sensors will 
predominate the building market for many years.  Fire and Security 
applications may stay wired for decades.  Our solutions must be viable to 
both wired and wireless solutions.

If you're looking for other characteristics: LLNs must guarantee packet 
delivery within stringent timing requirements.

Should we be more emphatic about existing routing protocols not meeting 
the requirements?  That is, 'may' s/b 'are'
 
not met by

The Working Group focuses only on IPv6 only routing architectural
One too many 'only'. Delete the second 'only'

Work Items:

Goals and Milestones:

Since a completely new routing protocol may need to be drafted, I think a 
submittal date of July 2009 for the new ROLL protocols is very aggressive. 
 You may want to give the WG a few more months.

Thanks.

JP and David.

---

From: JP Vasseur <[email-masked]>
Date: Wed, 11 Feb 2009 16:26:05 +0100

Hi Jerry,

Thanks. See in line.

On Feb 11, 2009, at 3:42 PM, [email-masked] wrote:

> I would like to more explicitly note 'wired' sensor networks.  While  
> PLC is a specific instance of a wired network, traditional wired  
> sensors will predominate the building market for many years.  Fire  
> and Security applications may stay wired for decades.  Our solutions  
> must be viable to both wired and wireless solutions.
>

JP> Yes. Let's keep the word "embedded devices" to stay as generic as  
possible.
We explicitly added PLC, let's also add "wired" link as well. Agree.

> If you're looking for other characteristics: LLNs must guarantee  
> packet delivery within stringent timing requirements.

JP> Well it is an application specific requirement (captured in some  
application-specific) routing
requirement I-D. We just tried here to capture the most common  
denominators.

> Should we be more emphatic about existing routing protocols not  
> meeting the requirements?  That is, 'may' s/b 'are'
>
> not met by
>  existing routing protocols, such as OSPF, IS-IS, AODV and OLSR.

JP> That part should have been tweaked. Thanks.

These unique properties lead to unique routing requirements that are  
not met by
existing routing protocols (in their current state), such as OSPF, IS- 
IS, AODV
and OLSR, which does not preclude existing protocols from being  
extended to meet these
specific requirements.

> For

JP> We wanted to insist a bit ;-) ... Thanks.

> and/
> Since a completely new routing protocol may need to be drafted, I  
> think a submittal date of July 2009 for the new ROLL protocols is  
> very aggressive.  You may want to give the WG a few more months.

It is hard to tell ... if extensions to an existing protocol is the  
way to go, we should be fine. If a new protocol is defined, this is  
aggressive but it has been done in the past. I prefer to stick with  
aggressive dates.

Thanks Jerry for the comments.

JP.

---

From: Mukul Goyal <[email-masked]>
Date: Wed, 11 Feb 2009 15:21:23 -0600 (CST)

The re-charter text gives the impression that ROLL plans to standardize _one_ routing protocol. Is it the intention?

Thanks
Mukul Goyal

----- Original Message -----
From: "JP Vasseur" <[email-masked]>
To: "ROLL WG" <[email-masked]>
Cc: "David E. Culler" <[email-masked]>
Sent: Wednesday, February 11, 2009 2:08:00 AM GMT -06:00 US/Canada Central
Subject: [Roll] ROLL re-chartering

Dear WG,

Work Items:

Goals and Milestones:

Thanks.

JP and David.

---

From: JP Vasseur <[email-masked]>
Date: Wed, 11 Feb 2009 22:31:09 +0100

Hi,

On Feb 11, 2009, at 10:21 PM, Mukul Goyal wrote:

> The re-charter text gives the impression that ROLL plans to  
> standardize _one_ routing protocol. Is it the intention?
>

Not yet determined. As we pointed before, the goal is always to have  
the minimum number of protocols (1 !).
If not possible, then each solution would have to be accompanied with  
an applicability statement and be
clearly justified. One solution per application (extreme case) is of  
course not acceptable. In short, our objective,
is one protocol. If not possible, which we will know during protocol  
work phase, we will decide at that point.

Thanks.

JP.

---

From: Mukul Goyal <[email-masked]>
Date: Wed, 11 Feb 2009 15:43:36 -0600 (CST)

I am not sure if it is a good idea. I dont think you can have one protocol that works best (and even good enough) in all 4 scenarios (home, building, industrial, urban) for all applications and at all scales. Why would I use a protocol, designed for 10000 battery-powered node network, in a 100 mains-powered node network? Further, there may be multiple very different protocols that have similar performance. I dont think the recharter text should retrict the number of protocols.

Thanks
Mukul

----- Original Message -----
From: "JP Vasseur" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>
Cc: "David E. Culler" <[email-masked]>, "ROLL WG" <[email-masked]>
Sent: Wednesday, February 11, 2009 3:31:09 PM GMT -06:00 US/Canada Central
Subject: Re: [Roll] ROLL re-chartering

Hi,

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Wed, 11 Feb 2009 22:50:52 +0100

Hi,

On Feb 11, 2009, at 10:43 PM, Mukul Goyal wrote:

> I am not sure if it is a good idea. I dont think you can have one  
> protocol that works best (and even good enough) in all 4 scenarios  
> (home, building, industrial, urban) for all applications and at all  
> scales. Why would I use a protocol, designed for 10000 battery- 
> powered node network, in a 100 mains-powered node network? Further,  
> there may be multiple very different protocols that have similar  
> performance. I dont think the recharter text should retrict the  
> number of protocols.

It does not. But as a general IETF rule we *always* try to avoid  
specifying many protocols. Remember that IP is good enough for  
everything. We will not try to find the best optimal solution for  
every situation. The work of the WG will be to try to find (extend,  
define) one protocol that meets our requirements. We will have to make  
compromise. But again, this is a premature discussion. The charter  
does not "restrict" anything. The comments above are general IETF rule  
that do apply for ROLL.

Thanks.

JP.

> Cc: "David E. Culler" <[email-masked]>, "ROLL WG" <[email-masked] 
> >
>> send
>> submitted
>> links.
>> off
>> an
>> as

---

From: "David E. Culler" <[email-masked]>
Date: Wed, 11 Feb 2009 16:30:12 -0800

I'm quite confident that working group can dig into the technical work
of resolving these issues well.  It has already set a good precedent
for thorough analysis as a basis for decision making.  There are
numerous folks involved that have built such protocols outside the
IETF, as well as folks who have built good protocols within the IETF.
Bringing the two together bodes well.  I think it is better that we
move forward in that analytical manner than put stakes in the ground
prematurely.

Mukul Goyal wrote:

Thanks
Mukul

----- Original Message -----
From: "JP Vasseur" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>
Cc: "David E. Culler" <[email-masked]>, "ROLL WG" <[email-masked]>
Sent: Wednesday, February 11, 2009 3:31:09 PM GMT -06:00 US/Canada Central
Subject: Re: [Roll] ROLL re-chartering

Hi,

Thanks.

JP.

Thanks
Mukul Goyal

----- Original Message -----
From: "JP Vasseur" <[email-masked]>
To: "ROLL WG" <[email-masked]>
Cc: "David E. Culler" <[email-masked]>
Sent: Wednesday, February 11, 2009 2:08:00 AM GMT -06:00 US/Canada
Central

Dear WG,

interconnected by a variety of links, such as IEEE 802.15.4,
Bluetooth,

The Working Group will pay particular attention to routing security
and
manageability (e.g., self configuration) issues. It will also need to
consider the transport characteristic the routing protocol messages
will
experience. Mechanisms that protect an LLN from congestion collapse
or
that establish some degree of fairness between concurrent
communication
sessions are out of scope of the Working Group. It is expected that
upper-layer applications utilizing LLNs define appropriate
mechanisms.

Work Items:

- Specification of routing metrics used in path calculation. This
includes static and dynamic link/node attributes required for
routing in
LLNs.

- Provide an architectural framework for routing and path selection at
Layer 3 (Routing for LLN Architecture) that addresses such issues as
whether LLN routing protocols require a distributed and/or centralized
path computation models, whether additional hierarchy is necessary
and
how it is applied. Manageability will be considered with each
approach,
along with various trade-offs for maintaining low power operation,
including the presence of non-trivial loss and networks with a very
large number of nodes.

Goals and Milestones:

Thanks.

JP and David.

---

From: Zach Shelby <[email-masked]>
Date: Thu, 12 Feb 2009 09:40:05 +0200

Hi,

I support this charter. Although the time-line looks tight, this WG is 
motivated, and the industry demand for a solution high - so still 
reasonable.

- Zach

JP Vasseur wrote:
> -       In most cases, LLNs need to be effective with very small packet 
> sizes,
> efficiency for generality; many LLN nodes do not have resources to waste.
> 
> These unique properties lead to unique routing requirements that may not 
> met by
>  framework for these application scenarios. The Framework will take into 
> consideration various
>  aspects including high reliability in the presence of time varying loss
>  consider the transport characteristic the routing protocol messages will
>  that establish some degree of fairness between concurrent communication
> and/or will select an existing routing protocol (with the appropriate 
> Done   Submit Routing requirements for Building applications to the IESG 
> to be considered as an Informational RFC.
> July 2009    Submit Routing metrics for LLNs document to the IESG to be 
> considered as a Proposed Standard.
> Dec 2009     Submit the ROLL routing protocol specification to the IESG 
> as Proposed Standard.

-- 

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti
FINLAND

mobile: +358 40 7796297

This e-mail and all attached material are confidential and may contain 
legally privileged information. If you are not the intended recipient, 
please contact the sender and delete the e-mail from your system without 
producing, distributing or retaining copies thereof.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Feb 2009 14:07:29 +0100

> Low Power WiFi or other low power PLC (Powerline Communication) links. 

Sorry, low power PLC sounds contradictory to me... low power and 
powerline...

I think the PLC devices are powered by the line itself.  Where does the 
low-power characteristic come from?

Or is that low-power radio? (short range, small dBm).

Alex

---

From: JP Vasseur <[email-masked]>
Date: Fri, 13 Feb 2009 14:16:06 +0100

Hi Alex,

On Feb 13, 2009, at 2:07 PM, Alexandru Petrescu wrote:

> I think the PLC devices are powered by the line itself.  Where does  
> the low-power characteristic come from?
>

Although they are main powered they can consume more of less power  
(thus the term low power).
You can find PLC chipset that consumes a few dozen of Mw. In our  
context we are referring to
these PLC type technologies that opposed to other PLC technologies  
that are in the Watt range.

Thanks.

JP.

>> These unique properties lead to unique routing requirements that  
>> may not met by
>> July 2009    Submit Routing metrics for LLNs document to the IESG  
>> to be considered as a Proposed Standard.

---

From: Mischa Dohler <[email-masked]>
Date: Fri, 13 Feb 2009 14:40:07 +0100

I am not sure why PLC has popped up again? Whilst they are and certainly 
will be part of the embedded system's landscape, I remember that we 
decided to exclude it for a set of reasons:

1) Where is the real routing challenge if you can only route 'along' the 
power line? I guess there are small items to be solved but I don't see 
yet *the* grand challenge.

2) A company trying to use PLC told us that they could not get a 
reasonable signal beyond the meter, ie if you have sensors reporting in 
several flats, there is no way you can aggregate this data in a single 
node placed in the building and possibly acting as a gateway to other 
nets. I have had a look at the circuits diagram of typical meters and 
have not yet fully got around why the signal gets so heavily attenuated 
but this is what it does (at the moment). Anybody on this list with 
other practical experiences with PLC?

Cheers,
Mischa.

JP Vasseur wrote:
>>> re-chartered thanks to let us know if you have any comment by the ned 
>>> of this week. The new charter is pretty straightforward.
> Although they are main powered they can consume more of less power (thus 
> the term low power).
> You can find PLC chipset that consumes a few dozen of Mw. In our context 
> we are referring to
> these PLC type technologies that opposed to other PLC technologies that 
> are in the Watt range.
> 
> Thanks.
> 
> JP.
>

---

From: JP Vasseur <[email-masked]>
Date: Fri, 13 Feb 2009 14:54:55 +0100

Hi Mischa,

On Feb 13, 2009, at 2:40 PM, Mischa Dohler wrote:

> I am not sure why PLC has popped up again? Whilst they are and  
> certainly will be part of the embedded system's landscape, I  
> remember that we decided to exclude it for a set of reasons:
>
> 1) Where is the real routing challenge if you can only route 'along'  
> the power line? I guess there are small items to be solved but I  
> don't see yet *the* grand challenge.
>

it is just that LLNs can be made of both wireless and wired devices  
(PLC and serial as pointed out by Jerry). Still constrained devices  
thus they are part of ROLL's scope. This is very much true in Smart  
Grid automation.

> reasonable signal beyond the meter, ie if you have sensors reporting  
> in several flats, there is no way you can aggregate this data in a  
> single node placed in the building and possibly acting as a gateway  
> to other nets. I have had a look at the circuits diagram of typical  
> meters and have not yet fully got around why the signal gets so  
> heavily attenuated but this is what it does (at the moment). Anybody  
> on this list with other practical experiences with PLC?

There is plenty of excellent PLC technos. I'll send you pointers, just  
trying to focus on the charter in this thread ;-)

Thanks.

JP.

>>>> send for publication this week (after posting of the last  
>>>> revision incorporating several useful comments).
>>>> submitted to the IESG for approval. In the hope of getting  
>>>> quickly re-chartered thanks to let us know if you have any  
>>>> comment by the ned of this week. The new charter is pretty  
>>>> straightforward.
>>> I think the PLC devices are powered by the line itself.  Where  
>>> does the low-power characteristic come from?
>>>
>>>> -       LLN routing protocols have to be very careful when  
>>>> trading off efficiency for generality; many LLN nodes do not have  
>>>> resources to waste.
>>>> framework for these application scenarios. The Framework will  
>>>> take into consideration various
>>>> requirements, the Working Group will either specify a new  
>>>> protocol and/or will select an existing routing protocol (with  
>>>> the appropriate extensions in cooperation with the relevant  
>>>> Working Group).
>>>> Done   Submit Routing requirements for Building applications to  
>>>> Done   Submit Routing requirements for Urban networks  
>>>> * Feb 2009   Submit Protocol Survey to the IESG to be considered  
>>>> as an Informational RFC.
>>>> April 2009   Submit Security Framework to the IESG to be  
>>>> considered as an Informational RFC
>>>> Dec 2009     Submit the ROLL routing protocol specification to  
>>>> the IESG as Proposed Standard.

---

From: "Stuebing, Gary K" <[email-masked]>
Date: Fri, 13 Feb 2009 08:55:02 -0500

Mischa:

We have had a lot of experience with PLC. Not sure how relevant this is to the discussion however:

1) I agree with you, I don't see a huge challenge.
2) Routing is extremely important when using PLC in an "access" scenario. Not as important in the Home scenario, although the importance does rise when looking at Multiple Dwelling units. We have not seen any problems getting the signal beyond the meter. We have had some issues in the North American market moving the signals between both legs of a 240v access (i.e. the signal is split into 120v inside the home).

Gary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mischa Dohler
Sent: Friday, February 13, 2009 8:40 AM
To: JP Vasseur
Cc: ROLL WG; David E. Culler
Subject: Re: [Roll] ROLL re-chartering

Cheers,
Mischa.

---

From: [email-masked]
Date: Fri, 13 Feb 2009 08:27:02 -0600

Powerline carrier (PLC) has been around for at least 30 years in many 
implementations.  It works quite well in the home market since all the 
wiring is 120/240v continuous within a home.  It has never worked well in 
commercial markets.  Most large buildings will bring in high-voltage 
(13.2kV) as primary power into the building and then transform the power 
to 208v (lights) and 120/240v (general purpose) within the building.  The 
transformers  will not allow the data riding on one secondary of a 
transformer to 'hop' across to the other secondaries.  Hence there is no 
ubiquitous wiring network within a commercial building.

As for your comment about PLC only traversing 1 meter, that hasn't been my 
experience.  The technology is pretty good at data communication rates and 
quality albeit the comment above.  The HomePlug Alliance (homeplug.org) is 
a consortium of companies developing and refining PLC for the residential 
market.  Just last week ZigBee, Homeplug, and EPRI announced an alliance 
to develop the HAN standard.  (I copied part of the press release below) 
EPRI is the governing body over all utilities in the US.  I am only 
speaking for North America, but there has been considerable interest in 
the meetings from Europe as well.

If we want ROLL to be successful in the home market, we should not lose 
sight of PLC technology.

Mischa Dohler <[email-masked]> 
Sent by: [email-masked]
02/13/2009 07:47 AM

To
JP Vasseur <[email-masked]>
cc
ROLL WG <[email-masked]>, "David E. Culler" <[email-masked]>
Subject
Re: [Roll] ROLL re-chartering

Cheers,
Mischa.

Bluetooth,

loss
and
will
communication
approach,

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Feb 2009 15:35:21 +0100

Jerald - ok, PLC is important.  It's related to routing and energy 
transportation.

But.  It doesn't sound as PLC devices having limited power, they sit on 
more power than they'd ever need.

I this sense, I don't agree with the Charter saying:
>  interconnected by a variety of links, such as [...] or other low
> power PLC (Powerline Communication) links.

What do you think?

Alex

---

From: Mischa Dohler <[email-masked]>
Date: Fri, 13 Feb 2009 15:28:45 +0100

I am happy with the charter, JP (also just having seen that there are a 
lot of PLC players listening into this list). Mischa.

JP Vasseur wrote:
>> certainly will be part of the embedded system's landscape, I remember 
>> that we decided to exclude it for a set of reasons:
>>
>> the power line? I guess there are small items to be solved but I don't 
>> see yet *the* grand challenge.
>>
> 
> it is just that LLNs can be made of both wireless and wired devices (PLC 
> and serial as pointed out by Jerry). Still constrained devices thus they 
> are part of ROLL's scope. This is very much true in Smart Grid automation.
> 
>> single node placed in the building and possibly acting as a gateway to 
>> other nets. I have had a look at the circuits diagram of typical

---

From: JP Vasseur <[email-masked]>
Date: Fri, 13 Feb 2009 15:40:20 +0100

On Feb 13, 2009, at 3:35 PM, Alexandru Petrescu wrote:

> But.  It doesn't sound as PLC devices having limited power, they sit  
> on more power than they'd ever need.

As I tried to explain before, still you want these device to consume  
as less energy as possible (e.g few dozens of mW)
thus there are constrained. If you have a house and want to do energy  
management you could not afford to have all
these device consume 3W each.

Thanks.

JP.

---

From: [email-masked]
Date: Fri, 13 Feb 2009 08:47:47 -0600

I think you're putting too much emphasis on the 'low-power' aspect of 
ROLL.  Just because the routing algorithms must support low-power devices 
(i.e. sleeping nodes, battery power, energy harvested) doesn't mean the 
network is composed only of those devices.  In the commercial building 
market, the only layer that will be truly 'low power' will be the sensors. 
 As soon as the sensor data hits the next layer (e.g. room controller) 
this will always be a powered device.  Why?  Because its main task will be 
to modulate the airflow into the building spaces.  The damper used to 
modulate the air will always need a powered actuator to open/close the 
actuator.

The point I am trying to make is that LLNs will be composed of a network 
of devices that must seamlessly interact regardless of power source.

Jerry

Alexandru Petrescu <[email-masked]> 
02/13/2009 08:35 AM

To
[email-masked]
cc
Mischa Dohler <[email-masked]>, ROLL WG <[email-masked]>, 
[email-masked], "David E. Culler" <[email-masked]>
Subject
Re: [Roll] ROLL re-chartering

What do you think?

Alex

---

From: "M. B. Anand" <[email-masked]>
Date: Fri, 13 Feb 2009 10:01:57 -0500

Mischa,
> on this list with other practical experiences with PLC?
In general, that is not the case. They don't go through the 
*transformer* very well, so most implementations aggregate at the 
transformer and jump to some other medium. There are both broadband and 
medium-band flavors that do that. In Europe (and in other parts of the 
world), the number of premises on a transformer tends to be more than in 
the US, so it is actually quite a popular technology there for AMR and 
well-proven. There are several large implementations and several in 
progress or under consideration.

There are also narrowband flavors - I mean really narrowband, like 60bps 
- that do punch through the transformer and these, at least in the US, 
are well-suited and quite well-proven in very rural environments where 
really nothing else suits the purpose.

Regards,
Anand.

---

From: Lars Eggert <[email-masked]>
Date: Fri, 13 Feb 2009 16:57:02 +0200

Hi,

> these device consume 3W each.

I get the part about still wanting to have very low power consumption  
in PLC scenarios, but ROLL is currently chartered to look at routing  
for low-powered *and lossy* networks.

It's not immediately clear to me that a PLC solution would need all  
the complexities that ROLL routing will likely need to have to deal  
with losses. Given that we don't yet know what the low-powered+lossy  
routing scheme will look like, it seems a bit premature to also make  
it work for PLCs.

Lars

---

From: JP Vasseur <[email-masked]>
Date: Fri, 13 Feb 2009 16:05:34 +0100

Hi Lars,

On Feb 13, 2009, at 3:57 PM, Lars Eggert wrote:

> I get the part about still wanting to have very low power  
> consumption in PLC scenarios, but ROLL is currently chartered to  
> look at routing for low-powered *and lossy* networks.
>

Well these low power PLC technologies and also loosy.

> with losses.

It does not introduce anything new, just clarify that these networks  
are made of wireless and wired links, which have been in our scope  
from the beginning.

> Given that we don't yet know what the low-powered+lossy routing  
> scheme will look like, it seems a bit premature to also make it work  
> for PLCs.
>

This actually does not introduce any more complexity. The idea is to  
not exclude PLC technologies, which have been mentioned in several use- 
cases of the requirement document.

Does that help clarifying ?

Thanks.

JP.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Feb 2009 16:11:14 +0100

> Well these low power PLC technologies and also loosy.

Well it's obvious wired communications aren't as lossy as wireless 
communications.

Alex

> It does not introduce anything new, just clarify that these networks are 
> made of wireless and wired links, which have been in our scope from the 
> beginning.
> 
>> Given that we don't yet know what the low-powered+lossy routing scheme 
>> will look like, it seems a bit premature to also make it work for PLCs.
>>
> 
> This actually does not introduce any more complexity. The idea is to not 
> exclude PLC technologies, which have been mentioned in several use-cases 
> of the requirement document.
>

---

From: "Daniel Smolinski" <[email-masked]>
Date: Fri, 13 Feb 2009 16:19:10 +0100

Hi all,

Actually, from in the field experience, PLC can be quite a lossy
communication technology. We have seen many cases where influence from
appliances (e.g. microwave ovens) can cause disturbances on the power line
that makes communication impossible for some time. Also, many PLC links are
asymmetrical.

While I agree that the low-power requirement can be seen either way, my
experience tells me that PLC is definitely experiencing the same problems as
do wireless networks.

Regards,
Daniel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lars
Eggert
Sent: Freitag, 13. Februar 2009 15:57
To: JP Vasseur
Cc: [email-masked]; ROLL WG; David E. Culler
Subject: Re: [Roll] ROLL re-chartering

Hi,

Lars

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 13 Feb 2009 16:24:38 +0100

JP Vasseur a écrit :
>> But.  It doesn't sound as PLC devices having limited power, they 
>> sit on more power than they'd ever need.
> 
>  as less energy as possible (e.g few dozens of mW) thus there are 
> constrained. If you have a house and want to do energy management you
>  could not afford to have all these device consume 3W each.

The problem here is _not_ to reduce the energy consumption in house.

It is to have routing work on small naturally-low-power devices - if 
that is achieved at the cost of 3W consumption by high-power devices 
then so be it.

It's difficult to embark on solving energy consumption at all possible 
levels.

Alex

---

From: "M. B. Anand" <[email-masked]>
Date: Fri, 13 Feb 2009 10:39:40 -0500

JP,
The charter looks good to me.

I would be OK with it as-is, but just a couple of very minor comments 
that don't affect the main substance:

1. In the paragraph on applications, that says:
   "There is a wide scope of application areas for LLNs, including 
industrial monitoring, building automation (HVAC, lighting, access 
control, fire), connected home, healthcare, environmental monitoring, 
urban sensor networks sensor networks, assets tracking, refrigeration."

may I suggest a small addition:
"......environmental monitoring, urban sensor networks (eg. Smart Grid), 
......."

Obviously, I am biased :-), but given that it is a big driver 
application, perhaps it would be useful to mention it by name.

2. "Refrigeration" ? Really ? Everything else on the list evokes a clear 
image and resonates, but I find I need to work hard to imagine the 
refrigeration application area.

Thanks,

Best regards,
Anand.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 13 Feb 2009 16:47:45 +0100

> Well it's obvious wired communications aren't as lossy as wireless  

do not think so ... I could provide you many pointers if you will.

Thanks.

JP.

> Alex
>
>>> It's not immediately clear to me that a PLC solution would need  
>>> all the complexities that ROLL routing will likely need to have to  
>>> deal with losses.
>> It does not introduce anything new, just clarify that these  
>> networks are made of wireless and wired links, which have been in  
>> our scope from the beginning.
>>> scheme will look like, it seems a bit premature to also make it  
>>> work for PLCs.
>>>
>> This actually does not introduce any more complexity. The idea is  
>> to not exclude PLC technologies, which have been mentioned in  
>> several use-cases of the requirement document.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 13 Feb 2009 16:50:35 +0100

changing the title ... since this is not about the charter

> The problem here is _not_ to reduce the energy consumption in house.

Yes it is ... look at smart grid operation (DR, DSM, ...)

>
>
> It is to have routing work on small naturally-low-power devices -

Right and because we have constraints on energy consumption you end up  
with constrained devices.

> if that is achieved at the cost of 3W consumption by high-power  
> devices then so be it.
>
> It's difficult to embark on solving energy consumption at all  
> possible levels.
>
> Alex
>
>

---

From: JP Vasseur <[email-masked]>
Date: Fri, 13 Feb 2009 16:52:59 +0100

Hi Anand,

On Feb 13, 2009, at 4:39 PM, M. B. Anand wrote:

> I would be OK with it as-is, but just a couple of very minor  
> comments that don't affect the main substance:
>
> control, fire), connected home, healthcare, environmental  
> monitoring, urban sensor networks sensor networks, assets tracking,  
> refrigeration."
>
> "......environmental monitoring, urban sensor networks (eg. Smart  
> Grid), ......."
>

Good catch, thanks.

> application, perhaps it would be useful to mention it by name.

Yes.

> 2. "Refrigeration" ? Really ? Everything else on the list evokes a  
> clear image and resonates, but I find I need to work hard to imagine  
> the refrigeration application area.
>

This is a bit funny ... I never "noticed" that we had "refrigeration"  
in there ;-) Will delete it.

Thanks.

JP.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 13 Feb 2009 16:04:08 -0000

I need to find the time to look more carefully at all the
proposed charter. For the moment, just one thing jumps out
at me.

> These unique properties lead to unique routing requirements

I would rather say that these specific properties lead to specific
routing requirements.

For a start, ROLL's requirements are based on four cases. These
aren't all of the cases that could have been considered, others
of which have very similar requirement (in fact they may hope
to use ROLL's solutions). In addition, what ROLL is doing is
not unique in the sense of no one else wants anything at all
like it, but rather that in the possible space of constraints
on routing solutions, ROLL occupies a particular area. But
there's continuity between what ROLL wants and what some other
people may want, it's not of totally alien nature.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: JP Vasseur <[email-masked]>
Date: Fri, 13 Feb 2009 17:08:14 +0100

> I would rather say that these specific properties lead to specific

This is fine.

> people may want, it's not of totally alien nature.

Again this is fine, I'll change the wording for "specific"

Thanks for the comment.

JP.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 13 Feb 2009 17:48:27 +0100

Hi JP and Dave:

I agree that autonomicity (self-*) is a key to scalability and deploy-ability, which are required in that space even more than for larger devices. We've heard too much buzz that L3 is too complex to deploy for simple applications such as sensor networks and backbone/backhaul, leaving the way for L2 solution.

I also agree that the centralized vs. distributed discussion is still very open and that's a good point to note in the charter. Maybe we'll end up with one of each and for all I know, there's no reason to bar either at this point.

And I agree that the concept of metric must be revisited. We'll have to cope with statistical information that cannot be properly abstracted by a simple number. We've heard too many times L2 mesh network protocols guys dismissing L3 because L3 would not be 'close enough' to the link issues to route properly. Certainly we'll have to define abstractions that enable a better visibility and accuracy from L3.

In the contextual information, I would have liked some emphasis on the fact that the routing should enable multipath to let packets slalom in the midst of interference and sleeping nodes. Also a little chat on the effects of density or the capability for the nodes to either change role or reduce their environmental impact upon density could have been good.

Nevertheless the work items themselves seem perfect to me. So the bottom line is that I do agree with this charter; the time line seems as constrained as the devices themselves but the people on the WG have shown an incredible degree of aggregated experience so I do hope and trust that we'll make it if we can find our own route past the interferences :)

Thanks a lot for all this work,

Pascal

>From: [email-masked] [mailto:[email-masked]] On Behalf Of JP Vasseur (jvasseur)
>Sent: mercredi 11 février 2009 09:08
>To: ROLL WG
>Cc: David E. Culler

---

From: JP Vasseur <[email-masked]>
Date: Fri, 13 Feb 2009 17:51:46 +0100

On Feb 13, 2009, at 5:48 PM, Pascal Thubert (pthubert) wrote:

> Hi JP and Dave:
>
> I agree that autonomicity (self-*) is a key to scalability and  
> deploy-ability, which are required in that space even more than for  
> larger devices. We've heard too much buzz that L3 is too complex to  
> deploy for simple applications such as sensor networks and backbone/ 
> backhaul, leaving the way for L2 solution.
>
> I also agree that the centralized vs. distributed discussion is  
> still very open and that's a good point to note in the charter.  
> Maybe we'll end up with one of each and for all I know, there's no  
> reason to bar either at this point.
>
> And I agree that the concept of metric must be revisited. We'll have  
> to cope with statistical information that cannot be properly  
> abstracted by a simple number. We've heard too many times L2 mesh  
> network protocols guys dismissing L3 because L3 would not be 'close  
> enough' to the link issues to route properly. Certainly we'll have  
> to define abstractions that enable a better visibility and accuracy  
> from L3.
>
> In the contextual information, I would have liked some emphasis on  
> the fact that the routing should enable multipath to let packets  
> slalom in the midst of interference and sleeping nodes. Also a  
> little chat on the effects of density or the capability for the  
> nodes to either change role or reduce their environmental impact  
> upon density could have been good.
>
> Nevertheless the work items themselves seem perfect to me. So the  
> bottom line is that I do agree with this charter; the time line  
> seems as constrained as the devices themselves but the people on the  
> WG have shown an incredible degree of aggregated experience so I do  
> hope and trust that we'll make it if we can find our own route past  
> the interferences :)
>

You are most welcome. Thanks for the feed-back. We are all looking  
forward to the next step.

Thanks.

JP.

---

From: Philip Levis <[email-masked]>
Date: Fri, 13 Feb 2009 22:04:17 -0800

> It's difficult to embark on solving energy consumption at all  

Alex,

Please listen to what the domain experts (e.g., Jerald) say, rather  
than make blanket statements based on no experience in the domain. I  
think it's safe to say that everyone here is very interested in  
constructive advice, comments, and even debate, but contradicting  
basic assumptions with no background knowledge hardly meets those  
criteria.

Phil

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 14 Feb 2009 19:05:14 +0100

Philip Levis a écrit :
> Please listen to what the domain experts (e.g., Jerald) say, rather than 
> make blanket statements based on no experience in the domain. I think 
> it's safe to say that everyone here is very interested in constructive 
> advice, comments, and even debate, but contradicting basic assumptions 
> with no background knowledge hardly meets those criteria.

Philip - I long thought about PLC-low-power text in question in the 
Charter.  I believe it to be contradictory.

That is an oppinion - make of it what you wish.

Alex

---

From: Philip Levis <[email-masked]>
Date: Sat, 14 Feb 2009 12:30:45 -0800

Comments/suggestions inline. Overall I think the charter is good.

> Low Power WiFi or other low power PLC (Powerline Communication) links.

Low power and Lossy Networks (LLNs) are made up of many embedded  
devices with limited energy, memory, and processing. The are  
interconnected by a variety of link layers, including IEEE 802.15.4,  
Bluetooth, low power WiFi and low power PLC (PowerLine Communication).

> interconnected by protocol translation gateways and proxies.

The challenges introduced by interconnecting non-interoperable LLNs  
through protocol translation gateways and proxies, as well as initial,  
non-standardized IP protocol stacks, demonstrate that LLNs greatly  
benefit from an end-to-send IP-based solution.

> LLNs have specific characteristics:

Generally speaking, LLNs have at least five distinguishing  
characteristics:

- They operate with a hard, very small bound on state.
- In most cases, LLNs optimize for saving energy.
- Typical traffic patterns are not simple unicast flows.
- LLN protocols need to be effective with very small packet sizes.
- LLN protocols have to be very careful trading off efficiency for  
generality; many LLN nodes do not have resources to waste.

> of the links and nodes in the network.

These properties cause LLNs to have requirements that existing routing  
protocols, such as OSPF, IS-IS, AODV, and OLSR, do not meet. For  
example, path selection must at times consider the specific power  
capabilities, attributes, and functional characteristics of links and  
nodes in the network.

> sensor networks and specify the set of routing requirements for

The scope of application domains for LLNs is large. Application  
domains include industrial monitoring, building automation (HVAC,  
lighting, access control, fire), connected homes, healthcare,  
environmental monitoring, urban sensor networks, assets tracking, and  
food safety monitoring. The Working Group focuses only on routing  
protocols for a subset of these: industrial automation, connected  
homes, building and urban sensor networks. The Working Group's work  
includes specifying the set of routing requirements for these domains.

> (if any) in the routing requirement creation.

The Working Group's protocol work centers on the IPv6 routing  
architecture for the above application domains. This architecture will  
consider the operating environments of LLNs, such as high reliability  
in the presence of time-varying link loss characteristics, time- 
varying connectivity, low-power operation, very limited memory and CPU  
resources, and small link-layer MTUs. The architecture will consider  
networks comprising a very large number (several thousand) nodes.  
Finally, the architecture will consider the traffic patterns typical  
to these application domains.

> upper-layer applications utilizing LLNs define appropriate mechanisms.

The Working Group will also consider the application and operational  
requirements of LLNs. These considerations
include routing security and manageability (e.g., self-configuration),  
the effects of routing decisions on transport protocols. Mechanisms  
that prevent an LLN from congestion collapse or that seek fairness  
between concurrent sessions are out of scope for the Working Group.  
The expectation is that these concerns will be handled by higher layers.

---

From: JP Vasseur <[email-masked]>
Date: Sat, 14 Feb 2009 22:59:39 +0100

Hi Phil,

Thanks for the editorial comments - I see no disagreement on the  
content, good.

JP.

On Feb 14, 2009, at 9:30 PM, Philip Levis wrote:

> through protocol translation gateways and proxies, as well as  
> initial, non-standardized IP protocol stacks, demonstrate that LLNs  
> greatly benefit from an end-to-send IP-based solution.
>
>
> These properties cause LLNs to have requirements that existing  
> routing protocols, such as OSPF, IS-IS, AODV, and OLSR, do not meet.  
> For example, path selection must at times consider the specific  
> power capabilities, attributes, and functional characteristics of  
> links and nodes in the network.
>
>
>>
>>
>>
>>
> environmental monitoring, urban sensor networks, assets tracking,  
> and food safety monitoring. The Working Group focuses only on  
> routing protocols for a subset of these: industrial automation,  
> connected homes, building and urban sensor networks. The Working  
> Group's work includes specifying the set of routing requirements for  
> these domains.
>
> architecture for the above application domains. This architecture  
> will consider the operating environments of LLNs, such as high  
> reliability in the presence of time-varying link loss  
> characteristics, time-varying connectivity, low-power operation,  
> very limited memory and CPU resources, and small link-layer MTUs.  
> The architecture will consider networks comprising a very large  
> number (several thousand) nodes. Finally, the architecture will  
> consider the traffic patterns typical to these application domains.
>
>
>
> include routing security and manageability (e.g., self- 
> configuration), the effects of routing decisions on transport  
> protocols. Mechanisms that prevent an LLN from congestion collapse  
> or that seek fairness between concurrent sessions are out of scope  
> for the Working Group. The expectation is that these concerns will  
> be handled by higher layers.
>
>> Work Items:
>>

---

From: Philip Levis <[email-masked]>
Date: Sat, 14 Feb 2009 14:07:51 -0800

> Thanks for the editorial comments - I see no disagreement on the  

Yes, no disagreement on content.

Phil

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 15 Feb 2009 14:16:53 +0100

Philip Levis a écrit :
>> embedded devices with limited power, memory, and processing
>> resources interconnected by a variety of links, such as IEEE
>> 802.15.4, Bluetooth, Low Power WiFi or other low power PLC
>> (Powerline Communication) links.

For clarification: would one point to a low-power PLC link, which is not
the typical range 100Mbps 220V/Ethernet/wifi bridge?  I wouldn't qualify
this latter as low-power device neither lossy link.

Alex

>> LLNs are transitioning to an end-to-end IP-based solution to avoid
>> the problem of non-interoperable networks interconnected by
>> protocol translation gateways and proxies.
> 
>> LLNs have specific characteristics: -       LLNs operate with a
>> hard, very small bound on state, -       In most cases, LLN need to
>> be optimized for energy saving, -       Typical traffic patterns
>> are not simply unicast flows, -       In most cases, LLNs need to
>> be effective with very small packet sizes, -       LLN routing
>> protocols have to be very careful when trading off efficiency for
> - They operate with a hard, very small bound on state. - In most
> cases, LLNs optimize for saving energy. - Typical traffic patterns
> are not simple unicast flows. - LLN protocols need to be effective
> with very small packet sizes. - LLN protocols have to be very careful
>> may not met by existing routing protocols, such as OSPF, IS-IS,
>> AODV and OLSR. For example 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.
> 
> For example, path selection must at times consider the specific power
>  capabilities, attributes, and functional characteristics of links
> and nodes in the network.
> 
> 
>> 
>> 
>> 
>> 
>> refrigeration. The Working Group will only focus on routing
>> solutions for a subset of these. It will focus on industrial,
>> connected home, building and urban sensor networks and specify the
>> set of routing requirements for these scenarios.
> 
>>  into consideration various aspects including high reliability in
>> the presence of time varying loss characteristics and connectivity
>> while permitting low-power operation with very modest memory and
>> CPU pressure in networks potentially comprising a very large number
>> (several thousands) of nodes. The Working Group will explore
>> aspects of mobility within a single LLN (if any) in the routing
>> requirement creation.
> 
> characteristics, time-varying connectivity, low-power operation, very
> limited memory and CPU resources, and small link-layer MTUs. The
> architecture will consider networks comprising a very large number
> (several thousand) nodes. Finally, the architecture will consider the
> traffic patterns typical to these application domains.
> 
> 
> 
>> and manageability (e.g., self configuration) issues. It will also
>> need to consider the transport characteristic the routing protocol
>> messages will experience. Mechanisms that protect an LLN from
>> congestion collapse or that establish some degree of fairness
>> between concurrent communication sessions are out of scope of the
>> Working Group. It is expected that upper-layer applications
>> utilizing LLNs define appropriate mechanisms.
> 
>  requirements of LLNs. These considerations include routing security
> and manageability (e.g., self-configuration), the effects of routing
> decisions on transport protocols. Mechanisms that prevent an LLN from
> congestion collapse or that seek fairness between concurrent sessions
> are out of scope for the Working Group. The expectation is that these
> concerns will be handled by higher layers.
> 
>> Work Items:
>> 
>> routing in LLNs.
>> - Provide an architectural framework for routing and path selection
>> at Layer 3 (Routing for LLN Architecture) that addresses such
>> issues as whether LLN routing protocols require a distributed
>> and/or centralized path computation models, whether additional
>> hierarchy is necessary and how it is applied. Manageability will be
>> considered with each approach, along with various trade-offs for
>> maintaining low power operation, including the presence of
>> non-trivial loss and networks with a very large number of nodes.
>> 
>> 
>> the IESG to be considered as an Informational RFC. Done   Submit
>> Routing requirements for Connected Home networks applications to
>> the IESG to be considered as an Informational RFC. Done   Submit
>> Routing requirements for Building applications to the IESG to be
>> considered as an Informational RFC. Done   Submit Routing
>> requirements for Urban networks applications to the IESG to be
>> considered as an Informational RFC. July 2009    Submit Routing
>> metrics for LLNs document to the IESG to be considered as a
>> Proposed Standard. * Feb 2009   Submit Protocol Survey to the IESG
>> to be considered as an Informational RFC. April 2009   Submit
>> Security Framework to the IESG to be considered as an Informational
>> RFC May 2009     Submit the Routing for LLNs Architecture document
>> to the IESG as an Informational RFC. July 2009    Submit first
>> draft of ROLL routing protocol specification as Proposed Standard. 
>> routing protocol specification. Dec 2009     Submit the ROLL
>> routing protocol specification to the IESG as Proposed Standard. 
>> specification to the IESG as Proposed Standard. Jan 2010
>> Evaluate WG progress, recharter or close.
>> 
> _______________________________________________ Roll mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>

---

From: Tim Winter <[email-masked]>
Date: Sun, 15 Feb 2009 15:39:19 -0500

The proposed charter looks good to me.

-Tim

---

From: Omprakash Gnawali <[email-masked]>
Date: Sun, 15 Feb 2009 18:02:23 -0800

Charter looks good. Two nits and one comment below.

On Sat, Feb 14, 2009 at 12:30 PM, Philip Levis <[email-masked]> wrote:
> Low power and Lossy Networks (LLNs) are made up of many embedded devices
> with limited energy, memory, and processing. The are interconnected by a

resources missing after processing.

...

> Generally speaking, LLNs have at least five distinguishing characteristics:
>

We already say "Generally", so we can drop "In most cases" and
"Typical" from the items on the list.

> - LLN protocols need to be effective with very small packet sizes.

Probably a few words missing after effective: effective at doing
something. I can not think of what that something is unless we are
talking about some type of efficiency.

- om_p

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 16 Feb 2009 09:49:15 +0100

Dear JP, David, ROLL wg,

(and, as I have a question to Alex, I Cc' him explicitly too)

I've got a couple of comments to the charter below. I think it needs  
a bit of clarification in some areas, and also the relationship to  
current ROLL WG products needs to be clarified IMO. See below for  
details -- most of which I believe are questions that I raise that it  
should be fairly easy for a more experienced person to simply answer  
and propose a one-sentence clarification-edit to the charter to fix.

> -       In most cases, LLN need to be optimized for energy saving,

I am not sure that "in most cases" is entirely clear here. Does this  
mean that we can get away with designing an "energy hungry" routing  
protocol for ROLL, as long as we specify in which cases it'd apply?  
I'd be happier getting rid of "in most cases" and replacing "energy  
saving" with "energy conservation" or something similar.

> -       Typical traffic patterns are not simply unicast flows,

This, I have a big question mark to as well. It applies equally to  
the survey I-D, but I'll comment on that I-D in another email.

Essentially, as a protocol designer, I'd expect a wg charter to help  
me understand the constraints under which I'd be designing a  
protocol. Reading the above item teaches me that I shouldn't design  
for "simply unicast flows", but what does that mean? Could I  
disregard unicast entirely and just build a multicast protocol? Do I  
then need group mgmt? Or is simple "roll-wide broadcast" all that's  
needed? Or all of the above? None of the above?

IOW, we need to be much more specific with what the traffic patterns  
then typically would be?

> -       In most cases, LLNs need to be effective with very small  

I've gone back and forth over this, and it's also a comment that I  
think needs clarification in the survey I-D. First, I think that it'd  
be helpful to say something as to "how small". Second, to which  
extend are we looking at transport [and other] issues in ROLL.

I can read this in different ways, here's my first impulse on that  
bullet point:

	o	ROLL runs over LLs with an extremely restricted frame-size, so  
something akin to
		IP header compression is on the table [are we then in RTG?].

	o	Presumably, the "very small packet sizes" also applies for data.  
Is this, then,
		a generic IP-over-FOO problem?

I can guess at what the intent would be, but we need to spell it out  
here.

> off efficiency for generality; many LLN nodes do not have resources  

I can see where Alexandru's question come from at this point, when we  
were talking about power-lines and such.

Essentially, what we're wanting to say [I think] is that "ROLL  
protocols MUST be able to run on routers with [very-strict-set-of- 
restrictions]" -- and that there then may be a few routers with  
"better than [very-strict-set-of-restrictions]" shouldn't be driving  
our design, and that such routers are present is purely incidental.

IOW, I'd suggest rephrasing this slightly, to say "these are the  
requirements that ROLL protocols shall satisfy -- if a device does  
better than that, more power to it, but it's not our primary design  
target".

Alex, would a rephrasing like this satisfy you?

> of the links and nodes in the network.

Request for clarification (a question may or may not follow): is  
multi-metric QoS thereby an explicit design requirement?

Also, it seems from the sentence construction that it is inferred  
that "OSPF, IS-IS, AODV and OLSR" do not have the capability to take  
"power capabilities, attributes and functional characteristics of the  
links and nodes in the network" into consideration. I'm not sure that  
that's the entire truth. Can this be clarified a notch?

> The Working Group is focused on routing issues for LLN

Alright, so routing issues only. Fair enough -- but what's the  
relationship then with the "very small packet sizes" bullet point  
above? Do we expect [other-wg] to resolve this issue, or is there  
routing-only-issues that need be brought forward? If so, which?

>  sensor networks and specify the set of routing requirements for

Question: does the above entail "new work", or is this in reference  
to the current requirement I-Ds?

>  framework for these application scenarios.

Question: by "architectural framework", what exactly is to be  
understood?

> The Framework will take into consideration various

Does this entail a new "routing requirements" document being produced?

>  experience.

This goes back to my previous question: IP-over-foo or ?

More broadly, how are the current ROLL products (survey I-D, rtg  
requirements) expected to be employed in all this?

Finally, in summarizing the charter, ROLL aims at solving:

	o 	routing over wireless
	o	scalability to several thousands of routers
	o	QoS in wireless networks, including
	o	formalization of wireless link metrics
	o	security

within 10 months, and to the level of proposed standard.

The items are very interesting, but 10 months is also *very* short --  
and the complexity of some of those is not trivial without making  
serious concessions in some areas.

Let me cite from an email from Dave Ward (Feb. 3, 2009)

On Feb 3, 2009, at 5:52 PM, David Ward wrote:
> I expect "wild swings" of the design pattern of the protocol during  
> the first year of the design effort. I attempted to make this clear  
> at the mic in Minneapolis that the current trajectory is very  
> complex problem domain that hasn't born a lot of fruit but, that in  
> the design phase reducing the complexity must occur.

Considering the complexity of the list of items above, I am much more  
in line with what Dave Ward writes, than with what the milestones  
suggest.

Thomas

> Mechanisms that protect an LLN from congestion collapse or

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Feb 2009 10:58:23 +0100

Thomas Heide Clausen a écrit :
[...]
> protocols MUST be able to run on routers with 
> [very-strict-set-of-restrictions]" -- and that there then may be a 
> few routers with "better than [very-strict-set-of-restrictions]" 
> shouldn't be driving our design, and that such routers are present is
>  purely incidental.
> 

This rephrasing sounds better to me.  I agree to a clearcut distinction
between constrained devices and generous devices (generous because they
could do better if really there was a need).  In this sense, your
suggestion to explicitely state that generous devices are not the
primary goal sounds good to me.

It could crystalize the generic energy-consumption goals, distinguishing
between:
-routing protocols which should consume less power for their own
  working (exchange routing protocol packets with few headers, and are
  short, and less often)
-routing protocols which would establish lowest-energy paths
  (subsequently to routing exchanges the application-level packets
  will follow paths with lowest energy)
-and too generic goal of reducing energy consumption in a building -
  this could be the Energy Considerations section of every other IETF
  protocol.

Alex

---

From: JP Vasseur <[email-masked]>
Date: Mon, 16 Feb 2009 11:02:27 +0100

Hi Thomas,

On Feb 16, 2009, at 9:49 AM, Thomas Heide Clausen wrote:

> details -- most of which I believe are questions that I raise that  
> it should be fairly easy for a more experienced person to simply  
> answer and propose a one-sentence clarification-edit to the charter  
> to fix.
>

Right this means that "energy saving" can be a soft constraint as  
opposed to a hard constraint with battery operated devices.

> saving" with "energy conservation" or something similar.

OK changing "energy saving" for "energy conservation"

> IOW, we need to be much more specific with what the traffic patterns  

We could be more specific on many items but we would end up with a  
very lengthy charter. These aspects are captured in the routing  
requirement IDs, which are the IDs where we specify the requirements  
that the protocol must satisfy.

How about ....

- Typically traffic patterns are not simply unicast flows (e.g. in  
some environments most if not all traffic can be point to multipoint)

> think needs clarification in the survey I-D. First, I think that  
> it'd be helpful to say something as to "how small".

But we do not want to be PHY/MAC specific. Here we list a general LLN  
characteristic.

> Second, to which extend are we looking at transport [and other]  
> issues in ROLL.
>

We do not. This is spelled out below in the charter.

> I can guess at what the intent would be, but we need to spell it out  

The former of course ... and in "most cases" (e.g. 15.4).

> I can see where Alexandru's question come from at this point, when  
> we were talking about power-lines and such.
>

That could be the case but again we cannot list all requirements in  
the charter. They are specified in the requirement documents.

> "power capabilities, attributes and functional characteristics of  
> the links and nodes in the network" into consideration. I'm not sure  
> that that's the entire truth. Can this be clarified a notch?

We do say "existing". Not sure which clarification you want ?

> above? Do we expect [other-wg] to resolve this issue,

A good example being 6lowpan.

> or is there routing-only-issues that need be brought forward? If so,  
> which?
>

This "a" characteristic since you asked to spell out a bit more  
precisely LLN's characteristics (and this was an excellent idea). An  
obvious consequence being that the routing protocol cannot afford to  
send to large frames (in some cases). Detailed requirements again are  
in application-specific routing requirements documents.

> to the current requirement I-Ds?

Good catch, it should read: "It focuses on industrial, connected home,  
building and urban sensor networks and specify the set of routing  
requirements for these scenarios."

> Question: by "architectural framework", what exactly is to be  

A routing architecture ID (pointed out in the WG item).

> Does this entail a new "routing requirements" document being produced?

Another good point. We can remove that last sentence.

> requirements) expected to be employed in all this?

Quite clear:
1) The survey was there to figure out whether *existing* protocol  
could meet the requirements. The answer is "no"
2) Requirements are used to produce the protocol (extensions or new).

> 	o	formalization of wireless link metrics

Not just wireless at discussed on the ML, not sure why you mention QoS  
in wireless network (at most we do QoS routing), ...

> The items are very interesting, but 10 months is also *very* short  
> -- and the complexity of some of those is not trivial without making  

It is aggressive but should we end up extending an existing protocol  
does not take so much time. The good thing is that we spent a lot of  
time spelling out all requirements, which will ease the protocol  
design phase. We can always add a few months to the last milestone.

> Considering the complexity of the list of items above, I am much  
> more in line with what Dave Ward writes, than with what the  
> milestones suggest.

Thanks.

JP.

>> at

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Feb 2009 11:04:08 +0100

> do not think so ... I could provide you many pointers if you will.

Is this saying that wireless _and_ wired communications are lossy?  In 
this sense all links are lossy, and all protocols designed for them have 
taken that into account.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Feb 2009 11:07:45 +0100

> Yes it is ... look at smart grid operation (DR, DSM, ...)

Well yes, I agree, there are many activities trying to reduce energy 
consumption in household, server farm and more.

The question is how to distinguish all these activities because not all 
could be addressed in a humble IETF WG.

> with constrained devices.

I think there's a difference between devices which couldn't do better 
than what their AA battery allowed them to, and devices which could do 
better if they were energy-minded.

Alex

---

From: JP Vasseur <[email-masked]>
Date: Mon, 16 Feb 2009 11:07:00 +0100

On Feb 16, 2009, at 11:04 AM, Alexandru Petrescu wrote:

> Is this saying that wireless _and_ wired communications are lossy?   
> In this sense all links are lossy, and all protocols designed for  
> them have taken that into account.

Many people tried to provide you answer. We mean that LLNs can be made  
of lossy wired links, yes. Which does not mean that all wired links  
are lossy of course ...

JP.

---

From: JP Vasseur <[email-masked]>
Date: Mon, 16 Feb 2009 11:07:59 +0100

On Feb 16, 2009, at 10:58 AM, Alexandru Petrescu wrote:

>> "better than [very-strict-set-of-restrictions]" shouldn't be  
>> driving our design, and that such routers are present is
>> purely incidental.
> This rephrasing sounds better to me.

What is exactly the proposed rephrasing ?

> I agree to a clearcut distinction

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Feb 2009 11:13:49 +0100

Daniel Smolinski a écrit :
> communication technology. We have seen many cases where influence 
> from appliances (e.g. microwave ovens) can cause disturbances on the 
> power line that makes communication impossible for some time. Also, 
> many PLC links are asymmetrical.

That's good to know and other influences are related to the number of
devices plugged into a same wall socket.  But these are warnings posted
on red stickers telling how to properly set up a PLC network.

I'm not sure a layer-3 routing protocol should address these.

> While I agree that the low-power requirement can be seen either way, 
> my experience tells me that PLC is definitely experiencing the same 
> problems as do wireless networks.

It's true, wireless networks often seem non-deterministic in behaviour,
as wireless links do often.

It's also very important to build a deterministic behaviour wireless
link-layer, with link-layer solutions.  When that is achieved, a layer-3
routing protocol is able to better run on top of it.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Feb 2009 11:21:47 +0100

JP Vasseur a écrit :
>>>>> Hi Lars, On Feb 13, 2009, at 3:57 PM, Lars Eggert wrote:
>>>>>> Hi,
>>>>>> 
>>>>>>>> Jerald - ok, PLC is important.  It's related to routing
>>>>>>>> and energy transportation.
>>>>>>>> 
>>>>>>>> But.  It doesn't sound as PLC devices having limited
>>>>>>>> power, they sit on more power than they'd ever need.
>>>>>>> 
>>>>>>> As I tried to explain before, still you want these device
>>>>>>> to consume as less energy as possible (e.g few dozens of
>>>>>>> mW) thus there are constrained. If you have a house and
>>>>>>> want to do energy management you could not afford to have
>>>>>>> all these device consume 3W each.
>>>>>> 
>>>>>> consumption in PLC scenarios, but ROLL is currently
>>>>>> chartered to look at routing for low-powered *and lossy*
>>>>>> networks.
>>>>>> 
>>>> Well it's obvious wired communications aren't as lossy as
>>>> wireless communications.
>>>> 
> Many people tried to provide you answer. We mean that LLNs can be
> made of lossy wired links, yes. Which does not mean that all wired
> links are lossy of course ...

JP,

To explain: if a link is lossy, frustratingly non-deterministic, it may
very well be because it's not correctly set up.  In this sense, this
lossiness is not relevant to any routing protocol.

Lossiness of PLC links could be avoided by setting them up properly,
don't plug the microwave oven if the manufacturer says so.

I think that lossiness aspect is fundamentally different than lossiness
aspect of battery-powered and 300Kb bluetooth 10m range as stated by its
manufacturer.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Feb 2009 11:31:04 +0100

[email-masked] a écrit :
> ROLL.  Just because the routing algorithms must support low-power 
> devices (i.e. sleeping nodes, battery power, energy harvested) doesn't 
> mean the network is composed only of those devices.  In the commercial 
> building market, the only layer that will be truly 'low power' will be 
> the sensors.  As soon as the sensor data hits the next layer (e.g. room 
> controller) this will always be a powered device.  Why?  Because its 
> main task will be to modulate the airflow into the building spaces.  The 
> damper used to modulate the air will always need a powered actuator to 
> open/close the actuator.
> 

The in-house network illustration makes sense to me.  I tend to agree 
there's a distinction in links, regarding their power.

I'm not sure how to understand this in the context of ROLL proposed 
Charter though.  Its first paragraph clearly mixes PLC links with 
lower-energy links:

> Low Power WiFi or other low power PLC (Powerline Communication) links. LLNs are transitioning to an end-to-end IP-based
> interconnected by protocol translation gateways and proxies. LLNs have specific characteristics:
> -       In most cases, LLNs need to be effective with very small packet sizes,
> -       LLN routing protocols have to be very careful when trading off efficiency for generality; many LLN nodes do not have resources to waste.

Alex

---

From: Emmanuel Baccelli <[email-masked]>
Date: Mon, 16 Feb 2009 11:37:52 +0100

Hi JP,
I have some comments about the strawman charter. Here they are, inline.
regards,
Emmanuel

> Low Power WiFi or other low power PLC (Powerline Communication) links. LLNs
> are transitioning to an end-to-end IP-based

In my mind, the charter needs to be more precise here: what is specific
about the targeted traffic patterns? Protocol designers need to know this.

> -       In most cases, LLNs need to be effective with very small packet

This needs to be more precise too: at first sight, this seems rather a
problem for layers below IP. Why is this a problem for ROLL? There should be
at least a hint why.

> of the links and nodes in the network.

Moreover, the way path selection is expressed in the above, is reminiscent
of the way QoS routing is evoked, with interesting NP-complete problems etc.
i.e. yet another "world" of problems that seem to be in scope too, while
ROLLs plate is already very full. I suggest being more precise about what is
in scope within the wide domain of QoS routing.

>  sensor networks and specify the set of routing requirements for

At first sight there is a serious contradiction with the current charter
here: what was the purpose of the WG documents so far, including requirement
documents, if there needs to be another requirement document down the line?
This is unclear. So the document should explain what is the difference
between the current WG documents and this future document, in order to avoid
confusing people.

> (if any) in the routing requirement creation.

Several thousands of nodes. Mobility. 10 months... Hmmm, this is extremely
ambitious, to say the least. More generally, in my opinion, the charter
should differentiate between short term achievable goals, and long term
directions. And if the charter is to be "conservative" (as are more and more
WG charters lately) it should list only short term, achievable goals.

>  upper-layer applications utilizing LLNs define appropriate mechanisms.

If self-configuration is an aim too for ROLL (yet another vast domain, by
the way), what is the relationship between this activity and the scope of
AUTOCONF? The charter should be explicit about this difference.

> includes static and dynamic link/node attributes required for routing in

Metrics for wireless is a very interesting research topic... but a can of
worm that has already stalled several IETF processes in the past. Again, 10
months seems unrealistic for that, and therefore I strongly suggest
restricting the charter to an achievable list of short-term goals.

>  including the presence of non-trivial loss and networks with a very

OK, so judging from the plural form used ("LLN routing protocols"), there
are going to be several protocols. This is fine, but the charter must spell
out

- why multiple routing protocols?
- what is the specificity of each routing protocol to be designed?

> - Protocol work: In light of the application specific routing requirements,
> the Working Group will either specify a new protocol and/or will select an
> existing routing protocol (with the appropriate extensions in cooperation
> with the relevant Working Group).
>
> Done   Submit Routing requirements for Industrial applications to the IESG
> Done   Submit Routing requirements for Building applications to the IESG to
> be considered as an Informational RFC.
> Done   Submit Routing requirements for Urban networks applications to the
> April 2009   Submit Security Framework to the IESG to be considered as an
> Informational RFC
> May 2009     Submit the Routing for LLNs Architecture document to the IESG
> as an Informational RFC.
> July 2009    Submit first draft of ROLL routing protocol specification as
> Proposed Standard.
> Dec 2009     Submit the ROLL routing protocol specification to the IESG as
> Proposed Standard.
>

Here I get very confused by two things:

- the date (10 months from now), which is awfully short
- the singular form ("the ROLL routing protocol") which contradicts the
plural form used earlier on in the charter.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Feb 2009 11:40:35 +0100

> What is exactly the proposed rephrasing ?

If one agrees with a distinction in energy between PLC device and 
batter-powered devices.

Then a clarifying suggestion could be the following.

> -       LLN routing protocols have to be very careful when trading off efficiency for generality; many LLN nodes do not have resources to waste.

Suggested text:
"
Low power and Lossy networks (LLNs) are typically composed of many
embedded devices with limited power, memory, and processing resources
interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth,
Low Power WiFi or other low power links [remove: PLC (Powerline 
Communication) links]. LLNs are transitioning to an end-to-end IP-based
  solution to avoid the problem of non-interoperable networks
interconnected by protocol translation gateways and proxies. LLNs have 
specific characteristics:
-       ...
-       They are securely connected to the Internet.
-       LLN devices and links are linked together with other
         devices and links, which are not energy-constrained and whose
         bandwidth/latency/range/emissionpower could be orders of
         magnitude better, e.g. PLC devices.
"

Would you agree with this PLC distinction and the explicit statement of 
Internet connectivity?

Alex

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 16 Feb 2009 11:41:49 +0100

JP,

I'll be brief....

On Feb 16, 2009, at 11:02 AM, JP Vasseur wrote:

>> I've got a couple of comments to the charter below. I think it  
>> needs a bit of clarification in some areas, and also the  
>> relationship to current ROLL WG products needs to be clarified  
>> IMO. See below for details -- most of which I believe are  
>> questions that I raise that it should be fairly easy for a more  
>> experienced person to simply answer and propose a one-sentence  
>> clarification-edit to the charter to fix.
>>
>>> resources
>> I am not sure that "in most cases" is entirely clear here. Does  
>> this mean that we can get away with designing an "energy hungry"  
>> routing protocol for ROLL, as long as we specify in which cases  
>> it'd apply?
>

Right, but this is kind of my point: designing for "most cases" will  
also allow running on "better than most cases". In this case,  
designing for "hard energy constraints" will mean that the protocol  
also will run well on something with an embedded nuclear reactor ;)

I'm wondering if it'd not be better to wrap all this up in a way  
similar to the below:

	LLNs have varied characteristics, below a list of "extreme" such --  
obviously,
	if a given LLN has better-than-these characteristics, it'll still  
work fine, but a
	LLN routing protocol MUST still be able to function under these  
constraints:

		-	Hard, small bound on state
		-	Energy
		<etc - rest of list>

This'd make it clear to me. I think it'd also capture the suggestion  
I made to Alex' issue?

>> I'd be happier getting rid of "in most cases" and replacing  
>> "energy saving" with "energy conservation" or something similar.
>>
>
>> Essentially, as a protocol designer, I'd expect a wg charter to  
>> help me understand the constraints under which I'd be designing a  
>> protocol. Reading the above item teaches me that I shouldn't  
>> design for "simply unicast flows", but what does that mean? Could  
>> I disregard unicast entirely and just build a multicast protocol?  
>> Do I then need group mgmt? Or is simple "roll-wide broadcast" all  
>> that's needed? Or all of the above? None of the above?
>>
>> IOW, we need to be much more specific with what the traffic  
>> patterns then typically would be?
>
> requirement IDs, which are the IDs where we specify the  
> requirements that the protocol must satisfy.
>
> How about ....
>

Much clearer, I think. [side-note/question/not-charter-as-such: does  
this mean that a ROLL protocol should be multicast-capable?]

> But we do not want to be PHY/MAC specific. Here we list a general  
> LLN characteristic.
>
>> 	o	Presumably, the "very small packet sizes" also applies for  
>> data. Is this, then,
>> I can guess at what the intent would be, but we need to spell it  
>> out here.
>

That's what I'd have suspected as well, although reading the charter  
gave me a slightly different impression. Trying to be constructive,  
how 'bout, then, some variation over the following:

	-	In most cases, LLNs will be employed over L2 with extremely  
restricted frame-sizes,
		thus a routing protocol for LLNs should be specifically adapted for  
such?

(I'm sure that it can be phrased better, but I think it'd be more  
unambiguous that way)

>> driving our design, and that such routers are present is purely  
>> incidental.
>>
>> better than that, more power to it, but it's not our primary  
>> design target".
>>

As I suggested above, this would also satisfy my other comment.

> the charter. They are specified in the requirement documents.

OK, you answered my question.

>> that "OSPF, IS-IS, AODV and OLSR" do not have the capability to  
>> take "power capabilities, attributes and functional  
>> characteristics of the links and nodes in the network" into  
>> consideration. I'm not sure that that's the entire truth. Can this  
>> be clarified a notch?
>

Ok, I may not have been clear. OSPF, IS-IS, AODV and OLSR do all  
support QoS in some form or other, i.e. they are able to take these  
(power, attributes, ...) into account. It reads as if the charter is  
saying "no they don't". It may be that they don't do so in a  
desirable way (in which case, that should be analyzed and stated).

> A good example being 6lowpan.

Would it make sense to reference that in the charter? "The ROLL wg  
will pay attention to other IETF work addressing topics within the  
ROLL space, e.g. 6lowpan, <complete-the-list>)". I've seen that done  
for other WG charters, and found it immensely helpful when diving  
into a new wg and trying to find foothold.

>
>> or is there routing-only-issues that need be brought forward? If  
>> so, which?
>>
>
> precisely LLN's characteristics (and this was an excellent idea).

And, I think, that it was excellently taken on board as well, and I  
appreciate both the survey I-D and the charter for having done so.

> An obvious consequence being that the routing protocol cannot  
> afford to send to large frames (in some cases). Detailed  
> requirements again are in application-specific routing requirements  
> documents.

Yep, agreed. I think that the suggestion that I made above would just  
about cover this issue. I agree that we do not want to be too verbose  
here, so I think it'd be a small fix.

>>> monitoring,
>> Question: does the above entail "new work", or is this in  
>> reference to the current requirement I-Ds?
>
> Good catch, it should read: "It focuses on industrial, connected  
> home, building and urban sensor networks and specify the set of  
> routing requirements for these scenarios."

Glad to not be entirely useless ;)

> A routing architecture ID (pointed out in the WG item).

OK, I am not quite sure what that is, though? Maybe it's me being  
dense, do you have a reference to something akin to this, just for my  
personal education?

> Another good point. We can remove that last sentence.

;)

> 2) Requirements are used to produce the protocol (extensions or new).

I just wonder if those "findings" (or at least the documents  
containing those) need not get mention in the charter?

> Not just wireless at discussed on the ML, not sure why you mention  
> QoS in wireless network (at most we do QoS routing), ...

Ok, remove "in wireless networks, including" from the list above, the  
rest of my comment still stands -- it seems very ambitious scheduling.

Thomas

>> -- and the complexity of some of those is not trivial without  
>> making serious concessions in some areas.
>
> It is aggressive but should we end up extending an existing  
> protocol does not take so much time. The good thing is that we  
> spent a lot of time spelling out all requirements, which will ease  
> the protocol design phase. We can always add a few months to the  
> last milestone.
>
>>> I expect "wild swings" of the design pattern of the protocol  
>>> during the first year of the design effort. I attempted to make  
>>> this clear at the mic in Minneapolis that the current trajectory  
>>> is very complex problem domain that hasn't born a lot of fruit  
>>> but, that in the design phase reducing the complexity must occur.
>>
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Feb 2009 11:51:00 +0100

> Much clearer, I think.

On this particular point, me to I agree, it becomes clearer.  If the 
terms unicast and multicast were used explicitely then it would make 
sense to me.

Typically traffic patterns are not simply unicast flows but also multicast.

Alex

---

From: JP Vasseur <[email-masked]>
Date: Mon, 16 Feb 2009 11:56:51 +0100

Hi Emmanuel,

Thanks for your comments - see in line.

On Feb 16, 2009, at 11:37 AM, Emmanuel Baccelli wrote:

> In my mind, the charter needs to be more precise here: what is  
> specific about the targeted traffic patterns? Protocol designers  
> need to know this.

What I proposed to Thomas was:

"- Typically traffic patterns are not simply unicast flows (e.g. in  
some environments most if not all traffic can be point to multipoint)"

Do you like this better ? If we want to go one step further, one  
should refer to the requirement.

> This needs to be more precise too: at first sight, this seems rather  
> a problem for layers below IP. Why is this a problem for ROLL? There  
> should be at least a hint why.
>

See my reply to Thomas and let me know.

> Moreover, the way path selection is expressed in the above, is  
> reminiscent of the way QoS routing is evoked, with interesting NP- 
> complete problems etc. i.e. yet another "world" of problems that  
> seem to be in scope too, while ROLLs plate is already very full. I  
> suggest being more precise about what is in scope within the wide  
> domain of QoS routing.

Where do you see "Qos routing ?".

Remember, the goal of the charter is not to express all specific  
requirements. There are for routing requirements documents for that  
purpose.

> At first sight there is a serious contradiction with the current  
> charter here: what was the purpose of the WG documents so far,  
> including requirement documents, if there needs to be another  
> requirement document down the line? This is unclear.

You are right, this has been corrected ("will only focus" should read  
"only focuses") - Fixed.

> So the document should explain what is the difference between the  
> current WG documents and this future document, in order to avoid  
> confusing people.
>
>
>
>
> Several thousands of nodes. Mobility. 10 months...

Yes again the last sentence has been removed.

> Hmmm, this is extremely ambitious, to say the least. More generally,  
> in my opinion, the charter should differentiate between short term  
> achievable goals, and long term directions. And if the charter is to  
> be "conservative" (as are more and more WG charters lately) it  
> should list only short term, achievable goals.

Do yo know why we think that it is achievable ? Because such routing  
protocols (non IP) are being deployed today.
That said, as proposed, let's add a few months to the milestone.

> If self-configuration is an aim too for ROLL (yet another vast  
> domain, by the way), what is the relationship between this activity  
> and the scope of AUTOCONF? The charter should be explicit about this  
> difference.

It is all spelled out in the requirement documents though, with  
dedicated "Manageability" section, as experimented in other WGs such  
as the PCE WG. But you are right that we should be a bit more precise  
here.

How about ?

OLD:

The Working Group will pay particular attention to routing security  
and manageability (e.g., self configuration) issues.

NEW:
The Working Group will pay particular attention to routing security  
and manageability (e.g., minimal routing configuration) issues.

> Metrics for wireless is a very interesting research topic... but a  
> can of worm that has already stalled several IETF processes in the  
> past. Again, 10 months seems unrealistic for that, and therefore I  
> strongly suggest restricting the charter to an achievable list of  
> short-term goals.

Note that we have been discussing this item for a long time and the  
existing (non WG document) is progressing well. New revision soon. The  
idea is to define a few useful metrics for the L3 (for link and node)  
and again we already had a good consensus on which metrics, ... Still  
far from being finalized but on its way.

> OK, so judging from the plural form used ("LLN routing protocols"),  
> there are going to be several protocols. This is fine, but the  
> charter must spell out

No ... as discussed on this list we do *not* know yet. Certainly not  
one per application, ideally one, may be two. Both David and I  
answered to this question on the list.

> - the singular form ("the ROLL routing protocol") which contradicts  
> the plural form used earlier on in the charter.
>
>

We will change for Feb 2010.
We do not know whether there will be one or more.

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Mon, 16 Feb 2009 11:57:15 +0100

OK.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 16 Feb 2009 11:05:47 -0000

There have been a number of agreed changes in response to emails
from various people. Could we have a revised draft with what the
current state is please. (I want to review, and it would seem sensible
not to possibly comment on something already changed.)

---

From: "Daniel Smolinski" <[email-masked]>
Date: Mon, 16 Feb 2009 12:12:47 +0100

Hi Alex,

to me, lossy means that link communication can fail because of natural
influences to the transmission media. It makes no difference if a wireless
link fails because some item temporarily blocks the path (or all paths) or
if a powerline link fails if the line impedance or noise spectrum changes
for some time.

> don't plug the microwave oven if the manufacturer says so.

I don't think that this is a valid solution to disturbances in the
powerline. The PLC technology itself must be able to handle these issues,
either by the robustness of the PHY layer, link layer mechanisms or a
combination of both. But, so should any technology, and if it fails due to
influences from the outside, it is lossy and this needs to be considered in
the routing.

Daniel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alexandru Petrescu
Sent: Montag, 16. Februar 2009 11:22
To: JP Vasseur
Cc: [email-masked]; David E. Culler; ROLL WG
Subject: Re: [Roll] ROLL re-chartering

JP,

Alex

Renesas Technology Europe GmbH
Sitz: Ratingen, Amtsgericht Duesseldorf, HRB 44903
Geschaeftsfuehrer: Peter Mies, Tsutomu Miki, Matthew Trowbridge, Holger Zielke

---

From: JP Vasseur <[email-masked]>
Date: Mon, 16 Feb 2009 12:19:53 +0100

Hi Thomas,

We are converging ... :-) See further proposed changes below and let  
me know if that addressed your remaining concerns.

>> some environments most if not all traffic can be point to multipoint)

OK Changed.

> [side-note/question/not-charter-as-such: does this mean that a ROLL  
> protocol should be multicast-capable?]
>

I'll leave this for a different thread ;-)

> 		thus a routing protocol for LLNs should be specifically adapted  
> for such?
>

If that helps clarifying I'm all for it:

NEW:

"In most cases, LLNs will be employed over L2 with restricted frame- 
sizes, thus a routing protocol for LLNs should be specifically adapted  
for such link layers".

OK.

> desirable way (in which case, that should be analyzed and stated).

Ah I see what you mean now:

Proposal:

OLD:
These specific properties cause LLNs to have specific routing  
requirements that existing routing protocols, such as OSPF, IS-IS,  
AODV, and OLSR, do not meet. For example, path selection must at times  
consider the specific power capabilities, attributes, and functional  
characteristics of links and nodes in the network.
NEW
These specific properties cause LLNs to have specific routing  
requirements that existing routing protocols, such as OSPF, IS-IS,  
AODV, and OLSR, do not meet.
Simply delete the last sentence, which may be confusing I agree.
Deleted: For example, path selection must at times consider the  
specific power capabilities, attributes, and functional  
characteristics of links and nodes in the network.

> into a new wg and trying to find foothold.

The only issue is that I do not want to create inter-dependencies  
between WGs. Today 6lowpan is exclusively focusing on 15.4, this may  
change ...

> Yep, agreed. I think that the suggestion that I made above would  
> just about cover this issue. I agree that we do not want to be too  
> verbose here, so I think it'd be a small fix.

OK.

> Glad to not be entirely useless ;)

;-) Hey I never implied any such thing ;-))

> dense, do you have a reference to something akin to this, just for  
> my personal education?

Sure, RFC4655 or RFC3945

> containing those) need not get mention in the charter?

Good suggestion. How about:

OLD:
These specific properties cause LLNs to have specific routing  
requirements that existing routing protocols, such as OSPF, IS-IS,  
AODV, and OLSR, do not meet. For example, path selection must at times  
consider the specific power capabilities, attributes, and functional  
characteristics of links and nodes in the network.
NEW
These specific properties cause LLNs to have specific routing  
requirements. As shown in a protocol survey existing routing protocols  
(in their current form) such as OSPF, IS-IS, AODV, and OLSR, do not  
meet these specific routing requirements.

And then ..

OLD:

... It will focus on industrial, connected home, building and urban
  sensor networks and specify the set of routing requirements for
  these scenarios ...

NEW:
The Working Group focuses on industrial, connected home, building and  
urban
  sensor networks and has specified the set of routing requirements for
  these scenarios. These application-specific routing requirement  
documents will be used for protocol design.

> Ok, remove "in wireless networks, including" from the list above,  
> the rest of my comment still stands -- it seems very ambitious  
> scheduling.

We have pushed the time line to Feb 09.

Thanks for the help.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Mon, 16 Feb 2009 12:25:04 +0100

On Feb 16, 2009, at 11:40 AM, Alexandru Petrescu wrote:

>>>> requirements that ROLL protocols shall satisfy -- if a device  
>>>> does better than that, more power to it, but it's not our primary  
>>>> design target".
>>>
> Would you agree with this PLC distinction and the explicit statement  
> of Internet connectivity?
>

Sorry but not sure what you mean ...
1) On Internet connectivity, some LLNs may not be connected to the  
Internet at all (not typical I agree).
2) The changes you propose above for PLC are very ambiguous ... I saw  
that someone replied to you on this and helped you understand a bit  
better the PLC issue.

Thanks.

JP.

---

From: Emmanuel Baccelli <[email-masked]>
Date: Mon, 16 Feb 2009 12:59:30 +0100

I agree with Chris. I'll comment further on the revision.Emmanuel

---

From: Emmanuel Baccelli <[email-masked]>
Date: Mon, 16 Feb 2009 13:09:36 +0100

I have one comment in the mean-time, though:

> This is unclear.
> You are right, this has been corrected ("will only focus" should read "only
> focuses") - Fixed.
>
> So the document should explain what is the difference between the current
> WG documents and this future document, in order to avoid confusing people.
>
>
JP, did you see my above comment? I'm not sure you answered the question
about why we do need another requirement document?

cheers

Emmanuel

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 16 Feb 2009 13:08:46 +0100

+1

I am starting to loose track (although we seem to be on a  
constructive track ;) )

---

From: JP Vasseur <[email-masked]>
Date: Mon, 16 Feb 2009 13:24:26 +0100

Hi Emmanuel,

On Feb 16, 2009, at 1:09 PM, Emmanuel Baccelli wrote:

> You are right, this has been corrected ("will only focus" should  
> read "only focuses") - Fixed.
>
> JP, did you see my above comment? I'm not sure you answered the  
> question about why we do need another requirement document?

There will not be any new requirement in fact. I think that the  
confusion is coming from the fact that the old text used to say "The  
Working group will ... " thus I have updated for "The Working Group  
focusses ....". Here is the new text.

There is a wide scope of application areas for LLNs, including
  industrial monitoring, building automation (HVAC, lighting, access
control, fire), connected homes, healthcare, environmental monitoring,
urban sensor networks (e.g. Smart Grid), assets tracking.
The Working Group focuses on routing solutions for a subset of
these: industrial, connected home, building and urban
  sensor networks for which routing requirements have been specified.  
These application-specific routing requirement documents will be used  
for protocol design.

Does that clarify ?

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Mon, 16 Feb 2009 13:25:08 +0100

waiting for an ACK from Thomas on the last thread before sending out  
the new revision.

---

From: Emmanuel Baccelli <[email-masked]>
Date: Mon, 16 Feb 2009 13:27:13 +0100

Yes, this point is clarified with the new text indeed.Emmanuel

On Mon, Feb 16, 2009 at 1:24 PM, JP Vasseur <[email-masked]> wrote:

> There will not be any new requirement in fact. I think that the confusion
> is coming from the fact that the old text used to say "The Working group
> will ... " thus I have updated for "The Working Group focusses ....". Here
> is the new text.
>
> There is a wide scope of application areas for LLNs, including  industrial
> monitoring, building automation (HVAC, lighting, access  control, fire),
> connected homes, healthcare, environmental monitoring,  urban sensor
> networks (e.g. Smart Grid), assets tracking.  The Working Group focuses on
> routing solutions for a subset of  these: industrial, connected home,
> building and urban  sensor networks for which routing requirements have been
> specified. These application-specific routing requirement documents will be
> used for protocol design.
>
> Does that clarify ?
>
> Thanks.
>
> JP.
>
>
> cheers
>
> Emmanuel

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 16 Feb 2009 13:25:55 +0100

Of charter? I thought that what you proposed sounded like a good  
step, but would like to see new revision with proposed changes.

Thomas

On Feb 16, 2009, at 1:25 PM, JP Vasseur wrote:

> waiting for an ACK from Thomas on the last thread before sending  
> out the new revision.
>

---

From: JP Vasseur <[email-masked]>
Date: Mon, 16 Feb 2009 13:30:15 +0100

Thanks.

On Feb 16, 2009, at 1:27 PM, Emmanuel Baccelli wrote:

> These application-specific routing requirement documents will be

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Feb 2009 14:31:19 +0100

Hi Daniel,

Daniel Smolinski a écrit :
> Hi Alex,
> 
> to me, lossy means that link communication can fail because of 
> natural influences to the transmission media. It makes no difference 
> if a wireless link fails because some item temporarily blocks the 
> path (or all paths) or if a powerline link fails if the line 
> impedance or noise spectrum changes for some time.
> 
>> Lossiness of PLC links could be avoided by setting them up 
>> properly, don't plug the microwave oven if the manufacturer says 
>> so.
> 
> powerline. The PLC technology itself must be able to handle these 
> issues, either by the robustness of the PHY layer, link layer 
> mechanisms or a combination of both. But, so should any technology, 
> and if it fails due to influences from the outside, it is lossy and 
> this needs to be considered in the routing.

I think the way we describe this lossiness characteristic begs for
solutions at PHY and MAC layers; dealing with it in a routing protocol
sounds to me as an overly stretched extension.

Adaptation to bandwidth variance happens at TCP level during an ongoing
exchange.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Feb 2009 14:40:02 +0100

JP Vasseur a écrit :
>>>> Thomas Heide Clausen a écrit : [...]
>>>>> I can see where Alexandru's question come from at this point,
>>>>> when we were talking about power-lines and such. Essentially,
>>>>> what we're wanting to say [I think] is that "ROLL protocols
>>>>> MUST be able to run on routers with 
>>>>> [very-strict-set-of-restrictions]" -- and that there then may
>>>>> be a few routers with "better than
>>>>> [very-strict-set-of-restrictions]" shouldn't be driving our
>>>>> design, and that such routers are present is purely
>>>>> incidental. IOW, I'd suggest rephrasing this slightly, to say
>>>>> "these are the requirements that ROLL protocols shall satisfy
>>>>> -- if a device does better than that, more power to it, but
>>>>> it's not our primary design target".
>>>> 
>>> Low power and Lossy networks (LLNs) are typically composed of
>>> many embedded devices with limited power, memory, and processing
>>> (Powerline Communication) links. LLNs are transitioning to an
>>> end-to-end IP-based solution to avoid the problem of
>>> non-interoperable networks interconnected by protocol translation
>>> gateways and proxies. LLNs have specific characteristics: -
>>> LLNs operate with a hard, very small bound on state, -       In
>>> most cases, LLN need to be optimized for energy saving, -
>>> Typical traffic patterns are not simply unicast flows, -       In
>>> most cases, LLNs need to be effective with very small packet
>>> sizes, -       LLN routing protocols have to be very careful when
>> Suggested text: " Low power and Lossy networks (LLNs) are typically
>> composed of many embedded devices with limited power, memory, and
>> processing resources interconnected by a variety of links, such as
>> IEEE 802.15.4, Bluetooth, Low Power WiFi or other low power links
>> [remove: PLC (Powerline Communication) links]. LLNs are
>> transitioning to an end-to-end IP-based solution to avoid the
>> problem of non-interoperable networks interconnected by protocol
>> translation gateways and proxies. LLNs have specific
>> characteristics: -       ... -       They are securely connected to
>> the Internet.
>> 
>> bandwidth/latency/range/emissionpower could be orders of magnitude
>> better, e.g. PLC devices. "
>> 
>> Would you agree with this PLC distinction and the explicit
>> statement of Internet connectivity?
>> 
> 
> Sorry but not sure what you mean ... 1) On Internet connectivity,
> some LLNs may not be connected to the Internet at all (not typical I
> agree).

At the very least limit, I would agree with saying "LLNs are 
intermitently connected to the Internet".

To deserve IETF consensus search, LLNs would be connected to the 
Internet at least from time to time.

Do you think ROLL protocol/extensions would only work in a network which 
is forbidden to connect to the Internet?

Alex

---

From: JP Vasseur <[email-masked]>
Date: Mon, 16 Feb 2009 15:16:41 +0100

Hi Alex,

As a follow up to our phone call to clarify a few things.

In line,

On Feb 16, 2009, at 2:40 PM, Alexandru Petrescu wrote:

>>>>>> MUST be able to run on routers with [very-strict-set-of- 
>>>>>> restrictions]" -- and that there then may
> Do you think ROLL protocol/extensions would only work in a network  
> which is forbidden to connect to the Internet?

Some LLNs may not be connected to the Internet, while this is  
certainly not the majority of the cases.
Thus let's stick with the proposed text.

As for the PLC, we keep the current text considering that low power  
PLC technologies are used in LLNs
and are both lossy and low power.

Thanks for commenting.

JP.

---

From: Philip Levis <[email-masked]>
Date: Mon, 16 Feb 2009 12:36:53 -0800

On Feb 16, 2009, at 2:13 AM, Alexandru Petrescu wrote:

>> from appliances (e.g. microwave ovens) can cause disturbances on  
>> the power line that makes communication impossible for some time.  
>> Also, many PLC links are asymmetrical.
>
>> While I agree that the low-power requirement can be seen either  
>> way, my experience tells me that PLC is definitely experiencing the  
>> same problems as do wireless networks.
>

In theory, I agree. Practice, however, has shown otherwise. For  
example, a link layer could detect that the SNR of a link X has  
dropped and so switches to a much lower bit rate. But a routing layer  
might, given the choice, rather use another link Y than X at this  
lower bit rate. Routing metrics are often tightly wound up with what  
decision the link layer makes. Super-intelligent link layers that try  
to do everything and mask this from higher layers generally lead to  
bad routes.

This does *not* mean that there needs to be some complex link/network  
layer interaction. Rather, it means that a routing protocol can't  
always assume that the link layer will work in its best interest, and  
so a specification should not preclude it from making quick and agile  
decisions.

Phil

---

From: "Childress, Steve" <[email-masked]>
Date: Mon, 16 Feb 2009 12:48:56 -0800

It would benefit the state of the art if we *finally* had a dynamic routing protocol standard that correctly employs link quality metrics. Wireless challenges are dynamic due to mobility and fleeting impairments (without mobility, there's little need for wireless).  This is not the instantaneous SNR, RSSI, or SINADR (alias LQI). It's a temporal metric of the correctable and uncorrectable FER (exclusive of coding/FEC) for the last x amount of time, for all messages sent by the currently favored neighbor node, irrespective of the destination MAC address.

There are several proprietary implementations of these principles.

steve childress

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Philip Levis
Sent: Monday, February 16, 2009 12:37 PM
To: Alexandru Petrescu
Cc: ROLL WG; David E. Culler; Daniel Smolinski
Subject: Re: [Roll] ROLL re-chartering

On Feb 16, 2009, at 2:13 AM, Alexandru Petrescu wrote:

>> power line that makes communication impossible for some time.
> devices plugged into a same wall socket.  But these are warnings 
> posted on red stickers telling how to properly set up a PLC network.
>
> It's true, wireless networks often seem non-deterministic in 
> behaviour, as wireless links do often.
>

In theory, I agree. Practice, however, has shown otherwise. For example, a link layer could detect that the SNR of a link X has dropped and so switches to a much lower bit rate. But a routing layer might, given the choice, rather use another link Y than X at this lower bit rate. Routing metrics are often tightly wound up with what decision the link layer makes. Super-intelligent link layers that try to do everything and mask this from higher layers generally lead to bad routes.

This does *not* mean that there needs to be some complex link/network layer interaction. Rather, it means that a routing protocol can't always assume that the link layer will work in its best interest, and so a specification should not preclude it from making quick and agile decisions.

Phil

---

From: Kris Pister <[email-masked]>
Date: Mon, 16 Feb 2009 14:02:03 -0800

Philip Levis wrote:
> layer interaction.
How about a really simple one ;)
> Rather, it means that a routing protocol can't always assume that the 
> link layer will work in its best interest, and so a specification 
> should not preclude it from making quick and agile decisions.
I agree with Phil.  The solution is not "magic PHY and/or MAC".  A good 
phy/mac can help, and some are better than others, but the laws of 
physics do not allow for a deterministic link-layer with low power 
radios.  That's one of the many challenges that make RoLL interesting.

ksjp

---

From: "Anders Brandt" <[email-masked]>
Date: Tue, 17 Feb 2009 15:01:13 +0100

I am happy with the proposed charter.

cheers,
  Anders

> Bluetooth, Low Power WiFi or other low power PLC (Powerline
Communication) links.
> the problem of non-interoperable networks interconnected by protocol 
> translation gateways and proxies. LLNs have specific characteristics:
packet
waste.
> not met by  existing routing protocols, such as OSPF, IS-IS, AODV and 
> OLSR. For example path selection must be designed to take into 
> consideration the specific power capabilities, attributes and 

> sensor networks and specify the set of routing requirements for  these

> scenarios.
> into consideration various  aspects including high reliability in the 
> presence of time varying loss  characteristics and connectivity while 
> permitting low-power operation  with very modest memory and CPU 
> pressure in networks potentially comprising a very large number 
> (several thousands) of nodes.

> and manageability (e.g., self configuration) issues. It will also need

> to  consider the transport characteristic the routing protocol 
> congestion collapse or  that establish some degree of fairness between

> concurrent communication sessions are out of scope of the Working 
> Group. It is expected that  upper-layer applications utilizing LLNs
define appropriate mechanisms.
> includes static and dynamic link/node attributes required for routing 
> in LLNs.
> 
> 
> 

> approach,  along with various trade-offs for maintaining low power 
> operation,  including the presence of non-trivial loss and networks 
> with a very  large number of nodes.
> 
> 
IESG
> July 2009    Submit Routing metrics for LLNs document to the IESG to
be
> Dec 2009     Submit the ROLL routing protocol specification to the
IESG