Subject: [Roll] proposed amendments to ROLL charter

From: Michael Richardson <[email-masked]>
Date: Mon, 23 Mar 2015 14:41:11 -0400

The following changes are proposed for the ROLL charter to include the work
to profile 6553/6554/IPIP, and to compress it.

To the pre-amble:

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

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

After: 
 The solution must include unicast and multicast considerations.

Add:
+The Working Group will document how non-control packets are routed when they
+cross the LLN, and when they enter and exit the LLN: the appropriate use of
+RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how routing
+loops are detected. In consultation with the 6lo WG, the Working Group will
+design a method to these routing headers into a single block.  The result
+will have a shared WGLC with 6lo.

To  Work Items, add:
+     - A document detailing when to use RFC6553, RFC6554 and IPIP
+       encapsulation.
+
+     - A document detailing how to compress RFC6553, RFC6554 and IP headers
+       in the 6lowPAN HC context.

The resulting charter (after reformatting of some of the ugly text wrapping
on the web site) is:

----
Low power and Lossy networks (LLNs) are made up of many
embedded devices with limited power, memory, and processing
resources. They are interconnected by a variety of links, such as
IEEE 802.15.4, Bluetooth, Low Power WiFi, wired 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.

Generally speaking, LLNs have at least five distinguishing
characteristics:
- LLNs operate with a hard, very small bound on state.
- In most cases, LLN optimize for saving energy.
- Typical traffic patterns are not simply unicast flows (e.g. in some cases most if not all traffic can be point to multipoint).
- In most cases, LLNs will be employed over link layers with restricted
  frame-sizes, thus a routing protocol for LLNs should be specifically
  adapted for such link layers.
- LLN routing protocols have to be very careful when trading off efficiency
  for generality; many LLN nodes do not have resources to waste.

These specific properties cause LLNs to have specific routing
requirements.

Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been
evaluated by the working group and have in their current form been found to
not satisfy all of these specific routing requirements.

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 homes, healthcare, environmental monitoring, urban sensor networks
(e.g. Smart Grid), asset 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.

The Working Group focuses only on IPv6 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 pay particular attention to routing security and
manageability (e.g., self routing 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. 

The solution must include unicast and multicast considerations.

The Working Group will document how non-control packets are routed when they
cross the LLN, and when they enter and exit the LLN: the appropriate use of
RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how routing
loops are detected. In consultation with the 6lo WG, the Working Group will
design a method to these routing headers into a single block.  The result
will have a shared WGLC with 6lo.

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 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: The Working Group will consider specific routing
       requirements from the four application documents collectively, and
       specify either a new protocol or extend an existing routing protocol
       in cooperation with the relevant Working Group.
       If requirements from the four target application areas cannot be met
       with a single protocol, the WG may choose to specify or extend more than
       one protocol (this will require a recharter of the WG).

     - Documentation of applicability statement of ROLL routing protocols.

     - A document detailing when to use RFC6553, RFC6554 and IPIP
       encapsulation.

     - A document detailing how to compress RFC6553, RFC6554 and IP headers
       in the 6lowPAN HC context.

$Id: charter.txt,v 1.3 2015/03/23 18:33:38 mcr Exp $

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 23 Mar 2015 13:43:45 -0500

+1 on adding these items to ROLL charter.

Editorial: "IP-in-IP encapsulation" might clearer than IPIP (your choice,
not a strong opinion)

On Mon, Mar 23, 2015 at 1:41 PM, Michael Richardson <[email-masked]>
wrote:

> - Typical traffic patterns are not simply unicast flows (e.g. in some
> cases most if not all traffic can be point to multipoint).
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>
>

---

From: "Turner, Randy" <[email-masked]>
Date: Mon, 23 Mar 2015 18:50:47 +0000

+1 on detailing when/why/how ip-in-ip tunnels should be used in, out, through LLNs

R.

From: Thomas Watteyne <[email-masked]<mailto:[email-masked]>>
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 23, 2015 at 2:43 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Roll] proposed amendments to ROLL charter

