Subject: RE: Re[2]: MANET Addressing Architecture

From: "M. Scott Corson" <[email-masked]>
Date: Wed, 9 Sep 1998 12:31:18 -0400 (EDT)

On Wed, 9 Sep 1998, Miguel Sanchez wrote:

> However, much of the wireless interfaces (I'm particullary thinking on
> 802.11, but it is applicable for each FHSS or DSSS transceivers) are not
> exactly broadcast because you have to syncrhonyze the spreading codes
> between transmiter and receiver (or the hopping secuence). Do you mean this
> kind of interfaces will be set all to the same channel to be used on a
> MANET? (this would imply a sacrifice of the available bandwith).
> 

You're right...my comments were aimed at single-channel systems.

Usage of multi-channel wireless technologies adds additional complexity.
Dynamic code assignment and changing, adaptive power control and
other link-layer techniques have the effect of changing a device's one-hop 
connectivity to its neighbor devices in time, creating dynamic logical 
subchannels if you will within a given technology.

I don't think the WG should spend much effort right now considering this issue.
The internal technical details are link-layer issues.  The interface to the
link layer should be developed as such wireless technologies develop, 
(hopefully) wrapped by something like the GloMo Radio API, which will 
provide a standard way for the network layer (i.e. IP layer) to interface 
with these link-layer devices.  As MAC and device technologies emerge,
they will likely fall into broad categories (the first category we have
are single-channel systems with contention-based MAC protocols that we
effectively treat as Ethernets), and standard protocols for interacting 
with these categories will likely emerge as well.

-Scott

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

M. Scott Corson                                 Institute for Systems Research
[email-masked]                              A.V. Williams Bldg. (115)
Phone: 301-405-6630 (Rm. 2205 AVW)              University of Maryland     
Fax:   301-314-8586                             College Park, MD  20742

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

---

From: Chip Elliott <[email-masked]>
Date: Thu, 10 Sep 1998 09:35:21 -0400

At 12:31 PM 09/09/1998 -0400, M. Scott Corson wrote:
>...

I've been thinking this over, and tend to agree with Miguel.
It really is desirable (but not required) for a MANET protocol to
be able to use multiple channels if they are supported by the
radio. In particular, I feel it can be advantageous to use receiver-based
spreading codes (either FH or DS) to allow multiple transmissions,
in parallel, in the same radio range.

I'm not sure exactly which of our MANET protocols can do so.
The Singapore proposal can do so, I think. I know that the NTDR
and Metricom protocols can as well, though in very different ways.
On the other hand, protocols that RELY on broadcasts and
eavesdropping do not seem to have this property.

Therefore I propose that this be part of the applicability
statement. A protocol's designers should state whether their
protocol can use multiple channels in parallel, and if so, how.

What say?

-- Chip

---

From: Joe Macker <[email-masked]>
Date: Thu, 10 Sep 1998 10:48:03 -0400

>protocol can use multiple channels in parallel, and if so, how.

Chip:

As for myself,I tend to agree with you this consideration should be part of
an applicability statement. Not a requirement, just an included statement
of basic applicability on the issue.

Multiple channel wireless capabilities, when available and feasible, can be
very useful. My history in working with multi-channel, mobile networks
makes my opinion tainted .. so I'd very much like to hear what others have
to say.

-joe

---

From: Jose Garcia-Luna <[email-masked]>
Date: Thu, 10 Sep 1998 12:50:04 -0700

Chip et al:

Don't get too excited with commercial SS radios and the ability to
have multiple channels.

With DSSS, the chips per bit are too few and with near-far probs we do
not have CDMA.  I do not think we gain anything by using separate
codes for net control purposes, because we don't get CDMA with 10
chips per bit (and none of these chips is a Chip :-)

With FHSS, we only have sloooooow hopping (entire pkts per freq. hop),
plus I have not heard any radio manufacturer tell me that they can
resync in less than a pkt.  I am not too excited about what is gained
by using multiple hopping sequences in slow hopping vs using a common
hopping sequence.  The sender has to find out the hopping seq of the
receiver. After that, collisions between different sequences
(channels) can still occur, because it is slow hopping. After that,
we'd need to transmit x times the same control pkt or mcast pkt to
reach x neighbors....not good for power consumption.

If we are looking at using typical commercial 802.11 goodies, we are
looking at common channels. 

I do support Chip's applicability statement! Some vendors (e.g.,
Rooftop) will have somethign to say about it.

JJ

---

From: "M. Scott Corson" <[email-masked]>
Date: Thu, 10 Sep 1998 21:41:14 -0400 (EDT)

> Rooftop) will have somethign to say about it.

OK...so the general consensus seems to be to add it to the appl. statement,
although there's less consensus regarding it's near-term usefulness.

I've attached a modified appl. statement draft.

-Scott

MANET Routing Protocol Applicability Statement

Context:

* Please describe the intended networking context for the protocol; 
  i.e., the type of networking environment for which the protocol
  is best suited.

Characteristics:

* Does the protocol provide support for unidirectional links? (if so,
how?)

* Does the protocol require the use of tunneling? (if so, how?)

* Does the protocol require using some form of source routing? (if so,
how?)

* Does the protocol require the use of periodic messaging? (if so,
how?)

* Does the protocol require the use of reliable or sequenced packet
delivery? (if so, how?)

* Does the protocol provide support for routing through a
multi-technology routing fabric? (if so, how?)

* Does the protocol provide support for multiple hosts per router? (if
so, how?)

* Does the protocol support the IP addressing architecture? (if so,
how?)

* Does the protocol require link or neighbor status sensing (if so,
how?)

* Does the protocol have dependence on a central entity? (if so, how?)

* Does the protocol function reactively? (if so, how?)

* Does the protocol function proactively? (if so, how?)

* Does the protocol provide loop-free routing? (if so, how?)

* Does the protocol provide for sleep period operation? (if so, how?)

* Does the protocol provide some form of security? (if so, how?)

* Does the protocol provide support for utilizing multi-channel, link-layer
  technologies? (if so, how?)