From owner-manet@itd.nrl.navy.mil  Wed Mar  1 07:41:53 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 HAA29598
	for <manet-archive@odin.ietf.org>; Wed, 1 Mar 2000 07:41:52 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id FAA02611
	for manet-outgoing; Wed, 1 Mar 2000 05:22:07 -0500 (EST)
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 FAA02606
	for <manet@itd.nrl.navy.mil>; Wed, 1 Mar 2000 05:22:01 -0500 (EST)
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 LAA17149
	for <manet@itd.nrl.navy.mil>; Wed, 1 Mar 2000 11:21:43 +0100 (MET)
Message-Id: <3.0.1.32.20000301112601.00c35e90@menetou.inria.fr>
X-Sender: jacquet@menetou.inria.fr
X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F]
Date: Wed, 01 Mar 2000 11:26:01 +0100
To: manet@itd.nrl.navy.mil
Subject: Re: Stable windows CE  MANET Implementations?
In-Reply-To: <0912222A35B9D311BBD300A0C9558F2C214F2B@exchange.cs.cornell
 .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 FAA02607
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk
Content-Transfer-Encoding: 8bit

Dear Li Li,

It depends whether you want to use Windows CE terminals as routers or as
mobile hosts. We also work on Windows implementation of OLSR, but on
Windows 98, NT, I don't know how about windows CE. 

Philippe

A 15:30 29/02/00 -0500, Li Li a écrit :
> There have been previous messages about linux MANET implementation. Does
>anyone know if there are any WINDOWS CE MANET implementations? We have a
>bunch of WINDOWS CE devices and would like to connect them as Ad-hoc
>networks.
>
>Thanks,
>
>Li Li
>CS Dept., Cornell University
>


From owner-manet@itd.nrl.navy.mil  Wed Mar  1 18:14: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 SAA16147
	for <manet-archive@odin.ietf.org>; Wed, 1 Mar 2000 18:14:57 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA18991
	for manet-outgoing; Wed, 1 Mar 2000 16:13:24 -0500 (EST)
Received: from scapa.cs.ualberta.ca (scapa.cs.ualberta.ca [129.128.4.44])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA18986
	for <manet@itd.nrl.navy.mil>; Wed, 1 Mar 2000 16:13:17 -0500 (EST)
Received: (from localhost user: 'wkui' uid#432 fake: STDIN
        (wkui@nampa.cs.ualberta.ca)) by scapa.cs.ualberta.ca
	id <S433594AbQCAVMn>; Wed, 1 Mar 2000 14:12:43 -0700
Date:   Wed, 1 Mar 2000 14:12:42 -0700 (MST)
From: Kui Wu <wkui@cs.ualberta.ca>
To: manet@itd.nrl.navy.mil
Subject: The defination of QoS in MANET
In-Reply-To: <0912222A35B9D311BBD300A0C9558F2C214F2B@exchange.cs.cornell.edu>
Message-ID: <Pine.LNX.4.10.10003011339520.4432-100000@nampa.cs.ualberta.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

Hi all:

It seems that the meaning of QoS in MANET is not clear. Because
of the dynamic topology, the traditional meaning that some performance
metrics(such as bandwidth,end-to-end delay) must be guaranteed once a
request is accepted is no longer true in MANET. In some senses, we can
not guarantee any performance constraint because of inevitable link
breakage. In MANET, after a service is accepted with QoS requirement, the
network system will "try its best" to satisfy the performance requirement. 
So the question is what is the meaning of "try its best" here?

In addition, the Block Rate, which is used to evaluate the performance of
a QoS routing protocol, can not totally represent the goodness of the
protocol, thinking of the situation that the block rate is low but  the
services can not be implemented after accepted. What kind of criteria
should be added to evaluate the performance of QoS routing in MANET?

Hopefully you can give your understanding of QoS in MANET.

    



From owner-manet@itd.nrl.navy.mil  Wed Mar  1 21:13: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 VAA20078
	for <manet-archive@odin.ietf.org>; Wed, 1 Mar 2000 21:13:17 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id TAA22613
	for manet-outgoing; Wed, 1 Mar 2000 19:16:27 -0500 (EST)
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 TAA22607
	for <manet@itd.nrl.navy.mil>; Wed, 1 Mar 2000 19:16:24 -0500 (EST)
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 TAA21407; Wed, 1 Mar 2000 19:16:05 -0500 (EST)
Message-ID: <38BDBCEE.77A1E460@comet.columbia.edu>
Date: Wed, 01 Mar 2000 19:59:26 -0500
From: campbell <campbell@comet.columbia.edu>
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: Kui Wu <wkui@cs.ualberta.ca>
CC: manet@itd.nrl.navy.mil, insignia@comet.columbia.edu
Subject: Re: Just Say No to QOS-routing in MANET
References: <Pine.LNX.4.10.10003011339520.4432-100000@nampa.cs.ualberta.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk
Content-Transfer-Encoding: 7bit


Kui:

Kui Wu wrote:
> 
> Hi all:
> 
> What kind of criteria
> should be added to evaluate the performance of QoS routing in MANET?
> 

I would argue the opposite:

  Keep the routing simple, light weight and fast.

Don't burden it with more that the typical state of non
QOS routing solutions found in wireline e.g., single metric delay,
shortest path. 

There are good reasons to have a
separation of routing, signaling and forwarding in MANET.

Let me explain my bias:

There has been a growing amount of work in the area of 
QOS routing for fixed networks. 

Here the routing protocols inter work with resource management to
establish paths 
through the network that meet end-to-end QOS requirements 
(i.e., delay, bandwidth, possibly multi-metrics demands). 
(There are lots of state (stale state for example) and
complexity issue here that I will step over.)

In this case there is a certain level of integration of resource 
management and routing. One could apply such an approach to MANET 
routing protocols given that the time scales over which new routes 
are computed is much faster than traditionally found in the case 
of routing in fixed infrastructures. 

While I believe this a promising approach (see the CEDAR as an example) 
- and should be investigated - I note that the 
time scales over which session (flows, microflows) setup and routing 
(i.e., computing new routes) operate are distinct and 
functionally independent tasks. 

Therefore, I believe that signaling, resource management 
and routing should be modeled independently in the network architecture. 

(Of course I am bias because our work on INSIGNIA. We have
implemented INSIGNIA with AODV, DSR and TORA and show
improved performance for TCP and UDP tarffic with these
non QOS routing protocols. We will release the NS
code for this soon which uses Dave J's ns extensions.
The performance looks good for a variety of mobility
and network loads.)

So my spin is that I consider that MANET routing protocol should not be 
burdened with the integration of QOS functionality (as in
the case of CEDAR - I'm sure CEDAR guys will forgive me
for pointing to their protocol as an example of how I
would do routing in MANET) that may be tailored 
toward specific QOS models.  Of
course if the routing scheme does QOS (which I am against)
then INSIGNIA would just do even better. 
I just advise against it as a general approach
for doing QOS in MANET.

Rather, I argue that it is better to maintain 
a clean separation between routing, signaling 
and forwarding. Each of these architectural components are rather 
different in the algorithms they implement and the time scales 
over which they operate. 


The INSIGNIA approach develops QOS framework that you 
can 'pluggin" a wide variety of routing protocols (e.g., CEDAR). 
You can even use INSIGNIA across and between different 
MANET domains and do QOS. 

In this case, resource reservation and signaling protocol will be 
capable of inter working with any number of routing protocols to 
provide end-to-end QOS support. 

For example INSIGNIA provides operational transparency with AODV, 
DSR and TORA which shows the nice quality of these
routing protocols to do there job in hairy environments.

Different MANET routing protocols 
clearly perform differently  in response to topology changes 
while the QOS framework should attempts to maintain end-to-end 
service quality. We see this from our ns simulations.

I'm off on a tangent here. Forgive me.....

Andrew

Kui Wu wrote:
> 
> Hi all:
> 
> It seems that the meaning of QoS in MANET is not clear. Because
> of the dynamic topology, the traditional meaning that some performance
> metrics(such as bandwidth,end-to-end delay) must be guaranteed once a
> request is accepted is no longer true in MANET. In some senses, we can
> not guarantee any performance constraint because of inevitable link
> breakage. In MANET, after a service is accepted with QoS requirement, the
> network system will "try its best" to satisfy the performance requirement.
> So the question is what is the meaning of "try its best" here?
> 
> In addition, the Block Rate, which is used to evaluate the performance of
> a QoS routing protocol, can not totally represent the goodness of the
> protocol, thinking of the situation that the block rate is low but  the
> services can not be implemented after accepted. What kind of criteria
> should be added to evaluate the performance of QoS routing in MANET?
> 
> Hopefully you can give your understanding of QoS in MANET.
> 
> 

--
Andrew
http://comet.columbia.edu/~campbell


From owner-manet@itd.nrl.navy.mil  Wed Mar  1 22:18:13 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 WAA21675
	for <manet-archive@odin.ietf.org>; Wed, 1 Mar 2000 22:18:13 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id UAA23752
	for manet-outgoing; Wed, 1 Mar 2000 20:33:00 -0500 (EST)
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 UAA23747
	for <manet@itd.nrl.navy.mil>; Wed, 1 Mar 2000 20:32:57 -0500 (EST)
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 UAA24262; Wed, 1 Mar 2000 20:32:35 -0500 (EST)
Message-ID: <38BDCEDD.B14972E@comet.columbia.edu>
Date: Wed, 01 Mar 2000 21:15:57 -0500
From: campbell <campbell@comet.columbia.edu>
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: Kui Wu <wkui@cs.ualberta.ca>, manet@itd.nrl.navy.mil,
        insignia@comet.columbia.edu
Subject: Re: Just Say No to QOS-routing in MANET
References: <Pine.LNX.4.10.10003011339520.4432-100000@nampa.cs.ualberta.ca> <38BDBCEE.77A1E460@comet.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk
Content-Transfer-Encoding: 7bit


Ophs.

campbell wrote:
 
> So my spin is that I consider that MANET routing protocol should not be
> burdened with the integration of QOS functionality (as in
> the case of CEDAR - I'm sure CEDAR guys will forgive me
> for pointing to their protocol as an example of how I
> would do routing in MANET)
       
should have read:

(as in the case of CEDAR - I'm sure CEDAR guys will forgive me
for pointing to their protocol as an example of how I
would *not* do routing in MANET)


From owner-manet@itd.nrl.navy.mil  Thu Mar  2 12:49:35 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 MAA20794
	for <manet-archive@odin.ietf.org>; Thu, 2 Mar 2000 12:49:34 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA06142
	for manet-outgoing; Thu, 2 Mar 2000 10:30:49 -0500 (EST)
Received: from tabasco (tabasco.itd.nrl.navy.mil [132.250.92.182])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id KAA05911;
	Thu, 2 Mar 2000 10:29:58 -0500 (EST)
Message-Id: <4.1.20000302100943.00c2c690@pop.itd.nrl.navy.mil>
X-Sender: macker@pop.itd.nrl.navy.mil
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 02 Mar 2000 10:27:30 -0500
To: campbell@comet.columbia.edu, Kui Wu <wkui@cs.ualberta.ca>
From: Joe Macker <macker@itd.nrl.navy.mil>
Subject: Re: Just Say No to QOS-routing in MANET
Cc: manet@itd.nrl.navy.mil, insignia@comet.columbia.edu
In-Reply-To: <38BDBCEE.77A1E460@comet.columbia.edu>
References: <Pine.LNX.4.10.10003011339520.4432-100000@nampa.cs.ualberta.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

Andrew:

Thank you for your considered response.
I agreed that we not overburden the present task at hand.

At present manet is not advocating any particular QoS approach whether
layered or integrated ( this is a longer term issue than basic routing
approaches that work).

-Joe

At 07:59 PM 3/1/00 -0500, campbell wrote:
>  Keep the routing simple, light weight and fast.

I agree this is the first term order of business.

>Rather, I argue that it is better to maintain 
>a clean separation between routing, signaling 
>and forwarding. Each of these architectural components are rather 
>different in the algorithms they implement and the time scales 
>over which they operate. 
>




From owner-manet@itd.nrl.navy.mil  Fri Mar  3 00:33: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 AAA07336
	for <manet-archive@odin.ietf.org>; Fri, 3 Mar 2000 00:33:00 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id VAA21360
	for manet-outgoing; Thu, 2 Mar 2000 21:51:42 -0500 (EST)
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 VAA21355
	for <manet@itd.nrl.navy.mil>; Thu, 2 Mar 2000 21:51:32 -0500 (EST)
Received: from euler.cs.albany.edu (euler.cs.albany.edu [169.226.2.43])
	by taurus.cs.albany.edu (8.9.3+Sun/8.9.1) with ESMTP id VAA26700;
	Thu, 2 Mar 2000 21:50:33 -0500 (EST)
From: "S.S.Ravi" <ravi@cs.albany.edu>
Received: (from ravi@localhost) by euler.cs.albany.edu (SMI-8.6/CLI2) id VAA01454; Thu, 2 Mar 2000 21:49:15 -0500
Date: Thu, 2 Mar 2000 21:49:15 -0500
Message-Id: <200003030249.VAA01454@euler.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
Subject: DIAL M for Mobility (Second Call for Papers)
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk


       (Please accept our apologies if you receive multiple copies.) 

                       SECOND 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.

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  Fri Mar  3 03:01:22 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 DAA20968
	for <manet-archive@odin.ietf.org>; Fri, 3 Mar 2000 03:01:21 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id BAA23867
	for manet-outgoing; Fri, 3 Mar 2000 01:00:57 -0500 (EST)
Received: from scapa.cs.ualberta.ca (scapa.cs.ualberta.ca [129.128.4.44])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id BAA23861
	for <manet@itd.nrl.navy.mil>; Fri, 3 Mar 2000 01:00:54 -0500 (EST)
Received: from async17-16.remote.ualberta.ca ([129.128.237.41]:3688 "EHLO
        cs.ualberta.ca") by scapa.cs.ualberta.ca with ESMTP
	id <S434024AbQCCGAN>; Thu, 2 Mar 2000 23:00:13 -0700
Message-ID: <38BF47B6.A1F91D5D@cs.ualberta.ca>
Date:   Thu, 02 Mar 2000 23:03:50 -0600
From: wkui <wkui@cs.ualberta.ca>
Reply-To: wkui@cs.ualberta.ca
Organization: U.of A.
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: manet@itd.nrl.navy.mil
Subject: Re:Just Say No to QOS-routing in MANET
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:

I think it is necessary to clarify that "Say No to QoS-Routing" is not
equivalent to "not advocating any particular QoS approach". In fact,
Andrew just proposes a method that supports QoS by using in-band
signaling together with routing protocols.

Both methods (QoS routing and signaling + routing+forwarding) have their
advantages. Does anybody want to give some comments?

Kui



From owner-manet@itd.nrl.navy.mil  Fri Mar  3 13:24: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 NAA05554
	for <manet-archive@odin.ietf.org>; Fri, 3 Mar 2000 13:24:22 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA02826
	for manet-outgoing; Fri, 3 Mar 2000 10:45:38 -0500 (EST)
Received: from tabasco (tabasco.itd.nrl.navy.mil [132.250.92.182])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id KAA02803;
	Fri, 3 Mar 2000 10:45:11 -0500 (EST)
Message-Id: <4.1.20000303101154.017ac310@pop.itd.nrl.navy.mil>
X-Sender: macker@pop.itd.nrl.navy.mil
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 03 Mar 2000 10:42:08 -0500
To: wkui@cs.ualberta.ca, manet@itd.nrl.navy.mil
From: Joe Macker <macker@itd.nrl.navy.mil>
Subject: Re:Just Say No to QOS-routing in MANET
In-Reply-To: <38BF47B6.A1F91D5D@cs.ualberta.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

Kui:

QoS is important technical topic in general.  

I want it to be clear that we Do NOT have a scoped charter to solve QoS
mobile routing and advocate a position on that.  

There are many valid alternative approaches to QoS with associated complex
tradeoffs.

It should be clarified that it is o.k. to discuss issues and propose
approaches (these may be integrated for consideration) but in my mind this
is secondary to getting routing protocol(s) matured. Afterall , a simple,
lightweight routing protocol and something like diffserv might go a long
way in a mobile wireless environment for many application scenarios.

-Joe

At 11:03 PM 3/2/00 -0600, wkui wrote:
>Hi:
>
>I think it is necessary to clarify that "Say No to QoS-Routing" is not
>equivalent to "not advocating any particular QoS approach". In fact,
>Andrew just proposes a method that supports QoS by using in-band
>signaling together with routing protocols.
>
>Both methods (QoS routing and signaling + routing+forwarding) have their
>advantages. Does anybody want to give some comments?
>
>Kui




From owner-manet@itd.nrl.navy.mil  Fri Mar  3 17:18: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 RAA10875
	for <manet-archive@odin.ietf.org>; Fri, 3 Mar 2000 17:18:01 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA10285
	for manet-outgoing; Fri, 3 Mar 2000 15:05:12 -0500 (EST)
Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA10276;
	Fri, 3 Mar 2000 15:05:03 -0500 (EST)
Received: from qma-lap (dhcp-sjc9-233-188.cisco.com [171.71.233.188]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id MAA00479; Fri, 3 Mar 2000 12:04:37 -0800 (PST)
Message-Id: <4.1.20000303114358.020f2380@zipper.cisco.com>
X-Sender: qma@zipper.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 03 Mar 2000 12:04:12 -0800
To: Joe Macker <macker@itd.nrl.navy.mil>, wkui@cs.ualberta.ca,
        manet@itd.nrl.navy.mil
From: Qingming Ma <qma@cisco.com>
Subject: Re:Just Say No to QOS-routing in MANET
In-Reply-To: <4.1.20000303101154.017ac310@pop.itd.nrl.navy.mil>
References: <38BF47B6.A1F91D5D@cs.ualberta.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

First, QoS routing is a part of general QoS resource management. Other
parts include scheduling, traffic conditioning and resource reservation,
depending on what service model (DiffServ or IntServ) to use.

QoS routing provides a way to balance network load in order to avoid
congested spots in the network. There is no agreed approach to do
QoS routing now, although the IETF Traffic Engineering group is defining 
an Architecture for traffic engineering, within which QoS routing function
can be achieved. It seems more promising
to use MPLS based explicit routes to support QoS routing rather than 
trying to extend the existing routing protocol such as OSPF or ISIS,
although these protocols may need to extended to distribute certain
load information needed for traffic engineering.

In a cellular mobile wireless network, load balancing is still necessary
although there may not need to do QoS routing at this time before the 
bandwidth intensive applications take place. Let us keep our eyes open 
to the development of QoS routing and traffic engineering technology 
before we say yes or no to QoS routing. 

That is my 2 cents.

Qingming     

At 10:42 AM 3/3/00 -0500, Joe Macker wrote:
>Kui:
>
>QoS is important technical topic in general.  
>
>I want it to be clear that we Do NOT have a scoped charter to solve QoS
>mobile routing and advocate a position on that.  
>
>There are many valid alternative approaches to QoS with associated complex
>tradeoffs.
>
>It should be clarified that it is o.k. to discuss issues and propose
>approaches (these may be integrated for consideration) but in my mind this
>is secondary to getting routing protocol(s) matured. Afterall , a simple,
>lightweight routing protocol and something like diffserv might go a long
>way in a mobile wireless environment for many application scenarios.
>
>-Joe
>
>At 11:03 PM 3/2/00 -0600, wkui wrote:
>>Hi:
>>
>>I think it is necessary to clarify that "Say No to QoS-Routing" is not
>>equivalent to "not advocating any particular QoS approach". In fact,
>>Andrew just proposes a method that supports QoS by using in-band
>>signaling together with routing protocols.
>>
>>Both methods (QoS routing and signaling + routing+forwarding) have their
>>advantages. Does anybody want to give some comments?
>>
>>Kui
>
>
>



From owner-manet@itd.nrl.navy.mil  Fri Mar  3 19:49:03 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 TAA12684
	for <manet-archive@odin.ietf.org>; Fri, 3 Mar 2000 19:49:02 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id RAA14121
	for manet-outgoing; Fri, 3 Mar 2000 17:55:08 -0500 (EST)
Received: from prima.time.saic.com (time.saic.com [205.153.241.31])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id RAA14116
	for <manet@itd.nrl.navy.mil>; Fri, 3 Mar 2000 17:55:00 -0500 (EST)
Received: from degas.time.saic.com (degas.time.saic.com [205.153.241.32])
	by prima.time.saic.com (8.9.3/8.8.5) with ESMTP id RAA16897;
	Fri, 3 Mar 2000 17:54:57 -0500 (EST)
Message-Id: <200003032254.RAA16897@prima.time.saic.com>
X-Mailer: exmh version 2.0.2 2/24/98
To: Qingming Ma <qma@cisco.com>
cc: manet@itd.nrl.navy.mil
Subject: Re: Just Say No to QOS-routing in MANET 
In-Reply-To: Your message of "Fri, 03 Mar 2000 12:04:12 PST."
             <4.1.20000303114358.020f2380@zipper.cisco.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 03 Mar 2000 17:51:58 -0500
From: Ken Carlberg <carlberg@time.saic.com>
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk


In principal, i agree with the points you make -- in particular, the
appeal of explicit routes.  the concern that rambles in my mind is 
the application MPLS to MANET-type networks.

part of the strength of MPLS is the expectation that edge routers are 
the entities that generate explicit routes.  thus, 'interior' routers
are not burdened with updates and hop-by-hop routing decisions, as well
as other system overhead conditions.  however, with ad-hoc networks, 
what constitutes the edge of the network with repect to hosts, is fuzzy 
at best, and likely or expected to change over time.

so maybe designs for MANET-QoS support may need to be (significantly?) 
less deterministic than that found for sesile (non-moving) networks.

cheers,

-ken




From owner-manet@itd.nrl.navy.mil  Fri Mar  3 22:17: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 WAA14897
	for <manet-archive@odin.ietf.org>; Fri, 3 Mar 2000 22:17:00 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id UAA16091
	for manet-outgoing; Fri, 3 Mar 2000 20:26:53 -0500 (EST)
Received: from plastique.stanford.edu (plastique.Stanford.EDU [171.64.67.81])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id UAA16086
	for <manet@itd.nrl.navy.mil>; Fri, 3 Mar 2000 20:26:47 -0500 (EST)
Message-Id: <200003040126.UAA16086@itd.nrl.navy.mil>
Received: (qmail 14767 invoked from network); 4 Mar 2000 01:26:29 -0000
Received: from localhost.stanford.edu (HELO plastique.Stanford.EDU) (127.0.0.1)
  by localhost.stanford.edu with SMTP; 4 Mar 2000 01:26:29 -0000
X-Mailer: exmh version 2.0.2
To: Derek Smithies <derek@indranet.co.nz>
Subject: Re: Stable Linux MANET Implementations? 
In-reply-to: Your message of "Fri, 25 Feb 2000 15:15:05 +1300."
	    <38B5E5A9.B8D56081@indranet.co.nz> 
Cc: manet@itd.nrl.navy.mil
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 03 Mar 2000 17:26:29 -0800
From: Mary Baker <mgbaker@plastique.stanford.edu>
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk


> 
> I wrote to one member of the manet group on this issue, and his reply
> was
> >yes v6 for ad hoc nets will be interesting...when v6 happens of course.
> A reply that suggests v6 is a long way away. However, everyone said that
> about computers having 100 MB/ram (when the biggest you ever heard of was
> 8 MB). Given the current congestion of the numbering space in IPv4, and
> that IPv6 stacks do exist, a shift to v6 is imminent.
> 
> Comment, anyone?


Those interested in this topic might like to look at 
	http://www.dsg.stanford.edu/papers/triad/triad.html

This is a project called TRIAD going on in David Cheriton's group at Stanford,
and it addresses some of the worries people have about IPv6 deployability.
It even has a section in it about perceived deployability issues.  They
present what looks like an interesting alternative that is, in a sense, 
already
taking place.  Please note that I'm not a member of the TRIAD project, but
I found it to be interesting reading.
  
Mary



From owner-manet@itd.nrl.navy.mil  Fri Mar  3 23:52: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 XAA17256
	for <manet-archive@odin.ietf.org>; Fri, 3 Mar 2000 23:52:42 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id VAA17135
	for manet-outgoing; Fri, 3 Mar 2000 21:53:14 -0500 (EST)
Received: from imc21.ex.nus.edu.sg (imc21.ex.nus.edu.sg [137.132.14.62])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id VAA17128;
	Fri, 3 Mar 2000 21:53:06 -0500 (EST)
Received: by imc21.ex.nus.edu.sg with Internet Mail Service (5.5.2650.21)
	id <G2AF9V5Q>; Sat, 4 Mar 2000 10:52:47 +0800
Message-ID: <30A14FB41CC5D311854D00508B5EEF02012D3665@exs23.ex.nus.edu.sg>
From: Xiao Hannan <engp8803@nus.edu.sg>
To: manet@itd.nrl.navy.mil, "'Joe Macker'" <macker@itd.nrl.navy.mil>
Subject: RE: Just Say No to QOS-routing in MANET
Date: Sat, 4 Mar 2000 10:52:45 +0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

	Dear all, 

	I agree with Dr. Macker's speculation that the relatively simple and
lightweight diffserv model may fit MANETs' scenario.

	> Afterall , a simple, lightweight routing protocol and something
like diffserv might go a long
	> way in a mobile wireless environment for many application
scenarios.

	> -Joe

	Here is the abstract of our paper to be appeared  in IEEE
VTC2000-spring, Tokyo, Japan, May, 2000.

> A Flexible Quality of Service Model for Mobile Ad-Hoc Networks
> 
> Abstract
> 
> Quality of service (QoS) support in Mobile Ad-hoc NETworks (MANETs) is a
> challenging
> task. Most of the proposals in the literature only address certain
> aspects of the QoS support, e.g., QoS routing, QoS medium access
> control (MAC) and resource reservation. However, none of them proposes
> a QoS model for MANETs.  Meanwhile, two QoS models have been proposed
> for the Internet, viz., the Integrated Services (IntServ) model and
> the Differentiated Services (DiffServ) model, but these models are
> aimed for wired networks. \vspace*{0.3ex}
> 
> In this paper, we propose a flexible QoS model for MANETs (FQMM)
> which considers the characteristics of MANETs and combines the
> high quality QoS of IntServ and service differentiation of
> DiffServ.  Salient features of FQMM include: dynamics roles of
> nodes, hybrid provisioning and adaptive conditioning.
> Preliminary simulation results show that FQMM achieves better
> performance in terms of throughput and service differentiation
> than the best-effort model.\vspace*{1.5ex}
> 
	If you are interested in the full paper, pls contact with me. 

Regards
Hannan

**********************************************
*    XIAO Hannan
*    Ph.D. candidate
*    Dept. of EE
*    National U. of Singapore
*    Email:  engp8803@nus.edu.sg
*********************************************








From owner-manet@itd.nrl.navy.mil  Sat Mar  4 03:09: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 DAA00892
	for <manet-archive@odin.ietf.org>; Sat, 4 Mar 2000 03:09:57 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id BAA19085
	for manet-outgoing; Sat, 4 Mar 2000 01:12:49 -0500 (EST)
Received: from simon.cs.cornell.edu (SIMON.CS.CORNELL.EDU [128.84.154.10])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id BAA19080
	for <manet@itd.nrl.navy.mil>; Sat, 4 Mar 2000 01:12:43 -0500 (EST)
Received: from sundial.cs.cornell.edu (SUNDIAL.CS.CORNELL.EDU [128.84.248.71])
	by simon.cs.cornell.edu (8.9.3/8.9.3/R-3.0) with ESMTP id BAA07184
	for <manet@itd.nrl.navy.mil>; Sat, 4 Mar 2000 01:12:23 -0500 (EST)
Received: from yodel.cs.cornell.edu (YODEL.CS.CORNELL.EDU [128.84.218.84])
	by sundial.cs.cornell.edu (8.9.3/8.9.3/M-3.1) with ESMTP id BAA12092
	for <manet@itd.nrl.navy.mil>; Sat, 4 Mar 2000 01:12:22 -0500 (EST)
Received: (from lili@localhost)
	by yodel.cs.cornell.edu (8.9.3/8.9.3/C-3.0) id BAA25594;
	Sat, 4 Mar 2000 01:12:22 -0500 (EST)
Date: Sat, 4 Mar 2000 01:12:22 -0500 (EST)
From: Li Li <lili@cs.cornell.edu>
To: manet@itd.nrl.navy.mil
Subject: MANET application scenarioes
In-Reply-To: <200003040126.UAA16086@itd.nrl.navy.mil>
Message-ID: <Pine.SUN.3.91.1000304010229.24428B@yodel.cs.cornell.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

Lots of people I talked to do not really think there are convincing 
applications for ad-hoc routing except in the military. For example, in 
our dept., the wireless device uses the BS to communicate to the internet 
and to one another. Lots of places that the wireless device needs 
connection, there are infrastructures such as workplace, airport, hotel, 
etc. 

Can anyone make a case for convincing applications outside the military?

Li Li
Dept. of Computer Science
Cornell University
 


From owner-manet@itd.nrl.navy.mil  Sat Mar  4 03:23:30 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 DAA00960
	for <manet-archive@odin.ietf.org>; Sat, 4 Mar 2000 03:23:29 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id BAA19419
	for manet-outgoing; Sat, 4 Mar 2000 01:48:37 -0500 (EST)
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 BAA19414
	for <manet@itd.nrl.navy.mil>; Sat, 4 Mar 2000 01:48:32 -0500 (EST)
Received: from comet.columbia.edu (sweetpea.comet.columbia.edu [128.59.68.61]) by sirius.ctr.columbia.edu (8.9.3/8.6.4.287) with ESMTP id BAA24345; Sat, 4 Mar 2000 01:48:11 -0500 (EST)
Message-ID: <38C0DF0F.A273A34@comet.columbia.edu>
Date: Sat, 04 Mar 2000 02:01:51 -0800
From: "Andrew T. Campbell" <campbell@comet.columbia.edu>
Reply-To: campbell@comet.columbia.edu
Organization: Center for Telecommunications Research
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Li Li <lili@cs.cornell.edu>
CC: manet@itd.nrl.navy.mil
Subject: Re: MANET application scenarioes
References: <Pine.SUN.3.91.1000304010229.24428B@yodel.cs.cornell.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk
Content-Transfer-Encoding: 7bit


POS

Li Li wrote:
> 
> Lots of people I talked to do not really think there are convincing
> applications for ad-hoc routing except in the military. For example, in
> our dept., the wireless device uses the BS to communicate to the internet
> and to one another. Lots of places that the wireless device needs
> connection, there are infrastructures such as workplace, airport, hotel,
> etc.
> 
> Can anyone make a case for convincing applications outside the military?
> 
> Li Li
> Dept. of Computer Science
> Cornell University
> 

-- 
Andrew
http://comet.columbia.edu/~campbell


From owner-manet@itd.nrl.navy.mil  Sat Mar  4 07:31: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 HAA02581
	for <manet-archive@odin.ietf.org>; Sat, 4 Mar 2000 07:31:01 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id FAA21475
	for manet-outgoing; Sat, 4 Mar 2000 05:23:49 -0500 (EST)
Received: from anise.ee.cornell.edu (ANISE.EE.CORNELL.EDU [128.84.239.14] (may be forged))
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id FAA21470
	for <manet@itd.nrl.navy.mil>; Sat, 4 Mar 2000 05:23:42 -0500 (EST)
Received: from verdi.ee.cornell.edu (VERDI.EE.CORNELL.EDU [128.84.240.71])
	by anise.ee.cornell.edu (8.9.3/8.9.1) with SMTP id FAA11835;
	Sat, 4 Mar 2000 05:23:40 -0500 (EST)
Date: Sat, 4 Mar 2000 05:23:40 -0500 (EST)
From: Zygmunt Haas <haas@anise.ee.cornell.edu>
To: Li Li <lili@cs.cornell.edu>
cc: manet@itd.nrl.navy.mil
Subject: Re: MANET application scenarioes
In-Reply-To: <Pine.SUN.3.91.1000304010229.24428B@yodel.cs.cornell.edu>
Message-ID: <Pine.HPP.3.96.1000304051319.6811B-100000@verdi.ee.cornell.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

Hi Li,

> Lots of people I talked to do not really think there are convincing 
> applications for ad-hoc routing except in the military. For example, in 
> our dept., the wireless device uses the BS to communicate to the internet 
> and to one another. Lots of places that the wireless device needs 
> connection, there are infrastructures such as workplace, airport, hotel, 
> etc. 

Hmmm, you may be talking to the wrong people (:-) ...

There are a number of applications of the ad hoc networking technology
outside the traditional military sector. The most notable, in my opinion,
are the sensor networks, such as, for example, would be needed for
communication in Smart Environments. There are, of course, many other
examples as well ...

Finally, the fact that in some cases there is an infrastructure, does not
preclude the use of a network that does not rely on the infrastructure, if
such use has some advantages ... For instance, use of ad hoc networks as
an extention to wireless LAN has been proposed ....

Zygmunt Haas.
==-=---===-===
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
Prof. Zygmunt J. Haas                    tel: +1-607-255-3454
Wireless Networks Laboratory		                  
School of Electrical Engineering         fax: +1-607-255-9072 
Cornell University
323 Frank Rhodes Hall			 e-mail: haas@ee.cornell.edu
Ithaca, NY 14853			 
U.S.A                             http://www.ee.cornell.edu/~haas/wnl.html
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-



From owner-manet@itd.nrl.navy.mil  Sat Mar  4 07:59: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 HAA02972
	for <manet-archive@odin.ietf.org>; Sat, 4 Mar 2000 07:59:17 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id FAA21800
	for manet-outgoing; Sat, 4 Mar 2000 05:54:02 -0500 (EST)
Received: from praseodumium.btinternet.com (praseodumium.btinternet.com [194.73.73.82])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id FAA21795
	for <manet@itd.nrl.navy.mil>; Sat, 4 Mar 2000 05:53:56 -0500 (EST)
Received: from [213.1.177.206] (helo=mofo.ecs.soton.ac.uk)
	by praseodumium.btinternet.com with esmtp (Exim 2.05 #1)
	id 12RCBp-0005ze-00; Sat, 4 Mar 2000 10:53:42 +0000
Received: (from mkt@localhost)
	by mofo.ecs.soton.ac.uk (8.9.3/8.9.3) id LAA01314;
	Sat, 4 Mar 2000 11:03:52 GMT
Date: Sat, 4 Mar 2000 11:03:51 +0000
From: Mark Thompson <mkt@ecs.soton.ac.uk>
To: Li Li <lili@cs.cornell.edu>
Cc: manet@itd.nrl.navy.mil
Subject: Re: MANET application scenarioes
Message-ID: <20000304110351.A1282@ecs.soton.ac.uk>
Reply-To: mkt@ecs.soton.ac.uk
References: <200003040126.UAA16086@itd.nrl.navy.mil> <Pine.SUN.3.91.1000304010229.24428B@yodel.cs.cornell.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <Pine.SUN.3.91.1000304010229.24428B@yodel.cs.cornell.edu>; from lili@cs.cornell.edu on Sat, Mar 04, 2000 at 01:12:22AM -0500
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

On 01:12(GMT) 04-03-00, Li Li wrote:
> Lots of people I talked to do not really think there are convincing 
> applications for ad-hoc routing except in the military. For example, in 
> our dept., the wireless device uses the BS to communicate to the internet 
> and to one another. Lots of places that the wireless device needs 
> connection, there are infrastructures such as workplace, airport, hotel, 
> etc. 
> 
> Can anyone make a case for convincing applications outside the military?

``A boy-scouts meeting in a field?'' ;-)

Seriously though, there are numerous scenarios where full access to the
Internet (note the big I) is either not available or not necessrary. We're
in a world where it isn't just laptop computers that are comms enabled,
but also PDAs, cellulars, and toasters(!)  Whilst HomeRF, Bluetooth
etc. may be providing rudimentary comms for some of these scenarios,
they dont AFAIK cover the routing of messages via devices, only between
them, or via a designated hub/switch/router...

Granted, the often quoted scenarios of meetings in offices; the hotel
lobby even the dentists office (/me nods to the IETF ipngwg) usually
stress the "well, we can give you global addressing and stateless
addrconf, so you can access the 'net", but they all require supporting
infrastructure.

IMO, the strongest case for the manet initiative is that it is
striving to provide that infrastructure "for free" (i.e. no additional
switches/hubs/wLAN BSes/hardware), but by software stacks on the
participating clients themselves.

The "convincing applications" are every single networked device scenario,
but without the infrastructure hardware - just the devices (thus people)
that want to communicate.

... or am I way off the mark here?


Mark/

-- 
iam: networks and distributed systems
http://www.ecs.soton.ac.uk/~mkt/contact.shtml for contact info...


From owner-manet@itd.nrl.navy.mil  Sat Mar  4 11:05:00 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 LAA05134
	for <manet-archive@odin.ietf.org>; Sat, 4 Mar 2000 11:05:00 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id IAA23247
	for manet-outgoing; Sat, 4 Mar 2000 08:58:01 -0500 (EST)
Received: from hematita.dcc.ufmg.br (hematita.dcc.ufmg.br [150.164.10.11])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id IAA23242
	for <manet@itd.nrl.navy.mil>; Sat, 4 Mar 2000 08:57:52 -0500 (EST)
Received: from turmalina.dcc.ufmg.br (turmalina [150.164.10.1])
	by hematita.dcc.ufmg.br (8.8.8/8.8.8) with SMTP id KAA28434;
	Sat, 4 Mar 2000 10:56:32 -0300 (EST)
Date: Sat, 4 Mar 2000 10:56:32 -0300 (EST)
From: Frederico Mesquita <mesquita@dcc.ufmg.br>
To: "Andrew T. Campbell" <campbell@comet.columbia.edu>
cc: Li Li <lili@cs.cornell.edu>, manet@itd.nrl.navy.mil
Subject: Re: MANET application scenarioes
In-Reply-To: <38C0DF0F.A273A34@comet.columbia.edu>
Message-ID: <Pine.SOL.4.02.10003041055540.14972-100000@turmalina.dcc.ufmg.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by itd.nrl.navy.mil id IAA23243
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk
Content-Transfer-Encoding: 8bit


	??? POS ???

	What?

	[ ]'s

	fred
	DCC / UFMG

		"...uma coisa é conhecer o caminho,
			outra coisa é percorrê-lo..."

On Sat, 4 Mar 2000, Andrew T. Campbell wrote:

> 
> POS
> 
> Li Li wrote:
> > 
> > Lots of people I talked to do not really think there are convincing
> > applications for ad-hoc routing except in the military. For example, in
> > our dept., the wireless device uses the BS to communicate to the internet
> > and to one another. Lots of places that the wireless device needs
> > connection, there are infrastructures such as workplace, airport, hotel,
> > etc.
> > 
> > Can anyone make a case for convincing applications outside the military?
> > 
> > Li Li
> > Dept. of Computer Science
> > Cornell University
> > 
> 
> -- 
> Andrew
> http://comet.columbia.edu/~campbell
> 



From owner-manet@itd.nrl.navy.mil  Sat Mar  4 14:55: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 OAA07325
	for <manet-archive@odin.ietf.org>; Sat, 4 Mar 2000 14:55:44 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA25386
	for manet-outgoing; Sat, 4 Mar 2000 13:06:33 -0500 (EST)
Received: from icarus.lis.pitt.edu (icarus.lis.pitt.edu [136.142.116.2])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id NAA25381
	for <manet@itd.nrl.navy.mil>; Sat, 4 Mar 2000 13:06:28 -0500 (EST)
Received: (tudball@localhost) by icarus.lis.pitt.edu (SMI-8.6/8.6.5) id NAA08216; Sat, 4 Mar 2000 13:06:31 -0500
Date: Sat, 4 Mar 2000 13:06:31 -0500 (EST)
From: "A. Bruce McDonald" <tudball@lis.pitt.edu>
Subject: Re: MANET application scenarioes
To: Li Li <lili@cs.cornell.edu>
cc: manet@itd.nrl.navy.mil
In-Reply-To: <Pine.SUN.3.91.1000304010229.24428B@yodel.cs.cornell.edu>
Message-ID: <Pine.3.89.10003041241.C7714-0100000@icarus.lis.pitt.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk


Hi,

In my opinion a MANET provides two very different potential network 
services: (1) It provides an instant---possibly temporary---network 
infrastucture where none is available; and (2) it provides an alternative 
network infrastructure in places where wireless/mobile access is 
available, but there is good reason for some group of users to bypass 
that infrastructure---perhaps 'sharing' access to that infrastructure.

What are the reasons for a group to bypass a network in favor of their 
own 'ad-hoc' network?  Cost, privacy, and ease of management come to mind 
for me.   If the communications needs are largely peer-to-peer, and the 
users are not in their home network, there is a strong argument NOT to 
use public wireless network services---both from a cost and security 
perspective, as well as from a performance perspective. Workers visting 
another company may not want their data available on the 'foreign' 
corporate LAN.  

Bruce McDonald
University of Pittsburgh


From owner-manet@itd.nrl.navy.mil  Sat Mar  4 18:27:41 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 SAA08968
	for <manet-archive@odin.ietf.org>; Sat, 4 Mar 2000 18:27:40 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA27086
	for manet-outgoing; Sat, 4 Mar 2000 16:42:47 -0500 (EST)
Received: from amber.crhc.uiuc.edu (amber.crhc.uiuc.edu [130.126.143.254])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA27081
	for <manet@itd.nrl.navy.mil>; Sat, 4 Mar 2000 16:42:42 -0500 (EST)
Received: from platinum (platinum.crhc.uiuc.edu [130.126.143.4])
	by amber.crhc.uiuc.edu (8.9.3/8.9.3) with SMTP id PAA14024;
	Sat, 4 Mar 2000 15:42:42 -0600 (CST)
Message-ID: <05a501bf8623$35be6230$048f7e82@crhc.uiuc.edu>
From: "Jeff Monks" <jmonks@uiuc.edu>
To: "Li Li" <lili@cs.cornell.edu>, <manet@itd.nrl.navy.mil>
References: <Pine.SUN.3.91.1000304010229.24428B@yodel.cs.cornell.edu>
Subject: Re: MANET application scenarioes
Date: Sat, 4 Mar 2000 15:47:16 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
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
Content-Transfer-Encoding: 7bit

One example of a current vendor implementing static ad-hoc networks to
provide home Internet access is Rooftop Communications
http://www.rooftop.com/networkFRAME.html
recently acquired by Nokia.

Jeff
----- Original Message -----
From: Li Li <lili@cs.cornell.edu>
To: <manet@itd.nrl.navy.mil>
Sent: Saturday, March 04, 2000 12:12 AM
Subject: MANET application scenarioes


> Lots of people I talked to do not really think there are convincing
> applications for ad-hoc routing except in the military. For example, in
> our dept., the wireless device uses the BS to communicate to the internet
> and to one another. Lots of places that the wireless device needs
> connection, there are infrastructures such as workplace, airport, hotel,
> etc.
>
> Can anyone make a case for convincing applications outside the military?
>
> Li Li
> Dept. of Computer Science
> Cornell University
>
>



From owner-manet@itd.nrl.navy.mil  Sat Mar  4 19:51:36 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 TAA09427
	for <manet-archive@odin.ietf.org>; Sat, 4 Mar 2000 19:51:35 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id SAA27711
	for manet-outgoing; Sat, 4 Mar 2000 18:05:47 -0500 (EST)
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 SAA27702
	for <manet@itd.nrl.navy.mil>; Sat, 4 Mar 2000 18:05:39 -0500 (EST)
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 PAA10415;
	Sat, 4 Mar 2000 15:05:11 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id PAA14486;
	Sat, 4 Mar 2000 15:05:11 -0800
X-Virus-Scanned:  Sat, 4 Mar 2000 15:05:11 -0800 Nokia Silicon Valley Email Exploit Scanner
Received: from <charliep@iprg.nokia.com> (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com  SMTP/WTS (12.69)
 xma014358; Sat, 4 Mar 00 15:05:08 -0800
Message-ID: <38C196A4.73A8FBED@iprg.nokia.com>
Date: Sat, 04 Mar 2000 15:05:08 -0800
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Mary Baker <mgbaker@plastique.stanford.edu>,
        Mobile Ad Hoc IETF working group <manet@itd.nrl.navy.mil>
Subject: Re: Stable Linux MANET Implementations?
References: <200003040126.UAA16086@itd.nrl.navy.mil>
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 Mary,

I also have read TRIAD, but I think there are some very significant
difficulties with the concept, which I don't want to go through just
now.  Suffice it to say that TRIAD deployment seems even more problematic
than IPv6 deployment, and that almost any scheme would work if everyone
agreed to do that scheme.  I don't think that TRIAD has any relevance
whatsoever to manet, and therefore I don't think this is the mailing
list to discuss the issues of TRIAD vs. IPv6.

Regards,
Charlie P.



Mary Baker wrote:
> 
> >
> > I wrote to one member of the manet group on this issue, and his reply
> > was
> > >yes v6 for ad hoc nets will be interesting...when v6 happens of course.
> > A reply that suggests v6 is a long way away. However, everyone said that
> > about computers having 100 MB/ram (when the biggest you ever heard of was
> > 8 MB). Given the current congestion of the numbering space in IPv4, and
> > that IPv6 stacks do exist, a shift to v6 is imminent.
> >
> > Comment, anyone?
> 
> Those interested in this topic might like to look at
>         http://www.dsg.stanford.edu/papers/triad/triad.html
> 
> This is a project called TRIAD going on in David Cheriton's group at Stanford,
> and it addresses some of the worries people have about IPv6 deployability.
> It even has a section in it about perceived deployability issues.  They
> present what looks like an interesting alternative that is, in a sense,
> already
> taking place.  Please note that I'm not a member of the TRIAD project, but
> I found it to be interesting reading.
> 
> Mary


From owner-manet@itd.nrl.navy.mil  Sun Mar  5 03:22:41 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 DAA01867
	for <manet-archive@odin.ietf.org>; Sun, 5 Mar 2000 03:22:41 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id BAA01049
	for manet-outgoing; Sun, 5 Mar 2000 01:03:37 -0500 (EST)
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 BAA01044
	for <manet@itd.nrl.navy.mil>; Sun, 5 Mar 2000 01:03:34 -0500 (EST)
Received: from localhost (talucci@localhost)
	by cheetah.cs.ucla.edu (8.9.1/UCLACS-5.0) with ESMTP id WAA04564;
	Sat, 4 Mar 2000 22:03:29 -0800 (PST)
Date: Sat, 4 Mar 2000 22:03:29 -0800 (PST)
From: Fabrizio Talucci <talucci@cs.ucla.edu>
To: manet@itd.nrl.navy.mil
cc: lili@cs.cornell.edu
Subject: Re: MANET application scenarioes
In-Reply-To: <Pine.SUN.3.91.1000304010229.24428B@yodel.cs.cornell.edu>
Message-ID: <Pine.SOL.4.10.10003042058460.27575-100000@cheetah.cs.ucla.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

What about the space ?

Do we really need to create a full-duplex radio link from the earth to
each single satellite ?
One, or even more, huge, mobile and expensive antennas on the earth 
for each satellite to track ?

If only few of them, carefully designed and deployed (geostationary orbit?),
could take care of the communication-to-the-earth task,
the others would just need ...

a satellite ad-hoc network ?

less power, smaller antennas, smaller size, less weight, less money,
no more severe orbit communication constraints, ...

Just thinkering,

 Fabrizio Talucci
 CSD-UCLA


On Sat, 4 Mar 2000, Li Li wrote:

> Lots of people I talked to do not really think there are convincing 
> applications for ad-hoc routing except in the military. For example, in 
> our dept., the wireless device uses the BS to communicate to the internet 
> and to one another. Lots of places that the wireless device needs 
> connection, there are infrastructures such as workplace, airport, hotel, 
> etc. 
> 
> Can anyone make a case for convincing applications outside the military?
> 
> Li Li
> Dept. of Computer Science
> Cornell University
>  
> 




From owner-manet@itd.nrl.navy.mil  Sun Mar  5 08:20:35 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 IAA08362
	for <manet-archive@odin.ietf.org>; Sun, 5 Mar 2000 08:20:34 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id GAA02989
	for manet-outgoing; Sun, 5 Mar 2000 06:30:21 -0500 (EST)
Received: from anise.ee.cornell.edu (ANISE.EE.CORNELL.EDU [128.84.239.14])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id GAA02957
	for <manet@itd.nrl.navy.mil>; Sun, 5 Mar 2000 06:30:16 -0500 (EST)
Received: from verdi.ee.cornell.edu (VERDI.EE.CORNELL.EDU [128.84.240.71])
	by anise.ee.cornell.edu (8.9.3/8.9.1) with SMTP id GAA21185;
	Sun, 5 Mar 2000 06:30:12 -0500 (EST)
Date: Sun, 5 Mar 2000 06:30:12 -0500 (EST)
From: Zygmunt Haas <haas@anise.ee.cornell.edu>
To: manet@itd.nrl.navy.mil
cc: lili@cs.cornell.edu
Subject: Re: MANET application scenarioes
In-Reply-To: <Pine.SOL.4.10.10003042058460.27575-100000@cheetah.cs.ucla.edu>
Message-ID: <Pine.HPP.3.96.1000305062604.7054G-100000@verdi.ee.cornell.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk


> What about the space ?

Yes, and what about the inter-UFO communication. I can already imagine,
millions of spacemen roaming through the galaxy, creating ad-hoc
networks ... (:-) ...

~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
Prof. Zygmunt J. Haas                    tel: +1-607-255-3454
Wireless Networks Laboratory		                  
School of Electrical Engineering         fax: +1-607-255-9072 
Cornell University
323 Frank Rhodes Hall			 e-mail: haas@ee.cornell.edu
Ithaca, NY 14853			 
U.S.A                             http://www.ee.cornell.edu/~haas/wnl.html
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-

> On Sat, 4 Mar 2000, Li Li wrote:
> 
> > Lots of people I talked to do not really think there are convincing 
> > applications for ad-hoc routing except in the military. For example, in 
> > our dept., the wireless device uses the BS to communicate to the internet 
> > and to one another. Lots of places that the wireless device needs 
> > connection, there are infrastructures such as workplace, airport, hotel, 
> > etc. 
> > 
> > Can anyone make a case for convincing applications outside the military?
> > 
> > Li Li
> > Dept. of Computer Science
> > Cornell University
> >  
> > 
> 
> 
> 



From owner-manet@itd.nrl.navy.mil  Sun Mar  5 10:48: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 KAA09247
	for <manet-archive@odin.ietf.org>; Sun, 5 Mar 2000 10:48:47 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id IAA03977
	for manet-outgoing; Sun, 5 Mar 2000 08:53:48 -0500 (EST)
Received: from hematita.dcc.ufmg.br (hematita.dcc.ufmg.br [150.164.10.11])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id IAA03972
	for <manet@itd.nrl.navy.mil>; Sun, 5 Mar 2000 08:53:40 -0500 (EST)
Received: from hyperion (hyperion [150.164.5.38])
	by hematita.dcc.ufmg.br (8.8.8/8.8.8) with SMTP id KAA21597;
	Sun, 5 Mar 2000 10:53:34 -0300 (EST)
Date: Sun, 5 Mar 2000 10:53:33 -0300 (EST)
From: Daniel Camara <danielc@dcc.ufmg.br>
X-Sender: danielc@hyperion
To: manet@itd.nrl.navy.mil
cc: Li Li <lili@cs.cornell.edu>
Subject: Re: MANET application scenarioes
In-Reply-To: <05a501bf8623$35be6230$048f7e82@crhc.uiuc.edu>
Message-ID: <Pine.SOL.4.02.10003051033160.1651-100000@hyperion>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk


        Hi,
           
        Rescue scenarios, conferences, even iterative games, if you want a
more commercial, and funny, issue :).  Imagine a RPG played in an
iterative form, with portable devices and relative information about the
environment. Interesting no??  Can you imagine the complexity required in
the routing protocol to do this in a efficient way???

	It's only one more example :).

	 Regards...

---------------------------
Daniel Camara  (03/05/1999)
Computer Science Graduate Student
Department of Computer Science (DCC)
Federal University of Minas Gerais (UFMG) - Belo Horizonte - Brazil
http://www.dcc.ufmg.br/~danielc - danielc@dcc.ufmg.br
  

----- Original Message -----
From: Li Li <lili@cs.cornell.edu>
To: <manet@itd.nrl.navy.mil>
Sent: Saturday, March 04, 2000 12:12 AM
Subject: MANET application scenarioes


> Lots of people I talked to do not really think there are convincing
> applications for ad-hoc routing except in the military. For example, in
> our dept., the wireless device uses the BS to communicate to the internet
> and to one another. Lots of places that the wireless device needs
> connection, there are infrastructures such as workplace, airport, hotel,
> etc.
>
> Can anyone make a case for convincing applications outside the military?
>
> Li Li
> Dept. of Computer Science
> Cornell University
>
>

> 



From owner-manet@itd.nrl.navy.mil  Sun Mar  5 17:53:19 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 RAA12022
	for <manet-archive@odin.ietf.org>; Sun, 5 Mar 2000 17:53:19 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA07485
	for manet-outgoing; Sun, 5 Mar 2000 15:57:02 -0500 (EST)
Received: from mail1.dh.trw.com (mail1.dh.trw.com [129.193.109.1])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA07480
	for <manet@itd.nrl.navy.mil>; Sun, 5 Mar 2000 15:57:00 -0500 (EST)
Received: from [129.193.123.140] by mail1.dh.trw.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAA4A39;
          Sun, 5 Mar 2000 12:56:46 -0800
User-Agent: Microsoft Outlook Express Macintosh Edition - 5.01 (1630)
Date: Sun, 05 Mar 2000 12:56:03 -0800
Subject: Re: MANET application scenarioes
From: "Ron Orr" <Ron.Orr@trw.com>
To: Li Li <lili@cs.cornell.edu>, <manet@itd.nrl.navy.mil>
Message-ID: <B4E809E3.2B6%ron.orr@trw.com>
In-Reply-To: <Pine.SUN.3.91.1000304010229.24428B@yodel.cs.cornell.edu>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk
Content-Transfer-Encoding: 7bit

Sure,

Disaster Relief during earthquakes, floods, war, fires (forest and other)
etc. Government agencies when an an area is declared "disaster area".

Scientific expeditions.

News coverage for large events (Woodstocks?) in areas which do not have
adequate communications networks in place.

Military operations other than war, such as Bosnia, Kosovo, Solmalia, East
Timor, Sinai, etc

and others which do not immediately come to mind
-- 


> From: Li Li <lili@cs.cornell.edu>
> Date: Sat, 4 Mar 2000 01:12:22 -0500 (EST)
> To: manet@itd.nrl.navy.mil
> Subject: MANET application scenarioes
> 
> Lots of people I talked to do not really think there are convincing
> applications for ad-hoc routing except in the military. For example, in
> our dept., the wireless device uses the BS to communicate to the internet
> and to one another. Lots of places that the wireless device needs
> connection, there are infrastructures such as workplace, airport, hotel,
> etc. 
> 
> Can anyone make a case for convincing applications outside the military?
> 
> Li Li
> Dept. of Computer Science
> Cornell University
> 
> 
> 



From owner-manet@itd.nrl.navy.mil  Sun Mar  5 19:36:00 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 TAA12594
	for <manet-archive@odin.ietf.org>; Sun, 5 Mar 2000 19:35:59 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id RAA16333
	for manet-outgoing; Sun, 5 Mar 2000 17:48:50 -0500 (EST)
Received: from mongoose.csse.monash.edu.au (mongoose.csse.monash.edu.au [130.194.67.245])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id RAA16328
	for <manet@itd.nrl.navy.mil>; Sun, 5 Mar 2000 17:48:45 -0500 (EST)
Received: from mongoose.csse.monash.edu.au (localhost [127.0.0.1])
	by mongoose.csse.monash.edu.au (8.9.1/8.9.1) with ESMTP id IAA05043;
	Mon, 6 Mar 2000 08:52:41 +1000 (EST)
Message-Id: <200003052252.IAA05043@mongoose.csse.monash.edu.au>
To: Ron Orr <Ron.Orr@trw.com>
Cc: Li Li <lili@cs.cornell.edu>, manet@itd.nrl.navy.mil
Subject: Re: MANET application scenarioes 
In-reply-to: Your message of Sun, 05 Mar 2000 12:56:03 -0800.
             <B4E809E3.2B6%ron.orr@trw.com> 
Date: Mon, 06 Mar 2000 08:52:40 +1000
From: Carlo Kopp <carlo@cs.monash.edu.au>
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk


> Sure,
> 
> Disaster Relief during earthquakes, floods, war, fires (forest and other)
> etc. Government agencies when an an area is declared "disaster area".
> 
> Scientific expeditions.
> 
> News coverage for large events (Woodstocks?) in areas which do not have
> adequate communications networks in place.
> 
> Military operations other than war, such as Bosnia, Kosovo, Solmalia, East
> Timor, Sinai, etc
> 
> and others which do not immediately come to mind

Ron, you might like to add general aviation (ie light aircraft) to that,
since there are costs associated with maintaining VHF radio coverage using
fixed repeaters, ad hoc allows for coverage beyond that, or coverage in
hilly areas where ground based VHF becomes too expensive.

Then we have the Third World and the aid distribution problem - in places 
were there is usually no useful infrastructure. We may only see the tip of
the iceberg on TV when there is a serious disaster or famine, ie there are a
lot of people doing this work in many places we don't see.

I am sure we can think of more applications with a little time.

I'd say the general case is any situation where many people and platforms
have to operate in areas where there is little or no fixed infrastructure.
Any scenario which fits that definition is a  potential or actual MANET
application scenario.

If people are arguing against the need for ad hoc outside of the military,
this may simply reflect the idea that if it is not a high traffic load
revenue service in a high density area, they think it is not a quick return
commercial proposal so they are not interested. This I think may be a little
short-sighted a position to take.

I have run into a number of people who have distinctly negative attitudes
to ad hoc, yet when I explored their motives I usually found other agendas
ie they thought it competed with one or another fixed networking scheme
they liked. 

The fixed insfrastructure network model is built upon a century or more of
cabled comms engineering, and more than a quarter century of satellite
centric comms engineering, most of which is built around assumptions of
almost static route behaviour. For a lot of people ad hoc opens up a
new frontier of route discovery algorithms and ideas, which many may find
a little intimidating. The behaviour I have observed seems to be centred
on the idea that it is easier to say that ad hoc is useless than actually
try to understand it !

I am convinced there is a huge number of potential ad hoc applications.

Cheers,

Carlo
-------------------------------------------------------------------------------
   Carlo Kopp                             carlo@cs.monash.edu.au
   Systems Research Group                 http://www.cs.monash.edu.au/~carlo
   Computer Science & Software Eng,       Ph: +61-3-9905-5229
   Monash Uni, Clayton, 3168, AUSTRALIA
   Kopp's Third Axiom : "The less substance to an opinion, the more 
                         vigorously it will be defended."
-------------------------------------------------------------------------------


From owner-manet@itd.nrl.navy.mil  Mon Mar  6 01:36:33 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 BAA19898
	for <manet-archive@odin.ietf.org>; Mon, 6 Mar 2000 01:36:33 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id WAA18551
	for manet-outgoing; Sun, 5 Mar 2000 22:28:45 -0500 (EST)
Received: from simon.cs.cornell.edu (SIMON.CS.CORNELL.EDU [128.84.154.10])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id WAA18546
	for <manet@itd.nrl.navy.mil>; Sun, 5 Mar 2000 22:28:43 -0500 (EST)
Received: from sundial.cs.cornell.edu (SUNDIAL.CS.CORNELL.EDU [128.84.248.71])
	by simon.cs.cornell.edu (8.9.3/8.9.3/R-3.0) with ESMTP id WAA14788;
	Sun, 5 Mar 2000 22:28:39 -0500 (EST)
Received: from yodel.cs.cornell.edu (YODEL.CS.CORNELL.EDU [128.84.218.84])
	by sundial.cs.cornell.edu (8.9.3/8.9.3/M-3.1) with ESMTP id WAA08289;
	Sun, 5 Mar 2000 22:28:39 -0500 (EST)
Received: (from lili@localhost)
	by yodel.cs.cornell.edu (8.9.3/8.9.3/C-3.0) id WAA19412;
	Sun, 5 Mar 2000 22:28:38 -0500 (EST)
Date: Sun, 5 Mar 2000 22:28:38 -0500 (EST)
From: Li Li <lili@cs.cornell.edu>
To: Nitin H Vaidya <vaidya@cs.tamu.edu>
cc: Ron.Orr@trw.com, carlo@cs.monash.edu.au, manet@itd.nrl.navy.mil
Subject: Re: MANET application scenarioes
In-Reply-To: <200003060304.VAA24903@photon.cs.tamu.edu>
Message-ID: <Pine.SUN.3.91.1000305221341.17552A-100000@yodel.cs.cornell.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

Hi Nitin,

I like the way you rephrase the question. As you pointed out (which is 
also my concern), there are not many convincing "civilian" applications 
for MANET of "fast moving" nodes. Most applications for MANET of 
"slow/occasionally moving" nodes may not need the protocols currently 
developed by MANET, trivial extension of traditional wired routing 
protocols may work very well. 

I am trying to stimulate discussions on possible convincing 
"civilian" applications for "fast/often" moving" nodes so that we could 
make a strong case for MANET and fend off criticisms about ad-hoc 
routing.

Li     

On Sun, 5 Mar 2000, Nitin H Vaidya wrote:

>   >> I am sure we can think of more applications with a little time.
> 
> That should be good enough for another start-up -:)
> 
> It might be useful to rephrase the question this thread
> is trying to answer, and split into two parts:
> 
> 1. What are applications of MANETs of "fast/often moving" nodes?
> 
> 2. What are applications of MANETs of "slow/ocassionally moving" nodes?
> 
> The second type of MANETs - with slow moving nodes - will
> see plenty of "civilian"
> applications (in absence of war, disaster, and despite
> presence of other infrastructure). Home networking, for instance.
> Even if you have a base station covering your home, ad hoc networks
> can let you extend the "range" of the infrastructure.
> Alternatively, ad hoc network can serve as a "backup" when
> the base station in your home fails, or cannot communicate
> with some nodes (due to some local/temporary interference).
> Besides, with ad hoc networking, you do not need to have
> a base station at all, which may make them preferable
> for some home networks. Nodes in a home are not likely
> to move terribly fast (except perhaps during
> an ad break), so topology changes are not likely to be
> too frequent.
> 
> MANETs of fast moving nodes seem to have much fewer
> civilian applications as yet, although the research issues here
> are more interesting, hence the flurry of research.
> I have not heard many convincing "civilian" applications
> of MANETs of fast moving nodes. (Yes, I have thought of
> ad hoc network of New York cabbies.)
> I am sure eventually someone will come up with a killer
> app for such MANETs too.
> 
> Cheerio.
> 
> - nitin
> 


From owner-manet@itd.nrl.navy.mil  Mon Mar  6 01:38:52 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 BAA19996
	for <manet-archive@odin.ietf.org>; Mon, 6 Mar 2000 01:38:51 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id WAA18307
	for manet-outgoing; Sun, 5 Mar 2000 22:04:49 -0500 (EST)
Received: from cs.tamu.edu (clavin.cs.tamu.edu [128.194.130.106])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id WAA18302
	for <manet@itd.nrl.navy.mil>; Sun, 5 Mar 2000 22:04:47 -0500 (EST)
Received: from photon.cs.tamu.edu (IDENT:2654@photon [128.194.134.1])
	by cs.tamu.edu (8.9.3/8.9.3) with ESMTP id VAA29624;
	Sun, 5 Mar 2000 21:04:44 -0600 (CST)
From: Nitin H Vaidya <vaidya@cs.tamu.edu>
Received: (from vaidya@localhost)
	by photon.cs.tamu.edu (8.9.3/8.9.3) id VAA24903;
	Sun, 5 Mar 2000 21:04:54 -0600 (CST)
Date: Sun, 5 Mar 2000 21:04:54 -0600 (CST)
Message-Id: <200003060304.VAA24903@photon.cs.tamu.edu>
To: Ron.Orr@trw.com, carlo@cs.monash.edu.au
Subject: Re: MANET application scenarioes
Cc: lili@cs.cornell.edu, manet@itd.nrl.navy.mil
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

  >> I am sure we can think of more applications with a little time.

That should be good enough for another start-up -:)