Editorial: "IP-in-IP encapsulation" might clearer than IPIP (your choice, not a strong opinion)

On Mon, Mar 23, 2015 at 1:41 PM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

To the pre-amble:

After:

Add:

After:

Add:

To  Work Items, add:

----

Work Items:

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

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

P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 23 Mar 2015 15:40:50 -0400

> choice, not a strong opinion)

Done.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Xavier Vilajosana <[email-masked]>
Date: Mon, 23 Mar 2015 21:10:22 +0100

I am in favor to add this items to the ROLL Charter. This is absolutely
needed.
regards,
Xavi

---

From: "Timothy L. Hirou" <[email-masked]>
Date: Mon, 23 Mar 2015 20:49:51 +0000

I agree with this proposal.

Best Regards,
Timothy L. Hirou
President & CEO
Convergence Wireless, Inc.
3334 E. Coast Highway
Corona Del Mar, CA 92625
(800) 519-9820 Office
(949) 444-1723 Cell
(949) 258-5592 Fax
[email-masked]
www.convergencewireless.com‎

Privileged And Confidential Communication This electronic transmission, and any documents attached hereto, (a) are protected by the Electronic Communications privacy Act (18 USC §§ 2510- 2521),(b)may contain confidential and or legally privileged information , and (c) are for the sole use of the intended recipient(s) named above.  If you have received this electronic message in error, please notify the sender and delete the electronic message and destroy any physical copies of the information that may have been generated. Any disclosure, copying, distribution, or use of the contents of the information received in error is strictly prohibited. 

-----Original Message-----
From: Roll [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Monday, March 23, 2015 11:41 AM
To: [email-masked]
Subject: [Roll] proposed amendments to ROLL charter

The following changes are proposed for the ROLL charter to include the work to profile 6553/6554/IPIP, and to compress it.

To the pre-amble:

After:

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

After: 

Add:
+The Working Group will document how non-control packets are routed when 
+they cross the LLN, and when they enter and exit the LLN: the 
+appropriate use of
+RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how 
+routing loops are detected. In consultation with the 6lo WG, the 
+Working Group will design a method to these routing headers into a 
+single block.  The result will have a shared WGLC with 6lo.

To  Work Items, add:

The resulting charter (after reformatting of some of the ugly text wrapping on the web site) is:

----
Low power and Lossy networks (LLNs) are made up of many embedded devices with limited power, memory, and processing resources. They are interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired 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.

These specific properties cause LLNs to have specific routing requirements.

Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been evaluated by the working group and have in their current form been found to not satisfy all of these specific routing requirements.

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), asset 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.

The Working Group focuses only on IPv6 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 pay particular attention to routing security and manageability (e.g., self routing 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. 

The Working Group will document how non-control packets are routed when they cross the LLN, and when they enter and exit the LLN: the appropriate use of
RH3 (RFC6553), RPI (RFC6554) and IPIP encapsulation including how routing loops are detected. In consultation with the 6lo WG, the Working Group will design a method to these routing headers into a single block.  The result will have a shared WGLC with 6lo.

Work Items:

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 25 Mar 2015 00:10:34 +0000

All in favor. 

Do I understand that the 6loRH draft should become a ROLL document after 6lo
approval of the dispatch method, then?

Cheers,

Pascal

> Sent: lundi 23 mars 2015 12:41
> To: [email-masked]
> The following changes are proposed for the ROLL charter to include the
work to
> profile 6553/6554/IPIP, and to compress it.
> 
> To the pre-amble:
> 
> After:
> The resulting charter (after reformatting of some of the ugly text
wrapping on
> the web site) is:
> 
> ----
> Low power and Lossy networks (LLNs) are made up of many embedded devices
> with limited power, memory, and processing resources. They are
interconnected
> by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi,
wired 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.
> 
cases most if
> not all traffic can be point to multipoint).
requirements.
> connected homes, healthcare, environmental monitoring, urban sensor
> networks (e.g. Smart Grid), asset 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.
> 
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 document how non-control packets are routed when
> they cross the LLN, and when they enter and exit the LLN: the appropriate
use of
> design a method to these routing headers into a single block.  The result
will
> have a shared WGLC with 6lo.
> 
> Work Items:
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Mar 2015 20:35:40 -0400

