[Roll] Request for Comments for ROLL Charter - version 5

Ines Robles <mariainesrobles@googlemail.com> Sun, 17 July 2016 14:07 UTC

Return-Path: <mariainesrobles@googlemail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BABD12B051 for <roll@ietfa.amsl.com>; Sun, 17 Jul 2016 07:07:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.689
X-Spam-Level:
X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com
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 58YICjktlDzM for <roll@ietfa.amsl.com>; Sun, 17 Jul 2016 07:07:49 -0700 (PDT)
Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 616AE12D0E7 for <roll@ietf.org>; Sun, 17 Jul 2016 07:07:48 -0700 (PDT)
Received: by mail-vk0-x22f.google.com with SMTP id s189so1397103vkh.1 for <roll@ietf.org>; Sun, 17 Jul 2016 07:07:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=y/XHAtdpvRGvw3xvEiI3Ge2TYSl4w3ssGW/ZjxK7fUw=; b=sf9iwel3pnO1my0wv8W2o0lujXsEQOfSwywx3xSwWtrFktPqAqCMTOgJu8MqFqYSXN OGCcFlsQaFTpWozSB9RB19XxcpKpykWYsZJ4eEyj0reiXU8ej2vxqu0Ss6jHpA6xZQlW BlPcvGDF7/RybYgN9UhacPXml8P94vKYw8MTayncGYc24PAbuAKmu6/1/oziKRPTiqMZ r5BZx5KuJLv833BNiaMxSltrh51UuhMWmIEUPeXKqpvO/NySf3hcXaUpSxBJB3+B2jwj Nu95skJUYJoTksAvrze7lRpKRV2B8J+Fc29QIDBG3v4fP5gV3uY20eyUQF8bTI6g7q2D A2KQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=y/XHAtdpvRGvw3xvEiI3Ge2TYSl4w3ssGW/ZjxK7fUw=; b=VFl58yGANzirIXmTmcKMoXhWLF8MAlcOwORbsbicidxT/Y2hFaaKHaHBD5pCZfx36i jBLHg+U3oX2u35fwW0/obPTiptYO5frDi4XyBKseztJ6Yo8z2rMI67uCXhzZyLXhf3VO HaN7o8SynrYvZQV+3O61aiB6w13C88cRMJpCZ5XyUUN1NW4Fk5l/rKVwaZWyqii/lquI qBvMHdb1zb405mJrYTneAB6LYpoWQyg5PlaWuL5oLL9bVR5ASVP6k7y3uNwidW7EDzen CZlzFhHU/xGUhjYq2LSq4Hw1WjSIeb3AWu6BdKuODw324+qaQ6gCPeS8SlIBlvWhTFty K3WA==
X-Gm-Message-State: ALyK8tJZz0ZdyDaYPKR16jXVBAuT7FltTQY+9RaTayEG5+7zTu+ha3AfPXNlsye8b3pVwgue3Tcq+JkHD8Bxjg==
X-Received: by 10.176.0.108 with SMTP id 99mr15247718uai.71.1468764467067; Sun, 17 Jul 2016 07:07:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.36.241 with HTTP; Sun, 17 Jul 2016 07:07:46 -0700 (PDT)
From: Ines Robles <mariainesrobles@googlemail.com>
Date: Sun, 17 Jul 2016 17:07:46 +0300
Message-ID: <CAP+sJUdwVYeMEU9SuNTJYtg=PSF1aujeS5q=zzkfNrLZamin-Q@mail.gmail.com>
To: roll <roll@ietf.org>
Content-Type: multipart/alternative; boundary=001a113f2ba0517ff50537d560ce
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/8Jg4YU_MFw55YlN26BgW1OnI7Lc>
Subject: [Roll] Request for Comments for ROLL Charter - version 5
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 17 Jul 2016 14:07:52 -0000

Dear all,

Please find a new version of the charter. Thanks to Michael  for the
suggestions.

Last changes:

A-

Old: "Alternative Multicast algorithm based on Bier forwarding.."

New: " Alternative Multicast algorithm such as Bier forwarding."

Comments are welcome.

Thank you,

Peter and Ines

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

CHARTER PROPOSAL:

Charter for Working Group

Low power and Lossy Networks (LLNs ) [RFC7102] [RFC7228] 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 are characterized as follows, but not limited to:

LLNs operate with a hard, very small bound on state.

In most cases, LLN optimize for saving energy by using small packet headers
and reduce amount of control packets.

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 and low bit rates, 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; since 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 (draft-levis-roll-overview-protocols-00) and
have in their current form been found to not satisfy all of these specific
routing requirements “Routing Requirements for Urban Low-Power and Lossy
Networks” RFC 5548, “Industrial Routing Requirements in Low-Power and Lossy
Networks” RFC 5673, “Home Automation Routing Requirements in Low-Power and
Lossy Networks” RFC 5826, Building Automation Routing Requirements in
Low-Power and Lossy Networks RFC 5867.

The Working Group is focused on routing issues for LLN and maintaining the
protocols developed by the working group.


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

The Working Group focuses 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 document how data packets are routed and
encapsulated when they cross the LLN, and when they enter and exit the LLN:
the appropriate use of RPI (RFC6553), RH3 (RFC6554) and IPv6-in-IPv6
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 into a single block. The WGLC on this work will be shared
with 6lo.


ROLL will coordinate closely with the working groups in other areas that
focus on constrained node networks, such as 6lo (Internet) and CoRE (APP).The
Working group will align with the 6man WG when needed.


ROLL is responsible for maintenance of the protocols that is has developed,
including RPL and MPL.