It might be useful to rephrase the question this thread
is trying to answer, and split into two parts:

1. What are applications of MANETs of "fast/often moving" nodes?

2. What are applications of MANETs of "slow/ocassionally moving" nodes?

The second type of MANETs - with slow moving nodes - will
see plenty of "civilian"
applications (in absence of war, disaster, and despite
presence of other infrastructure). Home networking, for instance.
Even if you have a base station covering your home, ad hoc networks
can let you extend the "range" of the infrastructure.
Alternatively, ad hoc network can serve as a "backup" when
the base station in your home fails, or cannot communicate
with some nodes (due to some local/temporary interference).
Besides, with ad hoc networking, you do not need to have
a base station at all, which may make them preferable
for some home networks. Nodes in a home are not likely
to move terribly fast (except perhaps during
an ad break), so topology changes are not likely to be
too frequent.

MANETs of fast moving nodes seem to have much fewer
civilian applications as yet, although the research issues here
are more interesting, hence the flurry of research.
I have not heard many convincing "civilian" applications
of MANETs of fast moving nodes. (Yes, I have thought of
ad hoc network of New York cabbies.)
I am sure eventually someone will come up with a killer
app for such MANETs too.

Cheerio.

- nitin



From owner-manet@itd.nrl.navy.mil  Mon Mar  6 04:33:52 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 EAA01301
	for <manet-archive@odin.ietf.org>; Mon, 6 Mar 2000 04:33:52 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id CAA01819
	for manet-outgoing; Mon, 6 Mar 2000 02:37:55 -0500 (EST)
Received: from mongoose.csse.monash.edu.au (mongoose.csse.monash.edu.au [130.194.67.245])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id CAA01814
	for <manet@itd.nrl.navy.mil>; Mon, 6 Mar 2000 02:37:49 -0500 (EST)
Received: from mongoose.csse.monash.edu.au (localhost [127.0.0.1])
	by mongoose.csse.monash.edu.au (8.9.1/8.9.1) with ESMTP id RAA05578;
	Mon, 6 Mar 2000 17:40:56 +1000 (EST)
Message-Id: <200003060740.RAA05578@mongoose.csse.monash.edu.au>
To: Li Li <lili@cs.cornell.edu>
Cc: Nitin H Vaidya <vaidya@cs.tamu.edu>, Ron.Orr@trw.com,
        Carlo.Kopp@infotech.monash.edu.au, manet@itd.nrl.navy.mil
Subject: Re: MANET application scenarioes 
In-reply-to: Your message of Sun, 05 Mar 2000 22:28:38 -0500.
             <Pine.SUN.3.91.1000305221341.17552A-100000@yodel.cs.cornell.edu> 
Date: Mon, 06 Mar 2000 17:40:56 +1000
From: Carlo Kopp <carlo@cs.monash.edu.au>
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk


> Hi Nitin,
> 
> I like the way you rephrase the question. As you pointed out (which is 
> also my concern), there are not many convincing "civilian" applications 
> for MANET of "fast moving" nodes. Most applications for MANET of 
> "slow/occasionally moving" nodes may not need the protocols currently 
> developed by MANET, trivial extension of traditional wired routing 
> protocols may work very well. 
> 
> I am trying to stimulate discussions on possible convincing 
> "civilian" applications for "fast/often" moving" nodes so that we could 
> make a strong case for MANET and fend off criticisms about ad-hoc 
> routing.
> 
Li,

A light aircraft using ad hoc protocols will be moving at a minimal speed of
about 70 knots and more typically between 100 and 200 knots. That is an 
immediate application for the distribution eg of weather data, approach
charts, safety advisories, local are and terminal traffic status information
and GPS and DGPS position information and updates.

This application has the immediate property of "continuous/fast motion" while
airborne. Also I am sure that you could sell it right now if you had
a working system !

This is an immediate application which has the required properties, and
is commercially viable. 

A similar case can be made for many maritime uses, such as mutual support
by fishing fleet vessels etc.

I am happy to debate this with anybody who chooses to dispute it !

Cheers,

Carlo


From owner-manet@itd.nrl.navy.mil  Mon Mar  6 07:17: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 HAA03014
	for <manet-archive@odin.ietf.org>; Mon, 6 Mar 2000 07:17:23 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id FAA03340
	for manet-outgoing; Mon, 6 Mar 2000 05:00:22 -0500 (EST)
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 FAA03335
	for <manet@itd.nrl.navy.mil>; Mon, 6 Mar 2000 05:00:20 -0500 (EST)
Received: from localhost (talucci@localhost)
	by cheetah.cs.ucla.edu (8.9.1/UCLACS-5.0) with ESMTP id BAA15990;
	Mon, 6 Mar 2000 01:59:56 -0800 (PST)
Date: Mon, 6 Mar 2000 01:59:55 -0800 (PST)
From: Fabrizio Talucci <talucci@cs.ucla.edu>
To: Zygmunt Haas <haas@anise.ee.cornell.edu>
cc: manet@itd.nrl.navy.mil, lili@cs.cornell.edu
Subject: Re: MANET application scenarioes
In-Reply-To: <Pine.HPP.3.96.1000305062604.7054G-100000@verdi.ee.cornell.edu>
Message-ID: <Pine.SOL.4.10.10003051727470.2925-100000@cheetah.cs.ucla.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk


On Sun, 5 Mar 2000, Zygmunt Haas wrote:

> 
> > What about the space ?
> 
> Yes, and what about the inter-UFO communication. I can already imagine,
> millions of spacemen roaming through the galaxy, creating ad-hoc
> networks ... (:-) ...
> 

Prof., much more than that,
I can even envisage them manipulating their ad-hoc 'sensor' networks
in their 'Smart Environments', too !

 Fabrizio Talucci ;-]
 CSD-UCLA




> ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
> Prof. Zygmunt J. Haas                    tel: +1-607-255-3454
> Wireless Networks Laboratory		                  
> School of Electrical Engineering         fax: +1-607-255-9072 
> Cornell University
> 323 Frank Rhodes Hall			 e-mail: haas@ee.cornell.edu
> Ithaca, NY 14853			 
> U.S.A                             http://www.ee.cornell.edu/~haas/wnl.html
> ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
> 
> > On Sat, 4 Mar 2000, Li Li wrote:
> > 
> > > Lots of people I talked to do not really think there are convincing 
> > > applications for ad-hoc routing except in the military. For example, in 
> > > our dept., the wireless device uses the BS to communicate to the internet 
> > > and to one another. Lots of places that the wireless device needs 
> > > connection, there are infrastructures such as workplace, airport, hotel, 
> > > etc. 
> > > 
> > > Can anyone make a case for convincing applications outside the military?
> > > 
> > > Li Li
> > > Dept. of Computer Science
> > > Cornell University
> > >  
> > > 
> > 
> > 
> > 
> 
> 














From owner-manet@itd.nrl.navy.mil  Mon Mar  6 12:06: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 MAA15005
	for <manet-archive@odin.ietf.org>; Mon, 6 Mar 2000 12:06:44 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA08070
	for manet-outgoing; Mon, 6 Mar 2000 10:06:33 -0500 (EST)
Received: from vega.upv.es (vega.cc.upv.es [158.42.4.1])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA08065
	for <manet@itd.nrl.navy.mil>; Mon, 6 Mar 2000 10:06:23 -0500 (EST)
Received: from disca.upv.es (montgo.disca.upv.es [158.42.50.203])
	by vega.upv.es (8.8.4/8.8.5) with SMTP id QAA21138;
	Mon, 6 Mar 2000 16:06:02 +0100 (MET)
Received: from ieee.org by disca.upv.es (SMI-8.6/SMI-SVR4)
	id QAA14023; Mon, 6 Mar 2000 16:18:28 GMT
Message-ID: <38C3C9D0.91A8D8F2@ieee.org>
Date: Mon, 06 Mar 2000 16:08:00 +0100
From: Miguel Sanchez <misan@ieee.org>
Organization: Universidad Politecnica de Valencia
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: mkt@ecs.soton.ac.uk
CC: Li Li <lili@cs.cornell.edu>, manet@itd.nrl.navy.mil
Subject: Re: MANET application scenarioes
References: <200003040126.UAA16086@itd.nrl.navy.mil> <Pine.SUN.3.91.1000304010229.24428B@yodel.cs.cornell.edu> <20000304110351.A1282@ecs.soton.ac.uk>
Content-Type: multipart/alternative;
 boundary="------------D45C80DC03D296DC55C26C12"
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk


--------------D45C80DC03D296DC55C26C12
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Li, Mark and all,

Some (not necessary new) applications:

* Remote sensing (earthquakes, fire, environmental data gathering, ...): In
this application you can launch (robust) probes from a plane (maybe with
parachutes :-) without even landing. Data can be distributedly gathered, then
a special node (coordinator) will contact with the headquarter (with a sat
link or a higher power radio).

* Robotic communication (cleaning, firefighting, patrolling, oceanic fishing
(maybe not yet :-), farming,  planets surface exploration (think of several
Sojourners instead of just one) ... :  In this scenario, a set of mobile
robots are performing a local task, each one working in its own area. Group
coordination is done by means of a manet.

* Internet access: In some countries, Internet access is not available for a
(low) flat rate (i.e. most European countries). Students with housing near
university campus can build a manet (in this case with non-mobile hosts) to
access campus backbone (and Internet from there). While houses closer to
campus can have direct access, those far away can get through intermediate
routers. The high rate network changes can justifiy the use of manet protocols
(computers turned on, shutted down, reboots, OS features ...). This can add
mobile support for people carrying notebooks in their way to campus. (Don't
forget that CDPD, Rooftop, Metricom, etc are USA based, some other European
countries do not have any of these mobile data services and proposals like WAP
and GPRS are still in the early stage of deployment).

* LEO constellations: By itself could constitute a especial kind of manet.
(mobile nodes, limited transmission range, changing neigborhood, BUT a
predictable neighborhood switching scheme!).  I mean about inter-sat links.

Anyway, I think that some of the manet applications can exploit the advantages
of manet routing but then, manet can be interconnected to other
infrastructure-based networks.

No military application was cited. I hope this can help.

Best,

Miguel

Mark Thompson wrote:

> On 01:12(GMT) 04-03-00, Li Li wrote:
> > Lots of people I talked to do not really think there are convincing
> > applications for ad-hoc routing except in the military. For example, in
> > our dept., the wireless device uses the BS to communicate to the internet
> > and to one another. Lots of places that the wireless device needs
> > connection, there are infrastructures such as workplace, airport, hotel,
> > etc.
> >
> > Can anyone make a case for convincing applications outside the military?
>
> ``A boy-scouts meeting in a field?'' ;-)
>
> Seriously though, there are numerous scenarios where full access to the
> Internet (note the big I) is either not available or not necessrary. We're
> in a world where it isn't just laptop computers that are comms enabled,
> but also PDAs, cellulars, and toasters(!)  Whilst HomeRF, Bluetooth
> etc. may be providing rudimentary comms for some of these scenarios,
> they dont AFAIK cover the routing of messages via devices, only between
> them, or via a designated hub/switch/router...
>
> Granted, the often quoted scenarios of meetings in offices; the hotel
> lobby even the dentists office (/me nods to the IETF ipngwg) usually
> stress the "well, we can give you global addressing and stateless
> addrconf, so you can access the 'net", but they all require supporting
> infrastructure.
>
> IMO, the strongest case for the manet initiative is that it is
> striving to provide that infrastructure "for free" (i.e. no additional
> switches/hubs/wLAN BSes/hardware), but by software stacks on the
> participating clients themselves.
>
> The "convincing applications" are every single networked device scenario,
> but without the infrastructure hardware - just the devices (thus people)
> that want to communicate.
>
> ... or am I way off the mark here?
>
> Mark/
>
> --
> iam: networks and distributed systems
> http://www.ecs.soton.ac.uk/~mkt/contact.shtml for contact info...

--
Miguel Sanchez Lopez                            |       misan@ieee.org
Universidad Politecnica de Valencia             | voice:+3496 387 9700
Camino de Vera, 14                              | fax:  +3496 387 7579
46071 VALENCIA (Spain)                          |



--------------D45C80DC03D296DC55C26C12
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi Li, Mark and all,
<p>Some (not necessary new)&nbsp;applications:
<p>*&nbsp;Remote sensing (earthquakes, fire, environmental data gathering,
...):&nbsp;In this application you can launch (robust) probes from a plane
(maybe with parachutes :-) without even landing. Data can be distributedly
gathered, then a special node (coordinator) will contact with the headquarter
(with a sat link or a higher power radio).
<p>* Robotic communication (cleaning, firefighting, patrolling, oceanic
fishing (maybe not yet :-), farming,&nbsp; planets surface exploration
(think of several Sojourners instead of just one)&nbsp;... :&nbsp; In this
scenario, a set of mobile robots are performing a local task, each one
working in its own area. Group coordination is done by means of a manet.
<p>* Internet access: In some countries, Internet access is not available
for a (low) flat rate (i.e. most European countries). Students with housing
near university campus can build a manet (in this case with non-mobile
hosts) to access campus backbone (and Internet from there). While houses
closer to campus can have direct access, those far away can get through
intermediate routers. The high rate network changes can justifiy the use
of manet protocols (computers turned on, shutted down, reboots, OS features
...). This can add mobile support for people carrying notebooks in their
way to campus. (Don't forget that CDPD, Rooftop, Metricom, etc are USA
based, some other European countries do not have any of these mobile data
services and proposals like WAP and GPRS are still in the early stage of
deployment).
<p>* LEO constellations: By itself could constitute a especial kind of
manet. (mobile nodes, limited transmission range, changing neigborhood,
BUT a predictable neighborhood switching scheme!).&nbsp; I mean about inter-sat
links.
<p>Anyway, I&nbsp;think that some of the manet applications can exploit
the advantages of manet routing but then, manet can be interconnected to
other infrastructure-based networks.
<p>No military application was cited. I hope this can help.
<p>Best,
<p>Miguel
<p>Mark Thompson wrote:
<blockquote TYPE=CITE>On 01:12(GMT) 04-03-00, Li Li wrote:
<br>> Lots of people I talked to do not really think there are convincing
<br>> applications for ad-hoc routing except in the military. For example,
in
<br>> our dept., the wireless device uses the BS to communicate to the
internet
<br>> and to one another. Lots of places that the wireless device needs
<br>> connection, there are infrastructures such as workplace, airport,
hotel,
<br>> etc.
<br>>
<br>> Can anyone make a case for convincing applications outside the military?
<p>``A boy-scouts meeting in a field?'' ;-)
<p>Seriously though, there are numerous scenarios where full access to
the
<br>Internet (note the big I) is either not available or not necessrary.
We're
<br>in a world where it isn't just laptop computers that are comms enabled,
<br>but also PDAs, cellulars, and toasters(!)&nbsp; Whilst HomeRF, Bluetooth
<br>etc. may be providing rudimentary comms for some of these scenarios,
<br>they dont AFAIK cover the routing of messages via devices, only between
<br>them, or via a designated hub/switch/router...
<p>Granted, the often quoted scenarios of meetings in offices; the hotel
<br>lobby even the dentists office (/me nods to the IETF ipngwg) usually
<br>stress the "well, we can give you global addressing and stateless
<br>addrconf, so you can access the 'net", but they all require supporting
<br>infrastructure.
<p>IMO, the strongest case for the manet initiative is that it is
<br>striving to provide that infrastructure "for free" (i.e. no additional
<br>switches/hubs/wLAN BSes/hardware), but by software stacks on the
<br>participating clients themselves.
<p>The "convincing applications" are every single networked device scenario,
<br>but without the infrastructure hardware - just the devices (thus people)
<br>that want to communicate.
<p>... or am I way off the mark here?
<p>Mark/
<p>--
<br>iam: networks and distributed systems
<br><a href="http://www.ecs.soton.ac.uk/~mkt/contact.shtml">http://www.ecs.soton.ac.uk/~mkt/contact.shtml</a>
for contact info...</blockquote>

