From roll-bounces@ietf.org Tue Mar 4 07:29:52 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FECE28C4B5; Tue, 4 Mar 2008 07:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=-1.391, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.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 r6A-ueM4J0fO; Tue, 4 Mar 2008 07:29:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1235E28C5F7; Tue, 4 Mar 2008 07:29:45 -0800 (PST) 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 5A4313A68A2 for ; Tue, 4 Mar 2008 07:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 OtVD+xZDnUTv for ; Tue, 4 Mar 2008 07:29:39 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 77C7E28C645 for ; Tue, 4 Mar 2008 07:28:37 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,444,1199682000"; d="scan'208";a="379578" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 04 Mar 2008 10:28:26 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m24FSRCK022578 for ; Tue, 4 Mar 2008 10:28:27 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m24FSLax027465 for ; Tue, 4 Mar 2008 15:28:27 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Mar 2008 10:28:24 -0500 Received: from 10.86.104.184 ([10.86.104.184]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Tue, 4 Mar 2008 15:28:24 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 04 Mar 2008 10:28:26 -0500 From: JP Vasseur To: Message-ID: Thread-Topic: Slides Thread-Index: Ach+DGPaokZKPOn/EdyVFgANk8WjQA== Mime-version: 1.0 X-OriginalArrivalTime: 04 Mar 2008 15:28:24.0828 (UTC) FILETIME=[632733C0:01C87E0C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=81; t=1204644507; x=1205508507; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Slides |Sender:=20 |To:=20; bh=loG6ArhJg+73D3iY3cGFEHt4/+veB+w/EU3oewM03QY=; b=j5cUSvOzm0WdWhHJqvCp8vrBQS6lgOMbHl0XXCQjwURU/yYxj9AclMGlj7 wFoxBoe33KhQHCdBWS6WvbzTHFH5fClEz8DRdfsBK3JOEk4f4O3NGaOM19cs rtnjNxeoX+; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [Roll] Slides 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, "Presenters" thanks to send us your slides by March 7? Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Sat Mar 8 12:10:37 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ECAE3A6B52; Sat, 8 Mar 2008 12:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.745 X-Spam-Level: X-Spam-Status: No, score=-100.745 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 LYmH7DMErZDs; Sat, 8 Mar 2008 12:10:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AE4C3A6AC0; Sat, 8 Mar 2008 12:10:35 -0800 (PST) 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 95EFD3A6AEE; Sat, 8 Mar 2008 12:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 8BI+JmlkoV38; Sat, 8 Mar 2008 12:10:31 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by core3.amsl.com (Postfix) with ESMTP id 5EE993A6BF0; Sat, 8 Mar 2008 12:10:25 -0800 (PST) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.2/8.13.5) with ESMTP id m28K80f7026690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 8 Mar 2008 12:08:01 -0800 (PST) Message-ID: <47D2F21A.7080309@eecs.berkeley.edu> Date: Sat, 08 Mar 2008 12:07:54 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: 6lowpan@ietf.org, roll@ietf.org References: <200803021021.10955.coflynn@newae.com> <001e01c87fd4$7264c4a0$8300a8c0@priveiqvfluhp9> In-Reply-To: <001e01c87fd4$7264c4a0$8300a8c0@priveiqvfluhp9> Cc: Colin O'Flynn , Robert Assimiti Subject: Re: [Roll] [6lowpan] Syncronized Wake 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Pieter, Collin: the ISA100.11a MAC is based on TSMP (http://en.wikipedia.org/wiki/TSMP), although it's been made very general because of political requirements in getting the .11 group off the ground. So it's actually possible to configure it to be pure scheduled unicast channel-hopping TDMA, pure single-channel CSMA, or anything in between. One likely operating mode would look something like this (this is basically what Wireless HART does): * 10ms slot length. Single packet sent and acknowledged in a single slot. Most scheduled slots would be unicast for "upstream" data collection. Some scheduled slots would be broadcast for downstream communication. Some might be shared bandwidth (slotted aloha). Scheduled slots repeat in one or more superframes, similar to but far more flexible than the 15.4 GTS mechanism. * +/- 1ms guard time at the beginning of the slot to allow for synchronization errors. Depending on the temperature range and the quality of the time-keeping at each mote, this leads to a synchronization requirement of between 10 seconds and a minute. Motes keep track of their last synchronization (optionally on a path-by-path basis) and send a keepalive packet if their synch timer expires. Every acknowledged packet carries time information in both directions, so they reset the synchronization timer. For many/most motes in many/all networks there is no need for additional synchronization traffic above and beyond normal data traffic. For low traffic networks, beaconing may be used if it makes more sense energetically than keepalives. For 802.15.4 radios, the overhead for maintaining +/-1ms synchronization across the entire network is less than 0.01% radio duty cycle. Since all motes share a common sense of time, they can pseudo-randomly channel hop, dramatically reducing the chance of a link between two motes "going down" due to external or multi-path interference. * Communication cells (={slot, channel_offset} pair) may be assigned by some central manager, or via purely distributed algorithms, or some combination of both. Enforcing unicast with no collisions, 1,600 cells per second are available (100 slots/second * 16 channels). Cells are collected into graphs. Graphs provide QoS to applications, and can be turned on and off to dynamically vary power and performance over many orders of magnitude in response to application requests. This is where things get interesting with 6LoWPAN and RoLL. TSMP provides the mechanisms to bind layer 4 quality of service to layer 3 routes and layer 2 performance/power provisioning. This is critical in industrial automation, and seems likely to be very useful in other applications as well. I don't think that it violates anything that the IETF holds dear, but I've been wrong about that before :) ksjp Pieter De Mil wrote: > Hi Robert, > > I don't know if Colin is interested in more details, but I certainly am. > > How frequently do you have to exchange sync. messages? Every 10/60/.. > seconds? > How are your sync. messages scheduled? Via a distributed assignment? > > Do you use CSMA/CA in a time slot? > > Pieter > > ----- Original Message ----- > From: "Robert Assimiti" > To: "Colin O'Flynn" ; <6lowpan@ietf.org> > Sent: Thursday, March 06, 2008 10:17 PM > Subject: Re: [6lowpan] Syncronized Wake > > > Hello Colin, > > The currently undergoing ISA100.11a standardization effort would be the > perfect paradigm for what you are trying to accomplish. It is a standard > geared towards industrial process and automation, but it definitely has > applicability in commercial applications as well. > > Currently employing the 802.15.4 PHY/MAC (although alternate PHY/MACs are > being considered), the Field Devices (FFD/RFDs in 802.15.4 semantics) > communicate during strictly enforced "time slots" without using beacons. > This allows for prolonged battery life although frequent time > synchronization messages must be exchanged. > > Let me know if you are interested in more details. > > > > > > "The nice thing about standards is that there are so many to choose from." - > Andrew S. Tanenbaum > Robert Assimiti > Executive Staff Engineer > Office: [678]-202-6859 > Mobile: [404]-578-0205 > robert.assimiti@nivis.com > > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > Of Colin O'Flynn > Sent: Sunday, March 02, 2008 9:21 AM > To: 6lowpan@ietf.org > Subject: [6lowpan] Syncronized Wake > > Hello All, > > First a quick question - I found this list on the IETF site. I assume it's a > public list, you don't have to be a member of the working group to submit? > > Anyway, a few of us are working on doing a 6lowpan implementation. I was > looking at doing a 'syncronized wake' to help save power yet get reasonable > response times. By my calculations you could wake every few seconds and > still > have an exceptional battery life (year+). > > Since some nodes might need to wake up more often than others they might > have > different schedules, and obviously you'd need some sort of beacon to > syncronize. The idea is each node has a "wake schedule" that nearby nodes > know, and will be listening at that time. But any node can TX at almost any > time. > > I don't want to do GTS though, as nodes can talk at any time. But I need a > way > to (a) sync nodes and (b) transmit wake schedule. > > So the question: would their be a standards-compliant way to do this? Or is > it > worth it trying to be standards compliant at this stage? It would be easy > enough to make some simple protocol up to do this for testing. > > Warm Regards, > > -Colin O'Flynn > > PS: If you are interested: hardware is 8-bit AVR devices, using uIP for IPv6 > implementation. The gateway router is AVR32 device, which can route over > ethernet. > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > > This e-mail (including any attachments to it) is confidential, proprietary, > legally privileged, subject to copyright and is sent for the personal > attention of the intended recipient only. If you have received this e-mail > in error, please reply to advise us immediately, delete it and destroy any > printed copies of it. You are notified that reading, disclosing, copying, > distributing or taking any action in reliance on the contents of this > information is strictly prohibited. No employee is authorized to conclude > any binding agreement on behalf of NIVIS LLC with another party by e-mail > without express written confirmation by an officer of the company. Although > we have taken reasonable precautions to ensure no viruses are present in > this e-mail, we cannot accept responsibility for any loss or damage arising > from the viruses in this e-mail or attachments. > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Mar 10 09:19:56 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E62B828C638; Mon, 10 Mar 2008 09:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.134 X-Spam-Level: X-Spam-Status: No, score=-100.134 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 PWoQcF9QV6FS; Mon, 10 Mar 2008 09:19:56 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A6A028C9C4; Mon, 10 Mar 2008 08:54:47 -0700 (PDT) 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 A378A28C867 for ; Mon, 10 Mar 2008 08:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 eIyAwc5Oj+U2 for ; Mon, 10 Mar 2008 08:54:44 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 749CD28CD96 for ; Mon, 10 Mar 2008 08:35:43 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id m2AFXMnP013699 for ; Mon, 10 Mar 2008 16:33:22 +0100 (MET) Received: from 130.129.18.139 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Mon, 10 Mar 2008 15:33:21 +0000 To: roll@ietf.org Date: Mon, 10 Mar 2008 15:33:21 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 10 Mar 2008 16:33:22 +0100 (MET) Subject: [Roll] question regarding context and service discovery routing issues 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Dear all I have checked the several ROLL requirements drafts, but I could not find a requirement that is related to context and service discovery routing! I think that for multi-hop wireless networks, and especially adhoc sensor networks the way of how the discovery of the environment of a device is accomplished and how routing based on this discovery is done, are very important capabilities that make the device usefull. The 6lowpan and zerocof have addressed/addressing this issue, but I am not sure if this is done in the context of low power and lossy networks. Can you please inform me if context and service discovery routing issues are out of the scope of this WG? Best regards, Georgios _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Mar 10 10:24:58 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 145D928C10E; Mon, 10 Mar 2008 10:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 RCnUta5yzM7g; Mon, 10 Mar 2008 10:24:57 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C676D3A6B90; Mon, 10 Mar 2008 10:23:57 -0700 (PDT) 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 5AC8528C13F; Mon, 10 Mar 2008 10:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 ep-cn8QJMhxc; Mon, 10 Mar 2008 10:23:52 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by core3.amsl.com (Postfix) with ESMTP id 66FEB3A6807; Mon, 10 Mar 2008 10:22:50 -0700 (PDT) Received: from [192.168.50.87] (64-199-205-2.ip.mcleodusa.net [64.199.205.2]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.2/8.13.5) with ESMTP id m2AHKQSw013267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Mar 2008 10:20:28 -0700 (PDT) Message-ID: <47D56DD6.5060009@eecs.berkeley.edu> Date: Mon, 10 Mar 2008 10:20:22 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Pieter De Mil References: <200803021021.10955.coflynn@newae.com> <001e01c87fd4$7264c4a0$8300a8c0@priveiqvfluhp9> <47D2F21A.7080309@eecs.berkeley.edu> <31227.76.160.222.32.1205108691.squirrel@webserver6.intec.ugent.be> In-Reply-To: <31227.76.160.222.32.1205108691.squirrel@webserver6.intec.ugent.be> Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] Syncronized Wake 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org responses inline Pieter De Mil wrote: > Hi Kris, All; > > Thanks for the info, the ISA100.11a MAC seems to be a very flexible MAC > layer. > There is some concern about it being too flexible :) > Some questions inline. > > >> Pieter, Collin: >> the ISA100.11a MAC is based on TSMP (http://en.wikipedia.org/wiki/TSMP), >> > although it's been made very general because of political requirements in > getting the .11 group off the ground. So it's actually possible to > configure it to be pure scheduled unicast channel-hopping TDMA, pure > single-channel CSMA, or anything in between. > >> One likely operating mode would look something like this (this is >> > basically what Wireless HART does): > >> * 10ms slot length. Single packet sent and acknowledged in a single >> > slot. Most scheduled slots would be unicast for "upstream" data > collection. Some scheduled slots would be broadcast for downstream > communication. Some might be shared bandwidth (slotted aloha). > >> Scheduled slots repeat in one or more superframes, similar to but far >> > more flexible than the 15.4 GTS mechanism. > > > Do you mean that the same scheduled slot "No 1" (assuming 1000 slots in 1 > superframe) can be configured as "upstream" at time0 and as "broasdcast > for downstream" at time0+10s? > > There are 16 cells in slot 0 that can be assigned independently without RF collision and without consideration of spatial frequency re-use. So you could have several unicast cells (A --> B) and several broadcast cells (Q --> *), and several aloha cells (* --> *), and still have some cells left to assign. All of these cells would fire every 10 seconds in a 1000 slot superframe, as you indicated. But a given cell would not change from superframe cycle to superframe cycle. (note that the actual channel used for each cell will hop pseudo-randomly - the cell gives the channel offset, not the absolute channel). > > >> * +/- 1ms guard time at the beginning of the slot to allow for >> synchronization errors. Depending on the temperature range and the >> > quality of the time-keeping at each mote, this leads to a > >> synchronization requirement of between 10 seconds and a minute. Motes >> > keep track of their last synchronization (optionally on a path-by-path > basis) and send a keepalive packet if their synch timer expires. Every > acknowledged packet carries time information in both directions, so they > reset the synchronization timer. > > > Can you disable this extra time information for some ack packets? > > hmm. Good question. You can disable the timer for certain paths (if you want to enforce regular updates between one pair of motes and not another). But I don't think that you can ignore the time update in the ack. What's the use case? > > >> For many/most motes in many/all >> networks there is no need for additional synchronization traffic above >> > and beyond normal data traffic. For low traffic networks, beaconing may > be used if it makes more sense energetically than keepalives. > > > Can you have a beacon-enabled ISA100.11a MAC? > I've read you can assign the communication cells > centrally/distributed/hybrid. Is this scheduling algorithm defined for > beacons in low traffic networks? Or is this out of scope of the standard > spec? > You can certainly distribute time via beacons if you want. If I don't hear your beacon a few times in a row, and my keepalive timer goes off, I would still send you a keepalive packet. The cell scheduling mechanism is out of scope, but assumed to be centralized in the first release of both wireless HART and forthcoming isa100. > > > >> For >> 802.15.4 radios, the overhead for maintaining +/-1ms synchronization >> > across the entire network is less than 0.01% radio duty cycle. > >> Since all motes share a common sense of time, they can pseudo-randomly >> > channel hop, dramatically reducing the chance of a link between two motes > "going down" due to external or multi-path interference. > > > Great! > > > > >> * Communication cells (={slot, channel_offset} pair) may be assigned by >> > some central manager, or via purely distributed algorithms, or some > combination of both. Enforcing unicast with no collisions, 1,600 cells > per second are available (100 slots/second * 16 channels). > >> Cells are collected into graphs. Graphs provide QoS to applications, >> > and can be turned on and off to dynamically vary power and performance > over many orders of magnitude in response to application requests. This > is where things get interesting with 6LoWPAN and RoLL. TSMP provides the > mechanisms to bind layer 4 quality of service to layer 3 routes and layer > 2 performance/power provisioning. This is critical in industrial > automation, and seems likely to be very useful in other applications as > well. I don't think that it violates anything that the IETF holds dear, > but I've been wrong about that before :) > > > :-) The need for an abstraction layer is clear, because some MAC layers do > not offer slots or synchronization. The routing layer has to know this. > > One option is defining a profile or information base that every MAC layer > (implementer) has to fill in. This profile must describe the MAC > capabilities (available channels, transmit power, synchronized, slotted, > slotlength,...). > > Someone has already started? > I don't think that anyone has started. Does that concept of a profile violate anything that ietf holds dear? ksjp > Pieter > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Mar 10 16:29:40 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 238383A69EB; Mon, 10 Mar 2008 16:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=-2.054, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 78Nl3rEpw0EG; Mon, 10 Mar 2008 16:29:39 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C2EE3A67A3; Mon, 10 Mar 2008 16:29:39 -0700 (PDT) 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 560AB3A67A3 for ; Mon, 10 Mar 2008 16:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 Vm+PUZULyx3P for ; Mon, 10 Mar 2008 16:29:37 -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 82B823A63CA for ; Mon, 10 Mar 2008 16:29:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,476,1199692800"; d="scan'208";a="8512005" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 10 Mar 2008 16:27:17 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m2ANRH1S030879; Mon, 10 Mar 2008 16:27:17 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m2ANR1nF024682; Mon, 10 Mar 2008 23:27:16 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 19:27:09 -0400 Received: from 10.21.95.210 ([10.21.95.210]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 10 Mar 2008 23:27:08 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 10 Mar 2008 19:27:07 -0400 From: JP Vasseur To: Georgios Karagiannis , Message-ID: Thread-Topic: [Roll] question regarding context and service discovery routing issues Thread-Index: AciDBkFhf8xvXO75Edy5UAANk8WjQA== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 10 Mar 2008 23:27:09.0177 (UTC) FILETIME=[42AD8690:01C88306] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1824; t=1205191637; x=1206055637; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20question=20regarding=20context =20and=20service=20discovery=0A=20routing=20issues |Sender:=20; bh=rVN0YsGNyC56+skHDdCWJF+8nr/U99t2Xd+1RSZXUvk=; b=1jlDTYTC3xpWZFhdGRaRej3rmSz+SNZ5cnUNE7Tq1S89jnZ7nNdu6DKoPO JzH9eHqoiyWDFLLRQm/FqFISsB0/qzOmKnJP3xWhM8WgWNM6iidepS4ve0sV 4k5GXX1B2E; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Roll] question regarding context and service discovery routing issues 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, > From: Georgios Karagiannis > Date: Mon, 10 Mar 2008 15:33:21 +0000 > To: > Subject: [Roll] question regarding context and service discovery routing > issues > > Dear all > > I have checked the several ROLL requirements drafts, but I could not find > a requirement that is related to context and service discovery routing! > I think that for multi-hop wireless networks, and especially adhoc sensor > networks the way of how the discovery of the environment of a device is > accomplished and how routing based on this discovery is done, are very > important capabilities that make the device usefull. > > The 6lowpan and zerocof have addressed/addressing this issue, but I am > not sure if this is done in the context of low power and lossy networks. > > Can you please inform me if context and service discovery routing issues > are out of the scope of this WG? Thanks, excellent question. It is perfectly in the scope. From the WG Charter: " ... For example path selection must be designed to take into consideration the specific power capabilities, attributes and functional characteristics of the links and nodes in the network. ...". A node constraint/attribute/service is clearly one on the specifics that a routing solution for LLN must support. Could be: - A Node constraint (level of energy, CPU, ...) - A Node attribute (e.g, to be to used to carry traffic with characteristic X, ... ) - A node service (e.g, ability to support data aggregation) May I suggest you to provide comments on the requirements IDs along these lines? Thanks. JP. > > Best regards, > Georgios > _______________________________________________ > 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 roll-bounces@ietf.org Mon Mar 10 18:44:05 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D86163A6A35; Mon, 10 Mar 2008 18:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.477 X-Spam-Level: X-Spam-Status: No, score=-100.477 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 Z76zRf-b0ass; Mon, 10 Mar 2008 18:44:05 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F17FC3A6A37; Mon, 10 Mar 2008 18:44:04 -0700 (PDT) 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 06A823A6A48 for ; Mon, 10 Mar 2008 18:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 32eyayAHK2VX for ; Mon, 10 Mar 2008 18:44:03 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id 5DA183A6865 for ; Mon, 10 Mar 2008 18:44:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 9AF65A92F2 for ; Mon, 10 Mar 2008 18:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ca3LlfqUALbz for ; Mon, 10 Mar 2008 18:41:36 -0700 (PDT) Received: from [192.168.1.110] (adsl-71-142-65-177.dsl.pltn13.pacbell.net [71.142.65.177]) by mail.sf.archrock.com (Postfix) with ESMTP id B2B69A92EA for ; Mon, 10 Mar 2008 18:41:36 -0700 (PDT) Message-ID: <47D5E34C.1050803@archrock.com> Date: Mon, 10 Mar 2008 18:41:32 -0700 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: roll@ietf.org Subject: [Roll] Internet-Drafts 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org I don't see any Internet-Drafts posted to ROLL. Has there been any progress there? I know there has been feedback/suggestions/concerns for various rl2n drafts on the mailing list before... -- Jonathan Hui _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Mar 10 20:08:35 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6AE73A6A1E; Mon, 10 Mar 2008 20:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.464 X-Spam-Level: X-Spam-Status: No, score=-101.464 tagged_above=-999 required=5 tests=[AWL=-1.027, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 RtFQIrUf-28P; Mon, 10 Mar 2008 20:08:35 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 065073A6A7A; Mon, 10 Mar 2008 20:08:35 -0700 (PDT) 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 0B9463A6A1F for ; Mon, 10 Mar 2008 20:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 PFjIBRjoJFCs for ; Mon, 10 Mar 2008 20:08:33 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id EA4553A682D for ; Mon, 10 Mar 2008 20:08:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,477,1199682000"; d="scan'208";a="1228903" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 10 Mar 2008 23:06:12 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m2B36CBj004673; Mon, 10 Mar 2008 23:06:12 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m2B364jb020418; Tue, 11 Mar 2008 03:06:12 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 23:05:13 -0400 Received: from 10.21.95.20 ([10.21.95.20]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Tue, 11 Mar 2008 03:05:12 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 10 Mar 2008 23:05:10 -0400 From: JP Vasseur To: Jonathan Hui , Message-ID: Thread-Topic: [Roll] Internet-Drafts Thread-Index: AciDJLd09iVcb+8XEdy5UAANk8WjQA== In-Reply-To: <47D5E34C.1050803@archrock.com> Mime-version: 1.0 X-OriginalArrivalTime: 11 Mar 2008 03:05:13.0286 (UTC) FILETIME=[B96A1E60:01C88324] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1223; t=1205204772; x=1206068772; c=relaxed/simple; s=rtpdkim1001; 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]=20Internet-Drafts |Sender:=20 |To:=20Jonathan=20Hui=20,=20; bh=U2m/gV1cDLIHmDA/haK6Uj/W1/DiBn9HFkSam/tHURU=; b=gqgx+NZUOZGSEkbvfTxdDGsU4Se7kX7JAqfGIFpMZg9ItxjWPxvJ25iA6P l2Ca8aA0f2r8CFFgZFqVmm0GsxFUVOjfdGHRFNLvzqciI6Y0uOQsYLxDFVRN gfPXRN09J2; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Roll] Internet-Drafts 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Jonathan, > From: Jonathan Hui > Date: Mon, 10 Mar 2008 18:41:32 -0700 > To: > Subject: [Roll] Internet-Drafts > > > I don't see any Internet-Drafts posted to ROLL. Internet drafts only appears on the ROLL web page when they are WG IDs. But there are several IDs (individual submissions at this point): http://www.ietf.org/internet-drafts/draft-brandt-roll-home-routing-reqs-00.t xt http://www.ietf.org/internet-drafts/draft-dohler-roll-urban-routing-reqs-00. txt http://www.ietf.org/internet-drafts/draft-levis-roll-overview-protocols-00.t xt http://www.ietf.org/internet-drafts/draft-pister-rl2n-indus-routing-reqs-00. txt Has there been any > progress there? I know there has been feedback/suggestions/concerns for > various rl2n drafts on the mailing list before... Indeed on the rsn@ietf.org ML. Now that ROLL is formed (a few weeks ago), feel free to send your comments on these IDs and contribute, your expertise in this area will be very much appreciated. Thanks. JP. > > -- > Jonathan Hui > _______________________________________________ > 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 roll-bounces@ietf.org Mon Mar 10 20:17:53 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5ED03A6828; Mon, 10 Mar 2008 20:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.54 X-Spam-Level: X-Spam-Status: No, score=-100.54 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 XaXodSz8YOZd; Mon, 10 Mar 2008 20:17:51 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA4103A6931; Mon, 10 Mar 2008 20:17:51 -0700 (PDT) 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 802993A6828 for ; Mon, 10 Mar 2008 20:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 A0WIJpdRRQsF for ; Mon, 10 Mar 2008 20:17:49 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id 2E9C23A6A83 for ; Mon, 10 Mar 2008 20:17:02 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 91FD2A9314; Mon, 10 Mar 2008 20:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxBpmMNyn2cM; Mon, 10 Mar 2008 20:14:35 -0700 (PDT) Received: from [192.168.1.110] (adsl-71-142-65-177.dsl.pltn13.pacbell.net [71.142.65.177]) by mail.sf.archrock.com (Postfix) with ESMTP id C0012A9311; Mon, 10 Mar 2008 20:14:35 -0700 (PDT) Message-ID: <47D5F919.2060606@archrock.com> Date: Mon, 10 Mar 2008 20:14:33 -0700 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: JP Vasseur References: In-Reply-To: Cc: roll@ietf.org Subject: Re: [Roll] Internet-Drafts 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Ah, okay. I simply went to the WG status page (http://tools.ietf.org/wg/roll/) and didn't see any documents listed. Typically there is a section for individual submissions below the section for working group documents. It would be nice to have individual submissions on the WG status page as well as it makes them easier to track. -- Jonathan Hui JP Vasseur wrote: > Hi Jonathan, > > >> From: Jonathan Hui >> Date: Mon, 10 Mar 2008 18:41:32 -0700 >> To: >> Subject: [Roll] Internet-Drafts >> >> >> I don't see any Internet-Drafts posted to ROLL. > > Internet drafts only appears on the ROLL web page when they are WG IDs. > > But there are several IDs (individual submissions at this point): > http://www.ietf.org/internet-drafts/draft-brandt-roll-home-routing-reqs-00.t > xt > http://www.ietf.org/internet-drafts/draft-dohler-roll-urban-routing-reqs-00. > txt > http://www.ietf.org/internet-drafts/draft-levis-roll-overview-protocols-00.t > xt > http://www.ietf.org/internet-drafts/draft-pister-rl2n-indus-routing-reqs-00. > txt > > Has there been any >> progress there? I know there has been feedback/suggestions/concerns for >> various rl2n drafts on the mailing list before... > > Indeed on the rsn@ietf.org ML. Now that ROLL is formed (a few weeks ago), > feel free to send your comments on these IDs and contribute, your expertise > in this area will be very much appreciated. > > Thanks. > > JP. > >> -- >> Jonathan Hui >> _______________________________________________ >> 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 roll-bounces@ietf.org Mon Mar 10 20:26:31 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 940563A6B2B; Mon, 10 Mar 2008 20:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.178 X-Spam-Level: X-Spam-Status: No, score=-100.178 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 AQPa9Lb84CQ6; Mon, 10 Mar 2008 20:26:30 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 227AF3A6AA5; Mon, 10 Mar 2008 20:26:30 -0700 (PDT) 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 3A7373A6A39; Mon, 10 Mar 2008 20:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 gTTSpPk4NtzP; Mon, 10 Mar 2008 20:26:28 -0700 (PDT) Received: from cypress.ugent.be (cypress.ugent.be [157.193.71.48]) by core3.amsl.com (Postfix) with ESMTP id 19A8A3A67FC; Mon, 10 Mar 2008 20:26:27 -0700 (PDT) Received: from gorilla.ugent.be (HELO localhost) ([157.193.49.20]) by cypress.ugent.be with ESMTP; 11 Mar 2008 04:24:07 +0100 Received: from cypress.ugent.be ([157.193.71.48]) by localhost (gorilla.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id 06489-09-3; Tue, 11 Mar 2008 04:24:07 +0100 (CET) Received: from mail4.intec.ugent.be ([157.193.214.4]) by cypress.ugent.be with ESMTP; 11 Mar 2008 04:24:07 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMeX1UedwdYE/2dsb2JhbACrKQ Received: from localhost (localhost [127.0.0.1]) by mail4.intec.ugent.be (Postfix) with ESMTP id 2F1B340B2BB; Tue, 11 Mar 2008 04:23:57 +0100 (CET) Received: from mail4.intec.ugent.be ([127.0.0.1]) by localhost (mail4.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEPCCzsJ6GEr; Tue, 11 Mar 2008 04:23:57 +0100 (CET) Received: from webserver6.intec.ugent.be (webserver6.intec.ugent.be [157.193.214.11]) by mail4.intec.ugent.be (Postfix) with ESMTP id 0386140B2BA; Tue, 11 Mar 2008 04:23:56 +0100 (CET) Received: from 76.160.222.32 (SquirrelMail authenticated user pdemil) by webserver6.intec.ugent.be with HTTP; Tue, 11 Mar 2008 04:24:07 +0100 (CET) Message-ID: <56871.76.160.222.32.1205205847.squirrel@webserver6.intec.ugent.be> In-Reply-To: <47D56DD6.5060009@eecs.berkeley.edu> References: <200803021021.10955.coflynn@newae.com> <001e01c87fd4$7264c4a0$8300a8c0@priveiqvfluhp9> <47D2F21A.7080309@eecs.berkeley.edu> <31227.76.160.222.32.1205108691.squirrel@webserver6.intec.ugent.be> <47D56DD6.5060009@eecs.berkeley.edu> Date: Tue, 11 Mar 2008 04:24:07 +0100 (CET) From: "Pieter De Mil" To: "Kris Pister" User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by UGent DICT Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] Syncronized Wake 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org >> Can you disable this extra time information for some ack packets? >> > hmm. Good question. You can disable the timer for certain paths (if > you want to enforce regular updates between one pair of motes and not > another). But I don't think that you can ignore the time update in the > ack. What's the use case? In a network with a lot of traffic, I can imagine that this time information in the ack's is not always necessary for the motes to stay synchronized. It is necessary sometimes, but not for all successive acks. Disabling this time information in the ack = saving battery juice. To keep things simple, it may be OK to keep the time info always in the ack. I was just wondering if the DLL was *that* flexible :-) Pieter _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Mar 11 02:36:37 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B88333A6D58; Tue, 11 Mar 2008 02:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.814 X-Spam-Level: X-Spam-Status: No, score=-99.814 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, 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 dnprdeWynNcC; Tue, 11 Mar 2008 02:36:33 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2FE73A6D4D; Tue, 11 Mar 2008 02:36:33 -0700 (PDT) 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 2788B28C1DF for ; Tue, 11 Mar 2008 02:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 AsFQOITV7NOz for ; Tue, 11 Mar 2008 02:36:32 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.234]) by core3.amsl.com (Postfix) with ESMTP id CF5963A6D58 for ; Tue, 11 Mar 2008 02:36:31 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id i26so2733139wxd.31 for ; Tue, 11 Mar 2008 02:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=x9gzp1LPDwpSY6g5+aHC/l7OPkU9y65h31jTF9Jq5yM=; b=x9inOMeWh80KtI3qrLMQDbBBcwTmXLc7CYhbBzpTc0tpcKnX1At6WCEkatIB+UMwAPcle2UBrFigpoY6/z941CKvpmM7d/+cnEzj5rO0R65/mDDoPAmTWAge5hEw31owdpTNy3SdjjT5KUVu+QeaKwu/Qmpd9QNmVXZ+kruSXZA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=WsPA0zbU8/6E7GjmXbgkET4VgS9JuWS3fAxp4yMZTsgrZ9LUNWWBdMfYivbRL7Leb9xw1BHKFdJoiRk+V7AlMc8Uv2Zu8Ji6lmQooduE0qK9wxamHyTtGBA/L69Ip8JXh+7AX5Ts5HlqLCdcHq3+/kbloWyWZWiStj0NXmnu5Wc= Received: by 10.115.110.6 with SMTP id n6mr4602079wam.92.1205228051170; Tue, 11 Mar 2008 02:34:11 -0700 (PDT) Received: by 10.114.14.6 with HTTP; Tue, 11 Mar 2008 02:34:11 -0700 (PDT) Message-ID: <86c3ed7b0803110234o1384d8c8o38f7f7e7ae06fd@mail.gmail.com> Date: Tue, 11 Mar 2008 10:34:11 +0100 From: "Miguel Sanchez" To: "Pieter De Mil" In-Reply-To: <56871.76.160.222.32.1205205847.squirrel@webserver6.intec.ugent.be> MIME-Version: 1.0 References: <200803021021.10955.coflynn@newae.com> <001e01c87fd4$7264c4a0$8300a8c0@priveiqvfluhp9> <47D2F21A.7080309@eecs.berkeley.edu> <31227.76.160.222.32.1205108691.squirrel@webserver6.intec.ugent.be> <47D56DD6.5060009@eecs.berkeley.edu> <56871.76.160.222.32.1205205847.squirrel@webserver6.intec.ugent.be> X-Google-Sender-Auth: f653a0c32535f201 Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] Syncronized Wake 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: , Content-Type: multipart/mixed; boundary="===============0274537218==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0274537218== Content-Type: multipart/alternative; boundary="----=_Part_2012_7879014.1205228051158" ------=_Part_2012_7879014.1205228051158 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tue, Mar 11, 2008 at 4:24 AM, Pieter De Mil wrote: > > >> Can you disable this extra time information for some ack packets? > >> > > hmm. Good question. You can disable the timer for certain paths (if > > you want to enforce regular updates between one pair of motes and not > > another). But I don't think that you can ignore the time update in the > > ack. What's the use case? > > > In a network with a lot of traffic, I can imagine that this time > information in the ack's is not always necessary for the motes to stay > synchronized. It is necessary sometimes, but not for all successive acks. > Disabling this time information in the ack =3D saving battery juice. > To keep things simple, it may be OK to keep the time info always in the > ack. I was just wondering if the DLL was *that* flexible :-) > Please bear in mind that for some radio hardware (802.15.4) the transmissio= n and reception power consumption is nearly the same, so not transmitting som= e bits (the time) only helps if you then can shut off the radio receiver sooner. Cheers, Miguel S=E1nchez ------=_Part_2012_7879014.1205228051158 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

On Tue, Mar 11, 2008 at 4:24 AM, Pieter = De Mil <pieter.demil@inte= c.ugent.be> wrote:

>> Can you disable this extra time information for some ack packets?<= br> >>
> hmm.  Good question.  You can disable the timer for certain = paths (if
> you want to enforce regular updates between one pair of motes and not<= br> > another).  But I don't think that you can ignore the time upd= ate in the
> ack.  What's the use case?


In a network with a lot of traffic, I can imagine that this time
information in the ack's is not always necessary for the motes to stay<= br> synchronized. It is necessary sometimes, but not for all successive acks. Disabling this time information  in the ack =3D saving battery juice.<= br> To keep things simple, it may be OK to keep the time info always in the
ack. I was just wondering if the DLL was *that* flexible :-)

Ple= ase bear in mind that for some radio hardware (802.15.4) the transmission a= nd reception power consumption is nearly the same, so not transmitting some= bits (the time) only helps if you then can shut off the radio receiver soo= ner.


Cheers,

Miguel S=E1nchez

------=_Part_2012_7879014.1205228051158-- --===============0274537218== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0274537218==-- From roll-bounces@ietf.org Tue Mar 11 07:05:29 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A10428C445; Tue, 11 Mar 2008 07:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.053 X-Spam-Level: X-Spam-Status: No, score=-101.053 tagged_above=-999 required=5 tests=[AWL=-0.616, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 XBroUt3TtL30; Tue, 11 Mar 2008 07:05:23 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A01A28C3E0; Tue, 11 Mar 2008 07:05:23 -0700 (PDT) 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 02BD028C376 for ; Tue, 11 Mar 2008 06:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 CNblfbulXrRv for ; Tue, 11 Mar 2008 06:53:01 -0700 (PDT) Received: from smtp-4.hut.fi (smtp-4.hut.fi [130.233.228.94]) by core3.amsl.com (Postfix) with ESMTP id D89933A6A91 for ; Tue, 11 Mar 2008 06:53:00 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id m2BDoPok028100; Tue, 11 Mar 2008 15:50:25 +0200 Received: from smtp-4.hut.fi ([130.233.228.94]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 16761-07-4; Tue, 11 Mar 2008 15:50:24 +0200 (EET) Received: from [NON-IPv4] (vipunen.hut.fi [130.233.228.9]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id m2BDoBqO027942; Tue, 11 Mar 2008 15:50:11 +0200 Date: Tue, 11 Mar 2008 15:50:11 +0200 (EET) From: Jukka MJ Manner To: JP Vasseur In-Reply-To: Message-ID: References: MIME-Version: 1.0 X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi X-Mailman-Approved-At: Tue, 11 Mar 2008 07:05:21 -0700 Cc: roll@ietf.org Subject: Re: [Roll] question regarding context and service discovery routing issues 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org I would also be interested to work on this topic. I'll provide comments to the I-Ds. Jukka On Mon, 10 Mar 2008, JP Vasseur wrote: > Hi, > > >> From: Georgios Karagiannis >> Date: Mon, 10 Mar 2008 15:33:21 +0000 >> To: >> Subject: [Roll] question regarding context and service discovery routing >> issues >> >> Dear all >> >> I have checked the several ROLL requirements drafts, but I could not find >> a requirement that is related to context and service discovery routing! >> I think that for multi-hop wireless networks, and especially adhoc sensor >> networks the way of how the discovery of the environment of a device is >> accomplished and how routing based on this discovery is done, are very >> important capabilities that make the device usefull. >> >> The 6lowpan and zerocof have addressed/addressing this issue, but I am >> not sure if this is done in the context of low power and lossy networks. >> >> Can you please inform me if context and service discovery routing issues >> are out of the scope of this WG? > > Thanks, excellent question. > > It is perfectly in the scope. From the WG Charter: " ... For > example path selection must be designed to take into consideration the > specific power capabilities, attributes and functional characteristics > of the links and nodes in the network. ...". > > A node constraint/attribute/service is clearly one on the specifics that a > routing solution for LLN must support. > > Could be: > - A Node constraint (level of energy, CPU, ...) > - A Node attribute (e.g, to be to used to carry traffic with characteristic > X, ... ) > - A node service (e.g, ability to support data aggregation) > > May I suggest you to provide comments on the requirements IDs along these > lines? > > Thanks. > > JP. > >> >> Best regards, >> Georgios >> _______________________________________________ >> 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 roll-bounces@ietf.org Tue Mar 11 22:43:30 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C42728C529; Tue, 11 Mar 2008 22:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 yPBnVxDpcD6W; Tue, 11 Mar 2008 22:43:29 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2393C3A6E1A; Tue, 11 Mar 2008 22:43:29 -0700 (PDT) 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 A14A828C4C7 for ; Tue, 11 Mar 2008 22:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 TI8Ius6aXUyV for ; Tue, 11 Mar 2008 22:43:27 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id 6139F3A6E0A for ; Tue, 11 Mar 2008 22:43:27 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id A4A38A92F4 for ; Tue, 11 Mar 2008 22:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+5DSRaT++KW for ; Tue, 11 Mar 2008 22:41:02 -0700 (PDT) Received: from [10.150.135.168] (72-255-5-190.client.stsn.net [72.255.5.190]) by mail.sf.archrock.com (Postfix) with ESMTP id C8509A92EC for ; Tue, 11 Mar 2008 22:41:01 -0700 (PDT) Message-ID: <47D76CE9.8010402@archrock.com> Date: Tue, 11 Mar 2008 22:40:57 -0700 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: roll@ietf.org Subject: [Roll] Urban WSNs Requirements Feedback 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Overall, I think this is an excellent first draft. I like how it starts off by describing the overall operational scenario, defines the kinds of nodes in use, the nature of the traffic (frequency, direction of flow, etc.). Next section describes the complete use-case beginning with deployment. It makes suggestions on what is important to the use-case w.r.t. the routing protocol but leaves the specific requirement statements for the requirements section. Specific comments: Section 2: Excellent section. Section 3: Overall, great section. Clearly presents the use-cases while suggesting what is important in a routing protocol to address those use-cases. Might also want to add a section about how nodes are phased out, if at all. That would complete the whole life-cycle. Section 4: I'd drop "unique" from the title. Many of these requirements are applicable to other application scenarios. Section 4.3: IPv6 only supports a notion of multicast. The formation of groups, in my mind, is a mechanism distinct from routing and arguably isn't within scope of ROLL. Multicast routing is responsible for delivering messages to two or more nodes in a group. We should separate these two concepts. Section 4.4: I think this is the right way to state it. Suggesting that the traffic patterns may allow certain optimizations, but that such optimizations aren't required. Section 4.5: A routing protocol that operates across a variety of link technologies in a single network is expected within ROLL. Maybe you meant to say that the routing protocol SHOULD optimize for the heterogeneous node capabilities. But this could also be folded into constraint-based routing. So not sure if we need this separate from requirement 4.2. Section 4.6: As I mentioned with the Home Automation draft, the IP architecture doesn't support a notion of groupcast. Maybe we should leave such a notion to the application-layer. Section 4.7: You might want to be a little more suggestive as to what latencies are acceptable. -- Jonathan Hui _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Mar 11 22:44:43 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C87133A6E0B; Tue, 11 Mar 2008 22:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.797 X-Spam-Level: X-Spam-Status: No, score=-100.797 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 W8+eQu0TKaMw; Tue, 11 Mar 2008 22:44:42 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA0B3A6DE7; Tue, 11 Mar 2008 22:44:42 -0700 (PDT) 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 274463A6DF2 for ; Tue, 11 Mar 2008 22:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 ABSRm+iTLo2Y for ; Tue, 11 Mar 2008 22:44:41 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id 3748B3A6C00 for ; Tue, 11 Mar 2008 22:44:41 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id A2F95A92FC for ; Tue, 11 Mar 2008 22:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-tBVM67orjg for ; Tue, 11 Mar 2008 22:42:15 -0700 (PDT) Received: from [10.150.135.168] (72-255-5-190.client.stsn.net [72.255.5.190]) by mail.sf.archrock.com (Postfix) with ESMTP id 9445AA92F6 for ; Tue, 11 Mar 2008 22:42:15 -0700 (PDT) Message-ID: <47D76D36.9080501@archrock.com> Date: Tue, 11 Mar 2008 22:42:14 -0700 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: roll@ietf.org Subject: [Roll] Home Requirements Feedback 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Overall, great set of use-cases that define the properties of a home automation application. However, I would prefer to see any requirement statements (e.g. MUST/SHOULD/etc) left for the Routing Requirements section. I think it's better to first establish the nature of the application before going into the requirements. Though, I do think it's appropate to suggest what requirements are important to consider in each scenario. This leads into my next comment, I think there should be a section (either in use-cases or following use-cases) that clearly describes the expected operational architecture. For example, the node architecture (processor, radios, power, etc.), how they are physically laid out, what environments are they expected to be in (yes, I know, in the Home, but is outside, inside, separated by concrete walls, etc.). I would also fold the Traffic Pattern section (Section 5) into this. Having a clear understanding of the operational architecture, along with the use-cases, will make it very clear in what conditions the routing requirements must be satisfied. The draft does state a good set of requirements (e.g. latency, node-join times, constrained routing, etc.). Though there are places where I think the requirements are being over-specified. My feeling is that these documents should state the functional requirements of a dynamic routing protocol, but leave the "how" open to the designers/implementors of such a protocol. For example, Section 5 seems to require optimal any-to-any routing that doesn't utilize a tree. I don't think Requirement draft is the right place to make such specific claims. Also, we should keep the requirements concise. No need to have too much surrounding explanation if the earlier sections are clear about the use-cases and operational scenario. I understand the need for groupcast, but it's unclear to me how this will be done within the IP architecture. Have you considered, possibly, pushing such functions to the application-layer? What this means is that the routing topology gives the necessary support to implement groupcast at the application, but does not implement groupcast directly. Specific comments: Section 3.1: At what layer does the reference to "broadcast" refer to? IPv6 technically doesn't have a broadcast primitive. At the physical layer, everything is broadcast. Section 3.2: I understand the need to support latencies at human time scales and that multiple paths may help meet those latency requirements. However, I think we should leave the "multiple path" requirement out of the routing requirements. Instead, we should let the requirements combined with the failure model drive what the routing protocol should do. Section 3.3: I think it would be more useful to include some notion of route discovery time here, rather than whether or not nodes are scanning, discovering, refining, etc. Section 3.4: Good example that could feed into the "architecture" section. Section 3.5: I think this requirement needs to be reworded into something closer to "constraint-based" routing. The current wording now leaves a bunch of questions in my mind. For example, what if neighboring powered routers do exist, but do not support the latency guarantees? Is routing through battery-powered acceptable in these cases? Section 3.6: Another good example that can feed into the operational architecture section. Sections 3.7 and 3.8: Looking forward to these. Section 4: We should distill each requirement to a concise statement, and leave any of the explanatory text to earlier sections. Section 4.1: What do you mean by multiple scopes? The RFC 4007 has a clear definition of what IPv6 scopes are, but I'm not sure this is what you mean. Also, see my earlier comment about groupcast and whether this should really be provided completely by IP. Section 4.2: Good requirement. Section 4.3: The mobility scenarios should be clearly stated in the operational scenario section. For example, how do the nodes move w.r.t. each other, how quickly, what kind of nodes are moving. Then we get a clear understanding of what the convergence-time requirement really is. Section 4.5: It's good to provide some explanation of the expected failure model (possibly in the architecture section). Is the goal to converge if a single link/node fails? What if multiple of them fail, due to some local interference? Section 5: I think you're over constraining the requirements here. There's already a latency requirement, so why constrain how those latency requirements are met? It's the job the designers/implementors to choose. -- Jonathan Hui _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Mar 11 22:45:11 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50A9A3A6E27; Tue, 11 Mar 2008 22:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.732 X-Spam-Level: X-Spam-Status: No, score=-100.732 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 LFuBtCN8SQCU; Tue, 11 Mar 2008 22:45:10 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 196AB3A6DB8; Tue, 11 Mar 2008 22:45:10 -0700 (PDT) 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 B0B563A6DF2 for ; Tue, 11 Mar 2008 22:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 c9bnlJkAYuwL for ; Tue, 11 Mar 2008 22:45:05 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id D0A6A3A6DB8 for ; Tue, 11 Mar 2008 22:45:04 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 3B96EA92F7 for ; Tue, 11 Mar 2008 22:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKJLPhB-QnMp for ; Tue, 11 Mar 2008 22:42:44 -0700 (PDT) Received: from [10.150.135.168] (72-255-5-190.client.stsn.net [72.255.5.190]) by mail.sf.archrock.com (Postfix) with ESMTP id 37BD7A92F6 for ; Tue, 11 Mar 2008 22:42:44 -0700 (PDT) Message-ID: <47D76D53.6060409@archrock.com> Date: Tue, 11 Mar 2008 22:42:43 -0700 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: roll@ietf.org Subject: [Roll] Industrial Requirements Feedback 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Overall, this is a great start. As a high-level structure, I would prefer to see up front a complete description of the use-cases and operation scenario. This would allow the requirements section to provide a list of concise statements about the requirements. It makes it much easier for a protocol designer/implementor to verify which requirements are being addressed. There are various L2 specific things sprinkled throughout the draft. ROLL is L2 agnostic, so we should limit these things. For example, there's specific mention of 802.15.4's bit-rates and even a requirement for multiple access points and load distribution when throughput exceeds 100 kbps. Do we still want to require this even when a different L2 technology can provide 100 kbps with ease? Also, there's various requirements that seem specific to a slotted L2. Any assumptions about the link should be generally applicable to any L2. The draft also mentions various QoS requirements, though I think some of them aren't really applicable to routing but rather forwarding. These should be decoupled and we should keep our focus on routing. Specific comments: Section 2: A good section overall, captures a good chunk of the application scenario. I'd still prefer to see some more about the expected node capabilities, how they're physically laid out, what the failure model is, what the mobility scenarios are, etc. Section 2.1: Good section in defining the different traffic classes. But it would be good to explicitly state where the traffic is going and whether this ever changes under different scenarios. At the end, there's a routing requirement statement. I think such statements should be left for the requirements section. My comment w.r.t. this specific requirement is that I don't think it's really in the scope of a requirements document. It's describing how to meet the routing requirements in this draft. Section 3: The QoS section here seems to be addressing more than routing, but the forwarding architecture as well. For example, I see bandwidth and latency as directly applicable to routing, but transmission phase and priority seem more applicable to forwarding. Note that QoS, in many cases, is provided completely by forwarding mechanisms. I think it's good to separate these issues since we're primarily focused on routing. Also, there is mention about L2 specifics here, however the ROLL WG is L2 agnostic. Any assumptions about the link should be generally applicable to other links as well. Section 3.1: Again, mentions specifics about the L2 protocol. Maybe we can just drop "slotted-link". Section 4: I think the network topology assumptions should be ahead of the routing requirements. The requirement for multiple access points should be in the requirements section. Requirements that assume specific L2 properties should be left out. ROLL is L2 agnostic and requiring particular features when throughput exceeds a 100 kbps isn't appropriate, especially if other L2 technologies may support >100 kbps with ease. Section 6: IPv6 does not support a notion of broadcast, only multicast. Also, the Internet architecture has generally decoupled unicast routing from multicast routing. So I think we can't require a single routing protocol to provide both unicast and multicast, but we not disallow it if one protocol can satisfy both. Section 7: Would it be more appropriate to state what the actual route establishment/convergence time requirements are? The re-optimization rules in this draft don't give a clear indication of the actual application requirement. Section 8: I like how the application scenario and requirements here are very concrete. This is, in general, the kind of requirements I like to see in these kinds of drafts. Minor nit with "reconfiguring graphs" as such reconfiguration may not actually require the routing topology to change. -- Jonathan Hui _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Mar 12 01:49:16 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC73828C5BE; Wed, 12 Mar 2008 01:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.653 X-Spam-Level: X-Spam-Status: No, score=-100.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 J8JgRsGfgZGy; Wed, 12 Mar 2008 01:49:11 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BCE228C5A5; Wed, 12 Mar 2008 01:49:11 -0700 (PDT) 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 556FD28C5BF for ; Wed, 12 Mar 2008 01:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 lg0cg2GTYDbD for ; Wed, 12 Mar 2008 01:49:09 -0700 (PDT) Received: from scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by core3.amsl.com (Postfix) with ESMTP id 1201128C54D for ; Wed, 12 Mar 2008 01:49:08 -0700 (PDT) Received: from castor.cttc.es (castor.cttc.es [84.88.62.196]) by scorpius.cttc.es (8.13.8/8.13.5) with ESMTP id m2C8jIUs029689 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 12 Mar 2008 09:45:18 +0100 Received: from CTTCPCMDOHLER (pcmdohler.cttc.es [84.88.61.89]) (authenticated bits=0) by castor.cttc.es (8.13.2/8.13.3) with ESMTP id m2C8kPjp005089 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 12 Mar 2008 09:46:25 +0100 Message-Id: <200803120846.m2C8kPjp005089@castor.cttc.es> From: "Mischa Dohler" To: "'Jonathan Hui'" , Date: Wed, 12 Mar 2008 09:44:37 +0100 Organization: CTTC MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciEA+h32GhQJka7QLWX0dbju3UG4AAF4Iiw In-Reply-To: <47D76CE9.8010402@archrock.com> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (castor.cttc.es [84.88.62.196]); Wed, 12 Mar 2008 09:46:25 +0100 (CET) X-Scanned-By: MIMEDefang 2.57 on 84.88.62.197 Subject: Re: [Roll] Urban WSNs Requirements Feedback X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mischa.dohler@cttc.es List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Thanks a lot, Jonathan, for this in-depth feedback! Please, see my replies in-line. With kind regards, Mischa. -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jonathan Hui Sent: Wednesday, March 12, 2008 6:41 AM To: roll@ietf.org Subject: [Roll] Urban WSNs Requirements Feedback Overall, I think this is an excellent first draft. I like how it starts off by describing the overall operational scenario, defines the kinds of nodes in use, the nature of the traffic (frequency, direction of flow, etc.). Next section describes the complete use-case beginning with deployment. It makes suggestions on what is important to the use-case w.r.t. the routing protocol but leaves the specific requirement statements for the requirements section. Specific comments: Section 2: Excellent section. Section 3: Overall, great section. Clearly presents the use-cases while suggesting what is important in a routing protocol to address those use-cases. Might also want to add a section about how nodes are phased out, if at all. That would complete the whole life-cycle. MISCHA: I am not sure what exactly you mean with "phased out" but I think we catered for this with the following phrase in that section: "Differentiation should be made between node disassociation, where the node has enough time to inform the network about its removal, and disappearance, where the node simply disappears without prior notification." Section 4: I'd drop "unique" from the title. Many of these requirements are applicable to other application scenarios. MISCHA: Yes, you are right. We will drop this in our next draft we will issue with my ex-colleagues at France Telecom. Section 4.3: IPv6 only supports a notion of multicast. The formation of groups, in my mind, is a mechanism distinct from routing and arguably isn't within scope of ROLL. Multicast routing is responsible for delivering messages to two or more nodes in a group. We should separate these two concepts. MISCHA: I totally agree with you that the organization process is distinct from the routing problem, albeit correlated. However, since we operate on the (energy) limit of design, we believe that the way the network is organized and hence the way routing is facilitated should also be dealt with in ROLL. Section 4.4: I think this is the right way to state it. Suggesting that the traffic patterns may allow certain optimizations, but that such optimizations aren't required. Section 4.5: A routing protocol that operates across a variety of link technologies in a single network is expected within ROLL. Maybe you meant to say that the routing protocol SHOULD optimize for the heterogeneous node capabilities. But this could also be folded into constraint-based routing. So not sure if we need this separate from requirement 4.2. MISCHA: This was one of the last sections we inserted. We did this to explicitly emphasize that heterogeneous design is a must. However, we didn't want to go as far as to say that you need to optimize it because this inherently means that there ought to be a strong coupling between these heterogeneous technologies which I am not sure we can guarantee in ROLL. I prefer to leave it as is. Section 4.6: As I mentioned with the Home Automation draft, the IP architecture doesn't support a notion of groupcast. Maybe we should leave such a notion to the application-layer. MISCHA: Ok. Do you think that this section ought to be removed or could we leave it just to make the point that this problem should be addressed? Section 4.7: You might want to be a little more suggestive as to what latencies are acceptable. MISCHA: Good idea: I will cross-check with my ex-colleagues in France Telecom and also with Kris and David to get some reasonable numbers. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Mar 12 07:43:03 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADABD3A6A99; Wed, 12 Mar 2008 07:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.482 X-Spam-Level: X-Spam-Status: No, score=-100.482 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 K+vh-IhmYX1B; Wed, 12 Mar 2008 07:43:02 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93BB53A6E3D; Wed, 12 Mar 2008 07:43:02 -0700 (PDT) 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 19FAD3A6D8C for ; Wed, 12 Mar 2008 07:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 xXPGoFd8fMg3 for ; Wed, 12 Mar 2008 07:42:56 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id 6EB2F3A6B2D for ; Wed, 12 Mar 2008 07:42:25 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 10A5AA92F7; Wed, 12 Mar 2008 07:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epy9NhngLj7w; Wed, 12 Mar 2008 07:40:00 -0700 (PDT) Received: from [130.129.22.182] (dhcp-16b6.ietf71.ietf.org [130.129.22.182]) by mail.sf.archrock.com (Postfix) with ESMTP id 2150AA92EA; Wed, 12 Mar 2008 07:40:00 -0700 (PDT) Message-ID: <47D7EB3B.1030704@archrock.com> Date: Wed, 12 Mar 2008 07:39:55 -0700 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: mischa.dohler@cttc.es References: <200803120846.m2C8kPjp005089@castor.cttc.es> In-Reply-To: <200803120846.m2C8kPjp005089@castor.cttc.es> Cc: roll@ietf.org Subject: Re: [Roll] Urban WSNs Requirements Feedback 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Mischa, thanks for the reply. See below: Mischa Dohler wrote: > Section 3: Overall, great section. Clearly presents the use-cases > while suggesting what is important in a routing protocol to address > those use-cases. Might also want to add a section about how nodes are > phased out, if at all. That would complete the whole life-cycle. > > MISCHA: I am not sure what exactly you mean with "phased out" but I think we > catered for this with the following phrase in that section: "Differentiation > should be made between node disassociation, where the node has enough time > to inform the network about its removal, and disappearance, where the node > simply disappears without prior notification." Ah, okay, so there is some statement buried in there. I still prefer seeing some statement that says what the expected decommissioning procedure is from the user's point-of-view. If that's simply to remove the node or battery from the node that's fine. Or is it really that the user/network manager needs to somehow inform the node/network that the node will be removed sometime soon so that the network can adapt if needed. > Section 4.3: IPv6 only supports a notion of multicast. The formation > of groups, in my mind, is a mechanism distinct from routing and > arguably isn't within scope of ROLL. Multicast routing is responsible > for delivering messages to two or more nodes in a group. We should > separate these two concepts. > > MISCHA: I totally agree with you that the organization process is distinct > from the routing problem, albeit correlated. However, since we operate on > the (energy) limit of design, we believe that the way the network is > organized and hence the way routing is facilitated should also be dealt with > in ROLL. I understand your point. I guess it wasn't clear to me what it meant for the routing protocol to "support the formation and identification of groups of field devices in the network." If the notion is that the routing topology should support some other protocol that is doing group formation, it makes it difficult to know exactly what is required until that protocol is formed. Note that there's a bunch of other things that may be required for creating such groups, including how addresses are assigned, the nature of such groups (can the span arbitrary nodes across the entire network or is there some spatial locality), while these things are out of scope of this specific draft they are related in that a routing protocol may be able to take advantage of these features. So I'm just looking for some clarification as to what is really intended here. > Section 4.5: A routing protocol that operates across a variety of link > technologies in a single network is expected within ROLL. Maybe you > meant to say that the routing protocol SHOULD optimize for the > heterogeneous node capabilities. But this could also be folded into > constraint-based routing. So not sure if we need this separate from > requirement 4.2. > > MISCHA: This was one of the last sections we inserted. We did this to > explicitly emphasize that heterogeneous design is a must. However, we didn't > want to go as far as to say that you need to optimize it because this > inherently means that there ought to be a strong coupling between these > heterogeneous technologies which I am not sure we can guarantee in ROLL. I > prefer to leave it as is. The requirement is a SHOULD so there's flexibility not to do so if you absolutely can't. Maybe 'optimize' is too strong a word, but say something along the lines of "SHOULD attempt to take advantage of additional resources when/where they exist" rather than "support a variety of different devices without compromising the operability and energy efficiency of the network." > Section 4.6: As I mentioned with the Home Automation draft, the IP > architecture doesn't support a notion of groupcast. Maybe we should > leave such a notion to the application-layer. > > MISCHA: Ok. Do you think that this section ought to be removed or could we > leave it just to make the point that this problem should be addressed? Well, this section also addresses multicast. So it is a good idea to leave it in. Also, we should stop referring to *the* routing protocol, since multicast and unicast may be supported by different routing protocols. Regarding groupcast, it might be good to state the expected traffic model and make some point to support it. But requiring the routing protocol to support groupcast directly is a bit unclear since IP (today) doesn't really support it. Thanks. -- Jonathan Hui _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Mar 12 08:19:59 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B9003A6E82; Wed, 12 Mar 2008 08:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.707 X-Spam-Level: X-Spam-Status: No, score=-100.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 ycffuBVNprgV; Wed, 12 Mar 2008 08:19:57 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0FB228C77A; Wed, 12 Mar 2008 08:19:35 -0700 (PDT) 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 5E56628C78D for ; Wed, 12 Mar 2008 08:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 AcFrKo+AKldF for ; Wed, 12 Mar 2008 08:19:33 -0700 (PDT) Received: from scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by core3.amsl.com (Postfix) with ESMTP id 587B728C6AB for ; Wed, 12 Mar 2008 08:19:08 -0700 (PDT) Received: from castor.cttc.es (castor.cttc.es [84.88.62.196]) by scorpius.cttc.es (8.13.8/8.13.5) with ESMTP id m2CFF03X013234 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 12 Mar 2008 16:15:00 +0100 Received: from CTTCPCMDOHLER (pcmdohler.cttc.es [84.88.61.89]) (authenticated bits=0) by castor.cttc.es (8.13.2/8.13.3) with ESMTP id m2CFG6Vs012159 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 12 Mar 2008 16:16:06 +0100 Message-Id: <200803121516.m2CFG6Vs012159@castor.cttc.es> From: "Mischa Dohler" To: "'Jonathan Hui'" Date: Wed, 12 Mar 2008 16:14:18 +0100 Organization: CTTC MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciETxKiIIE7BbymTaihki/1UiZs5gABEhVw In-Reply-To: <47D7EB3B.1030704@archrock.com> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (castor.cttc.es [84.88.62.196]); Wed, 12 Mar 2008 16:16:06 +0100 (CET) X-Scanned-By: MIMEDefang 2.57 on 84.88.62.197 Cc: roll@ietf.org Subject: Re: [Roll] Urban WSNs Requirements Feedback X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mischa.dohler@cttc.es List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Dear Jonathan, Thanks for coming back on this. I see now what you meant by "phased-out"; ok, good idea, we will add a statement to this in our next draft. We will also address all the other points you raised. I agree with you that we should start using "routing protocol(s)" instead of "THE routing protocol". JP, when are the next round drafts due? Thanks and kind regards, Mischa. -----Original Message----- From: Jonathan Hui [mailto:jhui@archrock.com] Sent: Wednesday, March 12, 2008 3:40 PM To: mischa.dohler@cttc.es Cc: roll@ietf.org Subject: Re: [Roll] Urban WSNs Requirements Feedback Hi Mischa, thanks for the reply. See below: Mischa Dohler wrote: > Section 3: Overall, great section. Clearly presents the use-cases > while suggesting what is important in a routing protocol to address > those use-cases. Might also want to add a section about how nodes are > phased out, if at all. That would complete the whole life-cycle. > > MISCHA: I am not sure what exactly you mean with "phased out" but I think we > catered for this with the following phrase in that section: "Differentiation > should be made between node disassociation, where the node has enough time > to inform the network about its removal, and disappearance, where the node > simply disappears without prior notification." Ah, okay, so there is some statement buried in there. I still prefer seeing some statement that says what the expected decommissioning procedure is from the user's point-of-view. If that's simply to remove the node or battery from the node that's fine. Or is it really that the user/network manager needs to somehow inform the node/network that the node will be removed sometime soon so that the network can adapt if needed. > Section 4.3: IPv6 only supports a notion of multicast. The formation > of groups, in my mind, is a mechanism distinct from routing and > arguably isn't within scope of ROLL. Multicast routing is responsible > for delivering messages to two or more nodes in a group. We should > separate these two concepts. > > MISCHA: I totally agree with you that the organization process is distinct > from the routing problem, albeit correlated. However, since we operate on > the (energy) limit of design, we believe that the way the network is > organized and hence the way routing is facilitated should also be dealt with > in ROLL. I understand your point. I guess it wasn't clear to me what it meant for the routing protocol to "support the formation and identification of groups of field devices in the network." If the notion is that the routing topology should support some other protocol that is doing group formation, it makes it difficult to know exactly what is required until that protocol is formed. Note that there's a bunch of other things that may be required for creating such groups, including how addresses are assigned, the nature of such groups (can the span arbitrary nodes across the entire network or is there some spatial locality), while these things are out of scope of this specific draft they are related in that a routing protocol may be able to take advantage of these features. So I'm just looking for some clarification as to what is really intended here. > Section 4.5: A routing protocol that operates across a variety of link > technologies in a single network is expected within ROLL. Maybe you > meant to say that the routing protocol SHOULD optimize for the > heterogeneous node capabilities. But this could also be folded into > constraint-based routing. So not sure if we need this separate from > requirement 4.2. > > MISCHA: This was one of the last sections we inserted. We did this to > explicitly emphasize that heterogeneous design is a must. However, we didn't > want to go as far as to say that you need to optimize it because this > inherently means that there ought to be a strong coupling between these > heterogeneous technologies which I am not sure we can guarantee in ROLL. I > prefer to leave it as is. The requirement is a SHOULD so there's flexibility not to do so if you absolutely can't. Maybe 'optimize' is too strong a word, but say something along the lines of "SHOULD attempt to take advantage of additional resources when/where they exist" rather than "support a variety of different devices without compromising the operability and energy efficiency of the network." > Section 4.6: As I mentioned with the Home Automation draft, the IP > architecture doesn't support a notion of groupcast. Maybe we should > leave such a notion to the application-layer. > > MISCHA: Ok. Do you think that this section ought to be removed or could we > leave it just to make the point that this problem should be addressed? Well, this section also addresses multicast. So it is a good idea to leave it in. Also, we should stop referring to *the* routing protocol, since multicast and unicast may be supported by different routing protocols. Regarding groupcast, it might be good to state the expected traffic model and make some point to support it. But requiring the routing protocol to support groupcast directly is a bit unclear since IP (today) doesn't really support it. Thanks. -- Jonathan Hui _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Mar 12 12:44:28 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BC3B28C7BA; Wed, 12 Mar 2008 12:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.653 X-Spam-Level: X-Spam-Status: No, score=-100.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 TigYtDmW7VDZ; Wed, 12 Mar 2008 12:44:22 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80BEE28C639; Wed, 12 Mar 2008 12:44:22 -0700 (PDT) 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 010E528C639 for ; Wed, 12 Mar 2008 12:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 3AGxEpIceFhr for ; Wed, 12 Mar 2008 12:44:20 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by core3.amsl.com (Postfix) with ESMTP id A3B613A67F4 for ; Wed, 12 Mar 2008 12:44:19 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id k40so3789628wah.25 for ; Wed, 12 Mar 2008 12:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=RH8judDltbPTjvrvi4xzqbZqMfPWxX8idyNfM94BrnI=; b=taVQ/EdWymfyvcnXM15dhMD8NFF6XzoD+9GD7BbldBBwQBIx+/mEzmq83b7wpys82eBPPNhIxCwnsVdrWcG3T/GJIvhgc/9sMibB7Nm7jdFwH0TbyP2fCZvmOXV6NRsYwjDZJSc+h0vK1uOO1xOEc3GPgvWHP3UZYjQGF7RSuVU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=phwMq20GF5pC/A494kp1Wj5Zc6v+7j86WQ0JPc5cfwO0Dz9SYI/aH8/hNMYz6AqImbyWtyms0h8Gz5uZ629azgBfdqbcnE7XvzqA45OWrRIXS5FEDlKbLJAu3Z0qtcWGWmzo4Fwr0EOZaBInaAv2RB4+o4N7eQVTNZJnmAzB118= Received: by 10.114.120.1 with SMTP id s1mr7722620wac.137.1205350921396; Wed, 12 Mar 2008 12:42:01 -0700 (PDT) Received: by 10.115.108.10 with HTTP; Wed, 12 Mar 2008 12:42:01 -0700 (PDT) Message-ID: <77f1dba80803121242g7e0fd7a8kc3d9a4451801b10b@mail.gmail.com> Date: Wed, 12 Mar 2008 15:42:01 -0400 From: "Eunsook \"Eunah\" Kim" To: roll@ietf.org In-Reply-To: <47D76D36.9080501@archrock.com> MIME-Version: 1.0 Content-Disposition: inline References: <47D76D36.9080501@archrock.com> Subject: Re: [Roll] Home Requirements Feedback 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, As an author of 6LoWPAN routing requirements draft, I think ROLL I-Ds are good source to discuss and share the thought, although 6LoWPAN work is focusing on 15.4 only. I also put my thought under Jonathan's review lines. I have a few questions and comments in Requirements section. On Wed, Mar 12, 2008 at 1:42 AM, Jonathan Hui wrote: > (snip) > > Section 4: We should distill each requirement to a concise statement, > and leave any of the explanatory text to earlier sections. > > Section 4.1: What do you mean by multiple scopes? The RFC 4007 has a > clear definition of what IPv6 scopes are, but I'm not sure this is > what you mean. Also, see my earlier comment about groupcast and > whether this should really be provided completely by IP. > 'groupcast' is also not clear to me. do you want to say 'anycast'? > Section 4.2: Good requirement. > The doc says "it may be preferable to choose a (potentially longer) route via non battery powered devices or via battery powered that have more energy." This is related how you will keep neighbor list in your routing table, and what will you use as routing metrics. I also think this is an important requirements to design, but I think it would be better if you state less philasophical way (sorry, if this is not a right expression, please blame my english, if so). :P > Section 4.3: The mobility scenarios should be clearly stated in the > operational scenario section. For example, how do the nodes move > w.r.t. each other, how quickly, what kind of nodes are moving. Then we > get a clear understanding of what the convergence-time requirement > really is. > I agree with Jonathan. I think I also have to change my draft, but it would be good to see specific routing perspective of requirements for mobility support, instead of 'support of mobility'. > Section 4.5: It's good to provide some explanation of the expected > failure model (possibly in the architecture section). Is the goal to > converge if a single link/node fails? What if multiple of them fail, > due to some local interference? > Yeah. it's a hard problem to solve. Nodes failuare can make isolated island within the network. To solve this, with possibly endurable low complexity for sensor nodes is not an easy task, I think. I'm not sure it's a good way to state 'MUST' with the harsh requirements of 'few hundreds of milliseconds'. Section 4.6. What does 'misbehaving node' node, you mean? > Section 5: I think you're over constraining the requirements > here. There's already a latency requirement, so why constrain how > those latency requirements are met? It's the job the > designers/implementors to choose. > I'm not sure if you want to make another requirement in Section 5, or just restate the importance of support the traffic pattern from the application. Thanks. -eunah _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Mar 12 15:13:28 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62B4D28C796; Wed, 12 Mar 2008 15:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.746 X-Spam-Level: X-Spam-Status: No, score=-100.746 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 MZ1IKGO1JqQx; Wed, 12 Mar 2008 15:13:27 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A487B3A6B73; Wed, 12 Mar 2008 15:13:27 -0700 (PDT) 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 0D2063A6ADD for ; Wed, 12 Mar 2008 15:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 TjOPRZJr8Sd7 for ; Wed, 12 Mar 2008 15:13:24 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by core3.amsl.com (Postfix) with ESMTP id 9557128C686 for ; Wed, 12 Mar 2008 15:13:22 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id k40so3853774wah.25 for ; Wed, 12 Mar 2008 15:11:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=fQF80hrN2Q1ugjluqr1BG24C4R5Z4MtcZbumIqa6uIY=; b=jBJK3qrdpolY6DAfR4mACab7nUmqI0NXmhWVqSmkm4hFatCaSxVt3GE0gGkG0AyxhM1m9rEFdmU9pltLTfk4mJfkeFwpj7ZIvfTL53XOVNY3lCy/ywGogOvFE+fCwloaH1w26N7waN4FvRfxdLfJNWGs7B9mTYBa9Nc3i3/2C6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KnzIQEJGkcYK/xwMurW7zVUNX7yJOLgI9RCiE0qaNfSxOD4SvIhJgTsMICwdG/fsIxZ+Fv6DL2HfuZG3fp4dEcJljW4AG3sqefxvLIucfjZ2Dl3wHcTsH51OWQ317PgUCwtEWsos8aup49ylcEU/XCgAnlaCJLVyNsdcHq6M1ic= Received: by 10.114.121.1 with SMTP id t1mr7959917wac.55.1205359862257; Wed, 12 Mar 2008 15:11:02 -0700 (PDT) Received: by 10.115.108.10 with HTTP; Wed, 12 Mar 2008 15:11:02 -0700 (PDT) Message-ID: <77f1dba80803121511h27cfe155u6f9aca9df5b14dc8@mail.gmail.com> Date: Wed, 12 Mar 2008 18:11:02 -0400 From: "Eunsook \"Eunah\" Kim" To: roll@ietf.org In-Reply-To: <47D76D53.6060409@archrock.com> MIME-Version: 1.0 Content-Disposition: inline References: <47D76D53.6060409@archrock.com> Subject: Re: [Roll] Industrial Requirements Feedback 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, I learned many specific requirements about industrial field from the draft. However, my overall feeling from this draft is that it would be better to seperate routing requirements from the application description. It provides very nice explanation on application-specific view, and then ended with very short routing requirements in each section. So, it makes me feel a bit confused what is the main part of the draft. In addition, some explanation of routing requirements sounds a bit vague for me, such as 'easy to deploy and manage'. As this is the start of the work, so I'm looking forward to seeing how it will be progress. :) Thanks, -eunah _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Mar 13 05:39:36 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5913D28C14C; Thu, 13 Mar 2008 05:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.457 X-Spam-Level: X-Spam-Status: No, score=-97.457 tagged_above=-999 required=5 tests=[AWL=-1.114, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_MEETING=2.697, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1, 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 8rU9kBdBuqZ0; Thu, 13 Mar 2008 05:39:35 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ECFC3A6B98; Thu, 13 Mar 2008 05:39:35 -0700 (PDT) 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 C49A13A6B98 for ; Thu, 13 Mar 2008 05:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 JOPI12LmsTCz for ; Thu, 13 Mar 2008 05:39:33 -0700 (PDT) Received: from zensys17.zensys.local (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 1A9F23A6A05 for ; Thu, 13 Mar 2008 05:39:32 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 13 Mar 2008 13:37:14 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3EF169C6@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Home Requirements Feedback Thread-Index: AciEeSpn2pRxKHjwRb6crx4XKE4woQAjCvO2 References: <47D76D36.9080501@archrock.com> <77f1dba80803121242g7e0fd7a8kc3d9a4451801b10b@mail.gmail.com> From: "Anders Brandt" To: Subject: Re: [Roll] Home Requirements Feedback 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: , Content-Type: multipart/mixed; boundary="===============1827391103==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============1827391103== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C88506.F74BDAE8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C88506.F74BDAE8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jonathan, Eunah =20 Thanks for constructive and detailed comments. I agree with you that the document goes too much into hard requirements. =20 Just a short comment on the groupcast issue: The intention is to be able to instruct a number of lamps to turn on in = a time correlated manner. If limiting subnets to 255 nodes, you may address node individually with = a (relatively) small bitmask having one bit per node (255/8 =3D 32 bytes). The user experience is significantly affected by light "popping up" in a = room over say, 1 second. Having many lamps in a group requires sending a (potentially) high = number of singlecast messages - and remember: in a wireless environment, you have no chance of knowing which of the = nodes are close to the user. =20 I look forward to share comments with you gentlemen in the ROLL meeeting = today and on the reflector in the time to come. =20 cheers, Anders ________________________________ From: roll-bounces@ietf.org on behalf of Eunsook "Eunah" Kim Sent: Wed 12-03-2008 20:42 To: roll@ietf.org Subject: Re: [Roll] Home Requirements Feedback Hi, As an author of 6LoWPAN routing requirements draft, I think ROLL I-Ds are good source to discuss and share the thought, although 6LoWPAN work is focusing on 15.4 only. I also put my thought under Jonathan's review lines. I have a few questions and comments in Requirements section. On Wed, Mar 12, 2008 at 1:42 AM, Jonathan Hui wrote: > (snip) > > Section 4: We should distill each requirement to a concise statement, > and leave any of the explanatory text to earlier sections. > > Section 4.1: What do you mean by multiple scopes? The RFC 4007 has a > clear definition of what IPv6 scopes are, but I'm not sure this is > what you mean. Also, see my earlier comment about groupcast and > whether this should really be provided completely by IP. > 'groupcast' is also not clear to me. do you want to say 'anycast'? > Section 4.2: Good requirement. > The doc says "it may be preferable to choose a (potentially longer) route via non battery powered devices or via battery powered that have more energy." This is related how you will keep neighbor list in your routing table, and what will you use as routing metrics. I also think this is an important requirements to design, but I think it would be better if you state less philasophical way (sorry, if this is not a right expression, please blame my english, if so). :P > Section 4.3: The mobility scenarios should be clearly stated in the > operational scenario section. For example, how do the nodes move > w.r.t. each other, how quickly, what kind of nodes are moving. Then we > get a clear understanding of what the convergence-time requirement > really is. > I agree with Jonathan. I think I also have to change my draft, but it would be good to see specific routing perspective of requirements for mobility support, instead of 'support of mobility'. > Section 4.5: It's good to provide some explanation of the expected > failure model (possibly in the architecture section). Is the goal to > converge if a single link/node fails? What if multiple of them fail, > due to some local interference? > Yeah. it's a hard problem to solve. Nodes failuare can make isolated island within the network. To solve this, with possibly endurable low complexity for sensor nodes is not an easy task, I think. I'm not sure it's a good way to state 'MUST' with the harsh requirements of 'few hundreds of milliseconds'. Section 4.6. What does 'misbehaving node' node, you mean? > Section 5: I think you're over constraining the requirements > here. There's already a latency requirement, so why constrain how > those latency requirements are met? It's the job the > designers/implementors to choose. > I'm not sure if you want to make another requirement in Section 5, or just restate the importance of support the traffic pattern from the application. Thanks. -eunah _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------_=_NextPart_001_01C88506.F74BDAE8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Roll] Home Requirements = Feedback=0A= =0A= =0A= =0A=
=0A=
Jonathan, = Eunah
=0A=
 
=0A=
Thanks for constructive and = detailed comments.
I agree with you that the document goes too much = into hard requirements.
=0A=
 
=0A=
Just a short comment on the = groupcast issue:
=0A=
The intention is to be able to instruct a number of lamps = to turn on in a time correlated manner.
=0A=
If limiting subnets to 255 nodes, you may address node = individually with a (relatively) small bitmask
having one bit per = node (255/8 =3D 32 bytes).
=0A=
=0A=
The user experience is significantly affected by light = "popping up" in a room over say, 1 second.
Having many lamps in a = group requires sending a (potentially) high number of singlecast = messages - and remember:
in a wireless environment, you have no = chance of knowing which of the nodes are close to the user.
=0A=
 
=0A=
I look forward to share comments with you gentlemen in = the ROLL meeeting today and on the reflector in the time to come.
=0A=
 
=0A=
cheers,
  Anders
=0A=
=0A=
=0A=
=0A=
From: = roll-bounces@ietf.org on behalf of Eunsook "Eunah" Kim
Sent: = Wed 12-03-2008 20:42
To: roll@ietf.org
Subject: Re: = [Roll] Home Requirements Feedback

=0A=
=0A=

Hi,

As an author of 6LoWPAN routing = requirements draft, I think ROLL I-Ds
are good source to discuss and = share the thought, although 6LoWPAN
work is focusing on 15.4 = only.

I also put my thought under Jonathan's review lines. I have = a few
questions and comments in Requirements section.

On Wed, = Mar 12, 2008 at 1:42 AM, Jonathan Hui <jhui@archrock.com> = wrote:
>
(snip)
>
> Section 4: We should distill = each requirement to a concise statement,
> and leave any of the = explanatory text to earlier sections.
>
> Section 4.1: What = do you mean by multiple scopes? The RFC 4007 has a
> clear = definition of what IPv6 scopes are, but I'm not sure this is
> = what you mean. Also, see my earlier comment about groupcast and
> = whether this should really be provided completely by = IP.
>

'groupcast' is also not clear to me. do you want to = say 'anycast'?

> Section 4.2: Good = requirement.
>

The doc says "it may be preferable to choose = a (potentially longer)
route via non battery powered devices or via = battery powered that have
more energy."

This is related how = you will keep neighbor list in your routing table,
and what will you = use as routing metrics.
I also think this is an important = requirements to design, but I think
it would be better if you state = less philasophical way (sorry, if this
is not a right expression, = please blame my english, if so). :P

> Section 4.3: The = mobility scenarios should be clearly stated in the
> operational = scenario section. For example, how do the nodes move
> w.r.t. each = other, how quickly, what kind of nodes are moving. Then we
> get a = clear understanding of what the convergence-time requirement
> = really is.
>

I agree with Jonathan. I think I also have to = change my draft, but it
would be good to see specific routing = perspective of requirements for
mobility support, instead of 'support = of mobility'.

> Section 4.5: It's good to provide some = explanation of the expected
> failure model (possibly in the = architecture section). Is the goal to
> converge if a single = link/node fails? What if multiple of them fail,
> due to some = local interference?
>

Yeah. it's a hard problem to solve. = Nodes failuare can make isolated
island within the network. To solve = this, with possibly endurable low
complexity for sensor nodes is not = an easy task, I think. I'm not sure
it's a good way to state 'MUST' = with the harsh requirements of 'few
hundreds of = milliseconds'.

Section 4.6.
What does 'misbehaving node' node, = you mean?

> Section 5: I think you're over constraining the = requirements
> here. There's already a latency requirement, so why = constrain how
> those latency requirements are met? It's the job = the
> designers/implementors to choose.
>

I'm not = sure if you want to make another requirement in Section 5, or
just = restate the importance of support the traffic pattern from = the
application.

Thanks.

-eunah
_____________________= __________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/= mailman/listinfo/roll

------_=_NextPart_001_01C88506.F74BDAE8-- --===============1827391103== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1827391103==-- From roll-bounces@ietf.org Thu Mar 13 06:13:57 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1F393A6E49; Thu, 13 Mar 2008 06:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.54 X-Spam-Level: X-Spam-Status: No, score=-100.54 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 kzfOAt7JBcMs; Thu, 13 Mar 2008 06:13:52 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3FE13A6E4B; Thu, 13 Mar 2008 06:13:36 -0700 (PDT) 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 CDEBB3A6E17 for ; Thu, 13 Mar 2008 06:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 6oqyPc9dcsog for ; Thu, 13 Mar 2008 06:13:33 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [64.147.171.179]) by core3.amsl.com (Postfix) with ESMTP id 2EA6128C81D for ; Thu, 13 Mar 2008 06:13:16 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 8E2A7A9310; Thu, 13 Mar 2008 06:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-AJhDY8s+Lw; Thu, 13 Mar 2008 06:10:52 -0700 (PDT) Received: from [130.129.22.182] (dhcp-16b6.ietf71.ietf.org [130.129.22.182]) by mail.sf.archrock.com (Postfix) with ESMTP id AE21EA930E; Thu, 13 Mar 2008 06:10:51 -0700 (PDT) Message-ID: <47D927D6.2040402@archrock.com> Date: Thu, 13 Mar 2008 06:10:46 -0700 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Anders Brandt References: <47D76D36.9080501@archrock.com> <77f1dba80803121242g7e0fd7a8kc3d9a4451801b10b@mail.gmail.com> <6D9687E95918C04A8B30A7D6DA805A3EF169C6@zensys17.zensys.local> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3EF169C6@zensys17.zensys.local> Cc: roll@ietf.org Subject: Re: [Roll] Home Requirements Feedback 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Anders, Anders Brandt wrote: > If limiting subnets to 255 nodes, you may address node individually with > a (relatively) small bitmask > having one bit per node (255/8 = 32 bytes). I'm not too clear on how you do this within the IP framework. IPv6 multicast group IDs are only 112 bits. If we limited groups to 112, I guess each node could subscribe to any multicast group that has its own bit set. But then how do you address different nodes in different subnets? The IPv6 multicast address doesn't have a notion of subnet, only scope. So my real question, in short, was whether you are intending to see groupcast implemented at L3 or is it really something that sits at the application layer (possibly with some support from the underlying routing topology). -- Jonathan Hui _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Mar 13 06:34:00 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4129328C77A; Thu, 13 Mar 2008 06:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.653 X-Spam-Level: X-Spam-Status: No, score=-100.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 U7ABsBNQzm6H; Thu, 13 Mar 2008 06:33:54 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E307B28C123; Thu, 13 Mar 2008 06:33:54 -0700 (PDT) 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 3A76A3A6BC4 for ; Thu, 13 Mar 2008 06:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 jTNtF6bFm3hG for ; Thu, 13 Mar 2008 06:33:47 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 998933A698D for ; Thu, 13 Mar 2008 06:33:46 -0700 (PDT) Received: from [130.129.20.26] (dhcp-141a.ietf71.ietf.org [130.129.20.26]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id m2DDV4gl005458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 15:31:16 +0200 Message-ID: <47D92C3E.4070708@sensinode.com> Date: Thu, 13 Mar 2008 15:29:34 +0200 From: Mikko Saarnivala User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Jonathan Hui References: <47D76D36.9080501@archrock.com> <77f1dba80803121242g7e0fd7a8kc3d9a4451801b10b@mail.gmail.com> <6D9687E95918C04A8B30A7D6DA805A3EF169C6@zensys17.zensys.local> <47D927D6.2040402@archrock.com> In-Reply-To: <47D927D6.2040402@archrock.com> Cc: roll@ietf.org Subject: Re: [Roll] Home Requirements Feedback 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Jonathan, Jonathan Hui wrote: > So my real question, in short, was whether you are intending to see > groupcast implemented at L3 or is it really something that sits at the > application layer (possibly with some support from the underlying > routing topology). This was actually my initial thought also. My personal opinion is that it's clearly something for the application layer as the information of the type of the device would be there. My point is that we wouldn't want the L2 or L3 to care anything whether the device is a lamp, smoke detector or you-name-it. Hope that made some sense :) Best regards, -- Mikko Saarnivala _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Mar 13 06:55:44 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19B9A28C85C; Thu, 13 Mar 2008 06:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.517 X-Spam-Level: X-Spam-Status: No, score=-101.517 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, 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 IDOdkDZLO0-A; Thu, 13 Mar 2008 06:55:42 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1DFB28C702; Thu, 13 Mar 2008 06:55:42 -0700 (PDT) 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 10DB83A684F for ; Thu, 13 Mar 2008 06:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 SSz5CfOUIh3T for ; Thu, 13 Mar 2008 06:55:36 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id EBB2B3A6E4B for ; Thu, 13 Mar 2008 06:55:35 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so2774067fgg.41 for ; Thu, 13 Mar 2008 06:53:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=wd0KLjwCFfBlFkO7NJx83T9W+JU/64yw/4tSLg0+qpg=; b=DllEkyHCEZI00puxR0NQ/5ihYZc5DTbTrF+siqRal+u3tOMi91VDmhNJi9GYH3rVeKB6uaY9dyKD5mTa44vZNHLcowmUzsBVcuhtecaVF7lAqQbtA1AUk9ksNvrS1P03EbvUcoC4iV4D+9srhWX4CIfmL0yfCG4MJZ+EgdiLZdw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=wj1jkOoiqbcgDluBru1hYtE5sOP/pbzVs314eYDGXgqU/tPvdRgQk7hoqfT0B9JkCS0jWLYVq3TnGDzpP7VdGILnFGlL2+jmoGJ8uLQSBJB8irG8PtEogcla3QwUZlQ1ZG1L6iTGgQC55OfSIN4u808dzejYhZ32dQf4RmZub+g= Received: by 10.82.113.6 with SMTP id l6mr23197723buc.20.1205416396832; Thu, 13 Mar 2008 06:53:16 -0700 (PDT) Received: by 10.82.177.4 with HTTP; Thu, 13 Mar 2008 06:53:16 -0700 (PDT) Message-ID: <785cd670803130653o78352da7ia7d0ca7a78ad1f8@mail.gmail.com> Date: Thu, 13 Mar 2008 21:53:16 +0800 From: "Gopinath Rao Sinniah" To: "Jonathan Hui" In-Reply-To: <47D76D36.9080501@archrock.com> MIME-Version: 1.0 References: <47D76D36.9080501@archrock.com> Cc: roll@ietf.org Subject: Re: [Roll] Home Requirements Feedback 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: , Content-Type: multipart/mixed; boundary="===============1264844337==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1264844337== Content-Type: multipart/alternative; boundary="----=_Part_11084_30077598.1205416396814" ------=_Part_11084_30077598.1205416396814 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree with Jonathan on the use-cases that are defined. I believe that there would be more uses-cases which can be defined now and in the future which are not covered in the draft. My suggestion is instead of specifically mentioning the uses-cases in the draft, these can be grouped based on the characteristics and functions of the use-cases. The reason for this is we might encounter new use-cases which cannot be included in the draft and by defining the groups, the new use-case can fall in any of the group. The examples of the use-cases can be explained in detail in the group itself and not separately. --gopinath On Wed, Mar 12, 2008 at 1:42 PM, Jonathan Hui wrote: > > Overall, great set of use-cases that define the properties of a home > automation application. However, I would prefer to see any requirement > statements (e.g. MUST/SHOULD/etc) left for the Routing Requirements > section. I think it's better to first establish the nature of the > application before going into the requirements. Though, I do think > it's appropate to suggest what requirements are important to consider > in each scenario. > > This leads into my next comment, I think there should be a section > (either in use-cases or following use-cases) that clearly describes > the expected operational architecture. For example, the node > architecture (processor, radios, power, etc.), how they are physically > laid out, what environments are they expected to be in (yes, I know, > in the Home, but is outside, inside, separated by concrete walls, > etc.). I would also fold the Traffic Pattern section (Section 5) into > this. Having a clear understanding of the operational architecture, > along with the use-cases, will make it very clear in what conditions > the routing requirements must be satisfied. > > The draft does state a good set of requirements (e.g. latency, > node-join times, constrained routing, etc.). Though there are places > where I think the requirements are being over-specified. My feeling is > that these documents should state the functional requirements of a > dynamic routing protocol, but leave the "how" open to the > designers/implementors of such a protocol. For example, Section 5 > seems to require optimal any-to-any routing that doesn't utilize a > tree. I don't think Requirement draft is the right place to make such > specific claims. Also, we should keep the requirements concise. No > need to have too much surrounding explanation if the earlier sections > are clear about the use-cases and operational scenario. > > I understand the need for groupcast, but it's unclear to me how this > will be done within the IP architecture. Have you considered, > possibly, pushing such functions to the application-layer? What this > means is that the routing topology gives the necessary support to > implement groupcast at the application, but does not implement > groupcast directly. > > > Specific comments: > > > Section 3.1: At what layer does the reference to "broadcast" refer to? > IPv6 technically doesn't have a broadcast primitive. At the physical > layer, everything is broadcast. > > Section 3.2: I understand the need to support latencies at human time > scales and that multiple paths may help meet those latency > requirements. However, I think we should leave the "multiple path" > requirement out of the routing requirements. Instead, we should let > the requirements combined with the failure model drive what the > routing protocol should do. > > Section 3.3: I think it would be more useful to include some notion of > route discovery time here, rather than whether or not nodes are > scanning, discovering, refining, etc. > > Section 3.4: Good example that could feed into the "architecture" > section. > > Section 3.5: I think this requirement needs to be reworded into > something closer to "constraint-based" routing. The current wording > now leaves a bunch of questions in my mind. For example, what if > neighboring powered routers do exist, but do not support the latency > guarantees? Is routing through battery-powered acceptable in these > cases? > > Section 3.6: Another good example that can feed into the operational > architecture section. > > Sections 3.7 and 3.8: Looking forward to these. > > Section 4: We should distill each requirement to a concise statement, > and leave any of the explanatory text to earlier sections. > > Section 4.1: What do you mean by multiple scopes? The RFC 4007 has a > clear definition of what IPv6 scopes are, but I'm not sure this is > what you mean. Also, see my earlier comment about groupcast and > whether this should really be provided completely by IP. > > Section 4.2: Good requirement. > > Section 4.3: The mobility scenarios should be clearly stated in the > operational scenario section. For example, how do the nodes move > w.r.t. each other, how quickly, what kind of nodes are moving. Then we > get a clear understanding of what the convergence-time requirement > really is. > > Section 4.5: It's good to provide some explanation of the expected > failure model (possibly in the architecture section). Is the goal to > converge if a single link/node fails? What if multiple of them fail, > due to some local interference? > > Section 5: I think you're over constraining the requirements > here. There's already a latency requirement, so why constrain how > those latency requirements are met? It's the job the > designers/implementors to choose. > > -- > Jonathan Hui > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > ------=_Part_11084_30077598.1205416396814 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree with Jonathan on the use-cases that are defined. I believe that there would be more uses-cases which can be defined now and in the future which are not covered in the draft. My suggestion is instead of specifically mentioning the uses-cases in the draft, these can be grouped based on the characteristics and functions of the use-cases. The reason for this is we might encounter new use-cases which cannot be included in the draft and by defining the groups, the new use-case can fall in any of the group.

The examples of the use-cases can be explained in detail in the group itself and not separately.

--gopinath

On Wed, Mar 12, 2008 at 1:42 PM, Jonathan Hui <jhui@archrock.com> wrote:

Overall, great set of use-cases that define the properties of a home
automation application. However, I would prefer to see any requirement
statements (e.g. MUST/SHOULD/etc) left for the Routing Requirements
section. I think it's better to first establish the nature of the
application before going into the requirements. Though, I do think
it's appropate to suggest what requirements are important to consider
in each scenario.

This leads into my next comment, I think there should be a section
(either in use-cases or following use-cases) that clearly describes
the expected operational architecture. For example, the node
architecture (processor, radios, power, etc.), how they are physically
laid out, what environments are they expected to be in (yes, I know,
in the Home, but is outside, inside, separated by concrete walls,
etc.). I would also fold the Traffic Pattern section (Section 5) into
this. Having a clear understanding of the operational architecture,
along with the use-cases, will make it very clear in what conditions
the routing requirements must be satisfied.

The draft does state a good set of requirements (e.g. latency,
node-join times, constrained routing, etc.). Though there are places
where I think the requirements are being over-specified. My feeling is
that these documents should state the functional requirements of a
dynamic routing protocol, but leave the "how" open to the
designers/implementors of such a protocol. For example, Section 5
seems to require optimal any-to-any routing that doesn't utilize a
tree. I don't think Requirement draft is the right place to make such
specific claims. Also, we should keep the requirements concise. No
need to have too much surrounding explanation if the earlier sections
are clear about the use-cases and operational scenario.

I understand the need for groupcast, but it's unclear to me how this
will be done within the IP architecture. Have you considered,
possibly, pushing such functions to the application-layer? What this
means is that the routing topology gives the necessary support to
implement groupcast at the application, but does not implement
groupcast directly.


Specific comments:


Section 3.1: At what layer does the reference to "broadcast" refer to?
IPv6 technically doesn't have a broadcast primitive. At the physical
layer, everything is broadcast.

Section 3.2: I understand the need to support latencies at human time
scales and that multiple paths may help meet those latency
requirements. However, I think we should leave the "multiple path"
requirement out of the routing requirements. Instead, we should let
the requirements combined with the failure model drive what the
routing protocol should do.

Section 3.3: I think it would be more useful to include some notion of
route discovery time here, rather than whether or not nodes are
scanning, discovering, refining, etc.

Section 3.4: Good example that could feed into the "architecture"
section.

Section 3.5: I think this requirement needs to be reworded into
something closer to "constraint-based" routing. The current wording
now leaves a bunch of questions in my mind. For example, what if
neighboring powered routers do exist, but do not support the latency
guarantees? Is routing through battery-powered acceptable in these
cases?

Section 3.6: Another good example that can feed into the operational
architecture section.

Sections 3.7 and 3.8: Looking forward to these.

Section 4: We should distill each requirement to a concise statement,
and leave any of the explanatory text to earlier sections.

Section 4.1: What do you mean by multiple scopes? The RFC 4007 has a
clear definition of what IPv6 scopes are, but I'm not sure this is
what you mean. Also, see my earlier comment about groupcast and
whether this should really be provided completely by IP.

Section 4.2: Good requirement.

Section 4.3: The mobility scenarios should be clearly stated in the
operational scenario section. For example, how do the nodes move
w.r.t. each other, how quickly, what kind of nodes are moving. Then we
get a clear understanding of what the convergence-time requirement
really is.

Section 4.5: It's good to provide some explanation of the expected
failure model (possibly in the architecture section). Is the goal to
converge if a single link/node fails? What if multiple of them fail,
due to some local interference?

Section 5: I think you're over constraining the requirements
here. There's already a latency requirement, so why constrain how
those latency requirements are met? It's the job the
designers/implementors to choose.

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

------=_Part_11084_30077598.1205416396814-- --===============1264844337== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1264844337==-- From roll-bounces@ietf.org Thu Mar 13 08:44:28 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2952028C125; Thu, 13 Mar 2008 08:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.488 X-Spam-Level: X-Spam-Status: No, score=-100.488 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, 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 292f670fZ-w2; Thu, 13 Mar 2008 08:44:27 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1262B28C1BD; Thu, 13 Mar 2008 08:44:21 -0700 (PDT) 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 0667C28C70C; Thu, 13 Mar 2008 08:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 ybznTYZCbWvY; Thu, 13 Mar 2008 08:44:14 -0700 (PDT) Received: from mail.nivis.com (mail.nivis.com [65.205.163.229]) by core3.amsl.com (Postfix) with SMTP id D0CD028C240; Thu, 13 Mar 2008 08:43:16 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 13 Mar 2008 11:40:52 -0400 Message-ID: In-Reply-To: <56871.76.160.222.32.1205205847.squirrel@webserver6.intec.ugent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Syncronized Wake Thread-Index: AciDJ2Cd0aW2nfL5SrmhMlfzwPpfvwB9Be2A References: <200803021021.10955.coflynn@newae.com><001e01c87fd4$7264c4a0$8300a8c0@priveiqvfluhp9><47D2F21A.7080309@eecs.berkeley.edu><31227.76.160.222.32.1205108691.squirrel@webserver6.intec.ugent.be><47D56DD6.5060009@eecs.berkeley.edu> <56871.76.160.222.32.1205205847.squirrel@webserver6.intec.ugent.be> From: "Robert Assimiti" To: "Pieter De Mil" , "Kris Pister" Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] Syncronized Wake 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: , Content-Type: multipart/mixed; boundary="===============1088721278==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============1088721278== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C88520.A2393EE6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C88520.A2393EE6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Pieter, =20 Yes, the DLL is that flexible....and more. =20 Minimizing battery consumption was one of the primary design constraints for the DLL. =20 Time corrections can be accomplished in two ways: =20 1. Through ACK=20 a. Time corrections can be enabled/disabled in the ACK b. Other fun data can be enabled/disabled in the ACK such as LQI/RSSI data or the EUI-64 of the receiving device =20 2. Through advertisement headers =20 =20 =20 "The nice thing about standards is that there are so many to choose from." - Andrew S. Tanenbaum=20 Robert Assimiti Executive Staff Engineer Office: [678]-202-6859 Mobile: [404]-578-0205 robert.assimiti@nivis.com =20 =20 -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Pieter De Mil Sent: Monday, March 10, 2008 11:24 PM To: Kris Pister Cc: roll@ietf.org; 6lowpan@ietf.org Subject: Re: [6lowpan] Syncronized Wake =20 =20 >> Can you disable this extra time information for some ack packets? >>=20 > hmm. Good question. You can disable the timer for certain paths (if > you want to enforce regular updates between one pair of motes and not > another). But I don't think that you can ignore the time update in the > ack. What's the use case? =20 =20 In a network with a lot of traffic, I can imagine that this time information in the ack's is not always necessary for the motes to stay synchronized. It is necessary sometimes, but not for all successive acks. Disabling this time information in the ack =3D saving battery juice. To keep things simple, it may be OK to keep the time info always in the ack. I was just wondering if the DLL was *that* flexible :-) =20 Pieter _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan This e-mail (including any attachments to it) is confidential, proprietar= y, legally privileged, subject to copyright and is sent for the personal = attention of the intended recipient only. If you have received this e-mai= l in error, please reply to advise us immediately, delete it and destroy = any printed copies of it. You are notified that reading, disclosing, copy= ing, distributing or taking any action in reliance on the contents of thi= s information is strictly prohibited. No employee is authorized to conclu= de any binding agreement on behalf of NIVIS LLC with another party by e-m= ail without express written confirmation by an officer of the company. Al= though we have taken reasonable precautions to ensure no viruses are pres= ent in this e-mail, we cannot accept responsibility for any loss or damag= e arising from the viruses in this e-mail or attachments. ------_=_NextPart_001_01C88520.A2393EE6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Pieter,

=

 

Yes, the DLL is that flexible....and more.

 

Minimizing battery consumption was one of the primary design constraints for the DLL= =2E

 

Time corrections can be accomplished in two ways:

=

 

1.  Through ACK

a.&nb= sp; Time corrections can be enabled/disabled in the ACK

b.&nb= sp; Other fun data can be enabled/disabled in the ACK such as LQI/RSSI data or the = EUI-64 of the receiving device

 

2.  Through advertisement header= s

 

 

 

"The nice thing about standards is that there are so many to choose from."= ; - Andrew S. Tanenbaum

Robert Assimiti

Executive Staff Engineer

Office: [678]-202-6859

Mobile: [404]-578-0205

robert.assimiti@nivis.com

 

 

-----Original Message-----
From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behal= f Of Pieter De Mil
Sent: Monday, March 10, 2008 11:24 PM
To: Kris Pister
Cc: roll@ietf.org; 6lowpan@ietf.org
Subject: Re: [6lowpan] Syncronized Wake

 

 

>> Can you disable this extra time information for some ack packets?

>> 

> hmm.  Good question.  You can disable the timer for certain pat= hs (if

> you want to enforce regular updates between one pair of motes and not

> another).  But I don't think that you can ignore the time update in = the

> ack.  What's the use case?

 

 

In a network with a lot of traffic, I can imagine that this time<= /span>

information in the ack's is not always necessary for the motes to stay

synchronized. It is necessary sometimes, but not for all successive acks.

Disabling this time information  in the ack =3D saving battery juice.

To keep things simple, it may be OK to keep the time info always in the=

ack. I was just wondering if the DLL was *that* flexible :-)=

 

Pieter

_______________________________________________=

6lowpan mailing list

6lowpan@ietf.org

https://www.ietf.org/mailman/listinfo/6lowpan



This e-mail (including any attachments to it) is confidential, pr= oprietary, legally privileged, subject to copyright and is sent for the p= ersonal attention of the intended recipient only. If you have received th= is e-mail in error, please reply to advise us immediately, delete it and = destroy any printed copies of it. You are notified that reading, disclosi= ng, copying, distributing or taking any action in reliance on the content= s of this information is strictly prohibited. No employee is authorized t= o conclude any binding agreement on behalf of NIVIS LLC with another part= y by e-mail without express written confirmation by an officer of the com= pany. Although we have taken reasonable precautions to ensure no viruses = are present in this e-mail, we cannot accept responsibility for any loss = or damage arising from the viruses in this e-mail or attachments. ------_=_NextPart_001_01C88520.A2393EE6-- --===============1088721278== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1088721278==-- From roll-bounces@ietf.org Sun Mar 16 13:32:51 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776763A6B27; Sun, 16 Mar 2008 13:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.502 X-Spam-Level: X-Spam-Status: No, score=-97.502 tagged_above=-999 required=5 tests=[AWL=1.076, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 y-GaZZEoQEBe; Sun, 16 Mar 2008 13:32:50 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0ED43A6899; Sun, 16 Mar 2008 13:32:50 -0700 (PDT) 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 B3C7F3A6899 for ; Sun, 16 Mar 2008 13:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 61VrbiGcQKn2 for ; Sun, 16 Mar 2008 13:32:48 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id AE9493A69D6 for ; Sun, 16 Mar 2008 13:32:47 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id m2GKUAws024160; Sun, 16 Mar 2008 21:30:15 +0100 (MET) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sun, 16 Mar 2008 20:30:10 +0000 To: "JP Vasseur" , "roll@ietf.org" Date: Sun, 16 Mar 2008 20:30:10 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Sun, 16 Mar 2008 21:30:27 +0100 (MET) Subject: Re: [Roll] question regarding context and service discovery routing issues 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi JP Thanks, I will follow your recommendations! Best regards, Georgios On 3/10/2008, "JP Vasseur" wrote: >Hi, > > >> From: Georgios Karagiannis >> Date: Mon, 10 Mar 2008 15:33:21 +0000 >> To: >> Subject: [Roll] question regarding context and service discovery routing >> issues >> >> Dear all >> >> I have checked the several ROLL requirements drafts, but I could not find >> a requirement that is related to context and service discovery routing! >> I think that for multi-hop wireless networks, and especially adhoc sensor >> networks the way of how the discovery of the environment of a device is >> accomplished and how routing based on this discovery is done, are very >> important capabilities that make the device usefull. >> >> The 6lowpan and zerocof have addressed/addressing this issue, but I am >> not sure if this is done in the context of low power and lossy networks. >> >> Can you please inform me if context and service discovery routing issues >> are out of the scope of this WG? > >Thanks, excellent question. > >It is perfectly in the scope. From the WG Charter: " ... For >example path selection must be designed to take into consideration the >specific power capabilities, attributes and functional characteristics >of the links and nodes in the network. ...". > >A node constraint/attribute/service is clearly one on the specifics that a >routing solution for LLN must support. > >Could be: >- A Node constraint (level of energy, CPU, ...) >- A Node attribute (e.g, to be to used to carry traffic with characteristic >X, ... ) >- A node service (e.g, ability to support data aggregation) > >May I suggest you to provide comments on the requirements IDs along these >lines? > >Thanks. > >JP. > >> >> Best regards, >> Georgios >> _______________________________________________ >> 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 roll-bounces@ietf.org Wed Mar 19 07:19:56 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E26428C481; Wed, 19 Mar 2008 07:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.451 X-Spam-Level: X-Spam-Status: No, score=-101.451 tagged_above=-999 required=5 tests=[AWL=-3.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1, 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 YIIx6MrqKJRi; Wed, 19 Mar 2008 07:19:55 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 828D928C441; Wed, 19 Mar 2008 07:19:55 -0700 (PDT) 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 6101228C441 for ; Wed, 19 Mar 2008 07:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 lxokoNq2yrAb for ; Wed, 19 Mar 2008 07:19:53 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 210CB28C3E1 for ; Wed, 19 Mar 2008 07:19:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,524,1199682000"; d="scan'208";a="2267592" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 19 Mar 2008 10:17:35 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m2JEHZoW028215; Wed, 19 Mar 2008 10:17:35 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m2JEHZs6027465; Wed, 19 Mar 2008 14:17:35 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 10:17:35 -0400 Received: from 161.44.71.244 ([161.44.71.244]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 19 Mar 2008 14:17:34 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 19 Mar 2008 10:17:31 -0400 From: JP Vasseur To: Jonathan Hui , Message-ID: Thread-Topic: [Roll] Urban WSNs Requirements Feedback Thread-Index: AciJy/feNrBEDPW/EdyNXAANk8WjQA== In-Reply-To: <47D76CE9.8010402@archrock.com> Mime-version: 1.0 X-OriginalArrivalTime: 19 Mar 2008 14:17:35.0164 (UTC) FILETIME=[FA5A2FC0:01C889CB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3564; t=1205936255; x=1206800255; c=relaxed/simple; s=rtpdkim2001; 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]=20Urban=20WSNs=20Requirements=20 Feedback |Sender:=20 |To:=20Jonathan=20Hui=20,=20; bh=8pkEvrZsB7C2rXJWgwfzE/bEcnTiADGA/yKH7HrpCDU=; b=HcUb9ryqzjbJ7mlXmI3h+fVPC/hGkFaa2GjL48bMkHqrblj2C0DxjxdiNi FLsZjmF5jupH2WIzNxwunVaOqdOIhhh3ZosXx1CwI8u8p7Aeej3MD1OljI63 Z7i+E1VFkz; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Roll] Urban WSNs Requirements Feedback 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Jonathan, Just a quick comment in line, > From: Jonathan Hui > Date: Tue, 11 Mar 2008 22:40:57 -0700 > To: > Subject: [Roll] Urban WSNs Requirements Feedback > > > Overall, I think this is an excellent first draft. I like how it > starts off by describing the overall operational scenario, defines the > kinds of nodes in use, the nature of the traffic (frequency, direction > of flow, etc.). Next section describes the complete use-case beginning > with deployment. It makes suggestions on what is important to the > use-case w.r.t. the routing protocol but leaves the specific > requirement statements for the requirements section. > > > Specific comments: > > Section 2: Excellent section. > > Section 3: Overall, great section. Clearly presents the use-cases > while suggesting what is important in a routing protocol to address > those use-cases. Might also want to add a section about how nodes are > phased out, if at all. That would complete the whole life-cycle. > > Section 4: I'd drop "unique" from the title. Many of these > requirements are applicable to other application scenarios. > > Section 4.3: IPv6 only supports a notion of multicast. The formation > of groups, in my mind, is a mechanism distinct from routing and > arguably isn't within scope of ROLL. Multicast routing is responsible > for delivering messages to two or more nodes in a group. We should > separate these two concepts. Let me shed some light here: There two distinct aspects here: 1) The ability to address a subset of nodes: as you pointed out, today IPv6 support unicast and multicast, there is no notion of groupcast, which would be out of the scope of ROLL indeed. For example: Note: with IP multicast, signaling mechanisms are used by a receiver to join a group and the sender does not necessarily know the receivers of the group. What is required is the ability to address a group of receivers known by the sender even if the receivers do not need to know that they have been grouped by the sender (since requesting each individual node to join a multicast group would be very energy- consuming). Is not relevant to the routing protocol. On the other hand, 2) You may want to have the ability to limit the scope of routing knowledge to a subset of nodes: using levels/areas as in ISIS/OSPF or with a link flooding scope (OSPF), ... Which is a very different requirement but clearly a routing requirement. > > Section 4.4: I think this is the right way to state it. Suggesting > that the traffic patterns may allow certain optimizations, but that > such optimizations aren't required. > > Section 4.5: A routing protocol that operates across a variety of link > technologies in a single network is expected within ROLL. Maybe you > meant to say that the routing protocol SHOULD optimize for the > heterogeneous node capabilities. But this could also be folded into > constraint-based routing. So not sure if we need this separate from > requirement 4.2. > > Section 4.6: As I mentioned with the Home Automation draft, the IP > architecture doesn't support a notion of groupcast. Maybe we should > leave such a notion to the application-layer. > > Section 4.7: You might want to be a little more suggestive as to what > latencies are acceptable. > Thanks. JP. > -- > Jonathan Hui > _______________________________________________ > 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 roll-bounces@ietf.org Wed Mar 19 07:21:37 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0878C28C493; Wed, 19 Mar 2008 07:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.14 X-Spam-Level: X-Spam-Status: No, score=-99.14 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1, 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 SnOH5zR-VQ9i; Wed, 19 Mar 2008 07:21:33 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BD6D28C4CC; Wed, 19 Mar 2008 07:21:31 -0700 (PDT) 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 8D19928C4B0 for ; Wed, 19 Mar 2008 07:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 RVScctLBckWE for ; Wed, 19 Mar 2008 07:21:29 -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 8766928C48C for ; Wed, 19 Mar 2008 07:21:29 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 19 Mar 2008 07:19:12 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m2JEJCYe019802; Wed, 19 Mar 2008 07:19:12 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m2JEJC4x028528; Wed, 19 Mar 2008 14:19:12 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 10:19:11 -0400 Received: from 161.44.71.244 ([161.44.71.244]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 19 Mar 2008 14:19:11 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 19 Mar 2008 10:19:10 -0400 From: JP Vasseur To: , "'Jonathan Hui'" , Message-ID: Thread-Topic: [Roll] Urban WSNs Requirements Feedback Thread-Index: AciEA+h32GhQJka7QLWX0dbju3UG4AAF4IiwAWwyElg= In-Reply-To: <200803120846.m2C8kPjp005089@castor.cttc.es> Mime-version: 1.0 X-OriginalArrivalTime: 19 Mar 2008 14:19:11.0715 (UTC) FILETIME=[33E6B330:01C889CC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4566; t=1205936352; x=1206800352; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Urban=20WSNs=20Requirements=20 Feedback |Sender:=20; bh=gAXhQcBTR/jky6+p/8x2ngEwGseHTPB85C239XZtj4E=; b=YmtF+xuLI1RS0zfI6mGawJgGGVHs1myhkqOU9v4wnY90ruqOx0SOsQ2QDH Ba4PVAaBIC6JYI1CJ0As6jqoLkmXeRDLPH4Oc3IIgq1AuteVTvua7y1iIRz8 bv/CxgEfje; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Roll] Urban WSNs Requirements Feedback 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org In line, > From: Mischa Dohler > Organization: CTTC > Reply-To: > Date: Wed, 12 Mar 2008 09:44:37 +0100 > To: 'Jonathan Hui' , > Subject: Re: [Roll] Urban WSNs Requirements Feedback > > Thanks a lot, Jonathan, for this in-depth feedback! Please, see my replies > in-line. With kind regards, Mischa. > > > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Jonathan Hui > Sent: Wednesday, March 12, 2008 6:41 AM > To: roll@ietf.org > Subject: [Roll] Urban WSNs Requirements Feedback > > Overall, I think this is an excellent first draft. I like how it > starts off by describing the overall operational scenario, defines the > kinds of nodes in use, the nature of the traffic (frequency, direction > of flow, etc.). Next section describes the complete use-case beginning > with deployment. It makes suggestions on what is important to the > use-case w.r.t. the routing protocol but leaves the specific > requirement statements for the requirements section. > > > Specific comments: > > Section 2: Excellent section. > > Section 3: Overall, great section. Clearly presents the use-cases > while suggesting what is important in a routing protocol to address > those use-cases. Might also want to add a section about how nodes are > phased out, if at all. That would complete the whole life-cycle. > > MISCHA: I am not sure what exactly you mean with "phased out" but I think we > catered for this with the following phrase in that section: "Differentiation > should be made between node disassociation, where the node has enough time > to inform the network about its removal, and disappearance, where the node > simply disappears without prior notification." > > > > Section 4: I'd drop "unique" from the title. Many of these > requirements are applicable to other application scenarios. > > MISCHA: Yes, you are right. We will drop this in our next draft we will > issue with my ex-colleagues at France Telecom. > > > > Section 4.3: IPv6 only supports a notion of multicast. The formation > of groups, in my mind, is a mechanism distinct from routing and > arguably isn't within scope of ROLL. Multicast routing is responsible > for delivering messages to two or more nodes in a group. We should > separate these two concepts. > > MISCHA: I totally agree with you that the organization process is distinct > from the routing problem, albeit correlated. However, since we operate on > the (energy) limit of design, we believe that the way the network is > organized and hence the way routing is facilitated should also be dealt with > in ROLL. Very much in line with my previous comment. Thanks. JP. > > > Section 4.4: I think this is the right way to state it. Suggesting > that the traffic patterns may allow certain optimizations, but that > such optimizations aren't required. > > Section 4.5: A routing protocol that operates across a variety of link > technologies in a single network is expected within ROLL. Maybe you > meant to say that the routing protocol SHOULD optimize for the > heterogeneous node capabilities. But this could also be folded into > constraint-based routing. So not sure if we need this separate from > requirement 4.2. > > MISCHA: This was one of the last sections we inserted. We did this to > explicitly emphasize that heterogeneous design is a must. However, we didn't > want to go as far as to say that you need to optimize it because this > inherently means that there ought to be a strong coupling between these > heterogeneous technologies which I am not sure we can guarantee in ROLL. I > prefer to leave it as is. > > > Section 4.6: As I mentioned with the Home Automation draft, the IP > architecture doesn't support a notion of groupcast. Maybe we should > leave such a notion to the application-layer. > > MISCHA: Ok. Do you think that this section ought to be removed or could we > leave it just to make the point that this problem should be addressed? > > > Section 4.7: You might want to be a little more suggestive as to what > latencies are acceptable. > > MISCHA: Good idea: I will cross-check with my ex-colleagues in France > Telecom and also with Kris and David to get some reasonable numbers. > > _______________________________________________ > 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 roll-bounces@ietf.org Wed Mar 19 07:27:39 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ED8428C4B0; Wed, 19 Mar 2008 07:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.914 X-Spam-Level: X-Spam-Status: No, score=-98.914 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1, 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 X21IHcmT0dB5; Wed, 19 Mar 2008 07:27:33 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 923013A6AED; Wed, 19 Mar 2008 07:27:33 -0700 (PDT) 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 E12B128C413 for ; Wed, 19 Mar 2008 07:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 2QLdmKS6kEZX for ; Wed, 19 Mar 2008 07:27:31 -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 0A73F3A6915 for ; Wed, 19 Mar 2008 07:27:31 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 19 Mar 2008 07:25:14 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m2JEPELI022149; Wed, 19 Mar 2008 07:25:14 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2JEPAr4004376; Wed, 19 Mar 2008 14:25:14 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 10:25:12 -0400 Received: from 161.44.71.244 ([161.44.71.244]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 19 Mar 2008 14:25:12 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 19 Mar 2008 10:25:11 -0400 From: JP Vasseur To: Jonathan Hui , Message-ID: Thread-Topic: [Roll] Urban WSNs Requirements Feedback Thread-Index: AciJzQoNSHwG7/XAEdyNXAANk8WjQA== In-Reply-To: <47D7EB3B.1030704@archrock.com> Mime-version: 1.0 X-OriginalArrivalTime: 19 Mar 2008 14:25:12.0646 (UTC) FILETIME=[0B086660:01C889CD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2715; t=1205936714; x=1206800714; c=relaxed/simple; s=sjdkim3002; 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]=20Urban=20WSNs=20Requirements=20 Feedback |Sender:=20; bh=ffGcjqA8a4VnfVVdxwVnaPK7QJg2vXVaO7qZk6PM4c4=; b=svtG6tYYvMFSnE+b2YkriX6HTlnjVrkF03PKPVqpVSX7EowHNsu6cR7NYC nXf3C+CiX2wQzH72vdmLjNKQ+WY9mIpO6tYtherphbGu6ewGX4/b55n4My1i dKOMMdZKza; Authentication-Results: sj-dkim-3; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] Urban WSNs Requirements Feedback 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org [snip] > >> Section 4.5: A routing protocol that operates across a variety of link >> technologies in a single network is expected within ROLL. Maybe you >> meant to say that the routing protocol SHOULD optimize for the >> heterogeneous node capabilities. But this could also be folded into >> constraint-based routing. So not sure if we need this separate from >> requirement 4.2. >> >> MISCHA: This was one of the last sections we inserted. We did this to >> explicitly emphasize that heterogeneous design is a must. However, we didn't >> want to go as far as to say that you need to optimize it because this >> inherently means that there ought to be a strong coupling between these >> heterogeneous technologies which I am not sure we can guarantee in ROLL. I >> prefer to leave it as is. > > The requirement is a SHOULD so there's flexibility not to do so if you > absolutely can't. Maybe 'optimize' is too strong a word, but say > something along the lines of "SHOULD attempt to take advantage of > additional resources when/where they exist" rather than "support a > variety of different devices without compromising the operability and > energy efficiency of the network." I would suggest to avoid the term "optimize" in requirements documents since it does not really mean anything unless you define the objective function, metrics, ... Further, the support of the variety of links is a de facto MUST, since we operate at layer 3. On the other hand, the ability to take into account node constraints in path computation is fairly unique and he is a MUST I guess this is what you meant to say here. > >> Section 4.6: As I mentioned with the Home Automation draft, the IP >> architecture doesn't support a notion of groupcast. Maybe we should >> leave such a notion to the application-layer. >> >> MISCHA: Ok. Do you think that this section ought to be removed or could we >> leave it just to make the point that this problem should be addressed? > > Well, this section also addresses multicast. So it is a good idea to > leave it in. Also, we should stop referring to *the* routing protocol, > since multicast and unicast may be supported by different routing > protocols. Regarding groupcast, it might be good to state the expected > traffic model and make some point to support it. But requiring the > routing protocol to support groupcast directly is a bit unclear since IP > (today) doesn't really support it. Just make it the "routing protocol(s)" Thanks. JP. > > Thanks. > > -- > Jonathan Hui > _______________________________________________ > 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 roll-bounces@ietf.org Wed Mar 19 07:29:31 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E15AA3A6C29; Wed, 19 Mar 2008 07:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.019 X-Spam-Level: X-Spam-Status: No, score=-99.019 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1, 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 5ioRaxevhypl; Wed, 19 Mar 2008 07:29:30 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B00828C1EB; Wed, 19 Mar 2008 07:29:30 -0700 (PDT) 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 AF36B3A6D0D for ; Wed, 19 Mar 2008 07:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 sJHc5Ma+HXmg for ; Wed, 19 Mar 2008 07:29:22 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 4958F28C455 for ; Wed, 19 Mar 2008 07:29:02 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 19 Mar 2008 07:26:45 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m2JEQjPf002002; Wed, 19 Mar 2008 07:26:45 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m2JEQiOx006826; Wed, 19 Mar 2008 14:26:45 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 10:26:44 -0400 Received: from 161.44.71.244 ([161.44.71.244]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 19 Mar 2008 14:26:44 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 19 Mar 2008 10:26:42 -0400 From: JP Vasseur To: , "'Jonathan Hui'" Message-ID: Thread-Topic: [Roll] Urban WSNs Requirements Feedback Thread-Index: AciETxKiIIE7BbymTaihki/1UiZs5gABEhVwAV55VXw= In-Reply-To: <200803121516.m2CFG6Vs012159@castor.cttc.es> Mime-version: 1.0 X-OriginalArrivalTime: 19 Mar 2008 14:26:44.0705 (UTC) FILETIME=[41E77D10:01C889CD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6096; t=1205936805; x=1206800805; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20Urban=20WSNs=20Requirements=20 Feedback |Sender:=20; bh=76Z5rlKnuOGxrEaLXWvGMxJmUJrRLx9wCLd3eFXORk8=; b=dwegAevOAF+l6LcfBI83ushKkpxr7VK1vHfWYFw7wQ3K8LfgOPLDQzt1GR z87vD1KjInqVfq6/aJWefAF0BfgshLk9B/K0CEweJQj+ivJJ6yU6AnAwmnRX lFJo8UHUHM; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] Urban WSNs Requirements Feedback 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Mischa, > From: Mischa Dohler > Organization: CTTC > Reply-To: > Date: Wed, 12 Mar 2008 16:14:18 +0100 > To: 'Jonathan Hui' > Cc: > Subject: Re: [Roll] Urban WSNs Requirements Feedback > > Dear Jonathan, > > Thanks for coming back on this. > > I see now what you meant by "phased-out"; ok, good idea, we will add a > statement to this in our next draft. We will also address all the other > points you raised. > > I agree with you that we should start using "routing protocol(s)" instead of > "THE routing protocol". > > JP, when are the next round drafts due? You're free to update to document whenever you want to (with the exception of the period between the cut-off date and the first day of the IETF meeting). Thanks. JP. > > Thanks and kind regards, > Mischa. > > > > -----Original Message----- > From: Jonathan Hui [mailto:jhui@archrock.com] > Sent: Wednesday, March 12, 2008 3:40 PM > To: mischa.dohler@cttc.es > Cc: roll@ietf.org > Subject: Re: [Roll] Urban WSNs Requirements Feedback > > Hi Mischa, thanks for the reply. See below: > > Mischa Dohler wrote: >> Section 3: Overall, great section. Clearly presents the use-cases >> while suggesting what is important in a routing protocol to address >> those use-cases. Might also want to add a section about how nodes are >> phased out, if at all. That would complete the whole life-cycle. >> >> MISCHA: I am not sure what exactly you mean with "phased out" but I think > we >> catered for this with the following phrase in that section: > "Differentiation >> should be made between node disassociation, where the node has enough time >> to inform the network about its removal, and disappearance, where the node >> simply disappears without prior notification." > > Ah, okay, so there is some statement buried in there. I still prefer > seeing some statement that says what the expected decommissioning > procedure is from the user's point-of-view. If that's simply to remove > the node or battery from the node that's fine. Or is it really that the > user/network manager needs to somehow inform the node/network that the > node will be removed sometime soon so that the network can adapt if needed. > >> Section 4.3: IPv6 only supports a notion of multicast. The formation >> of groups, in my mind, is a mechanism distinct from routing and >> arguably isn't within scope of ROLL. Multicast routing is responsible >> for delivering messages to two or more nodes in a group. We should >> separate these two concepts. >> >> MISCHA: I totally agree with you that the organization process is distinct >> from the routing problem, albeit correlated. However, since we operate on >> the (energy) limit of design, we believe that the way the network is >> organized and hence the way routing is facilitated should also be dealt > with >> in ROLL. > > I understand your point. I guess it wasn't clear to me what it meant for > the routing protocol to "support the formation and identification of > groups of field devices in the network." If the notion is that the > routing topology should support some other protocol that is doing group > formation, it makes it difficult to know exactly what is required until > that protocol is formed. Note that there's a bunch of other things that > may be required for creating such groups, including how addresses are > assigned, the nature of such groups (can the span arbitrary nodes across > the entire network or is there some spatial locality), while these > things are out of scope of this specific draft they are related in that > a routing protocol may be able to take advantage of these features. So > I'm just looking for some clarification as to what is really intended here. > >> Section 4.5: A routing protocol that operates across a variety of link >> technologies in a single network is expected within ROLL. Maybe you >> meant to say that the routing protocol SHOULD optimize for the >> heterogeneous node capabilities. But this could also be folded into >> constraint-based routing. So not sure if we need this separate from >> requirement 4.2. >> >> MISCHA: This was one of the last sections we inserted. We did this to >> explicitly emphasize that heterogeneous design is a must. However, we > didn't >> want to go as far as to say that you need to optimize it because this >> inherently means that there ought to be a strong coupling between these >> heterogeneous technologies which I am not sure we can guarantee in ROLL. I >> prefer to leave it as is. > > The requirement is a SHOULD so there's flexibility not to do so if you > absolutely can't. Maybe 'optimize' is too strong a word, but say > something along the lines of "SHOULD attempt to take advantage of > additional resources when/where they exist" rather than "support a > variety of different devices without compromising the operability and > energy efficiency of the network." > >> Section 4.6: As I mentioned with the Home Automation draft, the IP >> architecture doesn't support a notion of groupcast. Maybe we should >> leave such a notion to the application-layer. >> >> MISCHA: Ok. Do you think that this section ought to be removed or could we >> leave it just to make the point that this problem should be addressed? > > Well, this section also addresses multicast. So it is a good idea to > leave it in. Also, we should stop referring to *the* routing protocol, > since multicast and unicast may be supported by different routing > protocols. Regarding groupcast, it might be good to state the expected > traffic model and make some point to support it. But requiring the > routing protocol to support groupcast directly is a bit unclear since IP > (today) doesn't really support it. > > Thanks. > > -- > Jonathan Hui > > _______________________________________________ > 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 roll-bounces@ietf.org Wed Mar 26 12:58:31 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4224328C796; Wed, 26 Mar 2008 12:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.903 X-Spam-Level: X-Spam-Status: No, score=-98.903 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1, 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 HZTyIH8BbmFW; Wed, 26 Mar 2008 12:58:27 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5121628C780; Wed, 26 Mar 2008 12:58:27 -0700 (PDT) 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 2DB9228C762 for ; Wed, 26 Mar 2008 12:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 nh0X2ok1oWsM for ; Wed, 26 Mar 2008 12:58:25 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3D5D228C795 for ; Wed, 26 Mar 2008 12:58:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,560,1199682000"; d="scan'208";a="3137185" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 26 Mar 2008 15:55:55 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m2QJttNB017285 for ; Wed, 26 Mar 2008 15:55:55 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m2QJtthc029579 for ; Wed, 26 Mar 2008 19:55:55 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 15:55:55 -0400 Received: from 161.44.71.244 ([161.44.71.244]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 26 Mar 2008 19:55:55 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 26 Mar 2008 15:55:54 -0400 From: JP Vasseur To: Message-ID: Thread-Topic: IETF-71 ROLL WG Minutes posted Thread-Index: AciPe2ZLpOloUvtuEdygCAANk8WjQA== Mime-version: 1.0 X-OriginalArrivalTime: 26 Mar 2008 19:55:55.0455 (UTC) FILETIME=[672904F0:01C88F7B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=188; t=1206561355; x=1207425355; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20IETF-71=20ROLL=20WG=20Minutes=20posted |Sender:=20 |To:=20; bh=QNGSjp9Di47bjno7tpAr1nBFdfhbYJp1h122rvwXqF8=; b=aWgcRoWg1AWaUsR8BOJqnzZC+6m9dRAaY5Z07YQ84Uh4BSi7iD+ikvnDu1 A8F6IXobuJUsHvJ8vbtINQiMTjDEjCrxtbw3EDYKVshuQcIbmDMWZK8P1d7A qYnv2jCuiT; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [Roll] IETF-71 ROLL WG 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Dear WG, The minutes of the ROLL WG meeting IETF-71 have been posted: http://www.ietf.org/proceedings/08mar/minutes/roll.txt Let us know if you have any comment. Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Mar 27 00:51:21 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5E7F28C7D5; Thu, 27 Mar 2008 00:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.03 X-Spam-Level: X-Spam-Status: No, score=-99.03 tagged_above=-999 required=5 tests=[AWL=-0.804, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1, 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 FNqp85Qgb++y; Thu, 27 Mar 2008 00:51:19 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87A173A6C63; Thu, 27 Mar 2008 00:51:19 -0700 (PDT) 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 632F13A6C4F for ; Thu, 27 Mar 2008 00:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 IA0pGNzHeVUL for ; Thu, 27 Mar 2008 00:51:13 -0700 (PDT) Received: from pilet.ens-lyon.fr (pilet.ens-lyon.fr [140.77.167.16]) by core3.amsl.com (Postfix) with ESMTP id A06B03A6BCC for ; Thu, 27 Mar 2008 00:51:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by pilet.ens-lyon.fr (Postfix) with ESMTP id 8CB1415B62A; Thu, 27 Mar 2008 08:48:49 +0100 (CET) Received: from pilet.ens-lyon.fr ([127.0.0.1]) by localhost (pilet [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01208-30; Thu, 27 Mar 2008 08:48:47 +0100 (CET) Received: from [140.77.13.176] (morblok.lip.ens-lyon.fr [140.77.13.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by pilet.ens-lyon.fr (Postfix) with ESMTP id 0533A15B625; Thu, 27 Mar 2008 08:48:45 +0100 (CET) Message-ID: <47EB5153.9000509@ens-lyon.fr> Date: Thu, 27 Mar 2008 08:48:35 +0100 From: Vincent Rossi User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Gopinath Rao Sinniah References: <47D76D36.9080501@archrock.com> <785cd670803130653o78352da7ia7d0ca7a78ad1f8@mail.gmail.com> In-Reply-To: <785cd670803130653o78352da7ia7d0ca7a78ad1f8@mail.gmail.com> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at ens-lyon.fr Cc: roll@ietf.org Subject: Re: [Roll] Home Requirements Feedback 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: , Content-Type: multipart/mixed; boundary="===============0136322102==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============0136322102== Content-Type: multipart/alternative; boundary="------------010306060405050202050205" This is a multi-part message in MIME format. --------------010306060405050202050205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi everyone, First of all, thank you Anders for this first draft. It really helps writing down some specific requirements for the home automation routing over L2N. I would like to add my contribution to this work. It will be divided in two parts. First, I will make some comments on the current draft (and discuss about the comments made by others). And finally, there is an other example/use-case that I really would like to appear in this draft (but even if it is a draft, the issue should be discussed first). Concerning my comments, I totally agree with the idea of the group-cast even if it is also not very clear to me how it would be implemented (cf. previous comments). About the routing protocol, I understand that this draft is oriented toward an inner network for the house only but it appears (c.f. Section 3.6) that a need to connect to a wider network (e.g. Internet) will be required for some devices. I simply wonder how the bridge will be established between our network (with a wide variety of devices...) and the house's Internet connection. Of course, the routing can be handled by a more powerful unit but I think it should be stated how this should work (one gateway, multiple gateways...). Furthermore, considering this approach, I think it would be nice to be considering sharing part of the house's state with some well-known entities (electricity provider, surveillance companies...), this also implies further thinking about the security layer of such networks. Considering the location of the devices, as asked by Jonathan, I tend to think that we must take into consideration the physical and environmental restrictions due to the devices that will be deployed in a "hostile" environment. I mean that devices located outdoor may suffer harder radio perturbations (thicker walls with iron structure...), rain, variation in temperatures, all altering the battery's lifetime (and so much more). So a question would be: how should we deal with such devices? Should we prevent them to be part of a route? Should they forward packets? The idea of a gateway between the Internet and the WSN seems to be broadly accepted. We may see several of these gw providing links to the Internet and management capabilities to the WSN. This reduces SPOF and also provide new routing issues. About Gopinath's contribution (about the categorization of use-cases), I think that it would also be clearer to separate the use-cases and try to group them by routing topology/goal/problems. The problem is that if we get more and more use-cases, some of them won't probably fit in one particular category. I think that the use-cases must be more like concrete examples illustrating a particular problem about routing within a house (which is exactly what they are right now). Another remark would be about the automation itself. All of the use-cases are oriented toward the user, providing services, often in response to a certain input from the user (except for the networked smoke alarm). I also think that future applications of home automation should tend to be discrete and seamless. I think that the best embedded systems are those you can forget about. Of course, some use-cases are very interesting but instead of needing the users input, some can be automated (especially, section 3.1 and 3.4) by a device located somewhere on the Internet. Is this changing the routing requirements and policies? Considering the important point of energy consumption (stated in 3.5 about the ability to change the battery), I also think that in the aim of an "intelligent" house (I guess we can call it like that), the technology should not be visible. And this rises the problem of changing batteries for some devices. Even if we can think about a couple of years of operation on a single battery, we must think about how the routing protocol should handle the powering state of the nodes. I mean, this issue has already been covered in section 4.2 in the case a node cannot be part of a route, but if a node is truly dead, there is a good chance we never know about it (because another route will be used). I think that a change in the route used must be considered as an anomaly as long as they are not repetitive. It is a real and hard problem. If a change of route occurs from time to time, we can assume it is because of human activity (like described in the middle of section 2), but if it is a longer route change, there are 2 main problems, first, there is a good chance we do not keep track that the route has changed, and then, it may be because a node is "dead", or simply because the node has been removed. My question would be how the SNMP protocol should be supported on such a network and/or, should this matter be raised to the application level. Nevertheless, it is, according to me, an important issue and we should really discuss it. This leads to another comment (again!). Considering this draft is about routing, I think that we should define the routing elements that can appear in such environment. It has already been started in section 4.2 but I think that maybe we can define some specific devices for the network topology (like it exists in wired networks). Actually, I can see 3 types of devices: -sensors, which are more likely to send status but not receiving anything (no need to listen to the radio traffic) -actuators, which will probably only receive orders but may also send their status/result of action, through the network -routers-forwarder, which are only designed to reach some dark areas of the network Of course, some devices may be using a mix of these primary features. Should they all have an IP address ? or just the micro-controler ? Should we stay with FFD and RFD restrictions ? I would like your opinion on such a partition of the devices abilities. I think it would help hardware and software design to help achieve the goal of an efficient routing in the home. Considering the network as a graph could we assume the information is transmitted one way, two ways... Another comment would be about the addressing. As you probably know, the current motes are providing multiple way to interact with the environment (may it be with sensors, actuators...), but often, there is only one network interface and then, only one network address, but how about we only want to access one sensor on a mote which possesses many? Should the packet contain the sensor ID or can we think of a protocol that could address directly to a particular sensor/actuator without the help of an embedded DB? I mean that we might want to access not only a mote but a particular sensor from a mote, without pushing this to the application layer. This could result in a very efficient way to access/collect data we want and prevent use of the micro-controller of the mote for treating many packets and gathering information from sensor we do not want information. And at last, this is the use-case I propose for this draft: it concerns energy efficiency in the home. Considering the increasing need of reducing power consumption on the planet, home automation may be use to optimize energy consumption. This said, there would be several ways to do so. First, activating the windows shades without user intervention based on the solar energy available to heat the house, even if no one is actually in the home. Another way would be to set some levels of heating, room by room and thus there we need the group-cast functionality, based on current temperature, moment of the day and other pieces of informations, provided by the sensors in the home and/or even from the Internet. The main aspect of this application, which is quite similar to the one described in section 3.1, is that it should appear seamless to the user. Another extension would be to forward the information from the sensors, not directly but after some computation, to the services providers such as gas, water and electricity ones so that they can adjust the supplies furnished to the home and therefore, reduce the power consumption based on estimation of need. The routing protocol should then be designed so that sensors are able to gather their info, transmit them to a or multiple central unit(s), and then, after following some model, action can be taken and orders distributed among actuators. Some simpler decisions can be taken by the sensor itself and transmitted directly to the according actuator. About the part on transmitting the information outside of the house, there must be a way to communicate securely between the inner network and the Internet. Thank you if you have successfully come this far and read everything, I can't wait for your (numerous) replies :) Vincent Gopinath Rao Sinniah a écrit : > I agree with Jonathan on the use-cases that are defined. I believe > that there would be more uses-cases which can be defined now and in > the future which are not covered in the draft. My suggestion is > instead of specifically mentioning the uses-cases in the draft, these > can be grouped based on the characteristics and functions of the > use-cases. The reason for this is we might encounter new use-cases > which cannot be included in the draft and by defining the groups, the > new use-case can fall in any of the group. > > The examples of the use-cases can be explained in detail in the group > itself and not separately. > > --gopinath > > On Wed, Mar 12, 2008 at 1:42 PM, Jonathan Hui > wrote: > > > Overall, great set of use-cases that define the properties of a home > automation application. However, I would prefer to see any requirement > statements (e.g. MUST/SHOULD/etc) left for the Routing Requirements > section. I think it's better to first establish the nature of the > application before going into the requirements. Though, I do think > it's appropate to suggest what requirements are important to consider > in each scenario. > > This leads into my next comment, I think there should be a section > (either in use-cases or following use-cases) that clearly describes > the expected operational architecture. For example, the node > architecture (processor, radios, power, etc.), how they are physically > laid out, what environments are they expected to be in (yes, I know, > in the Home, but is outside, inside, separated by concrete walls, > etc.). I would also fold the Traffic Pattern section (Section 5) into > this. Having a clear understanding of the operational architecture, > along with the use-cases, will make it very clear in what conditions > the routing requirements must be satisfied. > > The draft does state a good set of requirements (e.g. latency, > node-join times, constrained routing, etc.). Though there are places > where I think the requirements are being over-specified. My feeling is > that these documents should state the functional requirements of a > dynamic routing protocol, but leave the "how" open to the > designers/implementors of such a protocol. For example, Section 5 > seems to require optimal any-to-any routing that doesn't utilize a > tree. I don't think Requirement draft is the right place to make such > specific claims. Also, we should keep the requirements concise. No > need to have too much surrounding explanation if the earlier sections > are clear about the use-cases and operational scenario. > > I understand the need for groupcast, but it's unclear to me how this > will be done within the IP architecture. Have you considered, > possibly, pushing such functions to the application-layer? What this > means is that the routing topology gives the necessary support to > implement groupcast at the application, but does not implement > groupcast directly. > > > Specific comments: > > > Section 3.1: At what layer does the reference to "broadcast" refer to? > IPv6 technically doesn't have a broadcast primitive. At the physical > layer, everything is broadcast. > > Section 3.2: I understand the need to support latencies at human time > scales and that multiple paths may help meet those latency > requirements. However, I think we should leave the "multiple path" > requirement out of the routing requirements. Instead, we should let > the requirements combined with the failure model drive what the > routing protocol should do. > > Section 3.3: I think it would be more useful to include some notion of > route discovery time here, rather than whether or not nodes are > scanning, discovering, refining, etc. > > Section 3.4: Good example that could feed into the "architecture" > section. > > Section 3.5: I think this requirement needs to be reworded into > something closer to "constraint-based" routing. The current wording > now leaves a bunch of questions in my mind. For example, what if > neighboring powered routers do exist, but do not support the latency > guarantees? Is routing through battery-powered acceptable in these > cases? > > Section 3.6: Another good example that can feed into the operational > architecture section. > > Sections 3.7 and 3.8: Looking forward to these. > > Section 4: We should distill each requirement to a concise statement, > and leave any of the explanatory text to earlier sections. > > Section 4.1: What do you mean by multiple scopes? The RFC 4007 has a > clear definition of what IPv6 scopes are, but I'm not sure this is > what you mean. Also, see my earlier comment about groupcast and > whether this should really be provided completely by IP. > > Section 4.2: Good requirement. > > Section 4.3: The mobility scenarios should be clearly stated in the > operational scenario section. For example, how do the nodes move > w.r.t. each other, how quickly, what kind of nodes are moving. Then we > get a clear understanding of what the convergence-time requirement > really is. > > Section 4.5: It's good to provide some explanation of the expected > failure model (possibly in the architecture section). Is the goal to > converge if a single link/node fails? What if multiple of them fail, > due to some local interference? > > Section 5: I think you're over constraining the requirements > here. There's already a latency requirement, so why constrain how > those latency requirements are met? It's the job the > designers/implementors to choose. > > -- > Jonathan Hui > _______________________________________________ > 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 > --------------010306060405050202050205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi everyone,

First of all, thank you Anders for this first draft. It really helps writing down some specific requirements for the home automation routing over L2N.
I would like to add my contribution to this work. It will be divided in two parts.
First, I will make some comments on the current draft (and discuss about the comments made by others).
And finally, there is an other example/use-case that I really would like to appear in this draft (but even if it is a draft, the issue should be discussed first).

Concerning my comments, I totally agree with the idea of the group-cast even if it is also not very clear to me how it would be implemented (cf. previous comments).

About the routing protocol, I understand that this draft is oriented toward an inner network for the house only but it appears (c.f. Section 3.6) that a need to connect to a wider network (e.g. Internet) will be required for some devices. I simply wonder how the bridge will be established between our network (with a wide variety of devices...) and the house's Internet connection. Of course, the routing can be handled by a more powerful unit but I think it should be stated how this should work (one gateway, multiple gateways...).

Furthermore, considering this approach, I think it would be nice to be considering sharing part of the house's state with some well-known entities (electricity provider, surveillance companies...), this also implies further thinking about the security layer of such networks.

Considering the location of the devices, as asked by Jonathan, I tend to think that we must take into consideration the physical and environmental restrictions due to the devices that will be deployed in a "hostile" environment. I mean that devices located outdoor may suffer harder radio perturbations (thicker walls with iron structure...), rain, variation in temperatures, all altering the battery's lifetime (and so much more). So a question would be: how should we deal with such devices? Should we prevent them to be part of a route? Should they forward packets?
The idea of a gateway between the Internet and the WSN seems to be broadly accepted. We may see several of these gw providing links to the Internet and management capabilities to the WSN. This reduces SPOF and also provide new routing issues.

About Gopinath's contribution (about the categorization of use-cases), I think that it would also be clearer to separate the use-cases and try to group them by routing topology/goal/problems. The problem is that if we get more and more use-cases, some of them won't probably fit in one particular category. I think that the use-cases must be more like concrete examples illustrating a particular problem about routing within a house (which is exactly what they are right now).

Another remark would be about the automation itself. All of the use-cases are oriented toward the user, providing services, often in response to a certain input from the user (except for the networked smoke alarm). I also think that future applications of home automation should tend to be discrete and seamless. I think that the best embedded systems are those you can forget about. Of course, some use-cases are very interesting but instead of needing the users input, some can be automated (especially, section 3.1 and 3.4) by a device located somewhere on the Internet. Is this changing the routing requirements and policies?

Considering the important point of energy consumption (stated in 3.5 about the ability to change the battery), I also think that in the aim of an "intelligent" house (I guess we can call it like that), the technology should not be visible. And this rises the problem of changing batteries for some devices. Even if we can think about a couple of years of operation on a single battery, we must think about how the routing protocol should handle the powering state of the nodes. I mean, this issue has already been covered in section 4.2 in the case a node cannot be part of a route, but if a node is truly dead, there is a good chance we never know about it (because another route will be used). I think that a change in the route used must be considered as an anomaly as long as they are not repetitive. It is a real and hard problem. If a change of route occurs from time to time, we can assume it is because of human activity (like described in the middle of section 2), but if it is a longer route change, there are 2 main problems, first, there is a good chance we do not keep track that the route has changed, and then, it may be because a node is "dead", or simply because the node has been removed. My question would be how the SNMP protocol should be supported on such a network and/or, should this matter be raised to the application level. Nevertheless, it is, according to me, an important issue and we should really discuss it.

This leads to another comment (again!). Considering this draft is about routing, I think that we should define the routing elements that can appear in such environment. It has already been started in section 4.2 but I think that maybe we can define some specific devices for the network topology (like it exists in wired networks).

Actually, I can see 3 types of devices:
-sensors, which are more likely to send status but not receiving anything (no need to listen to the radio traffic)
-actuators, which will probably only receive orders but may also send their status/result of action, through the network
-routers-forwarder, which are only designed to reach some dark areas of the network
Of course, some devices may be using a mix of these primary features.

Should they all have an IP address ? or just the micro-controler ? Should we stay with FFD and RFD restrictions ?
I would like your opinion on such a partition of the devices abilities. I think it would help hardware and software design to help achieve the goal of an efficient routing in the home.
Considering the network as a graph could we assume the information is transmitted one way, two ways...

Another comment would be about the addressing. As you probably know, the current motes are providing multiple way to interact with the environment (may it be with sensors, actuators...), but often, there is only one network interface and then, only one network address, but how about we only want to access one sensor on a mote which possesses many? Should the packet contain the sensor ID or can we think of a protocol that could address directly to a particular sensor/actuator without the help of an embedded DB? I mean that we might want to access not only a mote but a particular sensor from a mote, without pushing this to the application layer. This could result in a very efficient way to access/collect data we want and prevent use of the micro-controller of the mote for treating many packets and gathering information from sensor we do not want information.

And at last, this is the use-case I propose for this draft: it concerns energy efficiency in the home.
Considering the increasing need of reducing power consumption on the planet, home automation may be use to optimize energy consumption. This said, there would be several ways to do so. First, activating the windows shades without user intervention based on the solar energy available to heat the house, even if no one is actually in the home. Another way would be to set some levels of heating, room by room  and thus there we need the group-cast functionality, based on current temperature, moment of the day and other pieces of informations, provided by the sensors in the home and/or even from the Internet.
The main aspect of this application, which is quite similar to the one described in section 3.1, is that it should appear seamless to the user. Another extension would be to forward the information from the sensors, not directly but after some computation, to the services providers such as gas, water and electricity ones so that they can adjust the supplies furnished to the home and therefore, reduce the power consumption based on estimation of need.
The routing protocol should then be designed so that sensors are able to gather their info, transmit them to a or multiple central unit(s), and then, after following some model, action can be taken and orders distributed among actuators. Some simpler decisions can be taken by the sensor itself and transmitted directly to the according actuator. About the part on transmitting the information outside of the house, there must be a way to communicate securely between the inner network and the Internet.

Thank you if you have successfully come this far and read everything,
I can't wait for your (numerous) replies :)

Vincent

Gopinath Rao Sinniah a écrit :
I agree with Jonathan on the use-cases that are defined. I believe that there would be more uses-cases which can be defined now and in the future which are not covered in the draft. My suggestion is instead of specifically mentioning the uses-cases in the draft, these can be grouped based on the characteristics and functions of the use-cases. The reason for this is we might encounter new use-cases which cannot be included in the draft and by defining the groups, the new use-case can fall in any of the group.

The examples of the use-cases can be explained in detail in the group itself and not separately.

--gopinath

On Wed, Mar 12, 2008 at 1:42 PM, Jonathan Hui <jhui@archrock.com> wrote:

Overall, great set of use-cases that define the properties of a home
automation application. However, I would prefer to see any requirement
statements (e.g. MUST/SHOULD/etc) left for the Routing Requirements
section. I think it's better to first establish the nature of the
application before going into the requirements. Though, I do think
it's appropate to suggest what requirements are important to consider
in each scenario.

This leads into my next comment, I think there should be a section
(either in use-cases or following use-cases) that clearly describes
the expected operational architecture. For example, the node
architecture (processor, radios, power, etc.), how they are physically
laid out, what environments are they expected to be in (yes, I know,
in the Home, but is outside, inside, separated by concrete walls,
etc.). I would also fold the Traffic Pattern section (Section 5) into
this. Having a clear understanding of the operational architecture,
along with the use-cases, will make it very clear in what conditions
the routing requirements must be satisfied.

The draft does state a good set of requirements (e.g. latency,
node-join times, constrained routing, etc.). Though there are places
where I think the requirements are being over-specified. My feeling is
that these documents should state the functional requirements of a
dynamic routing protocol, but leave the "how" open to the
designers/implementors of such a protocol. For example, Section 5
seems to require optimal any-to-any routing that doesn't utilize a
tree. I don't think Requirement draft is the right place to make such
specific claims. Also, we should keep the requirements concise. No
need to have too much surrounding explanation if the earlier sections
are clear about the use-cases and operational scenario.

I understand the need for groupcast, but it's unclear to me how this
will be done within the IP architecture. Have you considered,
possibly, pushing such functions to the application-layer? What this
means is that the routing topology gives the necessary support to
implement groupcast at the application, but does not implement
groupcast directly.


Specific comments:


Section 3.1: At what layer does the reference to "broadcast" refer to?
IPv6 technically doesn't have a broadcast primitive. At the physical
layer, everything is broadcast.

Section 3.2: I understand the need to support latencies at human time
scales and that multiple paths may help meet those latency
requirements. However, I think we should leave the "multiple path"
requirement out of the routing requirements. Instead, we should let
the requirements combined with the failure model drive what the
routing protocol should do.

Section 3.3: I think it would be more useful to include some notion of
route discovery time here, rather than whether or not nodes are
scanning, discovering, refining, etc.

Section 3.4: Good example that could feed into the "architecture"
section.

Section 3.5: I think this requirement needs to be reworded into
something closer to "constraint-based" routing. The current wording
now leaves a bunch of questions in my mind. For example, what if
neighboring powered routers do exist, but do not support the latency
guarantees? Is routing through battery-powered acceptable in these
cases?

Section 3.6: Another good example that can feed into the operational
architecture section.

Sections 3.7 and 3.8: Looking forward to these.

Section 4: We should distill each requirement to a concise statement,
and leave any of the explanatory text to earlier sections.

Section 4.1: What do you mean by multiple scopes? The RFC 4007 has a
clear definition of what IPv6 scopes are, but I'm not sure this is
what you mean. Also, see my earlier comment about groupcast and
whether this should really be provided completely by IP.

Section 4.2: Good requirement.

Section 4.3: The mobility scenarios should be clearly stated in the
operational scenario section. For example, how do the nodes move
w.r.t. each other, how quickly, what kind of nodes are moving. Then we
get a clear understanding of what the convergence-time requirement
really is.

Section 4.5: It's good to provide some explanation of the expected
failure model (possibly in the architecture section). Is the goal to
converge if a single link/node fails? What if multiple of them fail,
due to some local interference?

Section 5: I think you're over constraining the requirements
here. There's already a latency requirement, so why constrain how
those latency requirements are met? It's the job the
designers/implementors to choose.

--
Jonathan Hui
_______________________________________________
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
--------------010306060405050202050205-- --===============0136322102== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0136322102==-- From roll-bounces@ietf.org Thu Mar 27 20:43:21 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9336D28C2FC; Thu, 27 Mar 2008 20:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.615 X-Spam-Level: X-Spam-Status: No, score=-100.615 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 y64i7X0lfFOL; Thu, 27 Mar 2008 20:43:20 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D892A28C184; Thu, 27 Mar 2008 20:43:19 -0700 (PDT) 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 D21453A689C; Thu, 27 Mar 2008 20:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 78SIvHyY4pUe; Thu, 27 Mar 2008 20:43:17 -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 D17133A6874; Thu, 27 Mar 2008 20:43:13 -0700 (PDT) Received: from c-71-198-71-178.hsd1.ca.comcast.net ([71.198.71.178] helo=[192.168.2.105]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Jf5Un-0007B4-9m; Thu, 27 Mar 2008 20:43:13 -0700 Message-Id: <97E4819D-602B-45ED-97BA-3CA9E130E919@cs.stanford.edu> From: Philip Levis To: roll@ietf.org, manet manet Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 27 Mar 2008 20:43:12 -0700 X-Mailer: Apple Mail (2.919.2) X-Scan-Signature: 9c8d7c79e82d9ccd3af9a51b4d3246f3 Subject: [Roll] Discussion on 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org I'd like to start a discussion on draft-levis-roll-overview-protocols. In particular, Section 5.8 has a table of several existing protocols and their properties. This table is really going to be critical in ROLL's assessment of existing technologies and protocols, so we want to make sure that 1) It has the relevant data points to compare (protocols/rows) 2) It distills what the important properties are(columns) 3) It accurately captures the properties of the values in question (cells are accurate) Let's start with 1), as it's probably the simplest. Are there any protocols that we should be including that aren't there? Trying to cover every single minor protocol tweak is a recipe for disaster, but protocols that differ significantly from those currently there, either in mechanism or in properties, are important to include. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri Mar 28 00:52:18 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AC9D3A6BE6; Fri, 28 Mar 2008 00:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 5Hxe4sYsu6ap; Fri, 28 Mar 2008 00:52:17 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A69E28C1D3; Fri, 28 Mar 2008 00:52:17 -0700 (PDT) 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 DD02B3A6B64 for ; Fri, 28 Mar 2008 00:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 vb9kUIs4HHFs for ; Fri, 28 Mar 2008 00:52:12 -0700 (PDT) Received: from cpsmtpo-eml02.kpnxchange.com (cpsmtpo-eml02.kpnxchange.com [213.75.38.151]) by core3.amsl.com (Postfix) with ESMTP id 633DD3A6C33 for ; Fri, 28 Mar 2008 00:52:11 -0700 (PDT) Received: from hpsmtp-eml09.kpnxchange.com ([213.75.38.109]) by cpsmtpo-eml02.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 08:52:10 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml09.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 08:52:09 +0100 From: "Teco Boot" To: "'Philip Levis'" References: <97E4819D-602B-45ED-97BA-3CA9E130E919@cs.stanford.edu> In-Reply-To: <97E4819D-602B-45ED-97BA-3CA9E130E919@cs.stanford.edu> Date: Fri, 28 Mar 2008 08:52:10 +0100 Message-ID: <007301c890a8$a0cc05d0$e2641170$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciQhfs6FoJZZWuFRFGi106aCvzZYwAIQhdw Content-Language: nl X-OriginalArrivalTime: 28 Mar 2008 07:52:09.0152 (UTC) FILETIME=[9FE48C00:01C890A8] Cc: roll@ietf.org Subject: Re: [Roll] [manet] Discussion on 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Phil, Maybe this raised before, but I miss a category of "xxx" protocols, sometimes referred as "mesh" protocols. "Mesh" is not pure MANET, as MANET routing protocols typically provide paths within the MANET. "Mesh" protocols provide paths between nodes and a backbone network. MANET protocols can provide paths to the backbone also. The other way is not always true, "mesh" protocols do typically not provide paths between nodes or at least this is the second priority. Maybe the draft only discuss existing IETF protocols (e.g. RFC exists or WG is chartered), but I think the "mesh" type of protocols is worth mentioning. Regards, Teco > -----Oorspronkelijk bericht----- > Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens > Philip Levis > Verzonden: vrijdag 28 maart 2008 4:43 > Aan: roll@ietf.org; manet manet > Onderwerp: [manet] Discussion on draft > > I'd like to start a discussion on draft-levis-roll-overview-protocols. > In particular, Section 5.8 has a table of several existing protocols > and their properties. This table is really going to be critical in > ROLL's assessment of existing technologies and protocols, so we want > to make sure that > > 1) It has the relevant data points to compare (protocols/rows) > 2) It distills what the important properties are(columns) > 3) It accurately captures the properties of the values in question > (cells are accurate) > > Let's start with 1), as it's probably the simplest. Are there any > protocols that we should be including that aren't there? Trying to > cover every single minor protocol tweak is a recipe for disaster, but > protocols that differ significantly from those currently there, either > in mechanism or in properties, are important to include. > > Phil > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri Mar 28 01:21:04 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DEE93A6CFA; Fri, 28 Mar 2008 01:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 EYa41Jt8Xgdw; Fri, 28 Mar 2008 01:21:03 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 596BC3A6C41; Fri, 28 Mar 2008 01:21:03 -0700 (PDT) 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 606AA3A6B45 for ; Fri, 28 Mar 2008 01:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 au-MP75WyqGf for ; Fri, 28 Mar 2008 01:20:59 -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 D240E3A6800 for ; Fri, 28 Mar 2008 01:20:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,569,1199660400"; d="scan'208";a="4682983" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 28 Mar 2008 09:20:57 +0100 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 m2S8Kvj4011668; Fri, 28 Mar 2008 09:20:57 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2S8KvQY028056; Fri, 28 Mar 2008 08:20:57 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 09:20:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 Mar 2008 09:20:24 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC056EE8A8@xmb-ams-337.emea.cisco.com> In-Reply-To: <007301c890a8$a0cc05d0$e2641170$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [manet] Discussion on draft thread-index: AciQhfs6FoJZZWuFRFGi106aCvzZYwAIQhdwAAD5hDA= From: "Pascal Thubert (pthubert)" To: "Teco Boot" , "Philip Levis" X-OriginalArrivalTime: 28 Mar 2008 08:20:57.0172 (UTC) FILETIME=[A5DF7940:01C890AC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3596; t=1206692457; x=1207556457; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20[manet]=20Discussion=20on=20dr aft |Sender:=20; bh=1FYNz8QtpkyP+EuDZgQjC2mZa3ssene5+XbdvZimLJg=; b=ayjy/hDZF39If3T7Zvs0EM3Fa1DERCyiRyYBfl1yJSZqQdAkXz0gcshkvM C7Tm+Og64dGmFODYHf4x/7Xvz98IJHtQWG4lJXHv/PHuqdM2Iuw3zPJtbzDO 6BVSdqhAAK; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] [manet] Discussion on 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org That's a very interesting point. For most applications I know of in sensor networks, there is a concept of manager, gateway or backbone router that acts as a sink for the sensor network. If that's how we characterize a mesh network then this is clearly a typical situation. Another very typical thing is that when the network grows large, multiple sinks are deployed and can be interconnected by a high speed backbone that is of a different nature than the sensor network (the rock for our roll :) Things get more complex when multiple sinks are available and the questions are like: - which is the best suited sink for a given flow - do we load balance flows over sinks? - should a given flow be routed internally (route inside) the sensor network or via sinks and backbone (route around)? - what about mobility for handheld reader? - what about reservation for typical sensor data publish subscribe flows? Seems to me that the first thing to focus on is manage the routes to the sink and rely on route around. On a second phase and if flows demand so, we can consider optimizing the routing inside but then we must be very careful because the core of the ROLL network can rapidly saturate. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Teco Boot >Sent: vendredi 28 mars 2008 08:52 >To: 'Philip Levis' >Cc: roll@ietf.org >Subject: Re: [Roll] [manet] Discussion on draft > >Hi Phil, >Maybe this raised before, but I miss a category of "xxx" protocols, >sometimes referred as "mesh" protocols. >"Mesh" is not pure MANET, as MANET routing protocols typically provide paths >within the MANET. "Mesh" protocols provide paths between nodes and a >backbone network. >MANET protocols can provide paths to the backbone also. The other way is not >always true, "mesh" protocols do typically not provide paths between nodes >or at least this is the second priority. >Maybe the draft only discuss existing IETF protocols (e.g. RFC exists or WG >is chartered), but I think the "mesh" type of protocols is worth mentioning. >Regards, Teco > >> -----Oorspronkelijk bericht----- >> Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens >> Philip Levis >> Verzonden: vrijdag 28 maart 2008 4:43 >> Aan: roll@ietf.org; manet manet >> Onderwerp: [manet] Discussion on draft >> >> I'd like to start a discussion on draft-levis-roll-overview-protocols. >> In particular, Section 5.8 has a table of several existing protocols >> and their properties. This table is really going to be critical in >> ROLL's assessment of existing technologies and protocols, so we want >> to make sure that >> >> 1) It has the relevant data points to compare (protocols/rows) >> 2) It distills what the important properties are(columns) >> 3) It accurately captures the properties of the values in question >> (cells are accurate) >> >> Let's start with 1), as it's probably the simplest. Are there any >> protocols that we should be including that aren't there? Trying to >> cover every single minor protocol tweak is a recipe for disaster, but >> protocols that differ significantly from those currently there, either >> in mechanism or in properties, are important to include. >> >> Phil >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > >_______________________________________________ >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 roll-bounces@ietf.org Fri Mar 28 08:16:51 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7787A28C3A8; Fri, 28 Mar 2008 08:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.774 X-Spam-Level: X-Spam-Status: No, score=-100.774 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 4u-zulJS8vRz; Fri, 28 Mar 2008 08:16:47 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF38B28C21D; Fri, 28 Mar 2008 08:16:47 -0700 (PDT) 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 242433A6E58 for ; Fri, 28 Mar 2008 08:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 5JbNktTc0N85 for ; Fri, 28 Mar 2008 08:16:44 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by core3.amsl.com (Postfix) with ESMTP id 801ED3A6E54 for ; Fri, 28 Mar 2008 08:16:44 -0700 (PDT) Received: from [192.168.1.179] (adsl-99-154-200-21.dsl.pltn13.sbcglobal.net [99.154.200.21]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.2/8.13.5) with ESMTP id m2SFGPme029277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 28 Mar 2008 08:16:41 -0700 (PDT) Message-ID: <47ED0BD9.3080607@eecs.berkeley.edu> Date: Fri, 28 Mar 2008 08:16:41 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: roll@ietf.org Subject: [Roll] industrial requirements draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org I posted the previous rl2n draft as a roll draft. No changes yet - I just wanted it to have the right name. I'm going back over all of the comments that I received and will incorporate that into -01. If you already gave me feedback on the rl2n draft, no need to re-read this one. http://www3.tools.ietf.org/html/draft-pister-roll-indus-routing-reqs-00 ksjp _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri Mar 28 08:26:39 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA19A28C9AB; Fri, 28 Mar 2008 08:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.811 X-Spam-Level: X-Spam-Status: No, score=-100.811 tagged_above=-999 required=5 tests=[AWL=-0.374, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 r9LTULihwQHF; Fri, 28 Mar 2008 08:26:39 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 579EA28C32A; Fri, 28 Mar 2008 08:26:38 -0700 (PDT) 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 BD5B23A6896 for ; Fri, 28 Mar 2008 08:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 lhLhvxPCloxp for ; Fri, 28 Mar 2008 08:26:36 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 4FF703A6E16 for ; Fri, 28 Mar 2008 08:26:34 -0700 (PDT) Received: from c-71-198-71-178.hsd1.ca.comcast.net ([71.198.71.178] helo=[192.168.2.105]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1JfGTR-0007kK-01; Fri, 28 Mar 2008 08:26:33 -0700 Message-Id: From: Philip Levis To: Teco Boot In-Reply-To: <007301c890a8$a0cc05d0$e2641170$@nl> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 28 Mar 2008 08:26:31 -0700 References: <97E4819D-602B-45ED-97BA-3CA9E130E919@cs.stanford.edu> <007301c890a8$a0cc05d0$e2641170$@nl> X-Mailer: Apple Mail (2.919.2) X-Scan-Signature: 2e2010fe0da008b9f5e122b86dc99621 Cc: roll@ietf.org Subject: Re: [Roll] [manet] Discussion on 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Mar 28, 2008, at 12:52 AM, Teco Boot wrote: > Hi Phil, > Maybe this raised before, but I miss a category of "xxx" protocols, > sometimes referred as "mesh" protocols. > "Mesh" is not pure MANET, as MANET routing protocols typically > provide paths > within the MANET. "Mesh" protocols provide paths between nodes and a > backbone network. > MANET protocols can provide paths to the backbone also. The other > way is not > always true, "mesh" protocols do typically not provide paths between > nodes > or at least this is the second priority. > Maybe the draft only discuss existing IETF protocols (e.g. RFC > exists or WG > is chartered), but I think the "mesh" type of protocols is worth > mentioning. > Regards, Teco Teco, You're right; currently, the document only addresses existing IETF protocols. Basically, if there isn't a suitable solution already within the IETF corpus, then ROLL may need to add one (to the corpus). If that's the case, the follow-up question whether such a protocol would be an RFC-based specification of an existing, open protocol. Coming from the academic side, for example, there are plenty of protocols, but few meet the requirements (in terms of functionality, interoperability, etc.) of something that could be presented as an RFC. I'm not sure I'd agree with your definition of the distinction of "mesh" protocols (I generally consider them to be ANET protocols, that is, ad-hoc but not necessarily mobile), but I understand the distinction you're making, and that's more important than debating terminology. Which protocols are you thinking of? Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri Mar 28 09:01:35 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C18203A6C63; Fri, 28 Mar 2008 09:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.817 X-Spam-Level: X-Spam-Status: No, score=-100.817 tagged_above=-999 required=5 tests=[AWL=-0.380, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 cvblrOWGZeB1; Fri, 28 Mar 2008 09:01:31 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9EF43A6D14; Fri, 28 Mar 2008 09:01:31 -0700 (PDT) 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 363EF3A6D14 for ; Fri, 28 Mar 2008 09:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 oIM7rjJnKWBN for ; Fri, 28 Mar 2008 09:01:29 -0700 (PDT) Received: from hpsmtp-eml15.kpnxchange.com (hpsmtp-eml15.kpnxchange.com [213.75.38.115]) by core3.amsl.com (Postfix) with ESMTP id 8C2C23A6A0F for ; Fri, 28 Mar 2008 09:01:29 -0700 (PDT) Received: from hpsmtp-eml06.kpnxchange.com ([213.75.38.106]) by hpsmtp-eml15.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 17:01:27 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml06.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 17:01:22 +0100 From: "Teco Boot" To: "'Philip Levis'" References: <97E4819D-602B-45ED-97BA-3CA9E130E919@cs.stanford.edu> <007301c890a8$a0cc05d0$e2641170$@nl> In-Reply-To: Date: Fri, 28 Mar 2008 17:01:24 +0100 Message-ID: <009301c890ec$f919ac30$eb4d0490$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciQ6CW8sveU2PYlR7+rwPjeRZI6WgAApVPQ Content-Language: nl X-OriginalArrivalTime: 28 Mar 2008 16:01:22.0453 (UTC) FILETIME=[F7D2D450:01C890EC] Cc: roll@ietf.org Subject: Re: [Roll] [roll] Discussion on 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Phil, I swapped subject from manet to roll, for fitting my (and others) mail rules. On (fixed)ANET, my experience is that obstacles may move. For MESH and MANET protocols, the trigger for recomputing paths is not that important. On existing protocols, discussed in IETF, we had MANEMO (MANET for NEMO). I have published NEMO for MANET, which is tailored for Autoconf as it builds a path between MANET Router and Border Router (sink) using NEMO. Before Dublin, I will split the proposal and refine the related parts for Autoconf. These drafts do not describe routing anymore. I plan to work on the MESH routing part starting second half this year, depending on the outcome in Autoconf WG. Maybe add a section on MESH, describing that currently IETF is not working on this? And that a couple of personal drafts are published. I still wonder why IETF is ignoring MESH, as I think it makes sense to solve the problem at L3. Heterogeneous media are difficult to manage at L2. Regards, Teco > -----Oorspronkelijk bericht----- > Van: Philip Levis [mailto:pal@cs.stanford.edu] > Verzonden: vrijdag 28 maart 2008 16:27 > Aan: Teco Boot > CC: roll@ietf.org > Onderwerp: Re: [manet] Discussion on draft > > On Mar 28, 2008, at 12:52 AM, Teco Boot wrote: > > > Hi Phil, > > Maybe this raised before, but I miss a category of "xxx" protocols, > > sometimes referred as "mesh" protocols. > > "Mesh" is not pure MANET, as MANET routing protocols typically > > provide paths > > within the MANET. "Mesh" protocols provide paths between nodes and a > > backbone network. > > MANET protocols can provide paths to the backbone also. The other > > way is not > > always true, "mesh" protocols do typically not provide paths between > > nodes > > or at least this is the second priority. > > Maybe the draft only discuss existing IETF protocols (e.g. RFC > > exists or WG > > is chartered), but I think the "mesh" type of protocols is worth > > mentioning. > > Regards, Teco > > Teco, > > You're right; currently, the document only addresses existing IETF > protocols. Basically, if there isn't a suitable solution already > within the IETF corpus, then ROLL may need to add one (to the corpus). > If that's the case, the follow-up question whether such a protocol > would be an RFC-based specification of an existing, open protocol. > Coming from the academic side, for example, there are plenty of > protocols, but few meet the requirements (in terms of functionality, > interoperability, etc.) of something that could be presented as an RFC. > > I'm not sure I'd agree with your definition of the distinction of > "mesh" protocols (I generally consider them to be ANET protocols, that > is, ad-hoc but not necessarily mobile), but I understand the > distinction you're making, and > that's more important than debating terminology. > > Which protocols are you thinking of? > > Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri Mar 28 09:09:44 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6660128C610; Fri, 28 Mar 2008 09:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.64 X-Spam-Level: X-Spam-Status: No, score=-100.64 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 lljrclehJ1OA; Fri, 28 Mar 2008 09:09:43 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F26FD3A6B69; Fri, 28 Mar 2008 09:09:42 -0700 (PDT) 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 EFE963A688D for ; Fri, 28 Mar 2008 09:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 cgG7YzGNP8Xm for ; Fri, 28 Mar 2008 09:09:40 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by core3.amsl.com (Postfix) with ESMTP id 7D30E28C2C7 for ; Fri, 28 Mar 2008 09:09:40 -0700 (PDT) Received: from [192.168.1.179] (adsl-99-154-200-21.dsl.pltn13.sbcglobal.net [99.154.200.21]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.2/8.13.5) with ESMTP id m2SG9aTD029637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Mar 2008 09:09:38 -0700 (PDT) Message-ID: <47ED1850.9050108@eecs.berkeley.edu> Date: Fri, 28 Mar 2008 09:09:52 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Teco Boot References: <97E4819D-602B-45ED-97BA-3CA9E130E919@cs.stanford.edu> <007301c890a8$a0cc05d0$e2641170$@nl> In-Reply-To: <007301c890a8$a0cc05d0$e2641170$@nl> Cc: roll@ietf.org Subject: Re: [Roll] [manet] Discussion on 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Teco - I'm not sure how you define mesh, so forgive me if I'm missing the point. It's true that most of the mesh work in sensor networks to date has been to a single data sink. But there are also lots of examples in the literature in which local networking doesn't involve a gateway or backbone. This local networking is sometimes used for "distributed signal processing" (a very loaded phrase), and local feedback control loops. It's the feedback control that I think is starting to see real commercial traction. For industrial markets, I'm surprised that people are already starting to talk about local meshes for feedback control loops. I thought that it would take longer for them to get comfortable with the technology, but some at least are ready now. In many cases, this *requires* a local mesh, since the latency requirements effectively prohibit going through a backbone - if the sensor and actuator are close, there are probably fewer hops to get between them than to get to the backbone. ksjp Teco Boot wrote: > Hi Phil, > Maybe this raised before, but I miss a category of "xxx" protocols, > sometimes referred as "mesh" protocols. > "Mesh" is not pure MANET, as MANET routing protocols typically provide paths > within the MANET. "Mesh" protocols provide paths between nodes and a > backbone network. > MANET protocols can provide paths to the backbone also. The other way is not > always true, "mesh" protocols do typically not provide paths between nodes > or at least this is the second priority. > Maybe the draft only discuss existing IETF protocols (e.g. RFC exists or WG > is chartered), but I think the "mesh" type of protocols is worth mentioning. > Regards, Teco > > >> -----Oorspronkelijk bericht----- >> Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens >> Philip Levis >> Verzonden: vrijdag 28 maart 2008 4:43 >> Aan: roll@ietf.org; manet manet >> Onderwerp: [manet] Discussion on draft >> >> I'd like to start a discussion on draft-levis-roll-overview-protocols. >> In particular, Section 5.8 has a table of several existing protocols >> and their properties. This table is really going to be critical in >> ROLL's assessment of existing technologies and protocols, so we want >> to make sure that >> >> 1) It has the relevant data points to compare (protocols/rows) >> 2) It distills what the important properties are(columns) >> 3) It accurately captures the properties of the values in question >> (cells are accurate) >> >> Let's start with 1), as it's probably the simplest. Are there any >> protocols that we should be including that aren't there? Trying to >> cover every single minor protocol tweak is a recipe for disaster, but >> protocols that differ significantly from those currently there, either >> in mechanism or in properties, are important to include. >> >> Phil >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > _______________________________________________ > 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 roll-bounces@ietf.org Fri Mar 28 09:43:17 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE05D28C4C2; Fri, 28 Mar 2008 09:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.122 X-Spam-Level: X-Spam-Status: No, score=-101.122 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 yjIrQTv9dzWI; Fri, 28 Mar 2008 09:43:16 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5630B3A6C63; Fri, 28 Mar 2008 09:43:16 -0700 (PDT) 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 6C7E028C330 for ; Fri, 28 Mar 2008 09:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 e+K6bsCpQAzC for ; Fri, 28 Mar 2008 09:43:10 -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 716F928C610 for ; Fri, 28 Mar 2008 09:40:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,571,1199660400"; d="scan'208";a="4746096" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 28 Mar 2008 17:40:41 +0100 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 m2SGef9J011477; Fri, 28 Mar 2008 17:40:41 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2SGeftU022268; Fri, 28 Mar 2008 16:40:41 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 17:40:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 Mar 2008 17:40:05 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC056EEC07@xmb-ams-337.emea.cisco.com> In-Reply-To: <009301c890ec$f919ac30$eb4d0490$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] Discussion on draft thread-index: AciQ6CW8sveU2PYlR7+rwPjeRZI6WgAApVPQAAFLbNA= From: "Pascal Thubert (pthubert)" To: "Teco Boot" , "Philip Levis" X-OriginalArrivalTime: 28 Mar 2008 16:40:41.0509 (UTC) FILETIME=[75EE3550:01C890F2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4963; t=1206722441; x=1207586441; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20[roll]=20Discussion=20on=20dra ft |Sender:=20; bh=xD8pQlbj9gRzP1AGn62teZHfcqTNXagc6c5kE2lv8as=; b=p+Tkz7ZHaod6iqKJEK9J4dO1nUSe1fNDEASDNZ86CE3uqmGT08Ye2zINPN c7X+DTYFOByaADCiP7Cqu0GqXdowucLGUAGMWKdg6KTn4B7rO5Dno6tmKzzf huoBU6Gxno; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] [roll] Discussion on 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Phil: MANEMO was an effort that lead to a number of preBOF that were quite successful. MANEMO and ROLL had very similar objectives but MANEMO started in the wrong area (Internet) and with a scope that was not specific enough (more generic L3 mesh for sensors, cities and disaster recovery). Most of all, a draft like yours was missing to convince the A-Ds that there was actual work to do apart from pointing at the usual suspects from the MANET WG. Seems to me that ROLL is doing the right thing for all of these matters; and if you add to the picture the strong requirement drafts that we already have, I'm very impressed with the WG and its leadership. In any case there is no RFC'ed solution for MANEMO that you can refer in your draft. There were solution drafts that were advanced enough though: http://tools.ietf.org/html/draft-thubert-tree-discovery-06 . TD is a simple distance-vecteur to locate a sink and establish a graph to/from that sink http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing-header-07 enables source route along the TD graph till routing states are established. This enables fast movements and cases when no routing at all is desired above TD. http://tools.ietf.org/html/draft-thubert-nina-02 . NINA (AKA bubbles) sets routing states along the tree; this is all optimized for mesh to sink. An additional component could be added to improve inner mesh routing as Kris discusses on this thread. For instance, 802.11s is using AODV for that purpose. I hope this helps, Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Teco Boot >Sent: vendredi 28 mars 2008 17:01 >To: 'Philip Levis' >Cc: roll@ietf.org >Subject: Re: [Roll] [roll] Discussion on draft > >Phil, > >I swapped subject from manet to roll, for fitting my (and others) mail >rules. >On (fixed)ANET, my experience is that obstacles may move. For MESH and MANET >protocols, the trigger for recomputing paths is not that important. >On existing protocols, discussed in IETF, we had MANEMO (MANET for NEMO). I >have published NEMO for MANET, which is tailored for Autoconf as it builds a >path between MANET Router and Border Router (sink) using NEMO. Before >Dublin, I will split the proposal and refine the related parts for Autoconf. >These drafts do not describe routing anymore. I plan to work on the MESH >routing part starting second half this year, depending on the outcome in >Autoconf WG. > >Maybe add a section on MESH, describing that currently IETF is not working >on this? And that a couple of personal drafts are published. > >I still wonder why IETF is ignoring MESH, as I think it makes sense to solve >the problem at L3. Heterogeneous media are difficult to manage at L2. > >Regards, Teco > > >> -----Oorspronkelijk bericht----- >> Van: Philip Levis [mailto:pal@cs.stanford.edu] >> Verzonden: vrijdag 28 maart 2008 16:27 >> Aan: Teco Boot >> CC: roll@ietf.org >> Onderwerp: Re: [manet] Discussion on draft >> >> On Mar 28, 2008, at 12:52 AM, Teco Boot wrote: >> >> > Hi Phil, >> > Maybe this raised before, but I miss a category of "xxx" protocols, >> > sometimes referred as "mesh" protocols. >> > "Mesh" is not pure MANET, as MANET routing protocols typically >> > provide paths >> > within the MANET. "Mesh" protocols provide paths between nodes and a >> > backbone network. >> > MANET protocols can provide paths to the backbone also. The other >> > way is not >> > always true, "mesh" protocols do typically not provide paths between >> > nodes >> > or at least this is the second priority. >> > Maybe the draft only discuss existing IETF protocols (e.g. RFC >> > exists or WG >> > is chartered), but I think the "mesh" type of protocols is worth >> > mentioning. >> > Regards, Teco >> >> Teco, >> >> You're right; currently, the document only addresses existing IETF >> protocols. Basically, if there isn't a suitable solution already >> within the IETF corpus, then ROLL may need to add one (to the corpus). >> If that's the case, the follow-up question whether such a protocol >> would be an RFC-based specification of an existing, open protocol. >> Coming from the academic side, for example, there are plenty of >> protocols, but few meet the requirements (in terms of functionality, >> interoperability, etc.) of something that could be presented as an RFC. >> >> I'm not sure I'd agree with your definition of the distinction of >> "mesh" protocols (I generally consider them to be ANET protocols, that >> is, ad-hoc but not necessarily mobile), but I understand the >> distinction you're making, and >> that's more important than debating terminology. >> >> Which protocols are you thinking of? >> >> 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 roll-bounces@ietf.org Fri Mar 28 10:27:49 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0038C28C208; Fri, 28 Mar 2008 10:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.702 X-Spam-Level: X-Spam-Status: No, score=-100.702 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 KiVlTPutC3hE; Fri, 28 Mar 2008 10:27:47 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D8523A6E2C; Fri, 28 Mar 2008 10:27:47 -0700 (PDT) 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 E45A73A6E16 for ; Fri, 28 Mar 2008 10:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 q8qeA3Z6eB3D for ; Fri, 28 Mar 2008 10:27:36 -0700 (PDT) Received: from hpsmtp-eml14.kpnxchange.com (hpsmtp-eml14.kpnxchange.com [213.75.38.114]) by core3.amsl.com (Postfix) with ESMTP id 5E35E28C610 for ; Fri, 28 Mar 2008 10:27:11 -0700 (PDT) Received: from hpsmtp-eml08.kpnxchange.com ([213.75.38.108]) by hpsmtp-eml14.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 18:27:10 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml08.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 18:27:08 +0100 From: "Teco Boot" To: "'Kris Pister'" References: <97E4819D-602B-45ED-97BA-3CA9E130E919@cs.stanford.edu> <007301c890a8$a0cc05d0$e2641170$@nl> <47ED1850.9050108@eecs.berkeley.edu> In-Reply-To: <47ED1850.9050108@eecs.berkeley.edu> Date: Fri, 28 Mar 2008 18:27:11 +0100 Message-ID: <009a01c890f8$f4b7bb30$de273190$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciQ7iLEM0hdCZI3T3WWVFw7bnR+RgAB8Bfw Content-Language: nl X-OriginalArrivalTime: 28 Mar 2008 17:27:08.0781 (UTC) FILETIME=[F34629D0:01C890F8] Cc: roll@ietf.org Subject: Re: [Roll] [manet] Discussion on 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, I do not know how to define mesh. I think it is a diffuse term. I tried to define something in draft-boot-manet-nemo-analysis-01.txt (section 4.2). On using shortcuts in a tree structure, Pascal posted already on this. See also slide 11 on http://www.inf-net.nl/IETF69%20-%20Autoconf%20MANEMO%20scenarios%20and%20req uirements.pdf I described the congested link avoidance problem in draft-boot-manet-nemo-analysis-01.txt, section 6.4. Both MANET and NEMO has the problem. An integrated MANET and NEMO (or whatever) mechanism should select a direct path or a path using the backbone. This is not that easy, what is the selection criteria? Presentation on NEMO for MANET: http://www.inf-net.nl/IETF70%20-%20Autoconf-nemo4manet.pdf Material is also on IETF webside, but packed in CDrom images! Teco. > -----Oorspronkelijk bericht----- > Van: Kris Pister [mailto:pister@eecs.berkeley.edu] > Verzonden: vrijdag 28 maart 2008 17:10 > Aan: Teco Boot > CC: roll@ietf.org > Onderwerp: Re: [Roll] [manet] Discussion on draft > > Teco - I'm not sure how you define mesh, so forgive me if I'm missing > the point. > It's true that most of the mesh work in sensor networks to date has > been > to a single data sink. But there are also lots of examples in the > literature in which local networking doesn't involve a gateway or > backbone. This local networking is sometimes used for "distributed > signal processing" (a very loaded phrase), and local feedback control > loops. It's the feedback control that I think is starting to see real > commercial traction. > For industrial markets, I'm surprised that people are already starting > to talk about local meshes for feedback control loops. I thought that > it would take longer for them to get comfortable with the technology, > but some at least are ready now. In many cases, this *requires* a > local > mesh, since the latency requirements effectively prohibit going through > a backbone - if the sensor and actuator are close, there are probably > fewer hops to get between them than to get to the backbone. > > ksjp > > Teco Boot wrote: > > Hi Phil, > > Maybe this raised before, but I miss a category of "xxx" protocols, > > sometimes referred as "mesh" protocols. > > "Mesh" is not pure MANET, as MANET routing protocols typically > provide paths > > within the MANET. "Mesh" protocols provide paths between nodes and a > > backbone network. > > MANET protocols can provide paths to the backbone also. The other way > is not > > always true, "mesh" protocols do typically not provide paths between > nodes > > or at least this is the second priority. > > Maybe the draft only discuss existing IETF protocols (e.g. RFC exists > or WG > > is chartered), but I think the "mesh" type of protocols is worth > mentioning. > > Regards, Teco > > > > > >> -----Oorspronkelijk bericht----- > >> Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens > >> Philip Levis > >> Verzonden: vrijdag 28 maart 2008 4:43 > >> Aan: roll@ietf.org; manet manet > >> Onderwerp: [manet] Discussion on draft > >> > >> I'd like to start a discussion on draft-levis-roll-overview- > protocols. > >> In particular, Section 5.8 has a table of several existing protocols > >> and their properties. This table is really going to be critical in > >> ROLL's assessment of existing technologies and protocols, so we want > >> to make sure that > >> > >> 1) It has the relevant data points to compare (protocols/rows) > >> 2) It distills what the important properties are(columns) > >> 3) It accurately captures the properties of the values in question > >> (cells are accurate) > >> > >> Let's start with 1), as it's probably the simplest. Are there any > >> protocols that we should be including that aren't there? Trying to > >> cover every single minor protocol tweak is a recipe for disaster, > but > >> protocols that differ significantly from those currently there, > either > >> in mechanism or in properties, are important to include. > >> > >> Phil > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > >> > > > > _______________________________________________ > > 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 roll-bounces@ietf.org Fri Mar 28 10:31:43 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C2733A6B0D; Fri, 28 Mar 2008 10:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.148 X-Spam-Level: X-Spam-Status: No, score=-101.148 tagged_above=-999 required=5 tests=[AWL=-0.711, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 QINe0y-7nktJ; Fri, 28 Mar 2008 10:31:39 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A2ED3A6A0F; Fri, 28 Mar 2008 10:31:39 -0700 (PDT) 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 9958B3A6A28 for ; Fri, 28 Mar 2008 10:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 ouBMKLsTOlqs for ; Fri, 28 Mar 2008 10:31: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 2BEA73A6A0F for ; Fri, 28 Mar 2008 10:31:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,571,1199660400"; d="scan'208";a="4750665" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 28 Mar 2008 18:31:35 +0100 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 m2SHVZwC029757; Fri, 28 Mar 2008 18:31:35 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2SHVZnp008496; Fri, 28 Mar 2008 17:31:35 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 18:31:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 Mar 2008 18:31:02 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC056EEC4A@xmb-ams-337.emea.cisco.com> In-Reply-To: <47ED1850.9050108@eecs.berkeley.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [manet] Discussion on draft thread-index: AciQ7kOslWqjtMZUQ8mygnf18kEXhgACa3Ww From: "Pascal Thubert (pthubert)" To: "Kris Pister" , "Teco Boot" X-OriginalArrivalTime: 28 Mar 2008 17:31:35.0520 (UTC) FILETIME=[92434E00:01C890F9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4289; t=1206725495; x=1207589495; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20[manet]=20Discussion=20on=20dr aft |Sender:=20; bh=vEdL+BG5EIBiL0L7H7ja5e/uxbbzzME5FeiL92ouMMM=; b=uGp2AJuu3PWkcwpXtBXXCTOfdANZbv6WmWI8i6Qq6Q22/TzdL39OcQVRMc UpKKoY2s1CJxFAHwPzRWnySBSiDPOYguj0x2NpnFclVT7lC9IxGV/eVQkFeV +O+epTQhsA; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] [manet] Discussion on 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Kris: I think that Teco means that finding a path inside the mesh might be a second priority vs. finding the way to the sink. By Priority I mean that intra mesh routing might: - require less optimized and well maintained path then the routing to the sinks - have an on-demand flavor to maintain only certain routes as opposed to any to any - be used only for certain applications such as closed loop as opposed to bulk data - be scoped to limit the number of radio hops and default to route around The mesh strategy is to default to the backbone and then do some route optimization. MANET alone does not have route around. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Kris Pister >Sent: vendredi 28 mars 2008 17:10 >To: Teco Boot >Cc: roll@ietf.org >Subject: Re: [Roll] [manet] Discussion on draft > >Teco - I'm not sure how you define mesh, so forgive me if I'm missing >the point. >It's true that most of the mesh work in sensor networks to date has been >to a single data sink. But there are also lots of examples in the >literature in which local networking doesn't involve a gateway or >backbone. This local networking is sometimes used for "distributed >signal processing" (a very loaded phrase), and local feedback control >loops. It's the feedback control that I think is starting to see real >commercial traction. >For industrial markets, I'm surprised that people are already starting >to talk about local meshes for feedback control loops. I thought that >it would take longer for them to get comfortable with the technology, >but some at least are ready now. In many cases, this *requires* a local >mesh, since the latency requirements effectively prohibit going through >a backbone - if the sensor and actuator are close, there are probably >fewer hops to get between them than to get to the backbone. > >ksjp > >Teco Boot wrote: >> Hi Phil, >> Maybe this raised before, but I miss a category of "xxx" protocols, >> sometimes referred as "mesh" protocols. >> "Mesh" is not pure MANET, as MANET routing protocols typically provide paths >> within the MANET. "Mesh" protocols provide paths between nodes and a >> backbone network. >> MANET protocols can provide paths to the backbone also. The other way is not >> always true, "mesh" protocols do typically not provide paths between nodes >> or at least this is the second priority. >> Maybe the draft only discuss existing IETF protocols (e.g. RFC exists or WG >> is chartered), but I think the "mesh" type of protocols is worth mentioning. >> Regards, Teco >> >> >>> -----Oorspronkelijk bericht----- >>> Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens >>> Philip Levis >>> Verzonden: vrijdag 28 maart 2008 4:43 >>> Aan: roll@ietf.org; manet manet >>> Onderwerp: [manet] Discussion on draft >>> >>> I'd like to start a discussion on draft-levis-roll-overview-protocols. >>> In particular, Section 5.8 has a table of several existing protocols >>> and their properties. This table is really going to be critical in >>> ROLL's assessment of existing technologies and protocols, so we want >>> to make sure that >>> >>> 1) It has the relevant data points to compare (protocols/rows) >>> 2) It distills what the important properties are(columns) >>> 3) It accurately captures the properties of the values in question >>> (cells are accurate) >>> >>> Let's start with 1), as it's probably the simplest. Are there any >>> protocols that we should be including that aren't there? Trying to >>> cover every single minor protocol tweak is a recipe for disaster, but >>> protocols that differ significantly from those currently there, either >>> in mechanism or in properties, are important to include. >>> >>> Phil >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >> >> _______________________________________________ >> 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 roll-bounces@ietf.org Fri Mar 28 10:53:48 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3344D3A6CC5; Fri, 28 Mar 2008 10:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.933 X-Spam-Level: X-Spam-Status: No, score=-100.933 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 Z6Rp4Sv28e6P; Fri, 28 Mar 2008 10:53:47 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 699C23A6831; Fri, 28 Mar 2008 10:53:47 -0700 (PDT) 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 1FE6D3A6831 for ; Fri, 28 Mar 2008 10:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 rnCUzmU5ssP1 for ; Fri, 28 Mar 2008 10:53:46 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 646143A6A44 for ; Fri, 28 Mar 2008 10:53:46 -0700 (PDT) Received: from c-71-198-71-178.hsd1.ca.comcast.net ([71.198.71.178] helo=[192.168.2.105]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1JfIlt-0000uf-9k; Fri, 28 Mar 2008 10:53:45 -0700 Message-Id: <72225ABE-C6BB-4348-A026-9128C19C7608@cs.stanford.edu> From: Philip Levis To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC056EEC07@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 28 Mar 2008 10:53:45 -0700 References: <7892795E1A87F04CADFCCF41FADD00FC056EEC07@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.919.2) X-Scan-Signature: 8e086a056c9d4443aaf3b84243aabc30 Cc: roll@ietf.org Subject: Re: [Roll] [roll] Discussion on 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Mar 28, 2008, at 9:40 AM, Pascal Thubert (pthubert) wrote: > Hi Phil: > > MANEMO was an effort that lead to a number of preBOF that were quite > successful. MANEMO and ROLL had very similar objectives but MANEMO > started in the wrong area (Internet) and with a scope that was not > specific enough (more generic L3 mesh for sensors, cities and disaster > recovery). Most of all, a draft like yours was missing to convince the > A-Ds that there was actual work to do apart from pointing at the usual > suspects from the MANET WG. > > Seems to me that ROLL is doing the right thing for all of these > matters; > and if you add to the picture the strong requirement drafts that we > already have, I'm very impressed with the WG and its leadership. > > In any case there is no RFC'ed solution for MANEMO that you can > refer in > your draft. There were solution drafts that were advanced enough > though: > Given the clear relevance of MANEMO, including it in the draft seems like a good idea, even if there is not an RFC. It is, after all, in the IETF corpus. What I'm leery of is starting to include protocols that are completely outside that corpus. A discussion of them might be a very useful document, I'd put it outside the scope of this particular draft, which examines existing IETF solutions. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri Mar 28 15:29:09 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E85A53A7076; Fri, 28 Mar 2008 15:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 1a46QDw+Kp90; Fri, 28 Mar 2008 15:29:08 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D15043A7040; Fri, 28 Mar 2008 15:29:08 -0700 (PDT) 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 7C0273A7046 for ; Fri, 28 Mar 2008 15:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 fW0e0p9o9Jpp for ; Fri, 28 Mar 2008 15:29:03 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 32B6C3A7040 for ; Fri, 28 Mar 2008 15:29:03 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 28 Mar 2008 15:29:02 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m2SMT2Ok014190; Fri, 28 Mar 2008 15:29:02 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m2SMT21t027639; Fri, 28 Mar 2008 22:29:02 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 18:29:02 -0400 Received: from 10.86.104.186 ([10.86.104.186]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 28 Mar 2008 22:29:01 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 28 Mar 2008 18:29:00 -0400 From: JP Vasseur To: Teco Boot , Philip Levis Message-ID: Thread-Topic: [Roll] [manet] Discussion on draft Thread-Index: AciQhfs6FoJZZWuFRFGi106aCvzZYwAIQhdwAAD5hDAAHg0wIA== In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC056EE8A8@xmb-ams-337.emea.cisco.com> Mime-version: 1.0 X-OriginalArrivalTime: 28 Mar 2008 22:29:02.0069 (UTC) FILETIME=[1FA29250:01C89123] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4903; t=1206743342; x=1207607342; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20[manet]=20Discussion=20on=20dr aft |Sender:=20; bh=6en+1eqr06pR8EQXEN7Y2S6mpoo7Y7WNnmimOkKDdXg=; b=UG3cmnEsfs8UCW64NBjDPLAbQd1wHahvjB++U7Qn3koDDUiBi1YRGbKU7k Z3+8HOWgTBC6Ql0z0bi0POwQlffY0GDPFFPTc/MlFXrtVZRTvmrK/SXYDhKX 7KtoyspUoG; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] [manet] Discussion on 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, I think that it is worth clarifying that ROLL is about routing over low power and loosy networks. Referring to: ""Mesh" protocols provide paths between nodes and a backbone network. MANET protocols can provide paths to the backbone also. The other way is not always true, "mesh" protocols do typically not provide paths between Nodes or at least this is the second priority." There is no such notion of "between nodes and a backbone network". We need to get a routing solution between nodes. Traffic patterns are important and discussed in the requirements documents. We may indeed want to get a solution optimized for some traffic patterns (P2MP versus Any-to-Any) of course. Thanks. JP. > From: "Pascal Thubert (pthubert)" > Date: Fri, 28 Mar 2008 09:20:24 +0100 > To: Teco Boot , Philip Levis > Cc: > Conversation: [Roll] [manet] Discussion on draft > Subject: Re: [Roll] [manet] Discussion on draft > > That's a very interesting point. > > For most applications I know of in sensor networks, there is a concept > of manager, gateway or backbone router that acts as a sink for the > sensor network. If that's how we characterize a mesh network then this > is clearly a typical situation. > > Another very typical thing is that when the network grows large, > multiple sinks are deployed and can be interconnected by a high speed > backbone that is of a different nature than the sensor network (the rock > for our roll :) > > Things get more complex when multiple sinks are available and the > questions are like: > - which is the best suited sink for a given flow > - do we load balance flows over sinks? > - should a given flow be routed internally (route inside) the sensor > network or via sinks and backbone (route around)? > - what about mobility for handheld reader? > - what about reservation for typical sensor data publish subscribe > flows? > > Seems to me that the first thing to focus on is manage the routes to the > sink and rely on route around. On a second phase and if flows demand so, > we can consider optimizing the routing inside but then we must be very > careful because the core of the ROLL network can rapidly saturate. > > Pascal > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Teco Boot >> Sent: vendredi 28 mars 2008 08:52 >> To: 'Philip Levis' >> Cc: roll@ietf.org >> Subject: Re: [Roll] [manet] Discussion on draft >> >> Hi Phil, >> Maybe this raised before, but I miss a category of "xxx" protocols, >> sometimes referred as "mesh" protocols. >> "Mesh" is not pure MANET, as MANET routing protocols typically provide > paths >> within the MANET. "Mesh" protocols provide paths between nodes and a >> backbone network. >> MANET protocols can provide paths to the backbone also. The other way > is not >> always true, "mesh" protocols do typically not provide paths between > nodes >> or at least this is the second priority. >> Maybe the draft only discuss existing IETF protocols (e.g. RFC exists > or WG >> is chartered), but I think the "mesh" type of protocols is worth > mentioning. >> Regards, Teco >> >>> -----Oorspronkelijk bericht----- >>> Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens >>> Philip Levis >>> Verzonden: vrijdag 28 maart 2008 4:43 >>> Aan: roll@ietf.org; manet manet >>> Onderwerp: [manet] Discussion on draft >>> >>> I'd like to start a discussion on > draft-levis-roll-overview-protocols. >>> In particular, Section 5.8 has a table of several existing protocols >>> and their properties. This table is really going to be critical in >>> ROLL's assessment of existing technologies and protocols, so we want >>> to make sure that >>> >>> 1) It has the relevant data points to compare (protocols/rows) >>> 2) It distills what the important properties are(columns) >>> 3) It accurately captures the properties of the values in question >>> (cells are accurate) >>> >>> Let's start with 1), as it's probably the simplest. Are there any >>> protocols that we should be including that aren't there? Trying to >>> cover every single minor protocol tweak is a recipe for disaster, but >>> protocols that differ significantly from those currently there, > either >>> in mechanism or in properties, are important to include. >>> >>> Phil >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> _______________________________________________ >> 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 roll-bounces@ietf.org Fri Mar 28 15:29:35 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A4FD3A7069; Fri, 28 Mar 2008 15:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.207 X-Spam-Level: X-Spam-Status: No, score=-101.207 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 pfW2UqVSBGMp; Fri, 28 Mar 2008 15:29:34 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 375E03A6E85; Fri, 28 Mar 2008 15:29:34 -0700 (PDT) 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 8E9673A6EB5 for ; Fri, 28 Mar 2008 15:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 C5cHRqWuPhON for ; Fri, 28 Mar 2008 15:29:32 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B43223A6E85 for ; Fri, 28 Mar 2008 15:29:32 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 28 Mar 2008 15:29:32 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m2SMTUw8011234; Fri, 28 Mar 2008 15:29:30 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m2SMTFa2027811; Fri, 28 Mar 2008 22:29:30 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 18:29:18 -0400 Received: from 10.86.104.186 ([10.86.104.186]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 28 Mar 2008 22:29:17 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 28 Mar 2008 18:29:16 -0400 From: JP Vasseur To: Philip Levis , Teco Boot Message-ID: Thread-Topic: [Roll] [manet] Discussion on draft Thread-Index: AciRIyfwZsjzfP0WEdym2wANk8WjQA== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 28 Mar 2008 22:29:18.0272 (UTC) FILETIME=[294AF400:01C89123] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2567; t=1206743370; x=1207607370; c=relaxed/simple; s=sjdkim4002; 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[manet]=20Discussion=20on=20dr aft |Sender:=20; bh=g+O2KEcei/XKb+gxasni8NdV6QmiaPUMTNMczPJ06pk=; b=TsegT3rCT4SY2StkZdhxHqDATcOtgeUXDJXJwe+ykx0pzt3Kc0lPc7931p UgljmtMyznUVenwkTEaxF8Mg0E4ZD71lE+T2zSWDn1jqqJv9+AKyGhzOHqgW 9g93oYeArs; Authentication-Results: sj-dkim-4; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] [manet] Discussion on 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > From: Philip Levis > Date: Fri, 28 Mar 2008 08:26:31 -0700 > To: Teco Boot > Cc: > Subject: Re: [Roll] [manet] Discussion on draft > > On Mar 28, 2008, at 12:52 AM, Teco Boot wrote: > >> Hi Phil, >> Maybe this raised before, but I miss a category of "xxx" protocols, >> sometimes referred as "mesh" protocols. >> "Mesh" is not pure MANET, as MANET routing protocols typically >> provide paths >> within the MANET. "Mesh" protocols provide paths between nodes and a >> backbone network. >> MANET protocols can provide paths to the backbone also. The other >> way is not >> always true, "mesh" protocols do typically not provide paths between >> nodes >> or at least this is the second priority. >> Maybe the draft only discuss existing IETF protocols (e.g. RFC >> exists or WG >> is chartered), but I think the "mesh" type of protocols is worth >> mentioning. >> Regards, Teco > > Teco, > > You're right; currently, the document only addresses existing IETF > protocols. Basically, if there isn't a suitable solution already > within the IETF corpus, then ROLL may need to add one (to the corpus). Right, and that is the point of this document. > If that's the case, the follow-up question whether such a protocol > would be an RFC-based specification of an existing, open protocol. > Coming from the academic side, for example, there are plenty of > protocols, but few meet the requirements (in terms of functionality, > interoperability, etc.) of something that could be presented as an RFC. It is premature to have that discussion before we know whether or not we could use an existing IETF protocol (with or without extensions) but clearly, the solution will have to be an RFC-based specification, which does mean that we could not be inspired by previous work of course. > > I'm not sure I'd agree with your definition of the distinction of > "mesh" protocols (I generally consider them to be ANET protocols, that > is, ad-hoc but not necessarily mobile), but I understand the > distinction you're making, and > that's more important than debating terminology. Right, what matters for the time being is to first have an agreement on the evaluation metrics and their associated weight in light of the requirement documents. Thanks. JP. > > Which protocols are you thinking of? > > 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 roll-bounces@ietf.org Fri Mar 28 15:34:07 2008 Return-Path: X-Original-To: ietfarch-roll-archive@core3.amsl.com Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CD623A70C2; Fri, 28 Mar 2008 15:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.097 X-Spam-Level: X-Spam-Status: No, score=-101.097 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 EkREXY49V7hL; Fri, 28 Mar 2008 15:33:49 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 172313A6E60; Fri, 28 Mar 2008 15:33:45 -0700 (PDT) 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 E8BF93A6DC1 for ; Fri, 28 Mar 2008 15:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 rynZExRVWhhp for ; Fri, 28 Mar 2008 15:33:42 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id CFCB43A70A0 for ; Fri, 28 Mar 2008 15:30:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,572,1199682000"; d="scan'208";a="3361526" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 28 Mar 2008 18:30:31 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m2SMUUgN012661; Fri, 28 Mar 2008 18:30:30 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m2SMUUln008170; Fri, 28 Mar 2008 22:30:30 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 18:30:30 -0400 Received: from 10.86.104.186 ([10.86.104.186]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 28 Mar 2008 22:30:30 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 28 Mar 2008 18:30:29 -0400 From: JP Vasseur To: Teco Boot Message-ID: Thread-Topic: [Roll] [manet] Discussion on draft Thread-Index: AciQ7iLEM0hdCZI3T3WWVFw7bnR+RgAB8BfwAAtcFPk= In-Reply-To: <009a01c890f8$f4b7bb30$de273190$@nl> Mime-version: 1.0 X-OriginalArrivalTime: 28 Mar 2008 22:30:30.0448 (UTC) FILETIME=[54502300:01C89123] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5150; t=1206743431; x=1207607431; c=relaxed/simple; s=rtpdkim2001; 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[manet]=20Discussion=20on=20dr aft |Sender:=20 |To:=20Teco=20Boot=20; bh=zqKR8OlhsE7XorGDXf56lNFeXtt9nAaBr6s1239z6gQ=; b=eu1aI56AnuzIZaMaY+fe9NV86AJFgEwr9rypX+BMUQOL015If7SDxb4SfL 9DUCYfG2u9YWn+31VlGS/ScKQjyc0y4O80WjLVrdxxXWYSghp4AqxvayVJcP Bmpz2QEtcG; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] [manet] Discussion on 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Teco, Thanks for all your input here but I just wanted to remind you that we should not try to restart a MANEMO discussion here but rather focus on (1) the requirements documents according to our charter, and then (2) move to the protocol survey in light of these requirements. Cheers, JP. > From: Teco Boot > Date: Fri, 28 Mar 2008 18:27:11 +0100 > To: 'Kris Pister' > Cc: > Subject: Re: [Roll] [manet] Discussion on draft > > Hi, > > I do not know how to define mesh. I think it is a diffuse term. I tried to > define something in draft-boot-manet-nemo-analysis-01.txt (section 4.2). > > On using shortcuts in a tree structure, Pascal posted already on this. > See also slide 11 on > http://www.inf-net.nl/IETF69%20-%20Autoconf%20MANEMO%20scenarios%20and%20req > uirements.pdf > I described the congested link avoidance problem in > draft-boot-manet-nemo-analysis-01.txt, section 6.4. Both MANET and NEMO has > the problem. An integrated MANET and NEMO (or whatever) mechanism should > select a direct path or a path using the backbone. This is not that easy, > what is the selection criteria? > > Presentation on NEMO for MANET: > http://www.inf-net.nl/IETF70%20-%20Autoconf-nemo4manet.pdf > > Material is also on IETF webside, but packed in CDrom images! > > Teco. > >> -----Oorspronkelijk bericht----- >> Van: Kris Pister [mailto:pister@eecs.berkeley.edu] >> Verzonden: vrijdag 28 maart 2008 17:10 >> Aan: Teco Boot >> CC: roll@ietf.org >> Onderwerp: Re: [Roll] [manet] Discussion on draft >> >> Teco - I'm not sure how you define mesh, so forgive me if I'm missing >> the point. >> It's true that most of the mesh work in sensor networks to date has >> been >> to a single data sink. But there are also lots of examples in the >> literature in which local networking doesn't involve a gateway or >> backbone. This local networking is sometimes used for "distributed >> signal processing" (a very loaded phrase), and local feedback control >> loops. It's the feedback control that I think is starting to see real >> commercial traction. >> For industrial markets, I'm surprised that people are already starting >> to talk about local meshes for feedback control loops. I thought that >> it would take longer for them to get comfortable with the technology, >> but some at least are ready now. In many cases, this *requires* a >> local >> mesh, since the latency requirements effectively prohibit going through >> a backbone - if the sensor and actuator are close, there are probably >> fewer hops to get between them than to get to the backbone. >> >> ksjp >> >> Teco Boot wrote: >>> Hi Phil, >>> Maybe this raised before, but I miss a category of "xxx" protocols, >>> sometimes referred as "mesh" protocols. >>> "Mesh" is not pure MANET, as MANET routing protocols typically >> provide paths >>> within the MANET. "Mesh" protocols provide paths between nodes and a >>> backbone network. >>> MANET protocols can provide paths to the backbone also. The other way >> is not >>> always true, "mesh" protocols do typically not provide paths between >> nodes >>> or at least this is the second priority. >>> Maybe the draft only discuss existing IETF protocols (e.g. RFC exists >> or WG >>> is chartered), but I think the "mesh" type of protocols is worth >> mentioning. >>> Regards, Teco >>> >>> >>>> -----Oorspronkelijk bericht----- >>>> Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens >>>> Philip Levis >>>> Verzonden: vrijdag 28 maart 2008 4:43 >>>> Aan: roll@ietf.org; manet manet >>>> Onderwerp: [manet] Discussion on draft >>>> >>>> I'd like to start a discussion on draft-levis-roll-overview- >> protocols. >>>> In particular, Section 5.8 has a table of several existing protocols >>>> and their properties. This table is really going to be critical in >>>> ROLL's assessment of existing technologies and protocols, so we want >>>> to make sure that >>>> >>>> 1) It has the relevant data points to compare (protocols/rows) >>>> 2) It distills what the important properties are(columns) >>>> 3) It accurately captures the properties of the values in question >>>> (cells are accurate) >>>> >>>> Let's start with 1), as it's probably the simplest. Are there any >>>> protocols that we should be including that aren't there? Trying to >>>> cover every single minor protocol tweak is a recipe for disaster, >> but >>>> protocols that differ significantly from those currently there, >> either >>>> in mechanism or in properties, are important to include. >>>> >>>> Phil >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>> >>> _______________________________________________ >>> 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 roll-bounces@ietf.org Sun Mar 30 15:51:58 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CC3F28C1EF; Sun, 30 Mar 2008 15:51:58 -0700 (PDT) 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 CE9A93A6903 for ; Sun, 30 Mar 2008 15:51:56 -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 CIvFa8dE3csb for ; Sun, 30 Mar 2008 15:51:55 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by core3.amsl.com (Postfix) with ESMTP id 66D633A681E for ; Sun, 30 Mar 2008 15:51:54 -0700 (PDT) Received: from [192.168.2.38] (c-24-4-149-226.hsd1.ca.comcast.net [24.4.149.226]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.2/8.13.5) with ESMTP id m2UMpoiF017487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 30 Mar 2008 15:51:52 -0700 (PDT) Message-ID: <47F019E9.8050605@eecs.berkeley.edu> Date: Sun, 30 Mar 2008 15:53:29 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: roll@ietf.org References: <97E4819D-602B-45ED-97BA-3CA9E130E919@cs.stanford.edu> <007301c890a8$a0cc05d0$e2641170$@nl> <47ED1850.9050108@eecs.berkeley.edu> <009a01c890f8$f4b7bb30$de273190$@nl> In-Reply-To: <009a01c890f8$f4b7bb30$de273190$@nl> Subject: [Roll] What's a mesh? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org I'm not 100% sure that I know what a mesh is, but I know a lot of things that it's not. A tree, for example, is not a mesh, despite what the Zigbee specification defines (mesh = any multi-hop network). When I use google to look for "mesh" images, I get what I expect meshes to look like (some racier than others :) ). In a LLN, at least from an industrial process automation perspective, mesh means a digraph with path redundancy at every hop. Networks look like very small hammocks, with the two supporting eye-bolts as the source and destination. ksjp Teco Boot wrote: > Hi, > > I do not know how to define mesh. I think it is a diffuse term. I tried to > define something in draft-boot-manet-nemo-analysis-01.txt (section 4.2). > > On using shortcuts in a tree structure, Pascal posted already on this. > See also slide 11 on > http://www.inf-net.nl/IETF69%20-%20Autoconf%20MANEMO%20scenarios%20and%20req > uirements.pdf > I described the congested link avoidance problem in > draft-boot-manet-nemo-analysis-01.txt, section 6.4. Both MANET and NEMO has > the problem. An integrated MANET and NEMO (or whatever) mechanism should > select a direct path or a path using the backbone. This is not that easy, > what is the selection criteria? > > Presentation on NEMO for MANET: > http://www.inf-net.nl/IETF70%20-%20Autoconf-nemo4manet.pdf > > Material is also on IETF webside, but packed in CDrom images! > > Teco. > > >> -----Oorspronkelijk bericht----- >> Van: Kris Pister [mailto:pister@eecs.berkeley.edu] >> Verzonden: vrijdag 28 maart 2008 17:10 >> Aan: Teco Boot >> CC: roll@ietf.org >> Onderwerp: Re: [Roll] [manet] Discussion on draft >> >> Teco - I'm not sure how you define mesh, so forgive me if I'm missing >> the point. >> It's true that most of the mesh work in sensor networks to date has >> been >> to a single data sink. But there are also lots of examples in the >> literature in which local networking doesn't involve a gateway or >> backbone. This local networking is sometimes used for "distributed >> signal processing" (a very loaded phrase), and local feedback control >> loops. It's the feedback control that I think is starting to see real >> commercial traction. >> For industrial markets, I'm surprised that people are already starting >> to talk about local meshes for feedback control loops. I thought that >> it would take longer for them to get comfortable with the technology, >> but some at least are ready now. In many cases, this *requires* a >> local >> mesh, since the latency requirements effectively prohibit going through >> a backbone - if the sensor and actuator are close, there are probably >> fewer hops to get between them than to get to the backbone. >> >> ksjp >> >> Teco Boot wrote: >> >>> Hi Phil, >>> Maybe this raised before, but I miss a category of "xxx" protocols, >>> sometimes referred as "mesh" protocols. >>> "Mesh" is not pure MANET, as MANET routing protocols typically >>> >> provide paths >> >>> within the MANET. "Mesh" protocols provide paths between nodes and a >>> backbone network. >>> MANET protocols can provide paths to the backbone also. The other way >>> >> is not >> >>> always true, "mesh" protocols do typically not provide paths between >>> >> nodes >> >>> or at least this is the second priority. >>> Maybe the draft only discuss existing IETF protocols (e.g. RFC exists >>> >> or WG >> >>> is chartered), but I think the "mesh" type of protocols is worth >>> >> mentioning. >> >>> Regards, Teco >>> >>> >>> >>>> -----Oorspronkelijk bericht----- >>>> Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens >>>> Philip Levis >>>> Verzonden: vrijdag 28 maart 2008 4:43 >>>> Aan: roll@ietf.org; manet manet >>>> Onderwerp: [manet] Discussion on draft >>>> >>>> I'd like to start a discussion on draft-levis-roll-overview- >>>> >> protocols. >> >>>> In particular, Section 5.8 has a table of several existing protocols >>>> and their properties. This table is really going to be critical in >>>> ROLL's assessment of existing technologies and protocols, so we want >>>> to make sure that >>>> >>>> 1) It has the relevant data points to compare (protocols/rows) >>>> 2) It distills what the important properties are(columns) >>>> 3) It accurately captures the properties of the values in question >>>> (cells are accurate) >>>> >>>> Let's start with 1), as it's probably the simplest. Are there any >>>> protocols that we should be including that aren't there? Trying to >>>> cover every single minor protocol tweak is a recipe for disaster, >>>> >> but >> >>>> protocols that differ significantly from those currently there, >>>> >> either >> >>>> in mechanism or in properties, are important to include. >>>> >>>> Phil >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>>> >>> _______________________________________________ >>> 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 roll-bounces@ietf.org Sun Mar 30 16:01:24 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 122923A694E; Sun, 30 Mar 2008 16:01:24 -0700 (PDT) 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 6B01B28C220 for ; Sun, 30 Mar 2008 16:01:22 -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 0G5ulXq8IQ64 for ; Sun, 30 Mar 2008 16:01:21 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by core3.amsl.com (Postfix) with ESMTP id 7E9DF3A681E for ; Sun, 30 Mar 2008 16:00:30 -0700 (PDT) Received: from [192.168.2.38] (c-24-4-149-226.hsd1.ca.comcast.net [24.4.149.226]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.2/8.13.5) with ESMTP id m2UN0Q1g017554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 30 Mar 2008 16:00:28 -0700 (PDT) Message-ID: <47F01BED.5030802@eecs.berkeley.edu> Date: Sun, 30 Mar 2008 16:02:05 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Teco Boot References: <97E4819D-602B-45ED-97BA-3CA9E130E919@cs.stanford.edu> <007301c890a8$a0cc05d0$e2641170$@nl> <47ED1850.9050108@eecs.berkeley.edu> <009a01c890f8$f4b7bb30$de273190$@nl> In-Reply-To: <009a01c890f8$f4b7bb30$de273190$@nl> Cc: roll@ietf.org Subject: Re: [Roll] [manet] Discussion on 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Teco Boot wrote: > [...] > On using shortcuts in a tree structure, Pascal posted already on this. > I don't like tree structures, and I don't like the idea that mote-to-mote communication is a shortcut in some bigger picture. The transport between A and Z is going to have its own QoS, and it's own L2 resources dedicated to it, so it really should be thought of as a completely separate graph. > See also slide 11 on > http://www.inf-net.nl/IETF69%20-%20Autoconf%20MANEMO%20scenarios%20and%20req > uirements.pdf > I can guess at what HA, BR, MR, and H mean, but that doesn't look like a mesh to me. > I described the congested link avoidance problem in > draft-boot-manet-nemo-analysis-01.txt, section 6.4. Both MANET and NEMO has > the problem. An integrated MANET and NEMO (or whatever) mechanism should > select a direct path or a path using the backbone. This is not that easy, > what is the selection criteria? > For most LLN applications and motes, it's not a congestion problem but rather a question of satisfying QoS while respecting the power and energy restristions on the various motes along the path. These can be be cast as congestion problems, but not isomorphically I think. > Presentation on NEMO for MANET: > http://www.inf-net.nl/IETF70%20-%20Autoconf-nemo4manet.pdf > > Material is also on IETF webside, but packed in CDrom images! > > Teco. > > ksjp _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Sun Mar 30 16:13:04 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75F043A6C92; Sun, 30 Mar 2008 16:13:04 -0700 (PDT) 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 9B1A93A6C92 for ; Sun, 30 Mar 2008 16:13:03 -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 wNl4F7wKbNAd for ; Sun, 30 Mar 2008 16:13:02 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by core3.amsl.com (Postfix) with ESMTP id 3BCAF3A692F for ; Sun, 30 Mar 2008 16:13:02 -0700 (PDT) Received: from [192.168.2.38] (c-24-4-149-226.hsd1.ca.comcast.net [24.4.149.226]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.2/8.13.5) with ESMTP id m2UNCvU3017612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 30 Mar 2008 16:12:59 -0700 (PDT) Message-ID: <47F01EDC.8090601@eecs.berkeley.edu> Date: Sun, 30 Mar 2008 16:14:36 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC056EEC4A@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC056EEC4A@xmb-ams-337.emea.cisco.com> Cc: roll@ietf.org Subject: Re: [Roll] [manet] Discussion on 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Pascal Thubert (pthubert) wrote: > Hi Kris: > > I think that Teco means that finding a path inside the mesh might be a > second priority vs. finding the way to the sink. By Priority I mean that > intra mesh routing might: > > - require less optimized and well maintained path then the routing to > the sinks > I'm not sure that I follow. I think that most of the mote-to-mote traffic (at least in industrial) is likely to be either control-related, or human query/response, both of which are generally going to be more demanding of network resources than regular data reporting. > - have an on-demand flavor to maintain only certain routes as opposed to > any to any > I certainly agree that any-to-any is not a common requirement. Human interaction is likely to be fairly short-term and on-demand, but control loops will be long term (not on-demand? not sure of the definition). > - be used only for certain applications such as closed loop as opposed > to bulk data > - be scoped to limit the number of radio hops and default to route > around > I think that you have a mental picture of the network that might be different from mine. Picture a multi-square-kilometer refinery, most of which is a tank farm. A few hundred motes will give you a nice reliable mesh in that environment, but it might be 5-10 hops across. Local feedback loops and mobile workers will tend to be only one or two hops. The backbone will be in the refinery proper, many hops away. Even there, powered infrastructure will typically be several hops away. So hopping to/from the powered infrastructure will in general be more costly than the direct route. > The mesh strategy is to default to the backbone and then do some route > optimization. [...] > I completely disagree. That's the ISA vision of a mesh, where in Company X's ideal future they have managed to convince everyone to put a WiFi AP every 50 meters over many square kilometers. I just don't see it going that way in industrial. It's a more plausible picture in building automation or home automation though. > Pascal > ksjp > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >> > Kris Pister > >> Sent: vendredi 28 mars 2008 17:10 >> To: Teco Boot >> Cc: roll@ietf.org >> Subject: Re: [Roll] [manet] Discussion on draft >> >> Teco - I'm not sure how you define mesh, so forgive me if I'm missing >> the point. >> It's true that most of the mesh work in sensor networks to date has >> > been > >> to a single data sink. But there are also lots of examples in the >> literature in which local networking doesn't involve a gateway or >> backbone. This local networking is sometimes used for "distributed >> signal processing" (a very loaded phrase), and local feedback control >> loops. It's the feedback control that I think is starting to see real >> commercial traction. >> For industrial markets, I'm surprised that people are already starting >> to talk about local meshes for feedback control loops. I thought that >> it would take longer for them to get comfortable with the technology, >> but some at least are ready now. In many cases, this *requires* a >> > local > >> mesh, since the latency requirements effectively prohibit going through >> a backbone - if the sensor and actuator are close, there are probably >> fewer hops to get between them than to get to the backbone. >> >> ksjp >> >> Teco Boot wrote: >> >>> Hi Phil, >>> Maybe this raised before, but I miss a category of "xxx" protocols, >>> sometimes referred as "mesh" protocols. >>> "Mesh" is not pure MANET, as MANET routing protocols typically >>> > provide paths > >>> within the MANET. "Mesh" protocols provide paths between nodes and a >>> backbone network. >>> MANET protocols can provide paths to the backbone also. The other way >>> > is not > >>> always true, "mesh" protocols do typically not provide paths between >>> > nodes > >>> or at least this is the second priority. >>> Maybe the draft only discuss existing IETF protocols (e.g. RFC exists >>> > or WG > >>> is chartered), but I think the "mesh" type of protocols is worth >>> > mentioning. > >>> Regards, Teco >>> >>> >>> >>>> -----Oorspronkelijk bericht----- >>>> Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens >>>> Philip Levis >>>> Verzonden: vrijdag 28 maart 2008 4:43 >>>> Aan: roll@ietf.org; manet manet >>>> Onderwerp: [manet] Discussion on draft >>>> >>>> I'd like to start a discussion on >>>> > draft-levis-roll-overview-protocols. > >>>> In particular, Section 5.8 has a table of several existing protocols >>>> and their properties. This table is really going to be critical in >>>> ROLL's assessment of existing technologies and protocols, so we want >>>> to make sure that >>>> >>>> 1) It has the relevant data points to compare (protocols/rows) >>>> 2) It distills what the important properties are(columns) >>>> 3) It accurately captures the properties of the values in question >>>> (cells are accurate) >>>> >>>> Let's start with 1), as it's probably the simplest. Are there any >>>> protocols that we should be including that aren't there? Trying to >>>> cover every single minor protocol tweak is a recipe for disaster, >>>> > but > >>>> protocols that differ significantly from those currently there, >>>> > either > >>>> in mechanism or in properties, are important to include. >>>> >>>> Phil >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>>> >>> _______________________________________________ >>> 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 roll-bounces@ietf.org Mon Mar 31 03:17:50 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68B7A3A6D67; Mon, 31 Mar 2008 03:17:50 -0700 (PDT) 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 24CDA3A6930; Mon, 31 Mar 2008 03:17:49 -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 Pf9SStabOW4e; Mon, 31 Mar 2008 03:17:48 -0700 (PDT) Received: from scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by core3.amsl.com (Postfix) with ESMTP id B2C8D3A68AB; Mon, 31 Mar 2008 03:17:47 -0700 (PDT) Received: from castor.cttc.es (castor.cttc.es [84.88.62.196]) by scorpius.cttc.es (8.13.8/8.13.5) with ESMTP id m2VAFsvC019631 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 31 Mar 2008 12:15:54 +0200 Received: from CTTCPCMDOHLER (pcmdohler.cttc.es [84.88.61.89]) (authenticated bits=0) by castor.cttc.es (8.13.2/8.13.3) with ESMTP id m2VAFsF2012263 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 31 Mar 2008 12:16:00 +0200 Message-Id: <200803311016.m2VAFsF2012263@castor.cttc.es> From: "Mischa Dohler" To: "'Philip Levis'" , , "'manet manet'" Date: Mon, 31 Mar 2008 12:14:56 +0200 Organization: CTTC MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciQhiuB7l706Z4bTqiOtmiFdzpaUgCj/a/g In-Reply-To: <97E4819D-602B-45ED-97BA-3CA9E130E919@cs.stanford.edu> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (castor.cttc.es [84.88.62.196]); Mon, 31 Mar 2008 12:16:00 +0200 (CEST) X-Scanned-By: MIMEDefang 2.57 on 84.88.62.197 Subject: Re: [Roll] Discussion on draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mischa.dohler@cttc.es List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Dear Phil, dear all, Sorry to start a new thread but my email does not quite fit into recent discussions. I and my colleagues at France Telecom support Phil's initiative of identifying the right set of protocols. However, personally, I am not quite sure why only link-state and distance-vector based protocols are listed. WSNs not only offer but also require different approaches - this had also been stated in recent discussions and we would like some canonical versions of these protocols to feature in the overview draft. My colleague Thomas Watteyne (cc'ed) has summarized some approaches based on "virtual/relative/approximate coordinates" (many terms for the same idea) as follows: - First, there is a set of propositions which infer the nodes "approximate coordinates" from a set of location aware anchor nodes. (Greedy) geographic routing protocols can then run on top of these coordinates, although the delivery ratio is rather low. - "Relative coordinates" can be inferred from a set of location-unaware anchor nodes. Coordinates are in fact a vector of distances (e.g. in hops) to these anchors. Protocols such as Vcap (infocom'06) and Gspring (ICNP'07) function this way. The good news is that delivery ratios on those relative coordinates are higher than if the same nodes knew their real coordinates (!). Drawback is that they need some sort of initialization, identification of the anchor nodes. Also, coordinate refreshing procedures seem not to be published. - Recently, the use of completely virtual coordinates has been proposed. These coordinates are randomly initialized when a node is booted. Whenever a node sends a message, it updates its virtual coordinate as a function of its neighbors' ones. A near-greedy geographic routing protocol is then used on top of these coordinates. Simulation results show that the network converges to a state where path length in number of hops exceeds the optimal one by a few percent. Whilst these approaches may not be of use for industrial or home automation, we are pretty sure that they are vital for urban applications as network lifetimes are significantly increased. Regards, Mischa. -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: Friday, March 28, 2008 4:43 AM To: roll@ietf.org; manet manet Subject: [Roll] Discussion on draft I'd like to start a discussion on draft-levis-roll-overview-protocols. In particular, Section 5.8 has a table of several existing protocols and their properties. This table is really going to be critical in ROLL's assessment of existing technologies and protocols, so we want to make sure that 1) It has the relevant data points to compare (protocols/rows) 2) It distills what the important properties are(columns) 3) It accurately captures the properties of the values in question (cells are accurate) Let's start with 1), as it's probably the simplest. Are there any protocols that we should be including that aren't there? Trying to cover every single minor protocol tweak is a recipe for disaster, but protocols that differ significantly from those currently there, either in mechanism or in properties, are important to include. 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 roll-bounces@ietf.org Mon Mar 31 07:01:01 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDBB328C47E; Mon, 31 Mar 2008 07:01:01 -0700 (PDT) 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 ED82528C47E for ; Mon, 31 Mar 2008 07:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 Xv32RCDanl4p for ; Mon, 31 Mar 2008 07:00:50 -0700 (PDT) Received: from cypress.ugent.be (cypress.ugent.be [157.193.71.48]) by core3.amsl.com (Postfix) with ESMTP id C427D28C477 for ; Mon, 31 Mar 2008 07:00:26 -0700 (PDT) Received: from gorilla.ugent.be (HELO localhost) ([157.193.49.20]) by cypress.ugent.be with ESMTP; 31 Mar 2008 16:00:24 +0200 Received: from cypress.ugent.be ([157.193.71.48]) by localhost (gorilla.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id 13515-05-6; Mon, 31 Mar 2008 16:00:24 +0200 (CEST) Received: from mail4.intec.ugent.be ([157.193.214.4]) by cypress.ugent.be with ESMTP; 31 Mar 2008 16:00:23 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwEAACL8EedwdYE/2dsb2JhbACCOzemTA Received: from localhost (localhost [127.0.0.1]) by mail4.intec.ugent.be (Postfix) with ESMTP id 1B99940B2B9; Mon, 31 Mar 2008 16:00:19 +0200 (CEST) Received: from mail4.intec.ugent.be ([127.0.0.1]) by localhost (mail4.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mT0Xf8cSav98; Mon, 31 Mar 2008 16:00:18 +0200 (CEST) Received: from [157.193.214.151] (crane.intec.ugent.be [157.193.214.151]) by mail4.intec.ugent.be (Postfix) with ESMTP id C62A940011C; Mon, 31 Mar 2008 16:00:18 +0200 (CEST) Message-ID: <47F0EECB.1000605@intec.ugent.be> Date: Mon, 31 Mar 2008 16:01:47 +0200 From: Pieter De Mil User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Vincent Rossi References: <47D76D36.9080501@archrock.com> <785cd670803130653o78352da7ia7d0ca7a78ad1f8@mail.gmail.com> <47EB5153.9000509@ens-lyon.fr> In-Reply-To: <47EB5153.9000509@ens-lyon.fr> X-Virus-Scanned: by UGent DICT Cc: roll@ietf.org Subject: Re: [Roll] Home Requirements Feedback 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: , Content-Type: multipart/mixed; boundary="===============1715020825==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============1715020825== Content-Type: multipart/alternative; boundary="------------060304030106000105030802" This is a multi-part message in MIME format. --------------060304030106000105030802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Vincent, All, Vincent Rossi wrote: > Hi everyone, > > First of all, thank you Anders for this first draft. It really helps > writing down some specific requirements for the home automation > routing over L2N. > I would like to add my contribution to this work. It will be divided > in two parts. > First, I will make some comments on the current draft (and discuss > about the comments made by others). > And finally, there is an other example/use-case that I really would > like to appear in this draft (but even if it is a draft, the issue > should be discussed first). > > Concerning my comments, I totally agree with the idea of the > group-cast even if it is also not very clear to me how it would be > implemented (cf. previous comments). > > About the routing protocol, I understand that this draft is oriented > toward an inner network for the house only but it appears (c.f. > Section 3.6) that a need to connect to a wider network (e.g. Internet) > will be required for some devices. I simply wonder how the bridge will > be established between our network (with a wide variety of devices...) > and the house's Internet connection. Of course, the routing can be > handled by a more powerful unit but I think it should be stated how > this should work (one gateway, multiple gateways...). > > Furthermore, considering this approach, I think it would be nice to be > considering sharing part of the house's state with some well-known > entities (electricity provider, surveillance companies...), this also > implies further thinking about the security layer of such networks. True, we don't want that surveillance company A has access to devices other than the subset of devices (with your permission: smoke detector, motion detector, keypads, siren,...) which are essential for the service provided by that company A (for example surveillance of your home). This approach raises the following 'problem': a motion detector can be useful in several scenarios: surveillance, HVAC, lighting,... If we are not at home and the alarm is switched on: where is the intelligence? Should the motion detector send a message to a (group of) lights, the same message (but in another packet) to the surveillance service provider on the Internet, and the same message (but in another packet) to the HVAC system controller? We probably don't want to turn on the heating for the potential thief. Do we care about the "popcorn" effect on HVAC systems? Do we want to send one "groupcast" message (one packet) to every device interested in the events detected by the motion detector? Maybe 1 (if we don't have different types of groupcast messages) or 2 (if we have an "avoid popcorn effect" groupcast message type and a "best effort" groupcast message type) groupcast messages and one unicast to the central management system (CMS)? This central management system can: -manage the network, -keep a list of devices with their profiles ( a profile contains the capabilities of the device (battery-powered / mains-powered; part of route or not; ...), -maintain the policies (restrict interactions between services, sensors and actuators), -provide security & AAA. -... In the home environment, we can group the CMS and the bridge to the wan, lan, wireless, sensor,... interfaces in a single embedded device (the Home Gateway). > > Considering the location of the devices, as asked by Jonathan, I tend > to think that we must take into consideration the physical and > environmental restrictions due to the devices that will be deployed in > a "hostile" environment. I mean that devices located outdoor may > suffer harder radio perturbations (thicker walls with iron > structure...), rain, variation in temperatures, all altering the > battery's lifetime (and so much more). So a question would be: how > should we deal with such devices? Should we prevent them to be part of > a route? Should they forward packets? > The idea of a gateway between the Internet and the WSN seems to be > broadly accepted. We may see several of these gw providing links to > the Internet and management capabilities to the WSN. This reduces SPOF > and also provide new routing issues. > > About Gopinath's contribution (about the categorization of use-cases), > I think that it would also be clearer to separate the use-cases and > try to group them by routing topology/goal/problems. The problem is > that if we get more and more use-cases, some of them won't probably > fit in one particular category. I think that the use-cases must be > more like concrete examples illustrating a particular problem about > routing within a house (which is exactly what they are right now). > > Another remark would be about the automation itself. All of the > use-cases are oriented toward the user, providing services, often in > response to a certain input from the user (except for the networked > smoke alarm). I also think that future applications of home automation > should tend to be discrete and seamless. I think that the best > embedded systems are those you can forget about. Of course, some > use-cases are very interesting but instead of needing the users input, > some can be automated (especially, section 3.1 and 3.4) by a device > located somewhere on the Internet. Is this changing the routing > requirements and policies? > > Considering the important point of energy consumption (stated in 3.5 > about the ability to change the battery), I also think that in the aim > of an "intelligent" house (I guess we can call it like that), the > technology should not be visible. And this rises the problem of > changing batteries for some devices. Even if we can think about a > couple of years of operation on a single battery, we must think about > how the routing protocol should handle the powering state of the > nodes. I mean, this issue has already been covered in section 4.2 in > the case a node cannot be part of a route, but if a node is truly > dead, there is a good chance we never know about it (because another > route will be used). I think that a change in the route used must be > considered as an anomaly as long as they are not repetitive. It is a > real and hard problem. If a change of route occurs from time to time, > we can assume it is because of human activity (like described in the > middle of section 2), but if it is a longer route change, there are 2 > main problems, first, there is a good chance we do not keep track that > the route has changed, and then, it may be because a node is "dead", > or simply because the node has been removed. My question would be how > the SNMP protocol should be supported on such a network and/or, should > this matter be raised to the application level. Nevertheless, it is, > according to me, an important issue and we should really discuss it. I agree that management is important, but I'm not sure if we want to run SNMP (as it is) on a home sensor network. Do we want push, pull, or hybrid? We should minimize the amount of traffic generated by the network management function. > > This leads to another comment (again!). Considering this draft is > about routing, I think that we should define the routing elements that > can appear in such environment. It has already been started in section > 4.2 but I think that maybe we can define some specific devices for the > network topology (like it exists in wired networks). > > Actually, I can see 3 types of devices: > -sensors, which are more likely to send status but not receiving > anything (no need to listen to the radio traffic) > -actuators, which will probably only receive orders but may also send > their status/result of action, through the network > -routers-forwarder, which are only designed to reach some dark areas > of the network > Of course, some devices may be using a mix of these primary features. I don't agree with this classification. Do we want to manage the sensor? How do we configure a sensor if it can't receive anything? The range of devices is very broad. We can have "stupid" sensors which will only send status and "intelligent" sensors which we can manage and configure. > > Should they all have an IP address ? Good question. Do you mean that, if we attach 2 sensors and 1 actuator on 1 physical node or mote, you assign 4 addresses (the "naked" node must be addressable)? Maybe we can keep this identification to the application level (considering sensors and actuators as applications) and only assign a(n) address(es) to the node. > or just the micro-controler ? Should we stay with FFD and RFD > restrictions ? Idea: every node and every application (sensor, actuator,...) has a profile that defines, among other things, the restrictions for the routing protocol. > I would like your opinion on such a partition of the devices > abilities. I think it would help hardware and software design to help > achieve the goal of an efficient routing in the home. > Considering the network as a graph could we assume the information is > transmitted one way, two ways... > > Another comment would be about the addressing. As you probably know, > the current motes are providing multiple way to interact with the > environment (may it be with sensors, actuators...), but often, there > is only one network interface and then, only one network address, but > how about we only want to access one sensor on a mote which possesses > many? Should the packet contain the sensor ID or can we think of a > protocol that could address directly to a particular sensor/actuator > without the help of an embedded DB? I mean that we might want to > access not only a mote but a particular sensor from a mote, without > pushing this to the application layer. This could result in a very > efficient way to access/collect data we want and prevent use of the > micro-controller of the mote for treating many packets and gathering > information from sensor we do not want information. Do you want to address a particular sensor on a mote without using the micro-controller? What's the difference between addressing a mote via a separate IP address, or via a mote IP address + sensor ID? If mote A possesses 30 sensors, and we want to change a setting on 15 sensors, you'll need 15 messages. Do you want this? Can you give a use case where this is useful? > > And at last, this is the use-case I propose for this draft: it > concerns energy efficiency in the home. > Considering the increasing need of reducing power consumption on the > planet, home automation may be use to optimize energy consumption. > This said, there would be several ways to do so. First, activating the > windows shades without user intervention based on the solar energy > available to heat the house, even if no one is actually in the home. > Another way would be to set some levels of heating, room by room and > thus there we need the group-cast functionality, based on current > temperature, moment of the day and other pieces of informations, > provided by the sensors in the home and/or even from the Internet. > The main aspect of this application, which is quite similar to the one > described in section 3.1, is that it should appear seamless to the > user. Another extension would be to forward the information from the > sensors, not directly but after some computation, to the services > providers such as gas, water and electricity ones so that they can > adjust the supplies furnished to the home and therefore, reduce the > power consumption based on estimation of need. > The routing protocol should then be designed so that sensors are able > to gather their info, transmit them to a or multiple central unit(s), > and then, after following some model, action can be taken and orders > distributed among actuators. Some simpler decisions can be taken by > the sensor itself and transmitted directly to the according actuator. > About the part on transmitting the information outside of the house, > there must be a way to communicate securely between the inner network > and the Internet. I agree, energy management is an interesting use case. I'm working on a draft on routing requirements for wireless building automation, and this is one of the applications (I'll be happy to receive input). Using such a system /Vooruit/ (an arts centre in a restored monument, consisting of 366 different rooms) has realized a saving of 35% on the gas and electricity bills. > > Thank you if you have successfully come this far and read everything, > I can't wait for your (numerous) replies :) > > Vincent > Pieter -- Pieter De Mil Department of Information Technology (INTEC) Ghent University Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium tel.: +32-9331 4981; tel. secr.: +32-9331 4900 fax: +32-9331 4899 pieter.demil@intec.ugent.be http://www.ibcn.intec.ugent.be Confidentiality Statement: This e-mail and any attached files are confidential and may be legally privileged. If you are not the addressee, any disclosure, reproduction, copying, distribution, or other dissemination or use of this communication is strictly prohibited. If you have received this transmission in error please notify INTEC immediately and then delete this e-mail. INTEC does not accept liability for the correct and complete transmission of the information, nor for any delay or interruption of the transmission, nor for damages arising from the use of or reliance on the information. --------------060304030106000105030802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Vincent, All,

Vincent Rossi wrote:
Hi everyone,

First of all, thank you Anders for this first draft. It really helps writing down some specific requirements for the home automation routing over L2N.
I would like to add my contribution to this work. It will be divided in two parts.
First, I will make some comments on the current draft (and discuss about the comments made by others).
And finally, there is an other example/use-case that I really would like to appear in this draft (but even if it is a draft, the issue should be discussed first).

Concerning my comments, I totally agree with the idea of the group-cast even if it is also not very clear to me how it would be implemented (cf. previous comments).

About the routing protocol, I understand that this draft is oriented toward an inner network for the house only but it appears (c.f. Section 3.6) that a need to connect to a wider network (e.g. Internet) will be required for some devices. I simply wonder how the bridge will be established between our network (with a wide variety of devices...) and the house's Internet connection. Of course, the routing can be handled by a more powerful unit but I think it should be stated how this should work (one gateway, multiple gateways...).

Furthermore, considering this approach, I think it would be nice to be considering sharing part of the house's state with some well-known entities (electricity provider, surveillance companies...), this also implies further thinking about the security layer of such networks.

True, we don't want that surveillance company A has access to devices other than the subset of devices (with your permission: smoke
detector, motion detector, keypads, siren,...) which are essential for the service provided by that company A (for example surveillance of your home).
 This approach raises the following 'problem': a motion detector can be useful in several scenarios: surveillance, HVAC, lighting,...
 If we are not at home and the alarm is switched on: where is the intelligence? Should the motion detector send a message to a (group of) lights, the same message (but in another packet) to the surveillance service provider on the Internet, and the same message (but in another packet) to the HVAC system controller? We probably don't want to turn on the heating for the potential thief. Do we care about the "popcorn" effect on HVAC systems?

Do we want to send one "groupcast" message (one packet) to every device interested in the events detected by the motion detector? Maybe 1 (if we don't have different types of groupcast messages) or 2 (if we have an "avoid popcorn effect" groupcast message type and a "best effort" groupcast message type) groupcast messages and one unicast to the central management system (CMS)? 

This central management system can:
-manage the network,
-keep a list of devices with their profiles ( a profile contains the capabilities of the device (battery-powered / mains-powered; part of route or not; ...),
-maintain the policies (restrict interactions between services, sensors and actuators),
-provide security & AAA.
-...

In the home environment, we can group the CMS and the bridge to the wan, lan, wireless, sensor,... interfaces in a single embedded device (the Home Gateway).
 

Considering the location of the devices, as asked by Jonathan, I tend to think that we must take into consideration the physical and environmental restrictions due to the devices that will be deployed in a "hostile" environment. I mean that devices located outdoor may suffer harder radio perturbations (thicker walls with iron structure...), rain, variation in temperatures, all altering the battery's lifetime (and so much more). So a question would be: how should we deal with such devices? Should we prevent them to be part of a route? Should they forward packets?
The idea of a gateway between the Internet and the WSN seems to be broadly accepted. We may see several of these gw providing links to the Internet and management capabilities to the WSN. This reduces SPOF and also provide new routing issues.

About Gopinath's contribution (about the categorization of use-cases), I think that it would also be clearer to separate the use-cases and try to group them by routing topology/goal/problems. The problem is that if we get more and more use-cases, some of them won't probably fit in one particular category. I think that the use-cases must be more like concrete examples illustrating a particular problem about routing within a house (which is exactly what they are right now).

Another remark would be about the automation itself. All of the use-cases are oriented toward the user, providing services, often in response to a certain input from the user (except for the networked smoke alarm). I also think that future applications of home automation should tend to be discrete and seamless. I think that the best embedded systems are those you can forget about. Of course, some use-cases are very interesting but instead of needing the users input, some can be automated (especially, section 3.1 and 3.4) by a device located somewhere on the Internet. Is this changing the routing requirements and policies?

Considering the important point of energy consumption (stated in 3.5 about the ability to change the battery), I also think that in the aim of an "intelligent" house (I guess we can call it like that), the technology should not be visible. And this rises the problem of changing batteries for some devices. Even if we can think about a couple of years of operation on a single battery, we must think about how the routing protocol should handle the powering state of the nodes. I mean, this issue has already been covered in section 4.2 in the case a node cannot be part of a route, but if a node is truly dead, there is a good chance we never know about it (because another route will be used). I think that a change in the route used must be considered as an anomaly as long as they are not repetitive. It is a real and hard problem. If a change of route occurs from time to time, we can assume it is because of human activity (like described in the middle of section 2), but if it is a longer route change, there are 2 main problems, first, there is a good chance we do not keep track that the route has changed, and then, it may be because a node is "dead", or simply because the node has been removed. My question would be how the SNMP protocol should be supported on such a network and/or, should this matter be raised to the application level. Nevertheless, it is, according to me, an important issue and we should really discuss it.
I agree that management is important, but I'm not sure if we want to run SNMP (as it is) on a home sensor network.
Do we want push, pull, or hybrid? We should minimize the amount of traffic generated by the network management function.


This leads to another comment (again!). Considering this draft is about routing, I think that we should define the routing elements that can appear in such environment. It has already been started in section 4.2 but I think that maybe we can define some specific devices for the network topology (like it exists in wired networks).

Actually, I can see 3 types of devices:
-sensors, which are more likely to send status but not receiving anything (no need to listen to the radio traffic)
-actuators, which will probably only receive orders but may also send their status/result of action, through the network
-routers-forwarder, which are only designed to reach some dark areas of the network
Of course, some devices may be using a mix of these primary features.

I don't agree with this classification. Do we want to manage the sensor? How do we configure a sensor if it can't receive anything?
The range of devices is very broad. We can have "stupid" sensors which will only send status and "intelligent" sensors which we can manage and configure.


Should they all have an IP address ?

Good question. Do you mean that, if we attach 2 sensors and 1 actuator on 1 physical node or mote, you assign 4 addresses (the "naked" node must be addressable)?
Maybe we can keep this identification to the application level (considering sensors and actuators as applications) and only assign a(n) address(es) to the node.
or just the micro-controler ? Should we stay with FFD and RFD restrictions ?

Idea: every node and every application (sensor, actuator,...) has a profile that defines, among other things, the restrictions for the routing protocol.

I would like your opinion on such a partition of the devices abilities. I think it would help hardware and software design to help achieve the goal of an efficient routing in the home.
Considering the network as a graph could we assume the information is transmitted one way, two ways...

Another comment would be about the addressing. As you probably know, the current motes are providing multiple way to interact with the environment (may it be with sensors, actuators...), but often, there is only one network interface and then, only one network address, but how about we only want to access one sensor on a mote which possesses many? Should the packet contain the sensor ID or can we think of a protocol that could address directly to a particular sensor/actuator without the help of an embedded DB? I mean that we might want to access not only a mote but a particular sensor from a mote, without pushing this to the application layer. This could result in a very efficient way to access/collect data we want and prevent use of the micro-controller of the mote for treating many packets and gathering information from sensor we do not want information.

Do you want to address a particular sensor on a  mote without using the micro-controller? What's the difference between addressing a mote via a separate IP address, or via a mote IP address + sensor ID?
If mote A possesses 30 sensors, and we want to change a setting on 15 sensors, you'll need 15 messages. Do you want this? Can you give a use case where this is useful?


And at last, this is the use-case I propose for this draft: it concerns energy efficiency in the home.
Considering the increasing need of reducing power consumption on the planet, home automation may be use to optimize energy consumption. This said, there would be several ways to do so. First, activating the windows shades without user intervention based on the solar energy available to heat the house, even if no one is actually in the home. Another way would be to set some levels of heating, room by room  and thus there we need the group-cast functionality, based on current temperature, moment of the day and other pieces of informations, provided by the sensors in the home and/or even from the Internet.
The main aspect of this application, which is quite similar to the one described in section 3.1, is that it should appear seamless to the user. Another extension would be to forward the information from the sensors, not directly but after some computation, to the services providers such as gas, water and electricity ones so that they can adjust the supplies furnished to the home and therefore, reduce the power consumption based on estimation of need.
The routing protocol should then be designed so that sensors are able to gather their info, transmit them to a or multiple central unit(s), and then, after following some model, action can be taken and orders distributed among actuators. Some simpler decisions can be taken by the sensor itself and transmitted directly to the according actuator. About the part on transmitting the information outside of the house, there must be a way to communicate securely between the inner network and the Internet.
I agree, energy management is an interesting use case. I'm working on a draft on routing requirements for wireless building automation, and this is one of the applications (I'll be happy to receive input). Using such a system Vooruit (an arts centre in a restored monument, consisting of 366 different rooms) has realized a saving of 35% on the gas and electricity bills.



Thank you if you have successfully come this far and read everything,
I can't wait for your (numerous) replies :)

Vincent

Pieter

-- 
Pieter De Mil
Department of Information Technology (INTEC)
Ghent University
Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium
tel.: +32-9331 4981; tel. secr.: +32-9331 4900
fax: +32-9331 4899
pieter.demil@intec.ugent.be
http://www.ibcn.intec.ugent.be

Confidentiality Statement:
This e-mail and any attached files are confidential and may be legally privileged. If you are not the addressee, any disclosure, reproduction, copying, distribution, or other dissemination or use of this communication is strictly prohibited. If you have received this transmission in error please notify INTEC immediately and then delete this e-mail. INTEC does not accept liability for the correct and complete transmission of the information, nor for any delay or interruption of the transmission, nor for damages arising from the use of or reliance on the information.
--------------060304030106000105030802-- --===============1715020825== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1715020825==-- From roll-bounces@ietf.org Mon Mar 31 09:36:20 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B9FB3A6DFA; Mon, 31 Mar 2008 09:36:20 -0700 (PDT) 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 DE3E13A6D03; Mon, 31 Mar 2008 09:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.915 X-Spam-Level: X-Spam-Status: No, score=-3.915 tagged_above=-999 required=5 tests=[AWL=2.684, 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 xjLlQp854-LL; Mon, 31 Mar 2008 09:36:17 -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 10D8D3A6E2E; Mon, 31 Mar 2008 09:36:15 -0700 (PDT) Received: from c-71-198-71-178.hsd1.ca.comcast.net ([71.198.71.178] helo=[192.168.2.105]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1JgMzV-0004wo-43; Mon, 31 Mar 2008 09:36:13 -0700 Message-Id: <6DBCCFE3-3EE9-43C5-B920-7C213FAC07FD@cs.stanford.edu> From: Philip Levis To: In-Reply-To: <200803311016.m2VAFsF2012263@castor.cttc.es> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 31 Mar 2008 09:36:12 -0700 References: <200803311016.m2VAFsF2012263@castor.cttc.es> X-Mailer: Apple Mail (2.919.2) X-Scan-Signature: fb418a055a615a79fddacbea7bf2a8e8 Cc: roll@ietf.org, 'manet manet' Subject: Re: [Roll] Discussion on 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Mar 31, 2008, at 3:14 AM, Mischa Dohler wrote: > Dear Phil, dear all, > > Sorry to start a new thread but my email does not quite fit into > recent > discussions. > > I and my colleagues at France Telecom support Phil's initiative of > identifying the right set of protocols. However, personally, I am > not quite > sure why only link-state and distance-vector based protocols are > listed. Because they are existing IETF protocols with RFCs. > WSNs not only offer but also require different approaches - this had > also > been stated in recent discussions and we would like some canonical > versions > of these protocols to feature in the overview draft. The purpose of this draft is to survey IETF protocols, so that we can then judge how best to move forward towards defining a protocol for WSNs. Its purpose is expressly *not* to survey research, other standards body, and custom protocols. That would be part of a next step, if the WG reaches consensus that existing solutions are insufficient. > > > My colleague Thomas Watteyne (cc'ed) has summarized some approaches > based on > "virtual/relative/approximate coordinates" (many terms for the same > idea) as > follows: > - First, there is a set of propositions which infer the nodes > "approximate > coordinates" from a set of location aware anchor nodes. (Greedy) > geographic > routing protocols can then run on top of these coordinates, although > the > delivery ratio is rather low. > - "Relative coordinates" can be inferred from a set of location- > unaware > anchor nodes. Coordinates are in fact a vector of distances (e.g. in > hops) > to these anchors. Protocols such as Vcap (infocom'06) and Gspring > (ICNP'07) > function this way. The good news is that delivery ratios on those > relative > coordinates are higher than if the same nodes knew their real > coordinates > (!). Drawback is that they need some sort of initialization, > identification > of the anchor nodes. Also, coordinate refreshing procedures seem not > to be > published. All of these results are from high-level simulators which use a unit- disk model for radio connectivity. Their claims therefore need to be taken with a grain of salt. Among other things, they do not consider any kind of temporal dynamics. There is a long literature of coordinate embedding approaches for wireless as well as wired networks. Just in the past few years, before the two you cite above, there is GEM (SenSys '03), Vivaldi (SIGCOMM '04), and BVR (NSDI '05). When it comes to scalable routing approaches, the state of the art in research today is S4 (NSDI '07), which uses compact routing techniques to ensure O(sqrt(n)) routing state with a maximum routing stretch of 3 and, in simulation and simple testbed experiments, an observed average routing stretch of 1.1. Recent work on compact routing has shown there is a fundamental tradeoff between routing state and stretch; while geometric or coordinate approaches enable nodes to have O(1) routing state, their stretch is unbounded. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Mar 31 11:31:02 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 318C928C2CE; Mon, 31 Mar 2008 11:31:02 -0700 (PDT) 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 2FCF728C38D for ; Mon, 31 Mar 2008 11:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.062 X-Spam-Level: X-Spam-Status: No, score=-4.062 tagged_above=-999 required=5 tests=[AWL=2.537, 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 6Pj9FZycMDxh for ; Mon, 31 Mar 2008 11:30:59 -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 5CC6328C3F4 for ; Mon, 31 Mar 2008 11:30:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,583,1199660400"; d="scan'208";a="4968209" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 31 Mar 2008 20:30:48 +0200 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 m2VIUmgq031904; Mon, 31 Mar 2008 20:30:48 +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 m2VIUmGc010274; Mon, 31 Mar 2008 18:30:48 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Mar 2008 20:30:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 31 Mar 2008 20:27:12 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0575A171@xmb-ams-337.emea.cisco.com> In-Reply-To: <47F01EDC.8090601@eecs.berkeley.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [manet] Discussion on draft thread-index: AciSu53xweeRKFQ8SqWx8YUs7EpfXAAmpsZw From: "Pascal Thubert (pthubert)" To: "Kris Pister" X-OriginalArrivalTime: 31 Mar 2008 18:30:48.0656 (UTC) FILETIME=[57561500:01C8935D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8397; t=1206988248; x=1207852248; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20[manet]=20Discussion=20on=20dr aft |Sender:=20; bh=8c+niGo2lb2ROlCAGaBMsrelxqiHhvyNxw/t1Yu6k4A=; b=VZQQaAwHKi3x3n+zdlSv1v9flogiAxVxJIBo1EbPzSpuVN0hjBnx37pkKL 4m+sFxmYw2j5cAvC2aVNbhnwPyI96Hx9nvkgdSt878AyZh49Ichyw6+1VWmt 2rDCYOGw6O; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] [manet] Discussion on 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Kris: I think we lost sync here. We were discussing Phil's draft and comparing routing strategies inside the Low-power Lossy Network. I did not attend to discuss whether there is a backbone and what that backbone is made of, WIFI mesh or else. The disconnect might have come from the word mesh, and yes I know what you are talking about but please let's not get there now. So let me please recap: First, on-demand means that you establish a path because you find that you need it. On-demand is very practical when you have constraints to place like class 0 because you can qualify the route that you want to build and build specifically what you want. On-demand was designed with host routes in mind and for that reason it plays well at layer 2 (Token Ring test frame, 802.11s AODV etc...) though it has already one major application at layer 3 for voice, since RSVP is also an on-demand protocol. In this thread, I was saying that the "any to any" optimized routing strategy that we find in proactive routing (OSPF, OLSR, etc...) spends a lot of energy computing LLN internal routes that we will never need and we seem to agree on that part. On the other end of the spectrum, full on-demand strategies (DYMO, DSR, AODV...) are reactive even for routes that we need in all configurations. So I was advocating the mesh strategy that is proactive for the routes to the sink and on-demand for the LLN internal routes. It is a specific 'mixed' strategy that recognizes the flows that we really have in sensors as opposed to the generic problem that other manet 'mixed' strategies can address. And I was pointing the cool side that if a need pops up (like this guy with his handheld) an unoptimized route exists to start with even if that means going to the sink and back. A better route can be established if the flows are characterized to require it; this is what I called optimizing the route. I hope my point is clearer now, Pascal >-----Original Message----- >From: Kris Pister [mailto:pister@eecs.berkeley.edu] >Sent: lundi 31 mars 2008 01:15 >To: Pascal Thubert (pthubert) >Cc: Teco Boot; roll@ietf.org >Subject: Re: [Roll] [manet] Discussion on draft > >Pascal Thubert (pthubert) wrote: >> Hi Kris: >> >> I think that Teco means that finding a path inside the mesh might be a >> second priority vs. finding the way to the sink. By Priority I mean that >> intra mesh routing might: >> >> - require less optimized and well maintained path then the routing to >> the sinks >> >I'm not sure that I follow. I think that most of the mote-to-mote >traffic (at least in industrial) is likely to be either control-related, >or human query/response, both of which are generally going to be more >demanding of network resources than regular data reporting. >> - have an on-demand flavor to maintain only certain routes as opposed to >> any to any >> >I certainly agree that any-to-any is not a common requirement. Human >interaction is likely to be fairly short-term and on-demand, but control >loops will be long term (not on-demand? not sure of the definition). >> - be used only for certain applications such as closed loop as opposed >> to bulk data >> - be scoped to limit the number of radio hops and default to route >> around >> >I think that you have a mental picture of the network that might be >different from mine. Picture a multi-square-kilometer refinery, most of >which is a tank farm. A few hundred motes will give you a nice reliable >mesh in that environment, but it might be 5-10 hops across. Local >feedback loops and mobile workers will tend to be only one or two hops. >The backbone will be in the refinery proper, many hops away. Even >there, powered infrastructure will typically be several hops away. So >hopping to/from the powered infrastructure will in general be more >costly than the direct route. >> The mesh strategy is to default to the backbone and then do some route >> optimization. [...] >> >I completely disagree. That's the ISA vision of a mesh, where in >Company X's ideal future they have managed to convince everyone to put a >WiFi AP every 50 meters over many square kilometers. I just don't see >it going that way in industrial. It's a more plausible picture in >building automation or home automation though. >> Pascal >> >ksjp >> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >>> >> Kris Pister >> >>> Sent: vendredi 28 mars 2008 17:10 >>> To: Teco Boot >>> Cc: roll@ietf.org >>> Subject: Re: [Roll] [manet] Discussion on draft >>> >>> Teco - I'm not sure how you define mesh, so forgive me if I'm missing >>> the point. >>> It's true that most of the mesh work in sensor networks to date has >>> >> been >> >>> to a single data sink. But there are also lots of examples in the >>> literature in which local networking doesn't involve a gateway or >>> backbone. This local networking is sometimes used for "distributed >>> signal processing" (a very loaded phrase), and local feedback control >>> loops. It's the feedback control that I think is starting to see real >>> commercial traction. >>> For industrial markets, I'm surprised that people are already starting >>> to talk about local meshes for feedback control loops. I thought that >>> it would take longer for them to get comfortable with the technology, >>> but some at least are ready now. In many cases, this *requires* a >>> >> local >> >>> mesh, since the latency requirements effectively prohibit going through >>> a backbone - if the sensor and actuator are close, there are probably >>> fewer hops to get between them than to get to the backbone. >>> >>> ksjp >>> >>> Teco Boot wrote: >>> >>>> Hi Phil, >>>> Maybe this raised before, but I miss a category of "xxx" protocols, >>>> sometimes referred as "mesh" protocols. >>>> "Mesh" is not pure MANET, as MANET routing protocols typically >>>> >> provide paths >> >>>> within the MANET. "Mesh" protocols provide paths between nodes and a >>>> backbone network. >>>> MANET protocols can provide paths to the backbone also. The other way >>>> >> is not >> >>>> always true, "mesh" protocols do typically not provide paths between >>>> >> nodes >> >>>> or at least this is the second priority. >>>> Maybe the draft only discuss existing IETF protocols (e.g. RFC exists >>>> >> or WG >> >>>> is chartered), but I think the "mesh" type of protocols is worth >>>> >> mentioning. >> >>>> Regards, Teco >>>> >>>> >>>> >>>>> -----Oorspronkelijk bericht----- >>>>> Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens >>>>> Philip Levis >>>>> Verzonden: vrijdag 28 maart 2008 4:43 >>>>> Aan: roll@ietf.org; manet manet >>>>> Onderwerp: [manet] Discussion on draft >>>>> >>>>> I'd like to start a discussion on >>>>> >> draft-levis-roll-overview-protocols. >> >>>>> In particular, Section 5.8 has a table of several existing protocols >>>>> and their properties. This table is really going to be critical in >>>>> ROLL's assessment of existing technologies and protocols, so we want >>>>> to make sure that >>>>> >>>>> 1) It has the relevant data points to compare (protocols/rows) >>>>> 2) It distills what the important properties are(columns) >>>>> 3) It accurately captures the properties of the values in question >>>>> (cells are accurate) >>>>> >>>>> Let's start with 1), as it's probably the simplest. Are there any >>>>> protocols that we should be including that aren't there? Trying to >>>>> cover every single minor protocol tweak is a recipe for disaster, >>>>> >> but >> >>>>> protocols that differ significantly from those currently there, >>>>> >> either >> >>>>> in mechanism or in properties, are important to include. >>>>> >>>>> Phil >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>> >>>>> >>>> _______________________________________________ >>>> 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 roll-bounces@ietf.org Mon Mar 31 11:59:57 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0091A28C1AE; Mon, 31 Mar 2008 11:59:57 -0700 (PDT) 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 8F3FE28C3B1 for ; Mon, 31 Mar 2008 11:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxr2Uju0xQY3 for ; Mon, 31 Mar 2008 11:59:53 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by core3.amsl.com (Postfix) with ESMTP id 99F7F28C1AE for ; Mon, 31 Mar 2008 11:59:53 -0700 (PDT) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.2/8.13.5) with ESMTP id m2VIxljj028680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 31 Mar 2008 11:59:48 -0700 (PDT) Message-ID: <47F1349E.4090801@eecs.berkeley.edu> Date: Mon, 31 Mar 2008 11:59:42 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC0575A171@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0575A171@xmb-ams-337.emea.cisco.com> Cc: roll@ietf.org Subject: Re: [Roll] [manet] Discussion on 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: , Content-Type: multipart/mixed; boundary="===============2071044634==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============2071044634== Content-Type: multipart/alternative; boundary="------------080504060803000802000002" This is a multi-part message in MIME format. --------------080504060803000802000002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit ok, I think that we're back in sync. My version of your recap: The early deployments in industrial are all around getting data back to one or more sinks. Increasingly over time, these sinks will be a part of a backbone (today they're often fragmented/isolated). This function is likely to always be an important function of the network. On-demand internal routes will become more prevalent over time. Some of the on-demand routes will last for years/decades. Internal routes will often be the most critical, optimized and well-maintained (I think that this was where I lost sync: with your statement that they might be less optimized and less well maintained). So I agree that a good strategy is to be pro-active in routing to sinks, and responding to internal on-demand requests with optimized internal mesh routes. ksjp Pascal Thubert (pthubert) wrote: > Hi Kris: > > I think we lost sync here. We were discussing Phil's draft and comparing > routing strategies inside the Low-power Lossy Network. I did not attend > to discuss whether there is a backbone and what that backbone is made > of, WIFI mesh or else. The disconnect might have come from the word > mesh, and yes I know what you are talking about but please let's not get > there now. > > So let me please recap: > > First, on-demand means that you establish a path because you find that > you need it. On-demand is very practical when you have constraints to > place like class 0 because you can qualify the route that you want to > build and build specifically what you want. On-demand was designed with > host routes in mind and for that reason it plays well at layer 2 (Token > Ring test frame, 802.11s AODV etc...) though it has already one major > application at layer 3 for voice, since RSVP is also an on-demand > protocol. > > In this thread, I was saying that the "any to any" optimized routing > strategy that we find in proactive routing (OSPF, OLSR, etc...) spends a > lot of energy computing LLN internal routes that we will never need and > we seem to agree on that part. On the other end of the spectrum, full > on-demand strategies (DYMO, DSR, AODV...) are reactive even for routes > that we need in all configurations. > > So I was advocating the mesh strategy that is proactive for the routes > to the sink and on-demand for the LLN internal routes. It is a specific > 'mixed' strategy that recognizes the flows that we really have in > sensors as opposed to the generic problem that other manet 'mixed' > strategies can address. > > And I was pointing the cool side that if a need pops up (like this guy > with his handheld) an unoptimized route exists to start with even if > that means going to the sink and back. A better route can be established > if the flows are characterized to require it; this is what I called > optimizing the route. > > I hope my point is clearer now, > > Pascal > >> -----Original Message----- >> From: Kris Pister [mailto:pister@eecs.berkeley.edu] >> Sent: lundi 31 mars 2008 01:15 >> To: Pascal Thubert (pthubert) >> Cc: Teco Boot; roll@ietf.org >> Subject: Re: [Roll] [manet] Discussion on draft >> >> Pascal Thubert (pthubert) wrote: >> >>> Hi Kris: >>> >>> I think that Teco means that finding a path inside the mesh might be >>> > a > >>> second priority vs. finding the way to the sink. By Priority I mean >>> > that > >>> intra mesh routing might: >>> >>> - require less optimized and well maintained path then the routing to >>> the sinks >>> >>> >> I'm not sure that I follow. I think that most of the mote-to-mote >> traffic (at least in industrial) is likely to be either >> > control-related, > >> or human query/response, both of which are generally going to be more >> demanding of network resources than regular data reporting. >> >>> - have an on-demand flavor to maintain only certain routes as opposed >>> > to > >>> any to any >>> >>> >> I certainly agree that any-to-any is not a common requirement. Human >> interaction is likely to be fairly short-term and on-demand, but >> > control > >> loops will be long term (not on-demand? not sure of the definition). >> >>> - be used only for certain applications such as closed loop as >>> > opposed > >>> to bulk data >>> - be scoped to limit the number of radio hops and default to route >>> around >>> >>> >> I think that you have a mental picture of the network that might be >> different from mine. Picture a multi-square-kilometer refinery, most >> > of > >> which is a tank farm. A few hundred motes will give you a nice >> > reliable > >> mesh in that environment, but it might be 5-10 hops across. Local >> feedback loops and mobile workers will tend to be only one or two hops. >> The backbone will be in the refinery proper, many hops away. Even >> there, powered infrastructure will typically be several hops away. So >> hopping to/from the powered infrastructure will in general be more >> costly than the direct route. >> >>> The mesh strategy is to default to the backbone and then do some >>> > route > >>> optimization. [...] >>> >>> >> I completely disagree. That's the ISA vision of a mesh, where in >> Company X's ideal future they have managed to convince everyone to put >> > a > >> WiFi AP every 50 meters over many square kilometers. I just don't see >> it going that way in industrial. It's a more plausible picture in >> building automation or home automation though. >> >>> Pascal >>> >>> >> ksjp >> >>>> -----Original Message----- >>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >>>> > Of > >>> Kris Pister >>> >>> >>>> Sent: vendredi 28 mars 2008 17:10 >>>> To: Teco Boot >>>> Cc: roll@ietf.org >>>> Subject: Re: [Roll] [manet] Discussion on draft >>>> >>>> Teco - I'm not sure how you define mesh, so forgive me if I'm >>>> > missing > >>>> the point. >>>> It's true that most of the mesh work in sensor networks to date has >>>> >>>> >>> been >>> >>> >>>> to a single data sink. But there are also lots of examples in the >>>> literature in which local networking doesn't involve a gateway or >>>> backbone. This local networking is sometimes used for "distributed >>>> signal processing" (a very loaded phrase), and local feedback >>>> > control > >>>> loops. It's the feedback control that I think is starting to see >>>> > real > >>>> commercial traction. >>>> For industrial markets, I'm surprised that people are already >>>> > starting > >>>> to talk about local meshes for feedback control loops. I thought >>>> > that > >>>> it would take longer for them to get comfortable with the >>>> > technology, > >>>> but some at least are ready now. In many cases, this *requires* a >>>> >>>> >>> local >>> >>> >>>> mesh, since the latency requirements effectively prohibit going >>>> > through > >>>> a backbone - if the sensor and actuator are close, there are >>>> > probably > >>>> fewer hops to get between them than to get to the backbone. >>>> >>>> ksjp >>>> >>>> Teco Boot wrote: >>>> >>>> >>>>> Hi Phil, >>>>> Maybe this raised before, but I miss a category of "xxx" protocols, >>>>> sometimes referred as "mesh" protocols. >>>>> "Mesh" is not pure MANET, as MANET routing protocols typically >>>>> >>>>> >>> provide paths >>> >>> >>>>> within the MANET. "Mesh" protocols provide paths between nodes and >>>>> > a > >>>>> backbone network. >>>>> MANET protocols can provide paths to the backbone also. The other >>>>> > way > >>> is not >>> >>> >>>>> always true, "mesh" protocols do typically not provide paths >>>>> > between > >>> nodes >>> >>> >>>>> or at least this is the second priority. >>>>> Maybe the draft only discuss existing IETF protocols (e.g. RFC >>>>> > exists > >>> or WG >>> >>> >>>>> is chartered), but I think the "mesh" type of protocols is worth >>>>> >>>>> >>> mentioning. >>> >>> >>>>> Regards, Teco >>>>> >>>>> >>>>> >>>>> >>>>>> -----Oorspronkelijk bericht----- >>>>>> Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens >>>>>> Philip Levis >>>>>> Verzonden: vrijdag 28 maart 2008 4:43 >>>>>> Aan: roll@ietf.org; manet manet >>>>>> Onderwerp: [manet] Discussion on draft >>>>>> >>>>>> I'd like to start a discussion on >>>>>> >>>>>> >>> draft-levis-roll-overview-protocols. >>> >>> >>>>>> In particular, Section 5.8 has a table of several existing >>>>>> > protocols > >>>>>> and their properties. This table is really going to be critical in >>>>>> ROLL's assessment of existing technologies and protocols, so we >>>>>> > want > >>>>>> to make sure that >>>>>> >>>>>> 1) It has the relevant data points to compare (protocols/rows) >>>>>> 2) It distills what the important properties are(columns) >>>>>> 3) It accurately captures the properties of the values in question >>>>>> (cells are accurate) >>>>>> >>>>>> Let's start with 1), as it's probably the simplest. Are there any >>>>>> protocols that we should be including that aren't there? Trying to >>>>>> cover every single minor protocol tweak is a recipe for disaster, >>>>>> >>>>>> >>> but >>> >>> >>>>>> protocols that differ significantly from those currently there, >>>>>> >>>>>> >>> either >>> >>> >>>>>> in mechanism or in properties, are important to include. >>>>>> >>>>>> Phil >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> --------------080504060803000802000002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit ok, I think that we're back in sync.  My version of your recap:
The early deployments in industrial are all around getting data back to one or more sinks.  Increasingly over time, these sinks will be a part of a backbone (today they're often fragmented/isolated).  This function is likely to always be an important function of the network.
On-demand internal routes will become more prevalent over time.  Some of the on-demand routes will last for years/decades.  Internal routes will often be the most critical, optimized and well-maintained (I think that this was where I lost sync: with your statement that they might be less optimized and less well maintained).

So I agree that a good strategy is to be pro-active in routing to sinks, and responding to internal on-demand requests with optimized internal mesh routes.

ksjp

Pascal Thubert (pthubert) wrote: 
Hi Kris:

I think we lost sync here. We were discussing Phil's draft and comparing
routing strategies inside the Low-power Lossy Network. I did not attend
to discuss whether there is a backbone and what that backbone is made
of, WIFI mesh or else. The disconnect might have come from the word
mesh, and yes I know what you are talking about but please let's not get
there now.

So let me please recap:

First, on-demand means that you establish a path because you find that
you need it. On-demand is very practical when you have constraints to
place like class 0 because you can qualify the route that you want to
build and build specifically what you want. On-demand was designed with
host routes in mind and for that reason it plays well at layer 2 (Token
Ring test frame, 802.11s AODV etc...) though it has already one major
application at layer 3 for voice, since RSVP is also an on-demand
protocol.

In this thread, I was saying that the "any to any" optimized routing
strategy that we find in proactive routing (OSPF, OLSR, etc...) spends a
lot of energy computing LLN internal routes that we will never need and
we seem to agree on that part. On the other end of the spectrum, full
on-demand strategies (DYMO, DSR, AODV...) are reactive even for routes
that we need in all configurations.

So I was advocating the mesh strategy that is proactive for the routes
to the sink and on-demand for the LLN internal routes. It is a specific
'mixed' strategy that recognizes the flows that we really have in
sensors as opposed to the generic problem that other manet 'mixed'
strategies can address.

And I was pointing the cool side that if a need pops up (like this guy
with his handheld) an unoptimized route exists to start with even if
that means going to the sink and back. A better route can be established
if the flows are characterized to require it; this is what I called
optimizing the route.

I hope my point is clearer now,

Pascal
  
-----Original Message-----
From: Kris Pister [mailto:pister@eecs.berkeley.edu]
Sent: lundi 31 mars 2008 01:15
To: Pascal Thubert (pthubert)
Cc: Teco Boot; roll@ietf.org
Subject: Re: [Roll] [manet] Discussion on draft

Pascal Thubert (pthubert) wrote:
    
Hi Kris:

I think that Teco means that finding a path inside the mesh might be
      
a
  
second priority vs. finding the way to the sink. By Priority I mean
      
that
  
intra mesh routing might:

- require less optimized and well maintained path then the routing to
the sinks

      
I'm not sure that I follow.  I think that most of the mote-to-mote
traffic (at least in industrial) is likely to be either
    
control-related,
  
or human query/response, both of which are generally going to be more
demanding of network resources than regular data reporting.
    
- have an on-demand flavor to maintain only certain routes as opposed
      
to
  
any to any

      
I certainly agree that any-to-any is not a common requirement.  Human
interaction is likely to be fairly short-term and on-demand, but
    
control
  
loops will be long term (not on-demand? not sure of the definition).
    
- be used only for certain applications such as closed loop as
      
opposed
  
to bulk data
- be scoped to limit the number of radio hops and default to route
around

      
I think that you have a mental picture of the network that might be
different from mine.  Picture a multi-square-kilometer refinery, most
    
of
  
which is a tank farm.  A few hundred motes will give you a nice
    
reliable
  
mesh in that environment, but it might be 5-10 hops across.  Local
feedback loops and mobile workers will tend to be only one or two hops.
The backbone will be in the refinery proper, many hops away.  Even
there, powered infrastructure will typically be several hops away.  So
hopping to/from the powered infrastructure will in general be more
costly than the direct route.
    
The mesh strategy is to default to the backbone and then do some
      
route
  
optimization. [...]

      
I completely disagree.  That's the ISA vision of a mesh, where in
Company X's ideal future they have managed to convince everyone to put
    
a
  
WiFi AP every 50 meters over many square kilometers.  I just don't see
it going that way in industrial.  It's a more plausible picture in
building automation or home automation though.
    
Pascal

      
ksjp
    
-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
        
Of
  
Kris Pister

      
Sent: vendredi 28 mars 2008 17:10
To: Teco Boot
Cc: roll@ietf.org
Subject: Re: [Roll] [manet] Discussion on draft

Teco - I'm not sure how you define mesh, so forgive me if I'm
        
missing
  
the point.
It's true that most of the mesh work in sensor networks to date has

        
been

      
to a single data sink.  But there are also lots of examples in the
literature in which local networking doesn't involve a gateway or
backbone.  This local networking is sometimes used for "distributed
signal processing" (a very loaded phrase), and local feedback
        
control
  
loops.  It's the feedback control that I think is starting to see
        
real
  
commercial traction.
For industrial markets, I'm surprised that people are already
        
starting
  
to talk about local meshes for feedback control loops.  I thought
        
that
  
it would take longer for them to get comfortable with the
        
technology,
  
but some at least are ready now.  In many cases, this *requires* a

        
local

      
mesh, since the latency requirements effectively prohibit going
        
through
  
a backbone - if the sensor and actuator are close, there are
        
probably
  
fewer hops to get between them than to get to the backbone.

ksjp

Teco Boot wrote:

        
Hi Phil,
Maybe this raised before, but I miss a category of "xxx" protocols,
sometimes referred as "mesh" protocols.
"Mesh" is not pure MANET, as MANET routing protocols typically

          
provide paths

      
within the MANET. "Mesh" protocols provide paths between nodes and
          
a
  
backbone network.
MANET protocols can provide paths to the backbone also. The other
          
way
  
is not

      
always true, "mesh" protocols do typically not provide paths
          
between
  
nodes

      
or at least this is the second priority.
Maybe the draft only discuss existing IETF protocols (e.g. RFC
          
exists
  
or WG

      
is chartered), but I think the "mesh" type of protocols is worth

          
mentioning.

      
Regards, Teco



          
-----Oorspronkelijk bericht-----
Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens
Philip Levis
Verzonden: vrijdag 28 maart 2008 4:43
Aan: roll@ietf.org; manet manet
Onderwerp: [manet] Discussion on draft

I'd like to start a discussion on

            
draft-levis-roll-overview-protocols.

      
In particular, Section 5.8 has a table of several existing
            
protocols
  
and their properties. This table is really going to be critical in
ROLL's assessment of existing technologies and protocols, so we
            
want
  
to make sure that

1) It has the relevant data points to compare (protocols/rows)
2) It distills what the important properties are(columns)
3) It accurately captures the properties of the values in question
(cells are accurate)

Let's start with 1), as it's probably the simplest. Are there any
protocols that we should be including that aren't there? Trying to
cover every single minor protocol tweak is a recipe for disaster,

            
but

      
protocols that differ significantly from those currently there,

            
either

      
in mechanism or in properties, are important to include.

Phil
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


            
_______________________________________________
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
--------------080504060803000802000002-- --===============2071044634== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============2071044634==-- From roll-bounces@ietf.org Mon Mar 31 12:30:00 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A4B528C3B1; Mon, 31 Mar 2008 12:30:00 -0700 (PDT) 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 458B928C433 for ; Mon, 31 Mar 2008 12:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[AWL=1.830, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEyZvi4qvFbm for ; Mon, 31 Mar 2008 12:06:17 -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 C5BB028C4A2 for ; Mon, 31 Mar 2008 12:05:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,583,1199692800"; d="scan'208,217";a="19283431" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 31 Mar 2008 12:05:01 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m2VJ50bh017819; Mon, 31 Mar 2008 12:05:00 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m2VJ4xBO024470; Mon, 31 Mar 2008 19:05:00 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Mar 2008 15:04:59 -0400 Received: from 10.86.104.186 ([10.86.104.186]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 31 Mar 2008 19:04:59 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 31 Mar 2008 15:04:56 -0400 From: JP Vasseur To: Kris Pister , "Pascal Thubert (pthubert)" Message-ID: Thread-Topic: [Roll] [manet] Discussion on draft Thread-Index: AciTYhulWjt6dv9VEdyyPgANk8WjQA== In-Reply-To: <47F1349E.4090801@eecs.berkeley.edu> Mime-version: 1.0 X-OriginalArrivalTime: 31 Mar 2008 19:04:59.0798 (UTC) FILETIME=[1DE98360:01C89362] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=49526; t=1206990301; x=1207854301; c=relaxed/simple; s=sjdkim4002; 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[manet]=20Discussion=20on=20dr aft |Sender:=20; bh=6AUNe7WKA/qnLXoxKt6TQKQLJj/ehHCXhlRwIF75x+c=; b=ij5v6wTB8LV93DBPknpvIosR1RxhFXLuMfsLzF8Lo7bdmMCLTOJcGG3siG L8XOLglXhFwsJzj+AULdhPX38g/fXladF7wvJGkoJUdpMNGgvs2t1olmDiSE tzqeZidvBu; Authentication-Results: sj-dkim-4; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Mailman-Approved-At: Mon, 31 Mar 2008 12:29:58 -0700 Cc: roll@ietf.org Subject: Re: [Roll] [manet] Discussion on 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: , Content-Type: multipart/mixed; boundary="===============0975830236==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0975830236== Content-type: multipart/alternative; boundary="B_3289820697_551721" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3289820697_551721 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi, Few comments here: From: Kris Pister Date: Mon, 31 Mar 2008 11:59:42 -0700 To: "Pascal Thubert (pthubert)" Cc: Subject: Re: [Roll] [manet] Discussion on draft ok, I think that we're back in sync. My version of your recap: The early deployments in industrial are all around getting data back to one or more sinks. Increasingly over time, these sinks will be a part of a backbone (today they're often fragmented/isolated). This function is likely to always be an important function of the network. JP> Which means that you need both in the requirement document. On-demand internal routes will become more prevalent over time. Some of the on-demand routes will last for years/decades. Internal routes will often be the most critical, optimized and well-maintained (I think that this was where I lost sync: with your statement that they might be less optimized and less well maintained). JP> Just make sure to stay solution-agnostic in the requirement document. So I agree that a good strategy is to be pro-active in routing to sinks, and responding to internal on-demand requests with optimized internal mesh routes. ksjp Pascal Thubert (pthubert) wrote: > > Hi Kris: > > I think we lost sync here. We were discussing Phil's draft and comparing > routing strategies inside the Low-power Lossy Network. I did not attend > to discuss whether there is a backbone and what that backbone is made > of, WIFI mesh or else. The disconnect might have come from the word > mesh, and yes I know what you are talking about but please let's not get > there now. > > So let me please recap: > > First, on-demand means that you establish a path because you find that > you need it. On-demand is very practical when you have constraints to > place like class 0 because you can qualify the route that you want to > build and build specifically what you want. On-demand was designed with > host routes in mind and for that reason it plays well at layer 2 (Token > Ring test frame, 802.11s AODV etc...) though it has already one major > application at layer 3 for voice, since RSVP is also an on-demand > protocol. > > In this thread, I was saying that the "any to any" optimized routing > strategy that we find in proactive routing (OSPF, OLSR, etc...) spends a > lot of energy computing LLN internal routes that we will never need and > we seem to agree on that part. On the other end of the spectrum, full > on-demand strategies (DYMO, DSR, AODV...) are reactive even for routes > that we need in all configurations. > > So I was advocating the mesh strategy that is proactive for the routes > to the sink and on-demand for the LLN internal routes. It is a specific > 'mixed' strategy that recognizes the flows that we really have in > sensors as opposed to the generic problem that other manet 'mixed' > strategies can address. > > And I was pointing the cool side that if a need pops up (like this guy > with his handheld) an unoptimized route exists to start with even if > that means going to the sink and back. A better route can be established > if the flows are characterized to require it; this is what I called > optimizing the route. > > I hope my point is clearer now, > > Pascal > > >> >> -----Original Message----- >> From: Kris Pister [mailto:pister@eecs.berkeley.edu] >> Sent: lundi 31 mars 2008 01:15 >> To: Pascal Thubert (pthubert) >> Cc: Teco Boot; roll@ietf.org >> Subject: Re: [Roll] [manet] Discussion on draft >> >> Pascal Thubert (pthubert) wrote: >> >> >>> >>> Hi Kris: >>> >>> I think that Teco means that finding a path inside the mesh might be >>> >>> >> > > a > > >> >>> >>> second priority vs. finding the way to the sink. By Priority I mean >>> >>> >> > > that > > >> >>> >>> intra mesh routing might: >>> >>> - require less optimized and well maintained path then the routing to >>> the sinks >>> >>> >>> >> >> I'm not sure that I follow. I think that most of the mote-to-mote >> traffic (at least in industrial) is likely to be either >> >> > > control-related, > > >> >> or human query/response, both of which are generally going to be more >> demanding of network resources than regular data reporting. >> >> >>> >>> - have an on-demand flavor to maintain only certain routes as opposed >>> >>> >> > > to > > >> >>> >>> any to any >>> >>> >>> >> >> I certainly agree that any-to-any is not a common requirement. Human >> interaction is likely to be fairly short-term and on-demand, but >> >> > > control > > >> >> loops will be long term (not on-demand? not sure of the definition). >> >> >>> >>> - be used only for certain applications such as closed loop as >>> >>> >> > > opposed > > >> >>> >>> to bulk data >>> - be scoped to limit the number of radio hops and default to route >>> around >>> >>> >>> >> >> I think that you have a mental picture of the network that might be >> different from mine. Picture a multi-square-kilometer refinery, most >> >> > > of > > >> >> which is a tank farm. A few hundred motes will give you a nice >> >> > > reliable > > >> >> mesh in that environment, but it might be 5-10 hops across. Local >> feedback loops and mobile workers will tend to be only one or two hops. >> The backbone will be in the refinery proper, many hops away. Even >> there, powered infrastructure will typically be several hops away. So >> hopping to/from the powered infrastructure will in general be more >> costly than the direct route. >> >> >>> >>> The mesh strategy is to default to the backbone and then do some >>> >>> >> > > route > > >> >>> >>> optimization. [...] >>> >>> >>> >> >> I completely disagree. That's the ISA vision of a mesh, where in >> Company X's ideal future they have managed to convince everyone to put >> >> > > a > > >> >> WiFi AP every 50 meters over many square kilometers. I just don't see >> it going that way in industrial. It's a more plausible picture in >> building automation or home automation though. >> >> >>> >>> Pascal >>> >>> >>> >> >> ksjp >> >> >>> >>>> >>>> -----Original Message----- >>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >>>> >>>> >>> >> > > Of > > >> >>> >>> Kris Pister >>> >>> >>> >>>> >>>> Sent: vendredi 28 mars 2008 17:10 >>>> To: Teco Boot >>>> Cc: roll@ietf.org >>>> Subject: Re: [Roll] [manet] Discussion on draft >>>> >>>> Teco - I'm not sure how you define mesh, so forgive me if I'm >>>> >>>> >>> >> > > missing > > >> >>> >>>> >>>> the point. >>>> It's true that most of the mesh work in sensor networks to date has >>>> >>>> >>>> >>> >>> been >>> >>> >>> >>>> >>>> to a single data sink. But there are also lots of examples in the >>>> literature in which local networking doesn't involve a gateway or >>>> backbone. This local networking is sometimes used for "distributed >>>> signal processing" (a very loaded phrase), and local feedback >>>> >>>> >>> >> > > control > > >> >>> >>>> >>>> loops. It's the feedback control that I think is starting to see >>>> >>>> >>> >> > > real > > >> >>> >>>> >>>> commercial traction. >>>> For industrial markets, I'm surprised that people are already >>>> >>>> >>> >> > > starting > > >> >>> >>>> >>>> to talk about local meshes for feedback control loops. I thought >>>> >>>> >>> >> > > that > > >> >>> >>>> >>>> it would take longer for them to get comfortable with the >>>> >>>> >>> >> > > technology, > > >> >>> >>>> >>>> but some at least are ready now. In many cases, this *requires* a >>>> >>>> >>>> >>> >>> local >>> >>> >>> >>>> >>>> mesh, since the latency requirements effectively prohibit going >>>> >>>> >>> >> > > through > > >> >>> >>>> >>>> a backbone - if the sensor and actuator are close, there are >>>> >>>> >>> >> > > probably > > >> >>> >>>> >>>> fewer hops to get between them than to get to the backbone. >>>> >>>> ksjp >>>> >>>> Teco Boot wrote: >>>> >>>> >>>> >>>>> >>>>> Hi Phil, >>>>> Maybe this raised before, but I miss a category of "xxx" protocols, >>>>> sometimes referred as "mesh" protocols. >>>>> "Mesh" is not pure MANET, as MANET routing protocols typically >>>>> >>>>> >>>>> >>>> >>> >>> provide paths >>> >>> >>> >>>> >>>>> >>>>> within the MANET. "Mesh" protocols provide paths between nodes and >>>>> >>>>> >>>> >>> >> > > a > > >> >>> >>>> >>>>> >>>>> backbone network. >>>>> MANET protocols can provide paths to the backbone also. The other >>>>> >>>>> >>>> >>> >> > > way > > >> >>> >>> is not >>> >>> >>> >>>> >>>>> >>>>> always true, "mesh" protocols do typically not provide paths >>>>> >>>>> >>>> >>> >> > > between > > >> >>> >>> nodes >>> >>> >>> >>>> >>>>> >>>>> or at least this is the second priority. >>>>> Maybe the draft only discuss existing IETF protocols (e.g. RFC >>>>> >>>>> >>>> >>> >> > > exists > > >> >>> >>> or WG >>> >>> >>> >>>> >>>>> >>>>> is chartered), but I think the "mesh" type of protocols is worth >>>>> >>>>> >>>>> >>>> >>> >>> mentioning. >>> >>> >>> >>>> >>>>> >>>>> Regards, Teco >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> -----Oorspronkelijk bericht----- >>>>>> Van: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] Namens >>>>>> Philip Levis >>>>>> Verzonden: vrijdag 28 maart 2008 4:43 >>>>>> Aan: roll@ietf.org; manet manet >>>>>> Onderwerp: [manet] Discussion on draft >>>>>> >>>>>> I'd like to start a discussion on >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> draft-levis-roll-overview-protocols. >>> >>> >>> >>>> >>>>> >>>>>> >>>>>> In particular, Section 5.8 has a table of several existing >>>>>> >>>>>> >>>>> >>>> >>> >> > > protocols > > >> >>> >>>> >>>>> >>>>>> >>>>>> and their properties. This table is really going to be critical in >>>>>> ROLL's assessment of existing technologies and protocols, so we >>>>>> >>>>>> >>>>> >>>> >>> >> > > want > > >> >>> >>>> >>>>> >>>>>> >>>>>> to make sure that >>>>>> >>>>>> 1) It has the relevant data points to compare (protocols/rows) >>>>>> 2) It distills what the important properties are(columns) >>>>>> 3) It accurately captures the properties of the values in question >>>>>> (cells are accurate) >>>>>> >>>>>> Let's start with 1), as it's probably the simplest. Are there any >>>>>> protocols that we should be including that aren't there? Trying to >>>>>> cover every single minor protocol tweak is a recipe for disaster, >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> but >>> >>> >>> >>>> >>>>> >>>>>> >>>>>> protocols that differ significantly from those currently there, >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> either >>> >>> >>> >>>> >>>>> >>>>>> >>>>>> in mechanism or in properties, are important to include. >>>>>> >>>>>> Phil >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 --B_3289820697_551721 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [Roll] [manet] Discussion on draft Hi,
Few comments here:


From: Kris Pister <pister@e= ecs.berkeley.edu>
Date: Mon, 31 Mar 2008 11:59:42 -0700
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>=
Cc: <roll@ietf.org>
Subject: Re: [Roll] [manet] Discussion on draft

ok, I think that we're back in sync.  My version of your recap:
The early deployments in industrial are all around getting data back to one= or more sinks.  Increasingly over time, these sinks will be a part of = a backbone (today they're often fragmented/isolated).  This function is= likely to always be an important function of the network.

JP> Which means that you need both in the requirement document.

On-demand internal routes will become more prevalent over time.  Some = of the on-demand routes will last for years/decades.  Internal routes w= ill often be the most critical, optimized and well-maintained (I think that = this was where I lost sync: with your statement that they might be less opti= mized and less well maintained).

JP> Just make sure to stay solution-agnostic in the requirement document= .

So I agree that a good strategy is to be pro-active in routing to sinks, an= d responding to internal on-demand requests with optimized internal mesh rou= tes.

ksjp

Pascal Thubert (pthubert) wrote:

Hi Kris:

I think we lost sync here. We were discussing Phil's draft and comparing routing strategies inside the Low-power Lossy Network. I did not attend
to discuss whether there is a backbone and what that backbone is made
of, WIFI mesh or else. The disconnect might have come from the word
mesh, and yes I know what you are talking about but please let's not get there now.

So let me please recap:

First, on-demand means that you establish a path because you find that
you need it. On-demand is very practical when you have constraints to
place like class 0 because you can qualify the route that you want to
build and build specifically what you want. On-demand was designed with
host routes in mind and for that reason it plays well at layer 2 (Token
Ring test frame, 802.11s AODV etc...) though it has already one major
application at layer 3 for voice, since RSVP is also an on-demand
protocol.

In this thread, I was saying that the "any to any" optimized rout= ing
strategy that we find in proactive routing (OSPF, OLSR, etc...) spends a lot of energy computing LLN internal routes that we will never need and
we seem to agree on that part. On the other end of the spectrum, full
on-demand strategies (DYMO, DSR, AODV...) are reactive even for routes
that we need in all configurations.

So I was advocating the mesh strategy that is proactive for the routes
to the sink and on-demand for the LLN internal routes. It is a specific
'mixed' strategy that recognizes the flows that we really have in
sensors as opposed to the generic problem that other manet 'mixed'
strategies can address.

And I was pointing the cool side that if a need pops up (like this guy
with his handheld) an unoptimized route exists to start with even if
that means going to the sink and back. A better route can be established if the flows are characterized to require it; this is what I called
optimizing the route.

I hope my point is clearer now,

Pascal
  
 

-----Original Message-----
From: Kris Pister [mailto:pister= @eecs.berkeley.edu]
Sent: lundi 31 mars 2008 01:15
To: Pascal Thubert (pthubert)
Cc: Teco Boot; roll@ietf.org
Subject: Re: [Roll] [manet] Discussion on draft

Pascal Thubert (pthubert) wrote:
    
 

Hi Kris:

I think that Teco means that finding a path inside the mesh might be
      
 


a
  
 


second priority vs. finding the way to the sink. By Priority I mean
      
 


that
  
 


intra mesh routing might:

- require less optimized and well maintained path then the routing to
the sinks

      
 

I'm not sure that I follow.  I think that most of the mote-to-mote
traffic (at least in industrial) is likely to be either
    
 

control-related,
  
 

or human query/response, both of which are generally going to be more
demanding of network resources than regular data reporting.
    
 

- have an on-demand flavor to maintain only certain routes as opposed
      
 


to
  
 


any to any

      
 

I certainly agree that any-to-any is not a common requirement.  Human<= BR> interaction is likely to be fairly short-term and on-demand, but
    
 

control
  
 

loops will be long term (not on-demand? not sure of the definition).
    
 

- be used only for certain applications such as closed loop as
      
 


opposed
  
 


to bulk data
- be scoped to limit the number of radio hops and default to route
around

      
 

I think that you have a mental picture of the network that might be
different from mine.  Picture a multi-square-kilometer refinery, most<= BR>     
 

of
  
 

which is a tank farm.  A few hundred motes will give you a nice
    
 

reliable
  
 

mesh in that environment, but it might be 5-10 hops across.  Local
feedback loops and mobile workers will tend to be only one or two hops.
The backbone will be in the refinery proper, many hops away.  Even
there, powered infrastructure will typically be several hops away.  So=
hopping to/from the powered infrastructure will in general be more
costly than the direct route.
    
 

The mesh strategy is to default to the backbone and then do some
      
 


route
  
 


optimization. [...]

      
 

I completely disagree.  That's the ISA vision of a mesh, where in
Company X's ideal future they have managed to convince everyone to put
    
 

a
  
 

WiFi AP every 50 meters over many square kilometers.  I just don't see=
it going that way in industrial.  It's a more plausible picture in
building automation or home automation though.
    
 

Pascal

      
 

ksjp
    
 


-----Original Message-----
From: roll-bounces@ietf.org [mailto= :roll-bounces@ietf.org] On Behalf
        
 



Of
  
 


Kris Pister

      
 

Sent: vendredi 28 mars 2008 17:10
To: Teco Boot
Cc: roll@ietf.org
Subject: Re: [Roll] [manet] Discussion on draft

Teco - I'm not sure how you define mesh, so forgive me if I'm
        
 



missing
  
 



the point.
It's true that most of the mesh work in sensor networks to date has

        
 

been

      
 

to a single data sink.  But there are also lots of examples in the
literature in which local networking doesn't involve a gateway or
backbone.  This local networking is sometimes used for "distribut= ed
signal processing" (a very loaded phrase), and local feedback
        
 



control
  
 



loops.  It's the feedback control that I think is starting to see
        
 



real
  
 



commercial traction.
For industrial markets, I'm surprised that people are already
        
 



starting
  
 



to talk about local meshes for feedback control loops.  I thought
        
 



that
  
 



it would take longer for them to get comfortable with the
        
 



technology,
  
 



but some at least are ready now.  In many cases, this *requires* a

        
 

local

      
 

mesh, since the latency requirements effectively prohibit going
        
 



through
  
 



a backbone - if the sensor and actuator are close, there are
        
 



probably
  
 



fewer hops to get between them than to get to the backbone.

ksjp

Teco Boot wrote:

        
 

Hi Phil,
Maybe this raised before, but I miss a category of "xxx" protocol= s,
sometimes referred as "mesh" protocols.
"Mesh" is not pure MANET, as MANET routing protocols typically
          
 


provide paths

      
 


within the MANET. "Mesh" protocols provide paths between nodes an= d
          
 




a
  
 




backbone network.
MANET protocols can provide paths to the backbone also. The other
          
 




way
  
 


is not

      
 


always true, "mesh" protocols do typically not provide paths
          
 




between
  
 


nodes

      
 


or at least this is the second priority.
Maybe the draft only discuss existing IETF protocols (e.g. RFC
          
 




exists
  
 


or WG

      
 


is chartered), but I think the "mesh" type of protocols is worth<= BR>
          
 


mentioning.

      
 


Regards, Teco



          
 

-----Oorspronkelijk bericht-----
Van: manet-bounces@ietf.org [mailt= o:manet-bounces@ietf.org] Namens
Philip Levis
Verzonden: vrijdag 28 maart 2008 4:43
Aan: roll@ietf.org; manet manet
Onderwerp: [manet] Discussion on draft

I'd like to start a discussion on

              



draft-levis-roll-overview-protocols.

      
 



In particular, Section 5.8 has a table of several existing
              





protocols
  
 





and their properties. This table is really going to be critical in
ROLL's assessment of existing technologies and protocols, so we
              





want
  
 





to make sure that

1) It has the relevant data points to compare (protocols/rows)
2) It distills what the important properties are(columns)
3) It accurately captures the properties of the values in question
(cells are accurate)

Let's start with 1), as it's probably the simplest. Are there any
protocols that we should be including that aren't there? Trying to
cover every single minor protocol tweak is a recipe for disaster,

              



but

      
 



protocols that differ significantly from those currently there,

              



either

      
 



in mechanism or in properties, are important to include.

Phil
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


              

_______________________________________________
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
 --B_3289820697_551721-- --===============0975830236== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0975830236==-- From roll-bounces@ietf.org Mon Mar 31 14:29:18 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D57DA3A69F6; Mon, 31 Mar 2008 14:29:18 -0700 (PDT) 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 6760E3A69F6 for ; Mon, 31 Mar 2008 14:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22ouBQXwOVni for ; Mon, 31 Mar 2008 14:29:17 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by core3.amsl.com (Postfix) with ESMTP id 6C5563A68EA for ; Mon, 31 Mar 2008 14:29:17 -0700 (PDT) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.2/8.13.5) with ESMTP id m2VLTDmZ002343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 31 Mar 2008 14:29:14 -0700 (PDT) Message-ID: <47F157A3.3080704@eecs.berkeley.edu> Date: Mon, 31 Mar 2008 14:29:07 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: JP Vasseur References: In-Reply-To: Cc: roll@ietf.org Subject: Re: [Roll] industrial requirements (was...) 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: , Content-Type: multipart/mixed; boundary="===============1526561448==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============1526561448== Content-Type: multipart/alternative; boundary="------------000405080603070000010206" This is a multi-part message in MIME format. --------------000405080603070000010206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit JP Vasseur wrote: > [...] > The early deployments in industrial are all around getting data back > to one or more sinks. Increasingly over time, these sinks will be a > part of a backbone (today they're often fragmented/isolated). This > function is likely to always be an important function of the network. > > JP> Which means that you need both in the requirement document. They're both in there. e.g. " Most low power and lossy network systems [in industrial] in the near future will be for low frequency data collection." "The routing protocol MUST support multiple paths (a tree-based solution is not sufficient)." "Thus, the routing protocol for L2Ns MUST support multi-topology routing (e.g especially critical for critical control applications)." > > On-demand internal routes will become more prevalent over time. Some > of the on-demand routes will last for years/decades. Internal routes > will often be the most critical, optimized and well-maintained (I > think that this was where I lost sync: with your statement that they > might be less optimized and less well maintained). > > JP> Just make sure to stay solution-agnostic in the requirement document. I think that we're largely solution-agnostic in -00, but a lot of people of appropriately complained about the repeated references to L2. I'm not trying to make this a HART-like document, or an ISA100-like document, so I'll yank all of the slotted-link and 15.4-specific stuff out of there. At the same time, I think that there are important underlying issues here that require some clever thinking at layer 3 to deal with what's going on in layer 2, and relate both to what layer 4 needs. Zach's email from 11/29 asked if routing metrics can serve as enough of an L2 abstraction, or if we need some kind of interactive relationship. I don't know the answer to that question, but I'd sure like to hear some good ideas. ksjp --------------000405080603070000010206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit JP Vasseur wrote:
Re: [Roll] [manet] Discussion on draft [...]
The early deployments in industrial are all around getting data back to one or more sinks.  Increasingly over time, these sinks will be a part of a backbone (today they're often fragmented/isolated).  This function is likely to always be an important function of the network.

JP> Which means that you need both in the requirement document.
They're both in there. e.g. " Most low power and lossy network systems [in industrial] in the near future will be for low frequency data collection."
"The routing protocol MUST support multiple paths (a tree-based solution is not sufficient)."
"Thus, the routing protocol for L2Ns MUST support multi-topology routing (e.g especially critical for critical control applications)."

On-demand internal routes will become more prevalent over time.  Some of the on-demand routes will last for years/decades.  Internal routes will often be the most critical, optimized and well-maintained (I think that this was where I lost sync: with your statement that they might be less optimized and less well maintained).

JP> Just make sure to stay solution-agnostic in the requirement document.
I think that we're largely solution-agnostic in -00, but a lot of people of appropriately complained about the repeated references to L2.  I'm not trying to make this a HART-like document, or an ISA100-like document, so I'll yank all of the slotted-link and 15.4-specific stuff out of there.  At the same time, I think that there are important underlying issues here that require some clever thinking at layer 3 to deal with what's going on in layer 2, and relate both to what layer 4 needs.
Zach's email from 11/29 asked if routing metrics can serve as enough of an L2 abstraction, or if we need some kind of interactive relationship.  I don't know the answer to that question, but I'd sure like to hear some good ideas.

ksjp

--------------000405080603070000010206-- --===============1526561448== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1526561448==-- From roll-bounces@ietf.org Mon Mar 31 15:24:04 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBB4C3A68C5; Mon, 31 Mar 2008 15:24:04 -0700 (PDT) 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 753583A69B9 for ; Mon, 31 Mar 2008 15:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.429 X-Spam-Level: X-Spam-Status: No, score=-3.429 tagged_above=-999 required=5 tests=[AWL=1.773, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pk-rQDSfO2du for ; Mon, 31 Mar 2008 15:23:57 -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 5C8B83A67D5 for ; Mon, 31 Mar 2008 15:23:57 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 31 Mar 2008 15:23:55 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m2VMNtaF022789; Mon, 31 Mar 2008 15:23:55 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m2VMNr9V015835; Mon, 31 Mar 2008 22:23:55 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Mar 2008 18:23:54 -0400 Received: from 10.86.104.186 ([10.86.104.186]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 31 Mar 2008 22:23:53 +0000 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 31 Mar 2008 18:23:51 -0400 From: JP Vasseur To: Kris Pister Message-ID: Thread-Topic: [Roll] industrial requirements (was...) Thread-Index: AciTfeV2I+jznP9xEdyyPgANk8WjQA== In-Reply-To: <47F157A3.3080704@eecs.berkeley.edu> Mime-version: 1.0 X-OriginalArrivalTime: 31 Mar 2008 22:23:54.0265 (UTC) FILETIME=[E768A890:01C8937D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7842; t=1207002235; x=1207866235; c=relaxed/simple; s=sjdkim4002; 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]=20industrial=20requirements=20(w as...) |Sender:=20; bh=SI3OFg6FmygNoTWNFCzqO9M7g+izuxfjooD84PnuwQg=; b=ChXKQFd/oC+dAqxLk4w7lwEovVWFiJLoeIQOEWYf1nyhnQJScTB96x+T2n /Y8mikbUKJ5kWHqxiV2Yb+RX6gpDmryPBbAMtDI9bFEkpv8cynx1qoEyx2kz jhqj441pRy; Authentication-Results: sj-dkim-4; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] industrial requirements (was...) 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: , Content-Type: multipart/mixed; boundary="===============1043601453==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1043601453== Content-type: multipart/alternative; boundary="B_3289832632_1311911" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3289832632_1311911 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Kris, See JP2> From: Kris Pister Date: Mon, 31 Mar 2008 14:29:07 -0700 To: JP Vasseur Cc: Subject: Re: [Roll] industrial requirements (was...) JP Vasseur wrote:=20 > Re: [Roll] [manet] Discussion on draft [...] > The early deployments in industrial are all around getting data back to o= ne or > more sinks. Increasingly over time, these sinks will be a part of a back= bone > (today they're often fragmented/isolated). This function is likely to al= ways > be an important function of the network. > =20 > JP> Which means that you need both in the requirement document. > =20 They're both in there. e.g. " Most low power and lossy network systems [in industrial] in the near future will be for low frequency data collection." "The routing protocol MUST support multiple paths (a tree-based solution is not sufficient)." "Thus, the routing protocol for L2Ns MUST support multi-topology routing (e.g especially critical for critical control applications)." >=20 > JP2> Multi-topology routing is different though: it refers to the ability= to > support multiple topologies (e.g., one for low latency, one for high > bandwidth): is this what you want ? >=20 > On-demand internal routes will become more prevalent over time. Some of = the > on-demand routes will last for years/decades. Internal routes will often= be > the most critical, optimized and well-maintained (I think that this was w= here > I lost sync: with your statement that they might be less optimized and le= ss > well maintained). > =20 > JP> Just make sure to stay solution-agnostic in the requirement document. > =20 I think that we're largely solution-agnostic in -00, but a lot of people of appropriately complained about the repeated references to L2. I'm not trying to make this a HART-like document, or an ISA100-like document, so I'll yank all of the slotted-link and 15.4-specific stuff out of there. At the same time, I think that there are important underlying issues here that require some clever thinking at layer 3 to deal with what's going on in layer 2,=20 JP2> The following WG item should help you there: Nov 2008 Submit Routing metrics for LLNs document to the IESG to b= e considered as a Proposed Standard. Link routing metric could be derived from the layer-2 characteristics. and relate both to what layer 4 needs. Zach's email from 11/29 asked if routing metrics can serve as enough of an L2 abstraction, or if we need some kind of interactive relationship. I don't know the answer to that question, but I'd sure like to hear some good ideas. JP2> For sure, we=B9ll need to have some discussions on this in the document referenced above. I tend to suggest to first progress on the requirements documents though. Thanks, Cheers. JP. ksjp _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --B_3289832632_1311911 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Roll] industrial requirements (was...) Hi Kr= is,

See JP2>


From: Kris Pister <pister@e= ecs.berkeley.edu>
Date: Mon, 31 Mar 2008 14:29:07 -0700
To: JP Vasseur <jvasseur@cisco.com>
Cc: <roll@ietf.org>
Subject: Re: [Roll] industrial requirements (was...)

JP Vasseur wrote:
Re: [Roll] [manet] Discussion on draft [...]
The early deployments in industrial are all around getting data back to one= or more sinks.  Increasingly over time, these sinks will be a part of = a backbone (today they're often fragmented/isolated).  This function is= likely to always be an important function of the network.
 
JP> Which means that you need both in the requirement document.
 
They're both in there. e.g. " Most low power and = lossy network systems [in industrial] in the near future will be for low fre= quency data collection."
"The routing protocol MUST support multiple paths (a tree-based soluti= on is not sufficient)."
"Thus, the routing protocol for L2Ns MUST support multi-topology routi= ng (e.g especially critical for critical control applications)."

JP2> Multi-topology routing is different though: it refers to the abilit= y to support multiple topologies (e.g., one for low latency, one for high ba= ndwidth): is this what you want ?

On-demand internal routes will become more prevalent over time.  Some = of the on-demand routes will last for years/decades.  Internal routes w= ill often be the most critical, optimized and well-maintained (I think that = this was where I lost sync: with your statement that they might be less opti= mized and less well maintained).
 
JP> Just make sure to stay solution-agnostic in the requirement document= .
 
I think that we're largely solution-agnostic in -00, b= ut a lot of people of appropriately complained about the repeated references= to L2.  I'm not trying to make this a HART-like document, or an ISA100= -like document, so I'll yank all of the slotted-link and 15.4-specific stuff= out of there.  At the same time, I think that there are important unde= rlying issues here that require some clever thinking at layer 3 to deal with= what's going on in layer 2,

JP2> The following WG item should help you there:
Nov 2008        &nbs= p; Submit Routing metrics for LLNs document to the IESG to be considere= d as a Proposed Standard.
Link routing metric could be derived from the layer-2 characteristics.

and relate both to what layer 4 needs.
Zach's email from 11/29 asked if routing metrics can serve as enough of an = L2 abstraction, or if we need some kind of interactive relationship.  I= don't know the answer to that question, but I'd sure like to hear some good= ideas.

JP2> For sure, we’ll need to have some discussions on this in the = document referenced above. I tend to suggest to first progress on the requir= ements documents though.

Thanks,

Cheers.

JP.

ksjp


____________________= ___________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
 --B_3289832632_1311911-- --===============1043601453== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1043601453==-- From roll-bounces@ietf.org Mon Mar 31 23:00:59 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D0053A6920; Mon, 31 Mar 2008 23:00:59 -0700 (PDT) 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 5BAB63A685A for ; Mon, 31 Mar 2008 23:00:55 -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 fjJKD5zy3iIQ for ; Mon, 31 Mar 2008 23:00:54 -0700 (PDT) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.230]) by core3.amsl.com (Postfix) with ESMTP id E4A3D3A6DE6 for ; Mon, 31 Mar 2008 23:00:33 -0700 (PDT) Received: by qb-out-0506.google.com with SMTP id o21so367013qba.9 for ; Mon, 31 Mar 2008 23:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; bh=vTMDMA7xDHoTxjpxhHvcIk+US4fs6dX8TCTa2A/AEwk=; b=KB9v+C3xezZEjESsmBPVW1RgwXj1H54MQ7BSXYQcev9pL6bSdKV9kRWvVb3M10W9iSOd/PGG5YUBiP6pYS7NWdtMhJspMVX85ibbh+TOjyuNrLwpFwTW4gcLJo2Dr4GX2Mb8ztizst0ssXRmUFAZ+dI43H7uDLQwghxemqTDoR0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=ow0yLdeo279lkf8UDIAsnuDx2fRwmFtnJDRgZ7nxvGxLZWcExGKEaBrMt6TRMoEpfioPbvq/GEUeExsCMBHqWWaufP30dH8DyOYQ81MCAABNXdCDws93S0zHS3ESuI/8M686yw/T1xN+mut4VVlQgJ5JLg0V7FJTFhVJTBhCKIw= Received: by 10.141.172.6 with SMTP id z6mr4032758rvo.80.1207029631328; Mon, 31 Mar 2008 23:00:31 -0700 (PDT) Received: from ?70.165.128.173? ( [70.165.128.2]) by mx.google.com with ESMTPS id b24sm3915361rvf.1.2008.03.31.23.00.29 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 31 Mar 2008 23:00:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <8C1DD7A0-7C74-4F30-A990-0550EB681793@gmail.com> From: Ian Chakeres Date: Tue, 1 Apr 2008 11:30:26 +0530 To: roll@ietf.org X-Mailer: Apple Mail (2.753) Subject: [Roll] review/comments on overview-protocols 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Here are some comments I have from reviewing the overview-protocols document. I think you should consider including proactive/reactive in the routing protocol taxonomy. You may also want to discuss distribution of a default route. On page 6 you bring up neighbor discovery. I would recommend you change the terminology to avoid the term "neighbor discovery (ND)". ND has very specific connotations within the IETF. I might recommend adjacent/neighboring router discovery. You might also want to mention asymmetric reachability (see ND RFC), since this behavior will be common in ROLL networks. RIPng and DYMO use distance as a metric. AODV use several things (in addition to hop count) when making routing decisions. My paper discusses it === Ian D. Chakeres and Elizabeth M. Belding-Royer. "Transparent Influence of Path Selection in Heterogeneous Ad hoc Networks." Proceedings of the 15th IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC), Barcelona, Spain, September 2004. === Several of these observations/features are also available for DYMO. Using the methods above (delay, distance, etc.) both AODV and DYMO can incorporate node metrics (e.g. remaining energy) during route discovery. This behavior may influence Section 5.2. In Section 5.3 you mention GPSR, please include a reference. In Section 5.4 you state that AODV headers are 24 bytes. This seems to be stated to indicate that protocols are not being built to support small MTU links, but I would argue that 24-bytes is a small packet in comparison to many other routing protocols. In Section 5.4, you might want to mention 6lowpan is one instance for handling IEEE 802.15.4 network small MTU problems. In Section 5.5 you discuss sleepy nodes. I see sleepy and low power as related but distinctly different problems. Perhaps you can make sleepy a subsection of low power. In Section 5.7 (MTR) - I have been discussing mechanism to enable MTR in all the MANET protocols. The draft is draft-chakeres-manet- manetid. It has been discussed on list and we plan to include it in DYMO. I'd like to say a few words about DYMO. DYMO has lots of optional behavior and only the most fundamental behaviors are required. For example, path accumulation is optional. Even processing/forwarding a RREQ is optional. Expanding ring search is optional. Interactions with relay sets are optional. Although not described - precursor lists could be implemented and they could be used to control RERR propagation. These optional behaviors allow an intelligent implementation to perform well in a larger number of scenarios, while still interoperating with less intelligent implementations. I understand that because only some basic mechanisms are required and other mechanisms are optional, it will make it more difficult to classify DYMO's performance. The discussion of DSR in the appendix seems quite short when compared to the other protocols, it should probably be expanded. I would suggest you contact the authors for assistance. I hope you can use this information to improve the document. Ian One more thing - Here is a comment related to the current on-list discussion about which protocols to include in the analysis - should mobile IP and other tunneling protocols be included? I say no, but many (e.g. MANEMO) people may say yes. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Apr 1 01:36:28 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10C233A6964; Tue, 1 Apr 2008 01:36:28 -0700 (PDT) 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 8F7683A67E1 for ; Tue, 1 Apr 2008 01:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52AfA90K6aLg for ; Tue, 1 Apr 2008 01:36:19 -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 8B47828C2C8 for ; Tue, 1 Apr 2008 01:35:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,586,1199660400"; d="scan'208,217";a="5011766" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2008 10:35:10 +0200 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 m318Z8O4030337; Tue, 1 Apr 2008 10:35:08 +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 m318Z6v5024788; Tue, 1 Apr 2008 08:35:08 GMT Received: from xmb-ams-335.cisco.com ([144.254.231.80]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 10:35:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 10:35:48 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] industrial requirements (was...) Thread-Index: AciTfeV2I+jznP9xEdyyPgANk8WjQAAUrvcA References: <47F157A3.3080704@eecs.berkeley.edu> From: "Telemaco Melia (tmelia)" To: "Jean Philippe Vasseur (jvasseur)" , "Kris Pister" X-OriginalArrivalTime: 01 Apr 2008 08:35:07.0872 (UTC) FILETIME=[4A94FE00:01C893D3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13655; t=1207038908; x=1207902908; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tmelia@cisco.com; z=From:=20=22Telemaco=20Melia=20(tmelia)=22=20 |Subject:=20RE=3A=20[Roll]=20industrial=20requirements=20(w as...) |Sender:=20; bh=0f5n+1d/ipBa5zLucnPF9jzlc+GOI6MsIQIVxTjAZ1w=; b=Nsxjk7yfL4HfdylWOV0O0nqQjcXmEq6g4XzC/YjPXEDP1R5IWK2qBT5XcG RW9b6IuytVqVgGgHHH3scIowFC9TqnkE8Z/ssGBqvT85KYtQB+NtXjoRG7Ol OsKRUavX59; Authentication-Results: ams-dkim-2; header.From=tmelia@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org Subject: Re: [Roll] industrial requirements (was...) 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: , Content-Type: multipart/mixed; boundary="===============0233278774==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============0233278774== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C893D3.4A63801C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C893D3.4A63801C Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable HI all, =20 Sorry to jump in the middle of this discussion but I would like to clarify the difference between multi path routing and multi topology routing. The former is the ability to maintain, mainly for reliability purposes, different routing paths between a source and destination. The latter, as stated by JP, refers to the ability to maintain multiple topologies for different purposes. Correct? =20 Would it also be correct to assume that between a source a destination you might have several paths depending on the metric you are considering: - reliability - low latency - bandwidth - ... =20 If yes then I guess the text of section 5.1 and 5.7 should be clarified. What do you think? =20 =20 Cheers Telemaco ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jean Philippe Vasseur (jvasseur) Sent: Tuesday, April 01, 2008 12:24 AM To: Kris Pister Cc: roll@ietf.org Subject: Re: [Roll] industrial requirements (was...) Hi Kris, See JP2> ________________________________ From: Kris Pister Date: Mon, 31 Mar 2008 14:29:07 -0700 To: JP Vasseur Cc: Subject: Re: [Roll] industrial requirements (was...) JP Vasseur wrote:=20 Re: [Roll] [manet] Discussion on draft [...] The early deployments in industrial are all around getting data back to one or more sinks. Increasingly over time, these sinks will be a part of a backbone (today they're often fragmented/isolated). This function is likely to always be an important function of the network. =20 JP> Which means that you need both in the requirement document. =20 =09 They're both in there. e.g. " Most low power and lossy network systems [in industrial] in the near future will be for low frequency data collection." "The routing protocol MUST support multiple paths (a tree-based solution is not sufficient)." "Thus, the routing protocol for L2Ns MUST support multi-topology routing (e.g especially critical for critical control applications)." =09 JP2> Multi-topology routing is different though: it refers to the ability to support multiple topologies (e.g., one for low latency, one for high bandwidth): is this what you want ? =09 On-demand internal routes will become more prevalent over time. Some of the on-demand routes will last for years/decades. Internal routes will often be the most critical, optimized and well-maintained (I think that this was where I lost sync: with your statement that they might be less optimized and less well maintained). =20 JP> Just make sure to stay solution-agnostic in the requirement document. =20 =09 I think that we're largely solution-agnostic in -00, but a lot of people of appropriately complained about the repeated references to L2. I'm not trying to make this a HART-like document, or an ISA100-like document, so I'll yank all of the slotted-link and 15.4-specific stuff out of there. At the same time, I think that there are important underlying issues here that require some clever thinking at layer 3 to deal with what's going on in layer 2,=20 JP2> The following WG item should help you there: Nov 2008 Submit Routing metrics for LLNs document to the IESG to be considered as a Proposed Standard. Link routing metric could be derived from the layer-2 characteristics. and relate both to what layer 4 needs. Zach's email from 11/29 asked if routing metrics can serve as enough of an L2 abstraction, or if we need some kind of interactive relationship. I don't know the answer to that question, but I'd sure like to hear some good ideas. JP2> For sure, we'll need to have some discussions on this in the document referenced above. I tend to suggest to first progress on the requirements documents though. Thanks, Cheers. JP. ksjp ________________________________ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------_=_NextPart_001_01C893D3.4A63801C Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: [Roll] industrial requirements (was...)
HI all,
 
Sorry to jump in the middle of this discussion = but I would=20 like to clarify the difference between multi path routing and multi = topology=20 routing.
The former is the ability to maintain, mainly = for=20 reliability purposes, different routing paths between a source and=20 destination.
The latter, as=20 stated by JP, refers to the ability to maintain multiple topologies for=20 different purposes.
Correct?
 
Would it = also be=20 correct to assume that between a=20 source a destination you might have several paths depending on the = metric you=20 are considering:
-=20 reliability
- low=20 latency
-=20 bandwidth
- = ...
 
If yes then I guess the text of section 5.1 = and 5.7=20 should be clarified.
What do you = think?
 
 
Cheers
Telemaco

From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of Jean Philippe Vasseur = (jvasseur)
Sent: Tuesday, April 01, 2008 12:24 = AM
To: Kris=20 Pister
Cc: roll@ietf.org
Subject: Re: [Roll] = industrial=20 requirements (was...)

Hi Kris,

See JP2>


From: Kris Pister <pister@eecs.berkeley.edu>
Date: = Mon,=20 31 Mar 2008 14:29:07 -0700
To: JP Vasseur=20 <jvasseur@cisco.com>
Cc: = <roll@ietf.org>
Subject:=20 Re: [Roll] industrial requirements (was...)

JP Vasseur wrote: =
Re: [Roll] [manet] Discussion on draft = [...]
The=20 early deployments in industrial are all around getting data back to = one or=20 more sinks.  Increasingly over time, these sinks will be a part = of a=20 backbone (today they're often fragmented/isolated).  This = function is=20 likely to always be an important function of the = network.
 
JP>=20 Which means that you need both in the requirement=20 document.
 
They're both in=20 there. e.g. " Most low power and lossy network systems [in industrial] = in the=20 near future will be for low frequency data collection."
"The routing = protocol=20 MUST support multiple paths (a tree-based solution is not=20 sufficient)."
"Thus, the routing protocol for L2Ns MUST support=20 multi-topology routing (e.g especially critical for critical control=20 applications)."

JP2> Multi-topology routing is = different=20 though: it refers to the ability to support multiple topologies (e.g., = one for=20 low latency, one for high bandwidth): is this what you want = ?

On-demand=20 internal routes will become more prevalent over time.  Some of = the=20 on-demand routes will last for years/decades.  Internal routes = will often=20 be the most critical, optimized and well-maintained (I think that this = was=20 where I lost sync: with your statement that they might be less = optimized and=20 less well maintained).
 
JP> Just make sure to stay=20 solution-agnostic in the requirement=20 document.
 
I = think that=20 we're largely solution-agnostic in -00, but a lot of people of = appropriately=20 complained about the repeated references to L2.  I'm not trying to = make=20 this a HART-like document, or an ISA100-like document, so I'll yank all = of the=20 slotted-link and 15.4-specific stuff out of there.  At the same = time, I=20 think that there are important underlying issues here that require some = clever=20 thinking at layer 3 to deal with what's going on in layer 2, =

JP2> The=20 following WG item should help you there:
Nov 2008 =          Submit Routing = metrics for=20 LLNs document to the IESG to be considered as a Proposed = Standard.
Link=20 routing metric could be derived from the layer-2=20 characteristics.

and relate=20 both to what layer 4 needs.
Zach's email from 11/29 asked if routing = metrics=20 can serve as enough of an L2 abstraction, or if we need some kind of = interactive=20 relationship.  I don't know the answer to that question, but I'd = sure like=20 to hear some good ideas.

JP2> For sure, we’ll need to = have some=20 discussions on this in the document referenced above. I tend to suggest = to first=20 progress on the requirements documents=20 though.

Thanks,

Cheers.

JP.

ksjp


_______________________________________________
Roll=20 mailing=20 list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
 ------_=_NextPart_001_01C893D3.4A63801C-- --===============0233278774== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0233278774==-- From roll-bounces@ietf.org Tue Apr 1 01:54:49 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BC703A6A62; Tue, 1 Apr 2008 01:54:49 -0700 (PDT) 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 4B82528C1EB; Tue, 1 Apr 2008 01:54:47 -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 pRQLIO2Uvv-n; Tue, 1 Apr 2008 01:54:45 -0700 (PDT) Received: from scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by core3.amsl.com (Postfix) with ESMTP id 876A03A6A62; Tue, 1 Apr 2008 01:54:45 -0700 (PDT) Received: from castor.cttc.es (castor.cttc.es [84.88.62.196]) by scorpius.cttc.es (8.13.8/8.13.5) with ESMTP id m318rVTb001099 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 1 Apr 2008 10:53:31 +0200 Received: from CTTCPCMDOHLER (pcmdohler.cttc.es [84.88.61.89]) (authenticated bits=0) by castor.cttc.es (8.13.2/8.13.3) with ESMTP id m318rbPt000534 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 Apr 2008 10:53:37 +0200 Message-Id: <200804010853.m318rbPt000534@castor.cttc.es> From: "Mischa Dohler" To: "'Philip Levis'" Date: Tue, 1 Apr 2008 10:52:39 +0200 Organization: CTTC MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <6DBCCFE3-3EE9-43C5-B920-7C213FAC07FD@cs.stanford.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AciTTXx3Jpxq2fIhQkKFtlINUDNPeAAh6GGQ X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (castor.cttc.es [84.88.62.196]); Tue, 01 Apr 2008 10:53:38 +0200 (CEST) X-Scanned-By: MIMEDefang 2.57 on 84.88.62.197 Cc: roll@ietf.org, 'manet manet' Subject: Re: [Roll] Discussion on draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mischa.dohler@cttc.es List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Phil: "Its purpose is expressly *not* to survey research, other standards body, and custom protocols." Mischa: Ok, we will kick in later then. (Phil: "All of these results are from high-level simulators which use a unit-disk model for radio connectivity. Their claims therefore need to be taken with a grain of salt. Among other things, they do not consider any kind of temporal dynamics." Mischa: We are very aware of this and our approaches do not consider unit disk and also cater for high network dynamicity - and - they work very well. Phil: "Recent work on compact routing has shown there is a fundamental tradeoff between routing state and stretch; while geometric or coordinate approaches enable nodes to have O(1) routing state, their stretch is unbounded." Mischa: Ok, thanks for pointing this out.) -----Original Message----- From: Philip Levis [mailto:pal@cs.stanford.edu] Sent: Monday, March 31, 2008 6:36 PM To: mischa.dohler@cttc.es Cc: roll@ietf.org; 'manet manet'; thomas.watteyne@orange-ftgroup.com Subject: Re: [Roll] Discussion on draft On Mar 31, 2008, at 3:14 AM, Mischa Dohler wrote: > Dear Phil, dear all, > > Sorry to start a new thread but my email does not quite fit into > recent > discussions. > > I and my colleagues at France Telecom support Phil's initiative of > identifying the right set of protocols. However, personally, I am > not quite > sure why only link-state and distance-vector based protocols are > listed. Because they are existing IETF protocols with RFCs. > WSNs not only offer but also require different approaches - this had > also > been stated in recent discussions and we would like some canonical > versions > of these protocols to feature in the overview draft. The purpose of this draft is to survey IETF protocols, so that we can then judge how best to move forward towards defining a protocol for WSNs. Its purpose is expressly *not* to survey research, other standards body, and custom protocols. That would be part of a next step, if the WG reaches consensus that existing solutions are insufficient. > > > My colleague Thomas Watteyne (cc'ed) has summarized some approaches > based on > "virtual/relative/approximate coordinates" (many terms for the same > idea) as > follows: > - First, there is a set of propositions which infer the nodes > "approximate > coordinates" from a set of location aware anchor nodes. (Greedy) > geographic > routing protocols can then run on top of these coordinates, although > the > delivery ratio is rather low. > - "Relative coordinates" can be inferred from a set of location- > unaware > anchor nodes. Coordinates are in fact a vector of distances (e.g. in > hops) > to these anchors. Protocols such as Vcap (infocom'06) and Gspring > (ICNP'07) > function this way. The good news is that delivery ratios on those > relative > coordinates are higher than if the same nodes knew their real > coordinates > (!). Drawback is that they need some sort of initialization, > identification > of the anchor nodes. Also, coordinate refreshing procedures seem not > to be > published. All of these results are from high-level simulators which use a unit- disk model for radio connectivity. Their claims therefore need to be taken with a grain of salt. Among other things, they do not consider any kind of temporal dynamics. There is a long literature of coordinate embedding approaches for wireless as well as wired networks. Just in the past few years, before the two you cite above, there is GEM (SenSys '03), Vivaldi (SIGCOMM '04), and BVR (NSDI '05). When it comes to scalable routing approaches, the state of the art in research today is S4 (NSDI '07), which uses compact routing techniques to ensure O(sqrt(n)) routing state with a maximum routing stretch of 3 and, in simulation and simple testbed experiments, an observed average routing stretch of 1.1. Recent work on compact routing has shown there is a fundamental tradeoff between routing state and stretch; while geometric or coordinate approaches enable nodes to have O(1) routing state, their stretch is unbounded. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll