From rsn-bounces@ietf.org Sat Apr 07 09:08:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaAf4-0005Cz-Ki; Sat, 07 Apr 2007 09:08:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaAf3-0005Co-Bk for rsn@ietf.org; Sat, 07 Apr 2007 09:08:57 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaAf2-0005mk-3C for rsn@ietf.org; Sat, 07 Apr 2007 09:08:57 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-3.cisco.com with ESMTP; 07 Apr 2007 06:08:56 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l37D8tZo020478 for ; Sat, 7 Apr 2007 06:08:55 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l37D8tA8008995 for ; Sat, 7 Apr 2007 13:08:55 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 7 Apr 2007 09:08:54 -0400 Received: from [10.86.104.181] ([10.86.104.181]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 7 Apr 2007 09:08:54 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain To: rsn@ietf.org From: JP Vasseur Date: Sat, 7 Apr 2007 09:08:48 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 07 Apr 2007 13:08:54.0429 (UTC) FILETIME=[E4DCACD0:01C77915] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2; t=1175951335; x=1176815335; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20test |Sender:=20; bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=; b=pIdUTBWtp+6sfzjEYuoUnQ/qtbruATOI+KPMtVSOBXlKxE4ESYkHk4KOH64tAYBaOz/Mg+9a bx/fx0E5ANuAXC7ioX7ovfmt0xT39N6Af5d2Ykxtev4p/iw4yv69WiYa; Authentication-Results: sj-dkim-5; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 Subject: [RSN] test X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu Apr 12 22:22:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcBQJ-0007XB-Bx; Thu, 12 Apr 2007 22:22:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcBQI-0007Wx-59 for rsn@ietf.org; Thu, 12 Apr 2007 22:22:02 -0400 Received: from py-out-1112.google.com ([64.233.166.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcBQG-0005ol-S8 for rsn@ietf.org; Thu, 12 Apr 2007 22:22:02 -0400 Received: by py-out-1112.google.com with SMTP id f31so586909pyh for ; Thu, 12 Apr 2007 19:22:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=F+gTj4h4w0MThpEhgoKPZ9mehb74FPxTTY5AqdqNlJ/F+B946tYwP9wotxSVQEE8k9BXDEzzBSCWKpPu5qQ1B7e88amRNmxsoO7g14ZP4kPza9M7wl6dobaXMo4CiNY5tYQB0DF2+6GWFMwXWsXa7OyK/h/P0iM/sZfMjKZHzHM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XKf6q6kw+1IY9CTolh2Fn7GR/C5qVCt2f6+CwBNgmifm1XCswn6ImouPWhqZG3bbaBN6CIpufz6OgkEzHZ4RWqHRNcO0fEmJiHPcwF3sMBf4LJnZ4oEw3BRWGYwy37ZYslTtuW5Ud2731ZwWKUmi34UNBveoIhuD1pNs8y0C8/s= Received: by 10.35.110.13 with SMTP id n13mr4250559pym.1176430920289; Thu, 12 Apr 2007 19:22:00 -0700 (PDT) Received: by 10.35.38.20 with HTTP; Thu, 12 Apr 2007 19:22:00 -0700 (PDT) Message-ID: <2a3692de0704121922g1c08a2b8q3f74d5c02a5f1b1b@mail.gmail.com> Date: Fri, 13 Apr 2007 11:22:00 +0900 From: "Dominik Kaspar" To: rsn@ietf.org In-Reply-To: <2a3692de0704121858u6d934aeckd891f381a138dec7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6938145F-DB59-4A13-97A2-B0F4CA8EFA7F@cisco.com> <2a3692de0704121858u6d934aeckd891f381a138dec7@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [RSN] New Mailing List: Routing for Sensor Network X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org JP, David, I would like to refer to our 6lowpan Routing Requirements draft, which discusses the issues of routing in "sensor networks". The draft provides design goals and a list of requirements for IP-based routing solutions in low-rate WPANs. At IETF-68 in Prague, we presented our work and solicited advice from both MANET and 6lowpan folks. There seemed to be a general consent that routing is a very important task to solve, however, it is heavily dependent on the network architecture itself, and what exactly this "architecture" is should be clarified first. If you haven't done it yet, please read our draft; we appreciate any constructive comments: http://tools.ietf.org/wg/6lowpan/draft-dokaspar-6lowpan-routreq-01.txt Sincerely, Dominik On 4/12/07, JP Vasseur wrote: > Hi, > > We wanted to inform you that a new Mailing List has been set up, the aim of > which is to discuss Routing for Sensor Networks (at the IP layer). Anybody > interested in contributing to the work is of course more than welcome to > subscribe and collaborate. To register: > https://www1.ietf.org/mailman/listinfo/rsn > > Several of you already expressed some real interest in this work and several > documents (with currently no home WG) already exist. David and I posted are > about to post an ID on the routing requirements for Sensor Networks > (probably early next week) to kick off the discussion. > > What is the overall objective ? > 1) As you know a plethora of proprietary routing protocols (thus outside of > the IETF) have been developed and there is within the IETF currently no > clear answer on which protocol(s) can satisfy the very specific requirements > of Sensor Networks. This triggered this initiative so as to define a routing > architecture and routing protocol at the IETF for Sensor Nets, thus this new > mailing list. Note that we may not be able to come up with a single set of > requirements but a few requirement documents accompanied with some > applicability IDs if it turns out that a unique solution cannot satisfy them > all. > 2) There is at this stage no a priori on the routing protocol that could be > used: it could either be (1) existing routing protocol(s) (AODV, DYMO, OLSR, > Triggered RIP, NEMO, ...) (1) existing routing protocol(s) with enhancements > or (3) new routing protocol(s). > > Possible next steps > If enough interest for this work is shown on the list, we will request a BOF > for Chicago, which may lead to forming a new WG. > > JP and David. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu Apr 12 22:26:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcBUS-0002KS-Mx; Thu, 12 Apr 2007 22:26:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcBUR-0002KF-2J for rsn@ietf.org; Thu, 12 Apr 2007 22:26:19 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcBUQ-0006x2-LS for rsn@ietf.org; Thu, 12 Apr 2007 22:26:19 -0400 Received: by ug-out-1314.google.com with SMTP id 72so377068ugd for ; Thu, 12 Apr 2007 19:26:18 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SWWB7N0clatJTencr4sPra8j0onbVLh/97y6Wek2ai/tzB1o/GqsmOhmS1uqkV3rXwnRrw8PLMOtRbb+/uhfoCxDQqNvtXmdtjdUSTsOFPx/lcNQVRVeayzlij0TiSZpngncZMyhyxZ5mib1mp9C8v5d34kcDxOF++qY6t6d8X8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jaEgMvxpaLzSJZ2f10sKhqUCv9eJMpgKqKiRtAaBMyEfP1rxSyUPm3HVtWvKrjSIuRcvQlV1N8avP/07fw+HvU42yXbblbdgfi+GjUVvFQv/x6Kv6zC5SCJ0GWHFwBJ/fITXoFjOjaT9JjNgN8rqlgL/PrTp8mI05D31gx2SIfI= Received: by 10.82.155.10 with SMTP id c10mr3518601bue.1176431177943; Thu, 12 Apr 2007 19:26:17 -0700 (PDT) Received: by 10.82.167.18 with HTTP; Thu, 12 Apr 2007 19:26:17 -0700 (PDT) Message-ID: <77f1dba80704121926v2b85dec7r6e5ec94fef776090@mail.gmail.com> Date: Fri, 13 Apr 2007 11:26:17 +0900 From: "Eunsook \"Eunah\" Kim" To: "Dominik Kaspar" , rsn@ietf.org In-Reply-To: <2a3692de0704121858u6d934aeckd891f381a138dec7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6938145F-DB59-4A13-97A2-B0F4CA8EFA7F@cisco.com> <2a3692de0704121858u6d934aeckd891f381a138dec7@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: manemo@mobileip.jp, manet@ietf.org, 6lowpan@lists.ietf.org, Mark Townsley Subject: [RSN] Re: [6lowpan] Re: [manet] New Mailing List: Routing for Sensor Network X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org JP, David, I'm happy to see RSN has been built up. > http://tools.ietf.org/wg/6lowpan/draft-dokaspar-6lowpan-routreq-01.txt which dominik mentioned below outlines the high-level of routing requirements of LowPAN. The draft has the same objectives as RSN pursuits. >> 2) There is at this stage no a priori on the routing protocol that could be > > used: it could either be (1) existing routing protocol(s) (AODV, DYMO, OLSR, > > Triggered RIP, NEMO, ...) (1) existing routing protocol(s) with enhancements > > or (3) new routing protocol(s). I hope we can gather many interests and results from this mailing list. Cheers, Eunah On 4/13/07, Dominik Kaspar wrote: > JP, David, > > I would like to refer to our 6lowpan Routing Requirements draft, which > discusses the issues of routing in "sensor networks". The draft > provides design goals and a list of requirements for IP-based routing > solutions in low-rate WPANs. > > At IETF-68 in Prague, we presented our work and solicited advice from > both MANET and 6lowpan folks. There seemed to be a general consent > that routing is a very important task to solve, however, it is heavily > dependent on the network architecture itself, and what exactly this > "architecture" is should be clarified first. > > If you haven't done it yet, please read our draft; we appreciate any > constructive comments: > http://tools.ietf.org/wg/6lowpan/draft-dokaspar-6lowpan-routreq-01.txt > > Sincerely, > Dominik > > > On 4/12/07, JP Vasseur wrote: > > Hi, > > > > We wanted to inform you that a new Mailing List has been set up, the aim of > > which is to discuss Routing for Sensor Networks (at the IP layer). Anybody > > interested in contributing to the work is of course more than welcome to > > subscribe and collaborate. To register: > > https://www1.ietf.org/mailman/listinfo/rsn > > > > Several of you already expressed some real interest in this work and several > > documents (with currently no home WG) already exist. David and I posted are > > about to post an ID on the routing requirements for Sensor Networks > > (probably early next week) to kick off the discussion. > > > > What is the overall objective ? > > 1) As you know a plethora of proprietary routing protocols (thus outside of > > the IETF) have been developed and there is within the IETF currently no > > clear answer on which protocol(s) can satisfy the very specific requirements > > of Sensor Networks. This triggered this initiative so as to define a routing > > architecture and routing protocol at the IETF for Sensor Nets, thus this new > > mailing list. Note that we may not be able to come up with a single set of > > requirements but a few requirement documents accompanied with some > > applicability IDs if it turns out that a unique solution cannot satisfy them > > all. > > 2) There is at this stage no a priori on the routing protocol that could be > > used: it could either be (1) existing routing protocol(s) (AODV, DYMO, OLSR, > > Triggered RIP, NEMO, ...) (1) existing routing protocol(s) with enhancements > > or (3) new routing protocol(s). > > > > Possible next steps > > If enough interest for this work is shown on the list, we will request a BOF > > for Chicago, which may lead to forming a new WG. > > > > JP and David. > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Fri Apr 13 07:40:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcK8f-0000TF-Be; Fri, 13 Apr 2007 07:40:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcK8e-0000Ph-AC for rsn@ietf.org; Fri, 13 Apr 2007 07:40:24 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcK8d-0008AC-Jn for rsn@ietf.org; Fri, 13 Apr 2007 07:40:24 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 13 Apr 2007 07:40:23 -0400 X-IronPort-AV: i="4.14,406,1170651600"; d="scan'208,217"; a="118427413:sNHT113484792" 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 l3DBeNkY016429; Fri, 13 Apr 2007 07:40:23 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3DBeJGd005779; Fri, 13 Apr 2007 11:40:23 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 07:40:19 -0400 Received: from [10.86.104.181] ([10.86.104.181]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 07:40:16 -0400 In-Reply-To: <2a3692de0704121922g1c08a2b8q3f74d5c02a5f1b1b@mail.gmail.com> References: <6938145F-DB59-4A13-97A2-B0F4CA8EFA7F@cisco.com> <2a3692de0704121858u6d934aeckd891f381a138dec7@mail.gmail.com> <2a3692de0704121922g1c08a2b8q3f74d5c02a5f1b1b@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: From: JP Vasseur Subject: Re: [RSN] New Mailing List: Routing for Sensor Network Date: Fri, 13 Apr 2007 07:40:04 -0400 To: Dominik Kaspar , Eunsook Eunah Kim X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 13 Apr 2007 11:40:16.0680 (UTC) FILETIME=[81B71280:01C77DC0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=18483; t=1176464423; x=1177328423; 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[RSN]=20New=20Mailing=20List=3A=20Routing=20for=20Sen sor=20Network |Sender:=20 |To:=20Dominik=20Kaspar=20, =0A=20=20=20=20=20=20 =20=20Eunsook=20Eunah=20Kim=20; bh=fFd0s3p9f4cyeR/nHw3bps/+d7Ou36tRBR7iy29ZsO0=; b=ZgupDWXCv2HUddajIQdZ6czjKuj865AFIrb74Q+DfzU4Cp+yJb3h7IgyrGoB3n0PsqDBWvkw oAg7HsjQQSadUElfqRzbcHjO0JqcH62/WSjSz8QkIh9+ZiuQ3RLNDBPw; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2048630227==" Errors-To: rsn-bounces@ietf.org --===============2048630227== Content-Type: multipart/alternative; boundary=Apple-Mail-28-588709374 --Apple-Mail-28-588709374 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Dominik and and Kim, Thanks for your email and support for this work, no need to say that your contribution is most welcome. What I would propose here would be for you to read the draft that Dave and I have posted and that should be available in the next few days and provide us some feed-back. As you will see we're trying to exclusively focus on the requirements for the time being while staying completely technology agnostic, which is key for a requirement ID. If my understanding is correct you state in R0 "Existing MANET protocols (e.g., AODV, OLSR, DYMO) SHOULD be reused." I would propose to step back for the moment from any specific solution to again focus on the requirements. As indicated below, we may end up using a MANET protocol with adaptation but this should not be a pre-requisite and none of them fully satisfy the requirements, thus the need for discussion on this list and potentially a WG since this discussion will likely require a significant amount of work. There is another fundamental difference: in R02 you mention "6LoWPAN routing MUST be performed in the adaptation layer, as defined in [3].". We propose to specify a routing protocol for Sensor Network above IP, not coupled with any specific layer1/2 technologies, which is of the utmost importance to support mixed environments that already exist. Looking forward to having your comments on the draft (draft-culler- rsn-routing-reqs-00.txt), which should be available very soon. Thanks. JP. On Apr 12, 2007, at 10:22 PM, Dominik Kaspar wrote: > JP, David, > > I would like to refer to our 6lowpan Routing Requirements draft, which > discusses the issues of routing in "sensor networks". The draft > provides design goals and a list of requirements for IP-based routing > solutions in low-rate WPANs. > > At IETF-68 in Prague, we presented our work and solicited advice from > both MANET and 6lowpan folks. There seemed to be a general consent > that routing is a very important task to solve, however, it is heavily > dependent on the network architecture itself, and what exactly this > "architecture" is should be clarified first. > > If you haven't done it yet, please read our draft; we appreciate any > constructive comments: > http://tools.ietf.org/wg/6lowpan/draft-dokaspar-6lowpan-routreq-01.txt > > Sincerely, > Dominik > > > On 4/12/07, JP Vasseur wrote: >> Hi, >> >> We wanted to inform you that a new Mailing List has been set up, >> the aim of >> which is to discuss Routing for Sensor Networks (at the IP layer). >> Anybody >> interested in contributing to the work is of course more than >> welcome to >> subscribe and collaborate. To register: >> https://www1.ietf.org/mailman/listinfo/rsn >> >> Several of you already expressed some real interest in this work >> and several >> documents (with currently no home WG) already exist. David and I >> posted are >> about to post an ID on the routing requirements for Sensor Networks >> (probably early next week) to kick off the discussion. >> >> What is the overall objective ? >> 1) As you know a plethora of proprietary routing protocols (thus >> outside of >> the IETF) have been developed and there is within the IETF >> currently no >> clear answer on which protocol(s) can satisfy the very specific >> requirements >> of Sensor Networks. This triggered this initiative so as to define >> a routing >> architecture and routing protocol at the IETF for Sensor Nets, >> thus this new >> mailing list. Note that we may not be able to come up with a >> single set of >> requirements but a few requirement documents accompanied with some >> applicability IDs if it turns out that a unique solution cannot >> satisfy them >> all. >> 2) There is at this stage no a priori on the routing protocol that >> could be >> used: it could either be (1) existing routing protocol(s) (AODV, >> DYMO, OLSR, >> Triggered RIP, NEMO, ...) (1) existing routing protocol(s) with >> enhancements >> or (3) new routing protocol(s). >> >> Possible next steps >> If enough interest for this work is shown on the list, we will >> request a BOF >> for Chicago, which may lead to forming a new WG. >> >> JP and David. >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn --Apple-Mail-28-588709374 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Dominik and and Kim,

Thanks for your email and = support for this work, no need to say that your contribution is most = welcome.
What I would propose here would be for you to read the = draft that Dave and I have posted and that should = be
available in the next few days and provide us some = feed-back.=A0

As you will see we're trying = to exclusively=A0focus on the requirements for the time being while = staying completely technology agnostic, which is key for=A0a requirement = ID.=A0

If my understanding is correct = you state in R0 "Existing MANET protocols (e.g., AODV, OLSR, DYMO) = SHOULD be reused." I would propose to step back for the moment from any = specific solution to again focus on the requirements. As indicated = below, we may end up using a MANET protocol with adaptation but this = should not be a pre-requisite and none of them fully satisfy the = requirements, thus the need for discussion on this list and potentially = a WG since this discussion will likely require a=A0significant amount of = work. There is another fundamental difference: in R02 you mention = "6LoWPAN routing MUST be performed in the adaptation layer, as defined = in [3].". We propose to specify a routing protocol for Sensor Network = above IP, not coupled with any specific layer1/2 technologies, which is = of the utmost importance to support mixed environments that already = exist.=A0

Looking forward to having your comments on the draft = (draft-culler-rsn-routing-reqs-00.txt), which should be available very = soon.

Thanks.

JP.

On Apr 12, 2007, at = 10:22 PM, Dominik Kaspar wrote:

JP, David,

I would like to refer to our = 6lowpan Routing Requirements draft, which
provides design goals and a list = of requirements for IP-based routing
solutions in = low-rate WPANs.

At IETF-68 in Prague, we presented our work and = solicited advice from
both MANET and 6lowpan = folks. There seemed to be a general consent
that = routing is a very important task to solve, however, it is = heavily
dependent on the network = architecture itself, and what exactly this

If you = haven't done it yet, please read our draft; we appreciate any
constructive comments:

Sincerely,


On = 4/12/07, JP Vasseur <jvasseur@cisco.com> = wrote:
Hi,

We = wanted to inform you that a new Mailing List has been set up, the aim = of
which is to discuss Routing for Sensor Networks = (at the IP layer). Anybody
interested in = contributing to the work is of course more than welcome to
subscribe and collaborate. To register:

Several of you already expressed = some real interest in this work and several
about to post an ID on the = routing requirements for Sensor Networks

What is = the overall objective ?
1) As you = know a plethora of proprietary routing protocols (thus outside = of
the IETF) have been developed and there is = within the IETF currently no
clear answer = on which protocol(s) can satisfy the very specific = requirements
of Sensor Networks. This = triggered this initiative so as to define a routing
architecture and routing protocol at the IETF for = Sensor Nets, thus this new
mailing list. = Note that we may not be able to come up with a single set of
requirements but a few requirement documents = accompanied with some
applicability IDs if it = turns out that a unique solution cannot satisfy them
all.
2) There is = at this stage no a priori on the routing protocol that could = be
used: it could either be (1) existing routing = protocol(s) (AODV, DYMO, OLSR,
Triggered = RIP, NEMO, ...) (1) existing routing protocol(s) with = enhancements
or (3) new routing = protocol(s).

Possible next steps
If = enough interest for this work is shown on the list, we will request a = BOF
for Chicago, which may lead to = forming a new WG.

JP and David.

manet mailing list

RSN mailing list
=

= --Apple-Mail-28-588709374-- --===============2048630227== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============2048630227==-- From rsn-bounces@ietf.org Fri Apr 13 07:48:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKGr-0006DM-9A; Fri, 13 Apr 2007 07:48:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKGq-0006DG-Sm for rsn@ietf.org; Fri, 13 Apr 2007 07:48:52 -0400 Received: from mail83.messagelabs.com ([195.245.231.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HcKGp-000210-PP for rsn@ietf.org; Fri, 13 Apr 2007 07:48:52 -0400 X-VirusChecked: Checked X-Env-Sender: N.Akhtar@surrey.ac.uk X-Msg-Ref: server-4.tower-83.messagelabs.com!1176464848!31587917!29 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 19560 invoked from network); 13 Apr 2007 11:48:48 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-4.tower-83.messagelabs.com with SMTP; 13 Apr 2007 11:48:48 -0000 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 12:47:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [RSN] New Mailing List: Routing for Sensor Network Date: Fri, 13 Apr 2007 12:46:59 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] New Mailing List: Routing for Sensor Network Thread-Index: Acd9wI2kVFnkHeJyQqSEUbgmQKNr8QAAD8aQ References: <6938145F-DB59-4A13-97A2-B0F4CA8EFA7F@cisco.com><2a3692de0704121858u6d934aeckd891f381a138dec7@mail.gmail.com><2a3692de0704121922g1c08a2b8q3f74d5c02a5f1b1b@mail.gmail.com> From: To: , , X-OriginalArrivalTime: 13 Apr 2007 11:47:01.0438 (UTC) FILETIME=[72F83DE0:01C77DC1] X-Spam-Score: 0.3 (/) X-Scan-Signature: efc5d1db3729b4b7031f1bb5f5a30ae3 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1915288078==" Errors-To: rsn-bounces@ietf.org This is a multi-part message in MIME format. --===============1915288078== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77DC1.71A1E847" This is a multi-part message in MIME format. ------_=_NextPart_001_01C77DC1.71A1E847 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I think it will be dangerous to start-off with requirements based on MANET work. I would suggest a more top-down approach by looking at the specific routing challenges for sensor networks and then looking at the SoA to see if there are existng protocols which can be used as the basis for further work. =20 Regards, Nadeem ________________________________ From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: 13 April 2007 12:40 To: Dominik Kaspar; Eunsook Eunah Kim Cc: rsn@ietf.org Subject: Re: [RSN] New Mailing List: Routing for Sensor Network Hi Dominik and and Kim,=20 Thanks for your email and support for this work, no need to say that your contribution is most welcome. What I would propose here would be for you to read the draft that Dave and I have posted and that should be available in the next few days and provide us some feed-back.=20 As you will see we're trying to exclusively focus on the requirements for the time being while staying completely technology agnostic, which is key for a requirement ID.=20 If my understanding is correct you state in R0 "Existing MANET protocols (e.g., AODV, OLSR, DYMO) SHOULD be reused." I would propose to step back for the moment from any specific solution to again focus on the requirements. As indicated below, we may end up using a MANET protocol with adaptation but this should not be a pre-requisite and none of them fully satisfy the requirements, thus the need for discussion on this list and potentially a WG since this discussion will likely require a significant amount of work. There is another fundamental difference: in R02 you mention "6LoWPAN routing MUST be performed in the adaptation layer, as defined in [3].". We propose to specify a routing protocol for Sensor Network above IP, not coupled with any specific layer1/2 technologies, which is of the utmost importance to support mixed environments that already exist.=20 Looking forward to having your comments on the draft (draft-culler-rsn-routing-reqs-00.txt), which should be available very soon. Thanks. JP. On Apr 12, 2007, at 10:22 PM, Dominik Kaspar wrote: JP, David, I would like to refer to our 6lowpan Routing Requirements draft, which discusses the issues of routing in "sensor networks". The draft provides design goals and a list of requirements for IP-based routing solutions in low-rate WPANs. At IETF-68 in Prague, we presented our work and solicited advice from both MANET and 6lowpan folks. There seemed to be a general consent that routing is a very important task to solve, however, it is heavily dependent on the network architecture itself, and what exactly this "architecture" is should be clarified first. If you haven't done it yet, please read our draft; we appreciate any constructive comments: =09 http://tools.ietf.org/wg/6lowpan/draft-dokaspar-6lowpan-routreq-01.txt Sincerely, Dominik On 4/12/07, JP Vasseur wrote: Hi, We wanted to inform you that a new Mailing List has been set up, the aim of which is to discuss Routing for Sensor Networks (at the IP layer). Anybody interested in contributing to the work is of course more than welcome to subscribe and collaborate. To register: https://www1.ietf.org/mailman/listinfo/rsn Several of you already expressed some real interest in this work and several documents (with currently no home WG) already exist. David and I posted are about to post an ID on the routing requirements for Sensor Networks (probably early next week) to kick off the discussion. What is the overall objective ? 1) As you know a plethora of proprietary routing protocols (thus outside of the IETF) have been developed and there is within the IETF currently no clear answer on which protocol(s) can satisfy the very specific requirements of Sensor Networks. This triggered this initiative so as to define a routing architecture and routing protocol at the IETF for Sensor Nets, thus this new mailing list. Note that we may not be able to come up with a single set of requirements but a few requirement documents accompanied with some applicability IDs if it turns out that a unique solution cannot satisfy them all. 2) There is at this stage no a priori on the routing protocol that could be used: it could either be (1) existing routing protocol(s) (AODV, DYMO, OLSR, Triggered RIP, NEMO, ...) (1) existing routing protocol(s) with enhancements or (3) new routing protocol(s). Possible next steps If enough interest for this work is shown on the list, we will request a BOF for Chicago, which may lead to forming a new WG. JP and David. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn ------_=_NextPart_001_01C77DC1.71A1E847 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear all,
 I think it will be dangerous to start-off = with=20 requirements based on MANET work. I would suggest a more top-down = approach by=20 looking at the specific routing challenges for sensor networks and then = looking=20 at the SoA to see if there are existng protocols which can be used = as the=20 basis for further work.
 
Regards,
Nadeem

From: JP Vasseur = [mailto:jvasseur@cisco.com]=20
Sent: 13 April 2007 12:40
To: Dominik Kaspar; = Eunsook Eunah=20 Kim
Cc: rsn@ietf.org
Subject: Re: [RSN] New Mailing = List:=20 Routing for Sensor Network

Hi Dominik and and Kim,

Thanks for your email = and support=20 for this work, no need to say that your contribution is most=20 welcome.
What I would propose = here would be=20 for you to read the draft that Dave and I have posted and that should=20 be
available in the next = few days and=20 provide us some feed-back. 
As you will see we're = trying to=20 exclusively focus on the requirements for the time being while = staying=20 completely technology agnostic, which is key for a requirement=20 ID. 
If my understanding is = correct you=20 state in R0 "Existing MANET protocols (e.g., AODV, OLSR, DYMO) SHOULD be = reused." I would propose to step back for the moment from any specific = solution=20 to again focus on the requirements. As indicated below, we may end up = using a=20 MANET protocol with adaptation but this should not be a pre-requisite = and none=20 of them fully satisfy the requirements, thus the need for discussion on = this=20 list and potentially a WG since this discussion will likely require=20 a significant amount of work. There is another fundamental = difference: in=20 R02 you mention "6LoWPAN routing MUST be performed in the adaptation = layer, as=20 defined in [3].". We propose to specify a routing protocol for Sensor = Network=20 above IP, not coupled with any specific layer1/2 technologies, which is = of the=20 utmost importance to support mixed environments that already=20 exist. 
Looking forward=20 to having your comments on the draft = (draft-culler-rsn-routing-reqs-00.txt),=20 which should be available very soon.
Thanks.
JP.

On Apr 12, 2007, at 10:22 PM, Dominik Kaspar wrote:
JP, David,

I would like to refer to our 6lowpan = Routing=20 Requirements draft, which
discusses the issues of routing in "sensor = networks".=20 The draft
provides design goals and a list of = requirements for=20 IP-based routing
solutions in low-rate WPANs.

At IETF-68 in Prague, we presented our work = and=20 solicited advice from
both MANET and 6lowpan folks. There seemed = to be a=20 general consent
that routing is a very important task to = solve,=20 however, it is heavily
dependent on the network architecture = itself, and=20 what exactly this
"architecture" is should be clarified = first.

If you haven't done it yet, please read our = draft; we=20 appreciate any
constructive comments:
http://tools.ietf.org/wg/6lowpan/draft-dokaspar-6lowpan-routreq-01= .txt

Sincerely,
Dominik


On 4/12/07, JP Vasseur <jvasseur@cisco.com> = wrote:
Hi,

We wanted to inform you that a new = Mailing List has=20 been set up, the aim of
which is to discuss Routing for Sensor = Networks (at=20 the IP layer). Anybody
interested in contributing to the work is = of course=20 more than welcome to
subscribe and collaborate. To = register:
https://www1.ietf.org= /mailman/listinfo/rsn

Several of you already expressed some = real interest=20 in this work and several
documents (with currently no home WG) = already=20 exist. David and I posted are
about to post an ID on the routing = requirements for=20 Sensor Networks
(probably early next week) to kick off = the=20 discussion.

What is the overall objective ?
1) As you know a plethora of proprietary = routing=20 protocols (thus outside of
the IETF) have been developed and there = is within=20 the IETF currently no
clear answer on which protocol(s) can = satisfy the=20 very specific requirements
of Sensor Networks. This triggered this = initiative=20 so as to define a routing
architecture and routing protocol at the = IETF for=20 Sensor Nets, thus this new
mailing list. Note that we may not be = able to come=20 up with a single set of
requirements but a few requirement = documents=20 accompanied with some
applicability IDs if it turns out that a = unique=20 solution cannot satisfy them
all.
2) There is at this stage no a priori on = the=20 routing protocol that could be
used: it could either be (1) existing = routing=20 protocol(s) (AODV, DYMO, OLSR,
Triggered RIP, NEMO, ...) (1) existing = routing=20 protocol(s) with enhancements
or (3) new routing protocol(s).

Possible next steps
If enough interest for this work is shown = on the=20 list, we will request a BOF
for Chicago, which may lead to forming a = new=20 WG.

JP and David.

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/manet

_______________________________________________
RSN mailing list
https://www1.ietf.org= /mailman/listinfo/rsn

= ------_=_NextPart_001_01C77DC1.71A1E847-- --===============1915288078== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============1915288078==-- From rsn-bounces@ietf.org Fri Apr 13 07:59:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKR4-000505-Gw; Fri, 13 Apr 2007 07:59:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKR3-0004zx-P6 for rsn@ietf.org; Fri, 13 Apr 2007 07:59:25 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcKR2-0005It-9x for rsn@ietf.org; Fri, 13 Apr 2007 07:59:25 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 13 Apr 2007 07:59:24 -0400 X-IronPort-AV: i="4.14,407,1170651600"; d="scan'208,217"; a="118428483:sNHT112241264" 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 l3DBxOFv031184; Fri, 13 Apr 2007 07:59:24 -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.12.10/8.12.6) with ESMTP id l3DBwvlm017951; Fri, 13 Apr 2007 11:59:21 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 07:59:14 -0400 Received: from [10.86.104.181] ([10.86.104.181]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 07:59:13 -0400 In-Reply-To: References: <6938145F-DB59-4A13-97A2-B0F4CA8EFA7F@cisco.com><2a3692de0704121858u6d934aeckd891f381a138dec7@mail.gmail.com><2a3692de0704121922g1c08a2b8q3f74d5c02a5f1b1b@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <79FE8B21-2B99-4FFB-B7F1-2BBE40D37B9D@cisco.com> From: JP Vasseur Subject: Re: [RSN] New Mailing List: Routing for Sensor Network Date: Fri, 13 Apr 2007 07:58:59 -0400 To: "" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 13 Apr 2007 11:59:13.0742 (UTC) FILETIME=[2774F6E0:01C77DC3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=17483; t=1176465564; x=1177329564; 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[RSN]=20New=20Mailing=20List=3A=20Routing=20for=20Sen sor=20Network |Sender:=20 |To:=20=22=22=20; bh=OcwnBNIFrF/lxxC5uTEOQVwkIg94v0CK1Obz7jmsPSE=; b=IDj3f9fkqrtSxh+jnV+dXpQ2SZiio2yD/gZ7HlgWbX2j+xVRn92XB9sv5uHpoXKN1UU16X+D cCGvNfuP9+TpYZdFb09W4HA6kZbEgY+VOiWPnAeqFNNq5dJZAvX2f4yl; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 32a65c0bf5eb4ec26489239c7cdd0636 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0130817982==" Errors-To: rsn-bounces@ietf.org --===============0130817982== Content-Type: multipart/alternative; boundary=Apple-Mail-30-589843864 --Apple-Mail-30-589843864 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On Apr 13, 2007, at 7:46 AM, wrote: > Dear all, > I think it will be dangerous to start-off with requirements based > on MANET work. I would suggest a more top-down approach by looking > at the specific routing challenges for sensor networks and then > looking at the SoA to see if there are existng protocols which can > be used as the basis for further work. > Right, as you'll see in the draft, this is the approach we took (a requirement ID must be solution agnostic anyway). Comments welcome. Thanks. JP. > > Regards, > Nadeem > > From: JP Vasseur [mailto:jvasseur@cisco.com] > Sent: 13 April 2007 12:40 > To: Dominik Kaspar; Eunsook Eunah Kim > Cc: rsn@ietf.org > Subject: Re: [RSN] New Mailing List: Routing for Sensor Network > > Hi Dominik and and Kim, > > Thanks for your email and support for this work, no need to say > that your contribution is most welcome. > What I would propose here would be for you to read the draft that > Dave and I have posted and that should be > available in the next few days and provide us some feed-back. > > As you will see we're trying to exclusively focus on the > requirements for the time being while staying completely technology > agnostic, which is key for a requirement ID. > > If my understanding is correct you state in R0 "Existing MANET > protocols (e.g., AODV, OLSR, DYMO) SHOULD be reused." I would > propose to step back for the moment from any specific solution to > again focus on the requirements. As indicated below, we may end up > using a MANET protocol with adaptation but this should not be a pre- > requisite and none of them fully satisfy the requirements, thus the > need for discussion on this list and potentially a WG since this > discussion will likely require a significant amount of work. There > is another fundamental difference: in R02 you mention "6LoWPAN > routing MUST be performed in the adaptation layer, as defined in > [3].". We propose to specify a routing protocol for Sensor Network > above IP, not coupled with any specific layer1/2 technologies, > which is of the utmost importance to support mixed environments > that already exist. > > Looking forward to having your comments on the draft (draft-culler- > rsn-routing-reqs-00.txt), which should be available very soon. > > Thanks. > > JP. > > On Apr 12, 2007, at 10:22 PM, Dominik Kaspar wrote: > >> JP, David, >> >> I would like to refer to our 6lowpan Routing Requirements draft, >> which >> discusses the issues of routing in "sensor networks". The draft >> provides design goals and a list of requirements for IP-based routing >> solutions in low-rate WPANs. >> >> At IETF-68 in Prague, we presented our work and solicited advice from >> both MANET and 6lowpan folks. There seemed to be a general consent >> that routing is a very important task to solve, however, it is >> heavily >> dependent on the network architecture itself, and what exactly this >> "architecture" is should be clarified first. >> >> If you haven't done it yet, please read our draft; we appreciate any >> constructive comments: >> http://tools.ietf.org/wg/6lowpan/draft-dokaspar-6lowpan- >> routreq-01.txt >> >> Sincerely, >> Dominik >> >> >> On 4/12/07, JP Vasseur wrote: >>> Hi, >>> >>> We wanted to inform you that a new Mailing List has been set up, >>> the aim of >>> which is to discuss Routing for Sensor Networks (at the IP >>> layer). Anybody >>> interested in contributing to the work is of course more than >>> welcome to >>> subscribe and collaborate. To register: >>> https://www1.ietf.org/mailman/listinfo/rsn >>> >>> Several of you already expressed some real interest in this work >>> and several >>> documents (with currently no home WG) already exist. David and I >>> posted are >>> about to post an ID on the routing requirements for Sensor Networks >>> (probably early next week) to kick off the discussion. >>> >>> What is the overall objective ? >>> 1) As you know a plethora of proprietary routing protocols (thus >>> outside of >>> the IETF) have been developed and there is within the IETF >>> currently no >>> clear answer on which protocol(s) can satisfy the very specific >>> requirements >>> of Sensor Networks. This triggered this initiative so as to >>> define a routing >>> architecture and routing protocol at the IETF for Sensor Nets, >>> thus this new >>> mailing list. Note that we may not be able to come up with a >>> single set of >>> requirements but a few requirement documents accompanied with some >>> applicability IDs if it turns out that a unique solution cannot >>> satisfy them >>> all. >>> 2) There is at this stage no a priori on the routing protocol >>> that could be >>> used: it could either be (1) existing routing protocol(s) (AODV, >>> DYMO, OLSR, >>> Triggered RIP, NEMO, ...) (1) existing routing protocol(s) with >>> enhancements >>> or (3) new routing protocol(s). >>> >>> Possible next steps >>> If enough interest for this work is shown on the list, we will >>> request a BOF >>> for Chicago, which may lead to forming a new WG. >>> >>> JP and David. >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www1.ietf.org/mailman/listinfo/manet >> >> _______________________________________________ >> RSN mailing list >> RSN@ietf.org >> https://www1.ietf.org/mailman/listinfo/rsn > --Apple-Mail-30-589843864 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi,

On Apr 13, = 2007, at 7:46 AM, <N.Akhtar@surrey.ac.uk> = <N.Akhtar@surrey.ac.uk>= wrote:

Dear=A0all,
=A0I think it will be dangerous to = start-off with requirements based on MANET work. I would suggest a more = top-down approach by looking at the specific routing challenges for = sensor networks and then looking at the SoA to see if there are existng = protocols=A0which can be used as the basis for further = work.


Right, as you'll see in the = draft, this is the approach we took (a requirement ID must be solution = agnostic anyway).
Comments welcome.

Thanks.

JP.

=A0
Regards,
Nadeem

=
From: JP = Vasseur [mailto:jvasseur@cisco.com] =
Sent: 13 April 2007 12:40
To: Dominik Kaspar; = Eunsook Eunah Kim
Cc: rsn@ietf.org
Subject: Re: = [RSN] New Mailing List: Routing for Sensor Network

=
Hi Dominik and and Kim,

Thanks for your email and = support for this work, no need to say that your contribution is most = welcome.
What I would propose here would be for you to read the = draft that Dave and I have posted and that should be
=
available in the = next few days and provide us some feed-back.=A0

As you will see we're trying = to exclusively=A0focus on the requirements for the time being while = staying completely technology agnostic, which is key for=A0a requirement = ID.=A0

=
If my understanding = is correct you state in R0 "Existing MANET protocols (e.g., AODV, OLSR, = DYMO) SHOULD be reused." I would propose to step back for the moment = from any specific solution to again focus on the requirements. As = indicated below, we may end up using a MANET protocol with adaptation = but this should not be a pre-requisite and none of them fully satisfy = the requirements, thus the need for discussion on this list and = potentially a WG since this discussion will likely require a=A0significant= amount of work. There is another fundamental difference: in R02 you = mention "6LoWPAN routing MUST be performed in the adaptation layer, as = defined in [3].". We propose to specify a routing protocol for Sensor = Network above IP, not coupled with any specific layer1/2 technologies, = which is of the utmost importance to support mixed environments that = already exist.=A0

Looking forward to = having your comments on the draft = (draft-culler-rsn-routing-reqs-00.txt), which should be available very = soon.

Thanks.
=

JP.

On Apr 12, 2007, at = 10:22 PM, Dominik Kaspar wrote:

JP, David,

I would like to = refer to our 6lowpan Routing Requirements draft, which
discusses the issues of routing in "sensor = networks". The draft
provides design = goals and a list of requirements for IP-based routing
solutions in low-rate WPANs.

At IETF-68 in Prague, we presented our work and solicited advice = from
both MANET and 6lowpan folks. = There seemed to be a general consent
that routing is a very important task to solve, however, it is = heavily
dependent on the network = architecture itself, and what exactly this
"architecture" is should be clarified first.

If you haven't done it yet, please read our draft; we appreciate = any
constructive comments:

=
Sincerely,
Dominik


=
On 4/12/07, JP Vasseur <jvasseur@cisco.com> = wrote:
Hi,

We wanted to inform you = that a new Mailing List has been set up, the aim of
which is to discuss Routing for Sensor Networks = (at the IP layer). Anybody
interested in contributing to the work is of course more than = welcome to
subscribe and = collaborate. To register:

Several of you = already expressed some real interest in this work and several
=
documents (with currently no home WG) = already exist. David and I posted are
about to post an ID on the routing requirements for Sensor = Networks
(probably early next week) = to kick off the discussion.

What is the = overall objective ?
1) As you know a = plethora of proprietary routing protocols (thus outside of
=
the IETF) have been developed and there is = within the IETF currently no
clear answer on which protocol(s) can satisfy the very specific = requirements
of Sensor Networks. = This triggered this initiative so as to define a routing
=
architecture and routing protocol at the IETF = for Sensor Nets, thus this new
mailing list. Note that we may not be able to come up with a = single set of
requirements but a few = requirement documents accompanied with some
applicability IDs if it turns out that a unique = solution cannot satisfy them
all.
2) There is at this stage = no a priori on the routing protocol that could be
used: it could either be (1) existing routing = protocol(s) (AODV, DYMO, OLSR,
Triggered RIP, NEMO, ...) (1) existing routing protocol(s) with = enhancements
or (3) new routing = protocol(s).

Possible next steps
=
If enough interest for this work is shown = on the list, we will request a BOF
for Chicago, which may lead to forming a new WG.

JP and David.

_______________________________________________
manet mailing list

_______________________________________________
RSN mailing list