<pre>--&nbsp;
Miguel Sanchez Lopez&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; misan@ieee.org
Universidad Politecnica de Valencia&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | voice:+3496 387 9700&nbsp;&nbsp;
Camino de Vera, 14&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | fax:&nbsp; +3496 387 7579&nbsp;
46071 VALENCIA (Spain)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</pre>
&nbsp;</html>

--------------D45C80DC03D296DC55C26C12--



From owner-manet@itd.nrl.navy.mil  Mon Mar  6 12:34:07 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 MAA16289
	for <manet-archive@odin.ietf.org>; Mon, 6 Mar 2000 12:34:04 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA09227
	for manet-outgoing; Mon, 6 Mar 2000 10:35:59 -0500 (EST)
Received: from cs.tamu.edu (clavin.cs.tamu.edu [128.194.130.106])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA09222
	for <manet@itd.nrl.navy.mil>; Mon, 6 Mar 2000 10:35:57 -0500 (EST)
Received: from sun.cs.tamu.edu (IDENT:2654@sun [128.194.135.14])
	by cs.tamu.edu (8.9.3/8.9.3) with ESMTP id JAA12456;
	Mon, 6 Mar 2000 09:35:49 -0600 (CST)
From: Nitin H Vaidya <vaidya@cs.tamu.edu>
Received: (from vaidya@localhost)
	by sun.cs.tamu.edu (8.9.3/8.9.3) id JAA12770;
	Mon, 6 Mar 2000 09:35:27 -0600 (CST)
Date: Mon, 6 Mar 2000 09:35:27 -0600 (CST)
Message-Id: <200003061535.JAA12770@sun.cs.tamu.edu>
To: carlo@cs.monash.edu.au
Subject: Re: MANET application scenarioes
Cc: manet@itd.nrl.navy.mil
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

  >> From carlo@mongoose.csse.monash.edu.au Mon Mar  6 01:37:31 2000
  >> 
  >> A light aircraft using ad hoc protocols will be moving at a minimal speed of
  >> about 70 knots and more typically between 100 and 200 knots. That is an 
  >> immediate application for the distribution eg of weather data, approach
  >> charts, safety advisories, local are and terminal traffic status information
  >> and GPS and DGPS position information and updates.

I believe the prior discussion was related to the
issue of routing for MANET, presumably unicast routing.
So please consider my comments in that context.

The application you mention above seems somewhat different
than what the typical ad hoc routing protocol targets.
This application appears more related to the stuff on
"sensor networks" which has become popular with
U.S. academia lately (thanks to DARPA) - correct me if
I am mistaken.

Would these aircrafts want to get the weather data from
a "specific" node, or just any aircraft (node) which happens
to know latest weather? To put it differently, would you
be addressing nodes based on their "IP address", or based
on the kind of data they might be able to provide?
In the latter case, the network
protocols needed are different from the vanilla unicast
protocols, particularly, putting them out of current scope
of MANET working group. (I do believe that the current scope
is terribly narrow, but that is another discussion).

  >> This application has the immediate property of "continuous/fast motion" while
  >> airborne. Also I am sure that you could sell it right now if you had
  >> a working system !

I hope your are right.

Regards.

- nitin



From owner-manet@itd.nrl.navy.mil  Mon Mar  6 12:34:19 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 MAA16329
	for <manet-archive@odin.ietf.org>; Mon, 6 Mar 2000 12:34:16 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA09357
	for manet-outgoing; Mon, 6 Mar 2000 10:39:43 -0500 (EST)
Received: from tabasco (tabasco.itd.nrl.navy.mil [132.250.92.182])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id KAA09352;
	Mon, 6 Mar 2000 10:39:39 -0500 (EST)
Message-Id: <4.1.20000306100555.0162f100@pop.itd.nrl.navy.mil>
X-Sender: macker@pop.itd.nrl.navy.mil
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 06 Mar 2000 10:37:39 -0500
To: Nitin H Vaidya <vaidya@cs.tamu.edu>
From: Joe Macker <macker@itd.nrl.navy.mil>
Subject: Re: MANET application scenarioes
Cc: manet@itd.nrl.navy.mil
In-Reply-To: <200003060304.VAA24903@photon.cs.tamu.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

At 09:04 PM 3/5/00 -0600, you wrote:
>  >> I am sure we can think of more applications with a little time.
>
>That should be good enough for another start-up -:)
>
>It might be useful to rephrase the question this thread
>is trying to answer, and split into two parts:
>
>1. What are applications of MANETs of "fast/often moving" nodes?
>
>2. What are applications of MANETs of "slow/ocassionally moving" nodes?
>
>The second type of MANETs - with slow moving nodes - will
>see plenty of "civilian"
>applications (in absence of war, disaster, and despite
>presence of other infrastructure). Home networking, for instance.
>Even if you have a base station covering your home, ad hoc networks
>can let you extend the "range" of the infrastructure.
>Alternatively, ad hoc network can serve as a "backup" when
>the base station in your home fails, or cannot communicate
>with some nodes (due to some local/temporary interference).
>Besides, with ad hoc networking, you do not need to have
>a base station at all, which may make them preferable
>for some home networks. Nodes in a home are not likely
>to move terribly fast (except perhaps during
>an ad break), so topology changes are not likely to be
>too frequent.

Nitin:

Additional 2 cents.

Some interesting observations.  I would add that even in some slow moving
networks ... topologies may be more dynamic that motion would indicate
(e.g., power cycling, urban multipath).  Meshed rooftops could be similar.
Just an additional thought for consideration.  

Dynamics are motion/range relative and I think low power, inexpensive
micronets could be another interesting area.  Small range, low power
provides an interesting perspective from the typical macro mobility vision
we like to talk about.  (Batteries don't follow Moore's law) so there is
operational incentive to go here for some applications.  So I am not sure
things have to move fast (on macro level) for topologies to be moderately
dynamic.

I could see this being a big issue for power-conserving robotics
applications, home networking, wearable computing, etc.

-Joe



From owner-manet@itd.nrl.navy.mil  Mon Mar  6 12:34: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 MAA16349
	for <manet-archive@odin.ietf.org>; Mon, 6 Mar 2000 12:34:23 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA09519
	for manet-outgoing; Mon, 6 Mar 2000 10:46:07 -0500 (EST)
Received: from cs.tamu.edu (clavin.cs.tamu.edu [128.194.130.106])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA09513;
	Mon, 6 Mar 2000 10:46:03 -0500 (EST)
Received: from sun.cs.tamu.edu (IDENT:2654@sun [128.194.135.14])
	by cs.tamu.edu (8.9.3/8.9.3) with ESMTP id JAA12937;
	Mon, 6 Mar 2000 09:45:56 -0600 (CST)
From: Nitin H Vaidya <vaidya@cs.tamu.edu>
Received: (from vaidya@localhost)
	by sun.cs.tamu.edu (8.9.3/8.9.3) id JAA12828;
	Mon, 6 Mar 2000 09:45:34 -0600 (CST)
Date: Mon, 6 Mar 2000 09:45:34 -0600 (CST)
Message-Id: <200003061545.JAA12828@sun.cs.tamu.edu>
To: macker@itd.nrl.navy.mil
Subject: Re: MANET application scenarioes
Cc: manet@itd.nrl.navy.mil
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

  >> From macker@itd.nrl.navy.mil Mon Mar  6 09:39:38 2000
  >>
  >> Some interesting observations.  I would add that even in some slow moving
  >> networks ... topologies may be more dynamic that motion would indicate
  >> (e.g., power cycling, urban multipath).  Meshed rooftops could be similar.
  >> Just an additional thought for consideration.  
  >> 
  >> Dynamics are motion/range relative and I think low power, inexpensive
  >> micronets could be another interesting area.  Small range, low power
  >> provides an interesting perspective from the typical macro mobility vision
  >> we like to talk about.  (Batteries don't follow Moore's law) so there is
  >> operational incentive to go here for some applications.  So I am not sure
  >> things have to move fast (on macro level) for topologies to be moderately
  >> dynamic.
  >>
  >> I could see this being a big issue for power-conserving robotics
  >> applications, home networking, wearable computing, etc.

Agreed. I guess it is worth clarifying, as you note, that speed should
be considered relative to transmission range of the devices -- I guess 
rate of topology change may be a better metric.


- nitin



From owner-manet@itd.nrl.navy.mil  Mon Mar  6 12:51:28 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 MAA17278
	for <manet-archive@odin.ietf.org>; Mon, 6 Mar 2000 12:51:24 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA10084
	for manet-outgoing; Mon, 6 Mar 2000 11:06:27 -0500 (EST)
Received: from mail.ee.gatech.edu (mail.ee.gatech.edu [130.207.230.10])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA10079
	for <manet@itd.nrl.navy.mil>; Mon, 6 Mar 2000 11:06:25 -0500 (EST)
Received: from trinity.ece.gatech.edu (trinity.ece.gatech.edu [199.77.145.156])
	by mail.ee.gatech.edu (8.9.3/8.9.3) with ESMTP id LAA01250;
	Mon, 6 Mar 2000 11:06:21 -0500 (EST)
Received: from localhost (keh@localhost)
          by trinity.ece.gatech.edu (8.8.4/8.8.4) with ESMTP
	  id LAA12603; Mon, 6 Mar 2000 11:06:21 -0500 (EST)
X-Authentication-Warning: trinity.ece.gatech.edu: keh owned process doing -bs
Date: Mon, 6 Mar 2000 11:06:21 -0500 (EST)
From: Santithorn Bunchua <keh@ece.gatech.edu>
To: Li Li <lili@cs.cornell.edu>
cc: manet@itd.nrl.navy.mil
Subject: Re: MANET application scenarioes
In-Reply-To: <Pine.SUN.3.91.1000305221341.17552A-100000@yodel.cs.cornell.edu>
Message-ID: <Pine.GSO.4.10.10003061033410.11902-100000@trinity.ece.gatech.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

Hi,

On Sun, 5 Mar 2000, Li Li wrote:

> for MANET of "fast moving" nodes. Most applications for MANET of 
> "slow/occasionally moving" nodes may not need the protocols currently 
> developed by MANET, trivial extension of traditional wired routing 
> protocols may work very well. 

Sometimes, even for the slow-moving nodes, there is a need for low-power,
low-overhead protocol since mobile devices/computers have limited power.
Also, we don't want connection to be disrupted (e.g. paused waiting for
route to converge) for too long when route breaks. For these reasons,
it is still more efficient to use MANET protocols.

In the near future, I believe many transmitters will be short-range and
thus require ad hoc networking to be more useful in extending its
communication range to other devices or fixed-network base stations.

=keh=



From owner-manet@itd.nrl.navy.mil  Mon Mar  6 12:59: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 MAA17619
	for <manet-archive@odin.ietf.org>; Mon, 6 Mar 2000 12:59:53 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA09883
	for manet-outgoing; Mon, 6 Mar 2000 10:58:57 -0500 (EST)
Received: from tabasco (tabasco.itd.nrl.navy.mil [132.250.92.182])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id KAA09877;
	Mon, 6 Mar 2000 10:58:54 -0500 (EST)
Message-Id: <4.1.20000306104717.015fa350@pop.itd.nrl.navy.mil>
X-Sender: macker@pop.itd.nrl.navy.mil
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 06 Mar 2000 10:56:55 -0500
To: Nitin H Vaidya <vaidya@cs.tamu.edu>
From: Joe Macker <macker@itd.nrl.navy.mil>
Subject: Re: MANET application scenarioes
Cc: manet@itd.nrl.navy.mil
In-Reply-To: <200003061545.JAA12828@sun.cs.tamu.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

At 09:45 AM 3/6/00 -0600, you wrote:
>  >> From macker@itd.nrl.navy.mil Mon Mar  6 09:39:38 2000
>  >>
>  >> Some interesting observations.  I would add that even in some slow moving
>  >> networks ... topologies may be more dynamic that motion would indicate
>  >> (e.g., power cycling, urban multipath).  Meshed rooftops could be
similar.
>  >> Just an additional thought for consideration.  
>  >> 
>  >> Dynamics are motion/range relative and I think low power, inexpensive
>  >> micronets could be another interesting area.  Small range, low power
>  >> provides an interesting perspective from the typical macro mobility
vision
>  >> we like to talk about.  (Batteries don't follow Moore's law) so there is
>  >> operational incentive to go here for some applications.  So I am not sure
>  >> things have to move fast (on macro level) for topologies to be moderately
>  >> dynamic.
>  >>
>  >> I could see this being a big issue for power-conserving robotics
>  >> applications, home networking, wearable computing, etc.
>
>Agreed. I guess it is worth clarifying, as you note, that speed should
>be considered relative to transmission range of the devices -- I guess 
>rate of topology change may be a better metric.
>
>

Agreed. And one might tradeoff moderate increases to the expected rate of
topology change for increased energy conservation and/or increased wireless
data rates when actually deploying a network or new technology (or an
algorithm might do this dynamically..but thats another story).  

Reasonable commercial and operational incentives to consider.

-joe




From owner-manet@itd.nrl.navy.mil  Mon Mar  6 18:24:27 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 SAA26860
	for <manet-archive@odin.ietf.org>; Mon, 6 Mar 2000 18:24:27 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA18934
	for manet-outgoing; Mon, 6 Mar 2000 16:09:04 -0500 (EST)
Received: from mongoose.csse.monash.edu.au (mongoose.csse.monash.edu.au [130.194.67.245])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA18928
	for <manet@itd.nrl.navy.mil>; Mon, 6 Mar 2000 16:08:59 -0500 (EST)
Received: from localhost (carlo@localhost)
	by mongoose.csse.monash.edu.au (8.9.1/8.9.1) with SMTP id HAA05991;
	Tue, 7 Mar 2000 07:13:05 +1000 (EST)
X-Authentication-Warning: mongoose.csse.monash.edu.au: carlo owned process doing -bs
Date: Tue, 7 Mar 2000 07:13:05 +1000 (EST)
From: Carlo Kopp <carlo@cs.monash.edu.au>
X-Sender: carlo@mongoose.csse.monash.edu.au
To: Nitin H Vaidya <vaidya@cs.tamu.edu>
cc: Carlo.Kopp@infotech.monash.edu.au, manet@itd.nrl.navy.mil
Subject: Re: MANET application scenarioes
In-Reply-To: <200003061535.JAA12770@sun.cs.tamu.edu>
Message-ID: <Pine.SUN.4.02.10003070645360.5976-100000@mongoose.csse.monash.edu.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

On Mon, 6 Mar 2000, Nitin H Vaidya wrote:

> Date: Mon, 06 Mar 2000 09:35:27 -0600 (CST)
> From: Nitin H Vaidya <vaidya@cs.tamu.edu>
> To: Carlo.Kopp@infotech.monash.edu.au
> Cc: manet@itd.nrl.navy.mil
> Subject: Re: MANET application scenarioes
> 
>   >> From carlo@mongoose.csse.monash.edu.au Mon Mar  6 01:37:31 2000
>   >> 
>   >> A light aircraft using ad hoc protocols will be moving at a minimal speed of
>   >> about 70 knots and more typically between 100 and 200 knots. That is an 
>   >> immediate application for the distribution eg of weather data, approach
>   >> charts, safety advisories, local are and terminal traffic status information
>   >> and GPS and DGPS position information and updates.
> 
> I believe the prior discussion was related to the
> issue of routing for MANET, presumably unicast routing.
> So please consider my comments in that context.
> 
> The application you mention above seems somewhat different
> than what the typical ad hoc routing protocol targets.
> This application appears more related to the stuff on
> "sensor networks" which has become popular with
> U.S. academia lately (thanks to DARPA) - correct me if
> I am mistaken.
> 
> Would these aircrafts want to get the weather data from
> a "specific" node, or just any aircraft (node) which happens
> to know latest weather? To put it differently, would you
> be addressing nodes based on their "IP address", or based
> on the kind of data they might be able to provide?
> In the latter case, the network
> protocols needed are different from the vanilla unicast
> protocols, particularly, putting them out of current scope
> of MANET working group. (I do believe that the current scope
> is terribly narrow, but that is another discussion).
> 
Nitin,

The model is to tap into a fixed ground network infrastructure which
distributes the data from various FAA ATC and database facilities. The problem
with the conventional approach is that you are limited in bandwidth if
you employ a sat link, and limited in coverage footprint if you use a
simple VHF or UHF ground station network.

Using ad hoc you can limit the number of ground stations and their cost,
by hopping the packets between aircraft over the VHF radio horizon.

You assign a unique IP address to each aircraft. The aircraft do not gather
or provide data, in general, rather they simply act as routing nodes w.r.t.
one another. They may also distribute other data like their own GPS position
for instance, but their primary function as an ad hoc network is to extend
coverage footprint.

The fishing boat scenario is similar, but eg one boat has a satcom link
to tap into sat a met database somewhere over the horizon, on the coast,
and you employ ad hoc to form a network between the boats to distribute
the data which is sent out.

This is in a sense only "one half" of a military application, since the
latter aims to pump data gathered by many moving platforms into a centralised
system, and then distribute to these platforms processed outputs of this
data and other data from centralised wide area surveillance sources.

In civilian applications the emphasis is to make available data from
centralised sources such as weather databases and ATC / GPS data. If the
network is established then you could possibly use it to collect say GPS
position data for tracking, but that is a very low bandwidth signal which
would be insignificant cf the volume of what you are trying to distribute.
Also what you are distributing will not be identical for every aircraft
or fishing boat. While some of what they may want to see may be identical,
in general this is not true. Eg in aircraft they may be looking at weather
advisories, NOTAMs, approach charts etc for different destinations. Therefore
a straight broadcast scheme is both wasteful and cumbersome.

An ongoing problem for instance is currency of maps and charts. If you can 
download the latest map as you approach a destination, this problem goes away.

Collision avoidance is another application, since you can get the same
situational picture as the air traffic controller sees.

I don't see how this diverges from current MANET objectives, insofar as
each platform has a unique IP address and may wish to make unique requests
on ground based data resources. The reason why ad hoc is used is that it
dramatically  reduces the required coverage and thus cost of the supporting
ground infrastructure.

Cheers,

Carlo



From owner-manet@itd.nrl.navy.mil  Tue Mar  7 09:48:38 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 JAA15100
	for <manet-archive@odin.ietf.org>; Tue, 7 Mar 2000 09:48:37 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id HAA01139
	for manet-outgoing; Tue, 7 Mar 2000 07:09:53 -0500 (EST)
Received: from phoebe.eim.surrey.ac.uk (phoebe.eim.surrey.ac.uk [131.227.74.4])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id HAA01134
	for <manet@itd.nrl.navy.mil>; Tue, 7 Mar 2000 07:09:49 -0500 (EST)
