From wwwrun@core3.amsl.com Wed Mar 4 07:39:27 2009 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 4A1C43A6CD4; Wed, 4 Mar 2009 07:39:26 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090304153927.4A1C43A6CD4@core3.amsl.com> Date: Wed, 4 Mar 2009 07:39:27 -0800 (PST) Cc: roll@ietf.org, culler@eecs.berkeley.edu Subject: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 15:39:27 -0000 A modified charter has been submitted for the Routing Over Low power and Lossy networks working group in the Routing Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. Routing Over Low power and Lossy networks (roll) ================================================== Last Modified: 2009-02-04 Current Status: Active Working Group Additional information is available at tools.ietf.org/wg/roll Chair(s): JP Vasseur David Culler Routing Area Director(s): Ross Callon David Ward Routing Area Advisor: David Ward Mailing Lists: General Discussion: roll@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/roll Archive: http://www.ietf.org/mail-archive/web/roll/ Description of Working Group: 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. As shown in a protocol survey existing routing protocols (in their current form) such as OSPF, IS-IS, AODV, and OLSR, do not meet 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. 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: In light of the application specific routing requirements, the Working Group will either specify a new protocol and/or will select an existing routing protocol (with the appropriate extensions in cooperation with the relevant Working Group). - Documentation of applicability statement of ROLL routing protocols. Goals and Milestones: Done Submit Routing requirements for Industrial applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Connected Home networks applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Building applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Urban networks applications to the IESG to be considered as an Informational RFC. July 2009 Submit Routing metrics for LLNs document to the IESG to be considered as a Proposed Standard. Feb 2009 Submit Protocol Survey to the IESG to be considered as an Informational RFC. April 2009 Submit Security Framework to the IESG to be considered as an Informational RFC May 2009 Submit the Routing for LLNs Architecture document to the IESG as an Informational RFC. July 2009 Submit first draft of ROLL routing protocol specification as Proposed Standard. Nov 2009 Submit first draft of the MIB module of the ROLL routing protocol specification. Feb 2010 Submit the ROLL routing protocol specification to the IESG as Proposed Standard. March 2010 Submit the MIB module of the ROLL routing protocol specification to the IESG as Proposed Standard. April 2010 Evaluate WG progress, recharter or close. From arsalan.tavakoli@gmail.com Wed Mar 4 16:45:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86B9728C3B4 for ; Wed, 4 Mar 2009 16:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzR4P4YFX7We for ; Wed, 4 Mar 2009 16:45:42 -0800 (PST) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id 2838028C3A3 for ; Wed, 4 Mar 2009 16:45:42 -0800 (PST) Received: by ewy25 with SMTP id 25so2872871ewy.37 for ; Wed, 04 Mar 2009 16:46:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=TbzynKnEL3VYOlkfDsQUYwyYoTy8VU+7LYWrx60Ri/M=; b=qjvAPg2Vm7es2OitiN9uHLtVmJDEPhMZuCMu8k9q7kEPF44XC6IZ6T2zZOCk3hcMUr vTCFrk+XGVRaWiUHrNWGUZQXkq68E1VjPybfS94vGTBuwZNEqAE2dsb/Lgh+1n3RsNjK A+Sxv9R/RodaibUkKRSW8yLDPZBgge0yevYN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=wUnlV4IVATXRFkmplm+MpXb2v4hP4jg0Ua3hIydxaJ4OZVVqQvoScW6VBtFi0FjsAk THUnEZRWnit/s6/yPHHPVwLQDrdrgHcY4HoJjKRtBaoScl4WB40OiATQqoUcw2M44sKc 0CbP8uNl+GvMR6TfFby4XsFX1Pknx8XFHlJMU= MIME-Version: 1.0 Sender: arsalan.tavakoli@gmail.com Received: by 10.210.141.17 with SMTP id o17mr367805ebd.46.1236213970100; Wed, 04 Mar 2009 16:46:10 -0800 (PST) Date: Wed, 4 Mar 2009 16:46:10 -0800 X-Google-Sender-Auth: 55e011d6d6a70866 Message-ID: <69306dde0903041646n7a1871d4u5c4faeab93978786@mail.gmail.com> From: Arsalan Tavakoli To: roll@ietf.org Content-Type: multipart/alternative; boundary=0015174bf0f88de49b0464547e49 Subject: [Roll] draft-tavakoli-hydro-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 00:45:43 -0000 --0015174bf0f88de49b0464547e49 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit http://www.ietf.org/internet-drafts/draft-tavakoli-hydro-00.txt This is the draft of a new protocol specification for a routing protocol for L2Ns that we thought members of this working group might find interesting. Any comments/feedback/questions would be highly appreciated, and we will attempt to incorporate those we receive before Monday (cutoff date for IETF documents) into a -01 version of the draft. Thanks in advance, Arsalan ----------------------------------------------------- A new version of I-D, draft-tavakoli-hydro-00.txt has been successfuly submitted by Arsalan Tavakoli and posted to the IETF repository. Filename: draft-tavakoli-hydro Revision: 00 Title: HYDRO: A Hybrid Routing Protocol for Lossy and Low Power Networks Creation_date: 2009-03-04 WG ID: Independent Submission Number_of_pages: 27 Abstract: HYDRO is a hybrid routing protocol for Lossy and Low power Networks (L2Ns) that embraces centralized and distributed routing mechanisms. Through the use of standard ICMP Route Advertisements and Route Solicitations, Node Routers build Default Routes to Border Routers. These routes, which maintain multiple options per each Node Router when available, are maintained through data-driven link estimation. Node Routers periodically report a high-quality subset of their Default Route Table to Border Routers, which then form a global view of the topology. When a Node Router attempts to route to another Node Router in the network, if no matching entry exists in the Node Router's Flow Table, it forwards the packet to a Border Router, which then installs the correct Flow Table Entries in the network to enable more efficient subsequent routing. --0015174bf0f88de49b0464547e49 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

This is the draft of a new protoco= l specification for a routing protocol for L2Ns that we thought members of = this working group might find interesting. =A0Any comments/feedback/questio= ns would be highly appreciated, and we will attempt to incorporate those we= receive before Monday (cutoff date for IETF documents) into a -01 version = of the draft.

Thanks in advance,
Arsalan

-----------------------------------------------------

A new version of I-D, draft-tavakoli-hydro-00.txt= has been successfuly submitted by Arsalan Tavakoli and posted to the IETF = repository.

Filename: =A0 =A0 =A0 =A0draft-tavakoli-hydro
Revision: =A0 =A0 =A0 = =A000
Title: =A0 =A0 =A0 =A0 =A0 HYDRO: A Hybrid Routing Protocol for Lo= ssy and Low Power Networks
Creation_date: =A0 2009-03-04
WG ID: =A0 = =A0 =A0 =A0 =A0 Independent Submission
Number_of_pages: 27

Abstract:
HYDRO is a hybrid routing protocol = for Lossy and Low power Networks
(L2Ns) that embraces centralized and di= stributed routing mechanisms.
Through the use of standard ICMP Route Adv= ertisements and Route
Solicitations, Node Routers build Default Routes to Border Routers.
Thes= e routes, which maintain multiple options per each Node Router
when avai= lable, are maintained through data-driven link estimation.
Node Routers = periodically report a high-quality subset of their
Default Route Table to Border Routers, which then form a global view
of = the topology. =A0When a Node Router attempts to route to another
Node Ro= uter in the network, if no matching entry exists in the Node
Router'= s Flow Table, it forwards the packet to a Border Router, which
then installs the correct Flow Table Entries in the network to enable
mo= re efficient subsequent routing.
--0015174bf0f88de49b0464547e49-- From dokaspar.ietf@gmail.com Thu Mar 5 00:02:38 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E0C028C144 for ; Thu, 5 Mar 2009 00:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peHxyAkafGRj for ; Thu, 5 Mar 2009 00:02:37 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id 2598128C11E for ; Thu, 5 Mar 2009 00:02:37 -0800 (PST) Received: by gxk22 with SMTP id 22so7239472gxk.13 for ; Thu, 05 Mar 2009 00:03:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=aMyvXPbWLk8ddIbSUjw9RGruDOvshTVEhskMihh54mE=; b=ny/e1Q9e7zBHpqc7+MMSkiCQY1hXsUFa1/ueuyQk0L1bzkwaWAvsUW8FkNeOfOktzR H1/RfPIeraotWHaYIS313/BXb7cG3syS3GuyaRoTiUsHcMcPuu0vGG2TCu4knMAu83w6 iNxoUqoViNZ2Z8zcwGZiL0kqXx0cvV0k4Nli0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=amxLNL9OjvjaLuwdb+TyTnMwzbfT5v0KH2ZFZQhzh4T7dAVpF+QaAhLbWplzbV+RrD kh9ltQJySnE/D2eC1uoUOeEuob3flmHmeNbiqnn1Hyr6DR2P4lzhwA6xDCWYhz+EBynt 1EpNhZOVTaP8NUEh1eBOYePOPLcgWvgMu+3ic= MIME-Version: 1.0 Received: by 10.220.92.21 with SMTP id p21mr264560vcm.47.1236240185976; Thu, 05 Mar 2009 00:03:05 -0800 (PST) In-Reply-To: <69306dde0903041646n7a1871d4u5c4faeab93978786@mail.gmail.com> References: <69306dde0903041646n7a1871d4u5c4faeab93978786@mail.gmail.com> Date: Thu, 5 Mar 2009 09:03:05 +0100 Message-ID: <2a3692de0903050003g1c183908t784406e5f223a389@mail.gmail.com> From: Dominik Kaspar To: Arsalan Tavakoli Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] draft-tavakoli-hydro-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 08:02:38 -0000 Hello. Can the posting of this protocol specification be interpreted as the strategical decision to ignore existing protocols (MANET) and move ahead with ROLL's own solution? Regards, Dominik On Thu, Mar 5, 2009 at 1:46 AM, Arsalan Tavakoli wrote: > http://www.ietf.org/internet-drafts/draft-tavakoli-hydro-00.txt > > This is the draft of a new protocol specification for a routing protocol = for > L2Ns that we thought members of this working group might find interesting= . > =A0Any comments/feedback/questions would be highly appreciated, and we wi= ll > attempt to incorporate those we receive before Monday (cutoff date for IE= TF > documents) into a -01 version of the draft. > Thanks in advance, > Arsalan > ----------------------------------------------------- > A new version of I-D, draft-tavakoli-hydro-00.txt has been successfuly > submitted by Arsalan Tavakoli and posted to the IETF repository. > > Filename: =A0 =A0 =A0 =A0draft-tavakoli-hydro > Revision: =A0 =A0 =A0 =A000 > Title: =A0 =A0 =A0 =A0 =A0 HYDRO: A Hybrid Routing Protocol for Lossy and= Low Power > Networks > Creation_date: =A0 2009-03-04 > WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission > Number_of_pages: 27 > > Abstract: > HYDRO is a hybrid routing protocol for Lossy and Low power Networks > (L2Ns) that embraces centralized and distributed routing mechanisms. > Through the use of standard ICMP Route Advertisements and Route > Solicitations, Node Routers build Default Routes to Border Routers. > These routes, which maintain multiple options per each Node Router > when available, are maintained through data-driven link estimation. > Node Routers periodically report a high-quality subset of their > Default Route Table to Border Routers, which then form a global view > of the topology. =A0When a Node Router attempts to route to another > Node Router in the network, if no matching entry exists in the Node > Router's Flow Table, it forwards the packet to a Border Router, which > then installs the correct Flow Table Entries in the network to enable > more efficient subsequent routing. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > From jvasseur@cisco.com Thu Mar 5 02:14:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCBA028C3D2 for ; Thu, 5 Mar 2009 02:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.452 X-Spam-Level: X-Spam-Status: No, score=-10.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftpRyCQxTzl8 for ; Thu, 5 Mar 2009 02:14:53 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7D9AC28C36B for ; Thu, 5 Mar 2009 02:14:52 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,305,1233532800"; d="scan'208";a="35422187" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 05 Mar 2009 10:15:19 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n25AFJAq019751; Thu, 5 Mar 2009 11:15:19 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n25AFJUd010248; Thu, 5 Mar 2009 10:15:19 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Mar 2009 11:15:18 +0100 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Mar 2009 11:15:17 +0100 Message-Id: From: JP Vasseur To: Dominik Kaspar In-Reply-To: <2a3692de0903050003g1c183908t784406e5f223a389@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 5 Mar 2009 11:15:17 +0100 References: <69306dde0903041646n7a1871d4u5c4faeab93978786@mail.gmail.com> <2a3692de0903050003g1c183908t784406e5f223a389@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 05 Mar 2009 10:15:18.0057 (UTC) FILETIME=[488DF190:01C99D7B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2712; t=1236248119; x=1237112119; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20draft-tavakoli-hydro-00.txt |Sender:=20; bh=nFugTG85o9PGuFhYwA8OdBgIPWimMbmLVtezL6wltC4=; b=m3o7fTMSTxAtQlPrfciB3s69UVt8iFZA3SmUM7GHllHUqLVTbhIWjmOZyZ xxQiZOQDpSx3Mc0D41fCdsRyOJFjI0aroLHlxd6ZCxWjd3Sh/RgGOdeaGZwW 24Pep6BqOF; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] draft-tavakoli-hydro-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 10:14:53 -0000 Hi, On Mar 5, 2009, at 9:03 AM, Dominik Kaspar wrote: > Hello. > > Can the posting of this protocol specification be interpreted as the > strategical decision to ignore existing protocols (MANET) and move > ahead with ROLL's own solution? > Not at all. There will be multiple candidates for sure, extensions to MANET can be candidates of course, as mentioned MANY times on the list. Thanks. JP. > Regards, > Dominik > > On Thu, Mar 5, 2009 at 1:46 AM, Arsalan Tavakoli > wrote: >> http://www.ietf.org/internet-drafts/draft-tavakoli-hydro-00.txt >> >> This is the draft of a new protocol specification for a routing >> protocol for >> L2Ns that we thought members of this working group might find >> interesting. >> Any comments/feedback/questions would be highly appreciated, and >> we will >> attempt to incorporate those we receive before Monday (cutoff date >> for IETF >> documents) into a -01 version of the draft. >> Thanks in advance, >> Arsalan >> ----------------------------------------------------- >> A new version of I-D, draft-tavakoli-hydro-00.txt has been >> successfuly >> submitted by Arsalan Tavakoli and posted to the IETF repository. >> >> Filename: draft-tavakoli-hydro >> Revision: 00 >> Title: HYDRO: A Hybrid Routing Protocol for Lossy and Low >> Power >> Networks >> Creation_date: 2009-03-04 >> WG ID: Independent Submission >> Number_of_pages: 27 >> >> Abstract: >> HYDRO is a hybrid routing protocol for Lossy and Low power Networks >> (L2Ns) that embraces centralized and distributed routing mechanisms. >> Through the use of standard ICMP Route Advertisements and Route >> Solicitations, Node Routers build Default Routes to Border Routers. >> These routes, which maintain multiple options per each Node Router >> when available, are maintained through data-driven link estimation. >> Node Routers periodically report a high-quality subset of their >> Default Route Table to Border Routers, which then form a global view >> of the topology. When a Node Router attempts to route to another >> Node Router in the network, if no matching entry exists in the Node >> Router's Flow Table, it forwards the packet to a Border Router, which >> then installs the correct Flow Table Entries in the network to enable >> more efficient subsequent routing. >> >> _______________________________________________ >> 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 From alexandru.petrescu@gmail.com Thu Mar 5 02:40:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51D1528C121 for ; Thu, 5 Mar 2009 02:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nE4tManoNIAw for ; Thu, 5 Mar 2009 02:40:46 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 26F5D28C45C for ; Thu, 5 Mar 2009 02:40:45 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n25AexvB006286; Thu, 5 Mar 2009 11:40:59 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n25Aexob026317; Thu, 5 Mar 2009 11:40:59 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n25AewGX032742; Thu, 5 Mar 2009 11:40:59 +0100 Message-ID: <49AFAC3A.3010009@gmail.com> Date: Thu, 05 Mar 2009 11:40:58 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: JP Vasseur References: <69306dde0903041646n7a1871d4u5c4faeab93978786@mail.gmail.com> <2a3692de0903050003g1c183908t784406e5f223a389@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] draft-tavakoli-hydro-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 10:40:47 -0000 JP Vasseur a écrit : > Hi, > > On Mar 5, 2009, at 9:03 AM, Dominik Kaspar wrote: > >> Hello. >> >> Can the posting of this protocol specification be interpreted as >> the strategical decision to ignore existing protocols (MANET) and >> move ahead with ROLL's own solution? >> > > Not at all. There will be multiple candidates for sure, extensions to > MANET can be candidates of course, as mentioned MANY times on the > list. Which addressing model are you guys planning to use? Alex > > Thanks. > > JP. > > >> Regards, Dominik >> >> On Thu, Mar 5, 2009 at 1:46 AM, Arsalan Tavakoli >> wrote: >>> http://www.ietf.org/internet-drafts/draft-tavakoli-hydro-00.txt >>> >>> This is the draft of a new protocol specification for a routing >>> protocol for L2Ns that we thought members of this working group >>> might find interesting. Any comments/feedback/questions would be >>> highly appreciated, and we will attempt to incorporate those we >>> receive before Monday (cutoff date for IETF documents) into a -01 >>> version of the draft. Thanks in advance, Arsalan >>> ----------------------------------------------------- A new >>> version of I-D, draft-tavakoli-hydro-00.txt has been successfuly >>> submitted by Arsalan Tavakoli and posted to the IETF repository. >>> >>> Filename: draft-tavakoli-hydro Revision: 00 Title: >>> HYDRO: A Hybrid Routing Protocol for Lossy and Low Power Networks >>> Creation_date: 2009-03-04 WG ID: Independent >>> Submission Number_of_pages: 27 >>> >>> Abstract: HYDRO is a hybrid routing protocol for Lossy and Low >>> power Networks (L2Ns) that embraces centralized and distributed >>> routing mechanisms. Through the use of standard ICMP Route >>> Advertisements and Route Solicitations, Node Routers build >>> Default Routes to Border Routers. These routes, which maintain >>> multiple options per each Node Router when available, are >>> maintained through data-driven link estimation. Node Routers >>> periodically report a high-quality subset of their Default Route >>> Table to Border Routers, which then form a global view of the >>> topology. When a Node Router attempts to route to another Node >>> Router in the network, if no matching entry exists in the Node >>> Router's Flow Table, it forwards the packet to a Border Router, >>> which then installs the correct Flow Table Entries in the network >>> to enable more efficient subsequent routing. >>> >>> _______________________________________________ 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 mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Thu Mar 5 02:52:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC4D63A6AC9; Thu, 5 Mar 2009 02:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYrQ8SsE6DtW; Thu, 5 Mar 2009 02:52:28 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id E28F93A67AC; Thu, 5 Mar 2009 02:52:27 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n25Ap7CZ019930; Thu, 5 Mar 2009 11:51:07 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n25AqrN8012167; Thu, 5 Mar 2009 11:52:53 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n25AqqSw022769; Thu, 5 Mar 2009 11:52:53 +0100 Message-ID: <49AFAF04.5090303@gmail.com> Date: Thu, 05 Mar 2009 11:52:52 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: iesg@ietf.org References: <20090304153927.4A1C43A6CD4@core3.amsl.com> In-Reply-To: <20090304153927.4A1C43A6CD4@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org, culler@eecs.berkeley.edu Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 10:52:29 -0000 IESG Secretary a écrit : [...] > - Protocol work: In light of the application specific routing > requirements, the Working Group will either specify a new protocol > and/or will select an existing routing protocol (with the appropriate > extensions in cooperation with the relevant Working Group). This is too unclear for a Charter: specify new? or select existing? The world is not short of routing protocols in general, and routing protocols in particular for these types of dynamic wireless networks. MANET - OLSR TBRPF DYMO, NEMO - many RO drafts - all come to mind. Alex > > - Documentation of applicability statement of ROLL routing protocols. > > > Goals and Milestones: > > Done Submit Routing requirements for Industrial applications to the > IESG to be considered as an Informational RFC. > > Done Submit Routing requirements for Connected Home networks > applications to the IESG to be considered as an Informational RFC. > > Done Submit Routing requirements for Building applications to the > IESG to be considered as an Informational RFC. > > Done Submit Routing requirements for Urban networks applications to > the IESG to be considered as an Informational RFC. > > July 2009 Submit Routing metrics for LLNs document to the IESG to be > considered as a Proposed Standard. > > Feb 2009 Submit Protocol Survey to the IESG to be considered as an > Informational RFC. > > April 2009 Submit Security Framework to the IESG to be considered as > an Informational RFC > > May 2009 Submit the Routing for LLNs Architecture document to the > IESG as an Informational RFC. > > July 2009 Submit first draft of ROLL routing protocol specification > as Proposed Standard. > > Nov 2009 Submit first draft of the MIB module of the ROLL routing > protocol specification. > > Feb 2010 Submit the ROLL routing protocol specification to the IESG > as Proposed Standard. > > March 2010 Submit the MIB module of the ROLL routing protocol > specification to the IESG as Proposed Standard. > > April 2010 Evaluate WG progress, recharter or close. > > _______________________________________________ IETF-Announce mailing > list IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > From culler@eecs.berkeley.edu Thu Mar 5 07:39:44 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ADFE28C1A0 for ; Thu, 5 Mar 2009 07:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.141 X-Spam-Level: X-Spam-Status: No, score=-5.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YAOwUdzUKuW for ; Thu, 5 Mar 2009 07:39:43 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 66A8828C1B6 for ; Thu, 5 Mar 2009 07:39:43 -0800 (PST) Received: from [192.168.2.102] (64-142-4-199.dsl.static.sonic.net [64.142.4.199]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n25Fe3A7009391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Mar 2009 07:40:07 -0800 (PST) Message-ID: <49AFF248.5080801@eecs.berkeley.edu> Date: Thu, 05 Mar 2009 07:39:52 -0800 From: "David E. Culler" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dominik Kaspar References: <69306dde0903041646n7a1871d4u5c4faeab93978786@mail.gmail.com> <2a3692de0903050003g1c183908t784406e5f223a389@mail.gmail.com> In-Reply-To: <2a3692de0903050003g1c183908t784406e5f223a389@mail.gmail.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: roll@ietf.org, Arsalan Tavakoli Subject: Re: [Roll] draft-tavakoli-hydro-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 15:39:44 -0000 Dominik,
   Although seeing a question such as yours may tempt one to head down just such a path, alas, such political maneuvering is not what the IETF is for.  The IETF encourages individual submissions in order to further a process of informed discussion, rather than mere opinion and positioning. Only if there is willingness to focus on the challenges at hand can rough consensus and running code emerge.  Now that ROLL has gone to great pains and delay to examine such protocols it has begun the process of rechartering.  Once that is complete it will be possible to consider extensions to existing protocols, such as those previously proposed to address mobility in MANET.  Hopefully, individuals in MANET will have begun thinking about such protocols might possibly made to work in a context where resources are highly constrained and link loss is non-negligible. These are very different issues from dealing with a device moving out of range, so don't underestimate how much technical work there is to address even the stationary problem. 
   What submission of this draft does suggest is that at least some members of ROLL would like to have the opportunity to consider protocols other that those historically put forward by MANET.  There are many such protocols and a substantial body of implementation experience and empirical analysis.  Few of them have been cast into I-D form, so it is hard for the IETF to give them serious thought.
   I do hope that representatives of MANET will participate in such discussions regarding technical merit of options and alternatives.

D.


Dominik Kaspar wrote: 
Hello.

Can the posting of this protocol specification be interpreted as the
strategical decision to ignore existing protocols (MANET) and move
ahead with ROLL's own solution?

Regards,
Dominik

On Thu, Mar 5, 2009 at 1:46 AM, Arsalan Tavakoli
<arsalan@cs.berkeley.edu> wrote:
  
http://www.ietf.org/internet-drafts/draft-tavakoli-hydro-00.txt

This is the draft of a new protocol specification for a routing protocol for
L2Ns that we thought members of this working group might find interesting.
 Any comments/feedback/questions would be highly appreciated, and we will
attempt to incorporate those we receive before Monday (cutoff date for IETF
documents) into a -01 version of the draft.
Thanks in advance,
Arsalan
-----------------------------------------------------
A new version of I-D, draft-tavakoli-hydro-00.txt has been successfuly
submitted by Arsalan Tavakoli and posted to the IETF repository.

Filename:        draft-tavakoli-hydro
Revision:        00
Title:           HYDRO: A Hybrid Routing Protocol for Lossy and Low Power
Networks
Creation_date:   2009-03-04
WG ID:           Independent Submission
Number_of_pages: 27

Abstract:
HYDRO is a hybrid routing protocol for Lossy and Low power Networks
(L2Ns) that embraces centralized and distributed routing mechanisms.
Through the use of standard ICMP Route Advertisements and Route
Solicitations, Node Routers build Default Routes to Border Routers.
These routes, which maintain multiple options per each Node Router
when available, are maintained through data-driven link estimation.
Node Routers periodically report a high-quality subset of their
Default Route Table to Border Routers, which then form a global view
of the topology.  When a Node Router attempts to route to another
Node Router in the network, if no matching entry exists in the Node
Router's Flow Table, it forwards the packet to a Border Router, which
then installs the correct Flow Table Entries in the network to enable
more efficient subsequent routing.

_______________________________________________
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
From emmanuel.baccelli@gmail.com Thu Mar 5 08:53:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62D243A69F2; Thu, 5 Mar 2009 08:53:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIYy7eDZCcX0; Thu, 5 Mar 2009 08:53:56 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id 7135B28C0DD; Thu, 5 Mar 2009 08:53:55 -0800 (PST) Received: by fxm24 with SMTP id 24so15950fxm.37 for ; Thu, 05 Mar 2009 08:54:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=0/Z49OPF9AEmqw7dnqiHN3WvQvHGygX5HC6RpbrkQDA=; b=E7tFibFP9meOIkFbg//OJzoVy8wfcW6K+xAhyOGAlLcYenwfZ4FWfx8UErgofG2Bco GPsiVgsHL+QDaK3zZTT3OkTvXL6AYufnJ3FJYbuk3EBljGnBHEL3ajOufoDphCvVovBG TTXGfXLZnBDP5HB3jx8qmaFsCfIr+kMh7c+AU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=lmGBDcktPOjj4/pAKWaPDiKJG1fu8uAj9RESFOh+0e1r4aQaV9/bU9/PMKIvAzoUGO CvsdUwXDM7fPmlCymBHEFNsFHi7YvezxIwiVkkWlFp5SGylI16Sgh8LwMtJlS17F/4c8 LRI2u9gCp8IFTpSllb+eJAqjPHmPNkCt81bEc= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.103.214.13 with SMTP id r13mr641298muq.37.1236272064291; Thu, 05 Mar 2009 08:54:24 -0800 (PST) In-Reply-To: <20090304153927.4A1C43A6CD4@core3.amsl.com> References: <20090304153927.4A1C43A6CD4@core3.amsl.com> Date: Thu, 5 Mar 2009 17:54:24 +0100 X-Google-Sender-Auth: 72f3a7a34641966d Message-ID: From: Emmanuel Baccelli To: iesg@ietf.org Content-Type: multipart/alternative; boundary=001636a7d9123cea4d046462051a Cc: roll@ietf.org, culler@eecs.berkeley.edu, IETF Announcement list Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 16:53:58 -0000 --001636a7d9123cea4d046462051a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all, The ROLL WG targets to operate IP under constraints that are clearly harsher than usual within the IETF, similar only to extreme forms of network addressed by few WGs (such as MANET or 6LOWPAN). As far as I understand, the context in which ROLL aims to operate IP is: - extremely limited RAM - extremely limited CPU - extremely limited wireless bandwidth The typical deployment aimed at by ROLL is: - thousands of nodes - no assumptions on the topology The typical usage of such deployment includes: - unicast data flows from nodes to border routers - unicast data flows between nodes - multicast/flooding/?cast data flows from one node to other nodes The proposed charter yields a slew of work-items in this context, based on the above and on some of the applications requirements listed in the WG documents that are currently under IESG review. The exact set of targeted requirements are unfortunately not explicitly mentioned in the charter, nor in any other document. However, the work-items that are explicitly or implicitly evoked in the proposed charter, include the following: - self-configuration protocols in order to be "IP-ready" and "routing-ready", - unicast routing protocols, - multicast/flooding/?cast (to be defined) routing protocols, - multi-homing mechanisms/protocols, - elaboration of metrics for wireless links, - securing all of the above with additional mechanims/protocols, - doing all of the above with real-time constraints (to be defined) with additional mechanims/protocols, While this list is already impressive (especially within the currently proposed time-frame), it may not be exact or exhaustive, depending on which set of requirements are indeed targeted. For this reason, it seems to me that the highest priority is to clarify this point as soon as possible. And by this I mean document: - the precise list of requirements that are targeted within the proposed time-frame, - the precise list the operation conditions, deployment & usage scenarios that are being targeted within the proposed time-frame (the charter would benefit from some additional effort put into setting some limits for targeted RAM and CPU, as well as more precision concerning the targeted traffic patterns), - the precise list the work-items that are targeted within the proposed time-frame (here, for instance, the charter would benefit from some additional effort put into defining what multicast/flooding/?cast is, what real-time means for ROLL, and what additional work-item(s) they entails). As a ROLL participant, it is necessary and urgent for me to have these details in order to carry out further work on protocol design. Regards, Emmanuel On Wed, Mar 4, 2009 at 4:39 PM, IESG Secretary wrote: > A modified charter has been submitted for the Routing Over Low power and > Lossy networks working group in the Routing Area of the IETF. The IESG > has not made any determination as yet. The modified charter is provided > below for informational purposes only. Please send your comments to the > IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. > > Routing Over Low power and Lossy networks (roll) > ================================================== > Last Modified: 2009-02-04 > > Current Status: Active Working Group > > Additional information is available at tools.ietf.org/wg/roll > > Chair(s): > > JP Vasseur > David Culler > > Routing Area Director(s): > > Ross Callon > David Ward > > Routing Area Advisor: > David Ward > > Mailing Lists: > > General Discussion: roll@ietf.org > To Subscribe: http://www.ietf.org/mailman/listinfo/roll > Archive: http://www.ietf.org/mail-archive/web/roll/ > > Description of Working Group: > > 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. > As shown in a protocol survey existing routing protocols (in their current > > form) such as OSPF, IS-IS, AODV, and OLSR, do not meet 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. > > 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: In light of the application specific routing > requirements, the > Working Group will either specify a new protocol and/or will select an > existing > routing protocol (with the appropriate extensions in cooperation with > the > relevant Working Group). > > - Documentation of applicability statement of ROLL routing protocols. > > Goals and Milestones: > > Done Submit Routing requirements for Industrial applications to the IESG > to be considered as an Informational RFC. > > Done Submit Routing requirements for Connected Home networks applications > to the IESG to be considered as an Informational RFC. > > Done Submit Routing requirements for Building applications to the IESG to > be considered as an Informational RFC. > > Done Submit Routing requirements for Urban networks applications to the > IESG to be considered as an Informational RFC. > > July 2009 Submit Routing metrics for LLNs document to the IESG to be > considered as a Proposed Standard. > > Feb 2009 Submit Protocol Survey to the IESG to be considered as an > Informational RFC. > > April 2009 Submit Security Framework to the IESG to be considered as an > Informational RFC > > May 2009 Submit the Routing for LLNs Architecture document to the IESG > as an Informational RFC. > > July 2009 Submit first draft of ROLL routing protocol specification as > Proposed Standard. > > Nov 2009 Submit first draft of the MIB module of the ROLL routing > protocol specification. > > Feb 2010 Submit the ROLL routing protocol specification to the IESG as > Proposed Standard. > > March 2010 Submit the MIB module of the ROLL routing protocol > specification to the IESG as Proposed Standard. > > April 2010 Evaluate WG progress, recharter or close. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --001636a7d9123cea4d046462051a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

The=A0ROLL WG targets to operate IP under= constraints that=A0are clearly harsher than usual within the IETF, similar= only to extreme forms of network addressed by few WGs (such as MANET or 6L= OWPAN).

As far as I understand, the context in which ROLL aims = to operate IP is:

- extremely limited RAM
- extremely limited CPU
- extremely limited wireless bandwidth<= /div>

The typical deployment aimed at by ROLL is:
<= br>
- thousands of nodes
- no assumptions on the topolo= gy

The typical usage of such deployment includes:<= /div>

- unicast data flows from nodes to border routers
=
- unicast data flows between nodes
-=A0multicast/flooding/?c= ast data flows from one node to other nodes

The pr= oposed charter yields a slew of work-items in this context,
based on the above and on some of the applications requirements
<= div>listed in the WG documents that are currently under IESG review.
<= div>
The exact set of targeted requirements are unfortunately= not explicitly
mentioned in the=A0charter, nor in any other document. However,=A0
the work-items that=A0are explicitly or implicitly evoked in the pro= posed
charter, include the following:

- self-configuration protocols in order to be "IP-ready" and=A0&q= uot;routing-ready",
- unicast routing protocols,
=
- multicast/flooding/?cast (to be defined) routing protocols,
- multi-homing mechanisms/protocols,
- elaboration of metrics for= wireless links,
- securing all of the above with additional mech= anims/protocols,
- doing all of the above with real-time constrai= nts (to be defined) with additional=A0mechanims/protocols,


While this list is already impressive = =A0(especially within the currently proposed=A0time-frame),
it ma= y not be exact or exhaustive, depending on which set of=A0requirements are = indeed targeted.

For this reason, it seems to me that the highest priori= ty is to clarify this
point as soon as possible. And by this I me= an document:

- the precise list of requirements th= at are targeted within the proposed time-frame,

- the precise list the=A0operation conditions,=A0deploy= ment & usage scenarios that are being targeted=A0within the proposed ti= me-frame (the charter would benefit from some additional effort put into se= tting=A0some limits for targeted RAM and CPU, as well as more precision con= cerning the targeted traffic patterns),

- the precise list the work-items that are=A0targeted w= ithin the proposed time-frame (here, for instance, the charter would benefi= t from some additional effort put into defining what=A0multicast/flooding/?= cast is, what real-time means for ROLL, and what additional work-item(s) th= ey entails).


As a ROLL participant, it is necessary a= nd urgent for me to have these details in order to carry out further work o= n protocol design.


Regards,
Emmanuel







On = Wed, Mar 4, 2009 at 4:39 PM, IESG Secretary <iesg-secretary@ietf.org> = wrote:
A modified charter has been submitted for t= he Routing Over Low power and
Lossy networks working group in the Routing Area of the IETF. =A0The IESG has not made any determination as yet. =A0The modified charter is provided<= br> below for informational purposes only. =A0Please send your comments to the<= br> IESG mailing list (iesg@ietf.org) by W= ednesday, March 11, 2009.

Routing Over Low power and Lossy networks (roll)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
Last Modified: 2009-02-04

Current Status: Active Working Group

Additional information is available at tools.ietf.org/wg/roll

Chair(s):

JP Vasseur <jpv@cisco.com>
David Culler <culler@eecs.be= rkeley.edu>

Routing Area Director(s):

Ross Callon <rcallon@juniper.net<= /a>>
David Ward <dward@cisco.com>
Routing Area Advisor:
David Ward <dward@cisco.com>
Mailing Lists:

General Discussion: roll@ietf.org
To Subscribe: http://www.ietf.org/mailman/listinfo/roll
Archive: http://www.ietf.org/mail-archive/web/roll/

Description of Working Group:

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
=A0most if not all traffic can be point to multipoint).
- In most cases, LLNs will be employed over link layers with restricted
=A0frame-sizes, thus a routing protocol for LLNs should be specifically adapted
=A0for such link layers.
- LLN routing protocols have to be very careful when trading off
efficiency
=A0for generality; many LLN nodes do not have resources to waste.

These specific properties cause LLNs to have specific routing
requirements.
As shown in a protocol survey existing routing protocols (in their current<= br>
form) such as OSPF, IS-IS, AODV, and OLSR, do not meet 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<= br> loss
characteristics and connectivity while permitting low-power operation with<= br>
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<= br> 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.

Work Items:

- Specification of routing metrics used in path calculation. This
includes
=A0static and dynamic link/node attributes required for routing in LLNs.
- Provide an architectural framework for routing and path selection at
=A0Layer 3 (Routing for LLN Architecture) that addresses such issues as =A0whether LLN routing require a distributed and/or centralized path
computation
=A0models, whether additional hierarchy is necessary and how it is applied= .

=A0Manageability will be considered with each approach, along with various=

=A0trade-offs for maintaining low power operation, including the presence<= br>
=A0of non-trivial loss and networks with a very large number of nodes.

- Produce a routing security framework for routing in LLNs.

- Protocol work: In light of the application specific routing
requirements, the
=A0Working Group will either specify a new protocol and/or will select an<= br> existing
=A0routing protocol (with the appropriate extensions in cooperation with the
=A0relevant Working Group).

- Documentation of applicability statement of ROLL routing protocols.

Goals and Milestones:

Done Submit Routing requirements for Industrial applications to the IESG to be considered as an Informational RFC.

Done Submit Routing requirements for Connected Home networks applications to the IESG to be considered as an Informational RFC.

Done Submit Routing requirements for Building applications to the IESG to be considered as an Informational RFC.

Done Submit Routing requirements for Urban networks applications to the
IESG to be considered as an Informational RFC.

July 2009 Submit Routing metrics for LLNs document to the IESG to be
considered as a Proposed Standard.

Feb 2009 Submit Protocol Survey to the IESG to be considered as an
Informational RFC.

April 2009 Submit Security Framework to the IESG to be considered as an
Informational RFC

May 2009 =A0 Submit the Routing for LLNs Architecture document to the IESG<= br> as an Informational RFC.

July 2009 =A0Submit first draft of ROLL routing protocol specification as Proposed Standard.

Nov 2009 =A0 Submit first draft of the MIB module of the ROLL routing
protocol specification.

Feb 2010 =A0 Submit the ROLL routing protocol specification to the IESG as<= br> Proposed Standard.

March 2010 Submit the MIB module of the ROLL routing protocol
specification to the IESG as Proposed Standard.

April 2010 Evaluate WG progress, recharter or close.

_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

--001636a7d9123cea4d046462051a-- From dokaspar.ietf@gmail.com Thu Mar 5 09:13:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90EEB28C29E for ; Thu, 5 Mar 2009 09:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+zxcI1hOQyr for ; Thu, 5 Mar 2009 09:13:21 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id 5A7EC3A6979 for ; Thu, 5 Mar 2009 09:13:21 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so16931yxm.49 for ; Thu, 05 Mar 2009 09:13:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zVCHkJXMxbqdW8XplQ7Z43l01iv5+bLGBsveAWhCTv8=; b=FC2sUt7tpa93IACP3ctHCMwyKqtIeSdbXwQHGsQ/NRpc6OMaylDph7SxdCVxaiChoY qJHsf2z4AF/VShQPRe75W68sDUsbGXC9H5e1VE0ufQQMxUlnyjgtjzUZDhhhCtPqxeHa X6nla+Rg4Sow6rikjAM9pz+3jiq4etEdy93Dk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LF+b0EmwaTcpx1bl0meC2PkM/ZZKBrEUkpaTiDzbM4XayOxriClK/jfo4Yxze/UGFd AOeceQg7H02NPblxjAsNC/tN4yJR2vbcwFepuopcOFDx5lTaij5lGj0/WT+aPVDCgHU8 QglPWJE15Yg215S8PF/djwtylBp6XC1Loy+50= MIME-Version: 1.0 Received: by 10.220.95.202 with SMTP id e10mr440924vcn.12.1236273230489; Thu, 05 Mar 2009 09:13:50 -0800 (PST) In-Reply-To: <49AFF248.5080801@eecs.berkeley.edu> References: <69306dde0903041646n7a1871d4u5c4faeab93978786@mail.gmail.com> <2a3692de0903050003g1c183908t784406e5f223a389@mail.gmail.com> <49AFF248.5080801@eecs.berkeley.edu> Date: Thu, 5 Mar 2009 18:13:46 +0100 Message-ID: <2a3692de0903050913h1ba5813al49228a770606d74a@mail.gmail.com> From: Dominik Kaspar To: "David E. Culler" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org, Arsalan Tavakoli Subject: Re: [Roll] draft-tavakoli-hydro-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 17:13:22 -0000 Hi David, Thanks for the clarifications. I was not speaking from a MANET's point of view, but was just probing whether ROLL has now entered the "protocol design stage" or not. Anyway, the draft looks very interesting. Have there been research papers published with results from a real implementation of HYDRO? Best regards, Dominik On Thu, Mar 5, 2009 at 4:39 PM, David E. Culler wrote: > Dominik, > =A0=A0 Although seeing a question such as yours may tempt one to head dow= n just > such a path, alas, such political maneuvering is not what the IETF is for= . > The IETF encourages individual submissions in order to further a process = of > informed discussion, rather than mere opinion and positioning. Only if th= ere > is willingness to focus on the challenges at hand can rough consensus and > running code emerge.=A0 Now that ROLL has gone to great pains and delay t= o > examine such protocols it has begun the process of rechartering.=A0 Once = that > is complete it will be possible to consider extensions to existing > protocols, such as those previously proposed to address mobility in MANET= . > Hopefully, individuals in MANET will have begun thinking about such > protocols might possibly made to work in a context where resources are > highly constrained and link loss is non-negligible. These are very differ= ent > issues from dealing with a device moving out of range, so don't > underestimate how much technical work there is to address even the > stationary problem. > =A0=A0 What submission of this draft does suggest is that at least some m= embers > of ROLL would like to have the opportunity to consider protocols other th= at > those historically put forward by MANET.=A0 There are many such protocols= and > a substantial body of implementation experience and empirical analysis.= =A0 Few > of them have been cast into I-D form, so it is hard for the IETF to give > them serious thought. > =A0=A0 I do hope that representatives of MANET will participate in such > discussions regarding technical merit of options and alternatives. > > D. > > > Dominik Kaspar wrote: > > Hello. > > Can the posting of this protocol specification be interpreted as the > strategical decision to ignore existing protocols (MANET) and move > ahead with ROLL's own solution? > > Regards, > Dominik > > On Thu, Mar 5, 2009 at 1:46 AM, Arsalan Tavakoli > wrote: > > > http://www.ietf.org/internet-drafts/draft-tavakoli-hydro-00.txt > > This is the draft of a new protocol specification for a routing protocol = for > L2Ns that we thought members of this working group might find interesting= . > =A0Any comments/feedback/questions would be highly appreciated, and we wi= ll > attempt to incorporate those we receive before Monday (cutoff date for IE= TF > documents) into a -01 version of the draft. > Thanks in advance, > Arsalan > ----------------------------------------------------- > A new version of I-D, draft-tavakoli-hydro-00.txt has been successfuly > submitted by Arsalan Tavakoli and posted to the IETF repository. > > Filename: =A0 =A0 =A0 =A0draft-tavakoli-hydro > Revision: =A0 =A0 =A0 =A000 > Title: =A0 =A0 =A0 =A0 =A0 HYDRO: A Hybrid Routing Protocol for Lossy and= Low Power > Networks > Creation_date: =A0 2009-03-04 > WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission > Number_of_pages: 27 > > Abstract: > HYDRO is a hybrid routing protocol for Lossy and Low power Networks > (L2Ns) that embraces centralized and distributed routing mechanisms. > Through the use of standard ICMP Route Advertisements and Route > Solicitations, Node Routers build Default Routes to Border Routers. > These routes, which maintain multiple options per each Node Router > when available, are maintained through data-driven link estimation. > Node Routers periodically report a high-quality subset of their > Default Route Table to Border Routers, which then form a global view > of the topology. =A0When a Node Router attempts to route to another > Node Router in the network, if no matching entry exists in the Node > Router's Flow Table, it forwards the packet to a Border Router, which > then installs the correct Flow Table Entries in the network to enable > more efficient subsequent routing. > > _______________________________________________ > 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 > From jvasseur@cisco.com Thu Mar 5 09:24:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 851AD28C247; Thu, 5 Mar 2009 09:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.455 X-Spam-Level: X-Spam-Status: No, score=-10.455 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4-SI5fem34x; Thu, 5 Mar 2009 09:24:46 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id F058828C17F; Thu, 5 Mar 2009 09:24:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,308,1233532800"; d="scan'208,217";a="35479437" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 05 Mar 2009 17:25:13 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n25HPDE9008560; Thu, 5 Mar 2009 18:25:13 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n25HPD0h000151; Thu, 5 Mar 2009 17:25:13 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Mar 2009 18:25:13 +0100 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Mar 2009 18:25:12 +0100 Message-Id: From: JP Vasseur To: Emmanuel Baccelli In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-18-268673909 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 5 Mar 2009 18:25:11 +0100 References: <20090304153927.4A1C43A6CD4@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 05 Mar 2009 17:25:12.0409 (UTC) FILETIME=[572FB490:01C99DB7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=24650; t=1236273913; x=1237137913; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20WG=20Review=3A=20Recharter=20o f=20Routing=20Over=20Low=20power=20and=20Lossy=20=20networks =20(roll) |Sender:=20; bh=l0Uc3sSuYR+h7ggyvj43XtN5zinBSJm6FHSpeVaGHDM=; b=PxsnttBWUNEAp+7YgnE7s/ZJP/uYc10M87UmJCYS8AzkBQiaqUsHh25NVB db8KGNXtjAe3tYwCXS3tf77OZ9oyANJc9OBfWRwbf2imgO7kqIWLqo5p1WOH K/staTNJ7+; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG , "David E. Culler" , iesg@ietf.org, IETF Announcement list Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 17:24:53 -0000 --Apple-Mail-18-268673909 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Emmanuel, Thanks for your comments - see below. On Mar 5, 2009, at 5:54 PM, Emmanuel Baccelli wrote: > Hi all, > > The ROLL WG targets to operate IP under constraints that are clearly > harsher than usual within the IETF, similar only to extreme forms of > network addressed by few WGs (such as MANET or 6LOWPAN). > > As far as I understand, the context in which ROLL aims to operate IP > is: > > - extremely limited RAM > - extremely limited CPU > - extremely limited wireless bandwidth > > The typical deployment aimed at by ROLL is: > > - thousands of nodes > - no assumptions on the topology > > The typical usage of such deployment includes: > > - unicast data flows from nodes to border routers > - unicast data flows between nodes > - multicast/flooding/?cast data flows from one node to other nodes > > The proposed charter yields a slew of work-items in this context, > based on the above and on some of the applications requirements > listed in the WG documents that are currently under IESG review. > > The exact set of targeted requirements are unfortunately not > explicitly > mentioned in the charter, nor in any other document. However, > the work-items that are explicitly or implicitly evoked in the > proposed > charter, include the following: > > - self-configuration protocols in order to be "IP-ready" and > "routing-ready", > - unicast routing protocols, > - multicast/flooding/?cast (to be defined) routing protocols, > - multi-homing mechanisms/protocols, > - elaboration of metrics for wireless links, > - securing all of the above with additional mechanims/protocols, > - doing all of the above with real-time constraints (to be defined) > with additional mechanims/protocols, > > > While this list is already impressive (especially within the > currently proposed time-frame), > it may not be exact or exhaustive, depending on which set of > requirements are indeed targeted. > > For this reason, it seems to me that the highest priority is to > clarify this > point as soon as possible. And by this I mean document: > > - the precise list of requirements that are targeted within the > proposed time-frame, The WG has produced 4 very detailed routing requirements written experts in the field. I think that we now have all the requirements. > > - the precise list the operation conditions, deployment & usage > scenarios that are being targeted within the proposed time-frame > (the charter would benefit from some additional effort put into > setting some limits for targeted RAM and CPU, as well as more > precision concerning the targeted traffic patterns), Applicability statements is an excellent idea and I do agree with you. This is one of the new WG items: - Documentation of applicability statement of ROLL routing protocols. > > - the precise list the work-items that are targeted within the > proposed time-frame (here, for instance, the charter would benefit > from some additional effort put into defining what multicast/ > flooding/?cast is, what real-time means for ROLL, and what > additional work-item(s) they entails). > > > As a ROLL participant, it is necessary and urgent for me to have > these details in order to carry out further work on protocol design. > Please read the requirements documents, they provide a lot of data. Of course, more discussion will take place on the list as we move forward. Thanks. JP. > > Regards, > Emmanuel > > > > > > > > On Wed, Mar 4, 2009 at 4:39 PM, IESG Secretary > wrote: > A modified charter has been submitted for the Routing Over Low power > and > Lossy networks working group in the Routing Area of the IETF. The > IESG > has not made any determination as yet. The modified charter is > provided > below for informational purposes only. Please send your comments to > the > IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. > > Routing Over Low power and Lossy networks (roll) > ================================================== > Last Modified: 2009-02-04 > > Current Status: Active Working Group > > Additional information is available at tools.ietf.org/wg/roll > > Chair(s): > > JP Vasseur > David Culler > > Routing Area Director(s): > > Ross Callon > David Ward > > Routing Area Advisor: > David Ward > > Mailing Lists: > > General Discussion: roll@ietf.org > To Subscribe: http://www.ietf.org/mailman/listinfo/roll > Archive: http://www.ietf.org/mail-archive/web/roll/ > > Description of Working Group: > > 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. > As shown in a protocol survey existing routing protocols (in their > current > > form) such as OSPF, IS-IS, AODV, and OLSR, do not meet 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. > > 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: In light of the application specific routing > requirements, the > Working Group will either specify a new protocol and/or will select > an > existing > routing protocol (with the appropriate extensions in cooperation with > the > relevant Working Group). > > - Documentation of applicability statement of ROLL routing protocols. > > Goals and Milestones: > > Done Submit Routing requirements for Industrial applications to the > IESG > to be considered as an Informational RFC. > > Done Submit Routing requirements for Connected Home networks > applications > to the IESG to be considered as an Informational RFC. > > Done Submit Routing requirements for Building applications to the > IESG to > be considered as an Informational RFC. > > Done Submit Routing requirements for Urban networks applications to > the > IESG to be considered as an Informational RFC. > > July 2009 Submit Routing metrics for LLNs document to the IESG to be > considered as a Proposed Standard. > > Feb 2009 Submit Protocol Survey to the IESG to be considered as an > Informational RFC. > > April 2009 Submit Security Framework to the IESG to be considered as > an > Informational RFC > > May 2009 Submit the Routing for LLNs Architecture document to the > IESG > as an Informational RFC. > > July 2009 Submit first draft of ROLL routing protocol specification > as > Proposed Standard. > > Nov 2009 Submit first draft of the MIB module of the ROLL routing > protocol specification. > > Feb 2010 Submit the ROLL routing protocol specification to the > IESG as > Proposed Standard. > > March 2010 Submit the MIB module of the ROLL routing protocol > specification to the IESG as Proposed Standard. > > April 2010 Evaluate WG progress, recharter or close. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --Apple-Mail-18-268673909 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Emmanuel,

Thanks for your comments - see = below.

On Mar 5, 2009, at 5:54 PM, Emmanuel = Baccelli wrote:

Hi all,

The ROLL WG = targets to operate IP under constraints that are clearly harsher = than usual within the IETF, similar only to extreme forms of network = addressed by few WGs (such as MANET or 6LOWPAN).
=

As far as I understand, the context in which ROLL = aims to operate IP is:

- extremely limited = RAM
- extremely limited CPU
- extremely limited = wireless bandwidth

The typical deployment = aimed at by ROLL is:

- thousands of = nodes
- no assumptions on the = topology

The typical usage of such deployment = includes:

- unicast data flows from nodes to = border routers
- unicast data flows between = nodes
- multicast/flooding/?cast data flows from one node = to other nodes

The proposed charter yields a = slew of work-items in this context,
based on the above and on = some of the applications requirements
listed in the WG = documents that are currently under IESG = review.

The exact set of targeted requirements = are unfortunately not explicitly
mentioned in = the charter, nor in any other document. = However, 
the work-items that are explicitly or = implicitly evoked in the proposed
charter, include the = following:

- self-configuration protocols = in order to be "IP-ready" and "routing-ready",
- = unicast routing protocols,
- multicast/flooding/?cast (to be = defined) routing protocols,
- multi-homing = mechanisms/protocols,
- elaboration of metrics for wireless = links,
- securing all of the above with additional = mechanims/protocols,
- doing all of the above with real-time = constraints (to be defined) with = additional mechanims/protocols,
=


While this list is already impressive =  (especially within the currently = proposed time-frame),
it may not be exact or exhaustive, = depending on which set of requirements are indeed targeted.
=

For this reason, it seems to me that the highest = priority is to clarify this
point as soon as possible. And by = this I mean document:

- the precise list of = requirements that are targeted within the proposed = time-frame,

The WG has = produced 4 very detailed routing requirements written experts in the = field. I think that we now have all the = requirements.

=

- the precise list the operation = conditions, deployment & usage scenarios that are being = targeted within the proposed time-frame (the charter would benefit = from some additional effort put into setting some limits for = targeted RAM and CPU, as well as more precision concerning the targeted = traffic = patterns),

Applicability = statements is an excellent idea and I do agree with you. This is one of = the new WG items:
- Documentation of applicability statement = of ROLL routing protocols.

=

- the precise list the work-items that = are targeted within the proposed time-frame (here, for instance, = the charter would benefit from some additional effort put into defining = what multicast/flooding/?cast is, what real-time means for ROLL, = and what additional work-item(s) they entails).
=


As a ROLL participant, it is = necessary and urgent for me to have these details in order to carry out = further work on protocol = design.


Please= read the requirements documents, they provide a lot of data. Of course, = more discussion will take place on the list as we move = forward.

Thanks.

JP.

Regards,
=
Emmanuel




<= /div>



On Wed, Mar 4, 2009 at 4:39 PM, IESG Secretary = <iesg-secretary@ietf.org> wrote:
A modified charter = has been submitted for the Routing Over Low power and
Lossy networks = working group in the Routing Area of the IETF.  The IESG
has = not made any determination as yet.  The modified charter is = provided
below for informational purposes only.  Please send = your comments to the
IESG mailing list (iesg@ietf.org) by Wednesday, March 11, = 2009.

Routing Over Low power and Lossy networks (roll)
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
Last Modified: 2009-02-04

Current Status: Active Working = Group

Additional information is available at tools.ietf.org/wg/roll

Chair(s):

= JP Vasseur <jpv@cisco.com>
= David Culler <culler@eecs.berkeley.edu>
=
Routing Area Director(s):

Ross Callon <rcallon@juniper.net>
David = Ward <dward@cisco.com>
=
Routing Area Advisor:
David Ward <dward@cisco.com>

Mailing = Lists:

General Discussion: roll@ietf.org
To Subscribe: http://www.ietf.org/mailman/listinfo/roll
= Archive: http://www.ietf.org/mail-archive/web/roll/
=
Description of Working Group:

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.
As = shown in a protocol survey existing routing protocols (in their = current

form) such as OSPF, IS-IS, AODV, and OLSR, do not meet = 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.

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: In light of the application specific = routing
requirements, the
 Working Group will either = specify a new protocol and/or will select an
existing
=  routing protocol (with the appropriate extensions in cooperation = with
the
 relevant Working Group).

- Documentation = of applicability statement of ROLL routing protocols.

Goals and = Milestones:

Done Submit Routing requirements for Industrial = applications to the IESG
to be considered as an Informational = RFC.

Done Submit Routing requirements for Connected Home = networks applications
to the IESG to be considered as an = Informational RFC.

Done Submit Routing requirements for = Building applications to the IESG to
be considered as an = Informational RFC.

Done Submit Routing requirements for Urban = networks applications to the
IESG to be considered as an = Informational RFC.

July 2009 Submit Routing metrics for LLNs = document to the IESG to be
considered as a Proposed Standard.
=
Feb 2009 Submit Protocol Survey to the IESG to be considered as = an
Informational RFC.

April 2009 Submit Security Framework = to the IESG to be considered as an
Informational RFC

May = 2009   Submit the Routing for LLNs Architecture document to the = IESG
as an Informational RFC.

July 2009  Submit first = draft of ROLL routing protocol specification as
Proposed = Standard.

Nov 2009   Submit first draft of the MIB module = of the ROLL routing
protocol specification.

Feb 2010   = Submit the ROLL routing protocol specification to the IESG as
= Proposed Standard.

March 2010 Submit the MIB module of the ROLL = routing protocol
specification to the IESG as Proposed Standard.
=
April 2010 Evaluate WG progress, recharter or close.

= _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
=


= --Apple-Mail-18-268673909-- From STEVE.CHILDRESS@saic.com Thu Mar 5 09:28:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31EC028C4C3 for ; Thu, 5 Mar 2009 09:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnKRDp2iQF5Z for ; Thu, 5 Mar 2009 09:28:40 -0800 (PST) Received: from cpmx2.mail.saic.com (cpmx2.mail.saic.com [139.121.17.172]) by core3.amsl.com (Postfix) with ESMTP id E68E928C460 for ; Thu, 5 Mar 2009 09:28:32 -0800 (PST) Received: from 0599-ITS-SMS01 ([139.121.17.139] [139.121.17.139]) by cpmx2.mail.saic.com with ESMTP id BT-MMP-2935698 for roll@ietf.org; Thu, 5 Mar 2009 09:28:55 -0800 X-AuditID: 8b79118b-a6261ba000002b2e-46-49b00bd7e802 Received: from 0599-its-exbh01.us.saic.com (unknown [139.121.21.144]) by 0599-ITS-SMS01 (Symantec Mail Security) with ESMTP id 8B42920149 for ; Thu, 5 Mar 2009 09:28:55 -0800 (PST) Received: from 0461-its-exmb01.us.saic.com ([10.8.67.21]) by 0599-its-exbh01.us.saic.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 09:28:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99DB7.DC18B012" Date: Thu, 5 Mar 2009 09:28:55 -0800 Message-Id: <6532E5AE1BD6FF4B989254190D6FF15102942FE6@0461-its-exmb01.us.saic.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] WG Review: Recharter of Routing Over Low power and Lossynetworks (roll) Thread-Index: Acmdt2kDmndGH+YjS6iixsWLbuvbtAAAB+zg References: <20090304153927.4A1C43A6CD4@core3.amsl.com> From: "Childress, Steve" To: "ROLL WG" X-OriginalArrivalTime: 05 Mar 2009 17:28:53.0523 (UTC) FILETIME=[DAFB0630:01C99DB7] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossynetworks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 17:28:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99DB7.DC18B012 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If ROLL would benefit from a real use case, drawn from a current/funded project, needing high density mesh, battery powered routers, we'd be glad to elaborate. It was presented in summary form at the most recent IEEE 802.15 and ISA 100 conferences. =20 steve childress ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Thursday, March 05, 2009 9:25 AM To: Emmanuel Baccelli Cc: ROLL WG; David E. Culler; iesg@ietf.org; IETF Announcement list Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossynetworks (roll) Hi Emmanuel,=20 Thanks for your comments - see below. On Mar 5, 2009, at 5:54 PM, Emmanuel Baccelli wrote: =09 Hi all, The ROLL WG targets to operate IP under constraints that are clearly harsher than usual within the IETF, similar only to extreme forms of network addressed by few WGs (such as MANET or 6LOWPAN). As far as I understand, the context in which ROLL aims to operate IP is: - extremely limited RAM - extremely limited CPU - extremely limited wireless bandwidth The typical deployment aimed at by ROLL is: - thousands of nodes - no assumptions on the topology The typical usage of such deployment includes: - unicast data flows from nodes to border routers - unicast data flows between nodes - multicast/flooding/?cast data flows from one node to other nodes The proposed charter yields a slew of work-items in this context, based on the above and on some of the applications requirements listed in the WG documents that are currently under IESG review. The exact set of targeted requirements are unfortunately not explicitly mentioned in the charter, nor in any other document. However,=20 the work-items that are explicitly or implicitly evoked in the proposed charter, include the following: - self-configuration protocols in order to be "IP-ready" and "routing-ready", - unicast routing protocols, - multicast/flooding/?cast (to be defined) routing protocols, - multi-homing mechanisms/protocols, - elaboration of metrics for wireless links, - securing all of the above with additional mechanims/protocols, - doing all of the above with real-time constraints (to be defined) with additional mechanims/protocols, While this list is already impressive (especially within the currently proposed time-frame), it may not be exact or exhaustive, depending on which set of requirements are indeed targeted. For this reason, it seems to me that the highest priority is to clarify this point as soon as possible. And by this I mean document: - the precise list of requirements that are targeted within the proposed time-frame, The WG has produced 4 very detailed routing requirements written experts in the field. I think that we now have all the requirements. =09 - the precise list the operation conditions, deployment & usage scenarios that are being targeted within the proposed time-frame (the charter would benefit from some additional effort put into setting some limits for targeted RAM and CPU, as well as more precision concerning the targeted traffic patterns), Applicability statements is an excellent idea and I do agree with you. This is one of the new WG items: - Documentation of applicability statement of ROLL routing protocols. =09 - the precise list the work-items that are targeted within the proposed time-frame (here, for instance, the charter would benefit from some additional effort put into defining what multicast/flooding/?cast is, what real-time means for ROLL, and what additional work-item(s) they entails). As a ROLL participant, it is necessary and urgent for me to have these details in order to carry out further work on protocol design. Please read the requirements documents, they provide a lot of data. Of course, more discussion will take place on the list as we move forward. Thanks. JP. =09 Regards, Emmanuel On Wed, Mar 4, 2009 at 4:39 PM, IESG Secretary wrote: =09 A modified charter has been submitted for the Routing Over Low power and Lossy networks working group in the Routing Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. =09 Routing Over Low power and Lossy networks (roll) = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Last Modified: 2009-02-04 =09 Current Status: Active Working Group =09 Additional information is available at tools.ietf.org/wg/roll =09 Chair(s): =09 JP Vasseur David Culler =09 Routing Area Director(s): =09 Ross Callon David Ward =09 Routing Area Advisor: David Ward =09 Mailing Lists: =09 General Discussion: roll@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/roll Archive: http://www.ietf.org/mail-archive/web/roll/ =09 Description of Working Group: =09 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. =09 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. =09 These specific properties cause LLNs to have specific routing requirements. As shown in a protocol survey existing routing protocols (in their current =09 form) such as OSPF, IS-IS, AODV, and OLSR, do not meet these specific routing requirements. =09 The Working Group is focused on routing issues for LLN. =09 There is a wide scope of application areas for LLNs, including industrial =09 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. =09 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 =09 very modest memory and CPU pressure in networks potentially comprising a very large number (several thousands) of nodes. =09 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. =09 Work Items: =09 - Specification of routing metrics used in path calculation. This includes static and dynamic link/node attributes required for routing in LLNs. =09 - 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. =09 Manageability will be considered with each approach, along with various =09 trade-offs for maintaining low power operation, including the presence =09 of non-trivial loss and networks with a very large number of nodes. =09 - Produce a routing security framework for routing in LLNs. =09 - Protocol work: In light of the application specific routing requirements, the Working Group will either specify a new protocol and/or will select an existing routing protocol (with the appropriate extensions in cooperation with the relevant Working Group). =09 - Documentation of applicability statement of ROLL routing protocols. =09 Goals and Milestones: =09 Done Submit Routing requirements for Industrial applications to the IESG to be considered as an Informational RFC. =09 Done Submit Routing requirements for Connected Home networks applications to the IESG to be considered as an Informational RFC. =09 Done Submit Routing requirements for Building applications to the IESG to be considered as an Informational RFC. =09 Done Submit Routing requirements for Urban networks applications to the IESG to be considered as an Informational RFC. =09 July 2009 Submit Routing metrics for LLNs document to the IESG to be considered as a Proposed Standard. =09 Feb 2009 Submit Protocol Survey to the IESG to be considered as an Informational RFC. =09 April 2009 Submit Security Framework to the IESG to be considered as an Informational RFC =09 May 2009 Submit the Routing for LLNs Architecture document to the IESG as an Informational RFC. =09 July 2009 Submit first draft of ROLL routing protocol specification as Proposed Standard. =09 Nov 2009 Submit first draft of the MIB module of the ROLL routing protocol specification. =09 Feb 2010 Submit the ROLL routing protocol specification to the IESG as Proposed Standard. =09 March 2010 Submit the MIB module of the ROLL routing protocol specification to the IESG as Proposed Standard. =09 April 2010 Evaluate WG progress, recharter or close. =09 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =09 ------_=_NextPart_001_01C99DB7.DC18B012 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
If ROLL would benefit from a real use = case, drawn from=20 a current/funded project, needing high density mesh, battery powered = routers,=20 we'd be glad to elaborate. It was presented in summary form at the most = recent=20 IEEE 802.15 and ISA 100 conferences.
 
steve childress

From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of JP = Vasseur
Sent:=20 Thursday, March 05, 2009 9:25 AM
To: Emmanuel = Baccelli
Cc:=20 ROLL WG; David E. Culler; iesg@ietf.org; IETF Announcement=20 list
Subject: Re: [Roll] WG Review: Recharter of Routing Over = Low=20 power and Lossynetworks (roll)

Hi Emmanuel,

Thanks for your comments - see below.

On Mar 5, 2009, at 5:54 PM, Emmanuel Baccelli wrote:
Hi all,

The ROLL WG targets to operate IP under constraints = that are=20 clearly harsher than usual within the IETF, similar only to extreme = forms of=20 network addressed by few WGs (such as MANET or 6LOWPAN).

As far as I understand, the context in which ROLL aims to operate = IP=20 is:

- extremely limited RAM
- extremely limited CPU
- extremely limited wireless bandwidth

The typical deployment aimed at by ROLL is:

- thousands of nodes
- no assumptions on the topology

The typical usage of such deployment includes:

- unicast data flows from nodes to border routers
- unicast data flows between nodes
- multicast/flooding/?cast data flows from one node to other = nodes

The proposed charter yields a slew of work-items in this = context,
based on the above and on some of the applications = requirements
listed in the WG documents that are currently under IESG = review.

The exact set of targeted requirements are unfortunately not=20 explicitly
mentioned in the charter, nor in any other document.=20 However, 
the work-items that are explicitly or implicitly evoked in = the=20 proposed
charter, include the following:

- self-configuration protocols in order to be "IP-ready"=20 and "routing-ready",
- unicast routing protocols,
- multicast/flooding/?cast (to be defined) routing = protocols,
- multi-homing mechanisms/protocols,
- elaboration of metrics for wireless links,
- securing all of the above with additional = mechanims/protocols,
- doing all of the above with real-time constraints (to be = defined) with=20 additional mechanims/protocols,


While this list is already impressive  (especially within = the=20 currently proposed time-frame),
it may not be exact or exhaustive, depending on which set=20 of requirements are indeed targeted.

For this reason, it seems to me that the highest priority is to = clarify=20 this
point as soon as possible. And by this I mean document:

- the precise list of requirements that are targeted within the = proposed=20 time-frame,

The WG has produced 4 very detailed routing requirements written = experts in=20 the field. I think that we now have all the requirements.


- the precise list the operation conditions, deployment = &=20 usage scenarios that are being targeted within the proposed = time-frame=20 (the charter would benefit from some additional effort put into=20 setting some limits for targeted RAM and CPU, as well as more = precision=20 concerning the targeted traffic patterns),

Applicability statements is an excellent idea and I do agree with = you. This=20 is one of the new WG items:
- Documentation of applicability statement of ROLL routing=20 protocols.


- the precise list the work-items that are targeted within = the=20 proposed time-frame (here, for instance, the charter would benefit = from some=20 additional effort put into defining what multicast/flooding/?cast = is,=20 what real-time means for ROLL, and what additional work-item(s) they=20 entails).


As a ROLL participant, it is necessary and urgent for me to have = these=20 details in order to carry out further work on protocol design.


Please read the requirements documents, they provide a lot of data. = Of=20 course, more discussion will take place on the list as we move = forward.

Thanks.

JP.


Regards,
Emmanuel







On Wed, Mar 4, 2009 at 4:39 PM, IESG = Secretary <iesg-secretary@ietf.org>=20 wrote:
A=20 modified charter has been submitted for the Routing Over Low power=20 and
Lossy networks working group in the Routing Area of the IETF. =  The IESG
has not made any determination as yet.  The = modified=20 charter is provided
below for informational purposes only. =  Please=20 send your comments to the
IESG mailing list (iesg@ietf.org) by Wednesday, March = 11,=20 2009.

Routing Over Low power and Lossy networks=20 = (roll)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
Last=20 Modified: 2009-02-04

Current Status: Active Working=20 Group

Additional information is available at tools.ietf.org/wg/roll

Chair(s):

JP = Vasseur=20 <jpv@cisco.com>
David = Culler=20 <culler@eecs.berkeley.edu>=

Routing=20 Area Director(s):

Ross Callon <rcallon@juniper.net>
David = Ward=20 <dward@cisco.com>

Routing=20 Area Advisor:
David Ward <dward@cisco.com>

Mailing=20 Lists:

General Discussion: roll@ietf.org
To Subscribe: http://www.ietf.org/mailman/listinfo/roll
Archive:= http://www.ietf.org/mail-archive/web/roll/

Des= cription=20 of Working Group:

Low power and Lossy networks (LLNs) are = made up of=20 many
embedded devices with limited power, memory, and=20 processing
resources. They are interconnected by a variety of = links, such=20 as
IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other = low
power=20 PLC (Powerline Communication) links. LLNs are transitioning
to an = end-to-end IP-based solution to avoid the problem = of
non-interoperable=20 networks interconnected by protocol translation
gateways and=20 proxies.

Generally speaking, LLNs have at least five=20 distinguishing
characteristics:
- LLNs operate with a hard, = very small=20 bound on state.
- In most cases, LLN optimize for saving = energy.
-=20 Typical traffic patterns are not simply unicast flows (e.g. in=20 some
cases
 most if not all traffic can be point to=20 multipoint).
- In most cases, LLNs will be employed over link = layers with=20 restricted
 frame-sizes, thus a routing protocol for LLNs = should be=20 specifically
adapted
 for such link layers.
- LLN = routing=20 protocols have to be very careful when trading=20 off
efficiency
 for generality; many LLN nodes do not = have=20 resources to waste.

These specific properties cause LLNs to = have=20 specific routing
requirements.
As shown in a protocol survey = existing=20 routing protocols (in their current

form) such as OSPF, = IS-IS, AODV,=20 and OLSR, do not meet these specific
routing = requirements.

The=20 Working Group is focused on routing issues for LLN.

There is = a wide=20 scope of application areas for LLNs, including = industrial

monitoring,=20 building automation (HVAC, lighting, access control, = fire),
connected=20 homes, healthcare, environmental monitoring, urban = sensor
networks (e.g.=20 Smart Grid), asset tracking. The Working Group focuses
on routing = solutions for a subset of these: industrial, connected = home,
building and=20 urban sensor networks for which routing requirements have
been = specified.=20 These application-specific routing requirement documents
will be = used for=20 protocol design.

The Working Group focuses only on IPv6 = routing=20 architectural framework
for these application scenarios. The = Framework=20 will take into
consideration
various aspects including high=20 reliability in the presence of time = varying
loss
characteristics and=20 connectivity while permitting low-power operation with

very = modest=20 memory and CPU pressure in networks potentially comprising
a very = large=20 number (several thousands) of nodes.

The Working Group will = pay=20 particular attention to routing security and
manageability (e.g., = self=20 routing configuration) issues. It will also need
to
consider = the=20 transport characteristic the routing protocol messages = will
experience.=20 Mechanisms that protect an LLN from congestion collapse or
that = establish=20 some degree of fairness between concurrent communication
sessions = are out=20 of scope of the Working Group. It is expected that
upper-layer=20 applications utilizing LLNs define appropriate = mechanisms.

Work=20 Items:

- Specification of routing metrics used in path = calculation.=20 This
includes
 static and dynamic link/node attributes = required=20 for routing in LLNs.

- Provide an architectural framework for = routing=20 and path selection at
 Layer 3 (Routing for LLN = Architecture) that=20 addresses such issues as
 whether LLN routing require a = distributed=20 and/or centralized path
computation
 models, whether = additional=20 hierarchy is necessary and how it is = applied.

 Manageability=20 will be considered with each approach, along with=20 various

 trade-offs for maintaining low power operation, = including the presence

 of non-trivial loss and networks = with a=20 very large number of nodes.

- Produce a routing security = framework=20 for routing in LLNs.

- Protocol work: In light of the = application=20 specific routing
requirements, the
 Working Group will = either=20 specify a new protocol and/or will select = an
existing
 routing=20 protocol (with the appropriate extensions in cooperation=20 with
the
 relevant Working Group).

- Documentation = of=20 applicability statement of ROLL routing protocols.

Goals and=20 Milestones:

Done Submit Routing requirements for Industrial=20 applications to the IESG
to be considered as an Informational=20 RFC.

Done Submit Routing requirements for Connected Home = networks=20 applications
to the IESG to be considered as an Informational=20 RFC.

Done Submit Routing requirements for Building = applications to=20 the IESG to
be considered as an Informational RFC.

Done = Submit=20 Routing requirements for Urban networks applications to the
IESG = to be=20 considered as an Informational RFC.

July 2009 Submit Routing = metrics=20 for LLNs document to the IESG to be
considered as a Proposed=20 Standard.

Feb 2009 Submit Protocol Survey to the IESG to be=20 considered as an
Informational RFC.

April 2009 Submit = Security=20 Framework to the IESG to be considered as an
Informational = RFC

May=20 2009   Submit the Routing for LLNs Architecture document to the = IESG
as an Informational RFC.

July 2009  Submit first = draft=20 of ROLL routing protocol specification as
Proposed = Standard.

Nov=20 2009   Submit first draft of the MIB module of the ROLL=20 routing
protocol specification.

Feb 2010   Submit the = ROLL=20 routing protocol specification to the IESG as
Proposed=20 Standard.

March 2010 Submit the MIB module of the ROLL = routing=20 protocol
specification to the IESG as Proposed = Standard.

April=20 2010 Evaluate WG progress, recharter or=20 = close.

_______________________________________________
Roll=20 mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll


------_=_NextPart_001_01C99DB7.DC18B012-- From jvasseur@cisco.com Thu Mar 5 09:36:32 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34A7628C257 for ; Thu, 5 Mar 2009 09:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.76 X-Spam-Level: X-Spam-Status: No, score=-9.76 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jS0kUUNolMHf for ; Thu, 5 Mar 2009 09:36:29 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 22FC328C3F7 for ; Thu, 5 Mar 2009 09:36:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,308,1233532800"; d="scan'208,217";a="35480940" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 05 Mar 2009 17:36:52 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n25HaoCP031433; Thu, 5 Mar 2009 18:36:50 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n25HaoY2003692; Thu, 5 Mar 2009 17:36:50 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Mar 2009 18:36:50 +0100 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Mar 2009 18:36:49 +0100 Message-Id: <4AC9D168-621A-4FBE-9839-DDACD545123F@cisco.com> From: JP Vasseur To: "Childress, Steve" In-Reply-To: <6532E5AE1BD6FF4B989254190D6FF15102942FE6@0461-its-exmb01.us.saic.com> Content-Type: multipart/alternative; boundary=Apple-Mail-23-269371340 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 5 Mar 2009 18:36:48 +0100 References: <20090304153927.4A1C43A6CD4@core3.amsl.com> <6532E5AE1BD6FF4B989254190D6FF15102942FE6@0461-its-exmb01.us.saic.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 05 Mar 2009 17:36:49.0855 (UTC) FILETIME=[F6E584F0:01C99DB8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=28303; t=1236274610; x=1237138610; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20WG=20Review=3A=20Recharter=20o f=20Routing=20Over=20Low=20power=20and=20Lossynetworks=20(ro ll) |Sender:=20; bh=qcYFKh2U0iFYOLWMEPWEUNvr+bJG+/mXuIOoSa4fGy8=; b=TTmWkdUTkZlOXqa/3R6uXxFFZxrEbgVxzpdD1pwuVXHznBxR8WpEPbkGVa Kv74NosQ1jbEGiWhjGCMkntBL5jwSoh2MGh0G0b4rcJJTRmlGF7OCEiVcKxl rnJlT5Dd2P; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossynetworks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 17:36:32 -0000 --Apple-Mail-23-269371340 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Thanks Steve for the offer. We'll get in touch with you soon. Cheers. JP. On Mar 5, 2009, at 6:28 PM, Childress, Steve wrote: > If ROLL would benefit from a real use case, drawn from a current/ > funded project, needing high density mesh, battery powered routers, > we'd be glad to elaborate. It was presented in summary form at the > most recent IEEE 802.15 and ISA 100 conferences. > > steve childress > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of JP Vasseur > Sent: Thursday, March 05, 2009 9:25 AM > To: Emmanuel Baccelli > Cc: ROLL WG; David E. Culler; iesg@ietf.org; IETF Announcement list > Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power > and Lossynetworks (roll) > > Hi Emmanuel, > > Thanks for your comments - see below. > > On Mar 5, 2009, at 5:54 PM, Emmanuel Baccelli wrote: > >> Hi all, >> >> The ROLL WG targets to operate IP under constraints that are >> clearly harsher than usual within the IETF, similar only to extreme >> forms of network addressed by few WGs (such as MANET or 6LOWPAN). >> >> As far as I understand, the context in which ROLL aims to operate >> IP is: >> >> - extremely limited RAM >> - extremely limited CPU >> - extremely limited wireless bandwidth >> >> The typical deployment aimed at by ROLL is: >> >> - thousands of nodes >> - no assumptions on the topology >> >> The typical usage of such deployment includes: >> >> - unicast data flows from nodes to border routers >> - unicast data flows between nodes >> - multicast/flooding/?cast data flows from one node to other nodes >> >> The proposed charter yields a slew of work-items in this context, >> based on the above and on some of the applications requirements >> listed in the WG documents that are currently under IESG review. >> >> The exact set of targeted requirements are unfortunately not >> explicitly >> mentioned in the charter, nor in any other document. However, >> the work-items that are explicitly or implicitly evoked in the >> proposed >> charter, include the following: >> >> - self-configuration protocols in order to be "IP-ready" and >> "routing-ready", >> - unicast routing protocols, >> - multicast/flooding/?cast (to be defined) routing protocols, >> - multi-homing mechanisms/protocols, >> - elaboration of metrics for wireless links, >> - securing all of the above with additional mechanims/protocols, >> - doing all of the above with real-time constraints (to be defined) >> with additional mechanims/protocols, >> >> >> While this list is already impressive (especially within the >> currently proposed time-frame), >> it may not be exact or exhaustive, depending on which set of >> requirements are indeed targeted. >> >> For this reason, it seems to me that the highest priority is to >> clarify this >> point as soon as possible. And by this I mean document: >> >> - the precise list of requirements that are targeted within the >> proposed time-frame, > > The WG has produced 4 very detailed routing requirements written > experts in the field. I think that we now have all the requirements. > >> >> - the precise list the operation conditions, deployment & usage >> scenarios that are being targeted within the proposed time-frame >> (the charter would benefit from some additional effort put into >> setting some limits for targeted RAM and CPU, as well as more >> precision concerning the targeted traffic patterns), > > Applicability statements is an excellent idea and I do agree with > you. This is one of the new WG items: > - Documentation of applicability statement of ROLL routing protocols. > >> >> - the precise list the work-items that are targeted within the >> proposed time-frame (here, for instance, the charter would benefit >> from some additional effort put into defining what multicast/ >> flooding/?cast is, what real-time means for ROLL, and what >> additional work-item(s) they entails). >> >> >> As a ROLL participant, it is necessary and urgent for me to have >> these details in order to carry out further work on protocol design. >> > > Please read the requirements documents, they provide a lot of data. > Of course, more discussion will take place on the list as we move > forward. > > Thanks. > > JP. > >> >> Regards, >> Emmanuel >> >> >> >> >> >> >> >> On Wed, Mar 4, 2009 at 4:39 PM, IESG Secretary > > wrote: >> A modified charter has been submitted for the Routing Over Low >> power and >> Lossy networks working group in the Routing Area of the IETF. The >> IESG >> has not made any determination as yet. The modified charter is >> provided >> below for informational purposes only. Please send your comments >> to the >> IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. >> >> Routing Over Low power and Lossy networks (roll) >> ================================================== >> Last Modified: 2009-02-04 >> >> Current Status: Active Working Group >> >> Additional information is available at tools.ietf.org/wg/roll >> >> Chair(s): >> >> JP Vasseur >> David Culler >> >> Routing Area Director(s): >> >> Ross Callon >> David Ward >> >> Routing Area Advisor: >> David Ward >> >> Mailing Lists: >> >> General Discussion: roll@ietf.org >> To Subscribe: http://www.ietf.org/mailman/listinfo/roll >> Archive: http://www.ietf.org/mail-archive/web/roll/ >> >> Description of Working Group: >> >> 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. >> As shown in a protocol survey existing routing protocols (in their >> current >> >> form) such as OSPF, IS-IS, AODV, and OLSR, do not meet 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. >> >> 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: In light of the application specific routing >> requirements, the >> Working Group will either specify a new protocol and/or will >> select an >> existing >> routing protocol (with the appropriate extensions in cooperation >> with >> the >> relevant Working Group). >> >> - Documentation of applicability statement of ROLL routing protocols. >> >> Goals and Milestones: >> >> Done Submit Routing requirements for Industrial applications to the >> IESG >> to be considered as an Informational RFC. >> >> Done Submit Routing requirements for Connected Home networks >> applications >> to the IESG to be considered as an Informational RFC. >> >> Done Submit Routing requirements for Building applications to the >> IESG to >> be considered as an Informational RFC. >> >> Done Submit Routing requirements for Urban networks applications to >> the >> IESG to be considered as an Informational RFC. >> >> July 2009 Submit Routing metrics for LLNs document to the IESG to be >> considered as a Proposed Standard. >> >> Feb 2009 Submit Protocol Survey to the IESG to be considered as an >> Informational RFC. >> >> April 2009 Submit Security Framework to the IESG to be considered >> as an >> Informational RFC >> >> May 2009 Submit the Routing for LLNs Architecture document to the >> IESG >> as an Informational RFC. >> >> July 2009 Submit first draft of ROLL routing protocol >> specification as >> Proposed Standard. >> >> Nov 2009 Submit first draft of the MIB module of the ROLL routing >> protocol specification. >> >> Feb 2010 Submit the ROLL routing protocol specification to the >> IESG as >> Proposed Standard. >> >> March 2010 Submit the MIB module of the ROLL routing protocol >> specification to the IESG as Proposed Standard. >> >> April 2010 Evaluate WG progress, recharter or close. >> >> _______________________________________________ >> 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 --Apple-Mail-23-269371340 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Thanks Steve for the offer. = We'll get in touch with you = soon.

Cheers.

JP.
On Mar 5, 2009, at 6:28 PM, Childress, Steve wrote:

If ROLL would benefit from a real use = case, drawn from a current/funded project, needing high density = mesh, battery powered routers, we'd be glad to elaborate. It was = presented in summary form at the most recent IEEE 802.15 and ISA 100 = conferences.
 
steve childress

=
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] = On Behalf Of JP Vasseur
Sent: Thursday, March 05, 2009 = 9:25 AM
To: Emmanuel Baccelli
Cc: ROLL WG; David E. = Culler; iesg@ietf.org; IETF = Announcement list
Subject: Re: [Roll] WG Review: Recharter of = Routing Over Low power and Lossynetworks (roll)

=
Hi Emmanuel,

Thanks for your comments - = see below.

On Mar 5, 2009, at 5:54 PM, = Emmanuel Baccelli wrote:

=
Hi all,
=

The ROLL WG targets to operate IP under = constraints that are clearly harsher than usual within the IETF, = similar only to extreme forms of network addressed by few WGs (such as = MANET or 6LOWPAN).

As far as I understand, = the context in which ROLL aims to operate IP is:
=

- extremely limited RAM
- extremely = limited CPU
- extremely limited wireless bandwidth
=

The typical deployment aimed at by ROLL is:
=

- thousands of nodes
- no assumptions = on the topology

The typical usage of such = deployment includes:

- unicast data flows = from nodes to border routers
- unicast data flows between = nodes
- multicast/flooding/?cast data flows from one = node to other nodes

The proposed charter = yields a slew of work-items in this context,
based on the = above and on some of the applications requirements
listed in = the WG documents that are currently under IESG review.
=

The exact set of targeted requirements are = unfortunately not explicitly
mentioned in = the charter, nor in any other document. However, 
=
the work-items that are explicitly or implicitly evoked in the = proposed
charter, include the following:
=

- self-configuration protocols in order to = be "IP-ready" and "routing-ready",
- unicast = routing protocols,
- multicast/flooding/?cast (to be = defined) routing protocols,
- multi-homing = mechanisms/protocols,
- elaboration of metrics for wireless = links,
- securing all of the above with additional = mechanims/protocols,
- doing all of the above with real-time = constraints (to be defined) with = additional mechanims/protocols,

=

While this list is already impressive =  (especially within the currently = proposed time-frame),
it may not be exact or = exhaustive, depending on which set of requirements are indeed = targeted.

For this reason, it seems to me = that the highest priority is to clarify this
point as soon = as possible. And by this I mean document:

- = the precise list of requirements that are targeted within the proposed = time-frame,

The WG has = produced 4 very detailed routing requirements written experts in the = field. I think that we now have all the requirements.

=

- the = precise list the operation conditions, deployment & = usage scenarios that are being targeted within the proposed = time-frame (the charter would benefit from some additional effort put = into setting some limits for targeted RAM and CPU, as well as = more precision concerning the targeted traffic = patterns),

Applicability = statements is an excellent idea and I do agree with you. This is one of = the new WG items:
- Documentation of applicability statement = of ROLL routing protocols.

=

- the precise list the work-items that = are targeted within the proposed time-frame (here, for instance, = the charter would benefit from some additional effort put into = defining what multicast/flooding/?cast is, what real-time means = for ROLL, and what additional work-item(s) they entails).
=


As a ROLL participant, it is = necessary and urgent for me to have these details in order to carry = out further work on protocol design.
=


Please read the = requirements documents, they provide a lot of data. Of course, more = discussion will take place on the list as we move forward.
=

Thanks.

JP.

=

=
Regards,
Emmanuel

=




=


On Wed, Mar 4, = 2009 at 4:39 PM, IESG Secretary <iesg-secretary@ietf.org> wrote:
A = modified charter has been submitted for the Routing Over Low power = and
Lossy networks working group in the Routing Area of the IETF. =  The IESG
has not made any determination as yet.  The = modified charter is provided
below for informational purposes = only.  Please send your comments to the
IESG mailing list = (iesg@ietf.org) by Wednesday, March = 11, 2009.

Routing Over Low power and Lossy networks = (roll)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
Last Modified: 2009-02-04

Current Status: Active = Working Group

Additional information is available at tools.ietf.org/wg/roll

Chair(s):

JP = Vasseur <jpv@cisco.com>
David Culler = <culler@eecs.berkeley.edu>
=
Routing Area Director(s):

Ross Callon <rcallon@juniper.net>
David = Ward <dward@cisco.com>

Routing = Area Advisor:
David Ward <dward@cisco.com>

Mailing = Lists:

General Discussion: roll@ietf.org
To Subscribe: http://www.ietf.org/mailman/listinfo/roll
Archive= : http://www.ietf.org/mail-archive/web/roll/

De= scription of Working Group:

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.
As shown in a = protocol survey existing routing protocols (in their = current

form) such as OSPF, IS-IS, AODV, and OLSR, do not = meet 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.

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: In = light of the application specific routing
requirements, = the
 Working Group will either specify a new protocol and/or = will select an
existing
 routing protocol (with the = appropriate extensions in cooperation with
the
 relevant = Working Group).

- Documentation of applicability statement of = ROLL routing protocols.

Goals and Milestones:

Done = Submit Routing requirements for Industrial applications to the = IESG
to be considered as an Informational RFC.

Done Submit = Routing requirements for Connected Home networks applications
to = the IESG to be considered as an Informational RFC.

Done = Submit Routing requirements for Building applications to the IESG = to
be considered as an Informational RFC.

Done Submit = Routing requirements for Urban networks applications to the
IESG to = be considered as an Informational RFC.

July 2009 Submit = Routing metrics for LLNs document to the IESG to be
considered as = a Proposed Standard.

Feb 2009 Submit Protocol Survey to the = IESG to be considered as an
Informational RFC.

April 2009 = Submit Security Framework to the IESG to be considered as = an
Informational RFC

May 2009   Submit the Routing = for LLNs Architecture document to the IESG
as an Informational = RFC.

July 2009  Submit first draft of ROLL routing = protocol specification as
Proposed Standard.

Nov 2009 =   Submit first draft of the MIB module of the ROLL = routing
protocol specification.

Feb 2010   Submit the = ROLL routing protocol specification to the IESG as
Proposed = Standard.

March 2010 Submit the MIB module of the ROLL routing = protocol
specification to the IESG as Proposed = Standard.

April 2010 Evaluate WG progress, recharter or = close.

_______________________________________________
Roll = mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll


= _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-23-269371340-- From pete.mccann@motorola.com Thu Mar 5 09:15:54 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B38E428C1BC; Thu, 5 Mar 2009 09:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LREL4QQuNCQm; Thu, 5 Mar 2009 09:15:53 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with ESMTP id B544B3A68DB; Thu, 5 Mar 2009 09:15:53 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-3.tower-153.messagelabs.com!1236273381!14218801!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [136.182.1.12] Received: (qmail 18600 invoked from network); 5 Mar 2009 17:16:22 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (136.182.1.12) by server-3.tower-153.messagelabs.com with AES256-SHA encrypted SMTP; 5 Mar 2009 17:16:22 -0000 Received: from il27exr04.cig.mot.com (il27exr04.mot.com [10.17.196.73]) by motgate2.mot.com (8.14.3/8.14.3) with ESMTP id n25HGLGq017723; Thu, 5 Mar 2009 10:16:21 -0700 (MST) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id n25HGLpJ009827; Thu, 5 Mar 2009 11:16:21 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Mar 2009 12:16:21 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART review of draft-ietf-roll-indus-routing-reqs-04 thread-index: AcmdthqXVWsRypCFR/6WUT8PKA/bvg== From: "McCann Peter-A001034" To: , X-Mailman-Approved-At: Thu, 05 Mar 2009 09:36:51 -0800 Cc: roll@ietf.org, roll-ads@tools.ietf.org, roll-chairs@tools.ietf.org Subject: [Roll] Gen-ART review of draft-ietf-roll-indus-routing-reqs-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 17:15:54 -0000 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-roll-indus-routing-reqs-04.txt Reviewer: Pete McCann Review Date: 05 March 2009 IETF LC End Date: 05 March 2009 IESG Telechat date: unknown=20 Summary: Ready but some editorial comments. The draft provides an interesting overview of the particular problem domain of industrial control networks. Major issues:=20 Minor issues:=20 The draft seems to contain a large number of run-on sentences. Here is one I couldn't quite parse, from Section 8: Undecided yet is if these PDAs will use the LLN network directly to talk to field sensors, or if they will rather use other wireless connectivity that proxys back into the field, or to anywhere else, the user interfaces typically used for plant historians, asset management systems, and the likes. Nits/editorial comments:=20 Section 2.1: OLD: most users tend to not aim NEW: most users tend not to aim Section 2.2.1: OLD: Form afar, NEW: From afar, Section 4: OLD: random bit errors, so white noise NEW: random bit errors due to white noise Section 10: OLD: risks of temporary losing connectivity, NEW: risks of temporarily losing connectivity, OLD: Wireless typically forces abandonance of classical 'by perimeter' NEW: The wireless environment typically forces the abandonment of classical 'by perimeter' From pister@eecs.berkeley.edu Thu Mar 5 21:26:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6240C28C0FD for ; Thu, 5 Mar 2009 21:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaUc+wHchAu9 for ; Thu, 5 Mar 2009 21:26:41 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 4A5B83A6928 for ; Thu, 5 Mar 2009 21:26:41 -0800 (PST) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n265R7Lh025021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 5 Mar 2009 21:27:08 -0800 (PST) Message-ID: <49B0B426.3050602@eecs.berkeley.edu> Date: Thu, 05 Mar 2009 21:27:02 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: roll@ietf.org References: <20090304153927.4A1C43A6CD4@core3.amsl.com> In-Reply-To: <20090304153927.4A1C43A6CD4@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 05:26:42 -0000 I would imagine that all of the authors of the routing requirements document would agree, but speaking only for myself, I'd like to say GREAT!!! Let's recharter and get to work! ksjp IESG Secretary wrote: > A modified charter has been submitted for the Routing Over Low power and > Lossy networks working group in the Routing Area of the IETF. The IESG > has not made any determination as yet. The modified charter is provided > below for informational purposes only. Please send your comments to the > IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. > > Routing Over Low power and Lossy networks (roll) > ================================================== > Last Modified: 2009-02-04 > > Current Status: Active Working Group > > Additional information is available at tools.ietf.org/wg/roll > > Chair(s): > > JP Vasseur > David Culler > > Routing Area Director(s): > > Ross Callon > David Ward > > Routing Area Advisor: > David Ward > > Mailing Lists: > > General Discussion: roll@ietf.org > To Subscribe: http://www.ietf.org/mailman/listinfo/roll > Archive: http://www.ietf.org/mail-archive/web/roll/ > > Description of Working Group: > > 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. > As shown in a protocol survey existing routing protocols (in their current > > form) such as OSPF, IS-IS, AODV, and OLSR, do not meet 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. > > 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: In light of the application specific routing > requirements, the > Working Group will either specify a new protocol and/or will select an > existing > routing protocol (with the appropriate extensions in cooperation with > the > relevant Working Group). > > - Documentation of applicability statement of ROLL routing protocols. > > Goals and Milestones: > > Done Submit Routing requirements for Industrial applications to the IESG > to be considered as an Informational RFC. > > Done Submit Routing requirements for Connected Home networks applications > to the IESG to be considered as an Informational RFC. > > Done Submit Routing requirements for Building applications to the IESG to > be considered as an Informational RFC. > > Done Submit Routing requirements for Urban networks applications to the > IESG to be considered as an Informational RFC. > > July 2009 Submit Routing metrics for LLNs document to the IESG to be > considered as a Proposed Standard. > > Feb 2009 Submit Protocol Survey to the IESG to be considered as an > Informational RFC. > > April 2009 Submit Security Framework to the IESG to be considered as an > Informational RFC > > May 2009 Submit the Routing for LLNs Architecture document to the IESG > as an Informational RFC. > > July 2009 Submit first draft of ROLL routing protocol specification as > Proposed Standard. > > Nov 2009 Submit first draft of the MIB module of the ROLL routing > protocol specification. > > Feb 2010 Submit the ROLL routing protocol specification to the IESG as > Proposed Standard. > > March 2010 Submit the MIB module of the ROLL routing protocol > specification to the IESG as Proposed Standard. > > April 2010 Evaluate WG progress, recharter or close. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From tim.winter@ekasystems.com Fri Mar 6 07:36:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA6323A680B for ; Fri, 6 Mar 2009 07:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+rnMvCdrfyz for ; Fri, 6 Mar 2009 07:36:56 -0800 (PST) Received: from smtp100.biz.mail.re2.yahoo.com (smtp100.biz.mail.re2.yahoo.com [206.190.52.46]) by core3.amsl.com (Postfix) with SMTP id 58BC33A6C61 for ; Fri, 6 Mar 2009 07:36:56 -0800 (PST) Received: (qmail 61526 invoked from network); 6 Mar 2009 15:37:26 -0000 Received: from unknown (HELO zeke.ekasystems.com) (tim.winter@209.48.242.70 with plain) by smtp100.biz.mail.re2.yahoo.com with SMTP; 6 Mar 2009 15:37:26 -0000 X-Yahoo-SMTP: eUj8LdaswBBWeR39KCwXsq8v1dqNCdNUVNk5_GtuwEk24wd2Wtg- X-YMail-OSG: yxzcIEkVM1k8y_4CNMN6tU76HLW8a96u__DgqzL44Ww3mOwU.T9zg6Rlt0CUM9qyG7KaNZT9jBNJt7bEiPAGd9uzU2H24xKSjn6erk58Vjyf_HVD_xAXtAy8uwIf.0rnMhvFzJbxU6P_8cgQAbDzMbtfnx9tzTUTurVKqYcwPcl7.wzOdlJ8mzXUqYpZeLcEVCt7HAHojMTeYAJ29pzvg1MUkC6g X-Yahoo-Newman-Property: ymail-3 Message-ID: <49B14332.10507@ekasystems.com> Date: Fri, 06 Mar 2009 10:37:22 -0500 From: Tim Winter User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: iesg@ietf.org References: <20090304153927.4A1C43A6CD4@core3.amsl.com> In-Reply-To: <20090304153927.4A1C43A6CD4@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 15:36:57 -0000 I am in support of the modified charter. The ROLL WG has covered a lot of ground in examining the requirements of an LLN routing protocol with respect to various applications, and the protocol survey effort does indicate that no existing IETF protocol without modification will be a good fit for the requirements. The modified charter will allow the WG to continue with its current momentum and either specify modifications to an existing IETF protocol or a new protocol in order to meet the demand of industry. -Tim IESG Secretary wrote: > A modified charter has been submitted for the Routing Over Low power and > Lossy networks working group in the Routing Area of the IETF. The IESG > has not made any determination as yet. The modified charter is provided > below for informational purposes only. Please send your comments to the > IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. > > Routing Over Low power and Lossy networks (roll) > ================================================== > Last Modified: 2009-02-04 > > Current Status: Active Working Group > > Additional information is available at tools.ietf.org/wg/roll > > Chair(s): > > JP Vasseur > David Culler > > Routing Area Director(s): > > Ross Callon > David Ward > > Routing Area Advisor: > David Ward > > Mailing Lists: > > General Discussion: roll@ietf.org > To Subscribe: http://www.ietf.org/mailman/listinfo/roll > Archive: http://www.ietf.org/mail-archive/web/roll/ > > Description of Working Group: > > 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. > As shown in a protocol survey existing routing protocols (in their current > > form) such as OSPF, IS-IS, AODV, and OLSR, do not meet 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. > > 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: In light of the application specific routing > requirements, the > Working Group will either specify a new protocol and/or will select an > existing > routing protocol (with the appropriate extensions in cooperation with > the > relevant Working Group). > > - Documentation of applicability statement of ROLL routing protocols. > > Goals and Milestones: > > Done Submit Routing requirements for Industrial applications to the IESG > to be considered as an Informational RFC. > > Done Submit Routing requirements for Connected Home networks applications > to the IESG to be considered as an Informational RFC. > > Done Submit Routing requirements for Building applications to the IESG to > be considered as an Informational RFC. > > Done Submit Routing requirements for Urban networks applications to the > IESG to be considered as an Informational RFC. > > July 2009 Submit Routing metrics for LLNs document to the IESG to be > considered as a Proposed Standard. > > Feb 2009 Submit Protocol Survey to the IESG to be considered as an > Informational RFC. > > April 2009 Submit Security Framework to the IESG to be considered as an > Informational RFC > > May 2009 Submit the Routing for LLNs Architecture document to the IESG > as an Informational RFC. > > July 2009 Submit first draft of ROLL routing protocol specification as > Proposed Standard. > > Nov 2009 Submit first draft of the MIB module of the ROLL routing > protocol specification. > > Feb 2010 Submit the ROLL routing protocol specification to the IESG as > Proposed Standard. > > March 2010 Submit the MIB module of the ROLL routing protocol > specification to the IESG as Proposed Standard. > > April 2010 Evaluate WG progress, recharter or close. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > From pal@cs.stanford.edu Fri Mar 6 09:18:50 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DDB43A6CBE; Fri, 6 Mar 2009 09:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRNcErh79k-J; Fri, 6 Mar 2009 09:18:49 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id A1AEF3A698C; Fri, 6 Mar 2009 09:18:49 -0800 (PST) Received: from dnab4220ca.stanford.edu ([171.66.32.202]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Lfdhg-00080p-BH; Fri, 06 Mar 2009 09:19:20 -0800 Message-Id: <59EEF538-A200-4879-B501-22879A39FAC4@cs.stanford.edu> From: Philip Levis To: Tim Winter In-Reply-To: <49B14332.10507@ekasystems.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Mar 2009 09:19:20 -0800 References: <20090304153927.4A1C43A6CD4@core3.amsl.com> <49B14332.10507@ekasystems.com> X-Mailer: Apple Mail (2.930.3) X-Scan-Signature: 9dddbef7dbf47a29383c7a3c8e5dce6e Cc: roll@ietf.org, iesg@ietf.org Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 17:18:50 -0000 On Mar 6, 2009, at 7:37 AM, Tim Winter wrote: > I am in support of the modified charter. > > The ROLL WG has covered a lot of ground in examining the > requirements of an > LLN routing protocol with respect to various applications, and the > protocol > survey effort does indicate that no existing IETF protocol without > modification will be a good fit for the requirements. > > The modified charter will allow the WG to continue with its current > momentum and either specify modifications to an existing IETF > protocol or a > new protocol in order to meet the demand of industry. I also support the modified charter. I look forward to working in ROLL to help define the routing standards for LLNs. JP and others, thanks so much for incorporating all of the comments and feedback so quickly. Phil From arsalan.tavakoli@gmail.com Fri Mar 6 09:25:44 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0B493A6CBE; Fri, 6 Mar 2009 09:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gQ90zffp8-W; Fri, 6 Mar 2009 09:25:44 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 64F293A6B20; Fri, 6 Mar 2009 09:25:43 -0800 (PST) Received: by bwz26 with SMTP id 26so458026bwz.37 for ; Fri, 06 Mar 2009 09:26:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=lCAoEemhHnDrTs68jpVtzAKsXcv/riFIIKTGsVnI8rg=; b=cKhO69xoxDXKtOnpIXr2YNs5LeM0jRWx2q044xdJrVTd4UErX/21oIV4kunTwSwOyV aK1KwTMne/WcsBq30/adxOoWvXbFYfmjA+UCoX+LbsOl1ortcG3UJscGa/flylgVstyt xhyJWBjyD25cjaqPTqZx0VxHrmezqRS33scNc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=ZOyi0XN7ICpwWQ5dlgKMhJvvUpgciniX1RXkgdsws1rdwYsGimTR0zgzVVCxBox95R oOTc5l5ojFg6FE7W4F7TF6/M6Fg7bF7YNniQTQmchSXjqclT1N24Eivtedzz4OEKWgUG ajmY1u2fZymzU1XaJc1NLYKgGVH5IE9gpbObM= MIME-Version: 1.0 Sender: arsalan.tavakoli@gmail.com Received: by 10.103.228.19 with SMTP id f19mr1178346mur.18.1236360372869; Fri, 06 Mar 2009 09:26:12 -0800 (PST) In-Reply-To: <59EEF538-A200-4879-B501-22879A39FAC4@cs.stanford.edu> References: <20090304153927.4A1C43A6CD4@core3.amsl.com> <49B14332.10507@ekasystems.com> <59EEF538-A200-4879-B501-22879A39FAC4@cs.stanford.edu> Date: Fri, 6 Mar 2009 09:26:12 -0800 X-Google-Sender-Auth: 13b55478e5a451ee Message-ID: <69306dde0903060926y170f4744vf042177997016819@mail.gmail.com> From: Arsalan Tavakoli To: Philip Levis Content-Type: multipart/alternative; boundary=00163662e5aed6dadb046476944b Cc: roll@ietf.org, iesg@ietf.org Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 17:25:44 -0000 --00163662e5aed6dadb046476944b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I also support the modified charter; I think it does a good job of capturing what ROLL should be doing, and I look forward to moving into the next stage of the process. - Arsalan On Fri, Mar 6, 2009 at 9:19 AM, Philip Levis wrote: > > On Mar 6, 2009, at 7:37 AM, Tim Winter wrote: > > I am in support of the modified charter. >> >> The ROLL WG has covered a lot of ground in examining the requirements of >> an >> LLN routing protocol with respect to various applications, and the >> protocol >> survey effort does indicate that no existing IETF protocol without >> modification will be a good fit for the requirements. >> >> The modified charter will allow the WG to continue with its current >> momentum and either specify modifications to an existing IETF protocol or >> a >> new protocol in order to meet the demand of industry. >> > > I also support the modified charter. I look forward to working in ROLL to > help define the routing standards for LLNs. JP and others, thanks so much > for incorporating all of the comments and feedback so quickly. > > Phil > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --00163662e5aed6dadb046476944b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I also support the modified charter; I think it does a good job of capturing what ROLL should be doing, and I look forward to moving into the next stage of the process.

- Arsalan

On Fri, Mar 6, 2009 at 9:19 AM, Philip Levis <pal@cs.stanford.edu> wrote:

On Mar 6, 2009, at 7:37 AM, Tim Winter wrote:

I am in support of the modified charter.

The ROLL WG has covered a lot of ground in examining the requirements of an
LLN routing protocol with respect to various applications, and the protocol
survey effort does indicate that no existing IETF protocol without
modification will be a good fit for the requirements.

The modified charter will allow the WG to continue with its current
momentum and either specify modifications to an existing IETF protocol or a
new protocol in order to meet the demand of industry.

I also support the modified charter. I look forward to working in ROLL to help define the routing standards for LLNs. JP and others, thanks so much for incorporating all of the comments and feedback so quickly.

Phil

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

--00163662e5aed6dadb046476944b-- From alexandru.petrescu@gmail.com Fri Mar 6 09:33:08 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42DDA3A6D1B; Fri, 6 Mar 2009 09:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFx5QThpeEwz; Fri, 6 Mar 2009 09:33:07 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 54C853A68F3; Fri, 6 Mar 2009 09:33:07 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n26HVm8S001611; Fri, 6 Mar 2009 18:31:48 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n26HXYqf015256; Fri, 6 Mar 2009 18:33:34 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n26HXYbk018551; Fri, 6 Mar 2009 18:33:34 +0100 Message-ID: <49B15E6E.1000705@gmail.com> Date: Fri, 06 Mar 2009 18:33:34 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Tim Winter References: <20090304153927.4A1C43A6CD4@core3.amsl.com> <49B14332.10507@ekasystems.com> In-Reply-To: <49B14332.10507@ekasystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org, iesg@ietf.org Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 17:33:08 -0000 Tim Winter a écrit : > I am in support of the modified charter. > > The ROLL WG has covered a lot of ground in examining the requirements of an > LLN routing protocol with respect to various applications, and the protocol > survey effort does indicate that no existing IETF protocol without > modification will be a good fit for the requirements. > > The modified charter will allow the WG to continue with its current > momentum and either specify modifications to an existing IETF protocol or a > new protocol in order to meet the demand of industry. What do you mean: specify modifications to existing protocol or new protocol? Both? Only one? What's the goal of this ambiguous language? Alex From arsalan.tavakoli@gmail.com Fri Mar 6 09:38:25 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 883E13A6919; Fri, 6 Mar 2009 09:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btED9dcn3taH; Fri, 6 Mar 2009 09:38:24 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 0A0763A690E; Fri, 6 Mar 2009 09:38:23 -0800 (PST) Received: by bwz26 with SMTP id 26so462894bwz.37 for ; Fri, 06 Mar 2009 09:38:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=fJdtfbpi9lxdYz8bLEoFKAUx0mrC/z/S8aP2OUkg0rI=; b=ezazCAOeGarXjcbc47dbc5bkdPcXhWyc2Jh7Uwk4ZjkJcuj5FIzQZGu0e/cVuSA0NG u8T/cVvZrp2khQ6Iz1CR0pwxCe3Jx155lumW0VvwBHk04A+4sYbY9B+xN0q/N4gE4jjq 83aoCCdCT38UwxHyEgDQIcQBWUXUIxJgFzYbs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=toscyWsDkTOs8GmkiSCazSWGnVwWNl471X1/i6QlrRmISxs2Bd6Bpv9lo16qEFwp3M THWRCP/9dISFHEs4V7acFRrg9jS7qUqzxHLpgTaUdFPpClvbFbven0SY7081/noh8I+q NtSCPXUesY5zfQc07AdaUaO6aJin7jADykHZA= MIME-Version: 1.0 Sender: arsalan.tavakoli@gmail.com Received: by 10.103.102.17 with SMTP id e17mr1162676mum.119.1236361133343; Fri, 06 Mar 2009 09:38:53 -0800 (PST) In-Reply-To: <49B15E6E.1000705@gmail.com> References: <20090304153927.4A1C43A6CD4@core3.amsl.com> <49B14332.10507@ekasystems.com> <49B15E6E.1000705@gmail.com> Date: Fri, 6 Mar 2009 09:38:53 -0800 X-Google-Sender-Auth: b331fd7952690593 Message-ID: <69306dde0903060938o20ecb259q36c264e625f15fbd@mail.gmail.com> From: Arsalan Tavakoli To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=0016363ba6602ac494046476c2f4 Cc: roll@ietf.org, iesg@ietf.org Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 17:38:25 -0000 --0016363ba6602ac494046476c2f4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Comments inline. On Fri, Mar 6, 2009 at 9:33 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Tim Winter a =E9crit : > >> I am in support of the modified charter. >> >> The ROLL WG has covered a lot of ground in examining the requirements of >> an >> LLN routing protocol with respect to various applications, and the >> protocol >> survey effort does indicate that no existing IETF protocol without >> modification will be a good fit for the requirements. >> >> The modified charter will allow the WG to continue with its current >> momentum and either specify modifications to an existing IETF protocol o= r >> a >> new protocol in order to meet the demand of industry. >> > > What do you mean: specify modifications to existing protocol or new > protocol? Both? Only one? > > What's the goal of this ambiguous language? > > Alex I don't understand how this is ambiguous. As has been discussed consistently, ROLL needs a specification for a routing protocol, and this specification can stem from modifications to an existing IETF protocol, or from something new altogether; no stance is taken on which one it should be (and hence the 'ambiguous' text), and I presume that when we move to the next stage proposals of both of these types will be put forward, allowing the working group to debate their merits. - Arsalan > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --0016363ba6602ac494046476c2f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Comments inline.

On Fri, Mar 6, 2009 at 9= :33 AM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
Tim Winter a =E9crit :

I am in support of the modified charter.

The ROLL WG has covered a lot of ground in examining the requirements of an=
LLN routing protocol with respect to various applications, and the protocol=
survey effort does indicate that no existing IETF protocol without
modification will be a good fit for the requirements.

The modified charter will allow the WG to continue with its current
momentum and either specify modifications to an existing IETF protocol or a=
new protocol in order to meet the demand of industry.

What do you mean: specify modifications to existing protocol or new protoco= l? =A0Both? =A0Only one?

What's the goal of this ambiguous language?

Alex

I don't understand how this is amb= iguous. =A0As has been discussed consistently, ROLL needs a specification f= or a routing protocol, and this specification can stem from modifications t= o an existing IETF protocol, or from something new altogether; no stance is= taken on which one it should be (and hence the 'ambiguous' text), = and I presume that when we move to the next stage proposals of both of thes= e types will be put forward, allowing the working group to debate their mer= its.

- Arsalan

=A0



_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

--0016363ba6602ac494046476c2f4-- From gnawali@gmail.com Fri Mar 6 09:47:30 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89A4228C21D; Fri, 6 Mar 2009 09:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5K+3wqlbdBK; Fri, 6 Mar 2009 09:47:29 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by core3.amsl.com (Postfix) with ESMTP id 1AE213A6AD0; Fri, 6 Mar 2009 09:47:29 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so307764ana.4 for ; Fri, 06 Mar 2009 09:47:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=OXvhaoRoTpj3inTBlpe302v4V+ePtrjlBa8dxhMJ6qU=; b=L2JpFaxwBYo2SjpXOABOj1dBRJ63LJFXwmjXVwAU/o+KqrloHr/ZT29RgzLU/VU1dg +2To0C1dtR6JZy5d0DefVjsQw679/QQUx5YRwBzXE1C6oS9IrWsnpo5Lcs+jMLW02Ir5 Bz8bWnIOikvl/vN1X1jn7MZG6nzs6Xfz56taQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Oi2AQarjvdOYHVsSgce9KrF6Rnc7YTUGObHZReMMB+XgfqKujVi9C5ZsN80zn1h1gb Atx3hFP3bIWeDiOAqXPOKJArmsl8Mbq1QS65HC0SCyVesQcDwbjJWMuEeDYAhSWCEiA7 XLKA/KFGvHJ+64d3DAajypsHu3iHS/IZGHzH8= MIME-Version: 1.0 Received: by 10.220.98.197 with SMTP id r5mr944238vcn.69.1236361679431; Fri, 06 Mar 2009 09:47:59 -0800 (PST) In-Reply-To: <49B14332.10507@ekasystems.com> References: <20090304153927.4A1C43A6CD4@core3.amsl.com> <49B14332.10507@ekasystems.com> Date: Fri, 6 Mar 2009 09:47:59 -0800 Message-ID: From: Omprakash Gnawali To: iesg@ietf.org, roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 17:47:30 -0000 I support the modified charter. Lots of work to do. Lets get started. - om_p On Fri, Mar 6, 2009 at 7:37 AM, Tim Winter wrot= e: > I am in support of the modified charter. > > The ROLL WG has covered a lot of ground in examining the requirements of = an > LLN routing protocol with respect to various applications, and the protoc= ol > survey effort does indicate that no existing IETF protocol without > modification will be a good fit for the requirements. > > The modified charter will allow the WG to continue with its current > momentum and either specify modifications to an existing IETF protocol or= a > new protocol in order to meet the demand of industry. > > -Tim > > > > IESG Secretary wrote: >> A modified charter has been submitted for the Routing Over Low power and >> Lossy networks working group in the Routing Area of the IETF. =A0The IES= G >> has not made any determination as yet. =A0The modified charter is provid= ed >> below for informational purposes only. =A0Please send your comments to t= he >> IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. >> >> Routing Over Low power and Lossy networks (roll) >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >> Last Modified: 2009-02-04 >> >> Current Status: Active Working Group >> >> Additional information is available at tools.ietf.org/wg/roll >> >> Chair(s): >> >> JP Vasseur >> David Culler >> >> Routing Area Director(s): >> >> Ross Callon >> David Ward >> >> Routing Area Advisor: >> David Ward >> >> Mailing Lists: >> >> General Discussion: roll@ietf.org >> To Subscribe: http://www.ietf.org/mailman/listinfo/roll >> Archive: http://www.ietf.org/mail-archive/web/roll/ >> >> Description of Working Group: >> >> 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 >> =A0 most if not all traffic can be point to multipoint). >> - In most cases, LLNs will be employed over link layers with restricted >> =A0 frame-sizes, thus a routing protocol for LLNs should be specifically >> adapted >> =A0 for such link layers. >> - LLN routing protocols have to be very careful when trading off >> efficiency >> =A0 for generality; many LLN nodes do not have resources to waste. >> >> These specific properties cause LLNs to have specific routing >> requirements. >> As shown in a protocol survey existing routing protocols (in their curre= nt >> >> form) such as OSPF, IS-IS, AODV, and OLSR, do not meet 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 industria= l >> >> 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 varyi= ng >> loss >> characteristics and connectivity while permitting low-power operation wi= th >> >> 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 ne= ed >> 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. >> >> Work Items: >> >> - Specification of routing metrics used in path calculation. This >> includes >> =A0 static and dynamic link/node attributes required for routing in LLNs= . >> >> - Provide an architectural framework for routing and path selection at >> =A0 Layer 3 (Routing for LLN Architecture) that addresses such issues as >> =A0 whether LLN routing require a distributed and/or centralized path >> computation >> =A0 models, whether additional hierarchy is necessary and how it is appl= ied. >> >> =A0 Manageability will be considered with each approach, along with vari= ous >> >> =A0 trade-offs for maintaining low power operation, including the presen= ce >> >> =A0 of non-trivial loss and networks with a very large number of nodes. >> >> - Produce a routing security framework for routing in LLNs. >> >> - Protocol work: In light of the application specific routing >> requirements, the >> =A0 Working Group will either specify a new protocol and/or will select = an >> existing >> =A0 routing protocol (with the appropriate extensions in cooperation wit= h >> the >> =A0 relevant Working Group). >> >> - Documentation of applicability statement of ROLL routing protocols. >> >> Goals and Milestones: >> >> Done Submit Routing requirements for Industrial applications to the IESG >> to be considered as an Informational RFC. >> >> Done Submit Routing requirements for Connected Home networks application= s >> to the IESG to be considered as an Informational RFC. >> >> Done Submit Routing requirements for Building applications to the IESG t= o >> be considered as an Informational RFC. >> >> Done Submit Routing requirements for Urban networks applications to the >> IESG to be considered as an Informational RFC. >> >> July 2009 Submit Routing metrics for LLNs document to the IESG to be >> considered as a Proposed Standard. >> >> Feb 2009 Submit Protocol Survey to the IESG to be considered as an >> Informational RFC. >> >> April 2009 Submit Security Framework to the IESG to be considered as an >> Informational RFC >> >> May 2009 =A0 Submit the Routing for LLNs Architecture document to the IE= SG >> as an Informational RFC. >> >> July 2009 =A0Submit first draft of ROLL routing protocol specification a= s >> Proposed Standard. >> >> Nov 2009 =A0 Submit first draft of the MIB module of the ROLL routing >> protocol specification. >> >> Feb 2010 =A0 Submit the ROLL routing protocol specification to the IESG = as >> Proposed Standard. >> >> March 2010 Submit the MIB module of the ROLL routing protocol >> specification to the IESG as Proposed Standard. >> >> April 2010 Evaluate WG progress, recharter or close. >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From dokaspar.ietf@gmail.com Fri Mar 6 10:00:21 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 015FA3A67F3; Fri, 6 Mar 2009 10:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vuHh50+GrDd; Fri, 6 Mar 2009 10:00:19 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id 5260E3A6835; Fri, 6 Mar 2009 10:00:19 -0800 (PST) Received: by gxk22 with SMTP id 22so1058233gxk.13 for ; Fri, 06 Mar 2009 10:00:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=hrSH05J1olik8WB2QyslIUBtAkCFV+LuUEEup+j1VoM=; b=Uneppm7R2h9newjLjiprHovsBqS4yd2paDdY6n1Gry4lyj20zuSN5c78pup/stuXt9 Uj6NyPklOqhVwisACvtT4E/2UVD2m8H5khq2QpBqbUKfDABMuhGGNU0+jlVpKuZARYWa eMjDOeRkmueYOWfnJ929ysVtGG70FiZly2+7Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=ntRM8QKb2DEUD5ciN9kP9hqV9BKo9lLF5i5rsL9CA5HzNMzoeUSmHPM90aMgOk28jJ C500IBp2/D7iAutJNM++s1VRhy+RjlsS/+mbK5P7cunDfATdTgIKFxHOB1nVEIbebPF0 yWzuJBUlks3nvgOx5otKOZ9NdhTUF3q5I7Ytg= MIME-Version: 1.0 Received: by 10.220.96.146 with SMTP id h18mr967811vcn.37.1236362449159; Fri, 06 Mar 2009 10:00:49 -0800 (PST) In-Reply-To: References: <20090304153927.4A1C43A6CD4@core3.amsl.com> <49B14332.10507@ekasystems.com> Date: Fri, 6 Mar 2009 19:00:49 +0100 Message-ID: <2a3692de0903061000m2b195270hb62941c7db0273f0@mail.gmail.com> From: Dominik Kaspar To: iesg@ietf.org, roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 18:00:21 -0000 I am also in favor of the modified charter. Dominik On Fri, Mar 6, 2009 at 6:47 PM, Omprakash Gnawali wrote= : > I support the modified charter. Lots of work to do. Lets get started. > > - om_p > > On Fri, Mar 6, 2009 at 7:37 AM, Tim Winter wr= ote: >> I am in support of the modified charter. >> >> The ROLL WG has covered a lot of ground in examining the requirements of= an >> LLN routing protocol with respect to various applications, and the proto= col >> survey effort does indicate that no existing IETF protocol without >> modification will be a good fit for the requirements. >> >> The modified charter will allow the WG to continue with its current >> momentum and either specify modifications to an existing IETF protocol o= r a >> new protocol in order to meet the demand of industry. >> >> -Tim >> >> >> >> IESG Secretary wrote: >>> A modified charter has been submitted for the Routing Over Low power an= d >>> Lossy networks working group in the Routing Area of the IETF. =A0The IE= SG >>> has not made any determination as yet. =A0The modified charter is provi= ded >>> below for informational purposes only. =A0Please send your comments to = the >>> IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. >>> >>> Routing Over Low power and Lossy networks (roll) >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >>> Last Modified: 2009-02-04 >>> >>> Current Status: Active Working Group >>> >>> Additional information is available at tools.ietf.org/wg/roll >>> >>> Chair(s): >>> >>> JP Vasseur >>> David Culler >>> >>> Routing Area Director(s): >>> >>> Ross Callon >>> David Ward >>> >>> Routing Area Advisor: >>> David Ward >>> >>> Mailing Lists: >>> >>> General Discussion: roll@ietf.org >>> To Subscribe: http://www.ietf.org/mailman/listinfo/roll >>> Archive: http://www.ietf.org/mail-archive/web/roll/ >>> >>> Description of Working Group: >>> >>> 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 >>> =A0 most if not all traffic can be point to multipoint). >>> - In most cases, LLNs will be employed over link layers with restricted >>> =A0 frame-sizes, thus a routing protocol for LLNs should be specificall= y >>> adapted >>> =A0 for such link layers. >>> - LLN routing protocols have to be very careful when trading off >>> efficiency >>> =A0 for generality; many LLN nodes do not have resources to waste. >>> >>> These specific properties cause LLNs to have specific routing >>> requirements. >>> As shown in a protocol survey existing routing protocols (in their curr= ent >>> >>> form) such as OSPF, IS-IS, AODV, and OLSR, do not meet 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 industri= al >>> >>> 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 document= s >>> 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 vary= ing >>> loss >>> characteristics and connectivity while permitting low-power operation w= ith >>> >>> 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 n= eed >>> to >>> consider the transport characteristic the routing protocol messages wil= l >>> 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. >>> >>> Work Items: >>> >>> - Specification of routing metrics used in path calculation. This >>> includes >>> =A0 static and dynamic link/node attributes required for routing in LLN= s. >>> >>> - Provide an architectural framework for routing and path selection at >>> =A0 Layer 3 (Routing for LLN Architecture) that addresses such issues a= s >>> =A0 whether LLN routing require a distributed and/or centralized path >>> computation >>> =A0 models, whether additional hierarchy is necessary and how it is app= lied. >>> >>> =A0 Manageability will be considered with each approach, along with var= ious >>> >>> =A0 trade-offs for maintaining low power operation, including the prese= nce >>> >>> =A0 of non-trivial loss and networks with a very large number of nodes. >>> >>> - Produce a routing security framework for routing in LLNs. >>> >>> - Protocol work: In light of the application specific routing >>> requirements, the >>> =A0 Working Group will either specify a new protocol and/or will select= an >>> existing >>> =A0 routing protocol (with the appropriate extensions in cooperation wi= th >>> the >>> =A0 relevant Working Group). >>> >>> - Documentation of applicability statement of ROLL routing protocols. >>> >>> Goals and Milestones: >>> >>> Done Submit Routing requirements for Industrial applications to the IES= G >>> to be considered as an Informational RFC. >>> >>> Done Submit Routing requirements for Connected Home networks applicatio= ns >>> to the IESG to be considered as an Informational RFC. >>> >>> Done Submit Routing requirements for Building applications to the IESG = to >>> be considered as an Informational RFC. >>> >>> Done Submit Routing requirements for Urban networks applications to the >>> IESG to be considered as an Informational RFC. >>> >>> July 2009 Submit Routing metrics for LLNs document to the IESG to be >>> considered as a Proposed Standard. >>> >>> Feb 2009 Submit Protocol Survey to the IESG to be considered as an >>> Informational RFC. >>> >>> April 2009 Submit Security Framework to the IESG to be considered as an >>> Informational RFC >>> >>> May 2009 =A0 Submit the Routing for LLNs Architecture document to the I= ESG >>> as an Informational RFC. >>> >>> July 2009 =A0Submit first draft of ROLL routing protocol specification = as >>> Proposed Standard. >>> >>> Nov 2009 =A0 Submit first draft of the MIB module of the ROLL routing >>> protocol specification. >>> >>> Feb 2010 =A0 Submit the ROLL routing protocol specification to the IESG= as >>> Proposed Standard. >>> >>> March 2010 Submit the MIB module of the ROLL routing protocol >>> specification to the IESG as Proposed Standard. >>> >>> April 2010 Evaluate WG progress, recharter or close. >>> >>> _______________________________________________ >>> IETF-Announce mailing list >>> IETF-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-announce >>> >> >> _______________________________________________ >> 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 > From anand@ekasystems.com Fri Mar 6 10:03:02 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3B063A6BDF for ; Fri, 6 Mar 2009 10:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.634 X-Spam-Level: X-Spam-Status: No, score=-1.634 tagged_above=-999 required=5 tests=[AWL=0.965, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Os-74ZLJWOsB for ; Fri, 6 Mar 2009 10:03:02 -0800 (PST) Received: from smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by core3.amsl.com (Postfix) with SMTP id 5454B3A67F3 for ; Fri, 6 Mar 2009 10:03:02 -0800 (PST) Received: (qmail 47330 invoked from network); 6 Mar 2009 17:56:53 -0000 Received: from unknown (HELO ?192.168.0.207?) (anand@209.48.242.70 with plain) by smtp104.biz.mail.re2.yahoo.com with SMTP; 6 Mar 2009 17:56:52 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <49B165B5.7070001@ekasystems.com> Date: Fri, 06 Mar 2009 13:04:37 -0500 From: "M. B. Anand" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: iesg@ietf.org, ROLL WG References: <20090304153927.4A1C43A6CD4@core3.amsl.com> In-Reply-To: <20090304153927.4A1C43A6CD4@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 18:03:02 -0000 I support this re-charter for ROLL. The proposed text has gone through a lot of review on the ROLL list and incorporation of comments. And there are many participants waiting, ready and willing to contribute to the work ahead . Let's move ahead. Regards, Anand. > A modified charter has been submitted for the Routing Over Low power and > Lossy networks working group in the Routing Area of the IETF. The IESG > has not made any determination as yet. The modified charter is provided > below for informational purposes only. Please send your comments to the > IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. > > Routing Over Low power and Lossy networks (roll) > ================================================== > Last Modified: 2009-02-04 > > Current Status: Active Working Group > > Additional information is available at tools.ietf.org/wg/roll > > Chair(s): > > JP Vasseur > David Culler > > Routing Area Director(s): > > Ross Callon > David Ward > > Routing Area Advisor: > David Ward > > Mailing Lists: > > General Discussion: roll@ietf.org > To Subscribe: http://www.ietf.org/mailman/listinfo/roll > Archive: http://www.ietf.org/mail-archive/web/roll/ > > Description of Working Group: > > 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. > As shown in a protocol survey existing routing protocols (in their current > > form) such as OSPF, IS-IS, AODV, and OLSR, do not meet 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. > > 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: In light of the application specific routing > requirements, the > Working Group will either specify a new protocol and/or will select an > existing > routing protocol (with the appropriate extensions in cooperation with > the > relevant Working Group). > > - Documentation of applicability statement of ROLL routing protocols. > > Goals and Milestones: > > Done Submit Routing requirements for Industrial applications to the IESG > to be considered as an Informational RFC. > > Done Submit Routing requirements for Connected Home networks applications > to the IESG to be considered as an Informational RFC. > > Done Submit Routing requirements for Building applications to the IESG to > be considered as an Informational RFC. > > Done Submit Routing requirements for Urban networks applications to the > IESG to be considered as an Informational RFC. > > July 2009 Submit Routing metrics for LLNs document to the IESG to be > considered as a Proposed Standard. > > Feb 2009 Submit Protocol Survey to the IESG to be considered as an > Informational RFC. > > April 2009 Submit Security Framework to the IESG to be considered as an > Informational RFC > > May 2009 Submit the Routing for LLNs Architecture document to the IESG > as an Informational RFC. > > July 2009 Submit first draft of ROLL routing protocol specification as > Proposed Standard. > > Nov 2009 Submit first draft of the MIB module of the ROLL routing > protocol specification. > > Feb 2010 Submit the ROLL routing protocol specification to the IESG as > Proposed Standard. > > March 2010 Submit the MIB module of the ROLL routing protocol > specification to the IESG as Proposed Standard. > > April 2010 Evaluate WG progress, recharter or close. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > From alexandru.petrescu@gmail.com Fri Mar 6 10:11:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6F6C3A6CD3; Fri, 6 Mar 2009 10:11:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRCQ-9ETCb-L; Fri, 6 Mar 2009 10:11:17 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id B84733A6C59; Fri, 6 Mar 2009 10:11:16 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n26IBgwa020437; Fri, 6 Mar 2009 19:11:42 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n26IBg0I017262; Fri, 6 Mar 2009 19:11:42 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n26IBfec009720; Fri, 6 Mar 2009 19:11:41 +0100 Message-ID: <49B1675D.8060805@gmail.com> Date: Fri, 06 Mar 2009 19:11:41 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Arsalan Tavakoli References: <20090304153927.4A1C43A6CD4@core3.amsl.com> <49B14332.10507@ekasystems.com> <49B15E6E.1000705@gmail.com> <69306dde0903060938o20ecb259q36c264e625f15fbd@mail.gmail.com> In-Reply-To: <69306dde0903060938o20ecb259q36c264e625f15fbd@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org, iesg@ietf.org Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 18:11:17 -0000 Arsalan Tavakoli a écrit : > Comments inline. > > On Fri, Mar 6, 2009 at 9:33 AM, Alexandru Petrescu > > wrote: > > Tim Winter a écrit : > > I am in support of the modified charter. > > The ROLL WG has covered a lot of ground in examining the > requirements of an > LLN routing protocol with respect to various applications, and > the protocol > survey effort does indicate that no existing IETF protocol without > modification will be a good fit for the requirements. > > The modified charter will allow the WG to continue with its current > momentum and either specify modifications to an existing IETF > protocol or a > new protocol in order to meet the demand of industry. > > > What do you mean: specify modifications to existing protocol or new > protocol? Both? Only one? > > What's the goal of this ambiguous language? > > Alex > > > I don't understand how this is ambiguous. As has been discussed > consistently, ROLL needs a specification for a routing protocol, and > this specification can stem from modifications to an existing IETF > protocol, or from something new altogether; no stance is taken on which > one it should be (and hence the 'ambiguous' text), and I presume that > when we move to the next stage proposals of both of these types will be > put forward, allowing the working group to debate their merits. What next stage? Another round of protocols-survey to definitely answer debates before the July milestone "first draft of ROLL routing protocol spec"? The protocols-survey draft was Last Call'ed, I suppose it will be sent soon to IESG (I haven't seen the write-up). Do you mean another protocol evaluation document? Alex From alexandru.petrescu@gmail.com Fri Mar 6 10:14:06 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DD603A691F; Fri, 6 Mar 2009 10:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCyxh9kKvTx1; Fri, 6 Mar 2009 10:14:00 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 2D2ED3A6A85; Fri, 6 Mar 2009 10:14:00 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n26IERgE026994; Fri, 6 Mar 2009 19:14:27 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n26IER8O020243; Fri, 6 Mar 2009 19:14:27 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n26IERIU010108; Fri, 6 Mar 2009 19:14:27 +0100 Message-ID: <49B16803.4000506@gmail.com> Date: Fri, 06 Mar 2009 19:14:27 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "M. B. Anand" References: <20090304153927.4A1C43A6CD4@core3.amsl.com> <49B165B5.7070001@ekasystems.com> In-Reply-To: <49B165B5.7070001@ekasystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG , iesg@ietf.org Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 18:14:06 -0000 Ah this impatience spells risks to me... Lots of reviews? HAs the multicast/multipoint been disambiguated? What does 'multipoint' mean please? Alex M. B. Anand a écrit : > I support this re-charter for ROLL. > > The proposed text has gone through a lot of review on the ROLL list and > incorporation of comments. And there are many participants waiting, > ready and willing to contribute to the work ahead . Let's move ahead. > > Regards, > Anand. >> A modified charter has been submitted for the Routing Over Low power and >> Lossy networks working group in the Routing Area of the IETF. The IESG >> has not made any determination as yet. The modified charter is provided >> below for informational purposes only. Please send your comments to the >> IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. >> >> Routing Over Low power and Lossy networks (roll) >> ================================================== >> Last Modified: 2009-02-04 >> >> Current Status: Active Working Group >> >> Additional information is available at tools.ietf.org/wg/roll >> Chair(s): >> >> JP Vasseur David Culler >> Routing Area Director(s): >> >> Ross Callon David Ward >> Routing Area Advisor: >> David Ward >> Mailing Lists: >> >> General Discussion: roll@ietf.org >> To Subscribe: http://www.ietf.org/mailman/listinfo/roll >> Archive: http://www.ietf.org/mail-archive/web/roll/ >> >> Description of Working Group: >> >> 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. As shown in a protocol survey existing routing protocols >> (in their current >> >> form) such as OSPF, IS-IS, AODV, and OLSR, do not meet 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. >> >> 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: In light of the application specific routing >> requirements, the Working Group will either specify a new protocol >> and/or will select an >> existing routing protocol (with the appropriate extensions in >> cooperation with >> the relevant Working Group). >> >> - Documentation of applicability statement of ROLL routing protocols. >> >> Goals and Milestones: >> >> Done Submit Routing requirements for Industrial applications to the IESG >> to be considered as an Informational RFC. >> >> Done Submit Routing requirements for Connected Home networks applications >> to the IESG to be considered as an Informational RFC. >> >> Done Submit Routing requirements for Building applications to the IESG to >> be considered as an Informational RFC. >> >> Done Submit Routing requirements for Urban networks applications to the >> IESG to be considered as an Informational RFC. >> >> July 2009 Submit Routing metrics for LLNs document to the IESG to be >> considered as a Proposed Standard. >> >> Feb 2009 Submit Protocol Survey to the IESG to be considered as an >> Informational RFC. >> >> April 2009 Submit Security Framework to the IESG to be considered as an >> Informational RFC >> >> May 2009 Submit the Routing for LLNs Architecture document to the IESG >> as an Informational RFC. >> >> July 2009 Submit first draft of ROLL routing protocol specification as >> Proposed Standard. >> >> Nov 2009 Submit first draft of the MIB module of the ROLL routing >> protocol specification. >> >> Feb 2010 Submit the ROLL routing protocol specification to the IESG as >> Proposed Standard. >> >> March 2010 Submit the MIB module of the ROLL routing protocol >> specification to the IESG as Proposed Standard. >> >> April 2010 Evaluate WG progress, recharter or close. >> >> _______________________________________________ >> 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 > From alexandru.petrescu@gmail.com Fri Mar 6 10:49:13 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A11193A6A87; Fri, 6 Mar 2009 10:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7sC9puFywOf; Fri, 6 Mar 2009 10:49:12 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 7D70D3A691F; Fri, 6 Mar 2009 10:49:12 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n26IlpVm014406; Fri, 6 Mar 2009 19:47:51 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n26IncLf012202; Fri, 6 Mar 2009 19:49:38 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n26Inc7d014570; Fri, 6 Mar 2009 19:49:38 +0100 Message-ID: <49B17042.1040006@gmail.com> Date: Fri, 06 Mar 2009 19:49:38 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Arsalan Tavakoli References: <20090304153927.4A1C43A6CD4@core3.amsl.com> <49B14332.10507@ekasystems.com> <49B15E6E.1000705@gmail.com> <69306dde0903060938o20ecb259q36c264e625f15fbd@mail.gmail.com> <49B1675D.8060805@gmail.com> <69306dde0903061032w5f592e20le5ba28a1482c1fbe@mail.gmail.com> In-Reply-To: <69306dde0903061032w5f592e20le5ba28a1482c1fbe@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org, iesg@ietf.org Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 18:49:13 -0000 Arsalan Tavakoli a écrit : > > > On Fri, Mar 6, 2009 at 10:11 AM, Alexandru Petrescu > > wrote: > > Arsalan Tavakoli a écrit : > > Comments inline. > > > On Fri, Mar 6, 2009 at 9:33 AM, Alexandru Petrescu > > >> wrote: > > Tim Winter a écrit : > > I am in support of the modified charter. > > The ROLL WG has covered a lot of ground in examining the > requirements of an > LLN routing protocol with respect to various > applications, and > the protocol > survey effort does indicate that no existing IETF > protocol without > modification will be a good fit for the requirements. > > The modified charter will allow the WG to continue with > its current > momentum and either specify modifications to an existing IETF > protocol or a > new protocol in order to meet the demand of industry. > > > What do you mean: specify modifications to existing protocol > or new > protocol? Both? Only one? > > What's the goal of this ambiguous language? > > Alex > > > I don't understand how this is ambiguous. As has been discussed > consistently, ROLL needs a specification for a routing protocol, > and this specification can stem from modifications to an > existing IETF protocol, or from something new altogether; no > stance is taken on which one it should be (and hence the > 'ambiguous' text), and I presume that when we move to the next > stage proposals of both of these types will be put forward, > allowing the working group to debate their merits. > > > What next stage? Another round of protocols-survey to definitely > answer debates before the July milestone "first draft of ROLL > routing protocol spec"? > > The protocols-survey draft was Last Call'ed, I suppose it will be > sent soon to IESG (I haven't seen the write-up). Do you mean > another protocol evaluation document? > > Alex > > > There is only one protocols-survey, and that has been last called. The > next stage is where ROLL must put forth a protocol specification (and > possibly more than one), Do you mean something like this: (1) _the_ ROLL protocol - WG item (2) OLSR-adaptation to make it look like the ROLL protocol - a WG item (3) DYMO-adaptation for same goal (4) NEMO-adaptation same Is it this? Alex From jvasseur@cisco.com Fri Mar 6 11:23:50 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DF7A28C2D6; Fri, 6 Mar 2009 11:23:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.145 X-Spam-Level: X-Spam-Status: No, score=-10.145 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZ6qX24Gappb; Fri, 6 Mar 2009 11:23:49 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5C04828C149; Fri, 6 Mar 2009 11:23:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,316,1233532800"; d="scan'208";a="35570552" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 06 Mar 2009 19:24:17 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n26JOHxH016560; Fri, 6 Mar 2009 20:24:17 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n26JOHLa018600; Fri, 6 Mar 2009 19:24:17 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Mar 2009 20:24:17 +0100 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Mar 2009 20:24:17 +0100 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <49B1675D.8060805@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Mar 2009 20:24:15 +0100 References: <20090304153927.4A1C43A6CD4@core3.amsl.com> <49B14332.10507@ekasystems.com> <49B15E6E.1000705@gmail.com> <69306dde0903060938o20ecb259q36c264e625f15fbd@mail.gmail.com> <49B1675D.8060805@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 06 Mar 2009 19:24:17.0420 (UTC) FILETIME=[245B9CC0:01C99E91] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4799; t=1236367458; x=1237231458; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20WG=20Review=3A=20Recharter=20o f=20Routing=20Over=20Low=20power=20and=20Lossy=20networks=20 (roll) |Sender:=20; bh=gmraM6bJUR6HRB5FFncFlHQQqfoB6KNUnJGtyUtbu3Q=; b=p+KJC5IvHCILOoIblSYJDgdjbKOOBkYYlHtv0uBywUrGgMQ4abj0m8Ofww 4tat2uR0LPnKZ5RrOZWio+CoFz0ho+FrBQ5Ybdva6uBgB7ButVe0os8axhQR PcqMYlSNiv; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org, iesg@ietf.org Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 19:23:50 -0000 Dear Alex, As you can see on the list, there is a good number of people =20 supporting the new charter and for whom the next stage is clear. Let =20 me restate the situation one more time (note that both co-chairs did =20 this many many times already) and there is a good consensus. Note also =20= that we addressed your points during the review of the WG charter, =20 before submitting the proposal to the IESG and it looks like we are =20 restarting again. Anyway let me try one last time. 1) We were tasked to first clearly spell out the ROLL routing =20 requirements: all of them are in publication request, under IESG =20 review with a very good WG consensus. 2) We had to evaluate whether we could find an existing routing =20 protocols that would meet our requirements (the protocol survey), this =20= was the only purpose of this document. Again we had a good consensus, =20= the answer being that there is no existing routing protocols =20 satisfying the specific routing requirements of ROLL. 3) As pointed out MANY times on the list, this does not mean that an =20 existing protocol could not be extended (e.g. MANET, ...) to satisfy =20 these requirement. At this stage we are not chartered to do any =20 protocol work, thus the proposal for rechartering. Thus the new =20 proposed charter explicitly states that we could either adapt an =20 existing protocol or design a new routing protocol. At this stage we =20 will go back to the routing requirements documents of course. =20 Otherwise, what would be the point of having worked for months on =20 these requirements that have been written by recognized expert in the =20= field. What comes next ? 1) Wait until we get the re-chartering green light from the IESG. 2) Start working on protocol specification in light of the =20 requirements. Nothing different than any regular WG. 3) If we have multiple candidates, the WG will select a solution, =20 based on consensus. The reason why you see so many people get a bit impatient is because =20 we have an excellent dynamic in this WG, with lots of recognized =20 experts in sensors and routing, we all agree on the requirements and =20 we now need to move forward because the industry is waiting for an IP-=20= based solution. Bear in mind that this is the objective, the work =20 group is not putting so much effort for the sake of an intellectual =20 exercise but because products are being design and a routing solution =20= is required. If this is still not clear, I'll be happy to spend some time with you =20= in SFO. Thanks. JP. On Mar 6, 2009, at 7:11 PM, Alexandru Petrescu wrote: > Arsalan Tavakoli a =E9crit : >> Comments inline. >> On Fri, Mar 6, 2009 at 9:33 AM, Alexandru Petrescu = > > wrote: >> Tim Winter a =E9crit : >> I am in support of the modified charter. >> The ROLL WG has covered a lot of ground in examining the >> requirements of an >> LLN routing protocol with respect to various applications, and >> the protocol >> survey effort does indicate that no existing IETF protocol =20 >> without >> modification will be a good fit for the requirements. >> The modified charter will allow the WG to continue with its =20= >> current >> momentum and either specify modifications to an existing IETF >> protocol or a >> new protocol in order to meet the demand of industry. >> What do you mean: specify modifications to existing protocol or =20= >> new >> protocol? Both? Only one? >> What's the goal of this ambiguous language? >> Alex >> I don't understand how this is ambiguous. As has been discussed =20 >> consistently, ROLL needs a specification for a routing protocol, =20 >> and this specification can stem from modifications to an existing =20 >> IETF protocol, or from something new altogether; no stance is taken =20= >> on which one it should be (and hence the 'ambiguous' text), and I =20 >> presume that when we move to the next stage proposals of both of =20 >> these types will be put forward, allowing the working group to =20 >> debate their merits. > > What next stage? Another round of protocols-survey to definitely =20 > answer debates before the July milestone "first draft of ROLL =20 > routing protocol spec"? > > The protocols-survey draft was Last Call'ed, I suppose it will be =20 > sent soon to IESG (I haven't seen the write-up). Do you mean =20 > another protocol evaluation document? > > Alex > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Fri Mar 6 12:14:37 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 466B63A659C for ; Fri, 6 Mar 2009 12:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.783 X-Spam-Level: X-Spam-Status: No, score=-1.783 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44FbEQfLDFvo for ; Fri, 6 Mar 2009 12:14:36 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 1592D3A6855 for ; Fri, 6 Mar 2009 12:14:34 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 4045AD4804C; Fri, 6 Mar 2009 21:15:00 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 8697CD480F0; Fri, 6 Mar 2009 21:14:57 +0100 (CET) Message-ID: <49B18439.8050703@gmail.com> Date: Fri, 06 Mar 2009 21:14:49 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: JP Vasseur References: <20090304153927.4A1C43A6CD4@core3.amsl.com> <49B14332.10507@ekasystems.com> <49B15E6E.1000705@gmail.com> <69306dde0903060938o20ecb259q36c264e625f15fbd@mail.gmail.com> <49B1675D.8060805@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090305-1, 05/03/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 20:14:37 -0000 [SFO - I won't be there, sorry, maybe next time.] JP thanks for the explanation of the procedure. As you put it sounds reasonable, except this quirk (and another posted separately). Requirements - then I will look again at the recently demanded feedback. ('experts' - I hear it as an overly elitist, touching arrogance, yet necessary attitude one has to label self before talking Routing. And I don't agree with it, please don't mention it. Rant off.) Alex JP Vasseur a écrit : > Dear Alex, > > As you can see on the list, there is a good number of people > supporting the new charter and for whom the next stage is clear. Let > me restate the situation one more time (note that both co-chairs did > this many many times already) and there is a good consensus. Note > also that we addressed your points during the review of the WG > charter, before submitting the proposal to the IESG and it looks like > we are restarting again. > > Anyway let me try one last time. > > 1) We were tasked to first clearly spell out the ROLL routing > requirements: all of them are in publication request, under IESG > review with a very good WG consensus. 2) We had to evaluate whether > we could find an existing routing protocols that would meet our > requirements (the protocol survey), this was the only purpose of this > document. Again we had a good consensus, the answer being that there > is no existing routing protocols satisfying the specific routing > requirements of ROLL. 3) As pointed out MANY times on the list, this > does not mean that an existing protocol could not be extended (e.g. > MANET, ...) to satisfy these requirement. At this stage we are not > chartered to do any protocol work, thus the proposal for > rechartering. Thus the new proposed charter explicitly states that we > could either adapt an existing protocol or design a new routing > protocol. At this stage we will go back to the routing requirements > documents of course. Otherwise, what would be the point of having > worked for months on these requirements that have been written by > recognized expert in the field. > > What comes next ? > > 1) Wait until we get the re-chartering green light from the IESG. 2) > Start working on protocol specification in light of the > requirements. Nothing different than any regular WG. 3) If we have > multiple candidates, the WG will select a solution, based on > consensus. > > The reason why you see so many people get a bit impatient is because > we have an excellent dynamic in this WG, with lots of recognized > experts in sensors and routing, we all agree on the requirements and > we now need to move forward because the industry is waiting for an > IP-based solution. Bear in mind that this is the objective, the work > group is not putting so much effort for the sake of an intellectual > exercise but because products are being design and a routing > solution is required. > > If this is still not clear, I'll be happy to spend some time with you > in SFO. > > Thanks. > > JP. > > On Mar 6, 2009, at 7:11 PM, Alexandru Petrescu wrote: > >> Arsalan Tavakoli a écrit : >>> Comments inline. On Fri, Mar 6, 2009 at 9:33 AM, Alexandru >>> Petrescu >> > wrote: Tim Winter a écrit >>> : I am in support of the modified charter. The ROLL WG has >>> covered a lot of ground in examining the requirements of an LLN >>> routing protocol with respect to various applications, and the >>> protocol survey effort does indicate that no existing IETF >>> protocol without modification will be a good fit for the >>> requirements. The modified charter will allow the WG to continue >>> with its current momentum and either specify modifications to an >>> existing IETF protocol or a new protocol in order to meet the >>> demand of industry. What do you mean: specify modifications to >>> existing protocol or new protocol? Both? Only one? What's the >>> goal of this ambiguous language? Alex I don't understand how this >>> is ambiguous. As has been discussed consistently, ROLL needs a >>> specification for a routing protocol, and this specification can >>> stem from modifications to an existing IETF protocol, or from >>> something new altogether; no stance is taken on which one it >>> should be (and hence the 'ambiguous' text), and I presume that >>> when we move to the next stage proposals of both of these types >>> will be put forward, allowing the working group to debate their >>> merits. >> >> What next stage? Another round of protocols-survey to definitely >> answer debates before the July milestone "first draft of ROLL >> routing protocol spec"? >> >> The protocols-survey draft was Last Call'ed, I suppose it will be >> sent soon to IESG (I haven't seen the write-up). Do you mean >> another protocol evaluation document? >> >> Alex >> >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > From alexandru.petrescu@gmail.com Fri Mar 6 12:23:46 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51A1C3A6987 for ; Fri, 6 Mar 2009 12:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAUTKrzdpHsn for ; Fri, 6 Mar 2009 12:23:45 -0800 (PST) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by core3.amsl.com (Postfix) with ESMTP id 3A7AF3A6971 for ; Fri, 6 Mar 2009 12:23:43 -0800 (PST) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id 0B7598180A6; Fri, 6 Mar 2009 21:24:10 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp3-g21.free.fr (Postfix) with ESMTP id DC1A08180B5; Fri, 6 Mar 2009 21:24:07 +0100 (CET) Message-ID: <49B1865F.8010005@gmail.com> Date: Fri, 06 Mar 2009 21:23:59 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Arsalan Tavakoli References: <69306dde0903041646n7a1871d4u5c4faeab93978786@mail.gmail.com> In-Reply-To: <69306dde0903041646n7a1871d4u5c4faeab93978786@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090305-1, 05/03/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] draft-tavakoli-hydro-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 20:23:46 -0000 Arsalan and co-authors, Thanks for the new draft. I will read it later in detail and comment. I hope WG member candid opinion is useful outside the deals you may have already settled outside. The first thing I did when it showed up was wow, authorship ok, ICMP ok, maybe this is all ok. Stimulated so I quickly searched. Only to soon get disappointed to see a Default Route table? An adaptation layer? Would this fit in the claimed requirements? 14kb RAM? Or are the claimed requirements just bogus? How should I read this draft and understand it for low-power and lossy networks? Until you tell me I'll read it anyways and provide technical feedback. Alex Arsalan Tavakoli a écrit : > http://www.ietf.org/internet-drafts/draft-tavakoli-hydro-00.txt > > This is the draft of a new protocol specification for a routing > protocol for L2Ns that we thought members of this working group might > find interesting. Any comments/feedback/questions would be highly > appreciated, and we will attempt to incorporate those we receive > before Monday (cutoff date for IETF documents) into a -01 version of > the draft. > > Thanks in advance, Arsalan > > ----------------------------------------------------- > > A new version of I-D, draft-tavakoli-hydro-00.txt has been > successfuly submitted by Arsalan Tavakoli and posted to the IETF > repository. > > Filename: draft-tavakoli-hydro Revision: 00 Title: > HYDRO: A Hybrid Routing Protocol for Lossy and Low Power Networks > Creation_date: 2009-03-04 WG ID: Independent Submission > Number_of_pages: 27 > > Abstract: HYDRO is a hybrid routing protocol for Lossy and Low power > Networks (L2Ns) that embraces centralized and distributed routing > mechanisms. Through the use of standard ICMP Route Advertisements and > Route Solicitations, Node Routers build Default Routes to Border > Routers. These routes, which maintain multiple options per each Node > Router when available, are maintained through data-driven link > estimation. Node Routers periodically report a high-quality subset of > their Default Route Table to Border Routers, which then form a global > view of the topology. When a Node Router attempts to route to > another Node Router in the network, if no matching entry exists in > the Node Router's Flow Table, it forwards the packet to a Border > Router, which then installs the correct Flow Table Entries in the > network to enable more efficient subsequent routing. > > > ------------------------------------------------------------------------ > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Fri Mar 6 12:43:00 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01FEB3A682A for ; Fri, 6 Mar 2009 12:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.142 X-Spam-Level: X-Spam-Status: No, score=-10.142 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLJocbpypPlm for ; Fri, 6 Mar 2009 12:42:58 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2AE813A659C for ; Fri, 6 Mar 2009 12:42:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,316,1233532800"; d="scan'208";a="35574023" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 06 Mar 2009 20:43:28 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n26KhRDi029437; Fri, 6 Mar 2009 21:43:27 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n26KhRtT000745; Fri, 6 Mar 2009 20:43:27 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Mar 2009 21:43:27 +0100 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Mar 2009 21:43:26 +0100 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <49B18439.8050703@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Mar 2009 21:43:26 +0100 References: <20090304153927.4A1C43A6CD4@core3.amsl.com> <49B14332.10507@ekasystems.com> <49B15E6E.1000705@gmail.com> <69306dde0903060938o20ecb259q36c264e625f15fbd@mail.gmail.com> <49B1675D.8060805@gmail.com> <49B18439.8050703@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 06 Mar 2009 20:43:27.0019 (UTC) FILETIME=[3356E7B0:01C99E9C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5660; t=1236372207; x=1237236207; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20WG=20Review=3A=20Recharter=20o f=20Routing=20Over=20Low=20power=20and=20Lossy=20networks=20 (roll) |Sender:=20; bh=yio/diECNIiKiBCEGPCdsfUsiAyw8ksWd3sthsTycFA=; b=YwAs3QWbkv7Jfj4wT+tzwPj0QRVq13kRq8op326N/Yj8xQpZpjaI749tcP bw5eawr5jh3yPrq/JoKIGFcZ9lOQAY0oytN4nMKFMZNEAjGltFCwogKr3Dg7 w2mtEBaCa9; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 20:43:00 -0000 On Mar 6, 2009, at 9:14 PM, Alexandru Petrescu wrote: > [SFO - I won't be there, sorry, maybe next time.] Sure. > > > JP thanks for the explanation of the procedure. As you put it =20 > sounds reasonable, except this quirk (and another posted separately). > OK glad that we are in sync. > Requirements - then I will look again at the recently demanded =20 > feedback. > > ('experts' - I hear it as an overly elitist, touching arrogance, yet > necessary attitude one has to label self before talking Routing. > And I don't agree with it, please don't mention it. Rant off.) > There was no intention of elitism or arrogance, an "expert" is usually =20= known was someone with a deep knowledge in some area and a strong =20 understanding of the requirements and solutions, that's all. Thanks. JP. > Alex > > JP Vasseur a =E9crit : >> Dear Alex, >> As you can see on the list, there is a good number of people =20 >> supporting the new charter and for whom the next stage is clear. Let >> me restate the situation one more time (note that both co-chairs did >> this many many times already) and there is a good consensus. Note =20 >> also that we addressed your points during the review of the WG =20 >> charter, before submitting the proposal to the IESG and it looks like >> we are restarting again. >> Anyway let me try one last time. >> 1) We were tasked to first clearly spell out the ROLL routing =20 >> requirements: all of them are in publication request, under IESG =20 >> review with a very good WG consensus. 2) We had to evaluate whether =20= >> we could find an existing routing protocols that would meet our =20 >> requirements (the protocol survey), this was the only purpose of this >> document. Again we had a good consensus, the answer being that there >> is no existing routing protocols satisfying the specific routing =20 >> requirements of ROLL. 3) As pointed out MANY times on the list, this >> does not mean that an existing protocol could not be extended (e.g. >> MANET, ...) to satisfy these requirement. At this stage we are not =20= >> chartered to do any protocol work, thus the proposal for =20 >> rechartering. Thus the new proposed charter explicitly states that we >> could either adapt an existing protocol or design a new routing =20 >> protocol. At this stage we will go back to the routing requirements =20= >> documents of course. Otherwise, what would be the point of having =20 >> worked for months on these requirements that have been written by =20 >> recognized expert in the field. >> What comes next ? >> 1) Wait until we get the re-chartering green light from the IESG. 2) >> Start working on protocol specification in light of the >> requirements. Nothing different than any regular WG. 3) If we have >> multiple candidates, the WG will select a solution, based on >> consensus. >> The reason why you see so many people get a bit impatient is because >> we have an excellent dynamic in this WG, with lots of recognized =20 >> experts in sensors and routing, we all agree on the requirements and >> we now need to move forward because the industry is waiting for an =20= >> IP-based solution. Bear in mind that this is the objective, the work >> group is not putting so much effort for the sake of an intellectual >> exercise but because products are being design and a routing >> solution is required. >> If this is still not clear, I'll be happy to spend some time with you >> in SFO. >> Thanks. >> JP. >> On Mar 6, 2009, at 7:11 PM, Alexandru Petrescu wrote: >>> Arsalan Tavakoli a =E9crit : >>>> Comments inline. On Fri, Mar 6, 2009 at 9:33 AM, Alexandru =20 >>>> Petrescu >>> >> wrote: Tim Winter a =E9crit >>>> : I am in support of the modified charter. The ROLL WG has =20 >>>> covered a lot of ground in examining the requirements of an LLN =20 >>>> routing protocol with respect to various applications, and the =20 >>>> protocol survey effort does indicate that no existing IETF =20 >>>> protocol without modification will be a good fit for the =20 >>>> requirements. The modified charter will allow the WG to continue >>>> with its current momentum and either specify modifications to an >>>> existing IETF protocol or a new protocol in order to meet the =20 >>>> demand of industry. What do you mean: specify modifications to =20 >>>> existing protocol or new protocol? Both? Only one? What's the =20 >>>> goal of this ambiguous language? Alex I don't understand how this >>>> is ambiguous. As has been discussed consistently, ROLL needs a >>>> specification for a routing protocol, and this specification can >>>> stem from modifications to an existing IETF protocol, or from =20 >>>> something new altogether; no stance is taken on which one it =20 >>>> should be (and hence the 'ambiguous' text), and I presume that =20 >>>> when we move to the next stage proposals of both of these types =20 >>>> will be put forward, allowing the working group to debate their =20 >>>> merits. >>> What next stage? Another round of protocols-survey to definitely =20= >>> answer debates before the July milestone "first draft of ROLL =20 >>> routing protocol spec"? >>> The protocols-survey draft was Last Call'ed, I suppose it will be =20= >>> sent soon to IESG (I haven't seen the write-up). Do you mean =20 >>> another protocol evaluation document? >>> Alex >>> _______________________________________________ Roll mailing list = Roll@ietf.org=20 >>> https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Fri Mar 6 14:52:51 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C9C13A681C for ; Fri, 6 Mar 2009 14:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4hwUXbQejOb for ; Fri, 6 Mar 2009 14:52:49 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id D88173A67D6 for ; Fri, 6 Mar 2009 14:52:47 -0800 (PST) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id BDDBA940109; Fri, 6 Mar 2009 23:53:14 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 345A894004B; Fri, 6 Mar 2009 23:53:11 +0100 (CET) Message-ID: <49B1A94F.8070606@gmail.com> Date: Fri, 06 Mar 2009 23:53:03 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Arsalan Tavakoli References: <69306dde0903041646n7a1871d4u5c4faeab93978786@mail.gmail.com> <49B1865F.8010005@gmail.com> In-Reply-To: <49B1865F.8010005@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 090305-1, 05/03/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: [Roll] Comments on draft-tavakoli-hydro-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 22:52:51 -0000 Dear co-authors of draft-tavakoli-hydro-00.txt, I've read most of the HYDRO document. I typed remarks as they came to my head. I think I forgot all the positive remarks but please think I do have some positive remarks about it. The document is more complex than a quick read could do. It's way too complex for me a Friday evening :-) Disapointingly, it seems too much linked to 802.15.4... couldn't run on ANT for example. Doesn't use 128bit IPv6 address either. Encouragingly, it uses ICPMv6, multicast, the whole nodes are in a subnet, extension headers proposals, and more. PacketBB could be used at places, and it's not mentioned. Following are a large set of technical remarks followed by a small set of nit syntax, not really important. Thanks for the draft, Alex > HYDRO Any relationship to sensor networks for watery environments, like in oceans and such? I'm asking not naively, I know an ANT wireless low-power link won't work under water. > An underlying set of routing trees are created using IPv6 Route > Advertisement and Route Solicitation Messages. You may be interested in citing draft-petrescu-manemo-nano-00 (expired) in which RAs contain prefixes, which otherwise uses RFC4191 which you may be more tempted in mentioning. > When a Node needs to route a packet, either as its originator or a > forwarder, it attempts to classify a packet against its Flow Table > (which is initially empty). If an entry matches the packet, then the > packet is forwarded according to the rules specified by the entry. > Otherwise, the Node forwards the packet along a Default Route to the > Border Router. Is this a plan to avoid searching the typical routing table? Is there a typical kernel routing table at all? Is this 'entry matches' happening before the node's typical routing table search? Afterwards? > It then forwards the packet to the destination by inserting a source > routing header into the packet and forwarding it to the first hop in > the source route. Say the type upfront (detailed later in section 6.2) > HYDRO mechanisms require the frequent transmission (or exchange) of > IPv6 addresses. Because full 128-bit addresses in this setting are > not practical, we assume that all Nodes are associated with a locally > unique 16-bit short identifier, and furthermore that all Border > Routers have access to the mapping between 16-bit and 64-bit > interface identifiers. This 16-bit identifier should be equivalent > to the 16-bit form of compressed address specified by [RFC4944]. The > mapping may be static or dynamic, using mechanisms like DHCPv6 but is > beyond the scope of this document. All routing takes place using 16- > bit short identifiers Only 802.15.4 16-bit addresses? What about IPv6 addresses? This makes too much think HYDRO being only about bridging in 802.15.4... > L2N Network: a network with a single IPv6 prefix encompasing both a > set of Border Routers and Edge Routers. Multiple types of links > connect these routers, and the Border Routers are all in a single > link-local multicast domain. All interfaces on this network share a > single prefix (the L2N prefix). I fully agree with this virtual picture. A real illustration would be more suggestive though. I could draw it if wish. And a quirk: not all interfaces on this network need to share the same prefix. I'm thinking about the Secondary Interfaces. I don't agree saying Border Routers are all in a single link-local multicast domain. Maybe all interfaces of the Border Routers' L2N Interfaces - yes. Picture would help here too. > Default Route Table: A Node's table which contains information about > a set of Default Routes and their associated next-hop Nodes, > including the cost of communicating with a Border Router using that > particular Default Route. I think I understand what's meant, just it dangerously approaches the name Default Router List of ND. > Neighbor: A Node or Border Router within a single IP-hop. I agree. > Node Router (Node): Any node in the network that serves as a router, > but not as a Border Router. Typically a constrained device. Mobile Node... > Neighbor Address: 16-bit short IPv6 address of the neighboring Node > or Border Router. Sorry? 16-bit short IPv6 address? 128bit IPv6 would be ok. Or you mean an IPv6 address formed by adding a 64bit prefix to the 64bit IID formed from the 16-bit MAC address ('short') and 16_bit_PAN and 16_zero_bits? Or am I overly optimistic trying to think what you actually don't think? > Route Hops: The distance to a Border Router in hops using the > specified Neighbor as the next-hop. For my clarification, would this mean that a hop separates two subnets? Or is it a 'hop' within the same unique link-local multicast scoped subnet. This would be a MAC-layer hop and not an IP hop? I think it's meant the former, a hop being a MAC-layer hop. This is very much risking misunderstanding the 'Next Hop' in a typical routing table, which is IP hop. > 5.2. Flow Table > > > Each Node maintains a Flow Table, whose entries are composed of two > parts: > > Flow Match: The Flow Match contains information against which packets > can be checked. Flow Match MUST include a Packet Destination field, > and MAY contain certain additional fields, such as Packet Source. > > Flow Path: The Flow Path indicates the path a packet should take. > This can either be a full source route, or simply the next-hop to > which the packet should be sent to. But earlier it was said Flow Table has a (Classification, Action) format. I suppose Flow Path is the Action, and Classification is the Flow Match, right? > The 6lowpan working group has defined an adaptation layer for IPv6 > datagrams, when carried over Low Power and Lossy links. 6lowpan hasn't mentioned Low Power and Lossy links or am I wrong. > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Next Header | Hdr Ext Len | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + > | | > . . > . Options . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The "Hdr Ext Len" is specified in units of 8-octet chunks, not > including the first 8 octets. A similar layout is used for TLV- > encoded options, except the 'Next Header' field is named the 'Option > Type' field. We suggest that the 6lowpan working group may wish to > define, as part of the adaptation layer, lengths in units of single > octets; we will assume for the rest of this document that such a > modification is in effect. Although this limits the length of > extension headers and options to 255 bytes, we feel that this is not > a significant limitation and the payload savings resulting from > removing unnecessary padding are significant. > > This recommendation applies specifically to Hop-by-hop, Destination, > and Routing extension headers (with 'next header' values 0, 60, and > 43, respectively). It also applies to TLV-encoded sub-headers as > specified in [RFC2460]. Hmm... I think I get the idea... but I find the text difficult to parse. I guess what you intend is 6lowpan to ask IANA to define a new value for Next Header field of headers potentially preceding this newly introduced header. I think it would be clearer if a picture were drawn precising where this new Extension Header could appear, with respect to _all_ the existing Extension Headers (also ESP, AH and MH and some I may have forgot). SHould also recommend whether final or non-final. This is paramount recommendation to implementers. Like e.g. base-do-thisheader-payload or base-ah-esp-thisheader-mh Too many combinations may look tedious at first (and because of that it's hard to propose new extension headers :-) but it could be done. And it would be great for potential implementers. > 6.2. Routing Header > > > IPv6 Routing extension headers are defined in [RFC2460]. However, > the loose source routing they define is not appropriate for this it s > setting since (a) it uses 128-bit addresses, and (b) it is deprecated > by [RFC5095]. Type 0 is indeed deprecated, but not Type 2 for example (Mobile IPv6 RFC 3775). > Source routing is a critical facility in this class of > network, and so we define a new routing type. Alternatively, we may > consider this a routing type 0 header, with adaptations. > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Next Header | Hdr Ext Len | Routing Type=0| Segments Left | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Address[1] | Address[2] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . . > . . . > . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Address[n-1] | Address[n] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The addresses in this header are stored in compressed 16-bit form, as > specified by [RFC4944] (or later). I get the idea. Sounds necessary and simple. However, I doubt it can fly if it doesn't hold 128bit IPv6 addresses... to see later. > 6.3. Route Install Header > > > A Route Install Header may be placed either as a Destination option > or a Hop-by-hop option, depending on the method of install. > Processing of this header will depend on which of these is in effect. > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Option Type | Option Len | M Len | |R| M | Path Len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Flow Match (D) | Address[1] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Address[2] | Address[3] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . . > . . . > . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Address[Path Len - 1] | Address[Path Len] | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Option Type: the TLV dispatch value, TLV_TYPE_INSTALL. I get the idea. If you want Option Type assigned by IANA just say TBD. If you feel like you could decide it, then just place a number like decimal 1, 2, etc. and use same numbers to explain what's meaning. > 6.4. Router Advertisement Extension > > > In order to carry the Total Path Cost in a router advertisement, we > define a new extension header to the Router Advertisement message > defined in [RFC2461]. > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Option Type | Option Len | Metric | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Willingness | > +-+-+-+-+-+-+-+-+ > > Option type: the TLV value for this header, TLV_TYPE_MULTIHOPMETRIC > > Option length: The option length, in octets (4). > > Metric: the Overall Route Cost from a Node to the original > advertising router, the Border Router. If this extension is not > present, a cost of zero should be assumed. > > Willingness: a value indicating the Node's willingness or capacity to > route traffic for other Nodes. This one is longer. In short: one would better use a new flag in the Flags Expansion Option in rfc5175. It was designed for needs exactly like this one. Or maybe use rfc4191, but I'm afraid this text until here doesn't seem intent on using 128bit IPv6 addresses and prefixes :-( > 7.1. Link Estimation > > > A critical design element for good performance in L2N networks is > good link estimation; low power wireless links exhibit significant > temporal and spacial variations in quality due to a number of > physical and environmental phenomenon. This poses a challenge to > traditional IP link abstraction since any protocol must account for > this behavior. Hmm... sounds as a fallacy. Links exhibit variations... challenge to traditional IP link abstractions, not. For example IP runs ok over wifi, which does expose significant temporal and spatial abstractions - all dealt with ok at its layer. > The link layer must also provide a mechanism for 'local broadcast'; > the 802.15.4 broadcast address (0xffff) is such a mechanism. It MAY > be advantageous to replace this mechanism with a dedicated discovery > component in the future. No, what may be advantageous is to have a mapping rule between this 0xffff and a link-local scope all-nodes multicast address. Just a mapping would be very useful first step. Make state that the 0xffff 802.15.4 address is mapped into the FF02:0:0:0:0:0:0:1 all-nodes multicast address and into the FF02:0:0:0:0:0:0:2 all-routers multicast address. And vice-versa. (HYDRO Node is an IPv6 Node or IPv6 Router? Or None?) This may even be a novelty since not even rfc4944 offers such a mapping, and I believe mapping is of help to implementer. > 7.2. Router Discovery > > > Router Advertisement and Router Solicitation messages and the > associated protocol have been standardized for IPv6 in [RFC2461]. > While many of the mechanisms can be applied directly in L2Ns, some > require modification for efficiency or performance. The 6lowpan > working group has created a committee to investigate these necessary > modifications; once their work is complete HYDRO SHOULD be modified > to used those mechanisms. Ouh-la... we reject committees... maybe a design team. But I agree with the intent... > When an event triggers the generation of Router Solicitation or > Router Advertisement messages, a binary exponential timer is started. > Each time the timer fires, a new Router Solicitation or Advertisement > is generated and sent to the IPv6 all-routers link-local multicast > address (ff02::2), using the link broadcast facility. Binary exponential timer... is the basis subunitary or supra? I mean will this firing happen more and more, exponentially, or less and less also exponentially? Or is it exponential backoff sending upon no reception of reply? Not clear. > There are two conditions which cause a reset of the Router > Solicitation timer, and thus the transmission of new Router > Solicitations: > > 1. Boot > > 2. No valid Default Route is present in the Default Route Table. > > There are two conditions which cause the Router Advertisement timer > to be started, if it is not running, and thus the transmission of > Router Advertisements: > > 1. Reception of a Router Solicitation, and the Primary Default Route > is valid. > > 2. The Total Route Cost of the Primary Default Route changes by more > then a threshold, ROUTE_COST_NOTIF_DIFF. I thought one of the conditions of exit is either: receiving the reply which was expected, or not receiving an expected reply within a pre-defined amount of time. With random values for the timers, within ranges, and without exponentially growing (or dereasing) values. > 7.3. Default Route Formation > > > The Border Router is manually configured with an IPv6 address, > including a full 64-bit network prefix. On which interface? L2N Interface or Secondary Interface? This is paramount importance in deciding the entire addressing scheme for HYDRO. > 7.4. Global Topology Construction > > > Each Border Router maintains a global view of the topology using > information obtained from the Topology Reports created by each Node. Global makes think of world and such. I understand the world here is the sensor network... Global Topology makes think of global IPv6 addresses, which this doesnt seem to be... > HYDRO receives feedback from the link layer following each > transmission about which Default Route next-hops the link was able to > successfully use. If the number of consecutive failures of the > Primary Default Route is greater than MAX_CONSEC_FAILURES, HYDRO > initiates a search for a new Primary Default Route. Well, how does a HYDRO node know when a transmission succeeded? YOu seem to mean HYDRO receives feedback from the link layer - but how? I'm afraid this is too much 802154 specific. If it were independent of the 802154 layer then it could simply wait for an IP reply (RA or other) and if no reply then do some action. > 1. If the destination address is a global unicast address, normal > IPv6 processing rules apply; the packet will be routed according to > the IPv6 Routing Table Entry for that destination. Ok! I adore that! > 2. If the packet contains an IPv6 Routing Header and the first hop > of that route is another Border Router, the packet is dropped. In this case, what's the dst address in the IPv6 Base Header? If first hop is another Border Router - the IPv6 address of the Border Router's which interface? > 3. If the destination is a unicast address within the L2N subnet and > the Border Router does not have a route in its route database, the > packet is dropped. It MAY generate an ICMPv6 Host Unreachable > message in this case, but implementors SHOULD take care to limit the > rate of message generation; it MAY be advantageous in many cases not > to generate this message. What's the dst address of the Host Unreachable ICMPv6 message? And why not an ICMPv6 Redirect instead? This would also install better routes to the interested parties. > 7.8. Multicast Forwarding > > > In this so-called "route-over" design, To me this is not yet route-over because it doesn't use IPv6 128bit addresses, and 'hops' are for you MAC-layer hops. It is indeed 'over' because you stated the L2N network is an entire subnet, ok. > the link-local multicast > address is mapped directly to link-local broadcast at the link layer. How? What are the mapping rules from 0xffff to ff02::1? > Additionally, it is often desirable for Nodes to send packets to all > Nodes in a subnet, regardless of whether or not they are within a > link-local broadcast domain. For this purpose, we use the IPv6 site- > local scope. Doubt doubt... because IPv6 site-local has been deprecated in an RFC, yet there seems to be discussion about resurrecting it because used by Windows for example... doubt doubt. > First, we define the well-known address ff05::XXXX to > correspond to a subnet-wide flood. Put it in IANA section. Depends what you mean by XXXX ff05::some_things_are_already_reserved > 7.9. Multiple Border Routers > > > It is often desirable for multiple Border Routers to be present on > single L2N subnet to provide a diversity of routing options and > failover connectivity. I fully agree! > If more then one Border Router is present, layer 2 connectivity > between them will be assumed, for example using Ethernet, 802.11 > mesh, or virtual tunneled IP links (something similar to [RFC2003]). Why this assumption? I believe it would work even if Border Routers' Secondary Interfaces where simply reachable at IP layer, like when connected to the Internet. Like this \ Internet / --|-------|-- / \ | | Secondary Interface --- ---- |BR1| | BR2| --- ---- | | L2N Interface > On startup, the Border Routers join a link-local multicast group > ff02::XXXX on their secondary interface and begin listening for > messages on UDP port XXXX. On which interface? If on the Secondary Interface then there may be better to join a wider than link scope, a newly defined scope like ff06 (if it's not already there)... IANA... TBD > > assumed to have have a relatively abundant nit have have > ... nit beween > It also not uncommon nit is missing > instantance nit From alexandru.petrescu@gmail.com Fri Mar 6 16:20:30 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8587F3A6969; Fri, 6 Mar 2009 16:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39WQ9UnOxjgl; Fri, 6 Mar 2009 16:20:29 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id B7B1E3A6A99; Fri, 6 Mar 2009 16:20:27 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 12F69D48044; Sat, 7 Mar 2009 01:20:54 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id F10AED48031; Sat, 7 Mar 2009 01:20:51 +0100 (CET) Message-ID: <49B1BDDB.4020509@gmail.com> Date: Sat, 07 Mar 2009 01:20:43 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: ietf@ietf.org References: <20090220013719.C2CCD3A6952@core3.amsl.com> In-Reply-To: <20090220013719.C2CCD3A6952@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090306-0, 06/03/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] Last Call: draft-ietf-roll-building-routing-reqs (Building Automation Routing Requirements in Low Power and Lossy Networks) to Informational RFC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 00:20:30 -0000 Dear IETF, This may be late, after 2009-03-05, but here it goes anyways. There was some discussion in the WG about the Mobility requirement, section 5.3. It seems the requirement is indeed in the draft but discussions don't make it appear as important as it may imply. This leads to potentially unclear decisions about what kind of protocol work should be done in ROLL WG. A simple example: > To minimize network dynamics, mobile devices SHOULD not be allowed to > act as forwarding devices (routers) for other devices in the LLN. This effectively prohibits the use of a NEMOv6 Mobile Router (RFC3963), which I find otherwise very appropriate for this task. Because I'm not sure I know of any other mobility protocol which would achieve the same. So, is this a requirement? A so-and-so requirement? A suggestion would be to completely remove the Mobility requirement section from the draft. But I'm not sure I could suggest that because it appears also that the requirements are very strongly supported by industry needs. That's my comment, Alex The IESG a écrit : > The IESG has received a request from the Routing Over Low power and > Lossy networks WG (roll) to consider the following document: > > - 'Building Automation Routing Requirements in Low Power and Lossy > Networks ' as an > Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to > the ietf@ietf.org mailing lists by 2009-03-05. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-roll-building-routing-reqs-05.txt > > > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17943&rfc_flag=0The > following IPR Declarations may be related to this I-D: > > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Fri Mar 6 16:20:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5318928C152; Fri, 6 Mar 2009 16:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFOwkWxkM4U9; Fri, 6 Mar 2009 16:20:33 -0800 (PST) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by core3.amsl.com (Postfix) with ESMTP id A244628C14C; Fri, 6 Mar 2009 16:20:31 -0800 (PST) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id 701744C8059; Sat, 7 Mar 2009 01:20:56 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp4-g21.free.fr (Postfix) with ESMTP id 13DB84C8078; Sat, 7 Mar 2009 01:20:54 +0100 (CET) Message-ID: <49B1BDDD.3020103@gmail.com> Date: Sat, 07 Mar 2009 01:20:45 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: ietf@ietf.org References: <20090220013917.8CEDE3A6B0A@core3.amsl.com> In-Reply-To: <20090220013917.8CEDE3A6B0A@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090306-0, 06/03/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] Last Call: draft-ietf-roll-indus-routing-reqs (Industrial Routing Requirements in Low Power and Lossy Networks) to Informational RFC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 00:20:34 -0000 Dear IETF, This may be late, after 2009-03-05, but here it goes anyways. There was some discussion in the WG about the Mobility requirement in this draft, section 8. It seems the requirement is indeed in the draft but discussions don't make it appear as important as it may imply. This leads to potentially unclear decisions about what kind of protocol work should be done in ROLL WG. A simple example: > The routing protocol SHOULD support the wireless worker with fast > network connection times of a few of seconds, and low command and > response latencies to the plant behind the LLN access points, to > applications, and to field devices. To me this reads as if a NEMOv6 Mobile Router would be a very pertinent solution, or part of the ROLL solution. However, it is not clear from the text, neither from the recent WG discussions, whether this Mobility requirement is important, or less important, or not important at all. BEcause of that, I can't say what kind of work should I expect to do or at least to see in the ROLL WG with respect to Mobility. A solution to it would be to completely remove the section 8. Mobility from the requirements draft, but I also understand this comes from a strong industrial need. That's my comment, Alex The IESG a écrit : > The IESG has received a request from the Routing Over Low power and > Lossy networks WG (roll) to consider the following document: > > - 'Industrial Routing Requirements in Low Power and Lossy Networks ' > as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to > the ietf@ietf.org mailing lists by 2009-03-05. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-roll-indus-routing-reqs-04.txt > > > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17220&rfc_flag=0The > following IPR Declarations may be related to this I-D: > > > > _______________________________________________ IETF-Announce mailing > list IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > From jau@ece.drexel.edu Sat Mar 7 13:41:55 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7D653A6B7E; Sat, 7 Mar 2009 13:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GS4l1+VIu8gN; Sat, 7 Mar 2009 13:41:55 -0800 (PST) Received: from coe.drexel.edu (cbis.ece.drexel.edu [129.25.60.1]) by core3.amsl.com (Postfix) with ESMTP id 052413A6B7D; Sat, 7 Mar 2009 13:41:54 -0800 (PST) Received: from [192.168.0.105] (c-68-45-81-183.hsd1.pa.comcast.net [68.45.81.183]) (authenticated bits=0) by coe.drexel.edu (8.13.6/8.13.4) with ESMTP id n27LhaX2022391; Sat, 7 Mar 2009 16:43:37 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v753.1) References: <837880AF-AB0A-4283-8400-5144C57AC31A@ece.drexel.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <29C458B3-6CFA-4181-8A4B-0340EAD58573@ece.drexel.edu> Content-Transfer-Encoding: 7bit From: Jaudelice de Oliveira Date: Sat, 7 Mar 2009 16:44:58 -0500 To: roll@ietf.org X-Mailer: Apple Mail (2.753.1) X-Scanned-By: MIMEDefang 2.51 on 129.25.60.1 Cc: iesg@ietf.org Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 21:41:55 -0000 I also want to express my support of the modified charter. The protocol survey indicated that a new/modified protocol is needed and we should move on with the items in the modified charter as the need for a standard is quite pressing! Jau. On Mar 6, 2009, at 12:19 PM, Philip Levis wrote: > > On Mar 6, 2009, at 7:37 AM, Tim Winter wrote: > >> I am in support of the modified charter. >> >> The ROLL WG has covered a lot of ground in examining the >> requirements of an >> LLN routing protocol with respect to various applications, and the >> protocol >> survey effort does indicate that no existing IETF protocol without >> modification will be a good fit for the requirements. >> >> The modified charter will allow the WG to continue with its current >> momentum and either specify modifications to an existing IETF >> protocol or a >> new protocol in order to meet the demand of industry. > > I also support the modified charter. I look forward to working in > ROLL to help define the routing standards for LLNs. JP and others, > thanks so much for incorporating all of the comments and feedback > so quickly. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jau@ece.drexel.edu Sat Mar 7 12:18:25 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8E1928C1DF; Sat, 7 Mar 2009 12:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BCK9HSb83f9; Sat, 7 Mar 2009 12:18:25 -0800 (PST) Received: from coe.drexel.edu (cbis.ece.drexel.edu [129.25.60.1]) by core3.amsl.com (Postfix) with ESMTP id 259303A67A1; Sat, 7 Mar 2009 12:18:24 -0800 (PST) Received: from [192.168.0.105] (c-68-45-81-183.hsd1.pa.comcast.net [68.45.81.183]) (authenticated bits=0) by coe.drexel.edu (8.13.6/8.13.4) with ESMTP id n27KK4f1022164; Sat, 7 Mar 2009 15:20:05 -0500 (EST) In-Reply-To: <59EEF538-A200-4879-B501-22879A39FAC4@cs.stanford.edu> References: <20090304153927.4A1C43A6CD4@core3.amsl.com> <49B14332.10507@ekasystems.com> <59EEF538-A200-4879-B501-22879A39FAC4@cs.stanford.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <837880AF-AB0A-4283-8400-5144C57AC31A@ece.drexel.edu> Content-Transfer-Encoding: 7bit From: Jaudelice de Oliveira Date: Sat, 7 Mar 2009 15:21:25 -0500 To: roll@ietf.org X-Mailer: Apple Mail (2.753.1) X-Scanned-By: MIMEDefang 2.51 on 129.25.60.1 X-Mailman-Approved-At: Sat, 07 Mar 2009 16:31:58 -0800 Cc: iesg@ietf.org Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 21:31:12 -0000 I also want to express my support for the modified charter. The protocol survey indicated that a new/modified protocol is needed and we should move on with the items in the modified charter as the need for a standard is quite pressing! Jau. On Mar 6, 2009, at 12:19 PM, Philip Levis wrote: > > On Mar 6, 2009, at 7:37 AM, Tim Winter wrote: > >> I am in support of the modified charter. >> >> The ROLL WG has covered a lot of ground in examining the >> requirements of an >> LLN routing protocol with respect to various applications, and the >> protocol >> survey effort does indicate that no existing IETF protocol without >> modification will be a good fit for the requirements. >> >> The modified charter will allow the WG to continue with its current >> momentum and either specify modifications to an existing IETF >> protocol or a >> new protocol in order to meet the demand of industry. > > I also support the modified charter. I look forward to working in > ROLL to help define the routing standards for LLNs. JP and others, > thanks so much for incorporating all of the comments and feedback > so quickly. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From arsalan.tavakoli@gmail.com Thu Mar 5 16:02:21 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C313C3A63D2 for ; Thu, 5 Mar 2009 16:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHGn4DYVqGuv for ; Thu, 5 Mar 2009 16:02:20 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id D81BC28C1F6 for ; Thu, 5 Mar 2009 16:02:19 -0800 (PST) Received: by fxm24 with SMTP id 24so173232fxm.37 for ; Thu, 05 Mar 2009 16:02:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=LTo8GHfUPcdvLYwdc5xycrCpkJCB9P4La+KjrOAs+5U=; b=JgX41mOfIb9OIH18z/QYpJDbSzjPLW7ECc5ZNPl2Kv+n5yjpkYDT++27ZIzPYclE0Q win0isa2z+skdQ73ZQP41aw4HS82conMnBKjej0oz5MIGbEVohdlH4fX3Yoke16WNxRS FzugO4OmXj2sq6aL3YEKyeP1vRVNSUjhAteQg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=GiH8yfyOId7edgWyGaq23dJ9Wc8sGW78WGeezo3bEJy8qptKDGGYvgYDySRzELl/9s VCYsAFRwty9s02/6Q/mfI7BvEF1/BK+Rfb9I/sNhn7+lRImDsikLtJXgv0CR9he0mO04 CzzOcF5hQ2xYfMf7eVc+jLsZIqh0kLhUoxKOA= MIME-Version: 1.0 Sender: arsalan.tavakoli@gmail.com Received: by 10.103.226.10 with SMTP id d10mr809141mur.35.1236297768400; Thu, 05 Mar 2009 16:02:48 -0800 (PST) In-Reply-To: <2a3692de0903050913h1ba5813al49228a770606d74a@mail.gmail.com> References: <69306dde0903041646n7a1871d4u5c4faeab93978786@mail.gmail.com> <2a3692de0903050003g1c183908t784406e5f223a389@mail.gmail.com> <49AFF248.5080801@eecs.berkeley.edu> <2a3692de0903050913h1ba5813al49228a770606d74a@mail.gmail.com> Date: Thu, 5 Mar 2009 16:02:48 -0800 X-Google-Sender-Auth: d5c03c6580b12b64 Message-ID: <69306dde0903051602i5203f1dekb2b9618233a77bf@mail.gmail.com> From: Arsalan Tavakoli To: Dominik Kaspar Content-Type: multipart/alternative; boundary=0016e6dd96a05276cd04646801af X-Mailman-Approved-At: Sat, 07 Mar 2009 16:32:15 -0800 Cc: roll@ietf.org, "David E. Culler" Subject: Re: [Roll] draft-tavakoli-hydro-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 00:02:21 -0000 --0016e6dd96a05276cd04646801af Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dominik, A real implementation of HYDRO exists, and we have been testing it internally on various campus projects and testbeds, and plan to release the code soon. In addition, a technical report providing evaluation results, and design details from this implementation and testing should be released in about a month or so. - Arsalan On Thu, Mar 5, 2009 at 9:13 AM, Dominik Kaspar wrote: > Hi David, > > Thanks for the clarifications. I was not speaking from a MANET's point > of view, but was just probing whether ROLL has now entered the > "protocol design stage" or not. > > Anyway, the draft looks very interesting. Have there been research > papers published with results from a real implementation of HYDRO? > > Best regards, > Dominik > - Show quoted text - > > > On Thu, Mar 5, 2009 at 4:39 PM, David E. Culler > wrote: > > Dominik, > > Although seeing a question such as yours may tempt one to head down > just > > such a path, alas, such political maneuvering is not what the IETF is > for. > > The IETF encourages individual submissions in order to further a process > of > > informed discussion, rather than mere opinion and positioning. Only if > there > > is willingness to focus on the challenges at hand can rough consensus and > > running code emerge. Now that ROLL has gone to great pains and delay to > > examine such protocols it has begun the process of rechartering. Once > that > > is complete it will be possible to consider extensions to existing > > protocols, such as those previously proposed to address mobility in > MANET. > > Hopefully, individuals in MANET will have begun thinking about such > > protocols might possibly made to work in a context where resources are > > highly constrained and link loss is non-negligible. These are very > different > > issues from dealing with a device moving out of range, so don't > > underestimate how much technical work there is to address even the > > stationary problem. > > What submission of this draft does suggest is that at least some > members > > of ROLL would like to have the opportunity to consider protocols other > that > > those historically put forward by MANET. There are many such protocols > and > > a substantial body of implementation experience and empirical analysis. > Few > > of them have been cast into I-D form, so it is hard for the IETF to give > > them serious thought. > > I do hope that representatives of MANET will participate in such > > discussions regarding technical merit of options and alternatives. > > > > D. > > > > > > Dominik Kaspar wrote: > > > > Hello. > > > > Can the posting of this protocol specification be interpreted as the > > strategical decision to ignore existing protocols (MANET) and move > > ahead with ROLL's own solution? > > > > Regards, > > Dominik > > > > On Thu, Mar 5, 2009 at 1:46 AM, Arsalan Tavakoli > > wrote: > > > > > > http://www.ietf.org/internet-drafts/draft-tavakoli-hydro-00.txt > > > > This is the draft of a new protocol specification for a routing protocol > for > > L2Ns that we thought members of this working group might find > interesting. > > Any comments/feedback/questions would be highly appreciated, and we will > > attempt to incorporate those we receive before Monday (cutoff date for > IETF > > documents) into a -01 version of the draft. > > Thanks in advance, > > Arsalan > > ----------------------------------------------------- > > A new version of I-D, draft-tavakoli-hydro-00.txt has been successfuly > > submitted by Arsalan Tavakoli and posted to the IETF repository. > > > > Filename: draft-tavakoli-hydro > > Revision: 00 > > Title: HYDRO: A Hybrid Routing Protocol for Lossy and Low Power > > Networks > > Creation_date: 2009-03-04 > > WG ID: Independent Submission > > Number_of_pages: 27 > > > > Abstract: > > HYDRO is a hybrid routing protocol for Lossy and Low power Networks > > (L2Ns) that embraces centralized and distributed routing mechanisms. > > Through the use of standard ICMP Route Advertisements and Route > > Solicitations, Node Routers build Default Routes to Border Routers. > > These routes, which maintain multiple options per each Node Router > > when available, are maintained through data-driven link estimation. > > Node Routers periodically report a high-quality subset of their > > Default Route Table to Border Routers, which then form a global view > > of the topology. When a Node Router attempts to route to another > > Node Router in the network, if no matching entry exists in the Node > > Router's Flow Table, it forwards the packet to a Border Router, which > > then installs the correct Flow Table Entries in the network to enable > > more efficient subsequent routing. > > > > _______________________________________________ > > 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 > > > --0016e6dd96a05276cd04646801af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dominik,
=A0=A0 =A0A real implementation of HYDRO exists, and we have b= een testing it internally on various campus projects and testbeds, and plan= to release the code soon. =A0In addition, a technical report providing eva= luation results, and design details from this implementation and testing sh= ould be released in about a month or so.

- Arsalan

On T= hu, Mar 5, 2009 at 9:13 AM, Dominik Kaspar <dokaspar.ietf@gmail.com> wro= te:
Hi David,

Thanks for the clarifications. I was not speaking from a MANET's point<= br> of view, but was just probing whether ROLL has now entered the
"protocol design stage" or not.

Anyway, the draft looks very interesting. Have there been research
papers published with results from a real implementation of HYDRO?

Best regards,
Dominik
- Show quot= ed text -


On Thu, Mar 5, 2009 at 4:39 PM, David E. Culler
<culler@eecs.berkeley.edu> wrote:
> Dominik,
> =A0=A0 Although seeing a question such as yours may tempt one to head = down just
> such a path, alas, such political maneuvering is not what the IETF is = for.
> The IETF encourages individual submissions in order to further a proce= ss of
> informed discussion, rather than mere opinion and positioning. Only if= there
> is willingness to focus on the challenges at hand can rough consensus = and
> running code emerge.=A0 Now that ROLL has gone to great pains and dela= y to
> examine such protocols it has begun the process of rechartering.=A0 On= ce that
> is complete it will be possible to consider extensions to existing
> protocols, such as those previously proposed to address mobility in MA= NET.
> Hopefully, individuals in MANET will have begun thinking about such > protocols might possibly made to work in a context where resources are=
> highly constrained and link loss is non-negligible. These are very dif= ferent
> issues from dealing with a device moving out of range, so don't > underestimate how much technical work there is to address even the
> stationary problem.
> =A0=A0 What submission of this draft does suggest is that at least som= e members
> of ROLL would like to have the opportunity to consider protocols other= that
> those historically put forward by MANET.=A0 There are many such protoc= ols and
> a substantial body of implementation experience and empirical analysis= .=A0 Few
> of them have been cast into I-D form, so it is hard for the IETF to gi= ve
> them serious thought.
> =A0=A0 I do hope that representatives of MANET will participate in suc= h
> discussions regarding technical merit of options and alternatives.
>
> D.
>
>
> Dominik Kaspar wrote:
>
> Hello.
>
> Can the posting of this protocol specification be interpreted as the > strategical decision to ignore existing protocols (MANET) and move
> ahead with ROLL's own solution?
>
> Regards,
> Dominik
>
> On Thu, Mar 5, 2009 at 1:46 AM, Arsalan Tavakoli
> <arsalan@cs.berkeley.edu= > wrote:
>
>
> http://www.ietf.org/internet-drafts/draft-tavakoli-= hydro-00.txt
>
> This is the draft of a new protocol specification for a routing protoc= ol for
> L2Ns that we thought members of this working group might find interest= ing.
> =A0Any comments/feedback/questions would be highly appreciated, and we= will
> attempt to incorporate those we receive before Monday (cutoff date for= IETF
> documents) into a -01 version of the draft.
> Thanks in advance,
> Arsalan
> -----------------------------------------------------
> A new version of I-D, draft-tavakoli-hydro-00.txt has been successfuly=
> submitted by Arsalan Tavakoli and posted to the IETF repository.
>
> Filename: =A0 =A0 =A0 =A0draft-tavakoli-hydro
> Revision: =A0 =A0 =A0 =A000
> Title: =A0 =A0 =A0 =A0 =A0 HYDRO: A Hybrid Routing Protocol for Lossy = and Low Power
> Networks
> Creation_date: =A0 2009-03-04
> WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission
> Number_of_pages: 27
>
> Abstract:
> HYDRO is a hybrid routing protocol for Lossy and Low power Networks > (L2Ns) that embraces centralized and distributed routing mechanisms. > Through the use of standard ICMP Route Advertisements and Route
> Solicitations, Node Routers build Default Routes to Border Routers. > These routes, which maintain multiple options per each Node Router
> when available, are maintained through data-driven link estimation. > Node Routers periodically report a high-quality subset of their
> Default Route Table to Border Routers, which then form a global view > of the topology. =A0When a Node Router attempts to route to another > Node Router in the network, if no matching entry exists in the Node > Router's Flow Table, it forwards the packet to a Border Router, wh= ich
> then installs the correct Flow Table Entries in the network to enable<= br> > more efficient subsequent routing.
>
> _______________________________________________
> 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
>

--0016e6dd96a05276cd04646801af-- From arsalan.tavakoli@gmail.com Fri Mar 6 10:31:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DFB728C142; Fri, 6 Mar 2009 10:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5zMzlq5FCNx; Fri, 6 Mar 2009 10:31:42 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id 7A6E83A6C3F; Fri, 6 Mar 2009 10:31:41 -0800 (PST) Received: by fxm24 with SMTP id 24so500675fxm.37 for ; Fri, 06 Mar 2009 10:32:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=yFk9hX7MuGrJZvqYfKOUSR+hsQ/FgAvA60dg8JBLyMw=; b=PH+2w8HSZuQ9znHt7zRqjqoRQ+v0hlpGS5fyo2WCI2zrt13e6NvNXUFFLp53oVa2U0 cxNBfxss+zG5TQSFuTgIDg+M7r05Gu0vPe9OFtZeWEI6JPc6Sg+ILz7kZX3JE9fQy8Ln 3AcfnRiIKVnFbBiu+etsXjderKJCl3RGo5EHY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=vWWu6mDuvldTxGF1l8StjyZjtulepjDZu2fpehLRdN7wEAxx8TBO9zc7Alsx2SidAy lODyAjPE+13rllVhiZqF1oeOljBa1J0zn6wmrsma7rl8e5fiSmybneM5G11UtWZzStIY 4+dA9sHDCqmB2yEsYjxcjuh982yHXSlFMRae0= MIME-Version: 1.0 Sender: arsalan.tavakoli@gmail.com Received: by 10.103.90.17 with SMTP id s17mr1196287mul.73.1236364331182; Fri, 06 Mar 2009 10:32:11 -0800 (PST) In-Reply-To: <49B1675D.8060805@gmail.com> References: <20090304153927.4A1C43A6CD4@core3.amsl.com> <49B14332.10507@ekasystems.com> <49B15E6E.1000705@gmail.com> <69306dde0903060938o20ecb259q36c264e625f15fbd@mail.gmail.com> <49B1675D.8060805@gmail.com> Date: Fri, 6 Mar 2009 10:32:11 -0800 X-Google-Sender-Auth: fd24366f5a3a4c96 Message-ID: <69306dde0903061032w5f592e20le5ba28a1482c1fbe@mail.gmail.com> From: Arsalan Tavakoli To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=001636416983c5eca70464778019 X-Mailman-Approved-At: Sat, 07 Mar 2009 16:32:16 -0800 Cc: roll@ietf.org, iesg@ietf.org Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 18:31:43 -0000 --001636416983c5eca70464778019 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Mar 6, 2009 at 10:11 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Arsalan Tavakoli a =E9crit : > >> Comments inline. >> >> On Fri, Mar 6, 2009 at 9:33 AM, Alexandru Petrescu < >> alexandru.petrescu@gmail.com > >> wrote: >> >> Tim Winter a =E9crit : >> >> I am in support of the modified charter. >> >> The ROLL WG has covered a lot of ground in examining the >> requirements of an >> LLN routing protocol with respect to various applications, and >> the protocol >> survey effort does indicate that no existing IETF protocol withou= t >> modification will be a good fit for the requirements. >> >> The modified charter will allow the WG to continue with its curre= nt >> momentum and either specify modifications to an existing IETF >> protocol or a >> new protocol in order to meet the demand of industry. >> >> >> What do you mean: specify modifications to existing protocol or new >> protocol? Both? Only one? >> >> What's the goal of this ambiguous language? >> >> Alex >> >> >> I don't understand how this is ambiguous. As has been discussed >> consistently, ROLL needs a specification for a routing protocol, and thi= s >> specification can stem from modifications to an existing IETF protocol, = or >> from something new altogether; no stance is taken on which one it should= be >> (and hence the 'ambiguous' text), and I presume that when we move to the >> next stage proposals of both of these types will be put forward, allowin= g >> the working group to debate their merits. >> > > What next stage? Another round of protocols-survey to definitely answer > debates before the July milestone "first draft of ROLL routing protocol > spec"? > > The protocols-survey draft was Last Call'ed, I suppose it will be sent so= on > to IESG (I haven't seen the write-up). Do you mean another protocol > evaluation document? > > Alex There is only one protocols-survey, and that has been last called. The nex= t stage is where ROLL must put forth a protocol specification (and possibly more than one), that meets the requirements laid out in the protocol-survey and will be embraced as the standard routing protocol for ROLL applications= . - Arsalan --001636416983c5eca70464778019 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Mar 6, 2009 at 10:11 AM, Alexand= ru Petrescu <alexandru.petrescu@gmail.com> wrote:
Arsalan Tavakoli a =E9crit :
Comments inline.


On Fri, Mar 6, 2009 at 9:33 AM, Alexandru Petrescu <alexandru.petrescu@gmail.com<= /a> <mailto:alexandru.petrescu@gmail.com>> wrote:

=A0 =A0Tim Winter a =E9crit :

=A0 =A0 =A0 =A0I am in support of the modified charter.

=A0 =A0 =A0 =A0The ROLL WG has covered a lot of ground in examining the =A0 =A0 =A0 =A0requirements of an
=A0 =A0 =A0 =A0LLN routing protocol with respect to various applications, = and
=A0 =A0 =A0 =A0the protocol
=A0 =A0 =A0 =A0survey effort does indicate that no existing IETF protocol = without
=A0 =A0 =A0 =A0modification will be a good fit for the requirements.

=A0 =A0 =A0 =A0The modified charter will allow the WG to continue with its= current
=A0 =A0 =A0 =A0momentum and either specify modifications to an existing IE= TF
=A0 =A0 =A0 =A0protocol or a
=A0 =A0 =A0 =A0new protocol in order to meet the demand of industry.


=A0 =A0What do you mean: specify modifications to existing protocol or new=
=A0 =A0protocol? =A0Both? =A0Only one?

=A0 =A0What's the goal of this ambiguous language?

=A0 =A0Alex


I don't understand how this is ambiguous. =A0As has been discussed cons= istently, ROLL needs a specification for a routing protocol, and this speci= fication can stem from modifications to an existing IETF protocol, or from = something new altogether; no stance is taken on which one it should be (and= hence the 'ambiguous' text), and I presume that when we move to th= e next stage proposals of both of these types will be put forward, allowing= the working group to debate their merits.

What next stage? =A0Another round of protocols-survey to definitely answer = debates before the July milestone "first draft of ROLL routing protoco= l spec"?

The protocols-survey draft was Last Call'ed, I suppose it will be sent = soon to IESG (I haven't seen the write-up). =A0Do you mean another prot= ocol evaluation document?

Alex

There is only one protocols-survey, an= d that has been last called. =A0The next stage is where ROLL must put forth= a protocol specification (and possibly more than one), that meets the requ= irements laid out in the protocol-survey and will be embraced as the standa= rd routing protocol for ROLL applications.

- Arsalan
=A0

--001636416983c5eca70464778019-- From jhui@archrock.com Sat Mar 7 17:19:01 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B45003A69EE for ; Sat, 7 Mar 2009 17:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMM4ZNBSloy2 for ; Sat, 7 Mar 2009 17:19:00 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 481B93A677C for ; Sat, 7 Mar 2009 17:19:00 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id A9896AF860; Sat, 7 Mar 2009 17:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeHdHoQbhNNY; Sat, 7 Mar 2009 17:19:31 -0800 (PST) Received: from [10.0.1.200] (adsl-71-142-69-247.dsl.pltn13.pacbell.net [71.142.69.247]) by mail.sf.archrock.com (Postfix) with ESMTP id 88F77AF85D; Sat, 7 Mar 2009 17:19:31 -0800 (PST) Message-Id: <77038A06-BE9B-45A1-B026-27157036E6E6@archrock.com> From: Jonathan Hui To: Arsalan Tavakoli In-Reply-To: <69306dde0903051602i5203f1dekb2b9618233a77bf@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 7 Mar 2009 17:19:29 -0800 References: <69306dde0903041646n7a1871d4u5c4faeab93978786@mail.gmail.com> <2a3692de0903050003g1c183908t784406e5f223a389@mail.gmail.com> <49AFF248.5080801@eecs.berkeley.edu> <2a3692de0903050913h1ba5813al49228a770606d74a@mail.gmail.com> <69306dde0903051602i5203f1dekb2b9618233a77bf@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: roll@ietf.org, "David E. Culler" Subject: Re: [Roll] draft-tavakoli-hydro-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 01:19:01 -0000 It's also worth mentioning that many of the core ideas in HYDRO have been in use commercially for over two years now, including use of multiple default routes going out and source routes going in, use of border routers for maintaining network-wide topology, data-driven link estimation using an additive metric as well as confidence metric, use of options in existing ICMP messages, trickle-style Router Advertisement timing, and more. You can see published results from a complete IPv6 implementation here: http://www.cs.berkeley.edu/~jwhui/pubs/jhui-sensys08-ipv6.pdf You can also find more in-depth information here: http://www.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008-116.html -- Jonathan Hui On Mar 5, 2009, at 4:02 PM, Arsalan Tavakoli wrote: > Dominik, > A real implementation of HYDRO exists, and we have been testing > it internally on various campus projects and testbeds, and plan to > release the code soon. In addition, a technical report providing > evaluation results, and design details from this implementation and > testing should be released in about a month or so. > > - Arsalan > > On Thu, Mar 5, 2009 at 9:13 AM, Dominik Kaspar > wrote: > Hi David, > > Thanks for the clarifications. I was not speaking from a MANET's point > of view, but was just probing whether ROLL has now entered the > "protocol design stage" or not. > > Anyway, the draft looks very interesting. Have there been research > papers published with results from a real implementation of HYDRO? > > Best regards, > Dominik > - Show quoted text - > > > On Thu, Mar 5, 2009 at 4:39 PM, David E. Culler > wrote: > > Dominik, > > Although seeing a question such as yours may tempt one to head > down just > > such a path, alas, such political maneuvering is not what the IETF > is for. > > The IETF encourages individual submissions in order to further a > process of > > informed discussion, rather than mere opinion and positioning. > Only if there > > is willingness to focus on the challenges at hand can rough > consensus and > > running code emerge. Now that ROLL has gone to great pains and > delay to > > examine such protocols it has begun the process of rechartering. > Once that > > is complete it will be possible to consider extensions to existing > > protocols, such as those previously proposed to address mobility > in MANET. > > Hopefully, individuals in MANET will have begun thinking about such > > protocols might possibly made to work in a context where resources > are > > highly constrained and link loss is non-negligible. These are very > different > > issues from dealing with a device moving out of range, so don't > > underestimate how much technical work there is to address even the > > stationary problem. > > What submission of this draft does suggest is that at least > some members > > of ROLL would like to have the opportunity to consider protocols > other that > > those historically put forward by MANET. There are many such > protocols and > > a substantial body of implementation experience and empirical > analysis. Few > > of them have been cast into I-D form, so it is hard for the IETF > to give > > them serious thought. > > I do hope that representatives of MANET will participate in such > > discussions regarding technical merit of options and alternatives. > > > > D. > > > > > > Dominik Kaspar wrote: > > > > Hello. > > > > Can the posting of this protocol specification be interpreted as the > > strategical decision to ignore existing protocols (MANET) and move > > ahead with ROLL's own solution? > > > > Regards, > > Dominik > > > > On Thu, Mar 5, 2009 at 1:46 AM, Arsalan Tavakoli > > wrote: > > > > > > http://www.ietf.org/internet-drafts/draft-tavakoli-hydro-00.txt > > > > This is the draft of a new protocol specification for a routing > protocol for > > L2Ns that we thought members of this working group might find > interesting. > > Any comments/feedback/questions would be highly appreciated, and > we will > > attempt to incorporate those we receive before Monday (cutoff date > for IETF > > documents) into a -01 version of the draft. > > Thanks in advance, > > Arsalan > > ----------------------------------------------------- > > A new version of I-D, draft-tavakoli-hydro-00.txt has been > successfuly > > submitted by Arsalan Tavakoli and posted to the IETF repository. > > > > Filename: draft-tavakoli-hydro > > Revision: 00 > > Title: HYDRO: A Hybrid Routing Protocol for Lossy and > Low Power > > Networks > > Creation_date: 2009-03-04 > > WG ID: Independent Submission > > Number_of_pages: 27 > > > > Abstract: > > HYDRO is a hybrid routing protocol for Lossy and Low power Networks > > (L2Ns) that embraces centralized and distributed routing mechanisms. > > Through the use of standard ICMP Route Advertisements and Route > > Solicitations, Node Routers build Default Routes to Border Routers. > > These routes, which maintain multiple options per each Node Router > > when available, are maintained through data-driven link estimation. > > Node Routers periodically report a high-quality subset of their > > Default Route Table to Border Routers, which then form a global view > > of the topology. When a Node Router attempts to route to another > > Node Router in the network, if no matching entry exists in the Node > > Router's Flow Table, it forwards the packet to a Border Router, > which > > then installs the correct Flow Table Entries in the network to > enable > > more efficient subsequent routing. > > > > _______________________________________________ > > 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 mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Sat Mar 7 19:35:11 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85DA93A6876; Sat, 7 Mar 2009 19:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7EObUR4ZD9v; Sat, 7 Mar 2009 19:35:10 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 8C1F23A6837; Sat, 7 Mar 2009 19:35:10 -0800 (PST) Received: from [32.153.29.25] (helo=[10.83.229.41]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Lg9nd-0004Ln-Jt; Sat, 07 Mar 2009 19:35:43 -0800 Message-Id: From: Philip Levis To: Arsalan Tavakoli In-Reply-To: <69306dde0903061032w5f592e20le5ba28a1482c1fbe@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1-478084859 X-Mailer: iPhone Mail (5H11) Mime-Version: 1.0 (iPhone Mail 5H11) Date: Sat, 7 Mar 2009 19:35:19 -0800 References: <20090304153927.4A1C43A6CD4@core3.amsl.com> <49B14332.10507@ekasystems.com> <49B15E6E.1000705@gmail.com> <69306dde0903060938o20ecb259q36c264e625f15fbd@mail.gmail.com> <49B1675D.8060805@gmail.com> <69306dde0903061032w5f592e20le5ba28a1482c1fbe@mail.gmail.com> X-Scan-Signature: 365f6f5e44d6f8db2699abaf9e884e33 Cc: "roll@ietf.org" , "iesg@ietf.org" Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 03:35:11 -0000 --Apple-Mail-1-478084859 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Comments inline. On Mar 6, 2009, at 10:32 AM, Arsalan Tavakoli =20 wrote: > > > On Fri, Mar 6, 2009 at 10:11 AM, Alexandru Petrescu = > wrote: > Arsalan Tavakoli a =C3=A9crit : > Comments inline. > > > On Fri, Mar 6, 2009 at 9:33 AM, Alexandru Petrescu = > wrote: > > Tim Winter a =C3=A9crit : > > I am in support of the modified charter. > > The ROLL WG has covered a lot of ground in examining the > requirements of an > LLN routing protocol with respect to various applications, and > the protocol > survey effort does indicate that no existing IETF protocol =20 > without > modification will be a good fit for the requirements. > > The modified charter will allow the WG to continue with its =20 > current > momentum and either specify modifications to an existing IETF > protocol or a > new protocol in order to meet the demand of industry. > > > What do you mean: specify modifications to existing protocol or new > protocol? Both? Only one? > > What's the goal of this ambiguous language? > > Alex > > > I don't understand how this is ambiguous. As has been discussed =20 > consistently, ROLL needs a specification for a routing protocol, and =20= > this specification can stem from modifications to an existing IETF =20 > protocol, or from something new altogether; no stance is taken on =20 > which one it should be (and hence the 'ambiguous' text), and I =20 > presume that when we move to the next stage proposals of both of =20 > these types will be put forward, allowing the working group to =20 > debate their merits. > > What next stage? Another round of protocols-survey to definitely =20 > answer debates before the July milestone "first draft of ROLL =20 > routing protocol spec"? > > The protocols-survey draft was Last Call'ed, I suppose it will be =20 > sent soon to IESG (I haven't seen the write-up). Do you mean =20 > another protocol evaluation document? > > Alex > > There is only one protocols-survey, and that has been last called. =20= > The next stage is where ROLL must put forth a protocol specification =20= > (and possibly more than one), that meets the requirements laid out =20 > in the protocol-survey and will be embraced as the standard routing =20= > protocol for ROLL applications. > > - Arsalan > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll This is not quite right. Protocols need to meet the requirements of =20 the application documents.=20= --Apple-Mail-1-478084859 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Comments = inline. 


On Mar 6, 2009, at = 10:32 AM, Arsalan Tavakoli <arsalan@eecs.berkeley.edu> = wrote:



On Fri, Mar 6, 2009 at 10:11 AM, Alexandru = Petrescu <alexandru.petrescu@gmail.com<= /a>> wrote:
Arsalan Tavakoli a =C3=A9crit :
Comments inline.


On Fri, Mar 6, 2009 at 9:33 AM, Alexandru Petrescu <alexandru.petrescu@gmail.com<= /a> <mailto:alexandru.petrescu@gmail.com<= /a>>> wrote:

   Tim Winter a =C3=A9crit :

       I am in support of the modified charter.

       The ROLL WG has covered a lot of ground in = examining the
       requirements of an
       LLN routing protocol with respect to various = applications, and
       the protocol
       survey effort does indicate that no existing = IETF protocol without
       modification will be a good fit for the = requirements.

       The modified charter will allow the WG to = continue with its current
       momentum and either specify modifications to = an existing IETF
       protocol or a
       new protocol in order to meet the demand of = industry.


   What do you mean: specify modifications to existing = protocol or new
   protocol?  Both?  Only one?

   What's the goal of this ambiguous language?

   Alex


I don't understand how this is ambiguous.  As has been discussed = consistently, ROLL needs a specification for a routing protocol, and = this specification can stem from modifications to an existing IETF = protocol, or from something new altogether; no stance is taken on which = one it should be (and hence the 'ambiguous' text), and I presume that = when we move to the next stage proposals of both of these types will be = put forward, allowing the working group to debate their merits.

What next stage?  Another round of protocols-survey to definitely = answer debates before the July milestone "first draft of ROLL routing = protocol spec"?

The protocols-survey draft was Last Call'ed, I suppose it will be sent = soon to IESG (I haven't seen the write-up).  Do you mean another = protocol evaluation document?

Alex

There is only one protocols-survey, = and that has been last called.  The next stage is where ROLL must = put forth a protocol specification (and possibly more than one), that = meets the requirements laid out in the protocol-survey and will be = embraced as the standard routing protocol for ROLL applications.

- Arsalan
 

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

This is = not quite right.  Protocols need to meet the requirements of the = application documents. 
= --Apple-Mail-1-478084859-- From dominique.barthel@orange-ftgroup.com Mon Mar 9 04:57:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABFC23A682E; Mon, 9 Mar 2009 04:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCfaMHYyvnn8; Mon, 9 Mar 2009 04:57:43 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 6D65E28C1CF; Mon, 9 Mar 2009 04:57:42 -0700 (PDT) Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Mar 2009 12:58:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A0AE.52EC567A" Date: Mon, 9 Mar 2009 12:56:15 +0100 Message-ID: <941BA0BF46DB8F4983FF7C8AFE800BC208B727D9@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) Thread-Index: Acmgrgyh0p19otTTTYqcckpDeKcuyA== From: To: X-OriginalArrivalTime: 09 Mar 2009 11:58:15.0000 (UTC) FILETIME=[53F3A580:01C9A0AE] Cc: iesg@ietf.org Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 11:57:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A0AE.52EC567A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm in favor of the proposed new charter, allowing us to move to the next step. Dominique ------_=_NextPart_001_01C9A0AE.52EC567A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Roll] WG Review: Recharter of Routing Over Low power and = Lossy networks (roll)

I'm in favor of the proposed new = charter, allowing us to move to the next step.
Dominique

------_=_NextPart_001_01C9A0AE.52EC567A-- From jabeille@cisco.com Mon Mar 9 05:26:56 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 635BD3A693C; Mon, 9 Mar 2009 05:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WneaSzsCD8-z; Mon, 9 Mar 2009 05:26:55 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 820983A692A; Mon, 9 Mar 2009 05:26:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,329,1233532800"; d="scan'208,217";a="152803388" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-1.cisco.com with ESMTP; 09 Mar 2009 12:27:28 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n29CRSNb029803; Mon, 9 Mar 2009 13:27:28 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n29CRSU2015636; Mon, 9 Mar 2009 12:27:28 GMT Received: from xmb-ams-33d.emea.cisco.com ([144.254.231.92]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Mar 2009 13:27:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A0B2.68CF275B" Date: Mon, 9 Mar 2009 13:27:27 +0100 Message-ID: <38F26F36EAA981478A49D1F37F474A8602C33A6D@xmb-ams-33d.emea.cisco.com> In-Reply-To: <941BA0BF46DB8F4983FF7C8AFE800BC208B727D9@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] WG Review: Recharter of Routing Over Low power and Lossynetworks (roll) Thread-Index: Acmgrgyh0p19otTTTYqcckpDeKcuyAABE/rg References: <941BA0BF46DB8F4983FF7C8AFE800BC208B727D9@ftrdmel3> From: "Julien Abeille (jabeille)" To: , X-OriginalArrivalTime: 09 Mar 2009 12:27:28.0073 (UTC) FILETIME=[68DD5B90:01C9A0B2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2667; t=1236601648; x=1237465648; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20RE=3A=20[Roll]=20WG=20Review=3A=20Recharter=20o f=20Routing=20Over=20Low=20power=20and=20Lossynetworks=20(ro ll) |Sender:=20; bh=FasIETGRfFBfySi0xJK/jfaq7/QyXzpbxrbrlgLW+BY=; b=uebyDe+J0Ac1ssY8jp7APZRtpyS3qbluUl77eryFqnCNtL3n4bz0UqiCne KuXgmSo/zctQI9IlUVoe3tpGN84Hj+AbLqjGLhe+EtinNr5tw5Qb0YctnZJr V3XfbU6qyl; Authentication-Results: ams-dkim-2; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: iesg@ietf.org Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossynetworks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 12:26:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A0B2.68CF275B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 I am in favor as well. =20 Best, Julien ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of dominique.barthel@orange-ftgroup.com Sent: lundi 9 mars 2009 12:56 To: roll@ietf.org Cc: iesg@ietf.org Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossynetworks (roll) I'm in favor of the proposed new charter, allowing us to move to the next step. Dominique=20 ------_=_NextPart_001_01C9A0B2.68CF275B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Roll] WG Review: Recharter of Routing Over Low = power and Lossy networks (roll)
Hi all,
 
I am in favor as well.
 
Best,
Julien

From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of=20 dominique.barthel@orange-ftgroup.com
Sent: lundi 9 mars = 2009=20 12:56
To: roll@ietf.org
Cc: = iesg@ietf.org
Subject:=20 Re: [Roll] WG Review: Recharter of Routing Over Low power and = Lossynetworks=20 (roll)

I'm in favor of the proposed new charter, = allowing us=20 to move to the next step.

Dominique=20

------_=_NextPart_001_01C9A0B2.68CF275B-- From zach@sensinode.com Mon Mar 9 05:29:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28E453A6956; Mon, 9 Mar 2009 05:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnnrnQjQUpt8; Mon, 9 Mar 2009 05:29:08 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 0B05E3A692A; Mon, 9 Mar 2009 05:29:07 -0700 (PDT) Received: from i021199.gprs.dnafinland.fi (i021199.gprs.dnafinland.fi [87.95.21.199]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n29CTYPH019340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2009 14:29:37 +0200 Message-ID: <49B50C92.4080302@sensinode.com> Date: Mon, 09 Mar 2009 14:33:22 +0200 From: Zach Shelby User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: iesg@ietf.org References: <941BA0BF46DB8F4983FF7C8AFE800BC208B727D9@ftrdmel3> <38F26F36EAA981478A49D1F37F474A8602C33A6D@xmb-ams-33d.emea.cisco.com> In-Reply-To: <38F26F36EAA981478A49D1F37F474A8602C33A6D@xmb-ams-33d.emea.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossynetworks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 12:29:09 -0000 Hi, The new ROLL charter has my full support as well. - Zach Julien Abeille (jabeille) wrote: > Hi all, > > I am in favor as well. > > Best, > Julien > > ------------------------------------------------------------------------ > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On Behalf > Of *dominique.barthel@orange-ftgroup.com > *Sent:* lundi 9 mars 2009 12:56 > *To:* roll@ietf.org > *Cc:* iesg@ietf.org > *Subject:* Re: [Roll] WG Review: Recharter of Routing Over Low power and > Lossynetworks (roll) > > I'm in favor of the proposed new charter, allowing us to move to the > next step. > > Dominique > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. From pthubert@cisco.com Mon Mar 9 06:45:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F54F3A6B5B; Mon, 9 Mar 2009 06:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.392 X-Spam-Level: X-Spam-Status: No, score=-10.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XeA1WcTXih9; Mon, 9 Mar 2009 06:45:08 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 569703A6C3B; Mon, 9 Mar 2009 06:45:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,329,1233532800"; d="scan'208";a="35636300" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Mar 2009 13:45:40 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n29DjdrZ011533; Mon, 9 Mar 2009 14:45:39 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n29DjdGR015045; Mon, 9 Mar 2009 13:45:39 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Mar 2009 14:45:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Mar 2009 14:45:33 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC071A590D@xmb-ams-337.emea.cisco.com> In-Reply-To: <20090304153927.4A1C43A6CD4@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Routing Over Low power and Lossy networks (roll) Thread-Index: Acmc36FqQe3Nr9LkQrCaGPYPHzda9AD27AUA References: <20090304153927.4A1C43A6CD4@core3.amsl.com> From: "Pascal Thubert (pthubert)" To: , "IETF Announcement list" X-OriginalArrivalTime: 09 Mar 2009 13:45:39.0592 (UTC) FILETIME=[553A5880:01C9A0BD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7832; t=1236606339; x=1237470339; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20WG=20Review=3A=20Recharter=20of=20Routi ng=20Over=20Low=20power=20and=20Lossy=20networks=20(roll)=20 |Sender:=20; bh=RPWAGQV13Q5MdwL5hZUCkq0yJRR4dPG5ItQB83eMlIs=; b=sJKAeKrggpl9WL4NML/F7O94K0W3pwfcwzyr1ZTumSiPm+phoyAnOD/z/3 S3nnriAlmgGVW9VCHV4YmEiNDzKc3kGE6X0qBzyPgAu4YhwZ9WKlXiAAA/FC zqWnQhRvhj; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org, culler@eecs.berkeley.edu Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 13:45:09 -0000 Dear chairs: The revisited charter is already very clear and specific and I definitely support it. This being said, I'd appreciate a little clarification: If the architectural framework ends up allowing for both centralized and distributed, and/or even a hybrid of those, then we might end up with 2 protocols that make equal sense, or a suite of protocol bricks that might be assembled in various fashions depending on the specific case we are looking at, e.g. industrial vs. building.=20 I understand that the "Protocol work" does not absolutely constrain to a single protocol, or does it? =20 Pascal >-----Original Message----- >From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IESG Secretary >Sent: mercredi 4 mars 2009 16:39 >To: IETF Announcement list >Cc: roll@ietf.org; culler@eecs.berkeley.edu >Subject: WG Review: Recharter of Routing Over Low power and Lossy networks (roll) > >A modified charter has been submitted for the Routing Over Low power and >Lossy networks working group in the Routing Area of the IETF. The IESG >has not made any determination as yet. The modified charter is provided >below for informational purposes only. Please send your comments to the >IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. > >Routing Over Low power and Lossy networks (roll) >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >Last Modified: 2009-02-04 > >Current Status: Active Working Group > >Additional information is available at tools.ietf.org/wg/roll > >Chair(s): > >JP Vasseur >David Culler > >Routing Area Director(s): > >Ross Callon >David Ward > >Routing Area Advisor: >David Ward > >Mailing Lists: > >General Discussion: roll@ietf.org >To Subscribe: http://www.ietf.org/mailman/listinfo/roll >Archive: http://www.ietf.org/mail-archive/web/roll/ > >Description of Working Group: > >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. >As shown in a protocol survey existing routing protocols (in their current > >form) such as OSPF, IS-IS, AODV, and OLSR, do not meet 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. > >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: In light of the application specific routing >requirements, the > Working Group will either specify a new protocol and/or will select an >existing > routing protocol (with the appropriate extensions in cooperation with >the > relevant Working Group). > >- Documentation of applicability statement of ROLL routing protocols. > >Goals and Milestones: > >Done Submit Routing requirements for Industrial applications to the IESG >to be considered as an Informational RFC. > >Done Submit Routing requirements for Connected Home networks applications >to the IESG to be considered as an Informational RFC. > >Done Submit Routing requirements for Building applications to the IESG to >be considered as an Informational RFC. > >Done Submit Routing requirements for Urban networks applications to the >IESG to be considered as an Informational RFC. > >July 2009 Submit Routing metrics for LLNs document to the IESG to be >considered as a Proposed Standard. > >Feb 2009 Submit Protocol Survey to the IESG to be considered as an >Informational RFC. > >April 2009 Submit Security Framework to the IESG to be considered as an >Informational RFC > >May 2009 Submit the Routing for LLNs Architecture document to the IESG >as an Informational RFC. > >July 2009 Submit first draft of ROLL routing protocol specification as >Proposed Standard. > >Nov 2009 Submit first draft of the MIB module of the ROLL routing >protocol specification. > >Feb 2010 Submit the ROLL routing protocol specification to the IESG as >Proposed Standard. > >March 2010 Submit the MIB module of the ROLL routing protocol >specification to the IESG as Proposed Standard. > >April 2010 Evaluate WG progress, recharter or close. > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/ietf-announce From jvasseur@cisco.com Mon Mar 9 07:04:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1909D3A6931; Mon, 9 Mar 2009 07:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.357 X-Spam-Level: X-Spam-Status: No, score=-10.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8o-wGZvZS-a; Mon, 9 Mar 2009 07:04:45 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 027853A67AF; Mon, 9 Mar 2009 07:04:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,329,1233532800"; d="scan'208";a="35638684" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Mar 2009 14:05:17 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n29E5HWr018712; Mon, 9 Mar 2009 15:05:17 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n29E5HSC022806; Mon, 9 Mar 2009 14:05:17 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Mar 2009 15:05:17 +0100 Received: from dhcp-hlb2-vl250-144-254-42-128.cisco.com ([144.254.42.128]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Mar 2009 15:05:16 +0100 Message-Id: <14922F2E-589D-40FF-A30A-8E361BC7D4A9@cisco.com> From: JP Vasseur To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC071A590D@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 9 Mar 2009 15:05:12 +0100 References: <20090304153927.4A1C43A6CD4@core3.amsl.com> <7892795E1A87F04CADFCCF41FADD00FC071A590D@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 09 Mar 2009 14:05:16.0858 (UTC) FILETIME=[12EEE1A0:01C9A0C0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8435; t=1236607517; x=1237471517; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20WG=20Review=3A=20Recharter=20o f=20Routing=20Over=20Low=20power=20and=20Lossy=20networks=20 (roll) |Sender:=20; bh=ZGvsom9isljonTIfL6UMx0M7sZXK7H3YPSKqol46ZVQ=; b=QMXo51J+H6D2c7Zy2VPj51+4jtFjJGra93/5E4CojDYY9LvzVt9dJTuoQn lFYAcuX0R0acFeW2jSUlw0Y2vf/GVLLmj2JbbycSD3SRXsPxDEtjenfWqraJ UkJU7sPfDI; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG , iesg@ietf.org, "David E. Culler" Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 14:04:47 -0000 Hi Pascal, On Mar 9, 2009, at 2:45 PM, Pascal Thubert (pthubert) wrote: > Dear chairs: > > The revisited charter is already very clear and specific and I > definitely support it. > > This being said, I'd appreciate a little clarification: > > If the architectural framework ends up allowing for both centralized > and > distributed, and/or even a hybrid of those, then we might end up > with 2 > protocols that make equal sense, or a suite of protocol bricks that > might be assembled in various fashions depending on the specific > case we > are looking at, e.g. industrial vs. building. > > I understand that the "Protocol work" does not absolutely constrain > to a > single protocol, or does it? > Correct. Thanks. JP. > Pascal > >> -----Original Message----- >> From: ietf-announce-bounces@ietf.org > [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IESG Secretary >> Sent: mercredi 4 mars 2009 16:39 >> To: IETF Announcement list >> Cc: roll@ietf.org; culler@eecs.berkeley.edu >> Subject: WG Review: Recharter of Routing Over Low power and Lossy > networks (roll) >> >> A modified charter has been submitted for the Routing Over Low power > and >> Lossy networks working group in the Routing Area of the IETF. The >> IESG >> has not made any determination as yet. The modified charter is > provided >> below for informational purposes only. Please send your comments to > the >> IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. >> >> Routing Over Low power and Lossy networks (roll) >> ================================================== >> Last Modified: 2009-02-04 >> >> Current Status: Active Working Group >> >> Additional information is available at tools.ietf.org/wg/roll >> >> Chair(s): >> >> JP Vasseur >> David Culler >> >> Routing Area Director(s): >> >> Ross Callon >> David Ward >> >> Routing Area Advisor: >> David Ward >> >> Mailing Lists: >> >> General Discussion: roll@ietf.org >> To Subscribe: http://www.ietf.org/mailman/listinfo/roll >> Archive: http://www.ietf.org/mail-archive/web/roll/ >> >> Description of Working Group: >> >> 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. >> As shown in a protocol survey existing routing protocols (in their > current >> >> form) such as OSPF, IS-IS, AODV, and OLSR, do not meet 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. >> >> 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: In light of the application specific routing >> requirements, the >> Working Group will either specify a new protocol and/or will select > an >> existing >> routing protocol (with the appropriate extensions in cooperation with >> the >> relevant Working Group). >> >> - Documentation of applicability statement of ROLL routing protocols. >> >> Goals and Milestones: >> >> Done Submit Routing requirements for Industrial applications to the > IESG >> to be considered as an Informational RFC. >> >> Done Submit Routing requirements for Connected Home networks > applications >> to the IESG to be considered as an Informational RFC. >> >> Done Submit Routing requirements for Building applications to the >> IESG > to >> be considered as an Informational RFC. >> >> Done Submit Routing requirements for Urban networks applications to >> the >> IESG to be considered as an Informational RFC. >> >> July 2009 Submit Routing metrics for LLNs document to the IESG to be >> considered as a Proposed Standard. >> >> Feb 2009 Submit Protocol Survey to the IESG to be considered as an >> Informational RFC. >> >> April 2009 Submit Security Framework to the IESG to be considered >> as an >> Informational RFC >> >> May 2009 Submit the Routing for LLNs Architecture document to the > IESG >> as an Informational RFC. >> >> July 2009 Submit first draft of ROLL routing protocol >> specification as >> Proposed Standard. >> >> Nov 2009 Submit first draft of the MIB module of the ROLL routing >> protocol specification. >> >> Feb 2010 Submit the ROLL routing protocol specification to the IESG > as >> Proposed Standard. >> >> March 2010 Submit the MIB module of the ROLL routing protocol >> specification to the IESG as Proposed Standard. >> >> April 2010 Evaluate WG progress, recharter or close. >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nicolas.riou@fr.schneider-electric.com Mon Mar 9 07:22:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC2493A6C57 for ; Mon, 9 Mar 2009 07:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9Abvo+f4kWH for ; Mon, 9 Mar 2009 07:22:09 -0700 (PDT) Received: from mailX03.eud.schneider-electric.com (mailx03.eud.schneider-electric.com [205.167.7.41]) by core3.amsl.com (Postfix) with ESMTP id 2995D3A6C21 for ; Mon, 9 Mar 2009 07:22:09 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX03.eud.schneider-electric.com with ESMTP id 2009030915222023-30469 ; Mon, 9 Mar 2009 15:22:20 +0100 In-Reply-To: To: roll@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: nicolas.riou@fr.schneider-electric.com Date: Mon, 9 Mar 2009 15:21:27 +0100 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 09/03/2009 15:22:31, Serialize complete at 09/03/2009 15:22:31, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 03/09/2009 03:22:20 PM, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 03/09/2009 03:22:32 PM, Serialize complete at 03/09/2009 03:22:32 PM Content-Type: multipart/alternative; boundary="=_alternative 004EF5E0C1257574_=" Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 14:22:10 -0000 Message en plusieurs parties au format MIME --=_alternative 004EF5E0C1257574_= Content-Type: text/plain; charset="US-ASCII" I support this re-charter for ROLL as well. Nicolas --=_alternative 004EF5E0C1257574_= Content-Type: text/html; charset="US-ASCII"
I support this re-charter for ROLL as well.

Nicolas

--=_alternative 004EF5E0C1257574_=-- From abr@zen-sys.com Mon Mar 9 07:22:32 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98A123A6C4C for ; Mon, 9 Mar 2009 07:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSCdo6YjWROx for ; Mon, 9 Mar 2009 07:22:31 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 306E03A6C21 for ; Mon, 9 Mar 2009 07:22:31 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Mar 2009 15:23:04 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429595@zensys17.zensys.local> In-Reply-To: <49B50C92.4080302@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) Thread-Index: AcmgsrxbwgL6jzBeRqC6jaiztm9O8QAD5+eQ References: <941BA0BF46DB8F4983FF7C8AFE800BC208B727D9@ftrdmel3><38F26F36EAA981478A49D1F37F474A8602C33A6D@xmb-ams-33d.emea.cisco.com> <49B50C92.4080302@sensinode.com> From: "Anders Brandt" To: Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 14:22:32 -0000 Hi, The new ROLL charter has my full support. - Anders ------------- Anders Brandt Senior Software Architect =20 Zensys Emdrupvej 26 DK-2100 Copenhagen O DENMARK =20 direct: +45 39130039=20 office: +45 70209940 fax: +4570209950 mail: abr@zen-sys.com web: www.zen-sys.com From menzel.thomas@gmail.com Mon Mar 9 07:21:06 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDFFC3A6C42 for ; Mon, 9 Mar 2009 07:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6Jdb+C3fVEX for ; Mon, 9 Mar 2009 07:21:06 -0700 (PDT) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id 836733A6C21 for ; Mon, 9 Mar 2009 07:21:06 -0700 (PDT) Received: by fxm24 with SMTP id 24so1258867fxm.37 for ; Mon, 09 Mar 2009 07:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=C2+YtgPgRSHkAMHV7PA1eVCBQxcKk3HW68MAiVmUChs=; b=Owr15zNjPdsz2nUjpNHUzCsFqLc/xENJ6zimmxGyU2JkT4mAC4LA7hfmuAQGiasdOP caWif3ObbbTqxLCIOeogEYyB2Sto9CJcVi+PpYYmH5qnz8JIStl6LNcRJ9+n34vcTQn8 zRmWzUVzrX+IORkBB/avkwG85nDKnifImxwC4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=Sw5sQj4i1qFgyZ0AbCadr03sAb675Xj8jl3dtMZqUSajpnMFBR23Q7gK3T56pXLRa6 +wbHofIEewPKsCJVxVGy0QFnJ1oPMmOO3fC5B5JO44NPhwslePPBPH1u1X3ySWSji1W+ VkBhbEgw0Iff2UfPiGTarJi/hCnJyXzeXTFbY= MIME-Version: 1.0 Sender: menzel.thomas@gmail.com Received: by 10.223.108.210 with SMTP id g18mr4535678fap.38.1236608498980; Mon, 09 Mar 2009 07:21:38 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Mar 2009 15:21:38 +0100 X-Google-Sender-Auth: c4e9e4d6ca439b86 Message-ID: From: Thomas Menzel To: roll@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Roll] WG Review: Recharter of Routing Over Low power and Lossynetworks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 14:25:19 -0000 Hi, we from TKN do also support the re-chartering Thomas > Message: 3 > Date: Mon, 09 Mar 2009 14:33:22 +0200 > From: Zach Shelby > Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and > =C2=A0 =C2=A0 =C2=A0 =C2=A0Lossynetworks (roll) > To: iesg@ietf.org > Cc: roll@ietf.org > Message-ID: <49B50C92.4080302@sensinode.com> > Content-Type: text/plain; charset=3Dwindows-1252; format=3Dflowed > > Hi, > > The new ROLL charter has my full support as well. > > - Zach -- Thomas Menzel =C2=A0menzel@tkn.tu-berlin.de =C2=A0Tel: ++49 30 314-23840 Technische Universitaet Berlin, Telecommunication Networks Group (TKN) Sekr. FT 5, Einsteinufer 25, 10587 Berlin, Germany From christian.jacquenet@orange-ftgroup.com Mon Mar 9 08:00:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ABBF3A6CD3 for ; Mon, 9 Mar 2009 08:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9t6JbDjtpMQ for ; Mon, 9 Mar 2009 08:00:09 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id 46D933A6CBD for ; Mon, 9 Mar 2009 08:00:08 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 5DB79700BF; Mon, 9 Mar 2009 16:00:41 +0100 (CET) Received: from PMEXCC11.intranet-paris.francetelecom.fr (unknown [10.196.130.4]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 36F7D7002B; Mon, 9 Mar 2009 16:00:41 +0100 (CET) Received: from PMEXCB30.intranet-paris.francetelecom.fr ([10.196.130.38]) by PMEXCC11.intranet-paris.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.2499); Mon, 9 Mar 2009 16:00:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Mar 2009 15:59:14 +0100 Message-ID: <53DE7AEBE1DD5741A44C36342768192203FF3BB6@PMEXCB30.intranet-paris.francetelecom.fr> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01429595@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] WG Review: Recharter of Routing Over Low power and Lossynetworks (roll) Thread-Index: AcmgsrxbwgL6jzBeRqC6jaiztm9O8QAD5+eQAAFNsTA= References: <941BA0BF46DB8F4983FF7C8AFE800BC208B727D9@ftrdmel3><38F26F36EAA981478A49D1F37F474A8602C33A6D@xmb-ams-33d.emea.cisco.com><49B50C92.4080302@sensinode.com> <6D9687E95918C04A8B30A7D6DA805A3E01429595@zensys17.zensys.local> From: To: "Anders Brandt" , X-OriginalArrivalTime: 09 Mar 2009 15:00:41.0116 (UTC) FILETIME=[D05865C0:01C9A0C7] Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossynetworks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 15:00:10 -0000 +1 Cheers, Christian=2E=20 -----Message d'origine----- De : roll-bounces@ietf=2Eorg [mailto:roll-bounces@ietf=2Eorg] De la part de= Anders Brandt Envoy=E9 : lundi 9 mars 2009 15:23 =C0 : roll@ietf=2Eorg Objet : Re: [Roll] WG Review: Recharter of Routing Over Low power and= Lossynetworks (roll) Hi, The new ROLL charter has my full support=2E - Anders ------------- Anders Brandt Senior Software Architect =20 Zensys Emdrupvej 26 DK-2100 Copenhagen O DENMARK =20 direct: +45 39130039 office: +45 70209940 fax: +4570209950 mail: abr@zen-sys=2Ecom web: www=2Ezen-sys=2Ecom _______________________________________________ Roll mailing list Roll@ietf=2Eorg https://www=2Eietf=2Eorg/mailman/listinfo/roll ********************************* This message and any attachments (the "message") are confidential and= intended solely for the addressees=2E=20 Any unauthorised use or dissemination is prohibited=2E Messages are susceptible to alteration=2E=20 France Telecom Group shall not be liable for the message if altered,= changed or falsified=2E If you are not the intended addressee of this message, please cancel it= immediately and inform the sender=2E ******************************** From dominique.barthel@orange-ftgroup.com Mon Mar 9 09:51:11 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C0BF3A6CBA for ; Mon, 9 Mar 2009 09:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GosSIHdS0T3a for ; Mon, 9 Mar 2009 09:51:10 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id F2F1A3A6CAD for ; Mon, 9 Mar 2009 09:51:06 -0700 (PDT) Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Mar 2009 17:51:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Mar 2009 17:49:40 +0100 Message-ID: <941BA0BF46DB8F4983FF7C8AFE800BC208B72AFC@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Comments on draft-tavakoli-hydro-00.txt Thread-Index: AcmdqNcQZvlCrlEaR/O2uRhNfHfmMQDLI57A References: From: To: X-OriginalArrivalTime: 09 Mar 2009 16:51:40.0997 (UTC) FILETIME=[51F19750:01C9A0D7] Subject: Re: [Roll] Comments on draft-tavakoli-hydro-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 16:51:11 -0000 Hello Arsalan, all, Thanks for this draft, full of technical contents. While I'm still chewing on it, I just wanted to report a few nits that you might want to correct in -01. Best regards, Dominique 8. Extensions - The word "controller" is used twice but was not defined before. I guess you mean Border Router. - "The current draft requires that Edge Routers ... to assign themselves ...". Either "that" or "to" should be removed. ---------------------------------------------------------------------- Message: 1 Date: Wed, 4 Mar 2009 16:46:10 -0800 From: Arsalan Tavakoli Subject: [Roll] draft-tavakoli-hydro-00.txt To: roll@ietf.org Message-ID: <69306dde0903041646n7a1871d4u5c4faeab93978786@mail.gmail.com> Content-Type: text/plain; charset=3D"iso-8859-1" http://www.ietf.org/internet-drafts/draft-tavakoli-hydro-00.txt This is the draft of a new protocol specification for a routing protocol for L2Ns that we thought members of this working group might find interesting. Any comments/feedback/questions would be highly appreciated, and we will attempt to incorporate those we receive before Monday (cutoff date for IETF documents) into a -01 version of the draft. Thanks in advance, Arsalan From Bernard.Tourancheau@ens-lyon.fr Mon Mar 9 10:00:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B09C73A6CDA for ; Mon, 9 Mar 2009 10:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjO4Lf6BkL6y for ; Mon, 9 Mar 2009 10:00:02 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 1B22C3A6831 for ; Mon, 9 Mar 2009 10:00:00 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id B48B2E0828E for ; Mon, 9 Mar 2009 18:00:31 +0100 (CET) Received: from [82.245.104.81] (mir01-2-82-245-104-81.fbx.proxad.net [82.245.104.81]) by smtp6-g21.free.fr (Postfix) with ESMTP id 6F61EE082AF for ; Mon, 9 Mar 2009 18:00:28 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v753.1) In-Reply-To: <20090304153927.4A1C43A6CD4@core3.amsl.com> References: <20090304153927.4A1C43A6CD4@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Bernard Tourancheau Date: Mon, 9 Mar 2009 18:00:18 +0100 To: roll@ietf.org X-Mailer: Apple Mail (2.753.1) Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 17:00:03 -0000 Hi all, I support this rechartering too. Regards, Bernard. -- LIP / ENS-Lyon INRIA Rhone-Alpes, France Le 4 mars 09 =E0 16:39, IESG Secretary a =E9crit : > A modified charter has been submitted for the Routing Over Low =20 > power and > Lossy networks working group in the Routing Area of the IETF. The =20 > IESG > has not made any determination as yet. The modified charter is =20 > provided > below for informational purposes only. Please send your comments =20 > to the > IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. > > Routing Over Low power and Lossy networks (roll) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > Last Modified: 2009-02-04 > > Current Status: Active Working Group > > Additional information is available at tools.ietf.org/wg/roll > > Chair(s): > > JP Vasseur > David Culler > > Routing Area Director(s): > > Ross Callon > David Ward > > Routing Area Advisor: > David Ward > > Mailing Lists: > > General Discussion: roll@ietf.org > To Subscribe: http://www.ietf.org/mailman/listinfo/roll > Archive: http://www.ietf.org/mail-archive/web/roll/ > > Description of Working Group: > > 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 =20 > 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. > As shown in a protocol survey existing routing protocols (in their =20 > current > > form) such as OSPF, IS-IS, AODV, and OLSR, do not meet 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 =20 > industrial > > monitoring, building automation (HVAC, lighting, access control, =20 > 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 =20 > home, > building and urban sensor networks for which routing requirements have > been specified. These application-specific routing requirement =20 > 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 =20 > varying > loss > characteristics and connectivity while permitting low-power =20 > 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 =20= > and > manageability (e.g., self routing configuration) issues. It will =20 > also need > to > consider the transport characteristic the routing protocol messages =20= > will > experience. Mechanisms that protect an LLN from congestion collapse or > that establish some degree of fairness between concurrent =20 > communication > sessions are out of scope of the Working Group. It is expected that > upper-layer applications utilizing LLNs define appropriate mechanisms. > > Work Items: > > - Specification of routing metrics used in path calculation. This > includes > static and dynamic link/node attributes required for routing in =20 > 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 =20 > applied. > > Manageability will be considered with each approach, along with =20 > various > > trade-offs for maintaining low power operation, including the =20 > 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: In light of the application specific routing > requirements, the > Working Group will either specify a new protocol and/or will =20 > select an > existing > routing protocol (with the appropriate extensions in cooperation =20 > with > the > relevant Working Group). > > - Documentation of applicability statement of ROLL routing protocols. > > Goals and Milestones: > > Done Submit Routing requirements for Industrial applications to the =20= > IESG > to be considered as an Informational RFC. > > Done Submit Routing requirements for Connected Home networks =20 > applications > to the IESG to be considered as an Informational RFC. > > Done Submit Routing requirements for Building applications to the =20 > IESG to > be considered as an Informational RFC. > > Done Submit Routing requirements for Urban networks applications to =20= > the > IESG to be considered as an Informational RFC. > > July 2009 Submit Routing metrics for LLNs document to the IESG to be > considered as a Proposed Standard. > > Feb 2009 Submit Protocol Survey to the IESG to be considered as an > Informational RFC. > > April 2009 Submit Security Framework to the IESG to be considered =20 > as an > Informational RFC > > May 2009 Submit the Routing for LLNs Architecture document to the =20= > IESG > as an Informational RFC. > > July 2009 Submit first draft of ROLL routing protocol =20 > specification as > Proposed Standard. > > Nov 2009 Submit first draft of the MIB module of the ROLL routing > protocol specification. > > Feb 2010 Submit the ROLL routing protocol specification to the =20 > IESG as > Proposed Standard. > > March 2010 Submit the MIB module of the ROLL routing protocol > specification to the IESG as Proposed Standard. > > April 2010 Evaluate WG progress, recharter or close. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From m1gs4n@gmail.com Mon Mar 9 10:44:39 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1C0E3A6CDE for ; Mon, 9 Mar 2009 10:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.007 X-Spam-Level: X-Spam-Status: No, score=-1.007 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgyDQup-IOoV for ; Mon, 9 Mar 2009 10:44:39 -0700 (PDT) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id AC6983A695B for ; Mon, 9 Mar 2009 10:44:38 -0700 (PDT) Received: by bwz26 with SMTP id 26so1297226bwz.37 for ; Mon, 09 Mar 2009 10:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:cc:content-type :content-transfer-encoding; bh=RJvtp1rqJJRhia13qdHEB8JZWkako3ERU3/ngsnNVhU=; b=XLFKhc4NR3cmQDXxK708imBx00/4JQypwiT+VLbhknHwOlzI4swKXv8xfQznXXR/3T hW47PO41uLgJhcYcQFUKYVQTqREnaHyuqvlzjrFehPv4QXLgD57GQnhke8yGGTCsek0z U8mDaNP+++0vU7IAUEicOKVEdP5l00Puqjlqo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:cc:content-type:content-transfer-encoding; b=fvvnnHfLoT1ETQqMTml149SJhNKQYrn4Clg5lsofOgPMe6k1iBpCVPswtcmevqeb7f ZMNeiJUZU1LzRE+2NA4e81sfvWQ9mCAdjE3Y1QkZK8BWIKvTyRU2zDIGZXxiplKEDjQ8 14xC8eckfkJ3srUkrr+DvIrGF8Jilfq1VA5BE= MIME-Version: 1.0 Received: by 10.181.148.13 with SMTP id a13mr2122470bko.20.1236620711775; Mon, 09 Mar 2009 10:45:11 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Mar 2009 18:45:11 +0100 Message-ID: <86c3ed7b0903091045p3ba8486ey5dfa56ecf0c6256c@mail.gmail.com> From: =?ISO-8859-1?Q?Miguel_S=E1nchez?= Cc: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: m1gs4n@gmail.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 17:44:39 -0000 Me too. Miguel S=E1nchez On Mon, Mar 9, 2009 at 3:21 PM, w= rote: > > I support this re-charter for ROLL as well. > > Nicolas > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > From samitac@ipinfusion.com Mon Mar 9 11:52:13 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A1223A690E for ; Mon, 9 Mar 2009 11:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qll23Xb+M98t for ; Mon, 9 Mar 2009 11:52:12 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id E98723A6A91 for ; Mon, 9 Mar 2009 11:52:11 -0700 (PDT) Received: (qmail 26079 invoked from network); 9 Mar 2009 18:52:46 -0000 Received: from unknown (HELO samitacD630) (samitac@71.141.116.8 with login) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 9 Mar 2009 18:52:45 -0000 X-YMail-OSG: DiEJde8VM1lccSL4z22C_ihsUqnQ4V4_k1JXVMy8ljjlhB0x_9JuUBvXTHd_c1FrpIxKEI8K3y2nW29Kh3DSiV5TYnQl05kOE8T7smuO0g3O0v4VR_Zy1m7AIU.O1.ydQ16sMOz8YMV0HsVHoe8w_96FfdK541IXwZHyQqaqLkmwlrWYk0g9bStaO0BxCLpzP7o9Je4z4g0CTFjvjHdFMmybBrHqvPJe.nJ3BegFNin.81RI5XGdaBz_8fWf0sZ9MYJf14_o4ISaW_xs76zhB4Hf2u6MLkWexA-- X-Yahoo-Newman-Property: ymail-5 From: "Samita Chakrabarti" To: References: <20090304153927.4A1C43A6CD4@core3.amsl.com> In-Reply-To: Date: Mon, 9 Mar 2009 11:52:43 -0700 Message-ID: <0c0701c9a0e8$3b2a8930$b17f9b90$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-index: Acmg2WWe9uhh68mLSIalYl7UZy7tHAADoqog Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 18:52:13 -0000 I support this charter as well. Thanks, -Samita > Le 4 mars 09 =E0 16:39, IESG Secretary a =E9crit : >=20 > > A modified charter has been submitted for the Routing Over Low power > > and Lossy networks working group in the Routing Area of the IETF. = The > > IESG has not made any determination as yet. The modified charter is > > provided below for informational purposes only. Please send your > > comments to the IESG mailing list (iesg@ietf.org) by Wednesday, = March > > 11, 2009. > > > > Routing Over Low power and Lossy networks (roll) > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > > Last Modified: 2009-02-04 > > > > Current Status: Active Working Group > > > > Additional information is available at tools.ietf.org/wg/roll > > > > Chair(s): > > > > JP Vasseur > > David Culler > > > > Routing Area Director(s): > > > > Ross Callon > > David Ward > > > > Routing Area Advisor: > > David Ward > > > > Mailing Lists: > > > > General Discussion: roll@ietf.org > > To Subscribe: http://www.ietf.org/mailman/listinfo/roll > > Archive: http://www.ietf.org/mail-archive/web/roll/ > > > > Description of Working Group: > > > > 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. > > As shown in a protocol survey existing routing protocols (in their > > current > > > > form) such as OSPF, IS-IS, AODV, and OLSR, do not meet 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. > > > > 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: In light of the application specific routing > > requirements, the > > Working Group will either specify a new protocol and/or will = select > > an existing > > routing protocol (with the appropriate extensions in cooperation > > with the > > relevant Working Group). > > > > - Documentation of applicability statement of ROLL routing = protocols. > > > > Goals and Milestones: > > > > Done Submit Routing requirements for Industrial applications to the > > IESG to be considered as an Informational RFC. > > > > Done Submit Routing requirements for Connected Home networks > > applications to the IESG to be considered as an Informational RFC. > > > > Done Submit Routing requirements for Building applications to the = IESG > > to be considered as an Informational RFC. > > > > Done Submit Routing requirements for Urban networks applications to > > the IESG to be considered as an Informational RFC. > > > > July 2009 Submit Routing metrics for LLNs document to the IESG to be > > considered as a Proposed Standard. > > > > Feb 2009 Submit Protocol Survey to the IESG to be considered as an > > Informational RFC. > > > > April 2009 Submit Security Framework to the IESG to be considered as > > an Informational RFC > > > > May 2009 Submit the Routing for LLNs Architecture document to the > > IESG > > as an Informational RFC. > > > > July 2009 Submit first draft of ROLL routing protocol specification > > as Proposed Standard. > > > > Nov 2009 Submit first draft of the MIB module of the ROLL routing > > protocol specification. > > > > Feb 2010 Submit the ROLL routing protocol specification to the > > IESG as > > Proposed Standard. > > > > March 2010 Submit the MIB module of the ROLL routing protocol > > specification to the IESG as Proposed Standard. > > > > April 2010 Evaluate WG progress, recharter or close. > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll >=20 From adam@sics.se Tue Mar 10 04:37:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9A333A6CB6 for ; Tue, 10 Mar 2009 04:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLLsDRvpIzzk for ; Tue, 10 Mar 2009 04:37:33 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 350C83A6CD3 for ; Tue, 10 Mar 2009 04:37:33 -0700 (PDT) Received: from [85.225.240.251] (c-fbf0e155.771-1-64736c10.cust.bredbandsbolaget.se [85.225.240.251]) by letter.sics.se (Postfix) with ESMTP id CFC2540258; Tue, 10 Mar 2009 12:38:05 +0100 (CET) Message-ID: <49B65120.6000102@sics.se> Date: Tue, 10 Mar 2009 12:38:08 +0100 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Samita Chakrabarti References: <20090304153927.4A1C43A6CD4@core3.amsl.com> <0c0701c9a0e8$3b2a8930$b17f9b90$@com> In-Reply-To: <0c0701c9a0e8$3b2a8930$b17f9b90$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 11:37:34 -0000 I chime in and support the charter. /adam Samita Chakrabarti wrote: > I support this charter as well. > Thanks, > -Samita > > >> Le 4 mars 09 à 16:39, IESG Secretary a écrit : >> >>> A modified charter has been submitted for the Routing Over Low power >>> and Lossy networks working group in the Routing Area of the IETF. The >>> IESG has not made any determination as yet. The modified charter is >>> provided below for informational purposes only. Please send your >>> comments to the IESG mailing list (iesg@ietf.org) by Wednesday, March >>> 11, 2009. >>> >>> Routing Over Low power and Lossy networks (roll) >>> ================================================== >>> Last Modified: 2009-02-04 >>> >>> Current Status: Active Working Group >>> >>> Additional information is available at tools.ietf.org/wg/roll >>> >>> Chair(s): >>> >>> JP Vasseur >>> David Culler >>> >>> Routing Area Director(s): >>> >>> Ross Callon >>> David Ward >>> >>> Routing Area Advisor: >>> David Ward >>> >>> Mailing Lists: >>> >>> General Discussion: roll@ietf.org >>> To Subscribe: http://www.ietf.org/mailman/listinfo/roll >>> Archive: http://www.ietf.org/mail-archive/web/roll/ >>> >>> Description of Working Group: >>> >>> 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. >>> As shown in a protocol survey existing routing protocols (in their >>> current >>> >>> form) such as OSPF, IS-IS, AODV, and OLSR, do not meet 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. >>> >>> 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: In light of the application specific routing >>> requirements, the >>> Working Group will either specify a new protocol and/or will select >>> an existing >>> routing protocol (with the appropriate extensions in cooperation >>> with the >>> relevant Working Group). >>> >>> - Documentation of applicability statement of ROLL routing protocols. >>> >>> Goals and Milestones: >>> >>> Done Submit Routing requirements for Industrial applications to the >>> IESG to be considered as an Informational RFC. >>> >>> Done Submit Routing requirements for Connected Home networks >>> applications to the IESG to be considered as an Informational RFC. >>> >>> Done Submit Routing requirements for Building applications to the IESG >>> to be considered as an Informational RFC. >>> >>> Done Submit Routing requirements for Urban networks applications to >>> the IESG to be considered as an Informational RFC. >>> >>> July 2009 Submit Routing metrics for LLNs document to the IESG to be >>> considered as a Proposed Standard. >>> >>> Feb 2009 Submit Protocol Survey to the IESG to be considered as an >>> Informational RFC. >>> >>> April 2009 Submit Security Framework to the IESG to be considered as >>> an Informational RFC >>> >>> May 2009 Submit the Routing for LLNs Architecture document to the >>> IESG >>> as an Informational RFC. >>> >>> July 2009 Submit first draft of ROLL routing protocol specification >>> as Proposed Standard. >>> >>> Nov 2009 Submit first draft of the MIB module of the ROLL routing >>> protocol specification. >>> >>> Feb 2010 Submit the ROLL routing protocol specification to the >>> IESG as >>> Proposed Standard. >>> >>> March 2010 Submit the MIB module of the ROLL routing protocol >>> specification to the IESG as Proposed Standard. >>> >>> April 2010 Evaluate WG progress, recharter or close. >>> >>> _______________________________________________ >>> 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 > -- Adam Dunkels , +46707731614 http://www.sics.se/~adam/ From ietf@thomasclausen.org Tue Mar 10 05:17:21 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B66E33A6A03; Tue, 10 Mar 2009 05:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hC5nb3X89dqT; Tue, 10 Mar 2009 05:17:21 -0700 (PDT) Received: from mho-01-bos.mailhop.org (mho-01-bos.mailhop.org [63.208.196.178]) by core3.amsl.com (Postfix) with ESMTP id 773AF3A699D; Tue, 10 Mar 2009 05:17:21 -0700 (PDT) Received: from aste-genev-bois-153-1-25-179.w83-112.abo.wanadoo.fr ([83.112.205.179] helo=[192.168.147.106]) by mho-01-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Lh0uB-0009c1-A3; Tue, 10 Mar 2009 12:17:55 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 83.112.205.179 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/rtXAT88ZNjF+yOa1F45zI In-Reply-To: <20090304153927.4A1C43A6CD4@core3.amsl.com> References: <20090304153927.4A1C43A6CD4@core3.amsl.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Thomas Heide Clausen Date: Tue, 10 Mar 2009 13:17:51 +0100 To: iesg@ietf.org X-Mailer: Apple Mail (2.753.1) Cc: roll@ietf.org, "David E. Culler" Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 12:17:21 -0000 Dear All, I am sure that we all want to see the roll work progress in a constructive and conductive way, and so hereby my remarks to the proposed charter. I feel that there are a couple of things which require readjustment in the charter, before it will be useful to the IETF and to the roll working group. I strongly urge that the working group rechartering takes the below into consideration. (i) Traffic characteristics and delivery semantics The proposed charter reads: Typical traffic patterns are not simply unicast flows (e.g. in some cases most if not all traffic can be point to multipoint). Comments: a) It is not clear what the exact semantics of "point-to-multipoint" is. On the roll@ietf.org list, it was made clear that it was "not multicast" as the destination-set for a transmission was not to be determined by the destinations (e.g. through subscribing to a multicast group) but rather by the source. b) It is not clear by which means the source is to make this determination. I can see a number of possibilities, which entail different design constraint on protocol(s) for this space: o the source has a-priori knowledge as to the destination set? o an orthogonal protocol exists which can supply this knowledge as to the destination set? o the destination-set is determined based on a service discovery mapping (e.g. "Send this to all gateways")? c) If an orthogonal protocol exists, it should be referenced, if the WG intends to develop a "service discovery protocol" it should likewise be listed explicitly. d) This "point to multipoint" delivery semantics seems a departure from classic unicast and multicast. Note, I am not suggesting that it is not of relevance and necessitating further reflections, simply observing that this is not a usual delivery semantics for IP networks. e) The "point-to-multipoint" characteristics is brought forward as an important factor in ROLL networks, and is not a "classic" data delivery model for IP -- yet: o the work items do not include definition of this "roll-cast" delivery semantics, including the impact this would have in an IP network (e.g. "how would a routing table look?" for such "roll-cast"; o the work items do not include specification of a protocol which accomplishes this "roll-cast". (ii) Applicability of existing IETF protocols The proposed charter reads: "These specific properties cause LLNs to have specific routing requirements. As shown in a protocol survey existing routing protocols (in their current form) such as OSPF, IS-IS, AODV, and OLSR, do not meet these specific routing requirements." Comments: a) Since the WGLC of this protocol survey document draft-ietf-roll- protocols-survey there have been a large amount of discussion and issues raised, some of which have raised questions regarding if indeed the above conclusion can be drawn based on this document. I am not taking a position on if the conclusion is justified or not in this email, however I note that there were a number of issues and questions raised on this topic on roll@ietf.org, and that it is my impression that these have not all been closed. b) It therefore appears advisable to, before presenting this as a fundamental assumption for the continued work of the roll working group, resolving the issues regarding draft-ietf-roll-protocols-survey. (iii) Protocol work The proposed charter reads: "Protocol work: In light of the application specific routing requirements, the Working Group will either specify a new protocol and/or will select an existing routing protocol (with the appropriate extensions in cooperation with the relevant Working Group)." Comments: a) The working group has produced a set of 4 application specific requirements I-Ds, - draft-ietf-roll-urban-routing-reqs - draft-ietf-roll-indus-routing-reqs - draft-ietf-roll-home-routing-reqs - draft-ietf-roll-building-routing-reqs These are relatively diverse and verbose. b) The current and proposed charter does not stipulate if one or multiple (up to 4?) distinct protocols are to be developed for routing in each of these application specific scenarios. c) Conversely, the current and proposed charter does not include among the work items to identify and extract, from these application specific scenario descriptions, a common set of requirements that will guide the protocol design. d) On the same token, protocol design is often a matter of making acceptable trade-offs. For example, routing protocols often trade off the overhead of control traffic, state necessary for representing the network topology and computational power for calculating routing paths, for the benefit of providing shortest-paths for data traffic. The protocol survey document draft-ietf-roll-protocols-survey, as well as the four application specific requirements documents listed above, does not make it clear what acceptable trade-offs are for ROLL networks, and so it is difficult to extract what proposed protocols make the right or the wrong trade-offs. (iv) Timeline and milestones The proposed charter has as its final milestone for the protocol to be developed: Feb 2010 Submit the ROLL routing protocol specification to the IESG as Proposed Standard. a) I realize that milestones first and foremost are a contract between the ADs and the WG; still I feel that as such may be used to set the pace for the working group, and so I make a couple of comments hereon. b) Considering the amount of work to be undertaken, the diverse application scenario, and the fact that at present only a single an recently submitted protocol proposal (-00 individual submission) exists, less than a year for a protocol to be proposed, tested, understood well enough and widely enough to reach consensus and developed to the point of attaining the maturity of a proposed standard is, at best, very very optimistic. c) I note that Dave Ward, as AD for roll, said on the roll@ietf.org mailing list as recent as February 3: ``I expect "wild swings" of the design pattern of the protocol during the first year of the design effort. I attempted to make this clear at the mic in Minneapolis that the current trajectory is very complex problem domain that hasn't born a lot of fruit but, that in the design phase reducing the complexity must occur. '' I find myself to be in agreement with this statement: I would expect the first year to be an exercise in narrowing down the complexity and evaluate potentially many different proposals and approaches at developing a protocol (set) for the roll problem space, and that protocol maturity would follow once these "wild swings" had dampened. Hope this helps, Thomas On 4Mar , 2009, at 16:39 , IESG Secretary wrote: > A modified charter has been submitted for the Routing Over Low > power and > Lossy networks working group in the Routing Area of the IETF. The > IESG > has not made any determination as yet. The modified charter is > provided > below for informational purposes only. Please send your comments > to the > IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. > > Routing Over Low power and Lossy networks (roll) > ================================================== > Last Modified: 2009-02-04 > > Current Status: Active Working Group > > Additional information is available at tools.ietf.org/wg/roll > > Chair(s): > > JP Vasseur > David Culler > > Routing Area Director(s): > > Ross Callon > David Ward > > Routing Area Advisor: > David Ward > > Mailing Lists: > > General Discussion: roll@ietf.org > To Subscribe: http://www.ietf.org/mailman/listinfo/roll > Archive: http://www.ietf.org/mail-archive/web/roll/ > > Description of Working Group: > > 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. > As shown in a protocol survey existing routing protocols (in their > current > > form) such as OSPF, IS-IS, AODV, and OLSR, do not meet 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. > > 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: In light of the application specific routing > requirements, the > Working Group will either specify a new protocol and/or will > select an > existing > routing protocol (with the appropriate extensions in cooperation > with > the > relevant Working Group). > > - Documentation of applicability statement of ROLL routing protocols. > > Goals and Milestones: > > Done Submit Routing requirements for Industrial applications to the > IESG > to be considered as an Informational RFC. > > Done Submit Routing requirements for Connected Home networks > applications > to the IESG to be considered as an Informational RFC. > > Done Submit Routing requirements for Building applications to the > IESG to > be considered as an Informational RFC. > > Done Submit Routing requirements for Urban networks applications to > the > IESG to be considered as an Informational RFC. > > July 2009 Submit Routing metrics for LLNs document to the IESG to be > considered as a Proposed Standard. > > Feb 2009 Submit Protocol Survey to the IESG to be considered as an > Informational RFC. > > April 2009 Submit Security Framework to the IESG to be considered > as an > Informational RFC > > May 2009 Submit the Routing for LLNs Architecture document to the > IESG > as an Informational RFC. > > July 2009 Submit first draft of ROLL routing protocol > specification as > Proposed Standard. > > Nov 2009 Submit first draft of the MIB module of the ROLL routing > protocol specification. > > Feb 2010 Submit the ROLL routing protocol specification to the > IESG as > Proposed Standard. > > March 2010 Submit the MIB module of the ROLL routing protocol > specification to the IESG as Proposed Standard. > > April 2010 Evaluate WG progress, recharter or close. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Jerald.P.Martocci@jci.com Tue Mar 10 11:00:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C87233A68B8 for ; Tue, 10 Mar 2009 11:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.314 X-Spam-Level: X-Spam-Status: No, score=-6.314 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeWqT2BpFOqz for ; Tue, 10 Mar 2009 11:00:24 -0700 (PDT) Received: from exprod8og107.obsmtp.com (exprod8og107.obsmtp.com [64.18.3.94]) by core3.amsl.com (Postfix) with ESMTP id 3EFCE3A6878 for ; Tue, 10 Mar 2009 11:00:24 -0700 (PDT) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob107.postini.com ([64.18.7.12]) with SMTP ID DSNKSbaq2jaJtOXqz98oqfcy+IWFAHSsazlM@postini.com; Tue, 10 Mar 2009 11:01:00 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009031013005163-129663 ; Tue, 10 Mar 2009 13:00:51 -0500 In-Reply-To: <7336D5AD-ED98-4D80-A7ED-9AF2A76BB1F6@cisco.com> MIME-Version: 1.0 To: JP Vasseur X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Tue, 10 Mar 2009 13:00:51 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 03/10/2009 01:00:54 PM, Serialize complete at 03/10/2009 01:00:54 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 03/10/2009 01:00:51 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 03/10/2009 01:00:57 PM, Serialize complete at 03/10/2009 01:00:57 PM Content-Type: multipart/alternative; boundary="=_alternative 0062F42286257575_=" Cc: roll@ietf.org Subject: Re: [Roll] Fwd: WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 18:00:26 -0000 This is a multipart message in MIME format. --=_alternative 0062F42286257575_= Content-Type: text/plain; charset="US-ASCII" JP, All, Once I got the finalized text last week, I circulated it throughout Johnson Controls Engineering and Management to assure that we (ROLL) hadn't missed anything in the charter. All feedback has been good. Let's start digging into the new charter. I am all for it. Best Regards, Jerry JP Vasseur 03/10/2009 12:34 PM To Jerald P Martocci cc Subject Fwd: WG Review: Recharter of Routing Over Low power and Lossy networks (roll) If you support the new charter, your feed-back is very much welcome. Begin forwarded message: From: IESG Secretary Date: March 4, 2009 4:39:27 PM CEST To: IETF Announcement list Cc: jpv@cisco.com, culler@eecs.berkeley.edu, roll@ietf.org Subject: WG Review: Recharter of Routing Over Low power and Lossy networks (roll) Reply-To: iesg@ietf.org A modified charter has been submitted for the Routing Over Low power and Lossy networks working group in the Routing Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. Routing Over Low power and Lossy networks (roll) ================================================== Last Modified: 2009-02-04 Current Status: Active Working Group Additional information is available at tools.ietf.org/wg/roll Chair(s): JP Vasseur David Culler Routing Area Director(s): Ross Callon David Ward Routing Area Advisor: David Ward Mailing Lists: General Discussion: roll@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/roll Archive: http://www.ietf.org/mail-archive/web/roll/ Description of Working Group: 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. As shown in a protocol survey existing routing protocols (in their current form) such as OSPF, IS-IS, AODV, and OLSR, do not meet 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. 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: In light of the application specific routing requirements, the Working Group will either specify a new protocol and/or will select an existing routing protocol (with the appropriate extensions in cooperation with the relevant Working Group). - Documentation of applicability statement of ROLL routing protocols. Goals and Milestones: Done Submit Routing requirements for Industrial applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Connected Home networks applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Building applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Urban networks applications to the IESG to be considered as an Informational RFC. July 2009 Submit Routing metrics for LLNs document to the IESG to be considered as a Proposed Standard. Feb 2009 Submit Protocol Survey to the IESG to be considered as an Informational RFC. April 2009 Submit Security Framework to the IESG to be considered as an Informational RFC May 2009 Submit the Routing for LLNs Architecture document to the IESG as an Informational RFC. July 2009 Submit first draft of ROLL routing protocol specification as Proposed Standard. Nov 2009 Submit first draft of the MIB module of the ROLL routing protocol specification. Feb 2010 Submit the ROLL routing protocol specification to the IESG as Proposed Standard. March 2010 Submit the MIB module of the ROLL routing protocol specification to the IESG as Proposed Standard. April 2010 Evaluate WG progress, recharter or close. --=_alternative 0062F42286257575_= Content-Type: text/html; charset="US-ASCII"

JP, All,

Once I got the finalized text last week, I circulated it throughout Johnson Controls Engineering and Management to assure that we (ROLL) hadn't missed anything in the charter.  All feedback has been good.  

Let's start digging into the new charter.  I am all for it.

Best Regards,

Jerry




JP Vasseur <jvasseur@cisco.com>

03/10/2009 12:34 PM

To
Jerald P Martocci <Jerald.P.Martocci@jci.com>
cc
Subject
Fwd: WG Review: Recharter of Routing Over Low power and Lossy  networks (roll)





If you support the new charter, your feed-back is very much welcome.

Begin forwarded message:

From: IESG Secretary <iesg-secretary@ietf.org>
Date: March 4, 2009 4:39:27 PM CEST
To: IETF Announcement list <ietf-announce@ietf.org>
Cc: jpv@cisco.com, culler@eecs.berkeley.edu, roll@ietf.org
Subject: WG Review: Recharter of Routing Over Low power and Lossy  networks (roll)
Reply-To: iesg@ietf.org

A modified charter has been submitted for the Routing Over Low power and
Lossy networks working group in the Routing Area of the IETF.  The IESG
has not made any determination as yet.  The modified charter is provided
below for informational purposes only.  Please send your comments to the
IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009.

Routing Over Low power and Lossy networks (roll)
==================================================
Last Modified: 2009-02-04

Current Status: Active Working Group

Additional information is available at tools.ietf.org/wg/roll

Chair(s):

JP Vasseur <jpv@cisco.com>
David Culler <culler@eecs.berkeley.edu>

Routing Area Director(s):

Ross Callon <rcallon@juniper.net>
David Ward <dward@cisco.com>

Routing Area Advisor:
David Ward <dward@cisco.com>

Mailing Lists:

General Discussion: roll@ietf.org
To Subscribe: http://www.ietf.org/mailman/listinfo/roll
Archive: http://www.ietf.org/mail-archive/web/roll/

Description of Working Group:

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.
As shown in a protocol survey existing routing protocols (in their current

form) such as OSPF, IS-IS, AODV, and OLSR, do not meet 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.

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: In light of the application specific routing
requirements, the
Working Group will either specify a new protocol and/or will select an
existing
routing protocol (with the appropriate extensions in cooperation with
the
relevant Working Group).

- Documentation of applicability statement of ROLL routing protocols.

Goals and Milestones:

Done Submit Routing requirements for Industrial applications to the IESG
to be considered as an Informational RFC.

Done Submit Routing requirements for Connected Home networks applications
to the IESG to be considered as an Informational RFC.

Done Submit Routing requirements for Building applications to the IESG to
be considered as an Informational RFC.

Done Submit Routing requirements for Urban networks applications to the
IESG to be considered as an Informational RFC.

July 2009 Submit Routing metrics for LLNs document to the IESG to be
considered as a Proposed Standard.

Feb 2009 Submit Protocol Survey to the IESG to be considered as an
Informational RFC.

April 2009 Submit Security Framework to the IESG to be considered as an
Informational RFC

May 2009   Submit the Routing for LLNs Architecture document to the IESG
as an Informational RFC.

July 2009  Submit first draft of ROLL routing protocol specification as
Proposed Standard.

Nov 2009   Submit first draft of the MIB module of the ROLL routing
protocol specification.

Feb 2010   Submit the ROLL routing protocol specification to the IESG as
Proposed Standard.

March 2010 Submit the MIB module of the ROLL routing protocol
specification to the IESG as Proposed Standard.

April 2010 Evaluate WG progress, recharter or close.

--=_alternative 0062F42286257575_=-- From pierre.colle@fr.schneider-electric.com Wed Mar 11 08:20:01 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44E9D3A68E6 for ; Wed, 11 Mar 2009 08:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKJdVaAbDbiv for ; Wed, 11 Mar 2009 08:19:56 -0700 (PDT) Received: from mailX02.eud.schneider-electric.com (mailx02.eud.schneider-electric.com [205.167.7.38]) by core3.amsl.com (Postfix) with ESMTP id BB2BB28C205 for ; Wed, 11 Mar 2009 08:19:49 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX02.eud.schneider-electric.com with ESMTP id 2009031116201895-47339 ; Wed, 11 Mar 2009 16:20:18 +0100 To: roll@ietf.org X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: pierre.colle@fr.schneider-electric.com Date: Wed, 11 Mar 2009 16:20:18 +0100 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 11/03/2009 16:20:25, Itemize by SMTP Server on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 03/11/2009 04:20:18 PM, Serialize by Router on AXEU2OUT.schneider-electric.com/X/SVR/SEIxtra at 03/11/2009 04:20:20 PM Content-type: multipart/related; Boundary="0__=4EBBFFE5DFC7969E8f9e8a93df938690918c4EBBFFE5DFC7969E" Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 15:20:01 -0000 --0__=4EBBFFE5DFC7969E8f9e8a93df938690918c4EBBFFE5DFC7969E Content-type: multipart/alternative; Boundary="1__=4EBBFFE5DFC7969E8f9e8a93df938690918c4EBBFFE5DFC7969E" --1__=4EBBFFE5DFC7969E8f9e8a93df938690918c4EBBFFE5DFC7969E Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=US-ASCII Hello, I support this rechartering too. Best regards, Pierre Technopole 38TEC T1 -TI 37 quai Paul-Louis Merlin FR - 38050 Grenoble Cedex 9 pierre.colle@fr.schneider-electric.com +33 (0)4 76 57 30 19 / 34 30 19 > A modified charter has been submitted for the Routing Over Low > power and > Lossy networks working group in the Routing Area of the IETF. The > IESG > has not made any determination as yet. The modified charter is > provided > below for informational purposes only. Please send your comments > to the > IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. > > Routing Over Low power and Lossy networks (roll) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Last Modified: 2009-02-04 > > Current Status: Active Working Group > > Additional information is available at tools.ietf.org/wg/roll > > Chair(s): > > JP Vasseur > David Culler > > Routing Area Director(s): > > Ross Callon > David Ward > > Routing Area Advisor: > David Ward > > Mailing Lists: > > General Discussion: roll@ietf.org > To Subscribe: http://www.ietf.org/mailman/listinfo/roll > Archive: http://www.ietf.org/mail-archive/web/roll/ > > Description of Working Group: > > 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 specificall= y > 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. > As shown in a protocol survey existing routing protocols (in their > current > > form) such as OSPF, IS-IS, AODV, and OLSR, do not meet 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 hav= e > been specified. These application-specific routing requirement > documents > will be used for protocol design. > > The Working Group focuses only on IPv6 routing architectural framewor= k > 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 comprisin= g > 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 o= r > 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= . > > 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 a= t > Layer 3 (Routing for LLN Architecture) that addresses such issues a= s > 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: In light of the application specific routing > requirements, the > Working Group will either specify a new protocol and/or will > select an > existing > routing protocol (with the appropriate extensions in cooperation > with > the > relevant Working Group). > > - Documentation of applicability statement of ROLL routing protocols.= > > Goals and Milestones: > > Done Submit Routing requirements for Industrial applications to the > IESG > to be considered as an Informational RFC. > > Done Submit Routing requirements for Connected Home networks > applications > to the IESG to be considered as an Informational RFC. > > Done Submit Routing requirements for Building applications to the > IESG to > be considered as an Informational RFC. > > Done Submit Routing requirements for Urban networks applications to > the > IESG to be considered as an Informational RFC. > > July 2009 Submit Routing metrics for LLNs document to the IESG to be > considered as a Proposed Standard. > > Feb 2009 Submit Protocol Survey to the IESG to be considered as an > Informational RFC. > > April 2009 Submit Security Framework to the IESG to be considered > as an > Informational RFC > > May 2009 Submit the Routing for LLNs Architecture document to the > IESG > as an Informational RFC. > > July 2009 Submit first draft of ROLL routing protocol > specification as > Proposed Standard. > > Nov 2009 Submit first draft of the MIB module of the ROLL routing > protocol specification. > > Feb 2010 Submit the ROLL routing protocol specification to the > IESG as > Proposed Standard. > > March 2010 Submit the MIB module of the ROLL routing protocol > specification to the IESG as Proposed Standard. > > April 2010 Evaluate WG progress, recharter or close. > > _______________________________________________ > 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 = --1__=4EBBFFE5DFC7969E8f9e8a93df938690918c4EBBFFE5DFC7969E Content-transfer-encoding: quoted-printable Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Hello,

I support this rechartering too.

Best regards,

Pierre
3D""
Technopole 38TEC T1 -TI
37 quai Paul-Louis Merlin
FR - 38050 Grenoble Cedex 9
p= ierre.colle@fr.schneider-electric.com
+33 (0)4 76 57 30 19 / 34 30 19


> A modified charter has been submitted for the Routing Over Low=  
> power and
> Lossy networks working group in the Routing Area of the IETF. &nbs= p;The  
> IESG
> has not made any determination as yet.  The modified charter = is  
> provided
> below for informational purposes only.  Please send your comm= ents  
> to the
> IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009. >
> Routing Over Low power and Lossy networks (roll)
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
> Last Modified: 2009-02-04
>
> Current Status: Active Working Group
>
> Additional information is available at tools.ietf.org/wg/roll
>
> Chair(s):
>
> JP Vasseur <jpv@cisco.com>
> David Culler <culler@eecs.berkeley.edu>
>
> Routing Area Director(s):
>
> Ross Callon <rcallon@juniper.net>
> David Ward <dward@cisco.com>
>
> Routing Area Advisor:
> David Ward <dward@cisco.com>
>
> Mailing Lists:
>
> General Discussion: roll@ietf.org
> To Subscribe: http://www.ietf.org/mailman/listinfo/roll
> Archive: http://www.ietf.org/mail-archive/web/roll/
>
> Description of Working Group:
>
> 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<= br> > IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low
> power PLC (Powerline Communication) links. LLNs are transitioning<= br> > to an end-to-end IP-based solution to avoid the problem of
> non-interoperable networks interconnected by protocol translation<= br> > 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 s= ome
> 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 spe= cifically
> 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 was= te.
>
> These specific properties cause LLNs to have specific routing
> requirements.
> As shown in a protocol survey existing routing protocols (in their=  
> current
>
> form) such as OSPF, IS-IS, AODV, and OLSR, do not meet these speci= fic
> routing requirements.
>
> The Working Group is focused on routing issues for LLN.
>
> There is a wide scope of application areas for LLNs, including &nb= sp;
> industrial
>
> monitoring, building automation (HVAC, lighting, access control, &= nbsp;
> fire),
> connected homes, healthcare, environmental monitoring, urban senso= r
> networks (e.g. Smart Grid), asset tracking. The Working Group focu= ses
> 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 &nb= sp;
> documents
> will be used for protocol design.
>
> The Working Group focuses only on IPv6 routing architectural frame= work
> 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 compri= sing
> a very large number (several thousands) of nodes.
>
> The Working Group will pay particular attention to routing securit= y  
> and
> manageability (e.g., self routing configuration) issues. It will &= nbsp;
> also need
> to
> consider the transport characteristic the routing protocol message= s  
> will
> experience. Mechanisms that protect an LLN from congestion collaps= e or
> that establish some degree of fairness between concurrent   > communication
> sessions are out of scope of the Working Group. It is expected tha= t
> upper-layer applications utilizing LLNs define appropriate mechani= sms.
>
> Work Items:
>
> - Specification of routing metrics used in path calculation. This<= br> > includes
>   static and dynamic link/node attributes required for routin= g in  
> LLNs.
>
> - Provide an architectural framework for routing and path selectio= n at
>   Layer 3 (Routing for LLN Architecture) that addresses such = issues as
>   whether LLN routing require a distributed and/or centralize= d path
> computation
>   models, whether additional hierarchy is necessary and how i= t is  
> applied.
>
>   Manageability will be considered with each approach, along = with  
> various
>
>   trade-offs for maintaining low power operation, including t= he  
> presence
>
>   of non-trivial loss and networks with a very large number o= f nodes.
>
> - Produce a routing security framework for routing in LLNs.
>
> - Protocol work: In light of the application specific routing
> requirements, the
>   Working Group will either specify a new protocol and/or wil= l  
> select an
> existing
>   routing protocol (with the appropriate extensions in cooper= ation  
> with
> the
>   relevant Working Group).
>
> - Documentation of applicability statement of ROLL routing protoco= ls.
>
> Goals and Milestones:
>
> Done Submit Routing requirements for Industrial applications to th= e  
> IESG
> to be considered as an Informational RFC.
>
> Done Submit Routing requirements for Connected Home networks  = ;
> applications
> to the IESG to be considered as an Informational RFC.
>
> Done Submit Routing requirements for Building applications to the =  
> IESG to
> be considered as an Informational RFC.
>
> Done Submit Routing requirements for Urban networks applications t= o  
> the
> IESG to be considered as an Informational RFC.
>
> July 2009 Submit Routing metrics for LLNs document to the IESG to = be
> considered as a Proposed Standard.
>
> Feb 2009 Submit Protocol Survey to the IESG to be considered as an=
> Informational RFC.
>
> April 2009 Submit Security Framework to the IESG to be considered =  
> as an
> Informational RFC
>
> May 2009   Submit the Routing for LLNs Architecture document = to the  
> IESG
> as an Informational RFC.
>
> July 2009  Submit first draft of ROLL routing protocol  =
> specification as
> Proposed Standard.
>
> Nov 2009   Submit first draft of the MIB module of the ROLL r= outing
> protocol specification.
>
> Feb 2010   Submit the ROLL routing protocol specification to = the  
> IESG as
> Proposed Standard.
>
> March 2010 Submit the MIB module of the ROLL routing protocol
> specification to the IESG as Proposed Standard.
>
> April 2010 Evaluate WG progress, recharter or close.
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> ht= tps://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
Roll@ietf.org
https:/= /www.ietf.org/mailman/listinfo/roll

= --1__=4EBBFFE5DFC7969E8f9e8a93df938690918c4EBBFFE5DFC7969E-- --0__=4EBBFFE5DFC7969E8f9e8a93df938690918c4EBBFFE5DFC7969E Content-type: image/jpeg; name="C2427754.jpg" Content-Disposition: inline; filename="C2427754.jpg" Content-ID: <10__=4EBBFFE5DFC7969E8@schneider-electric.com> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEASABIAAD/4QAWRXhpZgAATU0AKgAAAAgAAAAAAAD/2wBDAAEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/ 2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQH/wAARCAAlAGQDAREAAhEBAxEB/8QAHAAAAwACAwEAAAAAAAAAAAAAAAcIBgkB BAoF/8QAJhAAAgIDAQACAgMBAAMAAAAABAUDBgIHCAEACRMVERIUFhcxkf/EABsBAAIDAQEBAAAA AAAAAAAAAAAGBAUHAwgC/8QAKhEAAgMAAQUAAgICAgMBAAAAAgMBBAUGAAcREhMUIQgiFRYjMSRB UVL/2gAMAwEAAhEDEQA/APax1l19pfjDWseztztGkK49pghrldra+NtarW8zGnN9Wo105a8P+YAh pyjD2jJYpCjwjjJPjJLCgJptzez+P04uaBnAkcKSpIQx72TEl6LCSEf0MSRGwwWMREScEQwWe9ye 53Fe1WDHIOVWLApdYinQo0EjZ0dK3KzbNeog2JV/RSzY11h9esoYGGOFjFAyLdIfcRpHb+zNfasd 6Y6J1K52w6Xotcu7/Rlo9WshzbPGNZHG0Xvyio8TcpIvxlDrjlseOf5Z2EMPn5PV/O57nX7lWkzP 1aLLzAVUZarBCGmcxARBi0ij2mY8FAEHj9yUR1lXEv5QcS5Nv4nHbfFeccatcktop4VvayEBnX3W Zga4xYTcYwfrJB6sBDkDBezHgH9p25fHnr0v1HqbtLXDvsq2cSC1u7xbKp9EG2Axs04iHGjEKSll aa4CBGRv5H+bHGC0gx54T1+AbyaAvzwn3DGHOahXyCozffx2E2ItorRaJ0ir8aVyCTgRKGy338OG PEqgfMF/b/rzmFXuthW+6Wl2mXQ1h3svHXtPvmqnGQdZlehZhamjdK7L4DRSMwdIF+4MiGSMCRWF 8vutP6Ph0dHw6OpK3b2Jr7R+7+fefmtXv9t2D0Q+lV1uCmoxmK2tKRTBQWFqtRhjEDKBIslL/wBj L1XC0LXpwGrU0ceAYbE6i0d+rm6WXlmm0+1rNkExXWJAoBIRNziIx8LD29j9IMgWJmURER7Zry3u hi8R5bwrhdnP2tLa5xcKvQDLpreihWW1aXaOi1r0yFRBN+r5rhYYmqmzZaAAtcOoTYt2W6019etj ORjjU9AptnuzYNZgPIyLW1VIc9OGXxlkCCyHTigSxCYEljD5EZx4zEQx+5SY2tqwFSrZtsEiCtXd YMQ8SZAlZMIR9pGPaYGYHzMR58eZiP307bmtXwMTY3ba3Nq4uXoa1lVeAKwyvnVHXHLQLDUsnGtJ CqGMWEnIwRgPkoUHJ/TlK6/0pX96a/SWmvVixsrCsDV3EdSK+hmrbktGZITCkbvF+MUxQUko3sTG XPKDLDKXCKT3KPGDibFfdzlaVVblJabQELEALYlLCWUlC2MDxJDMx4Of148+J/XSx237gZPc7idL l+LU0aOffferqr6gVl3BOhabUaTAqWriIE2KIl+rymQmJKBnyMUh8tunvo+HR0fDo61dfabw373N qmkU2s3yu0rbNLsLix65FtRUkKS24EKMR7NXi8A8CWo/8ijrmWDhasb5LMgPxFL/AERhKUKm8z45 /slKtXTaVWvV2sbUF8zC3+VxDlF6wRj+oA/oAMkPXxISJSQ+e/5Edop7vccyMvP2KOTyXKvWr2Gv RYQ1NKDrQGhSZChZZD/jBFiLSK9qa/x9WIlbiYvW5p7vHubk3f2m+VfsV12lu9ZvdjqyOk7HmGQH 2UKSd4HXq5cllircs9duASNtOBI4wYqwr+DhJi0KY/s/IgWSlQ5LyPD1M/F5XVXYTZahde3IqNwz LRUqwDkzKnio5GWQYRaGPBkXv4E8H4v3i7vdtuZ8W7c98cOrr5+xezqmTumuk6+mTuKo0NSvezyO jqKp2TSVmH11bSYKLLX/AJHqmxk/Ld/7c+0a77y2tV+vn3Kuptb3XGp6919QqWmfnf1IiIYL5LRG aelnY+wK8QJmxjg1ng4blMRFYKFaBEL52xrPIuZWdK6ndbi0aln4Vatautp/uJIPtBGuT8B6SwmE cMYRiAqAYHqw7ebPdr+Quvy/kef3OuduuN4WrGbiYuNlVbrvDBNyJ0Ba6oT5CvCTsttNsRatMeuu mkhIr6WzLWPQNw+5PYutKNv+PXezMuW9fKNi70Fo6xo+PDV6u1JHbXVRqcpIyNNYLfYRw/YvciMB q2rZNJleXrANd57EOnqWOfWadbU/Euf4WqFvSGsBtIQp0oexCJmFrY90D4/fhIGch/YQ6on8f5rq fyk3cDH5oOHvz29xK25y9eRXsXHKr8e4yOlbzM0mLqVbuneBXr5ZC6Nd9gq8y5SOks97z7SpXK3Z NEc73euNl8t9V631gj3CKCrDtDmv2BpuSvPlR2cgU+BS7NjrGJqBKxxMbwYNpQZmU4wgccFc3kvI a2Lv1mabGXMbbqU13xEBcxTT0FNApkZ9gk6cGMn7Mj3kZOREYhUt94+62T267pY9rmNu1v8AbzuL g8fqcoWmurQtUrtjlNG5XdJKOGIl/HxspJ8NshFkkm81rUIVjsHbfbXKW9frpuN16pb7kSdf2KuV vZWsDqihR0OvCNGOsVxgVThFikN9yDXbGjzX2GX0F8S4r3jFxKcI6NVRXdq9yLE0uKWLO0d9e81S rdMkLXWUJnTEhRERJeRC3Ho6fVsmr2Z7Cwg60nb5N3Z7ccw7G6mt3Fs8oqdzrtGjv8fdmU6ePRXY fx9DVZorEneVI3YlN4vjcZaow+1LlW21hS8PcPUHUm2OlrAg2V11reuawsjGraJo/LPO0u2awKwX lPIFhe62Qyg8gqZl4qXEHqGEkvpmbBrkrxWrVcK8uvjkezs3thqrm7UVScac2ti5U3kwQk2AnRMQ KZk/QJIDmfaSOV+gBAEqD3c7g9w+Sc9u0t7uZg0eP3353D8jt5wcuSZ6nJZcCu3ljwrOYw3/AIyG PqvIvqTrM1ororghjRk7c7Ese4PqtWbIgvWkLRs65vKXvjX7WmlUr/uP0uxawjheTV6xJh268C01 4gc2eBdgGB4cUeOux8EGFxjmf7Fvtv8ACwtxZznXLDK+lVOuVf8AJ+dtKoZKnLhgi5UwUwHqPtJQ H9YGIYS7td0L3J/46190NfiWhyDVt5XMcWzlsyv8v+Lu0KY3CpXqoWUJ0aLAcYIhSYcxy0R8lriM R1vsDrz7EdFdudQmdVWjTOsaCt2xVaXoeoVSuMa8fW02tyLSyQ3Dxh+Eg2JpWnICWd0R6Y2lbFN2 QZC8ZcvV48adre5Xm8i2Z23Z9OsF5FbNQlRpJS6kuNT/AG8SUGlgLlk+zJMmGMhAAHVZhbXc3vfw /u13Cb3G0OK8fxUckzsrh2Zm0X0XUKuCei+nqQ/0Nw2KFpNQ7TPrZKyyy9TELQivEy6l7K3Ho7hj hrnzSbizUtzvnZ23PbhfqPS8dgbFV1MTbv6L9PrWpZwkeOrWzybMCYxRMIW0sy9UuVmgyNZjIKel v387jnHMvOY6uzTuXvyLNav+VbBEX/l6VETE/Rx+5l6j4ZMgAAQyyShA433S5TxHtD2h4TxO1oZV rmPIOSzqbORlRtblfNVyeaf4uDmyJ/l6NibL2QtcBZM01kV3JKwbQvzVvTHXdHc9G0Gb3r69aQ95 Z27sDXG7uk+fXer73qzblNodieQqzrRJXgkjtOf+s/1qpG2WUuLadOAuhh/zs8WrNT2N2szXqzO7 Zzv8LftU9HXy2U7NK9XqtbAE6VCtoF6ewSyfPvKxCI9Thmz8d593MyLXOsY57m7HEp7d8m2sLlvP OFW+PbHHeTZePetjXdozSVUt1Xfj/WsVkpKLJ1UIEPnYiz8T6+z/ALMeyNd6R3Sb0/hR9Ya62n6v sYbRaIwtu+EQV19YX41iVEhIVjL1daIjoVRVGjTCSOFDZkV6vk9HPz58XLmG/VztAtiK1Kpd9GiY wT9NQ2Pe0RzCpCBBM/ioAokZYszn0nwXUXsq7v53Sw+Jcrd3BjI4/h8ilF5Viup2lzGmrV++y17A pHXBFegY42ZXcslFarWXs+BSDp9IHzWuvdXUg9i8aULsyl1asXC23+guaFZv+yot11w5HT2CvWPw GZf4V5kUEbESNkPPl5nHH/jNwyxwzCYhyee5+0W9gVt+ulL32qrKzvyK1ioyFtU71kPb9iUEPif3 Eepf/kxn99Zj3Q7WY3dPKz8/T0trFtY1/wDymPrYVoKt2le+Johnlimixcgc+wj8nRMRKnpLyUxv p/6faNU900vem9eid5dS27Whq9jr8XaryY1UkPTmeMUk5mTJjYXLGFIzxiarVg7dWo8YxYTHLzof cx8l+hwOsjQr6Wlq6W0+oQHVG6ySBZLn2VJe5tYcKOIMAhgL94iSAo8jOXcY/jDj5vK8rmHMOccv 7h6eC1D8VfI7ZNrVHVW/eobZe+7aeFSxA2UVwtV6v3GCchweQnvvfqWRV/a982hzN1BvjlWLaZ8r PYNM1kxEzrLIwgooyaRLDJKvlTRxlHsCVkRWTrFBMwNir/6xbLgui+28HWq9auZGzp4sXSk7Vemc fIykiKZX5kZXHsREEF9PlJFCvQJgI7XP42U6XI9nkPAe4PMe3Q8icVjaysB6pz3tYxjTKqEkgqow xzmVxZNqKRuaNL8dBQgVX0frajfW5arH9g0dn2bvDZoOkqRoZdS7WzR5eO/EtbotDG2RsK5SxxOi CTiqksYWdiIEUY4sT/0MECL07woGFrVK3EnN5R9rmjcHOr5gV3Gvwz5qrVot2rExDJkiSBOMRImN b6iEe3sK7zrBx+xGje71jocg5dyBXEsnhyMrRfUmLf4lHHxl7u3qkI2zNzM2u7QetTG2r12VJUEu hiYY2MR9gOvdVx7v2pdONNZV7eglj2iu4v8A/AdbsZ25ScRsrc0RvkYWrn753aXGFixJbGudkFO1 Mj7KVnZFLGc+KFbtlyipSjRu2MCmnShtwOPf4xLj0J8fc1MWNNrWOZ9YJhHbli5bMm1ZyURkG6zv TicdHlvItbtZx+jzBd/kKO1f+m0LzuUs+c6VmncqK47du3NC1F6GWXWt5lusVySsX6zzcI7COm6j rvf8/wBYd5bUXfAd3rdd83/rjUOnK/QmkoQVeB0HbrBWLnPsm4Uf1WJXZpKshg8AnmZTfnZ+zwQS Cxf2aNhFTUnh1llbTGypP+UqUKCqxyAqHLe1Nibb63oKZlKo9Zk58n5iJiOts7gZmHzQ/wCP2vZx +Yq1qNH/AHPD4xxaljWDUmknhmldz9Q97UyPxl0SLOph8TOwXvYkwAlj57pfEddT9RMrFzTvroLj vZHR2unW79kUJGjoVpo82Cax1he+gYpW5jQBJcx7FsnybEYKWzplpRVj9rjNavkiDM+y46peybcj T1MC3rVGaNustdZ9afm5INE1sIxXYFtvzEDLlhMu+JgEwJdm9pqNXuFYvcC5lzXtfvc6w7fLt3Gq VMbRyDirez0XQfVstsJqaq729BwCi0KqGMv/AIFhCCFTXMz+tCqPtj8vbQf753DdLZzLbW9zxd3w 9Ta3uw37q0rLWdjY2uYgPipcMQtgWJ1KYMcVOlxGBHxy8GxkznnxBDbeNcbp37D8d52PpZMHtttY 4Hl9jkR9AgggFgsYFa4gY8+vmWmx2Dzrm7295Bd5jyjV0uAadnVi3sOraVzbu2tGvpOi9ZlafxkL YgK9WtVUC6tSFpCJ+cFKwe/UbUF9o3Sbp/p/eehNT718dlbS0/QmCSOpmltRmGJ0QRp0GUiiv5fs CozFOYpBWSUkxBC4DUSjjhw28FQLtA6GzpZlHS+hXKNYlwgpZBe8CRR/RM+0wQSMz85JUMFcxAr9 z+NGYnQ5W3jHcHl/DeOcw/LZyHjGM6oOa1thbocKmtCZrUp+7BZWlZsmoxtIbSqpACu8F9SPP7zl vTelR9m3khnpyzWDZGmOgqecnUXZAfdHcVtzJWEgRmJzkhJUSc2HIf2InLNSrZKmq8qP/Tn9jwbL bi5+eNyzJ0HNt5+pXJa7KjsMh8yBBBAS5KFlHjwXlYGBgUeeuyv408LudvOLcTDf1zfxe/d3eK81 y21a2tSdq2x0pZXYkW1XVGMGq0ZXIsma1d9ayhg/SWYl40uuE7Wrbu7F6S3qVfdU7T1xXBjK4qQ6 2rC211POru7LZAamhkRMbmKtfe4VM+7WCMg2WVrirDPljOlDlr4/Y8sTo72vpTapXaiYJQLqJB6P g1zhQqVHYEG/8B2GxJTJwAlMHMX9TtZqwdnO5b3R55zBmzxzkWFRW2jXp4OfX0s2c65fvpzaZU36 q0XPGa7WuibSKxFdTyFxKovjzmGuceaKruhqtaXFwUVhpZGkLt8OAI0nkszw17NEQOu8xFwwHlNz hg9xx8yziwxyz/nL3335bYOOnBzVZiHMetJtOGNgROZcwmzEwHgYiJKYj/7EdPHa/t/R7YcPo8Nz tG1qVs+xfsDbuAlVgy0LbrhCa0RCxgCbIBMR5kRiZ/fnqoflz1oXR8Ojo+HR0fDo684f26lV4Pou pxdYotnEceMNWV8mqWHSendR2a65baS3ogxxTXG1LsrGtFSrrBD/AENPQKLSHC59JWyBhS+QvcsM m51Kh1kRuLuTgnSVKHZ1Ci6zN5dkiZXZdsBD0KJX9yUt4wzyEiM+G+PC38mWUVc5zR7kU+QM7YP4 7SZnXeJ8X4zf1v8AZamwxtrLtci1q69HMovpeGupVdFQ2/pXlSi9LkxkdMcbi+zrrzWu5E+hrpqn jzUNHfVRNatm2PZurbc7ktjRQwszrXeWm9hUJrJZHa5CrqcEY1mtFARJxjmtiyct8ktfj61zv8x3 aegGZYo4NCs1C33HXKb2S8wNzav4FqscuYKwREQ59Va4JjpafzTE7Ktco/kB3NwOU1uG6vHO2HGc i5nVdHkF/f47p2y0rFZ9+1hzxbbx7JX7iKdfNAV39HFqVVus3it2ZqUY2Hdf6Kt+wto852+u6wtm 0KjrWq7tQ2JHSd6uNEWcM27+6l8qxcVuTXKmvGK/GKnPMGK7BxMPNJ4HMcPNJ4Png1b2a+3dybCq T7qKadFTV1tI814lZ/B+JQ9diuwx8V2QYQyYn+slEz4623udw/T2+Q8G06PH9LkOZgZ3LKd6pk8w tcO0FN1v9ajOYOnU1Mu49EDl24eiLRAZfInAZQEw0htV3o/butr0GtLpChVyNfNVk5MLNHb7FTL1 abNqBwlWlNCmB5tuLSi1Nz6bZpTzo2py3AglgRMywmlmxSslfqWRAqywwrNIpN0PbXsudQYsCMjM nksUM9nSRQZB5I5k4mWJfHdh3JsHYUhmRWrds9njrJfoDp3srY0dDjFqohlhj3t02VF5tr7aBOcN lyINjzJ8GUv8dcpbZ1DXtkKWyux62vVg0wHrpnfI7jqRxUbnslZE4iC28rS6513Urq6fSHtTnJV4 284L2MYKYOlceupxfHENNgYd6gm4tgNqWXZ41DsxYosRYthDIG+C6lRFhjZMzYVm+wrZCULZ9JH3 HP8Atd245Jxiju1rNe9g7F3iqsOxsDqcatZmrvVxtCrk1ephYeZq27kusttHr8mtM3Wqaupa/KNf 5QNTQfPkijnnZGnXHNlJ0rYbNrIaiWxsFYKtbUm5rZnU3SFpd3ZyWDN64hLPK8PJe35dDcnMbebF qB7ID5+Wbl5cryrdBmRXzmupjWewWpevQfKGKOyw1xLWQRT7S20MWGQcwwfI/ti4ZwoqvCN7i9ng eTxO7oYC8fSspu52lU5VpFm26djXtuqCVy0LHM+zLm0gNW2NkosJkk/2xNJzC5f8080adY6Jq+tQ Nd7c1g22hr4JvT80Nir9YQmg3yyk+VKbBO6FuzgsmdimK9mZWNYZP5Ywf7nnro+C8ZjMfHzyzEVA qX6R3KosRKnKSshtOL4TC2RYYRSay8m0CmHD/Ygitqdv7V3gXAuLv4fn4KcPk3H7PIcVVnLmlepZ 9NqtjQZGaUVba9a01hvqs97F5DTi+ny5yBpNlpeRJtzmI/XtcT1/V2mqft2rkKVeYq0KvhWRHSll SXKlGOWGcomP6M2H3waPLAPCLDKX3HyXH3K4PPld7HKqpaqWei8mVhIgKhaquCABf/sY+ZR+o/r4 jz/3092OKFU5L2/diUatLj3Fczk2edavK66qSb9PKr5qK1aJiSVE1Gj4XEwqBiS8e0TKu5A0vYdQ tLQHeNHV1PsKfO1523ptZYqy5b76mbXYp4sYOvI/x3/wqVeXGXOtt0GC+pTiZV+sEmqPYJvIWDnt om4bOcpdqfv99gGpYenJ2SYBs8f+V7SEwUg+IFEx8kyS/E9L3bHil3jFjQVr8Ro1ts50p0+f172f atcyKzrMuV3W/X12voSWC00aa4TmmuaWex1aRPq7/jL1sXR8Ojo+HR0fDo6498898/j3zz3z3/35 75/Pn/z34dHXPw6Oj4dHR8Ojo+HR0fDo6Ph0dHw6Oj4dHR8Ojr//2Q== --0__=4EBBFFE5DFC7969E8f9e8a93df938690918c4EBBFFE5DFC7969E-- From chris.dearlove@baesystems.com Wed Mar 11 10:37:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6054D3A6925 for ; Wed, 11 Mar 2009 10:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.699 X-Spam-Level: X-Spam-Status: No, score=-6.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QK3D6OTWcBN for ; Wed, 11 Mar 2009 10:37:24 -0700 (PDT) Received: from smtp1.bae.co.uk (smtp1.bae.co.uk [20.133.0.11]) by core3.amsl.com (Postfix) with ESMTP id 611783A69F1 for ; Wed, 11 Mar 2009 10:37:24 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n2BHbxh2023738 for ; Wed, 11 Mar 2009 17:37:59 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n2BHbxsj017740 for ; Wed, 11 Mar 2009 17:37:59 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 11 Mar 2009 17:37:58 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 11 Mar 2009 17:37:58 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 11 Mar 2009 17:37:53 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] WG Review: Recharter of Routing Over Low power and Lossynetworks (roll) thread-index: AcmhekC2sWrkraNUTTKGRy7EdgfPmAA87D7g References: <20090304153927.4A1C43A6CD4@core3.amsl.com> From: "Dearlove, Christopher (UK)" To: X-OriginalArrivalTime: 11 Mar 2009 17:37:58.0404 (UTC) FILETIME=[1E3BC440:01C9A270] Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossynetworks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 17:37:28 -0000 The nature of the routing protocol to be created still is not clear to me. The comments about point to multipoint are under the nature of the networks, not under the description of the work to be done. If this were the only issue, that would be less than ideal, but tolerable. But on the other hand a whole load of effort was spent discussing unicast routing protocols, from which one could have drawn the conclusion that is what's wanted, even if the specific existing protocols aren't appropriate. The combination of the two leads to a definite lack of clarity. All I would suggest (before getting on with the work) is that in the future work section it is clarified, with just one sentence perhaps, whether the group is working on: (a) A unicast routing protocol. (b) A IP-style multicast routing protocol. (c) A source-driven point to multipoint routing protocol. (d) Another distribution option I've not listed. (e) One or more protocols doing more than one of (a) to (d). (f) Working out which of (a) to (e) is an early work item. If everyone is clear on what's to be done, then it should take no time at all to pick appropriate wording for which of these is the case, drop it in, and all will be agreed. (I also think the timescale is definitely optimistic, but if it can be done, without cutting unacceptable corners - which will itself tend to cause delays anyway - fine. If not, well, this wouldn't be the first IETF WG to overrun.) ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From jvasseur@cisco.com Wed Mar 11 12:27:59 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DB4D3A69F7 for ; Wed, 11 Mar 2009 12:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.669 X-Spam-Level: X-Spam-Status: No, score=-9.669 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5BvKd4jXsPo for ; Wed, 11 Mar 2009 12:27:57 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id AB7053A68DE for ; Wed, 11 Mar 2009 12:27:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,345,1233532800"; d="scan'208,217";a="35852506" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Mar 2009 19:28:32 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2BJSWKu024105; Wed, 11 Mar 2009 20:28:32 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2BJSWlm018435; Wed, 11 Mar 2009 19:28:32 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Mar 2009 20:28:32 +0100 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Mar 2009 20:28:31 +0100 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-179-794473079 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Mar 2009 20:28:30 +0100 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 11 Mar 2009 19:28:31.0331 (UTC) FILETIME=[8FC41B30:01C9A27F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=17499; t=1236799712; x=1237663712; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20New=20proposed=20charter=20for=20ROLL=20(to=20b e=20approved=20by=20the=20IESG) |Sender:=20; bh=RTu8eQgAxjLH0y7wWpAL6giU99j1kC07uzPHD+RajTI=; b=EJhu6YWRdb2g02zJeRom3M6JNlq6ICZ5DaSNIwAVXwOA0/vQVAS0lE6Rtt 1p+wP0z4bceq864wCh/eKYY9IWhOs43TxXZnc227JvpSEC04tD2i8TU4zApp DgFgVD2om6; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [Roll] New proposed charter for ROLL (to be approved by the IESG) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 19:27:59 -0000 --Apple-Mail-179-794473079 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear all, First of all, I would like to thank you all for all the feed-backs. We have overall an excellent consensus. Some of you have expressed some concerns, thus we did make a few changes: - Start with one protocol: - 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). - Clarifying the support of unicast and multicast Please find the new proposed charter below, to be approved by the IESG. Routing Over Low power and Lossy networks (roll) ================================================== Last Modified: 2009-02-04 Current Status: Active Working Group Additional information is available at tools.ietf.org/wg/roll Chair(s): JP Vasseur David Culler Routing Area Director(s): Ross Callon David Ward Routing Area Advisor: David Ward Mailing Lists: General Discussion: roll@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/roll Archive: http://www.ietf.org/mail-archive/web/roll/ Description of Working Group: 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. 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. Goals and Milestones: Done Submit Routing requirements for Industrial applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Connected Home networks applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Building applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Urban networks applications to the IESG to be considered as an Informational RFC. July 2009 Submit Routing metrics for LLNs document to the IESG to be considered as a Proposed Standard. Feb 2009 Submit Protocol Survey to the IESG to be considered as an Informational RFC. April 2009 Submit Security Framework to the IESG to be considered as an Informational RFC May 2009 Submit the Routing for LLNs Architecture document to the IESG as an Informational RFC. July 2009 Submit first draft of ROLL routing protocol specification as Proposed Standard. Nov 2009 Submit first draft of the MIB module of the ROLL routing protocol specification. Feb 2010 Submit the ROLL routing protocol specification to the IESG as Proposed Standard. March 2010 Submit the MIB module of the ROLL routing protocol specification to the IESG as Proposed Standard. April 2010 Evaluate WG progress, recharter or close. --Apple-Mail-179-794473079 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear = all,


First of all, I would like to thank you all for = all the feed-backs. 

We have overall an = excellent consensus.

Some of you have expressed = some concerns, thus we did make a few changes:
- Start with = one protocol:

- 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).

- Clarifying = the support of unicast and multicast

Please find = the new proposed charter below, to be approved by the = IESG.

Routing Over Low power and = Lossy networks = (roll)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
Last Modified: 2009-02-04

Current Status: Active = Working Group

Additional information is available at = tools.ietf.org/wg/roll 

Chair(s):

JP Vasseur <jpv@cisco.com> 
David Culler = <culler@eecs.berkeley.edu>&nbs= p;

Routing Area Director(s):

Ross Callon <rcallon@juniper.net> 
Davi= d Ward <dward@cisco.com> 

Routing = Area Advisor:
David Ward <dward@cisco.com> 

Mailing = Lists:

General Discussion: roll@ietf.org
To Subscribe: http://www.ietf.org/mai= lman/listinfo/roll
Archive: http://www.ietf.org/ma= il-archive/web/roll/

Description of Working Group:

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.

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.

Goals and Milestones:

Done Submit = Routing requirements for Industrial applications to the IESG
to be = considered as an Informational RFC.

Done Submit Routing = requirements for Connected Home networks applications
to the IESG to = be considered as an Informational RFC.

Done Submit Routing = requirements for Building applications to the IESG to
be considered = as an Informational RFC.

Done Submit Routing requirements for = Urban networks applications to the
IESG to be considered as an = Informational RFC.

July 2009 Submit Routing metrics for LLNs = document to the IESG to be
considered as a Proposed = Standard.

Feb 2009 Submit Protocol Survey to the IESG to be = considered as an
Informational RFC.

April 2009 Submit Security = Framework to the IESG to be considered as an
Informational = RFC

May 2009   Submit the Routing for LLNs Architecture = document to the IESG
as an Informational RFC.

July 2009 =  Submit first draft of ROLL routing protocol specification = as
Proposed Standard.

Nov 2009   Submit first draft = of the MIB module of the ROLL routing
protocol = specification.

Feb 2010   Submit the ROLL routing = protocol specification to the IESG as
Proposed Standard.

March = 2010 Submit the MIB module of the ROLL routing protocol
specification = to the IESG as Proposed Standard.

April 2010 Evaluate WG = progress, recharter or = close.
= --Apple-Mail-179-794473079-- From alexandru.petrescu@gmail.com Wed Mar 11 14:01:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AD083A6BAA for ; Wed, 11 Mar 2009 14:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibGgWcWCIJ0c for ; Wed, 11 Mar 2009 14:01:09 -0700 (PDT) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by core3.amsl.com (Postfix) with ESMTP id 9BB243A6B2A for ; Wed, 11 Mar 2009 14:01:08 -0700 (PDT) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id 7CE1B818162; Wed, 11 Mar 2009 22:01:40 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp3-g21.free.fr (Postfix) with ESMTP id 35C588181B0; Wed, 11 Mar 2009 22:01:38 +0100 (CET) Message-ID: <49B826A0.5080405@gmail.com> Date: Wed, 11 Mar 2009 22:01:20 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: JP Vasseur References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090310-0, 10/03/2009), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] New proposed charter for ROLL (to be approved by the IESG) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 21:01:10 -0000 JP Vasseur a écrit : [...] > - Typical traffic patterns are not simply unicast flows (e.g. in some > cases most if not all traffic can be point to multipoint). I don't understand this logic because pt-to-mpt can be unicast: several simple unicast requests could be sent sequentially from pt to several points. If worried of packet duplication then use IP multicast. I'd be more tempted to agree with something along these lines: "typical comm patterns (querying several sensors at once) need IP multicast delivery of the query; IP multicast delivery on links without link-layer multicast support risks being inefficient - neighbors hear packets not for them; for such links use IP point-to-_point_ links instead; this addressing architecture should be accommodated by all ROLL protocols". It hints to a tangible problem and solution. IP point-to-point link /------------------------(sensor) --------- / | Querier |--------------------------(sensor) --------- \ \------------------------(sensor) That's why I'm not sure what kind of work should be done about it. Alex From alexandru.petrescu@gmail.com Wed Mar 11 14:14:24 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F217E3A6A74 for ; Wed, 11 Mar 2009 14:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCyJlG8Nd1xR for ; Wed, 11 Mar 2009 14:14:24 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id D5BFD3A690A for ; Wed, 11 Mar 2009 14:14:22 -0700 (PDT) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id 4AF759400CE; Wed, 11 Mar 2009 22:14:54 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 216659400F4; Wed, 11 Mar 2009 22:14:52 +0100 (CET) Message-ID: <49B829BA.5050509@gmail.com> Date: Wed, 11 Mar 2009 22:14:34 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <20090304153927.4A1C43A6CD4@core3.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090310-0, 10/03/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] WG Review: Recharter of Routing Over Low power and Lossynetworks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 21:14:25 -0000 Dearlove, Christopher (UK) a écrit : > The nature of the routing protocol to be created still is not clear > to me. > > The comments about point to multipoint are under the nature of the > networks, not under the description of the work to be done. If this > were the only issue, that would be less than ideal, but tolerable. I think it is a big issue here because 802.15.4 (a silently but strongly considered link) doesn't have link-layer multicast support. Of course, adding link-layer multicast support to 802.15.4 wouldn't be done at IETF. Of course too - if it existed it could help a lot ROLL. Which turns in circles. Getting out of it could be by ack'ing the practical IP point-to-point links: they solved many similar problems in the recent past (UMTS, 802.16 CS, IPv6-over-RS232, to name a few). > But on the other hand a whole load of effort was spent discussing > unicast routing protocols, I'm not sure even about 'unicast' routing protocols... a routing protocol often qualified as 'unicast' (e.g. OSPF as opposed to M-OSPF, or M-BGP) is actually _using_ multicast delivery of messages - is OSPF unicast or multicast? Doubt doubt. > from which one could have drawn the conclusion that is what's wanted, > even if the specific existing protocols aren't appropriate. The > combination of the two leads to a definite lack of clarity. > > All I would suggest (before getting on with the work) is that in the > future work section it is clarified, with just one sentence perhaps, > whether the group is working on: > > (a) A unicast routing protocol. (b) A IP-style multicast routing > protocol. (c) A source-driven point to multipoint routing protocol. Why not saying source-routing instead of pt-to-mpt routing protocol? Or better yet - anycast? What's a routing protocol anyways... > (d) Another distribution option I've not listed. (e) One or more > protocols doing more than one of (a) to (d). (f) Working out which of > (a) to (e) is an early work item. > > If everyone is clear on what's to be done, then it should take no > time at all to pick appropriate wording for which of these is the > case, drop it in, and all will be agreed. I fully agree on this part - if everyone is clear on what's to be done it shouldn't take any time at all to pick the wording. Alex From jvasseur@cisco.com Wed Mar 11 14:47:40 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B46328C1A1 for ; Wed, 11 Mar 2009 14:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.357 X-Spam-Level: X-Spam-Status: No, score=-10.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3Aes-86JiLR for ; Wed, 11 Mar 2009 14:47:39 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 135D53A688E for ; Wed, 11 Mar 2009 14:47:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,345,1233532800"; d="scan'208";a="35858728" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Mar 2009 21:48:13 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2BLmDk0017521; Wed, 11 Mar 2009 22:48:13 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2BLmDh6012736; Wed, 11 Mar 2009 21:48:13 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Mar 2009 22:48:13 +0100 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Mar 2009 22:48:12 +0100 Message-Id: <3BEDA5DB-25CC-4DD5-ADE8-AE05CE0F9D9D@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <49B826A0.5080405@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Mar 2009 22:48:12 +0100 References: <49B826A0.5080405@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 11 Mar 2009 21:48:13.0238 (UTC) FILETIME=[13C59D60:01C9A293] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1538; t=1236808093; x=1237672093; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20New=20proposed=20charter=20for =20ROLL=20(to=20be=20approved=20by=20the=20IESG) |Sender:=20; bh=dUjbYsvkPad6BKeRyd7vwABrLDeqNLGGAsNj+ONH1MI=; b=gYHRsBSgkqkqmsRXgyFf0UAwvDqNDCjldhw3NkGN5eP+C7P2obH3s2QEFy JzDZ3UT2cG63dT+XybR0UkGqJZv11n1+aH9zyOEkA2Wv2QdYHPFFbJf0Mj8J kBz7Uuhn3k; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG Subject: Re: [Roll] New proposed charter for ROLL (to be approved by the IESG) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 21:47:40 -0000 On Mar 11, 2009, at 10:01 PM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : > [...] >> - Typical traffic patterns are not simply unicast flows (e.g. in some >> cases most if not all traffic can be point to multipoint). > > I don't understand this logic because pt-to-mpt can be unicast: =20 > several > simple unicast requests could be sent sequentially from pt to several > points. If worried of packet duplication then use IP multicast. We all agree with you. This parts relates to LLN typical =20 characteristics. Thanks. JP. > > > I'd be more tempted to agree with something along these lines: =20 > "typical comm patterns (querying several sensors at once) need IP =20 > multicast delivery of the query; IP multicast delivery on links =20 > without link-layer multicast support risks being inefficient - =20 > neighbors hear packets not for them; for such links use IP point-to-=20= > _point_ links instead; this addressing architecture should be =20 > accommodated by all ROLL protocols". It hints to a tangible problem =20= > and solution. > > IP point-to-point link > /------------------------(sensor) > --------- / > | Querier |--------------------------(sensor) > --------- \ > \------------------------(sensor) > > > That's why I'm not sure what kind of work should be done about it. > > Alex > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From culler@eecs.berkeley.edu Wed Mar 11 14:53:59 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 843D828C213 for ; Wed, 11 Mar 2009 14:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gktbqzYPYll for ; Wed, 11 Mar 2009 14:53:58 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id B968A3A6950 for ; Wed, 11 Mar 2009 14:53:58 -0700 (PDT) Received: from [128.32.39.144] (dhcp-39-144.EECS.Berkeley.EDU [128.32.39.144]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n2BLsTwA019082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Mar 2009 14:54:30 -0700 (PDT) Message-ID: <49B8330E.7050607@eecs.berkeley.edu> Date: Wed, 11 Mar 2009 14:54:22 -0700 From: "David E. Culler" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Alexandru Petrescu References: <49B826A0.5080405@gmail.com> In-Reply-To: <49B826A0.5080405@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] New proposed charter for ROLL (to be approved by the IESG) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 21:53:59 -0000 The roll of the charter is to define the problem areas that fall under the purview of a working group and to identify the items of work and the timeline that will be pursued in addressing those problems. A detailed discussion of the means, alternatives, and performance tradeoffs in the implementation of particular features does not belong in such a document. If you are interested in implementation of multicast on ieee 802.15.4 links there is ample material available in the literature on that subject. If you are interested in the compaction of multicast addresses, that is dealt in 6LoWPAN. Alexandru Petrescu wrote: > JP Vasseur a écrit : > [...] >> - Typical traffic patterns are not simply unicast flows (e.g. in some >> cases most if not all traffic can be point to multipoint). > > I don't understand this logic because pt-to-mpt can be unicast: several > simple unicast requests could be sent sequentially from pt to several > points. If worried of packet duplication then use IP multicast. > > I'd be more tempted to agree with something along these lines: > "typical comm patterns (querying several sensors at once) need IP > multicast delivery of the query; IP multicast delivery on links > without link-layer multicast support risks being inefficient - > neighbors hear packets not for them; for such links use IP > point-to-_point_ links instead; this addressing architecture should be > accommodated by all ROLL protocols". It hints to a tangible problem > and solution. > > IP point-to-point link > /------------------------(sensor) > --------- / > | Querier |--------------------------(sensor) > --------- \ > \------------------------(sensor) > > > That's why I'm not sure what kind of work should be done about it. > > Alex > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Wed Mar 11 15:05:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 150473A6BA1 for ; Wed, 11 Mar 2009 15:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4crpBCxl+ji for ; Wed, 11 Mar 2009 15:05:16 -0700 (PDT) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by core3.amsl.com (Postfix) with ESMTP id 163673A688E for ; Wed, 11 Mar 2009 15:05:14 -0700 (PDT) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id ABA7F4B016A; Wed, 11 Mar 2009 23:05:47 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp2-g21.free.fr (Postfix) with ESMTP id 6A70C4B00C2; Wed, 11 Mar 2009 23:05:44 +0100 (CET) Message-ID: <49B835A7.1080505@gmail.com> Date: Wed, 11 Mar 2009 23:05:27 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: JP Vasseur References: <49B826A0.5080405@gmail.com> <3BEDA5DB-25CC-4DD5-ADE8-AE05CE0F9D9D@cisco.com> In-Reply-To: <3BEDA5DB-25CC-4DD5-ADE8-AE05CE0F9D9D@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090310-0, 10/03/2009), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] New proposed charter for ROLL (to be approved by the IESG) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 22:05:17 -0000 JP Vasseur a écrit : > > On Mar 11, 2009, at 10:01 PM, Alexandru Petrescu wrote: > >> JP Vasseur a écrit : >> [...] >>> - Typical traffic patterns are not simply unicast flows (e.g. in some >>> cases most if not all traffic can be point to multipoint). >> >> I don't understand this logic because pt-to-mpt can be unicast: several >> simple unicast requests could be sent sequentially from pt to several >> points. If worried of packet duplication then use IP multicast. > > We all agree with you. This parts relates to LLN typical characteristics. LLN like 802.15.4 and family being pt-to-mpt means I don't understand how to put IP on it. When I doubt I use IP ptp links - it works, worked in the past. Alex > > Thanks. > > JP. > >> >> >> I'd be more tempted to agree with something along these lines: >> "typical comm patterns (querying several sensors at once) need IP >> multicast delivery of the query; IP multicast delivery on links >> without link-layer multicast support risks being inefficient - >> neighbors hear packets not for them; for such links use IP >> point-to-_point_ links instead; this addressing architecture should be >> accommodated by all ROLL protocols". It hints to a tangible problem >> and solution. >> >> IP point-to-point link >> /------------------------(sensor) >> --------- / >> | Querier |--------------------------(sensor) >> --------- \ >> \------------------------(sensor) >> >> >> That's why I'm not sure what kind of work should be done about it. >> >> Alex >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > From alexandru.petrescu@gmail.com Wed Mar 11 15:52:30 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65D2428C224 for ; Wed, 11 Mar 2009 15:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bk5TUxEgd3Fd for ; Wed, 11 Mar 2009 15:52:29 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 55F8828C221 for ; Wed, 11 Mar 2009 15:52:27 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 45751E080BE; Wed, 11 Mar 2009 23:52:59 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp6-g21.free.fr (Postfix) with ESMTP id 0BA97E08065; Wed, 11 Mar 2009 23:52:56 +0100 (CET) Message-ID: <49B840B7.3040607@gmail.com> Date: Wed, 11 Mar 2009 23:52:39 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "David E. Culler" References: <49B826A0.5080405@gmail.com> <49B8330E.7050607@eecs.berkeley.edu> In-Reply-To: <49B8330E.7050607@eecs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090310-0, 10/03/2009), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] New proposed charter for ROLL (to be approved by the IESG) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 22:52:30 -0000 Generic charter, accommodating as much work as possible, generating impetus - ok. I'd simply like it clear. Reading point-to-multipoint isn't clear to MHO: -contrasting pt-to-mpt to 'unicast' is first sign of unclearness. -saying 'traffic patterns' leads think you mean application layer, actually. > Generally speaking, LLNs have at least five distinguishing > characteristics: [...] > - Typical traffic patterns are not simply unicast flows (e.g. in some > cases most if not all traffic can be point to multipoint). If "traffic" is pt-to-mpt does that mean application-layer traffic? We wouldn't design an application-layer protocol, and couldn't care less of it being pt-to-mpt or many-to-many. So one is tempted to better say "IP pt-to-mpt" which is 'IP multicast', really. 'not simply unicast flows' - so immediately think it's 'multicast', or 'anycast'. But not pt-to-mpt. I believe 'unicast' to be when both src and dst are unicast addresses. You may think otherwise... David E. Culler a écrit : > The roll of the charter is to define the problem areas that fall > under the purview of a working group and to identify the items of > work and the timeline that will be pursued in addressing those > problems. A detailed discussion of the means, alternatives, and > performance tradeoffs in the implementation of particular features > does not belong in such a document. > > If you are interested in implementation of multicast on ieee 802.15.4 > links there is ample material available in the literature on that > subject. Where do you think I should look better than an RFC? One surely wouldn't appreciate a ROLL protocol RFC about which later people will say go better read the literature... (Currently the IPV6-over-802154 RFC says "multicast is not supported natively in IEEE 802.15.4.") > If you are interested in the compaction of multicast addresses, that > is dealt in 6LoWPAN. Same length as unicast - why should I be interested in compacting IP multicast addresses in particualr... Alex > > > Alexandru Petrescu wrote: >> JP Vasseur a écrit : [...] >>> - Typical traffic patterns are not simply unicast flows (e.g. in >>> some cases most if not all traffic can be point to multipoint). >> >> I don't understand this logic because pt-to-mpt can be unicast: >> several simple unicast requests could be sent sequentially from pt >> to several points. If worried of packet duplication then use IP >> multicast. >> >> I'd be more tempted to agree with something along these lines: >> "typical comm patterns (querying several sensors at once) need IP >> multicast delivery of the query; IP multicast delivery on links >> without link-layer multicast support risks being inefficient - >> neighbors hear packets not for them; for such links use IP >> point-to-_point_ links instead; this addressing architecture should >> be accommodated by all ROLL protocols". It hints to a tangible >> problem and solution. >> >> IP point-to-point link /------------------------(sensor) --------- >> / | Querier |--------------------------(sensor) --------- \ >> \------------------------(sensor) >> >> >> That's why I'm not sure what kind of work should be done about it. >> >> Alex _______________________________________________ Roll mailing >> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From pthubert@cisco.com Thu Mar 12 01:33:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35C413A6BAE for ; Thu, 12 Mar 2009 01:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.444 X-Spam-Level: X-Spam-Status: No, score=-8.444 tagged_above=-999 required=5 tests=[AWL=-1.845, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T66ogxV9YIpV for ; Thu, 12 Mar 2009 01:33:14 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D99EC3A6B08 for ; Thu, 12 Mar 2009 01:33:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,349,1233532800"; d="scan'208,217";a="67025951" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-5.cisco.com with ESMTP; 12 Mar 2009 08:33:51 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2C8XofZ001388 for ; Thu, 12 Mar 2009 09:33:50 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2C8XoFO012782 for ; Thu, 12 Mar 2009 08:33:50 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Mar 2009 09:33:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A2ED.44EDE7A8" Date: Thu, 12 Mar 2009 09:33:46 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC071FF149@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] New proposed charter for ROLL (to be approved by the IESG) Thread-Index: Acmif5ciZkeaRnLZTpmbOdAfM95glQAbX8aA References: From: "Pascal Thubert (pthubert)" To: "Jp Vasseur (jvasseur)" , "ROLL WG" X-OriginalArrivalTime: 12 Mar 2009 08:33:50.0659 (UTC) FILETIME=[4512F930:01C9A2ED] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=22878; t=1236846830; x=1237710830; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20New=20proposed=20charter=20for =20ROLL=20(to=20be=20approved=20by=20the=20IESG) |Sender:=20; bh=WlYibpmV0E1K1vBW9hluexFDpSJl4uTaqyQHDPlfn34=; b=DbOPPNHAnxK7IQle+MMqwFNBsoYnpaz8CVSG292ja7TaR6agwoWguR8SE9 lszFusiBXx4Uiqsdoy5vkj0QQjleJOSei2qBbS2qwcyTFT4+Ky7ZS7q/aLcV ZJo35r2cSi; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [Roll] New proposed charter for ROLL (to be approved by the IESG) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 08:33:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A2ED.44EDE7A8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear JP: =20 This clarification is exactly what I was asking for. Thanks for the extra effort. I'm all for it now. =20 Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jp Vasseur (jvasseur) Sent: mercredi 11 mars 2009 20:29 To: ROLL WG Subject: [Roll] New proposed charter for ROLL (to be approved by the IESG) =20 Dear all, =20 First of all, I would like to thank you all for all the feed-backs.=20 =20 We have overall an excellent consensus. =20 Some of you have expressed some concerns, thus we did make a few changes: - Start with one protocol: =20 - Protocol work: The Working Group will consider specific routing requirements=20 from the four application documents collectively, and specify either a new protocol=20 or extend an existing routing protocol in cooperation with the relevant Working Group.=20 If requirements from the four target application areas cannot be met with a single=20 protocol, the WG may choose to specify or extend more than one protocol (this will=20 require a recharter of the WG). =20 - Clarifying the support of unicast and multicast =20 Please find the new proposed charter below, to be approved by the IESG. =20 Routing Over Low power and Lossy networks (roll) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Last Modified: 2009-02-04 Current Status: Active Working Group Additional information is available at tools.ietf.org/wg/roll=20 Chair(s): JP Vasseur =20 David Culler =20 Routing Area Director(s): Ross Callon =20 David Ward =20 Routing Area Advisor: David Ward =20 Mailing Lists: General Discussion: roll@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/roll Archive: http://www.ietf.org/mail-archive/web/roll/ Description of Working Group: Low power and Lossy networks (LLNs) are made up of many=20 embedded devices with limited power, memory, and processing=20 resources. They are interconnected by a variety of links, such as=20 IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low=20 power PLC (Powerline Communication) links. LLNs are transitioning=20 to an end-to-end IP-based solution to avoid the problem of=20 non-interoperable networks interconnected by protocol translation=20 gateways and proxies.=20 Generally speaking, LLNs have at least five distinguishing characteristics:=20 - 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=20 most if not all traffic can be point to multipoint). - In most cases, LLNs will be employed over link layers with restricted=20 frame-sizes, thus a routing protocol for LLNs should be specifically adapted for such link layers.=20 - 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.=20 =20 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=20 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),=20 connected homes, healthcare, environmental monitoring, urban sensor=20 networks (e.g. Smart Grid), asset tracking. The Working Group focuses=20 on routing solutions for a subset of these: industrial, connected home,=20 building and urban sensor networks for which routing requirements have=20 been specified. These application-specific routing requirement documents will be used for protocol design. The Working Group focuses only on IPv6 routing architectural framework=20 for these application scenarios. The Framework will take into consideration=20 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=20 a very large number (several thousands) of nodes.=20 The Working Group will pay particular attention to routing security and=20 manageability (e.g., self routing configuration) issues. It will also need to consider the transport characteristic the routing protocol messages will=20 experience. Mechanisms that protect an LLN from congestion collapse or=20 that establish some degree of fairness between concurrent communication=20 sessions are out of scope of the Working Group. It is expected that=20 upper-layer applications utilizing LLNs define appropriate mechanisms. The solution must include unicast and multicast considerations. Work Items: - Specification of routing metrics used in path calculation. This includes=20 static and dynamic link/node attributes required for routing in LLNs. - Provide an architectural framework for routing and path selection at=20 Layer 3 (Routing for LLN Architecture) that addresses such issues as=20 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=20 from the four application documents collectively, and specify either a new protocol=20 or extend an existing routing protocol in cooperation with the relevant Working Group.=20 If requirements from the four target application areas cannot be met with a single=20 protocol, the WG may choose to specify or extend more than one protocol (this will=20 require a recharter of the WG). - Documentation of applicability statement of ROLL routing protocols. Goals and Milestones: Done Submit Routing requirements for Industrial applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Connected Home networks applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Building applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Urban networks applications to the IESG to be considered as an Informational RFC. July 2009 Submit Routing metrics for LLNs document to the IESG to be considered as a Proposed Standard. Feb 2009 Submit Protocol Survey to the IESG to be considered as an Informational RFC. April 2009 Submit Security Framework to the IESG to be considered as an Informational RFC May 2009 Submit the Routing for LLNs Architecture document to the IESG as an Informational RFC. July 2009 Submit first draft of ROLL routing protocol specification as Proposed Standard. Nov 2009 Submit first draft of the MIB module of the ROLL routing protocol specification. Feb 2010 Submit the ROLL routing protocol specification to the IESG as Proposed Standard. March 2010 Submit the MIB module of the ROLL routing protocol specification to the IESG as Proposed Standard. April 2010 Evaluate WG progress, recharter or close. ------_=_NextPart_001_01C9A2ED.44EDE7A8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear JP:

 

This clarification is exactly what I was asking for. = Thanks for the extra effort. I’m all for it now.

 

Pascal

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Jp Vasseur (jvasseur)
Sent: mercredi 11 mars 2009 20:29
To: ROLL WG
Subject: [Roll] New proposed charter for ROLL (to be approved by = the IESG)

 

Dear all,

 

First of all, I would like to thank you all for all = the feed-backs. 

 

We have overall an excellent = consensus.

 

Some of you have expressed some concerns, thus we = did make a few changes:

- Start with one protocol:

 

- 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).

 

- Clarifying the support of unicast and = multicast

 

Please find the new proposed charter below, to be = approved by the IESG.

 

Routing Over Low power and Lossy networks = (roll)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
Last Modified: 2009-02-04

Current Status: Active Working Group

Additional information is available at tools.ietf.org/wg/roll 

Chair(s):

JP Vasseur <jpv@cisco.com> 
David Culler <culler@eecs.berkeley.edu>=  

Routing Area Director(s):

Ross Callon <rcallon@juniper.net> 
= David Ward <dward@cisco.com> 

Routing Area Advisor:
David Ward <dward@cisco.com> 

Mailing Lists:

General Discussion: roll@ietf.org
To Subscribe: http://www.ietf.org/ma= ilman/listinfo/roll
Archive: http://www.ietf.org/m= ail-archive/web/roll/

Description of Working Group:

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.

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.

Goals and Milestones:

Done Submit Routing requirements for Industrial applications to the = IESG
to be considered as an Informational RFC.

Done Submit Routing requirements for Connected Home networks = applications
to the IESG to be considered as an Informational RFC.

Done Submit Routing requirements for Building applications to the IESG = to
be considered as an Informational RFC.

Done Submit Routing requirements for Urban networks applications to = the
IESG to be considered as an Informational RFC.

July 2009 Submit Routing metrics for LLNs document to the IESG to be
considered as a Proposed Standard.

Feb 2009 Submit Protocol Survey to the IESG to be considered as an
Informational RFC.

April 2009 Submit Security Framework to the IESG to be considered as = an
Informational RFC

May 2009   Submit the Routing for LLNs Architecture document = to the IESG
as an Informational RFC.

July 2009  Submit first draft of ROLL routing protocol = specification as
Proposed Standard.

Nov 2009   Submit first draft of the MIB module of the ROLL = routing
protocol specification.

Feb 2010   Submit the ROLL routing protocol specification to = the IESG as
Proposed Standard.

March 2010 Submit the MIB module of the ROLL routing protocol
specification to the IESG as Proposed Standard.

April 2010 Evaluate WG progress, recharter or close.

------_=_NextPart_001_01C9A2ED.44EDE7A8-- From ietf@thomasclausen.org Thu Mar 12 06:07:00 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D61073A692A for ; Thu, 12 Mar 2009 06:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GapWCuHKgf1d for ; Thu, 12 Mar 2009 06:06:59 -0700 (PDT) Received: from mho-01-bos.mailhop.org (mho-01-bos.mailhop.org [63.208.196.178]) by core3.amsl.com (Postfix) with ESMTP id CF7883A6894 for ; Thu, 12 Mar 2009 06:06:58 -0700 (PDT) Received: from aste-genev-bois-153-1-25-179.w83-112.abo.wanadoo.fr ([83.112.205.179] helo=[192.168.147.109]) by mho-01-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LhkdJ-0004AU-T3; Thu, 12 Mar 2009 13:07:34 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 83.112.205.179 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18cuhxrfZqpjz+9tWFFHB4g In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC071FF149@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC071FF149@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: multipart/alternative; boundary=Apple-Mail-3-858140465 Message-Id: <500A9C11-A0E1-4EC9-89FE-C4CC3351AE58@thomasclausen.org> From: Thomas Heide Clausen Date: Thu, 12 Mar 2009 14:09:38 +0100 To: ROLL WG X-Mailer: Apple Mail (2.753.1) Cc: "David E. Culler" Subject: Re: [Roll] New proposed charter for ROLL (to be approved by the IESG) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 13:07:00 -0000 --Apple-Mail-3-858140465 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed All, This updated charter moves resolving one of my issues (the "multi-=20 point" issue) into the rechartered working group as explicit parts of =20= the work items. The updated charter likewise scopes down the protocol =20= work with regards to considering the various routing requirements =20 *collectively* and aim for *one* protocol (or, in case that's not =20 possible, for rechartering). Provided that we in the rechartered working group actually approach =20 the work according to, and in the spirit of, the charter, this seems =20 acceptable. I'd like to express my thanks to the wg chairs and the various ADs =20 who've been involved in the process of producing and revising this =20 updated charter. Thomas On Mar 12, 2009, at 09:33 AM, Pascal Thubert (pthubert) wrote: > Dear JP: > > > > This clarification is exactly what I was asking for. Thanks for the =20= > extra effort. I=92m all for it now. > > > > Pascal > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =20 > Behalf Of Jp Vasseur (jvasseur) > Sent: mercredi 11 mars 2009 20:29 > To: ROLL WG > Subject: [Roll] New proposed charter for ROLL (to be approved by =20 > the IESG) > > > > Dear all, > > > > First of all, I would like to thank you all for all the feed-backs. > > > > We have overall an excellent consensus. > > > > Some of you have expressed some concerns, thus we did make a few =20 > changes: > > - Start with one protocol: > > > > - Protocol work: The Working Group will consider specific routing =20 > requirements > > from the four application documents collectively, and specify =20 > either a new protocol > > or extend an existing routing protocol in cooperation with the =20 > relevant Working Group. > > If requirements from the four target application areas cannot be =20 > met with a single > > protocol, the WG may choose to specify or extend more than one =20 > protocol (this will > > require a recharter of the WG). > > > > - Clarifying the support of unicast and multicast > > > > Please find the new proposed charter below, to be approved by the =20 > IESG. > > > > Routing Over Low power and Lossy networks (roll) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > Last Modified: 2009-02-04 > > Current Status: Active Working Group > > Additional information is available at tools.ietf.org/wg/roll > > Chair(s): > > JP Vasseur > David Culler > > Routing Area Director(s): > > Ross Callon > David Ward > > Routing Area Advisor: > David Ward > > Mailing Lists: > > General Discussion: roll@ietf.org > To Subscribe: http://www.ietf.org/mailman/listinfo/roll > Archive: http://www.ietf.org/mail-archive/web/roll/ > > Description of Working Group: > > 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 =20 > 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 =20 > waste. > > These specific properties cause LLNs to have specific routing > requirements. > > > > Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have =20= > been > > evaluated by the working group and have in their current form been =20 > 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 =20 > industrial > monitoring, building automation (HVAC, lighting, access control, =20 > 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 =20 > home, > building and urban sensor networks for which routing requirements have > been specified. These application-specific routing requirement =20 > 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 =20 > consideration > > various aspects including high reliability in the presence of time =20 > varying > loss characteristics and connectivity while permitting low-power =20 > 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 =20= > and > manageability (e.g., self routing configuration) issues. It will =20 > also need > to consider the transport characteristic the routing protocol =20 > messages will > experience. Mechanisms that protect an LLN from congestion collapse or > that establish some degree of fairness between concurrent =20 > 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. > > 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 =20 > how it is applied. > > Manageability will be considered with each approach, along with =20 > 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 =20 > requirements > > from the four application documents collectively, and specify =20 > either a new protocol > > or extend an existing routing protocol in cooperation with the =20 > relevant Working Group. > > If requirements from the four target application areas cannot be =20 > met with a single > > protocol, the WG may choose to specify or extend more than one =20 > protocol (this will > > require a recharter of the WG). > > > - Documentation of applicability statement of ROLL routing protocols. > > Goals and Milestones: > > Done Submit Routing requirements for Industrial applications to the =20= > IESG > to be considered as an Informational RFC. > > Done Submit Routing requirements for Connected Home networks =20 > applications > to the IESG to be considered as an Informational RFC. > > Done Submit Routing requirements for Building applications to the =20 > IESG to > be considered as an Informational RFC. > > Done Submit Routing requirements for Urban networks applications to =20= > the > IESG to be considered as an Informational RFC. > > July 2009 Submit Routing metrics for LLNs document to the IESG to be > considered as a Proposed Standard. > > Feb 2009 Submit Protocol Survey to the IESG to be considered as an > Informational RFC. > > April 2009 Submit Security Framework to the IESG to be considered =20 > as an > Informational RFC > > May 2009 Submit the Routing for LLNs Architecture document to the =20= > IESG > as an Informational RFC. > > July 2009 Submit first draft of ROLL routing protocol =20 > specification as > Proposed Standard. > > Nov 2009 Submit first draft of the MIB module of the ROLL routing > protocol specification. > > Feb 2010 Submit the ROLL routing protocol specification to the =20 > IESG as > Proposed Standard. > > March 2010 Submit the MIB module of the ROLL routing protocol > specification to the IESG as Proposed Standard. > > April 2010 Evaluate WG progress, recharter or close. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-3-858140465 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 All,

This updated charter moves resolving one of my = issues (the "multi-point" issue) into the rechartered working group as = explicit parts of the work items.=A0The updated charter likewise scopes = down the protocol work with regards to considering the various routing = requirements *collectively* and aim for *one* protocol (or, in case = that's not possible, for = rechartering).

Provided that we in the = rechartered working group actually approach the work according to, and = in the spirit of, the charter, this seems = acceptable.

I'd like to express my thanks to = the wg chairs and the various ADs who've been involved in the process of = producing and revising this updated = charter.

Thomas

On Mar 12, 2009, at 09:33 AM, Pascal Thubert (pthubert) = wrote:

Dear JP:

=A0

This clarification is exactly what I was asking = for. Thanks for the extra effort. I=92m all for it = now.

=A0

Pascal

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] = On Behalf Of Jp Vasseur (jvasseur)
Sent: mercredi 11 = mars 2009 20:29
To: ROLL WG
Subject: [Roll] New = proposed charter for ROLL (to be approved by the = IESG)

=A0

Dear = all,

=A0

=

First of all, I would like to thank = you all for all the feed-backs.=A0

=A0

We have overall an excellent = consensus.

=A0

Some of you have expressed some concerns, thus we = did make a few changes:

- Start with one protocol:

=

=A0

-=A0Protocol work: The Working Group will = consider specific routing requirements=A0

=

from the four application documents = collectively, and specify either a new protocol=A0

=

or extend an existing routing = protocol in cooperation with the relevant Working = Group.=A0

If = requirements from the four target application areas cannot be met with a = single=A0

protocol, the WG may choose to specify or extend = more than one protocol (this will=A0

require a recharter of the = WG).

=A0

- Clarifying the support of unicast and = multicast

=A0

=

Please find the new proposed charter = below, to be approved by the IESG.

=A0

Routing Over Low power and Lossy networks (roll)
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
Last Modified: 2009-02-04

Current Status: Active Working = Group

Additional information is available at = tools.ietf.org/wg/roll=A0

Chair(s):

JP Vasseur <jpv@cisco.com>=A0
David Culler = <culler@eecs.berkeley.edu>=A0<= br>
Routing Area Director(s):

Ross Callon <rcallon@juniper.net>=A0
= David Ward <dward@cisco.com>=A0

Routing = Area Advisor:
David Ward <dward@cisco.com>=A0

Mailing = Lists:

General Discussion:=A0roll@ietf.org
To Subscribe:=A0http://www.ietf.org/mai= lman/listinfo/roll
Archive:=A0http://www.ietf.org/ma= il-archive/web/roll/

Description of Working Group:

= Low power and Lossy networks (LLNs) are made up of many=A0
embedded = devices with limited power, memory, and processing=A0
resources. = They are interconnected by a variety of links, such as=A0
IEEE = 802.15.4, Bluetooth, Low Power WiFi, wired or other low=A0
power PLC = (Powerline Communication) links. LLNs are transitioning=A0
to an = end-to-end IP-based solution to avoid the problem of=A0
= non-interoperable networks interconnected by protocol translation=A0
= gateways and proxies.=A0

Generally speaking, LLNs have at least = five distinguishing
characteristics:=A0
- 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=A0
=A0most if not all traffic can be = point to multipoint).
- In most cases, LLNs will be employed over = link layers with restricted=A0
=A0frame-sizes, thus a routing = protocol for LLNs should be specifically
adapted=A0for such link = layers.=A0
- LLN routing protocols have to be very careful when = trading off
efficiency=A0for generality; many LLN nodes do not have = resources to waste.

These specific properties cause LLNs to = have specific routing
requirements.=A0

=A0

Existing routing protocols such as OSPF, IS-IS, = AODV, and OLSR have been=A0

evaluated by the working group and have in their = current form been found to=A0

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),=A0
connected homes, healthcare, environmental monitoring, = urban sensor=A0
networks (e.g. Smart Grid), asset tracking. The = Working Group focuses=A0
on routing solutions for a subset of these: = industrial, connected home,=A0
building and urban sensor networks = for which routing requirements have=A0
been specified. These = application-specific routing requirement documents=A0
will be used = for protocol design.

The Working Group focuses only on IPv6 = routing architectural framework=A0
for these application scenarios. = The Framework will take into=A0consideration=A0

=

various aspects including high reliability = in the presence of time varying
loss=A0characteristics and = connectivity while permitting low-power operation with
very modest = memory and CPU pressure in networks potentially comprising=A0
a very = large number (several thousands) of nodes.=A0

The Working Group = will pay particular attention to routing security and=A0
= manageability (e.g., self routing configuration) issues. It will also = need
to=A0consider the transport characteristic the routing protocol = messages will=A0
experience. Mechanisms that protect an LLN from = congestion collapse or=A0
that establish some degree of fairness = between concurrent communication=A0
sessions are out of scope of the = Working Group. It is expected that=A0
upper-layer= applications utilizing LLNs define appropriate = mechanisms.

The solution must include unicast and multicast = considerations.

Work Items:


- Specification of routing metrics used in path = calculation. This
includes=A0
=A0static and dynamic link/node = attributes required for routing in LLNs.

- Provide an = architectural framework for routing and path selection at=A0
=A0Layer = 3 (Routing for LLN Architecture) that addresses such issues as=A0
= =A0whether LLN routing require a distributed and/or centralized path
= computation=A0models, 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.

-=A0Protocol work: The Working = Group will consider specific routing requirements=A0

=

from the four application documents = collectively, and specify either a new protocol=A0

=

or extend an existing routing protocol in = cooperation with the relevant Working Group.=A0

=

If requirements from the four target = application areas cannot be met with a single=A0

=

protocol, the WG may choose to specify or = extend more than one protocol (this will=A0

=

require a recharter of the = WG).


- = Documentation of applicability statement of ROLL routing protocols.
=
Goals and Milestones:

Done Submit Routing requirements for = Industrial applications to the IESG
to be considered as an = Informational RFC.

Done Submit Routing requirements for = Connected Home networks applications
to the IESG to be considered as = an Informational RFC.

Done Submit Routing requirements for = Building applications to the IESG to
be considered as an = Informational RFC.

Done Submit Routing requirements for Urban = networks applications to the
IESG to be considered as an = Informational RFC.

July 2009 Submit Routing metrics for LLNs = document to the IESG to be
considered as a Proposed Standard.
=
Feb 2009 Submit Protocol Survey to the IESG to be considered as = an
Informational RFC.

April 2009 Submit Security Framework = to the IESG to be considered as an
Informational RFC

May = 2009 =A0=A0Submit the Routing for LLNs Architecture document to the = IESG
as an Informational RFC.

July 2009 =A0Submit first = draft of ROLL routing protocol specification as
Proposed = Standard.

Nov 2009 =A0=A0Submit first draft of the MIB module = of the ROLL routing
protocol specification.

Feb 2010 = =A0=A0Submit the ROLL routing protocol specification to the IESG as
= Proposed Standard.

March 2010 Submit the MIB module of the ROLL = routing protocol
specification to the IESG as Proposed Standard.
=
April 2010 Evaluate WG progress, recharter or close.

=
Roll mailing list
=

= --Apple-Mail-3-858140465-- From chris.dearlove@baesystems.com Thu Mar 12 06:31:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CF9D3A685C for ; Thu, 12 Mar 2009 06:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.694 X-Spam-Level: X-Spam-Status: No, score=-6.694 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztmm00Q84gFI for ; Thu, 12 Mar 2009 06:31:52 -0700 (PDT) Received: from smtp2.bae.co.uk (smtp2.bae.co.uk [20.133.0.12]) by core3.amsl.com (Postfix) with ESMTP id 7C44E3A6856 for ; Thu, 12 Mar 2009 06:31:49 -0700 (PDT) Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id n2CDWOXF001698 for ; Thu, 12 Mar 2009 13:32:24 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id n2CDWODd003258 for ; Thu, 12 Mar 2009 13:32:24 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Thu, 12 Mar 2009 13:32:24 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Thu, 12 Mar 2009 13:32:24 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 12 Mar 2009 13:32:22 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] New proposed charter for ROLL (to be approved by the IESG) Thread-Index: Acmif5b523G8DmkFSTSOjYOUT85zmwAlyUzQ References: From: "Dearlove, Christopher (UK)" To: "JP Vasseur" , "ROLL WG" X-OriginalArrivalTime: 12 Mar 2009 13:32:24.0592 (UTC) FILETIME=[FA9C3900:01C9A316] Subject: Re: [Roll] New proposed charter for ROLL (to be approved by the IESG) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 13:31:53 -0000 > Start with one protocol:=20 =20 Not something I've commented on, but sounds like a good idea.=20 > Clarifying the support of unicast and multicast =20 Looks good to me. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From emmanuel.baccelli@gmail.com Thu Mar 12 08:37:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24BD13A6B94 for ; Thu, 12 Mar 2009 08:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b16T3cXQ1oS for ; Thu, 12 Mar 2009 08:37:38 -0700 (PDT) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id D05533A69E2 for ; Thu, 12 Mar 2009 08:37:36 -0700 (PDT) Received: by fxm24 with SMTP id 24so438681fxm.37 for ; Thu, 12 Mar 2009 08:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=eqEVqX0K4R0ieOVLk4Mg06h9enxaCH14aNCFfPBezac=; b=t0lH8nmyhyavAsdNnY82oEacFQMHKW/EAtcNKAPSnBWg0g1Ecj3vwkOfAwEdoQfm6Z 3jSknFTQoba6oILjf/+Eg76ffqHNvgUPtKI8B4M5HcbZ3bRCH3g3nAOeXxbJqAn50lBL 15E13laxreByyHXPJEnLhW+vOSSYghEfl1Xrg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=olILsWjBlcG6qEWMdcZpn7otD3xvY/6mndqA1Z7Dmfq7qLiko3wZth8GTrLuBmF5tN gmPDhnaeVd1dCpuq70P6X4WgS1MW9roNbMTwvEDam7XCDItxW3shIO5Kbva8S+PeO6Ra 5e5qZ97tkOXMncJekZz5kecyJusv4mWOo2ZDo= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.103.172.7 with SMTP id z7mr34418muo.129.1236872293300; Thu, 12 Mar 2009 08:38:13 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Mar 2009 16:38:13 +0100 X-Google-Sender-Auth: 5bd1559d4290f5e9 Message-ID: From: Emmanuel Baccelli To: ROLL WG Content-Type: multipart/alternative; boundary=001636416929acbf5f0464edc504 Subject: Re: [Roll] New proposed charter for ROLL (to be approved by the IESG) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 15:37:42 -0000 --001636416929acbf5f0464edc504 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi JP and all, I believe we are stirring in the right direction. I had mainly two comments about the previous version: a) The blur around "multi-point". It is now clearer that it is a must, and that it is separate from unicast. I can live with the fact that the exact nature of the traffic patterns aimed at will be defined for starters. I encourage as much as possible the WG to define this in a separate document. I still wonder, though, whether or not there should be a separate work item for unicast on one hand and for multicast on the otehr hand (usually these are quite different protocols). I suppose that it is nevertheless not impossible to count the two different components as a single solution/work item. b) The blur around "the set(s) of requirements". It is now clearer that either (i) a unique set of requirements will be factored out as soon as possible, or (ii) if this proves impossible, rechartering will conclude the debates. As everyone, I wish for (i). In the probable case where the set of requirements differs from the union of all the requirements listed by the 4 existing requirement drafts, I ecourage the WG to also document this in a separate doc. So, in a nutshell, assuming I understood things correctly ;) this is an OK plan as far as I am concerned. I also wanted to thank JP, David and the concerned ADs for the hard work they had to put in latetly in this regard. Cheers, Emmanuel On Thu, Mar 12, 2009 at 2:32 PM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > > > Start with one protocol: > > Not something I've commented on, but sounds like a good idea. > > > Clarifying the support of unicast and multicast > > Looks good to me. > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --001636416929acbf5f0464edc504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi JP and all,

I believe we are stirring in the right di= rection. I had mainly two comments about the previous version:

a) The blur around "multi-point".=A0<= /div>

It is now clearer that it=A0is a must, and that it is s= eparate from unicast. I can live with the fact that the exact nature of the= traffic patterns aimed at will be defined for starters. I encourage as muc= h as possible the WG to define this in a separate document.=A0

I still wonder, though, =A0whether or not there should = be a separate work item for unicast on one hand and for multicast on the ot= ehr hand (usually these are quite different protocols). I suppose that it i= s nevertheless not impossible to count the two different components as a si= ngle solution/work item.


b) The blur around "the set(s) of r= equirements".=A0

It is now clearer that eithe= r (i) a unique set of requirements will be factored out as soon as possible= , or (ii) if this proves impossible, rechartering will conclude the debates= .

As everyone, I wish for (i). In the probable case where= the set of requirements differs from the union of all the requirements lis= ted by the 4 existing requirement drafts, I ecourage the WG to also documen= t this=A0in a separate doc.


So, in a nutshell, assuming I understood= things correctly ;) this is an OK plan as far as I am concerned.=A0I also = wanted to thank JP, David and the concerned ADs for the hard work they had = to put in latetly in this regard.


Cheers,
Emmanuel



On Thu, Mar 1= 2, 2009 at 2:32 PM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:

> =A0Start with one protocol:

Not something I've commented on, but sounds like a good idea.

> Clarifying the support of unicast and multicast

Looks good to me.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

--001636416929acbf5f0464edc504-- From sicco.dwars@shell.com Fri Mar 13 00:57:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CABAC3A6AA4 for ; Fri, 13 Mar 2009 00:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=3.304, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TITLE_SUBJ_DIFF=1.217, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RglTJT3lMn87 for ; Fri, 13 Mar 2009 00:57:35 -0700 (PDT) Received: from SG2EHSOBE001.bigfish.com (outbound-sin.frontbridge.com [207.46.51.80]) by core3.amsl.com (Postfix) with ESMTP id 1928F3A683D for ; Fri, 13 Mar 2009 00:57:33 -0700 (PDT) Received: from mail12-sin-R.bigfish.com (10.3.40.3) by SG2EHSOBE001.bigfish.com (10.3.40.21) with Microsoft SMTP Server id 8.1.340.0; Fri, 13 Mar 2009 07:58:10 +0000 Received: from mail12-sin (localhost.localdomain [127.0.0.1]) by mail12-sin-R.bigfish.com (Postfix) with ESMTP id 75B5D830095 for ; Fri, 13 Mar 2009 07:58:09 +0000 (UTC) X-BigFish: VPS-49(zz119bM62a3L1402Jaf6W936eQ936fK9e5k9a6kzz1202hzz1033IL5fcfj19iz2dh6bh34h61h) X-Spam-TCS-SCL: 0:0 Received: by mail12-sin (MessageSwitch) id 1236931084316458_18823; Fri, 13 Mar 2009 07:58:04 +0000 (UCT) Received: from mailgate-b1.shell.com (unknown [134.163.253.57]) by mail12-sin.bigfish.com (Postfix) with ESMTP id 704E716D804E for ; Fri, 13 Mar 2009 07:58:03 +0000 (UTC) Received: from mailgate-b2.shell.com (134.163.208.158) by houic-s-03325.americas.shell.com (134.163.102.68) with Microsoft SMTP Server id 8.1.263.0; Fri, 13 Mar 2009 02:57:34 -0500 Received: from amsdc2-s-03320.europe.shell.com (145.26.56.249) by clldc-s-02322.americas.shell.com (134.163.208.158) with Microsoft SMTP Server id 8.1.340.0; Fri, 13 Mar 2009 02:57:33 -0500 Received: from amsdc1-s-03340.europe.shell.com ([145.26.110.109]) by amsdc2-s-03320.europe.shell.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Mar 2009 08:57:27 +0100 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9A3B1.3C6DCAA5" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 13 Mar 2009 08:55:57 +0100 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: ROLL charter Thread-Index: AcmjsSTbIOmKX9d6TJCSAp2yKRbQHA== From: To: X-OriginalArrivalTime: 13 Mar 2009 07:57:27.0859 (UTC) FILETIME=[5A6FE030:01C9A3B1] X-Mailman-Approved-At: Mon, 16 Mar 2009 09:21:18 -0700 Subject: [Roll] ROLL charter X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 07:57:36 -0000 ------_=_NextPart_001_01C9A3B1.3C6DCAA5 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9A3B1.3C6DCAA5" ------_=_NextPart_002_01C9A3B1.3C6DCAA5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I support the modified charter - the technology has great potential - = and with your efforts we might eventually get one standard that serves = both industrial and consumer markets. Please progress.=20 <>=20 Sicco Dwars Shell Global Solutions International B.V.=20 Sir Winston Churchilllaan 299, 2288 DC, Rijswijk Tel: +31 70 447 2660 Email: sicco.dwars@shell.com Internet: www.shell.com/globalsolutions Shell Global Solutions International B.V. has its statutory seat in The = Hague and its registered office at Carel van Bylandtlaan 30, 2596 HR, = The Hague, the Netherlands. It is registered with the Chamber of = Commerce in the Netherlands under number 27155370. ------_=_NextPart_002_01C9A3B1.3C6DCAA5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ROLL charter

I support the modified charter - the = technology has great potential - and with your efforts we might = eventually get one standard that serves both industrial and consumer = markets. Please progress.

<<WG Review: = Recharter of Routing Over Low power and Lossy networks (roll) >> =
Sicco Dwars

Shell Global Solutions International = B.V.
Sir Winston Churchilllaan 299, 2288 = DC, Rijswijk
Tel: +31 70 447 2660
Email: sicco.dwars@shell.com
Internet: www.shell.com/globalsolutions

Shell Global Solutions = International B.V. has its statutory seat in The Hague and its = registered office at Carel van Bylandtlaan 30, 2596 HR, The Hague, the = Netherlands. It is registered with the Chamber of = Commerce in the Netherlands under = number 27155370.


------_=_NextPart_002_01C9A3B1.3C6DCAA5-- ------_=_NextPart_001_01C9A3B1.3C6DCAA5 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C99CDF.A106FE80" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: WG Review: Recharter of Routing Over Low power and Lossy networks (roll) Date: Wed, 4 Mar 2009 16:39:27 +0100 Message-ID: <20090304153927.4A1C43A6CD4@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Routing Over Low power and Lossy networks (roll) Thread-Index: Acmc36FqQe3Nr9LkQrCaGPYPHzda9A== List-Help: List-Subscribe: , List-Unsubscribe: , From: Sender: To: Cc: , Reply-To: This is a multi-part message in MIME format. ------_=_NextPart_003_01C99CDF.A106FE80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A modified charter has been submitted for the Routing Over Low power and = Lossy networks working group in the Routing Area of the IETF. The IESG=20 has not made any determination as yet. The modified charter is provided = below for informational purposes only. Please send your comments to the = IESG mailing list (iesg@ietf.org) by Wednesday, March 11, 2009.=20 Routing Over Low power and Lossy networks (roll)=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =20 Last Modified: 2009-02-04=20 Current Status: Active Working Group=20 Additional information is available at tools.ietf.org/wg/roll=20 Chair(s):=20 JP Vasseur =20 David Culler =20 Routing Area Director(s):=20 Ross Callon =20 David Ward =20 Routing Area Advisor:=20 David Ward =20 Mailing Lists:=20 General Discussion: roll@ietf.org=20 To Subscribe: http://www.ietf.org/mailman/listinfo/roll=20 Archive: http://www.ietf.org/mail-archive/web/roll/=20 Description of Working Group:=20 Low power and Lossy networks (LLNs) are made up of many=20 embedded devices with limited power, memory, and processing=20 resources. They are interconnected by a variety of links, such as=20 IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low=20 power PLC (Powerline Communication) links. LLNs are transitioning=20 to an end-to-end IP-based solution to avoid the problem of=20 non-interoperable networks interconnected by protocol translation=20 gateways and proxies.=20 Generally speaking, LLNs have at least five distinguishing=20 characteristics:=20 - LLNs operate with a hard, very small bound on state.=20 - In most cases, LLN optimize for saving energy.=20 - Typical traffic patterns are not simply unicast flows (e.g. in some=20 cases=20 most if not all traffic can be point to multipoint).=20 - In most cases, LLNs will be employed over link layers with restricted=20 frame-sizes, thus a routing protocol for LLNs should be specifically=20 adapted=20 for such link layers.=20 - LLN routing protocols have to be very careful when trading off=20 efficiency=20 for generality; many LLN nodes do not have resources to waste.=20 These specific properties cause LLNs to have specific routing=20 requirements.=20 As shown in a protocol survey existing routing protocols (in their = current=20 =20 form) such as OSPF, IS-IS, AODV, and OLSR, do not meet these specific=20 routing requirements.=20 The Working Group is focused on routing issues for LLN.=20 There is a wide scope of application areas for LLNs, including = industrial=20 =20 monitoring, building automation (HVAC, lighting, access control, fire),=20 connected homes, healthcare, environmental monitoring, urban sensor=20 networks (e.g. Smart Grid), asset tracking. The Working Group focuses=20 on routing solutions for a subset of these: industrial, connected home,=20 building and urban sensor networks for which routing requirements have=20 been specified. These application-specific routing requirement documents = will be used for protocol design.=20 The Working Group focuses only on IPv6 routing architectural framework=20 for these application scenarios. The Framework will take into=20 consideration=20 various aspects including high reliability in the presence of time = varying=20 loss=20 characteristics and connectivity while permitting low-power operation = with=20 =20 very modest memory and CPU pressure in networks potentially comprising=20 a very large number (several thousands) of nodes.=20 The Working Group will pay particular attention to routing security and=20 manageability (e.g., self routing configuration) issues. It will also = need=20 to=20 consider the transport characteristic the routing protocol messages will = experience. Mechanisms that protect an LLN from congestion collapse or=20 that establish some degree of fairness between concurrent communication=20 sessions are out of scope of the Working Group. It is expected that=20 upper-layer applications utilizing LLNs define appropriate mechanisms.=20 Work Items:=20 - Specification of routing metrics used in path calculation. This=20 includes=20 static and dynamic link/node attributes required for routing in LLNs.=20 - Provide an architectural framework for routing and path selection at=20 Layer 3 (Routing for LLN Architecture) that addresses such issues as=20 whether LLN routing require a distributed and/or centralized path=20 computation=20 models, whether additional hierarchy is necessary and how it is = applied.=20 =20 Manageability will be considered with each approach, along with = various=20 trade-offs for maintaining low power operation, including the presence = of non-trivial loss and networks with a very large number of nodes.=20 - Produce a routing security framework for routing in LLNs.=20 - Protocol work: In light of the application specific routing=20 requirements, the=20 Working Group will either specify a new protocol and/or will select an = existing=20 routing protocol (with the appropriate extensions in cooperation with=20 the=20 relevant Working Group).=20 - Documentation of applicability statement of ROLL routing protocols.=20 Goals and Milestones:=20 Done Submit Routing requirements for Industrial applications to the IESG = to be considered as an Informational RFC.=20 Done Submit Routing requirements for Connected Home networks = applications=20 to the IESG to be considered as an Informational RFC.=20 Done Submit Routing requirements for Building applications to the IESG = to=20 be considered as an Informational RFC.=20 Done Submit Routing requirements for Urban networks applications to the=20 IESG to be considered as an Informational RFC.=20 July 2009 Submit Routing metrics for LLNs document to the IESG to be=20 considered as a Proposed Standard.=20 Feb 2009 Submit Protocol Survey to the IESG to be considered as an=20 Informational RFC.=20 April 2009 Submit Security Framework to the IESG to be considered as an=20 Informational RFC=20 May 2009 Submit the Routing for LLNs Architecture document to the IESG = as an Informational RFC.=20 July 2009 Submit first draft of ROLL routing protocol specification as=20 Proposed Standard.=20 Nov 2009 Submit first draft of the MIB module of the ROLL routing=20 protocol specification.=20 Feb 2010 Submit the ROLL routing protocol specification to the IESG as = Proposed Standard.=20 March 2010 Submit the MIB module of the ROLL routing protocol=20 specification to the IESG as Proposed Standard.=20 April 2010 Evaluate WG progress, recharter or close.=20 _______________________________________________=20 IETF-Announce mailing list=20 IETF-Announce@ietf.org=20 https://www.ietf.org/mailman/listinfo/ietf-announce=20 ------_=_NextPart_003_01C99CDF.A106FE80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable WG Review: Recharter of Routing Over Low power and Lossy networks = (roll)

A modified charter has been submitted for the Routing = Over Low power and
Lossy networks working group in the Routing Area of = the IETF.  The IESG
has not made any determination as yet.  The = modified charter is provided
below for informational purposes only.  Please = send your comments to the
IESG mailing list (iesg@ietf.org) by Wednesday, March = 11, 2009.

Routing Over Low power and Lossy networks = (roll)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
Last Modified: 2009-02-04

Current Status: Active Working Group

Additional information is available at = tools.ietf.org/wg/roll

Chair(s):

JP Vasseur <jpv@cisco.com>
David Culler <culler@eecs.berkeley.edu>

Routing Area Director(s):

Ross Callon <rcallon@juniper.net>
David Ward <dward@cisco.com>

Routing Area Advisor:
David Ward <dward@cisco.com>

Mailing Lists:

General Discussion: roll@ietf.org
To Subscribe: http://www.ietf.org/ma= ilman/listinfo/roll
Archive: http://www.ietf.org/m= ail-archive/web/roll/

Description of Working Group:

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.
As shown in a protocol survey existing routing = protocols (in their current
 
form) such as OSPF, IS-IS, AODV, and OLSR, do not = meet 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.

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: In light of the application specific = routing
requirements, the
  Working Group will either specify a new = protocol and/or will select an
existing
  routing protocol (with the appropriate = extensions in cooperation with
the
  relevant Working Group).

- Documentation of applicability statement of ROLL = routing protocols.

Goals and Milestones:

Done Submit Routing requirements for Industrial = applications to the IESG
to be considered as an Informational RFC.

Done Submit Routing requirements for Connected Home = networks applications
to the IESG to be considered as an Informational = RFC.

Done Submit Routing requirements for Building = applications to the IESG to
be considered as an Informational RFC.

Done Submit Routing requirements for Urban networks = applications to the
IESG to be considered as an Informational RFC.

July 2009 Submit Routing metrics for LLNs document to = the IESG to be
considered as a Proposed Standard.

Feb 2009 Submit Protocol Survey to the IESG to be = considered as an
Informational RFC.

April 2009 Submit Security Framework to the IESG to be = considered as an
Informational RFC

May 2009   Submit the Routing for LLNs = Architecture document to the IESG
as an Informational RFC.

July 2009  Submit first draft of ROLL routing = protocol specification as
Proposed Standard.

Nov 2009   Submit first draft of the MIB = module of the ROLL routing
protocol specification.

Feb 2010   Submit the ROLL routing protocol = specification to the IESG as
Proposed Standard.

March 2010 Submit the MIB module of the ROLL routing = protocol
specification to the IESG as Proposed = Standard.

April 2010 Evaluate WG progress, recharter or = close.

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.= ietf.org/mailman/listinfo/ietf-announce

------_=_NextPart_003_01C99CDF.A106FE80-- ------_=_NextPart_001_01C9A3B1.3C6DCAA5-- From jvasseur@cisco.com Mon Mar 16 10:40:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DD3428C16D for ; Mon, 16 Mar 2009 10:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.374 X-Spam-Level: X-Spam-Status: No, score=-8.374 tagged_above=-999 required=5 tests=[AWL=-1.775, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6D-+9YOVB1Y for ; Mon, 16 Mar 2009 10:40:26 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6639A28C149 for ; Mon, 16 Mar 2009 10:40:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,374,1233532800"; d="scan'208";a="268347233" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-6.cisco.com with ESMTP; 16 Mar 2009 17:41:08 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2GHf6Fr026963 for ; Mon, 16 Mar 2009 18:41:06 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2GHf6LP008093 for ; Mon, 16 Mar 2009 17:41:06 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Mar 2009 18:41:05 +0100 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Mar 2009 18:41:05 +0100 Message-Id: <5E6FEFF9-2624-49DE-95DF-87688C111593@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 16 Mar 2009 18:41:04 +0100 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 16 Mar 2009 17:41:05.0761 (UTC) FILETIME=[61F8ED10:01C9A65E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=586; t=1237225266; x=1238089266; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20WG=20Agenda |Sender:=20; bh=52RkcH3y49ti82hlgakf0cl4mwCVvWd+3eoGis0j1QM=; b=MQqBL9zGmvCQWTgjqVARqm5fL2VuRQNQfRKjCSHH8Nj8rw0VDrwMnDkb6a +M/BWCR+my/Cq+bkj+y4DxGoHiQMilOMkkCSKri3wFm/1YwS+oyusZy+AVGK F7Fn1kVhnn; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [Roll] WG Agenda X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2009 17:40:27 -0000 Dear WG, Good news: our new charter has been approved by the IESG during the Telechat last week and should be announced soon. Thanks to all of you for the support, comments and contribution. We are now entering in a new phase of ROLL ! With regards to the agenda of the ROLL WG meeting in SFO: we usually poll the WG for slot request before the cut-off submission date. We first wanted to hear from the IESG about the re-chartering of ROLL. This is a bit unusual, but if you want a slot and do not have an ID yet, please send us a request. Thanks. JP. From jvasseur@cisco.com Wed Mar 18 10:01:02 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EADF828C1B0 for ; Wed, 18 Mar 2009 10:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fc0i3-Rkfxri for ; Wed, 18 Mar 2009 10:01:02 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 21D1428C185 for ; Wed, 18 Mar 2009 10:01:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,385,1233532800"; d="scan'208";a="269692917" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 18 Mar 2009 17:01:46 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2IH1keH004893 for ; Wed, 18 Mar 2009 10:01:46 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2IH1kNe004081 for ; Wed, 18 Mar 2009 17:01:46 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Mar 2009 10:01:46 -0700 Received: from dhcp-171-70-235-103.cisco.com ([171.70.235.103]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Mar 2009 10:01:46 -0700 Message-Id: <11710E57-4844-441C-AF65-802C2C87D36A@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 18 Mar 2009 10:01:44 -0700 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 18 Mar 2009 17:01:46.0165 (UTC) FILETIME=[385EA650:01C9A7EB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=364; t=1237395706; x=1238259706; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Agenda=20for=20next=20week=20-=20ROLL=20WG=20Me eting |Sender:=20; bh=7kBuuyuxHMJNHP9FBxzb9CCa7S5mQR5dlfu6PZZ3BOM=; b=1cmX8mKREMQOMbRRkmT6xzuGE6e6lvLm4fIHrxXh1bmTgpMzPXo3A3WTrZ WIubjlNrhILW3AEy4C+J/WsAQ1gGOScG47PiiHqbS4ZIbxcIMBfB4uhgYkCx 6VV34JFfXL; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Roll] Agenda for next week - ROLL WG Meeting X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 17:01:03 -0000 Dear all, We published a draft agenda: http://www.ietf.org/proceedings/09mar/agenda/roll.txt As pointed out before on the mailing, as an exception since we have been rechartered just last week, some "presentations" do not have related I-D. Again let us know if you would like a slot, we still have a bit of time of the agenda. Thanks. JP. From root@core3.amsl.com Wed Mar 18 22:00:02 2009 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3656B3A67A4; Wed, 18 Mar 2009 22:00:02 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090319050002.3656B3A67A4@core3.amsl.com> Date: Wed, 18 Mar 2009 22:00:02 -0700 (PDT) Cc: roll@ietf.org, culler@eecs.berkeley.edu Subject: [Roll] WG Action: RECHARTER: Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 05:00:02 -0000 The charter of the Routing Over Low power and Lossy networks (roll) working group in the Routing Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. Routing Over Low power and Lossy networks (roll) ================================================== Last Modified: 2009-03-11 Additional information is available at tools.ietf.org/wg/roll Chair(s): JP Vasseur David Culler Routing Area Director(s): Ross Callon David Ward Routing Area Advisor: David Ward Mailing Lists: General Discussion: roll@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/roll Archive: http://www.ietf.org/mail-archive/web/roll/ Description of Working Group: 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. 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. Goals and Milestones: Done Submit Routing requirements for Industrial applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Connected Home networks applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Building applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Urban networks applications to the IESG to be considered as an Informational RFC. July 2009 Submit Routing metrics for LLNs document to the IESG to be considered as a Proposed Standard. Feb 2009 Submit Protocol Survey to the IESG to be considered as an Informational RFC. April 2009 Submit Security Framework to the IESG to be considered as an Informational RFC May 2009 Submit the Routing for LLNs Architecture document to the IESG as an Informational RFC. July 2009 Submit first draft of ROLL routing protocol specification as Proposed Standard. Nov 2009 Submit first draft of the MIB module of the ROLL routing protocol specification. Feb 2010 Submit the ROLL routing protocol specification to the IESG as Proposed Standard. March 2010 Submit the MIB module of the ROLL routing protocol specification to the IESG as Proposed Standard. April 2010 Evaluate WG progress, recharter or close. From jvasseur@cisco.com Thu Mar 19 10:32:59 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BA1D28C199 for ; Thu, 19 Mar 2009 10:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qu3am-UuTOca for ; Thu, 19 Mar 2009 10:32:57 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B5DE028C127 for ; Thu, 19 Mar 2009 10:32:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,389,1233532800"; d="scan'208,217";a="158374069" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 19 Mar 2009 17:33:42 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2JHXh6Z002219 for ; Thu, 19 Mar 2009 10:33:43 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2JHXh80005521 for ; Thu, 19 Mar 2009 17:33:43 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Mar 2009 10:33:43 -0700 Received: from dhcp-171-69-157-134.cisco.com ([171.69.157.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Mar 2009 10:33:42 -0700 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-7--668698720 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 19 Mar 2009 10:33:42 -0700 References: <20090319050002.3656B3A67A4@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 19 Mar 2009 17:33:43.0133 (UTC) FILETIME=[D96280D0:01C9A8B8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=18412; t=1237484023; x=1238348023; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Fwd=3A=20WG=20Action=3A=20RECHARTER=3A=20Routin g=20Over=20Low=20power=20and=20Lossy=20networks=20=20(roll)= 20 |Sender:=20; bh=VlPqVtITLsYgo7NQcA3AfAvGPOzlsPX/ToQ+zU79/dM=; b=GhdPNAlQiADUz+GcQnqPfP+t8aooIugq1qiQrpi9XfKuL4PEYllqyTsgAd ExG37Sh4dvzfdGRdK9TznYuyKs5KkO+LPNvZLE4ZhFl/0WW3rF+ZT0Cn8vQS Hi5pg75YyG; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Roll] Fwd: WG Action: RECHARTER: Routing Over Low power and Lossy networks (roll) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 17:32:59 -0000 --Apple-Mail-7--668698720 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Our new charter has been published: http://www.ietf.org/html.charters/roll-charter.html Thanks to all of you for the support, comments and contribution. We are now entering in a new phase of ROLL ! Special thanks to our ADs for the help and guidance. JP. Begin forwarded message: > From: IESG Secretary > Date: March 18, 2009 10:00:02 PM PDT > To: ietf-announce@ietf.org > Cc: roll@ietf.org, jpv@cisco.com, culler@eecs.berkeley.edu > Subject: WG Action: RECHARTER: Routing Over Low power and Lossy > networks (roll) > > The charter of the Routing Over Low power and Lossy networks (roll) > working group in the Routing Area of the IETF has been updated. For > additional information, please contact the Area Directors or the > working > group Chairs. > > Routing Over Low power and Lossy networks (roll) > ================================================== > > Last Modified: 2009-03-11 > > Additional information is available at tools.ietf.org/wg/roll > > Chair(s): > > JP Vasseur > David Culler > > Routing Area Director(s): > > Ross Callon > David Ward > > Routing Area Advisor: > David Ward > > Mailing Lists: > > General Discussion: roll@ietf.org > To Subscribe: http://www.ietf.org/mailman/listinfo/roll > Archive: http://www.ietf.org/mail-archive/web/roll/ > > Description of Working Group: > > 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. > > 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. > > Goals and Milestones: > > Done Submit Routing requirements for Industrial applications to the > IESG > to be considered as an Informational RFC. > Done Submit Routing requirements for Connected Home networks > applications > to the IESG to be considered as an Informational RFC. > Done Submit Routing requirements for Building applications to the > IESG to > be considered as an Informational RFC. > Done Submit Routing requirements for Urban networks applications to > the > IESG to be considered as an Informational RFC. > > July 2009 Submit Routing metrics for LLNs document to the IESG to be > considered as a Proposed Standard. > Feb 2009 Submit Protocol Survey to the IESG to be considered as an > Informational RFC. > April 2009 Submit Security Framework to the IESG to be considered as > an > Informational RFC > May 2009 Submit the Routing for LLNs Architecture document to the > IESG > as an Informational RFC. > July 2009 Submit first draft of ROLL routing protocol specification > as > Proposed Standard. > Nov 2009 Submit first draft of the MIB module of the ROLL routing > protocol specification. > Feb 2010 Submit the ROLL routing protocol specification to the > IESG as > Proposed Standard. > March 2010 Submit the MIB module of the ROLL routing protocol > specification to the IESG as Proposed Standard. > April 2010 Evaluate WG progress, recharter or close. --Apple-Mail-7--668698720 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Our new charter has been = published: http://www.ie= tf.org/html.charters/roll-charter.html

Thanks= to all of you for the support, comments and contribution. We are now = entering in a new phase of ROLL !

Special = thanks to our ADs for the help and = guidance.

JP.

Begin = forwarded message:

From: = IESG Secretary <iesg-secretary@ietf.org>
Date: March 18, 2009 10:00:02 PM = PDT
To: ietf-announce@ietf.org
Subject: WG Action: RECHARTER: Routing Over = Low power and Lossy networks  = (roll) 

The charter = of the Routing Over Low power and Lossy networks (roll)
working group = in the Routing Area of the IETF has been updated. =  For
additional information, please contact the Area Directors = or the working
group Chairs.

Routing Over Low power and Lossy = networks = (roll)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

Last Modified: 2009-03-11

Additional information = is available at tools.ietf.org/wg/roll

Chair(s):

JP = Vasseur <jpv@cisco.com> =
David Culler <culler@eecs.berkeley.edu> =

Routing Area Director(s):

Ross Callon <rcallon@juniper.net>
David = Ward <dward@cisco.com> =

Routing Area Advisor:
David Ward <dward@cisco.com>

Mailing = Lists:

General Discussion: roll@ietf.org
To Subscribe: http://www.ietf.org/mai= lman/listinfo/roll
Archive: http://www.ietf.org/ma= il-archive/web/roll/

Description of Working Group:

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.

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.

Goals and = Milestones:

Done Submit Routing requirements for Industrial = applications to the IESG
to be considered as an Informational = RFC.
Done Submit Routing requirements for Connected Home networks = applications
to the IESG to be considered as an Informational = RFC.
Done Submit Routing requirements for Building applications to = the IESG to
be considered as an Informational RFC.
Done Submit = Routing requirements for Urban networks applications to the
IESG to = be considered as an Informational RFC.

July 2009 Submit Routing = metrics for LLNs document to the IESG to be
considered as a Proposed = Standard.
Feb 2009 Submit Protocol Survey to the IESG to be = considered as an
Informational RFC.
April 2009 Submit Security = Framework to the IESG to be considered as an
Informational RFC
May = 2009   Submit the Routing for LLNs Architecture document to = the IESG
as an Informational RFC.
July 2009  Submit first = draft of ROLL routing protocol specification as
Proposed = Standard.
Nov 2009   Submit first draft of the MIB module = of the ROLL routing
protocol specification.
Feb 2010 =   Submit the ROLL routing protocol specification to the IESG = as
Proposed Standard.
March 2010 Submit the MIB module of the ROLL = routing protocol
specification to the IESG as Proposed = Standard.
April 2010 Evaluate WG progress, recharter or = close.

= --Apple-Mail-7--668698720-- From jvasseur@cisco.com Thu Mar 19 16:57:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E60723A6AF1 for ; Thu, 19 Mar 2009 16:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.25 X-Spam-Level: X-Spam-Status: No, score=-6.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwJQMFJokF41 for ; Thu, 19 Mar 2009 16:57:43 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 6B9F73A688C for ; Thu, 19 Mar 2009 16:57:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,391,1233532800"; d="scan'208";a="144080365" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 19 Mar 2009 23:58:29 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2JNwTYe003609 for ; Thu, 19 Mar 2009 16:58:29 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2JNwTnU007412 for ; Thu, 19 Mar 2009 23:58:29 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Mar 2009 16:58:29 -0700 Received: from dhcp-171-69-157-134.cisco.com ([171.69.157.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Mar 2009 16:58:29 -0700 Message-Id: <4E9BE305-661E-455F-A885-D725DA7DEE96@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: text/plain Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 19 Mar 2009 16:58:28 -0700 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 19 Mar 2009 23:58:29.0055 (UTC) FILETIME=[99AAA4F0:01C9A8EE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2; t=1237507109; x=1238371109; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20If=20you=20have=20a=20=22slot=22=20in=20SFO,=20 please=20provide=20your=20slides=20by=20tomorrow=206pm=20ET |Sender:=20; bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=; b=Fzlub6n7zCA2YChm9cd6wpXuCNGI2HPiJjrmeQvfTi4BLTHSxTRf+2loNG tICNQqSfRZO6gRKpSiViByQKR29aNMEBs5IUmvHpsqwrd02nZfCQjReHIt5O B44yE9/35IMghiBw1o2428iBj9s3PUt0FCc8iwzfvGvBIof7t1RdE=; Authentication-Results: sj-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Roll] If you have a "slot" in SFO, please provide your slides by tomorrow 6pm ET X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 23:57:44 -0000 From culler@eecs.berkeley.edu Tue Mar 24 12:13:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71E7A3A68F4 for ; Tue, 24 Mar 2009 12:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzHfGMNuQD7A for ; Tue, 24 Mar 2009 12:13:56 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id C9DE43A6899 for ; Tue, 24 Mar 2009 12:13:56 -0700 (PDT) Received: from [192.168.7.74] (69-12-164-136.sfo.archrock.com [69.12.164.136]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n2OJEhrQ002743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 24 Mar 2009 12:14:45 -0700 (PDT) Message-ID: <49C93116.20102@eecs.berkeley.edu> Date: Tue, 24 Mar 2009 12:14:30 -0700 From: "David E. Culler" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] Polling WG for adoption of Metrics Draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 19:13:57 -0000 The ROLL charter includes the following work item: * Specification of routing metrics used in path calculation. This includes static and dynamic link/node attributes required for routing in LLNs. The following draft has been submitted and discussed at the ROLL WG meeting during IETF 74: * http://tools.ietf.org/html/draft-mjkim-roll-routing-metrics-03 The consensus at the meeting was that it was ready to WG polling. I would like to poll the WG for adoption of this draft as a WG draft. Please respond to the list to establish consensus. Also, please provide feedback to the authors on the draft through the list. Thanks, David Culler From alexandru.petrescu@gmail.com Tue Mar 24 13:17:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E262628C10C for ; Tue, 24 Mar 2009 13:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSTCOjDB-LjU for ; Tue, 24 Mar 2009 13:17:14 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id DEC1528C10B for ; Tue, 24 Mar 2009 13:17:12 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 31D5DE0817D; Tue, 24 Mar 2009 21:17:59 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp6-g21.free.fr (Postfix) with ESMTP id 1B2FCE08056; Tue, 24 Mar 2009 21:17:57 +0100 (CET) Message-ID: <49C93FF3.1030701@gmail.com> Date: Tue, 24 Mar 2009 21:17:55 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "David E. Culler" References: <49C93116.20102@eecs.berkeley.edu> In-Reply-To: <49C93116.20102@eecs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090323-0, 23/03/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] Polling WG for adoption of Metrics Draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 20:17:15 -0000 IIRC, for energy metrics, I _think_ presenter mentioned that it would be very difficult to come up with a set of metrics covering all possible energy metrics. Which is understandable knowing the wide range of energy sources available to computing devices. But at the same time I think it would be valuable if we could come up with _some_ metrics, about the energy consumption. The most straighforward way of metering energy is the way one actually uses in practice. These should be documented. _If_ this document cited below has an intention to document at least a few metrics, metrics related to energy, in practice - then I'm all for it. It currently doesn't document any. Alex David E. Culler a écrit : > The ROLL charter includes the following work item: * Specification of > routing metrics used in path calculation. This includes static and > dynamic link/node attributes required for routing in LLNs. > > The following draft has been submitted and discussed at the ROLL WG > meeting during IETF 74: * > http://tools.ietf.org/html/draft-mjkim-roll-routing-metrics-03 > > The consensus at the meeting was that it was ready to WG polling. I > would like to poll the WG for adoption of this draft as a WG draft. > Please respond to the list to establish consensus. Also, please > provide feedback to the authors on the draft through the list. > > Thanks, > > David Culler _______________________________________________ Roll > mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > From m1gs4n@gmail.com Tue Mar 24 14:31:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 395DE28C122 for ; Tue, 24 Mar 2009 14:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.653 X-Spam-Level: X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaBPnhoKEq9l for ; Tue, 24 Mar 2009 14:31:17 -0700 (PDT) Received: from mail-bw0-f169.google.com (mail-bw0-f169.google.com [209.85.218.169]) by core3.amsl.com (Postfix) with ESMTP id 03F733A67FD for ; Tue, 24 Mar 2009 14:31:16 -0700 (PDT) Received: by bwz17 with SMTP id 17so2421202bwz.37 for ; Tue, 24 Mar 2009 14:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rlyb42Jv/TEwjIXkAvxF4KtvCpQ6MGEIo44OHin1mQs=; b=CM/vfPwNwhy3IMqjzXTS6LODrowPlbD/7OccRHY/PbkX3MW6sQZnszZQbxYxn1JT+R +6aGZALPAVM7LqkPQskNHuENgUPVdS+eoD6vGm76Va7ByyfwFiMXjOF4aW7t7Xxqbloz BLzAscqztYaMeapVB2Z7VCBvgHfoUaz3+f9qw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=bz7G65jLeC+eKafEnCYbLq/GRnNSr8CIzAp0US1egWKQfJXowf7KFmOfMt5sD+ovHP HqYgV6UW/PgfwwsWNgDDhYCw0u3UnF9WzseSCNhlsbFdCR53/9ZQEBBrRKMQ4BV3LrmK TrvlOrZDH7CLqbpwCOjGDdgJrPdU3iqn+CXp4= MIME-Version: 1.0 Received: by 10.204.62.68 with SMTP id w4mr3073892bkh.122.1237930326923; Tue, 24 Mar 2009 14:32:06 -0700 (PDT) In-Reply-To: <49C93116.20102@eecs.berkeley.edu> References: <49C93116.20102@eecs.berkeley.edu> Date: Tue, 24 Mar 2009 22:32:06 +0100 Message-ID: <86c3ed7b0903241432vf5307a0o506085aea3357e45@mail.gmail.com> From: =?ISO-8859-1?Q?Miguel_S=E1nchez?= To: "David E. Culler" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] Polling WG for adoption of Metrics Draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: m1gs4n@gmail.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 21:31:18 -0000 Hi, The document acknowledges the importance of remaining node energy but refuses to propose a metric: I do not get it! I think some energy related metric should be proposed in a revision of the document if we want routing to be energy aware. Of course we could end up with just tagging certain nodes as non-forwarders, but I think we can do better. However I do not have a detailed propossal at the moment. Regards, Miguel S=E1nchez Universidad Politecnica de Valencia, Spain On Tue, Mar 24, 2009 at 8:14 PM, David E. Culler wrote: > > The ROLL charter includes the following work item: > * Specification of routing metrics used in path calculation. This include= s static and dynamic link/node attributes required for routing in LLNs. > > The following draft has been submitted and discussed at the ROLL WG meeti= ng during IETF 74: > * http://tools.ietf.org/html/draft-mjkim-roll-routing-metrics-03 > > The consensus at the meeting was that it was ready to WG polling. =A0I wo= uld like to poll the WG for adoption of this draft as a WG draft. =A0Please= respond to the list to establish consensus. > Also, please provide feedback to the authors on the draft through the lis= t. > > Thanks, > > =A0David Culler > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pister@eecs.berkeley.edu Wed Mar 25 17:59:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3AA73A6832 for ; Wed, 25 Mar 2009 17:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[AWL=-0.621, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5uoxrhULo7J for ; Wed, 25 Mar 2009 17:59:42 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id B296C3A6805 for ; Wed, 25 Mar 2009 17:59:42 -0700 (PDT) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n2Q10VVa025720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Mar 2009 18:00:33 -0700 (PDT) Message-ID: <49CAD3AA.7060002@eecs.berkeley.edu> Date: Wed, 25 Mar 2009 18:00:26 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: m1gs4n@gmail.com References: <49C93116.20102@eecs.berkeley.edu> <86c3ed7b0903241432vf5307a0o506085aea3357e45@mail.gmail.com> In-Reply-To: <86c3ed7b0903241432vf5307a0o506085aea3357e45@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------000206010801040201090608" Cc: roll@ietf.org Subject: Re: [Roll] Polling WG for adoption of Metrics Draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 00:59:43 -0000 This is a multi-part message in MIME format. --------------000206010801040201090608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Miguel - I understand your frustration. There was in fact a 2 bit (and I mean that in both senses of the phrase) discrete metric in the document: {UNLIMITED, SCAVENGER, OK, LOW} I'm not super happy with that list, but it's a step up from "no info". Certainly "unlimited" is a good piece of information to know. "scavenger" doesn't help all that much unless it tells you something about how many packets per second your scavenger can support. I really don't like "OK" and "LOW". Below are some candidate metrics with more detail. I've made the assumption/recommendation that the node can summarize it's energy in terms of packets that it can forward (short packets? long packets? Usually there's an affine relationship between packet length and energy consumption), and it's power consumption in units of packets per second. total remaining packets forwardable - This would be for a primary battery powered node with a limit on total energy. average packets per second, lifetime - this would be for a primary battery powered node with a lifetime constraint, or an energy scavenger with a consistent but low power supply. peak packets per second, short term - this would be for an energy scavenger with short-term storage (ultra-cap, rechargeable battery), or similarly a low-current primary battery with short-term storage. Now of course some will say "this is routing - we know nothing of packets per second. Flows are unknowable". In that case, these metrics are close to useless. For most of the applications in the requirements draft, however, flows are well known, and long-term induration, in which case a power-aware routing or traffic engineering algorithm can make very good use of this information. ksjp Miguel Sánchez wrote: > Hi, > > The document acknowledges the importance of remaining node energy but > refuses to propose a metric: I do not get it! > > I think some energy related metric should be proposed in a revision of > the document if we want routing to be energy aware. Of course we could > end up with just tagging certain nodes as non-forwarders, but I think > we can do better. > > However I do not have a detailed propossal at the moment. > > Regards, > > Miguel Sánchez > Universidad Politecnica de Valencia, Spain > > > On Tue, Mar 24, 2009 at 8:14 PM, David E. Culler > wrote: > >> The ROLL charter includes the following work item: >> * Specification of routing metrics used in path calculation. This includes static and dynamic link/node attributes required for routing in LLNs. >> >> The following draft has been submitted and discussed at the ROLL WG meeting during IETF 74: >> * http://tools.ietf.org/html/draft-mjkim-roll-routing-metrics-03 >> >> The consensus at the meeting was that it was ready to WG polling. I would like to poll the WG for adoption of this draft as a WG draft. Please respond to the list to establish consensus. >> Also, please provide feedback to the authors on the draft through the list. >> >> Thanks, >> >> David Culler >> _______________________________________________ >> 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 > --------------000206010801040201090608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Miguel - I understand your frustration.  There was in fact a 2 bit (and I mean that in both senses of the phrase) discrete metric in the document: {UNLIMITED, SCAVENGER, OK, LOW}
I'm not super happy with that list, but it's a step up from "no info".  Certainly "unlimited" is a good piece of information to know.  "scavenger" doesn't help all that much unless it tells you something about how many packets per second your scavenger can support.  I really don't like "OK" and "LOW".
Below are some candidate metrics with more detail.  I've made the assumption/recommendation that the node can summarize it's energy in terms of packets that it can forward (short packets?  long packets?  Usually there's an affine relationship between packet length and energy consumption), and it's power consumption in units of packets per second.

total remaining packets forwardable -  This would be for a primary battery powered node with a limit on total energy.
average packets per second, lifetime - this would be for a primary battery powered node with a lifetime constraint, or an energy scavenger with a consistent but low power supply.
peak packets per second, short term - this would be for an energy scavenger with short-term storage (ultra-cap, rechargeable battery), or similarly a low-current primary battery with short-term storage.

Now of course some will say "this is routing - we know nothing of packets per second.  Flows are unknowable".  In that case, these metrics are close to useless.
For most of the applications in the requirements draft, however, flows are well known, and long-term induration, in which case a power-aware routing or traffic engineering algorithm can make very good use of this information.

ksjp

Miguel Sánchez wrote: 
Hi,

The document acknowledges the importance of remaining node energy but
refuses to propose a metric: I do not get it!

I think some energy related metric should be proposed in a revision of
the document if we want routing to be energy aware. Of course we could
end up with just tagging certain nodes as non-forwarders, but I think
we can do better.

However I do not have a detailed propossal at the moment.

Regards,

Miguel Sánchez
Universidad Politecnica de Valencia, Spain


On Tue, Mar 24, 2009 at 8:14 PM, David E. Culler
<culler@eecs.berkeley.edu> wrote:
  
The ROLL charter includes the following work item:
* Specification of routing metrics used in path calculation. This includes static and dynamic link/node attributes required for routing in LLNs.

The following draft has been submitted and discussed at the ROLL WG meeting during IETF 74:
* http://tools.ietf.org/html/draft-mjkim-roll-routing-metrics-03

The consensus at the meeting was that it was ready to WG polling.  I would like to poll the WG for adoption of this draft as a WG draft.  Please respond to the list to establish consensus.
Also, please provide feedback to the authors on the draft through the list.

Thanks,

 David Culler
_______________________________________________
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
--------------000206010801040201090608-- From pister@eecs.berkeley.edu Thu Mar 26 06:38:23 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51F513A6884 for ; Thu, 26 Mar 2009 06:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgEoTuS0nZNl for ; Thu, 26 Mar 2009 06:38:22 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id A47963A6827 for ; Thu, 26 Mar 2009 06:38:22 -0700 (PDT) Received: from [192.168.2.38] (c-24-4-144-147.hsd1.ca.comcast.net [24.4.144.147]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n2QDd5hY007509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 26 Mar 2009 06:39:11 -0700 (PDT) Message-ID: <49CB86DA.9050104@eecs.berkeley.edu> Date: Thu, 26 Mar 2009 06:44:58 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] security update? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 13:38:23 -0000 Since we weren't able to get an update on the security draft at this meeting, perhaps we could get an email summary? I'm confident that we can come up with a good routing protocol, and I'm 100% certain that the networks it serves will be attacked. We need to come up with something that is strong, but simple enough that everyone uses it by default. My strong preference would be that security is an intrinsic part of the routing protocol, and can't be "turned off". ksjp From pthubert@cisco.com Thu Mar 26 09:21:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE17C3A6B57 for ; Thu, 26 Mar 2009 09:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.225 X-Spam-Level: X-Spam-Status: No, score=-10.225 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzPcZ-rbHrmI for ; Thu, 26 Mar 2009 09:21:42 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8BC0D3A6E02 for ; Thu, 26 Mar 2009 09:21:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,426,1233532800"; d="scan'208";a="36888261" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Mar 2009 16:22:34 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2QGMYcu017631; Thu, 26 Mar 2009 17:22:34 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2QGMXBs016125; Thu, 26 Mar 2009 16:22:33 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Mar 2009 17:22:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Mar 2009 17:22:33 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0730F7B7@xmb-ams-337.emea.cisco.com> In-Reply-To: <49C93116.20102@eecs.berkeley.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Polling WG for adoption of Metrics Draft Thread-Index: AcmstM97440H4hQuRNePti9X85reXQBD5Ylw References: <49C93116.20102@eecs.berkeley.edu> From: "Pascal Thubert (pthubert)" To: "David E. Culler" , X-OriginalArrivalTime: 26 Mar 2009 16:22:33.0902 (UTC) FILETIME=[119DCCE0:01C9AE2F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1263; t=1238084554; x=1238948554; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20Polling=20WG=20for=20adoption= 20of=20Metrics=20Draft |Sender:=20; bh=g/4y3iFqj4LQdqBCpMku9gp7dEUzBWdgV7aOrx6ZG5M=; b=dq4lJUTunm9LskwNpPUAIe2SIdXkx+frLxfCbFPUXcHRm0t7YH6UfQj23G qk2/MkyuGp5q0f2f7ZQpE7CrDBWRCPvp0z/g7SJVmybxWAEwB78T80rcbsW1 erLSe+RzWD; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [Roll] Polling WG for adoption of Metrics Draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 16:21:42 -0000 Hi David, I'm all for it.=20 This work has to slightly precede the routing work that depends on it so it's fair that the WG gets control over it, and the way to get there is to make it WG doc. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of David E. Culler >Sent: mardi 24 mars 2009 12:15 >To: roll@ietf.org >Subject: [Roll] Polling WG for adoption of Metrics Draft > >The ROLL charter includes the following work item: >* Specification of routing metrics used in path calculation. This >includes static and dynamic link/node attributes required for routing in >LLNs. > >The following draft has been submitted and discussed at the ROLL WG >meeting during IETF 74: >* http://tools.ietf.org/html/draft-mjkim-roll-routing-metrics-03 > >The consensus at the meeting was that it was ready to WG polling. I >would like to poll the WG for adoption of this draft as a WG draft. >Please respond to the list to establish consensus. > >Also, please provide feedback to the authors on the draft through the list. > >Thanks, > > David Culler >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From m1gs4n@gmail.com Thu Mar 26 09:55:46 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 471EE3A693B for ; Thu, 26 Mar 2009 09:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.356 X-Spam-Level: X-Spam-Status: No, score=-1.356 tagged_above=-999 required=5 tests=[AWL=-0.297, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCWoRP8-JF-9 for ; Thu, 26 Mar 2009 09:55:45 -0700 (PDT) Received: from mail-bw0-f169.google.com (mail-bw0-f169.google.com [209.85.218.169]) by core3.amsl.com (Postfix) with ESMTP id F10513A67DD for ; Thu, 26 Mar 2009 09:55:44 -0700 (PDT) Received: by bwz17 with SMTP id 17so638037bwz.37 for ; Thu, 26 Mar 2009 09:56:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oy1r3B4XxKT+FBpNvREDyUSfKmte6bZZcNe0dCcvkd0=; b=jsqGidYFqBxhj0ZyS5sB9mM9vzbv1VPyLAh6oD3rEazZY4/0WsOdptXUowgmVF2vKG vh70ZVhqX2GtQGnFShoV1CckHcVzHGUrdJaUtiji2CHs4hpNknsaMYzH5YncJYMKBoJU gOcE7FR4WpQab7PN4XEntgaUpDsqZRQyc8Hc0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=LKL0oXhmsmM+URIzRWyq59xZB3yg0ccxs0wQdcAOdQMsvg26nTP3GkBx921t5gLZCL +BjsSjNFsPciKnn3WndqFCnquM+mF8pfETf3xanEOknSNc40DBT8JcsGJ0FpetVVOAQc XeH1LPYCyZWwDyK1/ylrDkSHw2Hsvjw7j42ZI= MIME-Version: 1.0 Received: by 10.204.57.67 with SMTP id b3mr347351bkh.128.1238086597512; Thu, 26 Mar 2009 09:56:37 -0700 (PDT) In-Reply-To: <49CAD3AA.7060002@eecs.berkeley.edu> References: <49C93116.20102@eecs.berkeley.edu> <86c3ed7b0903241432vf5307a0o506085aea3357e45@mail.gmail.com> <49CAD3AA.7060002@eecs.berkeley.edu> Date: Thu, 26 Mar 2009 17:56:37 +0100 Message-ID: <86c3ed7b0903260956y19ad47c7vb9af84ccaff5fe16@mail.gmail.com> From: =?ISO-8859-1?Q?Miguel_S=E1nchez?= To: Kris Pister Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] Polling WG for adoption of Metrics Draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: m1gs4n@gmail.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 16:55:46 -0000 Hi Kris, On Thu, Mar 26, 2009 at 2:00 AM, Kris Pister wro= te: > Miguel - I understand your frustration.=A0 There was in fact a 2 bit (and= I > mean that in both senses of the phrase) discrete metric in the document: > {UNLIMITED, SCAVENGER, OK, LOW} Let's assume that is the only thing we're going to have (not sure why we should set with that though). But for a metric to be useful we need to be able to make comparisons: I think we could agree that UNLIMITED > OK > LOW Not sure where to put SCAVENGER though. I would say it depends on the current success of the scavenging process. Even more difficult let's me decide which sub-path is best: OK --- SCAVENGER --- OK --- LOW or OK ----- LOW --- LOW or UNLIMITED ---- SCAVENGER ---- OK (different number of hops is intended). > I'm not super happy with that list, but it's a step up from "no info". > Certainly "unlimited" is a good piece of information to know.=A0 "scaveng= er" > doesn't help all that much unless it tells you something about how many > packets per second your scavenger can support.=A0 I really don't like "OK= " and > "LOW". > Below are some candidate metrics with more detail.=A0 I've made the > assumption/recommendation that the node can summarize it's energy in term= s > of packets that it can forward (short packets?=A0 long packets?=A0 Usuall= y > there's an affine relationship between packet length and energy > consumption), and it's power consumption in units of packets per second. > > total remaining packets forwardable -=A0 This would be for a primary batt= ery > powered node with a limit on total energy. > average packets per second, lifetime - this would be for a primary batter= y > powered node with a lifetime constraint, or an energy scavenger with a > consistent but low power supply. > peak packets per second, short term - this would be for an energy scaveng= er > with short-term storage (ultra-cap, rechargeable battery), or similarly a > low-current primary battery with short-term storage. > I do like these much more. For a given path, like in a chain, the expected path lifetime is the one of the weakest link. Given a numeric value of links metric routing algorithm would chose the lowest min of each alternative and, given a tie, the one with less hops. But still we'd need a numeric value for that. My proposal is for you to consider a few more bits for energy reporting (now we have 2 bits only). At any rate "unlimited" is always going to be a value (maximum) , and "forbidden" should also be another (minimum or zero) preventing any forwarding at all. Whether energy comes from a battery, solar panel or other source only matters when you take into account that some energy sources are "renewable" (ie. a low energy value today can increase after sunrise). However, battery operated equipment can also get the energy source replaced and thus increasing the available energy at the node too. (The latter requiring a human operator). I say this because much emphasis seems to be put to highlight the energy scavenging process and I am not sure that detail needs to be taken care of as part of the energy metric in ROLL. > Now of course some will say "this is routing - we know nothing of packets > per second.=A0 Flows are unknowable".=A0 In that case, these metrics are = close > to useless. > For most of the applications in the requirements draft, however, flows ar= e > well known, and long-term induration, in which case a power-aware routing= or > traffic engineering algorithm can make very good use of this information. > > ksjp > Kind regards, Miguel S=E1nchez From alexandru.petrescu@gmail.com Thu Mar 26 14:10:11 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF8BB3A6907 for ; Thu, 26 Mar 2009 14:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[AWL=-0.705, BAYES_20=-0.74, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLHb9U56jlin for ; Thu, 26 Mar 2009 14:10:11 -0700 (PDT) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by core3.amsl.com (Postfix) with ESMTP id CB28F3A67F2 for ; Thu, 26 Mar 2009 14:10:09 -0700 (PDT) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id E80D98180A4; Thu, 26 Mar 2009 22:10:58 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp3-g21.free.fr (Postfix) with ESMTP id 8147381809A; Thu, 26 Mar 2009 22:10:55 +0100 (CET) Message-ID: <49CBEF58.5090204@gmail.com> Date: Thu, 26 Mar 2009 22:10:48 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Kris Pister References: <49C93116.20102@eecs.berkeley.edu> <86c3ed7b0903241432vf5307a0o506085aea3357e45@mail.gmail.com> <49CAD3AA.7060002@eecs.berkeley.edu> In-Reply-To: <49CAD3AA.7060002@eecs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090325-0, 25/03/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] Polling WG for adoption of Metrics Draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 21:10:11 -0000 Kris Pister a écrit : [...] > Below are some candidate metrics with more detail. I've made the > assumption/recommendation that the node can summarize it's energy in > terms of packets that it can forward (short packets? long packets? > Usually there's an affine relationship between packet length and > energy consumption), and it's power consumption in units of packets > per second. Energy akin to MTU? For a particular link, energy representation for a link as MTU. This computer's interface needs x Watts to send a typical 1280byte IPv6 packet and y Watts to receive such. (Watt and not Joule for this case). These x and y figures are usually the same for all interfaces attached to that link, independent of computer - a server would spend same amount of energy to send that packet on that link, as a micro-controller on a PDA. Which would give to represent energy in the RA, as MTU is. Alex From zach@sensinode.com Thu Mar 26 23:51:29 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BAE93A6ADE for ; Thu, 26 Mar 2009 23:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuWHlJzPuagA for ; Thu, 26 Mar 2009 23:51:28 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 27C9A3A6A44 for ; Thu, 26 Mar 2009 23:51:27 -0700 (PDT) Received: from snl-zach.local (doc-24-32-29-62.truckee.ca.cebridge.net [24.32.29.62] (may be forged)) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n2R6qDhc024942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Mar 2009 08:52:16 +0200 Message-ID: <49CC779E.7050407@sensinode.com> Date: Fri, 27 Mar 2009 08:52:14 +0200 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: roll@ietf.org References: <49C93116.20102@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC0730F7B7@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0730F7B7@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] Polling WG for adoption of Metrics Draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 06:51:29 -0000 Ditto, it has my support as well. - Zach Pascal Thubert (pthubert) wrote: > Hi David, > > I'm all for it. > > This work has to slightly precede the routing work that depends on it so > it's fair that the WG gets control over it, and the way to get there is > to make it WG doc. > > Pascal > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > David E. Culler >> Sent: mardi 24 mars 2009 12:15 >> To: roll@ietf.org >> Subject: [Roll] Polling WG for adoption of Metrics Draft >> >> The ROLL charter includes the following work item: >> * Specification of routing metrics used in path calculation. This >> includes static and dynamic link/node attributes required for routing > in >> LLNs. >> >> The following draft has been submitted and discussed at the ROLL WG >> meeting during IETF 74: >> * http://tools.ietf.org/html/draft-mjkim-roll-routing-metrics-03 >> >> The consensus at the meeting was that it was ready to WG polling. I >> would like to poll the WG for adoption of this draft as a WG draft. >> Please respond to the list to establish consensus. >> >> Also, please provide feedback to the authors on the draft through the > list. >> Thanks, >> >> David Culler >> _______________________________________________ >> 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 -- http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. From zach@sensinode.com Thu Mar 26 23:51:40 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 096A23A6BA7 for ; Thu, 26 Mar 2009 23:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oc7bWKwJmamc for ; Thu, 26 Mar 2009 23:51:39 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 945A83A6A44 for ; Thu, 26 Mar 2009 23:51:39 -0700 (PDT) Received: from snl-zach.local (doc-24-32-29-62.truckee.ca.cebridge.net [24.32.29.62] (may be forged)) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n2R6qQhS024965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Mar 2009 08:52:29 +0200 Message-ID: <49CC77AC.8020702@sensinode.com> Date: Fri, 27 Mar 2009 08:52:28 +0200 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: roll@ietf.org References: <49C93116.20102@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC0730F7B7@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0730F7B7@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] Polling WG for adoption of Metrics Draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 06:51:40 -0000 Ditto, it has my support as well. - Zach Pascal Thubert (pthubert) wrote: > Hi David, > > I'm all for it. > > This work has to slightly precede the routing work that depends on it so > it's fair that the WG gets control over it, and the way to get there is > to make it WG doc. > > Pascal > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > David E. Culler >> Sent: mardi 24 mars 2009 12:15 >> To: roll@ietf.org >> Subject: [Roll] Polling WG for adoption of Metrics Draft >> >> The ROLL charter includes the following work item: >> * Specification of routing metrics used in path calculation. This >> includes static and dynamic link/node attributes required for routing > in >> LLNs. >> >> The following draft has been submitted and discussed at the ROLL WG >> meeting during IETF 74: >> * http://tools.ietf.org/html/draft-mjkim-roll-routing-metrics-03 >> >> The consensus at the meeting was that it was ready to WG polling. I >> would like to poll the WG for adoption of this draft as a WG draft. >> Please respond to the list to establish consensus. >> >> Also, please provide feedback to the authors on the draft through the > list. >> Thanks, >> >> David Culler >> _______________________________________________ >> 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 -- http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. From watteyne@eecs.berkeley.edu Fri Mar 27 00:02:19 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C33853A6BCB for ; Fri, 27 Mar 2009 00:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfsC01K4qE4e for ; Fri, 27 Mar 2009 00:02:19 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 06C1E3A6B51 for ; Fri, 27 Mar 2009 00:02:19 -0700 (PDT) Received: from [192.168.1.101] (uva-123-75.ResHall.Berkeley.EDU [169.229.123.75]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n2R73BPY021181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 27 Mar 2009 00:03:12 -0700 (PDT) Message-ID: <49CC7A2A.6000708@eecs.berkeley.edu> Date: Fri, 27 Mar 2009 00:03:06 -0700 From: Thomas Watteyne User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: roll@ietf.org References: <49C93116.20102@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC0730F7B7@xmb-ams-337.emea.cisco.com> <49CC77AC.8020702@sensinode.com> In-Reply-To: <49CC77AC.8020702@sensinode.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] Polling WG for adoption of Metrics Draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 07:02:19 -0000 The document has my support. Thomas Zach Shelby wrote: > Ditto, it has my support as well. > > - Zach > > Pascal Thubert (pthubert) wrote: >> Hi David, >> >> I'm all for it. >> This work has to slightly precede the routing work that depends on it so >> it's fair that the WG gets control over it, and the way to get there is >> to make it WG doc. >> >> Pascal >> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >> David E. Culler >>> Sent: mardi 24 mars 2009 12:15 >>> To: roll@ietf.org >>> Subject: [Roll] Polling WG for adoption of Metrics Draft >>> >>> The ROLL charter includes the following work item: >>> * Specification of routing metrics used in path calculation. This >>> includes static and dynamic link/node attributes required for routing >> in >>> LLNs. >>> >>> The following draft has been submitted and discussed at the ROLL WG >>> meeting during IETF 74: >>> * http://tools.ietf.org/html/draft-mjkim-roll-routing-metrics-03 >>> >>> The consensus at the meeting was that it was ready to WG polling. I >>> would like to poll the WG for adoption of this draft as a WG draft. >>> Please respond to the list to establish consensus. >>> >>> Also, please provide feedback to the authors on the draft through the >> list. >>> Thanks, >>> >>> David Culler >>> _______________________________________________ >>> 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 > From pthubert@cisco.com Sun Mar 29 23:59:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8BDE28C0F3 for ; Sun, 29 Mar 2009 23:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.063 X-Spam-Level: X-Spam-Status: No, score=-7.063 tagged_above=-999 required=5 tests=[AWL=-2.954, BAYES_05=-1.11, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5nSvDtYyRgA for ; Sun, 29 Mar 2009 23:59:55 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 28CCD28C0EB for ; Sun, 29 Mar 2009 23:59:55 -0700 (PDT) X-Files: image003.jpg : 1984 X-IronPort-AV: E=Sophos;i="4.38,445,1233532800"; d="jpg'145?scan'145,208,217,145";a="148006592" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-3.cisco.com with ESMTP; 30 Mar 2009 07:00:52 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2U70p9o021235; Mon, 30 Mar 2009 09:00:51 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2U70p5u021761; Mon, 30 Mar 2009 07:00:51 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Mar 2009 09:00:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C9B105.42C79D2B" Date: Mon, 30 Mar 2009 09:00:44 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07365047@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: your comment at ROLL about tree discovery Thread-Index: AcmxBT8ZKvAo+wKuRFGZvxDDS2czPQ== From: "Pascal Thubert (pthubert)" To: "Philip Levis" X-OriginalArrivalTime: 30 Mar 2009 07:00:51.0407 (UTC) FILETIME=[43042DF0:01C9B105] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13124; t=1238396451; x=1239260451; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20your=20comment=20at=20ROLL=20about=20tree=20dis covery |Sender:=20; bh=AMpk/1R/VB0h99Azsl9UUTBejTCdO5yrfL95QhgUo00=; b=AxpZ9FYZ94oI5e97M6UKVSCZqzpXpRzyHw4lF9w0cuadDN5FJR5hEF4WTd wBEx5z1PUajIeL9QbKbpTXzH4LdNyiIiZdRuHGiIMwBot4mkDH9c+Kqpn9uO 0DMRX9aP/Q; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: [Roll] your comment at ROLL about tree discovery X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 06:59:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B105.42C79D2B Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C9B105.42C79D2B" ------_=_NextPart_002_01C9B105.42C79D2B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Phil, =20 I'm coming back to you as promised (when I had the mike at the WG meeting) about an improvement to the td process you suggested. The discussion at the time would have consumed my slot and we agreed to take it offline. Now would be a great time to dig more. =20 Could you please elaborate what the proposed improvement is? =20 Thanks for all, =20 =20 =20 =20 =20 Pascal Thubert IP Engineering TC pthubert@cisco.com =20 Phone :+33 497 23 26 34 Mobile :+33 619 98 29 85 Cisco Systems Village d'Entreprises Green Side bat. T3=20 400, Avenue Roumanille 06410 Biot - Sophia Antipolis =20 France www.cisco.com/global/FR/ =20 This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message. =20 =20 ------_=_NextPart_002_01C9B105.42C79D2B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Phil,

 

I’m coming back to you as promised (when I = had the mike at the WG meeting) about an improvement to the td process you = suggested.

The discussion at the time would have consumed my = slot and we agreed to take it offline. Now would be a great time to dig = more.

 

Could you please elaborate what the proposed = improvement is?

 

Thanks for all,

 

 

 

 

<= /p>

= Pascal Thubert
IP Engineering TC

pthubert@cisco.com
Phone :+33 497 23 26 34
Mobile :+33 619 98 29 85

Cisco = Systems=
  Village d'Entreprises Green Side bat. T3
  400, Avenue Roumanille
  06410 Biot - Sophia Antipolis 
  France
  www.cisco.com/global/FR/

This e-mail may contain confidential and privileged = material for the sole use of the intended recipient. Any review, use, = distribution or disclosure by others is strictly prohibited. If you are not the = intended recipient (or authorized to receive for the recipient), please = contact the sender by reply e-mail and delete all copies of this = message.

 

 

------_=_NextPart_002_01C9B105.42C79D2B-- ------_=_NextPart_001_01C9B105.42C79D2B Content-Type: image/jpeg; name="image003.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.jpg Content-Location: image003.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABWAIEDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKoXmsWdjqFrYzybZrokRj 1py6tZtqzaWJR9pVN5T2rj/GH/I/eHf95f8A0OrjG7szOc7K6O9oqnqWq2mkwLPeSeWjuEB9zVtS GUMDkEZFRYu/QWimswRSzHAUZJqrpmqWmrWxuLOTfGGKk+4osF+gyy1mz1C9urS3k3S2rbZBV+uC 8Ef8jn4h/wCuh/8AQzXYf2tZjVxpfmj7UY/M2e1XKNnZEQnzRuy7RRRUGgUUUUAFFFFABRRRQAVy /hPxFea1qerW9yqBLWXEe30yR/SuoqnZaVZ6fNcTW0QR7l98hHc1SasyWndWOOtv+Sw3H/XD/wBk Wjxh/wAj94d/3h/6HXYrpVmuqNqYiH2lk2F/asTX/D1zqXinSNRiYCK0b95n2Oa0UlzL0MZQai15 md8VP+QHZ/8AXz/7Ka3tb1GbSfCUt9bhTLFApXd05wP61f1HTLTVYFhvIhIiuHAPqKkurOC8s5LS dA0Mi7WX2qOZWSL5HeTXUy9L1CbVfByX04USzWzFgvTOCKxPhZ/yLk//AF8n/wBBFdfb2kFrZpaR IFhRNgX2qPTtMtdKtjb2cYjjLFiPc0cys0PkfMm+hxvgj/kc/EP/AF0P/oZpW/5LIv8A17f+061f Dnh650rxDq99MwMd2+Y8ehJP9a2/7LtDqo1Pyh9pCbN/tVuS5n6GcYPlS8zD8T+IrzSNc0izt1Qx 3cmJN3XGQP611FU7zSrO+ube4uIg8ls26M+hq5WbasrGyTTdwoooqSgooooAKKKKACkZgqlmOABk mlqlrEMtxo95DBnzHhYLj1xQNK7scPqvxUI1CSz0LTHv/KJDPzg49Mdq6vStek1DwuNYktTDJ5bO YW4wV7fpXnnwv1zR9DS/s9VkS1uzLnfIOoAwVz9c16PPfWmpeGrq6sZFkgeGTayjg8GsYSbV2z0c VShTkqcYbW17lHwl4s/4SXR59RmtRarA5UgPu4A69BXOH4najeXk39j6BLeWkLYeQZz+lSfChYn8 J3qzY8szMHz6Y5rl9Xtz4LY6j4a8SpLDLLzbhst36juKlylypm0KFH286dtem9j1jUNdtNK0Marf kwx7FYofvZI+79a4m1+Kd9e3sZg0GQ2TyhPN5JGfwxTPiDJea18PNO1LyyuSskyqOBkda2fDHi/w wvh2xgW5hgdUWNoCOd/Q8e5qnJuVr2MoUYQo87hzO7XoavinxbYeFrFJ7oNJLL/qoV6t/wDWrk9O +LRN4iavpb2lvKcJKM9PXn+lU/ightfFekandxGWwUKGHUHDZI/Kl+I/iXQNX8P29pprx3Ny7q0f lrzGPT+mKmU3d67GtDDU3CCcW+bd9j1KORJolljYMjgFSO4p9ZXhiCa28M6dBcAiVLdQ4PUHFatb rY8mSSk0gooopkhRRRQAUUUUAFFFFAHPat4F8O6zcm5u7AeceWeNipb64rTstHsbDSl0u3h22qoU 2ZJ4PXmr1FLlV7mjqzcVFt2Rm6X4f0vRrKWysLUQwSkl03E5z9TWND8NfC0Fys4sCzK27DyEj8q6 uilyx7DVeqm2pPXcie2gktjbPEjQldpjI4x6YrnF+HPhhL5btLDa6uHCiQ7QfpXUUU3FPcUKs4X5 W1cqahpllqto1pfW6Twt/CwrG03wB4b0q7F1b2AMq/dMjFtp9QDXSUUOKbuwjVqRi4xbSCiiimZh RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/2Q== ------_=_NextPart_001_01C9B105.42C79D2B-- From david.bruemmer@johnsondiversey.com Mon Mar 30 14:01:08 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D00A28C145 for ; Mon, 30 Mar 2009 14:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGjkvcLNAfuO for ; Mon, 30 Mar 2009 14:01:07 -0700 (PDT) Received: from usstuh502.johnsondiversey.com (mail4.johnsondiversey.com [208.251.229.31]) by core3.amsl.com (Postfix) with ESMTP id 2D7E228C146 for ; Mon, 30 Mar 2009 14:01:07 -0700 (PDT) From: david.bruemmer@johnsondiversey.com To: roll@ietf.org Message-ID: Date: Mon, 30 Mar 2009 16:01:45 -0500 X-MIMETrack: Serialize by Router on USSTUH502/SVR/CMI(Release 7.0.3FP1|February 24, 2008) at 03/30/2009 16:02:05 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Roll] David Bruemmer is out of the office. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 21:01:08 -0000 I will be out of the office starting 03/30/2009 and will not return until 04/03/2009. I will check e-mails periodically during my absence and will respond as quickly as possible. From root@core3.amsl.com Mon Mar 30 18:15:01 2009 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BCC513A68A6; Mon, 30 Mar 2009 18:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090331011501.BCC513A68A6@core3.amsl.com> Date: Mon, 30 Mar 2009 18:15:01 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-urban-routing-reqs-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 01:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Urban WSNs Routing Requirements in Low Power and Lossy Networks Author(s) : M. Dohler, et al. Filename : draft-ietf-roll-urban-routing-reqs-05.txt Pages : 21 Date : 2009-03-30 The application-specific routing requirements for Urban Low Power and Lossy Networks (U-LLNs) are presented in this document. In the near future, sensing and actuating nodes will be placed outdoors in urban environments so as to improve the people's living conditions as well as to monitor compliance with increasingly strict environmental laws. These field nodes are expected to measure and report a wide gamut of data, such as required in smart metering, waste disposal, meteorological, pollution and allergy reporting applications. The majority of these nodes is expected to communicate wirelessly over a variety of links such as IEEE 802.15.4, Low power IEEE 802.11, IEEE 802.15.1 (Bluetooth), which given the limited radio range and the large number of nodes requires the use of suitable routing protocols. The design of such protocols will be mainly impacted by the limited resources of the nodes (memory, processing power, battery, etc.) and the particularities of the outdoor urban application scenarios. As such, for a wireless Routing Over Low power and Lossy networks (ROLL) solution to be useful, the protocol(s) ought to be energy-efficient, scalable, and autonomous. This documents aims to specify a set of IPv6 routing requirements reflecting these and further U-LLNs tailored characteristics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-urban-routing-reqs-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-urban-routing-reqs-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-30180706.I-D@ietf.org> --NextPart-- From tzeta.tsao@ekasystems.com Tue Mar 31 06:20:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D90B33A6D3D for ; Tue, 31 Mar 2009 06:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hcm6Vl2jzsY0 for ; Tue, 31 Mar 2009 06:20:53 -0700 (PDT) Received: from smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by core3.amsl.com (Postfix) with SMTP id E19703A6D3B for ; Tue, 31 Mar 2009 06:20:52 -0700 (PDT) Received: (qmail 83466 invoked from network); 31 Mar 2009 13:21:50 -0000 Received: from unknown (HELO ?192.168.0.237?) (tzeta.tsao@209.48.242.70 with plain) by smtp103.biz.mail.re2.yahoo.com with SMTP; 31 Mar 2009 13:21:50 -0000 X-Yahoo-SMTP: 18Fc8ICswBBVPDv5exrrk3k0phuhQJtGVVI9vm7eGXDtosryT8s- X-YMail-OSG: loS4eB0VM1kv9C2G6nhh8Jv6S_xYBRzR8wyJ01kUcElXg46Gd2VUzJ8uagn.yXC_e4Qb_xk_At5cDjtjeZG2C1wxp8wXN4ZcubkHGsGPMDd7kf9OvmqtS5qQBB0Oe9P.NSUurDNcEB8ZjAHiOEtmeb_8.6_6w54Fm3_Xr60HLCTr3c9i2oYKqhanuCPORsUIS3izJp63jpppVL97.y0fMrS5qp.t7qQKg8tXw6MKaHe87HIAy3yPy.9lzd4j83oAZ6cT4VM7RxrlgoCJpiy2LlPIboO8zw5WGid9Q9GVIr_Twy8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D218CC.6040304@ekasystems.com> Date: Tue, 31 Mar 2009 09:21:16 -0400 From: Tzeta Tsao User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: ROLL WG References: <49CB86DA.9050104@eecs.berkeley.edu> In-Reply-To: <49CB86DA.9050104@eecs.berkeley.edu> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Roll] security update? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 13:20:53 -0000 Hi Kris, All, We are indeed working on an update to the security draft and will present it once the revision is in shape. At the same time, I welcome, and I believe other authors, too, any comments and suggestions. I share the view that security should be an integral part of a ROLL protocol, but not an after-the-fact extension. In fact, even considering such diversified applications and capabilities of the LLN devices, I still hope this working group will come to the consensus that the stipulation should be such that an implementation of a ROLL protocol may choose not to conform rather than be given the choice of reduced security services. Regards, Tzeta Kris Pister wrote: > Since we weren't able to get an update on the security draft at this > meeting, perhaps we could get an email summary? > > I'm confident that we can come up with a good routing protocol, and > I'm 100% certain that the networks it serves will be attacked. We > need to come up with something that is strong, but simple enough that > everyone uses it by default. My strong preference would be that > security is an intrinsic part of the routing protocol, and can't be > "turned off". > > ksjp > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From pthubert@cisco.com Tue Mar 31 14:04:19 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C74C3A682B for ; Tue, 31 Mar 2009 14:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.012 X-Spam-Level: X-Spam-Status: No, score=-10.012 tagged_above=-999 required=5 tests=[AWL=0.587, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwBdqWWbcwK9 for ; Tue, 31 Mar 2009 14:04:18 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E08193A68F1 for ; Tue, 31 Mar 2009 14:04:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,304,1235952000"; d="scan'208";a="37145318" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 31 Mar 2009 21:05:16 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2VL5GJ1023948; Tue, 31 Mar 2009 23:05:16 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2VL5GdI018817; Tue, 31 Mar 2009 21:05:16 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Mar 2009 23:05:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 31 Mar 2009 23:05:11 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07365A53@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-thubert-roll-fundamentals-00 Thread-Index: AcmyQ9ozuPSr67B9QlmQhABk5GhFtwAAAlcg From: "Pascal Thubert (pthubert)" To: "ROLL WG" X-OriginalArrivalTime: 31 Mar 2009 21:05:16.0081 (UTC) FILETIME=[63EDAA10:01C9B244] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2004; t=1238533516; x=1239397516; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20FW=3A=20New=20Version=20Notification=20for=20dr aft-thubert-roll-fundamentals-00=20 |Sender:=20; bh=oRkzjq3reH7ywm5jqfx2LjY4OjpGNVn2w6u7mNwnl5g=; b=bBcTarEdTMPw6TrdYJ686+xI3zBe3PYORN3HCtaoVtKlL3C+MnYDcLzFu4 TG9D3FlE8+vbjWmIWJ831QdZYpAOOr1xvRLihsSltINoxBMSVKwby33i9pSV Xp6bli+B80; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Robert Assimiti , dominique.barthel@orange-ftgroup.com Subject: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 21:04:19 -0000 RGVhciBSb2xsZXJzLA0KDQpUaGlzIGlzIHRvIGFubm91bmNlIHRoYXQgd2UganVzdCBwb3N0ZWQg YSBkcmFmdCB0aGF0IGRldGFpbHMgdGhlIGFwcHJvYWNoIEkgcHJvcG9zZWQgaW4gdGhlIGJyb2Fk IGxpbmVzIGF0IHRoZSBST0xMIFdHIG1lZXRpbmcgaW4gU0ZPIGxhc3Qgd2VlazoNCg0KaHR0cDov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdGh1YmVydC1yb2xsLWZ1bmRhbWVu dGFscy0wMC50eHQgDQoNClRoZSBhdXRob3JzIGV4cGVjdCB0byBwcm92aWRlIGEgcmVmaW5lZCBy ZWZyZXNoZXIgc29tZXRpbWUgc29vbiBidXQgdGhlIDAwIGFscmVhZHkgcHJvdmlkZXMgYSByYXRo ZXIgY2xlYXIgdmlldyBvbiBvdXIgYXBwcm9hY2guDQoNCkNvbW1lbnRzIGFwcHJlY2lhdGVkIGFz IHVzdWFsLA0KDQpQYXNjYWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElF VEYgSS1EIFN1Ym1pc3Npb24gVG9vbCBbbWFpbHRvOmlkc3VibWlzc2lvbkBpZXRmLm9yZ10gDQpT ZW50OiBtYXJkaSAzMSBtYXJzIDIwMDkgMjM6MDANClRvOiBQYXNjYWwgVGh1YmVydCAocHRodWJl cnQpDQpDYzogd2F0dGV5bmVAZWVjcy5iZXJrZWxleS5lZHU7IHphY2hAc2Vuc2lub2RlLmNvbTsg ZG9taW5pcXVlLmJhcnRoZWxAb3JhbmdlLWZ0Z3JvdXAuY29tDQpTdWJqZWN0OiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXRodWJlcnQtcm9sbC1mdW5kYW1lbnRhbHMtMDAgDQoN Cg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXRodWJlcnQtcm9sbC1mdW5kYW1lbnRhbHMt MDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWx5IHN1Ym1pdHRlZCBieSBQYXNjYWwgVGh1YmVydCBh bmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtdGh1 YmVydC1yb2xsLWZ1bmRhbWVudGFscw0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkgTExOIFJvdXRp bmcgRnVuZGFtZW50YWxzDQpDcmVhdGlvbl9kYXRlOgkgMjAwOS0wMy0zMQ0KV0cgSUQ6CQkgSW5k ZXBlbmRlbnQgU3VibWlzc2lvbg0KTnVtYmVyX29mX3BhZ2VzOiAzMw0KDQpBYnN0cmFjdDoNClRo aXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgYmFzaWMgc2V0IG9mIGZ1bmRhbWVudGFsIG1lY2hhbmlz bXMgZm9yDQpyb3V0aW5nIG9uIGEgTG93LXBvd2VyIGFuZCBMb3NzeSBOZXR3b3JrIChMTE4pLiAg SXQgZG9lcyBub3QgaW50ZW5kDQp0byBzcGVjaWZ5IGEgZnVsbC1ibG93biBwcm90b2NvbC4gIEl0 IGlzIHJhdGhlciBvZmZlcmVkIGFzIGEgYmFzaXMgdG8NCnN1cHBvcnQgdGhlIGRpc2N1c3Npb24g d2hpbGUgZGVzaWduaW5nIHRoZSBST0xMIHByb3RvY29sLg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0Lg0KDQoNCg== From tim.winter@ekasystems.com Tue Mar 31 18:48:31 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6384A3A68EF for ; Tue, 31 Mar 2009 18:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6q0IYJFGerrP for ; Tue, 31 Mar 2009 18:48:30 -0700 (PDT) Received: from smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by core3.amsl.com (Postfix) with SMTP id 62D843A6888 for ; Tue, 31 Mar 2009 18:48:30 -0700 (PDT) Received: (qmail 61180 invoked from network); 1 Apr 2009 01:49:30 -0000 Received: from unknown (HELO ?192.168.47.101?) (tim.winter@206.83.249.194 with plain) by smtp103.biz.mail.re2.yahoo.com with SMTP; 1 Apr 2009 01:49:29 -0000 X-Yahoo-SMTP: eUj8LdaswBBWeR39KCwXsq8v1dqNCdNUVNk5_GtuwEk24wd2Wtg- X-YMail-OSG: qr8IKbYVM1l5a.txF.8sNK3CvdmZX4aTBuoDbdmZpvjuIZWBUniYOhhDcEOcmkTRtBV4kf0yyJ0k.IVQBAJaMJEO67FL19rMiyRAHErMNjCtbMsRiscXVenMYcBVV2Dwpa7T94OdO0a9jo35QznDV1BMI.IMZ6svD8kgcuPRcrci1bpi8unsyf9iE2rVu2OPHldV48eB2ZcD6CkpjMcs92_cbFxLx2jZHjVpXrjAWt2XbM8MVwMOuSq20A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D2C826.7020701@ekasystems.com> Date: Tue, 31 Mar 2009 21:49:26 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.19 (X11/20090114) MIME-Version: 1.0 To: roll@ietf.org References: <20090331011501.BCC513A68A6@core3.amsl.com> In-Reply-To: <20090331011501.BCC513A68A6@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Roll] I-D Action:draft-ietf-roll-urban-routing-reqs-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 01:48:31 -0000 WG, We have updated the urban draft to draft-ietf-roll-urban-routing-reqs-05 according to feedback from the IESG evaluation- We clarified the following: - adherence to layered IP architecture, in particular IPv6 - application endpoints can appear outside the LLN, e.g. beyond the LBR - some nodes may act as a combination of sensor/actuator/router - the routing protocol may distribute information on node capabilities to be used (only) for the routing decision process We have also removed reference to groupcast, as it is currently out of scope and not supported in IPv6. Regards, -Tim Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. > > > Title : Urban WSNs Routing Requirements in Low Power and Lossy Networks > Author(s) : M. Dohler, et al. > Filename : draft-ietf-roll-urban-routing-reqs-05.txt > Pages : 21 > Date : 2009-03-30 > > The application-specific routing requirements for Urban Low Power and > Lossy Networks (U-LLNs) are presented in this document. In the near > future, sensing and actuating nodes will be placed outdoors in urban > environments so as to improve the people's living conditions as well > as to monitor compliance with increasingly strict environmental laws. > These field nodes are expected to measure and report a wide gamut of > data, such as required in smart metering, waste disposal, > meteorological, pollution and allergy reporting applications. The > majority of these nodes is expected to communicate wirelessly over a > variety of links such as IEEE 802.15.4, Low power IEEE 802.11, IEEE > 802.15.1 (Bluetooth), which given the limited radio range and the > large number of nodes requires the use of suitable routing protocols. > The design of such protocols will be mainly impacted by the limited > resources of the nodes (memory, processing power, battery, etc.) and > the particularities of the outdoor urban application scenarios. As > such, for a wireless Routing Over Low power and Lossy networks (ROLL) > solution to be useful, the protocol(s) ought to be energy-efficient, > scalable, and autonomous. This documents aims to specify a set of > IPv6 routing requirements reflecting these and further U-LLNs > tailored characteristics. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-urban-routing-reqs-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll