Re: [Roll] Request for Comments for ROLL Charter - version 4
Michael Richardson <mcr+ietf@sandelman.ca> Sun, 17 July 2016 13:55 UTC
Return-Path: <mcr+ietf@sandelman.ca>
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 10CF212D16D for <roll@ietfa.amsl.com>; Sun, 17 Jul 2016 06:55:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.188
X-Spam-Level:
X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 WBfxeA9jkrNJ for <roll@ietfa.amsl.com>; Sun, 17 Jul 2016 06:55:31 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5F3712D0C4 for <roll@ietf.org>; Sun, 17 Jul 2016 06:55:30 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A05912015D for <roll@ietf.org>; Sun, 17 Jul 2016 10:04:50 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 81CB3638D1 for <roll@ietf.org>; Sun, 17 Jul 2016 09:55:29 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
In-Reply-To: <CAP+sJUcanyVSeogSGTemndd1k_QiBQkKK7arjQL6jO-rO=5+Bw@mail.gmail.com>
References: <CAP+sJUcanyVSeogSGTemndd1k_QiBQkKK7arjQL6jO-rO=5+Bw@mail.gmail.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
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: Sun, 17 Jul 2016 09:55:29 -0400
Message-ID: <3597.1468763729@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/W9F8AMPqZwps78oVlcBRm8o19sI>
Subject: Re: [Roll] Request for Comments for ROLL Charter - version 4
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 13:55:33 -0000
I have read the charter, and I do not find anything more to tweak. I would prefer to cut some of the history out, or move it to the end, but I recognize that this may have value to new comers. Do we presently have people willing to contribute to a YANG model? Ines Robles <mariainesrobles@googlemail.com> wrote: > 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. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- Re: [Roll] Request for Comments for ROLL Charter … Michael Richardson
- [Roll] Request for Comments for ROLL Charter - ve… Ines Robles