Re: [RSN] Update
JP Vasseur <jvasseur@cisco.com> Sat, 14 July 2007 12:56 UTC
Return-path: <rsn-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9hAe-0003LB-U7; Sat, 14 Jul 2007 08:56:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9hAd-0003Eq-2m for rsn@ietf.org; Sat, 14 Jul 2007 08:56:23 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9hAZ-0008Hr-FJ for rsn@ietf.org; Sat, 14 Jul 2007 08:56:23 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 14 Jul 2007 08:56:19 -0400
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8CAINkmEZAZnme/2dsb2JhbACCLzM
X-IronPort-AV: i="4.16,538,1175486400"; d="scan'208,217"; a="126051589:sNHT51745394"
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 l6ECuIPp007686; Sat, 14 Jul 2007 08:56:18 -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 l6ECuIWI000198; Sat, 14 Jul 2007 12:56:18 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); Sat, 14 Jul 2007 08:56:18 -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); Sat, 14 Jul 2007 08:56:17 -0400
In-Reply-To: <OF88D27330.F5A4BB25-ONC12572F2.004D4C6F-C12572F2.004EA42A@philips.com>
References: <OF88D27330.F5A4BB25-ONC12572F2.004D4C6F-C12572F2.004EA42A@philips.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Message-Id: <3BB9A12B-5DE5-4D1E-8DFC-2D650251E7C0@cisco.com>
From: JP Vasseur <jvasseur@cisco.com>
Subject: Re: [RSN] Update
Date: Sat, 14 Jul 2007 08:55:42 -0400
To: Anthony Schoofs <anthony.schoofs@philips.com>
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 14 Jul 2007 12:56:17.0921 (UTC) FILETIME=[5E6E3710:01C7C616]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11669; t=1184417778; x=1185281778; 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<jvasseur@cisco.com> |Subject:=20Re=3A=20[RSN]=20Update |Sender:=20 |To:=20Anthony=20Schoofs=20<anthony.schoofs@philips.com>; bh=12LMFYvQhm619iEv7LWcAPPY5A+XGlH0rrr6SJnYD6c=; b=saxqb+L0/qqX/1FzIwvDpS8SHJDSDY9NkAZmcbaSByYvSpJiT1S6/DraqwTPd8qYY/++rwCx tgAZMv0DM88yFEoGTFvJ23hdV1JBSAH0wmYMUz7bUt7MMtE1sEHBUpKe;
Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91
Cc: rsn@ietf.org
X-BeenThere: rsn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing Sensor Networks <rsn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/rsn>
List-Post: <mailto:rsn@ietf.org>
List-Help: <mailto:rsn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0842661601=="
Errors-To: rsn-bounces@ietf.org
Hi Anthony, On Jun 6, 2007, at 10:21 AM, Anthony Schoofs wrote: > > JP, I agree when you said in a previous email: > > > "the proposal is to design a IP routing solution > > specifically for sensor networks, that would of course be > independent > > to the L1/L2 protocol in use (it may be desirable to take into > account > > link layer attributes when calculating a route but the routing > process > > would not be tied up with the link layer). > > In addition, our routing scheme should know when the PAN > coordinator/Gateway location has changed to lower and balance the > network energy consumption. > Then new timezones can be assigned and data routed accordingly. Interesting, your feed-back on several on the new ID would be very welcome in light of the experience with your routing protocol. > > I am looking forward to seeing this new WG formed, Thanks, JP. > Best regards, > Anthony. > > > -- > Anthony Schoofs > Philips Research WY 7-038 > High Tech Campus 37 , 5656 AE Eindhoven, The Netherlands > Email: anthony.schoofs@philips.com > > > > > > > > > Anthony Schoofs > 04-06-2007 12:06 > > To > JP Vasseur <jvasseur@cisco.com> > cc > rsn@ietf.org > Subject > Re: [RSN] Update > Classification > > > > > > > We did some work to schedule a coordinate switching on and off of > sensor nodes in order to reduce at maximum the energy consumption > of the network. > We came up with a routing protocol that allows us to route data > throughout the network according to the ON/OFF state of the nodes. > > We would like to provide input for an ID on routing schemes that > have energy consumption as the first focus. > > Best regards, > Anthony. > > -- > Anthony Schoofs > Philips Research > High Tech Campus 37 , 5656 AE Eindhoven, The Netherlands > Email: anthony.schoofs@philips.com > > > > > > > > JP Vasseur <jvasseur@cisco.com> > 03-06-2007 14:02 > > > To > rsn@ietf.org > cc > Subject > [RSN] Update > Classification > > > > > > > > Dear all, > > Here is an update on where we stand: good progress ! > > 1) We've been having quite a bit of off-line and on-line discussions > and there is apparently a good level of interest in this work. > There are currently 5 IDs in the works: > * The generic routing requirements: draft-culler-rsn-routing-reqs > * Two application-specific routing requirements: > - Home Networking > - Industrial > * A problem statement > * An ID on routing metrics > > Of course, if you're interested to work on these IDs or other items, > feel free ! > > 2) New name > Although we called this initiative RSN: Routing for Sensor Networks, > it does apply more generally to constrained nodes (Low Power) > operating in Lossy Networks. Objects in general would typically be > part of those networks. So from now on, let's rename this work > R2LN: "Routing issues for Low Power, Lossy Networks", and use that > acronym in all IDs. > > 3) Next IETF > We asked for a presentation slot for the next IETF. Depending on the > feedback, the next step would then to request a BOF in Vancouver. > > Thanks. > > JP and David. > > _______________________________________________ > 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
- Re: [RSN] Update Cuda Alberto
- [RSN] Update JP Vasseur
- Fwd: [RSN] Update JP Vasseur
- Re: [RSN] Update Timothy J. Salo
- Re: [RSN] Update Mark Townsley
- Re: [RSN] Update JP Vasseur
- Re: [RSN] Industrial Zach Shelby
- Re: [RSN] Update Anthony Schoofs
- RE: [RSN] Update dculler
- Re: [RSN] Update Traian MUNTEAN
- Re: [RSN] Update Timothy J. Salo
- RE: [RSN] Update Anders Brandt
- Re: [RSN] Update JP Vasseur
- Re: [RSN] Update Anthony Schoofs
- [RSN] The need for RSN Geoff Mulligan
- Re: [RSN] The need for RSN Dominik Kaspar
- Re: [RSN] Update Philip Levis
- [RSN] Update JP Vasseur
- Re: [RSN] Update JP Vasseur
- [RSN] Update JP Vasseur