There are two additional minor typos to deal with:

-design a method to these routing headers into a single block.  The result
-will have a shared WGLC with 6lo.

+design a method to compress these routing headers.  The result will have a
+shared WGLC with 6lo.

The charter discussion will remain open until March 30. This will put it
on the telechat for April 9.

====

The Working Group will document how non-control packets are routed when they
cross the LLN, and when they enter and exit the LLN: the appropriate use of
RH3 (RFC6553), RPI (RFC6554) and IP-in-IP encapsulation including how routing
loops are detected. In consultation with the 6lo WG, the Working Group will
design a method to compress these routing headers.  The result will have a
shared WGLC with 6lo.

Work Items:

$Id: charter.txt,v 1.5 2015/03/25 00:34:00 mcr Exp mcr $

---

From: Michael Richardson <[email-masked]>
Date: Wed, 25 Mar 2015 11:36:16 -0400

> approval of the dispatch method, then?

6loRH can become a ROLL document.
During the WG process of that document, 6lo will recommend on what the
dispatch mechanism/values will be....   We can't hit WGLC without 6lo
approval, but I don't think we need to do it sequentially.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Mar 2015 17:28:08 -0400

Michael Richardson <[email-masked]> wrote:
    > The charter discussion will remain open until March 30. This will put
    > it on the telechat for April 9.

Last change to say something + or - about this charter update.

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 30 Mar 2015 21:57:51 -0400

On Mon, Mar 30, 2015 at 5:28 PM, Michael Richardson <[email-masked]>
wrote:

> +1 (after the typo fixes)

Kerry

--

---

From: Robert Cragie <[email-masked]>
Date: Tue, 31 Mar 2015 08:42:23 +0100

Hope I'm not too late...

I support the charter update. Just a couple of suggestions:

* Change "IPv6-in-IPv6 encapsulation" to "IPIP encapsulation" as also 
suggested by Thomas. AFAICT "IPIP" is not widely used and when it is, it 
refers more to IPv4.
* Change "in the 6lowpan HC context" to "in the 6LoWPAN adaptation layer 
context". This generalises it to include dispatch-based solutions as 
well, otherwise it could be read as only looking at NHC-based variants.

Robert

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 31 Mar 2015 09:45:29 +0200

Robert,

Change "IPv6-in-IPv6 encapsulation" to "IPIP encapsulation"

Do you mean the reverse?

Thomas

On Tue, Mar 31, 2015 at 9:42 AM, Robert Cragie <[email-masked]>
wrote:

> context". This generalises it to include dispatch-based solutions as well,
> otherwise it could be read as only looking at NHC-based variants.
>
> Robert
>
>
> Michael Richardson <[email-masked]> <[email-masked]> wrote:
> Roll mailing [email-masked]://www.ietf.org/mailman/listinfo/roll
>
>
>

---

From: Robert Cragie <[email-masked]>
Date: Tue, 31 Mar 2015 10:05:28 +0100

Er yes, apologies for the poor editing!

Robert

On 31/03/2015 08:45, Thomas Watteyne wrote:
> On Tue, Mar 31, 2015 at 9:42 AM, Robert Cragie 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hope I'm not too late...
>
>     * Change "IPv6-in-IPv6 encapsulation" to "IPIP encapsulation" as
>     also suggested by Thomas. AFAICT "IPIP" is not widely used and
>     when it is, it refers more to IPv4.
>     * Change "in the 6lowpan HC context" to "in the 6LoWPAN adaptation
>     layer context". This generalises it to include dispatch-based
>     solutions as well, otherwise it could be read as only looking at
>     NHC-based variants.
>
>     Robert
>
>
>>     Michael Richardson<[email-masked]>  <mailto:[email-masked]>  wrote:
>>     [email-masked]  <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 31 Mar 2015 10:49:53 +0000

