From owner-manet@itd.nrl.navy.mil Sat Apr 1 04:09:37 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07286 for ; Sat, 1 Apr 2000 04:09:36 -0500 (EST) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id CAA09865 for manet-outgoing; Sat, 1 Apr 2000 02:19:10 -0500 (EST) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id CAA09860 for ; Sat, 1 Apr 2000 02:19:07 -0500 (EST) From: dsuprati@in.ibm.com Received: from f03n05e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id RAA189560 for ; Sat, 1 Apr 2000 17:13:54 +1000 Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67]) by f03n05e.au.ibm.com (8.8.8m2/8.8.7) with SMTP id RAA11416 for ; Sat, 1 Apr 2000 17:18:50 +1000 Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA2568B4.00282C7B ; Sat, 1 Apr 2000 17:18:48 +1000 X-Lotus-FromDomain: IBMIN@IBMAU To: manet@itd.nrl.navy.mil Message-ID: Date: Sat, 1 Apr 2000 12:51:27 +0530 Subject: questions on routing in bluetooth Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi All: I was just following the mails over the last few days on routing in adhoc networks. Can somebody pour some light on what can be the major issues for routing in Bluetooth kind of adhoc network, where nodes are charaterized by low or zero mobility? Is it worthwhile to talk about the same issues of rothing in adhoc networks, when we talk about routing in Scatternet formed by multiple Piconets? The AODV or some proactive kind of protocols, if used, may have to be tweaked appropriately because of the Master slave Pico-cellular architecture. So, can a Clusterhead routing kind of thing work well here or there may be drawbacks when applied to BT? thanks, supratim/ibm irl ********************************************************************* SUPRATIM DEB Phone:+91-11-6861100 (Extn:146) E-mail: dsuprati@in.ibm.com Office: IBM India Research Lab Block 1, IIT Delhi, Hauz Khas , New Delhi- 110 016 28 deg 54 min North, 77 deg 13 min East From owner-manet@itd.nrl.navy.mil Mon Apr 3 09:05:02 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16913 for ; Mon, 3 Apr 2000 09:05:02 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id GAA02446 for manet-outgoing; Mon, 3 Apr 2000 06:40:56 -0400 (EDT) Received: from mintaka.isr.umd.edu (mintaka.isr.umd.edu [128.8.111.4]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id GAA02438 for ; Mon, 3 Apr 2000 06:40:51 -0400 (EDT) Received: from manet.isr.umd.edu (root@manet.isr.umd.edu [128.8.111.170]) by mintaka.isr.umd.edu (8.9.3/8.9.3) with ESMTP id GAA20482; Mon, 3 Apr 2000 06:37:51 -0400 (EDT) Received: from manet.isr.umd.edu (sendmail@localhost [127.0.0.1]) by manet.isr.umd.edu (8.9.3/8.9.3) with SMTP id GAA02021; Mon, 3 Apr 2000 06:40:49 -0400 (EDT) Received: from localhost (corson@localhost) by manet.isr.umd.edu (8.9.3/8.9.3) with ESMTP id GAA02017; Mon, 3 Apr 2000 06:40:49 -0400 (EDT) X-Authentication-Warning: manet.isr.umd.edu: corson owned process doing -bs Date: Mon, 3 Apr 2000 06:40:39 -0400 (EDT) From: "M. Scott Corson" X-Sender: corson@manet.isr.umd.edu To: Nitin H Vaidya cc: manet@itd.nrl.navy.mil Subject: Re: naming/address assignment In-Reply-To: <200003312051.OAA22435@sun.cs.tamu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk On Fri, 31 Mar 2000, Nitin H Vaidya wrote: tony mcauley et al. recently presented a short paper called "self-configuring networks" at the ARL Federated Laboratory 4th Annual Symposium which presents a DHCP-based extension for dynamic address assignment in ad hoc nets. you may want to ping him for a soft copy. -scott > Hello: > > If you know any work on naming/address assignment in > mobile ad hoc networks, can you please send me a pointer. > > Thanks. > > - nitin > > ******************************************************************************* M. Scott Corson Institute for Systems Research corson@isr.umd.edu A.V. Williams Bldg. (115) Phone: 301-405-6630 (Rm. 2205 AVW) University of Maryland Fax: 301-314-8586 College Park, MD 20742 ******************************************************************************* From owner-manet@itd.nrl.navy.mil Mon Apr 3 10:42:47 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17981 for ; Mon, 3 Apr 2000 10:42:46 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id IAA03943 for manet-outgoing; Mon, 3 Apr 2000 08:31:46 -0400 (EDT) Received: from mintaka.isr.umd.edu (mintaka.isr.umd.edu [128.8.111.4]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id IAA03938 for ; Mon, 3 Apr 2000 08:31:45 -0400 (EDT) Received: from manet.isr.umd.edu (root@manet.isr.umd.edu [128.8.111.170]) by mintaka.isr.umd.edu (8.9.3/8.9.3) with ESMTP id IAA22908; Mon, 3 Apr 2000 08:28:44 -0400 (EDT) Received: from manet.isr.umd.edu (sendmail@localhost [127.0.0.1]) by manet.isr.umd.edu (8.9.3/8.9.3) with SMTP id IAA02460; Mon, 3 Apr 2000 08:31:43 -0400 (EDT) Received: from localhost (corson@localhost) by manet.isr.umd.edu (8.9.3/8.9.3) with ESMTP id IAA02456; Mon, 3 Apr 2000 08:31:43 -0400 (EDT) X-Authentication-Warning: manet.isr.umd.edu: corson owned process doing -bs Date: Mon, 3 Apr 2000 08:31:42 -0400 (EDT) From: "M. Scott Corson" X-Sender: corson@manet.isr.umd.edu To: Kevin Grace cc: manet@itd.nrl.navy.mil Subject: Re: naming/address assignment In-Reply-To: <38E88BB4.49102FD4@mitre.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk On Mon, 3 Apr 2000, Kevin Grace wrote: it's available in http://search.ietf.org/internet-drafts/draft-itsumo-drcp-00.txt -scott > Do you have an email address for Tony? > > Thanks, > Kevin Grace > > The MITRE Corporation > 202 Burlington Rd > Bedford, MA 01730 > 781-271-8388 > kgrace@mitre.org > > "M. Scott Corson" wrote: > > > > On Fri, 31 Mar 2000, Nitin H Vaidya wrote: > > > > tony mcauley et al. recently presented a short paper called "self-configuring > > networks" at the ARL Federated Laboratory 4th Annual Symposium which presents > > a DHCP-based extension for dynamic address assignment in ad hoc nets. > > > > you may want to ping him for a soft copy. > > > > -scott > > > > > Hello: > > > > > > If you know any work on naming/address assignment in > > > mobile ad hoc networks, can you please send me a pointer. > > > > > > Thanks. > > > > > > - nitin > > > > > > > > > > ******************************************************************************* > > > > M. Scott Corson Institute for Systems Research > > corson@isr.umd.edu A.V. Williams Bldg. (115) > > Phone: 301-405-6630 (Rm. 2205 AVW) University of Maryland > > Fax: 301-314-8586 College Park, MD 20742 > > > > ******************************************************************************* > > ******************************************************************************* M. Scott Corson Institute for Systems Research corson@isr.umd.edu A.V. Williams Bldg. (115) Phone: 301-405-6630 (Rm. 2205 AVW) University of Maryland Fax: 301-314-8586 College Park, MD 20742 ******************************************************************************* From owner-manet@itd.nrl.navy.mil Mon Apr 3 10:55:51 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17980 for ; Mon, 3 Apr 2000 10:42:46 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id IAA03610 for manet-outgoing; Mon, 3 Apr 2000 08:19:07 -0400 (EDT) Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id IAA03605 for ; Mon, 3 Apr 2000 08:19:05 -0400 (EDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id IAA21842; Mon, 3 Apr 2000 08:18:58 -0400 (EDT) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id IAA17617; Mon, 3 Apr 2000 08:18:07 -0400 (EDT) Received: from marconi0.mitre.org (129.83.46.110) by mailhub1.mitre.org with SMTP id 3074158; Mon, 03 Apr 2000 08:18:25 EST Message-ID: <38E88BB4.49102FD4@mitre.org> Date: Mon, 03 Apr 2000 08:16:52 -0400 From: Kevin Grace Organization: The MITRE Corporation X-Mailer: Mozilla 4.61 [en]C-19990607M (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "M. Scott Corson" CC: manet@itd.nrl.navy.mil Subject: Re: naming/address assignment References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Do you have an email address for Tony? Thanks, Kevin Grace The MITRE Corporation 202 Burlington Rd Bedford, MA 01730 781-271-8388 kgrace@mitre.org "M. Scott Corson" wrote: > > On Fri, 31 Mar 2000, Nitin H Vaidya wrote: > > tony mcauley et al. recently presented a short paper called "self-configuring > networks" at the ARL Federated Laboratory 4th Annual Symposium which presents > a DHCP-based extension for dynamic address assignment in ad hoc nets. > > you may want to ping him for a soft copy. > > -scott > > > Hello: > > > > If you know any work on naming/address assignment in > > mobile ad hoc networks, can you please send me a pointer. > > > > Thanks. > > > > - nitin > > > > > > ******************************************************************************* > > M. Scott Corson Institute for Systems Research > corson@isr.umd.edu A.V. Williams Bldg. (115) > Phone: 301-405-6630 (Rm. 2205 AVW) University of Maryland > Fax: 301-314-8586 College Park, MD 20742 > > ******************************************************************************* From owner-manet@itd.nrl.navy.mil Mon Apr 3 12:07:37 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19297 for ; Mon, 3 Apr 2000 12:07:36 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA05406 for manet-outgoing; Mon, 3 Apr 2000 09:38:05 -0400 (EDT) Received: from Newman.GSC.GTE.Com (Newman.GSC.GTE.Com [192.160.62.66] (may be forged)) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA05397 for ; Mon, 3 Apr 2000 09:37:50 -0400 (EDT) Received: from gscex01.gsc.gte.com ("port 2212"@gscex01.ndhm.gsc.gte.com [155.95.162.170]) by Newman.GSC.GTE.Com (PMDF V5.2-30 #38015) with ESMTP id <01JNSM6IBXU20003IB@Newman.GSC.GTE.Com> for manet@itd.nrl.navy.mil; Mon, 3 Apr 2000 09:37:48 -0400 (EDT) Received: by GSCEX01.gsc.gte.com with Internet Mail Service (5.5.2448.0) id ; Mon, 03 Apr 2000 09:37:46 -0400 Content-return: allowed Date: Mon, 03 Apr 2000 09:37:46 -0400 From: "Josephson, William" Subject: RE: questions on routing in bluetooth To: "'dsuprati@in.ibm.com'" , manet@itd.nrl.navy.mil Message-id: <3774EF539472D211B98F0008C7F468A103ABF376@TNTNEX01.tntn.gtegsc.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: text/plain; charset="iso-8859-1" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk There are several parameters involved wrt what routing protocol to use. One is mobility but also bandwidth availability, energy needs, latency and speed of service. In the networks I am interested in right now, battery power is scarce, events are infrequent and reaction time and info dissemination time should be as short as possible. In my mind, energy consumption is the most critical since the nodes will otherwise be useless when called upon. Therefore I don't like any active periodic monitoring schemes and favor reactive protocols with caching of routes. -----Original Message----- From: dsuprati@in.ibm.com [mailto:dsuprati@in.ibm.com] Sent: Saturday, April 01, 2000 2:21 AM To: manet@itd.nrl.navy.mil Subject: questions on routing in bluetooth Hi All: I was just following the mails over the last few days on routing in adhoc networks. Can somebody pour some light on what can be the major issues for routing in Bluetooth kind of adhoc network, where nodes are charaterized by low or zero mobility? Is it worthwhile to talk about the same issues of rothing in adhoc networks, when we talk about routing in Scatternet formed by multiple Piconets? The AODV or some proactive kind of protocols, if used, may have to be tweaked appropriately because of the Master slave Pico-cellular architecture. So, can a Clusterhead routing kind of thing work well here or there may be drawbacks when applied to BT? thanks, supratim/ibm irl ********************************************************************* SUPRATIM DEB Phone:+91-11-6861100 (Extn:146) E-mail: dsuprati@in.ibm.com Office: IBM India Research Lab Block 1, IIT Delhi, Hauz Khas , New Delhi- 110 016 28 deg 54 min North, 77 deg 13 min East From owner-manet@itd.nrl.navy.mil Mon Apr 3 19:28:24 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27378 for ; Mon, 3 Apr 2000 19:28:22 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id RAA17673 for manet-outgoing; Mon, 3 Apr 2000 17:28:26 -0400 (EDT) Received: from cheetah.cs.ucla.edu (Cheetah.CS.UCLA.EDU [131.179.128.24]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id RAA17668 for ; Mon, 3 Apr 2000 17:28:15 -0400 (EDT) Received: from localhost (sjlee@localhost) by cheetah.cs.ucla.edu (8.9.1/UCLACS-5.0) with ESMTP id OAA15401; Mon, 3 Apr 2000 14:24:32 -0700 (PDT) Date: Mon, 3 Apr 2000 14:24:32 -0700 (PDT) From: SJ Lee To: "S.J. (Sung-Ju) Lee" Subject: CFP - MOBIHOC : Deadline extended to April 16th! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk [Please accept our apologies if you receive duplicate messages] NOTE: The submission deadline has been extended to April 16th! ========================================================================= Announcement and Call for Papers THE FIRST ANNUAL WORKSHOP ON MOBILE AD HOC NETWORKING & COMPUTING in conjunction with Mobicom 2000 August 11, 2000 Boston, Massachusetts, USA http://www.ece.gatech.edu/~cktoh/workshop.html SCOPE ===== We are interested in work-in-progress, visionary papers, experimental and systems-related papers. Papers should describe original, previously unpublished, and not currently under review by another conference, workshop, or journal. Topics of interest include, but are not limited to: - Ad Hoc Routing Protocols - Ad Hoc Multicasting Protocols - Ad Hoc Transport Issues - Service Discovery Protocols - Media Access Techniques - Low Power Algorithms and Protocols - Ad Hoc Mobile Applications - Sensor & Data Fusion Ad Hoc Networks - Quality of Service Issues - Ad Hoc Mobile Computing Platforms - Secure Ad Hoc Services Please consult the program chairs if you are uncertain whether your paper falls within the theme of this workshop. SUBMISSIONS =========== Postscript copies of your submissions should be sent to C.-K. Toh (cktoh@ece.gatech.edu) and Nitin Vaidya (vaidya@cs.tamu.edu). All papers will be reviewed for technical merit. Submissions should not exceed 20 double-spaced pages (including text and figures). IMPORTANT DATES =============== Paper submission due: April 16th, 2000 Notification of acceptance: May 15th, 2000 Camera ready version due: June 1st, 2000 SPONSORSHIP =========== ACM SIGMOBILE and IEEE Communications Society ORGANIZING COMMITTEE ==================== General Chair: Charles E. Perkins (Nokia Research Center) Technical Co-Chairs: C.-K. Toh (Georgia Institute of Technology) Nitin H. Vaidya (Texas A&M University) Advisory Committee: Leonard Kleinrock (UCLA/Nomadix) Victor O.K. Li (USC/Hong Kong University) Local Arrangement Chair: Katia Obraczka (USC/ISI) Publicity Chair: Sung-Ju Lee (University of California, Los Angeles) Registration Chair: Elizabeth M. Royer (University of California, Santa Barbara) Publication Co-Chairs: Stefano Basagni (University of Texas, Dallas) Violet R. Syrotiuk (University of Texas, Dallas) Treasurer: Bruce Worthman (IEEE) Steering Committee: Charles E. Perkins (Nokia Research Center) C.-K. Toh (Georgia Institute of Technology) Nitin H. Vaidya (Texas A&M University) Technical Program Committee: Samir Das University of Cincinnati Deborah Estrin USC/ISI J.J. Garcia-Luna-Aceves University of California, Santa Cruz Mario Gerla University of California, Los Angeles Zygmunt Haas Cornell University Parviz Kermani IBM Research Katia Obraczka USC/ISI Stephen Pink University of Arizona Ram Ramanathan BBN Technologies Adam Wolisz Technische Universitat Berlin From owner-manet@itd.nrl.navy.mil Wed Apr 5 10:09:25 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10351 for ; Wed, 5 Apr 2000 10:09:19 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id HAA20837 for manet-outgoing; Wed, 5 Apr 2000 07:03:12 -0400 (EDT) Received: from smtp1.cluster.oleane.net (smtp1.cluster.oleane.net [195.25.12.16]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id HAA20832 for ; Wed, 5 Apr 2000 07:03:09 -0400 (EDT) Received: from oleane (dyn-1-1-131.Vin.dialup.oleane.fr [195.25.4.131]) by smtp1.cluster.oleane.net with SMTP id NAA94719; Wed, 5 Apr 2000 13:02:14 +0200 (CEST) Message-ID: <006c01bf9eed$c2a51620$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: IP Based Cellular Networks Conference Date: Wed, 5 Apr 2000 12:57:30 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0069_01BF9EFE.80BE4C20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0069_01BF9EFE.80BE4C20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IP Based Cellular Networks Conference.=20 A scientific committe composed of the most eminent experts in this = technology will review the abstracts submitted from the Call For Papers: http://www.upperside.fr/baipcn.htm =20 ------=_NextPart_000_0069_01BF9EFE.80BE4C20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
IP Based Cellular Networks = Conference.=20
A scientific committe composed of = the most=20 eminent experts in this technology will review the abstracts submitted = from the=20 Call For Papers:
http://www.upperside.fr/baipc= n.htm
 
------=_NextPart_000_0069_01BF9EFE.80BE4C20-- From owner-manet@itd.nrl.navy.mil Thu Apr 6 14:56:48 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12942 for ; Thu, 6 Apr 2000 14:56:47 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA20925 for manet-outgoing; Thu, 6 Apr 2000 12:24:50 -0400 (EDT) Received: from mx2.ews.uiuc.edu (mx2.ews.uiuc.edu [130.126.161.238]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id MAA20920 for ; Thu, 6 Apr 2000 12:24:48 -0400 (EDT) Received: from softtooth.com (mgupta1@eesn34.ews.uiuc.edu [130.126.161.218]) by mx2.ews.uiuc.edu (8.9.3/8.9.3) with ESMTP id LAA20947 for ; Thu, 6 Apr 2000 11:24:47 -0500 (CDT) Message-ID: <38ECBA4F.774451DF@softtooth.com> Date: Thu, 06 Apr 2000 11:24:47 -0500 From: SoftTooth Organization: Engineering Workstations - UIUC X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: manet@itd.nrl.navy.mil Subject: Biological Wireless Internet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi, SoftTooth brings you the concept of "Biological Wireless Internet". Check it out at : http://www.softtooth.com/tech/bwn.html Do join this revolution. Manoj Gupta SoftTooth.Com ---------------------------------------------------- From owner-manet@itd.nrl.navy.mil Thu Apr 6 16:17:47 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14170 for ; Thu, 6 Apr 2000 16:17:46 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA24101 for manet-outgoing; Thu, 6 Apr 2000 14:12:06 -0400 (EDT) Received: from hotmail.com (f30.law7.hotmail.com [216.33.237.30]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id OAA24096 for ; Thu, 6 Apr 2000 14:12:02 -0400 (EDT) Received: (qmail 73140 invoked by uid 0); 6 Apr 2000 18:12:00 -0000 Message-ID: <20000406181200.73139.qmail@hotmail.com> Received: from 128.8.111.42 by www.hotmail.com with HTTP; Thu, 06 Apr 2000 11:12:00 PDT X-Originating-IP: [128.8.111.42] From: "bob jacques" To: manet@itd.nrl.navy.mil Subject: Re: Biological Wireless Internet Date: Thu, 06 Apr 2000 14:12:00 EDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk To join this revolution, do we have to live in Urbana, IL? ;-) bob >Date: Thu, 06 Apr 2000 11:24:47 -0500 >From: SoftTooth >To: manet@itd.nrl.navy.mil >Subject: Biological Wireless Internet > >Hi, > > SoftTooth brings you the concept of "Biological Wireless >Internet". > Check it out at : > > http://www.softtooth.com/tech/bwn.html > > Do join this revolution. > >Manoj Gupta >SoftTooth.Com > >---------------------------------------------------- > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-manet@itd.nrl.navy.mil Thu Apr 6 22:10:20 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19196 for ; Thu, 6 Apr 2000 22:10:17 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id UAA00531 for manet-outgoing; Thu, 6 Apr 2000 20:15:40 -0400 (EDT) Received: from web106.yahoomail.com (web106.yahoomail.com [205.180.60.73]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id UAA00526 for ; Thu, 6 Apr 2000 20:15:38 -0400 (EDT) Received: (qmail 18037 invoked by uid 60001); 7 Apr 2000 00:15:35 -0000 Message-ID: <20000407001535.18036.qmail@web106.yahoomail.com> Received: from [128.235.249.42] by web106.yahoomail.com; Thu, 06 Apr 2000 17:15:35 PDT Date: Thu, 6 Apr 2000 17:15:35 -0700 (PDT) From: ken Subject: Re:Biological Wireless Internet To: manet@itd.nrl.navy.mil MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk I will ask payment for that:-) __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-manet@itd.nrl.navy.mil Fri Apr 7 02:52:51 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03864 for ; Fri, 7 Apr 2000 02:52:50 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id AAA03566 for manet-outgoing; Fri, 7 Apr 2000 00:46:14 -0400 (EDT) Received: from mx1.ews.uiuc.edu (mx1.ews.uiuc.edu [130.126.161.237]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id AAA03561 for ; Fri, 7 Apr 2000 00:46:11 -0400 (EDT) Received: from softtooth.com (mgupta1@glsn12.ews.uiuc.edu [130.126.160.98]) by mx1.ews.uiuc.edu (8.9.3/8.9.3) with ESMTP id XAA29165 for ; Thu, 6 Apr 2000 23:46:11 -0500 (CDT) Message-ID: <38ED677D.A54E1EE5@softtooth.com> Date: Thu, 06 Apr 2000 23:43:41 -0500 From: SoftTooth Organization: Engineering Workstations - UIUC X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: manet@itd.nrl.navy.mil Subject: Re:Biological Wireless Internet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Biological Wireless Internet vision extends to bring three big tides of our time together "BioTech" + "Wireless" + "Internet" The context aware Bluetooth enabled Human bodies form adhoc networks where they are and whenever they can ... the network is transparent, seamless and dynamic .... a human interface is exported to the neighbourhood depending on the context ... if you are on the road only the name and profession may be what you would like the people on the road to know about you .... if you are in a job fair, may be you will like your name, profession, interest, skills, experience etc. to be known to the neighbourhood ...... whomever you meet is visually and electronically recorded ..... there is no device on your body ... every device you have is implanted in your body ..... the devices are microdevices (smaller than rice grain) .... You are a router, a server and a client ..... How to connect these local human nets to external world to form a true Internet I think is going to be the biggest challenge ..... should we use people in the cars on the highways to form a net ...... Nothing is very clear .... but a human to human rather than server to server Internet is the call of the future .... One way to build such adhoc networks is by topological mapping of neighbourhood around me such that each node of topology has dynamic membership ..... once a human node comes to that location my body transmits the data using that persons human body ..... surely he should lie in the direction of shortest routed distance which will change depending on the speed of that person and direction of his movement ..... remember that although My topology is fixed, it is moving with me .... so my direction and speed also matters in building a highly dynamic ad hoc network .... also this might work well in densely populated regions ..... as Bluetooth becomes more pervasive we may see networks formed hybrid of human and static devices ...... what is interesting about this vision is that it calls for greater understanding of many more fields than one or two ..... It is the wider integration of BioTech, Wirless, MEMS , Networking, Wearable computing etc. that will pave the way for it ..... Hope this gives you much broader picture of "Biological Wireless Internet" in the perpective of ad hoc network issues .... Hope to see you in our mailing list "BioWireNet" ... you can join it from http://www.softtooth.com/tech/bwn.html Thanks Manoj Gupta SoftTooth.Com ------------------------------------------------- From owner-manet@itd.nrl.navy.mil Fri Apr 7 06:15:20 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05531 for ; Fri, 7 Apr 2000 06:15:19 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id EAA05425 for manet-outgoing; Fri, 7 Apr 2000 04:01:51 -0400 (EDT) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id EAA05420 for ; Fri, 7 Apr 2000 04:01:43 -0400 (EDT) From: jacquet@menetou.inria.fr Received: from prisse (prisse.inria.fr [128.93.9.64]) by nez-perce.inria.fr (8.8.7/8.8.7) with SMTP id KAA11341; Fri, 7 Apr 2000 10:00:53 +0200 (MET DST) Message-Id: <3.0.1.32.20000407100520.00c8dbb0@menetou.inria.fr> X-Sender: jacquet@menetou.inria.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Fri, 07 Apr 2000 10:05:20 +0200 To: SoftTooth , manet@itd.nrl.navy.mil Subject: Re: Biological Wireless Internet In-Reply-To: <38ECBA4F.774451DF@softtooth.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id EAA05421 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit Does SoftTooth work underwater with fishes. It is a tradition in France that revolutions starting at the very beginning of April are strongly related with the fish "Poisson d'avril". Philippe A 11:24 06/04/00 -0500, SoftTooth a écrit : >Hi, > > SoftTooth brings you the concept of "Biological Wireless >Internet". > Check it out at : > > http://www.softtooth.com/tech/bwn.html > > Do join this revolution. > >Manoj Gupta >SoftTooth.Com > >---------------------------------------------------- > From owner-manet@itd.nrl.navy.mil Wed Apr 12 12:38:51 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26870 for ; Wed, 12 Apr 2000 12:38:50 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA14110 for manet-outgoing; Wed, 12 Apr 2000 10:00:34 -0400 (EDT) Received: from taurus.cs.albany.edu (taurus.cs.albany.edu [169.226.2.109]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA14105 for ; Wed, 12 Apr 2000 10:00:26 -0400 (EDT) Received: from karp.cs.albany.edu (karp.cs.albany.edu [169.226.2.52]) by taurus.cs.albany.edu (8.9.3+Sun/8.9.1) with ESMTP id JAA09401; Wed, 12 Apr 2000 09:59:34 -0400 (EDT) From: "S.S.Ravi" Received: (from ravi@localhost) by karp.cs.albany.edu (SMI-8.6/CLI2) id JAA23743; Wed, 12 Apr 2000 09:59:36 -0400 Date: Wed, 12 Apr 2000 09:59:36 -0400 Message-Id: <200004121359.JAA23743@karp.cs.albany.edu> To: dmanet@zpr.uni-koeln.de, im-net-digest@iwr.uni-heidelberg.de, itc@ieee.org, manet@itd.nrl.navy.mil, mobile-ip@standards.nortelnetworks.com, mobility@media.mit.edu, opt-net@zib.de, orcs-l@listserv.okstate.edu, podc-post@research.telcordia.com, tccc@ieee.org, theorynt@listserv.nodak.edu Subject: DIAL M Workshop (Final Call for Papers) Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk (Please accept our apologies if you receive multiple copies.) FINAL CALL FOR PAPERS 4th International Workshop on Discrete Algorithms and Methods for Mobile Computing & Communications (DIALM for Mobility) August 11, 2000 Boston, Massachusetts, USA In conjunction with ACM MobiCom 2000 Sponsored by ACM SIGMOBILE Submission Deadline: April 25, 2000 Workshop URL : http://www.eecis.udel.edu/~elloyd/dialm.d/home.html SCOPE: Mobile computing and communications devices such as portable phones, laptops and palmtops will have an enormous impact on our lifestyle over the next several decades. The introduction of mobility raises a number of new research issues. This workshop is devoted to discrete algorithms and methods in the context of mobile and wireless computing and communications. The workshop is intended to serve as a forum for open discussions and lively debate, and to foster cooperation among practitioners and theoreticians. The workshop encourages submission of papers based on work-in-progress. Proposals for panels designed to generate lively discussions are also invited. Contributions are solicited in all areas related to mobile computing and communications where discrete algorithms and methods are utilized, including, but not limited to: distributed algorithms frequency allocation scheduling location tracking site allocation multihop packet radio networks wireless networks synchronization cryptography and security error correcting codes handover (handoff) telecommunications modeling optimization routing satellite communication PROGRAM CHAIR: Errol L. Lloyd Department of Computer and Information Sciences University of Delaware Newark, DE, USA Email: elloyd@udel.edu PROGRAM COMMITTEE Amotz Bar-Noy, AT&T Labs and Tel Aviv University, Israel Anthony Ephremides, University of Maryland, USA Aura Ganz, University of Massachusetts, USA Juraj Hromkovic, RWTH Aachen, Germany Bo Li, Hong Kong University of Science and Technology, Hong Kong Jason Yi-Bing Lin, National Chiao-Tung University, ROC Errol Lloyd, University of Delaware,USA -- Program Chair Madhav Marathe, Los Alamos National Lab Marina Papatriantafilou, Chalmers Univ. of Technology, Sweden Stephane Perennes, INRIA, France Cynthia Phillips, Sandia National Laboratories, USA Balaji Raghavachari, University of Texas at Dallas, USA S.S. Ravi, SUNY Albany, USA -- Publicity Chair Andrea Richa, Arizona State University, USA Aravind Srinivasan, Bell Labs, USA Martha Steenstrup, BBN, USA Subhash Suri, Washington University, USA Eli Upfal, Brown University, USA Peter Widmayer, ETH Zurich, Switzerland STEERING COMMITTEE Ian Akyildiz, Georgia Tech, USA Maurizio Bonuccelli, University of Pisa, Italy (Chair) Afonso Ferreira, CNRS - I3S - INRIA - Sophia Antipolis, France Arunabha Sen, Arizona State University, USA. SUBMISSION GUIDELINES: All paper submissions and panel proposals will be handled electronically. Authors should e-mail a PostScript version of their full paper to elloyd@udel.edu. The font size should be at least 10 pt. The paper should not be longer than 10 single spaced pages using a standard 10point font. Panel proposals may be submitted in ASCII or PostScript format. A panel proposal should include panel topic, sample questions the panel would address, and proposed panel members and moderator. Since deadlines overlap, dual submission of papers to MobiCom and DIALM is encouraged. Any paper accepted for MobiCom will automatically be removed from consideration for DIALM. To ensure that the PostScript versions of the papers can be printed, use PostScript version 2 or later. Also ensure that the paper fits on "US Letter" size paper (8.5X11 inches). Reference only standard Adobe printer fonts (i.e., Courier, Times, Roman, or Helvetica); other fonts may be used but must be included in the PostScript file. Authors will receive a short email ack of their submission within two days of submission. If this is not received, the authors should contact the Program Chair immediately. Authors should separately email the title, authors, mailing address, and abstract to elloyd@udel.edu. All accepted papers will appear (7 to 10 pages per paper) in the workshop proceedings, which will be published by ACM. A special issue of Discrete Applied Mathematics will be devoted to a selection of submitted papers from this workshop. Full versions of the DIALM papers selected to appear in this special issue of Discrete Applied Mathematics will be subjected to the standard thorough journal refereeing process before final acceptance for the journal. IMPORTANT DATES: Submissions due : April 25, 2000 Acceptance notification: May 15, 2000 Final paper due : June 1, 2000 Workshop : August 11, 2000 From owner-manet@itd.nrl.navy.mil Sun Apr 16 13:04:42 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09068 for ; Sun, 16 Apr 2000 13:04:41 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA01543 for manet-outgoing; Sun, 16 Apr 2000 10:48:46 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA01538 for ; Sun, 16 Apr 2000 10:48:44 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA07163; Sun, 16 Apr 2000 07:48:40 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id HAA28867; Sun, 16 Apr 2000 07:32:10 -0700 X-Virus-Scanned: Sun, 16 Apr 2000 07:32:10 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (maxdialin25.iprg.nokia.com [205.226.20.219]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma028720; Sun, 16 Apr 00 07:32:05 -0700 Message-ID: <38F9D135.95984864@iprg.nokia.com> Date: Sun, 16 Apr 2000 07:41:57 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: dsuprati@in.ibm.com CC: manet@itd.nrl.navy.mil Subject: Re: questions on routing in bluetooth References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Sorry for the long delay in answering. My understanding is that, first, Bluetooth nodes need to set up a master/slave interconnection between first-hop neighbors. After that time, I believe that AODV (and, for that matter, other manet protocols) are applicable to Bluetooth for managing multi-hop routes through scatternets. The more interesting question surrounds the way in which service discovery might be handled. A few months ago, I proposed and then rather quickly retracted a way to adjoin service request details as part of AODV's path discovery algorithm. The idea was that a node might wish to find a route to a particular service instead of a particular IP address. I retracted the proposal because everyone seemed to hate it, since it represented a kind of layer violation. Maybe this idea should be reconsidered. If so, I am willing to make a separate Internet Draft containing the details about Service Request/Reply under AODV. An alternative would be to adapt Service Location Protocol for manet; I do not think there is very much that needs to be done for that to work. Regards, Charlie P. dsuprati@in.ibm.com wrote: > Hi All: > > I was just following the mails over the last few days on routing > in adhoc networks. Can somebody pour some light on what can be the > major issues for routing in Bluetooth kind of adhoc network, where > nodes are charaterized by low or zero mobility? Is it worthwhile > to talk about the same issues of rothing in adhoc networks, > when we talk about routing in Scatternet formed by multiple > Piconets? The AODV or some proactive kind of protocols, if used, > may have to be tweaked appropriately because of the Master slave > Pico-cellular architecture. So, can a Clusterhead routing kind of > thing work well here or there may be drawbacks when applied to BT? > > thanks, > supratim/ibm irl > > ********************************************************************* > SUPRATIM DEB > Phone:+91-11-6861100 (Extn:146) > E-mail: dsuprati@in.ibm.com > > Office: > IBM India Research Lab > Block 1, IIT Delhi, Hauz Khas , New Delhi- 110 016 > 28 deg 54 min North, 77 deg 13 min East From owner-manet@itd.nrl.navy.mil Sun Apr 16 13:51:20 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09243 for ; Sun, 16 Apr 2000 13:51:19 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA02015 for manet-outgoing; Sun, 16 Apr 2000 12:08:47 -0400 (EDT) Received: from sirius.ctr.columbia.edu (sirius.ctr.columbia.edu [128.59.64.60]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id MAA02010 for ; Sun, 16 Apr 2000 12:08:45 -0400 (EDT) Received: from comet.columbia.edu (coltrane.ocs.columbia.edu [128.59.240.174]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id MAA12937; Sun, 16 Apr 2000 12:08:32 -0400 (EDT) Message-ID: <38F9EF8A.397C9E74@comet.columbia.edu> Date: Sun, 16 Apr 2000 12:51:22 -0400 From: campbell Reply-To: campbell@comet.columbia.edu Organization: Center for Telecommunications Research, Columbia University X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Charlie Perkins CC: dsuprati@in.ibm.com, manet@itd.nrl.navy.mil Subject: Re: questions on routing in bluetooth References: <38F9D135.95984864@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi Charlie: I think there is a danger in the line of thought that MANET is a pure 'routing vehicle' and all value added gets piggybacked or integrated in the protocols. There is a separation of concerns here. Your alternative proposal (below) recognizes that. Best, Andrew Charlie Perkins wrote: > > Hello, > > Sorry for the long delay in answering. > > My understanding is that, first, Bluetooth nodes need to set > up a master/slave interconnection between first-hop neighbors. > After that time, I believe that AODV (and, for that matter, > other manet protocols) are applicable to Bluetooth for managing > multi-hop routes through scatternets. > > The more interesting question surrounds the way in which > service discovery might be handled. A few months ago, > I proposed and then rather quickly retracted a way to adjoin > service request details as part of AODV's path discovery > algorithm. The idea was that a node might wish to find a > route to a particular service instead of a particular IP address. > I retracted the proposal because everyone seemed to hate it, > since it represented a kind of layer violation. > > Maybe this idea should be reconsidered. If so, I am willing > to make a separate Internet Draft containing the details about > Service Request/Reply under AODV. An alternative would > be to adapt Service Location Protocol for manet; I do not > think there is very much that needs to be done for that to work. > > Regards, > Charlie P. > > dsuprati@in.ibm.com wrote: > > > Hi All: > > > > I was just following the mails over the last few days on routing > > in adhoc networks. Can somebody pour some light on what can be the > > major issues for routing in Bluetooth kind of adhoc network, where > > nodes are charaterized by low or zero mobility? Is it worthwhile > > to talk about the same issues of rothing in adhoc networks, > > when we talk about routing in Scatternet formed by multiple > > Piconets? The AODV or some proactive kind of protocols, if used, > > may have to be tweaked appropriately because of the Master slave > > Pico-cellular architecture. So, can a Clusterhead routing kind of > > thing work well here or there may be drawbacks when applied to BT? > > > > thanks, > > supratim/ibm irl > > > > ********************************************************************* > > SUPRATIM DEB > > Phone:+91-11-6861100 (Extn:146) > > E-mail: dsuprati@in.ibm.com > > > > Office: > > IBM India Research Lab > > Block 1, IIT Delhi, Hauz Khas , New Delhi- 110 016 > > 28 deg 54 min North, 77 deg 13 min East From owner-manet@itd.nrl.navy.mil Mon Apr 17 15:10:24 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07869 for ; Mon, 17 Apr 2000 15:10:23 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA17554 for manet-outgoing; Mon, 17 Apr 2000 12:34:17 -0400 (EDT) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id MAA17548 for ; Mon, 17 Apr 2000 12:34:11 -0400 (EDT) From: jacquet@menetou.inria.fr Received: from prisse (prisse.inria.fr [128.93.9.64]) by nez-perce.inria.fr (8.8.7/8.8.7) with SMTP id SAA20514; Mon, 17 Apr 2000 18:34:04 +0200 (MET DST) Message-Id: <3.0.1.32.20000417183830.00cd6850@menetou.inria.fr> X-Sender: jacquet@menetou.inria.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Mon, 17 Apr 2000 18:38:30 +0200 To: manet@itd.nrl.navy.mil Subject: assymmetric links Cc: manet@itd.nrl.navy.mil In-Reply-To: <38F9D135.95984864@iprg.nokia.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk We have detected that AODV may enter into a permanent deadlock if a permanent assymmetric link exists. This case may occur since power control may lead to large discrepancies between transmission powers. We think that there are two ways to cope with that problem with "on demand" protocols. One way is to permanently check link symmetry via periodic hellos. The node shall ignore RREQ packets when received from assymmetric nodes. Another way is for each node to maintain a "black list" were assymmetric neighbors are listed. A neighbor node will be detected as assymmetric if the update packet transmission fails (this supposes that MAC layer acknowledges unicast packets). A node is listed in black list during a black_list_holding_time and then the information is discarded (this information cannot be refreshed). A node shall ignore all RREQ packets received from an assymmetric neighbor, i.e. during the time where the neighbor node is listed in black list. What do you think? Philippe From owner-manet@itd.nrl.navy.mil Mon Apr 17 16:26:24 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09187 for ; Mon, 17 Apr 2000 16:26:23 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA20635 for manet-outgoing; Mon, 17 Apr 2000 14:30:22 -0400 (EDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id OAA20629 for ; Mon, 17 Apr 2000 14:30:18 -0400 (EDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 17 Apr 2000 19:29:23 +0100 X-Mailer: exmh version 2.0.2 To: jacquet@menetou.inria.fr cc: manet@itd.nrl.navy.mil Subject: Re: assymmetric links In-reply-to: Your message of "Mon, 17 Apr 2000 18:38:30 +0200." <3.0.1.32.20000417183830.00cd6850@menetou.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Apr 2000 19:29:17 +0100 Message-ID: <21055.955996157@cs.ucl.ac.uk> From: Nikos Triantafillis Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk In message <3.0.1.32.20000417183830.00cd6850@menetou.inria.fr>, jacquet@menetou.inria.fr writes: >We have detected that AODV may enter into a permanent deadlock if a >permanent assymmetric link exists. This case may occur since power control >may lead to large discrepancies between transmission powers. Personally I would be interested to know the hows and the whys of this permanent deadlock. >We think that there are two ways to cope with that problem with "on demand" >protocols. Is the deadlock problem only a problem with AODV? Or have you also looked at other protocols too? >One way is to permanently check link symmetry via periodic hellos. The node >shall ignore RREQ packets when received from assymmetric nodes. >Another way is for each node to maintain a "black list" were assymmetric >neighbors are listed. A neighbor node will be detected as assymmetric if >the update packet transmission fails (this supposes that MAC layer >acknowledges unicast packets). A node is listed in black list during a >black_list_holding_time and then the information is discarded (this >information cannot be refreshed). A node shall ignore all RREQ packets >received from an assymmetric neighbor, i.e. during the time where the >neighbor node is listed in black list. I may be missing something but doesn't that mean that the network and the nodes will be able to take advantage of bidirectional links only? If it does mean that, do we want such constrain in an ad hoc routing protocol? Do we need to look at on mobile ad hoc network routing with unidirectional links too perhaps? I know this has been brought up and debated in the list before but I'm still not convinced that it is or should be outside of the scope of this WG. Thanks, Nick PS:BTW if anyone out there has seen a formal proof or reasoning on the loop and deadlock free properties of the ad hoc routing protocols that have been proposed so far in the group or a performance evaluation of any of the protocols in the presence of unidirectional links, please send me a pointer. From owner-manet@itd.nrl.navy.mil Mon Apr 17 16:47:01 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09588 for ; Mon, 17 Apr 2000 16:47:01 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA21048 for manet-outgoing; Mon, 17 Apr 2000 14:44:17 -0400 (EDT) Received: from babbage.ececs.uc.edu (mail.ececs.uc.edu [129.137.8.2]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA21035 for ; Mon, 17 Apr 2000 14:44:10 -0400 (EDT) Received: from ececs.uc.edu (wayward.ececs.uc.edu [129.137.9.117]) by babbage.ececs.uc.edu (8.9.3+Sun/8.9.3) with ESMTP id OAA27739; Mon, 17 Apr 2000 14:43:44 -0400 (EDT) Message-ID: <38FB5B48.4405EDE@ececs.uc.edu> Date: Mon, 17 Apr 2000 14:43:20 -0400 From: "Samir R. Das" Organization: University of Cincinnati X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: jacquet@menetou.inria.fr CC: manet@itd.nrl.navy.mil Subject: Re: assymmetric links References: <3.0.1.32.20000417183830.00cd6850@menetou.inria.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit jacquet@menetou.inria.fr wrote: > > We have detected that AODV may enter into a permanent deadlock if a > permanent assymmetric link exists. This case may occur since power control > may lead to large discrepancies between transmission powers. True, AODV will not work in presense of asymmetric links without any modification. > We think that there are two ways to cope with that problem with "on demand" > protocols. > > One way is to permanently check link symmetry via periodic hellos. The node > shall ignore RREQ packets when received from assymmetric nodes. I assume that you want to mean that the neighbor will tell you via hello whether it can hear you. So the hello messages will contain the one-hop neighbors for it to work. Yes, I think it will work. > Another way is for each node to maintain a "black list" were assymmetric > neighbors are listed. A neighbor node will be detected as assymmetric if > the update packet transmission fails (this supposes that MAC layer > acknowledges unicast packets). A node is listed in black list during a > black_list_holding_time and then the information is discarded (this > information cannot be refreshed). A node shall ignore all RREQ packets > received from an assymmetric neighbor, i.e. during the time where the > neighbor node is listed in black list. I am not sure I follow you here. If you are using MAC layer acks, then you are implicitly working with only symmetric links. An asymmetric link will appear to you as no link. Why do you need to do anything additional? > What do you think? > > Philippe Samir From owner-manet@itd.nrl.navy.mil Mon Apr 17 18:18:18 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10682 for ; Mon, 17 Apr 2000 18:18:17 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA23536 for manet-outgoing; Mon, 17 Apr 2000 16:10:42 -0400 (EDT) Received: from ns0.utdallas.edu (ns0.utdallas.edu [129.110.10.1]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA23531 for ; Mon, 17 Apr 2000 16:10:40 -0400 (EDT) Received: from apache.utdallas.edu (apache.utdallas.edu [129.110.16.9]) by ns0.utdallas.edu (Postfix) with ESMTP id 7BF551A0260 for ; Mon, 17 Apr 2000 15:10:02 -0500 (CDT) Received: from localhost (sanket@localhost) by apache.utdallas.edu (8.9.1/8.9.1) with ESMTP id PAA24005 for ; Mon, 17 Apr 2000 15:10:41 -0500 (CDT) X-Authentication-Warning: apache.utdallas.edu: sanket owned process doing -bs Date: Mon, 17 Apr 2000 15:10:40 -0500 (CDT) From: Sanket S Nesargi To: Mobile Ad-hoc Networks Subject: Re: assymmetric links Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi, The assumption of symmetric links is not limited to AODV, few other protocols also make this assumption (eg., TORA). A solution to this problem has been addressed in the paper by Prakash presented at DIALM last year. The approach proposed here works on each node maintaining a list nodes which it can reach directly, as well as the nodes from which it can be reached directly. This information is propagated in the routing messages. The topology information is maintained as a matrix and unidirectional links are easily identified. This enables nodes to make use of the unidirectional links correctly. However a N * N matrix needs to be maintained and exchanged, where N is the number of nodes in the system. When the system size is large, the overhead can be significant. This needs to be reduced. Currently, we are working on an approach based on tunneling link layer ACKs and routing updates in a strongly connected ad hoc network, containing unidirectional links. Tunneling is done by encapsulating the link layer packets and routing updates in IP packets and using standard routing for them (based on paths established by the routing protocol ,neglecting the presence of unidirectional links). This allows the node at the head of the unidirectional link to make use of it. This should enable routing protocols that assume symmetric links, to work across unidirectional links effectively. This work is nearing completion, and I shall be posting a write up of it in the next couple of weeks. Thanks, - Sanket Sanket Nesargi University of Texas at Dallas Richardson, TX 75080 From owner-manet@itd.nrl.navy.mil Tue Apr 18 08:04:02 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01774 for ; Tue, 18 Apr 2000 08:04:01 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id FAA04174 for manet-outgoing; Tue, 18 Apr 2000 05:53:21 -0400 (EDT) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id FAA04169 for ; Tue, 18 Apr 2000 05:53:17 -0400 (EDT) From: jacquet@menetou.inria.fr Received: from prisse (prisse.inria.fr [128.93.9.64]) by nez-perce.inria.fr (8.8.7/8.8.7) with SMTP id LAA11822; Tue, 18 Apr 2000 11:53:12 +0200 (MET DST) Message-Id: <3.0.1.32.20000418115740.00cb8d50@menetou.inria.fr> X-Sender: jacquet@menetou.inria.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Tue, 18 Apr 2000 11:57:40 +0200 To: Nikos Triantafillis Subject: Re: assymmetric links Cc: manet@itd.nrl.navy.mil In-Reply-To: <21055.955996157@cs.ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Dear Nikos, We don't think it is specific to AODV, other protocols based on route discovery via flooding may also be concerned. About the principle of using unidirectional link for routing, this is another story and I don't discuss this topic. However unicast transmissions need bidirectional links on IEEE 802.11 and HIPERLAN. Our aim is to discuss about a possible improvement of AODV in case of permanent assymmetric links. We tried to keep the "on demand" spirit (i.e. no periodic hellos). I don't know if we are succesful. About the problem, there is no global deadlock of the protocol and maybe we are wrong. It seems that some nodes may never get access to some destinations. For example assume that the source A has a lot of power (for example a powered fixed station or something equivalent on a vehicle) and a chain of low power nodes B, C, D, ... A----B----C----D----E----F----G---H--- \............> Links between A and B, B-C, C-D, etc, are symmetric links. But nodes A has unidirectional links to C and D (C and D hear A but are not heared by A). If A wants a route to F (or G, H,...) it floods a RREQ. The RREQ is simultaneously received by B, C and D which list A as precursor. Forward from B and C are ignored by C and D. D forwards to E and then E to F. F returns via the reverse route which fails on the link D-A. If A repeats the flooding again, then the failure will occur again. The idea of the "black list" is that when D will detect that it has an assymmetric link with A (e.g. by receiving no ACK from IEEE 802.11 MAC layer), D will never forward any broadcast packet directly received from A. Doing so D will forward RREQ exclusively received from C. The problem with the black list is that this kind of information cannot be updated and the entries must be timed out. Does it make sense? Philippe From owner-manet@itd.nrl.navy.mil Tue Apr 18 08:04:16 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01785 for ; Tue, 18 Apr 2000 08:04:13 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id GAA04325 for manet-outgoing; Tue, 18 Apr 2000 06:11:42 -0400 (EDT) Received: from color.sics.se (color.sics.se [193.10.66.199]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id GAA04320 for ; Tue, 18 Apr 2000 06:11:24 -0400 (EDT) Received: from kanin.sics.se (kanin.sics.se [193.10.65.146]) by color.sics.se (8.9.3/8.9.3) with ESMTP id MAA26221; Tue, 18 Apr 2000 12:11:20 +0200 (MET DST) env-from (lmfeeney@color.sics.se) Received: (from lmfeeney@localhost) by kanin.sics.se (8.8.7/8.8.7) id MAA00469; Tue, 18 Apr 2000 12:11:20 +0200 Date: Tue, 18 Apr 2000 12:11:20 +0200 Message-Id: <200004181011.MAA00469@kanin.sics.se> X-Authentication-Warning: kanin.sics.se: lmfeeney set sender to lmfeeney@kanin.sics.se using -f From: Laura Feeney To: sdas@ececs.uc.edu CC: jacquet@menetou.inria.fr, manet@itd.nrl.navy.mil In-reply-to: <38FB5B48.4405EDE@ececs.uc.edu> (sdas@ececs.uc.edu) Subject: Re: asymmetric links References: <3.0.1.32.20000417183830.00cd6850@menetou.inria.fr> <38FB5B48.4405EDE@ececs.uc.edu> Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi, I think there is some confusion here about what people mean when they say "assuming symmetric links". A situation involving asymmetric wireless connectivity is something that happens at the physical layer. Using IEEE 802.11, this means that a broadcast message sent by host A is received at host B, but a broadcast message sent by host B is not received at host A. Host A can't send a point-to-point message to host B because B can't send the CTS/ACK to host A. Even if an ad hoc routing protocol does not "use" this asymmetric link, it exists and the protocol can get tripped up by it, especially in on-demand route discovery. In the case of AODV, this means that a sequence of (broadcast) route_request messages can ``discover'' a route along which the (point-to-point) route_reply message can't be sent because it is dropped at the asymmetric link. If the destination continues to respond to route_requests which have traveled via this link, the source will reinitiate the route discovery process in vain. I recall having a discussion about this with David Maltz some time ago and he suggested that DSR can avoid this problem by having the destination reply to all route_requests. For DSR, this has the advantage of distributing additional topology information. (I'm sorry, David, I don't remember whether we talked about this in person or online; so stomp on me if I'm misquoting you. :-) Laura >>>>> "Samir R. Das" writes: Samir> jacquet@menetou.inria.fr wrote: >> We have detected that AODV may enter into a permanent deadlock if >> a permanent assymmetric link exists. This case may occur since >> power control may lead to large discrepancies between transmission >> powers. Samir> True, AODV will not work in presense of asymmetric links Samir> without any modification. >> We think that there are two ways to cope with that problem with "on >> demand" protocols. >> >> One way is to permanently check link symmetry via periodic >> hellos. The node shall ignore RREQ packets when received from >> assymmetric nodes. Samir> I assume that you want to mean that the neighbor will tell you Samir> via hello whether it can hear you. So the hello messages will Samir> contain the one-hop neighbors for it to work. Yes, I think it Samir> will work. >> Another way is for each node to maintain a "black list" were >> assymmetric neighbors are listed. A neighbor node will be detected >> as assymmetric if the update packet transmission fails (this >> supposes that MAC layer acknowledges unicast packets). A node is >> listed in black list during a black_list_holding_time and then the >> information is discarded (this information cannot be refreshed). A >> node shall ignore all RREQ packets received from an assymmetric >> neighbor, i.e. during the time where the neighbor node is listed in >> black list. Samir> I am not sure I follow you here. If you are using MAC layer Samir> acks, then you are implicitly working with only symmetric Samir> links. An asymmetric link will appear to you as no link. Why Samir> do you need to do anything additional? >> What do you think? >> >> Philippe Samir> Samir -- Laura Marie Feeney lmfeeney@sics.se Visiting Researcher http://www.sics.se/ Computer and Network Architectures Lab Tel: +46 8 633 15 09 Swedish Institute of Computer Science Mobile: +46 70 246 56 63 Box 1263, SE-164 29 KISTA, SWEDEN Fax: +46 8 751 72 30 From owner-manet@itd.nrl.navy.mil Tue Apr 18 09:35:57 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04438 for ; Tue, 18 Apr 2000 09:35:57 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id HAA05791 for manet-outgoing; Tue, 18 Apr 2000 07:45:03 -0400 (EDT) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id HAA05786 for ; Tue, 18 Apr 2000 07:44:51 -0400 (EDT) From: jacquet@menetou.inria.fr Received: from prisse (prisse.inria.fr [128.93.9.64]) by nez-perce.inria.fr (8.8.7/8.8.7) with SMTP id NAA13821; Tue, 18 Apr 2000 13:44:24 +0200 (MET DST) Message-Id: <3.0.1.32.20000418134851.00c5e4a0@menetou.inria.fr> X-Sender: jacquet@menetou.inria.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Tue, 18 Apr 2000 13:48:51 +0200 To: Laura Feeney , sdas@ececs.uc.edu Subject: Re: asymmetric links Cc: manet@itd.nrl.navy.mil In-Reply-To: <200004181011.MAA00469@kanin.sics.se> References: <38FB5B48.4405EDE@ececs.uc.edu> <3.0.1.32.20000417183830.00cd6850@menetou.inria.fr> <38FB5B48.4405EDE@ececs.uc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id HAA05787 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit Hmm, I think AODV destination also reply to all RREQ's. But I don't think it solves the problem. In the example I give, the destination receives only one RREQ and it is a wrong one. Philippe A 12:11 18/04/00 +0200, Laura Feeney a écrit : >I recall having a discussion about this with David Maltz some time ago >and he suggested that DSR can avoid this problem by having the >destination reply to all route_requests. For DSR, this has the >advantage of distributing additional topology information. (I'm >sorry, David, I don't remember whether we talked about this in person >or online; so stomp on me if I'm misquoting you. :-) > >Laura From owner-manet@itd.nrl.navy.mil Tue Apr 18 09:44:46 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04591 for ; Tue, 18 Apr 2000 09:44:44 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id HAA05220 for manet-outgoing; Tue, 18 Apr 2000 07:27:42 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id HAA05213 for ; Tue, 18 Apr 2000 07:27:37 -0400 (EDT) Received: from regan.ee.surrey.ac.uk ([131.227.89.11] helo=ee.surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12hWAB-00056f-00; Tue, 18 Apr 2000 12:27:27 +0100 Message-ID: <38FC46A0.60AB521F@ee.surrey.ac.uk> Date: Tue, 18 Apr 2000 12:27:28 +0100 From: George Aggelou Organization: University of Surrey, Guildford, England X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Nikos Triantafillis , manet Subject: Re: assymmetric links References: <21055.955996157@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Nikos > > >Another way is for each node to maintain a "black list" were assymmetric > >neighbors are listed. A neighbor node will be detected as assymmetric if > >the update packet transmission fails (this supposes that MAC layer > >acknowledges unicast packets). A node is listed in black list during a > >black_list_holding_time and then the information is discarded (this > >information cannot be refreshed). A node shall ignore all RREQ packets > >received from an assymmetric neighbor, i.e. during the time where the > >neighbor node is listed in black list. > > I may be missing something but doesn't that mean that the network and the > nodes will be able to take advantage of bidirectional links only? Nick, My understanding is that "yes" and I do not fully agree with Philippe here as this can put alot of constraints on the routing protocol and on the MAC protocol as well. > If it does > mean that, do we want such constrain in an ad hoc routing protocol? Do we need > to look at on mobile ad hoc network routing with unidirectional links too > perhaps? My opinion is "yes and no".. At first, remember that among the factors which could make a wireless link unidirectional are interference and differing radio capabilities. I believe it really depends on the depth you are willing to simulate a MANET routing protocol. That is, along with the routing protocol does your simulator incorporate MAC and PHY layer stuff as well? If so, I believe that asymmetry in wireless links is a factor that should be taken into account as it does influence the relative performance of MAC _and_ hence of the routing protocol as well. An open issue though is *how much* this affects the performance of a routing protocol. If now your simulator does not include any such stuff from MAC and PHY layers, then I don;t see the real benefit of messing around with link asymmetry wich is a concern caused from wireless channel conditions and power fluctuations. > Thanks, > > Nick > > PS:BTW if anyone out there has seen a formal proof or reasoning on the loop > and deadlock free properties of the ad hoc routing protocols that have been > proposed so far in the group or a performance evaluation of any of the > protocols in the presence of unidirectional links, please send me a pointer. About loop-freedom you can see the appendix of DSDV paper from Charlie and Pravin Bhagwat at SIGCOMM 1994 (hope 'm correct for the year..:) Regards, George A. -- *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. George Aggelou Centre for Communications Systems Research Mobile Communications Research Group University of Surrey http://www.ee.surrey.ac.uk/Personal/G.Aggelou *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. From owner-manet@itd.nrl.navy.mil Tue Apr 18 12:56:59 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08051 for ; Tue, 18 Apr 2000 12:56:57 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA09432 for manet-outgoing; Tue, 18 Apr 2000 10:29:25 -0400 (EDT) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA09420 for ; Tue, 18 Apr 2000 10:29:02 -0400 (EDT) From: jacquet@menetou.inria.fr Received: from prisse (prisse.inria.fr [128.93.9.64]) by nez-perce.inria.fr (8.8.7/8.8.7) with SMTP id QAA17198; Tue, 18 Apr 2000 16:28:48 +0200 (MET DST) Message-Id: <3.0.1.32.20000418163316.00c5f330@menetou.inria.fr> X-Sender: jacquet@menetou.inria.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Tue, 18 Apr 2000 16:33:16 +0200 To: George Aggelou , Nikos Triantafillis , manet Subject: Re: assymmetric links In-Reply-To: <38FC46A0.60AB521F@ee.surrey.ac.uk> References: <21055.955996157@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id KAA09428 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit A 12:27 18/04/00 +0100, George Aggelou a écrit : >> I may be missing something but doesn't that mean that the network and the >> nodes will be able to take advantage of bidirectional links only? > >Nick, > >My understanding is that "yes" and I do not fully agree with Philippe >here as this can put alot of constraints on the routing protocol and on >the MAC protocol as well. I probably missed something here. I just said that AODV (DSR?) in its present form may have problems if there is a permanent asymmetric link in the network and there are remedies for that when detected. The question whether AODV can take advantage of asymmetric links is another question. Philippe From owner-manet@itd.nrl.navy.mil Wed Apr 19 10:14:06 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06929 for ; Wed, 19 Apr 2000 10:14:02 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id HAA28581 for manet-outgoing; Wed, 19 Apr 2000 07:43:41 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id HAA28575 for ; Wed, 19 Apr 2000 07:43:34 -0400 (EDT) Received: from regan.ee.surrey.ac.uk ([131.227.89.11] helo=ee.surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 12hstF-00014q-00; Wed, 19 Apr 2000 12:43:29 +0100 Message-ID: <38FD9BDC.27EC58F5@ee.surrey.ac.uk> Date: Wed, 19 Apr 2000 12:43:24 +0100 From: George Aggelou Organization: University of Surrey, Guildford, England X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: jacquet@menetou.inria.fr, manet Subject: Re: assymmetric links References: <3.0.1.32.20000418115740.00cb8d50@menetou.inria.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit > About the problem, there is no global deadlock of the protocol and maybe we > are wrong. It seems that some nodes may never get access to some > destinations. For example assume that the source A has a lot of power (for > example a powered fixed station or something equivalent on a vehicle) and a > chain of low power nodes B, C, D, ... > > A----B----C----D----E----F----G---H--- > \............> > > Links between A and B, B-C, C-D, etc, are symmetric links. But nodes A has > unidirectional links to C and D (C and D hear A but are not heared by A). > > If A wants a route to F (or G, H,...) it floods a RREQ. The RREQ is > simultaneously received by B, C and D which list A as precursor. Forward > from B and C are ignored by C and D. D forwards to E and then E to F. F > returns via the reverse route which fails on the link D-A. If A repeats the > flooding again, then the failure will occur again. > > The idea of the "black list" is that when D will detect that it has an > assymmetric link with A (e.g. by receiving no ACK from IEEE 802.11 MAC > layer), D will never forward any broadcast packet directly received from A. > Doing so D will forward RREQ exclusively received from C. The problem with > the black list is that this kind of information cannot be updated and the > entries must be timed out. Hallo Philippe, A few thoughts on your comments: a) Asymmetric link and unidirectional link are two different things. A link between nodes A and B is asymmetric when the data rate from A to B is different from this from B to A. Unidirectional link has to do with the transmission powers of the two nodes. A link between A and B is deemed as unidirectional when A for example is within B's transmission range while B not, due to differing transmission capabilities or wireless channel impairments. b) A few words on your comment: "It seems that some nodes may never get access to some destinations", with no intend to harm AODV..-:) There is an inherent concern on the way query quenching works in some of the existing MANET protocols (including AODV and DSR for example), as it may happen that a RREQ message may never reach its destination. This is not only due to the different power transmission levels of the nodes (this is not a problem specific to AODV as you also mention, but also to any MANET routing protocol I believe), but because the neighbors of the RREQ's destination may always have fresh routing info about that node and send RREPs on its behalf. Apart from being a concern, is this a problem then? I believe yes! Apart from load balancing concerns at high loads and incorrect routes carried in RREPs (see the MobiComm98 paper from Maltz/Broch), a scenario that comes in my mind that _could_ be problematic using query quenching schemes is QoS-based routing. As reservations need to be established on an end-to-end basis (see RSVP), then an end-to-end routing protocol is also required. (and a bit of RDMAR publicity...-:) You may want to have a look on our RDMAR protocol (http://www.ee.surrey.ac.uk/Personal/G.Aggelou/publications.html) where Route Discovery is an end-to-end process and problems related to incorrect RREPs as well as to reservation set-up are avoided. Thanks and Happy Easter! George A. -- *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. George Aggelou Centre for Communications Systems Research Mobile Communications Research Group University of Surrey http://www.ee.surrey.ac.uk/Personal/G.Aggelou *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. From owner-manet@itd.nrl.navy.mil Wed Apr 19 11:20:44 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08041 for ; Wed, 19 Apr 2000 11:20:43 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id IAA29515 for manet-outgoing; Wed, 19 Apr 2000 08:39:29 -0400 (EDT) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id IAA29507 for ; Wed, 19 Apr 2000 08:39:24 -0400 (EDT) From: jacquet@menetou.inria.fr Received: from prisse (prisse.inria.fr [128.93.9.64]) by nez-perce.inria.fr (8.8.7/8.8.7) with SMTP id OAA16067; Wed, 19 Apr 2000 14:38:35 +0200 (MET DST) Message-Id: <3.0.1.32.20000419144304.00c44e40@menetou.inria.fr> X-Sender: jacquet@menetou.inria.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Wed, 19 Apr 2000 14:43:04 +0200 To: "Samir R. Das" Subject: Re: assymmetric links Cc: manet@itd.nrl.navy.mil In-Reply-To: <38FB5B48.4405EDE@ececs.uc.edu> References: <3.0.1.32.20000417183830.00cd6850@menetou.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id IAA29509 Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 8bit Samir, As far as I know, MAC layers use ack only for unicast packets not for broadcast packets. But route request RREQ are broadcast packets and it seems that bidirectional link are not checked during broadcast transmissions. Philippe A 14:43 17/04/00 -0400, Samir R. Das a écrit : > >I am not sure I follow you here. If you are using MAC layer >acks, then you >are implicitly working with only symmetric links. An asymmetric >link will appear >to you as no link. Why do you need to do anything additional? > From owner-manet@itd.nrl.navy.mil Wed Apr 19 12:44:42 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09794 for ; Wed, 19 Apr 2000 12:44:41 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA01644 for manet-outgoing; Wed, 19 Apr 2000 09:58:52 -0400 (EDT) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA01635 for ; Wed, 19 Apr 2000 09:58:42 -0400 (EDT) From: jacquet@menetou.inria.fr Received: from prisse (prisse.inria.fr [128.93.9.64]) by nez-perce.inria.fr (8.8.7/8.8.7) with SMTP id PAA17711; Wed, 19 Apr 2000 15:58:05 +0200 (MET DST) Message-Id: <3.0.1.32.20000419160235.00c9aeb0@menetou.inria.fr> X-Sender: jacquet@menetou.inria.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Wed, 19 Apr 2000 16:02:35 +0200 To: George Aggelou , manet Subject: Re: assymmetric links In-Reply-To: <38FD9BDC.27EC58F5@ee.surrey.ac.uk> References: <3.0.1.32.20000418115740.00cb8d50@menetou.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Dear George, Yes you are right, with your definition of asymmetric links, the problem arises with unidirectional links. Sorry for the confusion! By query quenching you mean that B may generate a RREP after A's RREQ? But this implies that B have before asked for a route to F. In the example I gave, it is not even clear that B will be able to get a route to F if its own RREQ's go via A. Thanks, I will look at RDMAR. Philippe From owner-manet@itd.nrl.navy.mil Mon Apr 24 14:48:04 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11977 for ; Mon, 24 Apr 2000 14:48:04 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA02019 for manet-outgoing; Mon, 24 Apr 2000 12:32:23 -0400 (EDT) Received: from sargasso.cse.msu.edu (sargasso.cse.msu.edu [35.9.20.14]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id MAA02014 for ; Mon, 24 Apr 2000 12:32:20 -0400 (EDT) Received: from cadmium.cse.msu.edu (cadmium.cse.msu.edu [35.9.27.32]) by sargasso.cse.msu.edu (8.8.8/8.8.8) with SMTP id MAA26610 for ; Mon, 24 Apr 2000 12:31:09 -0400 (EDT) Date: Mon, 24 Apr 2000 12:29:23 -0400 (EDT) From: Dmitri Deshun Perkins To: manet@itd.nrl.navy.mil Subject: ad hoc routing,and Bluetooth Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hello, I a PhD student in the initial stages (literature review, etc) of my work and have read much of the work(routing protocols) in the MANET WG. I am very interested in pursuing this area as a research focus. I have also read many of the articles concerning the Bluetooth technology. Although I am fairly new to this area, it seems to me (I could be mistaken) that the MANET work and the Bluetooth work are somehow complimentary (at least conceptually). Is there anyone who can comment on (or point me to arcticles that discuss) how/if ad hoc routing is related to or can be used in a "Bluetooth environment"? Please excuse and inform me if these questions are inappropriate for this forum. Thanks for your time and patience, D. Perkins From owner-manet@itd.nrl.navy.mil Mon Apr 24 16:11:20 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13821 for ; Mon, 24 Apr 2000 16:11:19 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA04303 for manet-outgoing; Mon, 24 Apr 2000 14:13:38 -0400 (EDT) Received: from hadar.cse.Buffalo.EDU (hadar.cse.Buffalo.EDU [128.205.32.1] (may be forged)) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA04298 for ; Mon, 24 Apr 2000 14:13:35 -0400 (EDT) Received: (from hongyiwu@localhost) by hadar.cse.Buffalo.EDU (8.9.3/8.9.3) id OAA04824; Mon, 24 Apr 2000 14:13:31 -0400 (EDT) Date: Mon, 24 Apr 2000 14:13:31 -0400 (EDT) From: Hongyi Wu To: Dmitri Deshun Perkins cc: manet@itd.nrl.navy.mil Subject: Re: ad hoc routing,and Bluetooth In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Hi, Dmitri : I am a Ph.D student too. Based on my understanding, Bluetooth is a special Ad-Hoc network, which has very low mobility and normally short transmission range. You may find a lot of interesting information on http://www.bluetooth.com/. On Mon, 24 Apr 2000, Dmitri Deshun Perkins wrote: > > > Hello, > > > I a PhD student in the initial stages (literature review, etc) of my work > and have read much of the work(routing protocols) in the MANET WG. I am > very interested in pursuing this area as a research focus. > > I have also read many of the articles concerning the Bluetooth technology. > > Although I am fairly new to this area, it seems to me (I could be > mistaken) that the MANET work and the Bluetooth work are somehow > complimentary (at least conceptually). Is there anyone who can comment on > (or point me to arcticles that discuss) how/if ad hoc routing is related > to or can be used in a "Bluetooth environment"? > > Please excuse and inform me if these questions are inappropriate for > this forum. > > > Thanks for your time and patience, > D. Perkins > > > ------------------------------------------------------------------------ Hongyi Wu Phone: (716) 832-4572 E-mail: hongyiwu@cse.buffalo.edu URL: http://www.cse.buffalo.edu/~hongyiwu ------------------------------------------------------------------------ From owner-manet@itd.nrl.navy.mil Mon Apr 24 16:37:54 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14428 for ; Mon, 24 Apr 2000 16:37:53 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA05081 for manet-outgoing; Mon, 24 Apr 2000 14:42:41 -0400 (EDT) Received: from [140.32.132.66] (monterey.nps.navy.mil [131.120.18.26]) by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id OAA05075 for ; Mon, 24 Apr 2000 14:42:39 -0400 (EDT) Received: from monterey.nps.navy.mil by [140.32.132.66] via smtpd (for s2.itd.nrl.navy.mil [132.250.83.3]) with SMTP; 24 Apr 2000 18:42:43 UT Received: by monterey.nps.navy.mil with Internet Mail Service (5.5.2650.21) id <2DWQRT5K>; Mon, 24 Apr 2000 11:42:37 -0700 Message-ID: <0AD4772240C8D211ACEA00A0C99DBB0A564E2E@saipan.nps.navy.mil> From: "Theriot, Tyrone" To: "'manet@itd.nrl.navy.mil'" Subject: 802.11 OPNET model Date: Mon, 24 Apr 2000 11:42:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk NRL, I am interested in the work NRL has done on OPNET simulations model for 802.11. I am a USMC grad student at Naval Postgraduate school in Monterey doing a thesis on 802.11. In particular, I'm working on looking at the MAC layer for 802.11 and comparing it to Bluetooth/WAP. Any assistance (OPNET models) you could provide would be greatly appreciated. Thank you, Ty Theriot Captain USMC MSEE student From owner-manet@itd.nrl.navy.mil Mon Apr 24 16:46:31 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14601 for ; Mon, 24 Apr 2000 16:46:31 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA05521 for manet-outgoing; Mon, 24 Apr 2000 15:00:24 -0400 (EDT) Received: from papa.casa.com ([213.0.67.204]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA05515 for ; Mon, 24 Apr 2000 15:00:18 -0400 (EDT) Received: from disca.upv.es (IDENT:misan@localhost [127.0.0.1]) by papa.casa.com (8.9.3/8.9.3) with ESMTP id UAA01535; Mon, 24 Apr 2000 20:55:22 +0200 Message-ID: <39049899.648A53C@disca.upv.es> Date: Mon, 24 Apr 2000 20:55:21 +0200 From: Miguel Sanchez X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 To: Dmitri Deshun Perkins CC: manet@itd.nrl.navy.mil Subject: Re: ad hoc routing,and Bluetooth References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk Content-Transfer-Encoding: 7bit Hi Dmitri, Just as a personal opinion, I do not think MANET and Bluetooth are very much complementary although other people can think the opossite. From the initial statement of each technology: 1) Manet: networks made of set of nodes that act as routers too and use IP protocol stack(we are at IETF after all). 2) Bluetooth: Radio technology to "cut the cord" intended for PDAs, cellphones and the like. Ok, you can, theoretically build something resemling a MANET with physical and MAC layers of Bluetooth networks. In fact what can make Bluetooth attractive is the expected very low cost of radio transceivers. But remember, Bluetooth is intended to 10 meters of coverage (and up to 100 meters with some power extended mode ...?). However, I think that 10 meters of transmission range is too low for most of the MANET applications and the Bluetooth MAC level can imposse some limitations too. Some weeks ago it was discussed on the list this same topic. If you cannot access to previous postings I think that authors can send you a copy. Best wishes, Miguel Sanchez Universidad Politecnica de Valencia (Spain) PS: Sorry, I see I'm not answering your question, however I thought you also wanted some comments and this is my two cents one. Dmitri Deshun Perkins wrote: > Hello, > > I a PhD student in the initial stages (literature review, etc) of my work > and have read much of the work(routing protocols) in the MANET WG. I am > very interested in pursuing this area as a research focus. > > I have also read many of the articles concerning the Bluetooth technology. > > Although I am fairly new to this area, it seems to me (I could be > mistaken) that the MANET work and the Bluetooth work are somehow > complimentary (at least conceptually). Is there anyone who can comment on > (or point me to arcticles that discuss) how/if ad hoc routing is related > to or can be used in a "Bluetooth environment"? > > Please excuse and inform me if these questions are inappropriate for > this forum. > > Thanks for your time and patience, > D. Perkins From owner-manet@itd.nrl.navy.mil Mon Apr 24 17:28:29 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15470 for ; Mon, 24 Apr 2000 17:28:27 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA06228 for manet-outgoing; Mon, 24 Apr 2000 15:29:29 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA06223 for ; Mon, 24 Apr 2000 15:29:22 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id MAA24417; Mon, 24 Apr 2000 12:29:18 -0700 (MST)] Received: [from relay1.cig.mot.com (relay1.cig.mot.com [136.182.15.23]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id MAA01813; Mon, 24 Apr 2000 12:29:17 -0700 (MST)] Received: from Motorola.Com (dr05_239.il33.wes.mot.com [154.56.5.239]) by relay1.cig.mot.com (8.8.8+Sun/SCERG-RELAY-1.11b) with ESMTP id OAA05496; Mon, 24 Apr 2000 14:29:17 -0500 (CDT) Message-ID: <39049DCF.532C6CAC@Motorola.Com> Date: Mon, 24 Apr 2000 14:17:35 -0500 From: Phil Neumiller Organization: Personal Area Networking (PAN) X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Hongyi Wu CC: Dmitri Deshun Perkins , manet@itd.nrl.navy.mil Subject: Re: ad hoc routing,and Bluetooth References: Content-Type: multipart/mixed; boundary="------------BB5E9B407FE11F4231BD6DC3" Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk This is a multi-part message in MIME format. --------------BB5E9B407FE11F4231BD6DC3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Perhaps, by low mobility you really mean low velocity of the personal terminal devices. (Although this may not be the case for a network flying around in an airplane). In the case of the Internet world, inter-domain mobility is usually referred to as macro-mobility and this would map more or less macro-cellular wireless systems. Micro-mobility (or maybe its called Edge-mobility these days) refers to intra-domain mobility which allows host based forwarding. You might also be interested in: http://search.ietf.org/internet-drafts/draft-oneill-ema-01.txt Which discusses: Mobile IP, Cellular IP, and HAWAII Personal area networking (PAN) equipment may indeed have many more re-associations or "handovers" than classic cell phones due to the tiny physical size of the networks so its a matter of perspective of whether its highly mobile or not. We could call this pico-mobility but I'll probably get yelled at by somebody who uses this term for something else. I think the MANET work has an incredible amount to offer Bluetooth and Bluetooth can can act as a MANET testbed. However, I would hate to see MANET be developed just for Bluetooth though, and MANET must strive to be air interface agnostic as much as possible. Hongyi Wu wrote: > > Hi, Dmitri : > > I am a Ph.D student too. Based on my understanding, Bluetooth is a special > Ad-Hoc network, which has very low mobility and normally short > transmission range. You may find a lot of interesting information on > http://www.bluetooth.com/. > > On Mon, 24 Apr 2000, Dmitri Deshun Perkins wrote: > > > > > > > Hello, > > > > > > I a PhD student in the initial stages (literature review, etc) of my work > > and have read much of the work(routing protocols) in the MANET WG. I am > > very interested in pursuing this area as a research focus. > > > > I have also read many of the articles concerning the Bluetooth technology. > > > > Although I am fairly new to this area, it seems to me (I could be > > mistaken) that the MANET work and the Bluetooth work are somehow > > complimentary (at least conceptually). Is there anyone who can comment on > > (or point me to arcticles that discuss) how/if ad hoc routing is related > > to or can be used in a "Bluetooth environment"? > > > > Please excuse and inform me if these questions are inappropriate for > > this forum. > > > > > > Thanks for your time and patience, > > D. Perkins > > > > > > > > ------------------------------------------------------------------------ > Hongyi Wu > Phone: (716) 832-4572 > E-mail: hongyiwu@cse.buffalo.edu > URL: http://www.cse.buffalo.edu/~hongyiwu > ------------------------------------------------------------------------ --------------BB5E9B407FE11F4231BD6DC3 Content-Type: text/x-vcard; charset=us-ascii; name="Phillip.Neumiller.vcf" Content-Description: Card for Phil Neumiller Content-Disposition: attachment; filename="Phillip.Neumiller.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Neumiller;Phillip tel;pager:1258338@skytel.com tel;cell:iDen 847-9804238 / CDMA 847-370-3899 tel;home:847-516-2009 tel;work:847-576-9624 x-mozilla-html:TRUE url:www.mot.com/bluetooth org:Motorola, Inc.;Personal Area Networking (PAN) adr:;;50 E Commerce Drive;Schaumburg;IL;60195;USA version:2.1 email;internet:Phillip.Neumiller@Motorola.com title:Advanced Standards and Architecture fn:Phil Neumiller end:vcard --------------BB5E9B407FE11F4231BD6DC3-- From owner-manet@itd.nrl.navy.mil Mon Apr 24 21:07:42 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18932 for ; Mon, 24 Apr 2000 21:07:42 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id TAA10450 for manet-outgoing; Mon, 24 Apr 2000 19:03:38 -0400 (EDT) Received: from the.system.at ([193.170.125.214]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id TAA10443 for ; Mon, 24 Apr 2000 19:03:33 -0400 (EDT) Received: from localhost (IDENT:kyrah@localhost.localdomain [127.0.0.1]) by the.system.at (8.9.3/8.8.7) with ESMTP id BAA31748; Tue, 25 Apr 2000 01:03:41 +0200 Date: Tue, 25 Apr 2000 01:03:41 +0200 (CEST) From: kyrah To: Miguel Sanchez cc: Dmitri Deshun Perkins , manet@itd.nrl.navy.mil Subject: Re: ad hoc routing,and Bluetooth In-Reply-To: <39049899.648A53C@disca.upv.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk hello, one other thing comes to my mind when we are discussing bluetooth and manet.... how does Jini fit in here? i mean, i am currently working on a project where we develop a prototype of a bluetooth based ad-hoc network where the network nodes communicate using Jini. has anybody had any experience in combining these technologies?! best regards, kyrah / karin kosina +---------------------------------------------------------------------- "Calm down. It's only ones and zeros." -- Sam Kass karin kosina (kyrah) http://the.system.at +-------------------+ | .*n[ui]x rulez! | +-------------------+ From owner-manet@itd.nrl.navy.mil Tue Apr 25 12:41:59 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19317 for ; Tue, 25 Apr 2000 12:41:59 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA23465 for manet-outgoing; Tue, 25 Apr 2000 10:36:40 -0400 (EDT) Received: from tabasco (tabasco.itd.nrl.navy.mil [132.250.92.182]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA23370; Tue, 25 Apr 2000 10:32:16 -0400 (EDT) Message-Id: <4.2.2.20000425101440.00d66e30@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 25 Apr 2000 10:29:06 -0400 To: Miguel Sanchez , Dmitri Deshun Perkins From: Joe Macker Subject: Re: ad hoc routing,and Bluetooth Cc: manet@itd.nrl.navy.mil In-Reply-To: <39049899.648A53C@disca.upv.es> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-manet@itd.nrl.navy.mil Precedence: bulk At 08:55 PM 4/24/00 +0200, Miguel Sanchez wrote: >Hi Dmitri, > >Just as a personal opinion, I do not think MANET and Bluetooth are very much >complementary although other people can think the opossite. From the initial >statement of each technology: >1) Manet: networks made of set of nodes that act as routers too and use IP >protocol stack(we are at IETF after all). >2) Bluetooth: Radio technology to "cut the cord" intended for PDAs, >cellphones and the like. > >Ok, you can, theoretically build something resemling a MANET with physical >and MAC layers of Bluetooth networks. In fact what can make Bluetooth >attractive is the expected very low cost of radio transceivers. But remember, >Bluetooth is intended to 10 meters of coverage (and up to 100 meters with >some power extended mode ...?). However, I think that 10 meters of >transmission range is too low for most of the MANET applications and the >Bluetooth MAC level can imposse some limitations too. Miguel: I believe short range and low cost opens up more possibilities for manet solutions not the other way around. There is a more economic possibility of having a mesh of devices with associated dynamics (not just from motion). If you envision interconnecting a set of heterogeneous wireless devices things get even more interesting. The proliferation of Bluetooth-like technology will certainly occur and continue to evolve. >Some weeks ago it was discussed on the list this same topic. If you cannot >access to previous postings I think that authors can send you a copy. >Best wishes, > >Miguel Sanchez >Universidad Politecnica de Valencia (Spain) > >PS: Sorry, I see I'm not answering your question, however I thought you also >wanted some comments and this is my two cents one. From owner-mmnet@itd.nrl.navy.mil Fri Apr 28 20:13:04 2000 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20360 for ; Fri, 28 Apr 2000 20:13:04 -0400 (EDT) Received: (from majordom@localhost) by itd.nrl.navy.mil (8.8.8/8.8.8) id SAA16280 for mmnet-outgoing; Fri, 28 Apr 2000 18:09:22 -0400 (EDT) Received: from oak.C928942-A.plano1.tx.home.com (c928942-a.plano1.tx.home.com [24.15.253.11]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id SAA16275 for ; Fri, 28 Apr 2000 18:09:13 -0400 (EDT) Received: from localhost (montgo@localhost) by oak.C928942-A.plano1.tx.home.com (8.9.3/8.9.3) with ESMTP id RAA06536; Fri, 28 Apr 2000 17:07:58 -0500 X-Authentication-Warning: oak.C928942-A.plano1.tx.home.com: montgo owned process doing -bs Date: Fri, 28 Apr 2000 17:07:58 -0500 (CDT) From: Don Montgomery X-Sender: montgo@oak.C928942-A.plano1.tx.home.com To: itc@ieee.org, tccc@ieee.org, tcgn@ieee.org, nbhide@eecs.wsu.edu, alg@comm.toronto.edu, cabernet-events@ncl.ac.uk, cost237-transport@comp.lancs.ac.uk, end2end-interest@isi.edu, mmnet@itd.nrl.navy.mil, sig-dsm@doc.ic.ac.uk, announce@tcos.org, commsoft@cc.bellcore.com, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, dbworld@cs.wisc.edu, multicomm@cc.bellcore.com, tcos-announce@dartmouth.edu, ieeetcpc@ccvm.sunysb.edu, johnson_e@acm.org, chair_sigecom@acm.org, infodir_SIGMIS@acm.org, infodir_SIGOPS@acm.org, infodir_SIGMETRICS@acm.org cc: Don Montgomery Subject: CFP: Simulation, CAD, and Measurement of Optical Networks, Special Issue of Optical Networks Magazine Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mmnet@itd.nrl.navy.mil Precedence: bulk Dear Colleagues, I am appending the following CFP. Please put it before those who might be interested in submitting. Very truly yours, Don Montgomery Guest Editor, Optical Networks Magazine Special Issue on Simulation, CAD, and Measurement Boston Communications Networks, Inc. 5718 Moss Creek Court, Dallas TX 75252 cell: 214 403 4694 fax: 972 818 1289 CALL FOR PAPERS SPIE/Baltzer Science Optical Networks Magazine Simulation, CAD, and Measurement of Optical Networks CFP for Optical Networks Magazine: Emerging optical technologies, together with the rapidly rising demand for network bandwidth, are fueling an increasing amount of research in the field of optical networks. A new optical network layer is evolving, which focuses on providing advanced optical capabilities, such as optical reconfiguration, wavelength provisioning, and all-optical protection and restoration. New network protocols and architectures, in local, metropolitan, and wide-area environments, must be developed in order to fully utilize this emerging optical layer, and to create an efficient optical network that will ultimately provide end-to-end optical services. This special issue is focused on the use of simulation and computer aided design (CAD) in support of the technical and commercial development of optical network technologies, architectures, protocols, and applications; and on measurement of optical transmission parameters and optical network traffic. Commercial, experimental, and research submissions are encouraged. Topics: This Special Issue will collect and archive the state-of-the-art in all research and applied areas related to CAD, simulation, and measurement as they apply to optical networking, including, but not limited to: * existing CAD tools for design of optical LANs and access networks, all-optical switched networks, passive optical networks, core and access networks, optical layer protection and restoration, wavelength routing and conversion, dynamic reconfiguration; * simulation packages for optical networking, optical layer protocols, interaction between the optical networking (DWDM or lightpath routed) layer and adjacent layers, i.e., transmission, SONET/SDH, ATM, IP; or the simulation of management interactions dealing with the optical networking (DWDM or lightpath routed) layer; * existing or proposed methodologies for simulation and/or CAD modeling of the above; * measurements and comparisons of traffic and performance of all types of optical networks, opaque (all-) optical networks, hybrid optical networks; of backbone, regional, and access optical networks; of switched and passive optical networks; of hybrid provisioning implementations. SUBMISSION INSTRUCTIONS Prospective authors should send an electronic version (Postscript or PDF files ONLY) to one of the guest editors. The paper should be no longer than 20 double-spaced pages, excluding illustrations and graphs. If electronic submission is impossible, please submit FIVE hard copies of the paper to Don Montgomery's mail address. IMPORTANT DATES Submission deadline: July 31, 2000 Acceptance notification: November 30, 2000 Final manuscript due: January 31, 2001 Publication date: First half of 2001 Guest Co-Editors: Don Montgomery Project Manager Boston Communications Networks 5718 Moss Creek Court Dallas, Texas, 75252 Phone: +972-818-1288 Fax: +972-818-1289 montgo@bostoncomm.com Prof. Marco Ajmone Marsan Dipartimento di Elettronica Politecnico di Torino Corso Duca degli Abruzzi 24 10129 Torino, Italy Phone: +39-011-5644032 Fax: +39-011-5644099 AJMONE@polito.it Dr. Rohit Sharma Vice President and Chief Architect Optical Networks Inc. 166 Baypointe Parkway San Jose, California 95134 Phone: +408-965-2600 Fax: +408-965-2660 rsharma@opticalnetworks.com Nada Golmie National Institute of Standards and Technology High Speed Networks Technologies Group 100 Bureau Dr. Stop 8920 Gaithersburg, MD 20899-8920 Phone: +301-975-4190 Fax: +301-590-0932 nada.golmie@nist.gov