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