Received: from melian.ee.surrey.ac.uk ([131.227.50.17] ident=root)
	by phoebe.eim.surrey.ac.uk with smtp (Exim 3.03 #1)
	id 12SInt-0002Ez-00; Tue, 07 Mar 2000 12:09:33 +0000
Received: from ee.surrey.ac.uk by melian.ee.surrey.ac.uk with smtp
	(Smail3.1.29.1-ident) id m12SInj-000BGpC; Tue, 7 Mar 100 12:09 GMT
Message-ID: <38C4F173.27DE3C37@ee.surrey.ac.uk>
Date: Tue, 07 Mar 2000 12:09:23 +0000
From: George Aggelou <g.aggelou@eim.surrey.ac.uk>
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: corson@isr.umd.edu, manet <manet@itd.nrl.navy.mil>,
        rahim <r.tafazolli@eim.surrey.ac.uk>
Subject: RDMAR vs AODV: Second call for correction in IETF proceedings' page 
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 Scott,

Referring to my mail below, as this was sent a month ago, nothing has
been changed yet in IETF proceedings' page
(http://www.ietf.org/proceedings/99nov/unedit/manet-minutes-99nov.txt).

In your last mail you said that you would correct the description of
RDMAR in your report which however has not been done yet!

As the main author of the draft, I am kindly asking you *again* to
change the incorrect statement(s) in your report as these are reported
in my last mail (see below).

Please notify the WG as soon as this is fixed.

Regards,
George A.


***************************************************************************

Hello Scott,

I want to make a few clarifications on the description of RDMAR as this
is composed from you and advertised in IETF's MANET  minutes 
(http://www.ietf.org/proceedings/99nov/unedit/manet-minutes-99nov.txt)
and which contains a *categorically incorrect* statement.

You mention: "The protocol is structured along the lines of a distance
vector algorithm,uses sequence numbers to maintain loop freedom, and is
in several ways similar to AODV. The key concept behind RDM is that a
query flood can be localised by knowing the relative distance (RD)
between two terminals. "

We had a discussion last November and explained to you that RDMAR has
*nothing* in common with AODV.  So, I still can not see why you mention
that RDMAR is similar to AODV. If you still believe so, could you please
identify the similarities and inform the group if you find any?

First, the main and distinguished property of AODV is the dest_seq_nos
which are not used in RDMAR protocol as the discovery is end to end and,
thus, there is no fear for stale route in RREP messages.
Second, RDMAR makes use of sequence numbers during the Route Discovery
procedure (called RREQ_ID in the I-D) to ensure loop freedom.  AODV also
uses seq_nos but this is not a specific property of AODV protocol as
this is a well-establised technique to ensure loop freedom.
Third and most important, RDMAR presents a generic concept on the
maintenance of active paths (Route Maintenance procedure).  The Route
Maintenance algorithm in RDMAR is a distributed operation that exploits
the spatial relationship of nodes when a failure along an active route
occurs and depending on the relative
distance of the node that reports the failure from the calling and
called nodes, two heuristics are considered:

        a) if its relative distance from the called node is smaller or
           equal to this from the calling node, then RDM is to be
           applied to localise the repair of the failed route on the
           region of the network where the failure occurs; otherwise,
        b) the node proceeds and informs the calling node about the
           failure to deliver the call through this path.
        
For a detailed version and thorough understanding of the protocol,
please have a look at the paper attached herein or the RDMAR Internet
Draft.  


>From the above, I am kindly asking you to update the short description
of RDMAR in IETF's minutes page as this is currently put on and notfy
the group as soon as this is fixed.


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 Mar  7 13:21:30 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 NAA24162
	for <manet-archive@odin.ietf.org>; Tue, 7 Mar 2000 13:21:29 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA07054
	for manet-outgoing; Tue, 7 Mar 2000 11:20:17 -0500 (EST)
Received: from tabasco (tabasco.itd.nrl.navy.mil [132.250.92.182])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id LAA07046;
	Tue, 7 Mar 2000 11:19:52 -0500 (EST)
Message-Id: <4.1.20000307111536.00c39ed0@pop.itd.nrl.navy.mil>
X-Sender: macker@pop.itd.nrl.navy.mil
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 07 Mar 2000 11:17:49 -0500
To: George Aggelou <g.aggelou@eim.surrey.ac.uk>, corson@isr.umd.edu,
        manet <manet@itd.nrl.navy.mil>, rahim <r.tafazolli@eim.surrey.ac.uk>
From: Joe Macker <macker@itd.nrl.navy.mil>
Subject: Re: RDMAR vs AODV: Second call for correction in IETF
  proceedings' page 
In-Reply-To: <38C4F173.27DE3C37@ee.surrey.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

George:

I believe Scott requested this change already.

-Joe

At 12:09 PM 3/7/00 +0000, George Aggelou wrote:
>Hello Scott,
>
>Referring to my mail below, as this was sent a month ago, nothing has
>been changed yet in IETF proceedings' page
>(http://www.ietf.org/proceedings/99nov/unedit/manet-minutes-99nov.txt).
>
>In your last mail you said that you would correct the description of
>RDMAR in your report which however has not been done yet!
>
>As the main author of the draft, I am kindly asking you *again* to
>change the incorrect statement(s) in your report as these are reported
>in my last mail (see below).
>
>Please notify the WG as soon as this is fixed.
>
>Regards,
>George A.
>
>
>***************************************************************************
>
>Hello Scott,
>
>I want to make a few clarifications on the description of RDMAR as this
>is composed from you and advertised in IETF's MANET  minutes 
>(http://www.ietf.org/proceedings/99nov/unedit/manet-minutes-99nov.txt)
>and which contains a *categorically incorrect* statement.
>
>You mention: "The protocol is structured along the lines of a distance
>vector algorithm,uses sequence numbers to maintain loop freedom, and is
>in several ways similar to AODV. The key concept behind RDM is that a
>query flood can be localised by knowing the relative distance (RD)
>between two terminals. "
>
>We had a discussion last November and explained to you that RDMAR has
>*nothing* in common with AODV.  So, I still can not see why you mention
>that RDMAR is similar to AODV. If you still believe so, could you please
>identify the similarities and inform the group if you find any?
>
>First, the main and distinguished property of AODV is the dest_seq_nos
>which are not used in RDMAR protocol as the discovery is end to end and,
>thus, there is no fear for stale route in RREP messages.
>Second, RDMAR makes use of sequence numbers during the Route Discovery
>procedure (called RREQ_ID in the I-D) to ensure loop freedom.  AODV also
>uses seq_nos but this is not a specific property of AODV protocol as
>this is a well-establised technique to ensure loop freedom.
>Third and most important, RDMAR presents a generic concept on the
>maintenance of active paths (Route Maintenance procedure).  The Route
>Maintenance algorithm in RDMAR is a distributed operation that exploits
>the spatial relationship of nodes when a failure along an active route
>occurs and depending on the relative
>distance of the node that reports the failure from the calling and
>called nodes, two heuristics are considered:
>
>        a) if its relative distance from the called node is smaller or
>           equal to this from the calling node, then RDM is to be
>           applied to localise the repair of the failed route on the
>           region of the network where the failure occurs; otherwise,
>        b) the node proceeds and informs the calling node about the
>           failure to deliver the call through this path.
>        
>For a detailed version and thorough understanding of the protocol,
>please have a look at the paper attached herein or the RDMAR Internet
>Draft.  
>
>
>>From the above, I am kindly asking you to update the short description
>of RDMAR in IETF's minutes page as this is currently put on and notfy
>the group as soon as this is fixed.
>
>
>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 Mar  7 18:21:38 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 SAA23925
	for <manet-archive@odin.ietf.org>; Tue, 7 Mar 2000 18:21:37 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA15180
	for manet-outgoing; Tue, 7 Mar 2000 16:20:34 -0500 (EST)
Received: from ginger.lcs.mit.edu (ginger.lcs.mit.edu [18.26.0.82])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA15175
	for <manet@itd.nrl.navy.mil>; Tue, 7 Mar 2000 16:20:32 -0500 (EST)
Received: (from jnc@localhost)
	by ginger.lcs.mit.edu (8.9.1/8.9.1) id QAA26451;
	Tue, 7 Mar 2000 16:20:24 -0500
Date: Tue, 7 Mar 2000 16:20:24 -0500
From: "J. Noel Chiappa" <jnc@ginger.lcs.mit.edu>
Message-Id: <200003072120.QAA26451@ginger.lcs.mit.edu>
To: manet@itd.nrl.navy.mil
Subject: Re: Stable Linux MANET Implementations?
Cc: jnc@ginger.lcs.mit.edu
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

    > From: Mary Baker <mgbaker@plastique.stanford.edu>

I'm mostly replying to the part below, but while I'm here, I'll catch
the original point...

    >> A reply that suggests v6 is a long way away. However, everyone said
    >> that about computers having 100 MB/ram ... Given the current
    >> congestion of the numbering space in IPv4, and that IPv6 stacks do
    >> exist, a shift to v6 is imminent.

The analogy to computers with more memory is fallacious. Hardware with more
capacity always does get deployed (although I'm still waiting for bubble
memory :-), but alternative software is a different matter.

Some of us have been around networking long enough to remember the exact same
things being said about the ISO stack replacing TCP/IP - and for exactly the
same reason - "the sky is falling, IPv4 is running out of space". (Which it
is, just very slowly - see http://moat.nlanr.net/IPaddrocc/18monthSequel/).
The ISO stack, of course, has now joined Kruschev on the ash-heap of history.
Lots and lots of very clued people are predicting the same for IPv6, too.

    > Those interested in this topic might like to look at
    >    http://www.dsg.stanford.edu/papers/triad/triad.html
    > This is a project called TRIAD going on in David Cheriton's group at
    > Stanford, and it addresses some of the worries people have about IPv6
    > deployability. It even has a section in it about perceived
    > deployability issues. They present what looks like an interesting
    > alternative that is, in a sense, already taking place.

Let me say briefly that although I think Cheriton's analysis of the problem
with IPv6 is very good, I'm less certain that his proposed mechanism is a
good idea, and even less certain it's going to be adopted.

	Noel


From owner-manet@itd.nrl.navy.mil  Tue Mar  7 22:50: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 WAA13782
	for <manet-archive@odin.ietf.org>; Tue, 7 Mar 2000 22:50:25 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id UAA20362
	for manet-outgoing; Tue, 7 Mar 2000 20:56:13 -0500 (EST)
Received: from plastique.stanford.edu (plastique.Stanford.EDU [171.64.67.81])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id UAA20357
	for <manet@itd.nrl.navy.mil>; Tue, 7 Mar 2000 20:56:11 -0500 (EST)
Message-Id: <200003080156.UAA20357@itd.nrl.navy.mil>
Received: (qmail 20696 invoked from network); 8 Mar 2000 01:56:04 -0000
Received: from localhost.stanford.edu (HELO plastique.Stanford.EDU) (127.0.0.1)
  by localhost.stanford.edu with SMTP; 8 Mar 2000 01:56:04 -0000
X-Mailer: exmh version 2.0.2
To: manet@itd.nrl.navy.mil
Subject: Re: Stable Linux MANET Implementations?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 07 Mar 2000 17:56:04 -0800
From: Mary Baker <mgbaker@plastique.stanford.edu>
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk


Hi Everyone,

I've been reminded that the manet mailing list isn't the right forum
for a discussion of IPv6 deployability.  This is quite true!  My apologies
for bringing up the topic on this list.  I know there are a lot of strong,
interesting, and different opinions out there, but replies or related
information should be sent to me specifically rather than the whole mailing
list.  I'll keep a digest of the info I receive for anyone who requests it by
sending email to me.

Thanks very much,
Mary
---
Mary Baker			email: mgbaker@cs.stanford.edu
Gates Computer Science 4A	http://mosquitonet.stanford.edu/~mgbaker
Stanford University		phone: +1 650 725-3711
Stanford, CA  94305-9040	fax: +1 650 725-2588



From owner-manet@itd.nrl.navy.mil  Wed Mar  8 21:37: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 VAA13248
	for <manet-archive@odin.ietf.org>; Wed, 8 Mar 2000 21:37:47 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id RAA14123
	for manet-outgoing; Wed, 8 Mar 2000 17:39:25 -0500 (EST)
Received: from mail.ee.gatech.edu (mail.ee.gatech.edu [130.207.230.10])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id RAA14117
	for <manet@itd.nrl.navy.mil>; Wed, 8 Mar 2000 17:39:22 -0500 (EST)
Received: from ece.gatech.edu (anik.ece.gatech.edu [199.77.145.182])
	by mail.ee.gatech.edu (8.9.3/8.9.3) with ESMTP id RAA13552
	for <manet@itd.nrl.navy.mil>; Wed, 8 Mar 2000 17:39:23 -0500 (EST)
Message-ID: <38C6D5F7.696F67F0@ece.gatech.edu>
Date: Wed, 08 Mar 2000 14:36:39 -0800
From: MMT2000 <MMT2000@ece.gatech.edu>
Reply-To: MMT2000@ece.gatech.edu
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: manet@itd.nrl.navy.mil
Subject: CALL FOR PAPERS (IEEE MMT'2000)
Content-Type: multipart/mixed;
 boundary="------------99438AE950D27998803C6451"
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

This is a multi-part message in MIME format.
--------------99438AE950D27998803C6451
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



--------------99438AE950D27998803C6451
Content-Type: text/plain; charset=us-ascii;
 name="cfp"
Content-Disposition: inline;
 filename="cfp"
Content-Transfer-Encoding: 7bit

                           CALL FOR PAPERS
                              						   	   
         

                          IEEE  MMT'2000
 				    	  	
                 MULTIACCESS, MOBILITY AND TELETRAFFIC 
                      FOR WIRELESS COMMUNICATIONS

									    	   
                        December 3-6, 2000 
          
                   
                       Hawk's Cay Resort 
                     Duck Key, Florida, USA	   

									    	   
               Sponsored by IEEE Communications Society		    	   




Workshop Co-Chairs: 

Gordon L. Stuber and Ian F. Akyildiz	
  
Georgia Institute of Technology	
{stuber,ian}@ece.gatech.edu 

      									    	   
Advisory Board:				           	   
									    	   
Norman Abramson, ALOHA Networks, USA 
Hamid Aghvami, King's College, UK	 
Donald Cox, Stanford Univ., USA
Anthony Ephremides, UMD, USA
David Everitt, Univ. of Melbourne, AU		    	   
Robert Gallager, MIT, USA		   
Philippe Godlewski, ENST, France			   
Bijan Jabbari, GMU, USA						    	   
Jim Massey, ETH, Switzerland						    	  
Raj Pandya, BNR, Canada 
Raymond Pickholtz, GWU, USA
Stephen Rappaport, SUNY-Stony Brook, USA
Raymond Steele, MAC Ltd., UK
Andrew Viterbi, Qualcomm, USA

 
The focus of this workshop is to identify, present and discuss the 
theoretical and implementation issues critical to the design of land 
and satellite-based mobile cellular and microcellular, wireless personal 
communications as well as wireless local area networks. Topics of 
interest include but are not limited to: 
									    	   
 * Third Generation Wireless Systems					           
 * Multiaccess Methods and their Performance Analysis			    	   
 * Error Control Protocols						    	   
 * Teletraffic Issues							    	   
 * Mobility Management and Call Control				    	   
 * Handoff Strategies and Implementation				   
 * Power Control Algorithms and Implementations			    	   
 * Universal Personal Telecommunications Issues			    	   
 * Mobile Computing							   
 * Internet Access in Wireless Networks				    	   
 * Satellite Networks							   
 * Wireless Internet							   
									    	   
The workshop will feature distinguished speakers and a number of high 
quality technical presentations.

Submit your papers (in PS, PDF or DOC form) to 

                MMT2000@ece.gatech.edu

Important Dates:							    	  
          
	Deadline for Paper Submission:			June 1, 2000      
	Notification of Acceptance:			August 1, 2000        	  
	Final Manuscript for Workshop Proceedings:	September 1, 2000     	  
             	  
MMT'2000								    	   
Attention: Gordon L. Stuber and Ian F. Akyildiz			    	   
Tel: (404) 894-2923,  Fax: (404) 894-7883				    	   
Email: MMT2000@ece.gatech.edu						    	   
http://www.ece.gatech.edu/users/stuber/MMT2000			    	   



--------------99438AE950D27998803C6451--



From owner-manet@itd.nrl.navy.mil  Fri Mar 10 18:36:26 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 SAA09974
	for <manet-archive@odin.ietf.org>; Fri, 10 Mar 2000 18:36:26 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA28822
	for manet-outgoing; Fri, 10 Mar 2000 16:36:31 -0500 (EST)
Received: from swarm.cs.wustl.edu (swarm.cs.wustl.edu [128.252.165.116])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA28817
	for <manet@itd.nrl.navy.mil>; Fri, 10 Mar 2000 16:36:29 -0500 (EST)
Received: (from roman@localhost) by swarm.cs.wustl.edu (980427.SGI.8.8.8/980728.SGI.AUTOCF) id PAA66946 for manet@itd.nrl.navy.mil; Fri, 10 Mar 2000 15:36:15 -0600 (BLT)
Date: Fri, 10 Mar 2000 15:36:15 -0600 (BLT)
From: roman@swarm.cs.wustl.edu (Catalin Roman)
Message-Id: <200003102136.PAA66946@swarm.cs.wustl.edu>
To: manet@itd.nrl.navy.mil
Subject: COORDINATION 2000 (Second Call for Papers)
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk


                           Second Call for Papers
 
                              COORDINATION 2000
 
    Fourth International Conference on Coordination Models and Languages
 
                              Limassol, Cyprus
 
                            11-13 September 2000
 
 The need for increased programmer productivity and rapid development of
 complex systems provide the pragmatic motivation for the development of
 coordination languages and models. The intellectual excitement associated
 with such endeavors is rooted in the decades-old desire to leverage off
 increasingly higher levels of abstractions. Coordination-based methods
 provide a clean separation between individual software components and their
 interaction within the overall software organization. This separation makes
 large applications more tractable, supports global analysis, and enhances
 reuse of software.
 
 Building on the success of the last three editions, this conference
 provides a forum for the growing community of researchers interested in
 models, languages, and implementation techniques for coordination.
 
                                   Topics
 
 Topics of interest include (but are not limited to):
 
    * Theoretical models and foundations for coordination: component
      composition, concurrency, mobility, dynamic aspects of coordination.
    * Specification, refinement, and analysis of software architectures:
      patterns and styles, verification of functional and non-functional
      properties.
    * Coordination, architectural, and interface definition languages:
      implementation, interoperability, heterogeneity.
    * Agent-oriented languages: formal models for interacting agents.
    * Dynamic software architectures: mobile agents, configuration,
      reconfiguration.
    * Tools and environments for the development of coordinated
      applications: integration within the development process.
    * Industrial relevance of coordination and software architectures:
      programming in the large, domain-specific software architectures and
      coordination models, case studies.
 
                                 Proceedings
 
 The conference proceedings will be published by Springer, in the LNCS
 (Lecture Notes in Computer Science) series.
 
 Proceedings of the previous editions of this conference are also available
 in the LNCS series: volumes 1061, 1282 and 1594.
 
                           Submission Instructions
 
 Authors are invited to submit full papers (in English, up to 6000 words)
 electronically in PostScript or PDF using a two phase online submission
 process. First, registration of the paper and an abstract of no more than
 250 words must be complete before 7 April 2000. After successfully
 completeing this, you will receive a url through which to submit your
 paper, due no later than 14 April 2000.
 
 The authors' instructions provided by Springer should be followed.  A link 
 can be found from the conference web page.
 
 Simultaneous or similar submissions to other conferences or journals are
 not allowed.
 
 Submissions should explicitly state their contribution and their relevance
 to the theme of the conference. Other criteria for selection will be
 originality, significance, correctness, and clarity.
 
                             Conference Location
 
 The conference will be held in Limassol, the most popular and lively city
 of Cyprus, which is located on the southern coast of the island. The
 conference venue will be a five-star hotel on the coast.
 
                               Important Dates
 
                  Pre-submission abstracts      7 Apr 2000
 
                  Full paper submissions       14 Apr 2000
 
                  Notification of acceptance   14 Jun 2000
 
                  Camera-ready version          7 Jul 2000
 
                              Program co-chairs
 
  António Porto                        Gruia-Catalin Roman
 
  New University of Lisbon, Portugal   Washington University in St. Louis,
  ap@di.fct.unl.pt                     USA
  http://www-gloc.di.fct.unl.pt/~ap    roman@cs.wustl.edu
                                       http://www.cs.wustl.edu/~roman
 
                              Organizing Chair
 
 George A. Papadopoulos
 
 University of Cyprus
 george@cs.ucy.ac.cy
 http://www.cs.ucy.ac.cy/papadopo.html
 
                              Program Committee
 
                            (excluding co-chairs)
 
   Gul Agha
   U. Illinois,           Jean-Marie Jacquet      George Papadopoulos
   Urbana-Champaign, USA  U. Namur, Belgium       U. Cyprus, Cyprus
                          jmj@info.fundp.ac.be
                                                  george@cs.ucy.ac.cy
   agha@cs.uiuc.edu
                          Edwin de Jong
                                                  Rick Schlichting
   Farhad Arbab           Signaal, The            U. Arizona, USA
   CWI, The Netherlands   Netherlands             rick@cs.arizona.edu
   Farhad.Arbab@cwi.nl    edejong@signaal.nl
                                                  Katia Sycara
   Lubomir Bic            Joost Kok               Carnegie Mellon U., USA
   U. California,         U. Leiden, The          Katia.Sycara@cs.cmu.edu
   Irvine, USA            Netherlands
   bic@ics.uci.edu        joost@wi.leidenuniv.nl  John Thomas
                                                  Cruzio, USA
   GianLuigi Ferrari      Jose Meseguer           jthomas@cruzio.com
   U. Pisa, Italy         SRI, USA
   giangi@di.unipi.it     meseguer@csl.sri.com    Robert Tolksdorf
                                                  T.U. Berlin, Germany
   José Luiz Fiadeiro     Naftaly Minsky          tolk@cs.tu-berlin.de
   U. Lisbon, Portugal    Rutgers U., USA
   llf@di.fc.ul.pt        minsky@cs.rutgers.edu   Alan Wood
                                                  U. York, UK
   Roberto Gorrieri       Antonio Natali          wood@cs.york.ac.uk
   U. Bologna, Italy      U. Bologna, Italy
   gorrieri@cs.unibo.it   anatali@deis.unibo.it   Daniel Yankelevich
                                                  Pragma Consultores,
   Paola Inverardi        Rocco De Nicola         Argentina
   U. l'Aquila, Italy     U. Firenze, Italy       dyankele@pragma.com.ar
   inverard@univaq.it     denicola@dsi.unifi.it
 
                                 Sponsorship
 
 This conference is officially sponsored by the Esprit Working Group 24512
 Coordina.



From owner-manet@itd.nrl.navy.mil  Sat Mar 11 22:39: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 WAA28018
	for <manet-archive@odin.ietf.org>; Sat, 11 Mar 2000 22:39:58 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id UAA12884
	for manet-outgoing; Sat, 11 Mar 2000 20:26:11 -0500 (EST)
Received: from halley.fuse.net (halley.fuse.net [216.68.2.50])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id UAA12879
	for <manet@itd.nrl.navy.mil>; Sat, 11 Mar 2000 20:26:09 -0500 (EST)
Received: from ececs.uc.edu (theta-216-68-174-28.fuse.net [216.68.174.28])
	by halley.fuse.net (8.9.3/8.9.3) with ESMTP id UAA04416;
	Sat, 11 Mar 2000 20:24:39 -0500 (EST)
Message-ID: <38CAF204.2A90B497@ececs.uc.edu>
Date: Sat, 11 Mar 2000 20:25:24 -0500
From: "Samir R. Das" <sdas@ececs.uc.edu>
Organization: University of Cincinnati
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mobile Ad Hoc IETF working group <manet@itd.nrl.navy.mil>
CC: Mahesh Marina <mmarina@ececs.uc.edu>,
        Charles Perkins <charliep@iprg.nokia.com>, dmaltz@cs.cmu.edu,
        broch@cs.cmu.edu, "Carl A. Gunter" <gunter@cis.upenn.edu>,
        "Bhargavan, Karthikeyan" <bkarthik@saul.cis.upenn.edu>,
        Oleg Sokolsky <sokolsky@saul.cis.upenn.edu>
Subject: ns-2 code for AODV available
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 all:

This is to announce the availability of a latest version of
AODV simulation code based on ns-2 with CMU wireless
extension. The URL is 

http://www.ececs.uc.edu/~mmarina/aodv/

Details are on the web. Questions about the code should be
addressed to Mahesh Marina (mmarina@ececs.uc.edu) who will
be maintaining it. We will appreciate feedback on the code.

Samir Das
Mahesh Marina
University of Cincinnati


From owner-manet@itd.nrl.navy.mil  Mon Mar 13 22:14:49 2000
Received: from itd.nrl.navy.mil ([132.250.83.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15760
	for <manet-archive@odin.ietf.org>; Mon, 13 Mar 2000 22:14:48 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA15498
	for manet-outgoing; Mon, 13 Mar 2000 16:32:20 -0500 (EST)
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 QAA15492
	for <manet@itd.nrl.navy.mil>; Mon, 13 Mar 2000 16:32:18 -0500 (EST)
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 NAA05937
	for <manet@itd.nrl.navy.mil>; Mon, 13 Mar 2000 13:32:11 -0800 (PST)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id NAA15950
	for <manet@itd.nrl.navy.mil>; Mon, 13 Mar 2000 13:29:24 -0800
X-Virus-Scanned:  Mon, 13 Mar 2000 13:29:24 -0800 Nokia Silicon Valley Email Exploit Scanner
Received: from <charliep@iprg.nokia.com> (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com  SMTP/WTS (12.69)
 xma015499; Mon, 13 Mar 00 13:29:16 -0800
Message-ID: <38CD5E52.32400AC8@iprg.nokia.com>
Date: Mon, 13 Mar 2000 13:32:02 -0800
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Mobile Ad Hoc IETF working group <manet@itd.nrl.navy.mil>
Subject: New AODV draft available
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 folks,

Along with Samir and Elizabeth, I have submitted a new
revision for AODV.  It is available at:
	http://www.iprg.nokia.com/~charliep/txt/manet/aodvid.txt
Elizabeth has provided an appendix listing the changes since the
previous (-04) revision.

Regards,
Charlie P.


From owner-manet@itd.nrl.navy.mil  Tue Mar 14 17:27: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 RAA12741
	for <manet-archive@odin.ietf.org>; Tue, 14 Mar 2000 17:27:00 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA09716
	for manet-outgoing; Tue, 14 Mar 2000 15:41:33 -0500 (EST)
Received: from apex.ece.ucsb.edu (apex.ece.ucsb.edu [128.111.56.36])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA09710
	for <manet@itd.nrl.navy.mil>; Tue, 14 Mar 2000 15:41:30 -0500 (EST)
Received: from pi.ece.ucsb.edu (pi.ece.ucsb.edu [128.111.193.170])
	by apex.ece.ucsb.edu (8.9.1/8.9.1) with ESMTP id MAA03464;
	Tue, 14 Mar 2000 12:41:15 -0800 (PST)
Received: from pi.ece.ucsb.edu (pi.ece.ucsb.edu [128.111.193.170])
	by pi.ece.ucsb.edu (8.9.1/8.9.1) with SMTP id MAA07834;
	Tue, 14 Mar 2000 12:40:57 -0800 (PST)
Message-Id: <200003142040.MAA07834@pi.ece.ucsb.edu>
Date: Tue, 14 Mar 2000 12:40:57 -0800 (PST)
From: Elizabeth Royer <eroyer@alpha.ece.ucsb.edu>
Reply-To: Elizabeth Royer <eroyer@alpha.ece.ucsb.edu>
Subject: AODV draft (05) addresses looping potential
To: manet@itd.nrl.navy.mil
Cc: charliep@iprg.nokia.com, sdas@ececs.uc.edu, eroyer@alpha.ece.ucsb.edu
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: uoqs6OfZ0OJ7RpRz0ZOrPA==
X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc 
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

Hello everyone,

Previously Charlie had sent a message to the group reporting
the potential for routing loops in AODV which were found by 
Carl Gunter and his group at UPenn.  A few people have asked 
if we have fixed this looping potential in the latest version
(05) of our draft.  

The latest draft does address all of the situations indicated
to us where loops may occur.  Specifically, we have changed the
format of the RERR message so that the sequence number (incremented
by 1) of each listed destination is also included in the message.
Additionally, we have added 2 new sections, "Actions After Reboot"
for both unicast and multicast, which specify exactly that - actions
nodes should take after booting/rebooting in order to prevent
the formation of loops from stale routing information.  Finally,
we have added another section, "Route Expiry and Deletion", which
specifies the conditions under which a route may be deleted from
the route table.  This section introduces a DELETE_PERIOD (as
suggested by Gunter, et al) for which an invalidated route entry 
must be maintained before it can be completely deleted.  

These solutions should prevent the formation of routing loops
within AODV.  If anyone detects additional scenarios which could 
cause loops, please send us that information so we can continue 
to improve the protocol.

Thanks,
Elizabeth



From owner-manet@itd.nrl.navy.mil  Tue Mar 14 19:38: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 TAA27483
	for <manet-archive@odin.ietf.org>; Tue, 14 Mar 2000 19:38:17 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id RAA12291
	for manet-outgoing; Tue, 14 Mar 2000 17:31:24 -0500 (EST)
Received: from swarm.cs.wustl.edu (swarm.cs.wustl.edu [128.252.165.116])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id RAA12280
	for <manet@itd.nrl.navy.mil>; Tue, 14 Mar 2000 17:31:22 -0500 (EST)
Received: (from roman@localhost) by swarm.cs.wustl.edu (980427.SGI.8.8.8/980728.SGI.AUTOCF) id QAA21375 for manet@itd.nrl.navy.mil; Tue, 14 Mar 2000 16:31:09 -0600 (BLT)
Date: Tue, 14 Mar 2000 16:31:09 -0600 (BLT)
From: roman@swarm.cs.wustl.edu (Catalin Roman)
Message-Id: <200003142231.QAA21375@swarm.cs.wustl.edu>
To: manet@itd.nrl.navy.mil
Subject: COORDINATION 2000 (Second Call for Papers - updated)
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk


Please note the updated URL...
 ----
 
 
 
                            Second Call for Papers
 
                              COORDINATION 2000
 
    Fourth International Conference on Coordination Models and Languages
 
                              Limassol, Cyprus
 
                            11-13 September 2000
 
                  http://www-gloc.di.fct.unl.pt/coord00/
 
 The need for increased programmer productivity and rapid development of
 complex systems provide the pragmatic motivation for the development of
 coordination languages and models. The intellectual excitement associated
 with such endeavors is rooted in the decades-old desire to leverage off
 increasingly higher levels of abstractions. Coordination-based methods
 provide a clean separation between individual software components and their
 interaction within the overall software organization. This separation makes
 large applications more tractable, supports global analysis, and enhances
 reuse of software.
 
 Building on the success of the last three editions, this conference
 provides a forum for the growing community of researchers interested in
 models, languages, and implementation techniques for coordination.
 
                                   Topics
 
 Topics of interest include (but are not limited to):
 
    * Theoretical models and foundations for coordination: component
      composition, concurrency, mobility, dynamic aspects of coordination.
    * Specification, refinement, and analysis of software architectures:
      patterns and styles, verification of functional and non-functional
      properties.
    * Coordination, architectural, and interface definition languages:
      implementation, interoperability, heterogeneity.
    * Agent-oriented languages: formal models for interacting agents.
    * Dynamic software architectures: mobile agents, configuration,
      reconfiguration.
    * Tools and environments for the development of coordinated
      applications: integration within the development process.
    * Industrial relevance of coordination and software architectures:
      programming in the large, domain-specific software architectures and
      coordination models, case studies.
 
                                 Proceedings
 
 The conference proceedings will be published by Springer, in the LNCS
 (Lecture Notes in Computer Science) series.
 
 Proceedings of the previous editions of this conference are also available
 in the LNCS series: volumes 1061, 1282 and 1594.
 
                           Submission Instructions
 
 Authors are invited to submit full papers (in English, up to 6000 words)
 electronically in PostScript or PDF using a two phase online submission
 process. First, registration of the paper and an abstract of no more than
 250 words must be complete before 7 April 2000. After successfully
 completeing this, you will receive a url through which to submit your
 paper, due no later than 14 April 2000.
 
 The authors' instructions provided by Springer should be followed.  A link 
 can be found from the conference web page.
 
 Simultaneous or similar submissions to other conferences or journals are
 not allowed.
 
 Submissions should explicitly state their contribution and their relevance
 to the theme of the conference. Other criteria for selection will be
 originality, significance, correctness, and clarity.
 
                             Conference Location
 
 The conference will be held in Limassol, the most popular and lively city
 of Cyprus, which is located on the southern coast of the island. The
 conference venue will be a five-star hotel on the coast.
 
                               Important Dates
 
                  Pre-submission abstracts      7 Apr 2000
 
                  Full paper submissions       14 Apr 2000
 
                  Notification of acceptance   14 Jun 2000
 
                  Camera-ready version          7 Jul 2000
 
                              Program co-chairs
 
  António Porto                        Gruia-Catalin Roman
 
  New University of Lisbon, Portugal   Washington University in St. Louis,
  ap@di.fct.unl.pt                     USA
  http://www-gloc.di.fct.unl.pt/~ap    roman@cs.wustl.edu
                                       http://www.cs.wustl.edu/~roman
 
                              Organizing Chair
 
 George A. Papadopoulos
 
 University of Cyprus
 george@cs.ucy.ac.cy
 http://www.cs.ucy.ac.cy/papadopo.html
 
                              Program Committee
 
                            (excluding co-chairs)
 
   Gul Agha
   U. Illinois,           Jean-Marie Jacquet      George Papadopoulos
   Urbana-Champaign, USA  U. Namur, Belgium       U. Cyprus, Cyprus
   agha@cs.uiuc.edu      jmj@info.fundp.ac.be     george@cs.ucy.ac.cy
 
 
   Farhad Arbab           Edwin de Jong           Rick Schlichting
   CWI, The Netherlands   Signaal, The            U. Arizona, USA
   Farhad.Arbab@cwi.nl    Netherlands             rick@cs.arizona.edu
                          edejong@signaal.nl
                                                  Katia Sycara
   Lubomir Bic            Joost Kok               Carnegie Mellon U., USA
   U. California,         U. Leiden, The          Katia.Sycara@cs.cmu.edu
   Irvine, USA            Netherlands
   bic@ics.uci.edu        joost@wi.leidenuniv.nl  John Thomas
                                                  Cruzio, USA
   GianLuigi Ferrari      Jose Meseguer           jthomas@cruzio.com
   U. Pisa, Italy         SRI, USA
   giangi@di.unipi.it     meseguer@csl.sri.com    Robert Tolksdorf
                                                  T.U. Berlin, Germany
   José Luiz Fiadeiro     Naftaly Minsky          tolk@cs.tu-berlin.de
   U. Lisbon, Portugal    Rutgers U., USA
   llf@di.fc.ul.pt        minsky@cs.rutgers.edu   Alan Wood
                                                  U. York, UK
   Roberto Gorrieri       Antonio Natali          wood@cs.york.ac.uk
   U. Bologna, Italy      U. Bologna, Italy
   gorrieri@cs.unibo.it   anatali@deis.unibo.it   Daniel Yankelevich
                                                  Pragma Consultores,
   Paola Inverardi        Rocco De Nicola         Argentina
   U. l'Aquila, Italy     U. Firenze, Italy       dyankele@pragma.com.ar
   inverard@univaq.it     denicola@dsi.unifi.it
 
                                 Sponsorship
 
 This conference is officially sponsored by the Esprit Working Group 24512
 Coordina.



From owner-manet@itd.nrl.navy.mil  Wed Mar 15 08:26:23 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 IAA17743
	for <manet-archive@odin.ietf.org>; Wed, 15 Mar 2000 08:26:22 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id GAA21209
	for manet-outgoing; Wed, 15 Mar 2000 06:25:18 -0500 (EST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id GAA21204
	for <manet@itd.nrl.navy.mil>; Wed, 15 Mar 2000 06:25:15 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29638;
	Wed, 15 Mar 2000 06:25:15 -0500 (EST)
Message-Id: <200003151125.GAA29638@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: manet@itd.nrl.navy.mil
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-manet-aodv-05.txt
Date: Wed, 15 Mar 2000 06:25:14 -0500
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF.

	Title		: Ad Hoc On Demand Distance Vector (AODV) Routing
	Author(s)	: C. Perkins, E. Royer, S. Das
	Filename	: draft-ietf-manet-aodv-05.txt
	Pages		: 40
	Date		: 14-Mar-00
	
The Ad Hoc On-Demand Distance Vector (AODV) routing protocol is
intended for use by mobile nodes in an ad hoc network.  It offers
quick adaptation to dynamic link conditions, low processing and
memory overhead, low network utilization, and determines both unicast
and multicast routes between sources and destinations.  It uses
destination sequence numbers to ensure loop freedom at all times
(even in the face of anomalous delivery of routing control messages),
solving problems (such as 'counting to infinity') associated with
classical distance vector protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-manet-aodv-05.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-manet-aodv-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-manet-aodv-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000314133126.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-manet-aodv-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-manet-aodv-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000314133126.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-manet@itd.nrl.navy.mil  Fri Mar 17 17:35:10 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 RAA06118
	for <manet-archive@odin.ietf.org>; Fri, 17 Mar 2000 17:35:09 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA23285
	for manet-outgoing; Fri, 17 Mar 2000 15:48:53 -0500 (EST)
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 PAA23280
	for <manet@itd.nrl.navy.mil>; Fri, 17 Mar 2000 15:48:51 -0500 (EST)
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 PAA08014
	for <manet@itd.nrl.navy.mil>; Fri, 17 Mar 2000 15:46:35 -0500 (EST)
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 PAA23197
	for <manet@itd.nrl.navy.mil>; Fri, 17 Mar 2000 15:48:50 -0500 (EST)
Received: from localhost (corson@localhost)
	by manet.isr.umd.edu (8.9.3/8.9.3) with ESMTP id PAA23193
	for <manet@itd.nrl.navy.mil>; Fri, 17 Mar 2000 15:48:49 -0500 (EST)
X-Authentication-Warning: manet.isr.umd.edu: corson owned process doing -bs
Date: Fri, 17 Mar 2000 15:48:49 -0500 (EST)
From: "M. Scott Corson" <corson@glue.umd.edu>
X-Sender: corson@manet.isr.umd.edu
To: MANET WG <manet@itd.nrl.navy.mil>
Subject: MANET Agenda in Adelaide
Message-ID: <Pine.GSO.4.21.0003171547230.21997-100000@manet.isr.umd.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk


Everyone,

Here's the current agenda for Adelaide.

-Scott

*********************************************

Mobile Ad Hoc Networks (manet) Agenda
Monday, March 27, 13:00-15:00

ZRP Update - M. Pearlman (20 min)

AODV Update - C. Perkins (20 min)

OLSR Update - A. Qayyum (10 min)

Edge Mobility Architecture - A. O'Neill (15 min)

General Discussion




From owner-manet@itd.nrl.navy.mil  Fri Mar 17 17:35:15 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 RAA06157
	for <manet-archive@odin.ietf.org>; Fri, 17 Mar 2000 17:35:14 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA22401
	for manet-outgoing; Fri, 17 Mar 2000 15:18:59 -0500 (EST)
Received: from postoffice.mail.cornell.edu (POSTOFFICE.MAIL.CORNELL.EDU [132.236.56.7])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA22388
	for <manet@itd.nrl.navy.mil>; Fri, 17 Mar 2000 15:18:50 -0500 (EST)
Received: from pearlman (PEARLMAN.EE.CORNELL.EDU [128.84.224.56])
	by postoffice.mail.cornell.edu (8.9.3/8.9.3) with SMTP id PAA03268
	for <manet@itd.nrl.navy.mil>; Fri, 17 Mar 2000 15:18:49 -0500 (EST)
Received: by localhost with Microsoft MAPI; Fri, 17 Mar 2000 15:17:53 -0500
Message-ID: <01BF9023.F6EDD4E0.mrp12@cornell.edu>
From: Marc Pearlman <mrp12@cornell.edu>
Reply-To: "mrp12@cornell.edu" <mrp12@cornell.edu>
To: "manet@itd.nrl.navy.mil" <manet@itd.nrl.navy.mil>
Subject: New ZRP Internet Draft available
Date: Fri, 17 Mar 2000 15:17:40 -0500
Organization: Cornell University
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
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 Everyone,

We have submitted a new version of the ZRP internet draft .

For now, the draft is available at:  http://www.ee.cornell.edu/~pearlman/draft-ietf-manet-zone-zrp-03.txt

Updates to the draft are outlined in Section 7.  Most changes are related to the upgrade of our
"bordercast" mechanism from unicast to multicast delivery.

See you on the 27th!

regards,

Marc



From owner-manet@itd.nrl.navy.mil  Mon Mar 20 04:37: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 EAA03029
	for <manet-archive@odin.ietf.org>; Mon, 20 Mar 2000 04:37:03 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id CAA23171
	for manet-outgoing; Mon, 20 Mar 2000 02:20:35 -0500 (EST)
Received: from mercur.foa.se (custos.foa.se [150.227.16.253])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id CAA23166
	for <manet@itd.nrl.navy.mil>; Mon, 20 Mar 2000 02:20:33 -0500 (EST)
Received: from box.lin.foa.se (box.lin.foa.se [150.227.31.20])
	by mercur.foa.se (8.9.3/8.9.3) with ESMTP id IAA16894;
	Mon, 20 Mar 2000 08:20:24 +0100 (MET)
Received: from arnljot.lin.foa.se (IDENT:root@arnljot.lin.foa.se [150.227.33.98])
	by box.lin.foa.se (8.9.3/8.9.3) with ESMTP id IAA12306;
	Mon, 20 Mar 2000 08:19:56 +0100 (MET)
Received: from arnljot.lin.foa.se (IDENT:chj@localhost [127.0.0.1])
	by arnljot.lin.foa.se (8.9.3/8.9.3) with ESMTP id IAA29483;
	Mon, 20 Mar 2000 08:20:20 +0100
Message-Id: <200003200720.IAA29483@arnljot.lin.foa.se>
X-Mailer: exmh version 2.0.3
To: "M. Scott Corson" <corson@glue.umd.edu>
cc: MANET WG <manet@itd.nrl.navy.mil>
Subject: Re: MANET Agenda in Adelaide 
In-reply-to: corson's message of Fri, 17 Mar 2000 15:48:49 -0500.
	     <Pine.GSO.4.21.0003171547230.21997-100000@manet.isr.umd.edu> 
From: Christian =?iso-8859-1?Q?J=F6nsson?= Tf IC FOA 75 <chj@lin.foa.se>
X-face: 2tQjSw>|IA680lA7r'G9Y[jfoS>tTPw4-B#mQo_C+{6>^DWZP`o.h<N!-!iBER@5!"`:9^t
 ~MyeXP43[]t)W-sTm)TibB_c4=**35T?X(,6,POUlqae[Aq$"zn4hN{{w@(=rYp\i=\wUyhL
X-URL: http://www.foa.se
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 20 Mar 2000 08:20:20 +0100
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id CAA23167
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk
Content-Transfer-Encoding: 8bit


Hej everyone,

this Edge Mobility Arch by A. O'Neill sounds really interesting. Is 
there some publications available on paper or on the Internet about
it?

TIA,

/ChJ> 

> Everyone,
> 
> Here's the current agenda for Adelaide.
> 
> -Scott
> 
> *********************************************
> 
> Mobile Ad Hoc Networks (manet) Agenda
> Monday, March 27, 13:00-15:00
> 
> ZRP Update - M. Pearlman (20 min)
> 
> AODV Update - C. Perkins (20 min)
> 
> OLSR Update - A. Qayyum (10 min)
> 
> Edge Mobility Architecture - A. O'Neill (15 min)
> 
> General Discussion
> 
> 
> 







From owner-manet@itd.nrl.navy.mil  Mon Mar 20 05:48:07 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 FAA28080
	for <manet-archive@odin.ietf.org>; Mon, 20 Mar 2000 05:48:07 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id EAA24313
	for manet-outgoing; Mon, 20 Mar 2000 04:00:41 -0500 (EST)
Received: from babelfish.axion.bt.co.uk (babelfish.axion.bt.co.uk [132.146.17.20])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id EAA24306
	for <manet@itd.nrl.navy.mil>; Mon, 20 Mar 2000 04:00:39 -0500 (EST)
From: george.tsirtsis@bt.com
Received: from cbtlipnt01.btlabs.bt.co.uk by babelfish.axion.bt.co.uk (local) 
          with ESMTP; Mon, 20 Mar 2000 08:59:19 +0000
Received: by cbtlipnt01.btlabs.bt.co.uk 
          with Internet Mail Service (5.5.2651.88) id <HDS6DY3J>;
          Mon, 20 Mar 2000 09:00:26 -0000
Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB202DBA327@mbtlipnt02.btlabs.bt.co.uk>
To: chj@lin.foa.se
Cc: manet@itd.nrl.navy.mil
Subject: RE: MANET Agenda in Adelaide 
Date: Mon, 20 Mar 2000 09:00:08 -0000
X-Mailer: Internet Mail Service (5.5.2651.88)
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 EAA24307
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk
Content-Transfer-Encoding: 8bit

Christian,

Do you mean other than the Internet Draft?
http://www.ietf.org/internet-drafts/draft-oneill-ema-01.txt

Not yet.

George

> -----Original Message-----
> From:	Christian Jönsson Tf IC FOA 75 [SMTP:chj@lin.foa.se]
> Sent:	Monday, March 20, 2000 7:20 AM
> To:	M. Scott Corson
> Cc:	MANET WG
> Subject:	Re: MANET Agenda in Adelaide 
> 
> 
> Hej everyone,
> 
> this Edge Mobility Arch by A. O'Neill sounds really interesting. Is 
> there some publications available on paper or on the Internet about
> it?
> 
> TIA,
> 
> /ChJ> 
> 
> > Everyone,
> > 
> > Here's the current agenda for Adelaide.
> > 
> > -Scott
> > 
> > *********************************************
> > 
> > Mobile Ad Hoc Networks (manet) Agenda
> > Monday, March 27, 13:00-15:00
> > 
> > ZRP Update - M. Pearlman (20 min)
> > 
> > AODV Update - C. Perkins (20 min)
> > 
> > OLSR Update - A. Qayyum (10 min)
> > 
> > Edge Mobility Architecture - A. O'Neill (15 min)
> > 
> > General Discussion
> > 
> > 
> > 
> 
> 
> 
> 


From owner-manet@itd.nrl.navy.mil  Mon Mar 20 11:39:41 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 LAA18558
	for <manet-archive@odin.ietf.org>; Mon, 20 Mar 2000 11:39:41 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA28582
	for manet-outgoing; Mon, 20 Mar 2000 09:10:53 -0500 (EST)
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 JAA28575
	for <manet@itd.nrl.navy.mil>; Mon, 20 Mar 2000 09:10:52 -0500 (EST)
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 JAA27441;
	Mon, 20 Mar 2000 09:07:53 -0500 (EST)
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 JAA05478;
	Mon, 20 Mar 2000 09:10:10 -0500 (EST)
Received: from localhost (corson@localhost)
	by manet.isr.umd.edu (8.9.3/8.9.3) with ESMTP id JAA05474;
	Mon, 20 Mar 2000 09:10:08 -0500 (EST)
X-Authentication-Warning: manet.isr.umd.edu: corson owned process doing -bs
Date: Mon, 20 Mar 2000 09:10:08 -0500 (EST)
From: "M. Scott Corson" <corson@glue.umd.edu>
X-Sender: corson@manet.isr.umd.edu
To: george.tsirtsis@bt.com
cc: chj@lin.foa.se, manet@itd.nrl.navy.mil
Subject: RE: MANET Agenda in Adelaide 
In-Reply-To: <5104D4DBC598D211B5FE0000F8FE7EB202DBA327@mbtlipnt02.btlabs.bt.co.uk>
Message-ID: <Pine.GSO.4.21.0003200901550.5410-100000@manet.isr.umd.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by itd.nrl.navy.mil id JAA28576
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk
Content-Transfer-Encoding: 8bit

On Mon, 20 Mar 2000 george.tsirtsis@bt.com wrote:

Christian,

There is a technical report available online 

http://www.isr.umd.edu/TechReports/ISR/2000/TR_2000-5/TR_2000-5.phtml

that gives more information regarding a proposed routing algorithm
that is mentioned in the draft.

-scott

> Christian,
> 
> Do you mean other than the Internet Draft?
> http://www.ietf.org/internet-drafts/draft-oneill-ema-01.txt
> 
> Not yet.
> 
> George
> 
> > -----Original Message-----
> > From:	Christian Jönsson Tf IC FOA 75 [SMTP:chj@lin.foa.se]
> > Sent:	Monday, March 20, 2000 7:20 AM
> > To:	M. Scott Corson
> > Cc:	MANET WG
> > Subject:	Re: MANET Agenda in Adelaide 
> > 
> > 
> > Hej everyone,
> > 
> > this Edge Mobility Arch by A. O'Neill sounds really interesting. Is 
> > there some publications available on paper or on the Internet about
> > it?
> > 
> > TIA,
> > 
> > /ChJ> 
> > 
> > > Everyone,
> > > 
> > > Here's the current agenda for Adelaide.
> > > 
> > > -Scott
> > > 
> > > *********************************************
> > > 
> > > Mobile Ad Hoc Networks (manet) Agenda
> > > Monday, March 27, 13:00-15:00
> > > 
> > > ZRP Update - M. Pearlman (20 min)
> > > 
> > > AODV Update - C. Perkins (20 min)
> > > 
> > > OLSR Update - A. Qayyum (10 min)
> > > 
> > > Edge Mobility Architecture - A. O'Neill (15 min)
> > > 
> > > General Discussion
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> 


*******************************************************************************

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 Mar 20 13:19:23 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 NAA27373
	for <manet-archive@odin.ietf.org>; Mon, 20 Mar 2000 13:19:22 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA01914
	for manet-outgoing; Mon, 20 Mar 2000 11:02:05 -0500 (EST)
Received: from osf1.gmu.edu (osf1.gmu.edu [129.174.1.13])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA01907
	for <manet@itd.nrl.navy.mil>; Mon, 20 Mar 2000 11:02:01 -0500 (EST)
Received: from localhost (mrahman3@localhost)
	by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id LAA07103
	for <manet@itd.nrl.navy.mil>; Mon, 20 Mar 2000 11:01:50 -0500 (EST)
Date: Mon, 20 Mar 2000 11:01:50 -0500 (EST)
From: MD A Rahman <mrahman3@osf1.gmu.edu>
To: manet@itd.nrl.navy.mil
Subject: question about AODV home page 
Message-ID: <Pine.OSF.4.21.0003201054220.12488-100000@osf1.gmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

Dear Sir/Madam

I went to your web-site
http://tonnant.itd.nrl.navy.mil/manet/manet_home.html

I found some interesting topic on Ad hoc networking there. In few days ago
I went to "AODV Home Page" and "Charlie Perkins Home Page (AODV
references,etc)".At that time it worked fine, but today I tried to go
there,but it shows "the server is down".Is there anything happened?

Please let me know How I can see those two links?

Thank you 
sohela



From owner-manet@itd.nrl.navy.mil  Mon Mar 20 16:44:40 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 QAA17562
	for <manet-archive@odin.ietf.org>; Mon, 20 Mar 2000 16:44:39 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA07223
	for manet-outgoing; Mon, 20 Mar 2000 14:04:54 -0500 (EST)
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 OAA07214
	for <manet@itd.nrl.navy.mil>; Mon, 20 Mar 2000 14:04:49 -0500 (EST)
Received: from localhost (sjlee@localhost)
	by cheetah.cs.ucla.edu (8.9.1/UCLACS-5.0) with ESMTP id LAA02234;
	Mon, 20 Mar 2000 11:01:15 -0800 (PST)
Date: Mon, 20 Mar 2000 11:01:14 -0800 (PST)
From: SJ Lee <sjlee@cs.ucla.edu>
To: "S.J. (Sung-Ju) Lee" <sjlee@cs.ucla.edu>
Subject: CFP - MobiHOC 2000
Message-ID: <Pine.SOL.4.10.10003201056240.21093-100000@cheetah.cs.ucla.edu>
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]

=========================================================================


               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 10th, 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 Mar 22 08:25: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 IAA12710
	for <manet-archive@odin.ietf.org>; Wed, 22 Mar 2000 08:25:01 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id FAA15316
	for manet-outgoing; Wed, 22 Mar 2000 05:59:36 -0500 (EST)
Received: from mex.italtel.it (mex.italtel.it [138.132.117.4])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id FAA15311
	for <manet@itd.nrl.navy.mil>; Wed, 22 Mar 2000 05:59:32 -0500 (EST)
Received: .(iltws72 [138.132.52.82]) by mex.italtel.it (8.9.0/8.9.0) with ESMTP id LAA05860 for <manet@itd.nrl.navy.mil>; Wed, 22 Mar 2000 11:58:44 +0100 (MET)
Received: .(localhost [127.0.0.1]) by iltws72.settimo.italtel.it (8.9.1a/8.9.1) with ESMTP
 id LAA07410 for <manet@itd.nrl.navy.mil>; Wed, 22 Mar 2000 11:58:16 +0100 (MET)
Received: from ikuws01.cassina.italtel.it (ikuws01.cassina.italtel.it [138.132.208.4])
	by mix.italtel.it (8.9.3/8.9.3) with ESMTP id LAA00494
	for <manet@itd.nrl.navy.mil>; Wed, 22 Mar 2000 11:58:21 +0100 (MET)
Received: from ikbd19 (ikbd19.cassina.italtel.it [138.132.211.21])
	by ikuws01.cassina.italtel.it (8.8.8+Sun/8.8.8) with SMTP id LAA02740
	for <manet@itd.nrl.navy.mil>; Wed, 22 Mar 2000 11:58:18 +0100 (MET)
Message-ID: <003801bf93ed$dccd7d90$15d3848a@cassina.italtel.it>
From: "Alberto Ziglioli" <alberto.ziglioli@siemens-icn.it>
To: <manet@itd.nrl.navy.mil>
Subject: MANET authentication architecture
Date: Wed, 22 Mar 2000 12:00:40 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0035_01BF93F6.3E06E3A0"
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_0035_01BF93F6.3E06E3A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all,
I'm looking for a document that explain the concepts of authetication on =
MANET. Maybe the request is a Internet Draft I found on a MANET WG =
meeting summary doc dated October 98. The authors were S.Jacobs and =
M.S.Corson and the title was "MANET Authentication Architecture" (but =
the work was in progress) and no more present on "Internet Draft".

Thanks to all. Alberto

------=_NextPart_000_0035_01BF93F6.3E06E3A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi all,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I'm looking for a document that explain =
the=20
concepts of authetication on MANET. Maybe the request is a Internet =
Draft I=20
found on a MANET WG meeting summary doc dated October 98.=20
The&nbsp;authors&nbsp;were S.Jacobs and M.S.Corson and the title was =
"MANET=20
Authentication Architecture" (but the work was in progress) and no more =
present=20
on "Internet Draft".</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks to all. =
Alberto</FONT></DIV></BODY></HTML>

------=_NextPart_000_0035_01BF93F6.3E06E3A0--



From owner-manet@itd.nrl.navy.mil  Tue Mar 28 16:27:40 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 QAA26793
	for <manet-archive@odin.ietf.org>; Tue, 28 Mar 2000 16:27:33 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA19248
	for manet-outgoing; Tue, 28 Mar 2000 13:54:10 -0500 (EST)
Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA19243
	for <manet@itd.nrl.navy.mil>; Tue, 28 Mar 2000 13:54:08 -0500 (EST)
Received: from thinkbad (SSH.BBN.COM [192.1.50.70])
	by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with SMTP id NAA01323
	for <manet@itd.nrl.navy.mil>; Tue, 28 Mar 2000 13:53:51 -0500 (EST)
From: "John Zavgren" <jz@bbn.com>
To: <manet@itd.nrl.navy.mil>
Subject: overhead tradeoff between on-demand and generic link state routing protocols
Date: Tue, 28 Mar 2000 13:48:23 -0500
Message-ID: <NDBBLCLJOLMGNMOFLAKMOEGECBAA.jz@bbn.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id NAA19244
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk
Content-Transfer-Encoding: 8bit

Greetings:

 I have been reading about on-demand routing protocols that are being proposed by the manet group.  Is there any analysis that compares this class of routing protocol with the class of protocol that maintains routes "all the time", i.e., generic link state, or distance vector? 

Of course, this comparison would need to be made for carefully chosen end-to-end traffic profiles. If there is no traffic being offered to the network, then the on-demand protocol will generate no routing update traffic. And I suspect that if a uniform, heavy end-to-end traffic load is presented to an on-demand routing protocol, the protocol will look pretty bad in comparison.


Thanks

John Zavgren
jz@bbn.com
617-873-2280






From owner-manet@itd.nrl.navy.mil  Tue Mar 28 22:55: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 WAA03696
	for <manet-archive@odin.ietf.org>; Tue, 28 Mar 2000 22:55:18 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id UAA26050
	for manet-outgoing; Tue, 28 Mar 2000 20:36:59 -0500 (EST)
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 UAA26045
	for <manet@itd.nrl.navy.mil>; Tue, 28 Mar 2000 20:36:55 -0500 (EST)
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 UAA07664;
	Tue, 28 Mar 2000 20:33:59 -0500 (EST)
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 UAA07500;
	Tue, 28 Mar 2000 20:36:31 -0500 (EST)
Received: from localhost (corson@localhost)
	by manet.isr.umd.edu (8.9.3/8.9.3) with ESMTP id UAA07496;
	Tue, 28 Mar 2000 20:36:30 -0500 (EST)
X-Authentication-Warning: manet.isr.umd.edu: corson owned process doing -bs
Date: Tue, 28 Mar 2000 20:36:26 -0500 (EST)
From: "M. Scott Corson" <corson@glue.umd.edu>
X-Sender: corson@manet.isr.umd.edu
To: John Zavgren <jz@bbn.com>
cc: manet@itd.nrl.navy.mil
Subject: Re: overhead tradeoff between on-demand and generic link state
 routing protocols
In-Reply-To: <NDBBLCLJOLMGNMOFLAKMOEGECBAA.jz@bbn.com>
Message-ID: <Pine.GSO.4.21.0003282025400.7045-100000@manet.isr.umd.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

On Tue, 28 Mar 2000, John Zavgren wrote:


John,

Am not aware of any published results yet, but i think there are efforts
underway in this direction.

As for your conjecture that on-demand will perform porrly relative to
a proactive protocol in uniform, heavy load, this is not at all clear.
On-demand and proactive protocols come in diferent flavors.
More or less, on-demand protocols strive to put routing state only 
where it is needed.  On balance, whether this si more or less efficient 
than, for example, managed link state distribution needs to be determined
for various on-demand approaches.

-scott

> Greetings:
> 
>  I have been reading about on-demand routing protocols that are being proposed by the manet group.  Is there any analysis that compares this class of routing protocol with the class of protocol that maintains routes "all the time", i.e., generic link state, or distance vector? 
> 
> Of course, this comparison would need to be made for carefully chosen end-to-end traffic profiles. If there is no traffic being offered to the network, then the on-demand protocol will generate no routing update traffic. And I suspect that if a uniform, heavy end-to-end traffic load is presented to an on-demand routing protocol, the protocol will look pretty bad in comparison.
> 
> 
> Thanks
> 
> John Zavgren
> jz@bbn.com
> 617-873-2280
> 
> 
> 
> 
> 


*******************************************************************************

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  Wed Mar 29 09:49:05 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 JAA21464
	for <manet-archive@odin.ietf.org>; Wed, 29 Mar 2000 09:49:03 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id GAA02644
	for manet-outgoing; Wed, 29 Mar 2000 06:57:26 -0500 (EST)
Received: from anise.ee.cornell.edu (ANISE.EE.CORNELL.EDU [128.84.239.14] (may be forged))
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id GAA02639
	for <manet@itd.nrl.navy.mil>; Wed, 29 Mar 2000 06:57:25 -0500 (EST)
Received: from VERDI.EE.CORNELL.EDU (VERDI.EE.CORNELL.EDU [128.84.240.71])
	by anise.ee.cornell.edu (8.9.3/8.9.1) with ESMTP id GAA13359;
	Wed, 29 Mar 2000 06:56:54 -0500 (EST)
Date: Wed, 29 Mar 2000 06:56:51 -0500 (EST)
From: Zygmunt Haas <haas@anise.ee.cornell.edu>
To: John Zavgren <jz@bbn.com>
cc: "M. Scott Corson" <corson@glue.umd.edu>, manet@itd.nrl.navy.mil,
        Zygmunt Haas <haas@anise.ee.cornell.edu>
Subject: Re: overhead tradeoff between on-demand and generic link state
 routing protocols
In-Reply-To: <Pine.GSO.4.21.0003282025400.7045-100000@manet.isr.umd.edu>
Message-ID: <Pine.HPX.4.21.0003290637040.6136-100000@verdi.ee.cornell.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

Hi John,

Actually, such an analysis should take into the account not only the
traffic distribution, but the mobility of the nodes as well. Let me
explain further.

Another way of looking at the issue that you have raised is to see whether
some mix of proactive vs. reactive (on-demand) behavior of the routing 
protocol would be more efficient for a specific network operational condition. 
In other words, if the network load is heavy and uniform, proactive protocols 
should do better, while when the load is low and highly localized, reactive
protocols should be preferred. In the middle, there is a broad range of
traffic mixes that would justify some degree of proactivity/reactivity.

You see where I am getting at ... the ZRP is exactly such a protocol. It
allows to adjust the degree of reactivity/proactivity in the protocol
behavior based on a single parameter - the Zone Radius (ZR). It has been
shown that for a highly dynamic network (i.e., high mobility nodes) and
for low traffic load, small ZR leads to optimal performance - of course
small ZR corresponds to a purely reactive protocol. On the other hand, for
a stationary, highly loaded network, large ZR is much better, corresponding 
to purely proactive behavior.

The ZR is like a "knob" (Joe's analogy (:-)) that allows to adjust the
behavior of the protocol to the current network conditions (mobility and
traffic load). More information on the behavior of this "knob" could be
found in:
M.R. Pearlman and Z.J. Haas, "Determining the Optimal Configuration of for
the Zone Routing Protocol," IEEE JSAC, special issue on Ad-Hoc Networks,
vol. 17, no.8, August 1999

I believe that if there is to be a single (or a small set) of MANET
routing protocols, some mechanism to adapt to the current network
conditions (again, traffic load and nodal mobility) is essential, since
the ad hoc networking environment is so braodly defined.

Cheers,

Zygmunt.
==-=-=-==
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
Prof. Zygmunt J. Haas                    tel: +1-607-255-3454
Wireless Networks Laboratory		                  
School of Electrical Engineering         fax: +1-607-255-9072 
Cornell University
323 Frank Rhodes Hall			 e-mail: haas@ee.cornell.edu
Ithaca, NY 14853			 
U.S.A                             http://www.ee.cornell.edu/~haas/wnl.html
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-

> On Tue, 28 Mar 2000, John Zavgren wrote:
>
> > Greetings:
> > 
> >  I have been reading about on-demand routing protocols that are being proposed by the manet group.  Is there any analysis that compares this class of routing protocol with the class of protocol that maintains routes "all the time", i.e., generic link state, or distance vector? 
> > 
> > Of course, this comparison would need to be made for carefully chosen end-to-end traffic profiles. If there is no traffic being offered to the network, then the on-demand protocol will generate no routing update traffic. And I suspect that if a uniform, heavy end-to-end traffic load is presented to an on-demand routing protocol, the protocol will look pretty bad in comparison.
> > 
> > 
> > Thanks
> > 
> > John Zavgren
> > jz@bbn.com
> > 617-873-2280



From owner-manet@itd.nrl.navy.mil  Wed Mar 29 11:45:05 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 LAA22554
	for <manet-archive@odin.ietf.org>; Wed, 29 Mar 2000 11:45:05 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA04784
	for manet-outgoing; Wed, 29 Mar 2000 09:12:47 -0500 (EST)
Received: from postoffice.mail.cornell.edu (POSTOFFICE.MAIL.CORNELL.EDU [132.236.56.7])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA04762
	for <manet@itd.nrl.navy.mil>; Wed, 29 Mar 2000 09:12:19 -0500 (EST)
Received: from pearlman ([202.76.137.169])
	by postoffice.mail.cornell.edu (8.9.3/8.9.3) with SMTP id JAA04347;
	Wed, 29 Mar 2000 09:11:45 -0500 (EST)
Received: by localhost with Microsoft MAPI; Wed, 29 Mar 2000 09:10:29 -0500
Message-ID: <01BF995E.A0A97960.mrp12@cornell.edu>
From: Marc Pearlman <mrp12@cornell.edu>
Reply-To: "mrp12@cornell.edu" <mrp12@cornell.edu>
To: "'John Zavgren'" <jz@bbn.com>,
        "'manet@itd.nrl.navy.mil'"
	 <manet@itd.nrl.navy.mil>
Subject: RE: overhead tradeoff between on-demand and generic link state routing protocols
Date: Wed, 29 Mar 2000 09:10:03 -0500
Organization: Cornell University
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
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 John,

A little shameless self promotion (but for a good cause:-)...

The Zone Routing Protocol (ZRP) proivdes a hybrid proactive ("all the 
time") / reactive ("on demand") routing framework.  Specifically, each node 
employs a localized version of a proactive routing protocol (eg. a 
localized OSPF) to track the connectivity of a surrounding region (routing 
zone).  This local knowledge is then used to improve the efficiency of a 
*globally reactive* route discovery protocol (eg. AODV, TORA, DSR), by 
guiding route requests to the edge of routing zones.

The ZRP can be configured based on the size (radius, in hops) of each 
node's routing zone.  When a node knows nothing about its surrounding 
topology (or at most, only who its neighbors are), then the ZRP operates in 
a purely reactive mode (AODV, TORA, DSR, etc.).  At the other extreme, when 
the nodes' routing zones are infinitely large, then everyone has access to 
routing information "all the time" (purely proactive) and route discovery 
is not necessary.  In many cases, the "optimal" configuration is somewhere 
between these two extremes.

In general, large population (span), low node mobility and great route 
demand favor larger routing zones (more proactivity).  On the other hand, a 
smaller routing zone radius (more reactivity) is more suitable for smaller 
populations (span), higher node mobility and low route demand.  A more 
thorough discussion/analysis of these trends can be found in:

	M.R. Pearlman and Z.J. Haas, "Determining the Optimal Configuration for 
the Zone Routing Protocol,"
	IEEE JSAC, August 1999.


The important point is that one does not necessarily have to choose, 
all-or-nothing, between a purely reactive protocol (like AODV, DSR, TORA, 
etc.) vs. a purely proactive protocol (OSPF, RIP, WRP, etc.).  There is a 
rich hybrid proactive/reactive middle ground which often provides the best 
results.  Furthermore, hybrid proactive/reactive operation is not the 
exclusive domain of the ZRP.  Many protocols provide exhibit both proactive 
and reactive behavior...  for example ZHLS, CEDAR, IMEP's multipoint relay 
(all locally proactive and globally reactive).  Even TORA, traditionally 
purely reactive, now offers a proactive mode of operation.


regards,

Marc


On Tuesday, March 28, 2000 1:48 PM, John Zavgren [SMTP:jz@bbn.com] wrote:
> Greetings:
>
>  I have been reading about on-demand routing protocols that are being 
proposed by the manet group.  Is there any analysis that compares this 
class of routing protocol with the class of protocol that maintains routes 
"all the time", i.e., generic link state, or distance vector?
>
> Of course, this comparison would need to be made for carefully chosen 
end-to-end traffic profiles. If there is no traffic being offered to the 
network, then the on-demand protocol will generate no routing update 
traffic. And I suspect that if a uniform, heavy end-to-end traffic load is 
presented to an on-demand routing protocol, the protocol will look pretty 
bad in comparison.
>
>
> Thanks
>
> John Zavgren
> jz@bbn.com
> 617-873-2280
>
>
> 


From owner-manet@itd.nrl.navy.mil  Wed Mar 29 12:05:00 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 MAA22689
	for <manet-archive@odin.ietf.org>; Wed, 29 Mar 2000 12:04:59 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA05029
	for manet-outgoing; Wed, 29 Mar 2000 09:22:56 -0500 (EST)
Received: from postoffice.mail.cornell.edu (POSTOFFICE.MAIL.CORNELL.EDU [132.236.56.7])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA05024
	for <manet@itd.nrl.navy.mil>; Wed, 29 Mar 2000 09:22:54 -0500 (EST)
Received: from pearlman ([202.76.137.169])
	by postoffice.mail.cornell.edu (8.9.3/8.9.3) with SMTP id JAA26846
	for <manet@itd.nrl.navy.mil>; Wed, 29 Mar 2000 09:22:31 -0500 (EST)
Received: by localhost with Microsoft MAPI; Wed, 29 Mar 2000 09:21:15 -0500
Message-ID: <01BF9960.21CA9D20.mrp12@cornell.edu>
From: Marc Pearlman <mrp12@cornell.edu>
Reply-To: "mrp12@cornell.edu" <mrp12@cornell.edu>
To: "manet@itd.nrl.navy.mil" <manet@itd.nrl.navy.mil>
Subject: RE: overhead tradeoff between on-demand and generic link state routing protocols
Date: Wed, 29 Mar 2000 09:20:57 -0500
Organization: Cornell University
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk
Content-Transfer-Encoding: 7bit

Disclaimer (re: my previous posting)
... Any similarity between the response of a graduate student and his 
advisor is purely coincidental.  ;-)

regards,

Marc


On Wednesday, March 29, 2000 6:57 AM, Zygmunt Haas 
[SMTP:haas@ANISE.EE.CORNELL.EDU] wrote:
> Hi John,
>
> Actually, such an analysis should take into the account not only the
> traffic distribution, but the mobility of the nodes as well. Let me
> explain further.
>
> Another way of looking at the issue that you have raised is to see 
whether
> some mix of proactive vs. reactive (on-demand) behavior of the routing
> protocol would be more efficient for a specific network operational 
condition.
> In other words, if the network load is heavy and uniform, proactive 
protocols
> should do better, while when the load is low and highly localized, 
reactive
> protocols should be preferred. In the middle, there is a broad range of
> traffic mixes that would justify some degree of proactivity/reactivity.
>
> You see where I am getting at ... the ZRP is exactly such a protocol. It
> allows to adjust the degree of reactivity/proactivity in the protocol
> behavior based on a single parameter - the Zone Radius (ZR). It has been
> shown that for a highly dynamic network (i.e., high mobility nodes) and
> for low traffic load, small ZR leads to optimal performance - of course
> small ZR corresponds to a purely reactive protocol. On the other hand, 
for
> a stationary, highly loaded network, large ZR is much better, 
corresponding
> to purely proactive behavior.
>
> The ZR is like a "knob" (Joe's analogy (:-)) that allows to adjust the
> behavior of the protocol to the current network conditions (mobility and
> traffic load). More information on the behavior of this "knob" could be
> found in:
> M.R. Pearlman and Z.J. Haas, "Determining the Optimal Configuration of 
for
> the Zone Routing Protocol," IEEE JSAC, special issue on Ad-Hoc Networks,
> vol. 17, no.8, August 1999
>
> I believe that if there is to be a single (or a small set) of MANET
> routing protocols, some mechanism to adapt to the current network
> conditions (again, traffic load and nodal mobility) is essential, since
> the ad hoc networking environment is so braodly defined.
>
> Cheers,
>
> Zygmunt.
> ==-=-=-==
> 
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
> Prof. Zygmunt J. Haas                    tel: +1-607-255-3454
> Wireless Networks Laboratory		
> School of Electrical Engineering         fax: +1-607-255-9072
> Cornell University
> 323 Frank Rhodes Hall			 e-mail: haas@ee.cornell.edu
> Ithaca, NY 14853			
> U.S.A 
                            http://www.ee.cornell.edu/~haas/wnl.html
> 
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
>
> > On Tue, 28 Mar 2000, John Zavgren wrote:
> >
> > > Greetings:
> > >
> > >  I have been reading about on-demand routing protocols that are being 
proposed by the manet group.  Is there any analysis that compares this 
class of routing protocol with the class of protocol that maintains routes 
"all the time", i.e., generic link state, or distance vector?
> > >
> > > Of course, this comparison would need to be made for carefully chosen 
end-to-end traffic profiles. If there is no traffic being offered to the 
network, then the on-demand protocol will generate no routing update 
traffic. And I suspect that if a uniform, heavy end-to-end traffic load is 
presented to an on-demand routing protocol, the protocol will look pretty 
bad in comparison.
> > >
> > >
> > > Thanks
> > >
> > > John Zavgren
> > > jz@bbn.com
> > > 617-873-2280


From owner-manet@itd.nrl.navy.mil  Wed Mar 29 13:06:09 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 NAA23258
	for <manet-archive@odin.ietf.org>; Wed, 29 Mar 2000 13:06:08 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id KAA07070
	for manet-outgoing; Wed, 29 Mar 2000 10:41:46 -0500 (EST)
Received: from scires.com (mail.scires.com [12.36.154.4])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id KAA07064
	for <manet@itd.nrl.navy.mil>; Wed, 29 Mar 2000 10:41:43 -0500 (EST)
Received: from SRCATL-Message_Server by scires.com
	with Novell_GroupWise; Wed, 29 Mar 2000 10:37:03 -0500
Message-Id: <s8e1dccf.016@scires.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.2.1
Date: Wed, 29 Mar 2000 10:36:53 -0500
From: "Pete Sholander" <psholand@scires.com>
To: <jz@bbn.com>, <manet@itd.nrl.navy.mil>
Subject: Re: overhead tradeoff between on-demand and generic link state
	routing protocols
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id KAA07065
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk
Content-Transfer-Encoding: 8bit

John,

I think that Royer and Toh made a first cut at this trade-study back in the April 1999 issue of IEEE Personal Communications.  The title was "A Review of Current Routing Protocols for Ad Hoc Mobile Wireless Networks".  Although I don't believe that they considered network load in their analysis.

Kind Regards,
Pete Sholander

Scientific Research Corporation		
Atlanta, GA		

E: psholander@scires.com
V: 770-859-9161, x551

>>> "John Zavgren" <jz@bbn.com> 03/28/00 01:48PM >>>
Greetings:

 I have been reading about on-demand routing protocols that are being proposed by the manet group.  Is there any analysis that compares this class of routing protocol with the class of protocol that maintains routes "all the time", i.e., generic link state, or distance vector? 

Of course, this comparison would need to be made for carefully chosen end-to-end traffic profiles. If there is no traffic being offered to the network, then the on-demand protocol will generate no routing update traffic. And I suspect that if a uniform, heavy end-to-end traffic load is presented to an on-demand routing protocol, the protocol will look pretty bad in comparison.


Thanks

John Zavgren
jz@bbn.com 
617-873-2280







From owner-manet@itd.nrl.navy.mil  Wed Mar 29 13:12:08 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 NAA23281
	for <manet-archive@odin.ietf.org>; Wed, 29 Mar 2000 13:12:08 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA07965
	for manet-outgoing; Wed, 29 Mar 2000 11:21:35 -0500 (EST)
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 LAA07956
	for <manet@itd.nrl.navy.mil>; Wed, 29 Mar 2000 11:21:28 -0500 (EST)
Received: from gscex01.gsc.gte.com
 ("port 1418"@gscex01.ndhm.gsc.gte.com [155.95.162.170])
 by Newman.GSC.GTE.Com (PMDF V5.2-30 #38015)
 with ESMTP id <01JNLQBUUQ6O00022U@Newman.GSC.GTE.Com> for
 manet@itd.nrl.navy.mil; Wed, 29 Mar 2000 11:21:05 EST
Received: by GSCEX01.gsc.gte.com with Internet Mail Service (5.5.2448.0)
	id <GZX25MPP>; Wed, 29 Mar 2000 11:21:05 -0500
Content-return: allowed
Date: Wed, 29 Mar 2000 11:21:04 -0500
From: "Josephson, William" <William.Josephson@GD-CS.com>
Subject: RE: overhead tradeoff between on-demand and generic link state ro
	uting protocols
To: "'Zygmunt Haas'" <haas@anise.ee.cornell.edu>, John Zavgren <jz@bbn.com>
Cc: "M. Scott Corson" <corson@glue.umd.edu>, manet@itd.nrl.navy.mil
Message-id: <3774EF539472D211B98F0008C7F468A103ABF373@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

It's really not fair to describe any one approach to be optimal based solely
on the amount of overhead it generates.  In some situations, one desires
more to minimize delay to setup the topology and effect information transfer
more than minimizing overhead.  Usually
both count.  As a simple example, an on-demand protocol in which its nodes
caches its routes for a very long periods of node idleness will perform
quicker when all the nodes need to wake up
and react (to the event not the link change). This is a situation of a
fairly immobile but ad
hoc network like bluetooth attempts to solve.

-----Original Message-----
From: Zygmunt Haas [mailto:haas@anise.ee.cornell.edu]
Sent: Wednesday, March 29, 2000 6:57 AM
To: John Zavgren
Cc: M. Scott Corson; manet@itd.nrl.navy.mil; Zygmunt Haas
Subject: Re: overhead tradeoff between on-demand and generic link state
routing protocols


Hi John,

Actually, such an analysis should take into the account not only the
traffic distribution, but the mobility of the nodes as well. Let me
explain further.

Another way of looking at the issue that you have raised is to see whether
some mix of proactive vs. reactive (on-demand) behavior of the routing 
protocol would be more efficient for a specific network operational
condition. 
In other words, if the network load is heavy and uniform, proactive
protocols 
should do better, while when the load is low and highly localized, reactive
protocols should be preferred. In the middle, there is a broad range of
traffic mixes that would justify some degree of proactivity/reactivity.

You see where I am getting at ... the ZRP is exactly such a protocol. It
allows to adjust the degree of reactivity/proactivity in the protocol
behavior based on a single parameter - the Zone Radius (ZR). It has been
shown that for a highly dynamic network (i.e., high mobility nodes) and
for low traffic load, small ZR leads to optimal performance - of course
small ZR corresponds to a purely reactive protocol. On the other hand, for
a stationary, highly loaded network, large ZR is much better, corresponding 
to purely proactive behavior.

The ZR is like a "knob" (Joe's analogy (:-)) that allows to adjust the
behavior of the protocol to the current network conditions (mobility and
traffic load). More information on the behavior of this "knob" could be
found in:
M.R. Pearlman and Z.J. Haas, "Determining the Optimal Configuration of for
the Zone Routing Protocol," IEEE JSAC, special issue on Ad-Hoc Networks,
vol. 17, no.8, August 1999

I believe that if there is to be a single (or a small set) of MANET
routing protocols, some mechanism to adapt to the current network
conditions (again, traffic load and nodal mobility) is essential, since
the ad hoc networking environment is so braodly defined.

Cheers,

Zygmunt.
==-=-=-==
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
Prof. Zygmunt J. Haas                    tel: +1-607-255-3454
Wireless Networks Laboratory		                  
School of Electrical Engineering         fax: +1-607-255-9072 
Cornell University
323 Frank Rhodes Hall			 e-mail: haas@ee.cornell.edu
Ithaca, NY 14853			 
U.S.A                             http://www.ee.cornell.edu/~haas/wnl.html
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-

> On Tue, 28 Mar 2000, John Zavgren wrote:
>
> > Greetings:
> > 
> >  I have been reading about on-demand routing protocols that are being
proposed by the manet group.  Is there any analysis that compares this class
of routing protocol with the class of protocol that maintains routes "all
the time", i.e., generic link state, or distance vector? 
> > 
> > Of course, this comparison would need to be made for carefully chosen
end-to-end traffic profiles. If there is no traffic being offered to the
network, then the on-demand protocol will generate no routing update
traffic. And I suspect that if a uniform, heavy end-to-end traffic load is
presented to an on-demand routing protocol, the protocol will look pretty
bad in comparison.
> > 
> > 
> > Thanks
> > 
> > John Zavgren
> > jz@bbn.com
> > 617-873-2280


From owner-manet@itd.nrl.navy.mil  Wed Mar 29 13: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 NAA23301
	for <manet-archive@odin.ietf.org>; Wed, 29 Mar 2000 13:17:44 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id LAA08073
	for manet-outgoing; Wed, 29 Mar 2000 11:25:36 -0500 (EST)
Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA08068
	for <manet@itd.nrl.navy.mil>; Wed, 29 Mar 2000 11:25:34 -0500 (EST)
Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204])
 by research.kpn.com (PMDF V5.2-31 #35196)
 with ESMTP id <01JNM54RGYU20011ZQ@research.kpn.com> for
 manet@itd.nrl.navy.mil; Wed, 29 Mar 2000 18:25:15 +0200
Received: by l04.research.kpn.com with Internet Mail Service (5.5.2650.21)
	id <GZCCG6XC>; Wed, 29 Mar 2000 18:25:14 +0100
Content-return: allowed
Date: Wed, 29 Mar 2000 18:25:12 +0100
From: "Groten, D." <D.Groten@kpn.com>
Subject: Ad-hoc networking with the ETSI Hiperlan/1 standard
To: "'manet@itd.nrl.navy.mil'" <manet@itd.nrl.navy.mil>
Message-id: <59063B5B4D98D311BC0D0001FA7E4522704B9C@l04.research.kpn.com>
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

Hi all,

I recently stumbled across the Hiperlan/1 standard (ETSI EN 300 652) for
wireless networks, and noticed that this standard supports multi-hop routing
in an ad-hoc network. This standard defines its own layer model, PHY, CAC
and MAC layers which cover only the lowest two layers (physical and link) in
the OSI model. It includes a routing algorithm (including multi-hop) so that
the whole Hiperlan/1 network essentially behaves as an Ethernet and one can
put IP over it. 

My question is: What kind of routing approach is used in this standard? Can
it be compared to any of the routing approaches that are considered by the
MANET working group, which are mostly concerned with routing on the IP
(network) layer? I would be glad to hear of any publications/references
covering this subject.

Note: To prevent misunderstanding, I want to stress that I am talking here
about Hiperlan Type 1, and not about any of the other Hiperlan work in
progress (Hiperlan/2, HiperAccess or HiperLink) which has nothing to do with
mobile ad-hoc networking.

Thank you in advance,

Dirk.

Dr. D. Groten
KPN Research
P. O. Box 421
2260 AK Leidschendam
The Netherlands
Tel. +31 70 3325433


From owner-manet@itd.nrl.navy.mil  Wed Mar 29 15:03: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 PAA24067
	for <manet-archive@odin.ietf.org>; Wed, 29 Mar 2000 15:03:03 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id NAA10937
	for manet-outgoing; Wed, 29 Mar 2000 13:14:44 -0500 (EST)
Received: from anise.ee.cornell.edu (ANISE.EE.CORNELL.EDU [128.84.239.14])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id NAA10928
	for <manet@itd.nrl.navy.mil>; Wed, 29 Mar 2000 13:14:41 -0500 (EST)
Received: from VERDI.EE.CORNELL.EDU (VERDI.EE.CORNELL.EDU [128.84.240.71])
	by anise.ee.cornell.edu (8.9.3/8.9.1) with ESMTP id NAA07906;
	Wed, 29 Mar 2000 13:14:13 -0500 (EST)
Date: Wed, 29 Mar 2000 13:14:10 -0500 (EST)
From: Zygmunt Haas <haas@anise.ee.cornell.edu>
To: "Josephson, William" <William.Josephson@GD-CS.com>
cc: "'Zygmunt Haas'" <haas@anise.ee.cornell.edu>, John Zavgren <jz@bbn.com>,
        "M. Scott Corson" <corson@glue.umd.edu>, manet@itd.nrl.navy.mil
Subject: RE: overhead tradeoff between on-demand and generic link state ro
 uting protocols
In-Reply-To: <3774EF539472D211B98F0008C7F468A103ABF373@TNTNEX01.tntn.gtegsc.com>
Message-ID: <Pine.HPX.4.21.0003291239420.6690-100000@verdi.ee.cornell.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

Hi Bill,

Yes, I agree that other considerations, besides the volume of control
traffic, need to be taken while considering the proactive vs. reactive 
protocol behavior. As you have rightfully stated, delay is one such a
consideration. (I do not, however, agree that on-demand protocols
(even with extensively long caching) would perform better than proactive
protocols, as in the proactive protocols routes are always available
immediately when they are needed.
 
To add my "3 cents" again - a hybrid (proactive/reactive) protocol could
be useful in "optimizing" the response time. Maybe, a correct approach
would be to consider a "cost" function that contains both communication
overhead and delay, weighted by some coefficient of importance to a
specific application.

Zygmunt.
===--====

~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
Prof. Zygmunt J. Haas                    tel: +1-607-255-3454
Wireless Networks Laboratory		                  
School of Electrical Engineering         fax: +1-607-255-9072 
Cornell University
323 Frank Rhodes Hall			 e-mail: haas@ee.cornell.edu
Ithaca, NY 14853			 
U.S.A                             http://www.ee.cornell.edu/~haas/wnl.html
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-

On Wed, 29 Mar 2000, Josephson, William wrote:

> It's really not fair to describe any one approach to be optimal based solely
> on the amount of overhead it generates.  In some situations, one desires
> more to minimize delay to setup the topology and effect information transfer
> more than minimizing overhead.  Usually
> both count.  As a simple example, an on-demand protocol in which its nodes
> caches its routes for a very long periods of node idleness will perform
> quicker when all the nodes need to wake up
> and react (to the event not the link change). This is a situation of a
> fairly immobile but ad
> hoc network like bluetooth attempts to solve.
> 
> -----Original Message-----
> From: Zygmunt Haas [mailto:haas@anise.ee.cornell.edu]
> Sent: Wednesday, March 29, 2000 6:57 AM
> To: John Zavgren
> Cc: M. Scott Corson; manet@itd.nrl.navy.mil; Zygmunt Haas
> Subject: Re: overhead tradeoff between on-demand and generic link state
> routing protocols
> 
> 



From owner-manet@itd.nrl.navy.mil  Wed Mar 29 19:50: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 TAA26341
	for <manet-archive@odin.ietf.org>; Wed, 29 Mar 2000 19:50:02 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id RAA17396
	for manet-outgoing; Wed, 29 Mar 2000 17:53:48 -0500 (EST)
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 RAA17391
	for <manet@itd.nrl.navy.mil>; Wed, 29 Mar 2000 17:53:45 -0500 (EST)
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 RAA10262;
	Wed, 29 Mar 2000 17:50:41 -0500 (EST)
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 RAA11641;
	Wed, 29 Mar 2000 17:53:17 -0500 (EST)
Received: from localhost (corson@localhost)
	by manet.isr.umd.edu (8.9.3/8.9.3) with ESMTP id RAA11637;
	Wed, 29 Mar 2000 17:53:16 -0500 (EST)
X-Authentication-Warning: manet.isr.umd.edu: corson owned process doing -bs
Date: Wed, 29 Mar 2000 17:53:05 -0500 (EST)
From: "M. Scott Corson" <corson@glue.umd.edu>
X-Sender: corson@manet.isr.umd.edu
To: "Groten, D." <D.Groten@kpn.com>
cc: "'manet@itd.nrl.navy.mil'" <manet@itd.nrl.navy.mil>
Subject: Re: Ad-hoc networking with the ETSI Hiperlan/1 standard
In-Reply-To: <59063B5B4D98D311BC0D0001FA7E4522704B9C@l04.research.kpn.com>
Message-ID: <Pine.GSO.4.21.0003291746470.11552-100000@manet.isr.umd.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

On Wed, 29 Mar 2000, Groten, D. wrote:

The layer 2 subnet routing approach of Hiperlan/1 has been proposed
for use at layer 3 in the IETF and is named Optimized Link State
Routing (OLSR)...see...

draft-ietf-manet-olsr-01.txt

-scott

> Hi all,
> 
> I recently stumbled across the Hiperlan/1 standard (ETSI EN 300 652) for
> wireless networks, and noticed that this standard supports multi-hop routing
> in an ad-hoc network. This standard defines its own layer model, PHY, CAC
> and MAC layers which cover only the lowest two layers (physical and link) in
> the OSI model. It includes a routing algorithm (including multi-hop) so that
> the whole Hiperlan/1 network essentially behaves as an Ethernet and one can
> put IP over it. 
> 
> My question is: What kind of routing approach is used in this standard? Can
> it be compared to any of the routing approaches that are considered by the
> MANET working group, which are mostly concerned with routing on the IP
> (network) layer? I would be glad to hear of any publications/references
> covering this subject.
> 
> Note: To prevent misunderstanding, I want to stress that I am talking here
> about Hiperlan Type 1, and not about any of the other Hiperlan work in
> progress (Hiperlan/2, HiperAccess or HiperLink) which has nothing to do with
> mobile ad-hoc networking.
> 
> Thank you in advance,
> 
> Dirk.
> 
> Dr. D. Groten
> KPN Research
> P. O. Box 421
> 2260 AK Leidschendam
> The Netherlands
> Tel. +31 70 3325433
> 


*******************************************************************************

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  Wed Mar 29 23:16:45 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 XAA00174
	for <manet-archive@odin.ietf.org>; Wed, 29 Mar 2000 23:16:44 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id VAA20131
	for manet-outgoing; Wed, 29 Mar 2000 21:37:36 -0500 (EST)
Received: from cupidon.inria.fr (cupidon.inria.fr [128.93.5.23])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id VAA20125
	for <manet@itd.nrl.navy.mil>; Wed, 29 Mar 2000 21:37:33 -0500 (EST)
Received: (qmail 18167 invoked by uid 11205); 30 Mar 2000 01:37:12 -0000
From: Laurent Viennot <Laurent.Viennot@inria.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14562.44998.837520.413934@cupidon.inria.fr>
Date: Thu, 30 Mar 2000 03:37:10 +0200 (CEST)
To: "John Zavgren" <jz@bbn.com>
Cc: <manet@itd.nrl.navy.mil>
Subject: overhead tradeoff between on-demand and generic link state routing protocols
In-Reply-To: <NDBBLCLJOLMGNMOFLAKMOEGECBAA.jz@bbn.com>
References: <NDBBLCLJOLMGNMOFLAKMOEGECBAA.jz@bbn.com>
X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid
Reply-To: Laurent.Viennot@inria.fr
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk
Content-Transfer-Encoding: 7bit


Both pro-active and reactive protocols have significant traffic
control overhead to discover routes.

I see basically two approaches that differ by their main contribution
to traffic control :
- protocols that find routes by flooding (AODV, DSR, TORA, ...)
- protocols that discover topology with hellos (OLSR, STAR, ZRP, ...)


Another source of overhead is the use non-optimal routes. 

Concerning analytical models about overheads, you can also consult the
technical report by Jacquet and Laouiti "Analysis of mobile ad-hoc
routing protocols in random graph models".

Url : ftp://ftp.inria.fr/INRIA/tech-reports/RR/RR-3835.ps.gz

laurent


From owner-manet@itd.nrl.navy.mil  Thu Mar 30 08:51:30 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 IAA16448
	for <manet-archive@odin.ietf.org>; Thu, 30 Mar 2000 08:51:27 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id HAA25897
	for manet-outgoing; Thu, 30 Mar 2000 07:01:37 -0500 (EST)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id HAA25892
	for <manet@itd.nrl.navy.mil>; Thu, 30 Mar 2000 07:01:35 -0500 (EST)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id OAA16922;
	Thu, 30 Mar 2000 14:01:33 +0200 (MET DST)
Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id OAA26086; Thu, 30 Mar 2000 14:01:33 +0200
Message-ID: <38E3420E.E296FBF7@era.ericsson.se>
Date: Thu, 30 Mar 2000 14:01:18 +0200
From: Fredrik Alriksson <fredrik.alriksson@era.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: John Zavgren <jz@bbn.com>
CC: manet@itd.nrl.navy.mil
Subject: Re: overhead tradeoff between on-demand and generic link state routing 
 protocols
References: <NDBBLCLJOLMGNMOFLAKMOEGECBAA.jz@bbn.com>
Content-Type: multipart/mixed;
 boundary="------------000D7BDA0B6EB4B34CA43505"
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

This is a multi-part message in MIME format.
--------------000D7BDA0B6EB4B34CA43505
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi John,
              actually, a paper presented at MobiCom'99 compares AODV, DSR, and DSDV in different scenarios. It is called "Scenario-Based Performance Analysis of Routing Protocols for Mobile Ad-Hoc Networks" and written by Per Johansson et.al.

There is also a paper by Josh Broch et.al., "A performance Comparison of Multi-Hop Wireless Ad Hoc Network Routing Protocols", from MobiCom'98 that you might want to check out.

Regards,

    Fredrik Alriksson

John Zavgren wrote:

> Greetings:
>
>  I have been reading about on-demand routing protocols that are being proposed by the manet group.  Is there any analysis that compares this class of routing protocol with the class of protocol that maintains routes "all the time", i.e., generic link state, or distance vector?
>
> Of course, this comparison would need to be made for carefully chosen end-to-end traffic profiles. If there is no traffic being offered to the network, then the on-demand protocol will generate no routing update traffic. And I suspect that if a uniform, heavy end-to-end traffic load is presented to an on-demand routing protocol, the protocol will look pretty bad in comparison.
>
> Thanks
>
> John Zavgren
> jz@bbn.com
> 617-873-2280

--------------000D7BDA0B6EB4B34CA43505
Content-Type: text/x-vcard; charset=us-ascii;
 name="fredrik.alriksson.vcf"
Content-Description: Card for Fredrik Alriksson
Content-Disposition: attachment;
 filename="fredrik.alriksson.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Alriksson;Fredrik
tel;cell:+46 (0) 70 792 12 72
tel;fax:+46 8 508 780 86
tel;work:+46 8 508 780 86
x-mozilla-html:FALSE
org:Network & Systems;Ericsson Research, Corporate Unit
adr:;;Ericsson Radio Systems AB;;;SE-164 80 Stockholm;Sweden
version:2.1
email;internet:fredrik.alriksson@ericsson.com
fn:Fredrik Alriksson
end:vcard

--------------000D7BDA0B6EB4B34CA43505--



From owner-manet@itd.nrl.navy.mil  Thu Mar 30 11:09:14 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 LAA17412
	for <manet-archive@odin.ietf.org>; Thu, 30 Mar 2000 11:09:13 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id JAA28114
	for manet-outgoing; Thu, 30 Mar 2000 09:20:31 -0500 (EST)
Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA28109
	for <manet@itd.nrl.navy.mil>; Thu, 30 Mar 2000 09:20:28 -0500 (EST)
Received: from thinkbad (SSH.BBN.COM [192.1.50.70])
	by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with SMTP id JAA13453
	for <manet@itd.nrl.navy.mil>; Thu, 30 Mar 2000 09:20:27 -0500 (EST)
From: "John Zavgren" <jz@bbn.com>
To: <manet@itd.nrl.navy.mil>
Subject: comparison of reactive and proactive protocols
Date: Thu, 30 Mar 2000 09:14:55 -0500
Message-ID: <NDBBLCLJOLMGNMOFLAKMIEHNCBAA.jz@bbn.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by itd.nrl.navy.mil id JAA28110
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk
Content-Transfer-Encoding: 8bit

Greetings:

 Thanks for the overwhelming response to the question that I posted recently. I received a large number of good comments and references, however, I'm a little concerned by the lack of analysis that compares the behavior of the "avant guarde" on demand, reactive, protocols with the more staid, proactive protocols, sometimes referred to as "table driven".  (Or should we call them "plug board" protocols!) There seems to be a lot of work done on comparing reactive protcols against each other, but very little or no work seems to be done makes comparisons across the two broad catagories of protocols: proactive versus reactive.

 Is there a "level playing field" analysis that compares the two approaches for identical scenarios: mobility, traffic loads, datalink interface, etc? I.e., one and only one independent variable: the routing protocol?

Thanks.

 



From owner-manet@itd.nrl.navy.mil  Thu Mar 30 14:39:30 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 OAA20914
	for <manet-archive@odin.ietf.org>; Thu, 30 Mar 2000 14:39:30 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA02671
	for manet-outgoing; Thu, 30 Mar 2000 12:39:06 -0500 (EST)
Received: from mercury.utsa.edu (mercury.utsa.edu [129.115.102.85])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id MAA02663
	for <manet@itd.nrl.navy.mil>; Thu, 30 Mar 2000 12:39:00 -0500 (EST)
Received: by mercury.utsa.edu with Internet Mail Service (5.5.2448.0)
	id <HAR5P7HB>; Thu, 30 Mar 2000 11:37:58 -0600
Message-ID: <2AC6ACF763C9D21187B908002BB2A00502144418@cain.utsa.edu>
From: Rajendra Boppana <RBOPPANA@utsa.edu>
To: "'jz@bbn.com'" <jz@bbn.com>, manet@itd.nrl.navy.mil
Subject: RE: comparison of reactive and proactive protocols
Date: Thu, 30 Mar 2000 11:41:25 -0600
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

Hi John and others,

My student and I have recently completed a simulation analysis of pro-active
vs. on-demand algorithms. Starting with DSDV, we developed an adaptive
distance vector (ADV) algorithm that adapts to traffic and mobility. We
compared ADV with AODV and DSR.

We considered 64-byte and 512-byte packets, node speeds chosen randomly from
[0,1) or [0,20) m/s, 1000m x 1000m square field and 1500m x 600m rectangular
fields, 50- and 100-node networks, and 20, 40, or 60 CBR connections. (Not
all combinations of parameters were simulated.)

We found that ADV gives lower latency (at almost all packet rates) and
substantially higher throughput before saturating. The results on delivery
rates are mixed: ADV has lower delivery rate when the number of connections
is low, but comparable or higher delivery rates when the number of
connections is high. ADV's routing overhead in packets/s, but high in
bits/s.  (All comparisons are w.r.t. AODV and DSR.)

We are currently polishing the write-up, and hope to finish soon. If there
is sufficient interest, I will be glad to provide the graphs.


Raj


-----Original Message-----
From: John Zavgren [mailto:jz@bbn.com]
Sent: Thursday, March 30, 2000 6:15 AM
To: manet@itd.nrl.navy.mil
Subject: comparison of reactive and proactive protocols


Greetings:

 Thanks for the overwhelming response to the question that I posted
recently. I received a large number of good comments and references,
however, I'm a little concerned by the lack of analysis that compares the
behavior of the "avant guarde" on demand, reactive, protocols with the more
staid, proactive protocols, sometimes referred to as "table driven".  (Or
should we call them "plug board" protocols!) There seems to be a lot of work
done on comparing reactive protcols against each other, but very little or
no work seems to be done makes comparisons across the two broad catagories
of protocols: proactive versus reactive.

 Is there a "level playing field" analysis that compares the two approaches
for identical scenarios: mobility, traffic loads, datalink interface, etc?
I.e., one and only one independent variable: the routing protocol?

Thanks.

 


From owner-manet@itd.nrl.navy.mil  Thu Mar 30 16:53:13 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 QAA22031
	for <manet-archive@odin.ietf.org>; Thu, 30 Mar 2000 16:53:11 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id OAA05425
	for manet-outgoing; Thu, 30 Mar 2000 14:43:42 -0500 (EST)
Received: from uci.agh.edu.pl (galaxy.uci.agh.edu.pl [149.156.96.9])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA05331
	for <manet@itd.nrl.navy.mil>; Thu, 30 Mar 2000 14:38:37 -0500 (EST)
Received: from saturn.kt.agh.edu.pl (root@saturn.kt.agh.edu.pl [149.156.114.3])
	by uci.agh.edu.pl (8.9.3/8.8.7/rchk1.20) with SMTP id VAA01115
	for <manet@itd.nrl.navy.mil>; Thu, 30 Mar 2000 21:33:49 +0200 (MET DST)
Received: by saturn.kt.agh.edu.pl (AIX 3.2/UCB 5.64/5.1)
          id AA54464; Thu, 30 Mar 2000 21:03:21 +0100
Date: Thu, 30 Mar 2000 21:03:21 +0100
From: proms@saturn.kt.agh.edu.pl (Piotr Pacyna)
Message-Id: <10003302003.AA54464@saturn.kt.agh.edu.pl>
Organization: University of Mining and Metallurgy
Address: Mickiewicza 30, 30-059 Krakow, POLAND
To: manet@itd.nrl.navy.mil
Subject: PROMS2000 Call for Papers
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

Dear Sir, Dear Madam,

Please find enclosed the Protocols for Multimedia Systems conference CfP.
Please read it and send to your collegues. Thank you for your attention.
We do apologise if you receive multiple copies of this.

With best regards,
Piotr Pacyna

++++++++++++++++++++++++++++++++++++++++++++++++++++++

(Please apologize, if you receive multiple copies of this CfP)

                       Announcement and Call for Papers

                  PROTOCOLS FOR MULTIMEDIA SYSTEMS - PROMS2000

                       Cracow, Poland, October 22-25, 2000
Sponsored by IEEE Poland Sect. and Cracow Communications Soc. Chap.
Lucent Technologies, ZWUT a Siemens Company,
                         http://PROMS2000.kt.agh.edu.pl/

After past successful PROMS conferences held in Berlin, Salzburg,
Madrid, and Santiago de Chile now we cordially invite you to
Cracow/Poland, a lovely university city, with a 1000 year history, today
one of cultural capitals of Europe.

Emerging broadband interactive applications along with a development of
different networking technologies should draw telecom operators' and
service providers' attention to protocols supporting multimedia systems
as an interface between these two environments that has to be still
investigated and modified.

The PROMS2000 conference is intended to contribute to a scientific,
strategical and practical cooperation between research institutes and
industrial companies in the area of distributed multimedia applications,
protocols, and intelligent management tools, with emphasis on their
provision over broadband networks.

PROMS2000 will cover papers and demonstrations on research and
achievements related to the following topics:

TOPICS
* design and implementation of multimedia protocols for public switched
telephony networks, mobile networks, data networks, and satellite
networks using IP, ATM or other connectivity techniques;
* application, media, and protocol integration: synchronization of media
streams;
* multiparty and group communication protocols;
* mobile networking and routing: multimedia communication architectures
for mobile networks;
* multimedia applications: video-on-demand, digital video libraries,
video games, virtual community, teleworking, teleteaching, e-commerce,
telemeeting, virtual reality simulations;
* content based searching and querying;
* techniques for the specification of communication services required by
multimedia applications;
* methods for real-time testing and analysis of service implementations;

* integration of media storage and communication mechanisms, operating
system and high-performance issues;
* experiences with service provisioning using distributed multimedia
applications;
* performance of protocols, such as TCP, and applications: modeling, simulation and optimization in different networks
* multimedia traffic engineering;
* applications and platforms for service management and provisioning;
* definition, provisioning, and supervision of QoS parameters for
networked applications and services;
* intelligent management tools pertaining to costs and quality of
service, network access, accounting, security, and system resilience;
* service access - security, authentication, privacy;
* accounting and tariff policing for multimedia teleservices.

IMPORTANT DATES
* Full papers due                     June 26, 2000
* Authors notified                    July 24, 2000
* Full paper camera ready due         September 25, 2000

CONFERENCE TIMETABLE
* 1st day       October 22      full-day sightseeing tour (optional)
* 2nd day       October 23      tutorials, welcome reception
* 3rd day       October 24      invited talks, sessions, panel, banquet
* 4th day       October 25      invited talks, sessions

VENUE
Its history rooted deep in the Middle Ages, Cracow, is the most
celebrated city in Poland. UNESCO has added its architectural complex to
the World Heritage List. Cracow's appeal today, however, is no longer
attributable solely to the beauty of its medieval architecture, but to
its strong scientific potential for applied research and development.

The PROMS2000 Conference will be held on the modern premises of the
Department of Telecommunications within walking distance of both the
downtown area and hotels. Direct flights to Cracow are available to and
from Chicago, Copenhagen, New York, Toronto, Frankfurt, London, Paris,
Rome, Tel Aviv, Vienna and Zurich.

SUBMISSION
Submit a full manuscript to the PROMS chair in an electronic form
(MSWord, Postscript or pdf file); editorial requirements can be found at
http://PROMS2000.kt.agh.edu.pl/.

PROCEEDINGS
1. Each participant will receive Proceedings from the conference.
2. Two best papers will be considered for publication in the IEEE Communications
   Magazine (March 2001 issue) in a feature topic "Protocols for Multimedia
   Systems".

CONFERENCE CHAIR
Zdzislaw PAPIR
Department of Telecommunications
University of Mining and Metallurgy
Al. Mickiewicza 30
30-059 Cracow, Poland
E-mail: papir@kt.agh.edu.pl
Phone: +48 12 634 55 82
Fax: +48 12 634 23 72

PROGRAM COMMITTEE
Koichi Asatani, Univ. Kogakuin, asatani@sin.cc.kogakuin.ac.jp
William Atwood, Univ. Concordia, Bill@cs.Concordia.ca
Arturo Azcorra, Univ. Carlos III de Madrid, azcorra@it.uc3m.es
Stanislaw Budkowski, INT-Evry, stan@int-evry.fr
Andrew Campbell, Univ. Columbia, campbell@ctr.columbia.edu
Michel Diaz, LAAS-CNRS, diaz@laas.fr
Wolfgang Effelsberg, Univ. Mannheim,
effelsberg@informatik.uni-mannheim.de
Paolo Fasano, CSELT, Paolo.Fasano@cselt.it
Francisco Fontes, Portugal Telecom, fontes@ptinovacao.pt
Nicolas D. Georganas, Univ. Ottawa, georgana@mcrlab.uottawa.ca
Per Gunningberg, Univ. Uppsala, Per.Gunningberg@docs.uu.se
Ulrich Hofmann, Univ. Salzburg, ulrich.hofmann@fh-sbg.ac.at
David Hutchison, Univ. Lancaster, dh@comp.lancs.ac.uk
Yuji Inoue, NTT, yuji@rd.nttdata.co.jp
Andrzej Jajszczyk, Univ. Mining and Metallurgy, jajszcz@kt.agh.edu.pl
Pedro Lizcano, Telefonica Labs, lizcano@tid.es
John C. S. Lui, Chinese Univ. Hong Kong, cslui@cse.cuhk.edu.hk
Andrzej R. Pach, Univ. Mining & Metallurgy, pach@kt.agh.edu.pl
Sergio Palazzo, Univ. Catania, palazzo@iit.unict.it
Thomas Plagemann, Center for Technology, plageman@unik.no
Radia Perlman, SUN, radia.perlman@sun.com
Radu Popescu-Zeletin, GMD, zeletin@fokus.gmd.de
Marten J. van Sinderen, Univ. Twente, sinderen@cs.utwente.nl
Kazem Sohraby, Lucent, sohraby@lucent.com
Joan I. Solana, Nokia Telecom R & D, juan.solana@nokia.com
Eduardo Vera, Univ. of Chile, evera@accessnova.cl
Johan Zuidweg, Tecsidel, johan.zuidweg@ieee.org

ORGANISING COMMITTEE
Chair: Piotr PACYNA, proms@kt.agh.edu.pl
K. Juszkiewicz, juszkiew@kt.agh.edu.pl
J. Gozdecki, gozdecki@kt.agh.edu.pl
J. Roman, roman@kt.agh.edu.pl


From owner-manet@itd.nrl.navy.mil  Thu Mar 30 17:15: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 RAA22389
	for <manet-archive@odin.ietf.org>; Thu, 30 Mar 2000 17:15:23 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA06759
	for manet-outgoing; Thu, 30 Mar 2000 15:32:20 -0500 (EST)
Received: from pj.cse.ucsc.edu (pj.cse.ucsc.edu [128.114.49.50])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id PAA06748
	for <manet@itd.nrl.navy.mil>; Thu, 30 Mar 2000 15:32:16 -0500 (EST)
Received: from pj (jj@localhost) by pj.cse.ucsc.edu (8.6.10/8.6.12) with ESMTP id MAA01201; Thu, 30 Mar 2000 12:32:06 -0800
Message-Id: <200003302032.MAA01201@pj.cse.ucsc.edu>
To: Laurent.Viennot@inria.fr
cc: "John Zavgren" <jz@bbn.com>, manet@itd.nrl.navy.mil, jj@cse.ucsc.edu
Subject: Re: overhead tradeoff between on-demand and generic link state routing protocols 
In-reply-to: Your message of "Thu, 30 Mar 2000 03:37:10 +0200."
             <14562.44998.837520.413934@cupidon.inria.fr> 
Date: Thu, 30 Mar 2000 12:32:06 -0800
From: Jose Garcia-Luna <jj@cse.ucsc.edu>
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk


It appears that you are oversimplifying the way in which STAR works.
STAR does not use HELLOs.

JJ


From owner-manet@itd.nrl.navy.mil  Thu Mar 30 22:07:12 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 WAA26104
	for <manet-archive@odin.ietf.org>; Thu, 30 Mar 2000 22:07:11 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id UAA12418
	for manet-outgoing; Thu, 30 Mar 2000 20:29:21 -0500 (EST)
Received: from cupidon.inria.fr (cupidon.inria.fr [128.93.5.23])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id UAA12413
	for <manet@itd.nrl.navy.mil>; Thu, 30 Mar 2000 20:29:19 -0500 (EST)
Received: (qmail 22621 invoked by uid 11205); 31 Mar 2000 01:29:17 -0000
From: Laurent Viennot <Laurent.Viennot@inria.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14563.65389.69937.987050@cupidon.inria.fr>
Date: Fri, 31 Mar 2000 03:29:17 +0200 (CEST)
To: Jose Garcia-Luna <jj@cse.ucsc.edu>
Cc: Laurent.Viennot@inria.fr, "John Zavgren" <jz@bbn.com>,
        manet@itd.nrl.navy.mil
Subject: Re: overhead tradeoff between on-demand and generic link state routing protocols 
In-Reply-To: <200003302032.MAA01201@pj.cse.ucsc.edu>
References: <14562.44998.837520.413934@cupidon.inria.fr>
	<200003302032.MAA01201@pj.cse.ucsc.edu>
X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid
Reply-To: Laurent.Viennot@inria.fr
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk
Content-Transfer-Encoding: 7bit

I may have misunderstood how works your underlying neighbour protocol.
Don't you need periodic beaconing ? 

laurent



From owner-manet@itd.nrl.navy.mil  Fri Mar 31 01:57:14 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 BAA03547
	for <manet-archive@odin.ietf.org>; Fri, 31 Mar 2000 01:57:14 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id XAA15135
	for manet-outgoing; Thu, 30 Mar 2000 23:56:55 -0500 (EST)
Received: from pj.cse.ucsc.edu (pj.cse.ucsc.edu [128.114.49.50])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id XAA15127
	for <manet@itd.nrl.navy.mil>; Thu, 30 Mar 2000 23:56:47 -0500 (EST)
Received: from pj (jj@localhost) by pj.cse.ucsc.edu (8.6.10/8.6.12) with ESMTP id UAA04221; Thu, 30 Mar 2000 20:56:39 -0800
Message-Id: <200003310456.UAA04221@pj.cse.ucsc.edu>
To: Laurent.Viennot@inria.fr
cc: Jose Garcia-Luna <jj@cse.ucsc.edu>, "John Zavgren" <jz@bbn.com>,
        manet@itd.nrl.navy.mil, jj@cse.ucsc.edu
Subject: Re: overhead tradeoff between on-demand and generic link state routing protocols 
In-reply-to: Your message of "Fri, 31 Mar 2000 03:29:17 +0200."
             <14563.65389.69937.987050@cupidon.inria.fr> 
Date: Thu, 30 Mar 2000 20:56:39 -0800
From: Jose Garcia-Luna <jj@cse.ucsc.edu>
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

nope!
JJ


From owner-manet@itd.nrl.navy.mil  Fri Mar 31 17:38:10 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 RAA18913
	for <manet-archive@odin.ietf.org>; Fri, 31 Mar 2000 17:38:10 -0500 (EST)
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id PAA02453
	for manet-outgoing; Fri, 31 Mar 2000 15:52:31 -0500 (EST)
Received: from cs.tamu.edu (clavin.cs.tamu.edu [128.194.130.106])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA02448
	for <manet@itd.nrl.navy.mil>; Fri, 31 Mar 2000 15:52:28 -0500 (EST)
Received: from sun.cs.tamu.edu (IDENT:2654@sun [128.194.135.14])
	by cs.tamu.edu (8.9.3/8.9.3) with ESMTP id OAA21132
	for <manet@itd.nrl.navy.mil>; Fri, 31 Mar 2000 14:52:23 -0600 (CST)
From: Nitin H Vaidya <vaidya@cs.tamu.edu>
Received: (from vaidya@localhost)
	by sun.cs.tamu.edu (8.9.3/8.9.3) id OAA22435
	for manet@itd.nrl.navy.mil; Fri, 31 Mar 2000 14:51:27 -0600 (CST)
Date: Fri, 31 Mar 2000 14:51:27 -0600 (CST)
Message-Id: <200003312051.OAA22435@sun.cs.tamu.edu>
To: manet@itd.nrl.navy.mil
Subject: naming/address assignment
Sender: owner-manet@itd.nrl.navy.mil
Precedence: bulk

Hello:

If you know any work on naming/address assignment in
mobile ad hoc networks, can you please send me a pointer.

Thanks.

- nitin