Hello Michael (and all):

I fully support the additions. Since you are at it, I would like to explore a deeper realignment.

ROLL is now in charge of the maintenance of RPL, isn't it? 
- I think that this should be a work item in the charter. 
- this should replace elements that were or are being delivered such as metrics, security, and RPL itself

And if that's so, wouldn't it make sense to study how RPL works outside LLNs and in mixed environments? 
- I'd like to see work on RPL over foo where foo is Ethernet or Wi-Fi. Applicability of RPL in various environments outside LLN would be of interest, e.g. to build a Wi-Fi mesh or an unmanaged network. It seems that a DT will form at HOMENET to select a routing protocol, and an applicability statement of RPL for that case would be a good read if we can produce it in time.
- From our experience of actually doing RPL over Ethernet, it is mostly a matter of *not* using the packet artifacts, probably not using the stretch in local repair, and reacting immediately to changes in link state. This is a very small spec indeed, mostly guidance on what to use and what not to use from RFC 6550, how to tune some parameters, which OF to use and how. 
- The work should also detail the mode where there is a backbone and a virtual root. I think that the current charter does not cover work outside LLN but considering that we are the group that knows RPL best, that work should happen here.

What do you think?

Pascal

> Sent: lundi 23 mars 2015 19:41
> To: [email-masked]
> The following changes are proposed for the ROLL charter to include the work to
> with limited power, memory, and processing resources. They are interconnected
> by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or
> other low power PLC (Powerline Communication) links. LLNs are transitioning to
> - Typical traffic patterns are not simply unicast flows (e.g. in some cases most if
> routing solutions for a subset of these: industrial, connected home, building and
> these application scenarios. The Framework will take into consideration various
> characteristics and connectivity while permitting low-power operation with very
> they cross the LLN, and when they enter and exit the LLN: the appropriate use of
> design a method to these routing headers into a single block.  The result will

---

From: Ines Robles <[email-masked]>
Date: Tue, 31 Mar 2015 17:10:02 +0300

Hi Pascal,

Thank you very much for your comments, we are going to include them in our
meeting.

To all, There are additional topics that you would like to include in the
charter? Please justify.

Thank you very much,

Michael and Ines

2015-03-31 13:49 GMT+03:00 Pascal Thubert (pthubert) <[email-masked]>:

> - I'd like to see work on RPL over foo where foo is Ethernet or Wi-Fi.
> Applicability of RPL in various environments outside LLN would be of
> interest, e.g. to build a Wi-Fi mesh or an unmanaged network. It seems that
> a DT will form at HOMENET to select a routing protocol, and an
> applicability statement of RPL for that case would be a good read if we can
> produce it in time.
> - From our experience of actually doing RPL over Ethernet, it is mostly a
> matter of *not* using the packet artifacts, probably not using the stretch
> in local repair, and reacting immediately to changes in link state. This is
> a very small spec indeed, mostly guidance on what to use and what not to
> use from RFC 6550, how to tune some parameters, which OF to use and how.
> - The work should also detail the mode where there is a backbone and a
> virtual root. I think that the current charter does not cover work outside
> LLN but considering that we are the group that knows RPL best, that work
> should happen here.
>
> What do you think?
>
> Pascal
>
>

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 31 Mar 2015 18:27:35 +0000

On 3/31/15, 6:49 AM, "Pascal Thubert (pthubert)" <[email-masked]>
wrote:

Pascal:

Hi!

>It seems that a DT will form at HOMENET to select a routing protocol, and
>an applicability statement of RPL for that case would be a good read if
>we can produce it in time.

Just a quick comment..  The deliverable for the homenet DT is ³by July
2015², which I¹m interpreting as ³we want to discuss in Prague².  The
document that you¹re proposing for the DT doesn¹t need to be a WG item or
even chartered for you (individually) to make it happen.

Alvaro.