From rsn-bounces@ietf.org Wed May 09 17:19:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HltZT-0007Sm-SW; Wed, 09 May 2007 17:19:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HltG6-0004xN-Sl for RSN@ietf.org; Wed, 09 May 2007 16:59:39 -0400 Received: from smw151.hostingcare.net ([67.19.193.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HltG6-00010r-9J for RSN@ietf.org; Wed, 09 May 2007 16:59:38 -0400 Received: from smw151 ([127.0.0.1]) by smw151.hostingcare.net with MailEnable ESMTP; Wed, 09 May 2007 09:44:30 -0500 thread-index: AceSSI1IYtJrpRVHSIqIqtSRM13FTA== Thread-Topic: Call for Paper :: Special Issue on Ubiquitous Sensor Networks From: To: Date: Wed, 9 May 2007 09:44:30 -0500 Message-ID: <5445C4B410E248988521E8D461A85698@hostingcare.net> MIME-Version: 1.0 X-Mailer: Microsoft CDO for Windows 2000 Content-Class: urn:content-classes:message Importance: high Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3959 X-Spam-Score: 0.9 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 X-Mailman-Approved-At: Wed, 09 May 2007 17:19:38 -0400 Cc: Subject: [RSN] Call for Paper :: Special Issue on Ubiquitous Sensor Networks 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="===============1607373134==" Errors-To: rsn-bounces@ietf.org This is a multi-part message in MIME format. --===============1607373134== Content-Type: multipart/alternative; boundary="----=_NextPart_000_7F30_01C7921E.A4723210" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_7F30_01C7921E.A4723210 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Ubiquitous Computing and Communication Journal Call for Papers Special Issue on Ubiquitous Sensor Networks A ubiquitous sensor network is a combination of sensor networks and ubiquitous computing. It is a blend of theoretical and practical aspects of sensing, networking, middleware, applications, and management. In the future pervasive paradigm, ubiquitous sensor networks are envisioned not only to initiate an enormous number of new applications but also to add values to many existing applications in the areas of critical infrastructure protection and security, health care, environmental protection, industrial monitoring and control, food safety, and the potential impact on the quality of all areas of life. The purpose of this special issue is to promote the sharing of high quality research addressing both the theoretical and practical aspects of ubiquitous sensor networks. Your contribution to this special issue would be highly appreciated. Authors are invited to submit complete unpublished papers, which are not under review in any other conference or journal. The topics include but are not limited to the followings areas of ubiquitous sensor networks: - Architectures, Protocols and Algorithms Network architecture, Network topologies, Communication theory, Network protocols, Routing metrics and protocols, etc. - Management and Control Management models, Resource Provisioning, Location and Mobility management, Resource management, Topology control, Distributed actuation and control, Algorithms for self-management, etc. - Resource Allocation and Quality of Service Resource Allocation and fairness, Real time resource scheduling, capacity planning, QoS, Service level agreements, etc. - Performance Modeling Performance measurement, Comparison on capacity, coverage and connectivity, Modeling techniques, Simulation and theoretical analysis, Validation of ubiquitous sensor networks architectures, etc. - Security and Monitoring Security and privacy, Reliability, Encryption, Authentication, etc. - Software and Applications Disaster relief, Service discovery, Medical support, Context-aware applications, Living support, Smart home environments, etc. - Deployment and Implementation Models for deployment, Real life experiences, System implementations, Test beds, End-user aspects, etc. - Data Allocation and Information Processing Data processing, Data retrieval and dissemination, Query processing, Databases, etc IMPORTANT DATES: Manuscript Submission: May 20, 2007 First Notification: July 23,2007 Revised Final Submission: September 10, 2007 Publication Date: October 2007 Guest Editor Shafique Ahmad Chaudhry, Internet Lab, Division of Information and Communication, 532-Sanhak Hall, Ajou University , Wonchon-Dong, Yeongtong-Gu, Suwon , Republic of Korea 442-749. Phone: +82-31-219-1891 Cell: +82-10-5821-0055 Email: shafique@ajou.ac.kr , hazrat.shafique@gmail.com ------=_NextPart_000_7F30_01C7921E.A4723210 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

Ubiquitous Computing and Communication Journal  

Call for Papers

Special Issue on Ubiquitous Sensor Networks

 A ubiquitous sensor network is a combination of sensor networks and ubiquitous computing. It is a blend of theoretical and practical aspects of sensing, networking, middleware, applications, and management. In the future pervasive paradigm, ubiquitous sensor networks are envisioned not only to initiate an enormous number of new applications but also to add values to many existing applications in the areas of critical infrastructure protection and security, health care, environmental protection, industrial monitoring and control, food safety, and the potential impact on the quality of all areas of life. 

   The purpose of this special issue is to promote the sharing of high quality research addressing both the theoretical and practical aspects of ubiquitous sensor networks. Your contribution to this special issue would be highly appreciated.

   Authors are invited to submit complete unpublished papers, which are not under review in any other conference or journal. The topics include but are not limited to the followings areas of ubiquitous sensor networks:

 

-         Architectures, Protocols and Algorithms

Network architecture, Network topologies, Communication theory, Network protocols, Routing metrics and protocols, etc.

-         Management and Control

Management models, Resource Provisioning, Location and Mobility management, Resource management, Topology control, Distributed actuation and control, Algorithms for self-management, etc.

-         Resource Allocation and Quality of Service

Resource Allocation and fairness, Real time resource scheduling, capacity planning, QoS, Service level agreements, etc.

-         Performance Modeling

Performance measurement, Comparison on capacity, coverage and connectivity, Modeling techniques, Simulation and theoretical analysis, Validation of ubiquitous sensor networks architectures, etc.

-        Security and Monitoring

Security and privacy, Reliability, Encryption, Authentication, etc.

-        Software and Applications

Disaster relief, Service discovery, Medical support, Context-aware applications, Living support, Smart home environments, etc.

-         Deployment and Implementation

Models for deployment, Real life experiences, System implementations, Test beds, End-user aspects, etc.

-         Data Allocation and  Information Processing

Data processing, Data retrieval and dissemination, Query processing, Databases, etc

 

IMPORTANT DATES:

 

Manuscript Submission:                  May 20, 2007

First Notification:                              July 23,2007

Revised Final Submission:              September 10, 2007

Publication Date:                                 October 2007

 

Guest Editor

 

Shafique Ahmad Chaudhry,

 

Internet Lab, Division of Information and Communication,

532-Sanhak Hall, Ajou University , Wonchon-Dong, Yeongtong-Gu,

Suwon , Republic of Korea 442-749.

Phone:  +82-31-219-1891  Cell: +82-10-5821-0055

Email: shafique@ajou.ac.kr , hazrat.shafique@gmail.com

------=_NextPart_000_7F30_01C7921E.A4723210-- --===============1607373134== 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 --===============1607373134==-- From rsn-bounces@ietf.org Sat May 12 23:33: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 1Hn4ps-00016s-RS; Sat, 12 May 2007 23:33:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hn4ps-00016i-90 for rsn@ietf.org; Sat, 12 May 2007 23:33:28 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hn4pr-0005uk-0V for rsn@ietf.org; Sat, 12 May 2007 23:33:28 -0400 Received: by ug-out-1314.google.com with SMTP id 72so847354ugd for ; Sat, 12 May 2007 20:33:26 -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=qx8eExcp4VCRFUS0kmwZlfLO2Wi6Bv5Pv/Rrxv8zi73cRBSbjA9ccbw8tqEvW9vge+WkzWRsk96zSaSva1GjF8y+/WodCksB9101mK/XlJwytdMcfaUmHoNABBHmkpmzkyRcuDKDU2SssLRi/tJp/kjL3ZBH7Dd77Swjr48xTnQ= 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=NvH7xrU64FVmcv3gRecbFdZuTbqUdCIkSf/6QzYy+wt8TEA7ZO5g3qz8IbD1gKg7Gu53FAzAFndxHAprZ/diWnWL6ivAOA2IxBg3bzfP7T8b2GlGP6aNv6eLChzKnGzc0/ssBnGPdOkOH3cXBM9aWCN3wKGoSLE9HpsNzyCQWK0= Received: by 10.78.83.15 with SMTP id g15mr1662216hub.1179027206276; Sat, 12 May 2007 20:33:26 -0700 (PDT) Received: by 10.78.33.14 with HTTP; Sat, 12 May 2007 20:33:26 -0700 (PDT) Message-ID: <374005f30705122033n7989a1eap32346178cbdfef3b@mail.gmail.com> Date: Sun, 13 May 2007 09:03:26 +0530 From: "Ian Chakeres" To: rsn@ietf.org In-Reply-To: <374005f30705091834o49417256m944eab1bdbbc1371@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: <374005f30705091834o49417256m944eab1bdbbc1371@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: 6lowpan <6lowpan@ietf.org> Subject: [RSN] 6lowpan devices constraints 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 adding RSN to the conversation It appears that my question might have been misinterpreted or more likely I presented the two choices inappropriately. Let me try pose the question in another way. How much short term memory can we expect these devices to have? And how much can we use for routing functions? Can a routing function make use of 100's or 1000's of bytes of short term memory? My understanding was that memory is scarce and very hard limited. Alternatively, energy though scarce does not have as hard a limit. Ian Chakeres _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Sun May 13 08:43: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 1HnDQJ-0000jY-05; Sun, 13 May 2007 08:43:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hn5kg-0004uc-9r; Sun, 13 May 2007 00:32:10 -0400 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hn5ke-0005bD-Sy; Sun, 13 May 2007 00:32:10 -0400 Received: from [127.0.0.1] (mpls.saloits.com [216.243.132.62]) by newbsd.saloits.com (8.13.1/8.13.1) with ESMTP id l4D4Vsdc036929; Sat, 12 May 2007 23:32:06 -0500 (CDT) (envelope-from salo@saloits.com) Message-ID: <464694B2.9060201@saloits.com> Date: Sat, 12 May 2007 23:31:46 -0500 From: "Timothy J. Salo" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> References: <374005f30705091834o49417256m944eab1bdbbc1371@mail.gmail.com> <374005f30705122033n7989a1eap32346178cbdfef3b@mail.gmail.com> In-Reply-To: <374005f30705122033n7989a1eap32346178cbdfef3b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-Mailman-Approved-At: Sun, 13 May 2007 08:43:37 -0400 Cc: rsn@ietf.org Subject: [RSN] Re: [6lowpan] 6lowpan devices constraints 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 Ian Chakeres wrote: > How much short term memory can we expect these devices to have? And > how much can we use for routing functions? Can a routing function make > use of 100's or 1000's of bytes of short term memory? I believe that in some markets (e.g., home automation) vendors will try to include the absolute minimum amount of memory in large-volume, cost-sensitive (consumer-grade) products. A few cents-per-device cost reduction times a few tens-of-millions of units starts to add up to (sort of) real money. On the other hand, I suspect that there will also be classes of devices sold into these very cost-competitive markets that are slightly less cost sensitive. For example, vendors might be convinced to put a bit more memory in the wired/wireless gateways (are we allowed to say that word?) if we can give them a good reason to. Another strategy is to assume that the lowest-end devices will have enough memory to support the ZigBee protocol stack, and so we should ensure that we work with these devices. After we achieve that objective, we can use any leftover (RAM) memory for buffers. > My understanding was that memory is scarce and very hard limited. > Alternatively, energy though scarce does not have as hard a limit. I think that there will be two classes of devices in most of these networks: battery-powered and mains-powered. For a battery-powered device, energy consumption translates directly into product lifetime (for some devices) or at least into mean-time-to-battery-replacement. For mains-powered devices (e.g., wired/wireless gateways or home automation controllers) energy will be essentially unlimited. I believe that routing protocols that can more effectively accommodate both energy-constrained devices and and energy-rich devices will better meet the needs of these markets than will routing protocols that don't differentiate between these classes of devices. If nobody else beats me to it, I will go look up the characteristics of some of the current 802.14.4/ZigBee SOC products. -tjs _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Wed May 16 09:02:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoJ9Q-0001vl-F7; Wed, 16 May 2007 09:02:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnyJB-00015J-FH; Tue, 15 May 2007 10:47:25 -0400 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnyJ9-0007Vb-Ud; Tue, 15 May 2007 10:47:25 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l4FDjXW1015589; Tue, 15 May 2007 09:45:33 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l4FElMuX218252; Tue, 15 May 2007 10:47:22 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l4FElLcW002977; Tue, 15 May 2007 10:47:22 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l4FElLxR002971; Tue, 15 May 2007 10:47:21 -0400 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-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 Message-ID: From: Kang-won Lee Date: Tue, 15 May 2007 10:47:20 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V80_M4_03042007|March 04, 2007) at 05/15/2007 10:47:23, Serialize complete at 05/15/2007 10:47:23 X-Spam-Score: 0.1 (/) X-Scan-Signature: da41e01217ab11ad82db577473e913ae X-Mailman-Approved-At: Wed, 16 May 2007 09:02:43 -0400 Cc: youngko@ajou.ac.kr Subject: [RSN] CFP: USN 2007 Extended Deadline to June 15 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="===============0562359954==" Errors-To: rsn-bounces@ietf.org This is a multipart message in MIME format. --===============0562359954== Content-Type: multipart/alternative; boundary="=_alternative 0051302C852572DC_=" This is a multipart message in MIME format. --=_alternative 0051302C852572DC_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable [Please accept our apologies if you receive multiple copies of this CFP] ---------------------------------------------------- CALL FOR PAPERS for USN 2007 The 3rd International Workshop on RFID and Ubiquitous Sensor Networks=20 (USN)=20 http://uns.ajou.ac.kr/~usn2007/, December 17-20, 2007, Taipei, Taiwan) To be held in conjunction with EUC 2007 ---------------------------------------------------- Important Dates: * Submission Due: June 15, 2007 (extended deadline) * Acceptance notification: August 6, 2007=20 * Camera-ready due: September 4, 2007=20 =20 About the workshop: The purpose of USN 2007 is to establish a discussion framework on all the=20 challenges raised from the evolution of the Ubiquitous Sensor Networks and = RFID technologies. As a unique opportunity to obtain an insight on the=20 leading technologies of the next pervasive era, USN 2007 wants to invite=20 researchers to present and discuss their ideas.=20 =20 Topics of this workshop include, but are not limited to:=20 =B7 RFID Systems and Architecture=20 =B7 RFID Middleware Design=20 =B7 Anti-collision algorithms=20 =B7 Mobile RFID Systems and Applications=20 =B7 Data Modeling and Management=20 =B7 Embedded RFID-enabled Device Technology=20 =B7 Sensor Network Architectures and Protocols=20 =B7 Network protocols, e.g., MAC and routing=20 =B7 Distributed Algorithms, e.g., Localization and Synchronization = =B7 Cross Layer and Energy Efficient Design=20 =B7 USN Middleware Issues, e.g., OS and Database=20 =B7 Coexistence of RFID & USN=20 =B7 QoS and Real-Time Issues=20 =B7 Security and privacy issues=20 =B7 Network Management in Large-scale Deployment=20 =B7 Coexistence of RFID & USN=20 =B7 Novel RFID and USN Applications=20 =20 Workshop Chairs -------------------- Young-Bae Ko, Ajou University, Korea=20 Kang-Won Lee, IBM T.J Watson Research, USA =20 Steering Committee=20 ---------------------- Jongsuk Chae, ETRI, Korea Seung-Wha Yoo, Ajou University, Korea Yu-Chee Tseng, National Chiao Tung Univ., Taiwan Daeyoung Kim, Information and Communications University, Korea =20 Program Committee ------------------------ Byunghun Song, KETI, Korea Chansu Yu, Cleveland State University, USA Chih-Yung Chang, Tamkang University, Taiwan Dong-Kyun Kim, Kyungpook National University, Korea Jae-Hyun Kim, Ajou University, Korea Javier Gomez, National University of Mexico, Mexico Kang-Won Lee, IBM T.J Watson Research, USA Kui Wu, University of Victoria, Canada Ling-Jyh Chen, Institute of Information Science, Taiwan Mineo Takai, UCLA, USA Ming-Jer Tsai, National Tsing-Hua Univ., Taiwan Mischa Dohler, France Telecom, France Mohamed Younis, University of Maryland, USA Ozgur Ercetin, Sabanci University, Turkey Saad Biaz, Auburn University, USA Taekyung Kwon, Seoul National University, Korea Tae-Jin Lee, Sungkyunkwan University, Korea Yuh-Shyan Chen, National Chung Cheng University, Taiwan Wei Lou, Hong Kong Polytechnic University, China Wen-Chih Peng, National Chiao Tung Univ., Taiwan Wonjun Lee, Korea University, Korea =20 Kang-Won Lee, Ph.D. Research Staff Member IBM Thomas J. Watson Research Center 19 Skyline Dr. Hawthorne, NY 10532 Tel: 914-784-7228, Fax: 914-784-6205 http://www.research.ibm.com/people/k/kangwon/ --=_alternative 0051302C852572DC_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
[Please accept our apologies if you receive multiple copies of this CFP]

------------------------------------= ----------------
CALL FOR PAPERS for USN 2007

The 3rd International Workshop on RF= ID and Ubiquitous Sensor Networks (USN)

http://uns.ajou.ac.kr/~usn2007/, Dec= ember 17-20, 2007, Taipei, Taiwan)

To be held in conjunction with EUC 2= 007
------------------------------------= ----------------


Important Dates:

* Submission Due: June 15, 2007 (ext= ended deadline)

* Acceptance notification: August 6, 2007

* Camera-ready due: September 4, 2007

 
About the workshop:

The purpose of USN 2007 is to establ= ish a discussion framework on all the challenges raised from the evolution of the Ubiquitous Sensor Networks and RFID technologies. As a unique opport= unity to obtain an insight on the leading technologies of the next pervasive era, USN 2007 wants to invite researchers to present and discuss their ideas.
 

Topics of this workshop include, but are not limited to:

=B7         RFID= Systems and Architecture

=B7         RFID= Middleware Design

=B7         Anti= -collision algorithms

=B7         Mobi= le RFID Systems and Applications

=B7         Data= Modeling and Management

=B7         Embe= dded RFID-enabled Device Technology

=B7         Sens= or Network Architectures and Protocols

=B7         Netw= ork protocols, e.g., MAC and routing

=B7         Dist= ributed Algorithms, e.g., Localization and Synchronization

=B7         Cross Layer and Energy Efficient Design

=B7         USN = Middleware Issues, e.g., OS and Database

=B7         Coex= istence of RFID & USN

=B7         QoS = and Real-Time Issues

=B7         Secu= rity and privacy issues

=B7         Netw= ork Management in Large-scale Deployment

=B7         Coex= istence of RFID & USN

=B7         Novel RFID and USN Applications
 

Workshop Chairs
--------------------

Young-Bae Ko, Ajou University, Korea

Kang-Won Lee, IBM T.J Watson Researc= h, USA

 

Steering Committee
----------------------

Jongsuk Chae, ETRI, Korea

Seung-Wha Yoo, Ajou University, Kore= a

Yu-Chee Tseng, National Chiao Tung U= niv., Taiwan

Daeyoung Kim, Information and Commun= ications University, Korea

 

Program Committee
------------------------

Byunghun Song, KETI, Korea

Chansu Yu, Cleveland State Universit= y, USA

Chih-Yung Chang, Tamkang University, Taiwan

Dong-Kyun Kim, Kyungpook National Un= iversity, Korea

Jae-Hyun Kim, Ajou University, Korea=

Javier Gomez, National University of Mexico, Mexico

Kang-Won Lee, IBM T.J Watson Researc= h, USA

Kui Wu, University of Victoria, Cana= da

Ling-Jyh Chen, Institute of Informat= ion Science, Taiwan

Mineo Takai, UCLA, USA

Ming-Jer Tsai, National Tsing-Hua Un= iv., Taiwan

Mischa Dohler, France Telecom, Franc= e

Mohamed Younis, University of Maryla= nd, USA

Ozgur Ercetin, Sabanci University, T= urkey

Saad Biaz, Auburn University, USA

Taekyung Kwon, Seoul National Univer= sity, Korea

Tae-Jin Lee, Sungkyunkwan University, Korea

Yuh-Shyan Chen, National Chung Cheng University, Taiwan

Wei Lou, Hong Kong Polytechnic Unive= rsity, China

Wen-Chih Peng, National Chiao Tung U= niv., Taiwan

Wonjun Lee, Korea University, Korea<= /font>
 




Kang-Won Lee, Ph.D.

Research Staff Member
IBM Thomas J. Watson Research Center
19 Skyline Dr. Hawthorne, NY 10532
Tel: 914-784-7228, Fax: 914-784-6205
http://www.research.ibm.com/people/k/kangwon/ --=_alternative 0051302C852572DC_=-- --===============0562359954== 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 --===============0562359954==-- From rsn-bounces@ietf.org Tue May 22 12:08: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 1HqWu3-0000Ko-CW; Tue, 22 May 2007 12:08:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqUQo-0001et-7n for RSN@ietf.org; Tue, 22 May 2007 09:29:42 -0400 Received: from smw151.hostingcare.net ([67.19.193.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqUQm-0005zv-L0 for RSN@ietf.org; Tue, 22 May 2007 09:29:42 -0400 Received: from smw151 ([127.0.0.1]) by smw151.hostingcare.net with MailEnable ESMTP; Tue, 22 May 2007 03:11:54 -0500 thread-index: AcecSNwZC4yjSlI6SFaIn0y5aNg11Q== Thread-Topic: Call for Paper :: Special issue on Intelligent information processing in wireless domain From: To: Date: Tue, 22 May 2007 03:11:54 -0500 Message-ID: <3D39B4F3B8314DCEB4E69F1CEECFFF91@hostingcare.net> MIME-Version: 1.0 X-Mailer: Microsoft CDO for Windows 2000 Content-Class: urn:content-classes:message Importance: high Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3959 X-Spam-Score: 1.2 (+) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc X-Mailman-Approved-At: Tue, 22 May 2007 12:08:02 -0400 Cc: Subject: [RSN] Call for Paper :: Special issue on Intelligent information processing in wireless domain 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="===============0550053188==" Errors-To: rsn-bounces@ietf.org This is a multi-part message in MIME format. --===============0550053188== Content-Type: multipart/alternative; boundary="----=_NextPart_000_7F3F_01C79C1E.F3458540" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_7F3F_01C79C1E.F3458540 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Ubiquitous Computing and Communication Journal Call for Paper Special issue on Intelligent information processing in wireless domain Home Home | About Us About Us | Contact Us Contact Us | Login Tuesday, May 22, 2007 Information Technology is the umbrella term that encompasses the entire area of information processing, storage as well as dissemination of information content using computer and communication technology every aspect of human life is being affected by information technology due to capability of digital communication and computation power. Information Communication technology is making it possible for more and more individual than ever to access the knowledge and to learn a new and different ways. The information technology is changing the way of conducting, managing as well as executing business transaction using advance sophisticated computer & network. Ever expanding capabilities of data network and availability of devices and system with high computational power is changing the modality of a communication between person to person as well as person to organization in digital global world. This has ushred in a new set of opportunity and services in different areas of wireless scenario. Keeping in view of advancement in information communication technology, it becomes essential to identify and study the impact of Ubiquitous Computing and Communication on different aspects of human life. Theme of the Special Issue. * Intelligent information processing in wireless domain. Papers are invited in the following areas:- * Artificial intelligent techniques in wireless communication * Multi-Radio and Multi channel Wireless mesh networking * Wireless LAN, PAN, WAN, MAN. * Modeling and Performance Evaluations. * Digital. Signal Processing in Communication * Speech Communication * Computational intelligent information retrieval * Intelligent network and mobile computing * 3G,4G mobile system, Wi Fi , Wi Max * Wireless Access Technologies * Protocol / Security * Wireless / Adhoc networks. IMPORTANT DATES: Manuscript Submission: June 20, 2007 First Notification: July 01,2007 Revised Final Submission: September 10, 2007 Publication Date: October 2007 Editor Special Issue. Dr. Jasvir Singh B.E, M-Tech, P.hD Professor Communication Signal Processing Research Lab Dept. of Electronics Technology Faculty of Engineering & Technology, Guru Nanak Dev University, Amritsar, Punjab, India, j_singh00@rediffmail.com jsingh@ubicc.org ------=_NextPart_000_7F3F_01C79C1E.F3458540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
Ubiquitous Computing and Communication Journal
Call for Paper
Special issue on Intelligent information processing in wireless domain

   Home Home | About Us About Us | Contact Us Contact Us | Login

Tuesday, May 22, 2007

Information Technology is the umbrella term that encompasses the entire area of information processing, storage as well as dissemination of information content using computer and communication technology every aspect of human life is being affected by information technology due to capability of digital communication and computation power. Information Communication technology is making it possible for more and more individual than ever to access the knowledge and to learn a new and different ways. The information technology is changing the way of conducting, managing as well as executing business transaction using advance sophisticated computer & network. Ever expanding capabilities of data network and availability of devices and system with high computational power is changing the modality of a communication between person to person as well as person to organization in digital global world. This has ushred in a new set of opportunity and services in different areas of wireless scenario. Keeping in view of advancement in information communication technology, it becomes essential to identify and study the impact of Ubiquitous Computing and Communication on different aspects of human life.

 

Theme of the Special Issue.

 

  • Intelligent information processing in wireless domain.

 Papers are invited in the following areas:-

  • Artificial intelligent techniques in wireless communication
  • Multi-Radio and Multi channel Wireless mesh networking
  • Wireless LAN, PAN, WAN, MAN.
  • Modeling and Performance Evaluations.
  • Digital. Signal Processing in Communication
  • Speech Communication
  • Computational intelligent information retrieval
  • Intelligent network and mobile computing
  • 3G,4G mobile system, Wi Fi , Wi Max
  • Wireless Access Technologies
  • Protocol / Security
  • Wireless / Adhoc networks.

IMPORTANT DATES:

 

Manuscript Submission:                  June 20, 2007

First Notification:                             July 01,2007

Revised Final Submission:               September 10, 2007

Publication Date:                             October 2007

  

Editor Special Issue.

Dr. Jasvir Singh

      B.E, M-Tech, P.hD

Professor

Communication Signal Processing Research Lab

Dept. of Electronics Technology

Faculty of Engineering & Technology,

Guru Nanak Dev University,

      Amritsar, Punjab, India,     j_singh00@rediffmail.com

                                                 jsingh@ubicc.org

 
------=_NextPart_000_7F3F_01C79C1E.F3458540-- --===============0550053188== 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 --===============0550053188==-- From rsn-bounces@ietf.org Tue May 22 18:24: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 1HqcmI-0007JY-8h; Tue, 22 May 2007 18:24:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqcmD-000792-Go; Tue, 22 May 2007 18:24:21 -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 1HqcmC-00065r-2Y; Tue, 22 May 2007 18:24:21 -0400 Received: by secure.archedrock.com (Postfix, from userid 101) id 4AF8B16B0004; Tue, 22 May 2007 15:24:19 -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=-100.6 required=5.0 tests=AWL,BAYES_00, MSGID_FROM_MTA_ID, SARE_LWSHORTT, USER_IN_WHITELIST 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 D15D916B0003; Tue, 22 May 2007 15:24:16 -0700 (PDT) From: "dculler" To: "'Ian Chakeres'" , Subject: RE: [RSN] 6lowpan devices constraints Date: Tue, 22 May 2007 15:24:03 -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: AceVD4Ag0WPYYvszQDulbmEcecWGwQHrQM2g In-Reply-To: <374005f30705122033n7989a1eap32346178cbdfef3b@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070522222416.D15D916B0003@secure.archedrock.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: '6lowpan' <6lowpan@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 For devices built upon microcontrollers, memory is quite limited. You can get a handy picture of this for one vendor from http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?familyId=911§i onId=95&tabId=1527&family=mcu. These devices range from 128B to 10KB of RAM and from 1 KB to 60 KB of flash. Similar ranges are available for microcontrollers from Atmel, Microchip, Freescale, and other vendors. From the table you can see that the marginal cost of additional storage ($/KB) is surprisingly high. This is only part of the story. When devices are operating at low duty cycle the energy budget is dominated by the sleep current. And, the sleep current is in large part leakage from SRAM. Thus, the bigger the memory, the shorter the lifetime on a fixed amount of energy. A number of microprocessors have down moved into the microcontroller market with 32-bit processors and MBs of RAM. Generally, what you see there is that the sleep current is quite high, unless you discard the contents of SRAM. Unfortunately, if you do that, you pay a large energy cost when you wake up again. The memory constraint is important for routing because it implies that there are limits on the size of the data structures, such as any neighbor tables, route tables, route caches. Take, for example, a simple problem like link estimation. A certain amount of storage is required per neighbor to record any statistics on the link, such as error rate. Let's say we have 1,000 nodes that can hear each other. The vast majority may have weak links and only hear each other's packets infrequently. What fraction of the few KBs of memory are we willing to devote to link estimation? It is attractive to only keep statistics on the good links. However, when a packet arrives from a node not in the table, how do we know if the link is good or bad? We have no stats, and we won't have any unless we invest an entry in the table. More generally, the storage limitations can impact the routing algorithm itself. Many algorithms start from a concept such as "all 1-hop neighbors" or "all 2-hop neighbors" and then proceed to select a routing subgraph from this distributed topology representation. In general, it may not be possible to record "all the neighbors" in the space available in a node. This is an issue that has been often overlooked in many of the mesh routing proposals, but it is, of course, a basic scalability concept that goes back to the earliest days of IP routing. The routing information per node must scale slowly with the number of nodes in the network. Thus, we pay great attention to route summarization and routing in the presence of partial information. In many cases, this is addressed by hierarchical techniques. In the wireless case, there is the additional complication that the degree of the connectivity graph is determined by the proximity of the nodes (relative to the communication range of the radios) rather than the physical connection of wired links. -----Original Message----- From: Ian Chakeres [mailto:ian.chakeres@gmail.com] Sent: Saturday, May 12, 2007 8:33 PM To: rsn@ietf.org Cc: 6lowpan Subject: [RSN] 6lowpan devices constraints adding RSN to the conversation It appears that my question might have been misinterpreted or more likely I presented the two choices inappropriately. Let me try pose the question in another way. How much short term memory can we expect these devices to have? And how much can we use for routing functions? Can a routing function make use of 100's or 1000's of bytes of short term memory? My understanding was that memory is scarce and very hard limited. Alternatively, energy though scarce does not have as hard a limit. Ian Chakeres _______________________________________________ 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 May 22 19:25: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 1HqdjA-0008RB-Kd; Tue, 22 May 2007 19:25:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqdj8-0008R3-2x for rsn@ietf.org; Tue, 22 May 2007 19:25:14 -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 1Hqdj7-0005d6-HW for rsn@ietf.org; Tue, 22 May 2007 19:25:14 -0400 Received: by secure.archedrock.com (Postfix, from userid 101) id C504416B0003; Tue, 22 May 2007 16:25:12 -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=-100.9 required=5.0 tests=AWL,BAYES_00,HTML_30_40, HTML_MESSAGE, MSGID_FROM_MTA_ID, USER_IN_WHITELIST 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 DD58016B0002 for ; Tue, 22 May 2007 16:25:11 -0700 (PDT) From: "dculler" To: Date: Tue, 22 May 2007 16:24:58 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcecyGlEAzVtnJGMQOWtEnBHuq9uQg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070522232511.DD58016B0002@secure.archedrock.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Subject: [RSN] Interest in the Interplay of "routing" and "meshing" 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="===============1733486082==" Errors-To: rsn-bounces@ietf.org This is a multi-part message in MIME format. --===============1733486082== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0107_01C79C8D.BDC89730" This is a multi-part message in MIME format. ------=_NextPart_000_0107_01C79C8D.BDC89730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Several of the comments on this list have touched on the issue of different kinds of "multihop routing" in the context of sensor networks. Is there interest in working on how these forms of routing tie together? To make the question more grounded: Low power radios have relatively short range. IEEE 802.15.4 radios are typically 1 mW transmit power, vs 100 mW for 802.11, and have typical ranges in 10s to 100 m. Generally speaking, the power required to communicate a given distance by radio grows polynomially with distance. In typical settings it grows like the cube, but it can be much worse near the ground or somewhat better with directional antennas. The cost to communicate hop-by-hop grows only linearly, and it offers the potential to route around obstacles and enhance reliability through "receiver diversity". The question is at what layer(s) in the stack this routing occurs and how it relates to IP routing more generally. Most multihop protocols in the sensor network research community are effectively at layer2 - they form a single "patch" of homogeneous media. Logically, they are a subnet, although few of the protocols address what happens beyond the "patch" of sensor nodes, other than that some of the nodes are "gateways". Current industry standards, such as Zigbee, Zwave, and wirelessHART, are also a "multihop link", leaving open the question of how nodes within the sensor patch communicate with nodes outside. 6LoWPAN provides a compressed header format for "mesh routing", meaning multihop forwarding of packets within the 802.15.4 link. Such a link is assumed to be formed by a contiguously connected set of 802.15.4 nodes. The presence of such "mesh routing" capabilities does not eliminate the need for layer 3 routing. If a 15.4 node communicates with a remote node, say an 802.11 node, how is routing and forwarding carried out? If two "LoWPAN subnets" [sic] happen to be connected by 15.4 nodes, how does 15.4-to-15.4 routing occur? The 6LoWPAN header format is, of course, a general solution for carrying IP over 802.15.4, so it is able to express these other forms of routing, as well. In the extreme case, each individual node is an IP link and all routing is done at the IP layer. On the other hand, patches of nodes may want to function as a logical subnet, even if the wireless multihop routing is done at the IP layer. At this point, the concerns overlap with those addressed in autoconf (cf., draft-ietf-autoconf-manetarch-01). There is substantial commonality of concerns at the different layers of multihop routing, but also differences. It is also important to separate the process of forming a routing topology from the process of forwarding packets. Both of which are distinct (but not entirely independent of) how power management (turning on/off the radios) is performed. ------=_NextPart_000_0107_01C79C8D.BDC89730 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Several of the=20 comments on this list have touched on the issue of different kinds = of=20 "multihop routing" in the context of sensor networks.  Is there = interest in=20 working on how these forms of routing tie=20 together?
 
To = make the question=20 more grounded:  Low power radios have relatively short range.  = IEEE=20 802.15.4 radios are typically 1 mW transmit power, vs 100 mW for 802.11, = and=20 have typical ranges in 10s to 100 m.  Generally speaking, the power = required to communicate a given distance by radio grows polynomially = with=20 distance.  In typical settings it grows like the cube, but it can = be much=20 worse near the ground or somewhat better with directional=20 antennas.  The cost to communicate hop-by-hop grows only=20 linearly, and it offers the potential to route around obstacles and = enhance=20 reliability through "receiver diversity". 
 
The = question is at=20 what layer(s) in the stack this routing occurs and how it relates to IP = routing=20 more generally.  Most multihop protocols in the sensor network = research=20 community are effectively at layer2 - they form a single "patch" of = homogeneous=20 media.  Logically, they are a subnet, although few of the protocols = address=20 what happens beyond the "patch" of sensor nodes, other than that some of = the=20 nodes are "gateways".  Current industry standards, such=20 as Zigbee, Zwave, and wirelessHART, are also a "multihop link", = leaving=20 open the question of how nodes within the sensor patch communicate with = nodes=20 outside.
 
6LoWPAN provides a=20 compressed header format for "mesh routing", meaning multihop forwarding = of=20 packets within the 802.15.4 link.  Such a link is assumed to be = formed by a=20 contiguously connected set of 802.15.4 nodes.  The presence of such = "mesh=20 routing" capabilities does not eliminate the need for layer 3 = routing.  If=20 a 15.4 node communicates with a remote node, say an 802.11 node, how is = routing=20 and forwarding carried out?  If two "LoWPAN subnets" [sic] happen = to be=20 connected by 15.4 nodes, how does 15.4-to-15.4 routing occur?  The = 6LoWPAN=20 header format is, of course, a general solution for carrying IP over = 802.15.4,=20 so it is able to express these other forms of routing, as well.  In = the=20 extreme case, each individual node is an IP link and all routing is done = at the=20 IP layer.  On the other hand, patches of nodes may want to function = as a=20 logical subnet, even if the wireless multihop routing is done at the IP=20 layer.  At this point, the concerns overlap with those addressed in = autoconf (cf., draft-ietf-autoconf-manetarch-01).
 
There = is substantial=20 commonality of concerns at the different layers of multihop routing, but = also=20 differences.  It is also important to separate the process of = forming a=20 routing topology from the process of forwarding packets.  Both of = which are=20 distinct (but not entirely independent of) how power management (turning = on/off=20 the radios) is performed.
 
 
------=_NextPart_000_0107_01C79C8D.BDC89730-- --===============1733486082== 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 --===============1733486082==-- From rsn-bounces@ietf.org Tue May 22 22:33: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 1Hqgfg-0004ZO-I4; Tue, 22 May 2007 22:33:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqgfe-0004ZI-Ng for rsn@ietf.org; Tue, 22 May 2007 22:33:50 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqgfb-0000mp-ER for rsn@ietf.org; Tue, 22 May 2007 22:33:50 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 23 May 2007 04:33:47 +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 l4N2XkHa002391; Wed, 23 May 2007 04:33:46 +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 l4N2XkDR017315; Wed, 23 May 2007 02:33:46 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 May 2007 04:33:46 +0200 Received: from [10.43.1.84] ([10.58.48.2]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 May 2007 04:33:44 +0200 Mime-Version: 1.0 (Apple Message framework v752.2) References: <20070522232511.DD58016B0002@secure.archedrock.com> Message-Id: From: JP Vasseur Date: Wed, 23 May 2007 04:33:31 +0200 To: rsn@ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 23 May 2007 02:33:44.0661 (UTC) FILETIME=[C8AC1050:01C79CE2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=18357; t=1179887626; x=1180751626; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Next=20step=20for=20RSN=20? |Sender:=20; bh=n5s4MlsU1PHfiBQYxiWtiMwclcYdcjx0eih+retgnWo=; b=jznb9CSbgDYZNB51I8Vqpv+nIqULgcWBu3Wq/FU46oKOozN5vwlnIwKUl7vSLcFp1Ejo0eta cakLVi9S2peBgfPOrZmxFL8lNMVdFtIL3j2rNULLJ+j0VQn3mbIW6Sp4; Authentication-Results: ams-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.3 (/) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a Cc: Subject: [RSN] Next step for RSN ? 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="===============0558733323==" Errors-To: rsn-bounces@ietf.org --===============0558733323== Content-Type: multipart/alternative; boundary=Apple-Mail-164--283050840 --Apple-Mail-164--283050840 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear List members, Looking at the number of people who registered to this list, there seems to be a strong interest in designing a Routing solution for Sensor Networks. David and I had during the last few months a number of off-line discussions with positive feed-back and support, it is now a good time to use the Mailing List to gauge whether there is a consensus on whether to work on this topic. David provided an excellent problem statement below. I'd like to add a few comments and get feed-back from the ML members on whether we collectively want to work on this item. With no doubt, we'll see many other radio networks emerging soon and sensor networks will soon be made links using various layer1/2 protocols defined by other SDOs: 802.15.4, Wifi, WiMax but also non wireless links. Such networks will also comprise sensor nodes with a wide range of capabilities, which makes the routing fairly unique in term of requirement. Thus 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). It looks fairly obvious that a network made of N "mesh-under" routing protocols is very unlikely to satisfy an end to end path constraint and would be fairly complex to manage and tune. We all remember the issue of IP routing over ATM PVCs routed by PNNI. Think of this with N "Mesh-under" routing protocols. That said, this is not to say that we exclude the use of "mesh-under" solutions, but we propose to define a IP-based routing protocol. What would be a charter proposal ? First we would need to spend a good amount of time on the routing requirements. David and I posted a first revision of a generic requirement draft (draft-culler-rsn-routing-reqs-00.txt); the next revision will soon be posted accounting for the comments received so far. I would propose to continue to list the generic requirements in this draft and have other application-specific routing requirements drafts discussed in other IDs: for home networking, industrial applications, ... Such approach has been successfully adopted in other WGs. The second step would consist of making a survey on the existing routing protocols and see whether (1) they could be used as such (2) they should be adapted (for instance, see whether AODV or OLR or RIP could be made energy efficient, could support some form of constrained based routing, ...) or (3) we should design a new generic new protocol. Note that we may not be able to satisfy all the requirements, and this might be perfectly acceptable and should be documented. Indeed, we all know that Sensor Networks may significantly differ in term of degree of mobility, link layer reliability/bandwidth, node constraints, ... A very good outcome of this work might be that the newly defined/adapted protocol could satisfy the requirement IDs A, B, D and E but not C. So please use this list to provide feed-back on whether you would support such initiative and if so your contribution is more than welcome. Note that several people already mentioned some interest and we do expect to see new IDs posted before Chicago. JP and David. Begin forwarded message: > From: "dculler" > Date: May 23, 2007 1:24:58 AM GMT+02:00 > To: > Subject: [RSN] Interest in the Interplay of "routing" and "meshing" > Reply-To: dculler@archrock.com > > Several of the comments on this list have touched on the issue of > different kinds of "multihop routing" in the context of sensor > networks. Is there interest in working on how these forms of > routing tie together? > > To make the question more grounded: Low power radios have > relatively short range. IEEE 802.15.4 radios are typically 1 mW > transmit power, vs 100 mW for 802.11, and have typical ranges in > 10s to 100 m. Generally speaking, the power required to > communicate a given distance by radio grows polynomially with > distance. In typical settings it grows like the cube, but it can > be much worse near the ground or somewhat better with directional > antennas. The cost to communicate hop-by-hop grows only linearly, > and it offers the potential to route around obstacles and enhance > reliability through "receiver diversity". > > The question is at what layer(s) in the stack this routing occurs > and how it relates to IP routing more generally. Most multihop > protocols in the sensor network research community are effectively > at layer2 - they form a single "patch" of homogeneous media. > Logically, they are a subnet, although few of the protocols address > what happens beyond the "patch" of sensor nodes, other than that > some of the nodes are "gateways". Current industry standards, such > as Zigbee, Zwave, and wirelessHART, are also a "multihop link", > leaving open the question of how nodes within the sensor patch > communicate with nodes outside. > > 6LoWPAN provides a compressed header format for "mesh routing", > meaning multihop forwarding of packets within the 802.15.4 link. > Such a link is assumed to be formed by a contiguously connected set > of 802.15.4 nodes. The presence of such "mesh routing" > capabilities does not eliminate the need for layer 3 routing. If a > 15.4 node communicates with a remote node, say an 802.11 node, how > is routing and forwarding carried out? If two "LoWPAN > subnets" [sic] happen to be connected by 15.4 nodes, how does 15.4- > to-15.4 routing occur? The 6LoWPAN header format is, of course, a > general solution for carrying IP over 802.15.4, so it is able to > express these other forms of routing, as well. In the extreme > case, each individual node is an IP link and all routing is done at > the IP layer. On the other hand, patches of nodes may want to > function as a logical subnet, even if the wireless multihop routing > is done at the IP layer. At this point, the concerns overlap with > those addressed in autoconf (cf., draft-ietf-autoconf-manetarch-01). > > There is substantial commonality of concerns at the different > layers of multihop routing, but also differences. It is also > important to separate the process of forming a routing topology > from the process of forwarding packets. Both of which are distinct > (but not entirely independent of) how power management (turning on/ > off the radios) is performed. > > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn --Apple-Mail-164--283050840 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Dear List members,

Looking at the number of = people who registered to this list, there seems to be a strong interest = in designing a Routing solution for Sensor Networks. David and I had = during the last few months a number of off-line discussions with = positive feed-back and support, it is now a good time to use the Mailing = List to gauge whether there is a consensus on whether to work on this = topic.

David = provided an excellent problem statement below. I'd like to add a few = comments and get feed-back from the ML members on whether we = collectively want to work on this item.

With no doubt, we'll see many other radio = networks emerging soon and sensor networks will soon be made links using = various layer1/2 protocols defined by other SDOs: 802.15.4, Wifi, WiMax = but also non wireless links. Such networks will also comprise = sensor nodes with a wide range of capabilities, which makes the = routing fairly unique in term of requirement. Thus 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).=A0

It looks fairly obvious that a network made = of N "mesh-under" routing protocols is very unlikely to satisfy an end = to end path constraint and would be fairly complex to manage and tune. = We all remember the issue of IP routing over ATM PVCs routed by PNNI. = Think of this with N "Mesh-under" routing protocols. That said, this is = not to say that we exclude the use of "mesh-under" solutions, but we = propose to define a IP-based routing protocol.=A0

What would be a = charter proposal ?

First we would need to = spend a good amount of time on the routing requirements. David and I = posted a first revision of a generic requirement draft = (draft-culler-rsn-routing-reqs-00.txt); the next revision will soon be = posted accounting for the comments received so far. I would propose to = continue to list the generic requirements in this draft and have other = application-specific routing requirements drafts discussed in other IDs: = for home networking, industrial applications, ... Such approach has been = successfully adopted in other WGs.

The second step would = consist of making a survey on the existing routing protocols and see = whether (1) they could be used as such (2) they should be adapted (for = instance, see whether AODV or OLR or RIP could be made energy efficient, = could support some form of constrained based routing, ...) or (3) we = should design a new generic new protocol.=A0

Note that we may not be = able to satisfy all the requirements, and this might be perfectly = acceptable and should be documented. Indeed, we all know that Sensor = Networks may significantly differ in term of degree of mobility, link = layer reliability/bandwidth, node constraints, ... A very good outcome = of this work might be that the newly defined/adapted protocol could = satisfy the requirement IDs A, B, D and E but not C.=A0

So please use this list to = provide feed-back on whether you would support such initiative and if so = your contribution is more than welcome. Note that several people already = mentioned some interest and we do expect to see new IDs posted before = Chicago.

JP and = David.

Begin forwarded message:

From: = "dculler" <dculler@archrock.com>
Date: May 23, 2007 1:24:58 AM = GMT+02:00
Subject: = [RSN] Interest in the Interplay of "routing" and = "meshing"
=

Several of = the comments on this list have touched on the=A0issue of different kinds = of "multihop routing" in the context of sensor networks.=A0 Is there = interest in working on how these=A0forms of routing=A0tie = together?
=A0
To make the = question more grounded:=A0 Low power radios have relatively short = range.=A0 IEEE 802.15.4 radios are typically 1 mW transmit power, vs 100 = mW for 802.11, and have typical ranges in 10s to 100 m.=A0 Generally = speaking, the power required to communicate a given distance by radio = grows polynomially with distance.=A0 In typical settings it grows like = the cube, but it can be much worse near the ground or somewhat better = with directional antennas.=A0=A0The cost to communicate=A0hop-by-hop = grows only linearly, and it offers the potential to route around = obstacles and enhance reliability through "receiver diversity".=A0 =
=A0
The = question is at what layer(s) in the stack this routing occurs and how it = relates to IP routing more generally.=A0 Most multihop protocols in the = sensor network research community are effectively at layer2 - they form = a single "patch" of homogeneous media.=A0 Logically, they are a subnet, = although few of the protocols address what happens beyond the "patch" of = sensor nodes, other than that some of the nodes are "gateways".=A0 = Current industry standards,=A0such as=A0Zigbee, Zwave, and wirelessHART, = are also a "multihop link", leaving open the question of how nodes = within the sensor patch communicate with nodes = outside.
=A0
6LoWPAN = provides a compressed header format for "mesh routing", meaning multihop = forwarding of packets within the 802.15.4 link.=A0 Such a link is = assumed to be formed by a contiguously connected set of 802.15.4 nodes.=A0= The presence of such "mesh routing" capabilities does not eliminate the = need for layer 3 routing.=A0 If a 15.4 node communicates with a remote = node, say an 802.11 node, how is routing and forwarding carried out?=A0 = If two "LoWPAN subnets" [sic] happen to be connected by 15.4 nodes, how = does 15.4-to-15.4 routing occur?=A0 The 6LoWPAN header format is, of = course, a general solution for carrying IP over 802.15.4, so it is able = to express these other forms of routing, as well.=A0 In the extreme = case, each individual node is an IP link and all routing is done at the = IP layer.=A0 On the other hand, patches of nodes may want to function as = a logical subnet, even if the wireless multihop routing is done at the = IP layer.=A0 At this point, the concerns overlap with those addressed in = autoconf (cf., draft-ietf-autoconf-manetarch-01).
=
=A0
There is = substantial commonality of concerns at the different layers of multihop = routing, but also differences.=A0 It is also important to separate the = process of forming a routing topology from the process of forwarding = packets.=A0 Both of which are distinct (but not entirely independent of) = how power management (turning on/off the radios) is = performed.
=A0
=A0
RSN mailing list
=

= --Apple-Mail-164--283050840-- --===============0558733323== 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 --===============0558733323==-- From rsn-bounces@ietf.org Wed May 23 05:35:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqnFf-0000bE-Uy; Wed, 23 May 2007 05:35:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqnFe-0000b9-K0 for rsn@ietf.org; Wed, 23 May 2007 05:35:26 -0400 Received: from mail.zen-sys.com ([195.215.56.170] helo=zensys17.zensys.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqnFd-0007yO-8U for rsn@ietf.org; Wed, 23 May 2007 05:35:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [RSN] Next step for RSN ? Date: Wed, 23 May 2007 11:35:24 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E77B26D@zensys17.zensys.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] Next step for RSN ? thread-index: Acec4tBt0bZsgGqSSh6q5/SWSsIkmwAOfzyg References: <20070522232511.DD58016B0002@secure.archedrock.com> From: "Anders Brandt" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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="===============1329250284==" Errors-To: rsn-bounces@ietf.org This is a multi-part message in MIME format. --===============1329250284== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C79D1D.B075F4E5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C79D1D.B075F4E5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > ... it is now a good time to use the Mailing List to gauge whether there is a consensus on whether to work on this topic.=20 =20 Speaking on behalf of Zensys, we are ready to go on with this topic. =20 I expect to provide input to the Home Automation requirements ID within a few weeks. Anyone else focusing on this domain are invited to join. =20 Best regards, =20 ------------- Anders Brandt Senior Software Architect =20 Zensys =20 phone: +45 70209940 fax: +4570209950 mail: abr@zen-sys.com =20 web: www.zen-sys.com =20 ------_=_NextPart_001_01C79D1D.B075F4E5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
>=20 ... it is now a good time to use the Mailing List to = gauge=20 whether there is a consensus on whether to work on this topic. 
 
Speaking on behalf of Zensys, we are ready to go on with = this=20 topic.
 
I=20 expect to provide input to the Home Automation requirements ID = within a few=20 weeks.
Anyone=20 else focusing on this domain are invited to join.
 
Best=20 regards,
 
-------------
Anders Brandt
Senior Software = Architect
 
Zensys
 
phone: +45 = 70209940
fax: =20  +4570209950
mail: abr@zen-sys.com
web: www.zen-sys.com
<= /DIV> ------_=_NextPart_001_01C79D1D.B075F4E5-- --===============1329250284== 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 --===============1329250284==-- From rsn-bounces@ietf.org Thu May 24 09:45:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrDdd-0004U6-DR; Thu, 24 May 2007 09:45:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrDdc-0004U1-Tt for rsn@ietf.org; Thu, 24 May 2007 09:45:56 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrDdb-0006WC-Ic for rsn@ietf.org; Thu, 24 May 2007 09:45:56 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 24 May 2007 15:45:54 +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 l4ODjq6E007166 for ; Thu, 24 May 2007 15:45:52 +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 l4ODjmDR000425 for ; Thu, 24 May 2007 13:45:52 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); Thu, 24 May 2007 15:45:48 +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] Next step for RSN ? Date: Thu, 24 May 2007 15:45:44 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC03FCDD2E@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] Next step for RSN ? Thread-Index: Acec4vNOGes5unlmROyOeMBUt0TsrwBIG0/g References: <20070522232511.DD58016B0002@secure.archedrock.com> From: "Pascal Thubert \(pthubert\)" To: "Jean Philippe Vasseur \(jvasseur\)" , X-OriginalArrivalTime: 24 May 2007 13:45:48.0530 (UTC) FILETIME=[D5FBED20:01C79E09] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2079; t=1180014352; x=1180878352; 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]=20Next=20step=20for=20RSN=20? |Sender:=20; bh=bp7fsaUH1xiNYN7Xwsk3xdLRjLT6kY2iksR876F/j3Q=; b=AFyA1gHuYDG58ksEoXJ4vKSQOOZV2zIvJgE9mLTt2UxsOtdsYlnjV5Sh/H+nJMHqNVUbV0Mg pObT3bGBlTei+kRAiQCt/ubiG43YzhhwtDxMTB07V50zOoiDtl072bOp; 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: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 JP: Please see inline: It looks fairly obvious that a network made of N "mesh-under" routing = protocols is very unlikely to satisfy an end to end path constraint and = would be fairly complex to manage and tune. We all remember the issue of = IP routing over ATM PVCs routed by PNNI. Think of this with N = "Mesh-under" routing protocols. That said, this is not to say that we = exclude the use of "mesh-under" solutions, but we propose to define a = IP-based routing protocol.=A0 Pascal =3D> I agree there's a lot of value to federate over IP the = various approaches that are defined for mesh-under.=20 The second step would consist of making a survey on the existing routing = protocols and see whether (1) they could be used as such (2) they should = be adapted (for instance, see whether AODV or OLR or RIP could be made = energy efficient, could support some form of constrained based routing, = ...) or (3) we should design a new generic new protocol.=A0 Pascal =3D> One aspect of this could be to consider the features that = mesh and sensor networks have deployed and why, and then see if there is = a need to generalize the approach at layer 3. For instance, offline = routing is popular in WSNs while not the prominent model in IP or MANET. Pascal =3D> Another specificity could be to work on a tighter = integration with the radio and a more specific abstraction for L3. I = know we have that barrier at IETF against L2 related activities. Yet, if = the radio model provides such things as beacons, then it could be = beneficial to define a routing protocol that can take advantage of the = beacons. At the moment, IP is carried in data frames only. Pascal =3D> We'll also have to work out the relationship with MANEMO. My = understanding is that MANEMO is for bigger boxes (routers really) and = has strong mobility and global reachability constraints. That makes it = pretty different in the objectives. OTOH, there seems to be value to = keep sharing views and ideas between the groups, should they form. Pascal _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu May 24 09:55:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrDnL-0004D4-GC; Thu, 24 May 2007 09:55:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrDnK-0004Cz-C7 for rsn@ietf.org; Thu, 24 May 2007 09:55:58 -0400 Received: from wa-out-1112.google.com ([209.85.146.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrDnJ-0007lR-3U for rsn@ietf.org; Thu, 24 May 2007 09:55:58 -0400 Received: by wa-out-1112.google.com with SMTP id m16so179496waf for ; Thu, 24 May 2007 06:55:56 -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:references:x-google-sender-auth; b=iLAFGv6253+6BLOhxlVHfx6k77Ic9O7+n7Tfly35+LgpPPej8LJivmY+if4M33z90MJojtHS/a1WT18Rjm7L8f3YhQNdmOvsp8WxpaxFucz+vcih92XEi5LIDsT2SRI6jZKPZSJ/fMqie7eokQwKBr9VaE1QFp+1Nozj/fAtLQ0= 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:references:x-google-sender-auth; b=cnw5lWk188LrSblI2CdRBpXvl3yH4Ehv65C3iKW6m6P2P3X7aslDJHsAW18DH30s8+9iKLaJw765cPT1WNju39+cB/5Ai3k1dMDyATnXr6Bw+NkL4P3e4J6x/7vp4mHMJ/57bFY4brVPhxlnviu1kDfv3APMGn/QVMrZQhxQfLk= Received: by 10.114.192.1 with SMTP id p1mr903982waf.1180014953321; Thu, 24 May 2007 06:55:53 -0700 (PDT) Received: by 10.114.254.16 with HTTP; Thu, 24 May 2007 06:55:53 -0700 (PDT) Message-ID: <86c3ed7b0705240655t12b5a7dasb45aad07cb36b0f4@mail.gmail.com> Date: Thu, 24 May 2007 15:55:53 +0200 From: "Miguel Sanchez" To: rsn@ietf.org In-Reply-To: MIME-Version: 1.0 References: X-Google-Sender-Auth: 20299ff49df7def6 X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [RSN] Re: [manet] Fwd: Next step for RSN ? 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="===============1900528170==" Errors-To: rsn-bounces@ietf.org --===============1900528170== Content-Type: multipart/alternative; boundary="----=_Part_139599_31944387.1180014953281" ------=_Part_139599_31944387.1180014953281 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all: As Pascal just mentioned, I'm not certain IETF is the right forum for this discussion as I can see how including IP protocol into sensor networks make= s sense from the point of view of IETF. My question is whether or not we can say the same from the point of view of many sensor networks. Please not I formulate my point a question to stimulate the debate, by mean= s of what I hope we all may learn more about it. Best regards, Miguel S=E1nchez Polytechnic University of Valencia, Spain ------=_Part_139599_31944387.1180014953281 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all:

As Pascal just mentioned, I'm not certain IETF is the ri= ght forum for this discussion as I can see how including IP protocol into s= ensor networks makes sense from the point of view of IETF. My question is w= hether or not we can say the same from the point of view of many sensor net= works.=20

Please not I formulate my point a question to stimulate the debate,= by means of what I hope we all may learn more about it.

Best regard= s,

Miguel S=E1nchez
Polytechnic University of Valencia, Spain
------=_Part_139599_31944387.1180014953281-- --===============1900528170== 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 --===============1900528170==-- From rsn-bounces@ietf.org Thu May 24 10:34: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 1HrEOR-0002X6-Oo; Thu, 24 May 2007 10:34:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrEOQ-0002X1-Gi for rsn@ietf.org; Thu, 24 May 2007 10:34:18 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HrEOP-0005x8-SA for rsn@ietf.org; Thu, 24 May 2007 10:34:18 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-153.messagelabs.com!1180017256!706201!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 3832 invoked from network); 24 May 2007 14:34:17 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-153.messagelabs.com with SMTP; 24 May 2007 14:34:17 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4OEYGbl010651; Thu, 24 May 2007 07:34:16 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l4OEYGff009833; Thu, 24 May 2007 09:34:16 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l4OEYEQG009770; Thu, 24 May 2007 09:34:15 -0500 (CDT) Message-ID: <4655A261.2010304@gmail.com> Date: Thu, 24 May 2007 16:34:09 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: JP Vasseur Subject: Re: [RSN] Next step for RSN ? References: <20070522232511.DD58016B0002@secure.archedrock.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000742-1, 22/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 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, I've received this on the MANEMO list but I'm replying here. I have some comments, more like against forming the RSN work, but I'm ok with all other opinions too :-) One is that I generally don't really see why routing for sensor networks is different than other networks. Or maybe that it is generally too early for that. One can interpret that routing for serverfarms is same as routing for laptops (same std routing protocols) - and serverfarms and laptops have very different energy requirements. Or, sensors are to laptops what laptops are to serverfarms... JP Vasseur wrote: > Dear List members, > > Looking at the number of people who registered to this list, there > seems to be a strong interest in designing a Routing solution for > Sensor Networks. David and I had during the last few months a number > of off-line discussions with positive feed-back and support, it is > now a good time to use the Mailing List to gauge whether there is a > consensus on whether to work on this topic. > > David provided an excellent problem statement below. I'd like to add > a few comments and get feed-back from the ML members on whether we > collectively want to work on this item. > > With no doubt, we'll see many other radio networks emerging soon and > sensor networks will soon be made links using various layer1/2 > protocols defined by other SDOs: 802.15.4, 802.15.4 no doubt offers its own link-layer routing... IP routing not necessary here. > Wifi, WiFi has a very clear network topology (BAse Station and mobile) where routing is not necessary at all over the air (neither link-layer nor IP). Most deployments are done this way and I haven't seen any wifi deployment needing IP routing. > WiMax Same as wifi. No need for IP routing for WiMax over the air and down to mobile. BEsides, I doubt WiFi or WiMAx can be used by the smallest of the sensors... I really don't see a sensor having WMAN capability... it's really too far-fetched. Or do you mean to IP route and gate through the heterogeneity of these wireless link-layers? > but also *non wireless links*. Which ones? I think that the smallest wired network interfaces and connections are Ethernet and probably USB. > Such networks will also comprise sensor nodes with a wide range of > capabilities, *which makes the routing fairly unique in term of > requirement*. Thus 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). > > It looks fairly obvious that a network made of N "mesh-under" routing > protocols is very unlikely to satisfy an end to end path constraint > and would be fairly complex to manage and tune. We all remember the > issue of IP routing over ATM PVCs routed by PNNI. Think of this with > N "Mesh-under" routing protocols. That said, this is not to say that > we exclude the use of "mesh-under" solutions, but we propose to > define a IP-based routing protocol. > > /*What would be a charter proposal ?*/ > > First we would need to spend a good amount of time on the routing > requirements. David and I posted a first revision of a generic > requirement draft (draft-culler-rsn-routing-reqs-00.txt); the next > revision will soon be posted accounting for the comments received so > far. I would propose to continue to list the generic requirements in > this draft and have other application-specific routing requirements > drafts discussed in other IDs: for home networking, industrial > applications, ... Such approach has been successfully adopted in > other WGs. > > The second step would consist of making a survey on the existing > routing protocols and see whether (1) they could be used as such (2) > they should be adapted (for instance, see whether AODV or OLR or RIP > could be made energy efficient, could support some form of > constrained based routing, ...) or (3) we should design a new generic > new protocol. I agree with this point. MANEMO effort was recently (in March) directed to analyse what MANET protocol can satisfy the MANEMO needs. I think that if one goes to MANET and asks one will most certainly find out that MANET protocols (currently: DYMO, OLSRv2 and NDHP) can surely deal with RSN needs. I think that will be a tough barrier to overcome if one wants to build a new RSN protocol. > Note that we may not be able to satisfy all the requirements, and > this might be perfectly acceptable and should be documented. Indeed, > we all know that Sensor Networks may significantly differ in term of > degree of mobility, Mobility? I think sensor networks once deployed are not mobile at all. Neither do they move homogeneously as a group (with respect to Earth), nor do they move with respect to each-other. > link layer reliability/bandwidth, node constraints, ... A very good > outcome of this work might be that the newly defined/adapted protocol > could satisfy the requirement IDs A, B, D and E but not C. > > So please use this list to provide feed-back on whether you would > support such initiative and if so your contribution is more than > welcome. Note that several people already mentioned some interest and > we do expect to see new IDs posted before Chicago. What's the potential interaction between RSN and MANEMO? Will a vehicle full of sensors talk to another such vehicle by using RSN or MANEMO protocol? Or MANET protocol? Alex > > JP and David. > > Begin forwarded message: > >> *From: *"dculler" > > *Date: *May 23, 2007 1:24:58 AM >> GMT+02:00 *To: *> *Subject: >> **[RSN] Interest in the Interplay of "routing" and "meshing"* >> *Reply-To: *dculler@archrock.com >> >> Several of the comments on this list have touched on the issue of >> different kinds of "multihop routing" in the context of sensor >> networks. Is there interest in working on how these forms of >> routing tie together? >> >> To make the question more grounded: Low power radios have >> relatively short range. IEEE 802.15.4 radios are typically 1 mW >> transmit power, vs 100 mW for 802.11, and have typical ranges in >> 10s to 100 m. Generally speaking, the power required to communicate >> a given distance by radio grows polynomially with distance. In >> typical settings it grows like the cube, but it can be much worse >> near the ground or somewhat better with directional antennas. The >> cost to communicate hop-by-hop grows only linearly, and it offers >> the potential to route around obstacles and enhance reliability >> through "receiver diversity". >> >> The question is at what layer(s) in the stack this routing occurs >> and how it relates to IP routing more generally. Most multihop >> protocols in the sensor network research community are effectively >> at layer2 - they form a single "patch" of homogeneous media. >> Logically, they are a subnet, although few of the protocols address >> what happens beyond the "patch" of sensor nodes, other than that >> some of the nodes are "gateways". Current industry standards, such >> as Zigbee, Zwave, and wirelessHART, are also a "multihop link", >> leaving open the question of how nodes within the sensor patch >> communicate with nodes outside. >> >> 6LoWPAN provides a compressed header format for "mesh routing", >> meaning multihop forwarding of packets within the 802.15.4 link. >> Such a link is assumed to be formed by a contiguously connected set >> of 802.15.4 nodes. The presence of such "mesh routing" >> capabilities does not eliminate the need for layer 3 routing. If a >> 15.4 node communicates with a remote node, say an 802.11 node, how >> is routing and forwarding carried out? If two "LoWPAN subnets" >> [sic] happen to be connected by 15.4 nodes, how does 15.4-to-15.4 >> routing occur? The 6LoWPAN header format is, of course, a general >> solution for carrying IP over 802.15.4, so it is able to express >> these other forms of routing, as well. In the extreme case, each >> individual node is an IP link and all routing is done at the IP >> layer. On the other hand, patches of nodes may want to function as >> a logical subnet, even if the wireless multihop routing is done at >> the IP layer. At this point, the concerns overlap with those >> addressed in autoconf (cf., draft-ietf-autoconf-manetarch-01). >> >> There is substantial commonality of concerns at the different >> layers of multihop routing, but also differences. It is also >> important to separate the process of forming a routing topology >> from the process of forwarding packets. Both of which are distinct >> (but not entirely independent of) how power management (turning >> on/off the radios) is performed. >> >> >> _______________________________________________ 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 ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu May 24 19:17:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrMZ0-00016V-6C; Thu, 24 May 2007 19:17:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrMYz-00016Q-45 for rsn@ietf.org; Thu, 24 May 2007 19:17:45 -0400 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrMYx-0000f9-OT for rsn@ietf.org; Thu, 24 May 2007 19:17:45 -0400 Received: from dnab4232e1.stanford.edu ([171.66.50.225]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1HrMYr-0003EG-GF; Thu, 24 May 2007 16:17:40 -0700 In-Reply-To: <4655A261.2010304@gmail.com> References: <20070522232511.DD58016B0002@secure.archedrock.com> <4655A261.2010304@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <78045EBC-86F2-412F-870D-A5375031A789@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [RSN] Next step for RSN ? Date: Thu, 24 May 2007 16:17:36 -0700 To: Alexandru Petrescu 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: f69c4e6b4bf914f22ae37cd490358bf0 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 On May 24, 2007, at 7:34 AM, Alexandru Petrescu wrote: > Hi JP, I've received this on the MANEMO list but I'm replying here. > > I have some comments, more like against forming the RSN work, but > I'm ok with all other opinions too :-) > > One is that I generally don't really see why routing for sensor > networks > is different than other networks. Or maybe that it is generally too > early for that. Routing for sensornets is different than other networks because they operate under different constraints. The two major differences are: 1) Nodes are energy-limited. 2) One repercussion of 1) is that nodes are state-limited. You can take existing routing approaches, such as AODV, DYMO, GPSR, etc. and apply them to sensor networks. Users have done so. Practice has shown, however, that they don't work that well and generally aren't a very good fit. Instead, working versions of these protocols typically constrain the protocol. For example, the AODV implementation for sensor nodes[1] supports routing to a single destination. High densities, combined with slow radios (a product of energy concerns), make flooding discovery such as AODV's tricky to get right, especially without some kind of scoping. Fundamentally, links behave differently during a flood than during unicast flows due to the correlations in packet transmissions. David summarized many of the implications of 2) very well in a message to the 6lowpan list. In the context of routing, having each node store up to O(n) state is generally unfeasible. Capping the routing state to some value R obviously has problems if you need R+1 routes. Achieving scalable unicast communication within a state- limited wireless network is a very active area of research. Right now, the state of the art (S4, presented at NSDI in March, which uses compact routing) requires O(sqrt(n)) state. Achieving this, however, requires embedding a little bit more information in a routing packet besides the destination address. Phil [1] tinyos-1.x/contrib/hsn/tos/lob/AODV.nc from http:// sourceforge.net/cvs/?group_id=28656 _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Fri May 25 08:57:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrZMR-0006Sd-Hh; Fri, 25 May 2007 08:57:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrZMQ-0006SQ-CF for rsn@ietf.org; Fri, 25 May 2007 08:57:38 -0400 Received: from mail.zen-sys.com ([195.215.56.170] helo=zensys17.zensys.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrZMP-0008Hd-1W for rsn@ietf.org; Fri, 25 May 2007 08:57:38 -0400 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] Next step for RSN ? Date: Fri, 25 May 2007 14:57:35 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E77B297@zensys17.zensys.local> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC03FCDD2E@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] Next step for RSN ? thread-index: Acec4vNOGes5unlmROyOeMBUt0TsrwBIG0/gADIdwCA= References: <20070522232511.DD58016B0002@secure.archedrock.com> <7892795E1A87F04CADFCCF41FADD00FC03FCDD2E@xmb-ams-337.emea.cisco.com> From: "Anders Brandt" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 Pascal, > Pascal =3D> Another specificity could be to work on a tighter integration with the radio and a more specific abstraction for L3. > I know we have that barrier at IETF against L2 related activities. Yet, if the radio model provides such things as beacons, > then it could be beneficial to define a routing protocol that can take advantage of the beacons. At the moment, IP is carried > in data frames only. Since the basic goal of the RSN work is to achieve a Layer 2 technology agnostic routing mechanism, awareness of beacon capabilities seems to be a drastic move. I suppose the goal for us must be to describe a L2 service API, which gives a sufficiently precise abstraction of the link layer so that the routing layer can make sensible decisions. Whether beacons or some other arbitration strategy is used should not be relevant to the routing layer. What is important is which capabilites is provided by the lower layer, such as: * Guaranteed delivery to another node (Yes/No) * Worst-case time for delivery of a packet to another node (may depend on target node capabilities) * Power properties (AC / AC w. batt. Backup / Big battery / Button cell battery / Environmental -sun or wind) * Availability of another node (A sun-powered node may be available and reliable for long periods, but not always...) I see RSN as a strong initiative because it is targeting a sensor world with just a good integration of technologies as classic IP provides today: I do not have to worry whether my IP traffic is running over GPRS, ADSL, ATM, Ethernet, MPLS or WiFi. In exactly the same way, RSN should provide seamless operation between sensor solutions running over Z-Wave, 802.15.4 and other wireless low-power technologies. Br. Anders ------------- Anders Brandt Senior Software Architect =20 Zensys Emdrupvej 26 DK-2100 Copenhagen O DENMARK =20 phone: +45 70209940 fax: +4570209950 mail: abr@zen-sys.com web: www.zen-sys.com _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Fri May 25 09:41: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 1Hra2p-0000QH-Lq; Fri, 25 May 2007 09:41:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hra2o-0000QB-CY for rsn@ietf.org; Fri, 25 May 2007 09:41:26 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hra2m-0000DO-Um for rsn@ietf.org; Fri, 25 May 2007 09:41:26 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 25 May 2007 15:41:25 +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 l4PDfOgS017606; Fri, 25 May 2007 15:41:24 +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 l4PDfJDR011459; Fri, 25 May 2007 13:41:19 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, 25 May 2007 15:41:19 +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] Next step for RSN ? Date: Fri, 25 May 2007 15:41:12 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC03FCE257@xmb-ams-337.emea.cisco.com> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E77B297@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] Next step for RSN ? Thread-Index: Acec4vNOGes5unlmROyOeMBUt0TsrwBIG0/gADIdwCAAANFJIA== References: <20070522232511.DD58016B0002@secure.archedrock.com><7892795E1A87F04CADFCCF41FADD00FC03FCDD2E@xmb-ams-337.emea.cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E77B297@zensys17.zensys.local> From: "Pascal Thubert \(pthubert\)" To: "Anders Brandt" , X-OriginalArrivalTime: 25 May 2007 13:41:19.0786 (UTC) FILETIME=[603698A0:01C79ED2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3212; t=1180100484; x=1180964484; 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]=20Next=20step=20for=20RSN=20? |Sender:=20; bh=kWDRdgMOZI/lCXEKMBjqyT9XonapkWK10WvCMdRU58o=; b=jgGE3xTTg2OMm/q2eJp5nU7f9zGY6dpWYnYYLOlMRs/m1I4gpjGydn7vj2Zh2DMr/AcLmSjR plkY5OffG6y3lQjourIeiPo5ReZV0FQEfQeKi4N+qdPHHH+LcxdKAmfA; 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: 3002fc2e661cd7f114cb6bae92fe88f1 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 Anders: >> Pascal =3D> Another specificity could be to work on a tighter >integration with the radio and a more specific abstraction for L3. >> I know we have that barrier at IETF against L2 related activities. >Yet, if the radio model provides such things as beacons, >> then it could be beneficial to define a routing protocol that can take >advantage of the beacons. At the moment, IP is carried >> in data frames only. >Since the basic goal of the RSN work is to achieve a Layer 2 technology >agnostic routing mechanism, awareness of beacon capabilities seems to be >a drastic move. >I suppose the goal for us must be to describe a L2 service API, which >gives a sufficiently precise abstraction of the link layer so that the >routing layer can make sensible decisions. Pascal =3D> I would question that. I suspect that we need to define a sensor network abstraction and define a routing protocol for that abstraction. If the abstraction is really agnostic of the radio layer, then we might be missing a chance to get the optimizations that can be so critical in WSNs.=20 Pascal =3D> For instance, I believe that an abstract notion of beacon = can be useful to advertise L3 triggers that will help in peer selection, considering that the memory footprint will not enable to track all peers at all times. You can imagine that the L2 abstraction provides an optional timely broadcast on which L3 message can be passed, with a fallback solution of triggering a data frame broadcast if the beacon is not provided by one specific MAC. >Whether beacons or some other arbitration strategy is used should not be >relevant to the routing layer. What is important is which capabilites is >provided by the lower layer, such as: > >* Guaranteed delivery to another node (Yes/No) >* Worst-case time for delivery of a packet to another node (may depend >on target node capabilities) >* Power properties (AC / AC w. batt. Backup / Big battery / Button cell >battery / Environmental -sun or wind) >* Availability of another node (A sun-powered node may be available and >reliable for long periods, but not always...) > Pascal =3D> Agreed but it's a different level. These are metrics and constraints that will enter in path selection. I was discussing a potential optimization of the flow of the PDUs that would depend on how well we can exploit L2 mechanisms.=20 >I see RSN as a strong initiative because it is targeting a sensor world >with just a good integration of technologies as classic IP provides >today: >I do not have to worry whether my IP traffic is running over GPRS, ADSL, >ATM, Ethernet, MPLS or WiFi. > >In exactly the same way, RSN should provide seamless operation between >sensor solutions running over Z-Wave, 802.15.4 and other wireless >low-power technologies. > >Br. > Anders > >------------- >Anders Brandt >Senior Software Architect > >Zensys >Emdrupvej 26 >DK-2100 Copenhagen O >DENMARK > >phone: +45 70209940 >fax: +4570209950 >mail: abr@zen-sys.com >web: www.zen-sys.com > >_______________________________________________ >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 May 25 10:02:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HraNS-0003bt-Ve; Fri, 25 May 2007 10:02:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HraNQ-0003Pr-R8 for rsn@ietf.org; Fri, 25 May 2007 10:02:44 -0400 Received: from maily.danfoss.com ([193.162.34.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HraNP-00049W-I5 for rsn@ietf.org; Fri, 25 May 2007 10:02:44 -0400 Received: from DKDN04MX62.dkdn04.danfoss.net ([10.6.2.62]) by maily.danfoss.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 16:02:42 +0200 Received: from dkdn01mx21.danfoss.net ([10.12.129.21]) by DKDN04MX62.dkdn04.danfoss.net with InterScan Message Security Suite; Fri, 25 May 2007 16:02:42 +0200 Received: from dkdn01mx25.danfoss.net ([10.12.129.25]) by dkdn01mx21.danfoss.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 16:02:36 +0200 Received: from DKDN01MX55.danfoss.net ([10.12.29.55]) by dkdn01mx25.danfoss.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 16:02:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [RSN] Next step for RSN ? Date: Fri, 25 May 2007 16:02:35 +0200 Message-ID: <6BE3CE67D282B049905E9BC228CCF59A0AEF02@DKDN01MX55.danfoss.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] Next step for RSN ? Thread-Index: Acec4tERTTqbmmGYQOeGOmuBuTV3aAB74DxQ References: <20070522232511.DD58016B0002@secure.archedrock.com> From: "Nielsen Klaus Sonderskov" To: "JP Vasseur" , X-OriginalArrivalTime: 25 May 2007 14:02:36.0277 (UTC) FILETIME=[590FAA50:01C79ED5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 407b2b2f241d630837da70082e911e77 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="===============1321749231==" Errors-To: rsn-bounces@ietf.org This is a multi-part message in MIME format. --===============1321749231== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C79ED5.5901F591" This is a multi-part message in MIME format. ------_=_NextPart_001_01C79ED5.5901F591 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi JP, Just following this effort on the side... and hearing talks about RSN = being done in L2... would it by any chance be beneficial/possible to = talk about placing the routing on top of 6LowPan? From my point of view = placing routing on top of 6LowPan would add large amount of benefits to = the sensor community for building low power sensor networks on various = technologies. The benefit would come in taking the 6LowPan specification = and just change the adaptation layer to whatever PHY you have = underneath, and while not tie the RSN effort to the PHY there will be no = change to RSN if we were to use a different technology. Adding the = possibility to create interoperable applications running on 802.15.4, = FSK, 802.11 seamlessly on the same network (only having thin PHY = translators)... as David mentions below.=20 =20 Perhaps, there need to be a study of what are the costs in power/latency = etc. by have routing entirely on top of 6LowPan.=20 Best regards / Med venlig hilsen Klaus S=F8nderskov Nielsen Danfoss A/S, Communication Technology Centre ________________________________ From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: Wednesday, May 23, 2007 4:34 AM To: rsn@ietf.org Subject: [RSN] Next step for RSN ? =20 Dear List members, =20 Looking at the number of people who registered to this list, there seems = to be a strong interest in designing a Routing solution for Sensor = Networks. David and I had during the last few months a number of = off-line discussions with positive feed-back and support, it is now a = good time to use the Mailing List to gauge whether there is a consensus = on whether to work on this topic. =20 David provided an excellent problem statement below. I'd like to add a = few comments and get feed-back from the ML members on whether we = collectively want to work on this item. =20 With no doubt, we'll see many other radio networks emerging soon and = sensor networks will soon be made links using various layer1/2 protocols = defined by other SDOs: 802.15.4, Wifi, WiMax but also non wireless = links. Such networks will also comprise sensor nodes with a wide range = of capabilities, which makes the routing fairly unique in term of = requirement. Thus 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).=20 =20 It looks fairly obvious that a network made of N "mesh-under" routing = protocols is very unlikely to satisfy an end to end path constraint and = would be fairly complex to manage and tune. We all remember the issue of = IP routing over ATM PVCs routed by PNNI. Think of this with N = "Mesh-under" routing protocols. That said, this is not to say that we = exclude the use of "mesh-under" solutions, but we propose to define a = IP-based routing protocol.=20 =20 What would be a charter proposal ? =20 First we would need to spend a good amount of time on the routing = requirements. David and I posted a first revision of a generic = requirement draft (draft-culler-rsn-routing-reqs-00.txt); the next = revision will soon be posted accounting for the comments received so = far. I would propose to continue to list the generic requirements in = this draft and have other application-specific routing requirements = drafts discussed in other IDs: for home networking, industrial = applications, ... Such approach has been successfully adopted in other = WGs. =20 The second step would consist of making a survey on the existing routing = protocols and see whether (1) they could be used as such (2) they should = be adapted (for instance, see whether AODV or OLR or RIP could be made = energy efficient, could support some form of constrained based routing, = ...) or (3) we should design a new generic new protocol.=20 =20 Note that we may not be able to satisfy all the requirements, and this = might be perfectly acceptable and should be documented. Indeed, we all = know that Sensor Networks may significantly differ in term of degree of = mobility, link layer reliability/bandwidth, node constraints, ... A very = good outcome of this work might be that the newly defined/adapted = protocol could satisfy the requirement IDs A, B, D and E but not C.=20 =20 So please use this list to provide feed-back on whether you would = support such initiative and if so your contribution is more than = welcome. Note that several people already mentioned some interest and we = do expect to see new IDs posted before Chicago. =20 JP and David. =20 Begin forwarded message: From: "dculler" Date: May 23, 2007 1:24:58 AM GMT+02:00 To: Subject: [RSN] Interest in the Interplay of "routing" and "meshing" Reply-To: dculler@archrock.com =20 Several of the comments on this list have touched on the issue of = different kinds of "multihop routing" in the context of sensor networks. = Is there interest in working on how these forms of routing tie = together? =20 To make the question more grounded: Low power radios have relatively = short range. IEEE 802.15.4 radios are typically 1 mW transmit power, vs = 100 mW for 802.11, and have typical ranges in 10s to 100 m. Generally = speaking, the power required to communicate a given distance by radio = grows polynomially with distance. In typical settings it grows like the = cube, but it can be much worse near the ground or somewhat better with = directional antennas. The cost to communicate hop-by-hop grows only = linearly, and it offers the potential to route around obstacles and = enhance reliability through "receiver diversity". =20 =20 The question is at what layer(s) in the stack this routing occurs and = how it relates to IP routing more generally. Most multihop protocols in = the sensor network research community are effectively at layer2 - they = form a single "patch" of homogeneous media. Logically, they are a = subnet, although few of the protocols address what happens beyond the = "patch" of sensor nodes, other than that some of the nodes are = "gateways". Current industry standards, such as Zigbee, Zwave, and = wirelessHART, are also a "multihop link", leaving open the question of = how nodes within the sensor patch communicate with nodes outside. =20 6LoWPAN provides a compressed header format for "mesh routing", meaning = multihop forwarding of packets within the 802.15.4 link. Such a link is = assumed to be formed by a contiguously connected set of 802.15.4 nodes. = The presence of such "mesh routing" capabilities does not eliminate the = need for layer 3 routing. If a 15.4 node communicates with a remote = node, say an 802.11 node, how is routing and forwarding carried out? If = two "LoWPAN subnets" [sic] happen to be connected by 15.4 nodes, how = does 15.4-to-15.4 routing occur? The 6LoWPAN header format is, of = course, a general solution for carrying IP over 802.15.4, so it is able = to express these other forms of routing, as well. In the extreme case, = each individual node is an IP link and all routing is done at the IP = layer. On the other hand, patches of nodes may want to function as a = logical subnet, even if the wireless multihop routing is done at the IP = layer. At this point, the concerns overlap with those addressed in = autoconf (cf., draft-ietf-autoconf-manetarch-01). =20 There is substantial commonality of concerns at the different layers of = multihop routing, but also differences. It is also important to = separate the process of forming a routing topology from the process of = forwarding packets. Both of which are distinct (but not entirely = independent of) how power management (turning on/off the radios) is = performed. =20 =20 _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn =20 ------_=_NextPart_001_01C79ED5.5901F591 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = JP,

Just following this effort on the = side… and hearing talks about RSN being done in L2… would it by any = chance be beneficial/possible to talk about placing the routing on top of 6LowPan? = >From my point of view placing routing on top of 6LowPan would add large amount = of benefits to the sensor community for building low power sensor networks = on various technologies. The benefit would come in taking the 6LowPan = specification and just change the adaptation layer to whatever PHY you have = underneath, and while not tie the RSN effort to the PHY there will be no change to RSN = if we were to use a different technology. Adding the possibility to create interoperable applications running on 802.15.4, FSK, 802.11 seamlessly = on the same network (only having thin PHY translators)… as David mentions = below.

 

Perhaps, there need to be a study = of what are the costs in power/latency etc. by have routing entirely on top = of 6LowPan.

Best regards / Med venlig hilsen
Klaus S=F8nderskov = Nielsen
Danfoss A/S, Communication Technology = Centre

From: JP Vasseur [mailto:jvasseur@cisco.com]
Sent: Wednesday, May 23, = 2007 4:34 AM
To: rsn@ietf.org
Subject: [RSN] Next step = for RSN ?

 

Dear List = members,

 

Looking at the = number of people who registered to this list, there seems to be a strong interest = in designing a Routing solution for Sensor Networks. David and I had during = the last few months a number of off-line discussions with positive feed-back = and support, it is now a good time to use the Mailing List to gauge whether = there is a consensus on whether to work on this = topic.

 

David provided = an excellent problem statement below. I'd like to add a few comments and = get feed-back from the ML members on whether we collectively want to work on = this item.

 

With = no doubt, we'll see many other radio networks emerging soon and sensor networks = will soon be made links using various layer1/2 protocols defined by other SDOs: = 802.15.4, Wifi, WiMax but also non wireless = links. Such networks will also comprise sensor nodes with a wide range of capabilities, which makes the = routing fairly unique in term of requirement. Thus 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). 

 

It = looks fairly obvious that a network made of N "mesh-under" routing = protocols is very unlikely to satisfy an end to end path constraint and would be = fairly complex to manage and tune. We all remember the issue of IP routing over = ATM PVCs routed by PNNI. Think of this with N "Mesh-under" routing protocols. That said, this is not to say that we exclude the use of "mesh-under" solutions, but we propose to define a IP-based = routing protocol. 

 

What would be a charter proposal = ?

 

First we would = need to spend a good amount of time on the routing requirements. David and I = posted a first revision of a generic requirement draft (draft-culler-rsn-routing-reqs-00.txt); the next revision will soon be = posted accounting for the comments received so far. I would propose to continue = to list the generic requirements in this draft and have other = application-specific routing requirements drafts discussed in other IDs: for home networking, = industrial applications, ... Such approach has been successfully adopted in other = WGs.

 

The second = step would consist of making a survey on the existing routing protocols and see = whether (1) they could be used as such (2) they should be adapted (for instance, = see whether AODV or OLR or RIP could be made energy efficient, could support = some form of constrained based routing, ...) or (3) we should design a new = generic new protocol. 

 

Note that we = may not be able to satisfy all the requirements, and this might be perfectly = acceptable and should be documented. Indeed, we all know that Sensor Networks may significantly differ in term of degree of mobility, link layer reliability/bandwidth, node constraints, ... A very good outcome of this = work might be that the newly defined/adapted protocol could satisfy the = requirement IDs A, B, D and E but not C. 

 

So please use = this list to provide feed-back on whether you would support such initiative and if = so your contribution is more than welcome. Note that several people already mentioned some interest and we do expect to see new IDs posted before = Chicago.

 

JP and = David.

 

Begin = forwarded message:



From: "dculler" <dculler@archrock.com><= /font>

Date: May 23, 2007 1:24:58 AM = GMT+02:00

To: <rsn@ietf.org>

Subject: [RSN] Interest in the = Interplay of "routing" and = "meshing"

 

Several of the comments on = this list have touched on the issue of different kinds of "multihop routing" in the context of sensor networks.  Is there interest = in working on how these forms of routing tie = together?

 

To make the question more grounded:  Low power radios have relatively short range.  IEEE 802.15.4 radios are typically 1 mW transmit power, vs 100 mW for 802.11, = and have typical ranges in 10s to 100 m.  Generally speaking, the power required to communicate a given distance by radio grows polynomially = with distance.  In typical settings it grows like the cube, but it can = be much worse near the ground or somewhat better with directional antennas.  The cost to communicate hop-by-hop grows only linearly, and it offers the potential to route around obstacles and = enhance reliability through "receiver diversity".  =

 

The question is at what = layer(s) in the stack this routing occurs and how it relates to IP routing more generally.  Most multihop protocols in the sensor network research community are effectively at layer2 - they form a single = "patch" of homogeneous media.  Logically, they are a subnet, although few of the protocols address what happens beyond the "patch" of sensor nodes, other = than that some of the nodes are "gateways".  Current industry standards, such as Zigbee, Zwave, and wirelessHART, are also a "multihop link", leaving open the question of how nodes within = the sensor patch communicate with nodes = outside.

 

6LoWPAN provides a = compressed header format for "mesh routing", meaning multihop forwarding of = packets within the 802.15.4 link.  Such a link is assumed to be formed by a contiguously connected set of 802.15.4 nodes.  The presence of such "mesh routing" capabilities does not eliminate the need for = layer 3 routing.  If a 15.4 node communicates with a remote node, say an = 802.11 node, how is routing and forwarding carried out?  If two "LoWPAN subnets" [sic] happen to be connected by 15.4 nodes, how does = 15.4-to-15.4 routing occur?  The 6LoWPAN header format is, of course, a general solution for carrying IP over 802.15.4, so it is able to express these = other forms of routing, as well.  In the extreme case, each individual = node is an IP link and all routing is done at the IP layer.  On the other = hand, patches of nodes may want to function as a logical subnet, even if the = wireless multihop routing is done at the IP layer.  At this point, the = concerns overlap with those addressed in autoconf (cf., draft-ietf-autoconf-manetarch-01).

 

There is substantial = commonality of concerns at the different layers of multihop routing, but also differences.  It is also important to separate the process of = forming a routing topology from the process of forwarding packets.  Both of = which are distinct (but not entirely independent of) how power management = (turning on/off the radios) is performed.

 

 

______________________________________________= _

RSN mailing = list

 

------_=_NextPart_001_01C79ED5.5901F591-- --===============1321749231== 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 --===============1321749231==-- From rsn-bounces@ietf.org Fri May 25 10:05: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 1HraPo-0005Nx-QV; Fri, 25 May 2007 10:05:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HraPn-0005Ns-R6 for rsn@ietf.org; Fri, 25 May 2007 10:05:11 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HraPl-0004W6-Cf for rsn@ietf.org; Fri, 25 May 2007 10:05:11 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 25 May 2007 07:05:09 -0700 X-IronPort-AV: i="4.14,580,1170662400"; d="scan'208"; a="157523547:sNHT85067478" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l4PE58v2017365; Fri, 25 May 2007 07:05:08 -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 l4PE4q0E002271; Fri, 25 May 2007 14:05:07 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); Fri, 25 May 2007 10:05:04 -0400 Received: from [18.85.18.24] ([10.86.240.223]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 10:05:03 -0400 In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E77B297@zensys17.zensys.local> References: <20070522232511.DD58016B0002@secure.archedrock.com> <7892795E1A87F04CADFCCF41FADD00FC03FCDD2E@xmb-ams-337.emea.cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E77B297@zensys17.zensys.local> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [RSN] Next step for RSN ? Date: Fri, 25 May 2007 10:04:50 -0400 To: Anders Brandt X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 25 May 2007 14:05:03.0682 (UTC) FILETIME=[B0EBE220:01C79ED5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2748; t=1180101908; x=1180965908; 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:=20Re=3A=20[RSN]=20Next=20step=20for=20RSN=20? |Sender:=20; bh=FDEDjSm1ZWe1spm30iiKtgcxNtakGDluguQOrdvnfgI=; b=g4lYyBbqENib94RLUD1D/jR+UTlZaKeQrTx0+BUm8fXSVR5FvS1g+MqhT1iiw30KJkBTxiQu wqwUV9+zXlX1crVkIPi5t92RmC76sA74HoupMPm0RHMB0wLyhEHoXKhc; 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: 386e0819b1192672467565a524848168 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 anders, Thanks for your feed-back and support in this initiative considering your experience in Home Networking for Sensor. In line, On May 25, 2007, at 8:57 AM, Anders Brandt wrote: > Pascal, > >> Pascal => Another specificity could be to work on a tighter > integration with the radio and a more specific abstraction for L3. >> I know we have that barrier at IETF against L2 related activities. > Yet, if the radio model provides such things as beacons, >> then it could be beneficial to define a routing protocol that can >> take > advantage of the beacons. At the moment, IP is carried >> in data frames only. > > Since the basic goal of the RSN work is to achieve a Layer 2 > technology > agnostic routing mechanism, awareness of beacon capabilities seems > to be > a drastic move. > I suppose the goal for us must be to describe a L2 service API, which > gives a sufficiently precise abstraction of the link layer so that the > routing layer can make sensible decisions. > > Whether beacons or some other arbitration strategy is used should > not be > relevant to the routing layer. What is important is which > capabilites is > provided by the lower layer, such as: > > * Guaranteed delivery to another node (Yes/No) > * Worst-case time for delivery of a packet to another node (may depend > on target node capabilities) > * Power properties (AC / AC w. batt. Backup / Big battery / Button > cell > battery / Environmental -sun or wind) > * Availability of another node (A sun-powered node may be available > and > reliable for long periods, but not always...) > Indeed, such capabilities will be used by the routing layer for efficient constrained routing. Note that node capability is another example of unique requirements for Sensor Nets, not covered in most existing IP routing protocols. > I see RSN as a strong initiative because it is targeting a sensor > world > with just a good integration of technologies as classic IP provides > today: > I do not have to worry whether my IP traffic is running over GPRS, > ADSL, > ATM, Ethernet, MPLS or WiFi. Indeed. > > In exactly the same way, RSN should provide seamless operation between > sensor solutions running over Z-Wave, 802.15.4 and other wireless > low-power technologies. > Thanks. JP. > Br. > Anders > > ------------- > Anders Brandt > Senior Software Architect > > Zensys > Emdrupvej 26 > DK-2100 Copenhagen O > DENMARK > > phone: +45 70209940 > fax: +4570209950 > mail: abr@zen-sys.com > web: www.zen-sys.com > > _______________________________________________ > 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 May 25 10:05:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HraQG-0005Yr-5v; Fri, 25 May 2007 10:05:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HraQF-0005Ym-Pn for rsn@ietf.org; Fri, 25 May 2007 10:05:39 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HraQE-0004ri-2v for rsn@ietf.org; Fri, 25 May 2007 10:05:39 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 25 May 2007 10:05:38 -0400 X-IronPort-AV: i="4.14,580,1170651600"; d="scan'208,217"; a="122042544:sNHT344365612" 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 l4PE5bdT004029; Fri, 25 May 2007 10:05:37 -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 l4PE5F6D028452; Fri, 25 May 2007 14:05:32 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); Fri, 25 May 2007 10:05:32 -0400 Received: from [18.85.18.24] ([10.86.240.223]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 10:05:31 -0400 In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC03FCE257@xmb-ams-337.emea.cisco.com> References: <20070522232511.DD58016B0002@secure.archedrock.com><7892795E1A87F04CADFCCF41FADD00FC03FCDD2E@xmb-ams-337.emea.cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E77B297@zensys17.zensys.local> <7892795E1A87F04CADFCCF41FADD00FC03FCE257@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <55D78861-C538-4A6B-9B9D-9E30038A50AB@cisco.com> From: JP Vasseur Subject: Re: [RSN] Next step for RSN ? Date: Fri, 25 May 2007 10:05:20 -0400 To: Pascal Thubert ((pthubert)) X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 25 May 2007 14:05:31.0166 (UTC) FILETIME=[C14D9BE0:01C79ED5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=20158; t=1180101937; x=1180965937; 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]=20Next=20step=20for=20RSN=20? |Sender:=20 |To:=20Pascal=20Thubert=20((pthubert))=20; bh=emEiY3tezmEm53xYgQN1JgF5XsxeTSHKMGlWyabPjNI=; b=s7LNZsEaEprY7//mdGxfh/sLs5VbZhFXE/KOYLgZsCu/Ugjr8kS5evho68LN7MkFBTJIqiAE J++BQo4IlHAzPfpZ7viPZoRW8V8hTpsxQesNdmZEq1lXwfbCF+yAd1Nl; 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: 75ac735ede4d089f7192d230671d536e 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="===============0584730024==" Errors-To: rsn-bounces@ietf.org --===============0584730024== Content-Type: multipart/alternative; boundary=Apple-Mail-288--68742563 --Apple-Mail-288--68742563 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Pascal, On May 25, 2007, at 9:41 AM, Pascal Thubert ((pthubert)) wrote: > Hi Anders: > >>> Pascal => Another specificity could be to work on a tighter >> integration with the radio and a more specific abstraction for L3. >>> I know we have that barrier at IETF against L2 related activities. >> Yet, if the radio model provides such things as beacons, >>> then it could be beneficial to define a routing protocol that can > take >> advantage of the beacons. At the moment, IP is carried >>> in data frames only. > >> Since the basic goal of the RSN work is to achieve a Layer 2 >> technology >> agnostic routing mechanism, awareness of beacon capabilities seems to > be >> a drastic move. >> I suppose the goal for us must be to describe a L2 service API, which >> gives a sufficiently precise abstraction of the link layer so that >> the >> routing layer can make sensible decisions. > > Pascal => I would question that. I suspect that we need to define a > sensor network abstraction and define a routing protocol for that > abstraction. If the abstraction is really agnostic of the radio layer, > then we might be missing a chance to get the optimizations that can be > so critical in WSNs. > I think you both agree: we do want to be able to have an IP routing protocol not tied up with a specific layer 2 but it may be desirable to get layer2 information used for routing, this is why I wrote in my original email: " ... Thus 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). ..." > Pascal => For instance, I believe that an abstract notion of beacon > can > be useful to advertise L3 triggers that will help in peer selection, > considering that the memory footprint will not enable to track all > peers > at all times. You can imagine that the L2 abstraction provides an > optional timely broadcast on which L3 message can be passed, with a > fallback solution of triggering a data frame broadcast if the > beacon is > not provided by one specific MAC. > Agree, similarly to what is being done in today's network when SONET/ SDH/Optical parameters are used by the layer 3. But still, we want a routing solution working above any type of layer-2, we're in sync. >> Whether beacons or some other arbitration strategy is used should not > be >> relevant to the routing layer. What is important is which capabilites > is >> provided by the lower layer, such as: >> >> * Guaranteed delivery to another node (Yes/No) >> * Worst-case time for delivery of a packet to another node (may >> depend >> on target node capabilities) >> * Power properties (AC / AC w. batt. Backup / Big battery / Button >> cell >> battery / Environmental -sun or wind) >> * Availability of another node (A sun-powered node may be >> available and >> reliable for long periods, but not always...) >> > Pascal => Agreed but it's a different level. These are metrics and > constraints that will enter in path selection. I was discussing a > potential optimization of the flow of the PDUs that would depend on > how > well we can exploit L2 mechanisms. Yes. Thanks. JP. > >> I see RSN as a strong initiative because it is targeting a sensor >> world >> with just a good integration of technologies as classic IP provides >> today: >> I do not have to worry whether my IP traffic is running over GPRS, > ADSL, >> ATM, Ethernet, MPLS or WiFi. >> >> In exactly the same way, RSN should provide seamless operation >> between >> sensor solutions running over Z-Wave, 802.15.4 and other wireless >> low-power technologies. >> >> Br. >> Anders >> >> ------------- >> Anders Brandt >> Senior Software Architect >> >> Zensys >> Emdrupvej 26 >> DK-2100 Copenhagen O >> DENMARK >> >> phone: +45 70209940 >> fax: +4570209950 >> mail: abr@zen-sys.com >> web: www.zen-sys.com >> >> _______________________________________________ >> 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 --Apple-Mail-288--68742563 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Pascal,

On = May 25, 2007, at 9:41 AM, Pascal Thubert ((pthubert)) wrote:

Hi Anders:

Pascal =3D> Another = specificity could be to work on a tighter
integration with the radio and a more specific = abstraction for L3.
I know we have that barrier at IETF against L2 = related activities.
Yet, if the = radio model provides such things as beacons,
then it could be beneficial to = define a routing protocol that can
take
advantage of the beacons. At the moment, IP is = carried
in data = frames only.

Since the basic goal of the RSN work is to achieve a = Layer 2 technology
agnostic routing mechanism, = awareness of beacon capabilities seems to
be
a drastic move.
I suppose the = goal for us must be to describe a L2 service API, which
gives a sufficiently precise abstraction of the link = layer so that the
routing layer can make sensible = decisions.

Pascal =3D> I would question = that. I suspect that we need to define a
sensor = network abstraction and define a routing protocol for that
abstraction. If the abstraction is really agnostic = of the radio layer,
then we might be missing a = chance to get the optimizations that can be
so = critical in WSNs.=A0


I think you both agree: we = do want to be able to have an IP routing protocol not tied up with a = specific layer 2 but it may be desirable to
get layer2 = information used for routing, this is why I wrote in my original = email:

" = ...=A0Thus 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). ..."

Pascal =3D> For instance, I believe that an = abstract notion of beacon can
be useful to = advertise L3 triggers that will help in peer selection,
considering that the memory footprint will not = enable to track all peers
at all times. = You can imagine that the L2 abstraction provides an
optional timely broadcast on which L3 message can be = passed, with a
fallback solution of triggering = a data frame broadcast if the beacon is
not = provided by one specific MAC.


Agree, similarly to what is = being done in today's network when SONET/SDH/Optical parameters are used = by the layer 3.
But still, we want a routing solution working = above any type of layer-2, we're in sync.

=
Whether beacons or some = other arbitration strategy is used should not
be
relevant to the routing layer. What is important is = which capabilites
is
=
provided by the lower = layer, such as:

* Guaranteed delivery to another node = (Yes/No)
* Worst-case time for delivery = of a packet to another node (may depend
on = target node capabilities)
* Power = properties (AC / AC w. batt. Backup / Big battery / Button = cell
battery / Environmental -sun or = wind)
* Availability of another node = (A sun-powered node may be available and
reliable = for long periods, but not always...)

Pascal =3D> = Agreed but it's a different level. These are metrics and
constraints that will enter in path selection. I was = discussing a
potential optimization of the = flow of the PDUs that would depend on how
well we = can exploit L2 mechanisms.=A0

Yes.

Thanks.

JP.


=
I see RSN as a strong = initiative because it is targeting a sensor world
with just a good integration of technologies as = classic IP provides
today:
I do not have to worry whether my IP traffic is = running over GPRS,
ADSL,
=
ATM, Ethernet, MPLS or = WiFi.

In exactly the same way, RSN should provide seamless = operation between
sensor solutions running over = Z-Wave, 802.15.4 and other wireless
low-power = technologies.

Br.
=A0Anders

Anders Brandt
Senior Software Architect

Emdrupvej 26
DK-2100 Copenhagen O

phone: +45 70209940
fax: = =A0 +4570209950

RSN mailing list

RSN mailing list
=

= --Apple-Mail-288--68742563-- --===============0584730024== 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 --===============0584730024==-- From rsn-bounces@ietf.org Fri May 25 12:49:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hrcys-0000dT-2u; Fri, 25 May 2007 12:49:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hrcyq-0000cX-TA for rsn@ietf.org; Fri, 25 May 2007 12:49:32 -0400 Received: from cs-smtp-2.stanford.edu ([171.64.64.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hrcyp-0000KT-FL for rsn@ietf.org; Fri, 25 May 2007 12:49:32 -0400 Received: from dnab422323.stanford.edu ([171.66.35.35]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Hrcym-00089z-Ka; Fri, 25 May 2007 09:49:31 -0700 In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E77B297@zensys17.zensys.local> References: <20070522232511.DD58016B0002@secure.archedrock.com> <7892795E1A87F04CADFCCF41FADD00FC03FCDD2E@xmb-ams-337.emea.cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E77B297@zensys17.zensys.local> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8EEC3ACD-0243-43B1-B2CE-7226D24BB33D@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [RSN] Next step for RSN ? Date: Fri, 25 May 2007 09:16:48 -0700 To: Anders Brandt 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-2.Stanford.EDU X-Scan-Signature: dfe9a19d2d5d3f4658608889c96f7beb X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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 Comments inline. On May 25, 2007, at 5:57 AM, Anders Brandt wrote: > > > Since the basic goal of the RSN work is to achieve a Layer 2 > technology > agnostic routing mechanism, awareness of beacon capabilities seems > to be > a drastic move. > I suppose the goal for us must be to describe a L2 service API, which > gives a sufficiently precise abstraction of the link layer so that the > routing layer can make sensible decisions. In the TinyOS world, the networking working group struggled with a very similar problem when defining a "standard" collection protocol. Note that this effort (still ongoing) has two separate parts, the first being the specification of a standard API for TinyOS, the second being the specification of the protocol format itself. As TinyOS runs on top of a lot of link layers -- full 802.15.4, alternative MACs using the 15.4 link layer, FSK radios in the 900MHz and 433MHz band, etc. -- deciding on a minimal set of features that a multihop (layer 3) protocol could assume was fairly important. Note that these relate only to one particular protocol (an anycast collection tree): IP routing may have different requirements which call for a different layer 2 abstraction. Nevertheless, these may provide a strawman proposal. The four requirements the group settled on were[1]: "The CTP protocol assumes that the data link layer provides four things: 1) Provides an efficient local broadcast address. 2) Provides synchronous acknowledgments for unicast packets. 3) Provides a protocol dispatch field to support multiple higher-level protocols. 4) Has single-hop source and destination fields." Some of these might seem obvious, but it turns out that historically there have been link protocols that didn't have them. For example, early active messages in TinyOS (e.g., 1.1 and earlier) did not have a layer 2 source address. Similarly, not all TDMA protocols provide an efficient local broadcast address. Finally, 802.15.4 by itself does not provide a protocol dispatch field, so this means a link layer on top of 15.4 must add one. The requirement for synchronous layer 2 acknowledgements turns out to be pretty critical. Without it, it is very difficult for a protocol to quickly adapt to link variations. Unless there are single-hop acknowledgements issued by the layer 3 protocol -- which can really disrupt protocol timing in the wireless domain, as it introduces additional interference along a path -- detecting the cause of an end- to-end failure is difficult and retransmissions may just fail on the same link. Note that these 4 requirements do not include being able to overhear unicast packets destined to another node (snooping). This is a common assumption in the sensornet world, but turns out to be difficult or inefficient on some hardware, so we didn't include it. > > Whether beacons or some other arbitration strategy is used should > not be > relevant to the routing layer. What is important is which > capabilites is > provided by the lower layer, such as: One way to generalize "beacons" is "efficient local broadcast." > > * Guaranteed delivery to another node (Yes/No) This is of course impossible. A better way to phrase it is "mechanisms for improved reliability." > * Worst-case time for delivery of a packet to another node (may depend > on target node capabilities) This is also impossible (see above). > * Power properties (AC / AC w. batt. Backup / Big battery / Button > cell > battery / Environmental -sun or wind) Rather than the property you care about, it might be better to start from the goal. Generally, the issue raised by variable power levels is that some nodes might be more willing to communicate than others are. If a node can control its routing metric, then it can influence whether other nodes will route through it. E.g., in a protocol that uses hop count to decide on a minimum cost path, nodes that want to route less traffic can increase their advertised hopcount (e.g., they add more than one "hop" to a route). Phil [1] TEP 123: The Collection Tree Protocol (CTP) http://www.tinyos.net/ tinyos-2.x/doc/html/tep123.html _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Fri May 25 12:49:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hrcyt-0000eF-Ae; Fri, 25 May 2007 12:49:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hrcyr-0000dO-Uu for rsn@ietf.org; Fri, 25 May 2007 12:49:33 -0400 Received: from cs-smtp-2.stanford.edu ([171.64.64.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hrcyq-0000KZ-Mg for rsn@ietf.org; Fri, 25 May 2007 12:49:33 -0400 Received: from dnab422323.stanford.edu ([171.66.35.35]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Hrcyp-00089z-MT; Fri, 25 May 2007 09:49:32 -0700 In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC03FCE257@xmb-ams-337.emea.cisco.com> References: <20070522232511.DD58016B0002@secure.archedrock.com><7892795E1A87F04CADFCCF41FADD00FC03FCDD2E@xmb-ams-337.emea.cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E77B297@zensys17.zensys.local> <7892795E1A87F04CADFCCF41FADD00FC03FCE257@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <24224392-E943-45D1-B610-5CC6FC8E3313@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [RSN] Next step for RSN ? Date: Fri, 25 May 2007 09:26:32 -0700 To: Pascal Thubert ((pthubert)) 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-2.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 May 25, 2007, at 6:41 AM, Pascal Thubert ((pthubert)) wrote: > > > Pascal => I would question that. I suspect that we need to define a > sensor network abstraction and define a routing protocol for that > abstraction. If the abstraction is really agnostic of the radio layer, > then we might be missing a chance to get the optimizations that can be > so critical in WSNs. Clearly it can't be completely agnostic. The point is that if you make it specifically 802.15.4, then you're stuck once 802.15.99 (a hypothetical better and improved link layer) emerges. This requires distinguishing which parts of the abstraction are essential and which are ancillary. Minimalist abstractions give flexibility above and below. Phil _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Sat May 26 11:17: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 1Hry0v-0006Ji-Tt; Sat, 26 May 2007 11:17:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hry0u-0006JK-Ou for rsn@ietf.org; Sat, 26 May 2007 11:17:04 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hry0t-00038r-BZ for rsn@ietf.org; Sat, 26 May 2007 11:17:04 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 26 May 2007 11:16:59 -0400 X-IronPort-AV: i="4.14,582,1170651600"; d="scan'208,217"; a="122117959:sNHT139734732" 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 l4QFGxjb011719; Sat, 26 May 2007 11:16:59 -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 l4QFGu5f010677; Sat, 26 May 2007 15:16:58 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); Sat, 26 May 2007 11:16:56 -0400 Received: from [10.86.104.186] ([10.86.104.186]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 26 May 2007 11:16:54 -0400 In-Reply-To: <4655A261.2010304@gmail.com> References: <20070522232511.DD58016B0002@secure.archedrock.com> <4655A261.2010304@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <1EE4DA4A-F4EF-4192-9A99-E56C1F5D5D31@cisco.com> From: JP Vasseur Subject: Re: [RSN] Next step for RSN ? Date: Sat, 26 May 2007 11:16:43 -0400 To: Alexandru Petrescu X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 26 May 2007 15:16:54.0676 (UTC) FILETIME=[E4E31D40:01C79FA8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=45628; t=1180192619; x=1181056619; 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]=20Next=20step=20for=20RSN=20? |Sender:=20 |To:=20Alexandru=20Petrescu=20; bh=TzZcc/7ZQl6V2gbpJkMV3J3RLt/cHk6laTxhFpDjDCk=; b=hbZguAMI2rJu5K34WGdeRTzcYcRLil6fiYJJLIVnoeo3sM+E7rpTINVQ4+2MTE3GKhtYq3HW 4Too/7Obcn4uLXFYZHN0cCtS2Vo08PVW5uwluK8TWF6GQMH9M8uSVVVO; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 1dbd668ceca1a76e1ad844a781a4818d 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="===============1826089628==" Errors-To: rsn-bounces@ietf.org --===============1826089628== Content-Type: multipart/alternative; boundary=Apple-Mail-301-21940573 --Apple-Mail-301-21940573 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Alexandru, On May 24, 2007, at 10:34 AM, Alexandru Petrescu wrote: > Hi JP, I've received this on the MANEMO list but I'm replying here. > > I have some comments, more like against forming the RSN work, but > I'm ok with all other opinions too :-) > > One is that I generally don't really see why routing for sensor > networks > is different than other networks. Or maybe that it is generally too > early for that. > > One can interpret that routing for serverfarms is same as routing for > laptops (same std routing protocols) - and serverfarms and laptops > have > very different energy requirements. Or, sensors are to laptops what > laptops are to serverfarms... > Phil already replied to this comment but let me add a new more things since this is the *key* reason for RSN: no, sensor networks are very significantly different from other IP networks, in many respects and this is why an adequate routing solution is required. Should you want to have a look at the requirements, please ready draft-culler-rsn-routing-reqs. Note that other routing application specific IDs are in the works. Without reiterating the set of unique requirements that affect the routing protocol for Sensor Nets, here are some comments with regards to your statements: 1) First a laptop is usually a host rather than a router, but this is a cosmetic comment since it could perfectly run a routing protocol and Linux machine running OSPF are sometimes used as router for experiments. Anyway, just a side note. 2) When you look at the routing protocols in used in the Internet (IGP), they are not designed/optimized for networks with low bandwidth links, unreliable links and highly constraints nodes, the last aspects being key here since the computed path (SPT) does not taken into account the node characteristics (other than potential node pruning using node cap). There are networks with heterogenous devices indeed but the path is not a function of the nodes but the links using Dijkstra. This leads to defining IP constrained based routing while addressing the requirements of unreliable and dynamic topologies due to mobility and unstable links or nodes. Again the notion of constrained based routing (that has been designed in other contexts (MPLS)) differs from existing IGPs. Other requirements such as QoS aware routing, MTR, ... have been defined for other IGPs but would very likely require a different solutions here because of node constraints. This is particularly unique to Sensor Networks. So your analogy does not hold at all here. > JP Vasseur wrote: >> Dear List members, >> Looking at the number of people who registered to this list, there >> seems to be a strong interest in designing a Routing solution for >> Sensor Networks. David and I had during the last few months a >> number of off-line discussions with positive feed-back and >> support, it is now a good time to use the Mailing List to gauge >> whether there is a consensus on whether to work on this topic. >> David provided an excellent problem statement below. I'd like to >> add a few comments and get feed-back from the ML members on >> whether we collectively want to work on this item. >> With no doubt, we'll see many other radio networks emerging soon >> and sensor networks will soon be made links using various layer1/2 >> protocols defined by other SDOs: 802.15.4, > > 802.15.4 no doubt offers its own link-layer routing... IP routing not > necessary here. > >> Wifi, > > WiFi has a very clear network topology (BAse Station and mobile) where > routing is not necessary at all over the air (neither link-layer nor > IP). Most deployments are done this way and I haven't seen any wifi > deployment needing IP routing. > >> WiMax > > Same as wifi. No need for IP routing for WiMax over the air and > down to > mobile. > > BEsides, I doubt WiFi or WiMAx can be used by the smallest of the > sensors... I really don't see a sensor having WMAN capability... > it's > really too far-fetched. > > Or do you mean to IP route and gate through the heterogeneity of these > wireless link-layers? You're missing the point here of networks made of a variety of links of different natures, thus my comments to provide a routing solution offering an end to end constrained path (this is not the only requirement): this is clearly extremely challenging without a IP routing solution independent of the link layer. > >> but also *non wireless links*. > > Which ones? I think that the smallest wired network interfaces and > connections are Ethernet and probably USB. You can perfectly have a Sensor Networks made of RF links and wired links. > >> Such networks will also comprise sensor nodes with a wide range of >> capabilities, *which makes the routing fairly unique in term of >> requirement*. Thus 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). >> It looks fairly obvious that a network made of N "mesh-under" routing >> protocols is very unlikely to satisfy an end to end path >> constraint and would be fairly complex to manage and tune. We all >> remember the issue of IP routing over ATM PVCs routed by PNNI. >> Think of this with N "Mesh-under" routing protocols. That said, >> this is not to say that we exclude the use of "mesh-under" >> solutions, but we propose to define a IP-based routing protocol. >> /*What would be a charter proposal ?*/ >> First we would need to spend a good amount of time on the routing >> requirements. David and I posted a first revision of a generic >> requirement draft (draft-culler-rsn-routing-reqs-00.txt); the next >> revision will soon be posted accounting for the comments received >> so far. I would propose to continue to list the generic >> requirements in this draft and have other application-specific >> routing requirements drafts discussed in other IDs: for home >> networking, industrial applications, ... Such approach has been >> successfully adopted in other WGs. >> The second step would consist of making a survey on the existing >> routing protocols and see whether (1) they could be used as such >> (2) they should be adapted (for instance, see whether AODV or OLR >> or RIP could be made energy efficient, could support some form of >> constrained based routing, ...) or (3) we should design a new generic >> new protocol. > > I agree with this point. Ah. > > MANEMO effort was recently (in March) directed to analyse what MANET > protocol can satisfy the MANEMO needs. > > I think that if one goes to MANET and asks one will most certainly > find > out that MANET protocols (currently: DYMO, OLSRv2 and NDHP) can surely > deal with RSN needs. I think that will be a tough barrier to overcome > if one wants to build a new RSN protocol. > See my previous comment: No we cannot make the assumption that AODV or OLSR will be the protocol to use. It MAY be an excellent solution with adaptations though. This is why the proposal is indeed to have a place where we could make a clear analysis of the requirements and come up with a solution, which again could be based on Manemo, AODV, ... or a new routing protocol. There is NO reason to define a new protocol if not needed and we do not want at the IETF to invent protocols when not required. On the other hand, it is certainly a bad idea to state a priori that a protocol X should be used or could be used with several extensions if this is not the correct long term approach. We could mention many examples where using an existing protocol and adapt it to meet new requirements was indeed the right solution but there are also a number of example where we had to live with poorly engineered solutions, thus the proposed approach. Does that clarify the approach ? >> Note that we may not be able to satisfy all the requirements, and >> this might be perfectly acceptable and should be documented. >> Indeed, we all know that Sensor Networks may significantly differ >> in term of degree of mobility, > > Mobility? I think sensor networks once deployed are not mobile at > all. > Neither do they move homogeneously as a group (with respect to > Earth), > nor do they move with respect to each-other. Ah no life is not so simple ;-) ... As pointed out, there are many types of sensor networks. Some of them are completely static indeed but there are also many sensor networks where nodes are mobile with various degree of mobility. Just to mention two examples (among many other ones): healthcare with wearable sensors (see the SMART project as one example of deployed network), vehicular, industrial (with sensor on containers, moving machines, ...), ... Now here is one of our challenges: since there are so many potential deployment cases, you could indeed come up with a superset of all requirements and more than likely there won't be any protocols that would meet all of them, especially if designed for constrained nodes. So we would have to identify a core set of requirements, specify the solution and potentially document that this protocol would not be used for some applications (e.g DTN sensor nets, ... might be challenging). This is a perfectly fine approach. > >> link layer reliability/bandwidth, node constraints, ... A very >> good outcome of this work might be that the newly defined/adapted >> protocol >> could satisfy the requirement IDs A, B, D and E but not C. >> So please use this list to provide feed-back on whether you would >> support such initiative and if so your contribution is more than >> welcome. Note that several people already mentioned some interest and >> we do expect to see new IDs posted before Chicago. > > What's the potential interaction between RSN and MANEMO? MANEMO is a good candidate to be evaluated once the detailed requirements work will have been completed. > > Will a vehicle full of sensors talk to another such vehicle by > using RSN > or MANEMO protocol? Or MANET protocol? This is part of the work item. Thanks, hope this helps. JP. > > Alex > >> JP and David. >> Begin forwarded message: >>> *From: *"dculler" >> > *Date: *May 23, 2007 1:24:58 AM GMT >>> +02:00 *To: *> *Subject: ** >>> [RSN] Interest in the Interplay of "routing" and "meshing"* >>> *Reply-To: *dculler@archrock.com >>> Several of the comments on this list have touched on the issue of >>> different kinds of "multihop routing" in the context of sensor >>> networks. Is there interest in working on how these forms of >>> routing tie together? >>> To make the question more grounded: Low power radios have >>> relatively short range. IEEE 802.15.4 radios are typically 1 mW >>> transmit power, vs 100 mW for 802.11, and have typical ranges in >>> 10s to 100 m. Generally speaking, the power required to communicate >>> a given distance by radio grows polynomially with distance. In >>> typical settings it grows like the cube, but it can be much worse >>> near the ground or somewhat better with directional antennas. >>> The cost to communicate hop-by-hop grows only linearly, and it >>> offers the potential to route around obstacles and enhance >>> reliability through "receiver diversity". >>> The question is at what layer(s) in the stack this routing occurs >>> and how it relates to IP routing more generally. Most multihop >>> protocols in the sensor network research community are >>> effectively at layer2 - they form a single "patch" of homogeneous >>> media. Logically, they are a subnet, although few of the >>> protocols address >>> what happens beyond the "patch" of sensor nodes, other than that >>> some of the nodes are "gateways". Current industry standards, such >>> as Zigbee, Zwave, and wirelessHART, are also a "multihop link", >>> leaving open the question of how nodes within the sensor patch >>> communicate with nodes outside. >>> 6LoWPAN provides a compressed header format for "mesh routing", >>> meaning multihop forwarding of packets within the 802.15.4 link. >>> Such a link is assumed to be formed by a contiguously connected set >>> of 802.15.4 nodes. The presence of such "mesh routing" >>> capabilities does not eliminate the need for layer 3 routing. If a >>> 15.4 node communicates with a remote node, say an 802.11 node, how >>> is routing and forwarding carried out? If two "LoWPAN >>> subnets" [sic] happen to be connected by 15.4 nodes, how does >>> 15.4-to-15.4 routing occur? The 6LoWPAN header format is, of >>> course, a general solution for carrying IP over 802.15.4, so it >>> is able to express these other forms of routing, as well. In the >>> extreme case, each individual node is an IP link and all routing >>> is done at the IP layer. On the other hand, patches of nodes may >>> want to function as >>> a logical subnet, even if the wireless multihop routing is done at >>> the IP layer. At this point, the concerns overlap with those >>> addressed in autoconf (cf., draft-ietf-autoconf-manetarch-01). >>> There is substantial commonality of concerns at the different >>> layers of multihop routing, but also differences. It is also >>> important to separate the process of forming a routing topology >>> from the process of forwarding packets. Both of which are distinct >>> (but not entirely independent of) how power management (turning >>> on/off the radios) is performed. >>> _______________________________________________ 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 > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ --Apple-Mail-301-21940573 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi = Alexandru,

On May 24, 2007, at 10:34 AM, Alexandru = Petrescu wrote:

Hi JP, I've received this on the = MANEMO list but I'm replying here.

I have some comments, more like = against forming the RSN work, but
I'm ok with = all other opinions too :-)

One is that I generally don't = really see why routing for sensor networks
is = different than other networks.=A0 = Or maybe that it is generally too
early = for that.

One can interpret that routing for serverfarms is = same as routing for
laptops (same std routing = protocols) - and serverfarms and laptops have
very different energy requirements.=A0 Or, sensors are to laptops = what
laptops are to = serverfarms...
Phil already replied to = this comment but let me add a new more things since this is the *key* = reason for RSN: no, sensor networks
are very significantly = different from other IP networks, in many respects and this is why an = adequate routing solution is required.=A0
Should you want to = have a look at the requirements, please ready = draft-culler-rsn-routing-reqs. Note that other routing = application
specific IDs are in the works.

Without reiterating the set = of unique requirements that affect the routing protocol for Sensor Nets, = here are some comments with=A0
regards to your = statements:
1) First a laptop is usually a host rather than a = router, but this is a cosmetic comment since it could perfectly run a = routing protocol
and Linux machine running OSPF are sometimes = used as router for experiments. Anyway, just a side note.
2) = When you look at the routing protocols in used in the Internet (IGP), = they are not designed/optimized for networks with low bandwidth = links,
unreliable links and highly constraints nodes, the last = aspects being key here since the computed path (SPT) does not taken = into
account the node characteristics (other than potential = node pruning using node cap).=A0
There are networks with = heterogenous devices indeed but the path is not a function of the nodes = but=A0the links using Dijkstra. This leads to defining IP constrained = based routing=A0while addressing the requirements of unreliable=A0and = dynamic topologies due to mobility and unstable links or nodes. Again = the notion of constrained based routing (that has been designed=A0in = other contexts (MPLS)) differs from existing IGPs.

Other requirements such as = QoS aware routing, MTR, ... have been defined for other IGPs but would = very likely require a different
solutions here because of node = constraints.

This is particularly unique = to Sensor Networks. So your analogy does not hold at all = here.=A0

JP Vasseur wrote:
=
Dear List = members,
Looking at the number of people = who registered to this list, there seems to be a strong interest in = designing a Routing solution for Sensor Networks. David and I had during = the last few months a number of off-line discussions with positive = feed-back and support, it is now a good time to use the Mailing List to = gauge whether there is a consensus on whether to work on this = topic.
David provided an excellent = problem statement below. I'd like to add a few comments and get = feed-back from the ML members on whether we collectively want to work on = this item.
With no doubt, we'll see many = other radio networks emerging soon and sensor networks will soon be made = links using various layer1/2 protocols defined by other SDOs: = 802.15.4,

802.15.4 no doubt offers its own = link-layer routing... IP routing not
necessary = here.

=
Wifi,
=

WiFi has a very clear network topology (BAse Station = and mobile) where
routing is not necessary at all = over the air (neither link-layer nor
IP).=A0 Most deployments are done = this way and I haven't seen any wifi
deployment = needing IP routing.
WiMax
=

Same as wifi.=A0= No need for IP routing for WiMax over the air and down = to
mobile.

BEsides, I doubt WiFi or WiMAx = can be used by the smallest of the
=A0 I really = don't see a sensor having WMAN=A0 = capability... it's
really too = far-fetched.

Or do you mean to IP route and gate through the = heterogeneity of these
wireless = link-layers?

You're missing the point = here of networks made of a variety of links of different natures, thus = my comments to provide a routing
solution offering an end to = end constrained path (this is not the only requirement): this is clearly = extremely challenging without a IP routing solution independent = of
the link layer.


but also *non wireless = links*.
Which ones?=A0 I think that the smallest = wired network interfaces and
connections = are Ethernet and probably USB.

You can perfectly have a = Sensor Networks made of RF links and wired links.


=
Such networks will also = comprise sensor nodes with a wide range of capabilities, *which makes = the routing fairly unique in term of requirement*. Thus the proposal is = to design a IP routing solution specifically for sensor networks, that = would of course be independent
=A0to 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).
It looks fairly obvious that a = network made of N "mesh-under" routing
=A0protocols is very unlikely to = satisfy an end to end path constraint and would be fairly complex to = manage and tune. We all remember the issue of IP routing over ATM PVCs = routed by PNNI. Think of this with N "Mesh-under" routing protocols. = That said, this is not to say that we exclude the use of "mesh-under" = solutions, but we propose to define a IP-based routing = protocol.
/*What would be a charter = proposal ?*/
First we would need to spend a = good amount of time on the routing requirements. David and I posted a = first revision of a generic requirement draft = (draft-culler-rsn-routing-reqs-00.txt); the next revision will soon be = posted accounting for the comments received so far. I would propose to = continue to list the generic requirements in this draft and have other = application-specific routing requirements drafts discussed in other IDs: = for home networking, industrial applications, ... Such approach has been = successfully adopted in other WGs.
The second = step would consist of making a survey on the existing routing protocols = and see whether (1) they could be used as such (2) they should be = adapted (for instance, see whether AODV or OLR or RIP could be made = energy efficient, could support some form of constrained based routing, = ...) or (3) we should design a new generic
=A0new protocol.
=

I agree with this point.

Ah.


MANEMO effort was recently (in March) directed to = analyse what MANET
protocol can satisfy the = MANEMO needs.

I think that if one goes to MANET and asks one will = most certainly find
out that MANET protocols = (currently: DYMO, OLSRv2 and NDHP) can surely
deal with RSN needs.=A0 I think that will be a tough = barrier to overcome
if one wants to build a new = RSN protocol.
See my previous comment: No = we cannot make the assumption that AODV or OLSR will be the protocol to = use. It MAY be an excellent
solution with adaptations though. = This is why the proposal is indeed to have a place where we could make a = clear analysis of the requirements
and come up with a = solution, which again could be based on Manemo, AODV, ... or a new = routing protocol. There is NO reason to define a
new protocol = if not needed and we do not want at the IETF to invent protocols when = not required. On the other hand, it is certainly a bad idea
to = state a priori that a protocol X should be used or could be used with = several extensions if this is not the correct long term approach. We = could
mention many examples where using an existing protocol = and adapt it to meet new requirements was indeed the right solution but = there are=A0
also a number of example where we had to live = with poorly engineered solutions, thus the proposed = approach.

Does = that clarify the approach ?

Note that we may not be able to = satisfy all the requirements, and this might be perfectly acceptable and = should be documented. Indeed, we all know that Sensor Networks may = significantly differ in term of degree of mobility,
=

Mobility?=A0 = I think sensor networks once deployed are not mobile at = all.
=A0Neither do they move = homogeneously as a group (with respect to Earth),
nor do they move with respect to = each-other.

Ah no life is not so simple = ;-) ... As pointed out, there are many types of sensor networks. Some of = them are completely static indeed but
there are also many = sensor networks where nodes are mobile with various degree of mobility. = Just to mention two examples (among many
other = ones):=A0healthcare with wearable sensors (see the SMART project as one = example of deployed network), vehicular, industrial = (with=A0
sensor on containers, moving machines, ...), = ...

Now here = is one of our challenges: since there are so many potential deployment = cases, you could indeed come up with a superset of = all
requirements and more than likely there won't be any = protocols that would meet all of them, especially if designed for = constrained nodes.
So we would have to identify a core set of = requirements, specify the solution and potentially document that this = protocol would not be used
for some applications (e.g DTN = sensor nets, ... might be challenging). This is a perfectly fine = approach.


link layer reliability/bandwidth, node constraints, = ... A very good outcome of this work might be that the newly = defined/adapted protocol
=A0could satisfy the requirement = IDs A, B, D and E but not C.
So please use = this list to provide feed-back on whether you would support such = initiative and if so your contribution is more than welcome. Note that = several people already mentioned some interest and
=A0we = do expect to see new IDs posted before Chicago.

What's = the potential interaction between RSN and = MANEMO?

MANEMO is a good candidate = to be evaluated once the detailed requirements work will have been = completed.


Will a = vehicle full of sensors talk to another such vehicle by using = RSN
or MANEMO protocol?=A0 Or MANET = protocol?

This is part of the work = item.

Thanks, = hope this helps.

JP.


Alex

JP and = David.
Begin forwarded message:
=
*From: *"dculler" = <dculler@archrock.com <mailto:dculler@archrock.com>&g= t; *Date: *May 23, 2007 1:24:58 AM GMT+02:00 *To: *<rsn@ietf.org = <mailto:rsn@ietf.org>> = *Subject: **[RSN] Interest in the Interplay of "routing" and "meshing"* = *Reply-To: *dculler@archrock.com <mailto:dculler@archrock.com>
Several of the comments on this list have = touched on the issue of different kinds of "multihop routing" in the = context of sensor networks.=A0 = Is there interest in working on how these forms of routing tie = together?
To make the question more = grounded:=A0 Low power = radios have relatively short range.=A0= IEEE 802.15.4 radios are typically 1 mW transmit power, vs 100 = mW for 802.11, and have typical ranges in 10s to 100 m. Generally = speaking, the power required to communicate
=A0a given distance by radio = grows polynomially with distance.=A0= In typical settings it grows like the cube, but it can be much = worse near the ground or somewhat better with directional antennas.=A0 The cost to communicate = hop-by-hop grows only linearly, and it offers the potential to route = around obstacles and enhance reliability through "receiver = diversity".
The question is at what layer(s) = in the stack this routing occurs and how it relates to IP routing more = generally.=A0 Most multihop = protocols in the sensor network research community are effectively at = layer2 - they form a single "patch" of homogeneous media. Logically, = they are a subnet, although few of the protocols address
=A0what = happens beyond the "patch" of sensor nodes, other than that some of the = nodes are "gateways".=A0 = Current industry standards, such
=A0as Zigbee, Zwave, and = wirelessHART, are also a "multihop link", leaving open the question of = how nodes within the sensor patch communicate with nodes = outside.
6LoWPAN provides a compressed = header format for "mesh routing", meaning multihop forwarding of packets = within the 802.15.4 link. Such a link is assumed to be formed by a = contiguously connected set
=A0of 802.15.4 nodes.=A0 The presence of such "mesh = routing" capabilities does not eliminate the need for layer 3 = routing.=A0 If a
=A015.4 = node communicates with a remote node, say an 802.11 node, how
=A0is = routing and forwarding carried out?=A0= If two "LoWPAN subnets" [sic] happen to be connected by 15.4 = nodes, how does 15.4-to-15.4 routing occur?=A0 The 6LoWPAN header format is, = of course, a general solution for carrying IP over 802.15.4, so it is = able to express these other forms of routing, as well.=A0 In the extreme case, each = individual node is an IP link and all routing is done at the IP = layer.=A0 On the other = hand, patches of nodes may want to function as
=A0a = logical subnet, even if the wireless multihop routing is done = at
=A0t= he IP layer.=A0 At this = point, the concerns overlap with those addressed in autoconf (cf., = draft-ietf-autoconf-manetarch-01).
There is = substantial commonality of concerns at the different layers of multihop = routing, but also differences.=A0 = It is also important to separate the process of forming a routing = topology from the process of forwarding packets.=A0 Both of which are = distinct
=A0(but not entirely independent = of) how power management (turning on/off the radios) is = performed.
_______________________________________________ = RSN mailing list RSN@ietf.org https://www1.ietf.org/= mailman/listinfo/rsn


This email has been scanned by the MessageLabs = Email Security System.
For more information please = visit http://www.messagelabs.com/email= = ______________________________________________________________________

= --Apple-Mail-301-21940573-- --===============1826089628== 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 --===============1826089628==-- From rsn-bounces@ietf.org Mon May 28 01:55: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 1HsYCX-00020y-BC; Mon, 28 May 2007 01:55:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsYCW-00020s-D5 for rsn@ietf.org; Mon, 28 May 2007 01:55:28 -0400 Received: from auth-smtp.nebula.fi ([217.30.180.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsYCU-00042P-KF for rsn@ietf.org; Mon, 28 May 2007 01:55:28 -0400 Received: from dyn604.panoulu.local (gw1.panoulu.net [212.50.147.101]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id l4S5RVW6001082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 May 2007 08:27:36 +0300 Message-ID: <465A6EBF.70600@sensinode.com> Date: Mon, 28 May 2007 08:55:11 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: rsn@ietf.org Subject: Re: [RSN] Next step for RSN ? References: <20070522232511.DD58016B0002@secure.archedrock.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 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 support the RSN effort and like the requirements-based approach. A few comments on the lastest e-mail exchanges. - I like the minimum set of link-layer features approach suggested by Philip. In addition optional features such as providing RSSI/ToA could be listed as well. This should be added to the req ID? - Although RSN is independent of e.g. WiFi or 6lowpan mesh-under, it should be aware of them, differentiated from them, and compatible with them. I suggest that the interoperability with these mesh-under techniques be made explicit in the RSN req ID. This does not lock RSN into any particular L1/L2 technique, but simply ensures interoperability. Unlike in Ethernet bridget networks, where latencies are very minimal, a mesh-under subnet in a low-speed wireless network will have very different properties than a single hop. We should also be explicit to avoid confusion with the 6lowpan work. Don't underestimate mesh-under, in the WiFi world it is really what is being successfully deployed. - Application specific variants of the routing protocol reqs is a good idea. Zach JP Vasseur wrote: > Dear List members, > > Looking at the number of people who registered to this list, there seems > to be a strong interest in designing a Routing solution for Sensor > Networks. David and I had during the last few months a number of > off-line discussions with positive feed-back and support, it is now a > good time to use the Mailing List to gauge whether there is a consensus > on whether to work on this topic. > > David provided an excellent problem statement below. I'd like to add a > few comments and get feed-back from the ML members on whether we > collectively want to work on this item. > > With no doubt, we'll see many other radio networks emerging soon and > sensor networks will soon be made links using various layer1/2 protocols > defined by other SDOs: 802.15.4, Wifi, WiMax but also non wireless > links. Such networks will also comprise sensor nodes with a wide range > of capabilities, which makes the routing fairly unique in term of > requirement. Thus 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). > > It looks fairly obvious that a network made of N "mesh-under" routing > protocols is very unlikely to satisfy an end to end path constraint and > would be fairly complex to manage and tune. We all remember the issue of > IP routing over ATM PVCs routed by PNNI. Think of this with N > "Mesh-under" routing protocols. That said, this is not to say that we > exclude the use of "mesh-under" solutions, but we propose to define a > IP-based routing protocol. > > What would be a charter proposal ? > > First we would need to spend a good amount of time on the routing > requirements. David and I posted a first revision of a generic > requirement draft (draft-culler-rsn-routing-reqs-00.txt); the next > revision will soon be posted accounting for the comments received so > far. I would propose to continue to list the generic requirements in > this draft and have other application-specific routing requirements > drafts discussed in other IDs: for home networking, industrial > applications, ... Such approach has been successfully adopted in other WGs. > > The second step would consist of making a survey on the existing routing > protocols and see whether (1) they could be used as such (2) they should > be adapted (for instance, see whether AODV or OLR or RIP could be made > energy efficient, could support some form of constrained based routing, > ...) or (3) we should design a new generic new protocol. > > Note that we may not be able to satisfy all the requirements, and this > might be perfectly acceptable and should be documented. Indeed, we all > know that Sensor Networks may significantly differ in term of degree of > mobility, link layer reliability/bandwidth, node constraints, ... A very > good outcome of this work might be that the newly defined/adapted > protocol could satisfy the requirement IDs A, B, D and E but not C. > > So please use this list to provide feed-back on whether you would > support such initiative and if so your contribution is more than > welcome. Note that several people already mentioned some interest and we > do expect to see new IDs posted before Chicago. > > JP and David. > > Begin forwarded message: > >> From: "dculler" >> Date: May 23, 2007 1:24:58 AM GMT+02:00 >> To: >> Subject: [RSN] Interest in the Interplay of "routing" and "meshing" >> Reply-To: dculler@archrock.com >> >> Several of the comments on this list have touched on the issue of >> different kinds of "multihop routing" in the context of sensor >> networks. Is there interest in working on how these forms of routing >> tie together? >> >> To make the question more grounded: Low power radios have relatively >> short range. IEEE 802.15.4 radios are typically 1 mW transmit power, >> vs 100 mW for 802.11, and have typical ranges in 10s to 100 m. >> Generally speaking, the power required to communicate a given distance >> by radio grows polynomially with distance. In typical settings it >> grows like the cube, but it can be much worse near the ground or >> somewhat better with directional antennas. The cost to communicate >> hop-by-hop grows only linearly, and it offers the potential to route >> around obstacles and enhance reliability through "receiver diversity". >> >> The question is at what layer(s) in the stack this routing occurs and >> how it relates to IP routing more generally. Most multihop protocols >> in the sensor network research community are effectively at layer2 - >> they form a single "patch" of homogeneous media. Logically, they are >> a subnet, although few of the protocols address what happens beyond >> the "patch" of sensor nodes, other than that some of the nodes are >> "gateways". Current industry standards, such as Zigbee, Zwave, and >> wirelessHART, are also a "multihop link", leaving open the question of >> how nodes within the sensor patch communicate with nodes outside. >> >> 6LoWPAN provides a compressed header format for "mesh routing", >> meaning multihop forwarding of packets within the 802.15.4 link. Such >> a link is assumed to be formed by a contiguously connected set of >> 802.15.4 nodes. The presence of such "mesh routing" capabilities does >> not eliminate the need for layer 3 routing. If a 15.4 node >> communicates with a remote node, say an 802.11 node, how is routing >> and forwarding carried out? If two "LoWPAN subnets" [sic] happen to >> be connected by 15.4 nodes, how does 15.4-to-15.4 routing occur? The >> 6LoWPAN header format is, of course, a general solution for carrying >> IP over 802.15.4, so it is able to express these other forms of >> routing, as well. In the extreme case, each individual node is an IP >> link and all routing is done at the IP layer. On the other hand, >> patches of nodes may want to function as a logical subnet, even if the >> wireless multihop routing is done at the IP layer. At this point, the >> concerns overlap with those addressed in autoconf (cf., >> draft-ietf-autoconf-manetarch-01). >> >> There is substantial commonality of concerns at the different layers >> of multihop routing, but also differences. It is also important to >> separate the process of forming a routing topology from the process of >> forwarding packets. Both of which are distinct (but not entirely >> independent of) how power management (turning on/off the radios) is >> performed. >> >> >> _______________________________________________ >> 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 -- Zach Shelby | Managing Director | +358 40 7796297 Sensinode Ltd. www.sensinode.com _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Mon May 28 03:35:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsZlX-0003Yv-JN; Mon, 28 May 2007 03:35:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsZlV-0003Yq-UR for rsn@ietf.org; Mon, 28 May 2007 03:35:42 -0400 Received: from an-out-0708.google.com ([209.85.132.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsZlV-0002Pm-GT for rsn@ietf.org; Mon, 28 May 2007 03:35:41 -0400 Received: by an-out-0708.google.com with SMTP id c17so404233anc for ; Mon, 28 May 2007 00:35:41 -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=PIpEyTpw1+d6Hp3sGLCvczFcXRawSYAOiYd3/pxAblavWLgabxNFnkQjha7yZ5J7GCaC8GVkYK3Ftm7FaBwWTSuX198LFEwQGzYagIDZ3KXwh/niCoTgyyKF66yxdkqk8Y4h2f6r9bzsZ32hhv0fkgZ+cyN5Fpa+L/y2a7VSGpI= 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=aPNnrA99U99XWUWuogbuv5aO7hUsWyRF1z1ygD//Zf7Sz4Z6WHQggjF4wfMa1tdpMVwhINEODtGhcyDgTPYymRv3msZckTm7g3vxctqebdkQhP0Dgj9o2OCHsYVBhKFxvsONggjgMFGpM82uy9UJzsX75kFtwlJ4vTxiHJzkUJU= Received: by 10.100.47.9 with SMTP id u9mr4342977anu.1180337740750; Mon, 28 May 2007 00:35:40 -0700 (PDT) Received: by 10.100.121.2 with HTTP; Mon, 28 May 2007 00:35:40 -0700 (PDT) Message-ID: <2a3692de0705280035s370f952co2ac00558ed024cfb@mail.gmail.com> Date: Mon, 28 May 2007 16:35:40 +0900 From: "Dominik Kaspar" To: rsn@ietf.org Subject: Re: [RSN] Next step for RSN ? 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: <20070522232511.DD58016B0002@secure.archedrock.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd 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 RSN List, In my opinion, RSN should focus more on one basic problem or a number of orthogonal problems. Especially for sensor networks, there is no substitute for simplicity. This very basic requirement has been called "light footprint" in draft-culler-rsn-routing-reqs-00, but seems to have gone forgotten. The requirement list suggests a multi-purpose RSN protocol, which dynamically adapts to topology changes, intelligently switches between end-to-end routing and data diffusion, supports data-aware routing, topology-dependent QoS, ...etc. I question the feasibility of meeting such a complex set of orthogonal requirements for sensor networks. In order words, which ones of the current requirements, can we sacrifice? Also..., is it the goal of RSN to provide IP-based querying of a single sensor node in an end-to-end paradigm? Or is it the goal of RSN to allow querying a network as an entity? Is it the goal to allow sensors send their data to a sink on certain events? Is it the goal to allow sensor nodes address other remote sensor nodes, too? Is the the goal of RSN to support all of this at the same time? The answers would help me to see RSN more clearly. Regards, Dominik. On 5/23/07, JP Vasseur wrote: > Dear List members, > > Looking at the number of people who registered to this list, there seems to > be a strong interest in designing a Routing solution for Sensor Networks. > David and I had during the last few months a number of off-line discussions > with positive feed-back and support, it is now a good time to use the > Mailing List to gauge whether there is a consensus on whether to work on > this topic. > > David provided an excellent problem statement below. I'd like to add a few > comments and get feed-back from the ML members on whether we collectively > want to work on this item. > > With no doubt, we'll see many other radio networks emerging soon and sensor > networks will soon be made links using various layer1/2 protocols defined by > other SDOs: 802.15.4, Wifi, WiMax but also non wireless links. Such networks > will also comprise sensor nodes with a wide range of capabilities, which > makes the routing fairly unique in term of requirement. Thus 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). > > It looks fairly obvious that a network made of N "mesh-under" routing > protocols is very unlikely to satisfy an end to end path constraint and > would be fairly complex to manage and tune. We all remember the issue of IP > routing over ATM PVCs routed by PNNI. Think of this with N "Mesh-under" > routing protocols. That said, this is not to say that we exclude the use of > "mesh-under" solutions, but we propose to define a IP-based routing > protocol. > > What would be a charter proposal ? > > First we would need to spend a good amount of time on the routing > requirements. David and I posted a first revision of a generic requirement > draft (draft-culler-rsn-routing-reqs-00.txt); the next > revision will soon be posted accounting for the comments received so far. I > would propose to continue to list the generic requirements in this draft and > have other application-specific routing requirements drafts discussed in > other IDs: for home networking, industrial applications, ... Such approach > has been successfully adopted in other WGs. > > The second step would consist of making a survey on the existing routing > protocols and see whether (1) they could be used as such (2) they should be > adapted (for instance, see whether AODV or OLR or RIP could be made energy > efficient, could support some form of constrained based routing, ...) or (3) > we should design a new generic new protocol. > > Note that we may not be able to satisfy all the requirements, and this might > be perfectly acceptable and should be documented. Indeed, we all know that > Sensor Networks may significantly differ in term of degree of mobility, link > layer reliability/bandwidth, node constraints, ... A very good outcome of > this work might be that the newly defined/adapted protocol could satisfy the > requirement IDs A, B, D and E but not C. > > So please use this list to provide feed-back on whether you would support > such initiative and if so your contribution is more than welcome. Note that > several people already mentioned some interest and we do expect to see new > IDs posted before Chicago. > > JP and David. > > Begin forwarded message: > > From: "dculler" > Date: May 23, 2007 1:24:58 AM GMT+02:00 > To: > Subject: [RSN] Interest in the Interplay of "routing" and "meshing" > Reply-To: dculler@archrock.com > > Several of the comments on this list have touched on the issue of different > kinds of "multihop routing" in the context of sensor networks. Is there > interest in working on how these forms of routing tie together? > > To make the question more grounded: Low power radios have relatively short > range. IEEE 802.15.4 radios are typically 1 mW transmit power, vs 100 mW > for 802.11, and have typical ranges in 10s to 100 m. Generally speaking, > the power required to communicate a given distance by radio grows > polynomially with distance. In typical settings it grows like the cube, but > it can be much worse near the ground or somewhat better with directional > antennas. The cost to communicate hop-by-hop grows only linearly, and it > offers the potential to route around obstacles and enhance reliability > through "receiver diversity". > > The question is at what layer(s) in the stack this routing occurs and how it > relates to IP routing more generally. Most multihop protocols in the sensor > network research community are effectively at layer2 - they form a single > "patch" of homogeneous media. Logically, they are a subnet, although few of > the protocols address what happens beyond the "patch" of sensor nodes, other > than that some of the nodes are "gateways". Current industry standards, > such as Zigbee, Zwave, and wirelessHART, are also a "multihop link", leaving > open the question of how nodes within the sensor patch communicate with > nodes outside. > > 6LoWPAN provides a compressed header format for "mesh routing", meaning > multihop forwarding of packets within the 802.15.4 link. Such a link is > assumed to be formed by a contiguously connected set of 802.15.4 nodes. The > presence of such "mesh routing" capabilities does not eliminate the need for > layer 3 routing. If a 15.4 node communicates with a remote node, say an > 802.11 node, how is routing and forwarding carried out? If two "LoWPAN > subnets" [sic] happen to be connected by 15.4 nodes, how does 15.4-to-15.4 > routing occur? The 6LoWPAN header format is, of course, a general solution > for carrying IP over 802.15.4, so it is able to express these other forms of > routing, as well. In the extreme case, each individual node is an IP link > and all routing is done at the IP layer. On the other hand, patches of > nodes may want to function as a logical subnet, even if the wireless > multihop routing is done at the IP layer. At this point, the concerns > overlap with those addressed in autoconf (cf., > draft-ietf-autoconf-manetarch-01). > > There is substantial commonality of concerns at the different layers of > multihop routing, but also differences. It is also important to separate > the process of forming a routing topology from the process of forwarding > packets. Both of which are distinct (but not entirely independent of) how > power management (turning on/off the radios) is performed. > > > _______________________________________________ > 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 Mon May 28 07:43:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsddM-0005FY-GO; Mon, 28 May 2007 07:43:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsddL-0005FT-6f for rsn@ietf.org; Mon, 28 May 2007 07:43:31 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsddI-0000Wa-JQ for rsn@ietf.org; Mon, 28 May 2007 07:43:31 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 28 May 2007 07:43:28 -0400 X-IronPort-AV: i="4.14,586,1170651600"; d="scan'208"; a="61332875:sNHT145837730" 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 l4SBhSrE017459; Mon, 28 May 2007 07:43:28 -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 l4SBhL5f019934; Mon, 28 May 2007 11:43:26 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); Mon, 28 May 2007 07:43:20 -0400 Received: from [10.86.104.186] ([10.86.104.186]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 May 2007 07:43:15 -0400 In-Reply-To: <465A6EBF.70600@sensinode.com> References: <20070522232511.DD58016B0002@secure.archedrock.com> <465A6EBF.70600@sensinode.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9FCF525E-56EF-4440-AFE8-7EA31B84CAEA@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [RSN] Next step for RSN ? Date: Mon, 28 May 2007 07:42:46 -0400 To: Zach Shelby X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 28 May 2007 11:43:16.0333 (UTC) FILETIME=[6162B1D0:01C7A11D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10701; t=1180352608; x=1181216608; 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]=20Next=20step=20for=20RSN=20? |Sender:=20 |To:=20Zach=20Shelby=20; bh=WgpWFoxHy0UpbeAVrvhJPHFvT51Qfxdkot4M2416JJk=; b=K3pRAaPw28Ub2z10haMFu6IFIwA4g/t1EuAMY2eQaA90VlJ9fJhtYjm9C6Y9L+HKVpgzX6vR gWJY2THsBjCbZbJFtKXMt3an6Zaj+ldMiBuare89Ji6+IiLZTmR2l1o6; 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: cdb443e3957ca9b4c5b55e78cfcf4b26 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 Zach, Thanks for supporting the initiative. Few comments in line, On May 28, 2007, at 1:55 AM, Zach Shelby wrote: > Hi, > > I support the RSN effort and like the requirements-based approach. > A few comments on the lastest e-mail exchanges. > > - I like the minimum set of link-layer features approach suggested > by Philip. In addition optional features such as providing RSSI/ToA > could be listed as well. This should be added to the req ID? > > - Although RSN is independent of e.g. WiFi or 6lowpan mesh-under, > it should be aware of them, differentiated from them, and > compatible with them. I suggest that the interoperability with > these mesh-under techniques be made explicit in the RSN req ID. > This does not lock RSN into any particular L1/L2 technique, but > simply ensures interoperability. Unlike in Ethernet bridget > networks, where latencies are very minimal, a mesh-under subnet in > a low-speed wireless network will have very different properties > than a single hop. We should also be explicit to avoid confusion > with the 6lowpan work. Don't underestimate mesh-under, in the WiFi > world it is really what is being successfully deployed. > We should certainly get some minimalist level of abstraction from the L1/L2, which should be worked out in concert with 6lowpan: this has been a quite common approach in designing routing protocols as long as we do not introduce dependencies, as you pointed out. 1) Minimalist link layer abstraction: it would be perfectly fine indeed to provide some data link characteristics to the routing layer such as the reliability, propagation delays, bandwidth. Such parameter may themselves be a function of a sub-layer routing function or just the environmental conditions. Two comments though: first, we will of course need to ensure that such characteristics are relevant and limited (let's remember some proposals to provide dozens of link attributes in some GMPLS networks leading to NP-complete path computation issues). Second, they should not be "too" dynamic (need dampening) because of uncontrolled sub-layer "routing" function: loop control feed-back may be a very good source of oscillation (examples of this nature are notorious), especially in situation of sporadic traffic load. 2) Inter-layer routing dependencies: what we must avoid is a routing protocol that would compute paths based upon the decision of a mesh- under "routing" protocol. That would clear mean inter-layer dependency. > - Application specific variants of the routing protocol reqs is a > good idea. Thanks, your contribution will be welcome. So far two IDs are in the works: - Routing requirements for Home networking applications - Routing requirements for Industrial applications We would probably need another ID for Healthcare applications since there are specific requirements to such applications. Thanks. JP. > > Zach > > > JP Vasseur wrote: >> Dear List members, >> Looking at the number of people who registered to this list, there >> seems to be a strong interest in designing a Routing solution for >> Sensor Networks. David and I had during the last few months a >> number of off-line discussions with positive feed-back and >> support, it is now a good time to use the Mailing List to gauge >> whether there is a consensus on whether to work on this topic. >> David provided an excellent problem statement below. I'd like to >> add a few comments and get feed-back from the ML members on >> whether we collectively want to work on this item. >> With no doubt, we'll see many other radio networks emerging soon >> and sensor networks will soon be made links using various layer1/2 >> protocols defined by other SDOs: 802.15.4, Wifi, WiMax but also >> non wireless links. Such networks will also comprise sensor nodes >> with a wide range of capabilities, which makes the routing fairly >> unique in term of requirement. Thus 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). >> It looks fairly obvious that a network made of N "mesh-under" >> routing protocols is very unlikely to satisfy an end to end path >> constraint and would be fairly complex to manage and tune. We all >> remember the issue of IP routing over ATM PVCs routed by PNNI. >> Think of this with N "Mesh-under" routing protocols. That said, >> this is not to say that we exclude the use of "mesh-under" >> solutions, but we propose to define a IP-based routing protocol. >> What would be a charter proposal ? >> First we would need to spend a good amount of time on the routing >> requirements. David and I posted a first revision of a generic >> requirement draft (draft-culler-rsn-routing-reqs-00.txt); the next >> revision will soon be posted accounting for the comments received >> so far. I would propose to continue to list the generic >> requirements in this draft and have other application-specific >> routing requirements drafts discussed in other IDs: for home >> networking, industrial applications, ... Such approach has been >> successfully adopted in other WGs. >> The second step would consist of making a survey on the existing >> routing protocols and see whether (1) they could be used as such >> (2) they should be adapted (for instance, see whether AODV or OLR >> or RIP could be made energy efficient, could support some form of >> constrained based routing, ...) or (3) we should design a new >> generic new protocol. >> Note that we may not be able to satisfy all the requirements, and >> this might be perfectly acceptable and should be documented. >> Indeed, we all know that Sensor Networks may significantly differ >> in term of degree of mobility, link layer reliability/bandwidth, >> node constraints, ... A very good outcome of this work might be >> that the newly defined/adapted protocol could satisfy the >> requirement IDs A, B, D and E but not C. >> So please use this list to provide feed-back on whether you would >> support such initiative and if so your contribution is more than >> welcome. Note that several people already mentioned some interest >> and we do expect to see new IDs posted before Chicago. >> JP and David. >> Begin forwarded message: >>> From: "dculler" >>> Date: May 23, 2007 1:24:58 AM GMT+02:00 >>> To: >>> Subject: [RSN] Interest in the Interplay of "routing" and "meshing" >>> Reply-To: dculler@archrock.com >>> >>> Several of the comments on this list have touched on the issue of >>> different kinds of "multihop routing" in the context of sensor >>> networks. Is there interest in working on how these forms of >>> routing tie together? >>> >>> To make the question more grounded: Low power radios have >>> relatively short range. IEEE 802.15.4 radios are typically 1 mW >>> transmit power, vs 100 mW for 802.11, and have typical ranges in >>> 10s to 100 m. Generally speaking, the power required to >>> communicate a given distance by radio grows polynomially with >>> distance. In typical settings it grows like the cube, but it can >>> be much worse near the ground or somewhat better with directional >>> antennas. The cost to communicate hop-by-hop grows only >>> linearly, and it offers the potential to route around obstacles >>> and enhance reliability through "receiver diversity". >>> >>> The question is at what layer(s) in the stack this routing occurs >>> and how it relates to IP routing more generally. Most multihop >>> protocols in the sensor network research community are >>> effectively at layer2 - they form a single "patch" of homogeneous >>> media. Logically, they are a subnet, although few of the >>> protocols address what happens beyond the "patch" of sensor >>> nodes, other than that some of the nodes are "gateways". Current >>> industry standards, such as Zigbee, Zwave, and wirelessHART, are >>> also a "multihop link", leaving open the question of how nodes >>> within the sensor patch communicate with nodes outside. >>> >>> 6LoWPAN provides a compressed header format for "mesh routing", >>> meaning multihop forwarding of packets within the 802.15.4 link. >>> Such a link is assumed to be formed by a contiguously connected >>> set of 802.15.4 nodes. The presence of such "mesh routing" >>> capabilities does not eliminate the need for layer 3 routing. If >>> a 15.4 node communicates with a remote node, say an 802.11 node, >>> how is routing and forwarding carried out? If two "LoWPAN >>> subnets" [sic] happen to be connected by 15.4 nodes, how does >>> 15.4-to-15.4 routing occur? The 6LoWPAN header format is, of >>> course, a general solution for carrying IP over 802.15.4, so it >>> is able to express these other forms of routing, as well. In the >>> extreme case, each individual node is an IP link and all routing >>> is done at the IP layer. On the other hand, patches of nodes may >>> want to function as a logical subnet, even if the wireless >>> multihop routing is done at the IP layer. At this point, the >>> concerns overlap with those addressed in autoconf (cf., draft- >>> ietf-autoconf-manetarch-01). >>> >>> There is substantial commonality of concerns at the different >>> layers of multihop routing, but also differences. It is also >>> important to separate the process of forming a routing topology >>> from the process of forwarding packets. Both of which are >>> distinct (but not entirely independent of) how power management >>> (turning on/off the radios) is performed. >>> >>> >>> _______________________________________________ >>> 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 > > > -- > Zach Shelby | Managing Director | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > > _______________________________________________ > 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 May 28 07:55: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 1Hsdob-000316-46; Mon, 28 May 2007 07:55:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsdoZ-000311-So for rsn@ietf.org; Mon, 28 May 2007 07:55:07 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsdoZ-000360-9X for rsn@ietf.org; Mon, 28 May 2007 07:55:07 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 28 May 2007 07:55:07 -0400 X-IronPort-AV: i="4.14,586,1170651600"; d="scan'208"; a="122179424:sNHT56026558" 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 l4SBt6te006707; Mon, 28 May 2007 07:55:06 -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 l4SBt65f021453; Mon, 28 May 2007 11:55:06 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, 28 May 2007 07:55:06 -0400 Received: from [10.86.104.186] ([10.86.104.186]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 May 2007 07:54:59 -0400 In-Reply-To: <2a3692de0705280035s370f952co2ac00558ed024cfb@mail.gmail.com> References: <20070522232511.DD58016B0002@secure.archedrock.com> <2a3692de0705280035s370f952co2ac00558ed024cfb@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: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [RSN] Next step for RSN ? Date: Mon, 28 May 2007 07:54:29 -0400 To: Dominik Kaspar X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 28 May 2007 11:54:59.0430 (UTC) FILETIME=[0476C860:01C7A11F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10850; t=1180353306; x=1181217306; 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]=20Next=20step=20for=20RSN=20? |Sender:=20 |To:=20Dominik=20Kaspar=20; bh=seSo3wgeubFr7rBglOWqRJBZM1w13gXC7HshEqcF2vI=; b=aBISiptntkuag6Gf9zYHSXrHjlllBNRt9NaR08KKoSM4qmyVVaaWNShmvvCCnARsZaQyP03R zZpjKNhJ6oFqbTPqWTOaznidsFqdhC/z+6hVcCWy1lo5x1U03MEdWM18; 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: f60fbf3dbcaca652b6d10036f0630412 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 May 28, 2007, at 3:35 AM, Dominik Kaspar wrote: > Dear RSN List, > > In my opinion, RSN should focus more on one basic problem or a number > of orthogonal problems. Especially for sensor networks, there is no > substitute for simplicity. This very basic requirement has been called > "light footprint" in draft-culler-rsn-routing-reqs-00, but seems to > have gone forgotten. The requirement list suggests a multi-purpose RSN > protocol, which dynamically adapts to topology changes, intelligently > switches between end-to-end routing and data diffusion, supports > data-aware routing, topology-dependent QoS, ...etc. I question the > feasibility of meeting such a complex set of orthogonal requirements > for sensor networks. In order words, which ones of the current > requirements, can we sacrifice? This is a perfectly valid point, I can't agree more. This is why I wrote in a previous email: >> Note that we may not be able to satisfy all the requirements, and >> this might >> be perfectly acceptable and should be documented. Indeed, we all >> know that >> Sensor Networks may significantly differ in term of degree of >> mobility, link >> layer reliability/bandwidth, node constraints, ... A very good >> outcome of >> this work might be that the newly defined/adapted protocol could >> satisfy the >> requirement IDs A, B, D and E but not C. What makes Sensor Networks somehow unique is indeed the constrained nature of the nodes (and links somehow). This is why we proposed an applications-specific requirements approach. The idea being to design a protocol supporting a set of routing components that may not have to be simultaneously activated. A set of components (called a sub-system) could be defined for each application thus avoiding to specify a routing protocol supporting all of the requirements at once that would defeat the "light footprint" requirement. This is of course just an early stage proposal and we would need to collectively discuss once all the applications specific requirements will have been fleshed out. > > Also..., is it the goal of RSN to provide IP-based querying of a > single sensor node in an end-to-end paradigm? Or is it the goal of RSN > to allow querying a network as an entity? Is it the goal to allow > sensors send their data to a sink on certain events? Is it the goal to > allow sensor nodes address other remote sensor nodes, too? Is the the > goal of RSN to support all of this at the same time? > All good questions ... short answer is "to be discussed in the requirements IDs" but more than likely the routing protocol will have to support Multipoint to point, point to Multipoint and point to point. A good point of discussion will be to decide whether to optimize it for MP2P, P2MP, ... depending on the traffic pattern. This should be spelled out in the application specific ID. Makes sense ? > The answers would help me to see RSN more clearly. > Hope this helps. Suggestions very welcome of course. Thanks. JP. > Regards, > Dominik. > > > On 5/23/07, JP Vasseur wrote: >> Dear List members, >> >> Looking at the number of people who registered to this list, there >> seems to >> be a strong interest in designing a Routing solution for Sensor >> Networks. >> David and I had during the last few months a number of off-line >> discussions >> with positive feed-back and support, it is now a good time to use the >> Mailing List to gauge whether there is a consensus on whether to >> work on >> this topic. >> >> David provided an excellent problem statement below. I'd like to >> add a few >> comments and get feed-back from the ML members on whether we >> collectively >> want to work on this item. >> >> With no doubt, we'll see many other radio networks emerging soon >> and sensor >> networks will soon be made links using various layer1/2 protocols >> defined by >> other SDOs: 802.15.4, Wifi, WiMax but also non wireless links. >> Such networks >> will also comprise sensor nodes with a wide range of capabilities, >> which >> makes the routing fairly unique in term of requirement. Thus 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). >> >> It looks fairly obvious that a network made of N "mesh-under" routing >> protocols is very unlikely to satisfy an end to end path >> constraint and >> would be fairly complex to manage and tune. We all remember the >> issue of IP >> routing over ATM PVCs routed by PNNI. Think of this with N "Mesh- >> under" >> routing protocols. That said, this is not to say that we exclude >> the use of >> "mesh-under" solutions, but we propose to define a IP-based routing >> protocol. >> >> What would be a charter proposal ? >> >> First we would need to spend a good amount of time on the routing >> requirements. David and I posted a first revision of a generic >> requirement >> draft (draft-culler-rsn-routing-reqs-00.txt); the next >> revision will soon be posted accounting for the comments received >> so far. I >> would propose to continue to list the generic requirements in this >> draft and >> have other application-specific routing requirements drafts >> discussed in >> other IDs: for home networking, industrial applications, ... Such >> approach >> has been successfully adopted in other WGs. >> >> The second step would consist of making a survey on the existing >> routing >> protocols and see whether (1) they could be used as such (2) they >> should be >> adapted (for instance, see whether AODV or OLR or RIP could be >> made energy >> efficient, could support some form of constrained based >> routing, ...) or (3) >> we should design a new generic new protocol. >> >> Note that we may not be able to satisfy all the requirements, and >> this might >> be perfectly acceptable and should be documented. Indeed, we all >> know that >> Sensor Networks may significantly differ in term of degree of >> mobility, link >> layer reliability/bandwidth, node constraints, ... A very good >> outcome of >> this work might be that the newly defined/adapted protocol could >> satisfy the >> requirement IDs A, B, D and E but not C. >> >> So please use this list to provide feed-back on whether you would >> support >> such initiative and if so your contribution is more than welcome. >> Note that >> several people already mentioned some interest and we do expect to >> see new >> IDs posted before Chicago. >> >> JP and David. >> >> Begin forwarded message: >> >> From: "dculler" >> Date: May 23, 2007 1:24:58 AM GMT+02:00 >> To: >> Subject: [RSN] Interest in the Interplay of "routing" and "meshing" >> Reply-To: dculler@archrock.com >> >> Several of the comments on this list have touched on the issue of >> different >> kinds of "multihop routing" in the context of sensor networks. Is >> there >> interest in working on how these forms of routing tie together? >> >> To make the question more grounded: Low power radios have >> relatively short >> range. IEEE 802.15.4 radios are typically 1 mW transmit power, vs >> 100 mW >> for 802.11, and have typical ranges in 10s to 100 m. Generally >> speaking, >> the power required to communicate a given distance by radio grows >> polynomially with distance. In typical settings it grows like the >> cube, but >> it can be much worse near the ground or somewhat better with >> directional >> antennas. The cost to communicate hop-by-hop grows only linearly, >> and it >> offers the potential to route around obstacles and enhance >> reliability >> through "receiver diversity". >> >> The question is at what layer(s) in the stack this routing occurs >> and how it >> relates to IP routing more generally. Most multihop protocols in >> the sensor >> network research community are effectively at layer2 - they form a >> single >> "patch" of homogeneous media. Logically, they are a subnet, >> although few of >> the protocols address what happens beyond the "patch" of sensor >> nodes, other >> than that some of the nodes are "gateways". Current industry >> standards, >> such as Zigbee, Zwave, and wirelessHART, are also a "multihop >> link", leaving >> open the question of how nodes within the sensor patch communicate >> with >> nodes outside. >> >> 6LoWPAN provides a compressed header format for "mesh routing", >> meaning >> multihop forwarding of packets within the 802.15.4 link. Such a >> link is >> assumed to be formed by a contiguously connected set of 802.15.4 >> nodes. The >> presence of such "mesh routing" capabilities does not eliminate >> the need for >> layer 3 routing. If a 15.4 node communicates with a remote node, >> say an >> 802.11 node, how is routing and forwarding carried out? If two >> "LoWPAN >> subnets" [sic] happen to be connected by 15.4 nodes, how does 15.4- >> to-15.4 >> routing occur? The 6LoWPAN header format is, of course, a general >> solution >> for carrying IP over 802.15.4, so it is able to express these >> other forms of >> routing, as well. In the extreme case, each individual node is an >> IP link >> and all routing is done at the IP layer. On the other hand, >> patches of >> nodes may want to function as a logical subnet, even if the wireless >> multihop routing is done at the IP layer. At this point, the >> concerns >> overlap with those addressed in autoconf (cf., >> draft-ietf-autoconf-manetarch-01). >> >> There is substantial commonality of concerns at the different >> layers of >> multihop routing, but also differences. It is also important to >> separate >> the process of forming a routing topology from the process of >> forwarding >> packets. Both of which are distinct (but not entirely independent >> of) how >> power management (turning on/off the radios) is performed. >> >> >> _______________________________________________ >> 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 _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Mon May 28 10:31:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsgG6-0006FQ-0v; Mon, 28 May 2007 10:31:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsgFy-00064z-2E for RSN@ietf.org; Mon, 28 May 2007 10:31:34 -0400 Received: from criges14.insa-lyon.fr ([134.214.76.242] helo=smtp.insa-lyon.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsgFw-0007zf-Gr for RSN@ietf.org; Mon, 28 May 2007 10:31:34 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp.insa-lyon.fr (Postfix) with ESMTP id B2A1FF3181 for ; Mon, 28 May 2007 16:31:29 +0200 (CEST) X-Virus-Scanned: SMTP at INSA-LYON Received: from smtp.insa-lyon.fr ([127.0.0.1]) by localhost (criges14.insa-lyon.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGWOLBDAvMK2 for ; Mon, 28 May 2007 16:31:28 +0200 (CEST) Received: from [132.207.169.229] (unknown [132.207.169.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fvalois) by smtp.insa-lyon.fr (Postfix) with ESMTP id 8C406F3134 for ; Mon, 28 May 2007 16:31:28 +0200 (CEST) Message-ID: <465AE7C6.1050903@insa-lyon.fr> Date: Mon, 28 May 2007 10:31:34 -0400 From: Fabrice Valois User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: RSN@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Subject: [RSN] WiMob'07: Special Session on Mobility Models -- EXTENDED DEALINE: June 6, 2007 -- 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 (*** NEW EXTENDED DEADLINE ***) (*** MANUSCRIPT SUBMISSION DUE: June 6, 2007 ***) CFP for IEEE WiMOB=922007 Special Session on Mobility Models for Mobile Ad hoc Networks, Mesh networks, Wireless networks and NEMO networks The session is a part of the 3rd IEEE International Conference on Wireless and Mobile Computing, Networking and Communications =93WiMob 2007=94 Accepted papers will be published as regular paper in the proceedings of WiMob 2007 and will be available in IEEE Xplore. http://www.gel.usherbrooke.ca/WiMob2007/, which will take place in Crowne Plaza Hotel, White Plains, New York, USA, from October 8-10, 2007. Motivations: Because WiMob'07 conference is focused on wireless networks and because the performances of wireless networks are strongly linked to the mobility models used, we propose a special session focusing only on mobility models. This session is focused on these kind of wireless networks: - MANET: Mobile ad hoc networks where whole the topology is dynamic - Mesh networks and classical wireless networks offering an infrastructure topologies allowing fixed and mobile Internet for the end user. - Network Mobility (NEMO) networks offering new kind of dynamic topology where not only the user is mobile but also the network These kind of networks should deal with mobility: user mobility, group mobility, etc. But, what is really mobility? how mobility influences the performances? how to define new mobility models? etc. Scope of the Contributions for Mobility Models in the case of MANET, Mesh Networks, Wireless Networks and NEMO (include but are not limited to the following): - Performance evaluation of mobility models - New mobility models to mimic particular behavior - Theoretical aspects of mobility models - Theoretical frameworks for mobility - Mobility models based on realistic traces - Mobility management - Networking protocols and mobility models - Tools for mobility models (generators, integrators to simulators,..) - etc. Authors are invited to submit a complete technical paper of their original work. Maximum length for submissions is 8 double column pages in IEEE format. The preferred submission format is PDF. Session Chair: Fabrice Valois, INSA Lyon, France Session Co-chair: Thomas Noel, University of Strasbourg, France Submissions should be sent attached by email to the session chairs at: fabrice.valois@insa-lyon.fr Thomas.Noel@dpt-info.u-strasbg.fr Important Dates : Manuscript Submission Due: June 6, 2007 Acceptance Notification: June 15, 2007 Final Manuscript Due: June 22, 2007 --=20 Fabrice Valois, Associate Professor INRIA ARES / CITI - INSA Lyon, Telecommunications Dpt. Web: http://fvalois.insa-lyon.fr/ _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Mon May 28 12:07: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 1HshkO-0001Lh-L6; Mon, 28 May 2007 12:07:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HshkN-0001LU-0X for rsn@ietf.org; Mon, 28 May 2007 12:07:03 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HshkK-0008S6-G9 for rsn@ietf.org; Mon, 28 May 2007 12:07:02 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1180368419!261985!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 17224 invoked from network); 28 May 2007 16:06:59 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-128.messagelabs.com with SMTP; 28 May 2007 16:06:59 -0000 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4SG6w3O014503; Mon, 28 May 2007 09:06:59 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l4SG6wQr025548; Mon, 28 May 2007 11:06:58 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l4SG6ubP025504; Mon, 28 May 2007 11:06:56 -0500 (CDT) Message-ID: <465AFE1A.1090801@gmail.com> Date: Mon, 28 May 2007 18:06:50 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: JP Vasseur Subject: Re: [RSN] Next step for RSN ? References: <20070522232511.DD58016B0002@secure.archedrock.com> <4655A261.2010304@gmail.com> <1EE4DA4A-F4EF-4192-9A99-E56C1F5D5D31@cisco.com> In-Reply-To: <1EE4DA4A-F4EF-4192-9A99-E56C1F5D5D31@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000744-1, 27/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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 Vasseur wrote: [...] > 2) When you look at the routing protocols in used in the Internet > (IGP), they are not designed/optimized for networks with low > bandwidth links, unreliable links and highly constraints nodes, Err... not sure about this. Years ago I saw RIP over a 9600bps rs232 dialup, a link that I'd qualify as low bandwidth. Highly-constrained nodes? I think there exist very small footprint TCP/IP implementations, unmodified protocols. http://www.sics.se/~adam/uip/size.html I think in general a high-performance software implementation doesn't need to change a protocol. > the last aspects being key here since the computed path (SPT) does > not taken into account the node characteristics (other than potential > node pruning using node cap). There are networks with heterogenous > devices indeed but the path is not a function of the nodes but the > links using Dijkstra. This leads to defining IP *constrained based > routing* while addressing the requirements of unreliable and dynamic > topologies due to mobility and unstable links or nodes. Again the > notion of constrained based routing (that has been designed in other > contexts (MPLS)) differs from existing IGPs. > > Other requirements such as QoS aware routing, MTR, ... have been > defined for other IGPs but would very likely require a different > solutions here because of node constraints. > > This is particularly unique to Sensor Networks. So your analogy does > not hold at all here. > You're missing the point here of networks made of a variety of links > of different natures, thus my comments to provide a routing solution > offering an end to end constrained path (this is not the only > requirement): this is clearly extremely challenging without a IP > routing solution independent of the link layer. I think I agree with the heterogeneity of wireless link types being accommodated by IP. >>> but also *non wireless links*. >> >> Which ones? I think that the smallest wired network interfaces and >> connections are Ethernet and probably USB. > > You can perfectly have a Sensor Networks made of RF links and wired > links. Yes, I agree with this too. What I wanted to say is to mention the wired link names. Probably Ethernet and USB. Probably RS232 as well. Not any other. > See my previous comment: No we cannot make the assumption that AODV > or OLSR will be the protocol to use. It MAY be an excellent solution > with adaptations though. This is why the proposal is indeed to have > a place where we could make a clear analysis of the requirements and > come up with a solution, which again could be based on Manemo, AODV, > ... or a new routing protocol. There is NO reason to define a new > protocol if not needed and we do not want at the IETF to invent > protocols when not required. On the other hand, it is certainly a bad > idea to state a priori that a protocol X should be used or could be > used with several extensions if this is not the correct long term > approach. We could mention many examples where using an existing > protocol and adapt it to meet new requirements was indeed the right > solution but there are also a number of example where we had to live > with poorly engineered solutions, thus the proposed approach. > > Does that clarify the approach ? It sounds to me like an argument trying to persuade. >>> Note that we may not be able to satisfy all the requirements, and >>> this might be perfectly acceptable and should be documented. >>> Indeed, we all know that Sensor Networks may significantly differ >>> in term of degree of mobility, >> >> Mobility? I think sensor networks once deployed are not mobile at >> all. Neither do they move homogeneously as a group (with respect >> to Earth), nor do they move with respect to each-other. > > Ah no life is not so simple ;-) ... As pointed out, there are many > types of sensor networks. Some of them are completely static indeed > but there are also many sensor networks where nodes are mobile with > various degree of mobility. Just to mention two examples (among many > other ones): healthcare with wearable sensors (see the SMART project > as one example of deployed network), vehicular, Wearable sensor networks and vehicular networks are very similar conceptually. They pose two problems: (1) run IP on the sensor and (2) use Mobile IP to manage mobility of the whole; by "whole" I mean the PAN or the vehicle. For running an IP stack on the sensor itself we can talk about constraints (memory, speed, communication). But at the same time one very easily questions the unreliability of running TCP/IP on the sensor. I'm saying this after seeing deployed Car Area Networks (with sensors) and Personal Area Networks, where the necessity of running IP on the sensors is not felt, even sometimes discouraged. It's like the more the sensor is constrained the less chances are that it runs IP. For using Mobile IP to manage the mobility of the whole network (the VAN Vehicular Area Network or the PAN) one would look and reuse the Network Mobility work (in the NEMO WG). > industrial (with sensor on containers, I think currently sensor on containers seem to me more like RFIDs, with no power supply. I don't think TCP/IP can run on a device that doesn't have power supply. > moving machines, ...), ... Which ones? > Now here is one of our challenges: since there are so many potential > deployment cases, you could indeed come up with a superset of all > requirements and more than likely there won't be any protocols that > would meet all of them, especially if designed for constrained nodes. > So we would have to identify a core set of requirements, specify the > solution and potentially document that this protocol would not be > used for some applications (e.g DTN sensor nets, ... might be > challenging). This is a perfectly fine approach. This sounds like procedure, looks good. [snipped some parts]... Thanks, Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Mon May 28 12:27:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsi3n-00025v-Mu; Mon, 28 May 2007 12:27:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsi3m-00025q-W7 for rsn@ietf.org; Mon, 28 May 2007 12:27:06 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hsi3l-0002sN-FJ for rsn@ietf.org; Mon, 28 May 2007 12:27:06 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 28 May 2007 12:26:33 -0400 X-IronPort-AV: i="4.14,587,1170651600"; d="scan'208"; a="122188222:sNHT87563004914" 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 l4SGQUSN028427; Mon, 28 May 2007 12:26: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 l4SGQT5f001925; Mon, 28 May 2007 16:26:29 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); Mon, 28 May 2007 12:26:29 -0400 Received: from [10.86.104.186] ([10.86.104.186]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 May 2007 12:26:14 -0400 In-Reply-To: <465AFE1A.1090801@gmail.com> References: <20070522232511.DD58016B0002@secure.archedrock.com> <4655A261.2010304@gmail.com> <1EE4DA4A-F4EF-4192-9A99-E56C1F5D5D31@cisco.com> <465AFE1A.1090801@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [RSN] Next step for RSN ? Date: Mon, 28 May 2007 12:25:53 -0400 To: Alexandru Petrescu X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 28 May 2007 16:26:14.0987 (UTC) FILETIME=[E973B1B0:01C7A144] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7841; t=1180369590; x=1181233590; 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]=20Next=20step=20for=20RSN=20? |Sender:=20 |To:=20Alexandru=20Petrescu=20; bh=8K7akUQrAOLaGP/4zA8jGn8IMXYSfKdQbZnr5hFplcI=; b=ddsnwaEkzJ4X3Ldlos5tD7wZ88hjbFmLIT/wilRYK5kpq6UCkt/kxq+h/4MLYKM0cc9jhox8 Iiw6IJ4fbpKN7ZTzQglcBdcZxAF3G7mjbtDbnZdHQkyswRXykJtdr1C+; 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: 88b11fc64c1bfdb4425294ef5374ca07 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 Alex, Starting with your conclusion "This sounds like procedure, looks good.", it sounds like we are in sync with the approach. See in line for few comments though. On May 28, 2007, at 12:06 PM, Alexandru Petrescu wrote: > JP Vasseur wrote: > [...] >> 2) When you look at the routing protocols in used in the Internet >> (IGP), they are not designed/optimized for networks with low >> bandwidth links, unreliable links and highly constraints nodes, > > Err... not sure about this. > > Years ago I saw RIP over a 9600bps rs232 dialup, a link that I'd > qualify > as low bandwidth. Yes this is why we designed triggered RIP + many other optimizations, ... By the way, RIP is not exactly running in the Internet as an IGP ;-) > > Highly-constrained nodes? Yes none of the IGP like OSPF/ISIS takes into account the node capability when computing the path (other than exclude from SPT). > I think there exist very small footprint > TCP/IP implementations, unmodified protocols. > http://www.sics.se/~adam/uip/size.html > > I think in general a high-performance software implementation doesn't > need to change a protocol. That's an entirely different question. Here when we are referring to taking into account link and node characteristics, we refer to the path computation. > >> the last aspects being key here since the computed path (SPT) does >> not taken into account the node characteristics (other than potential >> node pruning using node cap). There are networks with >> heterogenous devices indeed but the path is not a function of the >> nodes but the links using Dijkstra. This leads to defining IP >> *constrained based routing* while addressing the requirements of >> unreliable and dynamic >> topologies due to mobility and unstable links or nodes. Again the >> notion of constrained based routing (that has been designed in other >> contexts (MPLS)) differs from existing IGPs. >> Other requirements such as QoS aware routing, MTR, ... have been >> defined for other IGPs but would very likely require a different >> solutions here because of node constraints. >> This is particularly unique to Sensor Networks. So your analogy does >> not hold at all here. > > >> You're missing the point here of networks made of a variety of links >> of different natures, thus my comments to provide a routing solution >> offering an end to end constrained path (this is not the only >> requirement): this is clearly extremely challenging without a IP >> routing solution independent of the link layer. > > I think I agree with the heterogeneity of wireless link types being > accommodated by IP. OK. > >>>> but also *non wireless links*. >>> Which ones? I think that the smallest wired network interfaces and >>> connections are Ethernet and probably USB. >> You can perfectly have a Sensor Networks made of RF links and >> wired links. > > Yes, I agree with this too. Good. > What I wanted to say is to mention the > wired link names. Probably Ethernet and USB. Probably RS232 as well. > Not any other. > >> See my previous comment: No we cannot make the assumption that >> AODV or OLSR will be the protocol to use. It MAY be an excellent >> solution >> with adaptations though. This is why the proposal is indeed to have >> a place where we could make a clear analysis of the requirements and >> come up with a solution, which again could be based on Manemo, AODV, >> ... or a new routing protocol. There is NO reason to define a new >> protocol if not needed and we do not want at the IETF to invent >> protocols when not required. On the other hand, it is certainly a bad >> idea to state a priori that a protocol X should be used or could be >> used with several extensions if this is not the correct long term >> approach. We could mention many examples where using an existing >> protocol and adapt it to meet new requirements was indeed the >> right solution but there are also a number of example where we had >> to live >> with poorly engineered solutions, thus the proposed approach. >> Does that clarify the approach ? > > It sounds to me like an argument trying to persuade. > >>>> Note that we may not be able to satisfy all the requirements, and >>>> this might be perfectly acceptable and should be documented. >>>> Indeed, we all know that Sensor Networks may significantly differ >>>> in term of degree of mobility, >>> Mobility? I think sensor networks once deployed are not mobile at >>> all. Neither do they move homogeneously as a group (with respect >>> to Earth), nor do they move with respect to each-other. >> Ah no life is not so simple ;-) ... As pointed out, there are many >> types of sensor networks. Some of them are completely static >> indeed but there are also many sensor networks where nodes are >> mobile with various degree of mobility. Just to mention two >> examples (among many other ones): healthcare with wearable sensors >> (see the SMART project as one example of deployed network), >> vehicular, > > Wearable sensor networks and vehicular networks are very similar > conceptually. And there are mobile nodes. ** Here starts a discussion that belongs to 6lowpan ** > They pose two problems: (1) run IP on the sensor and (2) > use Mobile IP to manage mobility of the whole; by "whole" I mean > the PAN > or the vehicle. > > For running an IP stack on the sensor itself we can talk about > constraints (memory, speed, communication). But at the same time one > very easily questions the unreliability of running TCP/IP on the > sensor. > I'm saying this after seeing deployed Car Area Networks (with > sensors) > and Personal Area Networks, where the necessity of running IP on the > sensors is not felt, even sometimes discouraged. > > It's like the more the sensor is constrained the less chances are that > it runs IP. This is highly debatable, I do think that running IP on a Sensor is completely feasible and has been demonstrated in many circumstances; note that this discussion belongs more to 6lowpan though. > > For using Mobile IP to manage the mobility of the whole network > (the VAN > Vehicular Area Network or the PAN) one would look and reuse the > Network > Mobility work (in the NEMO WG). > >> industrial (with sensor on containers, > > I think currently sensor on containers seem to me more like RFIDs, > with > no power supply. I don't think TCP/IP can run on a device that > doesn't > have power supply. Why ? There are many sensors for pressure for example that are battery powered used on mobile machines. > >> moving machines, ...), ... > > Which ones? > >> Now here is one of our challenges: since there are so many potential >> deployment cases, you could indeed come up with a superset of all >> requirements and more than likely there won't be any protocols >> that would meet all of them, especially if designed for >> constrained nodes. >> So we would have to identify a core set of requirements, specify the >> solution and potentially document that this protocol would not be >> used for some applications (e.g DTN sensor nets, ... might be >> challenging). This is a perfectly fine approach. > > This sounds like procedure, looks good. > Glad that we converged. Thanks. JP. > [snipped some parts]... > > Thanks, > > Alex > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Mon May 28 15:26:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HskrB-0005Mg-Iq; Mon, 28 May 2007 15:26:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HskrA-0005Mb-2n for rsn@ietf.org; Mon, 28 May 2007 15:26:16 -0400 Received: from cs-smtp-3.stanford.edu ([171.64.64.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hskr9-0005NK-PO for rsn@ietf.org; Mon, 28 May 2007 15:26:16 -0400 Received: from c-71-198-71-178.hsd1.ca.comcast.net ([71.198.71.178] helo=[192.168.2.100]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Hskr6-00062L-DJ; Mon, 28 May 2007 12:26:14 -0700 In-Reply-To: <465A6EBF.70600@sensinode.com> References: <20070522232511.DD58016B0002@secure.archedrock.com> <465A6EBF.70600@sensinode.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [RSN] Next step for RSN ? Date: Mon, 28 May 2007 12:26:10 -0700 To: Zach Shelby X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-3.Stanford.EDU X-Scan-Signature: 3acef658708772c1d00935e7d4d752c5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 May 27, 2007, at 10:55 PM, Zach Shelby wrote: > Hi, > > I support the RSN effort and like the requirements-based approach. > A few comments on the lastest e-mail exchanges. > > - I like the minimum set of link-layer features approach suggested > by Philip. In addition optional features such as providing RSSI/ToA > could be listed as well. This should be added to the req ID? RSSI is a tricky one; most radio hardware provides it, but by itself RSSI is useless. What really matters is the SNR. If you can't determine the N, then there are cases when RSSI breaks down (hardware noise floor is not uniform, and there are analog interference sources out there). Furthermore, multipath inter-symbol interference can cause high RSSI links to have a low SNR and so a low packet reception rate. In the cause of short range and low bandwidth radios, this isn't a big deal, as symbols won't overlap much, but who knows what future hardware will be like? 802.15.4 tried to deal with this by specifying LQI, but the specification is so vague it's hard to really depend on it. ToA is a common need. In the case of the features I mentioned, ToA wasn't at all important for the protocol, so it wasn't there. The big question is how ToA is specified. The primitive you generally find is ToA specified in terms of a node's local time base. This is inexpensive to provide and doesn't require any protocols, synchronization, or other implied services. At the very least, this enables reference broadcast synchronization. If a transmitter can embed a transmission timestamp in an outgoing packet and timestamps are on byte and not packet fidelity, then simple linear regression can often get you tens of microsecond accuracy without too much complexity. Phil _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue May 29 04:45: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 1HsxKV-0005w9-OW; Tue, 29 May 2007 04:45:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsxKU-0005w1-Sk for rsn@ietf.org; Tue, 29 May 2007 04:45:22 -0400 Received: from auth-smtp.nebula.fi ([217.30.180.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsxKT-0001JC-3p for rsn@ietf.org; Tue, 29 May 2007 04:45:22 -0400 Received: from s-cwc-pc199.local (addr-213-139-165-97.baananet.fi [213.139.165.97]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id l4T8HOwS023891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 29 May 2007 11:17:24 +0300 Message-ID: <465BE818.2020909@sensinode.com> Date: Tue, 29 May 2007 11:45:12 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: rsn@ietf.org Subject: Re: [RSN] Next step for RSN ? References: <20070522232511.DD58016B0002@secure.archedrock.com> <465A6EBF.70600@sensinode.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 Phil, Comments in-line: Philip Levis wrote: >> >> - I like the minimum set of link-layer features approach suggested by >> Philip. In addition optional features such as providing RSSI/ToA could >> be listed as well. This should be added to the req ID? > > RSSI is a tricky one; most radio hardware provides it, but by itself > RSSI is useless. What really matters is the SNR. If you can't determine > the N, then there are cases when RSSI breaks down (hardware noise floor > is not uniform, and there are analog interference sources out there). > Furthermore, multipath inter-symbol interference can cause high RSSI > links to have a low SNR and so a low packet reception rate. In the cause > of short range and low bandwidth radios, this isn't a big deal, as > symbols won't overlap much, but who knows what future hardware will be > like? 802.15.4 tried to deal with this by specifying LQI, but the > specification is so vague it's hard to really depend on it. Agreed, it is useful on current 2.4 GHz 802.15.4 hardware as a very rough indicator, no more. > ToA is a common need. In the case of the features I mentioned, ToA > wasn't at all important for the protocol, so it wasn't there. The big > question is how ToA is specified. The primitive you generally find is > ToA specified in terms of a node's local time base. This is inexpensive > to provide and doesn't require any protocols, synchronization, or other > implied services. At the very least, this enables reference broadcast > synchronization. If a transmitter can embed a transmission timestamp in > an outgoing packet and timestamps are on byte and not packet fidelity, > then simple linear regression can often get you tens of microsecond > accuracy without too much complexity. I have been involved with 802.15.4a ultra-wideband and chirp efforts for years, and see them having bright potential. By ToA I do not mean the raw ToA calculation, but the resulting distance in m calculated from that with some confidence metric. E.g. in 802.l5.4a chirp spread spectrum, the current SoA technique uses a round-trip calculation between two nodes, accuracy at least 1 m. UWB can achieve the same round-trip with an accuracy of a few cm. I have a demo running in the lab with that UWB accuracy, pretty cool I must say (running on Time-Domain hardware). That being, maybe the metric available to routing should be simply the last measured distance to the neighbor with a confidence metric attached? This would generalize RSSI and ToA. Of course RSSI would have a horrible confidence, and ToA quite a good one. This issue is to be left to later RSN work, so let's not get stuck on it now... > Phil -- Zach Shelby | Managing Director | +358 40 7796297 Sensinode Ltd. www.sensinode.com _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue May 29 11:04: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 1Ht3FG-0005eY-4A; Tue, 29 May 2007 11:04:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht3FF-0005eJ-4W for rsn@ietf.org; Tue, 29 May 2007 11:04:21 -0400 Received: from web37004.mail.mud.yahoo.com ([209.191.85.89]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ht3FD-0007bl-RZ for rsn@ietf.org; Tue, 29 May 2007 11:04:21 -0400 Received: (qmail 32383 invoked by uid 60001); 29 May 2007 15:04:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=qxYTrjPm19NWMjqQgfy3XOHXEUzWI3CBz7vbr+pEM1Evredhg7j6QRl/YQSl0bkjA5BsE5HF7ZQaM5QY/v1YeRzy8FAe0tR0y7xNjWtbsooXZImdEQ34OhvIOLSrkEhH8uk0FOyStxMm1I8MyWydO2lsu6qg4AsMSJRF7yHhlZc=; X-YMail-OSG: Wysty8oVM1lH1R6AkxJd5f7k1JTD1FakCB7Lnxhl Received: from [71.180.92.14] by web37004.mail.mud.yahoo.com via HTTP; Tue, 29 May 2007 08:04:18 PDT Date: Tue, 29 May 2007 08:04:18 -0700 (PDT) From: Ken Peirce To: rsn@ietf.org In-Reply-To: MIME-Version: 1.0 Message-ID: <173404.32340.qm@web37004.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [RSN] Next step for RSN ? 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="===============1737606525==" Errors-To: rsn-bounces@ietf.org --===============1737606525== Content-Type: multipart/alternative; boundary="0-858616383-1180451058=:32340" Content-Transfer-Encoding: 8bit --0-858616383-1180451058=:32340 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit It is exciting to see the vision process unfold for RSN. I see a lot of very good talk about using SNR, RSSI and other radio performance metrics. While it is certain that many sensors will have radios like 802.15.4, I would like to note that sensors can have much more simple radios that do not keep such detailed radio information. It takes power to compute and store radio statistics(state). Has the RSN group determined that the PHY/MAC layers will have some minimum level of functionality? Are there classes of RSNs? I am not trying to complicate things, just trying to understand the scope of what consitutes an RSN radio or MAC/PHY link. Cheers, Ken Peirce --0-858616383-1180451058=:32340 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit It is exciting to see the vision process unfold for RSN. I see a lot of very good talk about using SNR, RSSI and other radio performance metrics. While it is certain that many sensors will have radios like 802.15.4, I would like to note that sensors can have much more simple radios that do not keep such detailed radio information. It takes power to compute and store radio statistics(state).  Has the RSN group determined that the PHY/MAC layers will have some minimum level of functionality? Are there classes of RSNs? I am not trying to complicate things, just trying to understand the scope of what consitutes an RSN radio or MAC/PHY link.
Cheers,
Ken Peirce

--0-858616383-1180451058=:32340-- --===============1737606525== 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 --===============1737606525==-- From rsn-bounces@ietf.org Tue May 29 14:32: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 1Ht6UK-00055Q-Rb; Tue, 29 May 2007 14:32:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht6UJ-00055L-Lx for rsn@ietf.org; Tue, 29 May 2007 14:32:07 -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 1Ht6UI-0006CL-1C for rsn@ietf.org; Tue, 29 May 2007 14:32:07 -0400 Received: by secure.archedrock.com (Postfix, from userid 101) id 376DA16B0003; Tue, 29 May 2007 11:32:05 -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=-101.0 required=5.0 tests=AWL,BAYES_00, MSGID_FROM_MTA_ID,USER_IN_WHITELIST 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 08AB316B0001; Tue, 29 May 2007 11:32:04 -0700 (PDT) From: "dculler" To: "'Dominik Kaspar'" , Subject: RE: [RSN] Next step for RSN ? Date: Tue, 29 May 2007 11:31:46 -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 In-Reply-To: <2a3692de0705280035s370f952co2ac00558ed024cfb@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Aceg+tF5+AAQTN9FTtuMAKswhcnWEgBIxR+Q Message-Id: <20070529183204.08AB316B0001@secure.archedrock.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: 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 Dominik, I agree that prioritizing the suite of requirements and focusing on a small set is critical to rapid progress. "Light footprint" is a very useful one because it provides a sharp distinction in the scaling characteristics of alternative algorithms. (Of course, in practice we utilize many techniques to enhance the scaling properties of a variety of protocols, but it is good to understand the inherent scaling characteristics that we are beginning with.) The available memory footprint correlates with issues of power consumption and cost. It causes us to attend to issues of neighbor table size, routing table size, route summarization, and even estimators - and yet it is independent of the particular link technology. The second issue that I believe provides very strong guidance is the traffic characteristics or workload. That provides useful guidance on the "offered load" under which we should evaluate the different alternatives. In general, the load for monitoring and instrumentation is quite different from many of the traditionally dominant use characteristics, such as TTY, file transfer, email, browsing, voice. So perhaps we should identify the top three that do a fairly good job of "spanning the space" and then look at the other factors in the refinement stages. David -----Original Message----- From: Dominik Kaspar [mailto:dokaspar.ietf@gmail.com] Sent: Monday, May 28, 2007 12:36 AM To: rsn@ietf.org Subject: Re: [RSN] Next step for RSN ? Dear RSN List, In my opinion, RSN should focus more on one basic problem or a number of orthogonal problems. Especially for sensor networks, there is no substitute for simplicity. This very basic requirement has been called "light footprint" in draft-culler-rsn-routing-reqs-00, but seems to have gone forgotten. The requirement list suggests a multi-purpose RSN protocol, which dynamically adapts to topology changes, intelligently switches between end-to-end routing and data diffusion, supports data-aware routing, topology-dependent QoS, ...etc. I question the feasibility of meeting such a complex set of orthogonal requirements for sensor networks. In order words, which ones of the current requirements, can we sacrifice? Also..., is it the goal of RSN to provide IP-based querying of a single sensor node in an end-to-end paradigm? Or is it the goal of RSN to allow querying a network as an entity? Is it the goal to allow sensors send their data to a sink on certain events? Is it the goal to allow sensor nodes address other remote sensor nodes, too? Is the the goal of RSN to support all of this at the same time? The answers would help me to see RSN more clearly. Regards, Dominik. On 5/23/07, JP Vasseur wrote: > Dear List members, > > Looking at the number of people who registered to this list, there > seems to be a strong interest in designing a Routing solution for Sensor Networks. > David and I had during the last few months a number of off-line > discussions with positive feed-back and support, it is now a good time > to use the Mailing List to gauge whether there is a consensus on > whether to work on this topic. > > David provided an excellent problem statement below. I'd like to add a > few comments and get feed-back from the ML members on whether we > collectively want to work on this item. > > With no doubt, we'll see many other radio networks emerging soon and > sensor networks will soon be made links using various layer1/2 > protocols defined by other SDOs: 802.15.4, Wifi, WiMax but also non > wireless links. Such networks will also comprise sensor nodes with a > wide range of capabilities, which makes the routing fairly unique in > term of requirement. Thus 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). > > It looks fairly obvious that a network made of N "mesh-under" routing > protocols is very unlikely to satisfy an end to end path constraint > and would be fairly complex to manage and tune. We all remember the > issue of IP routing over ATM PVCs routed by PNNI. Think of this with N "Mesh-under" > routing protocols. That said, this is not to say that we exclude the > use of "mesh-under" solutions, but we propose to define a IP-based > routing protocol. > > What would be a charter proposal ? > > First we would need to spend a good amount of time on the routing > requirements. David and I posted a first revision of a generic > requirement draft (draft-culler-rsn-routing-reqs-00.txt); the next > revision will soon be posted accounting for the comments received so > far. I would propose to continue to list the generic requirements in > this draft and have other application-specific routing requirements > drafts discussed in other IDs: for home networking, industrial > applications, ... Such approach has been successfully adopted in other WGs. > > The second step would consist of making a survey on the existing > routing protocols and see whether (1) they could be used as such (2) > they should be adapted (for instance, see whether AODV or OLR or RIP > could be made energy efficient, could support some form of constrained > based routing, ...) or (3) we should design a new generic new protocol. > > Note that we may not be able to satisfy all the requirements, and this > might be perfectly acceptable and should be documented. Indeed, we all > know that Sensor Networks may significantly differ in term of degree > of mobility, link layer reliability/bandwidth, node constraints, ... A > very good outcome of this work might be that the newly defined/adapted > protocol could satisfy the requirement IDs A, B, D and E but not C. > > So please use this list to provide feed-back on whether you would > support such initiative and if so your contribution is more than > welcome. Note that several people already mentioned some interest and > we do expect to see new IDs posted before Chicago. > > JP and David. > > Begin forwarded message: > > From: "dculler" > Date: May 23, 2007 1:24:58 AM GMT+02:00 > To: > Subject: [RSN] Interest in the Interplay of "routing" and "meshing" > Reply-To: dculler@archrock.com > > Several of the comments on this list have touched on the issue of > different kinds of "multihop routing" in the context of sensor > networks. Is there interest in working on how these forms of routing tie together? > > To make the question more grounded: Low power radios have relatively > short range. IEEE 802.15.4 radios are typically 1 mW transmit power, > vs 100 mW for 802.11, and have typical ranges in 10s to 100 m. > Generally speaking, the power required to communicate a given distance > by radio grows polynomially with distance. In typical settings it > grows like the cube, but it can be much worse near the ground or > somewhat better with directional antennas. The cost to communicate > hop-by-hop grows only linearly, and it offers the potential to route > around obstacles and enhance reliability through "receiver diversity". > > The question is at what layer(s) in the stack this routing occurs and > how it relates to IP routing more generally. Most multihop protocols > in the sensor network research community are effectively at layer2 - > they form a single "patch" of homogeneous media. Logically, they are > a subnet, although few of the protocols address what happens beyond > the "patch" of sensor nodes, other than that some of the nodes are > "gateways". Current industry standards, such as Zigbee, Zwave, and > wirelessHART, are also a "multihop link", leaving open the question of > how nodes within the sensor patch communicate with nodes outside. > > 6LoWPAN provides a compressed header format for "mesh routing", > meaning multihop forwarding of packets within the 802.15.4 link. Such > a link is assumed to be formed by a contiguously connected set of > 802.15.4 nodes. The presence of such "mesh routing" capabilities does > not eliminate the need for layer 3 routing. If a 15.4 node > communicates with a remote node, say an > 802.11 node, how is routing and forwarding carried out? If two > "LoWPAN subnets" [sic] happen to be connected by 15.4 nodes, how does > 15.4-to-15.4 routing occur? The 6LoWPAN header format is, of course, > a general solution for carrying IP over 802.15.4, so it is able to > express these other forms of routing, as well. In the extreme case, > each individual node is an IP link and all routing is done at the IP > layer. On the other hand, patches of nodes may want to function as a > logical subnet, even if the wireless multihop routing is done at the > IP layer. At this point, the concerns overlap with those addressed in > autoconf (cf., draft-ietf-autoconf-manetarch-01). > > There is substantial commonality of concerns at the different layers > of multihop routing, but also differences. It is also important to > separate the process of forming a routing topology from the process of > forwarding packets. Both of which are distinct (but not entirely > independent of) how power management (turning on/off the radios) is performed. > > > _______________________________________________ > 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 _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Wed May 30 20:29:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtYXu-0005Fe-NI; Wed, 30 May 2007 20:29:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtYXt-0005FY-6Q for rsn@ietf.org; Wed, 30 May 2007 20:29:41 -0400 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtYXr-00065v-RV for rsn@ietf.org; Wed, 30 May 2007 20:29:41 -0400 Received: from dnab42335c.stanford.edu ([171.66.51.92]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1HtYXp-0006z2-JA; Wed, 30 May 2007 17:29:38 -0700 In-Reply-To: <465BE818.2020909@sensinode.com> References: <20070522232511.DD58016B0002@secure.archedrock.com> <465A6EBF.70600@sensinode.com> <465BE818.2020909@sensinode.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <329074DA-D05C-4BDB-8DA4-0F5F5D243A21@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [RSN] Next step for RSN ? Date: Wed, 30 May 2007 17:29:36 -0700 To: Zach Shelby 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: 3acef658708772c1d00935e7d4d752c5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 May 29, 2007, at 1:45 AM, Zach Shelby wrote: > > > I have been involved with 802.15.4a ultra-wideband and chirp > efforts for years, and see them having bright potential. By ToA I > do not mean the raw ToA calculation, but the resulting distance in > m calculated from that with some confidence metric. E.g. in > 802.l5.4a chirp spread spectrum, the current SoA technique uses a > round-trip calculation between two nodes, accuracy at least 1 m. > UWB can achieve the same round-trip with an accuracy of a few cm. I > have a demo running in the lab with that UWB accuracy, pretty cool > I must say (running on Time-Domain hardware). > > That being, maybe the metric available to routing should be simply > the last measured distance to the neighbor with a confidence metric > attached? This would generalize RSSI and ToA. Of course RSSI would > have a horrible confidence, and ToA quite a good one. This issue is > to be left to later RSN work, so let's not get stuck on it now... This seems like a link-specific thing; assuming its presence is probably a bad idea. At the very least, 802.15.4 doesn't have it, so that means that 15.4 nodes would require additional circuitry/hardware? The goal should be to define a *minimal* set of primitives the routing layer can depend on, in order to support as a broad a set of layer 2s as possible. Individual routing implementations for specific layer 2s can always take advantage of special hardware, but they can't assume its presence for correct operation. For example, a routing implementation might use physical layer indicators to guide its route selection, but it shouldn't be embedding these indicators in its packets as other nodes might have different radios with different indicators. E.g., an XBee Pro-based device might not know what to do with the soft chip decision indicator of a CC2420. Phil _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu May 31 07:19: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 1Htigj-0006BJ-Ow; Thu, 31 May 2007 07:19:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htigi-0006B8-FN for rsn@ietf.org; Thu, 31 May 2007 07:19:28 -0400 Received: from mail.zen-sys.com ([195.215.56.170] helo=zensys17.zensys.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htigg-000294-59 for rsn@ietf.org; Thu, 31 May 2007 07:19:28 -0400 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] Next step for RSN ? Date: Thu, 31 May 2007 13:19:24 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E77B2B7@zensys17.zensys.local> In-Reply-To: <329074DA-D05C-4BDB-8DA4-0F5F5D243A21@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] Next step for RSN ? thread-index: AcejGswAvQLN76Z/SC6psHNJtDzy9QAV1dgA References: <20070522232511.DD58016B0002@secure.archedrock.com><465A6EBF.70600@sensinode.com><465BE818.2020909@sensinode.com> <329074DA-D05C-4BDB-8DA4-0F5F5D243A21@cs.stanford.edu> From: "Anders Brandt" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 >The goal should be to define a *minimal* set of primitives the routing layer can depend on, in order to support as a broad a set >of layer 2s as possible. Individual routing implementations for specific layer 2s can always take advantage of special hardware, >but they can't assume its presence for correct operation. For example, a routing implementation might use physical layer >indicators to guide its route selection, but it shouldn't be embedding these indicators in its packets as other nodes might have >different radios with different indicators. E.g., an XBee Pro-based device might not know what to do with the soft chip decision >indicator of a CC2420. I couldn't agree more. RSSI and ToA sounds very sexy but very HW specific. A more pragmatic approach might be some high-level L2 API indication of the quality of the link to a given neighbour node. The challenge is mapping the specific properties of different L2's into that high-level L2 API. RSN's finest goal should be a set of primitives that allows routing across a broad range of RF platforms; mesh-under or not, beacon or not, etc. That high-level L2 API will give us a hard work before it satisfies all our conflicting interests, but our success depends on it. One final note on RF connection reliability: Having statistics for a given path is fine, but in RF, an apparently fine connection may quickly turn out to be weak because of some new noise generator in the neighbourhood. Therefore, being able to quickly choose another alternative link is at least as important as knowing the link quality upfront. Anders _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu May 31 13:06: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 1Hto6n-0002Ci-N0; Thu, 31 May 2007 13:06:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hto6m-0002Cc-Ah for rsn@ietf.org; Thu, 31 May 2007 13:06:44 -0400 Received: from cs-smtp-3.stanford.edu ([171.64.64.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hto6l-0001pp-TS for rsn@ietf.org; Thu, 31 May 2007 13:06:44 -0400 Received: from dnab42328d.stanford.edu ([171.66.50.141]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Hto6i-0000FD-Rk; Thu, 31 May 2007 10:06:43 -0700 In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E77B2B7@zensys17.zensys.local> References: <20070522232511.DD58016B0002@secure.archedrock.com><465A6EBF.70600@sensinode.com><465BE818.2020909@sensinode.com> <329074DA-D05C-4BDB-8DA4-0F5F5D243A21@cs.stanford.edu> <6D9687E95918C04A8B30A7D6DA805A3E77B2B7@zensys17.zensys.local> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [RSN] Next step for RSN ? Date: Thu, 31 May 2007 10:06:40 -0700 To: Anders Brandt 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: 50c535147b6e7155177bcd7d65214eb3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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 May 31, 2007, at 4:19 AM, Anders Brandt wrote: >> The goal should be to define a *minimal* set of primitives the >> routing > layer can depend on, in order to support as a broad a set >> of layer 2s as possible. Individual routing implementations for > specific layer 2s can always take advantage of special hardware, >> but they can't assume its presence for correct operation. For >> example, > a routing implementation might use physical layer >> indicators to guide its route selection, but it shouldn't be >> embedding > these indicators in its packets as other nodes might have >> different radios with different indicators. E.g., an XBee Pro-based > device might not know what to do with the soft chip decision >> indicator of a CC2420. > > I couldn't agree more. RSSI and ToA sounds very sexy but very HW > specific. Well, RSSI can definitely be useful, even if it is HW specific. For example, while different HW sensitivities (read: noise floors) means that trying to infer link quality from the RSSI value requires additional mechanisms, phenomena such as sudden changes in RSSI can be very valuable. For example, if a node observes that the RSSI of packets from another node just dropped 10 dB, this suggests that the link might have degraded. > > A more pragmatic approach might be some high-level L2 API > indication of > the quality of the link to a given neighbour node. > The challenge is mapping the specific properties of different L2's > into > that high-level L2 API. > RSN's finest goal should be a set of primitives that allows routing > across a broad range of RF platforms; > mesh-under or not, beacon or not, etc. > That high-level L2 API will give us a hard work before it satisfies > all > our conflicting interests, but our success depends on it. 15.4 tried to do this with LQI, and it's of limited use. There are basically two things to consider: 1) Unless you require an underlying protocol, neighborhood table management, or other state in the link layer, this measurement will be for *incoming* connectivity only. That is, it measures the quality of the packet you received, not the quality of packets you will transmit. As soon as you have link asymmetries from hardware (e.g., calibration) or from local interference (e.g., a microwave), then this simple value is insufficient. 2) Settling on a value that is truly interoperable is very hard. Again, 15.4 tried to specify LQI, but if you look how manufacturers suggest you compute LQI from their hardware, they basically say "it's up to you." Even given how vague the LQI specification is, it's still hard to meet. Based on these difficulties, the conclusion the TinyOS networking group was that trying to specify this L2 information was a lost cause. Rather, network protocols shouldn't assume any such information, and should be able to operate in its absence. In CTP, for example, the periodic routing beacons have sequence numbers in them so nodes can estimate PRRs at layer 3. Now, a particular implementation may have hardware resources that it can use to estimate more quickly or accurately, but the protocol does not assume them. For example, when seeding a routing table a node with a CC2420 radio can use the soft chip decision indicator (sort of a bit error rate) to come up with an estimate that is a lot faster and usually but not always more accurate than packet sequence numbers. > > One final note on RF connection reliability: > Having statistics for a given path is fine, but in RF, an apparently > fine connection may quickly turn out to be weak because of some new > noise generator in the neighbourhood. Therefore, being able to quickly > choose another alternative link is at least as important as knowing > the > link quality upfront. Very true. Most beacon-based routing protocols run into a problem here, in that the link quality is updated by periodic beacons, whose transmission is independent of data traffic. If a link goes down, the time it takes to recover is defined by the beacons and is independent of data traffic. The current CTP implementation in TinyOS deals with this problem by directly using acknowledgements to estimate link quality. CTP uses an ETX metric for routing, and there's no better measure of ETX than how many data packets you have to transmit before you get an ack... Phil _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu May 31 14:53:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htplh-0005AC-1Y; Thu, 31 May 2007 14:53:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htplf-0005A7-UL for rsn@ietf.org; Thu, 31 May 2007 14:53:03 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htplf-0001EY-ER for rsn@ietf.org; Thu, 31 May 2007 14:53:03 -0400 Received: from [192.168.1.211] (66.237.74.130.ptr.us.xo.net [66.237.74.130]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.1/8.13.5) with ESMTP id l4VIr166021112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 31 May 2007 11:53:02 -0700 (PDT) Message-ID: <465F198D.3080009@eecs.berkeley.edu> Date: Thu, 31 May 2007 11:53:01 -0700 From: Kris Pister User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: rsn@ietf.org Subject: Re: [RSN] Next step for RSN ? References: <20070522232511.DD58016B0002@secure.archedrock.com> <465A6EBF.70600@sensinode.com> <465BE818.2020909@sensinode.com> <329074DA-D05C-4BDB-8DA4-0F5F5D243A21@cs.stanford.edu> <6D9687E95918C04A8B30A7D6DA805A3E77B2B7@zensys17.zensys.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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 know what CTP and ETX are, but I'm 100% supportive of the use of L2 ACKs. In my experience, it is quite rare for links to go down in the 2.4GHz band. However, it is quite common for the PER to go from 0 to 100% on a given channel. If we have a requirement to support people who don't channel hop (sigh) then L2 ACKs are even more critical, since a single bad channel is perceived as a bad link. I do think that in an ideal world the network layer would have some visibility into the radio flexibility and the channel characteristics that the radio has to deal with. In some cases the available information may be "I'm stuck at 908.42MHz and don't move", or it may be "I can hop on 16 channels". The link characteristics can always be represented at the very least by some short term average of PER. I've included a plot below of a particular link in a mesh network running on 15.4 radios. Each horizontal trace is the 15 minute average PDR (=1-PER) on a particular 15.4 channel (channels are in 15.4 order, with 2.405 on bottom). You can clearly see the work-week in the periodicity of the data, for example all channels look great at around Day 12 (Sunday) and come Day 13 (monday morning) many of them go to hell. It's interesting that there are a couple of channels that always look good, but that most would regularly be declared to be "down links" in a single-channel network. Note also that other links in the network look similar, but with different channels that are good over the month-long test. (this data will be published soon at ICCCN) Routing algorithms for sensor networks need to comprehend and leverage this kind of link behavior. ksjp Philip Levis wrote: > On May 31, 2007, at 4:19 AM, Anders Brandt wrote: > >>> The goal should be to define a *minimal* set of primitives the routing >> layer can depend on, in order to support as a broad a set >>> of layer 2s as possible. Individual routing implementations for >> specific layer 2s can always take advantage of special hardware, >>> but they can't assume its presence for correct operation. For example, >> a routing implementation might use physical layer >>> indicators to guide its route selection, but it shouldn't be embedding >> these indicators in its packets as other nodes might have >>> different radios with different indicators. E.g., an XBee Pro-based >> device might not know what to do with the soft chip decision >>> indicator of a CC2420. >> >> I couldn't agree more. RSSI and ToA sounds very sexy but very HW >> specific. > > Well, RSSI can definitely be useful, even if it is HW specific. For > example, while different HW sensitivities (read: noise floors) means > that trying to infer link quality from the RSSI value requires > additional mechanisms, phenomena such as sudden changes in RSSI can be > very valuable. For example, if a node observes that the RSSI of > packets from another node just dropped 10 dB, this suggests that the > link might have degraded. > >> >> A more pragmatic approach might be some high-level L2 API indication of >> the quality of the link to a given neighbour node. >> The challenge is mapping the specific properties of different L2's into >> that high-level L2 API. >> RSN's finest goal should be a set of primitives that allows routing >> across a broad range of RF platforms; >> mesh-under or not, beacon or not, etc. >> That high-level L2 API will give us a hard work before it satisfies all >> our conflicting interests, but our success depends on it. > > 15.4 tried to do this with LQI, and it's of limited use. There are > basically two things to consider: > > 1) Unless you require an underlying protocol, neighborhood table > management, or other state in the link layer, this measurement will be > for *incoming* connectivity only. That is, it measures the quality of > the packet you received, not the quality of packets you will transmit. > As soon as you have link asymmetries from hardware (e.g., calibration) > or from local interference (e.g., a microwave), then this simple value > is insufficient. > > 2) Settling on a value that is truly interoperable is very hard. > Again, 15.4 tried to specify LQI, but if you look how manufacturers > suggest you compute LQI from their hardware, they basically say "it's > up to you." Even given how vague the LQI specification is, it's still > hard to meet. > > Based on these difficulties, the conclusion the TinyOS networking > group was that trying to specify this L2 information was a lost cause. > Rather, network protocols shouldn't assume any such information, and > should be able to operate in its absence. In CTP, for example, the > periodic routing beacons have sequence numbers in them so nodes can > estimate PRRs at layer 3. Now, a particular implementation may have > hardware resources that it can use to estimate more quickly or > accurately, but the protocol does not assume them. For example, when > seeding a routing table a node with a CC2420 radio can use the soft > chip decision indicator (sort of a bit error rate) to come up with an > estimate that is a lot faster and usually but not always more accurate > than packet sequence numbers. > >> >> One final note on RF connection reliability: >> Having statistics for a given path is fine, but in RF, an apparently >> fine connection may quickly turn out to be weak because of some new >> noise generator in the neighbourhood. Therefore, being able to quickly >> choose another alternative link is at least as important as knowing the >> link quality upfront. > > Very true. Most beacon-based routing protocols run into a problem > here, in that the link quality is updated by periodic beacons, whose > transmission is independent of data traffic. If a link goes down, the > time it takes to recover is defined by the beacons and is independent > of data traffic. The current CTP implementation in TinyOS deals with > this problem by directly using acknowledgements to estimate link > quality. CTP uses an ETX metric for routing, and there's no better > measure of ETX than how many data packets you have to transmit before > you get an ack... > > Phil > > _______________________________________________ > 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 May 31 16:51: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 1Htrc8-0003Nh-QZ; Thu, 31 May 2007 16:51:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtrIW-0005B2-It for rsn@ietf.org; Thu, 31 May 2007 16:31:04 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtrIW-00030t-2H for rsn@ietf.org; Thu, 31 May 2007 16:31:04 -0400 Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id l4VKUpRt020768; Thu, 31 May 2007 14:30:51 -0600 (MDT) Subject: Re: [RSN] Next step for RSN ? From: Geoff Mulligan To: Kris Pister In-Reply-To: <465F198D.3080009@eecs.berkeley.edu> References: <20070522232511.DD58016B0002@secure.archedrock.com> <465A6EBF.70600@sensinode.com> <465BE818.2020909@sensinode.com> <329074DA-D05C-4BDB-8DA4-0F5F5D243A21@cs.stanford.edu> <6D9687E95918C04A8B30A7D6DA805A3E77B2B7@zensys17.zensys.local> <465F198D.3080009@eecs.berkeley.edu> Content-Type: text/plain Date: Thu, 31 May 2007 14:30:58 -0600 Message-Id: <1180643458.8690.5.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c X-Mailman-Approved-At: Thu, 31 May 2007 16:51:20 -0400 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 Kris, I did get the plot. It would be great if we can define a protocol that would allow for the propagation of the link state information, but not require. geoff On Thu, 2007-05-31 at 11:53 -0700, Kris Pister wrote: > I don't know what CTP and ETX are, but I'm 100% supportive of the use of > L2 ACKs. > > In my experience, it is quite rare for links to go down in the 2.4GHz > band. However, it is quite common for the PER to go from 0 to 100% on a > given channel. If we have a requirement to support people who don't > channel hop (sigh) then L2 ACKs are even more critical, since a single > bad channel is perceived as a bad link. I do think that in an ideal > world the network layer would have some visibility into the radio > flexibility and the channel characteristics that the radio has to deal > with. In some cases the available information may be "I'm stuck at > 908.42MHz and don't move", or it may be "I can hop on 16 channels". The > link characteristics can always be represented at the very least by some > short term average of PER. > > I've included a plot below of a particular link in a mesh network > running on 15.4 radios. Each horizontal trace is the 15 minute average > PDR (=1-PER) on a particular 15.4 channel (channels are in 15.4 order, > with 2.405 on bottom). You can clearly see the work-week in the > periodicity of the data, for example all channels look great at around > Day 12 (Sunday) and come Day 13 (monday morning) many of them go to > hell. It's interesting that there are a couple of channels that always > look good, but that most would regularly be declared to be "down links" > in a single-channel network. Note also that other links in the network > look similar, but with different channels that are good over the > month-long test. (this data will be published soon at ICCCN) > > Routing algorithms for sensor networks need to comprehend and leverage > this kind of link behavior. > > ksjp > > > > Philip Levis wrote: > > On May 31, 2007, at 4:19 AM, Anders Brandt wrote: > > > >>> The goal should be to define a *minimal* set of primitives the routing > >> layer can depend on, in order to support as a broad a set > >>> of layer 2s as possible. Individual routing implementations for > >> specific layer 2s can always take advantage of special hardware, > >>> but they can't assume its presence for correct operation. For example, > >> a routing implementation might use physical layer > >>> indicators to guide its route selection, but it shouldn't be embedding > >> these indicators in its packets as other nodes might have > >>> different radios with different indicators. E.g., an XBee Pro-based > >> device might not know what to do with the soft chip decision > >>> indicator of a CC2420. > >> > >> I couldn't agree more. RSSI and ToA sounds very sexy but very HW > >> specific. > > > > Well, RSSI can definitely be useful, even if it is HW specific. For > > example, while different HW sensitivities (read: noise floors) means > > that trying to infer link quality from the RSSI value requires > > additional mechanisms, phenomena such as sudden changes in RSSI can be > > very valuable. For example, if a node observes that the RSSI of > > packets from another node just dropped 10 dB, this suggests that the > > link might have degraded. > > > >> > >> A more pragmatic approach might be some high-level L2 API indication of > >> the quality of the link to a given neighbour node. > >> The challenge is mapping the specific properties of different L2's into > >> that high-level L2 API. > >> RSN's finest goal should be a set of primitives that allows routing > >> across a broad range of RF platforms; > >> mesh-under or not, beacon or not, etc. > >> That high-level L2 API will give us a hard work before it satisfies all > >> our conflicting interests, but our success depends on it. > > > > 15.4 tried to do this with LQI, and it's of limited use. There are > > basically two things to consider: > > > > 1) Unless you require an underlying protocol, neighborhood table > > management, or other state in the link layer, this measurement will be > > for *incoming* connectivity only. That is, it measures the quality of > > the packet you received, not the quality of packets you will transmit. > > As soon as you have link asymmetries from hardware (e.g., calibration) > > or from local interference (e.g., a microwave), then this simple value > > is insufficient. > > > > 2) Settling on a value that is truly interoperable is very hard. > > Again, 15.4 tried to specify LQI, but if you look how manufacturers > > suggest you compute LQI from their hardware, they basically say "it's > > up to you." Even given how vague the LQI specification is, it's still > > hard to meet. > > > > Based on these difficulties, the conclusion the TinyOS networking > > group was that trying to specify this L2 information was a lost cause. > > Rather, network protocols shouldn't assume any such information, and > > should be able to operate in its absence. In CTP, for example, the > > periodic routing beacons have sequence numbers in them so nodes can > > estimate PRRs at layer 3. Now, a particular implementation may have > > hardware resources that it can use to estimate more quickly or > > accurately, but the protocol does not assume them. For example, when > > seeding a routing table a node with a CC2420 radio can use the soft > > chip decision indicator (sort of a bit error rate) to come up with an > > estimate that is a lot faster and usually but not always more accurate > > than packet sequence numbers. > > > >> > >> One final note on RF connection reliability: > >> Having statistics for a given path is fine, but in RF, an apparently > >> fine connection may quickly turn out to be weak because of some new > >> noise generator in the neighbourhood. Therefore, being able to quickly > >> choose another alternative link is at least as important as knowing the > >> link quality upfront. > > > > Very true. Most beacon-based routing protocols run into a problem > > here, in that the link quality is updated by periodic beacons, whose > > transmission is independent of data traffic. If a link goes down, the > > time it takes to recover is defined by the beacons and is independent > > of data traffic. The current CTP implementation in TinyOS deals with > > this problem by directly using acknowledgements to estimate link > > quality. CTP uses an ETX metric for routing, and there's no better > > measure of ETX than how many data packets you have to transmit before > > you get an ack... > > > > Phil > > > > _______________________________________________ > > 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 Thu May 31 17:14: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 1Htryf-0002O0-Aj; Thu, 31 May 2007 17:14:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htrye-0002Nv-04 for rsn@ietf.org; Thu, 31 May 2007 17:14:36 -0400 Received: from cs-smtp-3.stanford.edu ([171.64.64.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htryc-0002tE-GU for rsn@ietf.org; Thu, 31 May 2007 17:14:35 -0400 Received: from dnab422263.stanford.edu ([171.66.34.99]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Htryb-0004fe-O0; Thu, 31 May 2007 14:14:34 -0700 In-Reply-To: <465F198D.3080009@eecs.berkeley.edu> References: <20070522232511.DD58016B0002@secure.archedrock.com> <465A6EBF.70600@sensinode.com> <465BE818.2020909@sensinode.com> <329074DA-D05C-4BDB-8DA4-0F5F5D243A21@cs.stanford.edu> <6D9687E95918C04A8B30A7D6DA805A3E77B2B7@zensys17.zensys.local> <465F198D.3080009@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: Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [RSN] Next step for RSN ? Date: Thu, 31 May 2007 14:14:32 -0700 To: Kris Pister 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: a1ccd6d2fa83ef575f7b7817ead66a1e X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 May 31, 2007, at 11:53 AM, Kris Pister wrote: > I don't know what CTP and ETX are, but I'm 100% supportive of the > use of L2 ACKs. CTP is a protocol that TinyOS uses to build a collection tree to a data sink. ETX is "estimated transmissions." ETT -- "estimated transmission time" -- is a generalization of ETX that considers radios with multiple bit rates, such as 802.11. Phil _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu May 31 17:38:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtsMD-0007H4-IZ; Thu, 31 May 2007 17:38:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtsMB-0007Gk-RM for rsn@ietf.org; Thu, 31 May 2007 17:38:55 -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 1HtsMA-0001YQ-W2 for rsn@ietf.org; Thu, 31 May 2007 17:38:55 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 31 May 2007 14:38:25 -0700 X-IronPort-AV: i="4.16,370,1175497200"; d="scan'208"; a="489745171:sNHT80527792828" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l4VLcOHt002148; Thu, 31 May 2007 14:38:24 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4VLcK20002179; Thu, 31 May 2007 21:38:24 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); Thu, 31 May 2007 17:38:12 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 17:38:11 -0400 In-Reply-To: <1180643458.8690.5.camel@dellx1> References: <20070522232511.DD58016B0002@secure.archedrock.com> <465A6EBF.70600@sensinode.com> <465BE818.2020909@sensinode.com> <329074DA-D05C-4BDB-8DA4-0F5F5D243A21@cs.stanford.edu> <6D9687E95918C04A8B30A7D6DA805A3E77B2B7@zensys17.zensys.local> <465F198D.3080009@eecs.berkeley.edu> <1180643458.8690.5.camel@dellx1> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <40A93546-8084-4E8E-9452-BAA4F0A0DC13@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [RSN] Next step for RSN ? Date: Thu, 31 May 2007 17:37:58 -0400 To: Geoff Mulligan X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 31 May 2007 21:38:11.0961 (UTC) FILETIME=[FCE08690:01C7A3CB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7855; t=1180647504; x=1181511504; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[RSN]=20Next=20step=20for=20RSN=20? |Sender:=20; bh=Ytiw81ttWRBlPl3qffK/NQ9yEh3QsFEy6qTxsVT6Yq0=; b=c3E0KuTOE61W0qzXDedbF7P++UizLT+R+ROK8ujtH07zd7Yd1wQAB76JVPZD3/Cxgr9+7uLA S7NcqSV+m9ESeUIgThguiARqcBbG3FnYmSQQjpwM0gVZ4FdrDJRC22Qq; Authentication-Results: sj-dkim-3; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 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 Geoff, On May 31, 2007, at 4:30 PM, Geoff Mulligan wrote: > Kris, > I did get the plot. > > It would be great if we can define a protocol that would allow for the > propagation of the link state information, but not require. > Indeed, this is what I referred to as "minimal link layer abstraction" where the layer2 property of a link (discussed in 6lowpan: agree Geoff ?) would translate into some form of metric used by the routing protocol (Pascal and I will post soon an ID proposing a "framework" to define such metrics). Cheers. JP. > geoff > > On Thu, 2007-05-31 at 11:53 -0700, Kris Pister wrote: >> I don't know what CTP and ETX are, but I'm 100% supportive of the >> use of >> L2 ACKs. >> >> In my experience, it is quite rare for links to go down in the 2.4GHz >> band. However, it is quite common for the PER to go from 0 to >> 100% on a >> given channel. If we have a requirement to support people who don't >> channel hop (sigh) then L2 ACKs are even more critical, since a >> single >> bad channel is perceived as a bad link. I do think that in an ideal >> world the network layer would have some visibility into the radio >> flexibility and the channel characteristics that the radio has to >> deal >> with. In some cases the available information may be "I'm stuck at >> 908.42MHz and don't move", or it may be "I can hop on 16 >> channels". The >> link characteristics can always be represented at the very least >> by some >> short term average of PER. >> >> I've included a plot below of a particular link in a mesh network >> running on 15.4 radios. Each horizontal trace is the 15 minute >> average >> PDR (=1-PER) on a particular 15.4 channel (channels are in 15.4 >> order, >> with 2.405 on bottom). You can clearly see the work-week in the >> periodicity of the data, for example all channels look great at >> around >> Day 12 (Sunday) and come Day 13 (monday morning) many of them go to >> hell. It's interesting that there are a couple of channels that >> always >> look good, but that most would regularly be declared to be "down >> links" >> in a single-channel network. Note also that other links in the >> network >> look similar, but with different channels that are good over the >> month-long test. (this data will be published soon at ICCCN) >> >> Routing algorithms for sensor networks need to comprehend and >> leverage >> this kind of link behavior. >> >> ksjp >> >> >> >> Philip Levis wrote: >>> On May 31, 2007, at 4:19 AM, Anders Brandt wrote: >>> >>>>> The goal should be to define a *minimal* set of primitives the >>>>> routing >>>> layer can depend on, in order to support as a broad a set >>>>> of layer 2s as possible. Individual routing implementations for >>>> specific layer 2s can always take advantage of special hardware, >>>>> but they can't assume its presence for correct operation. For >>>>> example, >>>> a routing implementation might use physical layer >>>>> indicators to guide its route selection, but it shouldn't be >>>>> embedding >>>> these indicators in its packets as other nodes might have >>>>> different radios with different indicators. E.g., an XBee Pro- >>>>> based >>>> device might not know what to do with the soft chip decision >>>>> indicator of a CC2420. >>>> >>>> I couldn't agree more. RSSI and ToA sounds very sexy but very HW >>>> specific. >>> >>> Well, RSSI can definitely be useful, even if it is HW specific. For >>> example, while different HW sensitivities (read: noise floors) means >>> that trying to infer link quality from the RSSI value requires >>> additional mechanisms, phenomena such as sudden changes in RSSI >>> can be >>> very valuable. For example, if a node observes that the RSSI of >>> packets from another node just dropped 10 dB, this suggests that the >>> link might have degraded. >>> >>>> >>>> A more pragmatic approach might be some high-level L2 API >>>> indication of >>>> the quality of the link to a given neighbour node. >>>> The challenge is mapping the specific properties of different >>>> L2's into >>>> that high-level L2 API. >>>> RSN's finest goal should be a set of primitives that allows routing >>>> across a broad range of RF platforms; >>>> mesh-under or not, beacon or not, etc. >>>> That high-level L2 API will give us a hard work before it >>>> satisfies all >>>> our conflicting interests, but our success depends on it. >>> >>> 15.4 tried to do this with LQI, and it's of limited use. There are >>> basically two things to consider: >>> >>> 1) Unless you require an underlying protocol, neighborhood table >>> management, or other state in the link layer, this measurement >>> will be >>> for *incoming* connectivity only. That is, it measures the >>> quality of >>> the packet you received, not the quality of packets you will >>> transmit. >>> As soon as you have link asymmetries from hardware (e.g., >>> calibration) >>> or from local interference (e.g., a microwave), then this simple >>> value >>> is insufficient. >>> >>> 2) Settling on a value that is truly interoperable is very hard. >>> Again, 15.4 tried to specify LQI, but if you look how manufacturers >>> suggest you compute LQI from their hardware, they basically say >>> "it's >>> up to you." Even given how vague the LQI specification is, it's >>> still >>> hard to meet. >>> >>> Based on these difficulties, the conclusion the TinyOS networking >>> group was that trying to specify this L2 information was a lost >>> cause. >>> Rather, network protocols shouldn't assume any such information, and >>> should be able to operate in its absence. In CTP, for example, the >>> periodic routing beacons have sequence numbers in them so nodes can >>> estimate PRRs at layer 3. Now, a particular implementation may have >>> hardware resources that it can use to estimate more quickly or >>> accurately, but the protocol does not assume them. For example, when >>> seeding a routing table a node with a CC2420 radio can use the soft >>> chip decision indicator (sort of a bit error rate) to come up >>> with an >>> estimate that is a lot faster and usually but not always more >>> accurate >>> than packet sequence numbers. >>> >>>> >>>> One final note on RF connection reliability: >>>> Having statistics for a given path is fine, but in RF, an >>>> apparently >>>> fine connection may quickly turn out to be weak because of some new >>>> noise generator in the neighbourhood. Therefore, being able to >>>> quickly >>>> choose another alternative link is at least as important as >>>> knowing the >>>> link quality upfront. >>> >>> Very true. Most beacon-based routing protocols run into a problem >>> here, in that the link quality is updated by periodic beacons, whose >>> transmission is independent of data traffic. If a link goes down, >>> the >>> time it takes to recover is defined by the beacons and is >>> independent >>> of data traffic. The current CTP implementation in TinyOS deals with >>> this problem by directly using acknowledgements to estimate link >>> quality. CTP uses an ETX metric for routing, and there's no better >>> measure of ETX than how many data packets you have to transmit >>> before >>> you get an ack... >>> >>> Phil >>> >>> _______________________________________________ >>> 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 _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu May 31 17:59:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtsgZ-0003Ji-4G; Thu, 31 May 2007 17:59:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtsbR-0008RX-54 for rsn@ietf.org; Thu, 31 May 2007 17:54:41 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtsbQ-0005rm-IP for rsn@ietf.org; Thu, 31 May 2007 17:54:41 -0400 Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id l4VLsdX4021240; Thu, 31 May 2007 15:54:39 -0600 (MDT) Subject: Re: [RSN] Next step for RSN ? From: Geoff Mulligan To: JP Vasseur In-Reply-To: <40A93546-8084-4E8E-9452-BAA4F0A0DC13@cisco.com> References: <20070522232511.DD58016B0002@secure.archedrock.com> <465A6EBF.70600@sensinode.com> <465BE818.2020909@sensinode.com> <329074DA-D05C-4BDB-8DA4-0F5F5D243A21@cs.stanford.edu> <6D9687E95918C04A8B30A7D6DA805A3E77B2B7@zensys17.zensys.local> <465F198D.3080009@eecs.berkeley.edu> <1180643458.8690.5.camel@dellx1> <40A93546-8084-4E8E-9452-BAA4F0A0DC13@cisco.com> Content-Type: text/plain Date: Thu, 31 May 2007 15:54:46 -0600 Message-Id: <1180648486.8690.41.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 X-Mailman-Approved-At: Thu, 31 May 2007 17:59:58 -0400 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 Yes. We did talk briefly about this during the 6lowpan meeting. I don't know if we can abstract this down to a single metric number, but I think that this was sort of the idea. BTW- what I previously meant to say was that I DID NOT get Kris' plot. geoff On Thu, 2007-05-31 at 17:37 -0400, JP Vasseur wrote: > Hi Geoff, > > On May 31, 2007, at 4:30 PM, Geoff Mulligan wrote: > > > Kris, > > I did get the plot. > > > > It would be great if we can define a protocol that would allow for the > > propagation of the link state information, but not require. > > > > Indeed, this is what I referred to as "minimal link layer > abstraction" where the layer2 property of a link > (discussed in 6lowpan: agree Geoff ?) would translate into some form > of metric used by the routing > protocol (Pascal and I will post soon an ID proposing a "framework" > to define such metrics). > > Cheers. > > JP. > > > geoff > > > > On Thu, 2007-05-31 at 11:53 -0700, Kris Pister wrote: > >> I don't know what CTP and ETX are, but I'm 100% supportive of the > >> use of > >> L2 ACKs. > >> > >> In my experience, it is quite rare for links to go down in the 2.4GHz > >> band. However, it is quite common for the PER to go from 0 to > >> 100% on a > >> given channel. If we have a requirement to support people who don't > >> channel hop (sigh) then L2 ACKs are even more critical, since a > >> single > >> bad channel is perceived as a bad link. I do think that in an ideal > >> world the network layer would have some visibility into the radio > >> flexibility and the channel characteristics that the radio has to > >> deal > >> with. In some cases the available information may be "I'm stuck at > >> 908.42MHz and don't move", or it may be "I can hop on 16 > >> channels". The > >> link characteristics can always be represented at the very least > >> by some > >> short term average of PER. > >> > >> I've included a plot below of a particular link in a mesh network > >> running on 15.4 radios. Each horizontal trace is the 15 minute > >> average > >> PDR (=1-PER) on a particular 15.4 channel (channels are in 15.4 > >> order, > >> with 2.405 on bottom). You can clearly see the work-week in the > >> periodicity of the data, for example all channels look great at > >> around > >> Day 12 (Sunday) and come Day 13 (monday morning) many of them go to > >> hell. It's interesting that there are a couple of channels that > >> always > >> look good, but that most would regularly be declared to be "down > >> links" > >> in a single-channel network. Note also that other links in the > >> network > >> look similar, but with different channels that are good over the > >> month-long test. (this data will be published soon at ICCCN) > >> > >> Routing algorithms for sensor networks need to comprehend and > >> leverage > >> this kind of link behavior. > >> > >> ksjp > >> > >> > >> > >> Philip Levis wrote: > >>> On May 31, 2007, at 4:19 AM, Anders Brandt wrote: > >>> > >>>>> The goal should be to define a *minimal* set of primitives the > >>>>> routing > >>>> layer can depend on, in order to support as a broad a set > >>>>> of layer 2s as possible. Individual routing implementations for > >>>> specific layer 2s can always take advantage of special hardware, > >>>>> but they can't assume its presence for correct operation. For > >>>>> example, > >>>> a routing implementation might use physical layer > >>>>> indicators to guide its route selection, but it shouldn't be > >>>>> embedding > >>>> these indicators in its packets as other nodes might have > >>>>> different radios with different indicators. E.g., an XBee Pro- > >>>>> based > >>>> device might not know what to do with the soft chip decision > >>>>> indicator of a CC2420. > >>>> > >>>> I couldn't agree more. RSSI and ToA sounds very sexy but very HW > >>>> specific. > >>> > >>> Well, RSSI can definitely be useful, even if it is HW specific. For > >>> example, while different HW sensitivities (read: noise floors) means > >>> that trying to infer link quality from the RSSI value requires > >>> additional mechanisms, phenomena such as sudden changes in RSSI > >>> can be > >>> very valuable. For example, if a node observes that the RSSI of > >>> packets from another node just dropped 10 dB, this suggests that the > >>> link might have degraded. > >>> > >>>> > >>>> A more pragmatic approach might be some high-level L2 API > >>>> indication of > >>>> the quality of the link to a given neighbour node. > >>>> The challenge is mapping the specific properties of different > >>>> L2's into > >>>> that high-level L2 API. > >>>> RSN's finest goal should be a set of primitives that allows routing > >>>> across a broad range of RF platforms; > >>>> mesh-under or not, beacon or not, etc. > >>>> That high-level L2 API will give us a hard work before it > >>>> satisfies all > >>>> our conflicting interests, but our success depends on it. > >>> > >>> 15.4 tried to do this with LQI, and it's of limited use. There are > >>> basically two things to consider: > >>> > >>> 1) Unless you require an underlying protocol, neighborhood table > >>> management, or other state in the link layer, this measurement > >>> will be > >>> for *incoming* connectivity only. That is, it measures the > >>> quality of > >>> the packet you received, not the quality of packets you will > >>> transmit. > >>> As soon as you have link asymmetries from hardware (e.g., > >>> calibration) > >>> or from local interference (e.g., a microwave), then this simple > >>> value > >>> is insufficient. > >>> > >>> 2) Settling on a value that is truly interoperable is very hard. > >>> Again, 15.4 tried to specify LQI, but if you look how manufacturers > >>> suggest you compute LQI from their hardware, they basically say > >>> "it's > >>> up to you." Even given how vague the LQI specification is, it's > >>> still > >>> hard to meet. > >>> > >>> Based on these difficulties, the conclusion the TinyOS networking > >>> group was that trying to specify this L2 information was a lost > >>> cause. > >>> Rather, network protocols shouldn't assume any such information, and > >>> should be able to operate in its absence. In CTP, for example, the > >>> periodic routing beacons have sequence numbers in them so nodes can > >>> estimate PRRs at layer 3. Now, a particular implementation may have > >>> hardware resources that it can use to estimate more quickly or > >>> accurately, but the protocol does not assume them. For example, when > >>> seeding a routing table a node with a CC2420 radio can use the soft > >>> chip decision indicator (sort of a bit error rate) to come up > >>> with an > >>> estimate that is a lot faster and usually but not always more > >>> accurate > >>> than packet sequence numbers. > >>> > >>>> > >>>> One final note on RF connection reliability: > >>>> Having statistics for a given path is fine, but in RF, an > >>>> apparently > >>>> fine connection may quickly turn out to be weak because of some new > >>>> noise generator in the neighbourhood. Therefore, being able to > >>>> quickly > >>>> choose another alternative link is at least as important as > >>>> knowing the > >>>> link quality upfront. > >>> > >>> Very true. Most beacon-based routing protocols run into a problem > >>> here, in that the link quality is updated by periodic beacons, whose > >>> transmission is independent of data traffic. If a link goes down, > >>> the > >>> time it takes to recover is defined by the beacons and is > >>> independent > >>> of data traffic. The current CTP implementation in TinyOS deals with > >>> this problem by directly using acknowledgements to estimate link > >>> quality. CTP uses an ETX metric for routing, and there's no better > >>> measure of ETX than how many data packets you have to transmit > >>> before > >>> you get an ack... > >>> > >>> Phil > >>> > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > 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