Re: [Roll] proposed amendments to ROLL charter

"Timothy L. Hirou" <thirou@CONVERGENCEWIRELESS.COM> Mon, 23 March 2015 20:50 UTC

Return-Path: <thirou@CONVERGENCEWIRELESS.COM>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CA91B2A39 for <roll@ietfa.amsl.com>; Mon, 23 Mar 2015 13:50:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcfMfds4DWZE for <roll@ietfa.amsl.com>; Mon, 23 Mar 2015 13:50:31 -0700 (PDT)
Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.202]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 594CA1B2A16 for <roll@ietf.org>; Mon, 23 Mar 2015 13:50:31 -0700 (PDT)
Received: from [216.82.242.115] by server-10.bemta-8.messagelabs.com id E6/B6-07114-69C70155; Mon, 23 Mar 2015 20:50:30 +0000
X-Env-Sender: thirou@CONVERGENCEWIRELESS.COM
X-Msg-Ref: server-14.tower-132.messagelabs.com!1427143827!17350374!5
X-Originating-IP: [199.119.192.75]
X-StarScan-Received:
X-StarScan-Version: 6.13.4; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31263 invoked from network); 23 Mar 2015 20:50:29 -0000
Received: from out001.apptixemail.net (HELO out001.apptixemail.net) (199.119.192.75) by server-14.tower-132.messagelabs.com with AES128-SHA encrypted SMTP; 23 Mar 2015 20:50:29 -0000
Received: from AUSP01DAG0302.collaborationhost.net ([169.254.2.167]) by AUSP01MHUB15.collaborationhost.net ([10.2.68.87]) with mapi id 14.03.0195.001; Mon, 23 Mar 2015 15:49:52 -0500
From: "Timothy L. Hirou" <thirou@CONVERGENCEWIRELESS.COM>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] proposed amendments to ROLL charter
Thread-Index: AQHQZZj07GCLgU7o+kuoG9EPv7wjD50qiozA
Date: Mon, 23 Mar 2015 20:49:51 +0000
Message-ID: <BAE02773F003614585890698831DC50F010A98C1@AUSP01DAG0302.collaborationhost.net>
References: <30526.1427136071@sandelman.ca>
In-Reply-To: <30526.1427136071@sandelman.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [72.211.210.18]
Content-Type: text/plain; charset="windows-1255"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/tpsNl5lWhQ0iTVCM5AU_TZlpup4>
Subject: Re: [Roll] proposed amendments to ROLL charter
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2015 20:50:36 -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
thirou@convergencewireless.com
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:roll-bounces@ietf.org] On Behalf Of Michael Richardson
Sent: Monday, March 23, 2015 11:41 AM
To: roll@ietf.org
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:
 - 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 <mcr+IETF@sandelman.ca>, Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/