From pete.mccann@motorola.com Tue May 5 10:33: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 CE98D28C0CF; Tue, 5 May 2009 10:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.409 X-Spam-Level: X-Spam-Status: No, score=-6.409 tagged_above=-999 required=5 tests=[AWL=-0.037, 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 kFjZ3kf+xfQI; Tue, 5 May 2009 10:33:33 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with ESMTP id A75CC3A6CF7; Tue, 5 May 2009 10:33:33 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-7.tower-153.messagelabs.com!1241544892!12777424!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [136.182.1.12] Received: (qmail 18435 invoked from network); 5 May 2009 17:34:53 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (136.182.1.12) by server-7.tower-153.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 May 2009 17:34:53 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate2.mot.com (8.14.3/8.14.3) with ESMTP id n45HYqkh023556; Tue, 5 May 2009 10:34:52 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id n45HYqu8012688; Tue, 5 May 2009 12:34:52 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id n45HYp8D012676; Tue, 5 May 2009 12:34:51 -0500 (CDT) 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: Tue, 5 May 2009 13:34:23 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-roll-indus-routing-reqs-05 Thread-Index: AcnNp7qWovSrWEhpTtuY/MjxwBpzWQ== From: "McCann Peter-A001034" To: , X-CFilter-Loop: Reflected X-Mailman-Approved-At: Tue, 05 May 2009 22:02:38 -0700 Cc: roll@ietf.org, roll-ads@tools.ietf.org, roll-chairs@tools.ietf.org Subject: [Roll] Review of draft-ietf-roll-indus-routing-reqs-05 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, 05 May 2009 17:33:34 -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 ).=20 Please wait for direction from your document shepherd or AD before posting a new version of the draft.=20 Document: draft-ietf-roll-indus-routing-reqs-05.txt Reviewer: Pete McCann Review Date: 05 May 2009 IESG Telechat date: 07 May 2009=20 Summary: Ready. =20 This draft addresses all of my comments on -04. The new Introduction is helpful. Major issues: none Minor issues: none Nits/editorial comments: none From zach@sensinode.com Thu May 7 00:43: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 C20E13A6B43 for ; Thu, 7 May 2009 00:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=-1.184, BAYES_40=-0.185, 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 RsZhKC4hYWE8 for ; Thu, 7 May 2009 00:43: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 86FFB3A683D for ; Thu, 7 May 2009 00:43:27 -0700 (PDT) Received: from snl-zach.local ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n477ipIW003742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 May 2009 10:44:51 +0300 Message-ID: <4A02917B.40009@sensinode.com> Date: Thu, 07 May 2009 10:44:59 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [Roll] Border router terminology 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, 07 May 2009 07:43:29 -0000 Hi, Over in the 6lowpan WG we have been using the following term in draft-ietf-6lowpan-nd: LoWPAN Edge Router An IPv6 router that interconnects the LoWPAN to another network. Referred to as an edge router in this document. However following the ROLL documents it seems that this WG has converged on the term "Border Router". We are updated our draft and I am proposing to start using Border Router to keep consistency with ROLL as well. Is Border Router going to continue to be the term used by the design team? I can find references to Border Router in ROLL here: draft-ietf-roll-home-routing-reqs draft-ietf-roll-indus-routing-reqs draft-ietf-roll-urban-routing-reqs draft-thubert-roll-fundamentals draft-tavakoli-hydro Funny enough the (now expired) draft-ietf-roll-terminology doesn't mention it, would be nice if that would be updated. - Zach -- 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 jvasseur@cisco.com Thu May 7 03:36: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 C69E23A6EA6 for ; Thu, 7 May 2009 03:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.214 X-Spam-Level: X-Spam-Status: No, score=-10.214 tagged_above=-999 required=5 tests=[AWL=0.385, 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 25B4bYFJ3jwK for ; Thu, 7 May 2009 03:36:37 -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 F04503A6AC0 for ; Thu, 7 May 2009 03:35:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,309,1238976000"; d="scan'208";a="40019404" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 May 2009 10:37:05 +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 n47Ab5HS025377; Thu, 7 May 2009 12:37:05 +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 n47Ab5Sh022179; Thu, 7 May 2009 10:37:05 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); Thu, 7 May 2009 12:37:05 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 May 2009 12:37:05 +0200 Message-Id: <99D31F57-C845-47A8-A7C9-1B5EDFDC74FC@cisco.com> From: JP Vasseur To: Zach Shelby In-Reply-To: <4A02917B.40009@sensinode.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 7 May 2009 12:37:03 +0200 References: <4A02917B.40009@sensinode.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 07 May 2009 10:37:05.0297 (UTC) FILETIME=[C3C13010:01C9CEFF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2415; t=1241692625; x=1242556625; 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]=20Border=20router=20terminology |Sender:=20; bh=3nzeCW7VlcGBNFQWtBD43XB5TkXZzQazds6WUUVlLao=; b=qfrV/WeBEKxyiUtpp+7PuBUP3o/hAVlsLfQh21PGjZ+SckcVb6hVRZGzTc LTKjAD0EJ9p+9rjyWBhQY8fRkusavXRIpZ1dmduK6kg5U3IimlQA6dAsM+nj pHaBP8lEbJ; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG Subject: Re: [Roll] Border router terminology 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, 07 May 2009 10:36:38 -0000 Hi Zach, On May 7, 2009, at 9:44 AM, Zach Shelby wrote: > Hi, > > Over in the 6lowpan WG we have been using the following term in =20 > draft-ietf-6lowpan-nd: > > LoWPAN Edge Router > > An IPv6 router that interconnects the LoWPAN to another network. > Referred to as an edge router in this document. > > However following the ROLL documents it seems that this WG has =20 > converged on the term "Border Router". We are updated our draft and =20= > I am proposing to start using Border Router to keep consistency with =20= > ROLL as well. > This is an excellent suggestion, thanks. > Is Border Router going to continue to be the term used by the design =20= > team? > Yes. > I can find references to Border Router in ROLL here: > > draft-ietf-roll-home-routing-reqs > draft-ietf-roll-indus-routing-reqs > draft-ietf-roll-urban-routing-reqs > draft-thubert-roll-fundamentals > draft-tavakoli-hydro Good catch. The right term is Low power and lossy border router (LBR), =20= used by the urban draft, not used in industrial, should be updated in =20= the home automation ID. > > Funny enough the (now expired) draft-ietf-roll-terminology doesn't =20 > mention it, would be nice if that would be updated. > It was called LBR: LBR: Low power and lossy network Border Router. The LBR is a device =20 that connects the Low power and Lossy Network to another routing =20 domain such as a Local Area Network (LAN), Wide Area Network (WAN) or =20= the Internet where a possibly different routing protocol is in =20 operation. The LBR acts as a routing device and may possibly host =20 other functions such as data collector or aggregator. The ID has been refreshed. Thanks. JP. > - Zach > > --=20 > http://zachshelby.org - My blog =93On the Internet of Things=94 > 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 =20 > contain legally privileged information. If you are not the intended =20= > recipient, please contact the sender and delete the e-mail from your =20= > system without producing, distributing or retaining copies thereof. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From root@core3.amsl.com Thu May 7 04:00: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 CB4893A6882; Thu, 7 May 2009 04:00: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: <20090507110001.CB4893A6882@core3.amsl.com> Date: Thu, 7 May 2009 04:00:01 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-terminology-01.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, 07 May 2009 11:00: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 : Terminology in Low power And Lossy Networks Author(s) : J. Vasseur Filename : draft-ietf-roll-terminology-01.txt Pages : 7 Date : 2009-05-07 The documents defines a terminology for discussing routing requirements and solutions for networks referred to as Low power and Lossy Networks (LLN). A LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g. Heating, Ventilating, Air Conditioning, lighting, access control, fire), connected home, healthcare, environmental monitoring, urban sensor networks, energy management, assets tracking, refrigeration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-terminology-01.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-terminology-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-07034815.I-D@ietf.org> --NextPart-- From pal@cs.stanford.edu Thu May 7 09:48: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 C05D328C176 for ; Thu, 7 May 2009 09:48: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=[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 9lAbe2pLm105 for ; Thu, 7 May 2009 09:48:59 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 215FC3A6BE0 for ; Thu, 7 May 2009 09:46:48 -0700 (PDT) Received: from dnab4221c2.stanford.edu ([171.66.33.194]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1M26lc-0002Bm-71; Thu, 07 May 2009 09:48:16 -0700 Message-Id: From: Philip Levis To: JP Vasseur In-Reply-To: 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, 7 May 2009 09:48:16 -0700 References: X-Mailer: Apple Mail (2.930.3) X-Scan-Signature: ff384b2b9a2989b26e23b1d864f6aba2 Cc: ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] Few comments for our first discussion today 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, 07 May 2009 16:48:59 -0000 On Apr 16, 2009, at 6:31 AM, JP Vasseur wrote: > Dear all, > > First many thanks again for accepting to be part of the DT. I did > not want to comment on the various individual submissions so far > since it was much more appropriate to provide feed-back to the DT, > especially because the authors of these drafts are part of the DT. > > Please find below some comments (that apply to the IDs already > posted): Have there been any subsequent DT discussions? I can't seem to find any follow-up reports to the WG. Phil From jvasseur@cisco.com Thu May 7 10:00: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 CED7E3A6CB1 for ; Thu, 7 May 2009 10:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.221 X-Spam-Level: X-Spam-Status: No, score=-10.221 tagged_above=-999 required=5 tests=[AWL=0.378, 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 vv+s+tLovowm for ; Thu, 7 May 2009 10:00:37 -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 864B83A6C9E for ; Thu, 7 May 2009 10:00:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,311,1238976000"; d="scan'208";a="40065029" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 07 May 2009 17:02:03 +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 n47H234c014075; Thu, 7 May 2009 19:02:03 +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 n47H239D006183; Thu, 7 May 2009 17:02:03 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, 7 May 2009 19:02:03 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 May 2009 19:02:02 +0200 Message-Id: <842549E6-6773-4441-8EB1-29D669FF0785@cisco.com> From: JP Vasseur To: Philip Levis In-Reply-To: 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, 7 May 2009 19:02:02 +0200 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 07 May 2009 17:02:02.0964 (UTC) FILETIME=[8B097940:01C9CF35] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=892; t=1241715723; x=1242579723; 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]=20Few=20comments=20for=20our=20f irst=20discussion=20today |Sender:=20; bh=ioETEGg004tpbwA4Aa6a89v2Ygk6fdlhWy+4nDikDrE=; b=lhuOwLvcPWi/cHk/5uvxEivG1QgRsrPIrfVfJR8f4xSGrXtbfYtvwQeoIk y4Dkpqe38ysmr+q7GMkV6CVCfyiMPa9inH6QiQ0DSlVC97sBaxYTnhbUfOrS 7/vMM2cygg; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] Few comments for our first discussion today 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, 07 May 2009 17:00:37 -0000 Hi Phil, On May 7, 2009, at 6:48 PM, Philip Levis wrote: > > On Apr 16, 2009, at 6:31 AM, JP Vasseur wrote: > >> Dear all, >> >> First many thanks again for accepting to be part of the DT. I did >> not want to comment on the various individual submissions so far >> since it was much more appropriate to provide feed-back to the DT, >> especially because the authors of these drafts are part of the DT. >> >> Please find below some comments (that apply to the IDs already >> posted): > > Have there been any subsequent DT discussions? I can't seem to find > any follow-up reports to the WG. > Yes the DT has been working hard and should very soon be ready to provide some comments, ask for feed-back/advise from the WG, .. the goal is to have a first ID (very first draft) within 2 weeks or so to start some discussion. Thanks. JP. > Phil From pal@cs.stanford.edu Thu May 7 11:33: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 1631028C32F for ; Thu, 7 May 2009 11:33:53 -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 s6Ld5sc4osN5 for ; Thu, 7 May 2009 11:33:52 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 6991528C346 for ; Thu, 7 May 2009 11:33:28 -0700 (PDT) Received: from dnab4226fd.stanford.edu ([171.66.38.253]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1M28Qq-0008KP-HL; Thu, 07 May 2009 11:34:56 -0700 Message-Id: From: Philip Levis To: JP Vasseur In-Reply-To: <842549E6-6773-4441-8EB1-29D669FF0785@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: Thu, 7 May 2009 11:34:56 -0700 References: <842549E6-6773-4441-8EB1-29D669FF0785@cisco.com> X-Mailer: Apple Mail (2.930.3) X-Scan-Signature: 993826b9125cbf1b907f71dc54053338 Cc: ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] Few comments for our first discussion today 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, 07 May 2009 18:33:53 -0000 On May 7, 2009, at 10:02 AM, JP Vasseur wrote: > Hi Phil, > > On May 7, 2009, at 6:48 PM, Philip Levis wrote: > >> >> On Apr 16, 2009, at 6:31 AM, JP Vasseur wrote: >> >>> Dear all, >>> >>> First many thanks again for accepting to be part of the DT. I did >>> not want to comment on the various individual submissions so far >>> since it was much more appropriate to provide feed-back to the DT, >>> especially because the authors of these drafts are part of the DT. >>> >>> Please find below some comments (that apply to the IDs already >>> posted): >> >> Have there been any subsequent DT discussions? I can't seem to find >> any follow-up reports to the WG. >> > > Yes the DT has been working hard and should very soon be ready to > provide some comments, ask for feed-back/advise from the WG, .. the > goal is to have a first ID (very first draft) within 2 weeks or so > to start some discussion. Going from a restatement of general design considerations to a concrete design in a draft doesn't provide a lot of visibility into the process. While I think it would be counter-productive for the WG to question every intermediate state of the DT's design, having some understanding of the process and considerations made would be helpful. Otherwise, I fear that reception of the first ID will end up with a long discussion of assumptions rather than technical details, which will ultimately lead to an inferior design. Phil From alexandru.petrescu@gmail.com Thu May 7 12:24: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 BDFF33A68EA for ; Thu, 7 May 2009 12:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.832 X-Spam-Level: X-Spam-Status: No, score=-0.832 tagged_above=-999 required=5 tests=[AWL=-0.997, BAYES_40=-0.185, 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 ReoQh87--jUu for ; Thu, 7 May 2009 12:24:10 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 8316328C2F4 for ; Thu, 7 May 2009 12:24:05 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 33432E080FF; Thu, 7 May 2009 21:25:28 +0200 (CEST) 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 6F666E08197; Thu, 7 May 2009 21:25:25 +0200 (CEST) Message-ID: <4A0335A2.60308@gmail.com> Date: Thu, 07 May 2009 21:25:22 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Philip Levis References: <842549E6-6773-4441-8EB1-29D669FF0785@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090506-0, 06/05/2009), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] Few comments for our first discussion today 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, 07 May 2009 19:24:10 -0000 Philip Levis a écrit : > > On May 7, 2009, at 10:02 AM, JP Vasseur wrote: > >> Hi Phil, >> >> On May 7, 2009, at 6:48 PM, Philip Levis wrote: >> >>> >>> On Apr 16, 2009, at 6:31 AM, JP Vasseur wrote: >>> >>>> Dear all, >>>> >>>> First many thanks again for accepting to be part of the DT. I did >>>> not want to comment on the various individual submissions so far >>>> since it was much more appropriate to provide feed-back to the DT, >>>> especially because the authors of these drafts are part of the DT. >>>> >>>> Please find below some comments (that apply to the IDs already posted): >>> >>> Have there been any subsequent DT discussions? I can't seem to find >>> any follow-up reports to the WG. >>> >> >> Yes the DT has been working hard and should very soon be ready to >> provide some comments, ask for feed-back/advise from the WG, .. the >> goal is to have a first ID (very first draft) within 2 weeks or so to >> start some discussion. > > Going from a restatement of general design considerations to a concrete > design in a draft doesn't provide a lot of visibility into the process. > While I think it would be counter-productive for the WG to question > every intermediate state of the DT's design, having some understanding > of the process and considerations made would be helpful. Otherwise, I > fear that reception of the first ID will end up with a long discussion > of assumptions rather than technical details, which will ultimately lead > to an inferior design. I agree in the sense there is need for more visibility to the DT activities - are there public archives of the ongoing DT email discussions? I'm working on an energy metric for IPv6 links... how would this fit in the eventual ROLL protocol? For example, does the ROLL protocol take _any_ metric into account? The IP distance (number of hops)? Any other metric? I'm interested in the current DT thinking about the metrics, at least. Alex From cabo@tzi.org Thu May 7 15:08:49 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 A9E963A7021 for ; Thu, 7 May 2009 15:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 G38tEHvLP+dn for ; Thu, 7 May 2009 15:08:49 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 6D4213A67AC for ; Thu, 7 May 2009 15:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n47MA44E003674; Fri, 8 May 2009 00:10:05 +0200 (CEST) Received: from [192.168.217.107] (p5489D246.dip.t-dialin.net [84.137.210.70]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 5FA0E1704D6; Fri, 8 May 2009 00:10:04 +0200 (CEST) From: Carsten Bormann To: JP Vasseur In-Reply-To: <99D31F57-C845-47A8-A7C9-1B5EDFDC74FC@cisco.com> References: <4A02917B.40009@sensinode.com> <99D31F57-C845-47A8-A7C9-1B5EDFDC74FC@cisco.com> Message-Id: <729BF4C8-37FB-4508-8EE9-D50E7DD3310B@tzi.org> 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, 8 May 2009 00:10:02 +0200 X-Mailer: Apple Mail (2.930.3) Cc: ROLL WG Subject: Re: [Roll] Border router terminology 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, 07 May 2009 22:08:49 -0000 > LBR: Low power and lossy network Border Router. The LBR is a device > that connects the Low power and Lossy Network to another routing > domain such as a Local Area Network (LAN), Wide Area Network (WAN) > or the Internet where a possibly different routing protocol is in > operation. The LBR acts as a routing device and may possibly host > other functions such as data collector or aggregator. This is a great exhibit for explaining why I don't like the term "border router" for the Lowpan Edge Router. The Lowpan Edge Router (let's call that LER for the moment) is just that: a router. It does two things: 1) routing IP (possibly involving one or more routing protocols). 2) running the adaptation layers for its links (including certain parts of ND optimization for the 6lowpan, which make it one of the *edge* routers). Every IP router does exactly those two things, except that the LER is the only kind of node with that specific role in ND-opt. The LER is not a processing node. For some reason, the term "border" seems to cause people to think about barbed wire, customs officers, protecting domains and other processing like the data collection/aggregation mentioned above. I know that the history of this term in the IETF RTG area is closer to an actual router. with BGP and OSPF ABRs and all that. But even here, the term "border" is used for something sitting on the boundary connecting two equals (domains, areas), not for something sitting on the edge of one type of thing and talking to other types of things, which is pretty much what the LER does. Gruesse, Carsten From wintert@acm.org Thu May 7 18:20: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 1F61F3A67E4 for ; Thu, 7 May 2009 18:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 XGtpECGvSQhC for ; Thu, 7 May 2009 18:20:31 -0700 (PDT) Received: from smtp107.prem.mail.ac4.yahoo.com (smtp107.prem.mail.ac4.yahoo.com [76.13.13.46]) by core3.amsl.com (Postfix) with SMTP id EB9703A67AD for ; Thu, 7 May 2009 18:20:30 -0700 (PDT) Received: (qmail 71639 invoked from network); 8 May 2009 01:21:57 -0000 Received: from unknown (HELO ?192.168.47.101?) (wintert@206.83.249.194 with plain) by smtp107.prem.mail.ac4.yahoo.com with SMTP; 8 May 2009 01:21:57 -0000 X-YMail-OSG: F6NUXBoVM1kpKCxg_wEeX2fato01bZGZ2MCNr0r2EH76Tc5oGGROloV48_0YrBHDYfYnO9u3a.TsDiNNrCbYhdfMl.xcBLv36W0HfWfR6nGsiaLq5.mUBZANVws1bTG1rqJvHYMgtSjpa.CrsZdHNVbJs.YQ0HOAGgoi9RlXOmkT3SygNUrcjU_0pdhorncY9JEX0iB2oNPTlD_NlPx57O1zuCirbHjmsSPsm4xTamPGmunlEXXM3umz8gKKcN32Y19wzBE2mtiEGWjAW5zbwXE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A03892F.2060601@acm.org> Date: Thu, 07 May 2009 21:21:51 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.21 (X11/20090330) MIME-Version: 1.0 To: Philip Levis , alexandru.petrescu@gmail.com References: <842549E6-6773-4441-8EB1-29D669FF0785@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ROLL WG , dtroll@external.cisco.com Subject: [Roll] DT update (Re: Few comments for our first discussion today) 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, 08 May 2009 01:20:32 -0000 Hi Philip, Alexandru, WG, The design team is aware that our efforts are only viable if the WG finds them usable, and it is certainly not our intent that the process would appear opaque. I see your point that more visibility into the process will better equip the WG to perform a focused technical review of the resulting draft, as opposed to being distracted trying to understand the process/assumptions. I certainly dont want to see all of this effort produce an inferior solution. I shall endeavor to keep the WG updated more frequently. We have looked at the 4 requirements documents, extracting the MUSTs, categorized them together, and used this exercise as a basis to understand what would be required of a common routing solution. We recognize the constrained and challenging aspects of LLN networks, and the subsequent trade offs that will have to be made in application solutions. Based on these exercises and further discussion, we have a working concept of a routing solution built around a simple, core protocol plus a number of options which can be added in a controlled manner to suit various applications and take advantage of platform capabilities. Further, we are thinking that the solution should be specified in a parametrized/configurable manner that will allow a solution implementer to make trade-offs in the operation/administration of the protocol as appropriate to the application/platform. It is envisaged that a series of Applicability Statements will also be developed to guide the implementer in selecting parameters appropriate to solutions for the urban, building, industrial, and home applications. In light of this strategy, the DT has reached consensus that the most straightforward approach is to specify a new routing protocol. With this approach we believe we can be most successful in having a minimal protocol suitable to the ROLL application requirements. We do certainly hope to draw on many of the features found in existing protocols in order to composite a solution. The DT is currently in the process of defining the basic mechanisms of the core protocol. A first draft outlining what we know of the solution so far is underway, and will be further fleshed out by the basic mechanisms as DT consensus is reached. We are also working to refine our terminology. At this time it is a little too early in the process to have specific technical details on, e.g. metrics (although there will certainly be metrics! ;) ), but once the basic mechanisms are defined then I think the DT should be able to quickly reach consensus on such items, soliciting input from the WG as needed. Regards, -Tim Philip Levis wrote: > > On May 7, 2009, at 10:02 AM, JP Vasseur wrote: > >> Hi Phil, >> >> On May 7, 2009, at 6:48 PM, Philip Levis wrote: >> >>> >>> On Apr 16, 2009, at 6:31 AM, JP Vasseur wrote: >>> >>>> Dear all, >>>> >>>> First many thanks again for accepting to be part of the DT. I did >>>> not want to comment on the various individual submissions so far >>>> since it was much more appropriate to provide feed-back to the DT, >>>> especially because the authors of these drafts are part of the DT. >>>> >>>> Please find below some comments (that apply to the IDs already posted): >>> >>> Have there been any subsequent DT discussions? I can't seem to find >>> any follow-up reports to the WG. >>> >> >> Yes the DT has been working hard and should very soon be ready to >> provide some comments, ask for feed-back/advise from the WG, .. the >> goal is to have a first ID (very first draft) within 2 weeks or so to >> start some discussion. > > Going from a restatement of general design considerations to a concrete > design in a draft doesn't provide a lot of visibility into the process. > While I think it would be counter-productive for the WG to question > every intermediate state of the DT's design, having some understanding > of the process and considerations made would be helpful. Otherwise, I > fear that reception of the first ID will end up with a long discussion > of assumptions rather than technical details, which will ultimately lead > to an inferior design. > > Phil > From pal@cs.stanford.edu Thu May 7 18:26:20 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 53AB93A67AD for ; Thu, 7 May 2009 18:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 XmfWrgUHVXsh for ; Thu, 7 May 2009 18:26:19 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 194343A6F3F for ; Thu, 7 May 2009 18:26:12 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.105]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1M2EsG-00031m-5v; Thu, 07 May 2009 18:27:40 -0700 In-Reply-To: <4A03892F.2060601@acm.org> References: <842549E6-6773-4441-8EB1-29D669FF0785@cisco.com> <4A03892F.2060601@acm.org> 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: Philip Levis Date: Thu, 7 May 2009 18:27:18 -0700 To: Tim Winter X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: ae7d61d5ad21aa0d569d6b6c8168eb46 Cc: ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] DT update (Re: Few comments for our first discussion today) 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, 08 May 2009 01:26:20 -0000 On May 7, 2009, at 6:21 PM, Tim Winter wrote: > Hi Philip, Alexandru, WG, > > The design team is aware that our efforts are only viable if the WG > finds > them usable, and it is certainly not our intent that the process would > appear opaque. I see your point that more visibility into the > process will > better equip the WG to perform a focused technical review of the > resulting > draft, as opposed to being distracted trying to understand the > process/assumptions. I certainly dont want to see all of this effort > produce an inferior solution. I shall endeavor to keep the WG > updated more frequently. > > We have looked at the 4 requirements documents, extracting the MUSTs, > categorized them together, and used this exercise as a basis to > understand > what would be required of a common routing solution. > > We recognize the constrained and challenging aspects of LLN > networks, and > the subsequent trade offs that will have to be made in application > solutions. > > Based on these exercises and further discussion, we have a working > concept > of a routing solution built around a simple, core protocol plus a > number of > options which can be added in a controlled manner to suit various > applications and take advantage of platform capabilities. Further, > we are > thinking that the solution should be specified in a > parametrized/configurable manner that will allow a solution > implementer to > make trade-offs in the operation/administration of the protocol as > appropriate to the application/platform. It is envisaged that a > series of > Applicability Statements will also be developed to guide the > implementer in > selecting parameters appropriate to solutions for the urban, building, > industrial, and home applications. > > In light of this strategy, the DT has reached consensus that the most > straightforward approach is to specify a new routing protocol. > With this > approach we believe we can be most successful in having a minimal > protocol > suitable to the ROLL application requirements. We do certainly > hope to > draw on many of the features found in existing protocols in order > to composite a solution. > > The DT is currently in the process of defining the basic mechanisms > of the > core protocol. A first draft outlining what we know of the > solution so > far is underway, and will be further fleshed out by the basic > mechanisms as > DT consensus is reached. We are also working to refine our > terminology. > > At this time it is a little too early in the process to have specific > technical details on, e.g. metrics (although there will certainly be > metrics! ;) ), but once the basic mechanisms are defined then I > think the DT > should be able to quickly reach consensus on such items, soliciting > input from the WG as needed. Tim, This is very helpful. Thanks! One question: could you articulate the requirements of the core protocol? That is, what the DT's thoughts are on what should "core" and what should be an "option?" I understand that this list might change a bit, and so don't want to quibble on it, but it would help understand the priorities in the design's tradeoffs. Phil From zach@sensinode.com Fri May 8 01:28: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 1CDBA3A68B1 for ; Fri, 8 May 2009 01:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 sAiQTYuWFX+y for ; Fri, 8 May 2009 01:27:59 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id C9D8C3A698B for ; Fri, 8 May 2009 01:27:58 -0700 (PDT) Received: from snl-zach.local ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n488TKvg010079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 May 2009 11:29:21 +0300 Message-ID: <4A03ED6E.2040309@sensinode.com> Date: Fri, 08 May 2009 11:29:34 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Carsten Bormann References: <4A02917B.40009@sensinode.com> <99D31F57-C845-47A8-A7C9-1B5EDFDC74FC@cisco.com> <729BF4C8-37FB-4508-8EE9-D50E7DD3310B@tzi.org> In-Reply-To: <729BF4C8-37FB-4508-8EE9-D50E7DD3310B@tzi.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Border router terminology 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, 08 May 2009 08:28:00 -0000 Carsten Bormann wrote: >> LBR: Low power and lossy network Border Router. The LBR is a device >> that connects the Low power and Lossy Network to another routing >> domain such as a Local Area Network (LAN), Wide Area Network (WAN) or >> the Internet where a possibly different routing protocol is in >> operation. The LBR acts as a routing device and may possibly host >> other functions such as data collector or aggregator. > > This is a great exhibit for explaining why I don't like the term "border > router" for the Lowpan Edge Router. For some background, the original suggestion in the 6lowpan WG was that Access Router may be a more suitable term than Edge Router. However that also makes no sense as it doesn't provide any synchronization with ROLL. Regarding Edge vs. Border... personally I think we are splitting hairs here. The most important thing is that it is understandable and consistent for us and especially for newcomers to 6lowpan/roll specifications. Considering the ZigBee announcement last week - there will be plenty of newcomers coming in. You can compare this to IPv6 where all documents including RFC4861 and routing algorithms use the common term "router". It would make equal sense that in ND for 6LoWPAN and routing algorithms (such as roll) we will likely use with 6LoWPAN have the same terminology if possible. It is messy to have Edge Routers on which implementers need to understand are equivalent to Border Routers for the routing algorithm. I'll bring this back to the 6lowpan WG - seems we need to discuss a bit more if this term is really controversial or not. - Zach > The Lowpan Edge Router (let's call that LER for the moment) is just > that: a router. > It does two things: > 1) routing IP (possibly involving one or more routing protocols). > 2) running the adaptation layers for its links (including certain parts > of ND optimization for the 6lowpan, which make it one of the *edge* > routers). > Every IP router does exactly those two things, except that the LER is > the only kind of node with that specific role in ND-opt. > > The LER is not a processing node. > > For some reason, the term "border" seems to cause people to think about > barbed wire, customs officers, protecting domains and other processing > like the data collection/aggregation mentioned above. > > I know that the history of this term in the IETF RTG area is closer to > an actual router. with BGP and OSPF ABRs and all that. > But even here, the term "border" is used for something sitting on the > boundary connecting two equals (domains, areas), not for something > sitting on the edge of one type of thing and talking to other types of > things, which is pretty much what the LER does. > > Gruesse, Carsten > -- 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 jvasseur@cisco.com Fri May 8 03:33: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 846AD3A6CF8 for ; Fri, 8 May 2009 03:33:57 -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 wIhP3TjAJGnM for ; Fri, 8 May 2009 03:33:56 -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 E9DB23A68DA for ; Fri, 8 May 2009 03:33:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,316,1238976000"; d="scan'208";a="40111988" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 May 2009 10:35:21 +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 n48AZLe2018250; Fri, 8 May 2009 12:35:21 +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 n48AZLec014491; Fri, 8 May 2009 10:35:21 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); Fri, 8 May 2009 12:35:21 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 May 2009 12:35:20 +0200 Message-Id: <03960C5B-8DB5-427C-B77E-4AC1C357678D@cisco.com> From: JP Vasseur To: Philip Levis , Alexandru Petrescu In-Reply-To: <4A0335A2.60308@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, 8 May 2009 12:35:18 +0200 References: <842549E6-6773-4441-8EB1-29D669FF0785@cisco.com> <4A0335A2.60308@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 08 May 2009 10:35:20.0880 (UTC) FILETIME=[AFEE2B00:01C9CFC8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2825; t=1241778921; x=1242642921; 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]=20Few=20comments=20for=20our=20f irst=20discussion=20today |Sender:=20; bh=Sw3PWNz3OJsU5l0FQd+5aX8Md/sdvwvwXZyIvX6M3ps=; b=dwKSqc1rwbelC7VlhOtchiuiuD3OkR31CxH5vieEahc7hTL/mNFBJkA2Pv 2cqH9jJiUdhY2Q1rR3HTRmJVB5P5Wh2kRC7uwYrfev+JejeBC7jPdc5dMrfu vGAqSnoJnl; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] Few comments for our first discussion today 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, 08 May 2009 10:33:57 -0000 On May 7, 2009, at 9:25 PM, Alexandru Petrescu wrote: > Philip Levis a =E9crit : >> On May 7, 2009, at 10:02 AM, JP Vasseur wrote: >>> Hi Phil, >>> >>> On May 7, 2009, at 6:48 PM, Philip Levis wrote: >>> >>>> >>>> On Apr 16, 2009, at 6:31 AM, JP Vasseur wrote: >>>> >>>>> Dear all, >>>>> >>>>> First many thanks again for accepting to be part of the DT. I =20 >>>>> did not want to comment on the various individual submissions so =20= >>>>> far since it was much more appropriate to provide feed-back to =20 >>>>> the DT, especially because the authors of these drafts are part =20= >>>>> of the DT. >>>>> >>>>> Please find below some comments (that apply to the IDs already =20 >>>>> posted): >>>> >>>> Have there been any subsequent DT discussions? I can't seem to =20 >>>> find any follow-up reports to the WG. >>>> >>> >>> Yes the DT has been working hard and should very soon be ready to =20= >>> provide some comments, ask for feed-back/advise from the WG, .. =20 >>> the goal is to have a first ID (very first draft) within 2 weeks =20 >>> or so to start some discussion. >> Going from a restatement of general design considerations to a =20 >> concrete design in a draft doesn't provide a lot of visibility into =20= >> the process. While I think it would be counter-productive for the =20 >> WG to question every intermediate state of the DT's design, having =20= >> some understanding of the process and considerations made would be =20= >> helpful. Otherwise, I fear that reception of the first ID will end =20= >> up with a long discussion of assumptions rather than technical =20 >> details, which will ultimately lead to an inferior design. > > I agree in the sense there is need for more visibility to the DT =20 > activities - are there public archives of the ongoing DT email =20 > discussions? The DT will come back to the WG VEYR soon ... so far discussions have =20= been focussed on syncing up on requirements, look at existing =20 solutions, ... I asked the DT to go back to the WG for input as soon =20 as there will be even a first cut of the core protocol. > > I'm working on an energy metric for IPv6 links... how would this fit =20= > in the eventual ROLL protocol? For example, does the ROLL protocol =20= > take _any_ metric into account? The IP distance (number of hops)? =20= > Any other metric? > > I'm interested in the current DT thinking about the metrics, at least. There is a document discussing metrics that has been adopted as WG =20 (should be published soon). Expected new revision in 2 weeks: could =20 you comment on it ? Thanks. JP. > > Alex > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From wintert@acm.org Fri May 8 16:38:45 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 F24833A68CE for ; Fri, 8 May 2009 16:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 lK-IMngIqgmQ for ; Fri, 8 May 2009 16:38:45 -0700 (PDT) Received: from smtp103.prem.mail.ac4.yahoo.com (smtp103.prem.mail.ac4.yahoo.com [76.13.13.42]) by core3.amsl.com (Postfix) with SMTP id 201313A6A27 for ; Fri, 8 May 2009 16:38:45 -0700 (PDT) Received: (qmail 70050 invoked from network); 8 May 2009 23:40:12 -0000 Received: from unknown (HELO ?192.168.47.101?) (wintert@206.83.249.194 with plain) by smtp103.prem.mail.ac4.yahoo.com with SMTP; 8 May 2009 23:40:12 -0000 X-YMail-OSG: njLo8jcVM1ne2saBAQNluWco2QMMAysNMSbjwTKUIs57mwR6xVH6UNh9ElB5ZXN99NK3S1DEzbpwvfdQaM0Wafv0NZ58kffYmrYOsunEWuTSvB.c9ti_sTKJ8kBLJhxDLk_BH5HqU3Xb2VSKicqJhxb7Zo5KWlqqUOgm70xCka84eRw6tW3MgSrsGKY5UbEmHbQAm8jKuWwmQ_QmTiWrZ46gQSx8cMd0JlgzHa.MGwq2wpO0.ETNCK609Rs_HBRBVArvXkn0Rv4e2VObObVwduY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A04C2DC.6070608@acm.org> Date: Fri, 08 May 2009 19:40:12 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.21 (X11/20090330) MIME-Version: 1.0 To: Philip Levis , ROLL WG References: <842549E6-6773-4441-8EB1-29D669FF0785@cisco.com> <4A03892F.2060601@acm.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dtroll@external.cisco.com Subject: Re: [Roll] DT 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: Fri, 08 May 2009 23:38:46 -0000 Phil, We are not ready to articulate such a list yet, but should be shortly. I will keep you posted. -Tim Philip Levis wrote: > ... > One question: could you articulate the requirements of the core > protocol? That is, what the DT's thoughts are on what should "core" and > what should be an "option?" I understand that this list might change a > bit, and so don't want to quibble on it, but it would help understand > the priorities in the design's tradeoffs. > > Phil > From gnawali@gmail.com Fri May 8 17:50: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 C9E693A6D07 for ; Fri, 8 May 2009 17:50:36 -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 PXSrAk1MBH4j for ; Fri, 8 May 2009 17:50:35 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id 24AB43A6A03 for ; Fri, 8 May 2009 17:50:35 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so1265542rvb.49 for ; Fri, 08 May 2009 17:52:02 -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:content-transfer-encoding; bh=gKtLEgJaQ6GpznBaLIhe0py6rAWyt36Iz/mv+22oTtM=; b=K34BF+g4DKFeISDmsdxXmPUamHnjwMMb/LPjDoXqaK3+iPgpZBfMxmauyFFm9hLOS3 nm0aGh/vIrB+N/pF/E068WF4FTJOmyWk2HtRXPxrkE9hVaP6TC4+5STzifpiqruWwpgM Be0iDMLMKs5TzPLG/UERUQZ1072kPOqX68oxw= 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 :content-transfer-encoding; b=BmvoGENNPq9VApfqajlfw1z4XI4f92jt11Uqj4GdYUO7d/sQEguNHBRma0la9/WDvf s4kAnGijLlI5E4xgt1y4/YIMuVBW2rVchgwOVHBoIZkO04k323QUn5YNAYfwzxOSrBWZ bThULVu7YdLlBnFqyItDcgl4XhHmtOyg+PuDY= MIME-Version: 1.0 Sender: gnawali@gmail.com Received: by 10.142.101.17 with SMTP id y17mr1687718wfb.69.1241830322666; Fri, 08 May 2009 17:52:02 -0700 (PDT) In-Reply-To: <0719A7FB-BEC0-4CB2-9EF0-4CD4CE4CDE26@cs.stanford.edu> References: <7892795E1A87F04CADFCCF41FADD00FC074276FB@xmb-ams-337.emea.cisco.com> <200904101756.n3AHusWx022894@kelsey-ws.hq.ember.com> <49E041A2.9020206@sensinode.com> <200904131004.n3DA4gxC028339@kelsey-ws.hq.ember.com> <0719A7FB-BEC0-4CB2-9EF0-4CD4CE4CDE26@cs.stanford.edu> Date: Fri, 8 May 2009 17:52:02 -0700 X-Google-Sender-Auth: fafd5572f0b77592 Message-ID: From: Omprakash Gnawali To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-01 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, 09 May 2009 00:50:36 -0000 On Tue, Apr 14, 2009 at 4:52 PM, Philip Levis wrote: > > On Apr 13, 2009, at 3:04 AM, Richard Kelsey wrote: > >> =A0Date: Sat, 11 Apr 2009 10:07:14 +0300 >> =A0From: Zach Shelby >> >> =A0Richard Kelsey wrote: >>> >>> =A0From: Philip Levis >>> =A0Date: Fri, 10 Apr 2009 06:52:04 -0700 >>> >>> =A0On Apr 9, 2009, at 1:59 AM, Pascal Thubert (pthubert) wrote: >>> >>>> Basically, since we have a depth, we have feasible parents (of >>>> lesser depth) and siblings (of same depth). The draft suggests that >>>> we can select any parent to forward on a per packet basis using the >>>> best metric or more advanced load balancing functionality; if that >>>> fails then we can use a sibling with some basic loop avoidance like >>>> poison return or more advanced path vector (for hydrophiles). >>> >>> =A0Here's a URL to a paper that describes one way to solve this problem= , >>> =A0using the techniques I mentioned a few weeks ago and touched on in m= y >>> =A0talk in SF: >>> >>> =A0http://sing.stanford.edu/pubs/ctp.pdf >>> >>> Good stuff. =A0Relating this back to the Routing Fundamentals >>> draft, it seems clear that ROLL will most likely use trees >>> for at least some routing, and while Router Advertisements >>> can be used to build trees, it will be good if tree >>> building and/or maintenance can be performed independently >>> of Router Advertisements. =A0They add too much overhead >>> to make it easy to react quickly to changing conditions. >> >> =A0Don't think of router advertisements as overhead - as we >> =A0are working with IP networks you will always have RAs as >> =A0they are an integral part of network bootstrapping and >> =A0maintenance (Neighbor Discovery). =A0As you have RAs >> =A0anyways, you might as well piggyback some tree >> =A0information. >> >> To be pedantic, they aren't application payload, so they are >> overhead. =A0That wasn't the point I was making, though. > > Even if it isn't the point you were trying to make, I'd agree with it. :) > It's hard to say that a routing protocol is efficient if it sends 1000 RA= s > for every data packet. At the most abstract level, a protocol's overhead = is > (total bytes - data bytes)/data bytes. That being said, the presence of > energy as a critical metric means that there can and are situations where > higher overhead can lead to greater efficiency. For example, a header fie= ld > that gives some sort of rendezvous timing as in Jonathan's IP stack. > >> The piggybacking only works if there happens to be an RA >> going out around the time that new tree information needs to >> be sent. =A0Am I missing a connection between the two that >> makes this likely? =A0The Collection Tree Protocol mentioned >> above reacts to topology changes within a second or two. > > Even faster -- one experiment we did on this saw 10-15 packet times, whic= h > was 200-300ms. It turns out that, for 802.15.4 at least, in tough > environments links tend to have a coherence time around 500ms, so you'd l= ike > to be able to either react much faster or much slower than that. Faster s= o > you don't keep on hammering a bad link, or slower so that the next > transmission is a random coin toss. > > >> =A0I >> don't know if that low a response time is necessary, but it >> does seem clear that tree topology will sometimes be >> changing much faster than the data in the RAs. =A0If new tree >> information needs to be sent, but new RA information does >> not, then the RA data is overhead. > > I agree with this: it's the exact problem that adaptive beaconing tries t= o > solve. Any periodic RA mechanism introduces a tough tradeoff: beacon fast= er > for fast adaptation but high cost, or beacon slower for efficiency but sl= ow > adaptation. =A0Hence the point of borrowing and extending Trickle -- send= just > enough RAs for nodes to discover each other and verify that the tree is > still consistent. Data path validation allows the protocol to verify the > tree's consistency without introducing additional (RA) overhead. > > >> I am not suggesting that we not piggyback tree information >> on RAs, just that it would be good to also be able to >> piggyback it on other messages or send it independently. > > The design question here is *what* information to piggyback. One interest= ing > way that the paper I sent out differs from Jonathan's IP stack is his sta= ck > includes hop count in data packets (Section 8.1.4 of the SenSys 2008 pape= r). > From an academic standpoint, it would be an interesting evaluation to see > whether the cost of this field is less than the cost of false positives o= n > CTP's loop detection (the case where a node's ETX goes up but its childre= n > don't know yet, so it thinks there might be a loop). I say it's academic > because my guess is that it's a comparatively small difference either way= , > compared to other, more important issues. > > Om -- this might be a nice experiment to look at from the traces, just > compute how often CTP beacon resets are false positives on loop detection= . I did a quick analysis of logs from two experiments - one on channel 16 and one on 26 on a 91-node network. In general, a large number of detections are false positives -- thats a good thing. A node can generate a number of loop detection events after a single loop is detected because there might be a stream of incoming packets failing the consistency check while topology maintenance is triggered. Here are graphs for ch 16 (98% delivery ratio, 4k seconds): http://enl.usc.edu/~om_p/net2/ch16-loops1.gif (almost all nodes report loop detection events, max of 460 detections in a single node, gap between green and blue shows beacon timer resets due to true loops [node saw the same pkt twice]) http://enl.usc.edu/~om_p/net2/ch16-loops2.gif (significant fraction are false detections, most beacons are sent due to false detections) Here are graphs for ch 26 (99.997%, 10.8k seconds): http://enl.usc.edu/~om_p/net2/ch26-loops1.gif (shows 4 nodes reported loop detection events, max of 6 detection in a single node) http://enl.usc.edu/~om_p/net2/ch26-loops2.gif (all detections, loops -- false positives) - om_p From pal@cs.stanford.edu Fri May 8 20:52:12 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 29E523A689C for ; Fri, 8 May 2009 20:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.53 X-Spam-Level: X-Spam-Status: No, score=-5.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 eC7DuCQNd4bV for ; Fri, 8 May 2009 20:52:11 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 75ACD3A6813 for ; Fri, 8 May 2009 20:52:11 -0700 (PDT) Received: from [67.142.204.34] (helo=[192.168.1.8]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1M2dd3-0004rz-Cb; Fri, 08 May 2009 20:53:40 -0700 Message-Id: <89B77F58-BDF0-4ECC-A792-349096465991@cs.stanford.edu> From: Philip Levis To: JP Vasseur In-Reply-To: <03960C5B-8DB5-427C-B77E-4AC1C357678D@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: Fri, 8 May 2009 13:59:24 -0700 References: <842549E6-6773-4441-8EB1-29D669FF0785@cisco.com> <4A0335A2.60308@gmail.com> <03960C5B-8DB5-427C-B77E-4AC1C357678D@cisco.com> X-Mailer: Apple Mail (2.930.3) X-Scan-Signature: 2c238adc2661b13b123d68c6db09dced Cc: ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] Few comments for our first discussion today 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, 09 May 2009 03:52:12 -0000 On May 8, 2009, at 3:35 AM, JP Vasseur wrote: >> ] > > The DT will come back to the WG VEYR soon ... so far discussions > have been focussed on syncing up on requirements, look at existing > solutions, ... I asked the DT to go back to the WG for input as soon > as there will be even a first cut of the core protocol. JP, It would be more useful and productive to start a discussion on design considerations before presenting a protocol design to the larger WG. Consensus is more important for design priorities than technical details. While priorities are judgements that call for consensus, technical designs can be quantitatively evaluated through running code. Tim commented that the DT is going through the application IDs to derive the MUSTs and SHOULDs, distilling them to a set of core requirements and optional ones for extensions. This has always been the stated first work item of the WG after rechartering, and so it makes a much more logical synchronization point. Phil From jvasseur@cisco.com Sun May 10 04:14: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 024393A6A4F for ; Sun, 10 May 2009 04:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.23 X-Spam-Level: X-Spam-Status: No, score=-10.23 tagged_above=-999 required=5 tests=[AWL=0.369, 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 5jmcIJDMlpl3 for ; Sun, 10 May 2009 04:14: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 37F103A6983 for ; Sun, 10 May 2009 04:14:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,323,1238976000"; d="scan'208";a="40204625" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 10 May 2009 11:16:11 +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 n4ABGBSI030633; Sun, 10 May 2009 13:16:11 +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 n4ABGAhE022217; Sun, 10 May 2009 11:16:10 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); Sun, 10 May 2009 13:16:10 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 May 2009 13:16:10 +0200 Message-Id: <260300FD-E795-44BD-8EA4-0707DC8165E4@cisco.com> From: JP Vasseur To: Philip Levis In-Reply-To: <89B77F58-BDF0-4ECC-A792-349096465991@cs.stanford.edu> 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: Sun, 10 May 2009 13:16:09 +0200 References: <842549E6-6773-4441-8EB1-29D669FF0785@cisco.com> <4A0335A2.60308@gmail.com> <03960C5B-8DB5-427C-B77E-4AC1C357678D@cisco.com> <89B77F58-BDF0-4ECC-A792-349096465991@cs.stanford.edu> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 10 May 2009 11:16:10.0713 (UTC) FILETIME=[B8F88490:01C9D160] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1346; t=1241954171; x=1242818171; 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]=20Few=20comments=20for=20our=20f irst=20discussion=20today |Sender:=20; bh=ArOlGzM69vRUDfWHKSQYNYHXPp3akauRzaeFbAxBTcA=; b=voMI7LFsW/341KcvRnLU23xvdB/T/UdYQm6cAP8rng6FDEtz6S7mTX6INL 1BeYXvqettcWZmmmfh7Y+0ogn3fzjwU8efRDoFSNMti5OkafxnRwGh82RGlK k3vd78G4K6; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] Few comments for our first discussion today 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, 10 May 2009 11:14:44 -0000 On May 8, 2009, at 10:59 PM, Philip Levis wrote: > > On May 8, 2009, at 3:35 AM, JP Vasseur wrote: > >>> ] >> >> The DT will come back to the WG VEYR soon ... so far discussions >> have been focussed on syncing up on requirements, look at existing >> solutions, ... I asked the DT to go back to the WG for input as >> soon as there will be even a first cut of the core protocol. > > JP, > > It would be more useful and productive to start a discussion on > design considerations before presenting a protocol design to the > larger WG. Consensus is more important for design priorities than > technical details. While priorities are judgements that call for > consensus, technical designs can be quantitatively evaluated through > running code. You are absolutely right and this is what I meant by "core protocol". > > Tim commented that the DT is going through the application IDs to > derive the MUSTs and SHOULDs, distilling them to a set of core > requirements and optional ones for extensions. This has always been > the stated first work item of the WG after rechartering, and so it > makes a much more logical synchronization point. Yes note that there is nothing new here, just a review of the MUST. The DT will go back to the list very soon. Thanks. JP. > > Phil From jvasseur@cisco.com Mon May 11 01:07: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 66DE83A695B for ; Mon, 11 May 2009 01:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.234 X-Spam-Level: X-Spam-Status: No, score=-8.234 tagged_above=-999 required=5 tests=[AWL=-1.635, 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 L9yRW-ZmMpZb for ; Mon, 11 May 2009 01:07:08 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 772C128C0E2 for ; Mon, 11 May 2009 01:07:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,327,1238976000"; d="scan'208";a="35231391" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-4.cisco.com with ESMTP; 11 May 2009 08:08:37 +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 n4B88aGd004140 for ; Mon, 11 May 2009 10:08:36 +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 n4B88abs020440 for ; Mon, 11 May 2009 08:08:36 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, 11 May 2009 10:08:36 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 May 2009 10:08:36 +0200 Message-Id: <6EF466DD-9EF5-48CC-A9FA-18EC61589995@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 11 May 2009 10:08:35 +0200 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 11 May 2009 08:08:36.0217 (UTC) FILETIME=[AF2E7690:01C9D20F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=194; t=1242029316; x=1242893316; 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:=20ROL=20IETF-74=20Minutes=20posted |Sender:=20; bh=0atp3qH+CiQYJOy9OfxJgVkp4XMpxSJI9zOUNmFhLRo=; b=roAABHNl3xX6c9kOrXliJYsZeFWjiZKVlWH8+z0LpT0QAheCpMyIgLLUFP BGUh8W07WZZ6x0W2vL1rsZ+tKXA6B/5pzawy94naniZtekyIzPLqEynVj+GH XwLzNFbyVL; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Roll] ROL IETF-74 Minutes posted 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, 11 May 2009 08:07:09 -0000 Dear all, Minutes of the ROLL WG Meeting IETF-74 have been posted: http://www.ietf.org/proceedings/09mar/minutes/roll.txt Let us know if you have any comment by May 18. Thanks. JP. From alexandru.petrescu@gmail.com Mon May 11 01:31: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 ACB193A6BF1 for ; Mon, 11 May 2009 01:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.229 X-Spam-Level: X-Spam-Status: No, score=-1.229 tagged_above=-999 required=5 tests=[AWL=-0.839, 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 hIP3Xoo2F69F for ; Mon, 11 May 2009 01:31:31 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 89DED3A68C5 for ; Mon, 11 May 2009 01:31:31 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n4B8NHR6030712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 May 2009 10:23:17 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n4B8NHLb011656; Mon, 11 May 2009 10:23:17 +0200 (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 n4B8NG0X003524; Mon, 11 May 2009 10:23:17 +0200 Message-ID: <4A07E074.7060106@gmail.com> Date: Mon, 11 May 2009 10:23:16 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: JP Vasseur References: <842549E6-6773-4441-8EB1-29D669FF0785@cisco.com> <4A0335A2.60308@gmail.com> <03960C5B-8DB5-427C-B77E-4AC1C357678D@cisco.com> In-Reply-To: <03960C5B-8DB5-427C-B77E-4AC1C357678D@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] Few comments for our first discussion today 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, 11 May 2009 08:31:32 -0000 JP Vasseur a écrit : > > On May 7, 2009, at 9:25 PM, Alexandru Petrescu wrote: > >> Philip Levis a écrit : >>> On May 7, 2009, at 10:02 AM, JP Vasseur wrote: >>>> Hi Phil, >>>> >>>> On May 7, 2009, at 6:48 PM, Philip Levis wrote: >>>> >>>>> >>>>> On Apr 16, 2009, at 6:31 AM, JP Vasseur wrote: >>>>> >>>>>> Dear all, >>>>>> >>>>>> First many thanks again for accepting to be part of the DT. I did >>>>>> not want to comment on the various individual submissions so far >>>>>> since it was much more appropriate to provide feed-back to the DT, >>>>>> especially because the authors of these drafts are part of the DT. >>>>>> >>>>>> Please find below some comments (that apply to the IDs already >>>>>> posted): >>>>> >>>>> Have there been any subsequent DT discussions? I can't seem to find >>>>> any follow-up reports to the WG. >>>>> >>>> >>>> Yes the DT has been working hard and should very soon be ready to >>>> provide some comments, ask for feed-back/advise from the WG, .. the >>>> goal is to have a first ID (very first draft) within 2 weeks or so >>>> to start some discussion. >>> Going from a restatement of general design considerations to a >>> concrete design in a draft doesn't provide a lot of visibility into >>> the process. While I think it would be counter-productive for the WG >>> to question every intermediate state of the DT's design, having some >>> understanding of the process and considerations made would be >>> helpful. Otherwise, I fear that reception of the first ID will end up >>> with a long discussion of assumptions rather than technical details, >>> which will ultimately lead to an inferior design. >> >> I agree in the sense there is need for more visibility to the DT >> activities - are there public archives of the ongoing DT email >> discussions? > > The DT will come back to the WG VEYR soon ... so far discussions have > been focussed on syncing up on requirements, look at existing solutions, > ... I asked the DT to go back to the WG for input as soon as there will > be even a first cut of the core protocol. > >> >> I'm working on an energy metric for IPv6 links... how would this fit >> in the eventual ROLL protocol? For example, does the ROLL protocol >> take _any_ metric into account? The IP distance (number of hops)? >> Any other metric? >> >> I'm interested in the current DT thinking about the metrics, at least. > > There is a document discussing metrics that has been adopted as WG > (should be published soon). Expected new revision in 2 weeks: could you > comment on it ? I have commented earlier on it, about the necessity an energy for link metric... I will wait for the next revision. Alex > > Thanks. > > JP. > >> >> Alex >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > From jvasseur@cisco.com Mon May 11 02:08: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 52A743A6F35 for ; Mon, 11 May 2009 02:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.216 X-Spam-Level: X-Spam-Status: No, score=-8.216 tagged_above=-999 required=5 tests=[AWL=-1.617, 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 LNuIWFudH0eN for ; Mon, 11 May 2009 02:08:22 -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 345FE3A6C71 for ; Mon, 11 May 2009 02:08:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,327,1238976000"; d="scan'208";a="163957091" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-2.cisco.com with ESMTP; 11 May 2009 09:09:50 +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 n4B99oiF027931; Mon, 11 May 2009 11:09:50 +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 n4B99ofT017583; Mon, 11 May 2009 09:09:50 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, 11 May 2009 11:09:50 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 May 2009 11:09:49 +0200 Message-Id: <58914385-3289-4458-952E-27DABF0C71AF@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4A07E074.7060106@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: Mon, 11 May 2009 11:09:48 +0200 References: <842549E6-6773-4441-8EB1-29D669FF0785@cisco.com> <4A0335A2.60308@gmail.com> <03960C5B-8DB5-427C-B77E-4AC1C357678D@cisco.com> <4A07E074.7060106@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 11 May 2009 09:09:49.0698 (UTC) FILETIME=[3CBF2E20:01C9D218] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3294; t=1242032990; x=1242896990; 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]=20Few=20comments=20for=20our=20f irst=20discussion=20today |Sender:=20; bh=A9kZ4H5fgJxZwuHld2CwtQ5rvTQxGb4BfP+Shf5nkw4=; b=IkJTX4nj7oc4mcSwymxVWVp+lJLr6BavlNTKSLlID9sp+cL/ghSZ9bgJVC KOptXboKzuz8jQmpkUDlp3Ucexvz60ldrIots7D9IYV2UUkabXS2nWmiIano sMqYqrvBOS; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] Few comments for our first discussion today 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, 11 May 2009 09:08:23 -0000 On May 11, 2009, at 10:23 AM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> On May 7, 2009, at 9:25 PM, Alexandru Petrescu wrote: >>> Philip Levis a =E9crit : >>>> On May 7, 2009, at 10:02 AM, JP Vasseur wrote: >>>>> Hi Phil, >>>>> >>>>> On May 7, 2009, at 6:48 PM, Philip Levis wrote: >>>>> >>>>>> >>>>>> On Apr 16, 2009, at 6:31 AM, JP Vasseur wrote: >>>>>> >>>>>>> Dear all, >>>>>>> >>>>>>> First many thanks again for accepting to be part of the DT. I =20= >>>>>>> did not want to comment on the various individual submissions =20= >>>>>>> so far since it was much more appropriate to provide feed-back =20= >>>>>>> to the DT, especially because the authors of these drafts are =20= >>>>>>> part of the DT. >>>>>>> >>>>>>> Please find below some comments (that apply to the IDs already =20= >>>>>>> posted): >>>>>> >>>>>> Have there been any subsequent DT discussions? I can't seem to =20= >>>>>> find any follow-up reports to the WG. >>>>>> >>>>> >>>>> Yes the DT has been working hard and should very soon be ready =20 >>>>> to provide some comments, ask for feed-back/advise from the =20 >>>>> WG, .. the goal is to have a first ID (very first draft) within =20= >>>>> 2 weeks or so to start some discussion. >>>> Going from a restatement of general design considerations to a =20 >>>> concrete design in a draft doesn't provide a lot of visibility =20 >>>> into the process. While I think it would be counter-productive =20 >>>> for the WG to question every intermediate state of the DT's =20 >>>> design, having some understanding of the process and =20 >>>> considerations made would be helpful. Otherwise, I fear that =20 >>>> reception of the first ID will end up with a long discussion of =20 >>>> assumptions rather than technical details, which will ultimately =20= >>>> lead to an inferior design. >>> >>> I agree in the sense there is need for more visibility to the DT =20 >>> activities - are there public archives of the ongoing DT email =20 >>> discussions? >> The DT will come back to the WG VEYR soon ... so far discussions =20 >> have been focussed on syncing up on requirements, look at existing =20= >> solutions, ... I asked the DT to go back to the WG for input as =20 >> soon as there will be even a first cut of the core protocol. >>> >>> I'm working on an energy metric for IPv6 links... how would this =20 >>> fit in the eventual ROLL protocol? For example, does the ROLL =20 >>> protocol take _any_ metric into account? The IP distance (number =20= >>> of hops)? Any other metric? >>> >>> I'm interested in the current DT thinking about the metrics, at =20 >>> least. >> There is a document discussing metrics that has been adopted as WG =20= >> (should be published soon). Expected new revision in 2 weeks: could =20= >> you comment on it ? > > I have commented earlier on it, about the necessity an energy for =20 > link metric... yes this has been day 1 part of the METRIC ID. > > I will wait for the next revision. > Excellent, thanks. JP. > Alex > >> Thanks. >> JP. >>> >>> Alex >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll > > From alexandru.petrescu@gmail.com Mon May 11 03:02: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 3A7993A6A1D for ; Mon, 11 May 2009 03:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.098, 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 RNuj685Mr7tW for ; Mon, 11 May 2009 03:02:16 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 253AC3A67DD for ; Mon, 11 May 2009 03:02:15 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n4B9s2t5014711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 May 2009 11:54:02 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n4B9s2wY009697; Mon, 11 May 2009 11:54:02 +0200 (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 n4B9s2qQ004385; Mon, 11 May 2009 11:54:02 +0200 Message-ID: <4A07F5BA.2050909@gmail.com> Date: Mon, 11 May 2009 11:54:02 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: JP Vasseur References: <842549E6-6773-4441-8EB1-29D669FF0785@cisco.com> <4A0335A2.60308@gmail.com> <03960C5B-8DB5-427C-B77E-4AC1C357678D@cisco.com> <4A07E074.7060106@gmail.com> <58914385-3289-4458-952E-27DABF0C71AF@cisco.com> In-Reply-To: <58914385-3289-4458-952E-27DABF0C71AF@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] Few comments for our first discussion today 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, 11 May 2009 10:02:17 -0000 JP Vasseur a écrit : > > On May 11, 2009, at 10:23 AM, Alexandru Petrescu wrote: > >> JP Vasseur a écrit : >>> On May 7, 2009, at 9:25 PM, Alexandru Petrescu wrote: >>>> Philip Levis a écrit : >>>>> On May 7, 2009, at 10:02 AM, JP Vasseur wrote: >>>>>> Hi Phil, >>>>>> >>>>>> On May 7, 2009, at 6:48 PM, Philip Levis wrote: >>>>>> >>>>>>> >>>>>>> On Apr 16, 2009, at 6:31 AM, JP Vasseur wrote: >>>>>>> >>>>>>>> Dear all, >>>>>>>> >>>>>>>> First many thanks again for accepting to be part of the DT. I >>>>>>>> did not want to comment on the various individual submissions so >>>>>>>> far since it was much more appropriate to provide feed-back to >>>>>>>> the DT, especially because the authors of these drafts are part >>>>>>>> of the DT. >>>>>>>> >>>>>>>> Please find below some comments (that apply to the IDs already >>>>>>>> posted): >>>>>>> >>>>>>> Have there been any subsequent DT discussions? I can't seem to >>>>>>> find any follow-up reports to the WG. >>>>>>> >>>>>> >>>>>> Yes the DT has been working hard and should very soon be ready to >>>>>> provide some comments, ask for feed-back/advise from the WG, .. >>>>>> the goal is to have a first ID (very first draft) within 2 weeks >>>>>> or so to start some discussion. >>>>> Going from a restatement of general design considerations to a >>>>> concrete design in a draft doesn't provide a lot of visibility into >>>>> the process. While I think it would be counter-productive for the >>>>> WG to question every intermediate state of the DT's design, having >>>>> some understanding of the process and considerations made would be >>>>> helpful. Otherwise, I fear that reception of the first ID will end >>>>> up with a long discussion of assumptions rather than technical >>>>> details, which will ultimately lead to an inferior design. >>>> >>>> I agree in the sense there is need for more visibility to the DT >>>> activities - are there public archives of the ongoing DT email >>>> discussions? >>> The DT will come back to the WG VEYR soon ... so far discussions have >>> been focussed on syncing up on requirements, look at existing >>> solutions, ... I asked the DT to go back to the WG for input as soon >>> as there will be even a first cut of the core protocol. >>>> >>>> I'm working on an energy metric for IPv6 links... how would this fit >>>> in the eventual ROLL protocol? For example, does the ROLL protocol >>>> take _any_ metric into account? The IP distance (number of hops)? >>>> Any other metric? >>>> >>>> I'm interested in the current DT thinking about the metrics, at least. >>> There is a document discussing metrics that has been adopted as WG >>> (should be published soon). Expected new revision in 2 weeks: could >>> you comment on it ? >> >> I have commented earlier on it, about the necessity an energy for link >> metric... > > yes this has been day 1 part of the METRIC ID. But it doesn't seem to be in the draft(?) Alex From root@core3.amsl.com Mon May 11 05: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 D21B33A6AE2; Mon, 11 May 2009 05: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: <20090511121501.D21B33A6AE2@core3.amsl.com> Date: Mon, 11 May 2009 05:15:01 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-routing-metrics-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, 11 May 2009 12: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 : Routing Metrics used for Path Calculation in Low Power and Lossy Networks Author(s) : J. Vasseur, D. Networks Filename : draft-ietf-roll-routing-metrics-00.txt Pages : 12 Date : 2009-04-29 This document specifies routing metrics to be used in path calculation for Routing Over Low power and Lossy networks (ROLL). Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired networks or even with similar ones such as mobile ad-hoc networks. By contrast with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link attributes, this document specifies a set of routing metrics suitable to LLNs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-00.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-routing-metrics-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-11050718.I-D@ietf.org> --NextPart-- From alexandru.petrescu@gmail.com Wed May 13 05:50:16 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 921F63A6B8E for ; Wed, 13 May 2009 05:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.947 X-Spam-Level: X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[AWL=-1.112, BAYES_40=-0.185, 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 cMsQh9LXOCbz for ; Wed, 13 May 2009 05:50:15 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 7C7273A6DB0 for ; Wed, 13 May 2009 05:50:15 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n4DCpimu010371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 May 2009 14:51:44 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n4DCpie3001098; Wed, 13 May 2009 14:51:44 +0200 (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 n4DCphWq012041; Wed, 13 May 2009 14:51:44 +0200 Message-ID: <4A0AC25F.2060902@gmail.com> Date: Wed, 13 May 2009 14:51:43 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Miguel Sanchez References: <86c3ed7b0810300129w5ea1e843m4610566427245811@mail.gmail.com> <86c3ed7b0810310119y6c035b6en84f7ed9e9a2f1b6f@mail.gmail.com> In-Reply-To: <86c3ed7b0810310119y6c035b6en84f7ed9e9a2f1b6f@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed 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, 13 May 2009 12:50:16 -0000 REviving older discussions... Miguel Sanchez a écrit Octobre 2009: > Hi Mijeom, > > 2008/10/31 김미ì [USN연구담당] : >> >> Hi, Miguel, >> >> As I pointed out in my early posting, "Propagation delay" is just >> time a packet to traverse a link. So it doesn't include >> transmission time. On the > > Ok, I see, from the current wording I was not sure whether > transmission time was included or not. > >> other hand, node latency comprises transmission time, packet >> processing time and queuing delay in section 4.4. In section 5.3, >> path latency = propagation delay of all links + node latency of all >> nodes along the path. Since propagation delay is negligible as >> Philip wrote and it's hard to get its value, we might exclude the >> propagation delay from routing metrics. Need more opinions. >> >> Regarding the energy metric, I believe that there is a trade-off >> between multi-threshold approaches and using numerical values. But, >> for practical solutions, we might need to compromise precision by >> choosing multi-threshold mechanisms. > > The number of bits used for encoding energy information seems like an > implementation issue to me. YEs, and here we talk implementation. I propose to use 32bit single-precision floating point numbers, in network-byte order, as Joules. This number is the Energy needed to send a packet. What do you think? Alex From alexandru.petrescu@gmail.com Wed May 13 05:53:16 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 E38843A6782 for ; Wed, 13 May 2009 05:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[AWL=-0.640, BAYES_05=-1.11, 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 4BZyeicGjG0T for ; Wed, 13 May 2009 05:53:16 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id BA9C13A65A5 for ; Wed, 13 May 2009 05:53:15 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n4DCsiam015549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 May 2009 14:54:44 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n4DCsiOR002079; Wed, 13 May 2009 14:54:44 +0200 (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 n4DCshhT013293; Wed, 13 May 2009 14:54:44 +0200 Message-ID: <4A0AC313.5000709@gmail.com> Date: Wed, 13 May 2009 14:54:43 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC0683DF47@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0683DF47@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed 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, 13 May 2009 12:53:17 -0000 Pascal Thubert (pthubert) a écrit : > Hi: > > My few cents: > > This doc is intended for standard track. As such we should be very > careful with what we actually specify. What I think we should be > specifying is what the metrics are, what they mean, and if possible > an interoperable format for reporting them. How they can be used by a > routing protocol could depend on the routing protocol and I expect > only guideline, not real specification. I disagree. I expect real specification. Something saying how is the energy encoded, at least. Alex > > What they mean: -------------- > > Be very crisp. What do we count in transmission time, throughput > etc... Maybe we need to model a typical radio operation and discuss > what is accounted in which metric. > > For instance, we are using radios, time spent on CCA counts and the > outgoing queueing delay (waiting for the channel to be free) is a > good metric on link utilization and capability to add / reserve new > traffic. The recent experience in backoff/retries counts. > > If we are using slotted radios (TDM) then the actual time to access > the outgoing channel counts. The latency inside the device translates > immediately in buffer space that the device will typically lacks. > > How they can be used -------------------- > > Section 4 and 5 also are really informative. I expect recommendations > in chapter 6 but fail to see why we are using uppercase > MUST/SHOULD/RECOMMEND terms there; then again this is mostly > informative. > > I'd really wish to find some discussions on things like how can a > link state protocol manipulate statistical metrics, describing > mechanisms such as hysteresis (pro/con), triggered/piggy-backed > updates (pro/con) etc... Is that out of scope? > > Interoperable formats and operations > ------------------------------------ > > This might be when we really need a standard track as opposed to > informative. > > Knowing that a metric exists and what it is is a great step. > Providing a interoperable format to exchange it and detailing the > aggregation operation is needed as well if we want to standardize > anything. We are used to metrics where the representation is a flat > number, and the aggregation as simple as the weakest link or the sum > over the path. > > But for the data that we are contemplating here things can rapidly > get more complex. For instance, for metrics that have a statistical > aspect, I trust that we need to exchange information such mean, mode > or expected range (+/- X percent) so that we do not need to update as > long as we stay within range, that type of thing. > > One advantage of doing that in a separate spec as opposed to each > specific routing protocol is to enable redistributing metrics between > 2 different routing protocols that would understand this spec but are > designed differently for different parts of the network (eg backbone > vs. fringe). > > Then again is that out of scope? > > Pascal > >> -----Original Message----- From: roll-bounces@ietf.org >> [mailto:roll-bounces@ietf.org] On Behalf Of Miguel Sanchez Sent: >> mercredi 29 octobre 2008 11:59 To: ROLL WG Subject: Re: [Roll] ROLL >> Routing Metrics - WF feed-back needed >> >>> So we would need your feed-back, bearing in mind that we may want >>> to only keep the metrics that are >> critical to LLNs. Not sure what is the best way but being able to >> use remaining-energy as a parameter for routing decisions maybe >> useful (if routing contemplates that). Remaining node energy may be >> added to other metrics (delay, traffic, PER, etc). >> >> Cheers, >> >> Miguel Sánchez Universidad Politécnica de Valencia, Spain >> _______________________________________________ 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 Wed May 13 05: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 F194B3A6B8E for ; Wed, 13 May 2009 05:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.110, 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 kQVNiW0uV2je for ; Wed, 13 May 2009 05:53:57 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 6ADE53A65A5 for ; Wed, 13 May 2009 05:53:57 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n4DCo5J1008788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 May 2009 14:50:05 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n4DCo4re000671; Wed, 13 May 2009 14:50:04 +0200 (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 n4DCo4K6011496; Wed, 13 May 2009 14:50:04 +0200 Message-ID: <4A0AC1FC.1070705@gmail.com> Date: Wed, 13 May 2009 14:50:04 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Miguel Sanchez References: <86c3ed7b0810300129w5ea1e843m4610566427245811@mail.gmail.com> <86c3ed7b0810300356s1e916d53ye3f3d93cc493838f@mail.gmail.com> In-Reply-To: <86c3ed7b0810300356s1e916d53ye3f3d93cc493838f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed 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, 13 May 2009 12:53:59 -0000 Miguel Sanchez a écrit : > Hi JP, > > On Thu, Oct 30, 2008 at 10:02 AM, JP Vasseur wrote: >> Hi Miguel, >> >> >> On 10/30/08 9:29 AM, "Miguel Sanchez" wrote: >> >>> I've got a terminology problem with "propagation delay" (5.3), while >>> defined in the draft (and later defined is path propagation) a new >>> meaning is given to the term. (For short range communications >>> transmission time could be used instead). >> Let me make sure that I get your point here. The document says: >> "Propagation delay is the time taken for the packet to traverse the >> link from the source node to the target node." > > Definition is clear enough but what bothers me is that "propagation > delay" equals link length over propagation speed in my book. > Apparently the meaning here is more like transmission time + > propagation delay (the latter as I've defined here). >> I think that the notion of source and target node is confusing and the text >> should read: >> >> " Propagation delay is the time taken for the packet to traverse the >> link. " > > Do you mean including the transmission time? > >> Does that clarify ? >> >>> Regarding the energy metric I can see a problem if only one value is >>> given (ie: remaining enery). The value might be infinite to signal >>> nodes without energy restrictions, but for the remaining nodes, a >>> single value may not be enough. Let me elaborate on this with an >>> example: A node may have an overall lower consumption than another >>> one. If the former has slightly less energy than the second one, then >>> choosing the later may not be the best choice for long term >>> survivability of the network (this could be addressed by advertising >>> expected node lifetime instead of node's remaining energy). >>> >> Absolutely. The remaining energy metric may be difficult to interpret and >> the expected lifetime may be hard to compute. >> >>> On the other hand, without knowing the initial energy, it's not >>> possible to know what fraction of the original energy is the remaining >>> one. This could be addressesed advertising remaining energy as a >>> percentage (contrary to the above paragraph approach). >> Yes or ... We may use a simple multi-threshold mechanisms: "Low, Medium, >> High" where: >> "LOW: avoid this node if possible" >> "Medium: no particular constraint" >> "HIGH: favor this node" >> >> Avoid/favor should of course be interpreted in the context of energy. >> >> What do you think ? > I think the high/medium/low approach may hurt some implementations > over a numerical value (i.e: choosing between two nodes with high > value). >> But ... In any case, we need to avoid the definition of metric that are >> implementation/node dependent. The way you model energy cannot be >> standardized. > > We've to find a way to create an standard way for energy reporting. Haven't we? YEs we have to. Alex > >> We also need to ensure that nodes use consistent metrics (a fairly common >> problem). >> >>> And last, in certain network setups some nodes may be easy to replace >>> while others are not. You may want batteries to die out more often on >>> nodes that can have their batteries replaced easily even though other >>> nearby nodes have more energy available. >> Absolutely, as defined in the industrial routing requirement document. This >> should be an administrative constraint. >> >> Energy metric need to be >>> complemented with other metrics. (Network survivability is not the >>> only factor we have to take into account). >> Right. Did you have a look at the other ones ? > I mostly agree with the rest, perhaps I'd chose PER (packet error > rate) metric instead of BER. > > Regards, > > Miguel Sánchez > >> Thanks. >> >> JP. >> >>> Regards, >>> >>> Miguel Sánchez >>> >>> >>> On Thu, Oct 30, 2008 at 8:55 AM, JP Vasseur wrote: >>>> Good, feel free to comment on other metrics, we need to make a careful >>>> decision on which one we keep, remove, add, ... >>>> >>>> Thanks for the comments. >>>> >>>> JP. >>>> >>>> >>>> On 10/30/08 8:43 AM, "Mischa Dohler" wrote: >>>> >>>>> Hola Miguel, JP, all, >>>>> >>>>> They are all already either implicitly or explicitly part of the specs. If >>>>> we start thinking however which one to explicitly include and which to >>>>> exclude, remaining energy is definitely a vital metric. >>>>> >>>>> Mischa. >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP >>>>> Vasseur >>>>> Sent: Thursday, October 30, 2008 8:30 AM >>>>> To: Stan Ratliff (sratliff); Miguel Sanchez; ROLL WG >>>>> Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed >>>>> >>>>> Hi, >>>>> >>>>> >>>>> On 10/29/08 2:54 PM, "Stan Ratliff (sratliff)" wrote: >>>>> >>>>>> I absolutely agree with using remaining-energy. Would also >>>>>> suggest bandwidth on the link (current and maximum), BER, >>>>>> and latency. >>>>> All currently defined also. >>>>> >>>>> Still I think that we need to think a bit more about this. I personally >>>>> question whether we need these metrics or not. Designing a routing protocols >>>>> with so many dynamic metric is not trivial. >>>>> >>>>> For the sake of illustration propagation delay may greatly vary if queueing >>>>> delays are taken into account. So does the bandwidth. >>>>> >>>>> Thus we do need to make sure that we do not end up with a wide set of >>>>> dynamic metrics that will unavoidably lead to routing instabilities. >>>>> >>>>> Other comments from the WG ? >>>>> >>>>> Thanks. >>>>> >>>>> JP. >>>>> >>>>>> Regards, >>>>>> Stan >>>>>> >>>>>> -----Original Message----- >>>>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >>>>> Miguel >>>>>> Sanchez >>>>>> Sent: Wednesday, October 29, 2008 6:59 AM >>>>>> To: ROLL WG >>>>>> Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed >>>>>> >>>>>>> So we would need your feed-back, bearing in mind that we may want to only >>>>>>> keep the metrics that are critical to LLNs. >>>>>>> >>>>>> Not sure what is the best way but being able to use remaining-energy >>>>>> as a parameter for routing decisions maybe useful (if routing >>>>>> contemplates that). Remaining node energy may be added to other >>>>>> metrics (delay, traffic, PER, etc). >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Miguel Sánchez >>>>>> Universidad Politécnica de Valencia, Spain >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> _______________________________________________ >>>> 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 Wed May 13 05:56: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 025AE3A6B43 for ; Wed, 13 May 2009 05:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[AWL=-0.636, BAYES_05=-1.11, 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 SmgVEd+RWlw8 for ; Wed, 13 May 2009 05:56:43 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 2FD3D28C1C7 for ; Wed, 13 May 2009 05:55:54 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n4DCt4xa002450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 May 2009 14:55:05 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n4DCvE7h003320; Wed, 13 May 2009 14:57:14 +0200 (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 n4DCvDI9014676; Wed, 13 May 2009 14:57:13 +0200 Message-ID: <4A0AC3A9.2070603@gmail.com> Date: Wed, 13 May 2009 14:57:13 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) 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 Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed 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, 13 May 2009 12:56:44 -0000 JP Vasseur a écrit : > Hi, > > > On 11/10/08 11:52 PM, "Kris Pister" wrote: > >> Phil - I agree that the optimal routes are going to be a function of the >> state of all of the nodes along each route, not just one node >> advertising that it's fat and happy. > > Right. Bear in mind that we are discussing node metric. Path characteristics > are locally derived by the computing node ! DEpends whether we consider a path to be the set of links or the set of the nodes. I personally prefer it to be the set of links. And associate a metric to a link, not to a node. Alex > >> I don't think that I agree that we're assuming that a node must >> communicate a lot of factors to other nodes. I can imagine something >> like AODV, but where each node adds its own hop cost. Depending on >> shared network parameters, each node might add e.g. 1/(remaining >> lifetime) to the total route cost, or it might add it's link-latency to >> the route cost. I'm not advocating something AODV-like, just pointing >> out that we don't necessarily need to be propagating a lot of state >> information around the network, and potentially complicated (and >> platform dependent) local computations can still be done without the >> global algorithm needing to know the details. > > Absolutely. > > JP. > >> ksjp >> >> Philip Levis wrote: >>> On Nov 10, 2008, at 7:55 AM, Anders Brandt wrote: >>> >>>> Jerry touches a point I forgot to mention in relation to Kris' >>>> previous postings. >>>> >>>> I fully support the idea of preferred routers running on battery. >>>> We definitely also see this application in the home control domain. >>>> >>>>> ...let's say I have a battery powered repeater installed in a >>>> sparse portion of the mesh. This device has no other meaning in >>>>> life but to route messages. Rerouting around this device saves the >>>> energy on a device that has no reason to save energy. >>>>> Also, remember this repeater was strategically placed to 'fill-in' >>>> the mesh. >>>> >>>> In order to attract interest from the routing protocol, such a node >>>> should be able to signal "mains powered" or even better: >>>> "I have plenty of battery". >>>> Obviously, it should lower that indication to normal >>>> "battery-powered" if running close to low; ending with "battery low". >>>> br. Anders >>>> >>>> >>>> >>> I'm confused by this line of logic. Whether a node advertises itself >>> as having lots of energy is less important than the available energy >>> along a route. I.e., if the next hop, node A, has lots of energy but >>> its next hop, node B, is very limited, the fact that A has lots of >>> energy is not particularly useful. >>> >>> So far, this discussion has assumed that a node must communicate a lot >>> of factors to other nodes, so they can apply their own algorithms to >>> decide which next hop to take. The issue here is that it assumes the >>> optimization criteria are the same; even though the router-to-be wants >>> to save energy, the sender wants to optimize latency and so ignores >>> energy constraints. Another approach is that each node applies its own >>> algorithm to determine its willingness/cost, which other nodes then >>> take into account. That is, nodes advertise how good a router they >>> think they are, and senders take this into consideration. Otherwise, >>> especially in a distributed and dynamic system, senders can be making >>> decisions based on out-of-date information which is hard to detect >>> inconsistencies on without expensive periodic state exchanges. >>> >>> E.g., one simple way to articulate energy, rather than "I have X" is >>> "How expensive I consider sending a packet." This takes into >>> consideration a lot more useful information, and is much more flexible >>> to compute and consider. >>> >>> Phil >> _______________________________________________ >> 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 Wed May 13 05:57: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 2E9AE3A67B1 for ; Wed, 13 May 2009 05:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.114, 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 quvYCykvwvet for ; Wed, 13 May 2009 05:57:33 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id B3E113A6A4F for ; Wed, 13 May 2009 05:57:32 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n4DCnkYI005475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 May 2009 14:49:46 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n4DCnkxi000595; Wed, 13 May 2009 14:49:46 +0200 (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 n4DCnjWE011402; Wed, 13 May 2009 14:49:46 +0200 Message-ID: <4A0AC1E9.40802@gmail.com> Date: Wed, 13 May 2009 14:49:45 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) 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 Cc: roll@ietf.org Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed 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, 13 May 2009 12:57:34 -0000 JP Vasseur a écrit : > Hi, > > > On 10/30/08 1:31 PM, "Miguel Sanchez" wrote: > >> Hi JP, >> >> On Thu, Oct 30, 2008 at 12:30 PM, JP Vasseur >> wrote: >>> Hi Miguel, >>> >>> >>> On 10/30/08 11:56 AM, "Miguel Sanchez" >>> wrote: >>> >>>> Hi JP, >>>> >>>> On Thu, Oct 30, 2008 at 10:02 AM, JP Vasseur >>>> wrote: >>>>> Hi Miguel, >>>>> >>>>> >>>>> On 10/30/08 9:29 AM, "Miguel Sanchez" >>>>> wrote: >>>>> >>>>>> I've got a terminology problem with "propagation delay" >>>>>> (5.3), while defined in the draft (and later defined is >>>>>> path propagation) a new meaning is given to the term. (For >>>>>> short range communications transmission time could be used >>>>>> instead). >>>>> Let me make sure that I get your point here. The document >>>>> says: "Propagation delay is the time taken for the packet to >>>>> traverse the link from the source node to the target node." >>>> Definition is clear enough but what bothers me is that >>>> "propagation delay" equals link length over propagation speed >>>> in my book. Apparently the meaning here is more like >>>> transmission time + propagation delay (the latter as I've >>>> defined here). >>> Ah I see what you mean, it is w/o transmission delay (just >>> propagation delay). We'll clarify. >> Ok. >> >>>>> I think that the notion of source and target node is >>>>> confusing and the text should read: >>>>> >>>>> " Propagation delay is the time taken for the packet to >>>>> traverse the link. " >>>> Do you mean including the transmission time? >>>> >>>>> Does that clarify ? >>>>> >>>>>> Regarding the energy metric I can see a problem if only one >>>>>> value is given (ie: remaining enery). The value might be >>>>>> infinite to signal nodes without energy restrictions, but >>>>>> for the remaining nodes, a single value may not be enough. >>>>>> Let me elaborate on this with an example: A node may have >>>>>> an overall lower consumption than another one. If the >>>>>> former has slightly less energy than the second one, then >>>>>> choosing the later may not be the best choice for long term >>>>>> survivability of the network (this could be addressed by >>>>>> advertising expected node lifetime instead of node's >>>>>> remaining energy). >>>>>> >>>>> Absolutely. The remaining energy metric may be difficult to >>>>> interpret and the expected lifetime may be hard to compute. >>>>> >>>>>> On the other hand, without knowing the initial energy, it's >>>>>> not possible to know what fraction of the original energy >>>>>> is the remaining one. This could be addressesed advertising >>>>>> remaining energy as a percentage (contrary to the above >>>>>> paragraph approach). >>>>> Yes or ... We may use a simple multi-threshold mechanisms: >>>>> "Low, Medium, High" where: "LOW: avoid this node if possible" >>>>> "Medium: no particular constraint" "HIGH: favor this node" >>>>> >>>>> Avoid/favor should of course be interpreted in the context of >>>>> energy. >>>>> >>>>> What do you think ? >>>> I think the high/medium/low approach may hurt some >>>> implementations over a numerical value (i.e: choosing between >>>> two nodes with high value). >>> But that may be "good" enough ... The issue with a numeric value >>> is that it will be really hard to define a consistent way to >>> compute the value *and* will be hard to use by the computation >>> engine. >>> >>> Agree ? >> Not really. As I see it local computation at a node is used to >> determine the residual energy. Based on that (and may be other >> constraints) node is tagged as high/medium/low. That energy tag is >> used later for routing decisions. Nodes could advertise the source >> data instead, residual energy. Doing that might make routing >> calculations more complex, but not doing it restricts the freedom >> of routing algorithm. >> >> Certainly the numeric value could end up having a few bits and >> effectively becoming 2 or four discrete values (similar to what you >> suggest). > > Looks like you are agreeing with the suggested use of a few discrete > values (flags) used for constrained based routing ? I disagree to use a such a discrete metric, allowing only a few values. The existing metric (IP number of hops) has a much higher resolution, going from 15 vlaues for RIP to OSPF's huge 65535. Alex > >>>>> But ... In any case, we need to avoid the definition of >>>>> metric that are implementation/node dependent. The way you >>>>> model energy cannot be standardized. >>>> We've to find a way to create an standard way for energy >>>> reporting. Haven't we? >>> Heu ... You may want to try ... But certainly not trivial. >> We've agreed on energy reporting. How this is done effectively does >> not seem trivial but it has to be done for protocols to be able to >> use that. >> >> My suggestion here is to report two energy related values: residual >> energy in Joules and the same as a percentage. > > OK let's wait to see what others say. I claim that a few flags are > sufficient you would prefer to define a way to express energy. Let's > try to converge on the list. > >>>>> We also need to ensure that nodes use consistent metrics (a >>>>> fairly common problem). >>>>> >>>>>> And last, in certain network setups some nodes may be easy >>>>>> to replace while others are not. You may want batteries to >>>>>> die out more often on nodes that can have their batteries >>>>>> replaced easily even though other nearby nodes have more >>>>>> energy available. >>>>> Absolutely, as defined in the industrial routing requirement >>>>> document. This should be an administrative constraint. >>>>> >>>>> Energy metric need to be >>>>>> complemented with other metrics. (Network survivability is >>>>>> not the only factor we have to take into account). >>>>> Right. Did you have a look at the other ones ? >>>> I mostly agree with the rest, perhaps I'd chose PER (packet >>>> error rate) metric instead of BER. >>>> >>> One problem though: the PER of a function of packet size and can >>> be computed knowing the BER anyway. >>> >>> Agree ? >> Yes but non trivial (coding, iid errors). PER can be measured >> easily on the nodes (if link layer ACKs are used). That's why I was >> suggesting it. > > Yes. > > Thanks. > > JP. > >> Kind regards, >> >> Miguel > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Wed May 13 05:58: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 627263A6B43 for ; Wed, 13 May 2009 05:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.516 X-Spam-Level: X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 DU4tpmNpRUSP for ; Wed, 13 May 2009 05:58:57 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 43D573A67B6 for ; Wed, 13 May 2009 05:58:57 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n4DCwFPW004575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 May 2009 14:58:15 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n4DD0PuR004385; Wed, 13 May 2009 15:00:25 +0200 (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 n4DD0P1G015721; Wed, 13 May 2009 15:00:25 +0200 Message-ID: <4A0AC469.4090309@gmail.com> Date: Wed, 13 May 2009 15:00:25 +0200 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 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: Wed, 13 May 2009 12:58:58 -0000 Kris Pister a écrit : > 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} This ^ is too poor representation of what is energy, too little resolution, too small range of values. It wouldn't allow for fine grain decision in large networks. Compare it to the IP metric cost which has at least 15 values (RIP). Besides, what does 'SCAVENGER' mean in this context? IS this a manual dynamo or something? Is there an ordering relationship? (UNLIMITED larger than SCAVENGER larger than OK larger than LOW)? It's not obvious... Alex > 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 >> > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Chris.Dearlove@baesystems.com Wed May 13 08:05: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 5DE0C3A68F0 for ; Wed, 13 May 2009 08:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.468 X-Spam-Level: X-Spam-Status: No, score=-4.468 tagged_above=-999 required=5 tests=[AWL=-1.869, 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 9E-sInK27nhe for ; Wed, 13 May 2009 08:05:00 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 6276E3A6909 for ; Wed, 13 May 2009 08:05:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,188,1241391600"; d="scan'208";a="2132544" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 13 May 2009 16:06:23 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n4DF6Na2023126; Wed, 13 May 2009 16:06:23 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 May 2009 16:06:23 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 13 May 2009 16:06:22 +0100 Message-ID: In-Reply-To: <260300FD-E795-44BD-8EA4-0707DC8165E4@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Few comments for our first discussion today Thread-Index: AcnRYL0vyIiCox78QGiHZE8sGyuw0QCe0v9Q References: <842549E6-6773-4441-8EB1-29D669FF0785@cisco.com><4A0335A2.60308@gmail.com><03960C5B-8DB5-427C-B77E-4AC1C357678D@cisco.com><89B77F58-BDF0-4ECC-A792-349096465991@cs.stanford.edu> <260300FD-E795-44BD-8EA4-0707DC8165E4@cisco.com> From: "Dearlove, Christopher (UK)" To: "JP Vasseur" , "Philip Levis" X-OriginalArrivalTime: 13 May 2009 15:06:23.0467 (UTC) FILETIME=[6140C3B0:01C9D3DC] Cc: ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] Few comments for our first discussion today 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, 13 May 2009 15:05:01 -0000 JP Vasseur > Philip Levis >> Tim commented that the DT is going through the application IDs to >> derive the MUSTs and SHOULDs, distilling them to a set of core >> requirements and optional ones for extensions. This has always been >> the stated first work item of the WG after rechartering, and so it >> makes a much more logical synchronization point. > > Yes note that there is nothing new here, just a review of the MUST. As the various documents aren't exactly aligned, even this needs to make some judgements, and it would be useful to see what those are. ******************************************************************** 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 gnawali@gmail.com Wed May 13 09:48: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 442143A69E6 for ; Wed, 13 May 2009 09:48:32 -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 wxXrLdHbH3Tu for ; Wed, 13 May 2009 09:48:31 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id 8958A3A68C8 for ; Wed, 13 May 2009 09:48:31 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so525422wff.31 for ; Wed, 13 May 2009 09:50:01 -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:content-transfer-encoding; bh=kZf62YZ6tQi95g04JuoQVcMHBuxNs8wAb2lDJJDpl0E=; b=ANRNvPEDMYel32YnivrIfSxuneb8TSM4o0UF/ICrHO8UJccwpotyRW889rwk4oVvhG 5UCh5GJtZXxs2deXkzYoGqf1wbGcB5VRyi0UNIf5YLxN1dizb/ORmBuWovmrlj+LEb+i ccMXBOELZmucra2PQGZi1zlQxcsY1rFDRlVWU= 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 :content-transfer-encoding; b=pGwEQFwyme80urNLhRQuVNS8sJlY79ScML+jV20SLTtmuy88zqCLHqTxgkJcwfrHVX e7oZMMuoRaEOMPc7a4rbUHPCwuXoGMGt1b3jqeMrZBKtfZap0G3jSMvx481xvaaqO7L9 BUK3de/9zyzsq5KpuxXyT6p+s56oT1stNPFEM= MIME-Version: 1.0 Sender: gnawali@gmail.com Received: by 10.142.179.2 with SMTP id b2mr382967wff.308.1242233401798; Wed, 13 May 2009 09:50:01 -0700 (PDT) In-Reply-To: <4A0AC469.4090309@gmail.com> References: <49C93116.20102@eecs.berkeley.edu> <86c3ed7b0903241432vf5307a0o506085aea3357e45@mail.gmail.com> <49CAD3AA.7060002@eecs.berkeley.edu> <4A0AC469.4090309@gmail.com> Date: Wed, 13 May 2009 09:50:01 -0700 X-Google-Sender-Auth: fd4f0421e5917014 Message-ID: From: Omprakash Gnawali To: Alexandru Petrescu 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 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 16:48:32 -0000 On Wed, May 13, 2009 at 6:00 AM, Alexandru Petrescu wrote: > Kris Pister a =E9crit : >> >> Miguel - I understand your frustration. =A0There was in fact a 2 bit (an= d I >> mean that in both senses of the phrase) discrete metric in the document: >> {UNLIMITED, SCAVENGER, OK, LOW} > > This ^ is too poor representation of what is energy, too little resolutio= n, > too small range of values. > > It wouldn't allow for fine grain decision in large networks. =A0Compare i= t to > the IP metric cost which has at least 15 values (RIP). > > Besides, what does 'SCAVENGER' mean in this context? =A0IS this a manual > dynamo or something? > > Is there an ordering relationship? (UNLIMITED larger than SCAVENGER large= r > than OK larger than LOW)? =A0It's not obvious... Regarding the energy metric, it would be helpful to know if there are successful routing protocols (little bit more than simulation-only papers) that take energy into account. What does their energy representation look like? What shortcomings do they have that we are trying to improve on here? If there are already lots of non-standard LLNs with proprietary protocols, and if energy is a useful metric, perhaps they already use it? Some context information such as that would help the WG understand if we are trying to standardize what is already done or if we are trying to do new research. - om_p From m1gs4n@gmail.com Wed May 13 10:03:49 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 1DF103A6BA1 for ; Wed, 13 May 2009 10:03:49 -0700 (PDT) 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 ZgC-EzIvAx3p for ; Wed, 13 May 2009 10:03:48 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id A643B3A6941 for ; Wed, 13 May 2009 10:03:47 -0700 (PDT) Received: by fxm2 with SMTP id 2so780145fxm.37 for ; Wed, 13 May 2009 10:05:16 -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=PL95IsHT2DZtcrEZgPmlZH4ntm0cVwrOm60vIirUxOw=; b=xjGRGW07OfGOwov/MbIg/MPSvFzb6dawcx0XwT6rn9kDO/ghogA/ltYBBi8AWolClf 5D7Y26shf7YyAOif2h3M+urr/oHU6HUVldVqRGnrtU8Lv9L18tgJajF6EdWF3TdZ0Shy SQlxSJmXGqAhQZbX9tY0unh+o30As/r9aUD3A= 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=FQs/VEsX3ATq4yKG7bbzxHvA55O0Y8JWHDKI/7fc6s6tdJq6buSLNzB4ojAcWBoBX0 Wg6DbM93zp0r5t8lSiT2FLd5UtuiwhROmwmnHsrR4Jj941x+ercl9sXHVbCso5USqwO3 fj9C49MSGZ7iSrO+86nhFi5Iq/jxRSToYOQAo= MIME-Version: 1.0 Sender: m1gs4n@gmail.com Received: by 10.204.65.65 with SMTP id h1mr1128994bki.18.1242234316063; Wed, 13 May 2009 10:05:16 -0700 (PDT) In-Reply-To: <4A0AC25F.2060902@gmail.com> References: <86c3ed7b0810300129w5ea1e843m4610566427245811@mail.gmail.com> <86c3ed7b0810310119y6c035b6en84f7ed9e9a2f1b6f@mail.gmail.com> <4A0AC25F.2060902@gmail.com> Date: Wed, 13 May 2009 19:05:15 +0200 X-Google-Sender-Auth: aa2920de524cc798 Message-ID: <86c3ed7b0905131005sfba99dy82e390c2dfbc0319@mail.gmail.com> From: Miguel Sanchez To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=001636c5ad4d2304f60469ce371c Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed 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, 13 May 2009 17:03:49 -0000 --001636c5ad4d2304f60469ce371c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, May 13, 2009 at 2:51 PM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > REviving older discussions... > Miguel Sanchez a =C3=A9crit Octobre 2009: > >> Hi Mijeom, >> >> 2008/10/31 =EA=B9=80=EB=AF=B8=EC=A0=90[USN=EC=97=B0=EA=B5=AC=EB=8B=B4=EB= =8B=B9] : >> >>> >>> Hi, Miguel, >>> >>> As I pointed out in my early posting, "Propagation delay" is just >>> time a packet to traverse a link. So it doesn't include >>> transmission time. On the >>> >> >> Ok, I see, from the current wording I was not sure whether transmission >> time was included or not. >> >> other hand, node latency comprises transmission time, packet >>> processing time and queuing delay in section 4.4. In section 5.3, >>> path latency =3D propagation delay of all links + node latency of all >>> nodes along the path. Since propagation delay is negligible as >>> Philip wrote and it's hard to get its value, we might exclude the >>> propagation delay from routing metrics. Need more opinions. >>> >>> Regarding the energy metric, I believe that there is a trade-off >>> between multi-threshold approaches and using numerical values. But, >>> for practical solutions, we might need to compromise precision by >>> choosing multi-threshold mechanisms. >>> >> >> The number of bits used for encoding energy information seems like an >> implementation issue to me. >> > > YEs, and here we talk implementation. > > I propose to use 32bit single-precision floating point numbers, in > network-byte order, as Joules. This number is the Energy needed to send > a packet. > > What do you think? > I'm not entirely happy with floating point numbers if 8-bit micro controllers with not so much program memory (a few KBytes) are involved. However I do like the idea of using Energy units to express Energy values (whether it is Joules or mJ integers are easier). OTOH, the estimate of the battery capacity may come from a combination of usage recording and battery voltage (and maybe current) measurement (which is performed at a limited resolution), so a floating-point energy representation could be a bit overkill here. Just my two cents, Miguel S=C3=A1nchez > Alex > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --001636c5ad4d2304f60469ce371c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, May 13, 2009 at 2:51 PM, Alexandru Petre= scu <a= lexandru.petrescu@gmail.com> wrote:
REviving older discussions...
Miguel Sanchez a =C3=A9crit Octobre 2009:

Hi Mijeom,

2008/10/31 =EA=B9=80=EB=AF=B8=EC=A0=90[USN=EC=97=B0=EA=B5=AC=EB=8B=B4=EB=8B= =B9] <mjkim@kt.com= >:

Hi, Miguel,

As I pointed out in my early posting, "Propagation delay" is just=
time a packet to traverse a link. So it doesn't include
transmission time. On the

Ok, I see, from the current wording I was not sure whether transmission tim= e was included or not.

other hand, node latency comprises transmission time, packet
processing time and queuing delay in section 4.4. In section 5.3,
path latency =3D propagation delay of all links + node latency of all
nodes along the path. Since propagation delay is negligible as
Philip wrote and it's hard to get its value, we might exclude the
propagation delay from routing metrics. Need more opinions.

Regarding the energy metric, I believe that there is a trade-off
between multi-threshold approaches and using numerical values. But,
for practical solutions, we might need to compromise precision by
choosing multi-threshold mechanisms.

The number of bits used for encoding energy information seems like an
=C2=A0implementation issue to me.

YEs, and here we talk implementation.

I propose to use 32bit single-precision floating point numbers, in
network-byte order, as Joules. =C2=A0This number is the Energy needed to se= nd
a packet.

What do you think?

I'm not entirely happy with floating point number= s if 8-bit micro controllers=C2=A0 with not so much program memory (a few K= Bytes) are involved.=C2=A0 However I do like the idea of using Energy units= to express Energy values (whether it is Joules or mJ integers are easier).=

OTOH, the estimate of the battery capacity may come from a combination = of usage recording and battery voltage (and maybe current) measurement (whi= ch is performed at a limited resolution), so a floating-point energy repres= entation could be a bit overkill here.

Just my two cents,

Miguel S=C3=A1nchez




Alex




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

--001636c5ad4d2304f60469ce371c-- From alexandru.petrescu@gmail.com Wed May 13 11:14: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 A9FD23A6E7A for ; Wed, 13 May 2009 11:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.819 X-Spam-Level: X-Spam-Status: No, score=-0.819 tagged_above=-999 required=5 tests=[AWL=-0.984, BAYES_40=-0.185, 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 s65d2RPvM9Ls for ; Wed, 13 May 2009 11:14:02 -0700 (PDT) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by core3.amsl.com (Postfix) with ESMTP id 92D773A6CB1 for ; Wed, 13 May 2009 11:14:00 -0700 (PDT) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id B37F78181AF; Wed, 13 May 2009 20:15:29 +0200 (CEST) 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 686E981801E; Wed, 13 May 2009 20:15:26 +0200 (CEST) Message-ID: <4A0B0E36.8010400@gmail.com> Date: Wed, 13 May 2009 20:15:18 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Miguel Sanchez References: <86c3ed7b0810300129w5ea1e843m4610566427245811@mail.gmail.com> <86c3ed7b0810310119y6c035b6en84f7ed9e9a2f1b6f@mail.gmail.com> <4A0AC25F.2060902@gmail.com> <86c3ed7b0905131005sfba99dy82e390c2dfbc0319@mail.gmail.com> In-Reply-To: <86c3ed7b0905131005sfba99dy82e390c2dfbc0319@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090512-0, 12/05/2009), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed 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, 13 May 2009 18:14:03 -0000 Miguel Sanchez a écrit : [and some people replied] > >>> The number of bits used for encoding energy information seems like an >>> implementation issue to me. >> >> YEs, and here we talk implementation. >> >> I propose to use 32bit single-precision floating point numbers, in >> network-byte order, as Joules. This number is the Energy needed to >> send a packet. >> >> What do you think? > > > I'm not entirely happy with floating point numbers if 8-bit micro > controllers with not so much program memory (a few KBytes) are > involved. However I do like the idea of using Energy units to > express Energy values (whether it is Joules or mJ integers are > easier). > > OTOH, the estimate of the battery capacity may come from a > combination of usage recording and battery voltage (and maybe > current) measurement (which is performed at a limited resolution), so > a floating-point energy representation could be a bit overkill here. I agree the energy estimation may come from measurement happening straight on the sensor node (in addition to offline measurement performed potentially in the lab, with sophisticated equipment). This may involve measurement of the battery voltage while a packet is sent. Chipsets of PMU (Power Management Unit) do offer this as integers, not floats. Sure some constrained devices don't have PMU but some do have. At a limit, an 8bit controller could perform floating-point comparisons even if it had only 8bit registers, depends how it's programmed. The issue I have with an integer to represent energy is that it has a limited range. For example a 16bit integer may represent it as between 0 and 65535 mili-Volt. And this may correspond linearly to an Energy value between 0 and 65535 qualifier-Joule (qualifier may be micro, nano, mili, etc.) - but it would not allow to represent both a Joule and a micro-Joule. Or, the lowpower wireless links and the e.g. GSM can differ in orders of magnitude. This is of course subject to discussion. Alex > > Just my two cents, > > Miguel Sánchez > > > > > Alex > > > > > _______________________________________________ Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > From mcr@marajade.sandelman.ca Wed May 13 11:21: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 C2D3B3A6FCD for ; Wed, 13 May 2009 11:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.354 X-Spam-Level: X-Spam-Status: No, score=-1.354 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=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 2ICa-za6U7+e for ; Wed, 13 May 2009 11:21:43 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id DEB1928C22C for ; Wed, 13 May 2009 11:21:27 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [206.191.15.98]) by relay.sandelman.ca (Postfix) with ESMTPS id 8AA39341F5 for ; Wed, 13 May 2009 18:23:00 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id F34274E813 for ; Wed, 13 May 2009 14:22:59 -0400 (EDT) From: Michael Richardson To: ROLL WG In-Reply-To: <86c3ed7b0905131005sfba99dy82e390c2dfbc0319@mail.gmail.com> References: <86c3ed7b0810300129w5ea1e843m4610566427245811@mail.gmail.com> <86c3ed7b0810310119y6c035b6en84f7ed9e9a2f1b6f@mail.gmail.com> <4A0AC25F.2060902@gmail.com> <86c3ed7b0905131005sfba99dy82e390c2dfbc0319@mail.gmail.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 13 May 2009 14:22:59 -0400 Message-ID: <2416.1242238979@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed 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, 13 May 2009 18:21:43 -0000 >>>>> "Miguel" =3D=3D Miguel Sanchez writes: Miguel> I'm not entirely happy with floating point numbers if 8-bit Miguel> micro controllers with not so much program memory (a few Miguel> KBytes) are involved. However I do like the idea of using Miguel> Energy units to express Energy values (whether it is Joules Miguel> or mJ integers are easier). Floating point is expressed as mantissa * 2^(exponent). I wonder if the mantissa is even important.=20=20 Does it matter if it costs 10 Joules or 20 Joules to transmit: the point is that it costs O(10^1)? --=20 ] Y'avait une poule de jamm=E9 dans l'muffler!!!!!!!!! | firewa= lls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"= ); [ From alexandru.petrescu@gmail.com Wed May 13 12:31:41 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 B04C13A6EF1 for ; Wed, 13 May 2009 12:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.807 X-Spam-Level: X-Spam-Status: No, score=-0.807 tagged_above=-999 required=5 tests=[AWL=-0.972, BAYES_40=-0.185, 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 z77hcBSr2N2u for ; Wed, 13 May 2009 12:31:40 -0700 (PDT) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by core3.amsl.com (Postfix) with ESMTP id 19F303A6F92 for ; Wed, 13 May 2009 12:31:07 -0700 (PDT) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id E847E4B01C9; Wed, 13 May 2009 21:32:35 +0200 (CEST) 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 2EF934B01E4; Wed, 13 May 2009 21:32:31 +0200 (CEST) Message-ID: <4A0B2047.6000604@gmail.com> Date: Wed, 13 May 2009 21:32:23 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Michael Richardson References: <86c3ed7b0810300129w5ea1e843m4610566427245811@mail.gmail.com> <86c3ed7b0810310119y6c035b6en84f7ed9e9a2f1b6f@mail.gmail.com> <4A0AC25F.2060902@gmail.com> <86c3ed7b0905131005sfba99dy82e390c2dfbc0319@mail.gmail.com> <2367.1242238950@marajade.sandelman.ca> In-Reply-To: <2367.1242238950@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090513-0, 13/05/2009), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed 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, 13 May 2009 19:31:41 -0000 Michael Richardson a écrit : >>>>>> "Miguel" == Miguel Sanchez writes: > Miguel> I'm not entirely happy with floating point numbers if 8-bit > Miguel> micro controllers with not so much program memory (a few > Miguel> KBytes) are involved. However I do like the idea of using > Miguel> Energy units to express Energy values (whether it is Joules > Miguel> or mJ integers are easier). > > Floating point is expressed as mantissa * 2^(exponent). I wonder if > the mantissa is even important. If mantissa not important then we should propose a value and agree with it. Because it could be 1, 0.1, 2, etc. Mantissa could be important - it would allow finer representation (many digits after comma) between e.g. exa-Joule and ato-Joule, i.e. both a 121987,349164 exa-Joules and 0,0972734902 ato-Joules could be represented. I do understand an Energy value for a node of ROLL is very low (I expect it in the range of micro-Joules for 1280 bytes on WiFi). But a ROLL connected to the Internet should take paths into consideration too, maybe a sattelite link, which requires of course more than just micro-Joules... I must say I don't know how much. If I knew the maximum Energy value for sending an 1280 byte packet on the most hungry satellite link were 1 Joule, then of course the metric range representation should be adapted to that upper bound. But even then, people doing inter-galactic communications, or more Earthly communications through thick concrete, may think otherwise. Maybe even ask for 128bit floating point (instead of just the proposed 32bit). > Does it matter if it costs 10 Joules or 20 Joules to transmit: the > point is that it costs O(10^1)? On a link - yes, true, the question is perfectly legitimate. On a path I expect one to prefer finer expression. A routing protocol would add and compare the Energy values of links on paths. I would imagine an Energy metric for link in ROLL routing protocol could be further exported in the routing protocols in the Internet, OSPF, BGP, like the IP hopcount metric is. I may be far off with this... Thank you for the message, Alex (PS: Another argument in favor of the 32bit single precision format is that is standardized - IEEE 754-2008. As such many people understand it. Otherwise, if we eliminate mantissa, and decide only on some range of representation, we should agree in ROLL about it. We could agree when we had many confirmed measurements of this value on many different links...) From alexandru.petrescu@gmail.com Wed May 13 12:46: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 D524F28C218 for ; Wed, 13 May 2009 12:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[AWL=-1.353, BAYES_50=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_64=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 YkXgFCj6P48z for ; Wed, 13 May 2009 12:46:23 -0700 (PDT) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by core3.amsl.com (Postfix) with ESMTP id C4EC33A6B30 for ; Wed, 13 May 2009 12:46:21 -0700 (PDT) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id 24EE54B01A0; Wed, 13 May 2009 21:47:49 +0200 (CEST) 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 D2CA34B0203; Wed, 13 May 2009 21:47:46 +0200 (CEST) Message-ID: <4A0B23DA.2090801@gmail.com> Date: Wed, 13 May 2009 21:47:38 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Omprakash Gnawali References: <49C93116.20102@eecs.berkeley.edu> <86c3ed7b0903241432vf5307a0o506085aea3357e45@mail.gmail.com> <49CAD3AA.7060002@eecs.berkeley.edu> <4A0AC469.4090309@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090513-0, 13/05/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: Wed, 13 May 2009 19:46:23 -0000 Omprakash Gnawali a écrit : > On Wed, May 13, 2009 at 6:00 AM, Alexandru Petrescu > wrote: >> Kris Pister a écrit : >>> 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} >> This ^ is too poor representation of what is energy, too little >> resolution, too small range of values. >> >> It wouldn't allow for fine grain decision in large networks. >> Compare it to the IP metric cost which has at least 15 values >> (RIP). >> >> Besides, what does 'SCAVENGER' mean in this context? IS this a >> manual dynamo or something? >> >> Is there an ordering relationship? (UNLIMITED larger than SCAVENGER >> larger than OK larger than LOW)? It's not obvious... > > Regarding the energy metric, it would be helpful to know if there are > successful routing protocols (little bit more than simulation-only > papers) that take energy into account. What does their energy > representation look like? On my side, I can say about some chipsets reporting battery levels, in mili-Volt, and micro-Ampère. I havent'seen one hardware report in Joule. I've seen cards reporting dBm and RSSI. This is not an argument against Joule. Also performed theoretical calculations for 1280byte sized packets on WiFi brandname 100mWatt power is 19 micro-Joules. Also assisted at measurements with ampermeters serially connected on battery of emitting devices. I am interested in any hands-on report helping evaluate how much Joules does it take to send an 1280-byte packet on a wireless link. > What shortcomings do they have that we are trying to improve on here? I think the most important is to come up with a common - read agreed - means to represent Energy. Be it for node or for links. > If there are already lots of non-standard LLNs with proprietary > protocols, and if energy is a useful metric, perhaps they already use > it? Yes, I am interested to learn this. > Some context information such as that would help the WG understand if > we are trying to standardize what is already done or if we are trying > to do new research. I agree. Alex > > - om_p > From pister@eecs.berkeley.edu Wed May 13 17:02:07 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 E3A4C3A6A56 for ; Wed, 13 May 2009 17:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.565 X-Spam-Level: X-Spam-Status: No, score=-5.565 tagged_above=-999 required=5 tests=[AWL=-0.826, BAYES_20=-0.74, 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 fVN4sYfxV6zs for ; Wed, 13 May 2009 17:02:07 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 1D0A13A687F for ; Wed, 13 May 2009 17:02:07 -0700 (PDT) Received: from [128.32.32.46] (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 n4E03amr011301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 May 2009 17:03:37 -0700 (PDT) Message-ID: <4A0B5FD3.8000506@eecs.berkeley.edu> Date: Wed, 13 May 2009 17:03:31 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Michael Richardson References: <86c3ed7b0810300129w5ea1e843m4610566427245811@mail.gmail.com> <86c3ed7b0810310119y6c035b6en84f7ed9e9a2f1b6f@mail.gmail.com> <4A0AC25F.2060902@gmail.com> <86c3ed7b0905131005sfba99dy82e390c2dfbc0319@mail.gmail.com> <2416.1242238979@marajade.sandelman.ca> In-Reply-To: <2416.1242238979@marajade.sandelman.ca> Content-Type: multipart/alternative; boundary="------------010309010605030702070702" Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed 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, 14 May 2009 00:02:08 -0000 This is a multi-part message in MIME format. --------------010309010605030702070702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit ...and if you burn O(10^1) Joules per packet, should I route through you, or someone who burns O(10^-4) J/pkt? I think that metrics related to total lifetime packets and max packets per second are closer to what we really care about than the absolute cost of the packets, and the absolute state of the node's internal power source. ksjp Michael Richardson wrote: >>>>>> "Miguel" == Miguel Sanchez writes: >>>>>> > Miguel> I'm not entirely happy with floating point numbers if 8-bit > Miguel> micro controllers with not so much program memory (a few > Miguel> KBytes) are involved. However I do like the idea of using > Miguel> Energy units to express Energy values (whether it is Joules > Miguel> or mJ integers are easier). > > Floating point is expressed as mantissa * 2^(exponent). > I wonder if the mantissa is even important. > > Does it matter if it costs 10 Joules or 20 Joules to transmit: the > point is that it costs O(10^1)? > > --------------010309010605030702070702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit ...and if you burn O(10^1) Joules per packet, should I route through you, or someone who burns O(10^-4) J/pkt?

I think that metrics related to total lifetime packets and max packets per second are closer to what we really care about than the absolute cost of the packets, and the absolute state of the node's internal power source.

ksjp

Michael Richardson wrote: 
"Miguel" == Miguel Sanchez <misan@disca.upv.es> writes:
            
    Miguel> I'm not entirely happy with floating point numbers if 8-bit
    Miguel> micro controllers with not so much program memory (a few
    Miguel> KBytes) are involved.  However I do like the idea of using
    Miguel> Energy units to express Energy values (whether it is Joules
    Miguel> or mJ integers are easier).

  Floating point is expressed as mantissa * 2^(exponent).
  I wonder if the mantissa is even important.  

  Does it matter if it costs 10 Joules or 20 Joules to transmit: the
point is that it costs O(10^1)?
--------------010309010605030702070702-- From jvasseur@cisco.com Thu May 14 02:31: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 D49723A67AA for ; Thu, 14 May 2009 02:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.183 X-Spam-Level: X-Spam-Status: No, score=-10.183 tagged_above=-999 required=5 tests=[AWL=0.416, 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 QrP7lKOWqebH for ; Thu, 14 May 2009 02:31:35 -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 80B993A6C61 for ; Thu, 14 May 2009 02:31:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,193,1241395200"; d="scan'208";a="40560796" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 14 May 2009 09:33:00 +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 n4E9X0ox012702; Thu, 14 May 2009 11:33:00 +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 n4E9X07W018776; Thu, 14 May 2009 09:33:00 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, 14 May 2009 11:33:00 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 May 2009 11:33:00 +0200 Message-Id: <7E4C3EE9-2607-49F1-BA37-76906BADBA64@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4A0AC1E9.40802@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: Thu, 14 May 2009 11:32:59 +0200 References: <4A0AC1E9.40802@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 14 May 2009 09:33:00.0415 (UTC) FILETIME=[F8EB00F0:01C9D476] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7252; t=1242293580; x=1243157580; 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]=20ROLL=20Routing=20Metrics=20-=2 0WF=20feed-back=20needed |Sender:=20; bh=jqV69kMppU/+AJ3GjI7naLi6MQTtqQVYLaKWlMGe1mU=; b=CN8m0F8q1lIVAzChc/CNOrHAcNSu3Ok4j3HxcKY7i/cl1FKepDGoIrz+VU uFME9RIMCipWXl3M1mAoumlg+8r6u1Qd+NqLy7hqm3K9HFtHup9sa0AGqKVy hLhe1Hu+C2; 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] ROLL Routing Metrics - WF feed-back needed 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, 14 May 2009 09:31:36 -0000 On May 13, 2009, at 2:49 PM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> Hi, >> On 10/30/08 1:31 PM, "Miguel Sanchez" wrote: >>> Hi JP, >>> On Thu, Oct 30, 2008 at 12:30 PM, JP Vasseur >>> wrote: >>>> Hi Miguel, >>>> On 10/30/08 11:56 AM, "Miguel Sanchez" >>>> wrote: >>>>> Hi JP, >>>>> On Thu, Oct 30, 2008 at 10:02 AM, JP Vasseur >>>>> wrote: >>>>>> Hi Miguel, >>>>>> On 10/30/08 9:29 AM, "Miguel Sanchez" >>>>>> wrote: >>>>>>> I've got a terminology problem with "propagation delay" >>>>>>> (5.3), while defined in the draft (and later defined is >>>>>>> path propagation) a new meaning is given to the term. (For >>>>>>> short range communications transmission time could be used >>>>>>> instead). >>>>>> Let me make sure that I get your point here. The document >>>>>> says: "Propagation delay is the time taken for the packet to >>>>>> traverse the link from the source node to the target node." >>>>> Definition is clear enough but what bothers me is that >>>>> "propagation delay" equals link length over propagation speed >>>>> in my book. Apparently the meaning here is more like >>>>> transmission time + propagation delay (the latter as I've >>>>> defined here). >>>> Ah I see what you mean, it is w/o transmission delay (just >>>> propagation delay). We'll clarify. >>> Ok. >>>>>> I think that the notion of source and target node is >>>>>> confusing and the text should read: >>>>>> " Propagation delay is the time taken for the packet to >>>>>> traverse the link. " >>>>> Do you mean including the transmission time? >>>>>> Does that clarify ? >>>>>>> Regarding the energy metric I can see a problem if only one >>>>>>> value is given (ie: remaining enery). The value might be >>>>>>> infinite to signal nodes without energy restrictions, but >>>>>>> for the remaining nodes, a single value may not be enough. >>>>>>> Let me elaborate on this with an example: A node may have >>>>>>> an overall lower consumption than another one. If the >>>>>>> former has slightly less energy than the second one, then =20 >>>>>>> choosing the later may not be the best choice for long term >>>>>>> survivability of the network (this could be addressed by >>>>>>> advertising expected node lifetime instead of node's >>>>>>> remaining energy). >>>>>> Absolutely. The remaining energy metric may be difficult to >>>>>> interpret and the expected lifetime may be hard to compute. >>>>>>> On the other hand, without knowing the initial energy, it's >>>>>>> not possible to know what fraction of the original energy >>>>>>> is the remaining one. This could be addressesed advertising >>>>>>> remaining energy as a percentage (contrary to the above >>>>>>> paragraph approach). >>>>>> Yes or ... We may use a simple multi-threshold mechanisms: >>>>>> "Low, Medium, High" where: "LOW: avoid this node if possible" >>>>>> "Medium: no particular constraint" "HIGH: favor this node" >>>>>> Avoid/favor should of course be interpreted in the context of >>>>>> energy. >>>>>> What do you think ? >>>>> I think the high/medium/low approach may hurt some >>>>> implementations over a numerical value (i.e: choosing between >>>>> two nodes with high value). >>>> But that may be "good" enough ... The issue with a numeric value >>>> is that it will be really hard to define a consistent way to >>>> compute the value *and* will be hard to use by the computation >>>> engine. >>>> Agree ? >>> Not really. As I see it local computation at a node is used to =20 >>> determine the residual energy. Based on that (and may be other =20 >>> constraints) node is tagged as high/medium/low. That energy tag is =20= >>> used later for routing decisions. Nodes could advertise the source =20= >>> data instead, residual energy. Doing that might make routing =20 >>> calculations more complex, but not doing it restricts the freedom >>> of routing algorithm. >>> Certainly the numeric value could end up having a few bits and =20 >>> effectively becoming 2 or four discrete values (similar to what you >>> suggest). >> Looks like you are agreeing with the suggested use of a few discrete >> values (flags) used for constrained based routing ? > > I disagree to use a such a discrete metric, allowing only a few =20 > values. > > The existing metric (IP number of hops) has a much higher =20 > resolution, going from 15 vlaues for RIP to OSPF's huge 65535. It all depends on how we want to represent energy *and* for what =20 purpose. I never look only at what I want to model but what could be =20 done with it. WE has for example in depth discussion on metrics, =20 objective functions, ... in other WGs and many times people wanted to =20= standardize metrics and could be practically used by the routing =20 protocol, we know ho easy it is to come up with an NP complete =20 problem. This is why we would like to advance the document in parallel =20= with the routing protocol ! JP. > > Alex > >>>>>> But ... In any case, we need to avoid the definition of >>>>>> metric that are implementation/node dependent. The way you >>>>>> model energy cannot be standardized. >>>>> We've to find a way to create an standard way for energy >>>>> reporting. Haven't we? >>>> Heu ... You may want to try ... But certainly not trivial. >>> We've agreed on energy reporting. How this is done effectively does >>> not seem trivial but it has to be done for protocols to be able to >>> use that. >>> My suggestion here is to report two energy related values: residual >>> energy in Joules and the same as a percentage. >> OK let's wait to see what others say. I claim that a few flags are =20= >> sufficient you would prefer to define a way to express energy. Let's >> try to converge on the list. >>>>>> We also need to ensure that nodes use consistent metrics (a >>>>>> fairly common problem). >>>>>>> And last, in certain network setups some nodes may be easy >>>>>>> to replace while others are not. You may want batteries to >>>>>>> die out more often on nodes that can have their batteries >>>>>>> replaced easily even though other nearby nodes have more >>>>>>> energy available. >>>>>> Absolutely, as defined in the industrial routing requirement >>>>>> document. This should be an administrative constraint. >>>>>> Energy metric need to be >>>>>>> complemented with other metrics. (Network survivability is >>>>>>> not the only factor we have to take into account). >>>>>> Right. Did you have a look at the other ones ? >>>>> I mostly agree with the rest, perhaps I'd chose PER (packet >>>>> error rate) metric instead of BER. >>>> One problem though: the PER of a function of packet size and can >>>> be computed knowing the BER anyway. >>>> Agree ? >>> Yes but non trivial (coding, iid errors). PER can be measured >>> easily on the nodes (if link layer ACKs are used). That's why I was >>> suggesting it. >> Yes. >> Thanks. >> JP. >>> Kind regards, >>> Miguel >> _______________________________________________ Roll mailing list = Roll@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/roll > > From jvasseur@cisco.com Thu May 14 02:33: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 DF45D3A6CD8 for ; Thu, 14 May 2009 02:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.187 X-Spam-Level: X-Spam-Status: No, score=-10.187 tagged_above=-999 required=5 tests=[AWL=0.412, 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 lrsYyeaZ8Eml for ; Thu, 14 May 2009 02:33: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 2913C3A6C61 for ; Thu, 14 May 2009 02:33:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,193,1241395200"; d="scan'208";a="40561258" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 May 2009 09:34:50 +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 n4E9YoOZ020813; Thu, 14 May 2009 11:34:50 +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 n4E9YngK019969; Thu, 14 May 2009 09:34:50 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); Thu, 14 May 2009 11:34:49 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 May 2009 11:34:49 +0200 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4A0AC3A9.2070603@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: Thu, 14 May 2009 11:34:48 +0200 References: <4A0AC3A9.2070603@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 14 May 2009 09:34:49.0445 (UTC) FILETIME=[39E7A950:01C9D477] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4899; t=1242293690; x=1243157690; 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]=20ROLL=20Routing=20Metrics=20-=2 0WF=20feed-back=20needed |Sender:=20; bh=+R7k9b1cTji4okXXKefMyB6/CDgNXmU65OaCco6RT2E=; b=uEZumpXp6rFbSTlP3bCRjKvMmryXWesZyreCUux1zNrcjU797k/x67flnX q3PdMatimqjpxilam/RmpcL8HPqQ5sZD4w+fdcn9FkWINUHGW9TK48QnTP3S nCF+ZC5g+G; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed 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, 14 May 2009 09:33:20 -0000 On May 13, 2009, at 2:57 PM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> Hi, >> On 11/10/08 11:52 PM, "Kris Pister" wrote: >>> Phil - I agree that the optimal routes are going to be a function =20= >>> of the >>> state of all of the nodes along each route, not just one node >>> advertising that it's fat and happy. >> Right. Bear in mind that we are discussing node metric. Path =20 >> characteristics >> are locally derived by the computing node ! > > DEpends whether we consider a path to be the set of links or the set =20= > of the nodes. > > I personally prefer it to be the set of links. And associate a =20 > metric to a link, not to a node. A path is *always* is a set of links and nodes, which I agree does not =20= require to set metric for nodes. We could have metrics and constraints for the links and node =20 constraints for the node. This is going to be clarified in the routing protocol ID, to be discussed in the WG =20= of course. JP. > > Alex > >>> I don't think that I agree that we're assuming that a node must >>> communicate a lot of factors to other nodes. I can imagine =20 >>> something >>> like AODV, but where each node adds its own hop cost. Depending on >>> shared network parameters, each node might add e.g. 1/(remaining >>> lifetime) to the total route cost, or it might add it's link-=20 >>> latency to >>> the route cost. I'm not advocating something AODV-like, just =20 >>> pointing >>> out that we don't necessarily need to be propagating a lot of state >>> information around the network, and potentially complicated (and >>> platform dependent) local computations can still be done without the >>> global algorithm needing to know the details. >> Absolutely. >> JP. >>> ksjp >>> >>> Philip Levis wrote: >>>> On Nov 10, 2008, at 7:55 AM, Anders Brandt wrote: >>>> >>>>> Jerry touches a point I forgot to mention in relation to Kris' >>>>> previous postings. >>>>> >>>>> I fully support the idea of preferred routers running on battery. >>>>> We definitely also see this application in the home control =20 >>>>> domain. >>>>> >>>>>> ...let's say I have a battery powered repeater installed in a >>>>> sparse portion of the mesh. This device has no other meaning in >>>>>> life but to route messages. Rerouting around this device saves =20= >>>>>> the >>>>> energy on a device that has no reason to save energy. >>>>>> Also, remember this repeater was strategically placed to 'fill-=20= >>>>>> in' >>>>> the mesh. >>>>> >>>>> In order to attract interest from the routing protocol, such a =20 >>>>> node >>>>> should be able to signal "mains powered" or even better: >>>>> "I have plenty of battery". >>>>> Obviously, it should lower that indication to normal >>>>> "battery-powered" if running close to low; ending with "battery =20= >>>>> low". >>>>> br. Anders >>>>> >>>>> >>>>> >>>> I'm confused by this line of logic. Whether a node advertises =20 >>>> itself >>>> as having lots of energy is less important than the available =20 >>>> energy >>>> along a route. I.e., if the next hop, node A, has lots of energy =20= >>>> but >>>> its next hop, node B, is very limited, the fact that A has lots of >>>> energy is not particularly useful. >>>> >>>> So far, this discussion has assumed that a node must communicate =20= >>>> a lot >>>> of factors to other nodes, so they can apply their own algorithms =20= >>>> to >>>> decide which next hop to take. The issue here is that it assumes =20= >>>> the >>>> optimization criteria are the same; even though the router-to-be =20= >>>> wants >>>> to save energy, the sender wants to optimize latency and so ignores >>>> energy constraints. Another approach is that each node applies =20 >>>> its own >>>> algorithm to determine its willingness/cost, which other nodes then >>>> take into account. That is, nodes advertise how good a router they >>>> think they are, and senders take this into consideration. =20 >>>> Otherwise, >>>> especially in a distributed and dynamic system, senders can be =20 >>>> making >>>> decisions based on out-of-date information which is hard to detect >>>> inconsistencies on without expensive periodic state exchanges. >>>> >>>> E.g., one simple way to articulate energy, rather than "I have X" =20= >>>> is >>>> "How expensive I consider sending a packet." This takes into >>>> consideration a lot more useful information, and is much more =20 >>>> flexible >>>> to compute and consider. >>>> >>>> Phil >>> _______________________________________________ >>> 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 May 14 02:52: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 D489D28C10C for ; Thu, 14 May 2009 02:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.116, 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 RmhbM6p3Y+ED for ; Thu, 14 May 2009 02:52:07 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 54BCC28C19B for ; Thu, 14 May 2009 02:52:07 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n4E9kIDH020590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 May 2009 11:46:18 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n4E9mSn0010451; Thu, 14 May 2009 11:48:29 +0200 (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 n4E9mSjA022741; Thu, 14 May 2009 11:48:28 +0200 Message-ID: <4A0BE8EC.8060909@gmail.com> Date: Thu, 14 May 2009 11:48:28 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: JP Vasseur References: <4A0AC1E9.40802@gmail.com> <7E4C3EE9-2607-49F1-BA37-76906BADBA64@cisco.com> In-Reply-To: <7E4C3EE9-2607-49F1-BA37-76906BADBA64@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed 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, 14 May 2009 09:52:08 -0000 JP Vasseur a écrit : > > On May 13, 2009, at 2:49 PM, Alexandru Petrescu wrote: > >> JP Vasseur a écrit : >>> Hi, On 10/30/08 1:31 PM, "Miguel Sanchez" >>> wrote: >>>> Hi JP, On Thu, Oct 30, 2008 at 12:30 PM, JP Vasseur >>>> wrote: >>>>> Hi Miguel, On 10/30/08 11:56 AM, "Miguel Sanchez" >>>>> wrote: >>>>>> Hi JP, On Thu, Oct 30, 2008 at 10:02 AM, JP Vasseur >>>>>> wrote: >>>>>>> Hi Miguel, On 10/30/08 9:29 AM, "Miguel Sanchez" >>>>>>> wrote: >>>>>>>> I've got a terminology problem with "propagation delay" >>>>>>>> (5.3), while defined in the draft (and later defined >>>>>>>> is path propagation) a new meaning is given to the >>>>>>>> term. (For short range communications transmission time >>>>>>>> could be used instead). >>>>>>> Let me make sure that I get your point here. The document >>>>>>> says: "Propagation delay is the time taken for the >>>>>>> packet to traverse the link from the source node to the >>>>>>> target node." >>>>>> Definition is clear enough but what bothers me is that >>>>>> "propagation delay" equals link length over propagation >>>>>> speed in my book. Apparently the meaning here is more like >>>>>> transmission time + propagation delay (the latter as I've >>>>>> defined here). >>>>> Ah I see what you mean, it is w/o transmission delay (just >>>>> propagation delay). We'll clarify. >>>> Ok. >>>>>>> I think that the notion of source and target node is >>>>>>> confusing and the text should read: " Propagation delay >>>>>>> is the time taken for the packet to traverse the link. " >>>>>> Do you mean including the transmission time? >>>>>>> Does that clarify ? >>>>>>>> Regarding the energy metric I can see a problem if only >>>>>>>> one value is given (ie: remaining enery). The value >>>>>>>> might be infinite to signal nodes without energy >>>>>>>> restrictions, but for the remaining nodes, a single >>>>>>>> value may not be enough. Let me elaborate on this with >>>>>>>> an example: A node may have an overall lower >>>>>>>> consumption than another one. If the former has >>>>>>>> slightly less energy than the second one, then choosing >>>>>>>> the later may not be the best choice for long term >>>>>>>> survivability of the network (this could be addressed >>>>>>>> by advertising expected node lifetime instead of node's >>>>>>>> remaining energy). >>>>>>> Absolutely. The remaining energy metric may be difficult >>>>>>> to interpret and the expected lifetime may be hard to >>>>>>> compute. >>>>>>>> On the other hand, without knowing the initial energy, >>>>>>>> it's not possible to know what fraction of the original >>>>>>>> energy is the remaining one. This could be addressesed >>>>>>>> advertising remaining energy as a percentage (contrary >>>>>>>> to the above paragraph approach). >>>>>>> Yes or ... We may use a simple multi-threshold >>>>>>> mechanisms: "Low, Medium, High" where: "LOW: avoid this >>>>>>> node if possible" "Medium: no particular constraint" >>>>>>> "HIGH: favor this node" Avoid/favor should of course be >>>>>>> interpreted in the context of energy. What do you think ? >>>>>>> >>>>>> I think the high/medium/low approach may hurt some >>>>>> implementations over a numerical value (i.e: choosing >>>>>> between two nodes with high value). >>>>> But that may be "good" enough ... The issue with a numeric >>>>> value is that it will be really hard to define a consistent >>>>> way to compute the value *and* will be hard to use by the >>>>> computation engine. Agree ? >>>> Not really. As I see it local computation at a node is used to >>>> determine the residual energy. Based on that (and may be other >>>> constraints) node is tagged as high/medium/low. That energy >>>> tag is used later for routing decisions. Nodes could advertise >>>> the source data instead, residual energy. Doing that might make >>>> routing calculations more complex, but not doing it restricts >>>> the freedom of routing algorithm. Certainly the numeric value >>>> could end up having a few bits and effectively becoming 2 or >>>> four discrete values (similar to what you suggest). >>> Looks like you are agreeing with the suggested use of a few >>> discrete values (flags) used for constrained based routing ? >> >> I disagree to use a such a discrete metric, allowing only a few >> values. >> >> The existing metric (IP number of hops) has a much higher >> resolution, going from 15 vlaues for RIP to OSPF's huge 65535. > > It all depends on how we want to represent energy *and* for what > purpose. > > I never look only at what I want to model but what could be done with > it. WE has for example in depth discussion on metrics, objective > functions, ... in other WGs and many times people wanted to > standardize metrics and could be practically used by the routing > protocol, we know ho easy it is to come up with an NP complete > problem. JP, I'm intrigued... What does NP-completeness have to do with a metric here? When you say "we all know" - is this as a Chair of this WG? Or as a co-author of the metrics WG item? Alex > This is why we would like to advance the document in parallel with > the routing protocol ! > > JP. > >> >> Alex >> >>>>>>> But ... In any case, we need to avoid the definition of >>>>>>> metric that are implementation/node dependent. The way >>>>>>> you model energy cannot be standardized. >>>>>> We've to find a way to create an standard way for energy >>>>>> reporting. Haven't we? >>>>> Heu ... You may want to try ... But certainly not trivial. >>>> We've agreed on energy reporting. How this is done effectively >>>> does not seem trivial but it has to be done for protocols to be >>>> able to use that. My suggestion here is to report two energy >>>> related values: residual energy in Joules and the same as a >>>> percentage. >>> OK let's wait to see what others say. I claim that a few flags >>> are sufficient you would prefer to define a way to express >>> energy. Let's try to converge on the list. >>>>>>> We also need to ensure that nodes use consistent metrics >>>>>>> (a fairly common problem). >>>>>>>> And last, in certain network setups some nodes may be >>>>>>>> easy to replace while others are not. You may want >>>>>>>> batteries to die out more often on nodes that can have >>>>>>>> their batteries replaced easily even though other >>>>>>>> nearby nodes have more energy available. >>>>>>> Absolutely, as defined in the industrial routing >>>>>>> requirement document. This should be an administrative >>>>>>> constraint. Energy metric need to be >>>>>>>> complemented with other metrics. (Network survivability >>>>>>>> is not the only factor we have to take into account). >>>>>>> Right. Did you have a look at the other ones ? >>>>>> I mostly agree with the rest, perhaps I'd chose PER (packet >>>>>> error rate) metric instead of BER. >>>>> One problem though: the PER of a function of packet size and >>>>> can be computed knowing the BER anyway. Agree ? >>>> Yes but non trivial (coding, iid errors). PER can be measured >>>> easily on the nodes (if link layer ACKs are used). That's why I >>>> was suggesting it. >>> Yes. Thanks. JP. >>>> Kind regards, Miguel >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> >> > > From alexandru.petrescu@gmail.com Thu May 14 02:56:16 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 8FD293A68EF for ; Thu, 14 May 2009 02:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.116, 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 MG3i0U2ebzC9 for ; Thu, 14 May 2009 02:56:15 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 97A523A6F29 for ; Thu, 14 May 2009 02:55:59 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n4E9vLTS025130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 May 2009 11:57:21 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n4E9vKmN012345; Thu, 14 May 2009 11:57:21 +0200 (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 n4E9vK2o028106; Thu, 14 May 2009 11:57:20 +0200 Message-ID: <4A0BEB00.90108@gmail.com> Date: Thu, 14 May 2009 11:57:20 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: JP Vasseur References: <4A0AC3A9.2070603@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WG feed-back needed 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, 14 May 2009 09:56:16 -0000 JP Vasseur a écrit : > > On May 13, 2009, at 2:57 PM, Alexandru Petrescu wrote: > >> JP Vasseur a écrit : >>> Hi, On 11/10/08 11:52 PM, "Kris Pister" >>> wrote: >>>> Phil - I agree that the optimal routes are going to be a >>>> function of the state of all of the nodes along each route, not >>>> just one node advertising that it's fat and happy. >>> Right. Bear in mind that we are discussing node metric. Path >>> characteristics are locally derived by the computing node ! >> >> DEpends whether we consider a path to be the set of links or the >> set of the nodes. >> >> I personally prefer it to be the set of links. And associate a >> metric to a link, not to a node. > > A path is *always* is a set of links and nodes, which I agree does > not require to set metric for nodes. We could have metrics and > constraints for the links and node constraints for the node. Just to say I agree... > This is going to be clarified in the routing protocol ID, to be > discussed in the WG of course. Ok, looking forward, thanks, Alex > > JP. > >> >> Alex >> >>>> I don't think that I agree that we're assuming that a node must >>>> communicate a lot of factors to other nodes. I can imagine >>>> something like AODV, but where each node adds its own hop cost. >>>> Depending on shared network parameters, each node might add >>>> e.g. 1/(remaining lifetime) to the total route cost, or it >>>> might add it's link-latency to the route cost. I'm not >>>> advocating something AODV-like, just pointing out that we don't >>>> necessarily need to be propagating a lot of state information >>>> around the network, and potentially complicated (and platform >>>> dependent) local computations can still be done without the >>>> global algorithm needing to know the details. >>> Absolutely. JP. >>>> ksjp >>>> >>>> Philip Levis wrote: >>>>> On Nov 10, 2008, at 7:55 AM, Anders Brandt wrote: >>>>> >>>>>> Jerry touches a point I forgot to mention in relation to >>>>>> Kris' previous postings. >>>>>> >>>>>> I fully support the idea of preferred routers running on >>>>>> battery. We definitely also see this application in the >>>>>> home control domain. >>>>>> >>>>>>> ...let's say I have a battery powered repeater installed >>>>>>> in a >>>>>> sparse portion of the mesh. This device has no other >>>>>> meaning in >>>>>>> life but to route messages. Rerouting around this device >>>>>>> saves the >>>>>> energy on a device that has no reason to save energy. >>>>>>> Also, remember this repeater was strategically placed to >>>>>>> 'fill-in' >>>>>> the mesh. >>>>>> >>>>>> In order to attract interest from the routing protocol, >>>>>> such a node should be able to signal "mains powered" or >>>>>> even better: "I have plenty of battery". Obviously, it >>>>>> should lower that indication to normal "battery-powered" if >>>>>> running close to low; ending with "battery low". br. >>>>>> Anders >>>>>> >>>>>> >>>>>> >>>>>> >>>>> I'm confused by this line of logic. Whether a node advertises >>>>> itself as having lots of energy is less important than the >>>>> available energy along a route. I.e., if the next hop, node >>>>> A, has lots of energy but its next hop, node B, is very >>>>> limited, the fact that A has lots of energy is not >>>>> particularly useful. >>>>> >>>>> So far, this discussion has assumed that a node must >>>>> communicate a lot of factors to other nodes, so they can >>>>> apply their own algorithms to decide which next hop to take. >>>>> The issue here is that it assumes the optimization criteria >>>>> are the same; even though the router-to-be wants to save >>>>> energy, the sender wants to optimize latency and so ignores >>>>> energy constraints. Another approach is that each node >>>>> applies its own algorithm to determine its willingness/cost, >>>>> which other nodes then take into account. That is, nodes >>>>> advertise how good a router they think they are, and senders >>>>> take this into consideration. Otherwise, especially in a >>>>> distributed and dynamic system, senders can be making >>>>> decisions based on out-of-date information which is hard to >>>>> detect inconsistencies on without expensive periodic state >>>>> exchanges. >>>>> >>>>> E.g., one simple way to articulate energy, rather than "I >>>>> have X" is "How expensive I consider sending a packet." This >>>>> takes into consideration a lot more useful information, and >>>>> is much more flexible to compute and consider. >>>>> >>>>> Phil >>>> _______________________________________________ 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 Jerald.P.Martocci@jci.com Thu May 14 07:31: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 5BB5A3A702E; Thu, 14 May 2009 07:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.606 X-Spam-Level: X-Spam-Status: No, score=-6.606 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 srMFKWOwgjYQ; Thu, 14 May 2009 07:31:50 -0700 (PDT) Received: from exprod8og120.obsmtp.com (exprod8og120.obsmtp.com [64.18.3.40]) by core3.amsl.com (Postfix) with ESMTP id 5AB5228C29B; Thu, 14 May 2009 07:31:05 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob120.postini.com ([64.18.7.12]) with SMTP ID DSNKSgwq+9mNVcg213EGUzVwqD8kXJm6be0C@postini.com; Thu, 14 May 2009 07:32:39 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009051409310921-4297504 ; Thu, 14 May 2009 09:31:09 -0500 In-Reply-To: MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Thu, 14 May 2009 09:30:01 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 05/14/2009 09:30:05 AM, Serialize complete at 05/14/2009 09:30:05 AM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 05/14/2009 09:31:09 AM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 05/14/2009 09:33:41 AM, Serialize complete at 05/14/2009 09:33:41 AM Content-Type: multipart/alternative; boundary="=_alternative 004FA6ED862575B6_=" Cc: roll-bounces@ietf.org, ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] Few comments for our first discussion today 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, 14 May 2009 14:31:51 -0000 This is a multipart message in MIME format. --=_alternative 004FA6ED862575B6_= Content-Type: text/plain; charset="US-ASCII" I agree. Otherwise we are just setting ourselves up for confrontation once the DT has developed a working document. If they provide their integrated requirement set earlier the requirement's authors could in parallel be assimilating these four requirement sets into a single comprehensive set. "Dearlove, Christopher (UK)" Sent by: roll-bounces@ietf.org 05/13/2009 10:06 AM To "JP Vasseur" , "Philip Levis" cc ROLL WG , dtroll@external.cisco.com Subject Re: [Roll] Few comments for our first discussion today JP Vasseur > Philip Levis >> Tim commented that the DT is going through the application IDs to >> derive the MUSTs and SHOULDs, distilling them to a set of core >> requirements and optional ones for extensions. This has always been >> the stated first work item of the WG after rechartering, and so it >> makes a much more logical synchronization point. > > Yes note that there is nothing new here, just a review of the MUST. As the various documents aren't exactly aligned, even this needs to make some judgements, and it would be useful to see what those are. ******************************************************************** 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 --=_alternative 004FA6ED862575B6_= Content-Type: text/html; charset="US-ASCII"
I agree.  Otherwise we are just setting ourselves up for confrontation once the DT has developed a working document.  If they provide their integrated requirement set earlier the requirement's authors could in parallel be assimilating these four requirement sets into a single comprehensive set.





"Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
Sent by: roll-bounces@ietf.org

05/13/2009 10:06 AM

To
"JP Vasseur" <jvasseur@cisco.com>, "Philip Levis" <pal@cs.stanford.edu>
cc
ROLL WG <roll@ietf.org>, dtroll@external.cisco.com
Subject
Re: [Roll] Few comments for our first discussion today





JP Vasseur
> Philip Levis
>> Tim commented that the DT is going through the application IDs to  
>> derive the MUSTs and SHOULDs, distilling them to a set of core  
>> requirements and optional ones for extensions. This has always been  
>> the stated first work item of the WG after rechartering, and so it  
>> makes a much more logical synchronization point.
>
> Yes note that there is nothing new here, just a review of the MUST.

As the various documents aren't exactly aligned, even this needs
to make some judgements, and it would be useful to see what those
are.

********************************************************************
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
--=_alternative 004FA6ED862575B6_=-- From jvasseur@cisco.com Thu May 14 07: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 A801C28C248; Thu, 14 May 2009 07:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.191 X-Spam-Level: X-Spam-Status: No, score=-10.191 tagged_above=-999 required=5 tests=[AWL=0.407, 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 cATHNvMlHXjv; Thu, 14 May 2009 07:36:31 -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 BB9FD28C28E; Thu, 14 May 2009 07:36:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,194,1241395200"; d="scan'208,217";a="40606712" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 May 2009 14:37:58 +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 n4EEbwNn000475; Thu, 14 May 2009 16:37:58 +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 n4EEbwVh017379; Thu, 14 May 2009 14:37:58 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); Thu, 14 May 2009 16:37:58 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 May 2009 16:37:57 +0200 Message-Id: <314C5D40-78D3-4F66-AD40-093588E2233F@cisco.com> From: JP Vasseur To: Jerald P Martocci , "Dearlove, Christopher (UK)" In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-56--135811699 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 14 May 2009 16:37:56 +0200 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 14 May 2009 14:37:58.0327 (UTC) FILETIME=[9352CC70:01C9D4A1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6624; t=1242311878; x=1243175878; 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]=20Few=20comments=20for=20our=20f irst=20discussion=20today |Sender:=20; bh=nj59dEqjfP6aaempfbPF8a6QpWGySiTUuFmwm8JqW68=; b=FH9d27m4Csq4J9NKGHLhNz96v10hIdvEmICI636odnB/HB1MDvbijc3Eg3 f4cKJUxbgiA/MMmuSM6FWWgKZRZq6jtkl3ko+D2sLm3m3APUNjbW6E2FKJ7B p7uxiuKAjm; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll-bounces@ietf.org, ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] Few comments for our first discussion today 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, 14 May 2009 14:36:32 -0000 --Apple-Mail-56--135811699 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit That is an excellent suggestion. Since regrouping the requirements (MUST) is a starting point, we'll make sure to send it to the list. Note that the point is not to rediscuss any of these of course. Thanks. JP. On May 14, 2009, at 4:30 PM, Jerald.P.Martocci@jci.com wrote: > > I agree. Otherwise we are just setting ourselves up for > confrontation once the DT has developed a working document. If they > provide their integrated requirement set earlier the requirement's > authors could in parallel be assimilating these four requirement > sets into a single comprehensive set. > > > > > > "Dearlove, Christopher (UK)" > Sent by: roll-bounces@ietf.org > 05/13/2009 10:06 AM > > To > "JP Vasseur" , "Philip Levis" > > cc > ROLL WG , dtroll@external.cisco.com > Subject > Re: [Roll] Few comments for our first discussion today > > > > > > JP Vasseur > > Philip Levis > >> Tim commented that the DT is going through the application IDs to > >> derive the MUSTs and SHOULDs, distilling them to a set of core > >> requirements and optional ones for extensions. This has always been > >> the stated first work item of the WG after rechartering, and so it > >> makes a much more logical synchronization point. > > > > Yes note that there is nothing new here, just a review of the MUST. > > As the various documents aren't exactly aligned, even this needs > to make some judgements, and it would be useful to see what those > are. > > ******************************************************************** > 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 > --Apple-Mail-56--135811699 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable That is an excellent = suggestion. Since regrouping the requirements (MUST) is a starting = point, we'll make sure to send it to the list.
Note that the point = is not to rediscuss any of these of = course.

Thanks.

JP.

On May 14, 2009, at 4:30 PM, Jerald.P.Martocci@jci.com = wrote:


I agree. =  Otherwise we are just setting ourselves up for confrontation once = the DT has developed a working document.  If they provide their = integrated requirement set earlier the requirement's authors could in = parallel be assimilating these four requirement sets into a single = comprehensive set.





=
"Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.co= m>
Sent by: = roll-bounces@ietf.org

<= font size=3D"1" face=3D"sans-serif">05/13/2009 10:06 AM =

To
"JP Vasseur" <jvasseur@cisco.com>, "Philip = Levis" <pal@cs.stanford.edu> =
cc
ROLL WG <roll@ietf.org>, dtroll@external.cisco.com
Subject
Re: [Roll] Few comments for our first = discussion today

=
=



JP = Vasseur
> Philip Levis
>> Tim commented that the DT is = going through the application IDs to  
>> derive the = MUSTs and SHOULDs, distilling them to a set of core  
>> = requirements and optional ones for extensions. This has always been =  
>> the stated first work item of the WG after = rechartering, and so it  
>> makes a much more logical = synchronization point.
>
> Yes note that there is nothing = new here, just a review of the MUST.

As the various documents = aren't exactly aligned, even this needs
to make some judgements, and = it would be useful to see what those
are.

= ********************************************************************
= 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/m= ailman/listinfo/roll
 =

= --Apple-Mail-56--135811699-- From jvasseur@cisco.com Thu May 14 07:37: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 0327328C144 for ; Thu, 14 May 2009 07:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.195 X-Spam-Level: X-Spam-Status: No, score=-10.195 tagged_above=-999 required=5 tests=[AWL=0.404, 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 ouVqrcWDZp+5 for ; Thu, 14 May 2009 07:37:21 -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 1D80A3A6855 for ; Thu, 14 May 2009 07:37:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,194,1241395200"; d="scan'208";a="40606849" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 May 2009 14:38:53 +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 n4EEcr56000807; Thu, 14 May 2009 16:38:53 +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 n4EEcrs0017712; Thu, 14 May 2009 14:38:53 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); Thu, 14 May 2009 16:38:53 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 May 2009 16:38:52 +0200 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4A0BE8EC.8060909@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: Thu, 14 May 2009 16:38:51 +0200 References: <4A0AC1E9.40802@gmail.com> <7E4C3EE9-2607-49F1-BA37-76906BADBA64@cisco.com> <4A0BE8EC.8060909@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 14 May 2009 14:38:52.0795 (UTC) FILETIME=[B3C9F4B0:01C9D4A1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7817; t=1242311933; x=1243175933; 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]=20ROLL=20Routing=20Metrics=20-=2 0WF=20feed-back=20needed |Sender:=20; bh=V8IRd2yw1LVdiNrODzLBdEqDowST5OGW/X22dPqODMA=; b=grWNJM5KHFkHuhANlUc2KieClfP0fnXuS5OVJMcLOUtrF7CI6PH/NbbF2d fMJyxDS7NzhJGSunmTkJwhjNuXVV5QAWxSjr1CNIYtFA1IigkrLd6vmR6k/s Im77D9mk14; 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] ROLL Routing Metrics - WF feed-back needed 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, 14 May 2009 14:37:23 -0000 On May 14, 2009, at 11:48 AM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> On May 13, 2009, at 2:49 PM, Alexandru Petrescu wrote: >>> JP Vasseur a =E9crit : >>>> Hi, On 10/30/08 1:31 PM, "Miguel Sanchez" >>>> wrote: >>>>> Hi JP, On Thu, Oct 30, 2008 at 12:30 PM, JP Vasseur >>>>> wrote: >>>>>> Hi Miguel, On 10/30/08 11:56 AM, "Miguel Sanchez" >>>>>> wrote: >>>>>>> Hi JP, On Thu, Oct 30, 2008 at 10:02 AM, JP Vasseur = >>>>>> > wrote: >>>>>>>> Hi Miguel, On 10/30/08 9:29 AM, "Miguel Sanchez" >>>>>>>> wrote: >>>>>>>>> I've got a terminology problem with "propagation delay" >>>>>>>>> (5.3), while defined in the draft (and later defined >>>>>>>>> is path propagation) a new meaning is given to the >>>>>>>>> term. (For short range communications transmission time >>>>>>>>> could be used instead). >>>>>>>> Let me make sure that I get your point here. The document >>>>>>>> says: "Propagation delay is the time taken for the >>>>>>>> packet to traverse the link from the source node to the >>>>>>>> target node." >>>>>>> Definition is clear enough but what bothers me is that =20 >>>>>>> "propagation delay" equals link length over propagation >>>>>>> speed in my book. Apparently the meaning here is more like =20 >>>>>>> transmission time + propagation delay (the latter as I've =20 >>>>>>> defined here). >>>>>> Ah I see what you mean, it is w/o transmission delay (just =20 >>>>>> propagation delay). We'll clarify. >>>>> Ok. >>>>>>>> I think that the notion of source and target node is =20 >>>>>>>> confusing and the text should read: " Propagation delay >>>>>>>> is the time taken for the packet to traverse the link. " >>>>>>> Do you mean including the transmission time? >>>>>>>> Does that clarify ? >>>>>>>>> Regarding the energy metric I can see a problem if only >>>>>>>>> one value is given (ie: remaining enery). The value >>>>>>>>> might be infinite to signal nodes without energy >>>>>>>>> restrictions, but for the remaining nodes, a single >>>>>>>>> value may not be enough. Let me elaborate on this with >>>>>>>>> an example: A node may have an overall lower >>>>>>>>> consumption than another one. If the former has >>>>>>>>> slightly less energy than the second one, then choosing >>>>>>>>> the later may not be the best choice for long term =20 >>>>>>>>> survivability of the network (this could be addressed >>>>>>>>> by advertising expected node lifetime instead of node's >>>>>>>>> remaining energy). >>>>>>>> Absolutely. The remaining energy metric may be difficult >>>>>>>> to interpret and the expected lifetime may be hard to >>>>>>>> compute. >>>>>>>>> On the other hand, without knowing the initial energy, >>>>>>>>> it's not possible to know what fraction of the original >>>>>>>>> energy is the remaining one. This could be addressesed >>>>>>>>> advertising remaining energy as a percentage (contrary >>>>>>>>> to the above paragraph approach). >>>>>>>> Yes or ... We may use a simple multi-threshold >>>>>>>> mechanisms: "Low, Medium, High" where: "LOW: avoid this >>>>>>>> node if possible" "Medium: no particular constraint" >>>>>>>> "HIGH: favor this node" Avoid/favor should of course be >>>>>>>> interpreted in the context of energy. What do you think ? >>>>>>> I think the high/medium/low approach may hurt some =20 >>>>>>> implementations over a numerical value (i.e: choosing >>>>>>> between two nodes with high value). >>>>>> But that may be "good" enough ... The issue with a numeric >>>>>> value is that it will be really hard to define a consistent >>>>>> way to compute the value *and* will be hard to use by the >>>>>> computation engine. Agree ? >>>>> Not really. As I see it local computation at a node is used to >>>>> determine the residual energy. Based on that (and may be other >>>>> constraints) node is tagged as high/medium/low. That energy >>>>> tag is used later for routing decisions. Nodes could advertise >>>>> the source data instead, residual energy. Doing that might make >>>>> routing calculations more complex, but not doing it restricts >>>>> the freedom of routing algorithm. Certainly the numeric value >>>>> could end up having a few bits and effectively becoming 2 or >>>>> four discrete values (similar to what you suggest). >>>> Looks like you are agreeing with the suggested use of a few >>>> discrete values (flags) used for constrained based routing ? >>> I disagree to use a such a discrete metric, allowing only a few >>> values. >>> The existing metric (IP number of hops) has a much higher >>> resolution, going from 15 vlaues for RIP to OSPF's huge 65535. >> It all depends on how we want to represent energy *and* for what =20 >> purpose. > > >> I never look only at what I want to model but what could be done with >> it. WE has for example in depth discussion on metrics, objective >> functions, ... in other WGs and many times people wanted to =20 >> standardize metrics and could be practically used by the routing =20 >> protocol, we know ho easy it is to come up with an NP complete >> problem. > > JP, > > I'm intrigued... > > What does NP-completeness have to do with a metric here? > > When you say "we all know" - is this as a Chair of this WG? Or as a > co-author of the metrics WG item? As a protocol designer ;-) (individual contributor) Cheers. JP. > > Alex > >> This is why we would like to advance the document in parallel with >> the routing protocol ! >> JP. >>> Alex >>>>>>>> But ... In any case, we need to avoid the definition of =20 >>>>>>>> metric that are implementation/node dependent. The way >>>>>>>> you model energy cannot be standardized. >>>>>>> We've to find a way to create an standard way for energy =20 >>>>>>> reporting. Haven't we? >>>>>> Heu ... You may want to try ... But certainly not trivial. >>>>> We've agreed on energy reporting. How this is done effectively >>>>> does not seem trivial but it has to be done for protocols to be >>>>> able to use that. My suggestion here is to report two energy >>>>> related values: residual energy in Joules and the same as a >>>>> percentage. >>>> OK let's wait to see what others say. I claim that a few flags >>>> are sufficient you would prefer to define a way to express >>>> energy. Let's try to converge on the list. >>>>>>>> We also need to ensure that nodes use consistent metrics >>>>>>>> (a fairly common problem). >>>>>>>>> And last, in certain network setups some nodes may be >>>>>>>>> easy to replace while others are not. You may want >>>>>>>>> batteries to die out more often on nodes that can have >>>>>>>>> their batteries replaced easily even though other >>>>>>>>> nearby nodes have more energy available. >>>>>>>> Absolutely, as defined in the industrial routing >>>>>>>> requirement document. This should be an administrative >>>>>>>> constraint. Energy metric need to be >>>>>>>>> complemented with other metrics. (Network survivability >>>>>>>>> is not the only factor we have to take into account). >>>>>>>> Right. Did you have a look at the other ones ? >>>>>>> I mostly agree with the rest, perhaps I'd chose PER (packet >>>>>>> error rate) metric instead of BER. >>>>>> One problem though: the PER of a function of packet size and >>>>>> can be computed knowing the BER anyway. Agree ? >>>>> Yes but non trivial (coding, iid errors). PER can be measured =20 >>>>> easily on the nodes (if link layer ACKs are used). That's why I >>>>> was suggesting it. >>>> Yes. Thanks. JP. >>>>> Kind regards, Miguel >>>> _______________________________________________ Roll mailing list >>>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > From mcr@marajade.sandelman.ca Wed May 13 11: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 8FADC3A6FCD for ; Wed, 13 May 2009 11:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.354 X-Spam-Level: X-Spam-Status: No, score=-1.354 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=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 zbGMUoyTwlED for ; Wed, 13 May 2009 11:21:41 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id C5B5728C224 for ; Wed, 13 May 2009 11:20:59 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [206.191.15.98]) by relay.sandelman.ca (Postfix) with ESMTPS id DB4B8341E1; Wed, 13 May 2009 18:22:31 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id E73474E813; Wed, 13 May 2009 14:22:30 -0400 (EDT) From: Michael Richardson To: Miguel Sanchez In-Reply-To: <86c3ed7b0905131005sfba99dy82e390c2dfbc0319@mail.gmail.com> References: <86c3ed7b0810300129w5ea1e843m4610566427245811@mail.gmail.com> <86c3ed7b0810310119y6c035b6en84f7ed9e9a2f1b6f@mail.gmail.com> <4A0AC25F.2060902@gmail.com> <86c3ed7b0905131005sfba99dy82e390c2dfbc0319@mail.gmail.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 13 May 2009 14:22:30 -0400 Message-ID: <2367.1242238950@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca X-Mailman-Approved-At: Thu, 14 May 2009 07:41:47 -0700 Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed 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, 13 May 2009 18:21:42 -0000 >>>>> "Miguel" =3D=3D Miguel Sanchez writes: Miguel> I'm not entirely happy with floating point numbers if 8-bit Miguel> micro controllers with not so much program memory (a few Miguel> KBytes) are involved. However I do like the idea of using Miguel> Energy units to express Energy values (whether it is Joules Miguel> or mJ integers are easier). Floating point is expressed as mantissa * 2^(exponent). I wonder if the mantissa is even important.=20=20 Does it matter if it costs 10 Joules or 20 Joules to transmit: the point is that it costs O(10^1)? --=20 ] Y'avait une poule de jamm=E9 dans l'muffler!!!!!!!!! | firewa= lls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"= ); [ From jvasseur@cisco.com Thu May 14 07:41: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 7968D3A6AE1 for ; Thu, 14 May 2009 07:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.399, 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 Qs-CAVy-fakt for ; Thu, 14 May 2009 07:41: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 5D6553A6D7E for ; Thu, 14 May 2009 07:41:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,194,1241395200"; d="scan'208,217";a="40607460" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 14 May 2009 14:42:45 +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 n4EEgjBI027621; Thu, 14 May 2009 16:42:45 +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 n4EEgjMa019304; Thu, 14 May 2009 14:42:45 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, 14 May 2009 16:42:45 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 May 2009 16:42:43 +0200 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4A0BE8EC.8060909@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-58--135525796 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 14 May 2009 16:42:42 +0200 References: <4A0AC1E9.40802@gmail.com> <7E4C3EE9-2607-49F1-BA37-76906BADBA64@cisco.com> <4A0BE8EC.8060909@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 14 May 2009 14:42:43.0983 (UTC) FILETIME=[3D9671F0:01C9D4A2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=43086; t=1242312165; x=1243176165; 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]=20ROLL=20Routing=20Metrics=20-=2 0WF=20feed-back=20needed |Sender:=20; bh=Cj5n4NEB+dFQ1p7NXVQjeKTd0jas88u9ACt/eujDF7Q=; b=popkC03vRaozJFzw2UeflpfQzdflBAlLs2BfdCoSiJs/PRk3BSUeKJqXh+ ZSBfZ2NgNbyLQupfhBapJb82l3NdauNx9I3gMsVYD7Bg2O2UZw/eQclAwhJb /M5SlEhxlQ; 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] ROLL Routing Metrics - WF feed-back needed 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, 14 May 2009 14:41:47 -0000 --Apple-Mail-58--135525796 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On May 14, 2009, at 11:48 AM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> On May 13, 2009, at 2:49 PM, Alexandru Petrescu wrote: >>> JP Vasseur a =E9crit : >>>> Hi, On 10/30/08 1:31 PM, "Miguel Sanchez" >>>> wrote: >>>>> Hi JP, On Thu, Oct 30, 2008 at 12:30 PM, JP Vasseur >>>>> wrote: >>>>>> Hi Miguel, On 10/30/08 11:56 AM, "Miguel Sanchez" >>>>>> wrote: >>>>>>> Hi JP, On Thu, Oct 30, 2008 at 10:02 AM, JP Vasseur = >>>>>> > wrote: >>>>>>>> Hi Miguel, On 10/30/08 9:29 AM, "Miguel Sanchez" >>>>>>>> wrote: >>>>>>>>> I've got a terminology problem with "propagation delay" >>>>>>>>> (5.3), while defined in the draft (and later defined >>>>>>>>> is path propagation) a new meaning is given to the >>>>>>>>> term. (For short range communications transmission time >>>>>>>>> could be used instead). >>>>>>>> Let me make sure that I get your point here. The document >>>>>>>> says: "Propagation delay is the time taken for the >>>>>>>> packet to traverse the link from the source node to the >>>>>>>> target node." >>>>>>> Definition is clear enough but what bothers me is that =20 >>>>>>> "propagation delay" equals link length over propagation >>>>>>> speed in my book. Apparently the meaning here is more like =20 >>>>>>> transmission time + propagation delay (the latter as I've =20 >>>>>>> defined here). >>>>>> Ah I see what you mean, it is w/o transmission delay (just =20 >>>>>> propagation delay). We'll clarify. >>>>> Ok. >>>>>>>> I think that the notion of source and target node is =20 >>>>>>>> confusing and the text should read: " Propagation delay >>>>>>>> is the time taken for the packet to traverse the link. " >>>>>>> Do you mean including the transmission time? >>>>>>>> Does that clarify ? >>>>>>>>> Regarding the energy metric I can see a problem if only >>>>>>>>> one value is given (ie: remaining enery). The value >>>>>>>>> might be infinite to signal nodes without energy >>>>>>>>> restrictions, but for the remaining nodes, a single >>>>>>>>> value may not be enough. Let me elaborate on this with >>>>>>>>> an example: A node may have an overall lower >>>>>>>>> consumption than another one. If the former has >>>>>>>>> slightly less energy than the second one, then choosing >>>>>>>>> the later may not be the best choice for long term =20 >>>>>>>>> survivability of the network (this could be addressed >>>>>>>>> by advertising expected node lifetime instead of node's >>>>>>>>> remaining energy). >>>>>>>> Absolutely. The remaining energy metric may be difficult >>>>>>>> to interpret and the expected lifetime may be hard to >>>>>>>> compute. >>>>>>>>> On the other hand, without knowing the initial energy, >>>>>>>>> it's not possible to know what fraction of the original >>>>>>>>> energy is the remaining one. This could be addressesed >>>>>>>>> advertising remaining energy as a percentage (contrary >>>>>>>>> to the above paragraph approach). >>>>>>>> Yes or ... We may use a simple multi-threshold >>>>>>>> mechanisms: "Low, Medium, High" where: "LOW: avoid this >>>>>>>> node if possible" "Medium: no particular constraint" >>>>>>>> "HIGH: favor this node" Avoid/favor should of course be >>>>>>>> interpreted in the context of energy. What do you think ? >>>>>>> I think the high/medium/low approach may hurt some =20 >>>>>>> implementations over a numerical value (i.e: choosing >>>>>>> between two nodes with high value). >>>>>> But that may be "good" enough ... The issue with a numeric >>>>>> value is that it will be really hard to define a consistent >>>>>> way to compute the value *and* will be hard to use by the >>>>>> computation engine. Agree ? >>>>> Not really. As I see it local computation at a node is used to >>>>> determine the residual energy. Based on that (and may be other >>>>> constraints) node is tagged as high/medium/low. That energy >>>>> tag is used later for routing decisions. Nodes could advertise >>>>> the source data instead, residual energy. Doing that might make >>>>> routing calculations more complex, but not doing it restricts >>>>> the freedom of routing algorithm. Certainly the numeric value >>>>> could end up having a few bits and effectively becoming 2 or >>>>> four discrete values (similar to what you suggest). >>>> Looks like you are agreeing with the suggested use of a few >>>> discrete values (flags) used for constrained based routing ? >>> I disagree to use a such a discrete metric, allowing only a few >>> values. >>> The existing metric (IP number of hops) has a much higher >>> resolution, going from 15 vlaues for RIP to OSPF's huge 65535. >> It all depends on how we want to represent energy *and* for what =20 >> purpose. > > >> I never look only at what I want to model but what could be done with >> it. WE has for example in depth discussion on metrics, objective >> functions, ... in other WGs and many times people wanted to =20 >> standardize metrics and could be practically used by the routing =20 >> protocol, we know ho easy it is to come up with an NP complete >> problem. > > JP, > > I'm intrigued... > > What does NP-completeness have to do with a metric here? Defining metric is fairly easy ... the issue is what you with it. In =20 other words, take two metrics M1 and M2. Try to compute the "best" =20 path according to M1 and M2 and you have an NP complete problem. I am =20= of course not saying that we will ned up with only one of course and =20 one can use one at a time, many of them using a hierarchical approach, =20= as tie breaker, ... but it is necessary to move the metric document in =20= parallel with the protocol spec. Thanks. JP. > > When you say "we all know" - is this as a Chair of this WG? Or as a > co-author of the metrics WG item? > > Alex > >> This is why we would like to advance the document in parallel with >> the routing protocol ! >> JP. >>> Alex >>>>>>>> But ... In any case, we need to avoid the definition of =20 >>>>>>>> metric that are implementation/node dependent. The way >>>>>>>> you model energy cannot be standardized. >>>>>>> We've to find a way to create an standard way for energy =20 >>>>>>> reporting. Haven't we? >>>>>> Heu ... You may want to try ... But certainly not trivial. >>>>> We've agreed on energy reporting. How this is done effectively >>>>> does not seem trivial but it has to be done for protocols to be >>>>> able to use that. My suggestion here is to report two energy >>>>> related values: residual energy in Joules and the same as a >>>>> percentage. >>>> OK let's wait to see what others say. I claim that a few flags >>>> are sufficient you would prefer to define a way to express >>>> energy. Let's try to converge on the list. >>>>>>>> We also need to ensure that nodes use consistent metrics >>>>>>>> (a fairly common problem). >>>>>>>>> And last, in certain network setups some nodes may be >>>>>>>>> easy to replace while others are not. You may want >>>>>>>>> batteries to die out more often on nodes that can have >>>>>>>>> their batteries replaced easily even though other >>>>>>>>> nearby nodes have more energy available. >>>>>>>> Absolutely, as defined in the industrial routing >>>>>>>> requirement document. This should be an administrative >>>>>>>> constraint. Energy metric need to be >>>>>>>>> complemented with other metrics. (Network survivability >>>>>>>>> is not the only factor we have to take into account). >>>>>>>> Right. Did you have a look at the other ones ? >>>>>>> I mostly agree with the rest, perhaps I'd chose PER (packet >>>>>>> error rate) metric instead of BER. >>>>>> One problem though: the PER of a function of packet size and >>>>>> can be computed knowing the BER anyway. Agree ? >>>>> Yes but non trivial (coding, iid errors). PER can be measured =20 >>>>> easily on the nodes (if link layer ACKs are used). That's why I >>>>> was suggesting it. >>>> Yes. Thanks. JP. >>>>> Kind regards, Miguel >>>> _______________________________________________ Roll mailing list >>>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > --Apple-Mail-58--135525796 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On May 14, 2009, = at 11:48 AM, Alexandru Petrescu wrote:

JP = Vasseur a =E9crit :
On May 13, 2009, at = 2:49 PM, Alexandru Petrescu wrote:
JP Vasseur a =E9crit = :
Hi, On 10/30/08 1:31 PM, "Miguel = Sanchez" <misan@disca.upv.es>
wrote:
Hi JP, On Thu, Oct 30, 2008 at = 12:30 PM, JP = Vasseur
<jvasseur@cisco.com> = wrote:
Hi = Miguel, On 10/30/08 11:56 AM, "Miguel = Sanchez"
<misan@disca.upv.es> = wrote:
Hi JP, On Thu, Oct 30, 2008 at = 10:02 AM, JP Vasseur <jvasseur@cisco.com> = wrote:
Hi Miguel, On 10/30/08 9:29 AM, = "Miguel = Sanchez"
<misan@disca.upv.es> = wrote:
I've = got a terminology problem with "propagation = delay"
(5.3), while defined in the = draft (and later = defined
is path propagation) a new = meaning is given to = the
term. = (For short range communications transmission = time
<= /blockquote>
could be used = instead).
Let me = make sure that I get your point here. The = document
says: "Propagation delay is the = time taken for = the
packet to traverse the link from = the source node to = the
target = node."
Definition is clear enough but what bothers me is that = "propagation delay" equals link length over = propagation
speed = in my book. Apparently the meaning here is more like transmission time + = propagation delay (the latter as I've defined = here).
Ah I see what you mean, it is = w/o transmission delay (just propagation delay). We'll = clarify.
Ok.
<= blockquote type=3D"cite">
I = think that the notion of source and target node is confusing and the = text should read: " Propagation = delay
=
is the time taken for the packet = to traverse the link. = "
Do you = mean including the transmission = time?
=
Does that clarify = ?
Regarding the energy metric I can see a problem if = only
<= /blockquote>
one value is given (ie: = remaining enery). The = value
=
might be infinite to signal = nodes without = energy
restrictions, but for the = remaining nodes, a = single
value may not be enough. Let me = elaborate on this = with
<= /blockquote>
an example: A node may have an = overall = lower
=
consumption than another one. If = the former = has
slightly= less energy than the second one, then = choosing
the later may not be the best = choice for long term survivability of the network (this could be = addressed
by advertising expected node = lifetime instead of = node's
remaining = energy).
Absolutely. The remaining energy metric may be = difficult
to interpret and the expected = lifetime may be hard = to
compute.
On the other hand, without = knowing the initial = energy,
it's not possible to know what = fraction of the = original
energy is the remaining one. = This could be = addressesed
advertising remaining energy as = a percentage = (contrary
to the above paragraph = approach).
Yes or = ... We may use a simple = multi-threshold
mechanisms: "Low, Medium, High" = where: "LOW: avoid = this
<= /blockquote>
node if possible" "Medium: no = particular = constraint"
"HIGH: favor this node" = Avoid/favor should of course = be
interpreted in the context of = energy. What do you think = ?
I = think the high/medium/low approach may hurt some implementations over a = numerical value (i.e: = choosing
between = two nodes with high = value).
But that may be "good" enough = ... The issue with a = numeric
value = is that it will be really hard to define a = consistent
way to = compute the value *and* will be hard to use by = the
computation engine. Agree = ?
Not really. As I see it local = computation at a node is used = to
determine the residual energy. = Based on that (and may be = other
constraints) node is tagged as = high/medium/low. That = energy
tag is used later for routing = decisions. Nodes could = advertise
the source data instead, = residual energy. Doing that might = make
routing calculations more = complex, but not doing it = restricts
the freedom of routing = algorithm. Certainly the numeric = value
could end up having a few bits = and effectively becoming 2 = or
four discrete values (similar to = what you = suggest).
Looks= like you are agreeing with the suggested use of a = few
discrete= values (flags) used for constrained based routing = ?
I disagree to use a such a = discrete metric, allowing only a = few
values.
The existing metric (IP number = of hops) has a much higher
resolution, going from 15 vlaues = for RIP to OSPF's huge 65535.
It all depends on how we want to represent energy *and* = for what purpose.
>
I = never look only at what I want to model but what could be done = with
it. WE has for example in = depth discussion on metrics, objective
functions, ... in other WGs and many times people wanted = to standardize metrics and could be practically used by the routing = protocol, we know ho easy it is to come up with an NP = complete
problem.

JP,

I'm = intrigued...

What does NP-completeness have to do with a metric = here?

Defining metric is = fairly easy ... the issue is what you with it. In other words, take two = metrics M1 and M2. Try to compute the "best" path according to M1 = and M2 and you have an NP complete problem. I am of course not = saying that we will ned up with only one of course and one can use one = at a time, many of them using a hierarchical approach, as tie breaker, = ... but it is necessary to move the metric document = in parallel with the protocol = spec.

Thanks.

JP.
<= br>

When you say "we all know" - is = this as a Chair of this WG?  Or as a
co-author of the metrics WG = item?

Alex

This is why we would = like to advance the document in parallel = with
the routing protocol = !
JP.
Alex
But = ... In any case, we need to avoid the definition of metric that are = implementation/node dependent. The = way
you model energy cannot be = standardized.
We've = to find a way to create an standard way for energy reporting. Haven't = we?
Heu = ... You may want to try ... But certainly not = trivial.
We've agreed on energy = reporting. How this is done = effectively
does not seem trivial but it has = to be done for protocols to = be
able to use that. My suggestion = here is to report two = energy
related values: residual energy = in Joules and the same as = a
percentage.
OK let's wait to see what others say. I claim that a few = flags
are = sufficient you would prefer to define a way to = express
energy. = Let's try to converge on the = list.
We = also need to ensure that nodes use consistent = metrics
(a fairly common = problem).
And = last, in certain network setups some nodes may = be
easy = to replace while others are not. You may = want
<= /blockquote>
batteries to die out more often = on nodes that can = have
<= /blockquote>
their batteries replaced easily = even though = other
=
nearby nodes have more energy = available.
Absolutely, as defined in the industrial = routing
requirement document. This = should be an = administrative
constraint. Energy metric need = to = be
complemented with other metrics. (Network = survivability
is not the only factor we have = to take into = account).
Right. = Did you have a look at the other ones = ?
I = mostly agree with the rest, perhaps I'd chose PER = (packet
error = rate) metric instead of = BER.
<= /blockquote>
One problem though: the PER of a = function of packet size = and
can be = computed knowing the BER anyway. Agree = ?
Yes but non trivial (coding, iid = errors). PER can be measured easily on the nodes (if link layer ACKs are = used). That's why = I
was suggesting = it.
Yes. = Thanks. JP.
Kind regards, = Miguel
_______________________________________________ Roll = mailing list
= Roll@ietf.org https://www.ietf.org/m= ailman/listinfo/roll


= --Apple-Mail-58--135525796-- From pal@cs.stanford.edu Thu May 14 07:49:35 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 0F3BF28C26F; Thu, 14 May 2009 07:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 NjcT8vizUpIb; Thu, 14 May 2009 07:49:34 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 5343328C26E; Thu, 14 May 2009 07:49:34 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1M4cH5-0000WW-C1; Thu, 14 May 2009 07:51:07 -0700 Message-Id: From: Philip Levis To: JP Vasseur In-Reply-To: <314C5D40-78D3-4F66-AD40-093588E2233F@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: Thu, 14 May 2009 10:51:10 -0400 References: <314C5D40-78D3-4F66-AD40-093588E2233F@cisco.com> X-Mailer: Apple Mail (2.930.3) X-Scan-Signature: ff384b2b9a2989b26e23b1d864f6aba2 Cc: roll-bounces@ietf.org, "Dearlove, Christopher \(UK\)" , ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] Few comments for our first discussion today 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, 14 May 2009 14:49:35 -0000 On May 14, 2009, at 10:37 AM, JP Vasseur wrote: > That is an excellent suggestion. Since regrouping the requirements > (MUST) is a starting point, we'll make sure to send it to the list. > Note that the point is not to rediscuss any of these of course. Clearly the MUSTs are simply a synthesis of the application drafts and so not really worth discussing, unless WG members find a misreading or typo. That being said, the breakdown of what's "core" and what's "optional" may be worth discussion. Of course, this discussion would be more productive if it strove to better understand the DT's approach, rather than question it at this early stage. Phil From Chris.Dearlove@baesystems.com Thu May 14 08:04: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 0851D28C2A3; Thu, 14 May 2009 08:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.443 X-Spam-Level: X-Spam-Status: No, score=-4.443 tagged_above=-999 required=5 tests=[AWL=-1.844, 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 uG8da0Z9e6BO; Thu, 14 May 2009 08:04:29 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 9F1BB28C273; Thu, 14 May 2009 08:04:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,194,1241391600"; d="scan'208";a="2320657" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 14 May 2009 16:05:58 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n4EF5tPF014409; Thu, 14 May 2009 16:05:55 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 May 2009 16:05:55 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 14 May 2009 16:05:58 +0100 Message-ID: In-Reply-To: <314C5D40-78D3-4F66-AD40-093588E2233F@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Few comments for our first discussion today Thread-Index: AcnUoaPVnhUTLz41RK20MTD1BQjUAQAAEcSg References: <314C5D40-78D3-4F66-AD40-093588E2233F@cisco.com> From: "Dearlove, Christopher (UK)" To: "JP Vasseur" , "Jerald P Martocci" X-OriginalArrivalTime: 14 May 2009 15:05:55.0385 (UTC) FILETIME=[7AED8A90:01C9D4A5] Cc: roll-bounces@ietf.org, ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] Few comments for our first discussion today 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, 14 May 2009 15:04:30 -0000 JP Vasseur > That is an excellent suggestion. Since regrouping the requirements > (MUST) is a starting point, we'll make sure to send it to the list. > Note that the point is not to rediscuss any of these of course. If there are any resolutions of differences between the documents then to that extent, discussing the MUSTs is inevitable, you can't simply say don't rediscuss. And there are significant differences. The number of nodes to support varies (and by a couple of orders of magnitude). The route finding time varies from seconds to minutes. Yes, you could say "take the worst case for each". But now you have a large network, with a low latency - and a specification (in one of the drafts) for any peer to peer routing. And authentication has to be both compulsory and optional (OK, SHOULD technically rather than MUST for the latter, but still an issue - and I haven't checked all details of all four drafts). If anyone can achieve all the MUSTs (let alone the SHOULDs) in all drafts, excellent. But I suspect not, as document A may make a demand that's reasonable for its (for example) lower number of nodes, but not so easy for document B's higher number of nodes, especially in combination with document C's latency. I strongly suspect some trading off of requirements will be needed. And that's going to need agreement. ******************************************************************** 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 Chris.Dearlove@baesystems.com Thu May 14 08:09: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 4D2DE3A6FB0; Thu, 14 May 2009 08:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.419 X-Spam-Level: X-Spam-Status: No, score=-4.419 tagged_above=-999 required=5 tests=[AWL=-1.820, 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 0q9UEut9nZ0J; Thu, 14 May 2009 08:08:59 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 8810B28C2A3; Thu, 14 May 2009 08:08:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,194,1241391600"; d="scan'208";a="2322287" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 14 May 2009 16:10:24 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n4EFAOuG017588; Thu, 14 May 2009 16:10:24 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 May 2009 16:10:24 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 14 May 2009 16:10:27 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Few comments for our first discussion today Thread-Index: AcnUo3KFlZv3bEjmTkOZGjpgfMvr2AAAgsrQ References: <314C5D40-78D3-4F66-AD40-093588E2233F@cisco.com> From: "Dearlove, Christopher (UK)" To: "Philip Levis" , "JP Vasseur" X-OriginalArrivalTime: 14 May 2009 15:10:24.0071 (UTC) FILETIME=[1B13C570:01C9D4A6] Cc: roll-bounces@ietf.org, ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] Few comments for our first discussion today 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, 14 May 2009 15:09:00 -0000 Philip Levis > Clearly the MUSTs are simply a synthesis of the application drafts and > so not really worth discussing, unless WG members find a misreading or > typo. I think that is absolutely not the case. What's your synthesis, all worst cases to be supported simultaneously? Something else? > Of course, this discussion would be more > productive if it strove to better understand the DT's approach, > rather than question it at this early stage. I would love to understand the DT's approach. Where is it explained, in particular with regard to how conflicting requirements are being reconciled? ******************************************************************** 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 alexandru.petrescu@gmail.com Thu May 14 08:27: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 7AB203A6F05 for ; Thu, 14 May 2009 08:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=0.112, 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 2jkNi3QNZJhS for ; Thu, 14 May 2009 08:27:22 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 79CAD3A684E for ; Thu, 14 May 2009 08:27:22 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n4EFSE0X009049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 May 2009 17:28:14 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n4EFSDao030486; Thu, 14 May 2009 17:28:14 +0200 (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 n4EFSDsi013218; Thu, 14 May 2009 17:28:13 +0200 Message-ID: <4A0C388D.4040804@gmail.com> Date: Thu, 14 May 2009 17:28:13 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: JP Vasseur References: <4A0AC1E9.40802@gmail.com> <7E4C3EE9-2607-49F1-BA37-76906BADBA64@cisco.com> <4A0BE8EC.8060909@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] ROLL Routing Metrics - WF feed-back needed 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, 14 May 2009 15:27:23 -0000 JP Vasseur a écrit : [...] >>>> The existing metric (IP number of hops) has a much higher >>>> resolution, going from 15 vlaues for RIP to OSPF's huge 65535. >>> It all depends on how we want to represent energy *and* for what >>> purpose. >>> >>> I never look only at what I want to model but what could be done >>> with it. WE has for example in depth discussion on metrics, >>> objective functions, ... in other WGs and many times people >>> wanted to standardize metrics and could be practically used by >>> the routing protocol, we know ho easy it is to come up with an NP >>> complete problem. >> >> JP, >> >> I'm intrigued... >> >> What does NP-completeness have to do with a metric here? > > Defining metric is fairly easy ... the issue is what you with it. In > other words, take two metrics M1 and M2. Try to compute the "best" > path according to M1 *and* M2 and you have an NP complete problem. You seem to assume that trying to compute the best path only according to M1 is not an NP complete problem. Well, if instead of "M1 _and_ M2" we say "M1+M2", then this would be a not NP complete problem. I.e., if 1hopcount+1joule makes for metric 2hopcountjoule then this is not an NP complete problem, which is good, right? However, if we say 1hopcount can't be added to a selected value from (unlimited, scavenging, ok, low), because they're different types, then we may have an NP complete problem, right? Alex From pal@cs.stanford.edu Thu May 14 09:46:52 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 70F623A6CDA for ; Thu, 14 May 2009 09:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.516 X-Spam-Level: X-Spam-Status: No, score=-5.516 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 DFEDVwLa4Pwd for ; Thu, 14 May 2009 09:46:51 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id AAFB83A6B99 for ; Thu, 14 May 2009 09:46:51 -0700 (PDT) Received: from dnab4220ec.stanford.edu ([171.66.32.236]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1M4e6Z-0003Z5-6D; Thu, 14 May 2009 09:48:24 -0700 Message-Id: <907523DB-5E37-446D-86CE-6117B93A3225@cs.stanford.edu> From: Philip Levis To: Michael Richardson In-Reply-To: <2367.1242238950@marajade.sandelman.ca> 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, 14 May 2009 11:46:24 -0400 References: <86c3ed7b0810300129w5ea1e843m4610566427245811@mail.gmail.com> <86c3ed7b0810310119y6c035b6en84f7ed9e9a2f1b6f@mail.gmail.com> <4A0AC25F.2060902@gmail.com> <86c3ed7b0905131005sfba99dy82e390c2dfbc0319@mail.gmail.com> <2367.1242238950@marajade.sandelman.ca> X-Mailer: Apple Mail (2.930.3) X-Scan-Signature: f219e97bb238ccbb8ed40879dafdba3c Cc: ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed 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, 14 May 2009 16:46:52 -0000 On May 13, 2009, at 2:22 PM, Michael Richardson wrote: > >>>>>> "Miguel" == Miguel Sanchez writes: > Miguel> I'm not entirely happy with floating point numbers if 8-bit > Miguel> micro controllers with not so much program memory (a few > Miguel> KBytes) are involved. However I do like the idea of using > Miguel> Energy units to express Energy values (whether it is Joules > Miguel> or mJ integers are easier). > > Floating point is expressed as mantissa * 2^(exponent). > I wonder if the mantissa is even important. > > Does it matter if it costs 10 Joules or 20 Joules to transmit: the > point is that it costs O(10^1)? As an aside, floating point for routing metrics can cause problems. These problems are not insurmountable, but it's important to recognize them and design routing protocols appropriately. In particular, using floating point means that route costs will not necessarily be monotonically increasing: if a link cost is very small compared to the overall route cost, it can be lost in the exponent. The lack of monotonicity means that you cannot depend on the metric to detect loops, unless you add some special cases (e.g., always add). I raised this issue in the MANET link metric discussions (August 15, 2007). Phil From Jerald.P.Martocci@jci.com Thu May 14 10:03: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 502653A7058; Thu, 14 May 2009 10:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.605 X-Spam-Level: X-Spam-Status: No, score=-6.605 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 UnlWdueAUNWq; Thu, 14 May 2009 10:03:12 -0700 (PDT) Received: from exprod8og109.obsmtp.com (exprod8og109.obsmtp.com [64.18.3.98]) by core3.amsl.com (Postfix) with ESMTP id 1F01628C31F; Thu, 14 May 2009 10:02:31 -0700 (PDT) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob109.postini.com ([64.18.7.12]) with SMTP ID DSNKSgxOefTq4jYjJCMwkkigBGlz8SgX6uX8@postini.com; Thu, 14 May 2009 10:04:04 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009051412033738-3394604 ; Thu, 14 May 2009 12:03:37 -0500 In-Reply-To: MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Thu, 14 May 2009 12:01:10 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 05/14/2009 12:01:14 PM, Serialize complete at 05/14/2009 12:01:14 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 05/14/2009 12:03:37 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 05/14/2009 12:06:26 PM, Serialize complete at 05/14/2009 12:06:26 PM Content-Type: multipart/alternative; boundary="=_alternative 005D7D71862575B6_=" Cc: roll-bounces@ietf.org, ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] Few comments for our first discussion today 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, 14 May 2009 17:03:13 -0000 This is a multipart message in MIME format. --=_alternative 005D7D71862575B6_= Content-Type: text/plain; charset="US-ASCII" I couldn't have stated it better than Christopher. As one of the document authors (commercial buildings), I purposely spent little time reviewing the other 3 documents since I didn't want to taint my requirements by understanding the other requirements too well. I know the other authors didn't review my document since my document was drafted months after the other three. As was noted in San Francisco, we need to concern ourselves with the 'duck' syndrome. That is, when God created the duck he decided to make one animal that could swim, fly and walk. He got what he designed, except now the poor thing can't do any of them too well. If we simply take all the MUSTs as absolutes, we will be creating our own duck. I would be willing to 'rack and stack' my requirements with others. The worst that could happen is we decide we must have all our MUSTs which is where we are now. More likely, we will be able to assimilate the list into a more refined prioritized list that would better assist the DT. Jerry "Dearlove, Christopher (UK)" 05/14/2009 10:06 AM To "JP Vasseur" , "Jerald P Martocci" cc , "Philip Levis" , "ROLL WG" , Subject RE: [Roll] Few comments for our first discussion today JP Vasseur > That is an excellent suggestion. Since regrouping the requirements > (MUST) is a starting point, we'll make sure to send it to the list. > Note that the point is not to rediscuss any of these of course. If there are any resolutions of differences between the documents then to that extent, discussing the MUSTs is inevitable, you can't simply say don't rediscuss. And there are significant differences. The number of nodes to support varies (and by a couple of orders of magnitude). The route finding time varies from seconds to minutes. Yes, you could say "take the worst case for each". But now you have a large network, with a low latency - and a specification (in one of the drafts) for any peer to peer routing. And authentication has to be both compulsory and optional (OK, SHOULD technically rather than MUST for the latter, but still an issue - and I haven't checked all details of all four drafts). If anyone can achieve all the MUSTs (let alone the SHOULDs) in all drafts, excellent. But I suspect not, as document A may make a demand that's reasonable for its (for example) lower number of nodes, but not so easy for document B's higher number of nodes, especially in combination with document C's latency. I strongly suspect some trading off of requirements will be needed. And that's going to need agreement. ******************************************************************** 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. ******************************************************************** --=_alternative 005D7D71862575B6_= Content-Type: text/html; charset="US-ASCII"

I couldn't have stated it better than Christopher.  As one of the document authors (commercial buildings), I purposely spent little time reviewing the other 3 documents since I didn't want to taint my requirements by understanding the other requirements too well.  I know the other authors didn't review my document since my document was drafted months after the other three.

As was noted in San Francisco, we need to concern ourselves with the 'duck' syndrome. That is, when God created the duck he decided to make one animal that could swim, fly and walk.  He got what he designed, except now the poor thing can't do any of them too well.  If we simply take all the MUSTs as absolutes, we will be creating our own duck.  

I would be willing to 'rack and stack' my requirements with others.  The worst that could happen is we decide we must have all our MUSTs which is where we are now.  More likely, we will be able to assimilate the list into a more refined prioritized list that would better assist the DT.

Jerry





"Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>

05/14/2009 10:06 AM

To
"JP Vasseur" <jvasseur@cisco.com>, "Jerald P Martocci" <Jerald.P.Martocci@jci.com>
cc
<dtroll@external.cisco.com>, "Philip Levis" <pal@cs.stanford.edu>, "ROLL WG" <roll@ietf.org>, <roll-bounces@ietf.org>
Subject
RE: [Roll] Few comments for our first discussion today





JP Vasseur
>  That is an excellent suggestion. Since regrouping the requirements
> (MUST) is a starting point, we'll make sure to send it to the list.
>  Note that the point is not to rediscuss any of these of course.

If there are any resolutions of differences between the documents
then to that extent, discussing the MUSTs is inevitable, you can't
simply say don't rediscuss.

And there are significant differences. The number of nodes to support
varies (and by a couple of orders of magnitude). The route finding
time varies from seconds to minutes. Yes, you could say "take the
worst case for each". But now you have a large network, with a low
latency - and a specification (in one of the drafts) for any peer
to peer routing. And authentication has to be both compulsory and
optional (OK, SHOULD technically rather than MUST for the latter,
but still an issue - and I haven't checked all details of all four
drafts).

If anyone can achieve all the MUSTs (let alone the SHOULDs) in all
drafts, excellent. But I suspect not, as document A may make a
demand that's reasonable for its (for example) lower number of nodes,
but not so easy for document B's higher number of nodes, especially
in combination with document C's latency. I strongly suspect some
trading off of requirements will be needed. And that's going to need
agreement.

********************************************************************
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.
********************************************************************
--=_alternative 005D7D71862575B6_=-- From jvasseur@cisco.com Thu May 14 10:09: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 909833A68AB; Thu, 14 May 2009 10:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.203 X-Spam-Level: X-Spam-Status: No, score=-10.203 tagged_above=-999 required=5 tests=[AWL=0.395, 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 bvImu3sQjQm5; Thu, 14 May 2009 10:09:31 -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 427A53A688B; Thu, 14 May 2009 10:09:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,195,1241395200"; d="scan'208,217";a="40621092" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 May 2009 17:11:02 +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 n4EHB2jC014636; Thu, 14 May 2009 19:11:02 +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 n4EHB2fn005915; Thu, 14 May 2009 17:11:02 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, 14 May 2009 19:11:02 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 May 2009 19:11:01 +0200 Message-Id: From: JP Vasseur To: Jerald.P.Martocci@jci.com In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-92--126628198 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 14 May 2009 19:11:00 +0200 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 14 May 2009 17:11:01.0690 (UTC) FILETIME=[F508C9A0:01C9D4B6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10247; t=1242321062; x=1243185062; 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]=20Few=20comments=20for=20our=20f irst=20discussion=20today |Sender:=20; bh=c/++FuaBLg/HOop88f26JSnn5GQNAIp2qKS5Sf4uGk4=; b=kSN7tqxWfI7DWTbEDOiLA4SCUxmnkBBPV9rb1D4TV3Vnwqrn4de406Plmb kbPwDtNorFeGMtnkVV924ASYGSpIdbpMuqz5DjyeXkN6fbOGq/K32U3aykDf WXDiqukvVg; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll-bounces@ietf.org, "Dearlove, Christopher \(UK\)" , ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] Few comments for our first discussion today 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, 14 May 2009 17:09:32 -0000 --Apple-Mail-92--126628198 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On May 14, 2009, at 7:01 PM, Jerald.P.Martocci@jci.com wrote: > > > I couldn't have stated it better than Christopher. As one of the > document authors (commercial buildings), I purposely spent little > time reviewing the other 3 documents since I didn't want to taint my > requirements by understanding the other requirements too well. I > know the other authors didn't review my document since my document > was drafted months after the other three. > > As was noted in San Francisco, we need to concern ourselves with the > 'duck' syndrome. That is, when God created the duck he decided to > make one animal that could swim, fly and walk. He got what he > designed, except now the poor thing can't do any of them too well. > If we simply take all the MUSTs as absolutes, we will be creating > our own duck. I cannot agree more. > > > I would be willing to 'rack and stack' my requirements with others. > The worst that could happen is we decide we must have all our MUSTs > which is where we are now. Just a re-assure you ... I think that we are all on the same page, we will have to make compromises. That being said, and there are many examples of such protocols, the idea is to build a modular protocol with a minimal "core" of basic functions and optional features that could be used in different environments activating the required options only when necessary. > More likely, we will be able to assimilate the list into a more > refined prioritized list that would better assist the DT. > > Jerry > > > > > > "Dearlove, Christopher (UK)" > 05/14/2009 10:06 AM > > To > "JP Vasseur" , "Jerald P Martocci" > > cc > , "Philip Levis" , > "ROLL WG" , > Subject > RE: [Roll] Few comments for our first discussion today > > > > > > JP Vasseur > > That is an excellent suggestion. Since regrouping the requirements > > (MUST) is a starting point, we'll make sure to send it to the list. > > Note that the point is not to rediscuss any of these of course. > > If there are any resolutions of differences between the documents > then to that extent, discussing the MUSTs is inevitable, you can't > simply say don't rediscuss. > > And there are significant differences. The number of nodes to support > varies (and by a couple of orders of magnitude). The route finding > time varies from seconds to minutes. Yes, you could say "take the > worst case for each". But now you have a large network, with a low > latency - and a specification (in one of the drafts) for any peer > to peer routing. And authentication has to be both compulsory and > optional (OK, SHOULD technically rather than MUST for the latter, > but still an issue - and I haven't checked all details of all four > drafts). > > If anyone can achieve all the MUSTs (let alone the SHOULDs) in all > drafts, excellent. But I suspect not, as document A may make a > demand that's reasonable for its (for example) lower number of nodes, > but not so easy for document B's higher number of nodes, especially > in combination with document C's latency. I strongly suspect some > trading off of requirements will be needed. And that's going to need > agreement. > > ******************************************************************** > 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. > ******************************************************************** > > --Apple-Mail-92--126628198 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On May 14, 2009, = at 7:01 PM, Jerald.P.Martocci@jci.com = wrote:



I couldn't = have stated it better than Christopher.  As one of the document = authors (commercial buildings), I purposely spent little time reviewing = the other 3 documents since I didn't want to taint my requirements by = understanding the other requirements too well.  I know the other = authors didn't review my document since my document was drafted months = after the other three.

As was noted in San Francisco, we need to concern = ourselves with the 'duck' syndrome. That is, when God created the duck = he decided to make one animal that could swim, fly and walk.  He = got what he designed, except now the poor thing can't do any of them too = well.  If we simply take all the MUSTs as absolutes, we will be = creating our own duck.

I cannot = agree more.

 

I would be willing to 'rack and stack' my = requirements with others.  The worst that could happen is we decide = we must have all our MUSTs which is where we are now. =  

Just a re-assure you ... I = think that we are all on the same page, we will have to make = compromises.

That being said, and there are = many examples of such protocols, the idea is to build a modular protocol = with a minimal "core" of basic functions and optional features that = could be used in different environments activating the required options = only when necessary. 

More likely, we will be able to = assimilate the list into a more refined prioritized list that would = better assist the DT.

Jerry





"Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.co= m>

05/14/2009 = 10:06 AM

=
To
"JP Vasseur" <jvasseur@cisco.com>, "Jerald P = Martocci" <Jerald.P.Martocci@jci.com>= ;
cc
<dtroll@external.cisco.com>= ;, "Philip Levis" <pal@cs.stanford.edu>, "ROLL = WG" <roll@ietf.org>, <roll-bounces@ietf.org>=
Subject
RE: [Roll] Few comments for our first discussion = today

=



JP = Vasseur
>  That is an excellent suggestion. Since regrouping = the requirements
> (MUST) is a starting point, we'll make sure = to send it to the list.
>  Note that the point is not to = rediscuss any of these of course.

If there are any resolutions = of differences between the documents
then to that extent, discussing = the MUSTs is inevitable, you can't
simply say don't rediscuss.
=
And there are significant differences. The number of nodes to = support
varies (and by a couple of orders of magnitude). The route = finding
time varies from seconds to minutes. Yes, you could say = "take the
worst case for each". But now you have a large network, = with a low
latency - and a specification (in one of the drafts) for = any peer
to peer routing. And authentication has to be both = compulsory and
optional (OK, SHOULD technically rather than MUST for = the latter,
but still an issue - and I haven't checked all details = of all four
drafts).

If anyone can achieve all the MUSTs = (let alone the SHOULDs) in all
drafts, excellent. But I suspect not, = as document A may make a
demand that's reasonable for its (for = example) lower number of nodes,
but not so easy for document B's = higher number of nodes, especially
in combination with document C's = latency. I strongly suspect some
trading off of requirements will be = needed. And that's going to need
agreement.

= ********************************************************************
= 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.
= ********************************************************************
=


= --Apple-Mail-92--126628198-- From Jerald.P.Martocci@jci.com Thu May 14 10:09: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 F1C333A68A8; Thu, 14 May 2009 10:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.522 X-Spam-Level: X-Spam-Status: No, score=-5.522 tagged_above=-999 required=5 tests=[AWL=-1.090, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 Yq8CElDnO2ja; Thu, 14 May 2009 10:09:57 -0700 (PDT) Received: from exprod8og101.obsmtp.com (exprod8og101.obsmtp.com [64.18.3.82]) by core3.amsl.com (Postfix) with ESMTP id B38F828C273; Thu, 14 May 2009 10:09:56 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob101.postini.com ([64.18.7.12]) with SMTP ID DSNKSgxQwfTS0s2qCUvAowAP/+GAIzFHQsbn@postini.com; Thu, 14 May 2009 10:11:30 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009051412122082-4323134 ; Thu, 14 May 2009 12:12:20 -0500 In-Reply-To: <907523DB-5E37-446D-86CE-6117B93A3225@cs.stanford.edu> MIME-Version: 1.0 To: Philip Levis X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Thu, 14 May 2009 12:11:15 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 05/14/2009 12:11:16 PM, Serialize complete at 05/14/2009 12:11:16 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 05/14/2009 12:12:20 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 05/14/2009 12:12:33 PM, Serialize complete at 05/14/2009 12:12:33 PM Content-Type: multipart/alternative; boundary="=_alternative 005E69C5862575B6_=" Cc: roll-bounces@ietf.org, Michael Richardson , ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed 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, 14 May 2009 17:09:58 -0000 This is a multipart message in MIME format. --=_alternative 005E69C5862575B6_= Content-Type: text/plain; charset="US-ASCII" You can't assume that an 8-bit processor has intrinsic floating point support. If the sensor is measuring temperature, you might expect they would support floating point. (Not all of our do). However, a binary sensor (e.g. a window tamper switch) clearly won't have floating point support. Jerry Philip Levis Sent by: roll-bounces@ietf.org 05/14/2009 11:48 AM To Michael Richardson cc ROLL WG Subject Re: [Roll] ROLL Routing Metrics - WF feed-back needed On May 13, 2009, at 2:22 PM, Michael Richardson wrote: > >>>>>> "Miguel" == Miguel Sanchez writes: > Miguel> I'm not entirely happy with floating point numbers if 8-bit > Miguel> micro controllers with not so much program memory (a few > Miguel> KBytes) are involved. However I do like the idea of using > Miguel> Energy units to express Energy values (whether it is Joules > Miguel> or mJ integers are easier). > > Floating point is expressed as mantissa * 2^(exponent). > I wonder if the mantissa is even important. > > Does it matter if it costs 10 Joules or 20 Joules to transmit: the > point is that it costs O(10^1)? As an aside, floating point for routing metrics can cause problems. These problems are not insurmountable, but it's important to recognize them and design routing protocols appropriately. In particular, using floating point means that route costs will not necessarily be monotonically increasing: if a link cost is very small compared to the overall route cost, it can be lost in the exponent. The lack of monotonicity means that you cannot depend on the metric to detect loops, unless you add some special cases (e.g., always add). I raised this issue in the MANET link metric discussions (August 15, 2007). Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 005E69C5862575B6_= Content-Type: text/html; charset="US-ASCII"


You can't assume that an 8-bit processor has intrinsic floating point support.  If the sensor is measuring temperature, you might expect they would support floating point.  (Not all of our do).  However, a binary sensor (e.g. a window tamper switch) clearly won't have floating point support.

Jerry






Philip Levis <pal@cs.stanford.edu>
Sent by: roll-bounces@ietf.org

05/14/2009 11:48 AM

To
Michael Richardson <mcr@sandelman.ottawa.on.ca>
cc
ROLL WG <roll@ietf.org>
Subject
Re: [Roll] ROLL Routing Metrics - WF feed-back needed






On May 13, 2009, at 2:22 PM, Michael Richardson wrote:

>
>>>>>> "Miguel" == Miguel Sanchez <misan@disca.upv.es> writes:
>   Miguel> I'm not entirely happy with floating point numbers if 8-bit
>   Miguel> micro controllers with not so much program memory (a few
>   Miguel> KBytes) are involved.  However I do like the idea of using
>   Miguel> Energy units to express Energy values (whether it is Joules
>   Miguel> or mJ integers are easier).
>
> Floating point is expressed as mantissa * 2^(exponent).
> I wonder if the mantissa is even important.
>
> Does it matter if it costs 10 Joules or 20 Joules to transmit: the
> point is that it costs O(10^1)?

As an aside, floating point for routing metrics can cause problems.  
These problems are not insurmountable, but it's important to recognize  
them and design routing protocols appropriately. In particular, using  
floating point means that route costs will not necessarily be  
monotonically increasing: if a link cost is very small compared to the  
overall route cost, it can be lost in the exponent. The lack of  
monotonicity means that you cannot depend on the metric to detect  
loops, unless you add some special cases (e.g., always add).

I raised this issue in the MANET link metric discussions (August 15,  
2007).

Phil
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 005E69C5862575B6_=-- From pal@cs.stanford.edu Thu May 14 10:10: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 63A5B3A6992; Thu, 14 May 2009 10:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.464 X-Spam-Level: X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 wDA9aPWlZF6v; Thu, 14 May 2009 10:10:26 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 0EE1D3A68A8; Thu, 14 May 2009 10:10:26 -0700 (PDT) Received: from dnab4220ec.stanford.edu ([171.66.32.236]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1M4eTP-0004vh-6M; Thu, 14 May 2009 10:11:59 -0700 Message-Id: From: Philip Levis To: "Dearlove, Christopher (UK)" In-Reply-To: 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, 14 May 2009 10:11:58 -0700 References: <314C5D40-78D3-4F66-AD40-093588E2233F@cisco.com> X-Mailer: Apple Mail (2.930.3) X-Scan-Signature: bd70d0bdda1312c8b25f7b39d1e2fb7f Cc: roll-bounces@ietf.org, ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] Few comments for our first discussion today 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, 14 May 2009 17:10:27 -0000 On May 14, 2009, at 8:10 AM, Dearlove, Christopher (UK) wrote: > Philip Levis >> Clearly the MUSTs are simply a synthesis of the application drafts >> and > >> so not really worth discussing, unless WG members find a misreading >> or > >> typo. > > I think that is absolutely not the case. What's your synthesis, all > worst cases to be supported simultaneously? Something else? Oh, I think there's a misunderstanding here. Where the protocol survey document was very clear in that it did not treat application requirements exhaustively, a protocol design needs to. I think the point the DT is making by separating "core" from "optional" is that there might be a set of MUSTs which most if not all applications share, which you then want in the core protocol. MUSTs which are only in a subset of the applications might then be served by optional extensions. > I would love to understand the DT's approach. Where is it explained, > in particular with regard to how conflicting requirements are being > reconciled? I think they're in this process now: let's not burden them with over- documentation of every minutia and prevent them from getting work done. Phil From alexandru.petrescu@gmail.com Thu May 14 13:11: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 E30EF28C35D for ; Thu, 14 May 2009 13:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.894 X-Spam-Level: X-Spam-Status: No, score=-0.894 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 0eNc9YuzuZzP for ; Thu, 14 May 2009 13:11:43 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 1F6CC28C33C for ; Thu, 14 May 2009 13:10:57 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 13F8ED48069; Thu, 14 May 2009 22:12:26 +0200 (CEST) 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 AD694D4808F; Thu, 14 May 2009 22:12:23 +0200 (CEST) Message-ID: <4A0C7B1C.6080308@gmail.com> Date: Thu, 14 May 2009 22:12:12 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Philip Levis References: <86c3ed7b0810300129w5ea1e843m4610566427245811@mail.gmail.com> <86c3ed7b0810310119y6c035b6en84f7ed9e9a2f1b6f@mail.gmail.com> <4A0AC25F.2060902@gmail.com> <86c3ed7b0905131005sfba99dy82e390c2dfbc0319@mail.gmail.com> <2367.1242238950@marajade.sandelman.ca> <907523DB-5E37-446D-86CE-6117B93A3225@cs.stanford.edu> In-Reply-To: <907523DB-5E37-446D-86CE-6117B93A3225@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090513-0, 13/05/2009), Outbound message X-Antivirus-Status: Clean Cc: Michael Richardson , ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed 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, 14 May 2009 20:11:44 -0000 Philip Levis a écrit : > > On May 13, 2009, at 2:22 PM, Michael Richardson wrote: > >> >>>>>>> "Miguel" == Miguel Sanchez writes: >> Miguel> I'm not entirely happy with floating point numbers if 8-bit >> Miguel> micro controllers with not so much program memory (a few >> Miguel> KBytes) are involved. However I do like the idea of using >> Miguel> Energy units to express Energy values (whether it is >> Joules Miguel> or mJ integers are easier). >> >> Floating point is expressed as mantissa * 2^(exponent). I wonder if >> the mantissa is even important. >> >> Does it matter if it costs 10 Joules or 20 Joules to transmit: the >> point is that it costs O(10^1)? > > As an aside, floating point for routing metrics can cause problems. > These problems are not insurmountable, but it's important to > recognize them and design routing protocols appropriately. In > particular, using floating point means that route costs will not > necessarily be monotonically increasing: if a link cost is very small > compared to the overall route cost, it can be lost in the exponent. I don't get it... lost in the exponent? > The lack of monotonicity means that you cannot depend on the metric > to detect loops, unless you add some special cases (e.g., always > add). I don't fully understand you. Loop avoidance: IPv6 Hop Limit is 0 then discard. Not creating the really shortest path because floats are used: I can understand. I don't assume perfect paths are created with integer metrics either. But the influence of the difference float-integer metric - I don't get. > I raised this issue in the MANET link metric discussions (August 15, > 2007). That's a long way back I don't have archive that far. Could you please post a pointer? Alex From alexandru.petrescu@gmail.com Thu May 14 13:12: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 3FE0628C200; Thu, 14 May 2009 13:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[AWL=-0.802, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 Ira-TYNm+v9T; Thu, 14 May 2009 13:12:17 -0700 (PDT) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by core3.amsl.com (Postfix) with ESMTP id 9CE373A6AFF; Thu, 14 May 2009 13:12:15 -0700 (PDT) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id 03C344B013A; Thu, 14 May 2009 22:13:42 +0200 (CEST) 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 91E6A4B016D; Thu, 14 May 2009 22:13:39 +0200 (CEST) Message-ID: <4A0C7B68.4060306@gmail.com> Date: Thu, 14 May 2009 22:13:28 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Jerald.P.Martocci@jci.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090513-0, 13/05/2009), Outbound message X-Antivirus-Status: Clean Cc: Michael Richardson , roll-bounces@ietf.org, ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed 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, 14 May 2009 20:12:18 -0000 Jerald.P.Martocci@jci.com a écrit : > > > > You can't assume that an 8-bit processor has intrinsic floating point > support. Right, but one can expect a _program_ of the 8-bit processor to perform floating point operations. Alex If the sensor is measuring temperature, you might expect they > would support floating point. (Not all of our do). However, a binary > sensor (e.g. a window tamper switch) clearly won't have floating point > support. > > Jerry > > > > > > > *Philip Levis * > Sent by: roll-bounces@ietf.org > > 05/14/2009 11:48 AM > > > To > Michael Richardson > cc > ROLL WG > Subject > Re: [Roll] ROLL Routing Metrics - WF feed-back needed > > > > > > > > > > On May 13, 2009, at 2:22 PM, Michael Richardson wrote: > > > > >>>>>> "Miguel" == Miguel Sanchez writes: > > Miguel> I'm not entirely happy with floating point numbers if 8-bit > > Miguel> micro controllers with not so much program memory (a few > > Miguel> KBytes) are involved. However I do like the idea of using > > Miguel> Energy units to express Energy values (whether it is Joules > > Miguel> or mJ integers are easier). > > > > Floating point is expressed as mantissa * 2^(exponent). > > I wonder if the mantissa is even important. > > > > Does it matter if it costs 10 Joules or 20 Joules to transmit: the > > point is that it costs O(10^1)? > > As an aside, floating point for routing metrics can cause problems. > These problems are not insurmountable, but it's important to recognize > them and design routing protocols appropriately. In particular, using > floating point means that route costs will not necessarily be > monotonically increasing: if a link cost is very small compared to the > overall route cost, it can be lost in the exponent. The lack of > monotonicity means that you cannot depend on the metric to detect > loops, unless you add some special cases (e.g., always add). > > I raised this issue in the MANET link metric discussions (August 15, > 2007). > > Phil > _______________________________________________ > 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 May 14 13:22: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 68C973A68F5 for ; Thu, 14 May 2009 13:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.658 X-Spam-Level: X-Spam-Status: No, score=-0.658 tagged_above=-999 required=5 tests=[AWL=-1.009, BAYES_50=0.001, 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 F2e6TEnhV3A7 for ; Thu, 14 May 2009 13:22:50 -0700 (PDT) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by core3.amsl.com (Postfix) with ESMTP id 563ED3A6939 for ; Thu, 14 May 2009 13:22:48 -0700 (PDT) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id 3D3E44B0171 for ; Thu, 14 May 2009 22:24:17 +0200 (CEST) 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 08DDF4B006D for ; Thu, 14 May 2009 22:24:14 +0200 (CEST) Message-ID: <4A0C7DE4.2030307@gmail.com> Date: Thu, 14 May 2009 22:24:04 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 090513-0, 13/05/2009), Outbound message X-Antivirus-Status: Clean Subject: [Roll] 14kb 8-bit micro-controllers... 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, 14 May 2009 20:22:51 -0000 At several points the sringent node characteristics were expressed such as: -14kb of RAM -8-bit controller -no floating point -etc. This should be clarified. There are node requirements which can be so strict they couldn't even memorize a Neighbor Cache of IPv6 addresses, let alone a TCPv6 implementation. Querying a temperature value on 6 bits with an IPv6 message of mandatory 40bytes of base header... Or the program of the wireless link layer, which was never questioned whether it fits or not the stringent node requirements of 14kb. Or the program doing AES key security. Would all these assumed programs fit in a 14kb of RAM of an 8-bit controller? There should be a reality check here... Alex From Jerald.P.Martocci@jci.com Thu May 14 13: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 8A62628C353; Thu, 14 May 2009 13:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.438 X-Spam-Level: X-Spam-Status: No, score=-5.438 tagged_above=-999 required=5 tests=[AWL=-1.006, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 bHutVRDuLtOh; Thu, 14 May 2009 13:38:24 -0700 (PDT) Received: from exprod8og109.obsmtp.com (exprod8og109.obsmtp.com [64.18.3.98]) by core3.amsl.com (Postfix) with ESMTP id E03EE28C2D4; Thu, 14 May 2009 13:38:23 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob109.postini.com ([64.18.7.12]) with SMTP ID DSNKSgyBnCMnHbJEpTxrhheS2o2oAFh6Phja@postini.com; Thu, 14 May 2009 13:39:57 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009051415405338-4352229 ; Thu, 14 May 2009 15:40:53 -0500 In-Reply-To: <4A0C7B68.4060306@gmail.com> MIME-Version: 1.0 To: Alexandru Petrescu X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Thu, 14 May 2009 15:39:41 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 05/14/2009 03:39:50 PM, Serialize complete at 05/14/2009 03:39:50 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 05/14/2009 03:40:53 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 05/14/2009 03:41:00 PM, Serialize complete at 05/14/2009 03:41:00 PM Content-Type: multipart/alternative; boundary="=_alternative 00717EE4862575B6_=" Cc: roll-bounces@ietf.org, Michael Richardson , ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed 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, 14 May 2009 20:38:25 -0000 This is a multipart message in MIME format. --=_alternative 00717EE4862575B6_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Alex, I didn't say you shouldn't expect 'floating point hardware', I said you=20 shouldn't expect 'floating point'. That means neither hardware nor=20 software floating point. Many sensor implementations read the A/D=20 convertor directly; perform syntactic and semantic checks on this value=20 without converting it and then ship it upstream to its respective=20 controller in ADC form. The controller may convert this to floating point = so it can do other operations (e.g. averaging across multiple sensors). As we move toward energy harvested sensors (that is battery-less) the=20 processor may only have a few hundred machine instructions it can run=20 before it's out of energy. It won't have the luxury to perform floating=20 point operations. We need to be really careful that the NWK layer doesn't assume processing=20 and memory resources that aren't already available to the application=20 layer Jerry Alexandru Petrescu =20 05/14/2009 03:13 PM To Jerald.P.Martocci@jci.com cc Philip Levis , roll-bounces@ietf.org, Michael=20 Richardson , ROLL WG Subject Re: [Roll] ROLL Routing Metrics - WF feed-back needed Jerald.P.Martocci@jci.com a =E9crit : >=20 >=20 >=20 > You can't assume that an 8-bit processor has intrinsic floating point=20 > support. Right, but one can expect a =5Fprogram=5F of the 8-bit processor to perform= =20 floating point operations. Alex If the sensor is measuring temperature, you might expect they > would support floating point. (Not all of our do). However, a binary=20 > sensor (e.g. a window tamper switch) clearly won't have floating point=20 > support. >=20 > Jerry >=20 >=20 >=20 >=20 >=20 >=20 > *Philip Levis * > Sent by: roll-bounces@ietf.org >=20 > 05/14/2009 11:48 AM >=20 >=20 > To > Michael Richardson > cc > ROLL WG > Subject > Re: [Roll] ROLL Routing Metrics - WF feed-back needed >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On May 13, 2009, at 2:22 PM, Michael Richardson wrote: >=20 > > > >>>>>> "Miguel" =3D=3D Miguel Sanchez writes: > > Miguel> I'm not entirely happy with floating point numbers if 8-bit > > Miguel> micro controllers with not so much program memory (a few > > Miguel> KBytes) are involved. However I do like the idea of using > > Miguel> Energy units to express Energy values (whether it is Joules > > Miguel> or mJ integers are easier). > > > > Floating point is expressed as mantissa * 2^(exponent). > > I wonder if the mantissa is even important. > > > > Does it matter if it costs 10 Joules or 20 Joules to transmit: the > > point is that it costs O(10^1)? >=20 > As an aside, floating point for routing metrics can cause problems.=20 > These problems are not insurmountable, but it's important to recognize=20 > them and design routing protocols appropriately. In particular, using=20 > floating point means that route costs will not necessarily be=20 > monotonically increasing: if a link cost is very small compared to the=20 > overall route cost, it can be lost in the exponent. The lack of=20 > monotonicity means that you cannot depend on the metric to detect=20 > loops, unless you add some special cases (e.g., always add). >=20 > I raised this issue in the MANET link metric discussions (August 15,=20 > 2007). >=20 > Phil > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 >=20 > ------------------------------------------------------------------------ >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --=_alternative 00717EE4862575B6_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"

Alex,

I didn't say you shouldn't expect 'f= loating point hardware', I said you shouldn't expect 'floating point'.  That means neither hardware nor software floating point.  Many sensor imple= mentations read the A/D convertor directly; perform syntactic and semantic checks on this value without converting it and then ship it upstream to its respec= tive controller in ADC form.  The controller may convert this to floating point so it can do other operations (e.g. averaging across multiple sensors= ).

As we move toward energy harvested s= ensors (that is battery-less) the processor may only have a few hundred machine instructions it can run before it's out of energy.  It won't have the luxury to perform floating point operations.

We need to be really careful that the NWK layer doesn't assume processing and memory resources that aren't already available to the application layer

Jerry





Alexandru Petrescu &l= t;alexandru.petrescu@gmail.com>

05/14/2009 03:13 PM

To
Jerald.P.Martocci@jci.com
cc
Philip Levis <pal@cs.stanford.edu= >, roll-bounces@ietf.org, Michael Richardson <mcr@sandelman.ottawa.on.ca>= ;, ROLL WG <roll@ietf.org>
Subject
Re: [Roll] ROLL Routing Metrics - WF feed-back needed





Jerald.P.Martocci@jci.com a =E9crit :
>
>
>
> You can't assume that an 8-bit processor has intrinsic floating point
> support.

Right, but one can expect a =5Fprogram=5F of the 8-bit processor to perform
floating point operations.

Alex

  If the sensor is measuring temperature, you might expect they
> would support floating point.  (Not all of our do).  However, a binary
> sensor (e.g. a window tamper switch) clearly won't have floating point
> support.
>
> Jerry
>
>
>
>
>
>
> *Philip Levis <pal@cs.stanford.edu>*
> Sent by: roll-bounces@ietf.org
>
> 05/14/2009 11:48 AM
>
>                  
> To
>                  Michael Richardson <mcr@sandelman.ottawa.on.ca>
> cc
>                  ROLL WG <roll@ietf.org>
> Subject
>                  Re: [Roll] ROLL Routing Metrics - WF feed-back needed
>
>
>                  
>
>
>
>
>
>
> On May 13, 2009, at 2:22 PM, Michael Richardson wrote:
>
>  >
>  >>>>>> "Miguel" =3D=3D Miguel Sanchez <misan@disca.upv.es> writes:
>  >   Miguel> I'm not entirely happy with floating point numbers if 8-bit
>  >   Miguel> micro controllers with not so much program memory (a few
>  >   Miguel> KBytes) are involved.  However I do like the idea of using
>  >   Miguel> Energy units to express Energy values (whether it is Joules
>  >   Miguel> or mJ integers are easier).
>  >
>  > Floating point is expressed as mantissa * 2^(exponent).
>  > I wonder if the mantissa is even important.
>  >
>  > Does it matter if it costs 10 Joules or 20 Joules to transm= it: the
>  > point is that it costs O(10^1)?
>
> As an aside, floating point for routing metrics can cause problems.  
> These problems are not insurmountable, but it's important to recognize  
> them and design routing protocols appropriately. In particular, using  
> floating point means that route costs will not necessarily be   > monotonically increasing: if a link cost is very small compared to the  
> overall route cost, it can be lost in the exponent. The lack of  =
> monotonicity means that you cannot depend on the metric to detect  
> loops, unless you add some special cases (e.g., always add).
>
> I raised this issue in the MANET link metric discussions (August 15,  
> 2007).
>
> Phil
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>
> ----------------------------------------------------------------------= --
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
--=_alternative 00717EE4862575B6_=-- From Jerald.P.Martocci@jci.com Thu May 14 14:31: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 841AB3A682A; Thu, 14 May 2009 14:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.149, 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 Aj4S6PFZ0708; Thu, 14 May 2009 14:31:20 -0700 (PDT) Received: from exprod8og105.obsmtp.com (exprod8og105.obsmtp.com [64.18.3.90]) by core3.amsl.com (Postfix) with ESMTP id 476173A6F93; Thu, 14 May 2009 14:31:20 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob105.postini.com ([64.18.7.12]) with SMTP ID DSNKSgyOAyFBx6wfejANfirZT+bos26/C5kK@postini.com; Thu, 14 May 2009 14:32:54 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009051416335304-4358492 ; Thu, 14 May 2009 16:33:53 -0500 In-Reply-To: <4A0C7DE4.2030307@gmail.com> MIME-Version: 1.0 To: Alexandru Petrescu X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Thu, 14 May 2009 16:32:42 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 05/14/2009 04:32:50 PM, Serialize complete at 05/14/2009 04:32:50 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 05/14/2009 04:33:53 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 05/14/2009 04:33:57 PM, Serialize complete at 05/14/2009 04:33:57 PM Content-Type: multipart/alternative; boundary="=_alternative 007659B9862575B6_=" Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] 14kb 8-bit micro-controllers... 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, 14 May 2009 21:31:21 -0000 This is a multipart message in MIME format. --=_alternative 007659B9862575B6_= Content-Type: text/plain; charset="US-ASCII" Yep. Completely agree here. We are in a new world where processing power is orders of magnitude less that the smallest devices typically considered in the IETF. The real 'kick in the pants' is that these requirements are not just marketing hype. These devices have been built and in production for decades in the wired world and years in the wireless world. The IEEE folks realized this when they developed 802.15.4. They actually defined two different classes of devices (i.e. Full-function Devices and Reduced Function Devices) which allowed for different specifications for each class. We may have to follow suit to be sure the different gradations of devices can play well in the architecture yet still meet their cost/functionality requirements. Jerry Alexandru Petrescu Sent by: roll-bounces@ietf.org 05/14/2009 03:24 PM To ROLL WG cc Subject [Roll] 14kb 8-bit micro-controllers... At several points the sringent node characteristics were expressed such as: -14kb of RAM -8-bit controller -no floating point -etc. This should be clarified. There are node requirements which can be so strict they couldn't even memorize a Neighbor Cache of IPv6 addresses, let alone a TCPv6 implementation. Querying a temperature value on 6 bits with an IPv6 message of mandatory 40bytes of base header... Or the program of the wireless link layer, which was never questioned whether it fits or not the stringent node requirements of 14kb. Or the program doing AES key security. Would all these assumed programs fit in a 14kb of RAM of an 8-bit controller? There should be a reality check here... Alex _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 007659B9862575B6_= Content-Type: text/html; charset="US-ASCII"

Yep.  Completely agree here.

We are in a new world where processing power is orders of magnitude less that the smallest devices typically considered in the IETF.  The real 'kick in the pants' is that these requirements are not just marketing hype.  These devices have been built and in production for decades in the wired world and years in the wireless world.  

The IEEE folks realized this when they developed 802.15.4.  They actually defined two different classes of devices (i.e. Full-function Devices and Reduced Function Devices) which allowed for different specifications for each class.   We may have to follow suit to be sure the different gradations of devices can play well in the architecture yet still meet their cost/functionality requirements.

Jerry



Alexandru Petrescu <alexandru.petrescu@gmail.com>
Sent by: roll-bounces@ietf.org

05/14/2009 03:24 PM

To
ROLL WG <roll@ietf.org>
cc
Subject
[Roll] 14kb 8-bit micro-controllers...





At several points the sringent node characteristics were expressed such as:

-14kb of RAM
-8-bit controller
-no floating point
-etc.

This should be clarified.

There are node requirements which can be so strict they couldn't even
memorize a Neighbor Cache of IPv6 addresses, let alone a TCPv6
implementation.

Querying a temperature value on 6 bits with an IPv6 message of mandatory
40bytes of base header...

Or the program of the wireless link layer, which was never questioned
whether it fits or not the stringent node requirements of 14kb.

Or the program doing AES key security.

Would all these assumed programs fit in a 14kb of RAM of an 8-bit
controller?

There should be a reality check here...

Alex
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 007659B9862575B6_=-- From alexandru.petrescu@gmail.com Thu May 14 14:38:35 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 A991E3A693F; Thu, 14 May 2009 14:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.864 X-Spam-Level: X-Spam-Status: No, score=-0.864 tagged_above=-999 required=5 tests=[AWL=-0.781, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 o0MweUve8XWi; Thu, 14 May 2009 14:38:35 -0700 (PDT) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by core3.amsl.com (Postfix) with ESMTP id 2FC2828C285; Thu, 14 May 2009 14:38:32 -0700 (PDT) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id 1447D4B010D; Thu, 14 May 2009 23:40:00 +0200 (CEST) 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 D7C534B0021; Thu, 14 May 2009 23:39:53 +0200 (CEST) Message-ID: <4A0C8F9E.1040808@gmail.com> Date: Thu, 14 May 2009 23:39:42 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Jerald.P.Martocci@jci.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090513-0, 13/05/2009), Outbound message X-Antivirus-Status: Clean Cc: roll-bounces@ietf.org, Michael Richardson , ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WG feed-back needed 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, 14 May 2009 21:38:35 -0000 Jerald, Jerald.P.Martocci@jci.com a écrit : > > > Alex, > > I didn't say you shouldn't expect 'floating point hardware', I said > you shouldn't expect 'floating point'. That means neither hardware > nor software floating point. Many sensor implementations read the > A/D convertor directly; perform syntactic and semantic checks on this > value without converting it and then ship it upstream to its > respective controller in ADC form. The controller may convert this > to floating point so it can do other operations (e.g. averaging > across multiple sensors). > > As we move toward energy harvested sensors (that is battery-less) the > processor may only have a few hundred machine instructions it can > run before it's out of energy. It won't have the luxury to perform > floating point operations. On an 8-bit micro-controller with 8bit registers and 8bit addressing, a fundamental IP longest prefix match would average 8 CMP instructions before the successful JMP, plus 16 fetches of the 2 parts of the compared IP addresses. Optimistically: 30 instructions required. Only to route one packet! Not many packets could be routed when only a few hundred instructions are available... > We need to be really careful that the NWK layer doesn't assume > processing and memory resources that aren't already available to the > application layer I agree these ressources wouldn't be available on the most constrained chips, but IP couldn't run on them anyways, even the most stripped-out IP. Alex From Jerald.P.Martocci@jci.com Thu May 14 14:54: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 988633A7050; Thu, 14 May 2009 14:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.376 X-Spam-Level: X-Spam-Status: No, score=-5.376 tagged_above=-999 required=5 tests=[AWL=-0.944, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 shawEObITxKT; Thu, 14 May 2009 14:54:08 -0700 (PDT) Received: from exprod8og111.obsmtp.com (exprod8og111.obsmtp.com [64.18.3.22]) by core3.amsl.com (Postfix) with ESMTP id 39EA83A6D56; Thu, 14 May 2009 14:54:08 -0700 (PDT) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob111.postini.com ([64.18.7.12]) with SMTP ID DSNKSgyTXRIDop+CWHORKRNRhnrDbrbaRuvh@postini.com; Thu, 14 May 2009 14:55:42 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009051416575949-3432283 ; Thu, 14 May 2009 16:57:59 -0500 In-Reply-To: <4A0C8F9E.1040808@gmail.com> MIME-Version: 1.0 To: Alexandru Petrescu X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Thu, 14 May 2009 16:55:29 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 05/14/2009 04:55:36 PM, Serialize complete at 05/14/2009 04:55:36 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 05/14/2009 04:57:59 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 05/14/2009 04:58:05 PM, Serialize complete at 05/14/2009 04:58:05 PM Content-Type: multipart/alternative; boundary="=_alternative 00786F9A862575B6_=" Cc: roll-bounces@ietf.org, Michael Richardson , ROLL WG Subject: Re: [Roll] ROLL Routing Metrics - WG feed-back needed 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, 14 May 2009 21:54:09 -0000 This is a multipart message in MIME format. --=_alternative 00786F9A862575B6_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Yes. Don't forget, the sensor also has to actually sense the air and=20 complete sanity checks on the data prior packetizing and shipping the=20 packet.=20 As I mentioned in my last email, we might want to consider some 'reduced=20 function' definition for these really low power devices. Once we get past = this sensor/actuator layer, the upstream devices have some addition=20 horsepower (512Kbytes flash, 64Kbytes RAM, floating point) that can do=20 more traditional IP type operations. Jerry Alexandru Petrescu =20 05/14/2009 04:40 PM To Jerald.P.Martocci@jci.com cc Michael Richardson , Philip Levis=20 , ROLL WG , roll-bounces@ietf.org Subject Re: [Roll] ROLL Routing Metrics - WG feed-back needed Jerald, Jerald.P.Martocci@jci.com a =E9crit : >=20 >=20 > Alex, >=20 > I didn't say you shouldn't expect 'floating point hardware', I said > you shouldn't expect 'floating point'. That means neither hardware > nor software floating point. Many sensor implementations read the > A/D convertor directly; perform syntactic and semantic checks on this > value without converting it and then ship it upstream to its > respective controller in ADC form. The controller may convert this > to floating point so it can do other operations (e.g. averaging > across multiple sensors). >=20 > As we move toward energy harvested sensors (that is battery-less) the > processor may only have a few hundred machine instructions it can > run before it's out of energy. It won't have the luxury to perform > floating point operations. On an 8-bit micro-controller with 8bit registers and 8bit addressing, a fundamental IP longest prefix match would average 8 CMP instructions before the successful JMP, plus 16 fetches of the 2 parts of the compared IP addresses. Optimistically: 30 instructions required. Only to route one packet! Not many packets could be routed when only a few hundred instructions=20 are available... > We need to be really careful that the NWK layer doesn't assume=20 > processing and memory resources that aren't already available to the > application layer I agree these ressources wouldn't be available on the most constrained chips, but IP couldn't run on them anyways, even the most stripped-out IP. Alex --=_alternative 00786F9A862575B6_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"
Yes.  Don't forget, the sensor also has to actually sense the air and complete sanity checks on the data prior packetizing and shipping the packet.  

As I mentioned in my last email, we might want to consider some 'reduced function' definition for these really low power devices.  Once we get past this sensor/actuator layer, the upstream devices have some addition horsepower (512Kbytes flash, 64Kbytes RAM, floating point) that can do more traditional IP type operations.

Jerry




Alexandru Petrescu &l= t;alexandru.petrescu@gmail.com>

05/14/2009 04:40 PM

To
Jerald.P.Martocci@jci.com
cc
Michael Richardson <mcr@sandelman= .ottawa.on.ca>, Philip Levis <pal@cs.stanford.edu>, ROLL WG <roll@ietf.org>, roll-bounces@ietf.org
Subject
Re: [Roll] ROLL Routing Metrics - WG feed-back needed





Jerald,

Jerald.P.Martocci@jci.com a =E9crit :
>
>
> Alex,
>
> I didn't say you shouldn't expect 'floating point hardware', I said
> you shouldn't expect 'floating point'.  That means neither hardwa= re
> nor software floating point.  Many sensor implementations read the
> A/D convertor directly; perform syntactic and semantic checks on this<= br> > value without converting it and then ship it upstream to its
> respective controller in ADC form.  The controller may convert this
> to floating point so it can do other operations (e.g. averaging
> across multiple sensors).
>
> As we move toward energy harvested sensors (that is battery-less) the
>  processor may only have a few hundred machine instructions it can
> run before it's out of energy.  It won't have the luxury to perfo= rm
> floating point operations.

On an 8-bit micro-controller with 8bit registers and 8bit addressing, a
fundamental IP longest prefix match would average 8 CMP instructions
before the successful JMP, plus 16 fetches of the 2 parts of the
compared IP addresses.  Optimistically: 30 instructions required. Only
to route one packet!

Not many packets could be routed when only a few hundred instructions
are available...

> We need to be really careful that the NWK layer doesn't assume
> processing and memory resources that aren't already available to the >  application layer

I agree these ressources wouldn't be available on the most constrained
chips, but IP couldn't run on them anyways, even the most stripped-out IP.

Alex
--=_alternative 00786F9A862575B6_=-- From wintert@acm.org Thu May 14 19:08: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 73D8228C277 for ; Thu, 14 May 2009 19:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.855 X-Spam-Level: X-Spam-Status: No, score=-101.855 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, USER_IN_WHITELIST=-100] 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 gvnClngdvT7R for ; Thu, 14 May 2009 19:08:19 -0700 (PDT) Received: from smtp108.prem.mail.ac4.yahoo.com (smtp108.prem.mail.ac4.yahoo.com [76.13.13.47]) by core3.amsl.com (Postfix) with SMTP id C99B228C125 for ; Thu, 14 May 2009 19:08:18 -0700 (PDT) Received: (qmail 57769 invoked from network); 15 May 2009 02:09:50 -0000 Received: from unknown (HELO ?192.168.47.101?) (wintert@206.83.249.194 with plain) by smtp108.prem.mail.ac4.yahoo.com with SMTP; 15 May 2009 02:09:49 -0000 X-YMail-OSG: ffkWKLQVM1kF6jmSi6yROkfQRF6Qpb1ZIZh0Oz1ZdGZ4UfSa5xgGsZ3aQoOBYyFsoRQ7ja.sWf0vILCnkZzrON9dCi.IRuMenScwnc7NdkT6tFJuZg8aYd5UJ3y0UN4bWgZneOYuF_ze6Srm5Qn5XfugKzuLQVfQ9GNsmK_29AA4pjAlNnhkbQbNHUyp_hZzAQJdRHw6VAqv7prwABfIG_j84pmENKSbxqYUhRDqLVasE.r39SJzJRJTRKgi.XTA4UAuN8s2wDr5rTA0yKj4Q.5dzjTcgvA.GL1V2YeElvT8QNemYNlTCI4clwpnfGNa_7BLOg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A0CCEE8.8020709@acm.org> Date: Thu, 14 May 2009 22:09:44 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.21 (X11/20090330) MIME-Version: 1.0 To: ROLL WG , dtroll@external.cisco.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Roll] DT update -- MUSTs 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, 15 May 2009 02:08:21 -0000 WG, With the recent discussions regarding MUSTs, trade-offs, and how to reconcile the 4 different requirements documents into one protocol, I do hope that this update provides some useful insights into how the DT is proceeding. Here is a list of extracted MUSTs, with some categorization, along with uncategorized SHOULDs. Please do carefully note the following: 1) The source requirements documents contain much more background text and detail for interpreting the meaning and intent of the MUSTs than appears in this summary list. This summary list is quite simply keyed off of MUSTs (and SHOULDs) in the requirements documents. This list can be used like an index, but the requirements documents give further context which is important for detailed interpretation, and the requirements documents are authoritative. 2) The categories presented here may be considered a very coarse grouping. The intent was to begin to place the 4 requirements documents side by side in a way that is meaningful to begin interpretation, but is not intended to be a precise taxonomy. Similarly, please do not place too much meaning in the category names per se, they are perhaps coarse, but the intent is that the grouped functionalities are related. Finally, the coarse groupings may well produce `overlap' in some cases. 3) In some places [editorial comments] are added that do not appear in the original drafts. The design team underwent an exercise of going through and discussing these requirements, and at a first cut asked `can this requirement _not_ be satisfied?'. This exercise provides further familiarization with the requirements as well as a crude `reality check' if you will. So far, no requirement is clearly ruled out, and there is a basis to continue the discussion of what a routing protocol solution to meet these requirements will look like. It is also clear when we look at these requirements that an attempt to find or meet an intersection between all of them is very challenging. Nevertheless, it is not our intended approach to pick and choose, e.g. we do not want to say `let us define a protocol that will satisfy XXX in HOME, but at the cost of YYY in INDUSTRIAL'. We are tasked clearly to try and define _one_ protocol to satisfy _all_ of the requirements. Perhaps as the process continues it will become clear and necessary that such a `hard' trade-off needs to be made to resolve some fundamental conflict, but it would be very premature to say such things at this point. If such a trade-off emerges and becomes inevitable, there will most certainly be very careful discussion and justification to be made. This is the inspiration behind the approach we are taking: 1) define a basic core protocol + optional extensions 2) allow the protocol to be parameterized -> such that the implementor has the ability to make appropriate detailed trade-offs with the guidance of applicability statements as appropriate to the target application/platform. It is our hope that by following this approach we have a protocol which provides a practical and implementable framework in which can be made proper and measured compromises with respect to different applications. We do hope not to end up with a duck ;) More updates to come as the work proceeds. Regards, -Tim --------------------------------------------------------------------------- - Categorized MUSTs Sources: draft-ietf-roll-urban-routing-reqs-05.txt draft-ietf-roll-indus-routing-reqs-05.txt draft-ietf-roll-building-routing-reqs-05.txt draft-ietf-roll-home-routing-reqs-06.txt --------------------------------------------------------------------------- A. General: ----------- A.1 URBAN: For the latter [patches/updates], the protocol(s) MUST support multi- and any-cast addressing. A.2 URBAN: Routing protocols activated in urban sensor networks MUST support unicast (traffic is sent to a single field device), multicast (traffic is sent to a set of devices that are subscribed to the same multicast group), and anycast (where multiple field devices are configured to accept traffic sent on a single IP anycast address) transmission schemes. A.3 BUILDING: Routing MUST support anycast, unicast, and multicast. A.4 BUILDING: A network device MUST be able to communicate in a peer- to-peer manner with any other device on the network. Thus, the routing protocol MUST provide routes between arbitrary hosts within the appropriate administrative domain. A.5 BUILDING: The routing protocol MUST support a metric of route quality and optimize path selection according to such metrics within constraints established for links along the paths. A.6 BUILDING: In such cases [sleeping nodes], the routing protocol MUST discover the capability of a node to act as a proxy during path calculation; then deliver the packet to the assigned proxy for later delivery to the sleeping device upon its next awakened cycle. B. Traffic Flows: ----------------- [ Node -> (thru) LBR ] [ (thru) LBR -> Node ] [ Node -> Node ] B.1 URBAN: The routing protocol MUST be able to accommodate traffic bursts by dynamically computing and selecting multiple paths towards the same destination. B.2 INDUSTRIAL: The routing protocol MUST be able to compute paths of not-necessarily-equal cost toward a given destination so as to enable load balancing across a variety of paths. B.3 INDUSTRIAL: The routing protocol MUST be able to compute a set of unidirectional routes with potentially different costs that are composed of one or more non-congruent paths. C. Autonomous Configuration/Management/Reliability: ---------------------------------------- C.1 URBAN: To this end, the routing protocol(s) MUST provide a set of features including 0-configuration at network ramp-up, (network-internal) self- organization and configuration due to topological changes, and the ability to support (network-external) patches and configuration updates. C.2 INDUSTRIAL: The routing protocol MUST route on paths that are changed to appropriately provision the application requirements. The routing protocol MUST support the ability to recompute paths based on Network Layer abstractions of the underlying link attributes/metric that may change dynamically. C.3 INDUSTRIAL: The routing algorithm MUST be able to generate different routes with different characteristics (e.g. optimized according to difference cost, etc...). C.4 INDUSTRIAL: The routing protocol MUST enable the full discovery and setup of the environment (available links, selected peers, reachable network). The protocol also MUST support the distribution of configuration from a centralized management controller if operator-initiated configuration change is allowed. C.5 BUILDING: It MUST be possible to fully commission network devices without requiring any additional commissioning device (e.g. laptop). C.6 BUILDING: Devices referencing data in the replaced device MUST be able to reference data in its replacement without being reconfigured to refer to the new device. Thus, such a reference cannot be a hardware identifier, such as the MAC address, nor a hard-coded route. If such a reference is an IP address, the replacement device MUST be assigned the IP addressed previously bound to the replaced device. Or if the logical equivalent of a hostname is used for the reference, it must be translated to the replacement IP address. C.7 HOME: Thus the routing protocol designed for home automation networks MUST provide a set of features including zero- configuration of the routing protocol for a new node to be added to the network. From a routing perspective, zero-configuration means that a node can obtain an address and join the network on its own, without human intervention. C.8 HOME: The routing protocol MUST support the ability to isolate a misbehaving node thus preserving the correct operation of the overall network. D. Scalability: --------------- D.1 URBAN: The routing protocol(s) MUST be capable of supporting the organization of a large number of sensing nodes into regions containing on the order of 10^2 to 10^4 sensing nodes each. D.2 URBAN: The routing protocol(s) MUST be scalable so as to accommodate a very large and increasing number of nodes without deteriorating selected performance parameters below configurable thresholds. D.3 BUILDING: The routing protocol MUST be able to support networks with at least 2000 nodes supporting at least 1000 routing devices and 1000 non-routing device. Subnetworks (e.g. rooms, primary equipment) within the network must support upwards to 255 sensors and/or actuators. D.4 HOME: The routing protocol MUST support 250 devices in the network. E. Performance: --------------- E.1 INDUSTRIAL: The routing algorithm MUST find the appropriate route(s) and report success or failure within several minutes, and SHOULD report success or failure within tens of seconds. E.2 INDUSTRIAL: The routing algorithm MUST respond to normal link failure rates with routes that meet the Service requirements (especially latency) throughout the routing response. The routing algorithm SHOULD always be in the process of recalculating the route in response to changing link statistics. The routing algorithm MUST recalculate the paths when field devices change due to insertion, removal or failure, and this recalculation MUST NOT cause latencies greater than the specified constraints (typically seconds to minutes). E.3 HOME: The routing protocol MUST provide mobility with convergence time below 0.5 second if only the sender has moved. E.4 HOME: Sleeping nodes may appear to be non-responsive. The routing protocol MUST take into account the delivery time to a sleeping target node. The wake-up interval of a sleeping node MUST be less than one second. E.5 HOME: The routing protocol MUST converge within 0.5 second if no nodes have moved. E.6 HOME: The routing protocol MUST converge within 2 seconds if the destination node of the packet has moved. F. Constraint-based Routing: ---------------------------- F.1 URBAN: To this end, the routing protocol(s) MUST support parameter constrained routing, where examples of such parameters (CPU, memory size, battery level, etc.) have been given in the previous paragraph. In other words the routing protocol MUST be able to advertise node capabilities that will be exclusively used by the routing protocol engine for routing decision. F.2 INDUSTRIAL: The routing protocol MUST also support different metric types for each link used to compute the path according to some objective function (e.g. minimize latency) depending on the nature of the traffic. F.3 INDUSTRIAL: The routing algorithm MUST support node-constrained routing (e.g. taking into account the existing energy state as a node constraint). Node constraints include power and memory, as well as constraints placed on the device by the user, such as battery life. F.4 BUILDING: The routing protocol MUST take into account device characteristics such as power budget. F.5 HOME: The routing protocol MUST support constraint-based routing taking into account node properties (CPU, memory, level of energy, sleep intervals, safety/convenience of changing battery). G. Security: ------------ G.1 URBAN: The U-LLN network MUST deny any node who has not been authenticated to the U-LLN and authorized to participate to the routing decision process. G.2 URBAN: Mechanisms MUST be in place to deny any node which attempts to take malicious advantage of self-configuration and self- organization procedures. G.3 URBAN: A node MUST authenticate itself to a trusted node that is already associated with the U-LLN before the former can take part in self-configuration or self-organization. G.4 URBAN: A node that has already authenticated and associated with the U-LLN MUST deny, to the maximum extent possible, the allocation of resources to any unauthenticated peer. G.5 URBAN: The routing protocol(s) MUST deny service to any node which has not clearly established trust with the U-LLN. G.6 URBAN: To this end, routing protocol(s) proposed in the context of U-LLNs MUST support authentication and integrity measures and SHOULD support confidentiality (routing security) measures. G.7 INDUSTRIAL: The routing MUST be configured and managed using secure messages and protocols that prevent outsider attacks and limit insider attacks from field devices installed in insecure locations in the plant. G.8 BUILDING: Authentication policy and updates MUST be routable over-the-air. G.9 BUILDING: Data encryption of packets MUST optionally be supported by use of either a network wide key and/or application key. G.10 BUILDING: The routing protocol MUST allow routing a packet encrypted with an application key through forwarding devices that without requiring each node in the path have the application key. G.11 BUILDING: The encryption policy MUST support encryption of the payload only or the entire packet. G.12 BUILDING: Due to the limited resources of an LLN, the security policy defined within the LLN MUST be able to differ from that of the rest of the IP network within the facility yet packets MUST still be able to route to or through the LLN from/to these networks. G.13 BUILDING: The routing protocol MUST gracefully handle routing temporal security updates (e.g. dynamic keys) to sleeping devices on their 'awake' cycle to assure that sleeping devices can readily and efficiently access then network. G.14 HOME: The routing protocol chosen for ROLL MUST allow for low- power, low-cost network devices with limited security needs. G.15 HOME: Protection against unintentional inclusion in neighboring networks MUST be provided. --------------------------------------------------------------------------- --------------------------------------------------------------------------- --------------------------------------------------------------------------- - Uncategorized SHOULDs --------------------------------------------------------------------------- draft-ietf-roll-building-routing-reqs --------------------------------------------------------------------------- 5.1.3. Local Testing Routing should allow for temporary ad hoc paths to be established that are updated as the network physically and functionally expands. 5.3.1. Mobile Device Requirements To minimize network dynamics, mobile devices SHOULD not be allowed to act as forwarding devices (routers) for other devices in the LLN. A mobile device that moves within an LLN SHOULD reestablish end-to- end communication to a fixed device also in the LLN within 2 seconds. The network convergence time should be less than 5 seconds once the mobile device stops moving. A mobile device that moves outside of an LLN SHOULD reestablish end- to-end communication to a fixed device in the new LLN within 5 seconds. The network convergence time should be less than 5 seconds once the mobile device stops moving. A mobile device that moves outside of one LLN into another LLN SHOULD reestablish end-to-end communication to a fixed device in the old LLN within 10 seconds. The network convergence time should be less than 10 seconds once the mobile device stops. A mobile device that moves outside of one LLN into another LLN SHOULD reestablish end-to-end communication to another mobile device in the new LLN within 20 seconds. The network convergence time should be less than 30 seconds once the mobile devices stop moving. A mobile device that moves outside of one LLN into another LLN SHOULD reestablish end-to-end communication to a mobile device in the old LLN within 30 seconds. The network convergence time should be less than 30 seconds once the mobile devices stop moving. 5.4.1. Limited Processing Power for Non-routing Devices. The software size requirement for non-routing devices (e.g. sleeping sensors and actuators) SHOULD be implementable in 8-bit devices with no more than 128KB of memory. 5.4.2. Limited Processing Power for Routing Devices The software size requirements for routing devices (e.g. room controllers) SHOULD be implementable in 8-bit devices with no more than 256KB of flash memory. 5.6.2. Route Tracking Route diagnostics SHOULD be supported providing information such as path quality; number of hops; available alternate active paths with associated costs. Path quality is the relative measure of 'goodness' of the selected source to destination path as compared to alternate paths. This composite value may be measured as a function of hop count, signal strength, available power, existing active paths or any other criteria deemed by ROLL as the path cost differentiator. 5.7.1. Path Cost [...] These metrics SHOULD reflect metrics such as signal strength, available bandwidth, hop count, energy availability and communication error rates. 5.7.3. Route Redundancy The routing layer SHOULD be configurable to allow secondary and tertiary paths to be established and used upon failure of the primary path. 5.7.4. Route Discovery Time If route discovery occurs during packet transmission time, it SHOULD NOT add more than 120ms of latency to the packet delivery time. 5.7.5. Route Preference Route cost algorithms SHOULD allow the installer to optionally select 'preferred' paths based on the known spatial layout of the communicating devices. --------------------------------------------------------------------------- draft-ietf-roll-home-routing-reqs --------------------------------------------------------------------------- --------------------------------------------------------------------------- roll-indus-routing-reqs --------------------------------------------------------------------------- - In fast control, tens of milliseconds of latency is typical. [...] For these reasons, the ROLL routing infrastructure is required to compute and update constrained routes on demand, and it can be expected that this model will become more prevalent for field device to field device connectivity as well as for some field device to Infrastructure devices over time. [ A route that connects a field device to a plant application may have multiple paths that go through more than one LLN access point. The routing protocol MUST be able to compute paths of not-necessarily-equal cost toward a given destination so as to enable load balancing across a variety of paths. The availability of each path in a multipath route can change over time. Hence, it is important to measure the availability on a per-path basis and select a path (or paths) according to the availability requirements. ] The routing protocol SHOULD support broadcast or multicast addressing. 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. The routing protocol SHOULD also support the bandwidth allocation for bulk transfers between the field device and the handheld device of the wireless worker. The routing protocol SHOULD support walking speeds for maintaining network connectivity as the handheld device changes position in the wireless network. The routing protocol SHOULD NOT require to preprovision information about the environment where the node will be deployed. The routing protocol MUST enable the full discovery and setup of the environment (available links, selected peers, reachable network).The protocol also MUST support the distribution of configuration from a centralized management controller if operator-initiated configuration change is allowed. In industrial plants it must be assumed that the field devices have marginal physical security and might be compromised. The routing protocol SHOULD limit the risk incurred by one node being compromised, for instance by proposing non congruent path for a given route and balancing the traffic across the network. The routing protocol SHOULD compartmentalize the trust placed in field devices so that a compromised field device does not destroy the security of the whole network. --------------------------------------------------------------------------- - draft-ietf-roll-urban-routing-reqs-04 --------------------------------------------------------------------------- - The routing protocols(s) SHOULD support the organization of a large number of nodes into regions of configurable size. Routing within urban sensor networks SHOULD require the U-LLN nodes to dynamically compute, select and install different paths towards a same destination, depending on the nature of the traffic. Such functionality in support of, for example, data aggregation, may imply to use some mechanisms to mark/tag the traffic for appropriate routing decision using the IPv6 packet format (e.g. use of DSCP, Flow Label) based on an upper layer marking decision. The protocol(s) SHOULD also support the formation and identification of groups of field devices in the network. The routing protocol(s) SHOULD be able to dynamically adapt, e.g. through the application of appropriate routing metrics, to ever- changing conditions of communication (possible degradation of QoS, variable nature of the traffic (real time vs. non real time, sensed data vs. alerts), node mobility, a combination thereof, etc.) The routing protocol(s) SHOULD be able to dynamically compute, select and possibly optimize the (multiple) path(s) that will be used by the participating devices to forward the traffic towards the actuators and/or a LBR according to the service-specific and traffic-specific QoS, traffic engineering and routing security policies that will have to be enforced at the scale of a routing domain (that is, a set of networking devices administered by a globally unique entity), or a region of such domain (e.g. a metropolitan area composed of clusters of sensors). To this end, local network dynamics SHOULD NOT impact the entire network to be re-organized or re-reconfigured; however, the network SHOULD be locally optimized to cater for the encountered changes. The routing protocol(s) SHOULD support appropriate mechanisms in order to be informed of the association, disassociation, and disappearance of nodes. The routing protocol(s) SHOULD support appropriate updating mechanisms in order to be informed of changes in connectivity. The routing protocol(s) SHOULD use this information to initiate protocol specific mechanisms for reorganization and reconfiguration as necessary to maintain overall routing efficiency. Convergence and route establishment times SHOULD be significantly lower than the smallest reporting interval. Differentiation SHOULD be made between node disappearance, where the node disappears without prior notification, and user or node- initiated disassociation ("phased-out"), where the node has enough time to inform the network about its pending removal. The routing protocol(s) SHOULD also support the ability to route according to different metrics (one of which could e.g. be latency). The routing protocol(s) SHOULD support defense against DoS attacks and other attempts to maliciously or inadvertently cause the routing protocol(s) mechanisms to over consume the limited resources of LLN nodes, e.g. by constructing forwarding loops or causing excessive routing protocol overhead traffic, etc. The U-LLN SHOULD NOT interface with any external network which has not established trust. The U-LLN SHOULD be capable of limiting the resources granted in support of an external network so as not to be vulnerable to DoS. --------------------------------------------------------------------------- From alexandru.petrescu@gmail.com Thu May 14 23:38:48 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 A3D503A7069 for ; Thu, 14 May 2009 23:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=0.311, 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 h6r-9FTPPlg0 for ; Thu, 14 May 2009 23:38:46 -0700 (PDT) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by core3.amsl.com (Postfix) with ESMTP id 920F43A6807 for ; Thu, 14 May 2009 23:38:43 -0700 (PDT) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id 3EE7D81805A; Fri, 15 May 2009 08:40:12 +0200 (CEST) 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 9663D81814A; Fri, 15 May 2009 08:40:09 +0200 (CEST) Message-ID: <4A0D0E3E.6000407@gmail.com> Date: Fri, 15 May 2009 08:39:58 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Tim Winter References: <4A0CCEE8.8020709@acm.org> In-Reply-To: <4A0CCEE8.8020709@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090514-0, 14/05/2009), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] DT update -- MUSTs - energy for link metric? 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, 15 May 2009 06:38:48 -0000 Tim, thanks for the update - that's hard work. A side remark about one particular interest: the req list doesn't seem to include a metric for energy of the link: energy necessary to send a packet on the link, or energy radiated in the air, or similar. Or I can't find it - is there one? I do find reqs for energy as constraints of the node device: level of energy, energy of the node, power available, power budget, etc. Or is the link energy completely out of scope? Thanks, Alex Tim Winter a écrit : > WG, > > With the recent discussions regarding MUSTs, trade-offs, and how to > reconcile the 4 different requirements documents into one protocol, I > do hope that this update provides some useful insights into how the > DT is proceeding. > > Here is a list of extracted MUSTs, with some categorization, along > with uncategorized SHOULDs. > > Please do carefully note the following: 1) The source requirements > documents contain much more background text and detail for > interpreting the meaning and intent of the MUSTs than appears in this > summary list. This summary list is quite simply keyed off of MUSTs > (and SHOULDs) in the requirements documents. This list can be used > like an index, but the requirements documents give further context > which is important for detailed interpretation, and the requirements > documents are authoritative. 2) The categories presented here may be > considered a very coarse grouping. The intent was to begin to place > the 4 requirements documents side by side in a way that is > meaningful to begin interpretation, but is not intended to be a > precise taxonomy. Similarly, please do not place too much meaning in > the category names per se, they are perhaps coarse, but the intent is > that the grouped functionalities are related. Finally, the coarse > groupings may well produce `overlap' in some cases. 3) In some places > [editorial comments] are added that do not appear in the original > drafts. > > The design team underwent an exercise of going through and discussing > these requirements, and at a first cut asked `can this requirement > _not_ be satisfied?'. This exercise provides further familiarization > with the requirements as well as a crude `reality check' if you > will. > > > So far, no requirement is clearly ruled out, and there is a basis to > continue the discussion of what a routing protocol solution to meet > these requirements will look like. > > It is also clear when we look at these requirements that an attempt > to find or meet an intersection between all of them is very > challenging. Nevertheless, it is not our intended approach to pick > and choose, e.g. we do not want to say `let us define a protocol that > will satisfy XXX in HOME, but at the cost of YYY in INDUSTRIAL'. We > are tasked clearly to try and define _one_ protocol to satisfy _all_ > of the requirements. Perhaps as the process continues it will > become clear and necessary that such a `hard' trade-off needs to be > made to resolve some fundamental conflict, but it would be very > premature to say such things at this point. If such a trade-off > emerges and becomes inevitable, there will most certainly be very > careful discussion and justification to be made. > > This is the inspiration behind the approach we are taking: 1) define > a basic core protocol + optional extensions 2) allow the protocol to > be parameterized -> such that the implementor has the ability to make > appropriate detailed trade-offs with the guidance of applicability > statements as appropriate to the target application/platform. > > It is our hope that by following this approach we have a protocol > which provides a practical and implementable framework in which can > be made proper and measured compromises with respect to different > applications. > > We do hope not to end up with a duck ;) > > More updates to come as the work proceeds. > > Regards, > > -Tim > > > --------------------------------------------------------------------------- > > > > - Categorized MUSTs Sources: > draft-ietf-roll-urban-routing-reqs-05.txt > draft-ietf-roll-indus-routing-reqs-05.txt > draft-ietf-roll-building-routing-reqs-05.txt > draft-ietf-roll-home-routing-reqs-06.txt > > --------------------------------------------------------------------------- > > > > > A. General: ----------- A.1 URBAN: For the latter > [patches/updates], the protocol(s) MUST support multi- and any-cast > addressing. > > A.2 URBAN: Routing protocols activated in urban sensor networks > MUST support unicast (traffic is sent to a single field device), > multicast (traffic is sent to a set of devices that are subscribed to > the same multicast group), and anycast (where multiple field devices > are configured to accept traffic sent on a single IP anycast > address) transmission schemes. > > A.3 BUILDING: Routing MUST support anycast, unicast, and multicast. > > > > A.4 BUILDING: A network device MUST be able to communicate in a > peer- to-peer manner with any other device on the network. Thus, the > routing protocol MUST provide routes between arbitrary hosts within > the appropriate administrative domain. > > A.5 BUILDING: The routing protocol MUST support a metric of route > quality and optimize path selection according to such metrics within > constraints established for links along the paths. > > A.6 BUILDING: In such cases [sleeping nodes], the routing protocol > MUST discover the capability of a node to act as a proxy during path > calculation; then deliver the packet to the assigned proxy for later > delivery to the sleeping device upon its next awakened cycle. > > B. Traffic Flows: ----------------- [ Node -> (thru) LBR ] [ > (thru) LBR -> Node ] [ Node -> Node ] > > B.1 URBAN: The routing protocol MUST be able to accommodate > traffic bursts by dynamically computing and selecting multiple paths > towards the same destination. > > B.2 INDUSTRIAL: The routing protocol MUST be able to compute paths of > not-necessarily-equal cost toward a given destination so as to > enable load balancing across a variety of paths. > > B.3 INDUSTRIAL: The routing protocol MUST be able to compute a set of > unidirectional routes with potentially different costs that are > composed of one or more non-congruent paths. > > > C. Autonomous Configuration/Management/Reliability: > ---------------------------------------- C.1 URBAN: To this end, > the routing protocol(s) MUST provide a set of features including > 0-configuration at network ramp-up, (network-internal) self- > organization and configuration due to topological changes, and the > ability to support (network-external) patches and configuration > updates. > > C.2 INDUSTRIAL: The routing protocol MUST route on paths that are > changed to appropriately provision the application requirements. The > routing protocol MUST support the ability to recompute paths based > on Network Layer abstractions of the underlying link > attributes/metric that may change dynamically. > > C.3 INDUSTRIAL: The routing algorithm MUST be able to generate > different routes with different characteristics (e.g. optimized > according to difference cost, etc...). > > C.4 INDUSTRIAL: The routing protocol MUST enable the full discovery > and setup of the environment (available links, selected peers, > reachable network). The protocol also MUST support the distribution > of configuration from a centralized management controller if > operator-initiated configuration change is allowed. > > C.5 BUILDING: It MUST be possible to fully commission network > devices without requiring any additional commissioning device (e.g. > laptop). > > C.6 BUILDING: Devices referencing data in the replaced device MUST > be able to reference data in its replacement without being > reconfigured to refer to the new device. Thus, such a reference > cannot be a hardware identifier, such as the MAC address, nor a > hard-coded route. If such a reference is an IP address, the > replacement device MUST be assigned the IP addressed previously bound > to the replaced device. Or if the logical equivalent of a hostname > is used for the reference, it must be translated to the replacement > IP address. > > C.7 HOME: Thus the routing protocol designed for home > automation networks MUST provide a set of features including zero- > configuration of the routing protocol for a new node to be added to > the network. From a routing perspective, zero-configuration means > that a node can obtain an address and join the network on its own, > without human intervention. > > C.8 HOME: The routing protocol MUST support the ability to > isolate a misbehaving node thus preserving the correct operation of > the overall network. > > > D. Scalability: --------------- D.1 URBAN: The routing > protocol(s) MUST be capable of supporting the organization of a large > number of sensing nodes into regions containing on the order of 10^2 > to 10^4 sensing nodes each. > > D.2 URBAN: The routing protocol(s) MUST be scalable so as to > accommodate a very large and increasing number of nodes without > deteriorating selected performance parameters below configurable > thresholds. > > D.3 BUILDING: The routing protocol MUST be able to support networks > with at least 2000 nodes supporting at least 1000 routing devices > and 1000 non-routing device. Subnetworks (e.g. rooms, primary > equipment) within the network must support upwards to 255 sensors > and/or actuators. > > D.4 HOME: The routing protocol MUST support 250 devices in the > network. > > > E. Performance: --------------- E.1 INDUSTRIAL: The routing algorithm > MUST find the appropriate route(s) and report success or failure > within several minutes, and SHOULD report success or failure within > tens of seconds. > > E.2 INDUSTRIAL: The routing algorithm MUST respond to normal link > failure rates with routes that meet the Service requirements > (especially latency) throughout the routing response. The routing > algorithm SHOULD always be in the process of recalculating the route > in response to changing link statistics. The routing algorithm MUST > recalculate the paths when field devices change due to insertion, > removal or failure, and this recalculation MUST NOT cause latencies > greater than the specified constraints (typically seconds to > minutes). > > E.3 HOME: The routing protocol MUST provide mobility with > convergence time below 0.5 second if only the sender has moved. > > E.4 HOME: Sleeping nodes may appear to be non-responsive. The > routing protocol MUST take into account the delivery time to a > sleeping target node. The wake-up interval of a sleeping node MUST > be less than one second. > > E.5 HOME: The routing protocol MUST converge within 0.5 second > if no nodes have moved. > > E.6 HOME: The routing protocol MUST converge within 2 seconds > if the destination node of the packet has moved. > > > F. Constraint-based Routing: ---------------------------- F.1 URBAN: > To this end, the routing protocol(s) MUST support parameter > constrained routing, where examples of such parameters (CPU, memory > size, battery level, etc.) have been given in the previous paragraph. > In other words the routing protocol MUST be able to advertise node > capabilities that will be exclusively used by the routing protocol > engine for routing decision. > > F.2 INDUSTRIAL: The routing protocol MUST also support different > metric types for each link used to compute the path according to > some objective function (e.g. minimize latency) depending on the > nature of the traffic. > > F.3 INDUSTRIAL: The routing algorithm MUST support node-constrained > routing (e.g. taking into account the existing energy state as a node > constraint). Node constraints include power and memory, as well as > constraints placed on the device by the user, such as battery life. > > F.4 BUILDING: The routing protocol MUST take into account device > characteristics such as power budget. > > F.5 HOME: The routing protocol MUST support constraint-based > routing taking into account node properties (CPU, memory, level of > energy, sleep intervals, safety/convenience of changing battery). > > > G. Security: ------------ G.1 URBAN: The U-LLN network MUST deny > any node who has not been authenticated to the U-LLN and authorized > to participate to the routing decision process. > > G.2 URBAN: Mechanisms MUST be in place to deny any node which > attempts to take malicious advantage of self-configuration and self- > organization procedures. > > G.3 URBAN: A node MUST authenticate itself to a trusted node > that is already associated with the U-LLN before the former can take > part in self-configuration or self-organization. > > G.4 URBAN: A node that has already authenticated and associated > with the U-LLN MUST deny, to the maximum extent possible, the > allocation of resources to any unauthenticated peer. > > G.5 URBAN: The routing protocol(s) MUST deny service to any node > which has not clearly established trust with the U-LLN. > > G.6 URBAN: To this end, routing protocol(s) proposed in the > context of U-LLNs MUST support authentication and integrity measures > and SHOULD support confidentiality (routing security) measures. > > G.7 INDUSTRIAL: The routing MUST be configured and managed using > secure messages and protocols that prevent outsider attacks and limit > insider attacks from field devices installed in insecure locations > in the plant. > > G.8 BUILDING: Authentication policy and updates MUST be routable > over-the-air. > > G.9 BUILDING: Data encryption of packets MUST optionally be > supported by use of either a network wide key and/or application > key. > > G.10 BUILDING: The routing protocol MUST allow routing a packet > encrypted with an application key through forwarding devices that > without requiring each node in the path have the application key. > > G.11 BUILDING: The encryption policy MUST support encryption of the > payload only or the entire packet. > > G.12 BUILDING: Due to the limited resources of an LLN, the security > policy defined within the LLN MUST be able to differ from that of > the rest of the IP network within the facility yet packets MUST still > be able to route to or through the LLN from/to these networks. > > G.13 BUILDING: The routing protocol MUST gracefully handle routing > temporal security updates (e.g. dynamic keys) to sleeping devices on > their 'awake' cycle to assure that sleeping devices can readily and > efficiently access then network. > > G.14 HOME: The routing protocol chosen for ROLL MUST allow for > low- power, low-cost network devices with limited security needs. > > G.15 HOME: Protection against unintentional inclusion in > neighboring networks MUST be provided. > > > > --------------------------------------------------------------------------- > > > > --------------------------------------------------------------------------- > > > > --------------------------------------------------------------------------- > > > > - Uncategorized SHOULDs > --------------------------------------------------------------------------- > > > > draft-ietf-roll-building-routing-reqs > > --------------------------------------------------------------------------- > > > > 5.1.3. Local Testing > > Routing should allow for temporary ad hoc paths to be established > that are updated as the network physically and functionally expands. > > 5.3.1. Mobile Device Requirements > > To minimize network dynamics, mobile devices SHOULD not be allowed to > act as forwarding devices (routers) for other devices in the LLN. > > A mobile device that moves within an LLN SHOULD reestablish end-to- > end communication to a fixed device also in the LLN within 2 seconds. > The network convergence time should be less than 5 seconds once the > mobile device stops moving. > > A mobile device that moves outside of an LLN SHOULD reestablish end- > to-end communication to a fixed device in the new LLN within 5 > seconds. The network convergence time should be less than 5 seconds > once the mobile device stops moving. > > A mobile device that moves outside of one LLN into another LLN SHOULD > reestablish end-to-end communication to a fixed device in the old > LLN within 10 seconds. The network convergence time should be less > than 10 seconds once the mobile device stops. > > A mobile device that moves outside of one LLN into another LLN SHOULD > reestablish end-to-end communication to another mobile device in the > new LLN within 20 seconds. The network convergence time should be > less than 30 seconds once the mobile devices stop moving. > > A mobile device that moves outside of one LLN into another LLN SHOULD > reestablish end-to-end communication to a mobile device in the old > LLN within 30 seconds. The network convergence time should be less > than 30 seconds once the mobile devices stop moving. > > 5.4.1. Limited Processing Power for Non-routing Devices. > > The software size requirement for non-routing devices (e.g. sleeping > sensors and actuators) SHOULD be implementable in 8-bit devices with > no more than 128KB of memory. > > 5.4.2. Limited Processing Power for Routing Devices > > The software size requirements for routing devices (e.g. room > controllers) SHOULD be implementable in 8-bit devices with no more > than 256KB of flash memory. > > 5.6.2. Route Tracking > > Route diagnostics SHOULD be supported providing information such as > path quality; number of hops; available alternate active paths with > associated costs. Path quality is the relative measure of 'goodness' > of the selected source to destination path as compared to alternate > paths. This composite value may be measured as a function of hop > count, signal strength, available power, existing active paths or any > other criteria deemed by ROLL as the path cost differentiator. > > 5.7.1. Path Cost > > [...] These metrics SHOULD reflect metrics such as signal strength, > available bandwidth, hop count, energy availability and communication > error rates. > > 5.7.3. Route Redundancy > > The routing layer SHOULD be configurable to allow secondary and > tertiary paths to be established and used upon failure of the primary > path. > > 5.7.4. Route Discovery Time > > If route discovery occurs during packet transmission time, it SHOULD > NOT add more than 120ms of latency to the packet delivery time. > > 5.7.5. Route Preference > > Route cost algorithms SHOULD allow the installer to optionally select > 'preferred' paths based on the known spatial layout of the > communicating devices. > > --------------------------------------------------------------------------- > > > > draft-ietf-roll-home-routing-reqs > > --------------------------------------------------------------------------- > > > > > > --------------------------------------------------------------------------- > > > > roll-indus-routing-reqs > > --------------------------------------------------------------------------- > - In fast control, tens of milliseconds of latency is typical. > > [...] > > For these reasons, the ROLL routing infrastructure is required to > compute and update constrained routes on demand, and it can be > expected that this model will become more prevalent for field device > to field device connectivity as well as for some field device to > Infrastructure devices over time. > > [ A route that connects a field device to a plant application may > have multiple paths that go through more than one LLN access point. > The routing protocol MUST be able to compute paths of > not-necessarily-equal cost toward a given destination so as to enable > load balancing across a variety of paths. The availability of each > path in a multipath route can change over time. Hence, it is > important to measure the availability on a per-path basis and select > a path (or paths) according to the availability requirements. ] > > The routing protocol SHOULD support broadcast or multicast > addressing. > > 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. The routing protocol SHOULD also > support the bandwidth allocation for bulk transfers between the field > device and the handheld device of the wireless worker. The routing > protocol SHOULD support walking speeds for maintaining network > connectivity as the handheld device changes position in the wireless > network. > > The routing protocol SHOULD NOT require to preprovision information > about the environment where the node will be deployed. The routing > protocol MUST enable the full discovery and setup of the environment > (available links, selected peers, reachable network).The protocol > also MUST support the distribution of configuration from a > centralized management controller if operator-initiated configuration > change is allowed. > > In industrial plants it must be assumed that the field devices have > marginal physical security and might be compromised. The routing > protocol SHOULD limit the risk incurred by one node being > compromised, for instance by proposing non congruent path for a given > route and balancing the traffic across the network. > > The routing protocol SHOULD compartmentalize the trust placed in > field devices so that a compromised field device does not destroy the > security of the whole network. > > --------------------------------------------------------------------------- > - draft-ietf-roll-urban-routing-reqs-04 > > --------------------------------------------------------------------------- > - The routing protocols(s) SHOULD support the organization of a > large number of nodes into regions of configurable size. > > Routing within urban sensor networks SHOULD require the U-LLN nodes > to dynamically compute, select and install different paths towards a > same destination, depending on the nature of the traffic. Such > functionality in support of, for example, data aggregation, may imply > to use some mechanisms to mark/tag the traffic for appropriate > routing decision using the IPv6 packet format (e.g. use of DSCP, Flow > Label) based on an upper layer marking decision. > > The protocol(s) SHOULD also support the formation and identification > of groups of field devices in the network. > > The routing protocol(s) SHOULD be able to dynamically adapt, e.g. > through the application of appropriate routing metrics, to ever- > changing conditions of communication (possible degradation of QoS, > variable nature of the traffic (real time vs. non real time, sensed > data vs. alerts), node mobility, a combination thereof, etc.) > > The routing protocol(s) SHOULD be able to dynamically compute, select > and possibly optimize the (multiple) path(s) that will be used by the > participating devices to forward the traffic towards the actuators > and/or a LBR according to the service-specific and traffic-specific > QoS, traffic engineering and routing security policies that will > have to be enforced at the scale of a routing domain (that is, a set > of networking devices administered by a globally unique entity), or a > region of such domain (e.g. a metropolitan area composed of clusters > of sensors). > > To this end, local network dynamics SHOULD NOT impact the entire > network to be re-organized or re-reconfigured; however, the network > SHOULD be locally optimized to cater for the encountered changes. The > routing protocol(s) SHOULD support appropriate mechanisms in order > to be informed of the association, disassociation, and disappearance > of nodes. The routing protocol(s) SHOULD support appropriate > updating mechanisms in order to be informed of changes in > connectivity. The routing protocol(s) SHOULD use this information > to initiate protocol specific mechanisms for reorganization and > reconfiguration as necessary to maintain overall routing efficiency. > Convergence and route establishment times SHOULD be significantly > lower than the smallest reporting interval. > > Differentiation SHOULD be made between node disappearance, where the > node disappears without prior notification, and user or node- > initiated disassociation ("phased-out"), where the node has enough > time to inform the network about its pending removal. > > The routing protocol(s) SHOULD also support the ability to route > according to different metrics (one of which could e.g. be latency). > > The routing protocol(s) SHOULD support defense against DoS attacks > and other attempts to maliciously or inadvertently cause the routing > protocol(s) mechanisms to over consume the limited resources of LLN > nodes, e.g. by constructing forwarding loops or causing excessive > routing protocol overhead traffic, etc. > > The U-LLN SHOULD NOT interface with any external network which has > not established trust. The U-LLN SHOULD be capable of limiting the > resources granted in support of an external network so as not to be > vulnerable to DoS. > > --------------------------------------------------------------------------- > > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From jvasseur@cisco.com Fri May 15 00:54: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 ABA813A69D5 for ; Fri, 15 May 2009 00:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.208 X-Spam-Level: X-Spam-Status: No, score=-10.208 tagged_above=-999 required=5 tests=[AWL=0.391, 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 1PyicxbklH+h for ; Fri, 15 May 2009 00:54:44 -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 CB6383A69FC for ; Fri, 15 May 2009 00:54:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,198,1241395200"; d="scan'208";a="40653418" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 15 May 2009 07:56:14 +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 n4F7uE4e019046; Fri, 15 May 2009 09:56:14 +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 n4F7uEFg022341; Fri, 15 May 2009 07:56:14 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, 15 May 2009 09:56:14 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 May 2009 09:56:13 +0200 Message-Id: <32277E97-A9EF-4803-B797-FACCA21AFDB8@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4A0D0E3E.6000407@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, 15 May 2009 09:56:12 +0200 References: <4A0CCEE8.8020709@acm.org> <4A0D0E3E.6000407@gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 15 May 2009 07:56:13.0823 (UTC) FILETIME=[9E5520F0:01C9D532] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=27937; t=1242374174; x=1243238174; 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]=20DT=20update=20--=20MUSTs=20-=2 0energy=20for=20link=20metric? |Sender:=20; bh=JKLB+ymkQ5aRPHjMaprPDghcQyHVXw8Wn55B5aH30Ao=; b=m4qg48Vs2jFIT4qvHeZrihnlW4XtT7rocGPiit2+iACA4fcmy7BoI5pNf8 4rDSf6kw2O1uJEPUSzPSqqyNV6JlA7BjNSy/vupvMNJtRerpKJ9TDGBdjqeh ByDezbfqw1; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] DT update -- MUSTs - energy for link metric? 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, 15 May 2009 07:54:46 -0000 Hi Alex, On May 15, 2009, at 8:39 AM, Alexandru Petrescu wrote: > Tim, thanks for the update - that's hard work. > > A side remark about one particular interest: the req list doesn't seem > to include a metric for energy of the link: energy necessary to send a > packet on the link, or energy radiated in the air, or similar. > > Or I can't find it - is there one? First a general but important comment: Requirements document are =20 extremely important "guidelines". We (as a WG) may have to conclude =20 that a MUST cannot be satisfied, which is perfectly acceptable as long =20= as we document the rationale. Answering your question, a link energy metric will be discussed in the =20= context of the Metric I-D (where all metrics for the routing protocols =20= will be defined) and does not have to be listed on the requirements =20 list. If the WG thinks that we need it, we will work on it. > > I do find reqs for energy as constraints of the node device: level of > energy, energy of the node, power available, power budget, etc. > > Or is the link energy completely out of scope? > It is not. Let's see whether we all think that this is required. Cheers. JP. > Thanks, > > Alex > > Tim Winter a =E9crit : >> WG, >> With the recent discussions regarding MUSTs, trade-offs, and how to =20= >> reconcile the 4 different requirements documents into one protocol, I >> do hope that this update provides some useful insights into how the =20= >> DT is proceeding. >> Here is a list of extracted MUSTs, with some categorization, along =20= >> with uncategorized SHOULDs. >> Please do carefully note the following: 1) The source requirements =20= >> documents contain much more background text and detail for =20 >> interpreting the meaning and intent of the MUSTs than appears in this >> summary list. This summary list is quite simply keyed off of MUSTs =20= >> (and SHOULDs) in the requirements documents. This list can be used =20= >> like an index, but the requirements documents give further context =20= >> which is important for detailed interpretation, and the requirements >> documents are authoritative. 2) The categories presented here may be >> considered a very coarse grouping. The intent was to begin to place >> the 4 requirements documents side by side in a way that is >> meaningful to begin interpretation, but is not intended to be a >> precise taxonomy. Similarly, please do not place too much meaning in >> the category names per se, they are perhaps coarse, but the intent is >> that the grouped functionalities are related. Finally, the coarse =20= >> groupings may well produce `overlap' in some cases. 3) In some places >> [editorial comments] are added that do not appear in the original =20 >> drafts. >> The design team underwent an exercise of going through and discussing >> these requirements, and at a first cut asked `can this requirement =20= >> _not_ be satisfied?'. This exercise provides further familiarization >> with the requirements as well as a crude `reality check' if you >> will. >> So far, no requirement is clearly ruled out, and there is a basis to >> continue the discussion of what a routing protocol solution to meet =20= >> these requirements will look like. >> It is also clear when we look at these requirements that an attempt =20= >> to find or meet an intersection between all of them is very =20 >> challenging. Nevertheless, it is not our intended approach to pick =20= >> and choose, e.g. we do not want to say `let us define a protocol that >> will satisfy XXX in HOME, but at the cost of YYY in INDUSTRIAL'. We >> are tasked clearly to try and define _one_ protocol to satisfy _all_ >> of the requirements. Perhaps as the process continues it will >> become clear and necessary that such a `hard' trade-off needs to be >> made to resolve some fundamental conflict, but it would be very >> premature to say such things at this point. If such a trade-off >> emerges and becomes inevitable, there will most certainly be very >> careful discussion and justification to be made. >> This is the inspiration behind the approach we are taking: 1) =20 >> define a basic core protocol + optional extensions 2) allow the =20 >> protocol to be parameterized -> such that the implementor has the =20 >> ability to make >> appropriate detailed trade-offs with the guidance of applicability =20= >> statements as appropriate to the target application/platform. >> It is our hope that by following this approach we have a protocol =20 >> which provides a practical and implementable framework in which can =20= >> be made proper and measured compromises with respect to different =20 >> applications. >> We do hope not to end up with a duck ;) >> More updates to come as the work proceeds. >> Regards, >> -Tim >> = --------------------------------------------------------------------------= - >> - Categorized MUSTs Sources: draft-ietf-roll-urban-routing-=20 >> reqs-05.txt draft-ietf-roll-indus-routing-reqs-05.txt draft-ietf-=20 >> roll-building-routing-reqs-05.txt draft-ietf-roll-home-routing-=20 >> reqs-06.txt >> = --------------------------------------------------------------------------= - >> A. General: ----------- A.1 URBAN: For the latter [patches/=20 >> updates], the protocol(s) MUST support multi- and any-cast =20 >> addressing. >> A.2 URBAN: Routing protocols activated in urban sensor =20 >> networks MUST support unicast (traffic is sent to a single field =20 >> device), multicast (traffic is sent to a set of devices that are =20 >> subscribed to >> the same multicast group), and anycast (where multiple field devices >> are configured to accept traffic sent on a single IP anycast >> address) transmission schemes. >> A.3 BUILDING: Routing MUST support anycast, unicast, and multicast. >> A.4 BUILDING: A network device MUST be able to communicate in a =20 >> peer- to-peer manner with any other device on the network. Thus, the >> routing protocol MUST provide routes between arbitrary hosts within =20= >> the appropriate administrative domain. >> A.5 BUILDING: The routing protocol MUST support a metric of route =20= >> quality and optimize path selection according to such metrics within >> constraints established for links along the paths. >> A.6 BUILDING: In such cases [sleeping nodes], the routing =20 >> protocol MUST discover the capability of a node to act as a proxy =20= >> during path >> calculation; then deliver the packet to the assigned proxy for later >> delivery to the sleeping device upon its next awakened cycle. >> B. Traffic Flows: ----------------- [ Node -> (thru) LBR ] =20= >> [ (thru) LBR -> Node ] [ Node -> Node ] >> B.1 URBAN: The routing protocol MUST be able to accommodate =20 >> traffic bursts by dynamically computing and selecting multiple paths >> towards the same destination. >> B.2 INDUSTRIAL: The routing protocol MUST be able to compute paths of >> not-necessarily-equal cost toward a given destination so as to =20 >> enable load balancing across a variety of paths. >> B.3 INDUSTRIAL: The routing protocol MUST be able to compute a set of >> unidirectional routes with potentially different costs that are =20 >> composed of one or more non-congruent paths. >> C. Autonomous Configuration/Management/Reliability: =20 >> ---------------------------------------- C.1 URBAN: To this end, >> the routing protocol(s) MUST provide a set of features including 0-=20= >> configuration at network ramp-up, (network-internal) self- =20 >> organization and configuration due to topological changes, and the =20= >> ability to support (network-external) patches and configuration =20 >> updates. >> C.2 INDUSTRIAL: The routing protocol MUST route on paths that are =20 >> changed to appropriately provision the application requirements. The >> routing protocol MUST support the ability to recompute paths based =20= >> on Network Layer abstractions of the underlying link attributes/=20 >> metric that may change dynamically. >> C.3 INDUSTRIAL: The routing algorithm MUST be able to generate =20 >> different routes with different characteristics (e.g. optimized =20 >> according to difference cost, etc...). >> C.4 INDUSTRIAL: The routing protocol MUST enable the full discovery =20= >> and setup of the environment (available links, selected peers, =20 >> reachable network). The protocol also MUST support the =20 >> distribution of configuration from a centralized management =20 >> controller if operator-initiated configuration change is allowed. >> C.5 BUILDING: It MUST be possible to fully commission network =20 >> devices without requiring any additional commissioning device (e.g. =20= >> laptop). >> C.6 BUILDING: Devices referencing data in the replaced device =20 >> MUST be able to reference data in its replacement without being =20 >> reconfigured to refer to the new device. Thus, such a reference =20 >> cannot be a hardware identifier, such as the MAC address, nor a =20 >> hard-coded route. If such a reference is an IP address, the =20 >> replacement device MUST be assigned the IP addressed previously bound >> to the replaced device. Or if the logical equivalent of a hostname >> is used for the reference, it must be translated to the replacement >> IP address. >> C.7 HOME: Thus the routing protocol designed for home =20 >> automation networks MUST provide a set of features including zero- =20= >> configuration of the routing protocol for a new node to be added to =20= >> the network. =46rom a routing perspective, zero-configuration means =20= >> that a node can obtain an address and join the network on its own, =20= >> without human intervention. >> C.8 HOME: The routing protocol MUST support the ability to =20 >> isolate a misbehaving node thus preserving the correct operation of =20= >> the overall network. >> D. Scalability: --------------- D.1 URBAN: The routing =20 >> protocol(s) MUST be capable of supporting the organization of a large >> number of sensing nodes into regions containing on the order of 10^2 >> to 10^4 sensing nodes each. >> D.2 URBAN: The routing protocol(s) MUST be scalable so as to =20 >> accommodate a very large and increasing number of nodes without =20 >> deteriorating selected performance parameters below configurable =20 >> thresholds. >> D.3 BUILDING: The routing protocol MUST be able to support networks >> with at least 2000 nodes supporting at least 1000 routing devices >> and 1000 non-routing device. Subnetworks (e.g. rooms, primary =20 >> equipment) within the network must support upwards to 255 sensors =20 >> and/or actuators. >> D.4 HOME: The routing protocol MUST support 250 devices in =20 >> the network. >> E. Performance: --------------- E.1 INDUSTRIAL: The routing algorithm >> MUST find the appropriate route(s) and report success or failure =20 >> within several minutes, and SHOULD report success or failure within =20= >> tens of seconds. >> E.2 INDUSTRIAL: The routing algorithm MUST respond to normal link =20 >> failure rates with routes that meet the Service requirements =20 >> (especially latency) throughout the routing response. The routing =20= >> algorithm SHOULD always be in the process of recalculating the =20 >> route in response to changing link statistics. The routing =20 >> algorithm MUST recalculate the paths when field devices change due =20= >> to insertion, removal or failure, and this recalculation MUST NOT =20 >> cause latencies greater than the specified constraints (typically =20= >> seconds to minutes). >> E.3 HOME: The routing protocol MUST provide mobility with =20 >> convergence time below 0.5 second if only the sender has moved. >> E.4 HOME: Sleeping nodes may appear to be non-responsive. The =20= >> routing protocol MUST take into account the delivery time to a =20 >> sleeping target node. The wake-up interval of a sleeping node MUST =20= >> be less than one second. >> E.5 HOME: The routing protocol MUST converge within 0.5 =20 >> second if no nodes have moved. >> E.6 HOME: The routing protocol MUST converge within 2 seconds =20= >> if the destination node of the packet has moved. >> F. Constraint-based Routing: ---------------------------- F.1 =20 >> URBAN: To this end, the routing protocol(s) MUST support parameter =20= >> constrained routing, where examples of such parameters (CPU, memory =20= >> size, battery level, etc.) have been given in the previous paragraph. >> In other words the routing protocol MUST be able to advertise node =20= >> capabilities that will be exclusively used by the routing protocol =20= >> engine for routing decision. >> F.2 INDUSTRIAL: The routing protocol MUST also support different =20 >> metric types for each link used to compute the path according to =20 >> some objective function (e.g. minimize latency) depending on the =20 >> nature of the traffic. >> F.3 INDUSTRIAL: The routing algorithm MUST support node-constrained =20= >> routing (e.g. taking into account the existing energy state as a node >> constraint). Node constraints include power and memory, as well as =20= >> constraints placed on the device by the user, such as battery life. >> F.4 BUILDING: The routing protocol MUST take into account device =20= >> characteristics such as power budget. >> F.5 HOME: The routing protocol MUST support constraint-based =20= >> routing taking into account node properties (CPU, memory, level of =20= >> energy, sleep intervals, safety/convenience of changing battery). >> G. Security: ------------ G.1 URBAN: The U-LLN network MUST deny >> any node who has not been authenticated to the U-LLN and authorized =20= >> to participate to the routing decision process. >> G.2 URBAN: Mechanisms MUST be in place to deny any node which =20= >> attempts to take malicious advantage of self-configuration and self- >> organization procedures. >> G.3 URBAN: A node MUST authenticate itself to a trusted node =20 >> that is already associated with the U-LLN before the former can take >> part in self-configuration or self-organization. >> G.4 URBAN: A node that has already authenticated and =20 >> associated with the U-LLN MUST deny, to the maximum extent =20 >> possible, the allocation of resources to any unauthenticated peer. >> G.5 URBAN: The routing protocol(s) MUST deny service to any node >> which has not clearly established trust with the U-LLN. >> G.6 URBAN: To this end, routing protocol(s) proposed in the =20 >> context of U-LLNs MUST support authentication and integrity =20 >> measures and SHOULD support confidentiality (routing security) =20 >> measures. >> G.7 INDUSTRIAL: The routing MUST be configured and managed using =20 >> secure messages and protocols that prevent outsider attacks and limit >> insider attacks from field devices installed in insecure locations =20= >> in the plant. >> G.8 BUILDING: Authentication policy and updates MUST be routable =20= >> over-the-air. >> G.9 BUILDING: Data encryption of packets MUST optionally be =20 >> supported by use of either a network wide key and/or application =20 >> key. >> G.10 BUILDING: The routing protocol MUST allow routing a packet =20 >> encrypted with an application key through forwarding devices that =20 >> without requiring each node in the path have the application key. >> G.11 BUILDING: The encryption policy MUST support encryption of the >> payload only or the entire packet. >> G.12 BUILDING: Due to the limited resources of an LLN, the security >> policy defined within the LLN MUST be able to differ from that of >> the rest of the IP network within the facility yet packets MUST still >> be able to route to or through the LLN from/to these networks. >> G.13 BUILDING: The routing protocol MUST gracefully handle =20 >> routing temporal security updates (e.g. dynamic keys) to sleeping =20 >> devices on >> their 'awake' cycle to assure that sleeping devices can readily and =20= >> efficiently access then network. >> G.14 HOME: The routing protocol chosen for ROLL MUST allow =20 >> for low- power, low-cost network devices with limited security needs. >> G.15 HOME: Protection against unintentional inclusion in =20 >> neighboring networks MUST be provided. >> = --------------------------------------------------------------------------= - >> = --------------------------------------------------------------------------= - >> = --------------------------------------------------------------------------= - >> - Uncategorized SHOULDs =20 >> = --------------------------------------------------------------------------= - >> draft-ietf-roll-building-routing-reqs >> = --------------------------------------------------------------------------= - >> 5.1.3. Local Testing >> Routing should allow for temporary ad hoc paths to be established =20 >> that are updated as the network physically and functionally expands. >> 5.3.1. Mobile Device Requirements >> To minimize network dynamics, mobile devices SHOULD not be allowed to >> act as forwarding devices (routers) for other devices in the LLN. >> A mobile device that moves within an LLN SHOULD reestablish end-to- =20= >> end communication to a fixed device also in the LLN within 2 seconds. >> The network convergence time should be less than 5 seconds once the =20= >> mobile device stops moving. >> A mobile device that moves outside of an LLN SHOULD reestablish end- >> to-end communication to a fixed device in the new LLN within 5 =20 >> seconds. The network convergence time should be less than 5 =20 >> seconds once the mobile device stops moving. >> A mobile device that moves outside of one LLN into another LLN SHOULD >> reestablish end-to-end communication to a fixed device in the old >> LLN within 10 seconds. The network convergence time should be less >> than 10 seconds once the mobile device stops. >> A mobile device that moves outside of one LLN into another LLN SHOULD >> reestablish end-to-end communication to another mobile device in the >> new LLN within 20 seconds. The network convergence time should be >> less than 30 seconds once the mobile devices stop moving. >> A mobile device that moves outside of one LLN into another LLN SHOULD >> reestablish end-to-end communication to a mobile device in the old >> LLN within 30 seconds. The network convergence time should be less >> than 30 seconds once the mobile devices stop moving. >> 5.4.1. Limited Processing Power for Non-routing Devices. >> The software size requirement for non-routing devices (e.g. sleeping >> sensors and actuators) SHOULD be implementable in 8-bit devices with >> no more than 128KB of memory. >> 5.4.2. Limited Processing Power for Routing Devices >> The software size requirements for routing devices (e.g. room =20 >> controllers) SHOULD be implementable in 8-bit devices with no more =20= >> than 256KB of flash memory. >> 5.6.2. Route Tracking >> Route diagnostics SHOULD be supported providing information such as =20= >> path quality; number of hops; available alternate active paths with =20= >> associated costs. Path quality is the relative measure of 'goodness' >> of the selected source to destination path as compared to alternate =20= >> paths. This composite value may be measured as a function of hop =20 >> count, signal strength, available power, existing active paths or any >> other criteria deemed by ROLL as the path cost differentiator. >> 5.7.1. Path Cost >> [...] These metrics SHOULD reflect metrics such as signal strength, =20= >> available bandwidth, hop count, energy availability and communication >> error rates. >> 5.7.3. Route Redundancy >> The routing layer SHOULD be configurable to allow secondary and =20 >> tertiary paths to be established and used upon failure of the primary >> path. >> 5.7.4. Route Discovery Time >> If route discovery occurs during packet transmission time, it =20 >> SHOULD NOT add more than 120ms of latency to the packet delivery =20 >> time. >> 5.7.5. Route Preference >> Route cost algorithms SHOULD allow the installer to optionally select >> 'preferred' paths based on the known spatial layout of the =20 >> communicating devices. >> = --------------------------------------------------------------------------= - >> draft-ietf-roll-home-routing-reqs >> = --------------------------------------------------------------------------= - >> >> = --------------------------------------------------------------------------= - >> roll-indus-routing-reqs >> = --------------------------------------------------------------------------= - >> - In fast control, tens of milliseconds of latency is typical. >> [...] >> For these reasons, the ROLL routing infrastructure is required to =20 >> compute and update constrained routes on demand, and it can be =20 >> expected that this model will become more prevalent for field =20 >> device to field device connectivity as well as for some field =20 >> device to Infrastructure devices over time. >> [ A route that connects a field device to a plant application may =20 >> have multiple paths that go through more than one LLN access =20 >> point. The routing protocol MUST be able to compute paths of not-=20 >> necessarily-equal cost toward a given destination so as to enable >> load balancing across a variety of paths. The availability of each =20= >> path in a multipath route can change over time. Hence, it is =20 >> important to measure the availability on a per-path basis and =20 >> select a path (or paths) according to the availability =20 >> requirements. ] >> The routing protocol SHOULD support broadcast or multicast =20 >> addressing. >> The routing protocol SHOULD support the wireless worker with fast =20 >> network connection times of a few of seconds, and low command and =20 >> response latencies to the plant behind the LLN access points, to =20 >> applications, and to field devices. The routing protocol SHOULD also >> support the bandwidth allocation for bulk transfers between the field >> device and the handheld device of the wireless worker. The routing >> protocol SHOULD support walking speeds for maintaining network >> connectivity as the handheld device changes position in the wireless >> network. >> The routing protocol SHOULD NOT require to preprovision information =20= >> about the environment where the node will be deployed. The routing =20= >> protocol MUST enable the full discovery and setup of the =20 >> environment (available links, selected peers, reachable =20 >> network).The protocol also MUST support the distribution of =20 >> configuration from a centralized management controller if operator-=20= >> initiated configuration >> change is allowed. >> In industrial plants it must be assumed that the field devices have =20= >> marginal physical security and might be compromised. The routing =20 >> protocol SHOULD limit the risk incurred by one node being =20 >> compromised, for instance by proposing non congruent path for a given >> route and balancing the traffic across the network. >> The routing protocol SHOULD compartmentalize the trust placed in =20 >> field devices so that a compromised field device does not destroy the >> security of the whole network. >> = --------------------------------------------------------------------------= - >> - draft-ietf-roll-urban-routing-reqs-04 >> = --------------------------------------------------------------------------= - >> - The routing protocols(s) SHOULD support the organization of a =20 >> large number of nodes into regions of configurable size. >> Routing within urban sensor networks SHOULD require the U-LLN nodes =20= >> to dynamically compute, select and install different paths towards =20= >> a same destination, depending on the nature of the traffic. Such =20 >> functionality in support of, for example, data aggregation, may imply >> to use some mechanisms to mark/tag the traffic for appropriate =20 >> routing decision using the IPv6 packet format (e.g. use of DSCP, Flow >> Label) based on an upper layer marking decision. >> The protocol(s) SHOULD also support the formation and =20 >> identification of groups of field devices in the network. >> The routing protocol(s) SHOULD be able to dynamically adapt, e.g. =20 >> through the application of appropriate routing metrics, to ever- =20 >> changing conditions of communication (possible degradation of QoS, =20= >> variable nature of the traffic (real time vs. non real time, sensed =20= >> data vs. alerts), node mobility, a combination thereof, etc.) >> The routing protocol(s) SHOULD be able to dynamically compute, select >> and possibly optimize the (multiple) path(s) that will be used by the >> participating devices to forward the traffic towards the actuators >> and/or a LBR according to the service-specific and traffic-specific >> QoS, traffic engineering and routing security policies that will >> have to be enforced at the scale of a routing domain (that is, a set >> of networking devices administered by a globally unique entity), or a >> region of such domain (e.g. a metropolitan area composed of clusters >> of sensors). >> To this end, local network dynamics SHOULD NOT impact the entire =20 >> network to be re-organized or re-reconfigured; however, the network =20= >> SHOULD be locally optimized to cater for the encountered changes. The >> routing protocol(s) SHOULD support appropriate mechanisms in order >> to be informed of the association, disassociation, and disappearance >> of nodes. The routing protocol(s) SHOULD support appropriate >> updating mechanisms in order to be informed of changes in >> connectivity. The routing protocol(s) SHOULD use this information >> to initiate protocol specific mechanisms for reorganization and >> reconfiguration as necessary to maintain overall routing efficiency. >> Convergence and route establishment times SHOULD be significantly >> lower than the smallest reporting interval. >> Differentiation SHOULD be made between node disappearance, where =20 >> the node disappears without prior notification, and user or node- =20 >> initiated disassociation ("phased-out"), where the node has enough =20= >> time to inform the network about its pending removal. >> The routing protocol(s) SHOULD also support the ability to route =20 >> according to different metrics (one of which could e.g. be latency). >> The routing protocol(s) SHOULD support defense against DoS attacks =20= >> and other attempts to maliciously or inadvertently cause the =20 >> routing protocol(s) mechanisms to over consume the limited =20 >> resources of LLN nodes, e.g. by constructing forwarding loops or =20 >> causing excessive routing protocol overhead traffic, etc. >> The U-LLN SHOULD NOT interface with any external network which has =20= >> not established trust. The U-LLN SHOULD be capable of limiting the =20= >> resources granted in support of an external network so as not to be =20= >> vulnerable to DoS. >> = --------------------------------------------------------------------------= - >> _______________________________________________ Roll mailing list = Roll@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Fri May 15 00:59: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 58BC43A6A7F; Fri, 15 May 2009 00:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.212 X-Spam-Level: X-Spam-Status: No, score=-10.212 tagged_above=-999 required=5 tests=[AWL=0.387, 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 Wm5uP-mHFWJe; Fri, 15 May 2009 00:59: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 C33CE3A6830; Fri, 15 May 2009 00:59:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,198,1241395200"; d="scan'208";a="40654022" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 15 May 2009 08:00:50 +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 n4F80onP027187; Fri, 15 May 2009 10:00:50 +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 n4F80oEJ023957; Fri, 15 May 2009 08:00:50 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); Fri, 15 May 2009 10:00:50 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 May 2009 10:00:49 +0200 Message-Id: <2924ACF1-605D-416A-AAE5-5EFA8A8C59A7@cisco.com> From: JP Vasseur To: "Dearlove, Christopher (UK)" In-Reply-To: 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, 15 May 2009 10:00:48 +0200 References: <314C5D40-78D3-4F66-AD40-093588E2233F@cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 15 May 2009 08:00:49.0604 (UTC) FILETIME=[42B5F840:01C9D533] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2485; t=1242374450; x=1243238450; 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]=20Few=20comments=20for=20our=20f irst=20discussion=20today |Sender:=20; bh=E9RPQEq1YQVzWRZr8B+d/yw0A8Z5Q70MpZbfN936hfo=; b=qpvr96joWscdHS2mmVV0K18dFFZmFCPcUWuvsexl2yYxQlTC8EOdCVtlc4 fAfch5XBZgFF5WD8EIdakHPfD5iKDvT4GEAIT3zA6ERF8wcL+lXOe9vV43u2 MA3QlbHHE7; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll-bounces@ietf.org, ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] Few comments for our first discussion today 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, 15 May 2009 07:59:19 -0000 Hi Christopher, On May 14, 2009, at 5:05 PM, Dearlove, Christopher (UK) wrote: > JP Vasseur >> That is an excellent suggestion. Since regrouping the requirements >> (MUST) is a starting point, we'll make sure to send it to the list. >> Note that the point is not to rediscuss any of these of course. > > If there are any resolutions of differences between the documents > then to that extent, discussing the MUSTs is inevitable, you can't > simply say don't rediscuss. > Let me clarify what I mean by "rediscuss": I was referring to not reopening the discussion on the requirements. We will have to make compromise between the MUST, SHOULD, ... and in some cases we may not be able to satisfy them all, which is acceptable, as long as it is documented. Of course, each time I say "we" I mean the WG. > And there are significant differences. The number of nodes to support > varies (and by a couple of orders of magnitude). The route finding > time varies from seconds to minutes. Yes, you could say "take the > worst case for each". But now you have a large network, with a low > latency - and a specification (in one of the drafts) for any peer > to peer routing. And authentication has to be both compulsory and > optional (OK, SHOULD technically rather than MUST for the latter, > but still an issue - and I haven't checked all details of all four > drafts). > > If anyone can achieve all the MUSTs (let alone the SHOULDs) in all > drafts, excellent. But I suspect not, as document A may make a > demand that's reasonable for its (for example) lower number of nodes, > but not so easy for document B's higher number of nodes, especially > in combination with document C's latency. I strongly suspect some > trading off of requirements will be needed. And that's going to need > agreement. Completely agreeing. JP. > > ******************************************************************** > 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 From jvasseur@cisco.com Fri May 15 01:00: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 585343A6830; Fri, 15 May 2009 01:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.216 X-Spam-Level: X-Spam-Status: No, score=-10.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 LU1YHUvtdNdw; Fri, 15 May 2009 01:00: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 02A953A69D5; Fri, 15 May 2009 01:00:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,198,1241395200"; d="scan'208";a="40654140" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 15 May 2009 08:01: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 n4F81e1Y020859; Fri, 15 May 2009 10:01:40 +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 n4F81eeP024279; Fri, 15 May 2009 08:01:40 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); Fri, 15 May 2009 10:01:40 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 May 2009 10:01:39 +0200 Message-Id: <48D86EE0-9E1E-4F10-B49C-41CE6F971FE0@cisco.com> From: JP Vasseur To: Philip Levis In-Reply-To: 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, 15 May 2009 10:01:38 +0200 References: <314C5D40-78D3-4F66-AD40-093588E2233F@cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 15 May 2009 08:01:40.0244 (UTC) FILETIME=[60E50540:01C9D533] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1484; t=1242374500; x=1243238500; 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]=20Few=20comments=20for=20our=20f irst=20discussion=20today |Sender:=20; bh=zbfwE9+2lpIUS6Jlg8HPvL+GCPTofhF7cP34BfrfQyc=; b=i54HGksRXvFsipqGTf2iggjcMm9Ry9Jtb2/JNIfAMLUkOqlKuTSgpnIUuE Sx7h2C4j9oVGoJBGdwV70Zu5+CStXTro8hNdXr05qr0DAopWlrj/fFw37gMv L/QRsbhjx2; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "Dearlove, Christopher \(UK\)" , roll-bounces@ietf.org, ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] Few comments for our first discussion today 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, 15 May 2009 08:00:09 -0000 On May 14, 2009, at 7:11 PM, Philip Levis wrote: > > On May 14, 2009, at 8:10 AM, Dearlove, Christopher (UK) wrote: > >> Philip Levis >>> Clearly the MUSTs are simply a synthesis of the application drafts >>> and >> >>> so not really worth discussing, unless WG members find a >>> misreading or >> >>> typo. >> >> I think that is absolutely not the case. What's your synthesis, all >> worst cases to be supported simultaneously? Something else? > > Oh, I think there's a misunderstanding here. Where the protocol > survey document was very clear in that it did not treat application > requirements exhaustively, a protocol design needs to. > > I think the point the DT is making by separating "core" from > "optional" is that there might be a set of MUSTs which most if not > all applications share, which you then want in the core protocol. > MUSTs which are only in a subset of the applications might then be > served by optional extensions. That is exactly right. > >> I would love to understand the DT's approach. Where is it explained, >> in particular with regard to how conflicting requirements are being >> reconciled? > > I think they're in this process now: let's not burden them with over- > documentation of every minutia and prevent them from getting work > done. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From cabo@tzi.org Fri May 15 01:32: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 5EA9728C124; Fri, 15 May 2009 01:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 DKxz5Kiakphb; Fri, 15 May 2009 01:32:26 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id ED40D3A6C55; Fri, 15 May 2009 01:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n4F8W8wZ023853; Fri, 15 May 2009 10:32:08 +0200 (CEST) Received: from [192.168.217.107] (p5489E321.dip.t-dialin.net [84.137.227.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id A95721704D6; Fri, 15 May 2009 10:32:07 +0200 (CEST) From: Carsten Bormann To: Jerald.P.Martocci@jci.com In-Reply-To: References: Message-Id: <72FD9706-4821-4F67-B283-6101996593E2@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 15 May 2009 10:32:06 +0200 X-Mailer: Apple Mail (2.935.3) Cc: roll-bounces@ietf.org, ROLL WG Subject: Re: [Roll] 14kb 8-bit micro-controllers... 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, 15 May 2009 08:32:27 -0000 On May 14, 2009, at 23:32, Jerald.P.Martocci@jci.com wrote: > Full-function Devices and Reduced Function Devices We've had that distinction in the Internet for a while: Routers and Hosts. (I'm only 15 % joking.) Gruesse, Carsten From Chris.Dearlove@baesystems.com Fri May 15 02:08: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 6FA693A6D4D; Fri, 15 May 2009 02:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.396 X-Spam-Level: X-Spam-Status: No, score=-4.396 tagged_above=-999 required=5 tests=[AWL=-1.797, 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 0vgA41AguKLg; Fri, 15 May 2009 02:08:05 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 529F23A6945; Fri, 15 May 2009 02:08:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,198,1241391600"; d="scan'208";a="2437655" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 15 May 2009 10:09:38 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n4F99b63012027; Fri, 15 May 2009 10:09:37 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 May 2009 10:09:37 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 15 May 2009 10:09:36 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Few comments for our first discussion today Thread-Index: AcnUtxixBeROBqSYTXOpFuykq1TQYQAhPG3w References: <314C5D40-78D3-4F66-AD40-093588E2233F@cisco.com> From: "Dearlove, Christopher (UK)" To: "Philip Levis" X-OriginalArrivalTime: 15 May 2009 09:09:37.0710 (UTC) FILETIME=[DF40F4E0:01C9D53C] Cc: roll-bounces@ietf.org, ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] Few comments for our first discussion today 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, 15 May 2009 09:08:06 -0000 Philip Levis > Christopher Dearlove >> I would love to understand the DT's approach. Where is it explained, >> in particular with regard to how conflicting requirements are being >> reconciled? > > I think they're in this process now: let's not burden them with over- > documentation of every minutia and prevent them from getting work done. If they are putting together consolidated, and possibly prioritised, requirements as a recommendation to the WG, yes. Those will need some rationale where requirements are downgraded. But there's not much point in proceeding with protocol design until that. (Note that not proceeding with protocol design is not the same as not considering protocol realities.) ******************************************************************** 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 jabeille@cisco.com Fri May 15 03:42: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 AD47A3A70B9 for ; Fri, 15 May 2009 03:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.738 X-Spam-Level: X-Spam-Status: No, score=-9.738 tagged_above=-999 required=5 tests=[AWL=0.860, 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 NkALovle--3l for ; Fri, 15 May 2009 03:42:43 -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 81EE03A707F for ; Fri, 15 May 2009 03:42:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,199,1241395200"; d="scan'208,217";a="40672317" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 15 May 2009 10:44:15 +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 n4FAiFD0018294; Fri, 15 May 2009 12:44:15 +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 n4FAiFJM023930; Fri, 15 May 2009 10:44:15 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); Fri, 15 May 2009 12:44:15 +0200 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_01C9D54A.1705037E" Date: Fri, 15 May 2009 12:44:13 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A8603170312@xmb-ams-33d.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] 14kb 8-bit micro-controllers... Thread-Index: AcnU25FsBWN8zUVPRr+AP4uzS24I/AAaMhgQ References: <4A0C7DE4.2030307@gmail.com> From: "Julien Abeille (jabeille)" To: , "Alexandru Petrescu" X-OriginalArrivalTime: 15 May 2009 10:44:15.0123 (UTC) FILETIME=[17416E30:01C9D54A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14602; t=1242384255; x=1243248255; 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]=2014kb=208-bit=20micro-controlle rs... |Sender:=20; bh=HCfaVZznKODV1mh/RcQdh//WVEaKn8Fh+89GdVX82Vo=; b=ucpLkkQ8GA4kInta+u/WEFkvabnlsETuzzDVuTyT7BiypVXBfo5V3rBVNZ oWaRIyWOuDMXOj3cXgdhdIX2HfRCtDpAIeITUufE+EcTsQX5dMtFdQHmw/35 NojgXn6rSg; Authentication-Results: ams-dkim-2; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG Subject: Re: [Roll] 14kb 8-bit micro-controllers... 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, 15 May 2009 10:42:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9D54A.1705037E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 my input as implementer: =20 1 about RAM requirements There are protocols for which we know what they require (I give rough values as it is implementation, compiler, platform dependant): - IPv6 core protocols (as defined by the IPv6 ready logo program, more or less RFC4294 minus IPSec) can be implemented on less than 2K RAM. The important point is that protocol related data structures, namely a packet buffer, neighbor cache, prefix list, address list, routing table, require around 1.6K. The non protocol related code (pointers, integers for loops) can be made to use less than 150 bytes.=20 - UDP/TCP: there are implementation using roughly 100 bytes =20 The point about the cost of non protocol related code is important because it allows to estimate the RAM cost of other protocols.=20 - In 99% cases, I anticipate that the cost of non protocol related code will be of few 100 bytes maximum.=20 - Regarding protocol data structures, IPv6 is probably more demanding than most other, just because it needs 1.3K for the packet buffer. =20 If the requirement is 14K for RAM, because of the argument above , I am convinced you can fit a very large number of protocols in there.=20 =20 2 Code size Depends on protocol complexity. IPv6 core protocols (IPv6 ready version) uses roughly 10K. Note that IPv6 core protocols are not trivial (ND especially). A web server does not use more than 10K. =20 3 What we could do As said I am convinced most protocols will fit on a sensor, but we need to evaluate every one in details, because there will be some areas where modifications to usual protocols may be needed (routing is the first piece) in IETF Regarding security (AES was mentionned), encryption is usually done on sensors using hardware accelerators. AES-128, Triple DES are supported, but I cannot say for all. I am confident IPSec is light enough, key management may be more demanding. =20 Best, Julien =20 =20 =20 ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jerald.P.Martocci@jci.com Sent: jeudi 14 mai 2009 23:33 To: Alexandru Petrescu Cc: ROLL WG; roll-bounces@ietf.org Subject: Re: [Roll] 14kb 8-bit micro-controllers... Yep. Completely agree here.=20 We are in a new world where processing power is orders of magnitude less that the smallest devices typically considered in the IETF. The real 'kick in the pants' is that these requirements are not just marketing hype. These devices have been built and in production for decades in the wired world and years in the wireless world. =20 The IEEE folks realized this when they developed 802.15.4. They actually defined two different classes of devices (i.e. Full-function Devices and Reduced Function Devices) which allowed for different specifications for each class. We may have to follow suit to be sure the different gradations of devices can play well in the architecture yet still meet their cost/functionality requirements.=20 Jerry=20 Alexandru Petrescu =20 Sent by: roll-bounces@ietf.org=20 05/14/2009 03:24 PM=20 To ROLL WG =20 cc Subject [Roll] 14kb 8-bit micro-controllers... =09 At several points the sringent node characteristics were expressed such as: -14kb of RAM -8-bit controller -no floating point -etc. This should be clarified. There are node requirements which can be so strict they couldn't even=20 memorize a Neighbor Cache of IPv6 addresses, let alone a TCPv6=20 implementation. Querying a temperature value on 6 bits with an IPv6 message of mandatory 40bytes of base header... Or the program of the wireless link layer, which was never questioned=20 whether it fits or not the stringent node requirements of 14kb. Or the program doing AES key security. Would all these assumed programs fit in a 14kb of RAM of an 8-bit=20 controller? There should be a reality check here... Alex _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------_=_NextPart_001_01C9D54A.1705037E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi all,
 
my input as=20 implementer:
 
1 about RAM = requirements
There are protocols for which we know what they = require (I=20 give rough values as it is implementation, compiler, platform=20 dependant):
- IPv6 core protocols (as defined by the IPv6 = ready logo=20 program, more or less RFC4294 minus IPSec) can be implemented on=20 less than 2K RAM.
The important point is that protocol related = data=20 structures, namely a packet buffer, neighbor cache, prefix list, address = list,=20 routing table, require around 1.6K. The non protocol related code=20 (pointers, integers for loops) can be made to use less = than 150 bytes.=20
- UDP/TCP: there are implementation using = roughly 100=20 bytes
 
The point about the cost of non protocol = related code is=20 important because it allows to estimate the RAM cost of other=20 protocols. 
- In 99% cases, I anticipate that the = cost of non=20 protocol related code will be of few 100 bytes maximum. =
- Regarding protocol data structures, IPv6 is = probably more=20 demanding than most other, just because it needs 1.3K for the packet=20 buffer.
 
If the requirement is 14K for RAM, because = of the=20 argument above , I am convinced you can fit a very large number of = protocols in=20 there.
 
2 Code size
Depends on protocol complexity. IPv6 core = protocols (IPv6=20 ready version) uses roughly 10K. Note that IPv6 core protocols are not = trivial=20 (ND especially). A web server does not use more than = 10K.
 
3 What we could do
As said I am convinced most protocols will fit = on a sensor,=20 but we need to evaluate every one in details, because there will be = some=20 areas where modifications to usual protocols may be needed (routing = is the=20 first piece) in IETF
Regarding security (AES was mentionned), = encryption is=20 usually done on sensors using hardware accelerators. AES-128, Triple DES = are=20 supported, but I cannot say for all. I am confident IPSec is light = enough, key=20 management may be more demanding.
 
Best,
Julien  
 
 
From: roll-bounces@ietf.org = [mailto:roll-bounces@ietf.org] On=20 Behalf Of Jerald.P.Martocci@jci.com
Sent: jeudi 14 mai = 2009=20 23:33
To: Alexandru Petrescu
Cc: ROLL WG;=20 roll-bounces@ietf.org
Subject: Re: [Roll] 14kb 8-bit=20 micro-controllers...



Yep. =  Completely agree=20 here.

We are in a new = world where=20 processing power is orders of magnitude less that the smallest devices = typically=20 considered in the IETF.  The real 'kick in the pants' is that these = requirements are not just marketing hype.  These devices have been = built=20 and in production for decades in the wired world and years in the = wireless=20 world.  

The IEEE = folks=20 realized this when they developed 802.15.4.  They actually defined = two=20 different classes of devices (i.e. Full-function Devices and Reduced = Function=20 Devices) which allowed for different specifications for each class. =   We=20 may have to follow suit to be sure the different gradations of devices = can play=20 well in the architecture yet still meet their cost/functionality=20 requirements.

Jerry=20



Alexandru = Petrescu=20 <alexandru.petrescu@gmail.com>
Sent by: roll-bounces@ietf.org=20

05/14/2009 03:24 PM =

To
ROLL WG=20 <roll@ietf.org>=20
cc
Subject
[Roll] 14kb 8-bit=20 micro-controllers...

=




At several points the sringent node characteristics were = expressed=20 such as:

-14kb of RAM
-8-bit controller
-no floating=20 point
-etc.

This should be clarified.

There are node=20 requirements which can be so strict they couldn't even
memorize a = Neighbor=20 Cache of IPv6 addresses, let alone a TCPv6 =
implementation.

Querying a=20 temperature value on 6 bits with an IPv6 message of mandatory =
40bytes of=20 base header...

Or the program of the wireless link layer, which = was never=20 questioned
whether it fits or not the stringent node requirements of = 14kb.

Or the program doing AES key security.

Would all = these=20 assumed programs fit in a 14kb of RAM of an 8-bit =
controller?

There=20 should be a reality check=20 here...

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

------_=_NextPart_001_01C9D54A.1705037E-- From L.Wood@surrey.ac.uk Fri May 15 06:10: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 576793A6C0D; Fri, 15 May 2009 06:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.071 X-Spam-Level: X-Spam-Status: No, score=-6.071 tagged_above=-999 required=5 tests=[AWL=0.527, 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 tCZnf1UOokao; Fri, 15 May 2009 06:10:27 -0700 (PDT) Received: from mail72.messagelabs.com (mail72.messagelabs.com [193.109.255.147]) by core3.amsl.com (Postfix) with SMTP id 16CC23A6D6D; Fri, 15 May 2009 06:10:26 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-10.tower-72.messagelabs.com!1242393118!53615245!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 27272 invoked from network); 15 May 2009 13:11:59 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-10.tower-72.messagelabs.com with SMTP; 15 May 2009 13:11:59 -0000 Received: from EVS-EC1-NODE4.surrey.ac.uk ([131.227.102.145]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 May 2009 14:11:58 +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_01C9D55E.B9DDA93A" Date: Fri, 15 May 2009 14:10:58 +0100 Message-ID: <4835AFD53A246A40A3B8DA85D658C4BE7B100D@EVS-EC1-NODE4.surrey.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] 14kb 8-bit micro-controllers... Thread-Index: AcnVN/uY1MuaVnesQSW7PIRmTY7GOgAJpr4u References: <72FD9706-4821-4F67-B283-6101996593E2@tzi.org> From: To: , X-OriginalArrivalTime: 15 May 2009 13:11:58.0572 (UTC) FILETIME=[BA486AC0:01C9D55E] Cc: roll-bounces@ietf.org, roll@ietf.org Subject: Re: [Roll] 14kb 8-bit micro-controllers... 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, 15 May 2009 13:10:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9D55E.B9DDA93A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: roll-bounces@ietf.org on behalf of Carsten Bormann > On May 14, 2009, at 23:32, Jerald.P.Martocci@jci.com wrote: > > Full-function Devices and Reduced Function Devices > > We've had that distinction in the Internet for a while: >=20 > Routers and Hosts. Which is which? L. > (I'm only 15 % joking.) >=20 > Gruesse, Carsten ------_=_NextPart_001_01C9D55E.B9DDA93A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Roll] 14kb 8-bit micro-controllers...

From: roll-bounces@ietf.org on behalf of Carsten = Bormann
> On May 14, 2009, at 23:32, Jerald.P.Martocci@jci.com wrote:

> > Full-function Devices and Reduced Function Devices
>
> We've had that distinction in the Internet for a while:
>
> Routers and Hosts.

Which is which?

L.

> (I'm only 15 % joking.)
>
> Gruesse, Carsten

------_=_NextPart_001_01C9D55E.B9DDA93A-- From jabeille@cisco.com Mon May 18 02:13: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 0CDCF28C105; Mon, 18 May 2009 02:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.882 X-Spam-Level: X-Spam-Status: No, score=-9.882 tagged_above=-999 required=5 tests=[AWL=0.716, 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 uH4TtYmAYKEU; Mon, 18 May 2009 02:13:28 -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 7B0323A6C8A; Mon, 18 May 2009 02:13:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,208,1241395200"; d="scan'208,217";a="40802062" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 18 May 2009 09:15:02 +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 n4I9F2oE020895; Mon, 18 May 2009 11:15:02 +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 n4I9F2pF025341; Mon, 18 May 2009 09:15:02 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, 18 May 2009 11:15:02 +0200 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_01C9D799.1F927154" Date: Mon, 18 May 2009 11:14:56 +0200 Message-ID: <38F26F36EAA981478A49D1F37F474A86031708DA@xmb-ams-33d.emea.cisco.com> In-Reply-To: <4835AFD53A246A40A3B8DA85D658C4BE7B100D@EVS-EC1-NODE4.surrey.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] 14kb 8-bit micro-controllers... Thread-Index: AcnVN/uY1MuaVnesQSW7PIRmTY7GOgAJpr4uAI6Af1A= References: <72FD9706-4821-4F67-B283-6101996593E2@tzi.org> <4835AFD53A246A40A3B8DA85D658C4BE7B100D@EVS-EC1-NODE4.surrey.ac.uk> From: "Julien Abeille (jabeille)" To: , , X-OriginalArrivalTime: 18 May 2009 09:15:02.0195 (UTC) FILETIME=[1FE6B030:01C9D799] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4070; t=1242638102; x=1243502102; c=relaxed/simple; s=amsdkim1002; 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]=2014kb=208-bit=20micro-controlle rs... |Sender:=20; bh=BjMJ0qfpf/N0u12gksTfnKHPSNxjPhX2wvWT299dJ1A=; b=btZqJrGg6PRdPKmDR1VNIpdEx8Hl1X9jVGsuHn5SukUG6RvF6TbP/Gitsf oeM2lu1cwYaVFhvmP/HjdHZSEmO2zeljkbpbIGL9TQ9SYmU54CBwnBwzRfkV Upnh4kwzWs; Authentication-Results: ams-dkim-1; header.From=jabeille@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll-bounces@ietf.org, roll@ietf.org Subject: Re: [Roll] 14kb 8-bit micro-controllers... 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, 18 May 2009 09:13:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9D799.1F927154 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi L., =20 from RFC4294 for example (the same definition is present in many other RFCs):=20 - a router is "a node that forwards IPv6 packets not explicitly addressed to itself".=20 - a host is "any node that is not a router" =20 Best, Julien ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of L.Wood@surrey.ac.uk Sent: vendredi 15 mai 2009 15:11 To: cabo@tzi.org; Jerald.P.Martocci@jci.com Cc: roll-bounces@ietf.org; roll@ietf.org Subject: Re: [Roll] 14kb 8-bit micro-controllers... From: roll-bounces@ietf.org on behalf of Carsten Bormann > On May 14, 2009, at 23:32, Jerald.P.Martocci@jci.com wrote: > > Full-function Devices and Reduced Function Devices > > We've had that distinction in the Internet for a while: > > Routers and Hosts. Which is which? L. > (I'm only 15 % joking.) > > Gruesse, Carsten ------_=_NextPart_001_01C9D799.1F927154 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Roll] 14kb 8-bit micro-controllers...
Hi L.,
 
from RFC4294 for example (the same definition = is=20 present in many other RFCs):
- a router is "a node that forwards = IPv6 packets=20 not explicitly addressed to itself".=20
- a host is "any node that is not a=20 router"
 
Best,
Julien

From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of=20 L.Wood@surrey.ac.uk
Sent: vendredi 15 mai 2009 = 15:11
To:=20 cabo@tzi.org; Jerald.P.Martocci@jci.com
Cc: = roll-bounces@ietf.org;=20 roll@ietf.org
Subject: Re: [Roll] 14kb 8-bit=20 micro-controllers...


From: roll-bounces@ietf.org on behalf of Carsten = Bormann
>=20 On May 14, 2009, at 23:32, Jerald.P.Martocci@jci.com wrote:

> = >=20 Full-function Devices and Reduced Function Devices
>
> We've = had=20 that distinction in the Internet for a while:
>
> Routers = and=20 Hosts.

Which is which?

L.

> (I'm only 15 %=20 joking.)
>
> Gruesse, = Carsten

------_=_NextPart_001_01C9D799.1F927154-- From alexandru.petrescu@gmail.com Mon May 18 03:01: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 BE97328B797; Mon, 18 May 2009 03:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.109, 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 CfzJxOW3epYI; Mon, 18 May 2009 03:01:34 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 26E873A6CE5; Mon, 18 May 2009 03:01:31 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n4IA33Ek013880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 May 2009 12:03:03 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n4IA32tm030150; Mon, 18 May 2009 12:03:02 +0200 (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 n4IA31jY004358; Mon, 18 May 2009 12:03:02 +0200 Message-ID: <4A113255.9030305@gmail.com> Date: Mon, 18 May 2009 12:03:01 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Julien Abeille (jabeille)" References: <72FD9706-4821-4F67-B283-6101996593E2@tzi.org> <4835AFD53A246A40A3B8DA85D658C4BE7B100D@EVS-EC1-NODE4.surrey.ac.uk> <38F26F36EAA981478A49D1F37F474A86031708DA@xmb-ams-33d.emea.cisco.com> In-Reply-To: <38F26F36EAA981478A49D1F37F474A86031708DA@xmb-ams-33d.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org, roll-bounces@ietf.org Subject: Re: [Roll] 14kb 8-bit micro-controllers... 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, 18 May 2009 10:01:34 -0000 Julien Abeille (jabeille) a écrit : > Hi L., > > from RFC4294 for example (the same definition is present in many > other RFCs): - a router is "a node that forwards IPv6 packets not > explicitly addressed to itself". - a host is "any node that is not a > router" Host and Router - both run TCP/IP stacks. Further back in time is RFC 7 Host-IMP Interface (Interface Message Processor). Only the Host would run a TCP/IP stack, I suppose. This would make for: Full-function device: the RFC7 "Host", runs TCP/IP; Reduced-function device: the RFC7 "IMP", runs the link layer. I am not sure what Carsten and Lloyd meant. Alex > > Best, Julien > > ------------------------------------------------------------------------ > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On > Behalf Of *L.Wood@surrey.ac.uk *Sent:* vendredi 15 mai 2009 15:11 > *To:* cabo@tzi.org; Jerald.P.Martocci@jci.com *Cc:* > roll-bounces@ietf.org; roll@ietf.org *Subject:* Re: [Roll] 14kb 8-bit > micro-controllers... > > > From: roll-bounces@ietf.org on behalf of Carsten Bormann >> On May 14, 2009, at 23:32, Jerald.P.Martocci@jci.com wrote: > >>> Full-function Devices and Reduced Function Devices >> >> We've had that distinction in the Internet for a while: >> >> Routers and Hosts. > > Which is which? > > L. > >> (I'm only 15 % joking.) >> >> Gruesse, Carsten > > > ------------------------------------------------------------------------ > > > > > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From cabo@tzi.org Mon May 18 03:09: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 400C33A6FF6; Mon, 18 May 2009 03:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 PMoDyaOG0u+r; Mon, 18 May 2009 03:09:49 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 11D2D3A67EC; Mon, 18 May 2009 03:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n4IAAmt8019137; Mon, 18 May 2009 12:10:48 +0200 (CEST) Received: from [192.168.217.107] (p5489E1F8.dip.t-dialin.net [84.137.225.248]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 58A871704D6; Mon, 18 May 2009 12:10:48 +0200 (CEST) From: Carsten Bormann To: "Julien Abeille (jabeille)" In-Reply-To: <38F26F36EAA981478A49D1F37F474A86031708DA@xmb-ams-33d.emea.cisco.com> References: <72FD9706-4821-4F67-B283-6101996593E2@tzi.org> <4835AFD53A246A40A3B8DA85D658C4BE7B100D@EVS-EC1-NODE4.surrey.ac.uk> <38F26F36EAA981478A49D1F37F474A86031708DA@xmb-ams-33d.emea.cisco.com> Message-Id: <7935168F-EEBF-40ED-B80E-6CE4EB82F23B@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 18 May 2009 12:10:47 +0200 X-Mailer: Apple Mail (2.935.3) Cc: roll-bounces@ietf.org, roll@ietf.org Subject: Re: [Roll] 14kb 8-bit micro-controllers... 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, 18 May 2009 10:09:50 -0000 On May 18, 2009, at 11:14, Julien Abeille (jabeille) wrote: > - a router is "a node that forwards IPv6 packets not explicitly > addressed to itself". > - a host is "any node that is not a router" Julien, I'm pretty sure Lloyd knows that :-) He might have been alluding to the fact the hosts may have pretty significant functions on their own. In the original 802.15.4 context, however, it is pretty clear that the FFDs were meant to be the routers, and that RFDs play the equivalent of a host-only node (think battery-operated sensor). In the context of ROLL, participating in a routing protocol may be something that relates to 802.15.4's FFD concept, and there may be RFDs just smart enough to talk to the next router. (Of course, even in an "all nodes are routers" scenario, there may be a class of less functional devices, which may map to specific roles in the routing protocol; that was the 15 % I referred to.) Gruesse, Carsten From cabo@tzi.org Mon May 18 03:10:41 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 EF7EA3A6AF3; Mon, 18 May 2009 03:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 fZpdYOhbO-DO; Mon, 18 May 2009 03:10:41 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id AD14B3A6FFF; Mon, 18 May 2009 03:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n4IAC4YM020041; Mon, 18 May 2009 12:12:04 +0200 (CEST) Received: from [192.168.217.107] (p5489E1F8.dip.t-dialin.net [84.137.225.248]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 864921704D6; Mon, 18 May 2009 12:12:03 +0200 (CEST) From: Carsten Bormann To: Alexandru Petrescu In-Reply-To: <4A113255.9030305@gmail.com> References: <72FD9706-4821-4F67-B283-6101996593E2@tzi.org> <4835AFD53A246A40A3B8DA85D658C4BE7B100D@EVS-EC1-NODE4.surrey.ac.uk> <38F26F36EAA981478A49D1F37F474A86031708DA@xmb-ams-33d.emea.cisco.com> <4A113255.9030305@gmail.com> Message-Id: <484F850C-5086-4C56-B400-9B651A65D8D4@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 18 May 2009 12:12:02 +0200 X-Mailer: Apple Mail (2.935.3) Cc: roll-bounces@ietf.org, roll@ietf.org Subject: Re: [Roll] 14kb 8-bit micro-controllers... 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, 18 May 2009 10:10:42 -0000 On May 18, 2009, at 12:03, Alexandru Petrescu wrote: > Reduced-function device: the RFC7 "IMP", runs the link layer. No, that's not it. See my previous message. Gruesse, Carsten From L.Wood@surrey.ac.uk Mon May 18 05:32: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 8191A3A701C; Mon, 18 May 2009 05:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.177 X-Spam-Level: X-Spam-Status: No, score=-6.177 tagged_above=-999 required=5 tests=[AWL=0.421, 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 Co1BDFuSwdU3; Mon, 18 May 2009 05:32:54 -0700 (PDT) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with SMTP id 3524F3A7018; Mon, 18 May 2009 05:32:53 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-9.tower-82.messagelabs.com!1242650026!63561271!10 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 21598 invoked from network); 18 May 2009 12:34:09 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-9.tower-82.messagelabs.com with SMTP; 18 May 2009 12:34:09 -0000 Received: from EVS-EC1-NODE4.surrey.ac.uk ([131.227.102.145]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 May 2009 13:34:04 +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_01C9D7B4.ED66258E" Date: Mon, 18 May 2009 13:31:56 +0100 Message-ID: <4835AFD53A246A40A3B8DA85D658C4BE7B102B@EVS-EC1-NODE4.surrey.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] 14kb 8-bit micro-controllers... Thread-Index: AcnVN/uY1MuaVnesQSW7PIRmTY7GOgAJpr4uAI6Af1AABwJbog== References: <72FD9706-4821-4F67-B283-6101996593E2@tzi.org> <4835AFD53A246A40A3B8DA85D658C4BE7B100D@EVS-EC1-NODE4.surrey.ac.uk> <38F26F36EAA981478A49D1F37F474A86031708DA@xmb-ams-33d.emea.cisco.com> From: To: , , X-OriginalArrivalTime: 18 May 2009 12:34:04.0119 (UTC) FILETIME=[EDD7AE70:01C9D7B4] Cc: roll-bounces@ietf.org, roll@ietf.org Subject: Re: [Roll] 14kb 8-bit micro-controllers... 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, 18 May 2009 12:32:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9D7B4.ED66258E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My brief question was: Which of (router or host) is the full-function device? Which of (router or host) is the reduced-functionality device? hope that's clear. By the RFC4294 definition, any multihomed host has the potential to be a router. L. -----Original Message----- From: Julien Abeille (jabeille) [mailto:jabeille@cisco.com] Sent: Mon 2009-05-18 10:14 To: Wood L Dr (Electronic Eng); cabo@tzi.org; Jerald.P.Martocci@jci.com Cc: roll-bounces@ietf.org; roll@ietf.org Subject: RE: [Roll] 14kb 8-bit micro-controllers... =20 Hi L., =20 from RFC4294 for example (the same definition is present in many other RFCs):=20 - a router is "a node that forwards IPv6 packets not explicitly addressed to itself".=20 - a host is "any node that is not a router" =20 Best, Julien ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of L.Wood@surrey.ac.uk Sent: vendredi 15 mai 2009 15:11 To: cabo@tzi.org; Jerald.P.Martocci@jci.com Cc: roll-bounces@ietf.org; roll@ietf.org Subject: Re: [Roll] 14kb 8-bit micro-controllers... From: roll-bounces@ietf.org on behalf of Carsten Bormann > On May 14, 2009, at 23:32, Jerald.P.Martocci@jci.com wrote: > > Full-function Devices and Reduced Function Devices > > We've had that distinction in the Internet for a while: > > Routers and Hosts. Which is which? L. > (I'm only 15 % joking.) > > Gruesse, Carsten ------_=_NextPart_001_01C9D7B4.ED66258E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Roll] 14kb 8-bit micro-controllers...

My brief question was:

Which of (router or host) is the full-function device?
Which of (router or host) is the reduced-functionality device?

hope that's clear. By the RFC4294 definition, any multihomed host
has the potential to be a router.

L.

<http://www.ee.surrey= .ac.uk/Personal/L.Wood/><L.Wood@surrey.ac.uk>



-----Original Message-----
From: Julien Abeille (jabeille) [mailto:jabeille@cisco.com]
Sent: Mon 2009-05-18 10:14
To: Wood L Dr (Electronic Eng); cabo@tzi.org; = Jerald.P.Martocci@jci.com
Cc: roll-bounces@ietf.org; roll@ietf.org
Subject: RE: [Roll] 14kb 8-bit micro-controllers...

Hi L.,

from RFC4294 for example (the same definition is present in many = other
RFCs):
- a router is "a node that forwards IPv6 packets not explicitly
addressed to itself".
- a host is "any node that is not a router"

Best,
Julien

________________________________

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] = On Behalf Of
L.Wood@surrey.ac.uk
Sent: vendredi 15 mai 2009 15:11
To: cabo@tzi.org; Jerald.P.Martocci@jci.com
Cc: roll-bounces@ietf.org; roll@ietf.org
Subject: Re: [Roll] 14kb 8-bit micro-controllers...




From: roll-bounces@ietf.org on behalf of Carsten Bormann
> On May 14, 2009, at 23:32, Jerald.P.Martocci@jci.com wrote:

> > Full-function Devices and Reduced Function Devices
>
> We've had that distinction in the Internet for a while:
>
> Routers and Hosts.

Which is which?

L.

> (I'm only 15 % joking.)
>
> Gruesse, Carsten

------_=_NextPart_001_01C9D7B4.ED66258E-- From Peter.Burnett@philips.com Mon May 18 05:46: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 509E53A6358; Mon, 18 May 2009 05:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.408, 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 ieZH4dG8yton; Mon, 18 May 2009 05:46:55 -0700 (PDT) Received: from smtpx.philips.com (smtpx.philips.com [168.87.56.20]) by core3.amsl.com (Postfix) with ESMTP id 9AFD028C240; Mon, 18 May 2009 05:46:54 -0700 (PDT) Received: from NLHILEXH03.connect1.local (172.16.153.78) by connect1.philips.com (172.16.156.41) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 18 May 2009 14:48:32 +0200 Received: from NLCLUEXM06.connect1.local ([172.16.153.55]) by NLHILEXH03.connect1.local ([172.16.153.78]) with mapi; Mon, 18 May 2009 14:48:26 +0200 From: "Burnett, Peter" To: "L.Wood@surrey.ac.uk" , "jabeille@cisco.com" , "cabo@tzi.org" , "Jerald.P.Martocci@jci.com" Date: Mon, 18 May 2009 14:46:45 +0200 Thread-Topic: [Roll] 14kb 8-bit micro-controllers... Thread-Index: AcnVN/uY1MuaVnesQSW7PIRmTY7GOgAJpr4uAI6Af1AABwJbogAAhGiG Message-ID: <8E9C227490A7614B87D90C0AE18CF22CADF2602E87@NLCLUEXM06.connect1.local> References: <72FD9706-4821-4F67-B283-6101996593E2@tzi.org><4835AFD53A246A40A3B8DA85D 658C4BE7B100D@EVS-EC1-NODE4.surrey.ac.uk><38F26F36EAA981478A49D1F37F474A86031708DA@xmb-ams-33d.emea.cisco.com>, <4835AFD53A246A40A3B8DA85D658C4BE7B102B@EVS-EC1-NODE4.surrey.ac.uk> In-Reply-To: <4835AFD53A246A40A3B8DA85D658C4BE7B102B@EVS-EC1-NODE4.surrey.ac.uk> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8E9C227490A7614B87D90C0AE18CF22CADF2602E87NLCLUEXM06con_" MIME-Version: 1.0 Cc: "roll-bounces@ietf.org" , "roll@ietf.org" Subject: Re: [Roll] 14kb 8-bit micro-controllers... 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, 18 May 2009 12:46:56 -0000 --_000_8E9C227490A7614B87D90C0AE18CF22CADF2602E87NLCLUEXM06con_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In 15.4 an RFD only talks via its (FFD) parent so it is not multihomed. So = cannot be a router. But presumably an FFD can be a router or a host. Peter ________________________________ From: roll-bounces@ietf.org [roll-bounces@ietf.org] On Behalf Of L.Wood@sur= rey.ac.uk [L.Wood@surrey.ac.uk] Sent: 18 May 2009 13:31 To: jabeille@cisco.com; cabo@tzi.org; Jerald.P.Martocci@jci.com Cc: roll-bounces@ietf.org; roll@ietf.org Subject: Re: [Roll] 14kb 8-bit micro-controllers... My brief question was: Which of (router or host) is the full-function device? Which of (router or host) is the reduced-functionality device? hope that's clear. By the RFC4294 definition, any multihomed host has the potential to be a router. L. -----Original Message----- From: Julien Abeille (jabeille) [mailto:jabeille@cisco.com] Sent: Mon 2009-05-18 10:14 To: Wood L Dr (Electronic Eng); cabo@tzi.org; Jerald.P.Martocci@jci.com Cc: roll-bounces@ietf.org; roll@ietf.org Subject: RE: [Roll] 14kb 8-bit micro-controllers... Hi L., from RFC4294 for example (the same definition is present in many other RFCs): - a router is "a node that forwards IPv6 packets not explicitly addressed to itself". - a host is "any node that is not a router" Best, Julien ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of L.Wood@surrey.ac.uk Sent: vendredi 15 mai 2009 15:11 To: cabo@tzi.org; Jerald.P.Martocci@jci.com Cc: roll-bounces@ietf.org; roll@ietf.org Subject: Re: [Roll] 14kb 8-bit micro-controllers... From: roll-bounces@ietf.org on behalf of Carsten Bormann > On May 14, 2009, at 23:32, Jerald.P.Martocci@jci.com wrote: > > Full-function Devices and Reduced Function Devices > > We've had that distinction in the Internet for a while: > > Routers and Hosts. Which is which? L. > (I'm only 15 % joking.) > > Gruesse, Carsten ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_8E9C227490A7614B87D90C0AE18CF22CADF2602E87NLCLUEXM06con_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In 15.4= an RFD only talks via its (FFD) parent so it is not multihomed. So cannot = be a router. But presumably an FFD can be a router or a host.
Peter
From: roll-bounces@ietf.org [roll-b= ounces@ietf.org] On Behalf Of L.Wood@surrey.ac.uk [L.Wood@surrey.ac.uk]
Sent: 18 May 2009 13:31
To: jabeille@cisco.com; cabo@tzi.org; Jerald.P.Martocci@jci.com
Cc: roll-bounces@ietf.org; roll@ietf.org
Subject: Re: [Roll] 14kb 8-bit micro-controllers...


My brief question was:

Which of (router or host) is the full-function device?
Which of (router or host) is the reduced-functionality device?

hope that's clear. By the RFC4294 definition, any multihomed host
has the potential to be a router.

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood@surrey.ac.= uk>



-----Original Message-----
From: Julien Abeille (jabeille) [mail= to:jabeille@cisco.com]
Sent: Mon 2009-05-18 10:14
To: Wood L Dr (Electronic Eng); cabo@tzi.org; Jerald.P.Martocci@jci.com
Cc: roll-bounces@ietf.org; roll@ietf.org
Subject: RE: [Roll] 14kb 8-bit micro-controllers...

Hi L.,

from RFC4294 for example (the same definition is present in many other
RFCs):
- a router is "a node that forwards IPv6 packets not explicitly
addressed to itself".
- a host is "any node that is not a router"

Best,
Julien

________________________________

From: roll-bounces@ietf.org [mailt= o:roll-bounces@ietf.org] On Behalf Of
L.Wood@surrey.ac.uk
Sent: vendredi 15 mai 2009 15:11
To: cabo@tzi.org; Jerald.P.Martocci@jci.com
Cc: roll-bounces@ietf.org; roll@ietf.org
Subject: Re: [Roll] 14kb 8-bit micro-controllers...




From: roll-bounces@ietf.org on behalf of Carsten Bormann
> On May 14, 2009, at 23:32, Jerald.P.Martocci@jci.com wrote:

> > Full-function Devices and Reduced Function Devices
>
> We've had that distinction in the Internet for a while:
>
> Routers and Hosts.

Which is which?

L.

> (I'm only 15 % joking.)
>
> Gruesse, Carsten





The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_8E9C227490A7614B87D90C0AE18CF22CADF2602E87NLCLUEXM06con_-- From alexandru.petrescu@gmail.com Mon May 18 05:53: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 B16EC28C28D; Mon, 18 May 2009 05:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.109, 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 zqon6xMsmQJI; Mon, 18 May 2009 05:53:53 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 090EF3A6D9F; Mon, 18 May 2009 05:53:51 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n4ICtNFH031589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 May 2009 14:55:23 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n4ICtNBD003605; Mon, 18 May 2009 14:55:23 +0200 (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 n4ICtM01005943; Mon, 18 May 2009 14:55:23 +0200 Message-ID: <4A115ABA.608@gmail.com> Date: Mon, 18 May 2009 14:55:22 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Burnett, Peter" References: <72FD9706-4821-4F67-B283-6101996593E2@tzi.org><4835AFD53A246A40A3B8DA85D 658C4BE7B100D@EVS-EC1-NODE4.surrey.ac.uk><38F26F36EAA981478A49D1F37F474A86031708DA@xmb-ams-33d.emea.cisco.com>, <4835AFD53A246A40A3B8DA85D658C4BE7B102B@EVS-EC1-NODE4.surrey.ac.uk> <8E9C227490A7614B87D90C0AE18CF22CADF2602E87@NLCLUEXM06.connect1.local> In-Reply-To: <8E9C227490A7614B87D90C0AE18CF22CADF2602E87@NLCLUEXM06.connect1.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "roll@ietf.org" , "roll-bounces@ietf.org" Subject: Re: [Roll] 14kb 8-bit micro-controllers... 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, 18 May 2009 12:53:54 -0000 Could FFD have 2 interfaces? Or is it typically having a single interface? Alex Burnett, Peter a écrit : > In 15.4 an RFD only talks via its (FFD) parent so it is not multihomed. > So cannot be a router. But presumably an FFD can be a router or a host. > Peter > ------------------------------------------------------------------------ > *From:* roll-bounces@ietf.org [roll-bounces@ietf.org] On Behalf Of > L.Wood@surrey.ac.uk [L.Wood@surrey.ac.uk] > *Sent:* 18 May 2009 13:31 > *To:* jabeille@cisco.com; cabo@tzi.org; Jerald.P.Martocci@jci.com > *Cc:* roll-bounces@ietf.org; roll@ietf.org > *Subject:* Re: [Roll] 14kb 8-bit micro-controllers... > > > My brief question was: > > Which of (router or host) is the full-function device? > Which of (router or host) is the reduced-functionality device? > > hope that's clear. By the RFC4294 definition, any multihomed host > has the potential to be a router. > > L. > > > > > > -----Original Message----- > From: Julien Abeille (jabeille) [mailto:jabeille@cisco.com] > Sent: Mon 2009-05-18 10:14 > To: Wood L Dr (Electronic Eng); cabo@tzi.org; Jerald.P.Martocci@jci.com > Cc: roll-bounces@ietf.org; roll@ietf.org > Subject: RE: [Roll] 14kb 8-bit micro-controllers... > > Hi L., > > from RFC4294 for example (the same definition is present in many other > RFCs): > - a router is "a node that forwards IPv6 packets not explicitly > addressed to itself". > - a host is "any node that is not a router" > > Best, > Julien > > ________________________________ > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > L.Wood@surrey.ac.uk > Sent: vendredi 15 mai 2009 15:11 > To: cabo@tzi.org; Jerald.P.Martocci@jci.com > Cc: roll-bounces@ietf.org; roll@ietf.org > Subject: Re: [Roll] 14kb 8-bit micro-controllers... > > > > > From: roll-bounces@ietf.org on behalf of Carsten Bormann > > On May 14, 2009, at 23:32, Jerald.P.Martocci@jci.com wrote: > > > > Full-function Devices and Reduced Function Devices > > > > We've had that distinction in the Internet for a while: > > > > Routers and Hosts. > > Which is which? > > L. > > > (I'm only 15 % joking.) > > > > Gruesse, Carsten > > > > > > ------------------------------------------------------------------------ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or reproduction > of this message is strictly prohibited and may be unlawful. If you are > not the intended recipient, please contact the sender by return e-mail > and destroy all copies of the original message. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Peter.Burnett@philips.com Mon May 18 06:02: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 24E353A6B4A; Mon, 18 May 2009 06:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.258 X-Spam-Level: X-Spam-Status: No, score=-6.258 tagged_above=-999 required=5 tests=[AWL=0.341, 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 5G6kO77NzzsO; Mon, 18 May 2009 06:02:50 -0700 (PDT) Received: from smtpx.philips.com (smtpx.philips.com [168.87.56.20]) by core3.amsl.com (Postfix) with ESMTP id 2B8313A6BB6; Mon, 18 May 2009 06:02:50 -0700 (PDT) Received: from NLAMSEXH04.connect1.local (172.16.153.25) by connect1.philips.com (172.16.156.40) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 18 May 2009 15:04:07 +0200 Received: from NLCLUEXM06.connect1.local ([172.16.153.55]) by NLAMSEXH04.connect1.local ([172.16.153.25]) with mapi; Mon, 18 May 2009 15:04:08 +0200 From: "Burnett, Peter" To: Alexandru Petrescu Date: Mon, 18 May 2009 15:02:20 +0200 Thread-Topic: [Roll] 14kb 8-bit micro-controllers... Thread-Index: AcnXt/DEcCeQ6UPqQnGXXXgpOeP+CwAAPAGX Message-ID: <8E9C227490A7614B87D90C0AE18CF22CADF2602E88@NLCLUEXM06.connect1.local> References: <72FD9706-4821-4F67-B283-6101996593E2@tzi.org><4835AFD53A246A40A3B8DA85 D 658C4BE7B100D@EVS-EC1-NODE4.surrey.ac.uk><38F26F36EAA981478A49D1F37F474A8 6031708DA@xmb-ams-33d.emea.cisco.com>, <4835AFD53A246A40A3B8DA85D658C4BE7B10 2B@EVS-EC1-NODE4.surrey.ac.uk><8E9C227490A7614B87D90C0AE18CF22CADF2602E87@NLCLUEXM06.connect1.local>, <4A115ABA.608@gmail.com> In-Reply-To: <4A115ABA.608@gmail.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "roll@ietf.org" , "roll-bounces@ietf.org" Subject: Re: [Roll] 14kb 8-bit micro-controllers... 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, 18 May 2009 13:02:58 -0000 Typically only one interface but that doesnt stop it being a router because= links are non-transitive on WPANs. Back to that.... Peter ________________________________________ From: roll-bounces@ietf.org [roll-bounces@ietf.org] On Behalf Of Alexandru = Petrescu [alexandru.petrescu@gmail.com] Sent: 18 May 2009 13:55 To: Burnett, Peter Cc: roll@ietf.org; roll-bounces@ietf.org Subject: Re: [Roll] 14kb 8-bit micro-controllers... Could FFD have 2 interfaces? Or is it typically having a single interface? Alex Burnett, Peter a =E9crit : > In 15.4 an RFD only talks via its (FFD) parent so it is not multihomed. > So cannot be a router. But presumably an FFD can be a router or a host. > Peter > ------------------------------------------------------------------------ > *From:* roll-bounces@ietf.org [roll-bounces@ietf.org] On Behalf Of > L.Wood@surrey.ac.uk [L.Wood@surrey.ac.uk] > *Sent:* 18 May 2009 13:31 > *To:* jabeille@cisco.com; cabo@tzi.org; Jerald.P.Martocci@jci.com > *Cc:* roll-bounces@ietf.org; roll@ietf.org > *Subject:* Re: [Roll] 14kb 8-bit micro-controllers... > > > My brief question was: > > Which of (router or host) is the full-function device? > Which of (router or host) is the reduced-functionality device? > > hope that's clear. By the RFC4294 definition, any multihomed host > has the potential to be a router. > > L. > > > > > > -----Original Message----- > From: Julien Abeille (jabeille) [mailto:jabeille@cisco.com] > Sent: Mon 2009-05-18 10:14 > To: Wood L Dr (Electronic Eng); cabo@tzi.org; Jerald.P.Martocci@jci.com > Cc: roll-bounces@ietf.org; roll@ietf.org > Subject: RE: [Roll] 14kb 8-bit micro-controllers... > > Hi L., > > from RFC4294 for example (the same definition is present in many other > RFCs): > - a router is "a node that forwards IPv6 packets not explicitly > addressed to itself". > - a host is "any node that is not a router" > > Best, > Julien > > ________________________________ > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > L.Wood@surrey.ac.uk > Sent: vendredi 15 mai 2009 15:11 > To: cabo@tzi.org; Jerald.P.Martocci@jci.com > Cc: roll-bounces@ietf.org; roll@ietf.org > Subject: Re: [Roll] 14kb 8-bit micro-controllers... > > > > > From: roll-bounces@ietf.org on behalf of Carsten Bormann > > On May 14, 2009, at 23:32, Jerald.P.Martocci@jci.com wrote: > > > > Full-function Devices and Reduced Function Devices > > > > We've had that distinction in the Internet for a while: > > > > Routers and Hosts. > > Which is which? > > L. > > > (I'm only 15 % joking.) > > > > Gruesse, Carsten > > > > > > ------------------------------------------------------------------------ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or reproduction > of this message is strictly prohibited and may be unlawful. If you are > not the intended recipient, please contact the sender by return e-mail > and destroy all copies of the original message. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From jvasseur@cisco.com Mon May 18 08:04: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 EAE1D3A6D90; Mon, 18 May 2009 08:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.219 X-Spam-Level: X-Spam-Status: No, score=-10.219 tagged_above=-999 required=5 tests=[AWL=0.379, 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 WergLlWOjsyq; Mon, 18 May 2009 08:04:47 -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 2B7CF3A6A35; Mon, 18 May 2009 08:04:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,209,1241395200"; d="scan'208,217";a="40830755" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 18 May 2009 15:06:21 +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 n4IF6Li8025702; Mon, 18 May 2009 17:06:21 +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 n4IF6K30024506; Mon, 18 May 2009 15:06:20 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); Mon, 18 May 2009 17:06:20 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 May 2009 17:06:19 +0200 Message-Id: <0A8AF4E5-1522-4E14-8134-63AAD58A0162@cisco.com> From: JP Vasseur To: "Burnett, Peter" In-Reply-To: <8E9C227490A7614B87D90C0AE18CF22CADF2602E87@NLCLUEXM06.connect1.local> Content-Type: multipart/alternative; boundary=Apple-Mail-21-211489916 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 18 May 2009 17:06:18 +0200 References: <72FD9706-4821-4F67-B283-6101996593E2@tzi.org><4835AFD53A246A40A3B8DA85D 658C4BE7B100D@EVS-EC1-NODE4.surrey.ac.uk><38F26F36EAA981478A49D1F37F474A86031708DA@xmb-ams-33d.emea.cisco.com>, <4835AFD53A246A40A3B8DA85D658C4BE7B102B@EVS-EC1-NODE4.surrey.ac.uk> <8E9C227490A7614B87D90C0AE18CF22CADF2602E87@NLCLUEXM06.connect1.local> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 18 May 2009 15:06:19.0810 (UTC) FILETIME=[33238020:01C9D7CA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11122; t=1242659181; x=1243523181; 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]=2014kb=208-bit=20micro-controlle rs... |Sender:=20; bh=Y9PTIY8rV06dLKk7oeENOZXdj98fndNnXiMZYt5U4iI=; b=NyJrq33cWpfvEqq01cHWYd6uyx8fmKNlvdPKVfILXM8ONX1AjVxXHIDzrC 2DLBQR1XMYWAm4c6FGG9gyReinsXhgqJ3hXdKCLJwAUIF4qPb598anAcMYsf JmMTlPb5kn; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "roll@ietf.org" , "roll-bounces@ietf.org" Subject: Re: [Roll] 14kb 8-bit micro-controllers... 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, 18 May 2009 15:04:55 -0000 --Apple-Mail-21-211489916 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On May 18, 2009, at 2:46 PM, Burnett, Peter wrote: > In 15.4 an RFD only talks via its (FFD) parent so it is not > multihomed. So cannot be a router. But presumably an FFD can be a > router or a host. Just to make sure that we are on the same page, ROLL is not L2 specific. The notion of FFD, ... is 15.4 specific. The routing protocol may allow a router to announce specific capability of course. Thanks. JP. > Peter > From: roll-bounces@ietf.org [roll-bounces@ietf.org] On Behalf Of L.Wood@surrey.ac.uk > [L.Wood@surrey.ac.uk] > Sent: 18 May 2009 13:31 > To: jabeille@cisco.com; cabo@tzi.org; Jerald.P.Martocci@jci.com > Cc: roll-bounces@ietf.org; roll@ietf.org > Subject: Re: [Roll] 14kb 8-bit micro-controllers... > > > My brief question was: > > Which of (router or host) is the full-function device? > Which of (router or host) is the reduced-functionality device? > > hope that's clear. By the RFC4294 definition, any multihomed host > has the potential to be a router. > > L. > > > > > > -----Original Message----- > From: Julien Abeille (jabeille) [mailto:jabeille@cisco.com] > Sent: Mon 2009-05-18 10:14 > To: Wood L Dr (Electronic Eng); cabo@tzi.org; > Jerald.P.Martocci@jci.com > Cc: roll-bounces@ietf.org; roll@ietf.org > Subject: RE: [Roll] 14kb 8-bit micro-controllers... > > Hi L., > > from RFC4294 for example (the same definition is present in many other > RFCs): > - a router is "a node that forwards IPv6 packets not explicitly > addressed to itself". > - a host is "any node that is not a router" > > Best, > Julien > > ________________________________ > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > L.Wood@surrey.ac.uk > Sent: vendredi 15 mai 2009 15:11 > To: cabo@tzi.org; Jerald.P.Martocci@jci.com > Cc: roll-bounces@ietf.org; roll@ietf.org > Subject: Re: [Roll] 14kb 8-bit micro-controllers... > > > > > From: roll-bounces@ietf.org on behalf of Carsten Bormann > > On May 14, 2009, at 23:32, Jerald.P.Martocci@jci.com wrote: > > > > Full-function Devices and Reduced Function Devices > > > > We've had that distinction in the Internet for a while: > > > > Routers and Hosts. > > Which is which? > > L. > > > (I'm only 15 % joking.) > > > > Gruesse, Carsten > > > > > > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended > solely for the addressee(s). If you are not the intended recipient, > you are hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original > message. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-21-211489916 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On May 18, 2009, = at 2:46 PM, Burnett, Peter wrote:

In 15.4 = an RFD only talks via its (FFD) parent so it is not multihomed. So = cannot be a router. But presumably an FFD can be a router or a = host.

Just to = make sure that we are on the same page, ROLL is not L2 specific. The = notion of FFD, ... is 15.4 specific.
The routing protocol may = allow a router to announce specific capability of = course.

Thanks.

JP.
Peter
From: roll-bounces@ietf.org [roll-bounces@ietf.org] On = Behalf Of L.Wood@surrey.ac.uk [L.Wood@surrey.ac.uk]
Sent: 18 May 2009 = 13:31
To: jabeille@cisco.com; cabo@tzi.org; Jerald.P.Martocci@jci.comCc: roll-bounces@ietf.org; roll@ietf.org
Subject: Re: [Roll] 14kb 8-bit = micro-controllers...


My = brief question was:

Which of (router or host) is the = full-function device?
Which of (router or host) is the = reduced-functionality device?

hope that's clear. By the RFC4294 = definition, any multihomed host
has the potential to be a = router.

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><<= a = href=3D"mailto:L.Wood@surrey.ac.uk">L.Wood@surrey.ac.uk>


-----Original Message-----
From: Julien Abeille (jabeille) [mailto:jabeille@cisco.com]
Sent:= Mon 2009-05-18 10:14
To: Wood L Dr (Electronic Eng); cabo@tzi.org; Jerald.P.Martocci@jci.comCc: roll-bounces@ietf.org; roll@ietf.org
Subject: RE: [Roll] = 14kb 8-bit micro-controllers...

Hi L.,

from RFC4294 for = example (the same definition is present in many other
RFCs):
- a = router is "a node that forwards IPv6 packets not explicitly
addressed = to itself".
- a host is "any node that is not a = router"

Best,
Julien

________________________________
=
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] = On Behalf Of
L.Wood@surrey.ac.uk
Sent: = vendredi 15 mai 2009 15:11
To: cabo@tzi.org; Jerald.P.Martocci@jci.comCc: roll-bounces@ietf.org; roll@ietf.org
Subject: Re: [Roll] = 14kb 8-bit micro-controllers...




From: roll-bounces@ietf.org on behalf of Carsten = Bormann
> On May 14, 2009, at 23:32, Jerald.P.Martocci@jci.com wrote:

> > = Full-function Devices and Reduced Function Devices
>
> We've = had that distinction in the Internet for a while:
>
> = Routers and Hosts.

Which is which?

L.

> (I'm = only 15 % joking.)
>
> Gruesse, = Carsten





The information contained in this message may = be confidential and legally protected under applicable law. The message = is intended solely for the addressee(s). If you are not the intended = recipient, you are hereby notified that any use, forwarding, = dissemination, or reproduction of this message is strictly prohibited = and may be unlawful. If you are not the intended recipient, please = contact the sender by return e-mail and destroy all copies of the = original = message.
_______________________________________________
Roll= mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

= --Apple-Mail-21-211489916-- From pister@eecs.berkeley.edu Mon May 18 19:11: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 E7E8828C1C3 for ; Mon, 18 May 2009 19:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.772 X-Spam-Level: X-Spam-Status: No, score=-4.772 tagged_above=-999 required=5 tests=[AWL=-1.827, BAYES_40=-0.185, 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 VifK8a3KTmod for ; Mon, 18 May 2009 19:11:18 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 17C233A6E1A for ; Mon, 18 May 2009 19:11:18 -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 n4J2CoYw007393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 May 2009 19:12:51 -0700 (PDT) Message-ID: <4A121729.6050108@eecs.berkeley.edu> Date: Mon, 18 May 2009 19:19:21 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Omprakash Gnawali References: <49C93116.20102@eecs.berkeley.edu> <86c3ed7b0903241432vf5307a0o506085aea3357e45@mail.gmail.com> <49CAD3AA.7060002@eecs.berkeley.edu> <4A0AC469.4090309@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 19 May 2009 02:11:19 -0000 The wireless HART standard allows for power aware routing. HART nodes specify their power-related information when they join a network, and report energy consumption on a regular basis, to a centralized network manager. MPLS people might call this manager a Path Computation Engine. In these networks, basically all routing decisions are made by the PCE and pushed to the nodes. This is somewhat similar to what HYDRO does for peer-to-peer routes. Applications request services (packet flows between endpoints, with rate and latency requirements and duration), and the PCE determines if it can provide the requested service with sufficient redundancy to meet reliability requirements, while respecting the power-related restrictions of the nodes along the route. If it can, the route is installed, all routers along the path have their Layer2 links provisioned to meet the flow requirements, and the application gets a handle (basically a flow label) to use for any packets sent on that flow. The info that the node reports at join includes * peak tx rate [133 byte packets/s] * maximum lifetime at the peak rate [s] * recovery time [s] These were chosen to cover at least the four different cases that we could think of: line powered, energy-scavenging, peak-power-limited, total-energy limited For line-powered devices, the peak rate is a function only of the phy/mac. In the case of HART, this is one 133 byte (max total for 802.15.4) packet every 10ms. Max lifetime at this rate is INF, recovery time is 0. For energy harvesting devices, the peak rate and max lifetime at that rate are related to the size of the short-term storage (capacitor, rechargeable battery, ...). Recovery time is determined by the short term storage in Joules divided by the useful scavenging (charging) rate in Watts. For peak-power-limited devices (like many batteries, but also some line-powered devices in hazardous environments where energy storage is severely restricted) the peak rate depends on the radio and the supply. Max lifetime INF, recovery time 0. For total-energy limited devices (e.g. batteries), the product of peak rate and lifetime is related to the total energy stored in the battery. Recovery time is likely 0. Some "shortcomings" (from an IETF perspective) that would need to be changed if we wanted to do something similar in RoLL: * figure out how to handle a wide range of phy/macs, with very different packet sizes. Even in HART where you know the packet size for all devices, you'd still like more info - what if I send a 30B packet? Can I send 4 times as many (Ans: almost certainly not, it's rarely linear) * figure out how to do this in a distributed manner, instead of centralized * figure out how much, if any, of this has to do with routing ksjp Omprakash Gnawali wrote: > [...] > Regarding the energy metric, it would be helpful to know if there are > successful routing protocols (little bit more than simulation-only > papers) that take energy into account. What does their energy > representation look like? What shortcomings do they have that we are > trying to improve on here? If there are already lots of non-standard > LLNs with proprietary protocols, and if energy is a useful metric, > perhaps they already use it? Some context information such as that > would help the WG understand if we are trying to standardize what is > already done or if we are trying to do new research. > > - om_p > From prvs=383c72ea4=mukul@uwm.edu Mon May 18 21:04: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 3384E3A6B1F for ; Mon, 18 May 2009 21:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.169 X-Spam-Level: X-Spam-Status: No, score=-1.169 tagged_above=-999 required=5 tests=[AWL=-1.170, BAYES_50=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 BHjYUCZX0VGa for ; Mon, 18 May 2009 21:04:55 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id A71D93A68D1 for ; Mon, 18 May 2009 21:04:55 -0700 (PDT) Received: from mta01.pantherlink.uwm.edu ([129.89.7.81]) by ip2mta.uwm.edu with ESMTP; 18 May 2009 23:06:31 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 5C679B20008 for ; Mon, 18 May 2009 23:06:31 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdJOipVpMEtW for ; Mon, 18 May 2009 23:06:31 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 357B2B20006 for ; Mon, 18 May 2009 23:06:31 -0500 (CDT) Date: Mon, 18 May 2009 23:06:31 -0500 (CDT) From: Mukul Goyal To: roll@ietf.org Message-ID: <2089888244.5951821242705991151.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <2054907391.5951211242705577386.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] routing metrics: available channels on a link/node 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, 19 May 2009 04:05:24 -0000 I guess an important metric, for which I have seen no discussion so far, is the channel(s) available (or being used) on a link/node. I think multi-channel operation would emerge as a solution to many problems as LLN-based applications become popular. Should we have atleast some discussion of the "available channels on a link/node" as a potential metric in the metrics draft? Thanks Mukul From jvasseur@cisco.com Tue May 19 01:59: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 4460A3A708A for ; Tue, 19 May 2009 01:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.223 X-Spam-Level: X-Spam-Status: No, score=-10.223 tagged_above=-999 required=5 tests=[AWL=0.376, 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 HiNMJ9VBBudu for ; Tue, 19 May 2009 01:59:24 -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 E057D3A7096 for ; Tue, 19 May 2009 01:59:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,214,1241395200"; d="scan'208";a="40874788" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 May 2009 09:00:59 +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 n4J90xbm032728; Tue, 19 May 2009 11:00:59 +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 n4J90xpw011287; Tue, 19 May 2009 09:00:59 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); Tue, 19 May 2009 11:00:59 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 May 2009 11:00:58 +0200 Message-Id: From: JP Vasseur To: Mukul Goyal In-Reply-To: <2089888244.5951821242705991151.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 19 May 2009 11:00:57 +0200 References: <2089888244.5951821242705991151.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 19 May 2009 09:00:58.0876 (UTC) FILETIME=[53A82BC0:01C9D860] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=803; t=1242723659; x=1243587659; 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]=20routing=20metrics=3A=20availab le=20channels=20on=20a=20link/node |Sender:=20; bh=kzIMcUtjOBpxw4QwImlKl2OifuvWNBLg6jgmN/pW3Eo=; b=VFc//dPO4T0gU0uPW8fmCBCvinCvbDt0+0oaL6MwL/fS9m1d7Kmg4DJ7oG HgKHYHaGcI+DT/I2EHQcGoxiI4pVqfjp447y9yTe23xKhvEWl/gcUxjNPxGU PoGlZTw4xe; 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] routing metrics: available channels on a link/node 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, 19 May 2009 08:59:25 -0000 Hi Mukul, On May 19, 2009, at 6:06 AM, Mukul Goyal wrote: > I guess an important metric, for which I have seen no discussion so > far, is the channel(s) available (or being used) on a link/node. I > think multi-channel operation would emerge as a solution to many > problems as LLN-based applications become popular. Should we have > atleast some discussion of the "available channels on a link/node" > as a potential metric in the metrics draft? The best way to answer this question is to have see the routing implication, how would you expect the routing protocol to use this information ? Thanks. JP. > > Thanks > Mukul > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=383c72ea4=mukul@uwm.edu Tue May 19 02:31:16 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 B484B28C301 for ; Tue, 19 May 2009 02:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 e5qWpRZf4EbJ for ; Tue, 19 May 2009 02:31:15 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id EF4EC28C2C4 for ; Tue, 19 May 2009 02:31:13 -0700 (PDT) Received: from mta01.pantherlink.uwm.edu ([129.89.7.81]) by ip2mta.uwm.edu with ESMTP; 19 May 2009 04:32:48 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 9472FB20002; Tue, 19 May 2009 04:32:48 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0m0na+kKgDSf; Tue, 19 May 2009 04:32:47 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id B6B1AB20001; Tue, 19 May 2009 04:32:47 -0500 (CDT) Date: Tue, 19 May 2009 04:32:47 -0500 (CDT) From: Mukul Goyal To: JP Vasseur Message-ID: <765689116.5963131242725567633.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <709011721.5963011242725252079.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] routing metrics: available channels on a link/node 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, 19 May 2009 09:31:16 -0000 Hi JP, In multi-channel operation, a node would be able to dynamically change the frequency range/channel it is using to communicate with other nodes. It may even be possible for a node to use multiple channels for communication (e.g. a mains-powered device with multiple radios). The objective for dynamic channel selection or multiple channel operation could be to improve reliability or relieve congestion. The routing implication is that a node would not want to forward a packet to a neighbor on a channel that the neighbor is not listening to. Thanks Mukul ----- Original Message ----- From: "JP Vasseur" To: "Mukul Goyal" Cc: roll@ietf.org Sent: Tuesday, May 19, 2009 4:00:57 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] routing metrics: available channels on a link/node Hi Mukul, On May 19, 2009, at 6:06 AM, Mukul Goyal wrote: > I guess an important metric, for which I have seen no discussion so > far, is the channel(s) available (or being used) on a link/node. I > think multi-channel operation would emerge as a solution to many > problems as LLN-based applications become popular. Should we have > atleast some discussion of the "available channels on a link/node" > as a potential metric in the metrics draft? The best way to answer this question is to have see the routing implication, how would you expect the routing protocol to use this information ? Thanks. JP. > > Thanks > Mukul > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Tue May 19 02:35: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 8F4DF3A69E4 for ; Tue, 19 May 2009 02:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.227 X-Spam-Level: X-Spam-Status: No, score=-10.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 qbcOqk1ngVhY for ; Tue, 19 May 2009 02:35:23 -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 166A23A682D for ; Tue, 19 May 2009 02:35:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,214,1241395200"; d="scan'208";a="40881421" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 May 2009 09:36:58 +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 n4J9aw8Q015481; Tue, 19 May 2009 11:36:58 +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 n4J9awwe027918; Tue, 19 May 2009 09:36:58 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); Tue, 19 May 2009 11:36:58 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 May 2009 11:36:57 +0200 Message-Id: From: JP Vasseur To: Mukul Goyal In-Reply-To: <765689116.5963131242725567633.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 19 May 2009 11:36:57 +0200 References: <765689116.5963131242725567633.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 19 May 2009 09:36:58.0253 (UTC) FILETIME=[5ABEF3D0:01C9D865] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2283; t=1242725818; x=1243589818; 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]=20routing=20metrics=3A=20availab le=20channels=20on=20a=20link/node |Sender:=20; bh=V8vpivAHevzcW/M68CA0vgmmXKVsyMk+uLQTwXOORnI=; b=S2uzPsG78UPSWlp57cEwPH4/Gb/VpoQuI1tJv046LQIxnkLveaZjxEtbZP HLQQmnpWHk7wCXnF++maGoQj/+JS21mZnwMuiayL/ExZKbdJcIXdk99eioQ/ hZYYh/L9FP; 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] routing metrics: available channels on a link/node 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, 19 May 2009 09:35:24 -0000 Hi, On May 19, 2009, at 11:32 AM, Mukul Goyal wrote: > Hi JP, > > In multi-channel operation, a node would be able to dynamically > change the frequency range/channel it is using to communicate with > other nodes. It may even be possible for a node to use multiple > channels for communication (e.g. a mains-powered device with > multiple radios). The objective for dynamic channel selection or > multiple channel operation could be to improve reliability or > relieve congestion. > I know what multi-channel operation means, but my point was that a metric should be defined if and only if it is relevant to the routing protocol. If it translate to reliability, then it is a link reliability metrics, which could of course be used, not a metric that reflect the specific mechanism used by the L2, do you see my point ? > The routing implication is that a node would not want to forward a > packet to a neighbor on a channel that the neighbor is not listening > to. But then it is not a routing decision but a local forwarding one, handled locally by the transmitting node. Thanks. JP. > > Thanks > Mukul > > ----- Original Message ----- > From: "JP Vasseur" > To: "Mukul Goyal" > Cc: roll@ietf.org > Sent: Tuesday, May 19, 2009 4:00:57 AM GMT -06:00 US/Canada Central > Subject: Re: [Roll] routing metrics: available channels on a link/node > > Hi Mukul, > > On May 19, 2009, at 6:06 AM, Mukul Goyal wrote: > >> I guess an important metric, for which I have seen no discussion so >> far, is the channel(s) available (or being used) on a link/node. I >> think multi-channel operation would emerge as a solution to many >> problems as LLN-based applications become popular. Should we have >> atleast some discussion of the "available channels on a link/node" >> as a potential metric in the metrics draft? > > The best way to answer this question is to have see the routing > implication, how would you expect the routing protocol to use this > information ? > > Thanks. > > JP. > >> >> Thanks >> Mukul >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > From m1gs4n@gmail.com Tue May 19 02:36: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 4778528C2E8 for ; Tue, 19 May 2009 02:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 euoVO08mE9Ut for ; Tue, 19 May 2009 02:36:33 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 3C5B228C2AD for ; Tue, 19 May 2009 02:36:32 -0700 (PDT) Received: by fxm2 with SMTP id 2so3744887fxm.37 for ; Tue, 19 May 2009 02:38:02 -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; bh=rSg1L/obmESMqwdUQhBo3Fv///LLLjoZeZdhOd73rDs=; b=Jq2u/dI9sC3iSjAgxHopBza0vz+Fol7fxw9ffsqYdsvw92nG6+FjIi4qj+oQQhjEhw gp4WvJgopiiZCwge5VdnxiwKGVKEXlIs75rL9F0FU2yCvI8i9UnZ+KOa0XwDHgq7sO/t SOKKk5XCT6HvKHK0Hx751Mefl6bM//fmNEgOc= 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; b=HCrcTwuXzZzRLD9uexSrLmLDDePYGHhloF0LCR6GLrMr7sxG8vGeZoDIgiTM3LjY3Z CvZ4ec+P2FsNTbPas43aG2WkMxrioEe0Z4Zlqvt3ablfAe9bykB7B34aj0CnAtt9JAIf jO0Ko289w5GUcNtB4/9rO1vMoTsv1i7RQdXE8= MIME-Version: 1.0 Received: by 10.204.60.148 with SMTP id p20mr7672710bkh.160.1242725881660; Tue, 19 May 2009 02:38:01 -0700 (PDT) In-Reply-To: References: <2089888244.5951821242705991151.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Tue, 19 May 2009 11:38:01 +0200 Message-ID: <86c3ed7b0905190238w6c949b76kc632b260679c183a@mail.gmail.com> From: =?ISO-8859-1?Q?Miguel_S=E1nchez?= To: JP Vasseur Content-Type: multipart/alternative; boundary=00504502e3b4bac673046a40aac9 Cc: roll@ietf.org Subject: Re: [Roll] routing metrics: available channels on a link/node 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, 19 May 2009 09:36:34 -0000 --00504502e3b4bac673046a40aac9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Isn't this consideration making ROLL dependent on LL features? Miguel S=E1nchez On Tue, May 19, 2009 at 11:00 AM, JP Vasseur wrote: > Hi Mukul, > > On May 19, 2009, at 6:06 AM, Mukul Goyal wrote: > > I guess an important metric, for which I have seen no discussion so far, >> is the channel(s) available (or being used) on a link/node. I think >> multi-channel operation would emerge as a solution to many problems as >> LLN-based applications become popular. Should we have atleast some >> discussion of the "available channels on a link/node" as a potential met= ric >> in the metrics draft? >> > > The best way to answer this question is to have see the routing > implication, how would you expect the routing protocol to use this > information ? > > Thanks. > > JP. > > > >> Thanks >> Mukul >> >> _______________________________________________ >> 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 > --00504502e3b4bac673046a40aac9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Isn't this consideration making ROLL dependent on LL features?

= Miguel S=E1nchez


On Tue, May 19, 2009= at 11:00 AM, JP Vasseur <jvasseur@cisco.com> wrote:
Hi Mukul,


On May 19, 2009, at 6:06 AM, Mukul Goyal wrote:

I guess an important metric, for which I have seen no discussion so far, is= the channel(s) available (or being used) on a link/node. I think multi-cha= nnel operation would emerge as a solution to many problems as LLN-based app= lications become popular. Should we have atleast some discussion of the &qu= ot;available channels on a link/node" as a potential metric in the met= rics draft?

The best way to answer this question is to have see the routing implication= , how would you expect the routing protocol to use this information ?

Thanks.

JP.



Thanks
Mukul

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

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

--00504502e3b4bac673046a40aac9-- From jvasseur@cisco.com Tue May 19 02:36:45 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 030683A7091 for ; Tue, 19 May 2009 02:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.23 X-Spam-Level: X-Spam-Status: No, score=-10.23 tagged_above=-999 required=5 tests=[AWL=0.369, 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 f+l9HHcL5Gik for ; Tue, 19 May 2009 02:36: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 7541C3A6C13 for ; Tue, 19 May 2009 02:36:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,214,1241395200"; d="scan'208";a="40881564" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 19 May 2009 09:38:04 +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 n4J9c4Wd023787; Tue, 19 May 2009 11:38:04 +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 n4J9c4MW028293; Tue, 19 May 2009 09:38:04 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); Tue, 19 May 2009 11:38:04 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 May 2009 11:38:03 +0200 Message-Id: <46B2CB17-5D11-4C05-B523-B945F8E4D13F@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4A0D0E3E.6000407@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 v935.3) Date: Tue, 19 May 2009 11:38:02 +0200 References: <4A0CCEE8.8020709@acm.org> <4A0D0E3E.6000407@gmail.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 19 May 2009 09:38:03.0971 (UTC) FILETIME=[81EAB930:01C9D865] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=27967; t=1242725884; x=1243589884; 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]=20DT=20update=20--=20MUSTs=20-=2 0energy=20for=20link=20metric? |Sender:=20; bh=BiztHBLoTEbU/geFhLjbBvm6wDQqeZfokZ/MY4GqpCs=; b=AJV6nDbtZBtx7CVp1+Ve5mIwlD9BALdaFfD+zdFkknu3/dxXVv2+zpI/T4 ++r3LJInfp3VRgg6b5hlLVWB0CsXks5YUW1ZVPeO1kS//wgSAa7GxEzbTcl0 /qpU+wxLJM; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] DT update -- MUSTs - energy for link metric? 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, 19 May 2009 09:36:45 -0000 Hi Alex, On May 15, 2009, at 8:39 AM, Alexandru Petrescu wrote: > Tim, thanks for the update - that's hard work. > > A side remark about one particular interest: the req list doesn't seem > to include a metric for energy of the link: energy necessary to send a > packet on the link, or energy radiated in the air, or similar. > > Or I can't find it - is there one? > > I do find reqs for energy as constraints of the node device: level of > energy, energy of the node, power available, power budget, etc. > > Or is the link energy completely out of scope? > It would be useful to know what the WG thinks about link energy metrics. Here is my take on it. Node energy metric is undoubtedly needed, in =20 many cases, one may want to avoid a node that is battery operated or =20 running our of battery, we are all in sync with this. Now with regards =20= to link energy metrics, this is by far less obvious. Why would you =20 care knowing that the energy required to transmit 1 bit is X over a =20 link L1 and 2*X over a link L2? It might very well be that the node =20 connected to L2 has no energy constraint by contrast with the node =20 connected to L1 being battery operated. Thoughts ? Thanks. JP. > Thanks, > > Alex > > Tim Winter a =E9crit : >> WG, >> With the recent discussions regarding MUSTs, trade-offs, and how to =20= >> reconcile the 4 different requirements documents into one protocol, I >> do hope that this update provides some useful insights into how the =20= >> DT is proceeding. >> Here is a list of extracted MUSTs, with some categorization, along =20= >> with uncategorized SHOULDs. >> Please do carefully note the following: 1) The source requirements =20= >> documents contain much more background text and detail for =20 >> interpreting the meaning and intent of the MUSTs than appears in this >> summary list. This summary list is quite simply keyed off of MUSTs =20= >> (and SHOULDs) in the requirements documents. This list can be used =20= >> like an index, but the requirements documents give further context =20= >> which is important for detailed interpretation, and the requirements >> documents are authoritative. 2) The categories presented here may be >> considered a very coarse grouping. The intent was to begin to place >> the 4 requirements documents side by side in a way that is >> meaningful to begin interpretation, but is not intended to be a >> precise taxonomy. Similarly, please do not place too much meaning in >> the category names per se, they are perhaps coarse, but the intent is >> that the grouped functionalities are related. Finally, the coarse =20= >> groupings may well produce `overlap' in some cases. 3) In some places >> [editorial comments] are added that do not appear in the original =20 >> drafts. >> The design team underwent an exercise of going through and discussing >> these requirements, and at a first cut asked `can this requirement =20= >> _not_ be satisfied?'. This exercise provides further familiarization >> with the requirements as well as a crude `reality check' if you >> will. >> So far, no requirement is clearly ruled out, and there is a basis to >> continue the discussion of what a routing protocol solution to meet =20= >> these requirements will look like. >> It is also clear when we look at these requirements that an attempt =20= >> to find or meet an intersection between all of them is very =20 >> challenging. Nevertheless, it is not our intended approach to pick =20= >> and choose, e.g. we do not want to say `let us define a protocol that >> will satisfy XXX in HOME, but at the cost of YYY in INDUSTRIAL'. We >> are tasked clearly to try and define _one_ protocol to satisfy _all_ >> of the requirements. Perhaps as the process continues it will >> become clear and necessary that such a `hard' trade-off needs to be >> made to resolve some fundamental conflict, but it would be very >> premature to say such things at this point. If such a trade-off >> emerges and becomes inevitable, there will most certainly be very >> careful discussion and justification to be made. >> This is the inspiration behind the approach we are taking: 1) =20 >> define a basic core protocol + optional extensions 2) allow the =20 >> protocol to be parameterized -> such that the implementor has the =20 >> ability to make >> appropriate detailed trade-offs with the guidance of applicability =20= >> statements as appropriate to the target application/platform. >> It is our hope that by following this approach we have a protocol =20 >> which provides a practical and implementable framework in which can =20= >> be made proper and measured compromises with respect to different =20 >> applications. >> We do hope not to end up with a duck ;) >> More updates to come as the work proceeds. >> Regards, >> -Tim >> = --------------------------------------------------------------------------= - >> - Categorized MUSTs Sources: draft-ietf-roll-urban-routing-=20 >> reqs-05.txt draft-ietf-roll-indus-routing-reqs-05.txt draft-ietf-=20 >> roll-building-routing-reqs-05.txt draft-ietf-roll-home-routing-=20 >> reqs-06.txt >> = --------------------------------------------------------------------------= - >> A. General: ----------- A.1 URBAN: For the latter [patches/=20 >> updates], the protocol(s) MUST support multi- and any-cast =20 >> addressing. >> A.2 URBAN: Routing protocols activated in urban sensor =20 >> networks MUST support unicast (traffic is sent to a single field =20 >> device), multicast (traffic is sent to a set of devices that are =20 >> subscribed to >> the same multicast group), and anycast (where multiple field devices >> are configured to accept traffic sent on a single IP anycast >> address) transmission schemes. >> A.3 BUILDING: Routing MUST support anycast, unicast, and multicast. >> A.4 BUILDING: A network device MUST be able to communicate in a =20 >> peer- to-peer manner with any other device on the network. Thus, the >> routing protocol MUST provide routes between arbitrary hosts within =20= >> the appropriate administrative domain. >> A.5 BUILDING: The routing protocol MUST support a metric of route =20= >> quality and optimize path selection according to such metrics within >> constraints established for links along the paths. >> A.6 BUILDING: In such cases [sleeping nodes], the routing =20 >> protocol MUST discover the capability of a node to act as a proxy =20= >> during path >> calculation; then deliver the packet to the assigned proxy for later >> delivery to the sleeping device upon its next awakened cycle. >> B. Traffic Flows: ----------------- [ Node -> (thru) LBR ] =20= >> [ (thru) LBR -> Node ] [ Node -> Node ] >> B.1 URBAN: The routing protocol MUST be able to accommodate =20 >> traffic bursts by dynamically computing and selecting multiple paths >> towards the same destination. >> B.2 INDUSTRIAL: The routing protocol MUST be able to compute paths of >> not-necessarily-equal cost toward a given destination so as to =20 >> enable load balancing across a variety of paths. >> B.3 INDUSTRIAL: The routing protocol MUST be able to compute a set of >> unidirectional routes with potentially different costs that are =20 >> composed of one or more non-congruent paths. >> C. Autonomous Configuration/Management/Reliability: =20 >> ---------------------------------------- C.1 URBAN: To this end, >> the routing protocol(s) MUST provide a set of features including 0-=20= >> configuration at network ramp-up, (network-internal) self- =20 >> organization and configuration due to topological changes, and the =20= >> ability to support (network-external) patches and configuration =20 >> updates. >> C.2 INDUSTRIAL: The routing protocol MUST route on paths that are =20 >> changed to appropriately provision the application requirements. The >> routing protocol MUST support the ability to recompute paths based =20= >> on Network Layer abstractions of the underlying link attributes/=20 >> metric that may change dynamically. >> C.3 INDUSTRIAL: The routing algorithm MUST be able to generate =20 >> different routes with different characteristics (e.g. optimized =20 >> according to difference cost, etc...). >> C.4 INDUSTRIAL: The routing protocol MUST enable the full discovery =20= >> and setup of the environment (available links, selected peers, =20 >> reachable network). The protocol also MUST support the =20 >> distribution of configuration from a centralized management =20 >> controller if operator-initiated configuration change is allowed. >> C.5 BUILDING: It MUST be possible to fully commission network =20 >> devices without requiring any additional commissioning device (e.g. =20= >> laptop). >> C.6 BUILDING: Devices referencing data in the replaced device =20 >> MUST be able to reference data in its replacement without being =20 >> reconfigured to refer to the new device. Thus, such a reference =20 >> cannot be a hardware identifier, such as the MAC address, nor a =20 >> hard-coded route. If such a reference is an IP address, the =20 >> replacement device MUST be assigned the IP addressed previously bound >> to the replaced device. Or if the logical equivalent of a hostname >> is used for the reference, it must be translated to the replacement >> IP address. >> C.7 HOME: Thus the routing protocol designed for home =20 >> automation networks MUST provide a set of features including zero- =20= >> configuration of the routing protocol for a new node to be added to =20= >> the network. =46rom a routing perspective, zero-configuration means =20= >> that a node can obtain an address and join the network on its own, =20= >> without human intervention. >> C.8 HOME: The routing protocol MUST support the ability to =20 >> isolate a misbehaving node thus preserving the correct operation of =20= >> the overall network. >> D. Scalability: --------------- D.1 URBAN: The routing =20 >> protocol(s) MUST be capable of supporting the organization of a large >> number of sensing nodes into regions containing on the order of 10^2 >> to 10^4 sensing nodes each. >> D.2 URBAN: The routing protocol(s) MUST be scalable so as to =20 >> accommodate a very large and increasing number of nodes without =20 >> deteriorating selected performance parameters below configurable =20 >> thresholds. >> D.3 BUILDING: The routing protocol MUST be able to support networks >> with at least 2000 nodes supporting at least 1000 routing devices >> and 1000 non-routing device. Subnetworks (e.g. rooms, primary =20 >> equipment) within the network must support upwards to 255 sensors =20 >> and/or actuators. >> D.4 HOME: The routing protocol MUST support 250 devices in =20 >> the network. >> E. Performance: --------------- E.1 INDUSTRIAL: The routing algorithm >> MUST find the appropriate route(s) and report success or failure =20 >> within several minutes, and SHOULD report success or failure within =20= >> tens of seconds. >> E.2 INDUSTRIAL: The routing algorithm MUST respond to normal link =20 >> failure rates with routes that meet the Service requirements =20 >> (especially latency) throughout the routing response. The routing =20= >> algorithm SHOULD always be in the process of recalculating the =20 >> route in response to changing link statistics. The routing =20 >> algorithm MUST recalculate the paths when field devices change due =20= >> to insertion, removal or failure, and this recalculation MUST NOT =20 >> cause latencies greater than the specified constraints (typically =20= >> seconds to minutes). >> E.3 HOME: The routing protocol MUST provide mobility with =20 >> convergence time below 0.5 second if only the sender has moved. >> E.4 HOME: Sleeping nodes may appear to be non-responsive. The =20= >> routing protocol MUST take into account the delivery time to a =20 >> sleeping target node. The wake-up interval of a sleeping node MUST =20= >> be less than one second. >> E.5 HOME: The routing protocol MUST converge within 0.5 =20 >> second if no nodes have moved. >> E.6 HOME: The routing protocol MUST converge within 2 seconds =20= >> if the destination node of the packet has moved. >> F. Constraint-based Routing: ---------------------------- F.1 =20 >> URBAN: To this end, the routing protocol(s) MUST support parameter =20= >> constrained routing, where examples of such parameters (CPU, memory =20= >> size, battery level, etc.) have been given in the previous paragraph. >> In other words the routing protocol MUST be able to advertise node =20= >> capabilities that will be exclusively used by the routing protocol =20= >> engine for routing decision. >> F.2 INDUSTRIAL: The routing protocol MUST also support different =20 >> metric types for each link used to compute the path according to =20 >> some objective function (e.g. minimize latency) depending on the =20 >> nature of the traffic. >> F.3 INDUSTRIAL: The routing algorithm MUST support node-constrained =20= >> routing (e.g. taking into account the existing energy state as a node >> constraint). Node constraints include power and memory, as well as =20= >> constraints placed on the device by the user, such as battery life. >> F.4 BUILDING: The routing protocol MUST take into account device =20= >> characteristics such as power budget. >> F.5 HOME: The routing protocol MUST support constraint-based =20= >> routing taking into account node properties (CPU, memory, level of =20= >> energy, sleep intervals, safety/convenience of changing battery). >> G. Security: ------------ G.1 URBAN: The U-LLN network MUST deny >> any node who has not been authenticated to the U-LLN and authorized =20= >> to participate to the routing decision process. >> G.2 URBAN: Mechanisms MUST be in place to deny any node which =20= >> attempts to take malicious advantage of self-configuration and self- >> organization procedures. >> G.3 URBAN: A node MUST authenticate itself to a trusted node =20 >> that is already associated with the U-LLN before the former can take >> part in self-configuration or self-organization. >> G.4 URBAN: A node that has already authenticated and =20 >> associated with the U-LLN MUST deny, to the maximum extent =20 >> possible, the allocation of resources to any unauthenticated peer. >> G.5 URBAN: The routing protocol(s) MUST deny service to any node >> which has not clearly established trust with the U-LLN. >> G.6 URBAN: To this end, routing protocol(s) proposed in the =20 >> context of U-LLNs MUST support authentication and integrity =20 >> measures and SHOULD support confidentiality (routing security) =20 >> measures. >> G.7 INDUSTRIAL: The routing MUST be configured and managed using =20 >> secure messages and protocols that prevent outsider attacks and limit >> insider attacks from field devices installed in insecure locations =20= >> in the plant. >> G.8 BUILDING: Authentication policy and updates MUST be routable =20= >> over-the-air. >> G.9 BUILDING: Data encryption of packets MUST optionally be =20 >> supported by use of either a network wide key and/or application =20 >> key. >> G.10 BUILDING: The routing protocol MUST allow routing a packet =20 >> encrypted with an application key through forwarding devices that =20 >> without requiring each node in the path have the application key. >> G.11 BUILDING: The encryption policy MUST support encryption of the >> payload only or the entire packet. >> G.12 BUILDING: Due to the limited resources of an LLN, the security >> policy defined within the LLN MUST be able to differ from that of >> the rest of the IP network within the facility yet packets MUST still >> be able to route to or through the LLN from/to these networks. >> G.13 BUILDING: The routing protocol MUST gracefully handle =20 >> routing temporal security updates (e.g. dynamic keys) to sleeping =20 >> devices on >> their 'awake' cycle to assure that sleeping devices can readily and =20= >> efficiently access then network. >> G.14 HOME: The routing protocol chosen for ROLL MUST allow =20 >> for low- power, low-cost network devices with limited security needs. >> G.15 HOME: Protection against unintentional inclusion in =20 >> neighboring networks MUST be provided. >> = --------------------------------------------------------------------------= - >> = --------------------------------------------------------------------------= - >> = --------------------------------------------------------------------------= - >> - Uncategorized SHOULDs =20 >> = --------------------------------------------------------------------------= - >> draft-ietf-roll-building-routing-reqs >> = --------------------------------------------------------------------------= - >> 5.1.3. Local Testing >> Routing should allow for temporary ad hoc paths to be established =20 >> that are updated as the network physically and functionally expands. >> 5.3.1. Mobile Device Requirements >> To minimize network dynamics, mobile devices SHOULD not be allowed to >> act as forwarding devices (routers) for other devices in the LLN. >> A mobile device that moves within an LLN SHOULD reestablish end-to- =20= >> end communication to a fixed device also in the LLN within 2 seconds. >> The network convergence time should be less than 5 seconds once the =20= >> mobile device stops moving. >> A mobile device that moves outside of an LLN SHOULD reestablish end- >> to-end communication to a fixed device in the new LLN within 5 =20 >> seconds. The network convergence time should be less than 5 =20 >> seconds once the mobile device stops moving. >> A mobile device that moves outside of one LLN into another LLN SHOULD >> reestablish end-to-end communication to a fixed device in the old >> LLN within 10 seconds. The network convergence time should be less >> than 10 seconds once the mobile device stops. >> A mobile device that moves outside of one LLN into another LLN SHOULD >> reestablish end-to-end communication to another mobile device in the >> new LLN within 20 seconds. The network convergence time should be >> less than 30 seconds once the mobile devices stop moving. >> A mobile device that moves outside of one LLN into another LLN SHOULD >> reestablish end-to-end communication to a mobile device in the old >> LLN within 30 seconds. The network convergence time should be less >> than 30 seconds once the mobile devices stop moving. >> 5.4.1. Limited Processing Power for Non-routing Devices. >> The software size requirement for non-routing devices (e.g. sleeping >> sensors and actuators) SHOULD be implementable in 8-bit devices with >> no more than 128KB of memory. >> 5.4.2. Limited Processing Power for Routing Devices >> The software size requirements for routing devices (e.g. room =20 >> controllers) SHOULD be implementable in 8-bit devices with no more =20= >> than 256KB of flash memory. >> 5.6.2. Route Tracking >> Route diagnostics SHOULD be supported providing information such as =20= >> path quality; number of hops; available alternate active paths with =20= >> associated costs. Path quality is the relative measure of 'goodness' >> of the selected source to destination path as compared to alternate =20= >> paths. This composite value may be measured as a function of hop =20 >> count, signal strength, available power, existing active paths or any >> other criteria deemed by ROLL as the path cost differentiator. >> 5.7.1. Path Cost >> [...] These metrics SHOULD reflect metrics such as signal strength, =20= >> available bandwidth, hop count, energy availability and communication >> error rates. >> 5.7.3. Route Redundancy >> The routing layer SHOULD be configurable to allow secondary and =20 >> tertiary paths to be established and used upon failure of the primary >> path. >> 5.7.4. Route Discovery Time >> If route discovery occurs during packet transmission time, it =20 >> SHOULD NOT add more than 120ms of latency to the packet delivery =20 >> time. >> 5.7.5. Route Preference >> Route cost algorithms SHOULD allow the installer to optionally select >> 'preferred' paths based on the known spatial layout of the =20 >> communicating devices. >> = --------------------------------------------------------------------------= - >> draft-ietf-roll-home-routing-reqs >> = --------------------------------------------------------------------------= - >> >> = --------------------------------------------------------------------------= - >> roll-indus-routing-reqs >> = --------------------------------------------------------------------------= - >> - In fast control, tens of milliseconds of latency is typical. >> [...] >> For these reasons, the ROLL routing infrastructure is required to =20 >> compute and update constrained routes on demand, and it can be =20 >> expected that this model will become more prevalent for field =20 >> device to field device connectivity as well as for some field =20 >> device to Infrastructure devices over time. >> [ A route that connects a field device to a plant application may =20 >> have multiple paths that go through more than one LLN access =20 >> point. The routing protocol MUST be able to compute paths of not-=20 >> necessarily-equal cost toward a given destination so as to enable >> load balancing across a variety of paths. The availability of each =20= >> path in a multipath route can change over time. Hence, it is =20 >> important to measure the availability on a per-path basis and =20 >> select a path (or paths) according to the availability =20 >> requirements. ] >> The routing protocol SHOULD support broadcast or multicast =20 >> addressing. >> The routing protocol SHOULD support the wireless worker with fast =20 >> network connection times of a few of seconds, and low command and =20 >> response latencies to the plant behind the LLN access points, to =20 >> applications, and to field devices. The routing protocol SHOULD also >> support the bandwidth allocation for bulk transfers between the field >> device and the handheld device of the wireless worker. The routing >> protocol SHOULD support walking speeds for maintaining network >> connectivity as the handheld device changes position in the wireless >> network. >> The routing protocol SHOULD NOT require to preprovision information =20= >> about the environment where the node will be deployed. The routing =20= >> protocol MUST enable the full discovery and setup of the =20 >> environment (available links, selected peers, reachable =20 >> network).The protocol also MUST support the distribution of =20 >> configuration from a centralized management controller if operator-=20= >> initiated configuration >> change is allowed. >> In industrial plants it must be assumed that the field devices have =20= >> marginal physical security and might be compromised. The routing =20 >> protocol SHOULD limit the risk incurred by one node being =20 >> compromised, for instance by proposing non congruent path for a given >> route and balancing the traffic across the network. >> The routing protocol SHOULD compartmentalize the trust placed in =20 >> field devices so that a compromised field device does not destroy the >> security of the whole network. >> = --------------------------------------------------------------------------= - >> - draft-ietf-roll-urban-routing-reqs-04 >> = --------------------------------------------------------------------------= - >> - The routing protocols(s) SHOULD support the organization of a =20 >> large number of nodes into regions of configurable size. >> Routing within urban sensor networks SHOULD require the U-LLN nodes =20= >> to dynamically compute, select and install different paths towards =20= >> a same destination, depending on the nature of the traffic. Such =20 >> functionality in support of, for example, data aggregation, may imply >> to use some mechanisms to mark/tag the traffic for appropriate =20 >> routing decision using the IPv6 packet format (e.g. use of DSCP, Flow >> Label) based on an upper layer marking decision. >> The protocol(s) SHOULD also support the formation and =20 >> identification of groups of field devices in the network. >> The routing protocol(s) SHOULD be able to dynamically adapt, e.g. =20 >> through the application of appropriate routing metrics, to ever- =20 >> changing conditions of communication (possible degradation of QoS, =20= >> variable nature of the traffic (real time vs. non real time, sensed =20= >> data vs. alerts), node mobility, a combination thereof, etc.) >> The routing protocol(s) SHOULD be able to dynamically compute, select >> and possibly optimize the (multiple) path(s) that will be used by the >> participating devices to forward the traffic towards the actuators >> and/or a LBR according to the service-specific and traffic-specific >> QoS, traffic engineering and routing security policies that will >> have to be enforced at the scale of a routing domain (that is, a set >> of networking devices administered by a globally unique entity), or a >> region of such domain (e.g. a metropolitan area composed of clusters >> of sensors). >> To this end, local network dynamics SHOULD NOT impact the entire =20 >> network to be re-organized or re-reconfigured; however, the network =20= >> SHOULD be locally optimized to cater for the encountered changes. The >> routing protocol(s) SHOULD support appropriate mechanisms in order >> to be informed of the association, disassociation, and disappearance >> of nodes. The routing protocol(s) SHOULD support appropriate >> updating mechanisms in order to be informed of changes in >> connectivity. The routing protocol(s) SHOULD use this information >> to initiate protocol specific mechanisms for reorganization and >> reconfiguration as necessary to maintain overall routing efficiency. >> Convergence and route establishment times SHOULD be significantly >> lower than the smallest reporting interval. >> Differentiation SHOULD be made between node disappearance, where =20 >> the node disappears without prior notification, and user or node- =20 >> initiated disassociation ("phased-out"), where the node has enough =20= >> time to inform the network about its pending removal. >> The routing protocol(s) SHOULD also support the ability to route =20 >> according to different metrics (one of which could e.g. be latency). >> The routing protocol(s) SHOULD support defense against DoS attacks =20= >> and other attempts to maliciously or inadvertently cause the =20 >> routing protocol(s) mechanisms to over consume the limited =20 >> resources of LLN nodes, e.g. by constructing forwarding loops or =20 >> causing excessive routing protocol overhead traffic, etc. >> The U-LLN SHOULD NOT interface with any external network which has =20= >> not established trust. The U-LLN SHOULD be capable of limiting the =20= >> resources granted in support of an external network so as not to be =20= >> vulnerable to DoS. >> = --------------------------------------------------------------------------= - >> _______________________________________________ Roll mailing list = Roll@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Tue May 19 02:39: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 964D23A67F7 for ; Tue, 19 May 2009 02:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.233 X-Spam-Level: X-Spam-Status: No, score=-10.233 tagged_above=-999 required=5 tests=[AWL=0.365, 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 wvrXShTOKbuh for ; Tue, 19 May 2009 02:39:48 -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 991E33A682D for ; Tue, 19 May 2009 02:39:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,214,1241395200"; d="scan'208,217";a="40882119" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 May 2009 09:41:23 +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 n4J9fNqP017134; Tue, 19 May 2009 11:41:23 +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 n4J9fMOh029707; Tue, 19 May 2009 09:41:23 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); Tue, 19 May 2009 11:41:22 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 May 2009 11:41:22 +0200 Message-Id: <3199AC93-BB4D-4BE7-8076-297E1D883C99@cisco.com> From: JP Vasseur To: m1gs4n@gmail.com In-Reply-To: <86c3ed7b0905190238w6c949b76kc632b260679c183a@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-48-278392762 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 19 May 2009 11:41:21 +0200 References: <2089888244.5951821242705991151.JavaMail.root@mail02.pantherlink.uwm.edu> <86c3ed7b0905190238w6c949b76kc632b260679c183a@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 19 May 2009 09:41:22.0546 (UTC) FILETIME=[F846DD20:01C9D865] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4552; t=1242726083; x=1243590083; 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]=20routing=20metrics=3A=20availab le=20channels=20on=20a=20link/node |Sender:=20; bh=xeYi6d5BmoNmlfDGxziz9mKZ1RQxcO7YcsR7/Ks0t30=; b=vB9cLUzLjpcxQ/fqKJkbgEBX45Etj03Zt8f1tZ0DcOXcw6vK1cTGQSfZ7A KzqoNHGlYy9o9WAP1wFLeWvOk+SsdGA6gOM5CbKnoqYBfgOQ7jjXGaNpeknb ltH/6tz/IT; 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] routing metrics: available channels on a link/node 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, 19 May 2009 09:39:50 -0000 --Apple-Mail-48-278392762 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On May 19, 2009, at 11:38 AM, Miguel S=E1nchez wrote: > Isn't this consideration making ROLL dependent on LL features? Nope, that is the point. The aim of these metric is to provide an =20 independent link layer abstraction of its properties. When specifying =20= the routing protocol we will have to define rules as to how to use =20 these metrics of course. JP. > > Miguel S=E1nchez > > > On Tue, May 19, 2009 at 11:00 AM, JP Vasseur =20 > wrote: > Hi Mukul, > > > On May 19, 2009, at 6:06 AM, Mukul Goyal wrote: > > I guess an important metric, for which I have seen no discussion so =20= > far, is the channel(s) available (or being used) on a link/node. I =20 > think multi-channel operation would emerge as a solution to many =20 > problems as LLN-based applications become popular. Should we have =20 > atleast some discussion of the "available channels on a link/node" =20 > as a potential metric in the metrics draft? > > The best way to answer this question is to have see the routing =20 > implication, how would you expect the routing protocol to use this =20 > information ? > > Thanks. > > JP. > > > > Thanks > Mukul > > _______________________________________________ > 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-48-278392762 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On May 19, 2009, = at 11:38 AM, Miguel S=E1nchez wrote:

Isn't this = consideration making ROLL dependent on LL features? =

Nope, that is the point. The aim of = these metric is to provide an independent link layer abstraction of its = properties. When specifying the routing protocol we will have to define = rules as to how to use these metrics of = course.

JP.


Miguel S=E1nchez


On Tue, May 19, 2009 at 11:00 AM, JP Vasseur <jvasseur@cisco.com> = wrote:
Hi Mukul,


On May 19, 2009, at 6:06 AM, = Mukul Goyal wrote:

I guess an important metric, for which I = have seen no discussion so far, is the channel(s) available (or being = used) on a link/node. I think multi-channel operation would emerge as a = solution to many problems as LLN-based applications become popular. = Should we have atleast some discussion of the "available channels on a = link/node" as a potential metric in the metrics draft?
=
The best way to answer this question is to have see the = routing implication, how would you expect the routing protocol to use = this information ?

Thanks.

= JP.



Thanks
= Mukul

_______________________________________________
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-48-278392762-- From prvs=383c72ea4=mukul@uwm.edu Tue May 19 02:47: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 C72753A69FF for ; Tue, 19 May 2009 02:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.195, 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 S5cMjzKB-a7k for ; Tue, 19 May 2009 02:47:23 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id C67C728C327 for ; Tue, 19 May 2009 02:45:55 -0700 (PDT) Received: from mta01.pantherlink.uwm.edu ([129.89.7.81]) by ip2mta.uwm.edu with ESMTP; 19 May 2009 04:47:32 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 278F6B20002; Tue, 19 May 2009 04:47:32 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6lfjxzxdRAm; Tue, 19 May 2009 04:47:31 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id C169BB20001; Tue, 19 May 2009 04:47:31 -0500 (CDT) Date: Tue, 19 May 2009 04:47:31 -0500 (CDT) From: Mukul Goyal To: m1gs4n@gmail.com Message-ID: <728643150.5964101242726451478.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <86c3ed7b0905190238w6c949b76kc632b260679c183a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] routing metrics: available channels on a link/node 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, 19 May 2009 09:47:24 -0000 Not sure if multi-channel operation could be considered an LL-level feature= . It is not that only specific LL protocols would allow multi-channel opera= tion. Thanks Mukul ----- Original Message ----- From: "Miguel S=C3=A1nchez" To: "JP Vasseur" Cc: "Mukul Goyal" , roll@ietf.org Sent: Tuesday, May 19, 2009 4:38:01 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] routing metrics: available channels on a link/node Isn't this consideration making ROLL dependent on LL features?=20 Miguel S=C3=A1nchez=20 On Tue, May 19, 2009 at 11:00 AM, JP Vasseur < jvasseur@cisco.com > wrote:= =20 Hi Mukul,=20 On May 19, 2009, at 6:06 AM, Mukul Goyal wrote:=20 I guess an important metric, for which I have seen no discussion so far, is= the channel(s) available (or being used) on a link/node. I think multi-cha= nnel operation would emerge as a solution to many problems as LLN-based app= lications become popular. Should we have atleast some discussion of the "av= ailable channels on a link/node" as a potential metric in the metrics draft= ?=20 The best way to answer this question is to have see the routing implication= , how would you expect the routing protocol to use this information ?=20 Thanks.=20 JP.=20 Thanks=20 Mukul=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 From prvs=383c72ea4=mukul@uwm.edu Tue May 19 03:15: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 6ED9B3A709D for ; Tue, 19 May 2009 03:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 I8xKRzhmD5JF for ; Tue, 19 May 2009 03:15:42 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 5D5693A709C for ; Tue, 19 May 2009 03:15:42 -0700 (PDT) Received: from mta01.pantherlink.uwm.edu ([129.89.7.81]) by ip1mta.uwm.edu with ESMTP; 19 May 2009 05:17:18 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 6F78DB20002; Tue, 19 May 2009 05:17:18 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PGyzk4pPfpK; Tue, 19 May 2009 05:17:18 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 28966B20003; Tue, 19 May 2009 05:17:18 -0500 (CDT) Date: Tue, 19 May 2009 05:17:18 -0500 (CDT) From: Mukul Goyal To: JP Vasseur Message-ID: <803963583.5964411242728237980.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <2033187551.5964391242728116702.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.15_GA_2851.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.15_GA_2851.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] routing metrics: available channels on a link/node 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, 19 May 2009 10:15:43 -0000 Hi JP I see your point. I stand corrected. I agree that the channel used on a link is a local forwarding decision, not a routing one. Thanks Mukul ----- Original Message ----- From: "JP Vasseur" To: "Mukul Goyal" Cc: roll@ietf.org Sent: Tuesday, May 19, 2009 4:36:57 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] routing metrics: available channels on a link/node Hi, On May 19, 2009, at 11:32 AM, Mukul Goyal wrote: > Hi JP, > > In multi-channel operation, a node would be able to dynamically > change the frequency range/channel it is using to communicate with > other nodes. It may even be possible for a node to use multiple > channels for communication (e.g. a mains-powered device with > multiple radios). The objective for dynamic channel selection or > multiple channel operation could be to improve reliability or > relieve congestion. > I know what multi-channel operation means, but my point was that a metric should be defined if and only if it is relevant to the routing protocol. If it translate to reliability, then it is a link reliability metrics, which could of course be used, not a metric that reflect the specific mechanism used by the L2, do you see my point ? > The routing implication is that a node would not want to forward a > packet to a neighbor on a channel that the neighbor is not listening > to. But then it is not a routing decision but a local forwarding one, handled locally by the transmitting node. Thanks. JP. > > Thanks > Mukul > > ----- Original Message ----- > From: "JP Vasseur" > To: "Mukul Goyal" > Cc: roll@ietf.org > Sent: Tuesday, May 19, 2009 4:00:57 AM GMT -06:00 US/Canada Central > Subject: Re: [Roll] routing metrics: available channels on a link/node > > Hi Mukul, > > On May 19, 2009, at 6:06 AM, Mukul Goyal wrote: > >> I guess an important metric, for which I have seen no discussion so >> far, is the channel(s) available (or being used) on a link/node. I >> think multi-channel operation would emerge as a solution to many >> problems as LLN-based applications become popular. Should we have >> atleast some discussion of the "available channels on a link/node" >> as a potential metric in the metrics draft? > > The best way to answer this question is to have see the routing > implication, how would you expect the routing protocol to use this > information ? > > Thanks. > > JP. > >> >> Thanks >> Mukul >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Tue May 19 03:19:52 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 C140B3A70A0 for ; Tue, 19 May 2009 03:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.108, 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 M99WI3GtRvvn for ; Tue, 19 May 2009 03:19:52 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id AAFE03A67F7 for ; Tue, 19 May 2009 03:19:51 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n4JA9dKw032535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 May 2009 12:09:39 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n4JABooS000431; Tue, 19 May 2009 12:11:50 +0200 (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 n4JABolM018797; Tue, 19 May 2009 12:11:50 +0200 Message-ID: <4A1285E6.2040902@gmail.com> Date: Tue, 19 May 2009 12:11:50 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: JP Vasseur References: <4A0CCEE8.8020709@acm.org> <4A0D0E3E.6000407@gmail.com> <46B2CB17-5D11-4C05-B523-B945F8E4D13F@cisco.com> In-Reply-To: <46B2CB17-5D11-4C05-B523-B945F8E4D13F@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] DT update -- MUSTs - energy for link metric? 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, 19 May 2009 10:19:52 -0000 JP Vasseur a écrit : > Hi Alex, > > On May 15, 2009, at 8:39 AM, Alexandru Petrescu wrote: > >> Tim, thanks for the update - that's hard work. >> >> A side remark about one particular interest: the req list doesn't >> seem to include a metric for energy of the link: energy necessary >> to send a packet on the link, or energy radiated in the air, or >> similar. >> >> Or I can't find it - is there one? >> >> I do find reqs for energy as constraints of the node device: level >> of energy, energy of the node, power available, power budget, etc. >> >> >> Or is the link energy completely out of scope? >> > > It would be useful to know what the WG thinks about link energy > metrics. I am very interested on all WG oppinions on link energy metric. > Here is my take on it. Node energy metric is undoubtedly needed, in > many cases, one may want to avoid a node that is battery operated or > running our of battery, we are all in sync with this. Now with > regards to link energy metrics, this is by far less obvious. Why > would you care knowing that the energy required to transmit 1 bit is > X over a link L1 and 2*X over a link L2? My first impression: because typical cost metrics are _link_ metrics, not node metrics - the hop count is the number of links, not of nodes (a 3 node topology uses a 2 hop count metric - the number of links). More often than not the parameters advertised in Router Advertisements of OSPF and ICMP are link parameters: link MTU, link prefix. It sounds attractive to reuse the same link concept for energy. Prior publications making think link energy is relevant: Callaway, E., "Secure Low-Power Operation of Wireless Sensor Networks", Intelligent Systems, January 2004. Mentions transmission of a packet with a particular 15.4 transceiver to be 56 micro-Joules, and is computed relative to the number of bits transmitted. L. Li, J-Y. Jalpern, ICC'01, Finland., "Minimum-Energy Mobile Wireless Networks Revisited", June 2001. Explicitely assumes that "a transmission between node u and v takes power p(uv) [...]". IEEE Global Telecommunications Conference, Globecom '03, "Measurement and Characterization of Link Quality Metrics in Energy Constrained Wireless Sensor Networks", 2003. Mentions that the energy to transmit a packet is proportional to 'link inefficiency', and this latter (not the energy) is defined as a metric. > It might very well be that the node connected to L2 has no energy > constraint by contrast with the node connected to L1 being battery > operated. There seems indeed to be a decoupling between the energy left to a node, its battery level, its consumption patterns - and the energy needed to send an MTU-sized packet on a link. They could be both needed, I can't easily say, because the NP-completeness issue: routing according to metric "link-energy" _and_ metric "node-energy" may be NP-hard to do. Alex From Manhar.Goindi@landisgyr.com Tue May 19 03:24:15 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 08C8E3A709B for ; Tue, 19 May 2009 03:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=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 GP8UWJGPnTN6 for ; Tue, 19 May 2009 03:24:14 -0700 (PDT) Received: from mail.ap.landisgyr.com (mail.ap.landisgyr.com [61.8.13.202]) by core3.amsl.com (Postfix) with ESMTP id AAFD13A70A3 for ; Tue, 19 May 2009 03:24:13 -0700 (PDT) Received: from mail pickup service by mail.ap.landisgyr.com with Microsoft SMTPSVC; Tue, 19 May 2009 20:25:49 +1000 From: "Goindi, Manhar" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Importance: normal Priority: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 May 2009 20:25:46 +1000 Message-ID: In-Reply-To: <803963583.5964411242728237980.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] routing metrics: available channels on a link/node thread-index: AcnYaxcGFOTJ5ByETuGHopUGA7CtGQAAMW6g References: <2033187551.5964391242728116702.JavaMail.root@mail02.pantherlink.uwm.edu> <803963583.5964411242728237980.JavaMail.root@mail02.pantherlink.uwm.edu> To: "Mukul Goyal" X-OriginalArrivalTime: 19 May 2009 10:25:49.0288 (UTC) FILETIME=[2DC76680:01C9D86C] Cc: roll@ietf.org Subject: Re: [Roll] routing metrics: available channels on a link/node 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, 19 May 2009 10:24:15 -0000 Hi Mukul, I am not sure but I may be breaking your thread of discussion. But just one small question - Has the ROLL Routing Requirements Draft version been released (I think it was supposed to be released in May)? Please let me know the link if you have it. Sorry for any inconvenience caused. Thanks & Best Regards, Manhar Goindi Manhar Goindi Technical Expert Landis+Gyr Phone: +91 120 3352149 manhar.goindi@landisgyr.com http://www.landisgyr.com/ Manage Energy Better -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mukul Goyal Sent: Tuesday, May 19, 2009 3:47 PM To: JP Vasseur Cc: roll@ietf.org Subject: Re: [Roll] routing metrics: available channels on a link/node Hi JP I see your point. I stand corrected. I agree that the channel used on a link is a local forwarding decision, not a routing one. Thanks Mukul =20 ----- Original Message ----- From: "JP Vasseur" To: "Mukul Goyal" Cc: roll@ietf.org Sent: Tuesday, May 19, 2009 4:36:57 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] routing metrics: available channels on a link/node Hi, On May 19, 2009, at 11:32 AM, Mukul Goyal wrote: > Hi JP, > > In multi-channel operation, a node would be able to dynamically =20 > change the frequency range/channel it is using to communicate with =20 > other nodes. It may even be possible for a node to use multiple =20 > channels for communication (e.g. a mains-powered device with =20 > multiple radios). The objective for dynamic channel selection or =20 > multiple channel operation could be to improve reliability or =20 > relieve congestion. > I know what multi-channel operation means, but my point was that a =20 metric should be defined if and only if it is relevant to the routing =20 protocol. If it translate to reliability, then it is a link =20 reliability metrics, which could of course be used, not a metric that =20 reflect the specific mechanism used by the L2, do you see my point ? > The routing implication is that a node would not want to forward a =20 > packet to a neighbor on a channel that the neighbor is not listening =20 > to. But then it is not a routing decision but a local forwarding one, =20 handled locally by the transmitting node. Thanks. JP. > > Thanks > Mukul > > ----- Original Message ----- > From: "JP Vasseur" > To: "Mukul Goyal" > Cc: roll@ietf.org > Sent: Tuesday, May 19, 2009 4:00:57 AM GMT -06:00 US/Canada Central > Subject: Re: [Roll] routing metrics: available channels on a link/node > > Hi Mukul, > > On May 19, 2009, at 6:06 AM, Mukul Goyal wrote: > >> I guess an important metric, for which I have seen no discussion so >> far, is the channel(s) available (or being used) on a link/node. I >> think multi-channel operation would emerge as a solution to many >> problems as LLN-based applications become popular. Should we have >> atleast some discussion of the "available channels on a link/node" >> as a potential metric in the metrics draft? > > The best way to answer this question is to have see the routing > implication, how would you expect the routing protocol to use this > information ? > > Thanks. > > JP. > >> >> Thanks >> Mukul >> >> _______________________________________________ >> 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 PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. This e-mail (including any attachments) is confidential and may be = legally privileged. If you are not an intended recipient or an = authorized representative of an intended recipient, you are prohibited = from using, copying or distributing the information in this e-mail or = its attachments. If you have received this e-mail in error, please = notify the sender immediately by return e-mail and delete all copies of = this message and any attachments. Thank you. From jvasseur@cisco.com Tue May 19 03:26: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 01E0A3A6848 for ; Tue, 19 May 2009 03:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.937 X-Spam-Level: X-Spam-Status: No, score=-7.937 tagged_above=-999 required=5 tests=[AWL=-1.938, BAYES_00=-2.599, J_CHICKENPOX_63=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 cAnGR0-HBuLq for ; Tue, 19 May 2009 03:26:21 -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 B6F7E3A6CAB for ; Tue, 19 May 2009 03:26:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,214,1241395200"; d="scan'208";a="76632764" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-5.cisco.com with ESMTP; 19 May 2009 10:27:57 +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 n4JARuGe010214; Tue, 19 May 2009 12:27:56 +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 n4JARuhx018414; Tue, 19 May 2009 10:27:56 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); Tue, 19 May 2009 12:27:56 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 May 2009 12:27:55 +0200 Message-Id: From: JP Vasseur To: "Goindi, Manhar" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 19 May 2009 12:27:55 +0200 References: <2033187551.5964391242728116702.JavaMail.root@mail02.pantherlink.uwm.edu> <803963583.5964411242728237980.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 19 May 2009 10:27:56.0389 (UTC) FILETIME=[79897950:01C9D86C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4646; t=1242728876; x=1243592876; 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]=20routing=20metrics=3A=20availab le=20channels=20on=20a=20link/node |Sender:=20; bh=GdEgQHpSAjD4kvfLcDTZaqjF8vVP7eDc+Z9+Bs9Asf0=; b=MOOZDUeFz1lNZmquV5X2ziPUtNOPgU9xcLpoapPVQ+14A302a1RJnx2UiA 8lv6xPgmm/UhF58Hki/bqfBaqj8weLciNay0P8WVqvSrNmf+CCpK1MtKwFaE qZQxDtPfc0; 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] routing metrics: available channels on a link/node 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, 19 May 2009 10:26:23 -0000 Hi, On May 19, 2009, at 12:25 PM, Goindi, Manhar wrote: > Hi Mukul, > > I am not sure but I may be breaking your thread of discussion. > > But just one small question - Has the ROLL Routing Requirements Draft > version been released (I think it was supposed to be released in May)? > Please let me know the link if you have it. You can find all of then there: (along with all WG documents) http://www.ietf.org/html.charters/roll-charter.html JP. > > Sorry for any inconvenience caused. > > > Thanks & Best Regards, > Manhar Goindi > > > Manhar Goindi > Technical Expert > Landis+Gyr > Phone: +91 120 3352149 > manhar.goindi@landisgyr.com > http://www.landisgyr.com/ > > Manage Energy Better > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > Mukul Goyal > Sent: Tuesday, May 19, 2009 3:47 PM > To: JP Vasseur > Cc: roll@ietf.org > Subject: Re: [Roll] routing metrics: available channels on a link/node > > Hi JP > > I see your point. I stand corrected. I agree that the channel used > on a > link is a local forwarding decision, not a routing one. > > Thanks > Mukul > > ----- Original Message ----- > From: "JP Vasseur" > To: "Mukul Goyal" > Cc: roll@ietf.org > Sent: Tuesday, May 19, 2009 4:36:57 AM GMT -06:00 US/Canada Central > Subject: Re: [Roll] routing metrics: available channels on a link/node > > Hi, > > On May 19, 2009, at 11:32 AM, Mukul Goyal wrote: > >> Hi JP, >> >> In multi-channel operation, a node would be able to dynamically >> change the frequency range/channel it is using to communicate with >> other nodes. It may even be possible for a node to use multiple >> channels for communication (e.g. a mains-powered device with >> multiple radios). The objective for dynamic channel selection or >> multiple channel operation could be to improve reliability or >> relieve congestion. >> > > I know what multi-channel operation means, but my point was that a > metric should be defined if and only if it is relevant to the routing > protocol. If it translate to reliability, then it is a link > reliability metrics, which could of course be used, not a metric that > reflect the specific mechanism used by the L2, do you see my point ? > >> The routing implication is that a node would not want to forward a >> packet to a neighbor on a channel that the neighbor is not listening >> to. > > But then it is not a routing decision but a local forwarding one, > handled locally by the transmitting node. > > Thanks. > > JP. > >> >> Thanks >> Mukul >> >> ----- Original Message ----- >> From: "JP Vasseur" >> To: "Mukul Goyal" >> Cc: roll@ietf.org >> Sent: Tuesday, May 19, 2009 4:00:57 AM GMT -06:00 US/Canada Central >> Subject: Re: [Roll] routing metrics: available channels on a link/ >> node >> >> Hi Mukul, >> >> On May 19, 2009, at 6:06 AM, Mukul Goyal wrote: >> >>> I guess an important metric, for which I have seen no discussion so >>> far, is the channel(s) available (or being used) on a link/node. I >>> think multi-channel operation would emerge as a solution to many >>> problems as LLN-based applications become popular. Should we have >>> atleast some discussion of the "available channels on a link/node" >>> as a potential metric in the metrics draft? >> >> The best way to answer this question is to have see the routing >> implication, how would you expect the routing protocol to use this >> information ? >> >> Thanks. >> >> JP. >> >>> >>> Thanks >>> Mukul >>> >>> _______________________________________________ >>> 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 > > > PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. > > This e-mail (including any attachments) is confidential and may be > legally privileged. If you are not an intended recipient or an > authorized representative of an intended recipient, you are > prohibited from using, copying or distributing the information in > this e-mail or its attachments. If you have received this e-mail in > error, please notify the sender immediately by return e-mail and > delete all copies of this message and any attachments. Thank you. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Tue May 19 05:36: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 1FDAC3A689B for ; Tue, 19 May 2009 05:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.219 X-Spam-Level: X-Spam-Status: No, score=-10.219 tagged_above=-999 required=5 tests=[AWL=0.380, 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 sDULguCH9qGz for ; Tue, 19 May 2009 05:36:36 -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 A7FD63A6E96 for ; Tue, 19 May 2009 05:36:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,215,1241395200"; d="scan'208";a="40897030" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 May 2009 12:38: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 n4JCc8dZ012715; Tue, 19 May 2009 14:38:08 +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 n4JCc8Dt005783; Tue, 19 May 2009 12:38:08 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); Tue, 19 May 2009 14:38:08 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 May 2009 14:38:07 +0200 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4A1285E6.2040902@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 v935.3) Date: Tue, 19 May 2009 14:38:06 +0200 References: <4A0CCEE8.8020709@acm.org> <4A0D0E3E.6000407@gmail.com> <46B2CB17-5D11-4C05-B523-B945F8E4D13F@cisco.com> <4A1285E6.2040902@gmail.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 19 May 2009 12:38:07.0652 (UTC) FILETIME=[A9699E40:01C9D87E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3419; t=1242736688; x=1243600688; 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]=20DT=20update=20--=20MUSTs=20-=2 0energy=20for=20link=20metric? |Sender:=20; bh=BEYfzHTtVizZqO+AW/Thc7d2xDmJe4P35jjhHGHRweA=; b=hvzJdz+HezEvhIrHH8cb3u9tF3ag09Ms2GGdIW8WuHuTaC6hcGLfndVVq4 LyicoWah/tOJbr7yu6MwklgEF5cZEYjNVgyTybyNDxuYkZdJ1MHhJ0HpQdM/ NihZ8wQeQ/; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] DT update -- MUSTs - energy for link metric? 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, 19 May 2009 12:36:37 -0000 but again, this does not really answer *the* question: why should the =20= routing protocol take link energy into account during path computation ? On May 19, 2009, at 12:11 PM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> Hi Alex, >> On May 15, 2009, at 8:39 AM, Alexandru Petrescu wrote: >>> Tim, thanks for the update - that's hard work. >>> A side remark about one particular interest: the req list doesn't =20= >>> seem to include a metric for energy of the link: energy necessary =20= >>> to send a packet on the link, or energy radiated in the air, or =20 >>> similar. >>> Or I can't find it - is there one? >>> I do find reqs for energy as constraints of the node device: level >>> of energy, energy of the node, power available, power budget, etc. >>> Or is the link energy completely out of scope? >> It would be useful to know what the WG thinks about link energy =20 >> metrics. > > I am very interested on all WG oppinions on link energy metric. > >> Here is my take on it. Node energy metric is undoubtedly needed, in =20= >> many cases, one may want to avoid a node that is battery operated or >> running our of battery, we are all in sync with this. Now with =20 >> regards to link energy metrics, this is by far less obvious. Why =20 >> would you care knowing that the energy required to transmit 1 bit is >> X over a link L1 and 2*X over a link L2? > > My first impression: because typical cost metrics are _link_ > metrics, not node metrics - the hop count is the number of links, =20 > not of > nodes (a 3 node topology uses a 2 hop count metric - the number of =20 > links). > > More often than not the parameters advertised in Router Advertisements > of OSPF and ICMP are link parameters: link MTU, link prefix. > > It sounds attractive to reuse the same link concept for energy. > > Prior publications making think link energy is relevant: > > Callaway, E., "Secure Low-Power Operation of Wireless > Sensor Networks", Intelligent Systems, January 2004. > > Mentions transmission of a packet with a particular 15.4 transceiver =20= > to > be 56 micro-Joules, and is computed relative to the number of bits > transmitted. > > L. Li, J-Y. Jalpern, ICC'01, Finland., "Minimum-Energy > Mobile Wireless Networks Revisited", June 2001. > > Explicitely assumes that "a transmission between node u and v takes > power p(uv) [...]". > > IEEE Global Telecommunications Conference, Globecom '03, > "Measurement and Characterization of Link Quality Metrics > in Energy Constrained Wireless Sensor Networks", 2003. > > Mentions that the energy to transmit a packet is proportional to > 'link inefficiency', and this latter (not the energy) is defined as a > metric. > >> It might very well be that the node connected to L2 has no energy =20 >> constraint by contrast with the node connected to L1 being battery =20= >> operated. > > There seems indeed to be a decoupling between the energy left to a =20 > node, its battery level, its consumption patterns - and the energy =20 > needed to send an MTU-sized packet on a link. > > They could be both needed, I can't easily say, because the > NP-completeness issue: routing according to metric "link-energy" _and_ > metric "node-energy" may be NP-hard to do. > > Alex > > From alexandru.petrescu@gmail.com Tue May 19 07:50: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 DFC603A699C for ; Tue, 19 May 2009 07:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.106, 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 nvvXo+MOemsd for ; Tue, 19 May 2009 07:50:00 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 96F493A680A for ; Tue, 19 May 2009 07:50:00 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n4JEg1FS017541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 May 2009 16:42:01 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n4JEg1Zm002300; Tue, 19 May 2009 16:42:01 +0200 (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 n4JEg05F012991; Tue, 19 May 2009 16:42:01 +0200 Message-ID: <4A12C538.2020800@gmail.com> Date: Tue, 19 May 2009 16:42:00 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: JP Vasseur References: <4A0CCEE8.8020709@acm.org> <4A0D0E3E.6000407@gmail.com> <46B2CB17-5D11-4C05-B523-B945F8E4D13F@cisco.com> <4A1285E6.2040902@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] DT update -- MUSTs - energy for link metric? 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, 19 May 2009 14:50:02 -0000 JP Vasseur a écrit : > but again, this does not really answer *the* question: why should the > routing protocol take link energy into account during path > computation ? For example to identify a path requiring less energy to transceive a packet, than another path. > Why would you care knowing that the energy required to transmit 1 bit > is X over a link L1 and 2*X over a link L2? [...] It might very well > be that the node connected to L2 has no energy constraint by contrast > with the node connected to L1 being battery operated. For the same reasons an existing rt protocol cares about the number of hops, link bandwidth, link MTU, link prefix, and less about the nodes' MIPS, RAM. By analogy. Alex > > On May 19, 2009, at 12:11 PM, Alexandru Petrescu wrote: > >> JP Vasseur a écrit : >>> Hi Alex, On May 15, 2009, at 8:39 AM, Alexandru Petrescu wrote: >>>> Tim, thanks for the update - that's hard work. A side remark >>>> about one particular interest: the req list doesn't seem to >>>> include a metric for energy of the link: energy necessary to >>>> send a packet on the link, or energy radiated in the air, or >>>> similar. Or I can't find it - is there one? I do find reqs for >>>> energy as constraints of the node device: level of energy, >>>> energy of the node, power available, power budget, etc. Or is >>>> the link energy completely out of scope? >>> It would be useful to know what the WG thinks about link energy >>> metrics. >> >> I am very interested on all WG oppinions on link energy metric. >> >>> Here is my take on it. Node energy metric is undoubtedly needed, >>> in many cases, one may want to avoid a node that is battery >>> operated or running our of battery, we are all in sync with this. >>> Now with regards to link energy metrics, this is by far less >>> obvious. Why would you care knowing that the energy required to >>> transmit 1 bit is X over a link L1 and 2*X over a link L2? >> >> My first impression: because typical cost metrics are _link_ >> metrics, not node metrics - the hop count is the number of links, >> not of nodes (a 3 node topology uses a 2 hop count metric - the >> number of links). >> >> More often than not the parameters advertised in Router >> Advertisements of OSPF and ICMP are link parameters: link MTU, link >> prefix. >> >> It sounds attractive to reuse the same link concept for energy. >> >> Prior publications making think link energy is relevant: >> >> Callaway, E., "Secure Low-Power Operation of Wireless Sensor >> Networks", Intelligent Systems, January 2004. >> >> Mentions transmission of a packet with a particular 15.4 >> transceiver to be 56 micro-Joules, and is computed relative to the >> number of bits transmitted. >> >> L. Li, J-Y. Jalpern, ICC'01, Finland., "Minimum-Energy Mobile >> Wireless Networks Revisited", June 2001. >> >> Explicitely assumes that "a transmission between node u and v takes >> power p(uv) [...]". >> >> IEEE Global Telecommunications Conference, Globecom '03, >> "Measurement and Characterization of Link Quality Metrics in Energy >> Constrained Wireless Sensor Networks", 2003. >> >> Mentions that the energy to transmit a packet is proportional to >> 'link inefficiency', and this latter (not the energy) is defined as >> a metric. >> >>> It might very well be that the node connected to L2 has no energy >>> constraint by contrast with the node connected to L1 being >>> battery operated. >> >> There seems indeed to be a decoupling between the energy left to a >> node, its battery level, its consumption patterns - and the energy >> needed to send an MTU-sized packet on a link. >> >> They could be both needed, I can't easily say, because the >> NP-completeness issue: routing according to metric "link-energy" >> _and_ metric "node-energy" may be NP-hard to do. >> >> Alex >> >> > > From jvasseur@cisco.com Tue May 19 09:08: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 7A85A3A6F95 for ; Tue, 19 May 2009 09:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.223 X-Spam-Level: X-Spam-Status: No, score=-10.223 tagged_above=-999 required=5 tests=[AWL=0.376, 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 zEhMv20OYjDk for ; Tue, 19 May 2009 09:08:26 -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 DBE6D3A6F82 for ; Tue, 19 May 2009 09:08:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,216,1241395200"; d="scan'208";a="40922418" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 May 2009 16:10:01 +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 n4JGA1Pq018448; Tue, 19 May 2009 18:10:01 +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 n4JGA1T9021530; Tue, 19 May 2009 16:10:01 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); Tue, 19 May 2009 18:10:01 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 May 2009 18:10:00 +0200 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4A12C538.2020800@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 v935.3) Date: Tue, 19 May 2009 18:09:59 +0200 References: <4A0CCEE8.8020709@acm.org> <4A0D0E3E.6000407@gmail.com> <46B2CB17-5D11-4C05-B523-B945F8E4D13F@cisco.com> <4A1285E6.2040902@gmail.com> <4A12C538.2020800@gmail.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 19 May 2009 16:10:00.0961 (UTC) FILETIME=[43229F10:01C9D89C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4058; t=1242749401; x=1243613401; 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]=20DT=20update=20--=20MUSTs=20-=2 0energy=20for=20link=20metric? |Sender:=20; bh=n8R4C+xsw8SISIJ+2bi60X3wCK68Orqoe4s4qWhCSy8=; b=ZbacZe4S8cVCv5Um1cq+3xCLjnP1vnHw3d6ag+WypQr0Ly5C+q9wdCOj8u mtdNRj6k1gzTOeZTFnCD/WlJa5Uuv/OR5nga2WVFcWwG1d48f2vNZSBfoDH9 QTvU+XuN8A; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ROLL WG , dtroll@external.cisco.com Subject: Re: [Roll] DT update -- MUSTs - energy for link metric? 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, 19 May 2009 16:08:27 -0000 On May 19, 2009, at 4:42 PM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> but again, this does not really answer *the* question: why should the >> routing protocol take link energy into account during path >> computation ? > > For example to identify a path requiring less energy to transceive a > packet, than another path. but again, back to my example, this may not help: > >> Why would you care knowing that the energy required to transmit 1 bit >> is X over a link L1 and 2*X over a link L2? [...] It might very well >> be that the node connected to L2 has no energy constraint by contrast >> with the node connected to L1 being battery operated. > > For the same reasons an existing rt protocol cares about the number =20= > of hops, link bandwidth, link MTU, link prefix, and less about the =20 > nodes' MIPS, RAM. By analogy. > > Alex > >> On May 19, 2009, at 12:11 PM, Alexandru Petrescu wrote: >>> JP Vasseur a =E9crit : >>>> Hi Alex, On May 15, 2009, at 8:39 AM, Alexandru Petrescu wrote: >>>>> Tim, thanks for the update - that's hard work. A side remark >>>>> about one particular interest: the req list doesn't seem to >>>>> include a metric for energy of the link: energy necessary to =20 >>>>> send a packet on the link, or energy radiated in the air, or >>>>> similar. Or I can't find it - is there one? I do find reqs for >>>>> energy as constraints of the node device: level of energy, >>>>> energy of the node, power available, power budget, etc. Or is >>>>> the link energy completely out of scope? >>>> It would be useful to know what the WG thinks about link energy >>>> metrics. >>> I am very interested on all WG oppinions on link energy metric. >>>> Here is my take on it. Node energy metric is undoubtedly needed, >>>> in many cases, one may want to avoid a node that is battery >>>> operated or running our of battery, we are all in sync with this. >>>> Now with regards to link energy metrics, this is by far less >>>> obvious. Why would you care knowing that the energy required to >>>> transmit 1 bit is X over a link L1 and 2*X over a link L2? >>> My first impression: because typical cost metrics are _link_ =20 >>> metrics, not node metrics - the hop count is the number of links, >>> not of nodes (a 3 node topology uses a 2 hop count metric - the >>> number of links). >>> More often than not the parameters advertised in Router >>> Advertisements of OSPF and ICMP are link parameters: link MTU, link >>> prefix. >>> It sounds attractive to reuse the same link concept for energy. >>> Prior publications making think link energy is relevant: >>> Callaway, E., "Secure Low-Power Operation of Wireless Sensor >>> Networks", Intelligent Systems, January 2004. >>> Mentions transmission of a packet with a particular 15.4 >>> transceiver to be 56 micro-Joules, and is computed relative to the >>> number of bits transmitted. >>> L. Li, J-Y. Jalpern, ICC'01, Finland., "Minimum-Energy Mobile >>> Wireless Networks Revisited", June 2001. >>> Explicitely assumes that "a transmission between node u and v takes >>> power p(uv) [...]". >>> IEEE Global Telecommunications Conference, Globecom '03, =20 >>> "Measurement and Characterization of Link Quality Metrics in Energy >>> Constrained Wireless Sensor Networks", 2003. >>> Mentions that the energy to transmit a packet is proportional to =20 >>> 'link inefficiency', and this latter (not the energy) is defined as >>> a metric. >>>> It might very well be that the node connected to L2 has no energy >>>> constraint by contrast with the node connected to L1 being >>>> battery operated. >>> There seems indeed to be a decoupling between the energy left to a >>> node, its battery level, its consumption patterns - and the energy >>> needed to send an MTU-sized packet on a link. >>> They could be both needed, I can't easily say, because the NP-=20 >>> completeness issue: routing according to metric "link-energy" >>> _and_ metric "node-energy" may be NP-hard to do. >>> Alex > > From zahariad@teihal.gr Wed May 20 00:20: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 E22183A6E7A for ; Wed, 20 May 2009 00:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, STOX_REPLY_TYPE=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 quV6zFKoLhqX for ; Wed, 20 May 2009 00:20:16 -0700 (PDT) Received: from teihal.gr (mail.teihal.gr [195.130.65.41]) by core3.amsl.com (Postfix) with ESMTP id DE93D3A68EA for ; Wed, 20 May 2009 00:20:12 -0700 (PDT) X-MDAV-Processed: teihal.gr, Wed, 20 May 2009 10:21:58 +0300 Received: from sVAIO by teihal.gr (MDaemon PRO v10.0.1) with ESMTP id md50005923348.msg for ; Wed, 20 May 2009 10:21:57 +0300 X-Spam-Processed: teihal.gr, Wed, 20 May 2009 10:21:57 +0300 (not processed: message from valid local sender) X-Authenticated-Sender: zahariad@teihal.gr X-MDRemoteIP: 172.20.1.83 X-Return-Path: zahariad@teihal.gr X-Envelope-From: zahariad@teihal.gr X-MDaemon-Deliver-To: roll@ietf.org Message-ID: <4345CED632CC439D81F06EF5724F0864@sVAIO> From: "Theodore Zahariadis" To: , References: In-Reply-To: Date: Wed, 20 May 2009 10:21:45 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: roll@ietf.org Subject: Re: [Roll] DT update -- MUSTs - energy for link metric? (JP Vasseur) 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, 20 May 2009 07:20:17 -0000 Dear Tim, Alex, Maybe the question could be asked somewhat differently... Maybe something like: "Is the network survivability a routing protocol requirement or a feature?" or "Is a routing protocol that can achieve longer lifetime for the network (as a whole) better than a protocol that exhausts selectively some nodes?" If energy is not taken into account and a node has many data to send, then the nodes in a fixed path will be exhausted. On the other hand, if energy is a metric, the path will change (maybe it will not be always the optimal one), but the energy will be reduced progressively. Moreover, if the nodes have a method to create some energy (e.g. a tiny photovoltaic cell, or windmill) the network may survive. We have done a number of simulations in JSIM trying to combine routing and trust. It seams that even in a trust framework, taking into account energy metrics may drastically increase the network lifetime. Of course all these apply to homogeneous nodes. If the nodes are heterogeneous calculating the optimal energy metric may be too hard (may not worth). On the other hand, there may be some thresholds put e.g. "if the remaining energy of node "a" is less than "x", avoid it, unless it is the node with the maximum energy in the neighborhood". BR, Theodore > Date: Tue, 19 May 2009 14:38:06 +0200 > From: JP Vasseur > Subject: Re: [Roll] DT update -- MUSTs - energy for link metric? > To: Alexandru Petrescu > Cc: ROLL WG , dtroll@external.cisco.com > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes > > but again, this does not really answer *the* question: why should the > routing protocol take link energy into account during path computation ? > > On May 19, 2009, at 12:11 PM, Alexandru Petrescu wrote: > >> JP Vasseur a ?crit : >>> Hi Alex, >>> On May 15, 2009, at 8:39 AM, Alexandru Petrescu wrote: >>>> Tim, thanks for the update - that's hard work. >>>> A side remark about one particular interest: the req list doesn't >>>> seem to include a metric for energy of the link: energy necessary >>>> to send a packet on the link, or energy radiated in the air, or >>>> similar. >>>> Or I can't find it - is there one? >>>> I do find reqs for energy as constraints of the node device: level >>>> of energy, energy of the node, power available, power budget, etc. >>>> Or is the link energy completely out of scope? >>> It would be useful to know what the WG thinks about link energy >>> metrics. >> >> I am very interested on all WG oppinions on link energy metric. >> >>> Here is my take on it. Node energy metric is undoubtedly needed, in >>> many cases, one may want to avoid a node that is battery operated or >>> running our of battery, we are all in sync with this. Now with >>> regards to link energy metrics, this is by far less obvious. Why >>> would you care knowing that the energy required to transmit 1 bit is >>> X over a link L1 and 2*X over a link L2? >> >> My first impression: because typical cost metrics are _link_ >> metrics, not node metrics - the hop count is the number of links, >> not of >> nodes (a 3 node topology uses a 2 hop count metric - the number of >> links). >> >> More often than not the parameters advertised in Router Advertisements >> of OSPF and ICMP are link parameters: link MTU, link prefix. >> >> It sounds attractive to reuse the same link concept for energy. >> >> Prior publications making think link energy is relevant: >> >> Callaway, E., "Secure Low-Power Operation of Wireless >> Sensor Networks", Intelligent Systems, January 2004. >> >> Mentions transmission of a packet with a particular 15.4 transceiver >> to >> be 56 micro-Joules, and is computed relative to the number of bits >> transmitted. >> >> L. Li, J-Y. Jalpern, ICC'01, Finland., "Minimum-Energy >> Mobile Wireless Networks Revisited", June 2001. >> >> Explicitely assumes that "a transmission between node u and v takes >> power p(uv) [...]". >> >> IEEE Global Telecommunications Conference, Globecom '03, >> "Measurement and Characterization of Link Quality Metrics >> in Energy Constrained Wireless Sensor Networks", 2003. >> >> Mentions that the energy to transmit a packet is proportional to >> 'link inefficiency', and this latter (not the energy) is defined as a >> metric. >> >>> It might very well be that the node connected to L2 has no energy >>> constraint by contrast with the node connected to L1 being battery >>> operated. >> >> There seems indeed to be a decoupling between the energy left to a >> node, its battery level, its consumption patterns - and the energy >> needed to send an MTU-sized packet on a link. >> >> They could be both needed, I can't easily say, because the >> NP-completeness issue: routing according to metric "link-energy" _and_ >> metric "node-energy" may be NP-hard to do. >> >> Alex From jvasseur@cisco.com Wed May 20 00:42: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 D95B43A67FA for ; Wed, 20 May 2009 00:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.926 X-Spam-Level: X-Spam-Status: No, score=-9.926 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, J_CHICKENPOX_53=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 jJwK2CYlLXnf for ; Wed, 20 May 2009 00:42:29 -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 284F23A6A75 for ; Wed, 20 May 2009 00:42:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,220,1241395200"; d="scan'208";a="40961231" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 May 2009 07:44:05 +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 n4K7i52Y011904; Wed, 20 May 2009 09:44:05 +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 n4K7i5Pt009203; Wed, 20 May 2009 07:44:05 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); Wed, 20 May 2009 09:44:05 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 May 2009 09:44:04 +0200 From: JP Vasseur To: Theodore Zahariadis In-Reply-To: <4345CED632CC439D81F06EF5724F0864@sVAIO> X-Priority: 3 References: <4345CED632CC439D81F06EF5724F0864@sVAIO> Message-Id: <5B7F1002-2E08-4BA3-9BC1-11AB10B69867@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 20 May 2009 09:44:03 +0200 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 20 May 2009 07:44:04.0565 (UTC) FILETIME=[BFB9F050:01C9D91E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6254; t=1242805445; x=1243669445; 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=20DT=20update=20--=20MUSTs=20-=20energy=2 0for=20link=20metric?=20(JP=20Vasseur) |Sender:=20; bh=S7G4aW3X6D6DQDn7/zhRiZIy4nI2Y56OoPK44Ke6q3g=; b=l+Rye2XYjUt5s0eRg5+Z83fyBeuR+3DBrX433iahmCJZjiStvyYKxw0HlL LeByAzjxRsyCmPjoBpaPLESLNVehJ9kpNrhBqr/JIQNPxkWshp/+04+jNDRs KGwnoeCCx4; 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] DT update -- MUSTs - energy for link metric? (JP Vasseur) 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, 20 May 2009 07:42:36 -0000 Hi, On May 20, 2009, at 9:21 AM, Theodore Zahariadis wrote: > Dear Tim, Alex, > > Maybe the question could be asked somewhat differently... > Maybe something like: > "Is the network survivability a routing protocol requirement or a > feature?" > or > "Is a routing protocol that can achieve longer lifetime for the > network > (as a whole) better than a protocol that exhausts selectively some > nodes?" > > If energy is not taken into account and a node has many data to send, > then the nodes in a fixed path will be exhausted. On the other hand, > if energy > is a metric, the path will change (maybe it will not be always the > optimal one), but the energy will be reduced progressively. > Moreover, if > the nodes have a method to create some energy (e.g. a tiny > photovoltaic cell, > or windmill) the network may survive. That was exactly my point. Energy as a NODE metric is a definite MUST. I was highly questioning the need for energy link metric. A link may require x more times energy that another link to transmit but if it is connected to a main power node, then you would certainly favor that link. As pointed out earlier in a previous email, energy link would in my opinion make sense if nodes are homogenous, which is not our cases, thus my argument for only using node energy metric. Makes sense ? > > We have done a number of simulations in JSIM trying to combine > routing and > trust. It seams that even in a trust framework, taking into account > energy metrics > may drastically increase the network lifetime. Sure. By the way, as general comment do not hesitate to send pointer to simulations. Although they cannot be used to demonstrate that something works, that can provide interesting datapoint. > > Of course all these apply to homogeneous nodes. Here it is. > If the nodes are heterogeneous > calculating the optimal energy metric may be too hard (may not worth). > On the other hand, there may be some thresholds put e.g. "if the > remaining > energy of node "a" is less than "x", avoid it, unless it is the node > with the maximum > energy in the neighborhood". > Yes, and we use node energy metrics for that matter. Thanks. JP. > BR, > Theodore > >> Date: Tue, 19 May 2009 14:38:06 +0200 >> From: JP Vasseur >> Subject: Re: [Roll] DT update -- MUSTs - energy for link metric? >> To: Alexandru Petrescu >> Cc: ROLL WG , dtroll@external.cisco.com >> Message-ID: >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; >> delsp=yes >> >> but again, this does not really answer *the* question: why should the >> routing protocol take link energy into account during path >> computation ? >> >> On May 19, 2009, at 12:11 PM, Alexandru Petrescu wrote: >> >>> JP Vasseur a ?crit : >>>> Hi Alex, >>>> On May 15, 2009, at 8:39 AM, Alexandru Petrescu wrote: >>>>> Tim, thanks for the update - that's hard work. >>>>> A side remark about one particular interest: the req list doesn't >>>>> seem to include a metric for energy of the link: energy necessary >>>>> to send a packet on the link, or energy radiated in the air, or >>>>> similar. >>>>> Or I can't find it - is there one? >>>>> I do find reqs for energy as constraints of the node device: level >>>>> of energy, energy of the node, power available, power budget, etc. >>>>> Or is the link energy completely out of scope? >>>> It would be useful to know what the WG thinks about link energy >>>> metrics. >>> >>> I am very interested on all WG oppinions on link energy metric. >>> >>>> Here is my take on it. Node energy metric is undoubtedly needed, in >>>> many cases, one may want to avoid a node that is battery operated >>>> or >>>> running our of battery, we are all in sync with this. Now with >>>> regards to link energy metrics, this is by far less obvious. Why >>>> would you care knowing that the energy required to transmit 1 bit >>>> is >>>> X over a link L1 and 2*X over a link L2? >>> >>> My first impression: because typical cost metrics are _link_ >>> metrics, not node metrics - the hop count is the number of links, >>> not of >>> nodes (a 3 node topology uses a 2 hop count metric - the number of >>> links). >>> >>> More often than not the parameters advertised in Router >>> Advertisements >>> of OSPF and ICMP are link parameters: link MTU, link prefix. >>> >>> It sounds attractive to reuse the same link concept for energy. >>> >>> Prior publications making think link energy is relevant: >>> >>> Callaway, E., "Secure Low-Power Operation of Wireless >>> Sensor Networks", Intelligent Systems, January 2004. >>> >>> Mentions transmission of a packet with a particular 15.4 transceiver >>> to >>> be 56 micro-Joules, and is computed relative to the number of bits >>> transmitted. >>> >>> L. Li, J-Y. Jalpern, ICC'01, Finland., "Minimum-Energy >>> Mobile Wireless Networks Revisited", June 2001. >>> >>> Explicitely assumes that "a transmission between node u and v takes >>> power p(uv) [...]". >>> >>> IEEE Global Telecommunications Conference, Globecom '03, >>> "Measurement and Characterization of Link Quality >>> Metrics >>> in Energy Constrained Wireless Sensor Networks", 2003. >>> >>> Mentions that the energy to transmit a packet is proportional to >>> 'link inefficiency', and this latter (not the energy) is defined >>> as a >>> metric. >>> >>>> It might very well be that the node connected to L2 has no energy >>>> constraint by contrast with the node connected to L1 being battery >>>> operated. >>> >>> There seems indeed to be a decoupling between the energy left to a >>> node, its battery level, its consumption patterns - and the energy >>> needed to send an MTU-sized packet on a link. >>> >>> They could be both needed, I can't easily say, because the >>> NP-completeness issue: routing according to metric "link-energy" >>> _and_ >>> metric "node-energy" may be NP-hard to do. >>> >>> Alex > > From alexandru.petrescu@gmail.com Wed May 20 03:06: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 81C963A6B60 for ; Wed, 20 May 2009 03:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_53=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 Wkv6Cya0M1sZ for ; Wed, 20 May 2009 03:06:13 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 76DCF3A6AD7 for ; Wed, 20 May 2009 03:05:50 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n4KA7NxM024595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 May 2009 12:07:23 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n4KA7Mdp021668; Wed, 20 May 2009 12:07:22 +0200 (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 n4KA7MdY028469; Wed, 20 May 2009 12:07:22 +0200 Message-ID: <4A13D65A.3000205@gmail.com> Date: Wed, 20 May 2009 12:07:22 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: JP Vasseur References: <4345CED632CC439D81F06EF5724F0864@sVAIO> <5B7F1002-2E08-4BA3-9BC1-11AB10B69867@cisco.com> In-Reply-To: <5B7F1002-2E08-4BA3-9BC1-11AB10B69867@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] DT update -- MUSTs - energy for link metric? (JP Vasseur) 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, 20 May 2009 10:06:14 -0000 JP Vasseur a écrit : > Hi, > > On May 20, 2009, at 9:21 AM, Theodore Zahariadis wrote: > >> Dear Tim, Alex, >> >> Maybe the question could be asked somewhat differently... Maybe >> something like: "Is the network survivability a routing protocol >> requirement or a feature?" or "Is a routing protocol that can >> achieve longer lifetime for the network (as a whole) better than a >> protocol that exhausts selectively some nodes?" >> >> If energy is not taken into account and a node has many data to >> send, then the nodes in a fixed path will be exhausted. On the >> other hand, if energy is a metric, the path will change (maybe it >> will not be always the optimal one), but the energy will be reduced >> progressively. Moreover, if the nodes have a method to create some >> energy (e.g. a tiny photovoltaic cell, or windmill) the network >> may survive. > > That was exactly my point. Energy as a NODE metric is a definite > MUST. I was highly questioning the need for energy link metric. A > link may require x more times energy that another link to transmit > but if it is connected to a main power node, then you would certainly > favor that link. It's not that obvious, because a link itself is not connected to a single power supply, it's at least two - one for each node on the link. What if these 2 supplies are totally different: one is mains 220V the other is battery cell. Would the routing protocol still favor that link? Also the money cost: sending a packet on higher-energy link is supposedly costlier than sending on a lower-energy link, regardless of the power supply being a mains supply (220V) or battery cell. Alex > > As pointed out earlier in a previous email, energy link would in my > opinion make sense if nodes are homogenous, which is not our cases, > thus my argument for only using node energy metric. Makes sense ? > >> >> We have done a number of simulations in JSIM trying to combine >> routing and trust. It seams that even in a trust framework, taking >> into account energy metrics may drastically increase the network >> lifetime. > > Sure. By the way, as general comment do not hesitate to send pointer > to simulations. Although they cannot be used to demonstrate that > something works, that can provide interesting datapoint. > >> >> Of course all these apply to homogeneous nodes. > > Here it is. > >> If the nodes are heterogeneous calculating the optimal energy >> metric may be too hard (may not worth). On the other hand, there >> may be some thresholds put e.g. "if the remaining energy of node >> "a" is less than "x", avoid it, unless it is the node with the >> maximum energy in the neighborhood". >> > > Yes, and we use node energy metrics for that matter. > > Thanks. > > JP. > >> BR, Theodore >> >>> Date: Tue, 19 May 2009 14:38:06 +0200 From: JP Vasseur >>> Subject: Re: [Roll] DT update -- MUSTs - >>> energy for link metric? To: Alexandru Petrescu >>> Cc: ROLL WG , >>> dtroll@external.cisco.com Message-ID: >>> Content-Type: >>> text/plain; charset=ISO-8859-1; format=flowed; delsp=yes >>> >>> but again, this does not really answer *the* question: why should >>> the routing protocol take link energy into account during path >>> computation ? >>> >>> On May 19, 2009, at 12:11 PM, Alexandru Petrescu wrote: >>> >>>> JP Vasseur a ?crit : >>>>> Hi Alex, On May 15, 2009, at 8:39 AM, Alexandru Petrescu >>>>> wrote: >>>>>> Tim, thanks for the update - that's hard work. A side >>>>>> remark about one particular interest: the req list doesn't >>>>>> seem to include a metric for energy of the link: energy >>>>>> necessary to send a packet on the link, or energy radiated >>>>>> in the air, or similar. Or I can't find it - is there one? >>>>>> I do find reqs for energy as constraints of the node >>>>>> device: level of energy, energy of the node, power >>>>>> available, power budget, etc. Or is the link energy >>>>>> completely out of scope? >>>>> It would be useful to know what the WG thinks about link >>>>> energy metrics. >>>> >>>> I am very interested on all WG oppinions on link energy metric. >>>> >>>> >>>> >>>>> Here is my take on it. Node energy metric is undoubtedly >>>>> needed, in many cases, one may want to avoid a node that is >>>>> battery operated or running our of battery, we are all in >>>>> sync with this. Now with regards to link energy metrics, this >>>>> is by far less obvious. Why would you care knowing that the >>>>> energy required to transmit 1 bit is X over a link L1 and 2*X >>>>> over a link L2? >>>> >>>> My first impression: because typical cost metrics are _link_ >>>> metrics, not node metrics - the hop count is the number of >>>> links, not of nodes (a 3 node topology uses a 2 hop count >>>> metric - the number of links). >>>> >>>> More often than not the parameters advertised in Router >>>> Advertisements of OSPF and ICMP are link parameters: link MTU, >>>> link prefix. >>>> >>>> It sounds attractive to reuse the same link concept for energy. >>>> >>>> >>>> >>>> Prior publications making think link energy is relevant: >>>> >>>> Callaway, E., "Secure Low-Power Operation of Wireless Sensor >>>> Networks", Intelligent Systems, January 2004. >>>> >>>> Mentions transmission of a packet with a particular 15.4 >>>> transceiver to be 56 micro-Joules, and is computed relative to >>>> the number of bits transmitted. >>>> >>>> L. Li, J-Y. Jalpern, ICC'01, Finland., "Minimum-Energy Mobile >>>> Wireless Networks Revisited", June 2001. >>>> >>>> Explicitely assumes that "a transmission between node u and v >>>> takes power p(uv) [...]". >>>> >>>> IEEE Global Telecommunications Conference, Globecom '03, >>>> "Measurement and Characterization of Link Quality Metrics in >>>> Energy Constrained Wireless Sensor Networks", 2003. >>>> >>>> Mentions that the energy to transmit a packet is proportional >>>> to 'link inefficiency', and this latter (not the energy) is >>>> defined as a metric. >>>> >>>>> It might very well be that the node connected to L2 has no >>>>> energy constraint by contrast with the node connected to L1 >>>>> being battery operated. >>>> >>>> There seems indeed to be a decoupling between the energy left >>>> to a node, its battery level, its consumption patterns - and >>>> the energy needed to send an MTU-sized packet on a link. >>>> >>>> They could be both needed, I can't easily say, because the >>>> NP-completeness issue: routing according to metric >>>> "link-energy" _and_ metric "node-energy" may be NP-hard to do. >>>> >>>> Alex >> >> > > From zahariad@teihal.gr Wed May 20 06:17: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 19D4A3A6CD9 for ; Wed, 20 May 2009 06:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, J_CHICKENPOX_53=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 MwaIA7ocChF1 for ; Wed, 20 May 2009 06:17:38 -0700 (PDT) Received: from teihal.gr (mail.teihal.gr [195.130.65.41]) by core3.amsl.com (Postfix) with ESMTP id D67933A6810 for ; Wed, 20 May 2009 06:17:36 -0700 (PDT) X-MDAV-Processed: teihal.gr, Wed, 20 May 2009 16:19:23 +0300 Received: from sVAIO by teihal.gr (MDaemon PRO v10.0.1) with ESMTP id md50005923686.msg for ; Wed, 20 May 2009 16:19:22 +0300 X-Spam-Processed: teihal.gr, Wed, 20 May 2009 16:19:22 +0300 (not processed: message from valid local sender) X-Authenticated-Sender: zahariad@teihal.gr X-MDRemoteIP: 172.20.1.83 X-Return-Path: zahariad@teihal.gr X-Envelope-From: zahariad@teihal.gr X-MDaemon-Deliver-To: roll@ietf.org Message-ID: <975FDB9E36974B94AB68E7437B83003A@sVAIO> From: "Theodore Zahariadis" To: "Alexandru Petrescu" , "JP Vasseur" References: <4345CED632CC439D81F06EF5724F0864@sVAIO> <5B7F1002-2E08-4BA3-9BC1-11AB10B69867@cisco.com> <4A13D65A.3000205@gmail.com> In-Reply-To: <4A13D65A.3000205@gmail.com> Date: Wed, 20 May 2009 16:19:04 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: roll@ietf.org Subject: Re: [Roll] [SPAM] Re: DT update -- MUSTs - energy for link metric? (JP Vasseur) 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, 20 May 2009 13:17:40 -0000 Dear Alex, ----- Original Message ----- From: "Alexandru Petrescu" To: "JP Vasseur" Cc: "Theodore Zahariadis" ; ; Sent: Wednesday, May 20, 2009 1:07 PM Subject: [SPAM] Re: DT update -- MUSTs - energy for link metric? (JP Vasseur) > JP Vasseur a écrit : >> Hi, >> >> On May 20, 2009, at 9:21 AM, Theodore Zahariadis wrote: >> >>> Dear Tim, Alex, >>> >>> Maybe the question could be asked somewhat differently... Maybe >>> something like: "Is the network survivability a routing protocol >>> requirement or a feature?" or "Is a routing protocol that can achieve >>> longer lifetime for the network (as a whole) better than a protocol that >>> exhausts selectively some nodes?" >>> >>> If energy is not taken into account and a node has many data to send, >>> then the nodes in a fixed path will be exhausted. On the other hand, if >>> energy is a metric, the path will change (maybe it will not be always >>> the optimal one), but the energy will be reduced >>> progressively. Moreover, if the nodes have a method to create some >>> energy (e.g. a tiny photovoltaic cell, or windmill) the network >>> may survive. >> >> That was exactly my point. Energy as a NODE metric is a definite MUST. I >> was highly questioning the need for energy link metric. A link may >> require x more times energy that another link to transmit but if it is >> connected to a main power node, then you would certainly >> favor that link. > > It's not that obvious, because a link itself is not connected to a > single power supply, it's at least two - one for each node on the link. > > What if these 2 supplies are totally different: one is mains 220V the > other is battery cell. Would the routing protocol still favor that link? > > Also the money cost: sending a packet on higher-energy link is > supposedly costlier than sending on a lower-energy link, regardless of > the power supply being a mains supply (220V) or battery cell. >From what you say, I think it is definite that energy is a routing parameter. Maybe the function has to be decided (technological, economical, ...) or it may be a weighted factor (based on the application the weight may change according to the value that we want to give to the energy metric), but for sure energy can't be ignored. BR, Theodore > > Alex > > >> >> As pointed out earlier in a previous email, energy link would in my >> opinion make sense if nodes are homogenous, which is not our cases, thus >> my argument for only using node energy metric. Makes sense ? >> >>> >>> We have done a number of simulations in JSIM trying to combine routing >>> and trust. It seams that even in a trust framework, taking into account >>> energy metrics may drastically increase the network lifetime. >> >> Sure. By the way, as general comment do not hesitate to send pointer to >> simulations. Although they cannot be used to demonstrate that something >> works, that can provide interesting datapoint. >> >>> >>> Of course all these apply to homogeneous nodes. >> >> Here it is. >> >>> If the nodes are heterogeneous calculating the optimal energy metric may >>> be too hard (may not worth). On the other hand, there may be some >>> thresholds put e.g. "if the remaining energy of node "a" is less than >>> "x", avoid it, unless it is the node with the maximum energy in the >>> neighborhood". >>> >> >> Yes, and we use node energy metrics for that matter. >> >> Thanks. >> >> JP. >> >>> BR, Theodore >>> >>>> Date: Tue, 19 May 2009 14:38:06 +0200 From: JP Vasseur >>>> Subject: Re: [Roll] DT update -- MUSTs - energy >>>> for link metric? To: Alexandru Petrescu >>>> Cc: ROLL WG , dtroll@external.cisco.com Message-ID: >>>> Content-Type: >>>> text/plain; charset=ISO-8859-1; format=flowed; delsp=yes >>>> >>>> but again, this does not really answer *the* question: why should >>>> the routing protocol take link energy into account during path >>>> computation ? >>>> >>>> On May 19, 2009, at 12:11 PM, Alexandru Petrescu wrote: >>>> >>>>> JP Vasseur a ?crit : >>>>>> Hi Alex, On May 15, 2009, at 8:39 AM, Alexandru Petrescu wrote: >>>>>>> Tim, thanks for the update - that's hard work. A side remark about >>>>>>> one particular interest: the req list doesn't >>>>>>> seem to include a metric for energy of the link: energy necessary >>>>>>> to send a packet on the link, or energy radiated in the air, or >>>>>>> similar. Or I can't find it - is there one? >>>>>>> I do find reqs for energy as constraints of the node device: level >>>>>>> of energy, energy of the node, power available, power budget, etc. >>>>>>> Or is the link energy completely out of scope? >>>>>> It would be useful to know what the WG thinks about link energy >>>>>> metrics. >>>>> >>>>> I am very interested on all WG oppinions on link energy metric. >>>>> >>>>> >>>>> >>>>>> Here is my take on it. Node energy metric is undoubtedly needed, in >>>>>> many cases, one may want to avoid a node that is battery operated or >>>>>> running our of battery, we are all in sync with this. Now with >>>>>> regards to link energy metrics, this >>>>>> is by far less obvious. Why would you care knowing that the energy >>>>>> required to transmit 1 bit is X over a link L1 and 2*X >>>>>> over a link L2? >>>>> >>>>> My first impression: because typical cost metrics are _link_ metrics, >>>>> not node metrics - the hop count is the number of links, not of nodes >>>>> (a 3 node topology uses a 2 hop count metric - the number of links). >>>>> >>>>> More often than not the parameters advertised in Router Advertisements >>>>> of OSPF and ICMP are link parameters: link MTU, link prefix. >>>>> >>>>> It sounds attractive to reuse the same link concept for energy. >>>>> >>>>> >>>>> >>>>> Prior publications making think link energy is relevant: >>>>> >>>>> Callaway, E., "Secure Low-Power Operation of Wireless Sensor >>>>> Networks", Intelligent Systems, January 2004. >>>>> >>>>> Mentions transmission of a packet with a particular 15.4 transceiver >>>>> to be 56 micro-Joules, and is computed relative to the number of bits >>>>> transmitted. >>>>> >>>>> L. Li, J-Y. Jalpern, ICC'01, Finland., "Minimum-Energy Mobile Wireless >>>>> Networks Revisited", June 2001. >>>>> >>>>> Explicitely assumes that "a transmission between node u and v takes >>>>> power p(uv) [...]". >>>>> >>>>> IEEE Global Telecommunications Conference, Globecom '03, "Measurement >>>>> and Characterization of Link Quality Metrics in Energy Constrained >>>>> Wireless Sensor Networks", 2003. >>>>> >>>>> Mentions that the energy to transmit a packet is proportional to 'link >>>>> inefficiency', and this latter (not the energy) is defined as a >>>>> metric. >>>>> >>>>>> It might very well be that the node connected to L2 has no energy >>>>>> constraint by contrast with the node connected to L1 being battery >>>>>> operated. >>>>> >>>>> There seems indeed to be a decoupling between the energy left to a >>>>> node, its battery level, its consumption patterns - and the energy >>>>> needed to send an MTU-sized packet on a link. >>>>> >>>>> They could be both needed, I can't easily say, because the >>>>> NP-completeness issue: routing according to metric "link-energy" _and_ >>>>> metric "node-energy" may be NP-hard to do. >>>>> >>>>> Alex >>> >>> >> >> > > > > From alexandru.petrescu@gmail.com Wed May 20 06:54: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 0A5FB3A6D02 for ; Wed, 20 May 2009 06:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.842 X-Spam-Level: X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_53=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 kpImNXjNWwVe for ; Wed, 20 May 2009 06:54:27 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 52AAE3A6D1A for ; Wed, 20 May 2009 06:54:27 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n4KDrhUV018236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 May 2009 15:53:44 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n4KDttMq003553; Wed, 20 May 2009 15:55:56 +0200 (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 n4KDttNG030769; Wed, 20 May 2009 15:55:55 +0200 Message-ID: <4A140BEB.9070905@gmail.com> Date: Wed, 20 May 2009 15:55:55 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Theodore Zahariadis References: <4345CED632CC439D81F06EF5724F0864@sVAIO> <5B7F1002-2E08-4BA3-9BC1-11AB10B69867@cisco.com> <4A13D65A.3000205@gmail.com> <975FDB9E36974B94AB68E7437B83003A@sVAIO> In-Reply-To: <975FDB9E36974B94AB68E7437B83003A@sVAIO> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] [SPAM] Re: DT update -- MUSTs - energy for link metric? (JP Vasseur) 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, 20 May 2009 13:54:29 -0000 Theodore Zahariadis a écrit : > Dear Alex, > > ----- Original Message ----- From: "Alexandru Petrescu" > To: "JP Vasseur" > Cc: "Theodore Zahariadis" ; > ; Sent: Wednesday, May > 20, 2009 1:07 PM Subject: [SPAM] Re: DT update -- MUSTs - energy for > link metric? (JP Vasseur) > > >> JP Vasseur a écrit : >>> Hi, >>> >>> On May 20, 2009, at 9:21 AM, Theodore Zahariadis wrote: >>> >>>> Dear Tim, Alex, >>>> >>>> Maybe the question could be asked somewhat differently... Maybe >>>> something like: "Is the network survivability a routing >>>> protocol requirement or a feature?" or "Is a routing protocol >>>> that can achieve longer lifetime for the network (as a whole) >>>> better than a protocol that exhausts selectively some nodes?" >>>> >>>> If energy is not taken into account and a node has many data to >>>> send, then the nodes in a fixed path will be exhausted. On the >>>> other hand, if energy is a metric, the path will change (maybe >>>> it will not be always the optimal one), but the energy will be >>>> reduced progressively. Moreover, if the nodes have a method to >>>> create some energy (e.g. a tiny photovoltaic cell, or windmill) >>>> the network may survive. >>> >>> That was exactly my point. Energy as a NODE metric is a definite >>> MUST. I was highly questioning the need for energy link metric. >>> A link may require x more times energy that another link to >>> transmit but if it is connected to a main power node, then you >>> would certainly favor that link. >> >> It's not that obvious, because a link itself is not connected to a >> single power supply, it's at least two - one for each node on the >> link. >> >> What if these 2 supplies are totally different: one is mains 220V >> the other is battery cell. Would the routing protocol still favor >> that link? >> >> Also the money cost: sending a packet on higher-energy link is >> supposedly costlier than sending on a lower-energy link, regardless >> of the power supply being a mains supply (220V) or battery cell. > > From what you say, I think it is definite that energy is a routing > parameter. Maybe the function has to be decided (technological, > economical, ...) or it may be a weighted factor (based on the > application the weight may change according to the value that we want > to give to the energy metric), but for sure energy can't be ignored. Theodore, I tend to agree energy is a good candidate to make a metric for a routing protocol. Link metric or node metric - that is a question apparently difficult to converge on. Alex > > BR, Theodore > >> >> Alex >> >> >>> >>> As pointed out earlier in a previous email, energy link would in >>> my opinion make sense if nodes are homogenous, which is not our >>> cases, thus my argument for only using node energy metric. Makes >>> sense ? >>> >>>> >>>> We have done a number of simulations in JSIM trying to combine >>>> routing and trust. It seams that even in a trust framework, >>>> taking into account energy metrics may drastically increase the >>>> network lifetime. >>> >>> Sure. By the way, as general comment do not hesitate to send >>> pointer to simulations. Although they cannot be used to >>> demonstrate that something works, that can provide interesting >>> datapoint. >>> >>>> >>>> Of course all these apply to homogeneous nodes. >>> >>> Here it is. >>> >>>> If the nodes are heterogeneous calculating the optimal energy >>>> metric may be too hard (may not worth). On the other hand, >>>> there may be some thresholds put e.g. "if the remaining energy >>>> of node "a" is less than "x", avoid it, unless it is the node >>>> with the maximum energy in the neighborhood". >>>> >>> >>> Yes, and we use node energy metrics for that matter. >>> >>> Thanks. >>> >>> JP. >>> >>>> BR, Theodore >>>> >>>>> Date: Tue, 19 May 2009 14:38:06 +0200 From: JP Vasseur >>>>> Subject: Re: [Roll] DT update -- MUSTs - >>>>> energy for link metric? To: Alexandru Petrescu >>>>> Cc: ROLL WG , >>>>> dtroll@external.cisco.com Message-ID: >>>>> >>>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; >>>>> delsp=yes >>>>> >>>>> but again, this does not really answer *the* question: why >>>>> should the routing protocol take link energy into account >>>>> during path computation ? >>>>> >>>>> On May 19, 2009, at 12:11 PM, Alexandru Petrescu wrote: >>>>> >>>>>> JP Vasseur a ?crit : >>>>>>> Hi Alex, On May 15, 2009, at 8:39 AM, Alexandru Petrescu >>>>>>> wrote: >>>>>>>> Tim, thanks for the update - that's hard work. A side >>>>>>>> remark about one particular interest: the req list >>>>>>>> doesn't seem to include a metric for energy of the >>>>>>>> link: energy necessary to send a packet on the link, or >>>>>>>> energy radiated in the air, or similar. Or I can't find >>>>>>>> it - is there one? I do find reqs for energy as >>>>>>>> constraints of the node device: level of energy, energy >>>>>>>> of the node, power available, power budget, etc. Or is >>>>>>>> the link energy completely out of scope? >>>>>>> It would be useful to know what the WG thinks about link >>>>>>> energy metrics. >>>>>> >>>>>> I am very interested on all WG oppinions on link energy >>>>>> metric. >>>>>> >>>>>> >>>>>> >>>>>>> Here is my take on it. Node energy metric is undoubtedly >>>>>>> needed, in many cases, one may want to avoid a node that >>>>>>> is battery operated or running our of battery, we are all >>>>>>> in sync with this. Now with regards to link energy >>>>>>> metrics, this is by far less obvious. Why would you care >>>>>>> knowing that the energy required to transmit 1 bit is X >>>>>>> over a link L1 and 2*X over a link L2? >>>>>> >>>>>> My first impression: because typical cost metrics are >>>>>> _link_ metrics, not node metrics - the hop count is the >>>>>> number of links, not of nodes (a 3 node topology uses a 2 >>>>>> hop count metric - the number of links). >>>>>> >>>>>> More often than not the parameters advertised in Router >>>>>> Advertisements of OSPF and ICMP are link parameters: link >>>>>> MTU, link prefix. >>>>>> >>>>>> It sounds attractive to reuse the same link concept for >>>>>> energy. >>>>>> >>>>>> >>>>>> >>>>>> Prior publications making think link energy is relevant: >>>>>> >>>>>> Callaway, E., "Secure Low-Power Operation of Wireless >>>>>> Sensor Networks", Intelligent Systems, January 2004. >>>>>> >>>>>> Mentions transmission of a packet with a particular 15.4 >>>>>> transceiver to be 56 micro-Joules, and is computed relative >>>>>> to the number of bits transmitted. >>>>>> >>>>>> L. Li, J-Y. Jalpern, ICC'01, Finland., "Minimum-Energy >>>>>> Mobile Wireless Networks Revisited", June 2001. >>>>>> >>>>>> Explicitely assumes that "a transmission between node u and >>>>>> v takes power p(uv) [...]". >>>>>> >>>>>> IEEE Global Telecommunications Conference, Globecom '03, >>>>>> "Measurement and Characterization of Link Quality Metrics >>>>>> in Energy Constrained Wireless Sensor Networks", 2003. >>>>>> >>>>>> Mentions that the energy to transmit a packet is >>>>>> proportional to 'link inefficiency', and this latter (not >>>>>> the energy) is defined as a metric. >>>>>> >>>>>>> It might very well be that the node connected to L2 has >>>>>>> no energy constraint by contrast with the node connected >>>>>>> to L1 being battery operated. >>>>>> >>>>>> There seems indeed to be a decoupling between the energy >>>>>> left to a node, its battery level, its consumption patterns >>>>>> - and the energy needed to send an MTU-sized packet on a >>>>>> link. >>>>>> >>>>>> They could be both needed, I can't easily say, because the >>>>>> NP-completeness issue: routing according to metric >>>>>> "link-energy" _and_ metric "node-energy" may be NP-hard to >>>>>> do. >>>>>> >>>>>> Alex >>>> >>>> >>> >>> >> >> >> >> > > > From gnawali@gmail.com Wed May 20 07:22: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 ACFA53A69C2 for ; Wed, 20 May 2009 07:22:39 -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 mBu1nD5+qsWU for ; Wed, 20 May 2009 07:22:38 -0700 (PDT) Received: from mail-pz0-f179.google.com (mail-pz0-f179.google.com [209.85.222.179]) by core3.amsl.com (Postfix) with ESMTP id CEDC73A6801 for ; Wed, 20 May 2009 07:22:38 -0700 (PDT) Received: by pzk9 with SMTP id 9so159891pzk.29 for ; Wed, 20 May 2009 07:24: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:content-transfer-encoding; bh=jgR0M8IkVi0X6g/fHkV9gb853QeumO5oMM/rTbsXNHU=; b=Tm0iYRg2kLLdwKgycQq+mvvmolTrKXU6hcMxaDBcNtH7JxoWV7KLZb/AU8pBSOKORH BKhwwvz5buvvohvcBdYnn92auVbCxN7RFsvVXVSRa3JHK2I6jSyJ2c5qzP6s48bUJJfe 9Frid0cZBsV/XLCG0l4p5XiyCK/ILNogGERww= 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 :content-transfer-encoding; b=Qy3k301wz2kU5xtTfZi529hnr7dZEPpxzDXi4zzAMuPeNdGIm/Y+GFtZ/G7MwrxiA6 p7itMgYtiQeILFYlNiA6iRIloT5LBgAXkEBXSdd91UTbxaXG4ASWqj2z8xbeCW7YCYmU RcVT03KrdJssav1knhABRphXSA0ME/8euf9p0= MIME-Version: 1.0 Sender: gnawali@gmail.com Received: by 10.142.153.8 with SMTP id a8mr474300wfe.94.1242829453023; Wed, 20 May 2009 07:24:13 -0700 (PDT) In-Reply-To: <4A140BEB.9070905@gmail.com> References: <4345CED632CC439D81F06EF5724F0864@sVAIO> <5B7F1002-2E08-4BA3-9BC1-11AB10B69867@cisco.com> <4A13D65A.3000205@gmail.com> <975FDB9E36974B94AB68E7437B83003A@sVAIO> <4A140BEB.9070905@gmail.com> Date: Wed, 20 May 2009 07:24:13 -0700 X-Google-Sender-Auth: af0830184a8cb367 Message-ID: From: Omprakash Gnawali To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] [SPAM] Re: DT update -- MUSTs - energy for link metric? (JP Vasseur) 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, 20 May 2009 14:22:39 -0000 On Wed, May 20, 2009 at 6:55 AM, Alexandru Petrescu wrote: > Theodore Zahariadis a =E9crit : >> >> Dear Alex, >> >> ----- Original Message ----- From: "Alexandru Petrescu" >> To: "JP Vasseur" Cc: >> "Theodore Zahariadis" ; ; >> Sent: Wednesday, May >> 20, 2009 1:07 PM Subject: [SPAM] Re: DT update -- MUSTs - energy for >> link metric? (JP Vasseur) >> >> >>> JP Vasseur a =E9crit : >>>> >>>> Hi, >>>> >>>> On May 20, 2009, at 9:21 AM, Theodore Zahariadis wrote: >>>> >>>>> Dear Tim, Alex, >>>>> >>>>> Maybe the question could be asked somewhat differently... Maybe >>>>> =A0something like: "Is the network survivability a routing >>>>> protocol requirement or a feature?" or "Is a routing protocol >>>>> that can achieve longer lifetime for the network (as a whole) >>>>> better than a protocol that exhausts selectively some nodes?" >>>>> >>>>> If energy is not taken into account and a node has many data to >>>>> =A0send, then the nodes in a fixed path will be exhausted. On the >>>>> other hand, if energy is a metric, the path will change (maybe >>>>> it will not be always the optimal one), but the energy will be >>>>> reduced progressively. Moreover, if the nodes have a method to >>>>> create some energy (e.g. a tiny photovoltaic cell, or windmill) >>>>> the network may survive. >>>> >>>> That was exactly my point. Energy as a NODE metric is a definite >>>> =A0MUST. I was highly questioning the need for energy link metric. >>>> A link may require x more times energy that another link to >>>> transmit but if it is connected to a main power node, then you >>>> would certainly favor that link. >>> >>> It's not that obvious, because a link itself is not connected to a sing= le >>> power supply, it's at least two - one for each node on the >>> link. >>> >>> What if these 2 supplies are totally different: one is mains 220V >>> the other is battery cell. =A0Would the routing protocol still favor >>> that link? >>> >>> Also the money cost: sending a packet on higher-energy link is supposed= ly >>> costlier than sending on a lower-energy link, regardless >>> of the power supply being a mains supply (220V) or battery cell. >> >> From what you say, I think it is definite that energy is a routing >> parameter. Maybe the function has to be decided (technological, >> economical, ...) or it may be a weighted factor (based on the >> application the weight may change according to the value that we want >> to give to the energy metric), but for sure energy can't be ignored. > > Theodore, I tend to agree energy is a good candidate to make a metric for= a > routing protocol. > > Link metric or node metric - that is a question apparently difficult to > converge on. We can have both if the two are needed because their purpose would be different. I have seen work on selecting different link depending on their energy characteristics in the context of wireless radios (think cellphones) but not in the context of the type of networks we are talking about. - om_p From jvasseur@cisco.com Wed May 20 07:36: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 835923A69D7 for ; Wed, 20 May 2009 07:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.178 X-Spam-Level: X-Spam-Status: No, score=-8.178 tagged_above=-999 required=5 tests=[AWL=-1.579, 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 B5347v1UgAvJ for ; Wed, 20 May 2009 07:36:29 -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 8843C28C0DF for ; Wed, 20 May 2009 07:36:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,221,1241395200"; d="scan'208";a="163344063" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-3.cisco.com with ESMTP; 20 May 2009 14:37:34 +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 n4KEbXbv009271; Wed, 20 May 2009 16:37:33 +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 n4KEbX2O026433; Wed, 20 May 2009 14:37:33 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); Wed, 20 May 2009 16:37:33 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 May 2009 16:37:33 +0200 Message-Id: <0885DBE3-0DF9-403A-A8F5-BA7B3CF637C5@cisco.com> From: JP Vasseur To: Omprakash Gnawali In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 20 May 2009 16:37:32 +0200 References: <4345CED632CC439D81F06EF5724F0864@sVAIO> <5B7F1002-2E08-4BA3-9BC1-11AB10B69867@cisco.com> <4A13D65A.3000205@gmail.com> <975FDB9E36974B94AB68E7437B83003A@sVAIO> <4A140BEB.9070905@gmail.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 20 May 2009 14:37:33.0342 (UTC) FILETIME=[82E8E3E0:01C9D958] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3685; t=1242830253; x=1243694253; 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]=20[SPAM]=20Re=3A=20DT=20update=2 0--=20MUSTs=20-=20energy=20for=20link=20metric?=20(JP=20Vass eur) |Sender:=20; bh=ZA46ZVoexRnOntuhV/29J+eeOam2SrrAs6jfuznlN1A=; b=dOMQAn0X6JVPynCO4cSAJEHMluLHRugvC8yx4eEsQ04dSwLTHrl0U69gUP wK0kemqelyILZISjSwP7OCjrGUK/Ko44bVlyqcenu/kGQIvBeHZIJxbhIAyu VLUkeDqej+; 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] [SPAM] Re: DT update -- MUSTs - energy for link metric? (JP Vasseur) 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, 20 May 2009 14:36:30 -0000 On May 20, 2009, at 4:24 PM, Omprakash Gnawali wrote: > On Wed, May 20, 2009 at 6:55 AM, Alexandru Petrescu > wrote: >> Theodore Zahariadis a =E9crit : >>> >>> Dear Alex, >>> >>> ----- Original Message ----- From: "Alexandru Petrescu" >>> To: "JP Vasseur" =20 >>> Cc: >>> "Theodore Zahariadis" ; = >> >; >>> Sent: Wednesday, May >>> 20, 2009 1:07 PM Subject: [SPAM] Re: DT update -- MUSTs - energy for >>> link metric? (JP Vasseur) >>> >>> >>>> JP Vasseur a =E9crit : >>>>> >>>>> Hi, >>>>> >>>>> On May 20, 2009, at 9:21 AM, Theodore Zahariadis wrote: >>>>> >>>>>> Dear Tim, Alex, >>>>>> >>>>>> Maybe the question could be asked somewhat differently... Maybe >>>>>> something like: "Is the network survivability a routing >>>>>> protocol requirement or a feature?" or "Is a routing protocol >>>>>> that can achieve longer lifetime for the network (as a whole) >>>>>> better than a protocol that exhausts selectively some nodes?" >>>>>> >>>>>> If energy is not taken into account and a node has many data to >>>>>> send, then the nodes in a fixed path will be exhausted. On the >>>>>> other hand, if energy is a metric, the path will change (maybe >>>>>> it will not be always the optimal one), but the energy will be >>>>>> reduced progressively. Moreover, if the nodes have a method to >>>>>> create some energy (e.g. a tiny photovoltaic cell, or windmill) >>>>>> the network may survive. >>>>> >>>>> That was exactly my point. Energy as a NODE metric is a definite >>>>> MUST. I was highly questioning the need for energy link metric. >>>>> A link may require x more times energy that another link to >>>>> transmit but if it is connected to a main power node, then you >>>>> would certainly favor that link. >>>> >>>> It's not that obvious, because a link itself is not connected to =20= >>>> a single >>>> power supply, it's at least two - one for each node on the >>>> link. >>>> >>>> What if these 2 supplies are totally different: one is mains 220V >>>> the other is battery cell. Would the routing protocol still favor >>>> that link? >>>> >>>> Also the money cost: sending a packet on higher-energy link is =20 >>>> supposedly >>>> costlier than sending on a lower-energy link, regardless >>>> of the power supply being a mains supply (220V) or battery cell. >>> >>> =46rom what you say, I think it is definite that energy is a routing >>> parameter. Maybe the function has to be decided (technological, >>> economical, ...) or it may be a weighted factor (based on the >>> application the weight may change according to the value that we =20 >>> want >>> to give to the energy metric), but for sure energy can't be ignored. >> >> Theodore, I tend to agree energy is a good candidate to make a =20 >> metric for a >> routing protocol. >> >> Link metric or node metric - that is a question apparently =20 >> difficult to >> converge on. Well node energy is a MUST we already converged on. Link energy is =20 open for discussion. > > We can have both if the two are needed because their purpose would be > different. Right. > I have seen work on selecting different link depending on > their energy characteristics in the context of wireless radios (think > cellphones) but not in the context of the type of networks we are > talking about. Same here. Thanks. JP. > > - om_p > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Daniel.Popa@itron.com Wed May 20 08:27: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 6CD7D3A69DF for ; Wed, 20 May 2009 08:27:06 -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 cDB-dhdTzb7O for ; Wed, 20 May 2009 08:27:05 -0700 (PDT) Received: from ocn-mx3.itron.com (ocn-mx3.itron.com [74.253.3.158]) by core3.amsl.com (Postfix) with ESMTP id 1D38D3A6407 for ; Wed, 20 May 2009 08:27:04 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 May 2009 11:28:39 -0400 Message-ID: In-Reply-To: <0885DBE3-0DF9-403A-A8F5-BA7B3CF637C5@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [SPAM] Re: DT update -- MUSTs - energy for link metric?(JP Vasseur) Thread-Index: AcnZWKiDFerRpdcAT/K3i2YBeKixqQAAl4tQ References: <4345CED632CC439D81F06EF5724F0864@sVAIO><5B7F1002-2E08-4BA3-9BC1-11AB10B69867@cisco.com><4A13D65A.3000205@gmail.com><975FDB9E36974B94AB68E7437B83003A@sVAIO><4A140BEB.9070905@gmail.com> <0885DBE3-0DF9-403A-A8F5-BA7B3CF637C5@cisco.com> From: "Popa, Daniel" To: Cc: Omprakash Gnawali Subject: Re: [Roll] [SPAM] Re: DT update -- MUSTs - energy for link metric?(JP Vasseur) 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, 20 May 2009 15:27:06 -0000 Dear Rollers,=20 Accept my apologize if my following remarks may overlap some of previous = discussions (I'm quite new with ROLL mailing and didn't follow all the = previous discussions).=20 I would further bring to the discussion some issues related to node = and/or link energy metrics. I think it was Jean-Philippe that cited some = works from the state-of-art that links "link energy metric" with the = link quality (or link inefficiency) and I believe this is a good way to = follow. Indeed, the following situation may often arrive: a (battery = powered) node with enough available energy must spend lot of time trying = to (re-)transmit (1st transmission + retransmissions at MAC Layer) a = packet to its next-hop destination, if the link is heavily lossy and/or = congested for some period of time. Conversely, a similar node with a = less available power may have a 100% success rate to transmit the same = packet, at a first attempt, to its next-hop destination, by using an = alternative link/path with a much better quality.=20 In addition, for battery powered devices, the power consumed by a = (single) packet transmission (energy/bit) at PHY Layer, and for a given = signaling rate (PHY bit rate), is in generally optimized to guarantee a = long battery life. Therefore, the functioning mode of upper layers (MAC = + NET) will greatly impact the energy consumption and thus operation of = such layers must be optimized.=20 Taking into account only the node power might be tricky, if a (battery = powered) device with enough energy will spent lot of its energy trying = to (re-)transmit a packet over a lossy path. Taking into account only = the "link energy ~ inefficiency" might also be tricky, as a main power = supplied device may have no worry about the energy it spends by = attempting to (re-)transmit a packet over a lossy path.=20 Why not defining a hierarchical use of the energy metrics, as a = function of their power source: Type (A) Main power supplied device : metrics (M1, M2, ...) (at least = two: M1 =3D node energy metric; M2 =3D link energy metric) Type (B) Battery powered device : metrics (M1, M2, ....) (at least = two: M1 =3D node energy metric; M2 =3D link energy metric) A fast discrimination between battery and non-battery powered devices = can be done as a function of (M1) values. If this is not enough, then = link energy metric (M2) values can be used to discriminate between = multiple paths available via battery powered devices, as well as via = main power supplied devices. =20 Regards,=20 Daniel =20 -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = JP Vasseur Sent: mercredi 20 mai 2009 16:38 To: Omprakash Gnawali Cc: roll@ietf.org Subject: Re: [Roll] [SPAM] Re: DT update -- MUSTs - energy for link = metric?(JP Vasseur) On May 20, 2009, at 4:24 PM, Omprakash Gnawali wrote: > On Wed, May 20, 2009 at 6:55 AM, Alexandru Petrescu > wrote: >> Theodore Zahariadis a =E9crit : >>> >>> Dear Alex, >>> >>> ----- Original Message ----- From: "Alexandru Petrescu" >>> To: "JP Vasseur" =20 >>> Cc: >>> "Theodore Zahariadis" ; = >> >; >>> Sent: Wednesday, May >>> 20, 2009 1:07 PM Subject: [SPAM] Re: DT update -- MUSTs - energy for >>> link metric? (JP Vasseur) >>> >>> >>>> JP Vasseur a =E9crit : >>>>> >>>>> Hi, >>>>> >>>>> On May 20, 2009, at 9:21 AM, Theodore Zahariadis wrote: >>>>> >>>>>> Dear Tim, Alex, >>>>>> >>>>>> Maybe the question could be asked somewhat differently... Maybe >>>>>> something like: "Is the network survivability a routing >>>>>> protocol requirement or a feature?" or "Is a routing protocol >>>>>> that can achieve longer lifetime for the network (as a whole) >>>>>> better than a protocol that exhausts selectively some nodes?" >>>>>> >>>>>> If energy is not taken into account and a node has many data to >>>>>> send, then the nodes in a fixed path will be exhausted. On the >>>>>> other hand, if energy is a metric, the path will change (maybe >>>>>> it will not be always the optimal one), but the energy will be >>>>>> reduced progressively. Moreover, if the nodes have a method to >>>>>> create some energy (e.g. a tiny photovoltaic cell, or windmill) >>>>>> the network may survive. >>>>> >>>>> That was exactly my point. Energy as a NODE metric is a definite >>>>> MUST. I was highly questioning the need for energy link metric. >>>>> A link may require x more times energy that another link to >>>>> transmit but if it is connected to a main power node, then you >>>>> would certainly favor that link. >>>> >>>> It's not that obvious, because a link itself is not connected to =20 >>>> a single >>>> power supply, it's at least two - one for each node on the >>>> link. >>>> >>>> What if these 2 supplies are totally different: one is mains 220V >>>> the other is battery cell. Would the routing protocol still favor >>>> that link? >>>> >>>> Also the money cost: sending a packet on higher-energy link is =20 >>>> supposedly >>>> costlier than sending on a lower-energy link, regardless >>>> of the power supply being a mains supply (220V) or battery cell. >>> >>> From what you say, I think it is definite that energy is a routing >>> parameter. Maybe the function has to be decided (technological, >>> economical, ...) or it may be a weighted factor (based on the >>> application the weight may change according to the value that we =20 >>> want >>> to give to the energy metric), but for sure energy can't be ignored. >> >> Theodore, I tend to agree energy is a good candidate to make a =20 >> metric for a >> routing protocol. >> >> Link metric or node metric - that is a question apparently =20 >> difficult to >> converge on. Well node energy is a MUST we already converged on. Link energy is =20 open for discussion. > > We can have both if the two are needed because their purpose would be > different. Right. > I have seen work on selecting different link depending on > their energy characteristics in the context of wireless radios (think > cellphones) but not in the context of the type of networks we are > talking about. Same here. Thanks. JP. > > - om_p > _______________________________________________ > 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 zahariad@teihal.gr Wed May 20 08:44: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 B52C23A6D1C for ; Wed, 20 May 2009 08:44:57 -0700 (PDT) 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 DoGQletvXdRH for ; Wed, 20 May 2009 08:44:56 -0700 (PDT) Received: from teihal.gr (mail.teihal.gr [195.130.65.41]) by core3.amsl.com (Postfix) with ESMTP id 30A1F3A6C5A for ; Wed, 20 May 2009 08:44:55 -0700 (PDT) X-MDAV-Processed: teihal.gr, Wed, 20 May 2009 18:46:43 +0300 Received: from sVAIO by teihal.gr (MDaemon PRO v10.0.1) with ESMTP id md50005923806.msg for ; Wed, 20 May 2009 18:46:42 +0300 X-Spam-Processed: teihal.gr, Wed, 20 May 2009 18:46:42 +0300 (not processed: message from valid local sender) X-Authenticated-Sender: zahariad@teihal.gr X-MDRemoteIP: 172.20.1.83 X-Return-Path: zahariad@teihal.gr X-Envelope-From: zahariad@teihal.gr X-MDaemon-Deliver-To: roll@ietf.org Message-ID: From: "Theodore Zahariadis" To: "JP Vasseur" , "Omprakash Gnawali" References: <4345CED632CC439D81F06EF5724F0864@sVAIO><5B7F1002-2E08-4BA3-9BC1-11AB10B69867@cisco.com><4A13D65A.3000205@gmail.com><975FDB9E36974B94AB68E7437B83003A@sVAIO><4A140BEB.9070905@gmail.com> <0885DBE3-0DF9-403A-A8F5-BA7B3CF637C5@cisco.com> In-Reply-To: <0885DBE3-0DF9-403A-A8F5-BA7B3CF637C5@cisco.com> Date: Wed, 20 May 2009 18:46:25 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Cc: roll@ietf.org Subject: Re: [Roll] [SPAM] Re: [SPAM] Re: DT update -- MUSTs - energy for link metric? (JP Vasseur) 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, 20 May 2009 15:44:57 -0000 ----- Original Message ----- From: "JP Vasseur" To: "Omprakash Gnawali" Cc: Sent: Wednesday, May 20, 2009 5:37 PM Subject: [SPAM] Re: [Roll] [SPAM] Re: DT update -- MUSTs - energy for link metric? (JP Vasseur) On May 20, 2009, at 4:24 PM, Omprakash Gnawali wrote: > On Wed, May 20, 2009 at 6:55 AM, Alexandru Petrescu > wrote: >> Theodore Zahariadis a écrit : >>> >>> Dear Alex, >>> >>> ----- Original Message ----- From: "Alexandru Petrescu" >>> To: "JP Vasseur" >>> Cc: >>> "Theodore Zahariadis" ; >>> >> >; >>> Sent: Wednesday, May >>> 20, 2009 1:07 PM Subject: [SPAM] Re: DT update -- MUSTs - energy for >>> link metric? (JP Vasseur) >>> >>> >>>> JP Vasseur a écrit : >>>>> >>>>> Hi, >>>>> >>>>> On May 20, 2009, at 9:21 AM, Theodore Zahariadis wrote: >>>>> >>>>>> Dear Tim, Alex, >>>>>> >>>>>> Maybe the question could be asked somewhat differently... Maybe >>>>>> something like: "Is the network survivability a routing >>>>>> protocol requirement or a feature?" or "Is a routing protocol >>>>>> that can achieve longer lifetime for the network (as a whole) >>>>>> better than a protocol that exhausts selectively some nodes?" >>>>>> >>>>>> If energy is not taken into account and a node has many data to >>>>>> send, then the nodes in a fixed path will be exhausted. On the >>>>>> other hand, if energy is a metric, the path will change (maybe >>>>>> it will not be always the optimal one), but the energy will be >>>>>> reduced progressively. Moreover, if the nodes have a method to >>>>>> create some energy (e.g. a tiny photovoltaic cell, or windmill) >>>>>> the network may survive. >>>>> >>>>> That was exactly my point. Energy as a NODE metric is a definite >>>>> MUST. I was highly questioning the need for energy link metric. >>>>> A link may require x more times energy that another link to >>>>> transmit but if it is connected to a main power node, then you >>>>> would certainly favor that link. >>>> >>>> It's not that obvious, because a link itself is not connected to a >>>> single >>>> power supply, it's at least two - one for each node on the >>>> link. >>>> >>>> What if these 2 supplies are totally different: one is mains 220V >>>> the other is battery cell. Would the routing protocol still favor >>>> that link? >>>> >>>> Also the money cost: sending a packet on higher-energy link is >>>> supposedly >>>> costlier than sending on a lower-energy link, regardless >>>> of the power supply being a mains supply (220V) or battery cell. >>> >>> From what you say, I think it is definite that energy is a routing >>> parameter. Maybe the function has to be decided (technological, >>> economical, ...) or it may be a weighted factor (based on the >>> application the weight may change according to the value that we want >>> to give to the energy metric), but for sure energy can't be ignored. >> >> Theodore, I tend to agree energy is a good candidate to make a metric >> for a >> routing protocol. >> >> Link metric or node metric - that is a question apparently difficult to >> converge on. > Well node energy is a MUST we already converged on. Link energy is open > for discussion. I agree for the node. >> >> We can have both if the two are needed because their purpose would be >> different. > > Right. I agree. However, wrt the link energy it may be difficult to be evaluated, leading to only greedy algorithms. Lets say that we have the following paths: A->B->D or A->C->D Energy at B and C may be known (via beacons?). Moreover, the energy for links A->B and A->C may be calculated (though in case A has a single interface they may vary only based on B and C). However, energy for links B->D and C-> is very difficult to be evaluated (and if the path is longer, practically it can't). Thus, if the link energy is part of the routing algorithm, only greedy algorithms may be supported. Best Theodore >> I have seen work on selecting different link depending on >> their energy characteristics in the context of wireless radios (think >> cellphones) but not in the context of the type of networks we are >> talking about. > >Same here. > >Thanks. > >JP. > > > - om_p > _______________________________________________ > 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 Wed May 20 08:49: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 4DC1C3A6D1C for ; Wed, 20 May 2009 08:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.164 X-Spam-Level: X-Spam-Status: No, score=-10.164 tagged_above=-999 required=5 tests=[AWL=0.435, 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 8O1lp0KbGLu3 for ; Wed, 20 May 2009 08:48:56 -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 6E57F3A6BC3 for ; Wed, 20 May 2009 08:48:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,222,1241395200"; d="scan'208";a="41000448" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 May 2009 15:50:31 +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 n4KFoV47027136; Wed, 20 May 2009 17:50:31 +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 n4KFoVBc025229; Wed, 20 May 2009 15:50:31 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, 20 May 2009 17:50:30 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 May 2009 17:50:30 +0200 From: JP Vasseur To: "Theodore Zahariadis" In-Reply-To: X-Priority: 3 References: <4345CED632CC439D81F06EF5724F0864@sVAIO><5B7F1002-2E08-4BA3-9BC1-11AB10B69867@cisco.com><4A13D65A.3000205@gmail.com><975FDB9E36974B94AB68E7437B83003A@sVAIO><4A140BEB.9070905@gmail.com> <0885DBE3-0DF9-403A-A8F5-BA7B3CF637C5@cisco.com> Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 20 May 2009 17:50:29 +0200 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 20 May 2009 15:50:30.0643 (UTC) FILETIME=[B3FC0430:01C9D962] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5505; t=1242834631; x=1243698631; 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]=20[SPAM]=20Re=3A=20[SPAM]=20Re=3 A=20DT=20update=20--=20MUSTs=20-=20energy=20for=20link=20met ric?=20(JP=20Vasseur) |Sender:=20; bh=GXslEO8jN5O0zIBRCKVvh1Wix6zPY/mGx2q2cYhrnXQ=; b=rY5QFkhQ2gnfJZw+DUo4l1sPwUBjL2+PL1RnhORs0qeUqnIu4DZxugEn1R lrApDOCPvmisg51E5iciK+MFFggScN7ZrvgImIlsIR00mf0SpLQZMatN/pjR E3yG2ql5kr; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org, Omprakash Gnawali Subject: Re: [Roll] [SPAM] Re: [SPAM] Re: DT update -- MUSTs - energy for link metric? (JP Vasseur) 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, 20 May 2009 15:49:02 -0000 On May 20, 2009, at 5:46 PM, Theodore Zahariadis wrote: > > ----- Original Message ----- From: "JP Vasseur" > To: "Omprakash Gnawali" > Cc: > Sent: Wednesday, May 20, 2009 5:37 PM > Subject: [SPAM] Re: [Roll] [SPAM] Re: DT update -- MUSTs - energy =20 > for link metric? (JP Vasseur) > > > > On May 20, 2009, at 4:24 PM, Omprakash Gnawali wrote: > >> On Wed, May 20, 2009 at 6:55 AM, Alexandru Petrescu >> wrote: >>> Theodore Zahariadis a =E9crit : >>>> >>>> Dear Alex, >>>> >>>> ----- Original Message ----- From: "Alexandru Petrescu" >>>> To: "JP Vasseur" = >>> > Cc: >>>> "Theodore Zahariadis" ; = >>> >; >>>> Sent: Wednesday, May >>>> 20, 2009 1:07 PM Subject: [SPAM] Re: DT update -- MUSTs - energy =20= >>>> for >>>> link metric? (JP Vasseur) >>>> >>>> >>>>> JP Vasseur a =E9crit : >>>>>> >>>>>> Hi, >>>>>> >>>>>> On May 20, 2009, at 9:21 AM, Theodore Zahariadis wrote: >>>>>> >>>>>>> Dear Tim, Alex, >>>>>>> >>>>>>> Maybe the question could be asked somewhat differently... Maybe >>>>>>> something like: "Is the network survivability a routing >>>>>>> protocol requirement or a feature?" or "Is a routing protocol >>>>>>> that can achieve longer lifetime for the network (as a whole) >>>>>>> better than a protocol that exhausts selectively some nodes?" >>>>>>> >>>>>>> If energy is not taken into account and a node has many data to >>>>>>> send, then the nodes in a fixed path will be exhausted. On the >>>>>>> other hand, if energy is a metric, the path will change (maybe >>>>>>> it will not be always the optimal one), but the energy will be >>>>>>> reduced progressively. Moreover, if the nodes have a method to >>>>>>> create some energy (e.g. a tiny photovoltaic cell, or windmill) >>>>>>> the network may survive. >>>>>> >>>>>> That was exactly my point. Energy as a NODE metric is a definite >>>>>> MUST. I was highly questioning the need for energy link metric. >>>>>> A link may require x more times energy that another link to >>>>>> transmit but if it is connected to a main power node, then you >>>>>> would certainly favor that link. >>>>> >>>>> It's not that obvious, because a link itself is not connected =20 >>>>> to a single >>>>> power supply, it's at least two - one for each node on the >>>>> link. >>>>> >>>>> What if these 2 supplies are totally different: one is mains 220V >>>>> the other is battery cell. Would the routing protocol still favor >>>>> that link? >>>>> >>>>> Also the money cost: sending a packet on higher-energy link is =20 >>>>> supposedly >>>>> costlier than sending on a lower-energy link, regardless >>>>> of the power supply being a mains supply (220V) or battery cell. >>>> >>>> =46rom what you say, I think it is definite that energy is a = routing >>>> parameter. Maybe the function has to be decided (technological, >>>> economical, ...) or it may be a weighted factor (based on the >>>> application the weight may change according to the value that we =20= >>>> want >>>> to give to the energy metric), but for sure energy can't be =20 >>>> ignored. >>> >>> Theodore, I tend to agree energy is a good candidate to make a =20 >>> metric for a >>> routing protocol. >>> >>> Link metric or node metric - that is a question apparently =20 >>> difficult to >>> converge on. > >> Well node energy is a MUST we already converged on. Link energy is =20= >> open for discussion. > > I agree for the node. > >>> >>> We can have both if the two are needed because their purpose would =20= >>> be >>> different. >> >> Right. > > I agree. > However, wrt the link energy it may be difficult to be evaluated, =20 > leading to > only greedy algorithms. Lets say that we have the following paths: > A->B->D or > A->C->D > We're in sync. > Energy at B and C may be known (via beacons?). > Moreover, the energy for links A->B and A->C may be calculated > (though in case A has a single interface they may vary only based on =20= > B and C). > However, energy for links B->D and C-> is very difficult to be =20 > evaluated > (and if the path is longer, practically it can't). > > Thus, if the link energy is part of the routing algorithm, only =20 > greedy algorithms > may be supported. > Yes this is exactly why I was mentioning that the metric ID will =20 evolve in parrallel with the protocol ID. There are several ways to =20 sort this out, but let's see what we all come up with in term of =20 protocols. More very soon ... Cheers. JP. > Best > > Theodore > >>> I have seen work on selecting different link depending on >>> their energy characteristics in the context of wireless radios =20 >>> (think >>> cellphones) but not in the context of the type of networks we are >>> talking about. >> >> Same here. >> >> Thanks. >> >> JP. >> >> >> - om_p >> _______________________________________________ >> 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 John.E.Drake2@boeing.com Wed May 20 09:42: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 A8ED93A7115 for ; Wed, 20 May 2009 09:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.653 X-Spam-Level: X-Spam-Status: No, score=-5.653 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, J_CHICKENPOX_53=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 lmotl16c6iwi for ; Wed, 20 May 2009 09:42:17 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 30A353A70F2 for ; Wed, 20 May 2009 09:42:17 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4KGhqgi022527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 May 2009 09:43:52 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4KGhp5J029634; Wed, 20 May 2009 09:43:51 -0700 (PDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4KGhpod029624; Wed, 20 May 2009 09:43:51 -0700 (PDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 May 2009 09:43:51 -0700 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: Wed, 20 May 2009 09:43:50 -0700 Message-ID: <51661468CBD1354294533DA79E85955A01BEDFEE@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: <4A140BEB.9070905@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [SPAM] Re: DT update -- MUSTs - energy for link metric?(JP Vasseur) Thread-Index: AcnZUrrv/66dtFN/SV2tWGVeS2g0oAAFwyeA References: <4345CED632CC439D81F06EF5724F0864@sVAIO><5B7F1002-2E08-4BA3-9BC1-11AB10B69867@cisco.com><4A13D65A.3000205@gmail.com><975FDB9E36974B94AB68E7437B83003A@sVAIO> <4A140BEB.9070905@gmail.com> From: "Drake, John E" To: "Alexandru Petrescu" , "Theodore Zahariadis" X-OriginalArrivalTime: 20 May 2009 16:43:51.0277 (UTC) FILETIME=[27B601D0:01C9D96A] Cc: roll@ietf.org Subject: Re: [Roll] [SPAM] Re: DT update -- MUSTs - energy for link metric?(JP Vasseur) 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, 20 May 2009 16:42:18 -0000 Having it as a link parameter allows for heterogeneous links. It is = also consistent with the way TE parameters have ben handled in GMPLS, = even when referring to parameters that are actually associated with the = node as a whole, such as server cards. =20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Wednesday, May 20, 2009 6:56 AM > To: Theodore Zahariadis > Cc: roll@ietf.org > Subject: Re: [Roll] [SPAM] Re: DT update -- MUSTs - energy=20 > for link metric?(JP Vasseur) >=20 > Theodore Zahariadis a =E9crit : > > Dear Alex, > >=20 > > ----- Original Message ----- From: "Alexandru Petrescu"=20 > > To: "JP Vasseur" > > Cc: "Theodore Zahariadis" ;=20 > > ; Sent:=20 > Wednesday, May=20 > > 20, 2009 1:07 PM Subject: [SPAM] Re: DT update -- MUSTs -=20 > energy for=20 > > link metric? (JP Vasseur) > >=20 > >=20 > >> JP Vasseur a =E9crit : > >>> Hi, > >>>=20 > >>> On May 20, 2009, at 9:21 AM, Theodore Zahariadis wrote: > >>>=20 > >>>> Dear Tim, Alex, > >>>>=20 > >>>> Maybe the question could be asked somewhat differently... Maybe =20 > >>>> something like: "Is the network survivability a routing protocol=20 > >>>> requirement or a feature?" or "Is a routing protocol that can=20 > >>>> achieve longer lifetime for the network (as a whole)=20 > better than a=20 > >>>> protocol that exhausts selectively some nodes?" > >>>>=20 > >>>> If energy is not taken into account and a node has many data to =20 > >>>> send, then the nodes in a fixed path will be exhausted. On the=20 > >>>> other hand, if energy is a metric, the path will change=20 > (maybe it=20 > >>>> will not be always the optimal one), but the energy will=20 > be reduced=20 > >>>> progressively. Moreover, if the nodes have a method to=20 > create some=20 > >>>> energy (e.g. a tiny photovoltaic cell, or windmill) the=20 > network may=20 > >>>> survive. > >>>=20 > >>> That was exactly my point. Energy as a NODE metric is a definite =20 > >>> MUST. I was highly questioning the need for energy link metric. > >>> A link may require x more times energy that another link=20 > to transmit=20 > >>> but if it is connected to a main power node, then you would=20 > >>> certainly favor that link. > >>=20 > >> It's not that obvious, because a link itself is not connected to a=20 > >> single power supply, it's at least two - one for each node on the=20 > >> link. > >>=20 > >> What if these 2 supplies are totally different: one is=20 > mains 220V the=20 > >> other is battery cell. Would the routing protocol still=20 > favor that=20 > >> link? > >>=20 > >> Also the money cost: sending a packet on higher-energy link is=20 > >> supposedly costlier than sending on a lower-energy link,=20 > regardless=20 > >> of the power supply being a mains supply (220V) or battery cell. > >=20 > > From what you say, I think it is definite that energy is a routing=20 > > parameter. Maybe the function has to be decided (technological,=20 > > economical, ...) or it may be a weighted factor (based on the=20 > > application the weight may change according to the value=20 > that we want=20 > > to give to the energy metric), but for sure energy can't be ignored. >=20 > Theodore, I tend to agree energy is a good candidate to make=20 > a metric for a routing protocol. >=20 > Link metric or node metric - that is a question apparently=20 > difficult to converge on. >=20 > Alex >=20 > >=20 > > BR, Theodore > >=20 > >>=20 > >> Alex > >>=20 > >>=20 > >>>=20 > >>> As pointed out earlier in a previous email, energy link=20 > would in my=20 > >>> opinion make sense if nodes are homogenous, which is not=20 > our cases,=20 > >>> thus my argument for only using node energy metric. Makes sense ? > >>>=20 > >>>>=20 > >>>> We have done a number of simulations in JSIM trying to combine =20 > >>>> routing and trust. It seams that even in a trust=20 > framework, taking=20 > >>>> into account energy metrics may drastically increase the network=20 > >>>> lifetime. > >>>=20 > >>> Sure. By the way, as general comment do not hesitate to=20 > send pointer=20 > >>> to simulations. Although they cannot be used to demonstrate that=20 > >>> something works, that can provide interesting datapoint. > >>>=20 > >>>>=20 > >>>> Of course all these apply to homogeneous nodes. > >>>=20 > >>> Here it is. > >>>=20 > >>>> If the nodes are heterogeneous calculating the optimal energy=20 > >>>> metric may be too hard (may not worth). On the other hand, there=20 > >>>> may be some thresholds put e.g. "if the remaining energy of node=20 > >>>> "a" is less than "x", avoid it, unless it is the node with the=20 > >>>> maximum energy in the neighborhood". > >>>>=20 > >>>=20 > >>> Yes, and we use node energy metrics for that matter. > >>>=20 > >>> Thanks. > >>>=20 > >>> JP. > >>>=20 > >>>> BR, Theodore > >>>>=20 > >>>>> Date: Tue, 19 May 2009 14:38:06 +0200 From: JP Vasseur=20 > >>>>> Subject: Re: [Roll] DT update -- MUSTs - =20 > >>>>> energy for link metric? To: Alexandru Petrescu=20 > >>>>> Cc: ROLL WG ,=20 > >>>>> dtroll@external.cisco.com Message-ID: > >>>>> > >>>>> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed; = > >>>>> delsp=3Dyes > >>>>>=20 > >>>>> but again, this does not really answer *the* question:=20 > why should=20 > >>>>> the routing protocol take link energy into account during path=20 > >>>>> computation ? > >>>>>=20 > >>>>> On May 19, 2009, at 12:11 PM, Alexandru Petrescu wrote: > >>>>>=20 > >>>>>> JP Vasseur a ?crit : > >>>>>>> Hi Alex, On May 15, 2009, at 8:39 AM, Alexandru Petrescu > >>>>>>> wrote: > >>>>>>>> Tim, thanks for the update - that's hard work. A side remark=20 > >>>>>>>> about one particular interest: the req list doesn't seem to=20 > >>>>>>>> include a metric for energy of the > >>>>>>>> link: energy necessary to send a packet on the link,=20 > or energy=20 > >>>>>>>> radiated in the air, or similar. Or I can't find it=20 > - is there=20 > >>>>>>>> one? I do find reqs for energy as constraints of the node=20 > >>>>>>>> device: level of energy, energy of the node, power=20 > available,=20 > >>>>>>>> power budget, etc. Or is the link energy completely out of=20 > >>>>>>>> scope? > >>>>>>> It would be useful to know what the WG thinks about=20 > link energy=20 > >>>>>>> metrics. > >>>>>>=20 > >>>>>> I am very interested on all WG oppinions on link energy metric. > >>>>>>=20 > >>>>>>=20 > >>>>>>=20 > >>>>>>> Here is my take on it. Node energy metric is=20 > undoubtedly needed,=20 > >>>>>>> in many cases, one may want to avoid a node that is battery=20 > >>>>>>> operated or running our of battery, we are all in sync with=20 > >>>>>>> this. Now with regards to link energy metrics, this is by far=20 > >>>>>>> less obvious. Why would you care knowing that the energy=20 > >>>>>>> required to transmit 1 bit is X over a link L1 and 2*X over a=20 > >>>>>>> link L2? > >>>>>>=20 > >>>>>> My first impression: because typical cost metrics are _link_=20 > >>>>>> metrics, not node metrics - the hop count is the=20 > number of links,=20 > >>>>>> not of nodes (a 3 node topology uses a 2 hop count=20 > metric - the=20 > >>>>>> number of links). > >>>>>>=20 > >>>>>> More often than not the parameters advertised in Router=20 > >>>>>> Advertisements of OSPF and ICMP are link parameters: link MTU,=20 > >>>>>> link prefix. > >>>>>>=20 > >>>>>> It sounds attractive to reuse the same link concept for energy. > >>>>>>=20 > >>>>>>=20 > >>>>>>=20 > >>>>>> Prior publications making think link energy is relevant: > >>>>>>=20 > >>>>>> Callaway, E., "Secure Low-Power Operation of Wireless Sensor=20 > >>>>>> Networks", Intelligent Systems, January 2004. > >>>>>>=20 > >>>>>> Mentions transmission of a packet with a particular 15.4=20 > >>>>>> transceiver to be 56 micro-Joules, and is computed relative to=20 > >>>>>> the number of bits transmitted. > >>>>>>=20 > >>>>>> L. Li, J-Y. Jalpern, ICC'01, Finland., "Minimum-Energy Mobile=20 > >>>>>> Wireless Networks Revisited", June 2001. > >>>>>>=20 > >>>>>> Explicitely assumes that "a transmission between node u and v=20 > >>>>>> takes power p(uv) [...]". > >>>>>>=20 > >>>>>> IEEE Global Telecommunications Conference, Globecom '03,=20 > >>>>>> "Measurement and Characterization of Link Quality Metrics in=20 > >>>>>> Energy Constrained Wireless Sensor Networks", 2003. > >>>>>>=20 > >>>>>> Mentions that the energy to transmit a packet is=20 > proportional to=20 > >>>>>> 'link inefficiency', and this latter (not the energy)=20 > is defined=20 > >>>>>> as a metric. > >>>>>>=20 > >>>>>>> It might very well be that the node connected to L2 has no=20 > >>>>>>> energy constraint by contrast with the node connected to L1=20 > >>>>>>> being battery operated. > >>>>>>=20 > >>>>>> There seems indeed to be a decoupling between the=20 > energy left to=20 > >>>>>> a node, its battery level, its consumption patterns > >>>>>> - and the energy needed to send an MTU-sized packet on a link. > >>>>>>=20 > >>>>>> They could be both needed, I can't easily say, because the =20 > >>>>>> NP-completeness issue: routing according to metric=20 > "link-energy"=20 > >>>>>> _and_ metric "node-energy" may be NP-hard to do. > >>>>>>=20 > >>>>>> Alex > >>>>=20 > >>>>=20 > >>>=20 > >>>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >=20 > >=20 > >=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From rfc-editor@rfc-editor.org Tue May 19 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 B30F63A7107; Tue, 19 May 2009 14:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.256 X-Spam-Level: X-Spam-Status: No, score=-17.256 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] 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 9Qiu67MgXANd; Tue, 19 May 2009 14:52:50 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 7BAEC3A710B; Tue, 19 May 2009 14:52:45 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 9EC7B2B1BF9; Tue, 19 May 2009 14:53:58 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090519215358.9EC7B2B1BF9@bosco.isi.edu> Date: Tue, 19 May 2009 14:53:58 -0700 (PDT) X-Mailman-Approved-At: Wed, 20 May 2009 12:03:17 -0700 Cc: roll@ietf.org, rfc-editor@rfc-editor.org Subject: [Roll] RFC 5548 on Routing Requirements for Urban Low-Power and Lossy Networks 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, 19 May 2009 21:52:51 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5548 Title: Routing Requirements for Urban Low-Power and Lossy Networks Author: M. Dohler, Ed., T. Watteyne, Ed., T. Winter, Ed., D. Barthel, Ed. Status: Informational Date: May 2009 Mailbox: mischa.dohler@cttc.es, watteyne@eecs.berkeley.edu, wintert@acm.org, Dominique.Barthel@orange-ftgroup.com Pages: 21 Characters: 47759 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-roll-urban-routing-reqs-05.txt URL: http://www.rfc-editor.org/rfc/rfc5548.txt 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 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 (for example, the data required by applications that perform smart-metering or that monitor meteorological, pollution, and allergy conditions). The majority of these nodes are expected to communicate wirelessly over a variety of links such as IEEE 802.15.4, low-power IEEE 802.11, or 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 solution for Routing Over Low-Power and Lossy (ROLL) networks 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. This memo provides information for the Internet community. This document is a product of the Routing Over Low power and Lossy networks Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From zahariad@teihal.gr Thu May 21 10:09: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 847063A687A for ; Thu, 21 May 2009 10:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.146 X-Spam-Level: X-Spam-Status: No, score=0.146 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_50=0.001, STOX_REPLY_TYPE=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 PQU7B0XkQSpe for ; Thu, 21 May 2009 10:09:26 -0700 (PDT) Received: from aiolos.otenet.gr (aiolos.otenet.gr [83.235.67.30]) by core3.amsl.com (Postfix) with ESMTP id 501453A6E29 for ; Thu, 21 May 2009 10:09:25 -0700 (PDT) Received: from sVAIO (ppp-94-66-2-226.home.otenet.gr [94.66.2.226]) by aiolos.otenet.gr (8.13.8/8.13.8/Debian-3) with SMTP id n4LHAtsE004910 for ; Thu, 21 May 2009 20:10:55 +0300 Message-ID: <3C5BB0898A9542DC88EC912B04CC207C@sVAIO> From: "Theodore Zahariadis" To: Date: Thu, 21 May 2009 20:10:50 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: [Roll] A Trust Framework for Low Power and Lossy Networks 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, 21 May 2009 17:09:27 -0000 Dear all, As I said in previous emails, a trust framework may be complementary to the secure routing for LLNs and help protecting against a number of attacks. Though the node vs/plus link energy metric discussion is very interesting, I uploaded an I-D describing some ideas on such a framework. Comments are very welcomed and appreciated. Thanks, Theodore ----- Original Message ----- From: "IETF I-D Submission Tool" To: Cc: ; ; ; Sent: Thursday, May 21, 2009 7:42 PM Subject: New Version Notification for draft-zahariad-roll-trust-framework-00 > > A new version of I-D, draft-zahariad-roll-trust-framework-00.txt has been > successfuly submitted by Theodore Zahariadis and posted to the IETF > repository. > > Filename: draft-zahariad-roll-trust-framework > Revision: 00 > Title: A Trust Framework for Low Power and Lossy Networks > Creation_date: 2009-05-21 > WG ID: Independent Submission > Number_of_pages: 17 > > Abstract: > This document presents a trust framework, which may improve the > security and reliability of routing over Low Power and Lossy Networks > (LLN), against an increased set of attacks. The development of the > framework builds upon previous work on trust and secure routing, > adapting the trust assessments to the issues and constraints specific > to LLNs. > > The proposed trust management scheme is based on direct and indirect > interactions with neighboring nodes, to compute their trust value and > thus select the most trusted path or forwarding node. To reduce the > overhead of nodes' communication during the indirect trust value > retrieval procedure, indirect trust information is requested from a > limited number of neighbors, which respond only when they have highly > reliable trust information > > > > The IETF Secretariat. > > > > From jvasseur@cisco.com Thu May 21 22:58: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 4038B3A7023 for ; Thu, 21 May 2009 22:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.168 X-Spam-Level: X-Spam-Status: No, score=-10.168 tagged_above=-999 required=5 tests=[AWL=0.430, 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 1622JOHBad3U for ; Thu, 21 May 2009 22:58:50 -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 272AE3A7021 for ; Thu, 21 May 2009 22:58:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,231,1241395200"; d="scan'208,217";a="41102112" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 22 May 2009 05:59:54 +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 n4M5xs5F031422 for ; Fri, 22 May 2009 07:59:54 +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 n4M5xsRU004534 for ; Fri, 22 May 2009 05:59:54 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); Fri, 22 May 2009 07:59:54 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 May 2009 07:59:53 +0200 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-123-524304883 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 22 May 2009 07:59:53 +0200 References: <20090519215358.9EC7B2B1BF9@bosco.isi.edu> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 22 May 2009 05:59:54.0337 (UTC) FILETIME=[87205510:01C9DAA2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12221; t=1242971994; x=1243835994; 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:=20Fwd=3A=20RFC=205548=20on=20Routing=20Requiremen ts=20for=20Urban=20Low-Power=20and=20Lossy=20Networks |Sender:=20; bh=5MtmJbp3PIu2daqnviLt4//kolOoMyhd03Q0A9qEnMU=; b=t0HDRU7CHg5HKVDGzTdcnq9VcCo1p88pFxigitH/2mgj/AQ+H3f9I7BlyS ccgfT9xyKQBDZ5qllkyniv88Wqc11NKz8gGSY+cuxdH1aBbNYCC27CWpc4Rs lW7EUzbyGM; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [Roll] Fwd: RFC 5548 on Routing Requirements for Urban Low-Power and Lossy Networks 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, 22 May 2009 05:58:57 -0000 --Apple-Mail-123-524304883 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Our first RFC :-) JP. Begin forwarded message: > From: rfc-editor@rfc-editor.org > Date: May 19, 2009 11:53:58 PM CEDT > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > Cc: roll@ietf.org, rfc-editor@rfc-editor.org > Subject: RFC 5548 on Routing Requirements for Urban Low-Power and > Lossy Networks > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 5548 > > Title: Routing Requirements for Urban Low-Power > and Lossy Networks > Author: M. Dohler, Ed., > T. Watteyne, Ed., > T. Winter, Ed., > D. Barthel, Ed. > Status: Informational > Date: May 2009 > Mailbox: mischa.dohler@cttc.es, > watteyne@eecs.berkeley.edu, > wintert@acm.org, > Dominique.Barthel@orange-ftgroup.com > Pages: 21 > Characters: 47759 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-roll-urban-routing-reqs-05.txt > > URL: http://www.rfc-editor.org/rfc/rfc5548.txt > > 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 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 (for example, the data required by applications that perform > smart-metering or that monitor meteorological, pollution, and allergy > conditions). The majority of these nodes are expected to communicate > wirelessly over a variety of links such as IEEE 802.15.4, low-power > IEEE 802.11, or 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 > solution for Routing Over Low-Power and Lossy (ROLL) networks 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. This memo provides information for the Internet > community. > > This document is a product of the Routing Over Low power and Lossy > networks Working Group of the IETF. > > > INFORMATIONAL: This memo provides information for the Internet > community. > It does not specify an Internet standard of any kind. Distribution of > this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html > . > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. > Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > USC/Information Sciences Institute > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-123-524304883 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Our first RFC = :-)

JP.

Begin forwarded = message:

Date: May 19, 2009 11:53:58 PM = CEDT
Subject: RFC 5548 on Routing Requirements for = Urban Low-Power and Lossy Networks


A new = Request for Comments is now available in online RFC = libraries.


       RFC = 5548

       Title: =      Routing Requirements for Urban Low-Power =
=             &n= bsp;      and Lossy Networks
=        Author: =     M. Dohler, Ed.,
=             &n= bsp;      T. Watteyne, Ed.,
=             &n= bsp;      T. Winter, Ed.,
=             &n= bsp;      D. Barthel, Ed.
=        Status: =     Informational
=        Date: =       May 2009
=        Mailbox:    mischa.dohler@cttc.es,
=             &n= bsp;      watteyne@eecs.berkeley.edu,=
=             &n= bsp;      wintert@acm.org,
=             &n= bsp;      Dominique.Barthel@ora= nge-ftgroup.com
       Pages: =      21
=        Characters: 47759
=        Updates/Obsoletes/SeeAlso: =   None

       I-D = Tag:    draft-ietf-roll-urban-routing-reqs-05.txt

=        URL: =        http://www.rfc-editor.o= rg/rfc/rfc5548.txt

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 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 (for = example, the data required by applications that = perform
smart-metering or that monitor meteorological, pollution, and = allergy
conditions).  The majority of these nodes are expected = to communicate
wirelessly over a variety of links such as IEEE = 802.15.4, low-power
IEEE 802.11, or 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
solution for Routing Over Low-Power and Lossy = (ROLL) networks 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.  This memo provides = information for the Internet community.

This document is a = product of the Routing Over Low power and Lossy networks Working Group = of the IETF.


INFORMATIONAL: This memo provides information = for the Internet community.
It does not specify an Internet standard = of any kind. Distribution of
this memo is unlimited.

This = announcement is sent to the IETF-Announce and rfc-dist lists.
To = subscribe or unsubscribe, see
 http://www.iet= f.org/mailman/listinfo/ietf-announce
 http://ma= ilman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching = the RFC series, see http://www.rfc-editor.or= g/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.= html.

Requests for special distribution should be addressed = to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org. =  Unless
specifically noted otherwise on the RFC itself, all RFCs = are for
unlimited distribution.


The RFC Editor = Team
USC/Information Sciences = Institute


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

= --Apple-Mail-123-524304883--