Work Items are:

- Guidance in using RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation.

- Compression of  RFC6553, RFC6554, and IP headers in the 6LoWPAN
adaptation layer context. (co-ordinated with 6lo WG).

- Additional protocol elements to reduce packet size and the amount of
required routing states

- Automatic selection of MPL forwarders to reduce message replication

- Data models for RPL and MPL management

- Alternative Multicast algorithm such as Bier forwarding.

- Methods to improve or correct  the current RPL behaviour and the other
protocols defined by the working group.


Milestones

DATE                            Milestone

September 2017            Recharter WG or close

March 2017           Initial submission of draft about YANG RPL model to
IESG

January 2017         Initial submission of draft about MPL selection to IESG

November 2016        Initial submission of draft about Bier Multicast to
IESG

October 2016         Submit draft about YANG MPL model to IESG

August 2016          Initial Submission of the draft about when to use
RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation Draft-ietf-roll-useofrplinfo
to the IESG.

May 2016             Initial submission of the draft about how to compress
RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation layer context.
 to the IESG. draft-ietf-roll-routing-dispatch
November 2016        Initial Submission of the No-Path DAO Problem
Statement to the IESG



2016-07-13 9:56 GMT+03:00 Ines Robles <mariainesrobles@googlemail.com>;:

> Dear all,
>
> Please find a new version of the charter. Thanks to Samita for the
> suggestions.
>
> Last changes:
>
> A-
>
> Old: "The Working group will align with the 6man WG when needed."
>
> New: " ROLL will coordinate closely with the working groups in other areas
> that focus on constrained node networks, such as 6lo (Internet) and CoRE
> (APP).The Working group will align with the 6man WG when needed."
>
> B-
>
> Old: " Compression of  RFC6553, RFC6554, and IP headers in the 6LoWPAN
> adaptation layer context"
>
> New: " Compression of  RFC6553, RFC6554, and IP headers in the 6LoWPAN
> adaptation layer context" (co-ordinated with 6lo WG).
>
>
> Comments are welcome.
>
> Thank you,
>
> Peter and Ines
>
>
> ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
>
> CHARTER PROPOSAL:
>
> Charter for Working Group
>
> Low power and Lossy Networks (LLNs ) [RFC7102] [RFC7228] 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 are characterized as follows, but not limited to:
>
> LLNs operate with a hard, very small bound on state.
>
> In most cases, LLN optimize for saving energy by using small packet
> headers and reduce amount of control packets.
>
> 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 and low bit rates, 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; since 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 (draft-levis-roll-overview-protocols-00) and
> have in their current form been found to not satisfy all of these specific
> routing requirements “Routing Requirements for Urban Low-Power and Lossy
> Networks” RFC 5548, “Industrial Routing Requirements in Low-Power and Lossy
> Networks” RFC 5673, “Home Automation Routing Requirements in Low-Power and
> Lossy Networks” RFC 5826, Building Automation Routing Requirements in
> Low-Power and Lossy Networks RFC 5867.
>
> The Working Group is focused on routing issues for LLN and maintaining the
> protocols developed by the working group.
>
>
> There is a wide scope of application areas for LLNs, including industrial
> monitoring, building automation (HVAC, lighting, access control, fire),
> connected homes, health care, environmental monitoring, urban sensor
> networks (e.g. Smart Grid), asset tracking. The Working Group focuses on
> routing solutions for a subset of these: connected home, building and urban
> sensor networks for which routing requirements have been specified. These
> application-specific routing requirement documents were used for protocol
> design.
>
> The Working Group focuses 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 document how data packets are routed and
> encapsulated when they cross the LLN, and when they enter and exit the LLN:
> the appropriate use of RPI (RFC6553), RH3 (RFC6554) and IPv6-in-IPv6
> 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 into a single block. The WGLC on this work will be shared
> with 6lo.
>
>
> ROLL will coordinate closely with the working groups in other areas that
> focus on constrained node networks, such as 6lo (Internet) and CoRE (APP).The
> Working group will align with the 6man WG when needed.
>
>
> ROLL is responsible for maintenance of the protocols that is has
> developed, including RPL and MPL.
>
>
> Work Items are:
>
> - Guidance in using RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation.
>
> - Compression of  RFC6553, RFC6554, and IP headers in the 6LoWPAN
> adaptation layer context. (co-ordinated with 6lo WG).
>
> - Additional protocol elements to reduce packet size and the amount of
> required routing states
>
> - Automatic selection of MPL forwarders to reduce message replication
>
> - Data models for RPL and MPL management
>
> - Alternative Multicast algorithm based on Bier forwarding.
>
> - Methods to improve or correct  the current RPL behaviour and the other
> protocols defined by the working group.
>
>
> Milestones
>
> DATE                            Milestone
>
> September 2017            Recharter WG or close
>
> March 2017           Initial submission of draft about YANG RPL model to
> IESG
>
> January 2017         Initial submission of draft about MPL selection to
> IESG
>
> November 2016        Initial submission of draft about Bier Multicast to
> IESG
>
> October 2016         Submit draft about YANG MPL model to IESG
>
> August 2016          Initial Submission of the draft about when to use
> RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation
> Draft-ietf-roll-useofrplinfo to the IESG.
>
> May 2016             Initial submission of the draft about how to compress
> RFC6553, RFC6554, and IP headers in the 6LoWPAN adaptation layer context.
>  to the IESG. draft-ietf-roll-routing-dispatch
> November 2016        Initial Submission of the No-Path DAO Problem
> Statement to the IESG
>