= --Apple-Mail-30-589843864-- --===============0130817982== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============0130817982==-- From rsn-bounces@ietf.org Fri Apr 13 13:01:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcP9h-0001Ul-21; Fri, 13 Apr 2007 13:01:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcP9f-0001TZ-N5 for rsn@ietf.org; Fri, 13 Apr 2007 13:01:47 -0400 Received: from cs-smtp-3.stanford.edu ([171.64.64.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcP9e-0002Nl-Bg for rsn@ietf.org; Fri, 13 Apr 2007 13:01:47 -0400 Received: from dnab42209a.stanford.edu ([171.66.32.154]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1HcP9d-0007DP-6x; Fri, 13 Apr 2007 10:01:45 -0700 In-Reply-To: References: <6938145F-DB59-4A13-97A2-B0F4CA8EFA7F@cisco.com> <2a3692de0704121858u6d934aeckd891f381a138dec7@mail.gmail.com> <2a3692de0704121922g1c08a2b8q3f74d5c02a5f1b1b@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9C83F395-E3D8-415E-B18F-2AF191F9D429@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [RSN] New Mailing List: Routing for Sensor Network Date: Fri, 13 Apr 2007 09:04:24 -0700 To: JP Vasseur X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -102.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-3.Stanford.EDU X-Scan-Signature: d568c20fab0e2ccae07d583947984559 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org On Apr 13, 2007, at 4:40 AM, JP Vasseur wrote: > Hi Dominik and and Kim, > > Thanks for your email and support for this work, no need to say > that your contribution is most welcome. > What I would propose here would be for you to read the draft that > Dave and I have posted and that should be > available in the next few days and provide us some feed-back. > > As you will see we're trying to exclusively focus on the > requirements for the time being while staying completely technology > agnostic, which is key for a requirement ID. > > If my understanding is correct you state in R0 "Existing MANET > protocols (e.g., AODV, OLSR, DYMO) SHOULD be reused." I would > propose to step back for the moment from any specific solution to > again focus on the requirements. As indicated below, we may end up > using a MANET protocol with adaptation but this should not be a pre- > requisite and none of them fully satisfy the requirements, thus the > need for discussion on this list and potentially a WG since this > discussion will likely require a significant amount of work. I think this is a very important point. While mobility is an issue in many sensornets, many are quite stationary. Requiring the stationary ones to incur the energy cost of the overhead of supporting mobility might not be a good idea. Phil _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Fri Apr 13 16:28:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcSNR-0007yk-EF; Fri, 13 Apr 2007 16:28:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcSNP-0007yf-Ug for rsn@ietf.org; Fri, 13 Apr 2007 16:28:11 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcSNN-0003zY-6D for rsn@ietf.org; Fri, 13 Apr 2007 16:28:11 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 13 Apr 2007 16:28:09 -0400 X-IronPort-AV: i="4.14,409,1170651600"; d="scan'208,217"; a="118497027:sNHT113795204" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3DKS8EY008246 for ; Fri, 13 Apr 2007 16:28:08 -0400 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 l3DKS8Gd014670 for ; Fri, 13 Apr 2007 20:28:08 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 16:28:08 -0400 Received: from [161.44.71.112] ([161.44.71.112]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 16:28:08 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) To: rsn@ietf.org Message-Id: <4E21EAEE-F7AC-4424-A157-BFEECBBA7761@cisco.com> References: From: JP Vasseur Date: Fri, 13 Apr 2007 16:28:05 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 13 Apr 2007 20:28:08.0454 (UTC) FILETIME=[3F904260:01C77E0A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=20331; t=1176496089; x=1177360089; 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:=20Fwd=3A=20I-D=20ACTION=3Adraft-culler-rsn-routing-reqs-00.txt= 20 |Sender:=20 |To:=20rsn@ietf.org; bh=eg+XhkOWvoydUgK8MGKuJMlYEh6XDDepM5s9s3D2Xes=; b=f2zGrHweYM3v4r7F8kvc0ylSShx20tHkb5kO+51lRbCLV0RKJdlU0mWeygKVae2dnEmHQePJ EMwOxGyKv92QPGD9r+xnZ0xosco8GyFsXl2OR+rU+LpUa+p2vebLOWIf; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 Subject: [RSN] Fwd: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1578794781==" Errors-To: rsn-bounces@ietf.org --===============1578794781== Content-Type: multipart/alternative; boundary=Apple-Mail-44-620390418 --Apple-Mail-44-620390418 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, Glad to see a good number of people who signed up to list already. Here is the first revision of the requirements ID. Feedbacks most welcome of course ! Thanks. JP and David. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: April 13, 2007 3:50:01 PM EDT > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Routing Requirements for Sensor Networks > Author(s) : D. Cullerot, J. Vasseur > Filename : draft-culler-rsn-routing-reqs-00.txt > Pages : > Date : 2007-4-13 > > The need for high quality routing for Sensor networks comprised of > highly constrained devices (CPU, memory, ...) in sometimes unstable > wireless environments is critical now and will continue to > increase. > Interest in this class of applications has grown dramatically in > recent years and a routing solution addressing the specific > environments of such networks is highly required considering the > numerous, incompatible open-source and proprietary routing > protocols > as well as several industrial forums. The aim of this document > is to > define the routing requirements for Sensor Networks at the IP > layer. > Such routing protocol(s) would need to address several unique > aspects > of this class of embedded devices and would operate in networks > comprising links of various nature. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-culler-rsn-routing- > reqs-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-culler-rsn-routing-reqs-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-culler-rsn-routing-reqs-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2007-4-13132741.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce --Apple-Mail-44-620390418 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Hi,

Glad to see a good number = of people who signed up to list already. Here is the first revision of = the requirements ID. Feedbacks most welcome of course !

Thanks.

JP and = David.

Begin forwarded message:

Date: April 13, 2007 3:50:01 PM = EDT
To: i-d-announce@ietf.org
Subject: = I-D ACTION:draft-culler-rsn-routing-reqs-00.txt=A0

A New Internet-Draft is available from the on-line = Internet-Drafts=A0
directories.


Title : Routing Requirements for Sensor = Networks
Author(s) : D. = Cullerot, J. Vasseur
= Filename = : draft-culler-rsn-routing-reqs-00.txt
Pages :=A0
Date : = 2007-4-13

=A0=A0 The need for high quality = routing for Sensor networks comprised of
=A0=A0 highly constrained devices = (CPU, memory, ...) in sometimes unstable
=A0=A0 wireless environments is = critical now and will continue to increase.
=A0=A0 Interest in this class of = applications has grown dramatically in
=A0=A0 recent years and a routing = solution addressing the specific
=A0=A0 environments of such = networks is highly required considering the
=A0=A0 numerous, incompatible = open-source and proprietary routing protocols
=A0=A0 = as well as several industrial forums.=A0 The aim of this document is = to
=A0=A0 = define the routing requirements for Sensor Networks at the IP = layer.
=A0=A0 Such routing protocol(s) = would need to address several unique aspects
=A0=A0 = of this class of embedded devices and would operate in = networks
=A0=A0 comprising links of = various nature.


A URL = for this Internet-Draft is:

To remove yourself from the I-D Announcement list, = send a message to=A0
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of=A0
the = message.=A0
to = change your subscription settings.

Internet-Drafts are also = available by anonymous FTP. Login with the=A0
username = "anonymous" and a password of your e-mail address. After=A0
logging = in, type "cd internet-drafts" and then=A0
"get = draft-culler-rsn-routing-reqs-00.txt".

A list of = Internet-Drafts directories can be found in
Internet-Drafts can also be = obtained by e-mail.
Send a message to:
In the body type:
"FILE = /internet-drafts/draft-culler-rsn-routing-reqs-00.txt".

NOTE: The mail = server at ietf.org can return the document in
MIME-encoded form by using the = "mpack" utility.=A0 To use = this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 Different = MIME-compliant mail readers
exhibit = different behavior, especially when dealing with
"multipart" MIME messages (i.e. = documents which have been split
up into = multiple messages), so check your local documentation on
how to manipulate these = messages.

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically = retrieve the ASCII version of the
Content-Type: = text/plain

=

= --Apple-Mail-44-620390418-- --===============1578794781== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============1578794781==-- From rsn-bounces@ietf.org Mon Apr 16 03:16:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdLSG-0002QF-7D; Mon, 16 Apr 2007 03:16:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdLSE-0002Q5-KW for rsn@ietf.org; Mon, 16 Apr 2007 03:16:50 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdLSB-0003Ua-A9 for rsn@ietf.org; Mon, 16 Apr 2007 03:16:50 -0400 Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JGK00G24XJXMT@mailout3.samsung.com> for rsn@ietf.org; Mon, 16 Apr 2007 16:16:45 +0900 (KST) Received: from subbareddy ([107.108.72.143]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0JGK00K0PXJTKL@mmp1.samsung.com> for rsn@ietf.org; Mon, 16 Apr 2007 16:16:45 +0900 (KST) Date: Mon, 16 Apr 2007 12:51:56 +0530 From: Subba Reddy Subject: Re: [RSN] Fwd: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt To: JP Vasseur , rsn@ietf.org Message-id: <031401c77ff7$f580b110$8f486c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-Priority: 3 X-MSMail-priority: Normal References: <4E21EAEE-F7AC-4424-A157-BFEECBBA7761@cisco.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d9aaf4f837d0910b987cb9188300fdd Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0971705857==" Errors-To: rsn-bounces@ietf.org This is a multi-part message in MIME format. --===============0971705857== Content-type: multipart/alternative; boundary="Boundary_(ID_ChrEyHtxiTUAlmNwi9YmUQ)" This is a multi-part message in MIME format. --Boundary_(ID_ChrEyHtxiTUAlmNwi9YmUQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, Overall, the draft is good. Here are few questions / comments on the draft. 1. From Section 2.10 " Ultimately, scalability may benefit from the ability to perform computations for data reduction or fusion within the network, not just at the data processing sink level. The most common case being aggregation along a dynamically computed path to a sink. Thus the routing protocol SHOULD take points of aggregation (another node capability) into account when calculating routes." Does this mean, we can drop few packets (destined to sink) at aggregator and send the aggregated data to sink? I feel this is more related to application than routing. Please clarify. 2. Following may need to be considered while designing routing protocol. a. Node Failures - more common than other networks b. Increasing network lifetime c. Non real time nature of the data (in general) Here are few typos. >From section 1, 1. "Considering the variety of Sensor based applications, there may not be a single routing protocol satisfying the entire list of requirements, in which case it may be decided to define a limited set of routing protocols that could be combined to satify the overall ^^^^^^ objective." s/satify/satisfy 2. From section 2.10, "Date Aware routing" ^^^^^ s/Date/Data -Subba Reddy ----- Original Message ----- From: JP Vasseur To: rsn@ietf.org Sent: Saturday, April 14, 2007 1:58 AM Subject: [RSN] Fwd: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt Hi, Glad to see a good number of people who signed up to list already. Here is the first revision of the requirements ID. Feedbacks most welcome of course ! Thanks. JP and David. Begin forwarded message: From: Internet-Drafts@ietf.org Date: April 13, 2007 3:50:01 PM EDT To: i-d-announce@ietf.org Subject: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt Reply-To: internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Routing Requirements for Sensor Networks Author(s) : D. Cullerot, J. Vasseur Filename : draft-culler-rsn-routing-reqs-00.txt Pages : Date : 2007-4-13 The need for high quality routing for Sensor networks comprised of highly constrained devices (CPU, memory, ...) in sometimes unstable wireless environments is critical now and will continue to increase. Interest in this class of applications has grown dramatically in recent years and a routing solution addressing the specific environments of such networks is highly required considering the numerous, incompatible open-source and proprietary routing protocols as well as several industrial forums. The aim of this document is to define the routing requirements for Sensor Networks at the IP layer. Such routing protocol(s) would need to address several unique aspects of this class of embedded devices and would operate in networks comprising links of various nature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-culler-rsn-routing-reqs-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-culler-rsn-routing-reqs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-culler-rsn-routing-reqs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2007-4-13132741.I-D@ietf.org> _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------------------------------------------------------------------------------ _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --Boundary_(ID_ChrEyHtxiTUAlmNwi9YmUQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi,
 
Overall, the draft is good.
Here are few questions / comments on the draft.
 
1. From Section 2.10
 
"   Ultimately, scalability may benefit from the ability to perform
   computations for data reduction or fusion within the network, not
   just at the data processing sink level.  The most common case being
   aggregation along a dynamically computed path to a sink.  Thus the
   routing protocol SHOULD take points of aggregation (another node
   capability) into account when calculating routes."
 
Does this mean, we can drop few packets (destined to sink) at aggregator and send the aggregated data to sink?
I feel this is more related to application than routing.
Please clarify.
 
 
2. Following may need to be considered while designing routing protocol.
    a. Node Failures - more common than other networks
    b. Increasing network lifetime
    c. Non real time nature of the data (in general) 
 
 
Here are few typos.
 
From section 1,
 
1.   "Considering the variety of Sensor based applications, there may not
   be a single routing protocol satisfying the entire list of
   requirements, in which case it may be decided to define a limited set
   of routing protocols that could be combined to satify the overall
                                                                          ^^^^^^
   objective."
s/satify/satisfy
 
2. From section 2.10,
    "Date Aware routing"
      ^^^^^
 
s/Date/Data
 
 
-Subba Reddy

 
 
----- Original Message -----
From: JP Vasseur
Sent: Saturday, April 14, 2007 1:58 AM
Subject: [RSN] Fwd: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt

Hi,

Glad to see a good number of people who signed up to list already. Here is the first revision of the requirements ID. Feedbacks most welcome of course !

Thanks.

JP and David.

Begin forwarded message:

Date: April 13, 2007 3:50:01 PM EDT
Subject: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


Title : Routing Requirements for Sensor Networks
Author(s) : D. Cullerot, J. Vasseur
Filename : draft-culler-rsn-routing-reqs-00.txt
Pages : 
Date : 2007-4-13

   The need for high quality routing for Sensor networks comprised of
   highly constrained devices (CPU, memory, ...) in sometimes unstable
   wireless environments is critical now and will continue to increase.
   Interest in this class of applications has grown dramatically in
   recent years and a routing solution addressing the specific
   environments of such networks is highly required considering the
   numerous, incompatible open-source and proprietary routing protocols
   as well as several industrial forums.  The aim of this document is to
   define the routing requirements for Sensor Networks at the IP layer.
   Such routing protocol(s) would need to address several unique aspects
   of this class of embedded devices and would operate in networks
   comprising links of various nature.


A URL for this Internet-Draft is:

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-culler-rsn-routing-reqs-00.txt".

A list of Internet-Drafts directories can be found in

Internet-Drafts can also be obtained by e-mail.

Send a message to:
In the body type:
"FILE /internet-drafts/draft-culler-rsn-routing-reqs-00.txt".

NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility.  To use this
feature, insert the command "ENCODING mime" before the "FILE"
command.  To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader.  Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain

_______________________________________________
I-D-Announce mailing list

_______________________________________________
RSN mailing list
RSN@ietf.org
https://www1.ietf.org/mailman/listinfo/rsn
--Boundary_(ID_ChrEyHtxiTUAlmNwi9YmUQ)-- --===============0971705857== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============0971705857==-- From rsn-bounces@ietf.org Mon Apr 16 11:51:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTUf-0006a2-23; Mon, 16 Apr 2007 11:51:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTUe-0006Zx-3W for rsn@ietf.org; Mon, 16 Apr 2007 11:51:52 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdTUd-0000UJ-9W for rsn@ietf.org; Mon, 16 Apr 2007 11:51:52 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Apr 2007 17:51:51 +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 l3GFpogA028648 for ; Mon, 16 Apr 2007 17:51:50 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3GFpPm3023345 for ; Mon, 16 Apr 2007 15:51:50 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, 16 Apr 2007 17:51:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [RSN] Fwd: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt Date: Mon, 16 Apr 2007 17:51:43 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC03CA35D1@xmb-ams-337.emea.cisco.com> In-Reply-To: <4E21EAEE-F7AC-4424-A157-BFEECBBA7761@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] Fwd: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt Thread-Index: Acd+CkitAj/tMblUSvuRuopGWvOOFwCKjXZQ References: <4E21EAEE-F7AC-4424-A157-BFEECBBA7761@cisco.com> From: "Pascal Thubert \(pthubert\)" To: "Jean Philippe Vasseur \(jvasseur\)" X-OriginalArrivalTime: 16 Apr 2007 15:51:47.0682 (UTC) FILETIME=[23E47C20:01C7803F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10618; t=1176738710; x=1177602710; 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[RSN]=20Fwd=3A=20I-D=20ACTION=3Adraft-culler-rsn-rout ing-reqs-00.txt=20 |Sender:=20; bh=QwDH7l2iQwVV2t4SEaQjbrBHjXdtBgbFpTbSrP/BL1E=; b=qRXUhIb46aMwJKuuxtdRpWZF5et+EdDjF4UuViLi6wBkpCAvln3EnuAX0Ol5sSspYHSGDBEi YOZZzDxXDAQWT+Q727lnZccsSsdvlfylsdPG/rI6PixK53RZE4FCf19Z; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi JP: Congrats to the authors for this excellent 00 draft. It is already very = thorough and sheds some good light on how different the WSN approaches = need to be vs. traditional routing and MANET approaches. Now to the comments: High level: ----------- I believe you need a terminology: - In particular, you need to define what a "sink" is and which functions = you expect there - you also need to define what a "point of connectivity" is and how = that's different from a sink - same for data aggregation - finally, IMHO, it would be good to define RFD and FFD which are = implicit in the draft, and link that with battery problem and the = expected functional set (host, forwarder, router, aggregator). There are 2 assumptions in the text that could be discussed: - The need for multiple topologies. I do like the concept of MTR in that = space and agree it will be useful. But it is not mandatory as suggested = in section 2.9. For instance, you can achieve similar results with = multiple feasible successors in EIGRP, or with ants routing, link = reversal (TORA), etc... long as your routing protocol enables multiple = non-equal-cost routes in parallel you can get QoS enabled forwarding. - The need for A routing protocol that does everything you mention: In one hand, some of the operations you describe are forwarding = operation and could be done outside of routing, provided that the = routing proposes either multiple feasible successors or multiple = topologies.=20 ITOH, considering the broad range of applications (radio types, battery = vs. power source, device size, etc...) we might not need A routing = protocol that does it all but maybe a more generic framework that = interoperates at a basic level but can be extended with specific options = and protocol values for the various cases that you describe, and the = ones which will come in the future. - The fact that the requirements are unique to sensors can also be = discussed. Taken individually, that might not be true. For instance = you'll find UHF radios in places with very scare bandwidth, and radios = carried by soldiers and firemen with similar constraints but a different = trade off in range vs. battery life. I'd hope that whatever comes out of = this work is not limited to sensors but can also be applied / extended = to other types of mesh networking applications. Details : --------- Page 3. Title 2. - I believe that some text would be good to position WSN that is covered = by the document vs. mesh and PAN (that are not?). Note that per its new = charter, NEMO is actually gathering requirements for PANs, and there's = still no official WG for mesh and sensors. Page 4, section 2.4 - First sentence is a bit hard to read, could you rephrase? - I'm not convinced that routing is the key to power management. It is = true some protocols merge the control of the routing (decide who are the = next hops) and the forwarding (decide which next hop and when to = transmit for a given packet). But it might be much more economical to = separate the routing and the forwarding protocols in order to get a = simpler and more generic routing plane; you could then add a more = specific forwarding protocol when needed, in order to change only the = forwarding behavior as some conditions change (link load, link = interference, path load, you name it) which do not require to establish = new routes. An example of what we can not do in WSN is using SPF with = dynamic metrics, because it computes a single path to the sink and has = to re-compute it all when things change, that is all the time. OTOH, a = DV or a greedy approach give you multiple next hops in a general = Directed Acyclic Graph towards the sink, and circulating metrics in a = forwarding protocol is a sufficient and more to the point to enable the = next hop selection in the forwarding plane. - last sentence about " the devices have their network link off most of = the time." This is a very interesting point and it might deserve a bit = more text; maybe a little discussion on FFD vs. RFD. And the related = expectation in the routing, forwarding and data aggregation functions = that you would place in those boxes; also, please note that in the = military, being able to operate in stealth (send nothing unless = absolutely necessary) mode is a critical feature. =20 Page 5, section 2.5 Again comes the FFD / RFD discussion. Considering the wide variety of = cases within sensors itself I can hardly believe that one protocol / one = algorithm / one set of metrics fits it all. Back to the 2nd assumption = I discussed at the beginning of this mail, we have to propose something = that guarantees interoperability and loopless routing, but we need to = ensure some liberty for case specific routing decisions, based on = specific extension options (for instance radio dependent metrics, L3 = data that might influence policies, etc), and timing.=20 Page 5, section 2.5 "and detection of a point of connectivity". Apart from the missing dot = :) and that you really need to define not only what this is (a wire = access or any router that can relay including a wireless sensor?), this = sentence implies that there is a need for the protocol to discover that = "point of connectivity". In many cases that you describe in 2.7, a = logical topology that is defined by this sink is sufficient for the = basic needs of the WSN, and that deserves some words either in 2.5 or = maybe in 2.8. Page 6, section 2.8 Another interesting aspect of mobile mesh and WSN is that there might = not be a global topology for the routing to converge, just because too = many things move for the control plane to cope with over the limited = resources.=20 As a result, SPF-type convergence is a non-goal. In such an environment = you can expect at best to reach most peers at most times. A consequence = is that if there are peers that are more equals than the others (the = sinks for instance), you should be able to maintain the associated = path(s) back and forth before you consider maintaining other, less = important routes (Back to the discussion on 2.5). Page 7, section 2.10 (you mean data aware, right? - note: we can do both = :) The "point of aggregation" is another good topic that illustrates that = the routing protocol that we want will need the capability to support = extensions for case specific and even proprietary algorithms from day 1. = Some deployments will have aggregations and some will not. Some nodes = will support the aggregation options, and some will not. It all needs to = work and interoperate regardless of the specific options and option = derived algorithms that nodes in the network actually support. Thanks again to the authors for this excellent work. Pascal ________________________________________ From: Jean Philippe Vasseur (jvasseur)=20 Sent: Friday, April 13, 2007 10:28 PM To: rsn@ietf.org Subject: [RSN] Fwd: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt=20 Hi, Glad to see a good number of people who signed up to list already. Here = is the first revision of the requirements ID. Feedbacks most welcome of = course ! Thanks. JP and David. Begin forwarded message: From: Internet-Drafts@ietf.org Date: April 13, 2007 3:50:01 PM EDT To: i-d-announce@ietf.org Subject: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt=A0 Reply-To: internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts=A0 directories. Title : Routing Requirements for Sensor Networks Author(s) : D. Cullerot, J. Vasseur Filename : draft-culler-rsn-routing-reqs-00.txt Pages :=A0 Date : 2007-4-13 =09 =A0=A0 The need for high quality routing for Sensor networks comprised = of =A0=A0 highly constrained devices (CPU, memory, ...) in sometimes = unstable =A0=A0 wireless environments is critical now and will continue to = increase. =A0=A0 Interest in this class of applications has grown dramatically in =A0=A0 recent years and a routing solution addressing the specific =A0=A0 environments of such networks is highly required considering the =A0=A0 numerous, incompatible open-source and proprietary routing = protocols =A0=A0 as well as several industrial forums.=A0 The aim of this document = is to =A0=A0 define the routing requirements for Sensor Networks at the IP = layer. =A0=A0 Such routing protocol(s) would need to address several unique = aspects =A0=A0 of this class of embedded devices and would operate in networks =A0=A0 comprising links of various nature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-culler-rsn-routing-reqs-00.txt To remove yourself from the I-D Announcement list, send a message to=A0 i-d-announce-request@ietf.org with the word unsubscribe in the body = of=A0 the message.=A0 You can also visit = https://www1.ietf.org/mailman/listinfo/I-D-announce=A0 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=A0 username "anonymous" and a password of your e-mail address. After=A0 logging in, type "cd internet-drafts" and then=A0 "get draft-culler-rsn-routing-reqs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=A0 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-culler-rsn-routing-reqs-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility.=A0 To use this feature, insert the command "ENCODING mime" before the "FILE" command.=A0 To decode the response(s), you will need "munpack" or a MIME-compliant mail reader.=A0 Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2007-4-13132741.I-D@ietf.org> _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Mon Apr 16 16:53:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdYCA-0001XP-Qe; Mon, 16 Apr 2007 16:53:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdYCA-0001XK-7h for rsn@ietf.org; Mon, 16 Apr 2007 16:53:06 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdYC9-0001kK-3m for rsn@ietf.org; Mon, 16 Apr 2007 16:53:06 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 16 Apr 2007 16:53:06 -0400 X-IronPort-AV: i="4.14,415,1170651600"; d="scan'208,217"; a="57794629:sNHT182933728" 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 l3GKr4Eg013686; Mon, 16 Apr 2007 16:53:04 -0400 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 l3GKqiHH016984; Mon, 16 Apr 2007 20:53:04 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 16:52:57 -0400 Received: from [10.86.104.181] ([10.86.104.181]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 16:52:55 -0400 In-Reply-To: <031401c77ff7$f580b110$8f486c6b@sisodomain.com> References: <4E21EAEE-F7AC-4424-A157-BFEECBBA7761@cisco.com> <031401c77ff7$f580b110$8f486c6b@sisodomain.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Message-Id: <7653E875-570E-4B1E-A54F-8297D99A16E3@cisco.com> From: JP Vasseur Subject: Re: [RSN] Fwd: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt Date: Mon, 16 Apr 2007 16:52:53 -0400 To: rsn@ietf.org, Subba Reddy X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 16 Apr 2007 20:52:55.0993 (UTC) FILETIME=[3571F290:01C78069] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=47200; t=1176756784; x=1177620784; 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[RSN]=20Fwd=3A=20I-D=20ACTION=3Adraft-culler-rsn-rout ing-reqs-00.txt |Sender:=20 |To:=20rsn@ietf.org,=20Subba=20Reddy=20; bh=LzsS25Jmu/YcrMINkqO3q1du0aid/IC1oJi6r8ZGFm4=; b=lXdiWKZB6nN/g1y6BkWP0ekBpoIEZjDnso37qFYNpQtFzPMcqlmvRzp1YlHZnTF3BvBibCBq HRPRSJ+9AICla1BvaCMo1waKGCypAV4V1p5nok3FIBOhYWDqnJSzXKlp; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 6e5958278d089090169a903f246b3f39 Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0625913264==" Errors-To: rsn-bounces@ietf.org --===============0625913264== Content-Type: multipart/alternative; boundary=Apple-Mail-77-881078264 --Apple-Mail-77-881078264 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Subba, Thanks for your comments - see in line, On Apr 16, 2007, at 3:21 AM, Subba Reddy wrote: > Hi, > > Overall, the draft is good. > Here are few questions / comments on the draft. > > 1. From Section 2.10 > > " Ultimately, scalability may benefit from the ability to perform > computations for data reduction or fusion within the network, not > just at the data processing sink level. The most common case being > aggregation along a dynamically computed path to a sink. Thus the > routing protocol SHOULD take points of aggregation (another node > capability) into account when calculating routes." > > Does this mean, we can drop few packets (destined to sink) at > aggregator and send the aggregated data to sink? > I feel this is more related to application than routing. > Please clarify. The intention here is to indicate that when fusion is used, it may be beneficial to compute a path to the sink while taking into account the capability of some nodes to perform data fusion. Although this is indeed an application-level capability of the node, we may need a routing protocol that favors the use of such path, which is a pretty unique requirement of Sensor Networks. Such capability should be learned by the computing node thanks to the routing protocol itself. Note that such function is also performed in other routing contexts: for example, when a router computes a Point to Multipoint Label Switched Path, the ability of some nodes to perform traffic replication can be learned via the routing protocol to compute the path. Does that clarify ? > > > 2. Following may need to be considered while designing routing > protocol. > a. Node Failures - more common than other networks > b. Increasing network lifetime > c. Non real time nature of the data (in general) > Fully agree. We surely need to specify that node failures are generally more common in WSNs, which may or may not have an impact on the routing protocol. Very likely the impact will be on the rerouting times: indeed, it is quite well-known that fast rerouting times is more challenging in case of node failures than link failures. Note sure what you mean by b. ? As far as c. is concerned, this is an interesting topic of discussion. For the time being, you're absolutely right. But since we'll need to design a routing protocol for the next few years, what will be the requirements of future Sensor Nets applications ? Think of industrial alarms to report critical states or healthcare applications ... Thoughts ? > > Here are few typos. > > From section 1, > > 1. "Considering the variety of Sensor based applications, there > may not > be a single routing protocol satisfying the entire list of > requirements, in which case it may be decided to define a > limited set > of routing protocols that could be combined to satify the overall > > ^^^^^^ > objective." > s/satify/satisfy > > 2. From section 2.10, > "Date Aware routing" > ^^^^^ > > s/Date/Data > Thanks. We'll fix them. JP. > > > -Subba Reddy > > > > ----- Original Message ----- > From: JP Vasseur > To: rsn@ietf.org > Sent: Saturday, April 14, 2007 1:58 AM > Subject: [RSN] Fwd: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt > > Hi, > > Glad to see a good number of people who signed up to list already. > Here is the first revision of the requirements ID. Feedbacks most > welcome of course ! > > Thanks. > > JP and David. > > Begin forwarded message: > >> From: Internet-Drafts@ietf.org >> Date: April 13, 2007 3:50:01 PM EDT >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt >> Reply-To: internet-drafts@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Routing Requirements for Sensor Networks >> Author(s) : D. Cullerot, J. Vasseur >> Filename : draft-culler-rsn-routing-reqs-00.txt >> Pages : >> Date : 2007-4-13 >> >> The need for high quality routing for Sensor networks comprised of >> highly constrained devices (CPU, memory, ...) in sometimes >> unstable >> wireless environments is critical now and will continue to >> increase. >> Interest in this class of applications has grown dramatically in >> recent years and a routing solution addressing the specific >> environments of such networks is highly required considering the >> numerous, incompatible open-source and proprietary routing >> protocols >> as well as several industrial forums. The aim of this document >> is to >> define the routing requirements for Sensor Networks at the IP >> layer. >> Such routing protocol(s) would need to address several unique >> aspects >> of this class of embedded devices and would operate in networks >> comprising links of various nature. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-culler-rsn-routing- >> reqs-00.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the >> body of >> the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- >> announce >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then >> "get draft-culler-rsn-routing-reqs-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-culler-rsn-routing-reqs-00.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> Content-Type: text/plain >> Content-ID: <2007-4-13132741.I-D@ietf.org> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn > --Apple-Mail-77-881078264 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Subba,

Thanks for your comments - = see in line,

On Apr 16, 2007, at 3:21 AM, Subba = Reddy wrote:

=A0
Here are few questions / comments on the = draft.
=A0
=A0
=A0=A0 Ultimately, scalability may benefit from the ability to = perform
=A0=A0= computations for data reduction or fusion within the network, = not
=A0=A0= just at the data processing sink level.=A0 The most common case = being
=A0=A0= aggregation along a dynamically computed path to a sink.=A0 Thus = the
=A0=A0= routing protocol SHOULD take points of aggregation (another = node
=A0=A0= capability) into account when calculating routes
=A0
Please = clarify.

The intention here is to = indicate that when fusion is used, it may be beneficial to compute a = path to the
sink while taking into account the capability of = some nodes to perform data fusion. Although this is indeed
an = application-level capability of the node, we may need a routing protocol = that favors the use of such path,
which is a pretty unique = requirement of Sensor Networks. Such capability should be learned by the = computing
node thanks to the routing protocol = itself.=A0

Note= that such function is also performed in other routing contexts:=A0for = example, when a router computes a Point to Multipoint Label Switched = Path, the ability of some nodes to=A0perform traffic replication can be = learned via the routing protocol to compute the path.

Does that clarify = ?

=A0
=A0
=A0=A0=A0 c.=A0Non real = time nature of the data=A0(in general)=A0
=A0

Fully agree.=A0
We surely need to specify = that node failures are generally more common in WSNs, which may or may = not have
an impact on the routing protocol. Very likely the = impact will be on the rerouting times: indeed, it is quite = well-known
that fast rerouting times is more challenging in = case of node failures than link failures.

Note sure what you mean by = b. ?

As far = as c. is concerned, this is an interesting topic of discussion. For the = time being, you're absolutely right.=A0
But since we'll need = to design a routing protocol for the next few years, what will be the = requirements of future Sensor Nets applications ? Think of industrial = alarms to report critical states or healthcare applications = ...

Thoughts = ?

=A0
Here are few typos.
=A0
=46rom section 1,
=A0
1.=A0=A0 "Considering the = variety of Sensor based applications, there may not
=A0=A0 be a = single routing protocol satisfying the entire list of
=A0=A0 = requirements, in which case it may be decided to define a limited = set
=A0=A0 of routing protocols that could be combined to satify the = overall
=A0
=A0=A0=A0 "Date Aware routing
=A0


Thanks. We'll fix = them.

JP.

=A0

=A0
=A0
----- Original = Message -----
To:

Hi,



JP and = David.

Begin forwarded message:

Date: = April 13, 2007 3:50:01 PM = EDT
Subject: = I-D = ACTION:draft-culler-rsn-routing-reqs-00.txtinternet-drafts@ietf.org

A New Internet-Draft is available from the on-line = Internet-Drafts

: Routing Requirements for Sensor Networks
Author(s) : D. Cullerot, J. Vasseur
Filename : = draft-culler-rsn-routing-reqs-00.txt
:Date : 2007-4-13

=A0=A0 The need = for high quality routing for Sensor networks comprised = of
=A0=A0 highly = constrained devices (CPU, memory, ...) in sometimes = unstable
=A0=A0 wireless = environments is critical now and will continue to = increase.
=A0=A0 Interest in = this class of applications has grown dramatically in
=A0=A0 recent = years and a routing solution addressing the specific
=A0=A0 =A0=A0 numerous, = incompatible open-source and proprietary routing = protocols
=A0=A0 as well as = several industrial forums.=A0 The aim of = this document is to
=A0=A0 = define the routing requirements for Sensor Networks at the IP = layer.
=A0=A0 Such = routing protocol(s) would need to address several unique = aspects
=A0=A0 of this = class of embedded devices and would operate in networks
=A0=A0 comprising = links of various nature.


A URL for = this Internet-Draft is:



or =





__________________________________= _____________
RSN mailing list
RSN@ietf.org
https://www1.ietf.org/mai= lman/listinfo/rsn


= --Apple-Mail-77-881078264-- --===============0625913264== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============0625913264==-- From rsn-bounces@ietf.org Tue Apr 17 03:40:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdiIX-0003jf-D9; Tue, 17 Apr 2007 03:40:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdiIW-0003ja-RF for rsn@ietf.org; Tue, 17 Apr 2007 03:40:20 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdiIV-0006Pk-V8 for rsn@ietf.org; Tue, 17 Apr 2007 03:40:20 -0400 Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JGM00940TAD3I@mailout1.samsung.com> for rsn@ietf.org; Tue, 17 Apr 2007 16:39:49 +0900 (KST) Received: from subbareddy ([107.108.72.143]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0JGM00NP7TAA2X@mmp1.samsung.com> for rsn@ietf.org; Tue, 17 Apr 2007 16:39:49 +0900 (KST) Date: Tue, 17 Apr 2007 13:15:06 +0530 From: Subba Reddy Subject: Re: [RSN] Fwd: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt To: JP Vasseur , rsn@ietf.org Message-id: <04db01c780c4$5227bdb0$8f486c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-Priority: 3 X-MSMail-priority: Normal References: <4E21EAEE-F7AC-4424-A157-BFEECBBA7761@cisco.com> <031401c77ff7$f580b110$8f486c6b@sisodomain.com> <7653E875-570E-4B1E-A54F-8297D99A16E3@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0035856034==" Errors-To: rsn-bounces@ietf.org This is a multi-part message in MIME format. --===============0035856034== Content-type: multipart/alternative; boundary="Boundary_(ID_QKj+9lkiBteKiLWkrecdNw)" This is a multi-part message in MIME format. --Boundary_(ID_QKj+9lkiBteKiLWkrecdNw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi JP, Please see my inline comments starting with sr>> 1. From Section 2.10 " Ultimately, scalability may benefit from the ability to perform computations for data reduction or fusion within the network, not just at the data processing sink level. The most common case being aggregation along a dynamically computed path to a sink. Thus the routing protocol SHOULD take points of aggregation (another node capability) into account when calculating routes." Does this mean, we can drop few packets (destined to sink) at aggregator and send the aggregated data to sink? I feel this is more related to application than routing. Please clarify. The intention here is to indicate that when fusion is used, it may be beneficial to compute a path to the sink while taking into account the capability of some nodes to perform data fusion. Although this is indeed an application-level capability of the node, we may need a routing protocol that favors the use of such path, which is a pretty unique requirement of Sensor Networks. Such capability should be learned by the computing node thanks to the routing protocol itself. Note that such function is also performed in other routing contexts: for example, when a router computes a Point to Multipoint Label Switched Path, the ability of some nodes to perform traffic replication can be learned via the routing protocol to compute the path. Does that clarify ? sr>> Thanks for the clarification. 2. Following may need to be considered while designing routing protocol. a. Node Failures - more common than other networks b. Increasing network lifetime c. Non real time nature of the data (in general) Fully agree. We surely need to specify that node failures are generally more common in WSNs, which may or may not have an impact on the routing protocol. Very likely the impact will be on the rerouting times: indeed, it is quite well-known that fast rerouting times is more challenging in case of node failures than link failures. Note sure what you mean by b. ? sr>> Some of the sensor nodes may be selected in most of the forwarding paths (may be beacuse of their position in the network). This can exhaust the energy of those nodes and thereby disconnecting the network. As far as c. is concerned, this is an interesting topic of discussion. For the time being, you're absolutely right. But since we'll need to design a routing protocol for the next few years, what will be the requirements of future Sensor Nets applications ? Think of industrial alarms to report critical states or healthcare applications ... Thoughts ? sr>> I agree that the data can be of real time nature. Can we have some optimizations (may be interms of configurations or options) in saving the energy for non-real time applications? -Subba Reddy --Boundary_(ID_QKj+9lkiBteKiLWkrecdNw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi JP,
 
    Please see my inline comments starting with sr>>
1. From Section 2.10
 
"   Ultimately, scalability may benefit from the ability to perform
   computations for data reduction or fusion within the network, not
   just at the data processing sink level.  The most common case being
   aggregation along a dynamically computed path to a sink.  Thus the
   routing protocol SHOULD take points of aggregation (another node
   capability) into account when calculating routes."
 
Does this mean, we can drop few packets (destined to sink) at aggregator and send the aggregated data to sink?
I feel this is more related to application than routing.
Please clarify.

The intention here is to indicate that when fusion is used, it may be beneficial to compute a path to the
sink while taking into account the capability of some nodes to perform data fusion. Although this is indeed
an application-level capability of the node, we may need a routing protocol that favors the use of such path,
which is a pretty unique requirement of Sensor Networks. Such capability should be learned by the computing
node thanks to the routing protocol itself. 

Note that such function is also performed in other routing contexts: for example, when a router computes a Point to Multipoint Label Switched Path, the ability of some nodes to perform traffic replication can be learned via the routing protocol to compute the path.

Does that clarify ?
 
 
sr>> Thanks for the clarification.

 
 
2. Following may need to be considered while designing routing protocol.
    a. Node Failures - more common than other networks
    b. Increasing network lifetime
    c. Non real time nature of the data (in general) 
 

Fully agree. 

We surely need to specify that node failures are generally more common in WSNs, which may or may not have
an impact on the routing protocol. Very likely the impact will be on the rerouting times: indeed, it is quite well-known
that fast rerouting times is more challenging in case of node failures than link failures.

Note sure what you mean by b. ?
 
sr>> Some of the sensor nodes may be selected in most of the forwarding paths (may be beacuse of their
position in the network).  This can exhaust the energy of those nodes and thereby disconnecting the network. 

As far as c. is concerned, this is an interesting topic of discussion. For the time being, you're absolutely right. 
But since we'll need to design a routing protocol for the next few years, what will be the requirements of future Sensor Nets applications ? Think of industrial alarms to report critical states or healthcare applications ...

Thoughts ?
 
 
sr>> I agree that the data can be of real time nature. Can we have some optimizations (may be interms of configurations or options) in saving the energy for non-real time applications?
 
-Subba Reddy
--Boundary_(ID_QKj+9lkiBteKiLWkrecdNw)-- --===============0035856034== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============0035856034==-- From rsn-bounces@ietf.org Tue Apr 17 08:34:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdmt3-0005y3-Tn; Tue, 17 Apr 2007 08:34:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdmt2-0005xv-TU for rsn@ietf.org; Tue, 17 Apr 2007 08:34:20 -0400 Received: from relay2.ptmail.sapo.pt ([212.55.154.22] helo=sapo.pt) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hdmt0-0003Wf-10 for rsn@ietf.org; Tue, 17 Apr 2007 08:34:20 -0400 Received: (qmail 11913 invoked from network); 17 Apr 2007 12:34:15 -0000 Received: from unknown (HELO sapo.pt) (10.134.35.209) by relay2 with SMTP; 17 Apr 2007 12:34:15 -0000 Received: (qmail 22390 invoked from network); 17 Apr 2007 12:34:15 -0000 X-AntiVirus: PTMail-AV 0.3-0.90.1 X-Virus-Status: Clean (0.00055 seconds) Received: from unknown (HELO [192.168.1.10]) (tandre@sapo.pt@[85.240.138.107]) (envelope-sender ) by mta14 (qmail-ldap-1.03) with SMTP for ; 17 Apr 2007 12:34:15 -0000 Message-ID: <4624BEDF.2010500@dei.uc.pt> Date: Tue, 17 Apr 2007 13:34:39 +0100 From: Tiago Camilo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: JP Vasseur Subject: Re: [RSN] Fwd: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt References: <4E21EAEE-F7AC-4424-A157-BFEECBBA7761@cisco.com> In-Reply-To: <4E21EAEE-F7AC-4424-A157-BFEECBBA7761@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi, Glad to see WSN standard work in IETF. I agree with Pascal comment regarding the terminology. I think that a terminology section helps to clarify some points in the ID. Terms such as sink, RFD and FFD are very common in WSN routing protocols, and should be IMO defined and used in the text. I think that is important in the introduction when you write about "Considering the variety of Sensor based applications" to refer that in WSNs, the routing protocol is somehow restricted by the application, meaning it is the application that defines if the protocol is time-driven, event-driven or hybrid. In section 2.7, I believe that is important to say that differently from MANETs, WSNs communications are normally not made between monitoring sensors, meaning sensors normally communicate in point-to-point fashion only with the sink and not with others monitoring sensors (i.e. RFD), except in forwarding operations. In section 2.9. I do not understand why the phrase "MUST support multi-topology routing in one form or another with different degrees of route optimization" is under the QoS topic. Moreover I suggest to change the keyword MUST to SHOULD, since in some applications scenarios, such support is not a requirement, i.e. habitat monitoring. Apart from QoS I feel that is necessary to say something about Security, which nowadays is a hot topic in WSNs. There are several ways to attack a WSN, and some use the routing protocol leaks to perform DoS attacks, data hijacking, introduce radio noise, etc. Therefore I think its necessary to say that at least security aspects SHOULD be made. It is important in section 2.10 to enhance that is more energy-efficient to process data locally then forward it, thats the main reason for data aggregation. Regards, Tiago Camilo University of Coimbra JP Vasseur wrote: > Hi, > > Glad to see a good number of people who signed up to list already. > Here is the first revision of the requirements ID. Feedbacks most > welcome of course ! > > Thanks. > > JP and David. > > Begin forwarded message: > >> *From: *Internet-Drafts@ietf.org >> *Date: *April 13, 2007 3:50:01 PM EDT >> *To: *i-d-announce@ietf.org >> *Subject: **I-D ACTION:draft-culler-rsn-routing-reqs-00.txt * >> *Reply-To: *internet-drafts@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Routing Requirements for Sensor Networks >> Author(s) : D. Cullerot, J. Vasseur >> Filename : draft-culler-rsn-routing-reqs-00.txt >> Pages : >> Date : 2007-4-13 >> >> The need for high quality routing for Sensor networks comprised of >> highly constrained devices (CPU, memory, ...) in sometimes unstable >> wireless environments is critical now and will continue to increase. >> Interest in this class of applications has grown dramatically in >> recent years and a routing solution addressing the specific >> environments of such networks is highly required considering the >> numerous, incompatible open-source and proprietary routing protocols >> as well as several industrial forums. The aim of this document is to >> define the routing requirements for Sensor Networks at the IP layer. >> Such routing protocol(s) would need to address several unique aspects >> of this class of embedded devices and would operate in networks >> comprising links of various nature. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-culler-rsn-routing-reqs-00.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org >> with the word unsubscribe in the body of >> the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then >> "get draft-culler-rsn-routing-reqs-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org . >> In the body type: >> "FILE /internet-drafts/draft-culler-rsn-routing-reqs-00.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> Content-Type: text/plain >> Content-ID: <2007-4-13132741.I-D@ietf.org >> > >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce > > ------------------------------------------------------------------------ > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn > _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue Apr 17 12:43:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdqmB-0006uU-4o; Tue, 17 Apr 2007 12:43:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdqmA-0006uO-9T for rsn@ietf.org; Tue, 17 Apr 2007 12:43:30 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdqm9-0005aJ-Iw for rsn@ietf.org; Tue, 17 Apr 2007 12:43:30 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 17 Apr 2007 12:43:29 -0400 X-IronPort-AV: i="4.14,419,1170651600"; d="scan'208,217"; a="118745419:sNHT119727520" 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 l3HGhTFd011343; Tue, 17 Apr 2007 12:43:29 -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.12.10/8.12.6) with ESMTP id l3HGhNlU002776; Tue, 17 Apr 2007 16:43:28 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 12:43:27 -0400 Received: from [64.102.165.14] ([10.82.217.62]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 12:43:27 -0400 In-Reply-To: <04db01c780c4$5227bdb0$8f486c6b@sisodomain.com> References: <4E21EAEE-F7AC-4424-A157-BFEECBBA7761@cisco.com> <031401c77ff7$f580b110$8f486c6b@sisodomain.com> <7653E875-570E-4B1E-A54F-8297D99A16E3@cisco.com> <04db01c780c4$5227bdb0$8f486c6b@sisodomain.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Message-Id: <5307510E-39A4-4555-95EC-DBC36ACD3AF3@cisco.com> From: JP Vasseur Subject: Re: [RSN] Fwd: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt Date: Tue, 17 Apr 2007 12:43:24 -0400 To: Subba Reddy X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Apr 2007 16:43:27.0056 (UTC) FILETIME=[85AD2D00:01C7810F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=20702; t=1176828209; x=1177692209; 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[RSN]=20Fwd=3A=20I-D=20ACTION=3Adraft-culler-rsn-rout ing-reqs-00.txt |Sender:=20 |To:=20Subba=20Reddy=20; bh=Qj2uDZ2N3zivXhPftmM9weImDvXimkT2m6Qjz+jKo2o=; b=UPjctOoZ66AqZdCOuPAZecEb1JJxnOXVgQAURHg35T1XqI3uY6IPwWuA+g4pNYGfpc7NGvhk S3INRgJOcZlKLtzqbS1XgAbDmCEYVfnqWMdv7PYwPr4FcAn6usjO5df2; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1691748667==" Errors-To: rsn-bounces@ietf.org --===============1691748667== Content-Type: multipart/alternative; boundary=Apple-Mail-86-952509004 --Apple-Mail-86-952509004 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Subba, On Apr 17, 2007, at 3:45 AM, Subba Reddy wrote: > Hi JP, > > Please see my inline comments starting with sr>> > 1. From Section 2.10 >> >> " Ultimately, scalability may benefit from the ability to perform >> computations for data reduction or fusion within the network, not >> just at the data processing sink level. The most common case >> being >> aggregation along a dynamically computed path to a sink. Thus the >> routing protocol SHOULD take points of aggregation (another node >> capability) into account when calculating routes." >> >> Does this mean, we can drop few packets (destined to sink) at >> aggregator and send the aggregated data to sink? >> I feel this is more related to application than routing. >> Please clarify. > > The intention here is to indicate that when fusion is used, it may > be beneficial to compute a path to the > sink while taking into account the capability of some nodes to > perform data fusion. Although this is indeed > an application-level capability of the node, we may need a routing > protocol that favors the use of such path, > which is a pretty unique requirement of Sensor Networks. Such > capability should be learned by the computing > node thanks to the routing protocol itself. > > Note that such function is also performed in other routing > contexts: for example, when a router computes a Point to Multipoint > Label Switched Path, the ability of some nodes to perform traffic > replication can be learned via the routing protocol to compute the > path. > > Does that clarify ? > > > sr>> Thanks for the clarification. > >> >> >> 2. Following may need to be considered while designing routing >> protocol. >> a. Node Failures - more common than other networks >> b. Increasing network lifetime >> c. Non real time nature of the data (in general) >> > > Fully agree. > > We surely need to specify that node failures are generally more > common in WSNs, which may or may not have > an impact on the routing protocol. Very likely the impact will be > on the rerouting times: indeed, it is quite well-known > that fast rerouting times is more challenging in case of node > failures than link failures. > > Note sure what you mean by b. ? > > sr>> Some of the sensor nodes may be selected in most of the > forwarding paths (may be beacuse of their > position in the network). This can exhaust the energy of those > nodes and thereby disconnecting the network. Dynamic node states should be taken into account by the routing protocols, the level of energy available per node being one possible constraints considering during route computation. > As far as c. is concerned, this is an interesting topic of > discussion. For the time being, you're absolutely right. > But since we'll need to design a routing protocol for the next few > years, what will be the requirements of future Sensor Nets > applications ? Think of industrial alarms to report critical states > or healthcare applications ... > > Thoughts ? > > > sr>> I agree that the data can be of real time nature. Can we have > some optimizations (may be interms of configurations or options) in > saving the energy for non-real time applications? > Yes definitely, thus the need for MTR (Multi-topology Routing) expressed in section 2.9; note that the text must still require some work of course. Thanks. JP. > -Subba Reddy > --Apple-Mail-86-952509004 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Subba,

On = Apr 17, 2007, at 3:45 AM, Subba Reddy wrote:

Hi JP,
=A0
=A0=A0=A0 = Please see my inline comments starting with = sr>>
1. =46rom Section = 2.10
=A0
"=A0=A0 Ultimately, scalability may benefit from the ability = to perform
=A0=A0 computations for data reduction or fusion = within the network, not
=A0=A0 just at the data processing sink level.=A0 The = most common case being
=A0=A0 aggregation along a dynamically computed path = to a sink.=A0 Thus the
=A0=A0 routing protocol SHOULD take points of = aggregation (another node
=A0=A0 capability) into account when calculating = routes."
Does this mean, we can drop few packets = (destined to sink) at aggregator and send the aggregated data to = sink?
I feel this is more related to application = than routing.
Please = clarify.

The intention here is to = indicate that when fusion is used, it may be beneficial to compute a = path to the
sink while taking into account the capability of = some nodes to perform data fusion. Although this is indeed
an = application-level capability of the node, we may need a routing protocol = that favors the use of such path,
which is a pretty unique = requirement of Sensor Networks. Such capability should be learned by the = computing
node thanks to the routing protocol = itself.=A0

Note that such function is = also performed in other routing contexts:=A0for example, when a router = computes a Point to Multipoint Label Switched Path, the ability of some = nodes to=A0perform traffic replication can be learned via the routing = protocol to compute the path.

Does = that clarify ?
=A0
=A0
sr>> = Thanks for the clarification.

=A0
=A0
2. Following may need to be considered while = designing routing protocol.
=A0=A0=A0 b. Increasing network = lifetime
=A0=A0=A0 c.=A0Non real time nature of the = data=A0(in general)=A0
=A0

Fully = agree.=A0

We surely need to specify = that node failures are generally more common in WSNs, which may or may = not have
an impact on the routing protocol. Very likely the = impact will be on the rerouting times: indeed, it is quite = well-known
that fast rerouting times is more challenging in = case of node failures than link failures.

Note sure what you mean by = b. ?
=A0
sr>> = Some of the sensor nodes may be=A0selected in most of the forwarding = paths (may be beacuse of their
position in the network).=A0 This can exhaust the energy of = those nodes and thereby disconnecting the network.=A0
Dynamic node states should be = taken into account by the routing protocols, the level of energy = available per node being one possible constraints considering during = route computation.
As far as c. is concerned, this is an interesting = topic of discussion. For the time being, you're absolutely = right.=A0
But since we'll need to design a routing protocol = for the next few years, what will be the requirements of future Sensor = Nets applications ? Think of industrial alarms to report critical states = or healthcare applications ...

Thoughts ?
=A0
=A0
sr>> I = agree that the data can be of real time nature. Can we have some = optimizations (may be interms of configurations or options) in saving = the energy for non-real time applications?
=A0
Yes = definitely, thus the need for MTR (Multi-topology Routing) expressed in = section 2.9; note that the text must still require some work of = course.

Thanks.

JP.
-Subba Reddy


= --Apple-Mail-86-952509004-- --===============1691748667== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============1691748667==-- From rsn-bounces@ietf.org Tue Apr 17 13:01:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdr3O-0006F8-Ri; Tue, 17 Apr 2007 13:01:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdr3N-0006Eo-Fu for rsn@ietf.org; Tue, 17 Apr 2007 13:01:17 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdr3M-000535-PI for rsn@ietf.org; Tue, 17 Apr 2007 13:01:17 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 17 Apr 2007 10:01:16 -0700 X-IronPort-AV: i="4.14,419,1170662400"; d="scan'208"; a="412366405:sNHT61747692" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l3HH1Gia011666; Tue, 17 Apr 2007 10:01:16 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l3HH0rxJ028351; Tue, 17 Apr 2007 17:01:15 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 13:01:07 -0400 Received: from [64.102.165.14] ([10.82.217.62]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 13:01:06 -0400 In-Reply-To: <4624BEDF.2010500@dei.uc.pt> References: <4E21EAEE-F7AC-4424-A157-BFEECBBA7761@cisco.com> <4624BEDF.2010500@dei.uc.pt> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <926016FD-CC89-4235-BAD2-5102D9240A05@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [RSN] Fwd: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt Date: Tue, 17 Apr 2007 13:01:04 -0400 To: Tiago Camilo X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Apr 2007 17:01:06.0799 (UTC) FILETIME=[FD551FF0:01C78111] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7565; t=1176829276; x=1177693276; c=relaxed/simple; s=sjdkim8002; 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[RSN]=20Fwd=3A=20I-D=20ACTION=3Adraft-culler-rsn-rout ing-reqs-00.txt |Sender:=20; bh=5hcqlQgdTmxLQjO6T790wJa3/btbnnsCc9M8SkHQvBU=; b=s00o/9tayA3+J6DErRpyFJWIKKJZgM7t5M0DttaSyz0Fd3txN1/TbH8CFaZ0lWoRSAVBKE09 8E1VZH4mrkFcvJYArHoUOxRoUiewS1Dax7BUmgml1M6W1T8W7HR9fCMB; Authentication-Results: sj-dkim-8; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi, On Apr 17, 2007, at 8:34 AM, Tiago Camilo wrote: > Hi, > Glad to see WSN standard work in IETF. > Good, thanks for the support. > I agree with Pascal comment regarding the terminology. I think that > a terminology section helps to clarify some points in the ID. Terms > such as sink, RFD and FFD are very common in WSN routing protocols, > and should be IMO defined and used in the text. > Absolutely, this will be in the next revision for sure. > I think that is important in the introduction when you write about > "Considering the variety of Sensor based applications" to refer > that in WSNs, the routing protocol is somehow restricted by the > application, meaning it is the application that defines if the > protocol is time-driven, event-driven or hybrid. > I'm not sure that the routing protocol is "restricted" by the application. It may be somehow related to it, an example of which being data-aware routing. I agree with you that the applications dictates the requirements for the routing protocols but in that respect this does not differ from other routing protocols. For example, the convergence requirements for BGP, OSPF, ... have also been driven by the emergence of new applications. > In section 2.7, I believe that is important to say that differently > from MANETs, WSNs communications are normally not made between > monitoring sensors, meaning sensors normally communicate in point- > to-point fashion only with the sink and not with others > monitoring sensors (i.e. RFD), except in forwarding operations. Yes indeed, most traffic flows are MP2MP, although the routing protocol will have to support P2P since we start to see such traffic patterns in WSN as well. > > In section 2.9. I do not understand why the phrase "MUST support > multi-topology routing in one form or another with different > degrees of route optimization" is under the QoS topic. Moreover I > suggest to change the keyword MUST to SHOULD, since in some > applications scenarios, such support is not a requirement, i.e. > habitat monitoring. OK let me clarify something wrt MUST and SHOULD: in the requirement document, the MUST applies to the ability for the routing protocol to support MTR, which does not mean that MTR will be used in all environments. This is an important distinction. > > Apart from QoS I feel that is necessary to say something about > Security, which nowadays is a hot topic in WSNs. There are several > ways to attack a WSN, and some use the routing protocol leaks to > perform DoS attacks, data hijacking, introduce radio noise, etc. > Therefore I think its necessary to say that at least security > aspects SHOULD be made. 200% ... interesting that you mentioned this since we were about to send an email to the list looking for security experts to work on this KEY topic. I'll follow up on this. > > It is important in section 2.10 to enhance that is more energy- > efficient to process data locally then forward it, thats the main > reason for data aggregation. > Agree, although this is a bit of the scope of this ID (focussed on routing issues). Thanks. JP. > > Regards, > > Tiago Camilo > University of Coimbra > > > > JP Vasseur wrote: >> Hi, >> >> Glad to see a good number of people who signed up to list already. >> Here is the first revision of the requirements ID. Feedbacks most >> welcome of course ! >> >> Thanks. >> >> JP and David. >> >> Begin forwarded message: >> >>> *From: *Internet-Drafts@ietf.org >>> *Date: *April 13, 2007 3:50:01 PM EDT >>> *To: *i-d-announce@ietf.org >>> *Subject: **I-D ACTION:draft-culler-rsn-routing-reqs-00.txt * >>> *Reply-To: *internet-drafts@ietf.org >> drafts@ietf.org> >>> >>> A New Internet-Draft is available from the on-line Internet- >>> Drafts directories. >>> >>> >>> Title : Routing Requirements for Sensor Networks >>> Author(s) : D. Cullerot, J. Vasseur >>> Filename : draft-culler-rsn-routing-reqs-00.txt >>> Pages : Date : 2007-4-13 >>> >>> The need for high quality routing for Sensor networks >>> comprised of >>> highly constrained devices (CPU, memory, ...) in sometimes >>> unstable >>> wireless environments is critical now and will continue to >>> increase. >>> Interest in this class of applications has grown dramatically in >>> recent years and a routing solution addressing the specific >>> environments of such networks is highly required considering the >>> numerous, incompatible open-source and proprietary routing >>> protocols >>> as well as several industrial forums. The aim of this >>> document is to >>> define the routing requirements for Sensor Networks at the IP >>> layer. >>> Such routing protocol(s) would need to address several unique >>> aspects >>> of this class of embedded devices and would operate in networks >>> comprising links of various nature. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-culler-rsn-routing- >>> reqs-00.txt >>> >>> To remove yourself from the I-D Announcement list, send a message >>> to i-d-announce-request@ietf.org >> request@ietf.org> with the word unsubscribe in the body of the >>> message. You can also visit https://www1.ietf.org/mailman/ >>> listinfo/I-D-announce to change your subscription settings. >>> >>> Internet-Drafts are also available by anonymous FTP. Login with >>> the username "anonymous" and a password of your e-mail address. >>> After logging in, type "cd internet-drafts" and then "get draft- >>> culler-rsn-routing-reqs-00.txt". >>> >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/ >>> 1shadow-sites.txt >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org . >>> In the body type: >>> "FILE /internet-drafts/draft-culler-rsn-routing-reqs-00.txt". >>> >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant mail readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> Content-Type: text/plain >>> Content-ID: <2007-4-13132741.I-D@ietf.org >> 2007-4-13132741.I-D@ietf.org>> >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www1.ietf.org/mailman/listinfo/i-d-announce >> >> --------------------------------------------------------------------- >> --- >> >> _______________________________________________ >> RSN mailing list >> RSN@ietf.org >> https://www1.ietf.org/mailman/listinfo/rsn >> _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue Apr 17 13:05:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdr7b-0001Aw-Qs; Tue, 17 Apr 2007 13:05:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdr7a-0001An-QW for rsn@ietf.org; Tue, 17 Apr 2007 13:05:38 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdr7a-00079y-FO for rsn@ietf.org; Tue, 17 Apr 2007 13:05:38 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-3.cisco.com with ESMTP; 17 Apr 2007 10:05:39 -0700 X-IronPort-AV: i="4.14,419,1170662400"; d="scan'208"; a="478865943:sNHT44540016" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l3HH5bd6029532; Tue, 17 Apr 2007 10:05:37 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l3HH5CxB000269; Tue, 17 Apr 2007 17:05:37 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 13:05:34 -0400 Received: from [64.102.165.14] ([10.82.217.62]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 13:05:33 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0DE20062-EA06-49BA-B4A6-0219572B275D@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Tue, 17 Apr 2007 13:05:30 -0400 To: rsn@ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Apr 2007 17:05:33.0454 (UTC) FILETIME=[9C4572E0:01C78112] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=536; t=1176829537; x=1177693537; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Anyone=20interested=20to=20work=20on=20security=20for=20Senso r=20Routing=20? |Sender:=20; bh=IAesrrmWvR73CBfAOvc7DkaVEVKwOIAsFdAQdf5USXc=; b=G70hBDX2qIzxP9ftfABOHX8rn5g2pLsTRUP3nUNb/VlhREoispc66ArmOnFqU/V2BNVuC3en /xABtvpdH5nXAs+vuHbGn4oiwczuWqxai0CJWt9Yf5PstmLGfGdU0Nnh; Authentication-Results: sj-dkim-6; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [RSN] Anyone interested to work on security for Sensor Routing ? X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Dear list members, I guess that we all agree on the fact Routing Security is a particularly important topics for Sensor Networks. There is another key topic that we'd like to address: manageability (in a separate thread). David and I decided to work soon on the security aspects; that said, if there are security experts on this list willing to help out, please let us know (let's use the list also). We could also ask to the security AD to see whether they could appoint security experts. Thanks. JP. _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue Apr 17 13:16:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdrHg-0005Ou-0g; Tue, 17 Apr 2007 13:16:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdrHe-0005Mn-Ge for rsn@ietf.org; Tue, 17 Apr 2007 13:16:02 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdrHd-0001Un-4n for rsn@ietf.org; Tue, 17 Apr 2007 13:16:02 -0400 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.1/8.13.5) with ESMTP id l3HHFxTB001985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 17 Apr 2007 10:16:00 -0700 (PDT) Message-ID: <462500CA.4050506@eecs.berkeley.edu> Date: Tue, 17 Apr 2007 10:15:54 -0700 From: Kris Pister User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: rsn@ietf.org Subject: Re: [RSN] Fwd: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt References: <4E21EAEE-F7AC-4424-A157-BFEECBBA7761@cisco.com> <4624BEDF.2010500@dei.uc.pt> In-Reply-To: <4624BEDF.2010500@dei.uc.pt> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org This is an excellent start. Tiago Camilo wrote: > [...] > In section 2.7, I believe that is important to say that differently > from MANETs, WSNs communications are normally not made between > monitoring sensors, meaning sensors normally communicate in > point-to-point fashion only with the sink and not with others > monitoring sensors (i.e. RFD), except in forwarding operations. Hmmm. I'm concerned that people are spending too much time worrying about RFDs. Have you seen one? Is anyone shipping/installing/configuring any? I don't think that RFDs are likely to be a part of the WSN future. If anything, technology will push us to FFDs and EMFFDs (even more full function devices :) ). Regarding communication flow, I think that 2.7 reads well as it stands. It calls out that any-to-any does happen sometimes, but often the flows are very different, including aggregation, dissemination, and local multi-hop to another mote. > > [...] > > Apart from QoS I feel that is necessary to say something about > Security, which nowadays is a hot topic in WSNs. There are several > ways to attack a WSN, and some use the routing protocol leaks to > perform DoS attacks, data hijacking, introduce radio noise, etc. > Therefore I think its necessary to say that at least security aspects > SHOULD be made. I agree. > > It is important in section 2.10 to enhance that is more > energy-efficient to process data locally then forward it, thats the > main reason for data aggregation. > As it turns out, it is often *not* more energy-efficient to process data locally than forward it, at least not in terms of what is sometimes called distributed signal processing. Compressing your own data stream is great. Payload concatenation/aggregation is great. Processing your neighbor's payload introduces other security concerns. I think that 2.10 is fine the way it is. It's clear that some times this will be useful - do we need to enumerate the reasons why? > > Regards, > > Tiago Camilo > University of Coimbra > > ksjp -- Prof. EECS, UC Berkeley Founder & CTO, Dust Networks _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue Apr 17 13:21:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdrMc-0007dn-7T; Tue, 17 Apr 2007 13:21:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdrMb-0007Zu-7N for rsn@ietf.org; Tue, 17 Apr 2007 13:21:09 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdrMZ-0003Fc-Q6 for rsn@ietf.org; Tue, 17 Apr 2007 13:21:09 -0400 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.1/8.13.5) with ESMTP id l3HHL5OC002058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Apr 2007 10:21:07 -0700 (PDT) Message-ID: <462501FD.8000809@eecs.berkeley.edu> Date: Tue, 17 Apr 2007 10:21:01 -0700 From: Kris Pister User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: JP Vasseur Subject: Re: [RSN] Anyone interested to work on security for Sensor Routing ? References: <0DE20062-EA06-49BA-B4A6-0219572B275D@cisco.com> In-Reply-To: <0DE20062-EA06-49BA-B4A6-0219572B275D@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org I don't think that I can call myself a security expert, but I helped design the security for Wireless HART (just out to ballot yesterday!), and am slogging through^H^H^H^H...eagerly participating in the ISA SP100 security working group. I'd like to contribute. ksjp JP Vasseur wrote: > Dear list members, > > I guess that we all agree on the fact Routing Security is a > particularly important topics for Sensor Networks. There is another > key topic that we'd like to address: manageability (in a separate > thread). > > David and I decided to work soon on the security aspects; that said, > if there are security experts on this list willing to help out, please > let us know (let's use the list also). > > We could also ask to the security AD to see whether they could appoint > security experts. > > Thanks. > > JP. > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue Apr 17 13:25:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdrQK-0001io-Bx; Tue, 17 Apr 2007 13:25:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdrQI-0001ij-E5 for rsn@ietf.org; Tue, 17 Apr 2007 13:24:58 -0400 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdrQH-0004zq-63 for rsn@ietf.org; Tue, 17 Apr 2007 13:24:58 -0400 Received: from dnab42321e.stanford.edu ([171.66.50.30]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1HdrQF-0002hW-Kg; Tue, 17 Apr 2007 10:24:56 -0700 In-Reply-To: <0DE20062-EA06-49BA-B4A6-0219572B275D@cisco.com> References: <0DE20062-EA06-49BA-B4A6-0219572B275D@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7736334E-629C-4C88-88D6-2E5D38FCF0E3@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [RSN] Anyone interested to work on security for Sensor Routing ? Date: Tue, 17 Apr 2007 10:25:07 -0700 To: JP Vasseur X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -102.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-1.Stanford.EDU X-Scan-Signature: 6bee508a35d8245455fa42c2dd36c733 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org On Apr 17, 2007, at 10:05 AM, JP Vasseur wrote: > Dear list members, > > I guess that we all agree on the fact Routing Security is a > particularly important topics for Sensor Networks. There is another > key topic that we'd like to address: manageability (in a separate > thread). > > David and I decided to work soon on the security aspects; that > said, if there are security experts on this list willing to help > out, please let us know (let's use the list also). > > We could also ask to the security AD to see whether they could > appoint security experts. I'm very interested in manageability (in a separate thread). Phil _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue Apr 17 13:39:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdreU-0007bX-PQ; Tue, 17 Apr 2007 13:39:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdreT-0007bL-HX for rsn@ietf.org; Tue, 17 Apr 2007 13:39:37 -0400 Received: from mail80.messagelabs.com ([195.245.230.163]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdreQ-0000RT-Qa for rsn@ietf.org; Tue, 17 Apr 2007 13:39:37 -0400 X-VirusChecked: Checked X-Env-Sender: D.He@surrey.ac.uk X-Msg-Ref: server-7.tower-80.messagelabs.com!1176831573!46448649!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 2085 invoked from network); 17 Apr 2007 17:39:33 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-7.tower-80.messagelabs.com with SMTP; 17 Apr 2007 17:39:33 -0000 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 18:39:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [RSN] Anyone interested to work on security for Sensor Routing ? Date: Tue, 17 Apr 2007 18:36:03 +0100 Message-ID: <018160DBE8D48349A0CABF4424C3DC21BE341B@EVS-EC1-NODE1.surrey.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] Anyone interested to work on security for Sensor Routing ? Thread-Index: AceBEqJnkwg+NM3kRHm+RXpxCYxMcgABDynF References: <0DE20062-EA06-49BA-B4A6-0219572B275D@cisco.com> From: To: , X-OriginalArrivalTime: 17 Apr 2007 17:39:33.0083 (UTC) FILETIME=[5BFC22B0:01C78117] X-Spam-Score: 0.3 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0129047927==" Errors-To: rsn-bounces@ietf.org This is a multi-part message in MIME format. --===============0129047927== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78117.5B950A31" This is a multi-part message in MIME format. ------_=_NextPart_001_01C78117.5B950A31 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi JP, =20 I am personally interested in routing security as well as anonymity issues. currently I invoved in security and privacy assessment which seems very difficult to perform so far. if anyone could have references, I would like to=20 get a touch it.=20 =20 Best Regards, =20 Dan ________________________________ From: JP Vasseur [mailto:jvasseur@cisco.com] Sent: Tue 17/04/2007 18:05 To: rsn@ietf.org Subject: [RSN] Anyone interested to work on security for Sensor Routing = ? Dear list members, I guess that we all agree on the fact Routing Security is a=20 particularly important topics for Sensor Networks. There is another=20 key topic that we'd like to address: manageability (in a separate=20 thread). David and I decided to work soon on the security aspects; that said,=20 if there are security experts on this list willing to help out,=20 please let us know (let's use the list also). We could also ask to the security AD to see whether they could=20 appoint security experts. Thanks. JP. _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn ------_=_NextPart_001_01C78117.5B950A31 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= [RSN] Anyone interested to work on security for Sensor Routing = ?=0A= =0A= =0A=
=0A=
Hi JP,
=0A=
 
=0A=
I am personally interested in  routing security
=0A=
as well as anonymity issues. currently I invoved in =0A= security
=0A=
and privacy assessment which seems very difficult to = perform
=0A=
so far. if anyone could have references, I would like to =
=0A=
get a touch it.
=0A=
 
=0A=
Best Regards,
=0A=
 
=0A=
Dan
=0A=

=0A=
=0A= From: JP Vasseur =0A= [mailto:jvasseur@cisco.com]
Sent: Tue 17/04/2007 = 18:05
To: =0A= rsn@ietf.org
Subject: [RSN] Anyone interested to work on = security for =0A= Sensor Routing ?

=0A=
=0A=

Dear list members,

I guess that we all agree on = the fact =0A= Routing Security is a 
particularly important topics for Sensor =0A= Networks. There is another 
key topic that we'd like to address: =0A= manageability (in a separate 
thread).

David and I = decided to =0A= work soon on the security aspects; that said, 
if there are = security =0A= experts on this list willing to help out, 
please let us know = (let's use =0A= the list also).

We could also ask to the security AD to see = whether they =0A= could 
appoint security =0A= experts.

Thanks.

JP.

_______________________________= ________________
RSN =0A= mailing list
RSN@ietf.org
https://www1.ietf.org= /mailman/listinfo/rsn

=0A= =0A= =0A= ------_=_NextPart_001_01C78117.5B950A31-- --===============0129047927== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============0129047927==-- From rsn-bounces@ietf.org Tue Apr 17 14:47:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdsi6-0002IT-1j; Tue, 17 Apr 2007 14:47:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdsi4-0002GN-Tn for rsn@ietf.org; Tue, 17 Apr 2007 14:47:24 -0400 Received: from cs1.sf.archedrock.com ([64.147.171.181] helo=secure.archedrock.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdsi3-0004vO-Ql for rsn@ietf.org; Tue, 17 Apr 2007 14:47:24 -0400 Received: by secure.archedrock.com (Postfix, from userid 101) id 4468C16B0002; Tue, 17 Apr 2007 11:47:23 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on cs1.sf.archedrock.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00, MSGID_FROM_MTA_ID autolearn=no version=3.1.8 Received: from GoatRock (69-12-164-142.sfo.archedrock.com [69.12.164.142]) by secure.archedrock.com (Postfix) with ESMTP id 3113316B0001; Tue, 17 Apr 2007 11:47:21 -0700 (PDT) From: "dculler" To: "'Pascal Thubert \(pthubert\)'" , "'Jean Philippe Vasseur \(jvasseur\)'" Subject: RE: [RSN] Fwd: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt Date: Tue, 17 Apr 2007 11:46:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acd+CkitAj/tMblUSvuRuopGWvOOFwCKjXZQADiVAwA= In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC03CA35D1@xmb-ams-337.emea.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070417184721.3113316B0001@secure.archedrock.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8e9fbe727bc2159b431d624c595c1eab Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dculler@archrock.com List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org =20 -----Original Message----- From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: Monday, April 16, 2007 8:52 AM To: Jean Philippe Vasseur (jvasseur) Cc: rsn@ietf.org Subject: RE: [RSN] Fwd: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt=20 Hi JP: Congrats to the authors for this excellent 00 draft. It is already very thorough and sheds some good light on how different the WSN approaches = need to be vs. traditional routing and MANET approaches. >> Thanks. It is intended to be a start. Through the discussion, those trade-offs and alternatives Will hopefully be spelled out in greater detail. Now to the comments: High level: ----------- I believe you need a terminology: >> Yes. This section will be in 01. - In particular, you need to define what a "sink" is and which functions = you expect there >> This is indeed an important point of clarification. Different terms = get used with slightly varying meaning in different communities. Traditionally, collections = of sensors (instruments, meters, guages, sense points) typically provide = data into data collection points (e.g., controllers, logs, analytics). As we move from "traditional instrumentation" to "a network of sensors" we = need to tease apart several related concepts, and this draft will be a good = place to do it. Even in the more general sensor network setting, the dominant traffic pattern is still likely to be a small minority of devices (often one) collecting data from a large number of others. Of course, this is = true if we have a network of completely independent devices routing through a common gateway or router. What makes it attractive to think of it as multipoint-to-point is that the collection of "sources" are often = closely related and highly correlated, as they are part of the same application. The "many sources to few sinks" relationship is often very long lived. = In the case of a "sensor inter-network", rather than a "sensor link" in the = IP sense, the application level "sink" may be removed from the sensor = "sources" by multiple IP hops. The convergence of flows may occur into intevening routing points. >> In addition, while these multipoint-to-point relationships are very common from a data path perspective (sense points act like servers), = there is invariably a point-to-multipoint relationship in configuration, = control and management, say to set sample rates, configure thresholds, etc. >> Finally, even in the presence of a "dominant data collection under = common control and management" there is need to individually configure, = calibrate, or access sensor nodes. =20 >> The draft should indeed clarify the relationship between these application level characteristics and the underlying networking characteristics, as well as how these drives the evaluation of routing protocol alternatives and trade-offs. - you also need to define what a "point of connectivity" is and how = that's different from a sink >> Indeed, 2.6 seeks to broaden the domain of evaluation to include = various kinds of dynamics, including among others * varying interconnectivity even in a stationary network due to = changing environmental factors, * mobile devices moving within a stationary network (with potentially varying connectivity),=20 * and networks of devices that move together. The "point of connectivity" may indeed be a temporary "sink" in the application level sense of a data collection point, or in the routing = sense. Even if it serves only at a routing point, its presence may trigger the communication. - same for data aggregation >> Agreed. I'll try to pick this up on the other thread on "data aware routing" - finally, IMHO, it would be good to define RFD and FFD which are = implicit in the draft, and link that with battery problem and the expected = functional set (host, forwarder, router, aggregator). >> This is a very important point. The draft intentionally avoids the = RFD and FFD terms that have specific meaning relative to certain link technologies. Obviously, there is a broad spectrum of "fullness" or "reducedness" in functionality. An individual device may be able to = change its role substantial because it gets plugged in (or has some other power service) even if it does not change its storage or processing = capability. We would like to recognize that a routing protocol that was able to = utilize the presence "more capable devices" to reduce the demand on "less = capable devices" has substantial value. This also means that we need to define scalability well. It is not just the number of devices, but the ability = to scale down in the device dimension and to scale up. There are 2 assumptions in the text that could be discussed: - The need for multiple topologies. I do like the concept of MTR in that space and agree it will be useful. But it is not mandatory as suggested = in section 2.9. For instance, you can achieve similar results with multiple feasible successors in EIGRP, or with ants routing, link reversal = (TORA), etc... long as your routing protocol enables multiple non-equal-cost = routes in parallel you can get QoS enabled forwarding. >> A very good point. JP may want to comment more on this. Clearly, if = the relevant variations in links can be captured in a common cost function = it provides a certain simplicity. - The need for A routing protocol that does everything you mention: In one hand, some of the operations you describe are forwarding operation and could be done outside of routing, provided that the = routing proposes either multiple feasible successors or multiple topologies.=20 ITOH, considering the broad range of applications (radio types, battery vs. power source, device size, etc...) we might not need A = routing protocol that does it all but maybe a more generic framework that interoperates at a basic level but can be extended with specific options = and protocol values for the various cases that you describe, and the ones = which will come in the future. >> Indeed. Part of the beauty of IP routing is precisely that we can separate these two issues. We can have a common fowarding engine, even = if the routing tables are derived from a variety of differ routing = protocols. These two issues too often get confused. It would be good if the draft could pull these issues apart. Would you go farther and suggest that = this separation is a SHOULD or MUST? =20 >>The other side of this, of course, is that you want aspects of the forwarding (selection of multiple alternative routes, avoidance of = energy depleted nodes) to potentially be aware of issues associated with route formation (e.g., costs) and potentially vice versa. - The fact that the requirements are unique to sensors can also be discussed. Taken individually, that might not be true. For instance = you'll find UHF radios in places with very scare bandwidth, and radios carried = by soldiers and firemen with similar constraints but a different trade off = in range vs. battery life. I'd hope that whatever comes out of this work is = not limited to sensors but can also be applied / extended to other types of = mesh networking applications. >> Absolutely. Even in the simplest case, sensors versus other = transducers. The question is what boundaries do we need to establish in order to get enough focus on the technical issues that we can make solid progress. Clearly there are issues in here having to do with the mobility model, = the presence or lack of infrastructure, the duration of communication relationships, and the coherency of operation across collections of = devices, and whether devices are largely attended or unattended.=20 Details : --------- Page 3. Title 2. - I believe that some text would be good to position WSN that is covered = by the document vs. mesh and PAN (that are not?). Note that per its new charter, NEMO is actually gathering requirements for PANs, and there's = still no official WG for mesh and sensors. >> Makes sense, but those terms are not terribly well defined. "PAN" = serves as an IEEE concept to differentiation a certain wireless bit-rate and transmission power from "LAN". We certainly want to include "PAN"s. = Mesh is particularly ill-defined. Perhaps what you mean here is "multihop routing within and IP link" versus routing at the next level up. We = would certainly like to deal with IP routing over collections of "mesh routed" links. Obviously, a very interesting case is where the mesh is of size = one. Page 4, section 2.4 - First sentence is a bit hard to read, could you rephrase? >> Agreed.=20 - I'm not convinced that routing is the key to power management. It is = true some protocols merge the control of the routing (decide who are the next hops) and the forwarding (decide which next hop and when to transmit for = a given packet). But it might be much more economical to separate the = routing and the forwarding protocols in order to get a simpler and more generic routing plane; you could then add a more specific forwarding protocol = when needed, in order to change only the forwarding behavior as some = conditions change (link load, link interference, path load, you name it) which do = not require to establish new routes. An example of what we can not do in WSN = is using SPF with dynamic metrics, because it computes a single path to the sink and has to re-compute it all when things change, that is all the = time. OTOH, a DV or a greedy approach give you multiple next hops in a general Directed Acyclic Graph towards the sink, and circulating metrics in a forwarding protocol is a sufficient and more to the point to enable the = next hop selection in the forwarding plane. >> There is clearly a separation here. The main point is that the = routing protocols should not prevent deep power management. We generally focus = on links that are "always on". A typical design point is WSNs is that = radios are only on 0.1% - 1% of the time. All too often, this has caused forwarding concerns (scheduled transfers and TDMA techniques) to get all mixed up with routing. Being able to maintain reasonable separation and still be able to perform deep power management is a good goal. - last sentence about " the devices have their network link off most of = the time." This is a very interesting point and it might deserve a bit more text; maybe a little discussion on FFD vs. RFD. And the related = expectation in the routing, forwarding and data aggregation functions that you would place in those boxes; also, please note that in the military, being able = to operate in stealth (send nothing unless absolutely necessary) mode is a critical feature. =20 >> Agree Page 5, section 2.5 Again comes the FFD / RFD discussion. Considering the wide variety of = cases within sensors itself I can hardly believe that one protocol / one = algorithm / one set of metrics fits it all. Back to the 2nd assumption I discussed = at the beginning of this mail, we have to propose something that guarantees interoperability and loopless routing, but we need to ensure some = liberty for case specific routing decisions, based on specific extension options (for instance radio dependent metrics, L3 data that might influence policies, etc), and timing.=20 Page 5, section 2.5 "and detection of a point of connectivity". Apart from the missing dot = :) and that you really need to define not only what this is (a wire access = or any router that can relay including a wireless sensor?), this sentence implies that there is a need for the protocol to discover that "point of connectivity". In many cases that you describe in 2.7, a logical = topology that is defined by this sink is sufficient for the basic needs of the = WSN, and that deserves some words either in 2.5 or maybe in 2.8. Page 6, section 2.8 Another interesting aspect of mobile mesh and WSN is that there might = not be a global topology for the routing to converge, just because too many = things move for the control plane to cope with over the limited resources.=20 As a result, SPF-type convergence is a non-goal. In such an environment = you can expect at best to reach most peers at most times. A consequence is = that if there are peers that are more equals than the others (the sinks for instance), you should be able to maintain the associated path(s) back = and forth before you consider maintaining other, less important routes (Back = to the discussion on 2.5). Page 7, section 2.10 (you mean data aware, right? - note: we can do both = :) The "point of aggregation" is another good topic that illustrates that = the routing protocol that we want will need the capability to support = extensions for case specific and even proprietary algorithms from day 1. Some deployments will have aggregations and some will not. Some nodes will support the aggregation options, and some will not. It all needs to work = and interoperate regardless of the specific options and option derived algorithms that nodes in the network actually support. Thanks again to the authors for this excellent work. Pascal ________________________________________ From: Jean Philippe Vasseur (jvasseur) Sent: Friday, April 13, 2007 10:28 PM To: rsn@ietf.org Subject: [RSN] Fwd: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt=20 Hi, Glad to see a good number of people who signed up to list already. Here = is the first revision of the requirements ID. Feedbacks most welcome of = course ! Thanks. JP and David. Begin forwarded message: From: Internet-Drafts@ietf.org Date: April 13, 2007 3:50:01 PM EDT To: i-d-announce@ietf.org Subject: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt Reply-To: internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Routing Requirements for Sensor Networks Author(s) : D. Cullerot, J. Vasseur Filename : draft-culler-rsn-routing-reqs-00.txt Pages :=A0 Date : 2007-4-13 =09 =A0=A0 The need for high quality routing for Sensor networks comprised = of =A0=A0 highly constrained devices (CPU, memory, ...) in sometimes = unstable =A0=A0 wireless environments is critical now and will continue to = increase. =A0=A0 Interest in this class of applications has grown dramatically in =A0=A0 recent years and a routing solution addressing the specific =A0=A0 environments of such networks is highly required considering the =A0=A0 numerous, incompatible open-source and proprietary routing = protocols =A0=A0 as well as several industrial forums.=A0 The aim of this document = is to =A0=A0 define the routing requirements for Sensor Networks at the IP = layer. =A0=A0 Such routing protocol(s) would need to address several unique = aspects =A0=A0 of this class of embedded devices and would operate in networks =A0=A0 comprising links of various nature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-culler-rsn-routing-reqs-00.txt To remove yourself from the I-D Announcement list, send a message to=A0 i-d-announce-request@ietf.org with the word unsubscribe in the body = of=A0 the message.=A0 You can also visit = https://www1.ietf.org/mailman/listinfo/I-D-announce=A0 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=A0 username "anonymous" and a password of your e-mail address. After=A0 logging in, type "cd internet-drafts" and then=A0 "get draft-culler-rsn-routing-reqs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=A0 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-culler-rsn-routing-reqs-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility.=A0 To use this feature, insert the command "ENCODING mime" before the "FILE" command.=A0 To decode the response(s), you will need "munpack" or a MIME-compliant mail reader.=A0 Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2007-4-13132741.I-D@ietf.org> _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue Apr 17 21:33:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdz3A-0005h5-UD; Tue, 17 Apr 2007 21:33:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdz39-0005gy-8r for rsn@ietf.org; Tue, 17 Apr 2007 21:33:35 -0400 Received: from web62308.mail.re1.yahoo.com ([69.147.75.22]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hdz35-0004HD-PY for rsn@ietf.org; Tue, 17 Apr 2007 21:33:35 -0400 Received: (qmail 4068 invoked by uid 60001); 18 Apr 2007 01:20:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=dsfXz+pkCK6yIwKBMILRujD4svwQXpEKif8ZnQ8mnieIc1COAQv+qTclDO3xZlsabEsohpq4VdIh64BIv/0/aZALgcks0xx6OovYPfVXhHDByKlmj8+wTsagJh6ccekroMctWBrZAIWoK+LdVgZuebISc3kpkrTe+6ZvfIcHL6o=; X-YMail-OSG: iOY4kH8VM1nKGwoCq5pcN65lWeBo3gqysEy5iCcrpbc5Z4ZNbg7eX7RuhAv2ftOAxz284mR65L0DmX7S8B.etn9IVQ-- Received: from [202.120.37.2] by web62308.mail.re1.yahoo.com via HTTP; Tue, 17 Apr 2007 18:20:38 PDT X-Mailer: YahooMailRC/478 YahooMailWebService/0.7.41.10 Date: Tue, 17 Apr 2007 18:20:38 -0700 (PDT) From: Longjiang Li To: rsn-owner@ietf.org Cc: rsn@ietf.org MIME-Version: 1.0 Message-ID: <697748.1396.qm@web62308.mail.re1.yahoo.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Subject: [RSN] why does RSN Digest always include only one item? X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1074252709==" Errors-To: rsn-bounces@ietf.org --===============1074252709== Content-Type: multipart/alternative; boundary="0-657454781-1176859238=:1396" --0-657454781-1176859238=:1396 Content-Type: text/plain; charset=ascii Dear sir, Since I subscribed to RSN mail list in the fashion of digest, why did I receive many emails where eache mail only includes one item? What's wrong with it? Best Regards, Longjiang Li ----- Original Message ---- From: "rsn-request@ietf.org" To: rsn@ietf.org Sent: Wednesday, April 18, 2007 1:25:00 AM Subject: RSN Digest, Vol 1, Issue 20 Send RSN mailing list submissions to rsn@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/rsn or, via email, send a message with subject or body 'help' to rsn-request@ietf.org You can reach the person managing the list at rsn-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of RSN digest..." Today's Topics: 1. Re: Anyone interested to work on security for Sensor Routing ? (Philip Levis) ---------------------------------------------------------------------- Message: 1 Date: Tue, 17 Apr 2007 10:25:07 -0700 From: Philip Levis Subject: Re: [RSN] Anyone interested to work on security for Sensor Routing ? To: JP Vasseur Cc: rsn@ietf.org Message-ID: <7736334E-629C-4C88-88D6-2E5D38FCF0E3@cs.stanford.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Apr 17, 2007, at 10:05 AM, JP Vasseur wrote: > Dear list members, > > I guess that we all agree on the fact Routing Security is a > particularly important topics for Sensor Networks. There is another > key topic that we'd like to address: manageability (in a separate > thread). > > David and I decided to work soon on the security aspects; that > said, if there are security experts on this list willing to help > out, please let us know (let's use the list also). > > We could also ask to the security AD to see whether they could > appoint security experts. I'm very interested in manageability (in a separate thread). Phil ------------------------------ _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn End of RSN Digest, Vol 1, Issue 20 ********************************** __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-657454781-1176859238=:1396 Content-Type: text/html; charset=ascii
Dear sir,

Since I subscribed to  RSN mail list in the fashion of digest, why did I receive many emails where eache mail only includes one item?  What's wrong with it?

Best Regards,
Longjiang Li

----- Original Message ----
From: "rsn-request@ietf.org" <rsn-request@ietf.org>
To: rsn@ietf.org
Sent: Wednesday, April 18, 2007 1:25:00 AM
Subject: RSN Digest, Vol 1, Issue 20

Send RSN mailing list submissions to
    rsn@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
    https://www1.ietf.org/mailman/listinfo/rsn
or, via email, send a message with subject or body 'help' to
    rsn-request@ietf.org

You can reach the person managing the list at
    rsn-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of RSN digest..."


Today's Topics:

   1. Re:  Anyone interested to work on security for Sensor Routing
      ? (Philip Levis)


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

Message: 1
Date: Tue, 17 Apr 2007 10:25:07 -0700
From: Philip Levis <pal@cs.stanford.edu>
Subject: Re: [RSN] Anyone interested to work on security for Sensor
    Routing ?
To: JP Vasseur <jvasseur@cisco.com>
Cc: rsn@ietf.org
Message-ID: <7736334E-629C-4C88-88D6-2E5D38FCF0E3@cs.stanford.edu>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

On Apr 17, 2007, at 10:05 AM, JP Vasseur wrote:

> Dear list members,
>
> I guess that we all agree on the fact Routing Security is a  
> particularly important topics for Sensor Networks. There is another  
> key topic that we'd like to address: manageability (in a separate  
> thread).
>
> David and I decided to work soon on the security aspects; that  
> said, if there are security experts on this list willing to help  
> out, please let us know (let's use the list also).
>
> We could also ask to the security AD to see whether they could  
> appoint security experts.

I'm very interested in manageability (in a separate thread).

Phil



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

_______________________________________________
RSN mailing list
RSN@ietf.org
https://www1.ietf.org/mailman/listinfo/rsn


End of RSN Digest, Vol 1, Issue 20
**********************************


Ahhh...imagining that irresistible "new car" smell?
Check out new cars at Yahoo! Autos. --0-657454781-1176859238=:1396-- --===============1074252709== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============1074252709==-- From rsn-bounces@ietf.org Wed Apr 18 01:22:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He2cF-0006Lt-Rf; Wed, 18 Apr 2007 01:22:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He2cD-0006Ln-Vg for rsn@ietf.org; Wed, 18 Apr 2007 01:22:01 -0400 Received: from cs1.sf.archedrock.com ([64.147.171.181] helo=secure.archedrock.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He2cC-0002vV-HH for rsn@ietf.org; Wed, 18 Apr 2007 01:22:01 -0400 Received: by secure.archedrock.com (Postfix, from userid 101) id D58F216B0002; Tue, 17 Apr 2007 22:21:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on cs1.sf.archedrock.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00, MSGID_FROM_MTA_ID autolearn=no version=3.1.8 Received: from GoatRock (64-142-4-192.dsl.static.sonic.net [64.142.4.192]) by secure.archedrock.com (Postfix) with ESMTP id D855116B0002; Tue, 17 Apr 2007 22:21:58 -0700 (PDT) From: "dculler" To: "'Kris Pister'" , "'JP Vasseur'" Subject: RE: [RSN] Anyone interested to work on security for Sensor Routing ? Date: Tue, 17 Apr 2007 22:21:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceBFMxI9Ov5krHEQfqhaXWwoTzamwAX5BQw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <462501FD.8000809@eecs.berkeley.edu> Message-Id: <20070418052158.D855116B0002@secure.archedrock.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dculler@archrock.com List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org It sounds like we have strong interest in the security aspects, so let's see if we can frame the technical issues. Then ee can determine with are relevant to routing, and which need to be addressed elsewhere. The requirements draft needs to have a security section in any case. To get things rolling, I'll try to lay out some of the obvious ones. Hopefully, others will pick up the thread and take it deeper. * Where wireless is involved, physical security is very limited, so at the very least communication ought to be encrypted. In the case of 802.15.4, AES128 is provided in compliant hardware, so we can assume link level encryption. With that as a basis, authentication protocols can be put in place. Wagner and others have looked at the vulnerabilities of these link level mechanisms. Of course, there is the issue of key management. One issue particularly germaine to sensor networks, is that the devices will often be without a user interface, so there is no way to type in the pass phrase. Actually, this is the case for many other embedded device without a UI. Typically there is some equivalent of a service account that provides a means of physical authentication and key insertion. All of this is important, but little of it spills over to routing unless the initial keys must be entered via the network, which may be the only interface. * We can assume that the usual mechanisms of firewalls, ACLs, etc. apply to IP routing in sensor networks as they do elsewhere and have similar strengths and weaknesses. At the same time, we should probably observe that an IP-connected gateway in front of a non-routed subnet is no security panacea, since if the gateway is compromised the devices behind it are effectively compromised. * Under assumptions of small MTU and low footprint, there are issues of when and how public keys can be used. Several studies have been conducted on taking RSA and eliptic schemes down to MCU class devices. * If routing protocols are utilized to establish routing tables, we must attend to the vulnerability of these protocols and whether their communication is authenticated, etc. For example, where routing is cost based, can the costs be easily spoofed? * Certain routing protocol primitives are more vulnerable than others. For example, if route determination involves a flood of the network to discover the path to the desire destination. A node that simply requests a route to a non-existent destination could potentially deny service throughout the network. Additionally, it could consume precious energy resources. Thus, there is some connection between parsimonious routing protocols and vulnerability. * Diversity and scale can potentially be utilized to a security advantage. The more routing paths available, the more ability to deliver data despite compromises. * Routing security issued carry over to some degree to forwarding, as the incoming packet must be consulted to determine a forwarding decision. Thus, either the destination (or route, if source routing is used) will be carried in the clear or be decrypted at each routing hop. * Security interacts with header compression. For example, short dynamically assigned addresses have somewhat different properties than EUIDs. * The potential to compromise of devices within physical premises exists for hosts and routers, not just sensor nodes. So physical compromise issues and associated legal mechanisms are largely and orthogonal to sensor networking, per se. -----Original Message----- From: Kris Pister [mailto:pister@eecs.berkeley.edu] Sent: Tuesday, April 17, 2007 10:21 AM To: JP Vasseur Cc: rsn@ietf.org Subject: Re: [RSN] Anyone interested to work on security for Sensor Routing ? I don't think that I can call myself a security expert, but I helped design the security for Wireless HART (just out to ballot yesterday!), and am slogging through^H^H^H^H...eagerly participating in the ISA SP100 security working group. I'd like to contribute. ksjp JP Vasseur wrote: > Dear list members, > > I guess that we all agree on the fact Routing Security is a > particularly important topics for Sensor Networks. There is another > key topic that we'd like to address: manageability (in a separate > thread). > > David and I decided to work soon on the security aspects; that said, > if there are security experts on this list willing to help out, please > let us know (let's use the list also). > > We could also ask to the security AD to see whether they could appoint > security experts. > > Thanks. > > JP. > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Wed Apr 18 01:40:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He2tl-0000Dx-FZ; Wed, 18 Apr 2007 01:40:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He2tj-0000Dg-8P for rsn@ietf.org; Wed, 18 Apr 2007 01:40:07 -0400 Received: from wx-out-0506.google.com ([66.249.82.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He2tf-0000YS-UQ for rsn@ietf.org; Wed, 18 Apr 2007 01:40:07 -0400 Received: by wx-out-0506.google.com with SMTP id h31so50532wxd for ; Tue, 17 Apr 2007 22:40:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=PNwtYWJwzp1/ePkh8KOZ2F8ndp6B2EPur8MJ07Wl2DFm6tf2BT1jg6Ik5THnx19T70MdSHhFdcJ+9IhnObzw0yYKuw0ERe3HRoom93n48k+RI6l1h3FaixWL2AUoeQmXEqYWYufsKbkqASaEOFS1w5LzVilfLOyqRSjWSouexJ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=G8P6N2ni0ktA+a/Q4YmVPAt5+i7zradjZdfoYjILFy0YXxlSO/cvzRmiPKjYGpLVnmQwX3vAhkuKIL69LlhgUEFnwkuuj533OnH5YOwaedagRMc3p9DPEK9AFdnEVlXDHzjxUxwnA7Rq92WkULrBeDyd/FStTUNYRFD1JOYncYc= Received: by 10.114.194.1 with SMTP id r1mr65056waf.1176874802814; Tue, 17 Apr 2007 22:40:02 -0700 (PDT) Received: by 10.114.24.11 with HTTP; Tue, 17 Apr 2007 22:40:02 -0700 (PDT) Message-ID: Date: Wed, 18 Apr 2007 14:40:02 +0900 From: "Ki-Hyung Kim" To: "JP Vasseur" Subject: Re: [RSN] Anyone interested to work on security for Sensor Routing ? In-Reply-To: <0DE20062-EA06-49BA-B4A6-0219572B275D@cisco.com> MIME-Version: 1.0 References: <0DE20062-EA06-49BA-B4A6-0219572B275D@cisco.com> X-Spam-Score: 0.6 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1542462872==" Errors-To: rsn-bounces@ietf.org --===============1542462872== Content-Type: multipart/alternative; boundary="----=_Part_73023_26835653.1176874802729" ------=_Part_73023_26835653.1176874802729 Content-Type: text/plain; charset=EUC-KR; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SGksIEpQLAoKSSBhbSBpbnRlcmVzdGVkIGluIHRoZSBtYW5hZ2VhYmlsaXR5IGlzc3VlLgoKCgoK T24gNC8xOC8wNywgSlAgVmFzc2V1ciA8anZhc3NldXJAY2lzY28uY29tPiB3cm90ZToKPgo+IERl YXIgbGlzdCBtZW1iZXJzLAo+Cj4gSSBndWVzcyB0aGF0IHdlIGFsbCBhZ3JlZSBvbiB0aGUgZmFj dCBSb3V0aW5nIFNlY3VyaXR5IGlzIGEKPiBwYXJ0aWN1bGFybHkgaW1wb3J0YW50IHRvcGljcyBm b3IgU2Vuc29yIE5ldHdvcmtzLiBUaGVyZSBpcyBhbm90aGVyCj4ga2V5IHRvcGljIHRoYXQgd2Un ZCBsaWtlIHRvIGFkZHJlc3M6IG1hbmFnZWFiaWxpdHkgKGluIGEgc2VwYXJhdGUKPiB0aHJlYWQp Lgo+Cj4gRGF2aWQgYW5kIEkgZGVjaWRlZCB0byB3b3JrIHNvb24gb24gdGhlIHNlY3VyaXR5IGFz cGVjdHM7IHRoYXQgc2FpZCwKPiBpZiB0aGVyZSBhcmUgc2VjdXJpdHkgZXhwZXJ0cyBvbiB0aGlz IGxpc3Qgd2lsbGluZyB0byBoZWxwIG91dCwKPiBwbGVhc2UgbGV0IHVzIGtub3cgKGxldCdzIHVz ZSB0aGUgbGlzdCBhbHNvKS4KPgo+IFdlIGNvdWxkIGFsc28gYXNrIHRvIHRoZSBzZWN1cml0eSBB RCB0byBzZWUgd2hldGhlciB0aGV5IGNvdWxkCj4gYXBwb2ludCBzZWN1cml0eSBleHBlcnRzLgo+ Cj4gVGhhbmtzLgo+Cj4gSlAuCj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwo+IFJTTiBtYWlsaW5nIGxpc3QKPiBSU05AaWV0Zi5vcmcKPiBodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yc24KPgoKCgotLSAKS2ktSHl1bmcgS2lt ICix6LHix/wsINDd0cP6+ykKQXNzb2NpYXRlIFByb2Zlc3NvcgpEaXZpc2lvbiBvZiBJbmZvcm1h dGlvbiBhbmQgQ29tcHV0ZXIgRW5nLiwgQWpvdSBVbml2ZXJzaXR5LCBTdXdvbiwgS29yZWEKNDQy LTc0OQpUZWw6ICs4Mi0zMS0yMTktMjQzMywgQ2VsOiArODItMTctNzYwLTI1NTEsICBGYXg6ICs4 Mi0zMS0yMTktMjQzMwpodHRwOi8vd3d3LjZsb3dwYW4ub3JnCg== ------=_Part_73023_26835653.1176874802729 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5IaSwgSlAsPC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+SSBhbSBpbnRlcmVzdGVk IGluIHRoZSBtYW5hZ2VhYmlsaXR5IGlzc3VlLjwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2 Pjxicj48YnI+Jm5ic3A7PC9kaXY+CjxkaXY+PHNwYW4gY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiA0 LzE4LzA3LCA8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+SlAgVmFzc2V1cjwvYj4gJmx0Ozxh IGhyZWY9Im1haWx0bzpqdmFzc2V1ckBjaXNjby5jb20iPmp2YXNzZXVyQGNpc2NvLmNvbTwvYT4m Z3Q7IHdyb3RlOjwvc3Bhbj4KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0i UEFERElORy1MRUZUOiAxZXg7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IEJPUkRFUi1MRUZU OiAjY2NjIDFweCBzb2xpZCI+RGVhciBsaXN0IG1lbWJlcnMsPGJyPjxicj5JIGd1ZXNzIHRoYXQg d2UgYWxsIGFncmVlIG9uIHRoZSBmYWN0IFJvdXRpbmcgU2VjdXJpdHkgaXMgYTxicj5wYXJ0aWN1 bGFybHkgaW1wb3J0YW50IHRvcGljcyBmb3IgU2Vuc29yIE5ldHdvcmtzLiBUaGVyZSBpcyBhbm90 aGVyCjxicj5rZXkgdG9waWMgdGhhdCB3ZSYjMzk7ZCBsaWtlIHRvIGFkZHJlc3M6IG1hbmFnZWFi aWxpdHkgKGluIGEgc2VwYXJhdGU8YnI+dGhyZWFkKS48YnI+PGJyPkRhdmlkIGFuZCBJIGRlY2lk ZWQgdG8gd29yayBzb29uIG9uIHRoZSBzZWN1cml0eSBhc3BlY3RzOyB0aGF0IHNhaWQsPGJyPmlm IHRoZXJlIGFyZSBzZWN1cml0eSBleHBlcnRzIG9uIHRoaXMgbGlzdCB3aWxsaW5nIHRvIGhlbHAg b3V0LAo8YnI+cGxlYXNlIGxldCB1cyBrbm93IChsZXQmIzM5O3MgdXNlIHRoZSBsaXN0IGFsc28p Ljxicj48YnI+V2UgY291bGQgYWxzbyBhc2sgdG8gdGhlIHNlY3VyaXR5IEFEIHRvIHNlZSB3aGV0 aGVyIHRoZXkgY291bGQ8YnI+YXBwb2ludCBzZWN1cml0eSBleHBlcnRzLjxicj48YnI+VGhhbmtz Ljxicj48YnI+SlAuPGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwo8YnI+UlNOIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86UlNOQGll dGYub3JnIj5SU05AaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3MS5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3JzbiI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcnNuPC9hPjxicj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjxiciBjbGVhcj0iYWxsIj48 YnI+LS0gCjxicj5LaS1IeXVuZyBLaW0gKLHoseLH/Cwg0N3Rw/r7KTxicj5Bc3NvY2lhdGUgUHJv ZmVzc29yPGJyPkRpdmlzaW9uIG9mIEluZm9ybWF0aW9uIGFuZCBDb21wdXRlciBFbmcuLCBBam91 IFVuaXZlcnNpdHksIFN1d29uLCBLb3JlYSA0NDItNzQ5PGJyPlRlbDogKzgyLTMxLTIxOS0yNDMz LCBDZWw6ICs4Mi0xNy03NjAtMjU1MSwmbmJzcDsmbmJzcDtGYXg6ICs4Mi0zMS0yMTktMjQzMyA8 YSBocmVmPSJodHRwOi8vd3d3LjZsb3dwYW4ub3JnIj4KaHR0cDovL3d3dy42bG93cGFuLm9yZzwv YT4gCg== ------=_Part_73023_26835653.1176874802729-- --===============1542462872== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============1542462872==-- From rsn-bounces@ietf.org Wed Apr 18 01:44:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He2xf-0001DE-TF; Wed, 18 Apr 2007 01:44:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He2xe-0001D9-TY for rsn@ietf.org; Wed, 18 Apr 2007 01:44:10 -0400 Received: from cs1.sf.archedrock.com ([64.147.171.181] helo=secure.archedrock.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He2xd-0001ms-LF for rsn@ietf.org; Wed, 18 Apr 2007 01:44:10 -0400 Received: by secure.archedrock.com (Postfix, from userid 101) id 1F8E316B0004; Tue, 17 Apr 2007 22:44:09 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on cs1.sf.archedrock.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,HTML_30_40, HTML_MESSAGE, HTML_TITLE_EMPTY, MSGID_FROM_MTA_ID autolearn=no version=3.1.8 Received: from GoatRock (64-142-4-192.dsl.static.sonic.net [64.142.4.192]) by secure.archedrock.com (Postfix) with ESMTP id F3FE416B0003; Tue, 17 Apr 2007 22:44:06 -0700 (PDT) From: "dculler" To: "'Tiago Camilo'" , "'JP Vasseur'" Subject: RE: [RSN] Fwd: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt Date: Tue, 17 Apr 2007 22:43:33 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AceA7L5/WfJOdCvNRrSCBH/NuQCA5gAjZW/Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <4624BEDF.2010500@dei.uc.pt> Message-Id: <20070418054406.F3FE416B0003@secure.archedrock.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 680445c3afe8c9e96925f2dfef141924 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dculler@archrock.com List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1351099313==" Errors-To: rsn-bounces@ietf.org This is a multi-part message in MIME format. --===============1351099313== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0043_01C78141.D52EA610" This is a multi-part message in MIME format. ------=_NextPart_000_0043_01C78141.D52EA610 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: Tiago Camilo [mailto:tandre@dei.uc.pt] Sent: Tuesday, April 17, 2007 5:35 AM To: JP Vasseur Cc: rsn@ietf.org Subject: Re: [RSN] Fwd: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt Hi, Glad to see WSN standard work in IETF. I agree with Pascal comment regarding the terminology. I think that a terminology section helps to clarify some points in the ID. Terms such as sink, RFD and FFD are very common in WSN routing protocols, and should be IMO defined and used in the text. RFD and FFD have been defined with respect to specific mechanisms in IEEE 802.15.4, such as power management, beaconing, and the need to "route" (in the L2 sense) through a coordinator. I feel that is essential to recognize and utilize heterogeneity, but I am concerned about using those terms that have a specific technical meaning in IEEE 802.15.4 and certain industrial L2 protocols that run over it. I think that is important in the introduction when you write about "Considering the variety of Sensor based applications" to refer that in WSNs, the routing protocol is somehow restricted by the application, meaning it is the application that defines if the protocol is time-driven, event-driven or hybrid. I certainly understand that sensor applications may be time-driven, event-driven, or hybrid, and I can see that these apply to forwarding. It is less clear that this defines the routing protocol. In section 2.7, I believe that is important to say that differently from MANETs, WSNs communications are normally not made between monitoring sensors, meaning sensors normally communicate in point-to-point fashion only with the sink and not with others monitoring sensors (i.e. RFD), except in forwarding operations. Although such collection is indeed the dominate traffic in typical usage, there are a number of useful cases where point-to-point occurs. There are certainly cases where it make sense for a sensor reading to trigger or in some way be incorporated into the readings or actions of another sensor before being collected. There are also cases where an individual sensor is queried or configured. These need not have a geographic locality involved. There are also a number of cases where geographic locality is essential, such as the combining a set of readings covering a certain region of space or a person interacting with nearby sensors through a handheld field unit. So it does seem wise to attend to how different the traffic patterns are in this domain from that which we normally use to evaluate routing algorithms, but it is also important to cover the less common cases properly. In section 2.9. I do not understand why the phrase "MUST support multi-topology routing in one form or another with different degrees of route optimization" is under the QoS topic. Moreover I suggest to change the keyword MUST to SHOULD, since in some applications scenarios, such support is not a requirement, i.e. habitat monitoring. I agree. It is probably premature to make MUST determinations at this stage of requirements definition. Apart from QoS I feel that is necessary to say something about Security, which nowadays is a hot topic in WSNs. There are several ways to attack a WSN, and some use the routing protocol leaks to perform DoS attacks, data hijacking, introduce radio noise, etc. Therefore I think its necessary to say that at least security aspects SHOULD be made. It is important in section 2.10 to enhance that is more energy-efficient to process data locally then forward it, thats the main reason for data aggregation. Regards, Tiago Camilo University of Coimbra JP Vasseur wrote: > Hi, > > Glad to see a good number of people who signed up to list already. > Here is the first revision of the requirements ID. Feedbacks most > welcome of course ! > > Thanks. > > JP and David. > > Begin forwarded message: > >> *From: *Internet-Drafts@ietf.org >> *Date: *April 13, 2007 3:50:01 PM EDT >> *To: *i-d-announce@ietf.org >> *Subject: **I-D ACTION:draft-culler-rsn-routing-reqs-00.txt * >> *Reply-To: *internet-drafts@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Routing Requirements for Sensor Networks >> Author(s) : D. Cullerot, J. Vasseur >> Filename : draft-culler-rsn-routing-reqs-00.txt >> Pages : >> Date : 2007-4-13 >> >> The need for high quality routing for Sensor networks comprised of >> highly constrained devices (CPU, memory, ...) in sometimes unstable >> wireless environments is critical now and will continue to increase. >> Interest in this class of applications has grown dramatically in >> recent years and a routing solution addressing the specific >> environments of such networks is highly required considering the >> numerous, incompatible open-source and proprietary routing protocols >> as well as several industrial forums. The aim of this document is to >> define the routing requirements for Sensor Networks at the IP layer. >> Such routing protocol(s) would need to address several unique aspects >> of this class of embedded devices and would operate in networks >> comprising links of various nature. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-culler-rsn-routing-reqs-00. >> txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org >> with the word unsubscribe in the body of the message. >> You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then "get >> draft-culler-rsn-routing-reqs-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org . >> In the body type: >> "FILE /internet-drafts/draft-culler-rsn-routing-reqs-00.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this feature, >> insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or a >> MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with "multipart" >> MIME messages (i.e. documents which have been split up into multiple >> messages), so check your local documentation on how to manipulate >> these messages. >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> Content-Type: text/plain >> Content-ID: <2007-4-13132741.I-D@ietf.org >> > >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn > _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn ------=_NextPart_000_0043_01C78141.D52EA610 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable



-----Original Message-----
From: Tiago Camilo [mailto:tandre@dei.uc.pt]
Sent: = Tuesday,=20 April 17, 2007 5:35 AM
To: JP Vasseur
Cc: = rsn@ietf.org
Subject: Re:=20 [RSN] Fwd: I-D = ACTION:draft-culler-rsn-routing-reqs-00.txt

Hi,
Glad=20 to see WSN standard work in IETF.

I agree with Pascal comment = regarding=20 the terminology. I think that a terminology section helps to clarify = some=20 points in the ID. Terms such as sink, RFD and FFD are very common in = WSN=20 routing protocols, and should be IMO defined and used in the=20 text.

RFD and FFD have been defined with respect to specific = mechanisms in=20 IEEE 802.15.4, such as power management, beaconing, and the need to = "route" (in=20 the L2 sense) through a coordinator. I feel that is essential to = recognize and=20 utilize heterogeneity, but I am concerned about using those terms that = have a=20 specific technical meaning in IEEE 802.15.4 and certain industrial L2 = protocols=20 that run over it.


I think that is important in the introduction when you write = about=20 "Considering the variety of Sensor based applications" to refer that = in WSNs,=20 the routing protocol is somehow restricted by the application, meaning = it is=20 the application that defines if the protocol is time-driven, = event-driven or=20 hybrid.

I certainly understand that sensor applications may be = time-driven,=20 event-driven, or hybrid, and I can see that these apply to = forwarding.  It=20 is less clear that this defines the routing protocol.

In section 2.7, I believe that is important to say that = differently=20 from MANETs, WSNs communications are normally not made between = monitoring=20 sensors, meaning sensors normally communicate in point-to-point = fashion=20 only  with the sink and not with  others monitoring sensors = (i.e.=20 RFD), except in forwarding operations.

Although such collection = is indeed the=20 dominate traffic in typical usage, there are a number of useful cases = where=20 point-to-point occurs.  There are certainly cases where it make = sense for a=20 sensor reading to trigger or in some way be incorporated into the = readings or=20 actions of another sensor before being collected.  There are also = cases=20 where an individual sensor is queried or configured.  These need = not have a=20 geographic locality involved.  There are also a number of cases = where=20 geographic locality is essential, such as the combining a set of = readings=20 covering a certain region of space or a person interacting with nearby = sensors=20 through a handheld field unit.  So it does seem wise to attend to = how=20 different the traffic patterns are in this domain from = that which we=20 normally use to evaluate routing algorithms, but it is also important to = cover=20 the less common cases properly.



In section 2.9. I do not understand why the = phrase "MUST=20 support multi-topology routing in one form or another with different = degrees=20 of route optimization" is under the QoS topic. Moreover I suggest to = change=20 the keyword MUST to SHOULD, since in some applications scenarios, such = support=20 is not a requirement, i.e. habitat monitoring.

I agree.  It is probably premature to make MUST = determinations=20 at this stage of requirements definition.

Apart from QoS I feel = that is=20 necessary to say something about Security, which nowadays is a hot = topic in=20 WSNs. There are several ways to attack a WSN, and some use the routing = protocol leaks to perform DoS attacks, data hijacking, introduce radio = noise,=20 etc. Therefore I think its necessary to say that at least security = aspects=20 SHOULD be made.

It is important in section 2.10 to enhance that = is more=20 energy-efficient to process data locally then forward it, thats the = main=20 reason for data aggregation.


Regards,

Tiago=20 Camilo
University of Coimbra



JP Vasseur = wrote:
>=20 Hi,
>
> Glad to see a good number of people who signed up = to list=20 already.
> Here is the first revision of the requirements ID. = Feedbacks=20 most
> welcome of course !
>
> = Thanks.
>
> JP=20 and David.
>
> Begin forwarded = message:
>
>> *From:=20 *Internet-Drafts@ietf.org <mailto:Internet-Drafts@ietf.org<= /A>>
>>=20 *Date: *April 13, 2007 3:50:01 PM EDT
>> *To: = *i-d-announce@ietf.org=20 <mailto:i-d-announce@ietf.org>= ;
>>=20 *Subject: **I-D ACTION:draft-culler-rsn-routing-reqs-00.txt = *
>>=20 *Reply-To: *internet-drafts@ietf.org
>> <mailto:internet-drafts@ietf.org<= /A>>
>>
>>=20 A New Internet-Draft is available from the on-line = Internet-Drafts
>>=20 directories.
>>
>>
>> Title : Routing = Requirements=20 for Sensor Networks
>> Author(s) : D. Cullerot, J.=20 Vasseur
>> Filename :=20 draft-culler-rsn-routing-reqs-00.txt
>> Pages :
>> = Date :=20 2007-4-13
>>
>>    The need for high = quality=20 routing for Sensor networks comprised of
>>    = highly=20 constrained devices (CPU, memory, ...) in sometimes=20 unstable
>>    wireless environments is = critical now=20 and will continue to increase.
>>    Interest = in this=20 class of applications has grown dramatically = in
>>   =20 recent years and a routing solution addressing the=20 specific
>>    environments of such networks = is highly=20 required considering the
>>    numerous, = incompatible=20 open-source and proprietary routing = protocols
>>    as=20 well as several industrial forums.  The aim of this document is=20 to
>>    define the routing requirements for = Sensor=20 Networks at the IP layer.
>>    Such routing=20 protocol(s) would need to address several unique=20 aspects
>>    of this class of embedded = devices and=20 would operate in networks
>>    comprising = links of=20 various nature.
>>
>>
>> A URL for this=20 Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-culler-rsn-routing-reqs-00= .
>>=20 txt
>>
>> To remove yourself from the I-D = Announcement list,=20 send a message to
>> i-d-announce-request@ietf.org <mailto:i-d-announce-request= @ietf.org>
>>=20 with the word unsubscribe in the body of the message.
>> You = can also=20 visit
>> https://www1= .ietf.org/mailman/listinfo/I-D-announce
>>=20 to change your subscription settings.
>>
>> = Internet-Drafts=20 are also available by anonymous FTP. Login with the
>> = username=20 "anonymous" and a password of your e-mail address. After
>> = logging=20 in, type "cd internet-drafts" and then "get
>>=20 draft-culler-rsn-routing-reqs-00.txt".
>>
>> A list = of=20 Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html<= /A>=20 or
>> ftp://ftp.ietf.org/iet= f/1shadow-sites.txt
>>
>>=20 Internet-Drafts can also be obtained by = e-mail.
>>
>> Send a=20 message to:
>> mailserv@ietf.org <mailto:mailserv@ietf.org>.
&g= t;>=20 In the body type:
>> "FILE=20 = /internet-drafts/draft-culler-rsn-routing-reqs-00.txt".
>>
&g= t;>=20 NOTE: The mail server at ietf.org can return the document = in
>>=20 MIME-encoded form by using the "mpack" utility.  To use this=20 feature,
>> insert the command "ENCODING mime" before the=20 "FILE"
>> command.  To decode the response(s), you will = need=20 "munpack" or a
>> MIME-compliant mail reader.  Different = MIME-compliant mail readers
>> exhibit different behavior, = especially=20 when dealing with "multipart"
>> MIME messages (i.e. = documents which=20 have been split up into multiple
>> messages), so check your = local=20 documentation on how to manipulate
>> these=20 messages.
>>
>> Below is the data which will enable = a MIME=20 compliant mail reader
>> implementation to automatically = retrieve the=20 ASCII version of the
>> Internet-Draft.
>> = Content-Type:=20 text/plain
>> Content-ID:=20 <2007-4-13132741.I-D@ietf.org
>> <mailto:2007-4-13132741.I-D@i= etf.org>>
>>
>>=20 _______________________________________________
>> = I-D-Announce=20 mailing list
>> I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>= ;
>>=20 https://www1= .ietf.org/mailman/listinfo/i-d-announce
>
>=20 = ---------------------------------------------------------------------->=20 --
>
> = _______________________________________________
> RSN=20 mailing list
> RSN@ietf.org
> https://www1.ietf.org= /mailman/listinfo/rsn
>  


________________= _______________________________
RSN=20 mailing list
RSN@ietf.org
https://www1.ietf.org= /mailman/listinfo/rsn

 ------=_NextPart_000_0043_01C78141.D52EA610-- --===============1351099313== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============1351099313==-- From rsn-bounces@ietf.org Wed Apr 18 02:25:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He3c0-0003Ku-Hb; Wed, 18 Apr 2007 02:25:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He3by-0003JF-RE for rsn@ietf.org; Wed, 18 Apr 2007 02:25:50 -0400 Received: from wr-out-0506.google.com ([64.233.184.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He3bv-00042l-Hy for rsn@ietf.org; Wed, 18 Apr 2007 02:25:50 -0400 Received: by wr-out-0506.google.com with SMTP id 71so45410wri for ; Tue, 17 Apr 2007 23:25:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gm1spNF9a/COGOZHrvI4MSv5o8ghJ+pAf/BxTM8eQQRyZuZDTCex1BIRaRI5rOT9KFVh64S9OPIVTA0CwDxqQYnwGAxlqekHSSymKRrKEAdFUi8PQt5On/zf10ssoGoSSnfdQy1vLXrISFs8mLcJ7S/Z5KzN3AdA/PLaoypTVTE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rDnM4wCWzFcfd03+rVCJD8fBBp8N51ALV1hIZo7xByENuGlwKNRLXvXFBuEeldS62/3KpGnT/z8EYMYfLlWp3NNJg5Cnuj7HIaOm66rjEQbqvX+a4oPWmgUsqr3q/B8aYYg43MhMXTWRAccB5IU2Gwg7V1yHKLs/Q3hukT/EbcI= Received: by 10.115.78.1 with SMTP id f1mr86853wal.1176877546872; Tue, 17 Apr 2007 23:25:46 -0700 (PDT) Received: by 10.114.136.3 with HTTP; Tue, 17 Apr 2007 23:25:46 -0700 (PDT) Message-ID: Date: Wed, 18 Apr 2007 15:25:46 +0900 From: "Daniel Park" To: "JP Vasseur" Subject: Re: [RSN] Anyone interested to work on security for Sensor Routing ? In-Reply-To: <0DE20062-EA06-49BA-B4A6-0219572B275D@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0DE20062-EA06-49BA-B4A6-0219572B275D@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org JP and David, What's logic in this list ? Aren't you targeting for proposing a new BOF at upcoming Chicago IETF ? If yes, please keep the regular process in IETF. First, you should let us know the CHARTER of BOF including work scopes, deliverables to be considered and expecially relationship with others relevant WGs. As usual, PS (problem statements) is shown in the first step toward BOF. I am fine your energetic driving, but I am still not sure what this BOF want to archieve in IETF. FYI in case you missed it: http://www.watersprings.org/pub/id/draft-narten-successful-bof-02.txt RSN seems Routing Area. Why you need a security stuff in here ? Most concern in my mind is how to coordinate with 6lowpan (INT Area) stuffs. You want to take over all of 6lowpan stuffs except the current deliverables ? Also, as you definitely know, I am working for 6lowpan security analysis with several folks. I don't think you want to spoil all of our efforts. -- Daniel Park On 4/18/07, JP Vasseur wrote: > Dear list members, > > I guess that we all agree on the fact Routing Security is a > particularly important topics for Sensor Networks. There is another > key topic that we'd like to address: manageability (in a separate > thread). > > David and I decided to work soon on the security aspects; that said, > if there are security experts on this list willing to help out, > please let us know (let's use the list also). > > We could also ask to the security AD to see whether they could > appoint security experts. > > Thanks. > > JP. > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn > -- Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Wed Apr 18 09:19:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeA4b-0003Ql-4H; Wed, 18 Apr 2007 09:19:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeA4a-0003Qg-E5 for rsn@ietf.org; Wed, 18 Apr 2007 09:19:48 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeA4X-00018Z-Tr for rsn@ietf.org; Wed, 18 Apr 2007 09:19:48 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Apr 2007 09:19:45 -0400 X-IronPort-AV: i="4.14,422,1170651600"; d="scan'208,217"; a="118829375:sNHT98144480" 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 l3IDJjSg003960; Wed, 18 Apr 2007 09:19:45 -0400 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 l3IDJHHH015497; Wed, 18 Apr 2007 13:19:45 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 09:19:39 -0400 Received: from [64.102.165.11] ([10.82.224.50]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 09:19:38 -0400 In-Reply-To: References: <0DE20062-EA06-49BA-B4A6-0219572B275D@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <6CBCE339-005E-4B90-AD44-CE1FD1BCCE57@cisco.com> From: JP Vasseur Subject: Re: [RSN] Anyone interested to work on security for Sensor Routing ? Date: Wed, 18 Apr 2007 09:19:34 -0400 To: Daniel Park X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 18 Apr 2007 13:19:38.0874 (UTC) FILETIME=[37866DA0:01C781BC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12238; t=1176902385; x=1177766385; 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[RSN]=20Anyone=20interested=20to=20work=20on=20securi ty=20for=20Sensor=20Routing=20? |Sender:=20 |To:=20Daniel=20Park=20; bh=KYxYJFUFXK0gtpqPF4cZLqyPJuxiCAHgzhgaCP8ncvE=; b=NoyLMK5v9HDtyjRLSosclw2S9kH0GVBtBujl9MGTdWnOGS36YxYvJigQI/YCOaPFKYnOSs9D F3i4Bdd+H3ebHlyY4t+BN5Zoe9QprWvDUzcfHrj99BZrpHnf583GJTi6; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0267277998==" Errors-To: rsn-bounces@ietf.org --===============0267277998== Content-Type: multipart/alternative; boundary=Apple-Mail-105-1026678904 --Apple-Mail-105-1026678904 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Daniel, On Apr 18, 2007, at 2:25 AM, Daniel Park wrote: > JP and David, > > What's logic in this list ? Aren't you targeting for proposing a new > BOF at upcoming Chicago IETF ? If yes, please keep the regular process > in IETF. First, you should let us know the CHARTER of BOF including > work scopes, deliverables to be considered and expecially relationship > with others relevant WGs. As usual, PS (problem statements) is shown > in the first step toward BOF. I am fine your energetic driving, but I > am still not sure what this BOF want to archieve in IETF. > FYI in case you missed it: > http://www.watersprings.org/pub/id/draft-narten-successful-bof-02.txt > > RSN seems Routing Area. Why you need a security stuff in here ? Most > concern in my mind is how to coordinate with 6lowpan (INT Area) > stuffs. You want to take over all of 6lowpan stuffs except the current > deliverables ? > > Also, as you definitely know, I am working for 6lowpan security > analysis with several folks. I don't think you want to spoil all of > our efforts. > Apparently you look confused: please read the title: Security for Sensor Routing ! No the goal of this list is *not* to discuss any item not related to routing. The idea was to find people interested by some work on security for the routing protocols, which is part of the problem statement/routing requirements. Thanks for the reminder on how to proceed at the IETF, I think that I'm very much aware of the process. Yes there will be a BOF proposal, which may or may not be approved by the routing ADs. The next step will be to send the BOF proposal on this list and others. Does that clarify ? Thanks. JP. > -- Daniel Park > > On 4/18/07, JP Vasseur wrote: >> Dear list members, >> >> I guess that we all agree on the fact Routing Security is a >> particularly important topics for Sensor Networks. There is another >> key topic that we'd like to address: manageability (in a separate >> thread). >> >> David and I decided to work soon on the security aspects; that said, >> if there are security experts on this list willing to help out, >> please let us know (let's use the list also). >> >> We could also ask to the security AD to see whether they could >> appoint security experts. >> >> Thanks. >> >> JP. >> >> _______________________________________________ >> RSN mailing list >> RSN@ietf.org >> https://www1.ietf.org/mailman/listinfo/rsn >> > > > -- > > > Daniel (Soohong Daniel Park) > Mobile Convergence Laboratory, SAMSUNG Electronics. --Apple-Mail-105-1026678904 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Daniel,

On = Apr 18, 2007, at 2:25 AM, Daniel Park wrote:

JP and David,

What's logic in this list ? = Aren't you targeting for proposing a new
BOF at = upcoming Chicago IETF ? If yes, please keep the regular = process
in IETF. First, you should let = us know the CHARTER of BOF including
work scopes, = deliverables to be considered and expecially relationship
with others relevant WGs. As usual, PS (problem = statements) is shown
in the first step toward = BOF. I am fine your energetic driving, but I
am still not sure what this BOF want to archieve in = IETF.
FYI in case you missed = it:

RSN seems Routing Area. Why you need a security = stuff in here ? Most
concern in my mind is how = to coordinate with 6lowpan (INT Area)
stuffs. = You want to take over all of 6lowpan stuffs except the current
deliverables ?

Also, as you definitely know, I = am working for 6lowpan security
analysis with = several folks. I don't think you want to spoil all of
our efforts.


Apparently you look confused: please read the = title: Security for Sensor Routing !
No the goal = of this list is *not* to discuss any item not related to routing. The = idea was to find people
interested by some work on security = for the routing protocols, which is part of the problem = statement/routing
requirements.
Thanks for the = reminder on how to proceed at the IETF, I think that I'm very much aware = of the process.
Yes there will be a BOF proposal, which may or = may not be approved by the routing ADs. The next step will be to send = the=A0BOF proposal on this list and others.

Does that clarify = ?

Thanks.

JP.

-- Daniel Park

On 4/18/07, JP Vasseur <jvasseur@cisco.com> = wrote:
Dear list = members,

I guess that we all agree on the fact Routing = Security is a
particularly important topics = for Sensor Networks. There is another
key = topic that we'd like to address: manageability (in a separate
thread).

David and I decided to work soon = on the security aspects; that said,
if there are = security experts on this list willing to help out,
please let us know (let's use the list = also).

We could also ask to the security AD to see whether = they could
appoint security = experts.

Thanks.

JP.

RSN mailing list



--=A0


Daniel (Soohong Daniel = Park)
Mobile Convergence Laboratory, = SAMSUNG Electronics.

= --Apple-Mail-105-1026678904-- --===============0267277998== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============0267277998==-- From rsn-bounces@ietf.org Wed Apr 18 10:23:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeB4T-0005C7-Pu; Wed, 18 Apr 2007 10:23:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeB4T-0005C1-10 for rsn@ietf.org; Wed, 18 Apr 2007 10:23:45 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeB4R-0002az-NF for rsn@ietf.org; Wed, 18 Apr 2007 10:23:45 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Apr 2007 10:23:43 -0400 X-IronPort-AV: i="4.14,423,1170651600"; d="scan'208"; a="118836842:sNHT61241348" 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 l3IENhMb013474; Wed, 18 Apr 2007 10:23:43 -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 l3IENHlq023659; Wed, 18 Apr 2007 14:23:43 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 10:23:35 -0400 Received: from [64.102.165.11] ([10.82.224.50]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 10:23:35 -0400 In-Reply-To: <462500CA.4050506@eecs.berkeley.edu> References: <4E21EAEE-F7AC-4424-A157-BFEECBBA7761@cisco.com> <4624BEDF.2010500@dei.uc.pt> <462500CA.4050506@eecs.berkeley.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6B61FED3-B436-48EE-BB08-E4A08793926B@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [RSN] Fwd: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt Date: Wed, 18 Apr 2007 10:23:33 -0400 To: Kris Pister X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 18 Apr 2007 14:23:35.0311 (UTC) FILETIME=[263841F0:01C781C5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2776; t=1176906223; x=1177770223; 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[RSN]=20Fwd=3A=20I-D=20ACTION=3Adraft-culler-rsn-rout ing-reqs-00.txt |Sender:=20 |To:=20Kris=20Pister=20; bh=g0fAL6nLiNWPTYL0PJOGS1BGQhH/1Mj1uoWToNdAnNM=; b=EbmUvYdSsQCm1XQGHGw1yjgl0LJY3kF2lZb4f11X+JXl2pPqOb4VADvR3Bb+S6uiOQzvCZLZ eUE1/FKiwksmsMQaLxqRZcImLhZCPQpmtA6ZYZk0pE3ZlP+Vfgqrj5tl; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org On Apr 17, 2007, at 1:15 PM, Kris Pister wrote: > This is an excellent start. > Thanks, still require significant work, but we should collectively be able to come up with a good set of requirements, important before moving to the protocol design. > Tiago Camilo wrote: >> [...] >> In section 2.7, I believe that is important to say that >> differently from MANETs, WSNs communications are normally not made >> between monitoring sensors, meaning sensors normally communicate >> in point-to-point fashion only with the sink and not with others >> monitoring sensors (i.e. RFD), except in forwarding operations. > Hmmm. I'm concerned that people are spending too much time > worrying about RFDs. Have you seen one? Is anyone shipping/ > installing/configuring any? I don't think that RFDs are likely to > be a part of the WSN future. If anything, technology will push us > to FFDs and EMFFDs (even more full function devices :) ). Yes, by the way, let's avoid Zigbee terminology here ;-) > Regarding communication flow, I think that 2.7 reads well as it > stands. It calls out that any-to-any does happen sometimes, but > often the flows are very different, including aggregation, > dissemination, and local multi-hop to another mote. Right. >> >> [...] >> >> Apart from QoS I feel that is necessary to say something about >> Security, which nowadays is a hot topic in WSNs. There are several >> ways to attack a WSN, and some use the routing protocol leaks to >> perform DoS attacks, data hijacking, introduce radio noise, etc. >> Therefore I think its necessary to say that at least security >> aspects SHOULD be made. > I agree. >> >> It is important in section 2.10 to enhance that is more energy- >> efficient to process data locally then forward it, thats the main >> reason for data aggregation. >> > As it turns out, it is often *not* more energy-efficient to process > data locally than forward it, at least not in terms of what is > sometimes called distributed signal processing. Compressing your > own data stream is great. Payload concatenation/aggregation is > great. Processing your neighbor's payload introduces other > security concerns. I think that 2.10 is fine the way it is. It's > clear that some times this will be useful - do we need to enumerate > the reasons why? I don't think so ... as long as we state the requirement. Thanks. JP. >> >> Regards, >> >> Tiago Camilo >> University of Coimbra >> >> > ksjp > -- > Prof. EECS, UC Berkeley > Founder & CTO, Dust Networks > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Wed Apr 18 10:42:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBMZ-000876-M6; Wed, 18 Apr 2007 10:42:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBMY-00086v-70 for rsn@ietf.org; Wed, 18 Apr 2007 10:42:26 -0400 Received: from wr-out-0506.google.com ([64.233.184.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeBMU-0000ff-SU for rsn@ietf.org; Wed, 18 Apr 2007 10:42:26 -0400 Received: by wr-out-0506.google.com with SMTP id 71so155564wri for ; Wed, 18 Apr 2007 07:42:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UsUGXbCvMXMEyH3FqM9r6dXj8jqzg4VkjakEJr70SafTxcAFW1d2c8WL+mJ0xTYrCM3in5+fQ6wOmO9YPKo+PwHm20l8pnDA+LcAFnNZOrbZasEU8Q9lFmzjmSI465/VJ+oxddYM4swuYILM+OIGRTSLEQtjIzTt9mCDOrBpa8k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GNM38+6DycpwqFua1PEP1KzwjDy6YcUUGDSJwtSNr/23xLlnn/A8dAQyUYnM9hJM+P2u2EWVIcuWt2VOVA1iF/XVGDJaGix8m0tpR96TcnWeb7jTqHnAvm5tgHsnlolu6vJF5FxGcuk6PeJ4d3J1afOiwWGGg/WbJEe9vYvGpD0= Received: by 10.114.185.8 with SMTP id i8mr253465waf.1176907342011; Wed, 18 Apr 2007 07:42:22 -0700 (PDT) Received: by 10.114.136.3 with HTTP; Wed, 18 Apr 2007 07:42:21 -0700 (PDT) Message-ID: Date: Wed, 18 Apr 2007 23:42:21 +0900 From: "Daniel Park" To: "JP Vasseur" Subject: Re: [RSN] Anyone interested to work on security for Sensor Routing ? In-Reply-To: <6CBCE339-005E-4B90-AD44-CE1FD1BCCE57@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0DE20062-EA06-49BA-B4A6-0219572B275D@cisco.com> <6CBCE339-005E-4B90-AD44-CE1FD1BCCE57@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Ok JP, I am looking forward to seeing an official charter of BOF at this stage. And...are you really thinking that I was confused ? ...Sigh. -- Daniel Park On 4/18/07, JP Vasseur wrote: > Hi Daniel, > > > On Apr 18, 2007, at 2:25 AM, Daniel Park wrote: > > JP and David, > > What's logic in this list ? Aren't you targeting for proposing a new > BOF at upcoming Chicago IETF ? If yes, please keep the regular process > in IETF. First, you should let us know the CHARTER of BOF including > work scopes, deliverables to be considered and expecially relationship > with others relevant WGs. As usual, PS (problem statements) is shown > in the first step toward BOF. I am fine your energetic driving, but I > am still not sure what this BOF want to archieve in IETF. > FYI in case you missed it: > http://www.watersprings.org/pub/id/draft-narten-successful-bof-02.txt > > RSN seems Routing Area. Why you need a security stuff in here ? Most > concern in my mind is how to coordinate with 6lowpan (INT Area) > stuffs. You want to take over all of 6lowpan stuffs except the current > deliverables ? > > Also, as you definitely know, I am working for 6lowpan security > analysis with several folks. I don't think you want to spoil all of > our efforts. > > > Apparently you look confused: please read the title: Security for Sensor > Routing ! > No the goal of this list is *not* to discuss any item not related to > routing. The idea was to find people > interested by some work on security for the routing protocols, which is part > of the problem statement/routing > requirements. > Thanks for the reminder on how to proceed at the IETF, I think that I'm very > much aware of the process. > Yes there will be a BOF proposal, which may or may not be approved by the > routing ADs. The next step will be to send the BOF proposal on this list and > others. > > Does that clarify ? > > Thanks. > > JP. > > -- Daniel Park > > On 4/18/07, JP Vasseur wrote: > Dear list members, > > I guess that we all agree on the fact Routing Security is a > particularly important topics for Sensor Networks. There is another > key topic that we'd like to address: manageability (in a separate > thread). > > David and I decided to work soon on the security aspects; that said, > if there are security experts on this list willing to help out, > please let us know (let's use the list also). > > We could also ask to the security AD to see whether they could > appoint security experts. > > Thanks. > > JP. > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn > > > > -- > > > Daniel (Soohong Daniel Park) > Mobile Convergence Laboratory, SAMSUNG Electronics. > _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Wed Apr 18 15:12:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeFZU-0004AW-Ef; Wed, 18 Apr 2007 15:12:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeFZS-0004AB-8q for rsn@ietf.org; Wed, 18 Apr 2007 15:12:02 -0400 Received: from wr-out-0506.google.com ([64.233.184.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeFZR-0002Wa-0k for rsn@ietf.org; Wed, 18 Apr 2007 15:12:02 -0400 Received: by wr-out-0506.google.com with SMTP id 71so239830wri for ; Wed, 18 Apr 2007 12:12:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Yw1Ra1WZd+HrZJh7kJfr44ku2WrbJGO4ggzcyzzuqWNdl4mldKpbg+rI6j0bx6oIBOrHm8aiwowuNxulPzRbgASC49NHREF3FGk21CO7xEqE2zgFmu9fOil1CwBQK23NeCTbxqIoPejnsggErmIcNxiLK65Xkn0ViK6EHlkG8OE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=GVUOMBkHU9bHi09X6sFf4ZrxR8qZls/hY+t1Vcw0FFPnSuTmPE1CkXFMrNUKm6IlWCm+Y+SkIOHpWok+p67Kvw37j8BHThM776ALredLqVHfrsWAPiEBmmAeGZ0K56/iaImzXVMhUizGxBBFxC7t1bcN2STeNbeeO1xW6bgAMfQ= Received: by 10.114.78.1 with SMTP id a1mr385607wab.1176923519915; Wed, 18 Apr 2007 12:11:59 -0700 (PDT) Received: by 10.114.14.13 with HTTP; Wed, 18 Apr 2007 12:11:59 -0700 (PDT) Message-ID: <13786f330704181211g3c7d0b26y21942ece233b10a4@mail.gmail.com> Date: Wed, 18 Apr 2007 15:11:59 -0400 From: "Joseph Kopena" To: rsn@ietf.org Subject: Re: [RSN] Anyone interested to work on security for Sensor Routing ? In-Reply-To: <6CBCE339-005E-4B90-AD44-CE1FD1BCCE57@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0DE20062-EA06-49BA-B4A6-0219572B275D@cisco.com> <6CBCE339-005E-4B90-AD44-CE1FD1BCCE57@cisco.com> X-Google-Sender-Auth: 4128a81c147560d3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org On 4/18/07, JP Vasseur wrote: > Apparently you look confused: please read the title: Security for Sensor > Routing ! > No the goal of this list is *not* to discuss any item not related to > routing. The idea was to find people > interested by some work on security for the routing protocols, which is part > of the problem statement/routing > requirements. This statement is actually fairly confusing---is the goal of the list to discuss general considerations in routing for sensor networks (including presumably differentiation from existing efforts), or security? I think you meant to say this thread, as opposed to this list, is for discussing security, but that is not clear. Certainly nothing previously implied that the list focus was on security. This would be good to clarify. Thx -- - joe kopena right here and now _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Wed Apr 18 15:15:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeFcv-0006KT-2m; Wed, 18 Apr 2007 15:15:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeFcu-0006KK-EY for rsn@ietf.org; Wed, 18 Apr 2007 15:15:36 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HeFcs-0002LH-1Y for rsn@ietf.org; Wed, 18 Apr 2007 15:15:36 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Apr 2007 15:15:34 -0400 X-IronPort-AV: i="4.14,423,1170651600"; d="scan'208"; a="118863120:sNHT47280640" 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 l3IJFXMd006749; Wed, 18 Apr 2007 15:15:33 -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 l3IJFXlG000924; Wed, 18 Apr 2007 19:15:33 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 15:15:33 -0400 Received: from [64.102.165.11] ([10.82.240.212]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 15:15:33 -0400 In-Reply-To: <13786f330704181211g3c7d0b26y21942ece233b10a4@mail.gmail.com> References: <0DE20062-EA06-49BA-B4A6-0219572B275D@cisco.com> <6CBCE339-005E-4B90-AD44-CE1FD1BCCE57@cisco.com> <13786f330704181211g3c7d0b26y21942ece233b10a4@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6259CB4E-1385-45F3-A3CD-B1FF6CFD90BF@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [RSN] Anyone interested to work on security for Sensor Routing ? Date: Wed, 18 Apr 2007 15:15:31 -0400 To: Joseph Kopena X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 18 Apr 2007 19:15:33.0036 (UTC) FILETIME=[EF98F6C0:01C781ED] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1359; t=1176923733; x=1177787733; 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[RSN]=20Anyone=20interested=20to=20work=20on=20securi ty=20for=20Sensor=20Routing=20? |Sender:=20 |To:=20Joseph=20Kopena=20; bh=tAZffIAGvBezVYIn3OE+V+UnJC0qZLc7BB9EfesPSvk=; b=0baqTcd8ZsqWtZEKQVmaEi21bOVpIYYQtzXWQmnJ3SEZWwD97iV3KB8vREoILtjALRkjLR2O bsSWFjFKq7kHrgDSkaTkWOBwttWrNLPs0hHz3GhNJaWvEj9yLOZudjMe; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi Joseph, On Apr 18, 2007, at 3:11 PM, Joseph Kopena wrote: > On 4/18/07, JP Vasseur wrote: >> Apparently you look confused: please read the title: Security for >> Sensor >> Routing ! >> No the goal of this list is *not* to discuss any item not related to >> routing. The idea was to find people >> interested by some work on security for the routing protocols, >> which is part >> of the problem statement/routing >> requirements. > > This statement is actually fairly confusing---is the goal of the list > to discuss general considerations in routing for sensor networks > (including presumably differentiation from existing efforts), Yes. > or > security? I think you meant to say this thread, as opposed to this > list, is for discussing security, but that is not clear. Certainly > nothing previously implied that the list focus was on security. This > would be good to clarify. > Sure let me try to clarify again: the ML only focusses on routing issues. A particular item relates to the security issues for the routing protocol to which we were looking for contributors. Thanks. JP. > Thx > > -- > - joe kopena > right here and now > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Wed Apr 18 15:30:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeFrE-0000bX-H3; Wed, 18 Apr 2007 15:30:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeFrD-0000ag-3W for rsn@ietf.org; Wed, 18 Apr 2007 15:30:23 -0400 Received: from wr-out-0506.google.com ([64.233.184.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeFrB-00016y-Tp for rsn@ietf.org; Wed, 18 Apr 2007 15:30:23 -0400 Received: by wr-out-0506.google.com with SMTP id 71so244804wri for ; Wed, 18 Apr 2007 12:30:21 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Vo6oOzJDACU82Tueph8SdLYskUPpo+cGWp9/sUyGiCsjp3nb225M7OcJi/yPj3JeeOFJUEsnzCUj5iHEdtCoaxvnkU+W4c8po78h2b8KJCEcYQHuNJGTLZ163QR9sQbZOxMqucIrjqfPCjIABcq5NndUPRQJ2BUtzuhpovM/Osk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=k3V0qbHw1yY4NgAOL3AAnmzEtcqCx7Qq46H35lBt2GUvnwhfd19QTwf8u6CW/P0Q3P9hIvRagNKmCZ8dFFcfAqNEY1Cguw4fA464x4n1s+EZJElAZAKLjmiEKwqNJyPOcfj11r+nWCGGq7gYoR/JNrXwAxoh209786vFqHzEtEc= Received: by 10.114.185.8 with SMTP id i8mr381656waf.1176924621232; Wed, 18 Apr 2007 12:30:21 -0700 (PDT) Received: by 10.114.14.13 with HTTP; Wed, 18 Apr 2007 12:30:21 -0700 (PDT) Message-ID: <13786f330704181230w73fa2eceg1d07d84dc6c9a703@mail.gmail.com> Date: Wed, 18 Apr 2007 15:30:21 -0400 From: "Joseph Kopena" To: rsn@ietf.org Subject: Re: [RSN] Anyone interested to work on security for Sensor Routing ? In-Reply-To: <6259CB4E-1385-45F3-A3CD-B1FF6CFD90BF@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0DE20062-EA06-49BA-B4A6-0219572B275D@cisco.com> <6CBCE339-005E-4B90-AD44-CE1FD1BCCE57@cisco.com> <13786f330704181211g3c7d0b26y21942ece233b10a4@mail.gmail.com> <6259CB4E-1385-45F3-A3CD-B1FF6CFD90BF@cisco.com> X-Google-Sender-Auth: 042d38acea6e0a6d X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org On 4/18/07, JP Vasseur wrote: > Sure let me try to clarify again: the ML only focusses on routing > issues. A particular item relates to > the security issues for the routing protocol to which we were looking > for contributors. Great; thanks for the clarification! -- - joe kopena right here and now _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu Apr 19 03:22:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeQy4-0007wq-Ff; Thu, 19 Apr 2007 03:22:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeQy3-0007wj-OS for rsn@ietf.org; Thu, 19 Apr 2007 03:22:11 -0400 Received: from seowon.ajou.ac.kr ([202.30.0.18] helo=mail.ajou.ac.kr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HeQy1-0007nK-NO for rsn@ietf.org; Thu, 19 Apr 2007 03:22:11 -0400 Received: from ajou.ac.kr (127.0.0.1) by mail.ajou.ac.kr with ESMTP imoxion SensMail SmtpServer 5.0 id <46271c693fe502068df3f5a3> for from ; Thu, 19 Apr 2007 16:22:10 +0900 Message-ID: <462719d93f7e@imoxion.com> Date: Thu, 19 Apr 2007 16:22:12 +0900 (KST) From: Zeeshan Hameed Mir To: manet@ietf.org, rsn@ietf.org, tccc@cs.columbia.edu, 6lowpan@lists.ietf.org, dbworld-request@cs.wisc.edu MIME-Version: 1.0 X-Priority: 3 X-Spam-Score: 1.6 (+) X-Scan-Signature: 111b48b3edee1f6fe0a892c95423c18d Cc: Subject: [RSN] CFP: USN 2007 - Workshop X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1809740723==" Errors-To: rsn-bounces@ietf.org --===============1809740723== Content-Type: multipart/alternative; boundary="----=_Part_1216785_27937050.1176967332780" ------=_Part_1216785_27937050.1176967332780 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 KlNvcnJ5IGZvciByZWNlaXZpbmcgbXVsdGlwbGUgY29waWVzKg0KIA0KPT09PT09PT09PT09PT09 PT09PT09PT09PT0NCkNhbGwgZm9yIFBhcGVycyBmb3IgVVNOIDIwMDcNCj09PT09PT09PT09PT09 PT09PT09PT09PT09DQooVGhlIDNyZCBJbnRlcm5hdGlvbmFsIFdvcmtzaG9wIG9uIFJGSUQgYW5k IFViaXF1aXRvdXMgU2Vuc29yIE5ldHdvcmtzIChVU04pIEluIGNvbmp1bmN0aW9uIHdpdGggdGhl IEVVQyAyMDA3DQpodHRwOi8vdW5zLmFqb3UuYWMua3IvfnVzbjIwMDcvLCBEZWNlbWJlciAxNy0y MCwgMjAwNywgVGFpcGVpLCBUYWl3YW4pDQogDQo9PT09PT09PT09PT09PT09PT09PT09PT09PQ0K KioqIEltcG9ydGFudCBEYXRlcyAqKioNCj09PT09PT09PT09PT09PT09PT09PT09PT09DQpTdWJt aXNzaW9uIER1ZTogTWF5IDE3LCAyMDA3IA0KQWNjZXB0YW5jZSBub3RpZmljYXRpb246IEF1Z3Vz dCA2LCAyMDA3IA0KQ2FtZXJhLXJlYWR5IGR1ZTogU2VwdGVtYmVyIDQsIDIwMDcgDQogDQo9PT09 PT09PT09PT09PT09PT09PT09PT09PQ0KQmFja2dyb3VuZA0KPT09PT09PT09PT09PT09PT09PT09 PT09PT0NClRoZSBwdXJwb3NlIG9mIFVTTiAyMDA3IGlzIHRvIGVzdGFibGlzaCBhIGRpc2N1c3Np b24gZnJhbWV3b3JrIG9uIGFsbCB0aGUgY2hhbGxlbmdlcyByYWlzZWQgZnJvbSB0aGUgZXZvbHV0 aW9uIG9mIHRoZSBVYmlxdWl0b3VzIFNlbnNvciBOZXR3b3JrcyBhbmQgUkZJRCB0ZWNobm9sb2dp ZXMuIEFzIGEgdW5pcXVlIG9wcG9ydHVuaXR5IHRvIG9idGFpbiBhbiBpbnNpZ2h0IG9uIHRoZSBs ZWFkaW5nIHRlY2hub2xvZ2llcyBvZiB0aGUgbmV4dCBwZXJ2YXNpdmUgZXJhLCBVU04gMjAwNyB3 YW50cyB0byBpbnZpdGUgcmVzZWFyY2hlcnMgdG8gcHJlc2VudCBhbmQgZGlzY3VzcyB0aGVpciBp ZGVhcy4gDQoNClRvcGljcyBvZiB0aGlzIHdvcmtzaG9wIGluY2x1ZGUsIGJ1dCBhcmUgbm90IGxp bWl0ZWQgdG86IA0KIA0KoaQgICAgICAgICBSRklEIFN5c3RlbXMgYW5kIEFyY2hpdGVjdHVyZSAN CqGkICAgICAgICAgUkZJRCBNaWRkbGV3YXJlIERlc2lnbiANCqGkICAgICAgICAgQW50aS1jb2xs aXNpb24gYWxnb3JpdGhtcyANCqGkICAgICAgICAgTW9iaWxlIFJGSUQgU3lzdGVtcyBhbmQgQXBw bGljYXRpb25zIA0KoaQgICAgICAgICBEYXRhIE1vZGVsaW5nIGFuZCBNYW5hZ2VtZW50IA0KoaQg ICAgICAgICBFbWJlZGRlZCBSRklELWVuYWJsZWQgRGV2aWNlIFRlY2hub2xvZ3kgDQqhpCAgICAg ICAgIFNlbnNvciBOZXR3b3JrIEFyY2hpdGVjdHVyZXMgYW5kIFByb3RvY29scyANCqGkICAgICAg ICAgTmV0d29yayBwcm90b2NvbHMsIGUuZy4sIE1BQyBhbmQgcm91dGluZyANCqGkICAgICAgICAg RGlzdHJpYnV0ZWQgQWxnb3JpdGhtcywgZS5nLiwgTG9jYWxpemF0aW9uIGFuZCBTeW5jaHJvbml6 YXRpb24gDQqhpCAgICAgICAgIENyb3NzIExheWVyIGFuZCBFbmVyZ3kgRWZmaWNpZW50IERlc2ln biANCqGkICAgICAgICAgVVNOIE1pZGRsZXdhcmUgSXNzdWVzLCBlLmcuLCBPUyBhbmQgRGF0YWJh c2UgDQqhpCAgICAgICAgIENvZXhpc3RlbmNlIG9mIFJGSUQgJiBVU04gDQqhpCAgICAgICAgIFFv UyBhbmQgUmVhbC1UaW1lIElzc3VlcyANCqGkICAgICAgICAgU2VjdXJpdHkgYW5kIHByaXZhY3kg aXNzdWVzIA0KoaQgICAgICAgICBOZXR3b3JrIE1hbmFnZW1lbnQgaW4gTGFyZ2Utc2NhbGUgRGVw bG95bWVudCANCqGkICAgICAgICAgQ29leGlzdGVuY2Ugb2YgUkZJRCAmIFVTTiANCqGkICAgICAg ICAgTm92ZWwgUkZJRCBhbmQgVVNOIEFwcGxpY2F0aW9ucyANCiANCldvcmtzaG9wIENvLUNoYWly cw0KPT09PT09PT09PT09PT09PT09PT09PT09PT0NCllvdW5nLUJhZSBLbywgQWpvdSBVbml2ZXJz aXR5LCBLb3JlYSANCkthbmctV29uIExlZSwgSUJNIFQuSiBXYXRzb24gUmVzZWFyY2gsIFVTQQ0K IA0KIA0KU3RlZXJpbmcgQ29tbWl0dGVlIA0KPT09PT09PT09PT09PT09PT09PT09PT09PT0NCkpv bmdzdWsgQ2hhZSwgRVRSSSwgS29yZWENClNldW5nLVdoYSBZb28sIEFqb3UgVW5pdmVyc2l0eSwg S29yZWENCll1LUNoZWUgVHNlbmcsIE5hdGlvbmFsIENoaWFvIFR1bmcgVW5pdi4sIFRhaXdhbg0K RGFleW91bmcgS2ltLCBJbmZvcm1hdGlvbiBhbmQgQ29tbXVuaWNhdGlvbnMgVW5pdmVyc2l0eSwg S29yZWENCiANClByb2dyYW0gQ29tbWl0dGVlDQo9PT09PT09PT09PT09PT09PT09PT09PT09PQ0K Qnl1bmdodW4gU29uZywgS0VUSSwgS29yZWENCkNoYW5zdSBZdSwgQ2xldmVsYW5kIFN0YXRlIFVu aXZlcnNpdHksIFVTQQ0KQ2hpaC1ZdW5nIENoYW5nLCBUYW1rYW5nIFVuaXZlcnNpdHksIFRhaXdh bg0KRG9uZy1LeXVuIEtpbSwgS3l1bmdwb29rIE5hdGlvbmFsIFVuaXZlcnNpdHksIEtvcmVhDQpK YWUtSHl1biBLaW0sIEFqb3UgVW5pdmVyc2l0eSwgS29yZWENCkphdmllciBHb21leiwgTmF0aW9u YWwgVW5pdmVyc2l0eSBvZiBNZXhpY28sIE1leGljbw0KS2FuZy1Xb24gTGVlLCBJQk0gVC5KIFdh dHNvbiBSZXNlYXJjaCwgVVNBDQpLdWkgV3UsIFVuaXZlcnNpdHkgb2YgVmljdG9yaWEsIENhbmFk YQ0KTGluZy1KeWggQ2hlbiwgSW5zdGl0dXRlIG9mIEluZm9ybWF0aW9uIFNjaWVuY2UsIFRhaXdh bg0KTWluZW8gVGFrYWksIFVDTEEsIFVTQQ0KTWluZy1KZXIgVHNhaSwgTmF0aW9uYWwgVHNpbmct SHVhIFVuaXYuLCBUYWl3YW4NCk1pc2NoYSBEb2hsZXIsIEZyYW5jZSBUZWxlY29tLCBGcmFuY2UN Ck1vaGFtZWQgWW91bmlzLCBVbml2ZXJzaXR5IG9mIE1hcnlsYW5kLCBVU0ENCk96Z3VyIEVyY2V0 aW4sIFNhYmFuY2kgVW5pdmVyc2l0eSwgVHVya2V5DQpTYWFkIEJpYXosIEF1YnVybiBVbml2ZXJz aXR5LCBVU0ENClRhZWt5dW5nIEt3b24sIFNlb3VsIE5hdGlvbmFsIFVuaXZlcnNpdHksIEtvcmVh DQpUYWUtSmluIExlZSwgU3VuZ2t5dW5rd2FuIFVuaXZlcnNpdHksIEtvcmVhDQpZdWgtU2h5YW4g Q2hlbiwgTmF0aW9uYWwgQ2h1bmcgQ2hlbmcgVW5pdmVyc2l0eSwgVGFpd2FuDQpXZWkgTG91LCBI b25nIEtvbmcgUG9seXRlY2huaWMgVW5pdmVyc2l0eSwgQ2hpbmENCldlbi1DaGloIFBlbmcsIE5h dGlvbmFsIENoaWFvIFR1bmcgVW5pdi4sIFRhaXdhbg0KV29uanVuIExlZSwgS29yZWEgVW5pdmVy c2l0eSwgS29yZWENCg0K ------=_Part_1216785_27937050.1176967332780 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PHN0eWxlIHR5cGU9J3RleHQvY3NzJz4gUCB7cGFkZGluZzowcHg7IG1hcmdp bjoycHg7IGJvcmRlcjowcHg7Zm9udC1zaXplOjEzcHg7Zm9udC1mYW1pbHk6J2FyaWFsJzt9ICBi b2R5IHtwYWRkaW5nOjVweDsgbWFyZ2luOjBweDsgYm9yZGVyOjBweDtmb250LXNpemU6MTNweDtm b250LWZhbWlseTonYXJpYWwnO30gPC9zdHlsZT48L2hlYWQ+PGJvZHk+PHRhYmxlIHdpZHRoPTk5 JSBhbGlnbj1jZW50ZXIgaGVpZ2h0PScxMDAnPjx0ciB2YWxpZ249dG9wPjx0ZD48Zm9udCBzaXpl PTI+PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0Ij48U1BBTiBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxh bmd1YWdlOiBLTyI+KlNvcnJ5IGZvciByZWNlaXZpbmcgbXVsdGlwbGUgY29waWVzKjw/eG1sOm5h bWVzcGFjZSBwcmVmaXggPSBvIG5zID0gInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNl Om9mZmljZSIgLz48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQiPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZP TlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj48bzpwPiZuYnNwOzwv bzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBp biAwcHQiPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsg bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj49PT09PT09PT09PT09PT09PT09PT09PT09PTxvOnA+ PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4g MGluIDBwdCI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGlt OyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPkNhbGwgZm9yIFBhcGVycyBmb3IgVVNOIDIwMDc8 QlI+PT09PT09PT09PT09PT09PT09PT09PT09PT08bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQiPjxTUEFOIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 IEtPIj4oVGhlIDM8U1VQPnJkPC9TVVA+IEludGVybmF0aW9uYWwgV29ya3Nob3Agb24gUkZJRCBh bmQgVWJpcXVpdG91cyBTZW5zb3IgTmV0d29ya3MgKFVTTikgSW4gY29uanVuY3Rpb24gd2l0aCB0 aGUgRVVDIDIwMDc8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQiPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZP TlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj48QSBocmVmPSJodHRw Oi8vdW5zLmFqb3UuYWMua3IvfnVzbjIwMDcvIj48U1BBTiBzdHlsZT0ibXNvLWJpZGktZm9udC1z aXplOiAxMi4wcHQiPmh0dHA6Ly91bnMuYWpvdS5hYy5rci9+dXNuMjAwNy88L1NQQU4+PC9BPiwg PC9TUEFOPjw/eG1sOm5hbWVzcGFjZSBwcmVmaXggPSBzdDEgbnMgPSAidXJuOnNjaGVtYXMtbWlj cm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIiAvPjxzdDE6ZGF0ZSBNb250aD0iMTIiIERheT0i MTciIFllYXI9IjIwMDciPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZ OiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj5EZWNlbWJlciAxNy0yMCwgMjAwNzwv U1BBTj48L3N0MTpkYXRlPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZ OiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj4sIDwvU1BBTj48c3QxOnBsYWNlPjxz dDE6Q2l0eT48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07 IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+VGFpcGVpPC9TUEFOPjwvc3QxOkNpdHk+PFNQQU4g c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1s YW5ndWFnZTogS08iPiwgPC9TUEFOPjxzdDE6Y291bnRyeS1yZWdpb24+PFNQQU4gc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTog S08iPlRhaXdhbjwvU1BBTj48L3N0MTpjb3VudHJ5LXJlZ2lvbj48L3N0MTpwbGFjZT48U1BBTiBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxh bmd1YWdlOiBLTyI+KTxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Rk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4g MGluIDBwdCI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGlt OyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPj09PT09PT09PT09PT09PT09PT09PT09PT09PG86 cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBp biAwaW4gMHB0Ij48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3Vs aW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+KioqIEltcG9ydGFudCBEYXRlcyAqKio8bzpw PjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGlu IDBpbiAwcHQiPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxp bTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj49PT09PT09PT09PT09PT09PT09PT09PT09PTxv OnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAw aW4gMGluIDBwdCI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1 bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPlN1Ym1pc3Npb24gRHVlOiA8L1NQQU4+PHN0 MTpkYXRlIE1vbnRoPSI1IiBEYXk9IjE3IiBZZWFyPSIyMDA3Ij48U1BBTiBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+ TWF5IDE3LCAyMDA3PC9TUEFOPjwvc3QxOmRhdGU+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPiA8bzpwPjwv bzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBp biAwcHQiPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsg bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj5BY2NlcHRhbmNlIG5vdGlmaWNhdGlvbjogPC9TUEFO PjxzdDE6ZGF0ZSBNb250aD0iOCIgRGF5PSI2IiBZZWFyPSIyMDA3Ij48U1BBTiBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBL TyI+QXVndXN0IDYsIDIwMDc8L1NQQU4+PC9zdDE6ZGF0ZT48U1BBTiBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+IDxv OnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAw aW4gMGluIDBwdCI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1 bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPkNhbWVyYS1yZWFkeSBkdWU6IDwvU1BBTj48 c3QxOmRhdGUgTW9udGg9IjkiIERheT0iNCIgWWVhcj0iMjAwNyI+PFNQQU4gc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08i PlNlcHRlbWJlciA0LCAyMDA3PC9TUEFOPjwvc3QxOmRhdGU+PFNQQU4gc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPiA8 bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjog MGluIDBpbiAwcHQiPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBG T05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+PG86cD4mbmJzcDs8 L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAw aW4gMHB0Ij48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07 IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+PT09PT09PT09PT09PT09PT09PT09PT09PT08bzpw PjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGlu IDBpbiAwcHQiPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxp bTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj5CYWNrZ3JvdW5kPG86cD48L286cD48L1NQQU4+ PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0Ij48U1BB TiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0 LWxhbmd1YWdlOiBLTyI+PT09PT09PT09PT09PT09PT09PT09PT09PT08bzpwPjwvbzpwPjwvU1BB Tj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9IlRFWFQtSlVTVElGWTogaW50ZXItaWRl b2dyYXBoOyBNQVJHSU46IDBpbiAwaW4gMHB0OyBURVhULUFMSUdOOiBqdXN0aWZ5Ij48U1BBTiBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxh bmd1YWdlOiBLTyI+VGhlIHB1cnBvc2Ugb2YgVVNOIDIwMDcgaXMgdG8gZXN0YWJsaXNoIGEgZGlz Y3Vzc2lvbiBmcmFtZXdvcmsgb24gYWxsIHRoZSBjaGFsbGVuZ2VzIHJhaXNlZCBmcm9tIHRoZSBl dm9sdXRpb24gb2YgdGhlIFViaXF1aXRvdXMgU2Vuc29yIE5ldHdvcmtzIGFuZCBSRklEIHRlY2hu b2xvZ2llcy4gPC9TUEFOPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZ OiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj5BcyBhIHVuaXF1ZSBvcHBvcnR1bml0 eSB0byBvYnRhaW4gYW4gaW5zaWdodCBvbiB0aGUgbGVhZGluZyB0ZWNobm9sb2dpZXMgb2YgdGhl IG5leHQgcGVydmFzaXZlIGVyYSwgVVNOIDIwMDcgd2FudHMgdG8gaW52aXRlIHJlc2VhcmNoZXJz IHRvIHByZXNlbnQgYW5kIGRpc2N1c3MgdGhlaXIgaWRlYXMuIDxvOnA+PC9vOnA+PC9TUEFOPjwv UD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3Jh cGg7IE1BUkdJTjogMGluIDBpbiAwcHQ7IFRFWFQtQUxJR046IGp1c3RpZnkiPjxTUEFOIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6IEtPIj48L1NQQU4+Jm5ic3A7PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJURVhU LUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgTUFSR0lOOiAwaW4gMGluIDBwdDsgVEVYVC1BTElH TjoganVzdGlmeSI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1 bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPlRvcGljcyBvZiB0aGlzIHdvcmtzaG9wIGlu Y2x1ZGUsIGJ1dCBhcmUgbm90IGxpbWl0ZWQgdG86IDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQ IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGg7IE1B UkdJTjogMGluIDBpbiAwcHQ7IFRFWFQtQUxJR046IGp1c3RpZnkiPjxTUEFOIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtP Ij48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 IlRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBNQVJHSU46IDBpbiAwaW4gMHB0IDAuMjVp bjsgVEVYVC1JTkRFTlQ6IC0wLjI1aW47IFRFWFQtQUxJR046IGp1c3RpZnk7IG1zby1saXN0OiBs MCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC4yNWluIj48U1BBTiBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3ltYm9sOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTog U3ltYm9sOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBT eW1ib2wiPjxTUEFOIHN0eWxlPSJtc28tbGlzdDogSWdub3JlIj6hpDxTUEFOIHN0eWxlPSJGT05U OiA3cHQgJ1RpbWVzIE5ldyBSb21hbiciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+PC9TUEFOPjwvU1BBTj48U1BBTiBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+ UkZJRCBTeXN0ZW1zIGFuZCBBcmNoaXRlY3R1cmUgPG86cD48L286cD48L1NQQU4+PC9QPg0KPFAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgTUFS R0lOOiAwaW4gMGluIDBwdCAwLjI1aW47IFRFWFQtSU5ERU5UOiAtMC4yNWluOyBURVhULUFMSUdO OiBqdXN0aWZ5OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuMjVp biI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5bWJvbDsgbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6IFN5bWJvbDsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPOyBt c28tYmlkaS1mb250LWZhbWlseTogU3ltYm9sIj48U1BBTiBzdHlsZT0ibXNvLWxpc3Q6IElnbm9y ZSI+oaQ8U1BBTiBzdHlsZT0iRk9OVDogN3B0ICdUaW1lcyBOZXcgUm9tYW4nIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPjwvU1BBTj48L1NQ QU4+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28t ZmFyZWFzdC1sYW5ndWFnZTogS08iPlJGSUQgTWlkZGxld2FyZSBEZXNpZ24gPG86cD48L286cD48 L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJURVhULUpVU1RJRlk6IGludGVy LWlkZW9ncmFwaDsgTUFSR0lOOiAwaW4gMGluIDBwdCAwLjI1aW47IFRFWFQtSU5ERU5UOiAtMC4y NWluOyBURVhULUFMSUdOOiBqdXN0aWZ5OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1z dG9wczogbGlzdCAuMjVpbiI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1J TFk6IFN5bWJvbDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IFN5bWJvbDsgbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6IEtPOyBtc28tYmlkaS1mb250LWZhbWlseTogU3ltYm9sIj48U1BBTiBzdHlsZT0i bXNvLWxpc3Q6IElnbm9yZSI+oaQ8U1BBTiBzdHlsZT0iRk9OVDogN3B0ICdUaW1lcyBOZXcgUm9t YW4nIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9T UEFOPjwvU1BBTj48L1NQQU4+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1J TFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPkFudGktY29sbGlzaW9uIGFsZ29y aXRobXMgPG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJU RVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgTUFSR0lOOiAwaW4gMGluIDBwdCAwLjI1aW47 IFRFWFQtSU5ERU5UOiAtMC4yNWluOyBURVhULUFMSUdOOiBqdXN0aWZ5OyBtc28tbGlzdDogbDAg bGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuMjVpbiI+PFNQQU4gc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5bWJvbDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IFN5 bWJvbDsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPOyBtc28tYmlkaS1mb250LWZhbWlseTogU3lt Ym9sIj48U1BBTiBzdHlsZT0ibXNvLWxpc3Q6IElnbm9yZSI+oaQ8U1BBTiBzdHlsZT0iRk9OVDog N3B0ICdUaW1lcyBOZXcgUm9tYW4nIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgPC9TUEFOPjwvU1BBTj48L1NQQU4+PFNQQU4gc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPk1v YmlsZSBSRklEIFN5c3RlbXMgYW5kIEFwcGxpY2F0aW9ucyA8bzpwPjwvbzpwPjwvU1BBTj48L1A+ DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9IlRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBo OyBNQVJHSU46IDBpbiAwaW4gMHB0IDAuMjVpbjsgVEVYVC1JTkRFTlQ6IC0wLjI1aW47IFRFWFQt QUxJR046IGp1c3RpZnk7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0 IC4yNWluIj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3ltYm9s OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogU3ltYm9sOyBtc28tZmFyZWFzdC1sYW5ndWFnZTog S087IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBTeW1ib2wiPjxTUEFOIHN0eWxlPSJtc28tbGlzdDog SWdub3JlIj6hpDxTUEFOIHN0eWxlPSJGT05UOiA3cHQgJ1RpbWVzIE5ldyBSb21hbiciPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+PC9TUEFO PjwvU1BBTj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07 IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+RGF0YSBNb2RlbGluZyBhbmQgTWFuYWdlbWVudCA8 bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9IlRFWFQtSlVT VElGWTogaW50ZXItaWRlb2dyYXBoOyBNQVJHSU46IDBpbiAwaW4gMHB0IDAuMjVpbjsgVEVYVC1J TkRFTlQ6IC0wLjI1aW47IFRFWFQtQUxJR046IGp1c3RpZnk7IG1zby1saXN0OiBsMCBsZXZlbDEg bGZvMTsgdGFiLXN0b3BzOiBsaXN0IC4yNWluIj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogU3ltYm9sOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogU3ltYm9sOyBt c28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBTeW1ib2wiPjxT UEFOIHN0eWxlPSJtc28tbGlzdDogSWdub3JlIj6hpDxTUEFOIHN0eWxlPSJGT05UOiA3cHQgJ1Rp bWVzIE5ldyBSb21hbiciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8L1NQQU4+PC9TUEFOPjwvU1BBTj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+RW1iZWRkZWQg UkZJRC1lbmFibGVkIERldmljZSBUZWNobm9sb2d5IDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQ IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGg7IE1B UkdJTjogMGluIDBpbiAwcHQgMC4yNWluOyBURVhULUlOREVOVDogLTAuMjVpbjsgVEVYVC1BTElH TjoganVzdGlmeTsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3QgLjI1 aW4iPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeW1ib2w7IG1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OiBTeW1ib2w7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsg bXNvLWJpZGktZm9udC1mYW1pbHk6IFN5bWJvbCI+PFNQQU4gc3R5bGU9Im1zby1saXN0OiBJZ25v cmUiPqGkPFNQQU4gc3R5bGU9IkZPTlQ6IDdwdCAnVGltZXMgTmV3IFJvbWFuJyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj48L1NQQU4+PC9T UEFOPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj5TZW5zb3IgTmV0d29yayBBcmNoaXRlY3R1cmVzIGFuZCBQ cm90b2NvbHMgPG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSJURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgTUFSR0lOOiAwaW4gMGluIDBwdCAwLjI1 aW47IFRFWFQtSU5ERU5UOiAtMC4yNWluOyBURVhULUFMSUdOOiBqdXN0aWZ5OyBtc28tbGlzdDog bDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuMjVpbiI+PFNQQU4gc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5bWJvbDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 IFN5bWJvbDsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPOyBtc28tYmlkaS1mb250LWZhbWlseTog U3ltYm9sIj48U1BBTiBzdHlsZT0ibXNvLWxpc3Q6IElnbm9yZSI+oaQ8U1BBTiBzdHlsZT0iRk9O VDogN3B0ICdUaW1lcyBOZXcgUm9tYW4nIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPjwvU1BBTj48L1NQQU4+PFNQQU4gc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08i Pk5ldHdvcmsgcHJvdG9jb2xzLCBlLmcuLCBNQUMgYW5kIHJvdXRpbmcgPG86cD48L286cD48L1NQ QU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJURVhULUpVU1RJRlk6IGludGVyLWlk ZW9ncmFwaDsgTUFSR0lOOiAwaW4gMGluIDBwdCAwLjI1aW47IFRFWFQtSU5ERU5UOiAtMC4yNWlu OyBURVhULUFMSUdOOiBqdXN0aWZ5OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9w czogbGlzdCAuMjVpbiI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6 IFN5bWJvbDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IFN5bWJvbDsgbXNvLWZhcmVhc3QtbGFu Z3VhZ2U6IEtPOyBtc28tYmlkaS1mb250LWZhbWlseTogU3ltYm9sIj48U1BBTiBzdHlsZT0ibXNv LWxpc3Q6IElnbm9yZSI+oaQ8U1BBTiBzdHlsZT0iRk9OVDogN3B0ICdUaW1lcyBOZXcgUm9tYW4n Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFO PjwvU1BBTj48L1NQQU4+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6 IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPkRpc3RyaWJ1dGVkIEFsZ29yaXRobXMs IGUuZy4sIExvY2FsaXphdGlvbiBhbmQgU3luY2hyb25pemF0aW9uIDxvOnA+PC9vOnA+PC9TUEFO PjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVv Z3JhcGg7IE1BUkdJTjogMGluIDBpbiAwcHQgMC4yNWluOyBURVhULUlOREVOVDogLTAuMjVpbjsg VEVYVC1BTElHTjoganVzdGlmeTsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6 IGxpc3QgLjI1aW4iPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBT eW1ib2w7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBTeW1ib2w7IG1zby1mYXJlYXN0LWxhbmd1 YWdlOiBLTzsgbXNvLWJpZGktZm9udC1mYW1pbHk6IFN5bWJvbCI+PFNQQU4gc3R5bGU9Im1zby1s aXN0OiBJZ25vcmUiPqGkPFNQQU4gc3R5bGU9IkZPTlQ6IDdwdCAnVGltZXMgTmV3IFJvbWFuJyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj48 L1NQQU4+PC9TUEFOPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBH dWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj5Dcm9zcyBMYXllciBhbmQgRW5lcmd5IEVm ZmljaWVudCBEZXNpZ24gPG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSJURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgTUFSR0lOOiAwaW4gMGluIDBw dCAwLjI1aW47IFRFWFQtSU5ERU5UOiAtMC4yNWluOyBURVhULUFMSUdOOiBqdXN0aWZ5OyBtc28t bGlzdDogbDAgbGV2ZWwxIGxmbzE7IHRhYi1zdG9wczogbGlzdCAuMjVpbiI+PFNQQU4gc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFN5bWJvbDsgbXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6IFN5bWJvbDsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPOyBtc28tYmlkaS1mb250LWZh bWlseTogU3ltYm9sIj48U1BBTiBzdHlsZT0ibXNvLWxpc3Q6IElnbm9yZSI+oaQ8U1BBTiBzdHls ZT0iRk9OVDogN3B0ICdUaW1lcyBOZXcgUm9tYW4nIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPjwvU1BBTj48L1NQQU4+PFNQQU4gc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFn ZTogS08iPlVTTiBNaWRkbGV3YXJlIElzc3VlcywgZS5nLiwgT1MgYW5kIERhdGFiYXNlIDxvOnA+ PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iVEVYVC1KVVNUSUZZ OiBpbnRlci1pZGVvZ3JhcGg7IE1BUkdJTjogMGluIDBpbiAwcHQgMC4yNWluOyBURVhULUlOREVO VDogLTAuMjVpbjsgVEVYVC1BTElHTjoganVzdGlmeTsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8x OyB0YWItc3RvcHM6IGxpc3QgLjI1aW4iPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZP TlQtRkFNSUxZOiBTeW1ib2w7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBTeW1ib2w7IG1zby1m YXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWJpZGktZm9udC1mYW1pbHk6IFN5bWJvbCI+PFNQQU4g c3R5bGU9Im1zby1saXN0OiBJZ25vcmUiPqGkPFNQQU4gc3R5bGU9IkZPTlQ6IDdwdCAnVGltZXMg TmV3IFJvbWFuJyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDwvU1BBTj48L1NQQU4+PC9TUEFOPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZP TlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj5Db2V4aXN0ZW5jZSBv ZiBSRklEICZhbXA7IFVTTiA8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9IlRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBNQVJHSU46IDBpbiAwaW4g MHB0IDAuMjVpbjsgVEVYVC1JTkRFTlQ6IC0wLjI1aW47IFRFWFQtQUxJR046IGp1c3RpZnk7IG1z by1saXN0OiBsMCBsZXZlbDEgbGZvMTsgdGFiLXN0b3BzOiBsaXN0IC4yNWluIj48U1BBTiBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU3ltYm9sOyBtc28tZmFyZWFzdC1mb250 LWZhbWlseTogU3ltYm9sOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWZvbnQt ZmFtaWx5OiBTeW1ib2wiPjxTUEFOIHN0eWxlPSJtc28tbGlzdDogSWdub3JlIj6hpDxTUEFOIHN0 eWxlPSJGT05UOiA3cHQgJ1RpbWVzIE5ldyBSb21hbiciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+PC9TUEFOPjwvU1BBTj48U1BBTiBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1 YWdlOiBLTyI+UW9TIGFuZCBSZWFsLVRpbWUgSXNzdWVzIDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4N CjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGg7 IE1BUkdJTjogMGluIDBpbiAwcHQgMC4yNWluOyBURVhULUlOREVOVDogLTAuMjVpbjsgVEVYVC1B TElHTjoganVzdGlmeTsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3Qg LjI1aW4iPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeW1ib2w7 IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBTeW1ib2w7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBL TzsgbXNvLWJpZGktZm9udC1mYW1pbHk6IFN5bWJvbCI+PFNQQU4gc3R5bGU9Im1zby1saXN0OiBJ Z25vcmUiPqGkPFNQQU4gc3R5bGU9IkZPTlQ6IDdwdCAnVGltZXMgTmV3IFJvbWFuJyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj48L1NQQU4+ PC9TUEFOPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsg bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj5TZWN1cml0eSBhbmQgcHJpdmFjeSBpc3N1ZXMgPG86 cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJURVhULUpVU1RJ Rlk6IGludGVyLWlkZW9ncmFwaDsgTUFSR0lOOiAwaW4gMGluIDBwdCAwLjI1aW47IFRFWFQtSU5E RU5UOiAtMC4yNWluOyBURVhULUFMSUdOOiBqdXN0aWZ5OyBtc28tbGlzdDogbDAgbGV2ZWwxIGxm bzE7IHRhYi1zdG9wczogbGlzdCAuMjVpbiI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Rk9OVC1GQU1JTFk6IFN5bWJvbDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IFN5bWJvbDsgbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6IEtPOyBtc28tYmlkaS1mb250LWZhbWlseTogU3ltYm9sIj48U1BB TiBzdHlsZT0ibXNvLWxpc3Q6IElnbm9yZSI+oaQ8U1BBTiBzdHlsZT0iRk9OVDogN3B0ICdUaW1l cyBOZXcgUm9tYW4nIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgPC9TUEFOPjwvU1BBTj48L1NQQU4+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Rk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPk5ldHdvcmsgTWFu YWdlbWVudCBpbiBMYXJnZS1zY2FsZSBEZXBsb3ltZW50IDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4N CjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGg7 IE1BUkdJTjogMGluIDBpbiAwcHQgMC4yNWluOyBURVhULUlOREVOVDogLTAuMjVpbjsgVEVYVC1B TElHTjoganVzdGlmeTsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xOyB0YWItc3RvcHM6IGxpc3Qg LjI1aW4iPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeW1ib2w7 IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBTeW1ib2w7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBL TzsgbXNvLWJpZGktZm9udC1mYW1pbHk6IFN5bWJvbCI+PFNQQU4gc3R5bGU9Im1zby1saXN0OiBJ Z25vcmUiPqGkPFNQQU4gc3R5bGU9IkZPTlQ6IDdwdCAnVGltZXMgTmV3IFJvbWFuJyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj48L1NQQU4+ PC9TUEFOPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsg bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj5Db2V4aXN0ZW5jZSBvZiBSRklEICZhbXA7IFVTTiA8 bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9IlRFWFQtSlVT VElGWTogaW50ZXItaWRlb2dyYXBoOyBNQVJHSU46IDBpbiAwaW4gMHB0IDAuMjVpbjsgVEVYVC1J TkRFTlQ6IC0wLjI1aW47IFRFWFQtQUxJR046IGp1c3RpZnk7IG1zby1saXN0OiBsMCBsZXZlbDEg bGZvMTsgdGFiLXN0b3BzOiBsaXN0IC4yNWluIj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogU3ltYm9sOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogU3ltYm9sOyBt c28tZmFyZWFzdC1sYW5ndWFnZTogS087IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBTeW1ib2wiPjxT UEFOIHN0eWxlPSJtc28tbGlzdDogSWdub3JlIj6hpDxTUEFOIHN0eWxlPSJGT05UOiA3cHQgJ1Rp bWVzIE5ldyBSb21hbiciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8L1NQQU4+PC9TUEFOPjwvU1BBTj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+Tm92ZWwgUkZJ RCBhbmQgVVNOIEFwcGxpY2F0aW9ucyA8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQiPjxTUEFOIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxh bmd1YWdlOiBLTyI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0Ij48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+V29ya3No b3AgQ28tQ2hhaXJzPG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0Ij48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG T05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+PT09PT09PT09PT09 PT09PT09PT09PT09PT08bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQiPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj5Zb3VuZy1CYWUg S28sIDwvU1BBTj48c3QxOnBsYWNlPjxzdDE6Q2l0eT48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+QWpvdSBV bml2ZXJzaXR5PC9TUEFOPjwvc3QxOkNpdHk+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Rk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPiwgPC9TUEFOPjxz dDE6Y291bnRyeS1yZWdpb24+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1J TFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPktvcmVhPC9TUEFOPjwvc3QxOmNv dW50cnktcmVnaW9uPjwvc3QxOnBsYWNlPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZP TlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj4gPG86cD48L286cD48 L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0 Ij48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1m YXJlYXN0LWxhbmd1YWdlOiBLTyI+S2FuZy1Xb24gTGVlLCBJQk0gVC5KIFdhdHNvbiBSZXNlYXJj aCwgPC9TUEFOPjxzdDE6Y291bnRyeS1yZWdpb24+PHN0MTpwbGFjZT48U1BBTiBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBL TyI+VVNBPC9TUEFOPjwvc3QxOnBsYWNlPjwvc3QxOmNvdW50cnktcmVnaW9uPjxTUEFOIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6IEtPIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 Ik1BUkdJTjogMGluIDBpbiAwcHQiPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt RkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj48bzpwPiZuYnNwOzwvbzpw PjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAw cHQiPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQo8UCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQiPjxTUEFOIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 IEtPIj5TdGVlcmluZyBDb21taXR0ZWUgPG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0Ij48U1BBTiBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+ PT09PT09PT09PT09PT09PT09PT09PT09PT08bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQiPjxTUEFOIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtP Ij5Kb25nc3VrIENoYWUsIEVUUkksIDwvU1BBTj48c3QxOmNvdW50cnktcmVnaW9uPjxzdDE6cGxh Y2U+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28t ZmFyZWFzdC1sYW5ndWFnZTogS08iPktvcmVhPC9TUEFOPjwvc3QxOnBsYWNlPjwvc3QxOmNvdW50 cnktcmVnaW9uPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxp bTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQiPjxTUEFOIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 IEtPIj5TZXVuZy1XaGEgWW9vLCA8L1NQQU4+PHN0MTpwbGFjZT48c3QxOkNpdHk+PFNQQU4gc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5n dWFnZTogS08iPkFqb3UgVW5pdmVyc2l0eTwvU1BBTj48L3N0MTpDaXR5PjxTUEFOIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 IEtPIj4sIDwvU1BBTj48c3QxOmNvdW50cnktcmVnaW9uPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj5Lb3Jl YTwvU1BBTj48L3N0MTpjb3VudHJ5LXJlZ2lvbj48L3N0MTpwbGFjZT48U1BBTiBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBL TyI+PG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJH SU46IDBpbiAwaW4gMHB0Ij48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM WTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+WXUtQ2hlZSBUc2VuZywgTmF0aW9u YWwgQ2hpYW8gVHVuZyBVbml2LiwgPC9TUEFOPjxzdDE6Y291bnRyeS1yZWdpb24+PHN0MTpwbGFj ZT48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1m YXJlYXN0LWxhbmd1YWdlOiBLTyI+VGFpd2FuPC9TUEFOPjwvc3QxOnBsYWNlPjwvc3QxOmNvdW50 cnktcmVnaW9uPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxp bTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQiPjxTUEFOIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 IEtPIj5EYWV5b3VuZyBLaW0sIEluZm9ybWF0aW9uIGFuZCA8L1NQQU4+PHN0MTpwbGFjZT48c3Qx OkNpdHk+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBt c28tZmFyZWFzdC1sYW5ndWFnZTogS08iPkNvbW11bmljYXRpb25zIFVuaXZlcnNpdHk8L1NQQU4+ PC9zdDE6Q2l0eT48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3Vs aW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+LCA8L1NQQU4+PHN0MTpjb3VudHJ5LXJlZ2lv bj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1m YXJlYXN0LWxhbmd1YWdlOiBLTyI+S29yZWE8L1NQQU4+PC9zdDE6Y291bnRyeS1yZWdpb24+PC9z dDE6cGxhY2U+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGlt OyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCI+PFNQQU4gc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTog S08iPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0iTUFSR0lOOiAwaW4gMGluIDBwdCI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9O VC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPlByb2dyYW0gQ29tbWl0 dGVlPG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJH SU46IDBpbiAwaW4gMHB0Ij48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM WTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+PT09PT09PT09PT09PT09PT09PT09 PT09PT08bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1B UkdJTjogMGluIDBpbiAwcHQiPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFN SUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj5CeXVuZ2h1biBTb25nLCBLRVRJ LCA8L1NQQU4+PHN0MTpjb3VudHJ5LXJlZ2lvbj48c3QxOnBsYWNlPjxTUEFOIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtP Ij5Lb3JlYTwvU1BBTj48L3N0MTpwbGFjZT48L3N0MTpjb3VudHJ5LXJlZ2lvbj48U1BBTiBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1 YWdlOiBLTyI+PG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSJNQVJHSU46IDBpbiAwaW4gMHB0Ij48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05U LUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+Q2hhbnN1IFl1LCA8L1NQ QU4+PHN0MTpwbGFjZT48c3QxOkNpdHk+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9O VC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPkNsZXZlbGFuZCBTdGF0 ZSBVbml2ZXJzaXR5PC9TUEFOPjwvc3QxOkNpdHk+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPiwgPC9TUEFO PjxzdDE6Y291bnRyeS1yZWdpb24+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1G QU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPlVTQTwvU1BBTj48L3N0MTpj b3VudHJ5LXJlZ2lvbj48L3N0MTpwbGFjZT48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG T05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+PG86cD48L286cD48 L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0 Ij48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1m YXJlYXN0LWxhbmd1YWdlOiBLTyI+Q2hpaC1ZdW5nIENoYW5nLCA8L1NQQU4+PHN0MTpwbGFjZT48 c3QxOkNpdHk+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGlt OyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPlRhbWthbmcgVW5pdmVyc2l0eTwvU1BBTj48L3N0 MTpDaXR5PjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsg bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj4sIDwvU1BBTj48c3QxOmNvdW50cnktcmVnaW9uPjxT UEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6IEtPIj5UYWl3YW48L1NQQU4+PC9zdDE6Y291bnRyeS1yZWdpb24+PC9zdDE6 cGxhY2U+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBt c28tZmFyZWFzdC1sYW5ndWFnZTogS08iPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCI+PFNQQU4gc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08i PkRvbmctS3l1biBLaW0sIDwvU1BBTj48c3QxOnBsYWNlPjxzdDE6Q2l0eT48U1BBTiBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdl OiBLTyI+S3l1bmdwb29rIE5hdGlvbmFsIFVuaXZlcnNpdHk8L1NQQU4+PC9zdDE6Q2l0eT48U1BB TiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0 LWxhbmd1YWdlOiBLTyI+LCA8L1NQQU4+PHN0MTpjb3VudHJ5LXJlZ2lvbj48U1BBTiBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdl OiBLTyI+S29yZWE8L1NQQU4+PC9zdDE6Y291bnRyeS1yZWdpb24+PC9zdDE6cGxhY2U+PFNQQU4g c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1s YW5ndWFnZTogS08iPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Rk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPkphZS1IeXVuIEtp bSwgPC9TUEFOPjxzdDE6cGxhY2U+PHN0MTpDaXR5PjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj5Bam91IFVu aXZlcnNpdHk8L1NQQU4+PC9zdDE6Q2l0eT48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG T05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+LCA8L1NQQU4+PHN0 MTpjb3VudHJ5LXJlZ2lvbj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM WTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+S29yZWE8L1NQQU4+PC9zdDE6Y291 bnRyeS1yZWdpb24+PC9zdDE6cGxhY2U+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9O VC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPjxvOnA+PC9vOnA+PC9T UEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCI+ PFNQQU4gbGFuZz1FUy1DTyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3Vs aW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVTLUNPIj5K YXZpZXIgR29tZXosIE5hdGlvbmFsIFVuaXZlcnNpdHkgb2YgTWV4aWNvLCBNZXhpY288bzpwPjwv bzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBp biAwcHQiPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsg bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj5LYW5nLVdvbiBMZWUsIElCTSBULkogV2F0c29uIFJl c2VhcmNoLCA8L1NQQU4+PHN0MTpjb3VudHJ5LXJlZ2lvbj48c3QxOnBsYWNlPjxTUEFOIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6IEtPIj5VU0E8L1NQQU4+PC9zdDE6cGxhY2U+PC9zdDE6Y291bnRyeS1yZWdpb24+PFNQQU4g c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1s YW5ndWFnZTogS08iPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Rk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPkt1aSBXdSwgPC9T UEFOPjxzdDE6cGxhY2U+PHN0MTpDaXR5PjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZP TlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj5Vbml2ZXJzaXR5IG9m IFZpY3RvcmlhPC9TUEFOPjwvc3QxOkNpdHk+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Rk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPiwgPC9TUEFOPjxz dDE6Y291bnRyeS1yZWdpb24+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1J TFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPkNhbmFkYTwvU1BBTj48L3N0MTpj b3VudHJ5LXJlZ2lvbj48L3N0MTpwbGFjZT48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG T05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+PG86cD48L286cD48 L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0 Ij48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1m YXJlYXN0LWxhbmd1YWdlOiBLTyI+TGluZy1KeWggQ2hlbiwgSW5zdGl0dXRlIG9mIDwvU1BBTj48 c3QxOnBsYWNlPjxzdDE6Q2l0eT48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZB TUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+SW5mb3JtYXRpb24gU2NpZW5j ZTwvU1BBTj48L3N0MTpDaXR5PjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFN SUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj4sIDwvU1BBTj48c3QxOmNvdW50 cnktcmVnaW9uPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxp bTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj5UYWl3YW48L1NQQU4+PC9zdDE6Y291bnRyeS1y ZWdpb24+PC9zdDE6cGxhY2U+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1J TFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPjxvOnA+PC9vOnA+PC9TUEFOPjwv UD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCI+PFNQQU4g c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1s YW5ndWFnZTogS08iPk1pbmVvIFRha2FpLCA8L1NQQU4+PHN0MTpwbGFjZT48c3QxOkNpdHk+PFNQ QU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFz dC1sYW5ndWFnZTogS08iPlVDTEE8L1NQQU4+PC9zdDE6Q2l0eT48U1BBTiBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+ LCA8L1NQQU4+PHN0MTpjb3VudHJ5LXJlZ2lvbj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+VVNBPC9TUEFO Pjwvc3QxOmNvdW50cnktcmVnaW9uPjwvc3QxOnBsYWNlPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj48bzpw PjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGlu IDBpbiAwcHQiPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxp bTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj5NaW5nLUplciBUc2FpLCBOYXRpb25hbCA8L1NQ QU4+PHN0MTpwbGFjZT48c3QxOkNpdHk+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9O VC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPlRzaW5nLUh1YSBVbml2 LjwvU1BBTj48L3N0MTpDaXR5PjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFN SUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj4sIDwvU1BBTj48c3QxOmNvdW50 cnktcmVnaW9uPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxp bTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj5UYWl3YW48L1NQQU4+PC9zdDE6Y291bnRyeS1y ZWdpb24+PC9zdDE6cGxhY2U+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1J TFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPjxvOnA+PC9vOnA+PC9TUEFOPjwv UD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCI+PHN0MTpw bGFjZT48c3QxOkNpdHk+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6 IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPk1pc2NoYSBEb2hsZXI8L1NQQU4+PC9z dDE6Q2l0eT48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07 IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+LCA8L1NQQU4+PHN0MTpjb3VudHJ5LXJlZ2lvbj48 U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJl YXN0LWxhbmd1YWdlOiBLTyI+RnJhbmNlPC9TUEFOPjwvc3QxOmNvdW50cnktcmVnaW9uPjwvc3Qx OnBsYWNlPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsg bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj4gPC9TUEFOPjxzdDE6cGxhY2U+PHN0MTpDaXR5PjxT UEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6IEtPIj5UZWxlY29tPC9TUEFOPjwvc3QxOkNpdHk+PFNQQU4gc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTog S08iPiwgPC9TUEFOPjxzdDE6Y291bnRyeS1yZWdpb24+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPkZyYW5j ZTwvU1BBTj48L3N0MTpjb3VudHJ5LXJlZ2lvbj48L3N0MTpwbGFjZT48U1BBTiBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBL TyI+PG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJH SU46IDBpbiAwaW4gMHB0Ij48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM WTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+TW9oYW1lZCBZb3VuaXMsIDwvU1BB Tj48c3QxOnBsYWNlPjxzdDE6Q2l0eT48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05U LUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+VW5pdmVyc2l0eSBvZiBN YXJ5bGFuZDwvU1BBTj48L3N0MTpDaXR5PjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZP TlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj4sIDwvU1BBTj48c3Qx OmNvdW50cnktcmVnaW9uPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZ OiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj5VU0E8L1NQQU4+PC9zdDE6Y291bnRy eS1yZWdpb24+PC9zdDE6cGxhY2U+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1G QU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPjxvOnA+PC9vOnA+PC9TUEFO PjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCI+PFNQ QU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFz dC1sYW5ndWFnZTogS08iPk96Z3VyIEVyY2V0aW4sIDwvU1BBTj48c3QxOnBsYWNlPjxzdDE6Q2l0 eT48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1m YXJlYXN0LWxhbmd1YWdlOiBLTyI+U2FiYW5jaSBVbml2ZXJzaXR5PC9TUEFOPjwvc3QxOkNpdHk+ PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFy ZWFzdC1sYW5ndWFnZTogS08iPiwgPC9TUEFOPjxzdDE6Y291bnRyeS1yZWdpb24+PFNQQU4gc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5n dWFnZTogS08iPlR1cmtleTwvU1BBTj48L3N0MTpjb3VudHJ5LXJlZ2lvbj48L3N0MTpwbGFjZT48 U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJl YXN0LWxhbmd1YWdlOiBLTyI+PG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0Ij48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+U2FhZCBC aWF6LCA8L1NQQU4+PHN0MTpwbGFjZT48c3QxOkNpdHk+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPkF1YnVy biBVbml2ZXJzaXR5PC9TUEFOPjwvc3QxOkNpdHk+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPiwgPC9TUEFO PjxzdDE6Y291bnRyeS1yZWdpb24+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1G QU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPlVTQTwvU1BBTj48L3N0MTpj b3VudHJ5LXJlZ2lvbj48L3N0MTpwbGFjZT48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG T05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+PG86cD48L286cD48 L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0 Ij48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1m YXJlYXN0LWxhbmd1YWdlOiBLTyI+VGFla3l1bmcgS3dvbiwgPC9TUEFOPjxzdDE6cGxhY2U+PHN0 MTpDaXR5PjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsg bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj5TZW91bCBOYXRpb25hbCBVbml2ZXJzaXR5PC9TUEFO Pjwvc3QxOkNpdHk+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1 bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPiwgPC9TUEFOPjxzdDE6Y291bnRyeS1yZWdp b24+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28t ZmFyZWFzdC1sYW5ndWFnZTogS08iPktvcmVhPC9TUEFOPjwvc3QxOmNvdW50cnktcmVnaW9uPjwv c3QxOnBsYWNlPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxp bTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQiPjxTUEFOIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 IEtPIj5UYWUtSmluIExlZSwgPC9TUEFOPjxzdDE6cGxhY2U+PHN0MTpDaXR5PjxTUEFOIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6IEtPIj5TdW5na3l1bmt3YW4gVW5pdmVyc2l0eTwvU1BBTj48L3N0MTpDaXR5PjxTUEFOIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFu Z3VhZ2U6IEtPIj4sIDwvU1BBTj48c3QxOmNvdW50cnktcmVnaW9uPjxTUEFOIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtP Ij5Lb3JlYTwvU1BBTj48L3N0MTpjb3VudHJ5LXJlZ2lvbj48L3N0MTpwbGFjZT48U1BBTiBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1 YWdlOiBLTyI+PG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSJNQVJHSU46IDBpbiAwaW4gMHB0Ij48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05U LUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+WXVoLVNoeWFuIENoZW4s IDwvU1BBTj48c3QxOnBsYWNlPjxzdDE6Q2l0eT48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+TmF0aW9uYWwg Q2h1bmcgQ2hlbmcgVW5pdmVyc2l0eTwvU1BBTj48L3N0MTpDaXR5PjxTUEFOIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtP Ij4sIDwvU1BBTj48c3QxOmNvdW50cnktcmVnaW9uPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj5UYWl3YW48 L1NQQU4+PC9zdDE6Y291bnRyeS1yZWdpb24+PC9zdDE6cGxhY2U+PFNQQU4gc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08i PjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lO OiAwaW4gMGluIDBwdCI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6 IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPldlaSBMb3UsIDwvU1BBTj48c3QxOnBs YWNlPjxzdDE6Q2l0eT48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTog R3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+SG9uZyBLb25nIFBvbHl0ZWNobmljIFVu aXZlcnNpdHk8L1NQQU4+PC9zdDE6Q2l0eT48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG T05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+LCA8L1NQQU4+PHN0 MTpjb3VudHJ5LXJlZ2lvbj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM WTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+Q2hpbmE8L1NQQU4+PC9zdDE6Y291 bnRyeS1yZWdpb24+PC9zdDE6cGxhY2U+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9O VC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogS08iPjxvOnA+PC9vOnA+PC9T UEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCI+ PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFy ZWFzdC1sYW5ndWFnZTogS08iPldlbi1DaGloIFBlbmcsIE5hdGlvbmFsIENoaWFvIFR1bmcgVW5p di4sIDwvU1BBTj48c3QxOmNvdW50cnktcmVnaW9uPjxzdDE6cGxhY2U+PFNQQU4gc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5ndWFnZTog S08iPlRhaXdhbjwvU1BBTj48L3N0MTpwbGFjZT48L3N0MTpjb3VudHJ5LXJlZ2lvbj48U1BBTiBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxh bmd1YWdlOiBLTyI+PG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0Ij48c3QxOnBsYWNlPjxzdDE6Q2l0eT48U1BBTiBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1 YWdlOiBLTyI+V29uanVuIExlZTwvU1BBTj48L3N0MTpDaXR5PjxTUEFOIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj4s IDwvU1BBTj48c3QxOmNvdW50cnktcmVnaW9uPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEtPIj5Lb3JlYTwvU1BB Tj48L3N0MTpjb3VudHJ5LXJlZ2lvbj48L3N0MTpwbGFjZT48U1BBTiBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBGT05ULUZBTUlMWTogR3VsaW07IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBLTyI+IFVu aXZlcnNpdHksIDwvU1BBTj48c3QxOmNvdW50cnktcmVnaW9uPjxzdDE6cGxhY2U+PFNQQU4gc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEd1bGltOyBtc28tZmFyZWFzdC1sYW5n dWFnZTogS08iPktvcmVhPC9TUEFOPjwvc3QxOnBsYWNlPjwvc3QxOmNvdW50cnktcmVnaW9uPjxT UEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBHdWxpbTsgbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6IEtPIj48bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9mb250PjwvdGQ+PC90cj48 L3RhYmxlPjxicj4NCjxpbWcgaWQ9J21haWxleHAnIHdpZHRoPTAgaGVpZ2g9MCBib3JkZXI9MCBz cmM9J2h0dHA6Ly9tYWlsLmFqb3UuYWMua3I6ODAvbWFpbF9yZWNlaXB0X2NoZWNrLmpzcD91a2V5 PTQ2MjcxOWQ4M2ZjZTY3YTFmYzUxNmUyOCZ1c2VyaWQ9emhtaXImYWhvc3Q9YWpvdV9hY19rcic+ PC9ib2R5PjwvaHRtbD4= ------=_Part_1216785_27937050.1176967332780-- --===============1809740723== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============1809740723==-- From rsn-bounces@ietf.org Thu Apr 19 19:33:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heg7y-0000E0-8a; Thu, 19 Apr 2007 19:33:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heg7w-0000Du-Cl for rsn@ietf.org; Thu, 19 Apr 2007 19:33:24 -0400 Received: from bay0-omc3-s6.bay0.hotmail.com ([65.54.246.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heg7v-0004N2-1V for rsn@ietf.org; Thu, 19 Apr 2007 19:33:24 -0400 Received: from BAY126-W3 ([65.55.131.38]) by bay0-omc3-s6.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 19 Apr 2007 16:33:22 -0700 Message-ID: X-Originating-IP: [66.45.156.87] From: Dan Fokum To: Date: Thu, 19 Apr 2007 18:33:22 -0500 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 19 Apr 2007 23:33:22.0475 (UTC) FILETIME=[1E83C7B0:01C782DB] X-Spam-Score: 2.2 (++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [RSN] Digest Delivery of RSN Discussions X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0397925325==" Errors-To: rsn-bounces@ietf.org --===============0397925325== Content-Type: multipart/alternative; boundary="_0ac79d5c-6372-4707-b3c2-e3370abf3c18_" --_0ac79d5c-6372-4707-b3c2-e3370abf3c18_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is in follow-up to a similar question from Longjiang Li. Does a chang= e need to be made so that we can actually receive a daily digest of the mai= ling list's discussions? I have signed up for a batched digest of the day'= s discussions, but I always get a message when something is posted to the m= ailing list. =20 Thanks, Daniel _________________________________________________________________ Connect to the next generation of MSN Messenger=A0 http://imagine-msn.com/messenger/launch80/default.aspx?locale=3Den-us&sourc= e=3Dwlmailtagline= --_0ac79d5c-6372-4707-b3c2-e3370abf3c18_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is in follow-up to a similar question from Longjiang Li.  D= oes a change need to be made so that we can actually receive a daily digest= of the mailing list's discussions?  I have signed up for a batched di= gest of the day's discussions, but I always get a message when something is= posted to the mailing list.
 
Thanks,
Daniel

Connect to the next generation of MSN Messenger=A0 <= a href=3D'http://imagine-msn.com/messenger/launch80/default.aspx?locale=3De= n-us&source=3Dwlmailtagline' target=3D'_new'>Get it now! = --_0ac79d5c-6372-4707-b3c2-e3370abf3c18_-- --===============0397925325== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============0397925325==-- From rsn-bounces@ietf.org Fri Apr 20 05:24:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HepLy-0000qM-GJ; Fri, 20 Apr 2007 05:24:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HepLx-0000qD-Eb for rsn@ietf.org; Fri, 20 Apr 2007 05:24:29 -0400 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HepLw-0004NR-Ur for rsn@ietf.org; Fri, 20 Apr 2007 05:24:29 -0400 Received: by py-out-1112.google.com with SMTP id f31so711168pyh for ; Fri, 20 Apr 2007 02:24:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oczUmnwrzW8w9Lm6ZWQat6NxOtX0y80rPaB+7TcCYfDUErIS5uXTxloRRuceBcK8Hd4M/JsHfUL9tr1yV3YMX3uqLakoVBZRfIULdOzuAv1/njp8PBvDlXdNq3D1aMADPdKLxBClvRIY3TQlvgK9Vi4SPvzfbRIjPqErlnM6UiA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fuW6Uo3P3z8e7HoSnAbZbX/BLr0hc66NndFvKqF9vZg/OB80SbIPwsQ76FnpDBNKyBcD5qWNRmjK+/qOjm3djg/7vhtmBWmPeV4oZRkYbVvHG7Bf84HnmETbLcWTYZHRQBELolsE2Vo3wE/1ogn5MkptiSygh+u+mDFpe39n+hs= Received: by 10.35.41.14 with SMTP id t14mr4594851pyj.1177061068615; Fri, 20 Apr 2007 02:24:28 -0700 (PDT) Received: by 10.35.38.20 with HTTP; Fri, 20 Apr 2007 02:24:28 -0700 (PDT) Message-ID: <2a3692de0704200224s67c5782dt5bb75455339a1ceb@mail.gmail.com> Date: Fri, 20 Apr 2007 18:24:28 +0900 From: "Dominik Kaspar" To: "JP Vasseur" , rsn@ietf.org, "David Culler" Subject: Re: [RSN] New Mailing List: Routing for Sensor Network In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6938145F-DB59-4A13-97A2-B0F4CA8EFA7F@cisco.com> <2a3692de0704121858u6d934aeckd891f381a138dec7@mail.gmail.com> <2a3692de0704121922g1c08a2b8q3f74d5c02a5f1b1b@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org JP and David, I agree with your point that MANET is not a pre-requisite for sensor network routing, and the reason why we wrote the routing requirements draft was to find what will be really necessary for designing a new protocol or reusing existing protocols. > If my understanding is correct you state in R0 "Existing MANET > protocols (e.g., AODV, OLSR, DYMO) SHOULD be reused." I would > propose to step back for the moment from any specific solution to > again focus on the requirements. As indicated below, we may end up > using a MANET protocol with adaptation but this should not be a pre- > requisite and none of them fully satisfy the requirements, thus the > need for discussion on this list and potentially a WG since this > discussion will likely require a significant amount of work. The reason why we added requirement R00 was that 6lowpan has been handling sensor network issues, and the WG charter states: "As such, the working group may also work on an informational document to show how to apply an existing MANET protocol to LoWPANs (e.g., AODV, OLSR, DYMO, etc)". Therefore, we tried to work within the WG work scope. If our R00 causes some confusion, and if the discussion is not restricted within 6lowpan, but general sensor network routing, I totally agree that we need to take a different approach for this work. > As you will see we're trying to exclusively focus on the > requirements for the time being while staying completely technology > agnostic, which is key for a requirement ID. Well, I can see your concerns from your draft, which our draft also covers and already listed many common requirements with yours; just using different wording. (FYI, I listed our intention of the listed requirements compared to your requirements at the end of this email. I hope you don't misunderstand this. It's for your better understanding that we are talking in the same language.) One of our main concerns is the possibility of creating a big list of requirements for sensor networks, but if you analyze what the requirement differences are between sensor network routing and routing in other areas (such as MANET) you see that they are mostly coming from a few common design goals. The main requirements for sensor networks are namely power saving and what you call "light footprint". That's why we wrote a chapter on the major design goals and have drawn out the requirements from that. Your requirements draft details the requirements, but IMHO, if you added another chapter "the design challenge of sensor routing" before the list of the requirements, and explain the special characteristics of sensor network and why and how it effects routing, it would increase readability. For this, I suggest you to check Section 3 of our draft (http://tools.ietf.org/wg/6lowpan/draft-dokaspar-6lowpan-routreq-01.txt). I think we can merge the works to a nice shape. Other than to your requirements list, I have one more comment. In Chapter 3 it is stated that "The objective of this work would be to define a routing protocol that will satisfy those requirements as much as possible and that would potentially adapt itself to the particular deployment context." If I understand correctly, this objective contradicts with your own requirements. Sensor network applications are really diverse, and for certain applications, they only need a subset of the requirements, while others need a different subset of requirements. I think we shouldn't constrain us to defining "a" routing protocol to satisfy those requirements as much as possible. Please correct me in case of a misunderstanding. Greetings, Dominik & Eunsook ------------------------------ 2.1. Spatially-Driven Multihop: - Your point of energy-aware multihop routing is a major design goal in our draft (Section 3.1) and is addressed by requirement R04 ("energy-minimal routing"). 2.2. Light Footprint: - This requirement is also one of our major design goals (Section 3.2) and listed as requirement R05 ("low protocol complexity"). 2.3. Small MTU: - This requirement is covered by our requirements R03 ("small frames"), R04 ("energy-minimal routing"), R06 ("code length") and in some way R02 ("header compression"). 2.4. Deep power management: - Parts of this requirement is basically "minimizing energy" again. - The other part is covered by our requirement R11 ("sleeping nodes") 2.5. Heterogeneous Capabilities: - The way you word it, this requirement also boils down to R04 ("energy-minimal routing"). 2.6. Highly Variable Connectivity: - The first and third paragraphs are covered by our requirements R13 ("adaptive topologies") and R04 ("energy-minimal routing"). - The second paragraph can be seen as a subset of our requirement R11 ("sleeping nodes") or R08 ("neighbor discovery"); 2.7. Structured Workload and Traffic Pattern: - This requirement is partially described as our R10 ("gateways & querying"). 2.8. Partial Information: - This requirement has been thought of in our draft as R14 ("scalable architecture"). 2.9. Quality of Service Capable Routing: - Path selection, path quality optimization and route performance are already part of other requirements, such as R04 ("energy-minimal routing"). - QoS is intentionally left out as a routing requirement for sensornets. 2.10. Data Aware routing: - If "points of aggregation" is the same as "gateways", it is covered by our requirement R10 ("gateways & querying"). ---<\Draft Comparison>--------------------------- On 4/13/07, JP Vasseur wrote: > Hi Dominik and and Kim, > > Thanks for your email and support for this work, no need to say that your > contribution is most welcome. > What I would propose here would be for you to read the draft that Dave and I > have posted and that should be > available in the next few days and provide us some feed-back. > > As you will see we're trying to exclusively focus on the requirements for > the time being while staying completely technology agnostic, which is key > for a requirement ID. > > If my understanding is correct you state in R0 "Existing MANET protocols > (e.g., AODV, OLSR, DYMO) SHOULD be reused." I would propose to step back for > the moment from any specific solution to again focus on the requirements. As > indicated below, we may end up using a MANET protocol with adaptation but > this should not be a pre-requisite and none of them fully satisfy the > requirements, thus the need for discussion on this list and potentially a WG > since this discussion will likely require a significant amount of work. > There is another fundamental difference: in R02 you mention "6LoWPAN routing > MUST be performed in the adaptation layer, as defined in [3].". We propose > to specify a routing protocol for Sensor Network above IP, not coupled with > any specific layer1/2 technologies, which is of the utmost importance to > support mixed environments that already exist. > > Looking forward to having your comments on the draft > (draft-culler-rsn-routing-reqs-00.txt), which should be > available very soon. > > Thanks. > > JP. > > > On Apr 12, 2007, at 10:22 PM, Dominik Kaspar wrote: > > JP, David, > > I would like to refer to our 6lowpan Routing Requirements draft, which > discusses the issues of routing in "sensor networks". The draft > provides design goals and a list of requirements for IP-based routing > solutions in low-rate WPANs. > > At IETF-68 in Prague, we presented our work and solicited advice from > both MANET and 6lowpan folks. There seemed to be a general consent > that routing is a very important task to solve, however, it is heavily > dependent on the network architecture itself, and what exactly this > "architecture" is should be clarified first. > > If you haven't done it yet, please read our draft; we appreciate any > constructive comments: > http://tools.ietf.org/wg/6lowpan/draft-dokaspar-6lowpan-routreq-01.txt > > Sincerely, > Dominik > > > On 4/12/07, JP Vasseur wrote: > Hi, > > We wanted to inform you that a new Mailing List has been set up, the aim of > which is to discuss Routing for Sensor Networks (at the IP layer). Anybody > interested in contributing to the work is of course more than welcome to > subscribe and collaborate. To register: > https://www1.ietf.org/mailman/listinfo/rsn > > Several of you already expressed some real interest in this work and several > documents (with currently no home WG) already exist. David and I posted are > about to post an ID on the routing requirements for Sensor Networks > (probably early next week) to kick off the discussion. > > What is the overall objective ? > 1) As you know a plethora of proprietary routing protocols (thus outside of > the IETF) have been developed and there is within the IETF currently no > clear answer on which protocol(s) can satisfy the very specific requirements > of Sensor Networks. This triggered this initiative so as to define a routing > architecture and routing protocol at the IETF for Sensor Nets, thus this new > mailing list. Note that we may not be able to come up with a single set of > requirements but a few requirement documents accompanied with some > applicability IDs if it turns out that a unique solution cannot satisfy them > all. > 2) There is at this stage no a priori on the routing protocol that could be > used: it could either be (1) existing routing protocol(s) (AODV, DYMO, OLSR, > Triggered RIP, NEMO, ...) (1) existing routing protocol(s) with enhancements > or (3) new routing protocol(s). > > Possible next steps > If enough interest for this work is shown on the list, we will request a BOF > for Chicago, which may lead to forming a new WG. > > JP and David. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn > _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Fri Apr 20 06:03:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hepxi-00027Y-KK; Fri, 20 Apr 2007 06:03:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hepxh-00025D-QB for rsn@ietf.org; Fri, 20 Apr 2007 06:03:29 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hepxg-0004yU-En for rsn@ietf.org; Fri, 20 Apr 2007 06:03:29 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Apr 2007 12:03:28 +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 l3KA3Rbx022320; Fri, 20 Apr 2007 12:03:27 +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.12.10/8.12.6) with ESMTP id l3KA3Cld000376; Fri, 20 Apr 2007 10:03:27 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, 20 Apr 2007 12:03:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [RSN] New Mailing List: Routing for Sensor Network Date: Fri, 20 Apr 2007 12:03:01 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC03CEFCB8@xmb-ams-337.emea.cisco.com> In-Reply-To: <2a3692de0704200224s67c5782dt5bb75455339a1ceb@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] New Mailing List: Routing for Sensor Network Thread-Index: AceDLcGorsdFwmEUSPaP5Y3RWOy3CQABIq3g References: <6938145F-DB59-4A13-97A2-B0F4CA8EFA7F@cisco.com><2a3692de0704121858u6d934aeckd891f381a138dec7@mail.gmail.com><2a3692de0704121922g1c08a2b8q3f74d5c02a5f1b1b@mail.gmail.com> <2a3692de0704200224s67c5782dt5bb75455339a1ceb@mail.gmail.com> From: "Pascal Thubert \(pthubert\)" To: "Dominik Kaspar" , "Jean Philippe Vasseur \(jvasseur\)" , , "David Culler" X-OriginalArrivalTime: 20 Apr 2007 10:03:13.0944 (UTC) FILETIME=[1BFC5180:01C78333] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1376; t=1177063407; x=1177927407; 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[RSN]=20New=20Mailing=20List=3A=20Routing=20for=20Sen sor=20Network |Sender:=20; bh=JdRPydbSNQgteIVb+mzooARJk4qT7lrwK7zQU9SUdkY=; b=aB7GLKSOl9LktovBzKlP+0oH8aO09pOjBRU+2SEzxOgL0GQqrnlKDYP9NRwbu8qEc0vnKlE8 WEbVrP9rVclIPwWOhV/SKpWz0kYqSIeIZK92Bib3N7B1dgkrd50qACZM; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi Dominik >Other than to your requirements list, I have one more comment. In >Chapter 3 it is stated that "The objective of this work would be to >define a routing protocol that will satisfy those requirements as much >as possible and that would potentially adapt itself to the particular >deployment context." > >If I understand correctly, this objective contradicts with your own >requirements. Sensor network applications are really diverse, and for >certain applications, they only need a subset of the requirements, >while others need a different subset of requirements. >I think we shouldn't constrain us to defining "a" routing protocol to >satisfy those requirements as much as possible. Please correct me in >case of a misunderstanding. > [Pascal] I agree with that. There will hardly be one fits it all in WSN. It's not just the subnet, the power level and othet low layer things but maybe application layer reasons, like the type of data being reported, the application run in the sensor (like tinyDB vs. Messo), which will be used to structure the network. =20 Still we want interoperability. I see the requirement as a plug-in structure. We need a simple common framework that guarantees some loopless routing and leave up to specific vendors / deployment how the plug ins actually use that framework to structure the network. Pascal _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Mon Apr 23 07:49:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfx2o-0001TV-Pi; Mon, 23 Apr 2007 07:49:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfx2n-0001TN-KD for rsn@ietf.org; Mon, 23 Apr 2007 07:49:21 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfx2n-0003VZ-2E for rsn@ietf.org; Mon, 23 Apr 2007 07:49:21 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 23 Apr 2007 07:49:21 -0400 X-IronPort-AV: i="4.14,441,1170651600"; d="scan'208"; a="119217336:sNHT71484364" 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 l3NBnKkC021828; Mon, 23 Apr 2007 07:49:20 -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 l3NBnKlG002515; Mon, 23 Apr 2007 11:49:20 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 07:49:20 -0400 Received: from [10.86.104.182] ([10.86.104.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 07:49:19 -0400 In-Reply-To: <2a3692de0704200224s67c5782dt5bb75455339a1ceb@mail.gmail.com> References: <6938145F-DB59-4A13-97A2-B0F4CA8EFA7F@cisco.com> <2a3692de0704121858u6d934aeckd891f381a138dec7@mail.gmail.com> <2a3692de0704121922g1c08a2b8q3f74d5c02a5f1b1b@mail.gmail.com> <2a3692de0704200224s67c5782dt5bb75455339a1ceb@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <01C56674-C9BB-47C6-85EA-9F803B567AA1@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [RSN] New Mailing List: Routing for Sensor Network Date: Mon, 23 Apr 2007 07:49:17 -0400 To: Dominik Kaspar X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 23 Apr 2007 11:49:19.0723 (UTC) FILETIME=[6D865BB0:01C7859D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11819; t=1177328960; x=1178192960; 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[RSN]=20New=20Mailing=20List=3A=20Routing=20for=20Sen sor=20Network |Sender:=20 |To:=20Dominik=20Kaspar=20; bh=1huXHL4bI/QHOfOzbh56mfgxXfj+0GurlorwfjIFrQI=; b=zlVfIAKpMK7KwKy5BXtQE9f/99VPoXzk5rm2rqTpeLcedLrFTDVtgJl1o5OVp5bJH36OEj0G WC10So2GqHyjGMN1sBtWpgepUubKIBDYaA31C06lcGtZACKOSCuKfumd; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi Dominik, On Apr 20, 2007, at 5:24 AM, Dominik Kaspar wrote: > JP and David, > > I agree with your point that MANET is not a pre-requisite for sensor > network routing, and the reason why we wrote the routing requirements > draft was to find what will be really necessary for designing a new > protocol or reusing existing protocols. Good, we're in sync. > >> If my understanding is correct you state in R0 "Existing MANET >> protocols (e.g., AODV, OLSR, DYMO) SHOULD be reused." I would >> propose to step back for the moment from any specific solution to >> again focus on the requirements. As indicated below, we may end up >> using a MANET protocol with adaptation but this should not be a pre- >> requisite and none of them fully satisfy the requirements, thus the >> need for discussion on this list and potentially a WG since this >> discussion will likely require a significant amount of work. > > The reason why we added requirement R00 was that 6lowpan has been > handling sensor network issues, and the WG charter states: "As such, > the working group may also work on an informational document to show > how to apply an existing MANET protocol to LoWPANs (e.g., AODV, OLSR, > DYMO, etc)". Therefore, we tried to work within the WG work scope. > > If our R00 causes some confusion, and if the discussion is not > restricted within 6lowpan, but general sensor network routing, I > totally agree that we need to take a different approach for this work. Perfect. > >> As you will see we're trying to exclusively focus on the >> requirements for the time being while staying completely technology >> agnostic, which is key for a requirement ID. > > Well, I can see your concerns from your draft, which our draft also > covers and already listed many common requirements with yours; just > using different wording. (FYI, I listed our intention of the listed > requirements compared to your requirements at the end of this email. I > hope you don't misunderstand this. It's for your better understanding > that we are talking in the same language.) > > One of our main concerns is the possibility of creating a big list of > requirements for sensor networks, but if you analyze what the > requirement differences are between sensor network routing and routing > in other areas (such as MANET) you see that they are mostly coming > from a few common design goals. The main requirements for sensor > networks are namely power saving and what you call "light footprint". > That's why we wrote a chapter on the major design goals and have drawn > out the requirements from that. > > Your requirements draft details the requirements, but IMHO, if you > added another chapter "the design challenge of sensor routing" before > the list of the requirements, and explain the special characteristics > of sensor network and why and how it effects routing, it would > increase readability. For this, I suggest you to check Section 3 of > our draft (http://tools.ietf.org/wg/6lowpan/draft-dokaspar-6lowpan- > routreq-01.txt). > I think we can merge the works to a nice shape. > > Other than to your requirements list, I have one more comment. In > Chapter 3 it is stated that "The objective of this work would be to > define a routing protocol that will satisfy those requirements as much > as possible and that would potentially adapt itself to the particular > deployment context." > > If I understand correctly, this objective contradicts with your own > requirements. Sensor network applications are really diverse, and for > certain applications, they only need a subset of the requirements, > while others need a different subset of requirements. > I think we shouldn't constrain us to defining "a" routing protocol to > satisfy those requirements as much as possible. Please correct me in > case of a misunderstanding. I think that we should indeed try to have "a" routing protocol rather than a set of routing protocols since as soon as more than one routing protocol is defined that does add a lot of complexity, interop issues and so on. There are many such examples of course. Now the question is "Is that possible ?". Here is a proposed approach: 1) Try to list the requirements ... during that phase it is critical to differentiate the MUST, SHOULD, ... 2) If we can find or define "a" protocol that satisfies the MUST and for which we can provide options to support the SHOULD, that would be ideal. We may also decide to not support all the MUST if that allows us to not define many protocols, to be discussed of course. Thanks for the draft comparison. I understand that you added some requirements because of the 6lowpan WG charter. Instead of a comparison, would you want to point the section that you would like to add or remove ? Thanks. JP. > > Greetings, > Dominik & Eunsook > > ------------------------------ > > 2.1. Spatially-Driven Multihop: > - Your point of energy-aware multihop routing is a major design goal > in our draft (Section 3.1) and is addressed by requirement R04 > ("energy-minimal routing"). > > 2.2. Light Footprint: > - This requirement is also one of our major design goals (Section 3.2) > and listed as requirement R05 ("low protocol complexity"). > > 2.3. Small MTU: > - This requirement is covered by our requirements R03 ("small > frames"), R04 ("energy-minimal routing"), R06 ("code length") and in > some way R02 ("header compression"). > > 2.4. Deep power management: > - Parts of this requirement is basically "minimizing energy" again. > - The other part is covered by our requirement R11 ("sleeping nodes") > > 2.5. Heterogeneous Capabilities: > - The way you word it, this requirement also boils down to R04 > ("energy-minimal routing"). > > 2.6. Highly Variable Connectivity: > - The first and third paragraphs are covered by our requirements R13 > ("adaptive topologies") and R04 ("energy-minimal routing"). > - The second paragraph can be seen as a subset of our requirement R11 > ("sleeping nodes") or R08 ("neighbor discovery"); > > 2.7. Structured Workload and Traffic Pattern: > - This requirement is partially described as our R10 ("gateways & > querying"). > > 2.8. Partial Information: > - This requirement has been thought of in our draft as R14 ("scalable > architecture"). > > 2.9. Quality of Service Capable Routing: > - Path selection, path quality optimization and route performance are > already part of other requirements, such as R04 ("energy-minimal > routing"). > - QoS is intentionally left out as a routing requirement for > sensornets. > > 2.10. Data Aware routing: > - If "points of aggregation" is the same as "gateways", it is covered > by our requirement R10 ("gateways & querying"). > > ---<\Draft Comparison>--------------------------- > > > On 4/13/07, JP Vasseur wrote: >> Hi Dominik and and Kim, >> >> Thanks for your email and support for this work, no need to say >> that your >> contribution is most welcome. >> What I would propose here would be for you to read the draft that >> Dave and I >> have posted and that should be >> available in the next few days and provide us some feed-back. >> >> As you will see we're trying to exclusively focus on the >> requirements for >> the time being while staying completely technology agnostic, which >> is key >> for a requirement ID. >> >> If my understanding is correct you state in R0 "Existing MANET >> protocols >> (e.g., AODV, OLSR, DYMO) SHOULD be reused." I would propose to >> step back for >> the moment from any specific solution to again focus on the >> requirements. As >> indicated below, we may end up using a MANET protocol with >> adaptation but >> this should not be a pre-requisite and none of them fully satisfy the >> requirements, thus the need for discussion on this list and >> potentially a WG >> since this discussion will likely require a significant amount of >> work. >> There is another fundamental difference: in R02 you mention >> "6LoWPAN routing >> MUST be performed in the adaptation layer, as defined in [3].". We >> propose >> to specify a routing protocol for Sensor Network above IP, not >> coupled with >> any specific layer1/2 technologies, which is of the utmost >> importance to >> support mixed environments that already exist. >> >> Looking forward to having your comments on the draft >> (draft-culler-rsn-routing-reqs-00.txt), which should be >> available very soon. >> >> Thanks. >> >> JP. >> >> >> On Apr 12, 2007, at 10:22 PM, Dominik Kaspar wrote: >> >> JP, David, >> >> I would like to refer to our 6lowpan Routing Requirements draft, >> which >> discusses the issues of routing in "sensor networks". The draft >> provides design goals and a list of requirements for IP-based routing >> solutions in low-rate WPANs. >> >> At IETF-68 in Prague, we presented our work and solicited advice from >> both MANET and 6lowpan folks. There seemed to be a general consent >> that routing is a very important task to solve, however, it is >> heavily >> dependent on the network architecture itself, and what exactly this >> "architecture" is should be clarified first. >> >> If you haven't done it yet, please read our draft; we appreciate any >> constructive comments: >> http://tools.ietf.org/wg/6lowpan/draft-dokaspar-6lowpan- >> routreq-01.txt >> >> Sincerely, >> Dominik >> >> >> On 4/12/07, JP Vasseur wrote: >> Hi, >> >> We wanted to inform you that a new Mailing List has been set up, >> the aim of >> which is to discuss Routing for Sensor Networks (at the IP layer). >> Anybody >> interested in contributing to the work is of course more than >> welcome to >> subscribe and collaborate. To register: >> https://www1.ietf.org/mailman/listinfo/rsn >> >> Several of you already expressed some real interest in this work >> and several >> documents (with currently no home WG) already exist. David and I >> posted are >> about to post an ID on the routing requirements for Sensor Networks >> (probably early next week) to kick off the discussion. >> >> What is the overall objective ? >> 1) As you know a plethora of proprietary routing protocols (thus >> outside of >> the IETF) have been developed and there is within the IETF >> currently no >> clear answer on which protocol(s) can satisfy the very specific >> requirements >> of Sensor Networks. This triggered this initiative so as to define >> a routing >> architecture and routing protocol at the IETF for Sensor Nets, >> thus this new >> mailing list. Note that we may not be able to come up with a >> single set of >> requirements but a few requirement documents accompanied with some >> applicability IDs if it turns out that a unique solution cannot >> satisfy them >> all. >> 2) There is at this stage no a priori on the routing protocol that >> could be >> used: it could either be (1) existing routing protocol(s) (AODV, >> DYMO, OLSR, >> Triggered RIP, NEMO, ...) (1) existing routing protocol(s) with >> enhancements >> or (3) new routing protocol(s). >> >> Possible next steps >> If enough interest for this work is shown on the list, we will >> request a BOF >> for Chicago, which may lead to forming a new WG. >> >> JP and David. >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >> >> _______________________________________________ >> RSN mailing list >> RSN@ietf.org >> https://www1.ietf.org/mailman/listinfo/rsn >> _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Mon Apr 23 08:30:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfxgO-0000mj-2o; Mon, 23 Apr 2007 08:30:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfxgM-0000me-RN for rsn@ietf.org; Mon, 23 Apr 2007 08:30:14 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfxgK-0005iF-Dn for rsn@ietf.org; Mon, 23 Apr 2007 08:30:14 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 23 Apr 2007 08:29:56 -0400 X-IronPort-AV: i="4.14,441,1170651600"; d="scan'208,217"; a="119220048:sNHT43793331742" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3NCTupJ011154; Mon, 23 Apr 2007 08:29:56 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3NCTuGd011554; Mon, 23 Apr 2007 12:29:56 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 08:29:44 -0400 Received: from [10.86.104.182] ([10.86.104.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 08:29:43 -0400 In-Reply-To: References: <0DE20062-EA06-49BA-B4A6-0219572B275D@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <38C8A521-13B7-458E-B33C-29EA23C972E2@cisco.com> From: JP Vasseur Date: Mon, 23 Apr 2007 08:29:40 -0400 To: Ki-Hyung Kim X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 23 Apr 2007 12:29:43.0932 (UTC) FILETIME=[12774BC0:01C785A3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3891; t=1177331396; x=1178195396; 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:=20Routing=20Manageability |Sender:=20 |To:=20Ki-Hyung=20Kim=20; bh=2sxeSfRPBaFM8t7+K10E1b8tBG5fFtQvJvgKmmuYrU0=; b=h/sFFrk8OUpJJYfgsFKBZTDVMFKEpc8eDCwaIar51chrZJgNCKAvGlTKpGs5Hv+BfqmdhqcX AazqEuf+MOr/+bdjl/pKNYG/LM+vJ1Ga6p9cRBUCxu3+eFwmbUvCwXgC; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: rsn@ietf.org Subject: [RSN] Routing Manageability X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1711556812==" Errors-To: rsn-bounces@ietf.org --===============1711556812== Content-Type: multipart/alternative; boundary=Apple-Mail-31--691799015 --Apple-Mail-31--691799015 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=EUC-KR; delsp=yes; format=flowed Hi Kim, On Apr 18, 2007, at 1:40 AM, Ki-Hyung Kim wrote: > Hi, JP, > > I am interested in the manageability issue. > Excellent, would you want to draft a manageability section and we'll =20 start from there ? Thanks. JP. > > > > > On 4/18/07, JP Vasseur wrote: > Dear list members, > > I guess that we all agree on the fact Routing Security is a > particularly important topics for Sensor Networks. There is another > key topic that we'd like to address: manageability (in a separate > thread). > > David and I decided to work soon on the security aspects; that said, > if there are security experts on this list willing to help out, > please let us know (let's use the list also). > > We could also ask to the security AD to see whether they could > appoint security experts. > > Thanks. > > JP. > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn > > > > --=20 > Ki-Hyung Kim (=B1=E8=B1=E2=C7=FC, =D0=DD=D1=C3=FA=FB) > Associate Professor > Division of Information and Computer Eng., Ajou University, Suwon, =20 > Korea 442-749 > Tel: +82-31-219-2433, Cel: +82-17-760-2551, Fax: +82-31-219-2433 =20 > http://www.6lowpan.org --Apple-Mail-31--691799015 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Kim,

On Apr = 18, 2007, at 1:40 AM, Ki-Hyung Kim wrote:

Hi, = JP,
=C2=A0
I am interested in the manageability = issue.


Excellent, would you want = to draft a manageability section and we'll start from there = ?

Thanks.

JP.

=C2=A0


=C2=A0
On 4/18/07, JP = Vasseur <jvasseur@cisco.com> = wrote:
Dear list = members,

I guess that we all agree on the fact Routing Security = is a
particularly important topics for Sensor Networks. There is = another
key topic that we'd like to address: manageability (in a = separate
thread).

David and I decided to work soon on the = security aspects; that said,
if there are security experts on this = list willing to help out,
please let us know (let's use the list = also).

We could also ask to the security AD to see whether they = could
appoint security = experts.

Thanks.

JP.

________________________________= _______________
RSN mailing list
RSN@ietf.org
https://www1.ietf.org/= mailman/listinfo/rsn



--
Ki-Hyung Kim (=EA=B9=80=EA=B8=B0=ED=98=95, = =EF=A4=8A=E8=B5=B7=E4=BA=A8)
Associate Professor
Division of = Information and Computer Eng., Ajou University, Suwon, Korea = 442-749
Tel: +82-31-219-2433, Cel: +82-17-760-2551,=C2=A0=C2=A0Fax: = +82-31-219-2433 = http://www.6lowpan.org

= --Apple-Mail-31--691799015-- --===============1711556812== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============1711556812==-- From rsn-bounces@ietf.org Mon Apr 23 09:30:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfycf-0000Oj-FP; Mon, 23 Apr 2007 09:30:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfyce-0000Oe-B2 for rsn@ietf.org; Mon, 23 Apr 2007 09:30:28 -0400 Received: from relay1.ptmail.sapo.pt ([212.55.154.21] helo=sapo.pt) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hfycc-0003k4-Lu for rsn@ietf.org; Mon, 23 Apr 2007 09:30:28 -0400 Received: (qmail 11262 invoked from network); 23 Apr 2007 13:30:20 -0000 Received: from unknown (HELO sapo.pt) (10.134.35.209) by relay1 with SMTP; 23 Apr 2007 13:30:20 -0000 Received: (qmail 29846 invoked from network); 23 Apr 2007 13:30:15 -0000 X-AntiVirus: PTMail-AV 0.3-0.90.1 X-Virus-Status: Clean (0.05057 seconds) Received: from unknown (HELO [192.168.1.10]) (tandre@sapo.pt@[85.240.136.86]) (envelope-sender ) by mta14 (qmail-ldap-1.03) with SMTP for ; 23 Apr 2007 13:30:15 -0000 Message-ID: <462CB501.7040107@dei.uc.pt> Date: Mon, 23 Apr 2007 14:30:41 +0100 From: Tiago Camilo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: JP Vasseur Subject: Re: [RSN] Routing Manageability References: <0DE20062-EA06-49BA-B4A6-0219572B275D@cisco.com> <38C8A521-13B7-458E-B33C-29EA23C972E2@cisco.com> In-Reply-To: <38C8A521-13B7-458E-B33C-29EA23C972E2@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi, I am also interesting in working in manageability in terms of layer 3. Thanks, Tiago JP Vasseur wrote: > Hi Kim, > > On Apr 18, 2007, at 1:40 AM, Ki-Hyung Kim wrote: > >> Hi, JP, >> >> I am interested in the manageability issue. >> > > Excellent, would you want to draft a manageability section and we'll > start from there ? > > Thanks. > > JP. > >> >> >> >> >> On 4/18/07, *JP Vasseur* > > wrote: >> >> Dear list members, >> >> I guess that we all agree on the fact Routing Security is a >> particularly important topics for Sensor Networks. There is another >> key topic that we'd like to address: manageability (in a separate >> thread). >> >> David and I decided to work soon on the security aspects; that said, >> if there are security experts on this list willing to help out, >> please let us know (let's use the list also). >> >> We could also ask to the security AD to see whether they could >> appoint security experts. >> >> Thanks. >> >> JP. >> >> _______________________________________________ >> RSN mailing list >> RSN@ietf.org >> https://www1.ietf.org/mailman/listinfo/rsn >> >> >> >> >> -- >> Ki-Hyung Kim (김기형, 金起亨) >> Associate Professor >> Division of Information and Computer Eng., Ajou University, Suwon, >> Korea 442-749 >> Tel: +82-31-219-2433, Cel: +82-17-760-2551, Fax: +82-31-219-2433 >> http://www.6lowpan.org > > ------------------------------------------------------------------------ > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn > _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Mon Apr 23 12:29:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1QD-0000i9-Hk; Mon, 23 Apr 2007 12:29:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1QC-0000ho-3r for rsn@ietf.org; Mon, 23 Apr 2007 12:29:48 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg1QA-0006XL-IA for rsn@ietf.org; Mon, 23 Apr 2007 12:29:48 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 23 Apr 2007 12:29:33 -0400 X-IronPort-AV: i="4.14,443,1170651600"; d="scan'208"; a="119250635:sNHT36410634108" 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 l3NGTUAr016472; Mon, 23 Apr 2007 12:29:30 -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 l3NGTRlG029041; Mon, 23 Apr 2007 16:29:30 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 12:29:27 -0400 Received: from [10.86.104.182] ([10.86.104.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 12:29:27 -0400 In-Reply-To: <462CB501.7040107@dei.uc.pt> References: <0DE20062-EA06-49BA-B4A6-0219572B275D@cisco.com> <38C8A521-13B7-458E-B33C-29EA23C972E2@cisco.com> <462CB501.7040107@dei.uc.pt> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: <419B63AA-3F1F-41B9-AE56-223872B98418@cisco.com> Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: [RSN] Routing Manageability Date: Mon, 23 Apr 2007 12:20:23 -0400 To: Tiago Camilo X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 23 Apr 2007 16:29:27.0129 (UTC) FILETIME=[8F84FC90:01C785C4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2578; t=1177345770; x=1178209770; 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[RSN]=20Routing=20Manageability |Sender:=20 |To:=20Tiago=20Camilo=20; bh=Ig8qC3JHKGYsiLA3qhIgUn+7EzrBvzLb6Lt66ljc11k=; b=SuTg/7uUiPnqs8LI8Gj6dlnBXKeZHh//NRqFFN8PS91U/44dcl8pKkfEsbWFWDC/qft2Ne29 kYg1HkBQ8VAVIn8urtfswy1a0ZvnVbTFBU0PtF+5qUmjdGCHyQH+mdOj; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi, On Apr 23, 2007, at 9:30 AM, Tiago Camilo wrote: > Hi, > I am also interesting in working in manageability in terms of layer 3. > Great, just to make sure to avoid any confusion: we're not talking =20 about Manageability for Sensor Networks in general of course but manageability for the routing protocol =20 designed for Sensor Networks. Let me point to another ID: http://www.ietf.org/internet-drafts/draft-=20= ietf-pce-manageability-requirements-01.txt that provides some =20 guidance on manageability sections in another context but that sheds =20 some light on the spirit on the section we should be looking for, for =20= this requirements ID. Does that make sense ? Thanks. JP. > Thanks, > Tiago > > JP Vasseur wrote: >> Hi Kim, >> >> On Apr 18, 2007, at 1:40 AM, Ki-Hyung Kim wrote: >> >>> Hi, JP, >>> I am interested in the manageability issue. >>> >> >> Excellent, would you want to draft a manageability section and =20 >> we'll start from there ? >> >> Thanks. >> >> JP. >> >>> >>> >>> On 4/18/07, *JP Vasseur* >> > wrote: >>> >>> Dear list members, >>> >>> I guess that we all agree on the fact Routing Security is a >>> particularly important topics for Sensor Networks. There is =20 >>> another >>> key topic that we'd like to address: manageability (in a =20 >>> separate >>> thread). >>> >>> David and I decided to work soon on the security aspects; =20 >>> that said, >>> if there are security experts on this list willing to help out, >>> please let us know (let's use the list also). >>> >>> We could also ask to the security AD to see whether they could >>> appoint security experts. >>> >>> Thanks. >>> >>> JP. >>> >>> _______________________________________________ >>> RSN mailing list >>> RSN@ietf.org >>> https://www1.ietf.org/mailman/listinfo/rsn >>> >>> >>> >>> >>> --=20 >>> Ki-Hyung Kim (=EA=B9=80=EA=B8=B0=ED=98=95, =EF=A4=8A=E8=B5=B7=E4=BA=A8= ) >>> Associate Professor >>> Division of Information and Computer Eng., Ajou University, =20 >>> Suwon, Korea 442-749 >>> Tel: +82-31-219-2433, Cel: +82-17-760-2551, Fax: +82-31-219-2433 =20= >>> http://www.6lowpan.org >> >> ---------------------------------------------------------------------=20= >> --- >> >> _______________________________________________ >> RSN mailing list >> RSN@ietf.org >> https://www1.ietf.org/mailman/listinfo/rsn >> _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu Apr 26 09:34:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh46n-0007tI-NE; Thu, 26 Apr 2007 09:34:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh46m-0007tD-LY for rsn@ietf.org; Thu, 26 Apr 2007 09:34:04 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh46l-0005Z4-Ah for rsn@ietf.org; Thu, 26 Apr 2007 09:34:04 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 26 Apr 2007 09:34:04 -0400 X-IronPort-AV: i="4.14,454,1170651600"; d="scan'208"; a="58677761:sNHT43449240" 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 l3QDY2wj000963; Thu, 26 Apr 2007 09:34:02 -0400 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 l3QDY2Gd005360; Thu, 26 Apr 2007 13:34:02 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 09:34:02 -0400 Received: from [10.86.104.182] ([10.86.104.182]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 09:34:02 -0400 In-Reply-To: <6ae06b9f0704230020h6b2feffm19581eae0e6af1fd@mail.gmail.com> References: <6ae06b9f0704230020h6b2feffm19581eae0e6af1fd@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0182B2B4-B70F-42E6-B93F-8087A2488474@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Thu, 26 Apr 2007 09:33:56 -0400 To: Narendran Sivakumar X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 26 Apr 2007 13:34:02.0090 (UTC) FILETIME=[8D58BCA0:01C78807] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=624; t=1177594442; x=1178458442; 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[manet]=20Re=20=3A=20Energy=20Efficiency=20in=20Routi ng=20Protocols |Sender:=20 |To:=20Narendran=20Sivakumar=20; bh=/jf/rv3fjbatLpms8IO7lM36Pnr+OJDDA7N8U4/ZDIQ=; b=PPje5VFmVgdgvQl/mAQkMz2kzMGo6hl6+ZmDjCAwspHUGM71lpd+tjtc+DfcmrlLvhBgtZgI grh72goyOuq4DacJm0k5hAzHIGdR8QIkBmENc+feHiKVkHf6MuYSodQN; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: rsn@ietf.org Subject: [RSN] Re: [manet] Re : Energy Efficiency in Routing Protocols X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org copying the RSN list since this is a key requirement for Sensor Networks. On Apr 23, 2007, at 3:20 AM, Narendran Sivakumar wrote: > Dear All , > > I've implemented DYMO and comparing the performance of DYMO with > other protocols. Is there a way to analyze how energy efficient > these protocols especially DYMO as i consider energy efficiency a > big factor. > > Any suggestions and ideas relating to this subject are most welcome. > > Thank You > > Naren > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn