Re: [Roll] proposed amendments to ROLL charter
Ines Robles <mariainesrobles@googlemail.com> Mon, 06 April 2015 10:26 UTC
Return-Path: <mariainesrobles@googlemail.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 5B9481A86DD for <roll@ietfa.amsl.com>; Mon, 6 Apr 2015 03:26:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level:
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 pXT3c2t6FWn3 for <roll@ietfa.amsl.com>; Mon, 6 Apr 2015 03:26:31 -0700 (PDT)
Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (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 DE8DD1A8034 for <roll@ietf.org>; Mon, 6 Apr 2015 03:26:30 -0700 (PDT)
Received: by lagv1 with SMTP id v1so16951463lag.3 for <roll@ietf.org>; Mon, 06 Apr 2015 03:26:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6VadsWpDdqnCtC33rw8ExeodrHNpGwzfhAq6P1K3Esc=; b=wuErv3hdv3xiLATnwkJzlIgtVjVFeO4B1sMZ6rGUdGEsj0kqPPT0RkcBJnMLBpLigz nOZHPbEzNQMMrzUi321FHHWfAc+Fwiy/cDP3INGNb/DbKkEXmoSx0TU11Ah994C6PplG w2vSHRizKtnjjlvarswsxo0Rmir+Zl2weSSCpQCpszAiaWxp5JByuQX4bT0Y3oZiTvxe GqfzEWt+Kw2v6Kz3ZC8G2aZmdMcxu5+zEajI+rw0fJEpKsQaY3MEDuSc37n3jj39WDVU DiUr2Q1CfwQJNmFXNqKioTGZpcw7/G9hHQxxMAU+62wXjGwr3GwVowIF0TLAfTlzsdg/ WcHg==
MIME-Version: 1.0
X-Received: by 10.112.8.101 with SMTP id q5mr13109697lba.19.1428315989297; Mon, 06 Apr 2015 03:26:29 -0700 (PDT)
Received: by 10.25.89.4 with HTTP; Mon, 6 Apr 2015 03:26:29 -0700 (PDT)
In-Reply-To: <E045AECD98228444A58C61C200AE1BD849D98770@xmb-rcd-x01.cisco.com>
References: <30526.1427136071@sandelman.ca> <E045AECD98228444A58C61C200AE1BD849D918D7@xmb-rcd-x01.cisco.com> <CAP+sJUf4QMXXzZ4Dj7rB5J95idDdCBo5AQDXV2kuo_okfCRMSw@mail.gmail.com> <E045AECD98228444A58C61C200AE1BD849D98770@xmb-rcd-x01.cisco.com>
Date: Mon, 06 Apr 2015 13:26:29 +0300
Message-ID: <CAP+sJUcmy-f3vhtgCH_wV4HJaJo9EJxYUo32_uG4_e0gw7vjqg@mail.gmail.com>
From: Ines Robles <mariainesrobles@googlemail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary="001a1134df962b511105130bbb12"
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/-SEGMb1oWsvyYnNtvFD2JbGM0_Y>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>
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, 06 Apr 2015 10:26:35 -0000
Hi, Ticket #169 [http://trac.tools.ietf.org/wg/roll/trac/ticket/169] was created to tack these items. Thank you, Michael and Ines. 2015-04-02 18:59 GMT+03:00 Pascal Thubert (pthubert) <pthubert@cisco.com>: > A few other things I’d like to see, Ines: > > > > - One is a MOP based on BIER and/or Bloom filters, which is a way to > compress BIER with a chance of false positive. Carsten has a draft that > details the use of Bloom filters for source routing, but really both BIER > and Bloom can apply to either storing and non-storing. > > - Work on mixed storing and non-storing, and all sort of optimization for > the storing mode. I’m aware of feasible solutions in that space that really > should be shared and made available to all. > > - Work on additional capabilities that we did not initially include in the > spec: > > - The capability to kill a route from the root, e.g. if a DAO state is > installed and should be cleaned up, e.g. if the root realizes that the node > is no more there or there is a duplication or what-else. > > - The capability to trigger a DAO from the root if a target is expected to > be present in the network but there is no DAO state (maybe to save > resources) > > - The capability to request the triggering of a new iteration of a DODAG > from a RPL node or a controlling element. > > > > Thanks for asking J > > > > Pascal > > > > *From:* Roll [mailto:roll-bounces@ietf.org] *On Behalf Of *Ines Robles > *Sent:* mardi 31 mars 2015 16:10 > *To:* Routing Over Low power and Lossy networks > *Cc:* Michael Richardson > *Subject:* Re: [Roll] proposed amendments to ROLL charter > > > > 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) <pthubert@cisco.com>: > > 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 > > > > -----Original Message----- > > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Michael > Richardson > > Sent: lundi 23 mars 2015 19:41 > > 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/ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > >
- [Roll] proposed amendments to ROLL charter Michael Richardson
- Re: [Roll] proposed amendments to ROLL charter Thomas Watteyne
- Re: [Roll] proposed amendments to ROLL charter Turner, Randy
- Re: [Roll] proposed amendments to ROLL charter Michael Richardson
- Re: [Roll] proposed amendments to ROLL charter Xavier Vilajosana
- Re: [Roll] proposed amendments to ROLL charter Timothy L. Hirou
- Re: [Roll] proposed amendments to ROLL charter Pascal Thubert (pthubert)
- Re: [Roll] proposed amendments to ROLL charter Michael Richardson
- Re: [Roll] proposed amendments to ROLL charter Michael Richardson
- Re: [Roll] proposed amendments to ROLL charter Michael Richardson
- Re: [Roll] proposed amendments to ROLL charter Kerry Lynn
- Re: [Roll] proposed amendments to ROLL charter Robert Cragie
- Re: [Roll] proposed amendments to ROLL charter Thomas Watteyne
- Re: [Roll] proposed amendments to ROLL charter Robert Cragie
- Re: [Roll] proposed amendments to ROLL charter Pascal Thubert (pthubert)
- Re: [Roll] proposed amendments to ROLL charter Ines Robles
- Re: [Roll] proposed amendments to ROLL charter Alvaro Retana (aretana)
- Re: [Roll] proposed amendments to ROLL charter Pascal Thubert (pthubert)
- Re: [Roll] proposed amendments to ROLL charter Turner, Randy
- Re: [Roll] proposed amendments to ROLL charter Pascal Thubert (pthubert)
- Re: [Roll] proposed amendments to ROLL charter Ines Robles
- Re: [Roll] proposed amendments to ROLL charter Ines Robles