Re: [Roll] proposed amendments to ROLL charter

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 25 March 2015 00:35 UTC

Return-Path: <mcr@sandelman.ca>
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 6419A1A1B20 for <roll@ietfa.amsl.com>; Tue, 24 Mar 2015 17:35:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 nYIZiUGQRVYi for <roll@ietfa.amsl.com>; Tue, 24 Mar 2015 17:35:41 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97FBF1A1B3D for <roll@ietf.org>; Tue, 24 Mar 2015 17:35:41 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D8160203B2 for <roll@ietf.org>; Tue, 24 Mar 2015 20:45:32 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 9DFFE63B76; Tue, 24 Mar 2015 20:35:40 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 84C61636A2 for <roll@ietf.org>; Tue, 24 Mar 2015 20:35:40 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
to: roll@ietf.org
In-Reply-To: <30526.1427136071@sandelman.ca>
References: <30526.1427136071@sandelman.ca>
X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Tue, 24 Mar 2015 20:35:40 -0400
Message-ID: <10807.1427243740@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/Nl8ZVx4AHdbj1fGBgJ2AWSHbrUM>
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: Wed, 25 Mar 2015 00:35:44 -0000

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.

-- 
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

====

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 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:

     - 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.5 2015/03/25 00:34:00 mcr Exp mcr $