Subject: Re[2]: MANET Addressing Architecture

From: [email-masked] (Stuart Hamer (United Kingdom))
Date: Thu, 3 Sep 1998 16:37:53 -0400

This sounds rather like a two tier architecture to me. Why don't we just call 
 them cluster heads and cluster members.
 
 Stuart.

______________________________ Reply Separator _________________________________
Subject: Re: MANET Addressing Architecture 
Author:  "M. Scott Corson" <[email-masked]> at Internet_Gateway
Date:    9/2/98 4:28 PM
 
> 
> So, perhaps what is needed is a dynamic means for simple hosts to become 
> routers when the MANET is router-scarce and for routers to revert back to 
> being simple hosts when the MANET is router-rich?
> 
 
Yes.  I think this is essentially where this discussion is headed...rather 
interesting actually.
 
A host-like device can become a MANET router *when necessary* 
(when it is alone), but when it affiliates with another MANET router, 
it suppresses its router behavior and reverts to being a simple host.  
This could be part of the IGMP-like affiliation protocol where it is 
decided which becomes a host, and which continues being a router.
 
Kind of cool....this could supported by the general addressing architecture.
 
-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
 
*******************************************************************************

Received: from cecom10.monmouth.army.mil (134.80.0.10) by
doim6.monmouth.army.mil with SMTP
  (IMA Internet Exchange 2.1 (Gold Candidate) Enterprise) id 000B2B17; Wed, 2
Sep 98 16:41:10 -0400
[128.8.110.117])
	by mintaka.isr.umd.edu (8.9.0.Beta6/8.8.7) with ESMTP id QAA16565;
	Wed, 2 Sep 1998 16:28:38 -0400 (EDT)
Received: from localhost by manet.isr.umd.edu (8.9.0.Beta6/8.8.7) with SMTP id
QAA25316;
	Wed, 2 Sep 1998 16:28:19 -0400 (EDT)
X-Authentication-Warning: manet.isr.umd.edu: corson owned process doing -bs
Date: Wed, 2 Sep 1998 16:28:18 -0400 (EDT)
From: "M. Scott Corson" <[email-masked]>
X-Sender: [email-masked]
Reply-To: "M. Scott Corson" <[email-masked]>
To: "Fred L. Templin" <[email-masked]>
cc: MANET WG <[email-masked]>
Subject: Re: MANET Addressing Architecture 
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email-masked]
Precedence: bulk

---

From: Stefano Basagni <[email-masked]>
Date: Thu, 3 Sep 1998 17:04:05 -0500 (CDT)

>  them cluster heads and cluster members.

  That is exactly the same impression that I had by reading Scott's
writeup. (One of) The "definition" that I have always found for these
networks is that each node is willing to forward packets for other
nodes that can't communicate directly with each other, i.e., each node
is also a router. It seems to me that most of the routing algorithm
proposed so far assume this "flat" organization.

  If we want to see some nodes more "powerful" (or with more/different
duties) than others nodes, then clutering is what comes to (my) mind
...

  St.

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 03 Sep 1998 17:32:52 -0700

> proposed so far assume this "flat" organization.

Perhaps a different twist on this is that each node within the "flat"
address space could also behave as a BRIDGE (in the spirit of IEEE 802.1d
MAC-level bridging) rather than a router. The concept of MAC-level bridging
was designed for the very purpose of building up a flat network in which not 
all nodes are connected to the same broadcast media. (Analagous to a
fragmented datalink-level connectivity graph within a MANET.) Bridging
relies much more on PASSIVE topology discovery as opposed to ACTIVE routing
exchanges. There is still the bridge spanning tree algorithm overhead to
consider, and I really don't have a feel for how bad this can get within
a MANET. But perhaps it should be considered as an alternative to
"datalink-level routing" for multi-hop?

> duties) than others nodes, then clutering is what comes to (my) mind

I'm not too familiar with clustering terminology, but I think I can see
the point of view. The only distinction is that MANET clusters might need
to re-organize frequently, with members (and possibly even the cluster head
itself) dynamically joining and leaving. So there would need to be a way
to elect new cluster heads when there aren't any around and demote
redundant cluster heads when there are too many...

Fred
[email-masked]

---

From: "M. Scott Corson" <[email-masked]>
Date: Fri, 4 Sep 1998 15:12:09 -0400 (EDT)

> duties) than others nodes, then clutering is what comes to (my) mind

The comments to which you are referring come from a side discussion 
that Fred originated...whethers routers morph to hosts, or hosts morph to
routers, or routers cluster together, or whatever...it's all rather
orthogonal to the original note, and strays from my point that the 
working group should adopt an addressing architecture that is 
sufficiently *flexible* to support future MANETs.

At the moment, a sufficient architecture appears to be one that
supports the following:

* multiple hosts per router

* multiple wireless technologies

* interoperability (via adherence to the IP addressing architecture)

I'm not suggesting *what* people do with such architecture, in the short
or long term.  

Supporting this general architecture simply requires: 

* identifying router and host interfaces with IP addresses 

* identifying a router with a separate Router ID (RID)

This is essentially the practice in the fixed network, and appears to
be sufficient for building a mobile infrastructure as well.

-Scott

---

From: "Fred L. Templin" <[email-masked]>
Date: Fri, 04 Sep 1998 16:19:33 -0700

Scott,

> be sufficient for building a mobile infrastructure as well.

Did you mean to imply by this that there is an analogy to the Router ID
(RID) in the fixed infrastructure? Are you thinking in terms of something
like a BGP4 Autonomous System number, or am I simply reading too much into
your message? I was under the impression that the RID was a new concept
introduced by IMEP.

Thanks,

Fred
[email-masked]

---

From: Joel Halpern <[email-masked]>
Date: Fri, 4 Sep 1998 19:39:48 -0400 (EDT)

> your message? I was under the impression that the RID was a new concept

I can't speak for Scott, but if you go look in OSPF, you will find that
under some circumstances it uses RouterIDs.  In particular, it uses
RouterIDs when there is no appropriate interface IP address.  In the
current environment, that occurs when there are unnumbered point-to-point
links.  
One way of looking at the inter-router links in MANET is that they are
unnumbered links (since assigning IP addresses to links which appear and
disappear frequently would be rather unpleasant).
It is not the only way to look at it, but it is one reasonable way.

Yours,
Joel M. Halpern                         [email-masked]
Newbridge Networks Inc.

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 08 Sep 1998 09:43:57 -0700

One other thought about the MANET addressing; it seems to me that there
may be some unspoken assumptions about what goes on at the datalink and
physical levels. At the physical level, it seems to me that many of the
MANET documents assume that wireless interfaces will have omni-directional
antennas with the capability of "hearing" other nodes operating at the
same frequency (with the same spreading/hopping pattern) and within
transmission range of one another; in other words, a broadcast-oriented
topology instead of point-to-point. This also implies a dynamic membership
join/leave as new nodes come into range and others leave due to mobility,
fading, etc. This in turn would imply that nodes need to be uniquely 
addressable at the datalink level since there is no way of telling a priori
which nodes might come in contact with one another. So, I think an addressing 
architecture discussion should also consider the entire
hierarchy of addresses from the physical layer up. Is there an unspoken
concensus in the group as to addressing at the datalink/physical levels?

Fred
[email-masked]

---

From: "M. Scott Corson" <[email-masked]>
Date: Tue, 8 Sep 1998 15:08:31 -0400 (EDT)

> your message? I was under the impression that the RID was a new concept

I do not think the idea is new.  As Joel suggests,
the following definition comes from RFC 2328 (OSPF Version 2).

Router ID
            A 32-bit number assigned to each router running the OSPF
            protocol.  This number uniquely identifies the router within
            an Autonomous System.

However, part of the *rationale* for using a RID in MANET routing may be new.
The RID is key to the concept of routing through a wireless routing *fabric*.

When multiple wireless technologies are available in a MANET,
it is technically desirable that routing occur at the IP layer
(as opposed to the subnetwork layer) for the following reasons.  
Consider a MANET where each node consists of a mobile router with 
two *different* wireless devices (technologies A and B) attached.  
In general, the wireless connectivity and, hence, the network topology 
corresponding to each wireless technology will be different.  
Thus, adjacent nodes may be connected by one or both technologies.  
Using subnetworked-based routing, a packet must be routed within
the topology defined by a given technology.
By routing at the IP layer, it is possible to
flexibly, efficiently and robustly forward a packet through the
wireless ``fabric" consisting of the *logical union* of the
topologies of the individual wireless technologies.

In other words, a packet may initially be routed via wireless technology A 
for several hops, and then switched to technology B on subsequent hops,
because either more capacity is available there, or because no connectivity 
exists in technology A's topology, and possibly then switched back to 
technology A.  There are no restrictions regarding the number of such
technology transitions a packet may undergo as it traces a path through
the network. In single-technology (i.e. ``subnet-based")
routing, lack of connectivity in topology A would either have caused
the packet to be dropped, or its restriction to the slower technology
A would have resulted in higher end-to-end latency. Thus, it can be
seen that the ability to dynamically route mixing *multiple* wireless
technologies (by routing through the wireless fabric) gives added
power and flexibility to the routing and forwarding algorithms,
including more robustness to topological changes and potentially higher
performance as well.  DSR was recently (March 98) enhanced to support
multi-technology routing.

This concept was first presented at the Dec. 97 IETF meeting, and has
been described and motivated in more detail in a quarterly article series 
Joe and I are contributing to the ACM Mobile Computing and Communication 
Review.  The series chronicles the work of the MANET WG, and also gives 
rationale for the architectural approach being followed.

We have not specified what the RID is, how long it is, how it is assigned
or updated, etc.. This is a routing/addressing policy-specific issue.
It may be a flat 8-bit identifier for use in small networks, or it may be
a larger, dynamically-renumbered quantity encoding router identities
and interrelationships.  For example, the RID could consist of
a (clusterheadID,clustermemberID) pair identifying a router with its
clusterhead in a two-level clustering approach.
The RID is not intended to be visible outside the network layer
(i.e. to transport and above).

-Scott

---

From: "M. Scott Corson" <[email-masked]>
Date: Tue, 8 Sep 1998 15:28:01 -0400 (EDT)

> concensus in the group as to addressing at the datalink/physical levels?

Fred,

It's pretty well understood that in broadcast networks, link-layer devices
will be set to listen for broadcast or multicast addresses, which pretty
much removes the need for individual link-layer addressability 
(they all hear the transmissions anyway) from the perspective of IP layer 
processing.  Higher layer processing can throw away unneeded received 
traffic.

-Scott

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 08 Sep 1998 13:41:27 -0700

Scott,

> processing.  Higher layer processing can throw away unneeded received 

So, I am right in that an underlying assumption for MANET is a multiple-
access, broadcast-capable domain with the possibility of dynamic join and
leave for participant nodes? Then, from what you've said here, *another*
unspoken assumption of which I was previously unaware is that all messages
will be sent to a link-layer broadcast or multicast address (or, perhaps,
no link-level address at all) and it will be up to the network (IP) layer to 
discard packets not intended for that node. Is this what you had in
mind?

This is OK (because, as you've observed, everything is broadcast to all
nodes within earshot anyway), but it pushes the requirement for being able
to uniquely address each node from the traditional datalink level (with
"burned-in" IEEE 802 addresses, for example) up to the network (IP) level. So 
the challenge now becomes how to ensure uniqueness for IP addresses
within a MANET. Is it your feeling that each node should have a
pre-configured IP address which will be guaranteed unique from those of
the other nodes within the set of all MANETs a node may visit? Or, do you
think nodes should be "amnesiacs" and only learn their IP addresses once
they've joined a particular MANET? If the latter, then how can such an
"amnesiac" node transition session state when it moves from one MANET to
another?

Thanks,

Fred
[email-masked]

---

From: Chip Elliott <[email-masked]>
Date: Tue, 08 Sep 1998 17:15:24 -0400

The link layer has a fairly important vote in exactly
what kinds of links are supported, and whether or not nodes
have link-level addresses.

It seems to me that the earliest packet radio networks
had some pretty bad performance problems due to the
"Hidden Terminal" problem, which is in simplified form:

   A is in range of B, which is in range of C, but A and C
   cannot hear each other. Now packets from A and C to B
   will step on each other, so B will have poor performance.

Today's usual solution to the Hidden Terminal problem is
a MACA-like waveform, ie, a 4-way handshake involving
an RTS (request to send), CTS (clear to send), data frame,
and frame ACK.

This waveform imposes constraints on the upper layers:

1. It only works on bidirectional links.
2. It requires the upper layers to have netwide unique MAC addresses.
3. It does not support broadcast or multicast.

Point 3 is especially important: those systems that RELY on
all nodes broadcasting (for normal packet forwarding, eg) WILL
suffer from the Hidden Terminal problem.

Thus it seems we have a basic choice:

a) Use a unicast MACA style system at the link level, eg, 802.11
b) or broadcast and suffer from the Hidden Terminal problem

Note that one can use modern 802.11 radios with either the
MACA waveform (unicast), or broadcast, so our networks
could take either of these choices -- or a judicious mix of
both features, such as using broadcasts for beacons and routing
updates, but unicast for message forwarding.

-- Chip

---

From: Jose Garcia-Luna <[email-masked]>
Date: Tue, 08 Sep 1998 15:37:48 -0700

Chip:

I quite agree with your note, except that I'd encourgae MANET people
to look beyond 802.11 and address MAC-level protocols that support
multicast transmissions, to think about what it means to have
unidirectional links at the MAC layer, and to exploit the neighbor
information provided at the MAC layer. 

Unless that is done, talking about a routing protocol sending fewer
HELLOs than another protocol or talking about a routing protocol
operating with unidirectional links is only interesting as an academic
exercise, because in practice HELLOs should not be needed (in most
cases) and---if we want to remedy h-t problems to some degree--we only
have bidirectional links with p-t-p MAC protocols commercially
available today. I do not think we can live with the comemrcial
solution to broadcast, which is ALOHA (carrier sensing does not work
with h.t. and there is no true carrier sensing in commercial
radios).....I think once we stare at the problem long enough, we'll
end up with a MAC protocol that resembles TDMA in some ways.

As for all these references to "MACA" I keep hearing, I'd like to give
due credit to Kleinrock and Tobagi, who were the first to propose the
"RTS-CTS" like handshake. The protocol was called SRMA (part III of
the pkt switching in radio channels papers, Trans Comm, 78, Vol 24, No 8,
pp 832-845, or read Tobagi's ucla thesis). MACA amounts to a
single-channel SRMA using ALOHA to send RTSs.

JJ

---

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

> end up with a MAC protocol that resembles TDMA in some ways.

Agreed...a protocol we presented at INFOCOM 98 may be a step in that 
direction, but if so, it is premised on the ability to do *efficient*
(i.e. very fast) collision detection in multihop, TDMA-based spread 
spectrum systems, something which may not yet be feasible.
(If it is already....someone please let me know. ;-)

I think topology-dependent TDMA scheduling is the way to go.

Hopefully...protocols like this will soon become available...at present,
the WG is stuck with what it can buy.

-Scott

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 09 Sep 1998 10:49:18 -0700

Scott,
 
> the WG is stuck with what it can buy.

In the wired world, there are lots of RFC's that tell how to run
IP atop various datalink protocols (e.g. RFC 1042: Standard for the
transmission of IP datagrams over IEEE 802 networks). Perhaps there is
a need for something along these lines for MANET, e.g. "The operation
of MANETs over IEEE 802.11 networks". It's great to have all of this
routing work going on, but at some point you need to look at how the
"rubber meets the road".

Regards,

Fred
[email-masked]

---

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

> routing work going on, but at some point you need to look at how the

Sure...but for this sort of thing to occur, we first need to agree on
standardized approach for the MANET stuff, otherwise there is nothing
for the link-layer stuff to interface with...that's one reason I'm 
suggesting we come to a common understanding regarding basic issues
such as host and router identification in MANETs.

-Scott

---

From: Joe Macker <[email-masked]>
Date: Wed, 09 Sep 1998 14:46:29 -0400

>routing work going on, but at some point you need to look at how the
Fred:

Yes, at a certain level of maturity such documents should occur.  It can
help to agree first at a higher layer on the level of flexible
functionality to be provided by a routing layer interface.... then specific
link layer issues can be worked on overtime.  If the initial interface
framework defined is flexible (somewhat technology independent) this can be
less painful than otherwise, but there certainly is some interplay between
what is decided there and what goes on across different link layers.  

There is additional historical IETF precedence for your suggestion.
Consider the intserv, rsvp, and issll WGs and their relationships.  In this
case, different WGs took on different responsibility roles and problem
focus while working closely together.  ISSLL focuses on specific link layer
interface and functional mapping issues.  Much of ISSLL's work required a
certain amount of maturity in upper layer specifications (i.e., rsvp and
intserv).

-joe

---

From: Ram Ramanathan <[email-masked]>
Date: Wed, 09 Sep 1998 15:26:23 -0400

> Date: Wed, 9 Sep 1998 14:10:37 -0400 (EDT)
> cc: Jose Garcia-Luna <[email-masked]>, MANET WG <[email-masked]>
> Subject: Re: Hidden Terminals (Addressing, Unidirectional links)
> In-Reply-To: <[email-masked]>
> Message-ID: <[email-masked]>
> MIME-Version: 1.0

This discussion reminds me of the light-bulb joke : "How many software
engineers does it take to change a light bulb"? Answer "None, it is a
hardware problem".

More seriously though, the more I work in this field, the more I feel
that the layering approach that was so useful in the wired world may
not really fly in the mobile wireless world (I mean in practice, everything 
works on paper). While the main villian is the channel access, there is
so much need to pass information across layers (punch holes in the layers)
that the stack soon looks more like a honeycomb. JJ mentioned the acquisition
of neighbor information using the MAC layer itself. And I might want to
control my local neighborhood by adjusting xmit power...

Different routing protocols may work best with different MAC layers. One
approach, as you say, is choose one solution at the network layer and then
worry about which MAC layer suits it best. However, if am not interested
in standards or layering or IETF and simply want to get the best possible
mobile wireless system, I would rather choose the best routing-channel access
*combination*.

As part of GloMo Multimedia Support for Mobile Wireless Networks (MMWN),
we did some work on routing algorithms at the network layer, and hoped
that the "right MAC layer would come along by the time we are done and
we would be all set" (similar to MANET?). Well, all we needed was a MAC 
layer that does efficient multicast, provides reserved access for QoS 
support, is simple, doesn't have too much overhead, tolerates hidden 
terminals and works with unidirectional links! We are still waiting. 
For the hardware engineer to fix the light bulb. Any takers? :)

-Ram.

---

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

> For the hardware engineer to fix the light bulb. Any takers? :)

No kidding...the strictly-layered approach followed in the fixed network
worked well, but I do not think that is the way to go here, principally
due to the different *nature* of the mobile multihop system constraints.

Fixed Network Constraints: Router Processing and Storage

MANET/MMWN Constraints: Channel Bandwidth (and possibly Router Energy)

Joe and I commented in a recent MC2R article (July 98) that while 
the protocol design philosophy of the fixed network was to burn bandwidth
to save router resources, the opposite approach is needed for MANETs as
communication eats up both channel capacity and router energy.
This essentially requires a protocol architecture that increases
vertical coupling and communication between layers to reduce horizontal 
communication across peer protocol layers thus saving bandwidth and energy.

Does this mean that we must resort to stovepipe systems?  

We don't think so, otherwise there would be little point to the working group.
Cramming all functionality into a single protocol has flexibility nearly
equivalent to that of a stovepipe system.  Separate protocol layers are 
still required (for architectural flexibility),
but the protocols must communicate via rich interfaces permitting
sufficient information exchange to eliminate horizontal communication 
redundancy (for system efficiency).

Hence, the approach espoused by IMEP, TORA, OLSR and LAM.

        (multicast)      LAM
                          |
        (unicast)        TORA  OLSR
                            |  |
   (link sensing, etc.)     IMEP
                             |
 (addr arch., frag., etc.)  IP

IMEP does lower-level network things (just above the link layer).
TORA provides unicast routing in certain networking contexts, but usage
of IMEP means that TORA can be *replaced* by other protocols using IMEP
such as OLSR better-suited for contexts for which TORA is ill-suited.
LAM provides multicast routing atop TORA, but again other protocols could
efficiently be layered atop TORA to provide multicast in a different way.

So...it makes use of the notion of extended rich interfaces to permit an
increased vertical coupling while still permitting policy flexibility
across differing networking contexts.  Protocol designers can develop
protocols for different layers and services, and others can choose to use
these layers (or not) depending on their merits.

The intent is for this approach to be continued down towards the interface
with the link layer, coupling IMEP (or some other equivalent mechanism)
to a radio API in a standard fashion.

It's something between a stovepipe and the current Internet, 
as we think it needs to be for efficiency and economics.

-Scott

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 09 Sep 1998 14:02:31 -0700

Scott,

> such as host and router identification in MANETs.

The two key pieces of information you might wish to glean from a node's
address are it's location (i.e. where it currently exists within the global
Internet routing framework) and it's identity (i.e. a way to uniquely
differentiate it from all other nodes). In the traditional Internet model, addressing is hierarchical; the datalink address gives the node's identity
while the IP(v4) address gives it's location, and there is a binding
protocol (ARP) to associate the two addresses. So, an IPv4 address on
it's own is really insufficient for host and router identification.

You might be able to statically assign an arbitrary-length IPv4 network
prefix (e.g. 128.129.130/24) as a router's ID, but then you really can't
allow simple hosts to dynamically associate/disassociate with the router
(due to mobility) unless the router has some way to dynamically allocate
them addresses out of the 128.129.130/24 address space. I believe this
brings us back to the need for a way to uniquely differentiate nodes;
whether it be through 802-style datalink addresses or some other way
that hasn't been mentioned yet. Otherwise, how could dynamic IP address
allocation be managed? In short, I don't think it's possible to consider
the MANET addressing in isolation from the underling datalink/physical
levels without spelling out the assumptions being made.

Thanks,

Fred
[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 09 Sep 1998 15:19:13 -0700

Ram,

> not really fly in the mobile wireless world

I agree with this; I definitely don't feel there is anything sacred with
regards to the OSI reference model as far as practical implementation is
concerned. I do feel that it can still serve as a useful reference point 
for discussion, however.

Thanks,

Fred
[email-masked]

---

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

Fred,

As I understand it, the datalink address has no network-level significance.

ARP determines a temporary binding between an IP address (network-level
significant) and a link-level identifier for purposes of link-level
reception filtering on a given subnet.  IPv4 mixes the notions of 
network-level identity and location by encoding both in the same number,
a host's home address.  Mobile IP is one approach for distinguishing between
them where, in one mode, a node's network-level *identity* becomes its 
home address (while on the road) and its *location* in the network is
its care-of address.

> levels without spelling out the assumptions being made.

Interoperability with link-layers such as 802.11 may entail certain
functionality, including some form of ARP-like link identifier exchange
between nodes that bump into one another.  This would be part of an
interface spec that needs to be written for a given link layer.

As Joe indicated earlier, specs are commonly written for the network-layer 
to interoperate with certain link layers.  Such a spec would be 
useful for 802.11, enabling various network-layer protocols (such as IMEP) 
to glean useful information from a given link layer, thereby
allowing them to reduce or eliminate unnecessary signaling overhead over
their 802.11 interfaces.  The network-level assumptions and connection 
signalling mechanisms currently spec'ed in IMEP are necessary to 
enable operation over a generic link layer from which no such information 
can be obtained (such link layers commonly employing some form of
CSMA/CA exist today).  IMEP is modular, and is intended to be modified 
to operate efficiency on interfaces for which such link-layer-specific
information is available.  I encourage anyone interested to submit an
MANET/802.11 interface spec draft.

Still (taking the datalink identifiers out of the picture),
the issue of network-layer identification of hosts and routers is very
important.  My comment last week suggested a way to *structure* the
identification process, but did not specify *how* to assign the 
identifiers.  That is policy-specific, and is an active research topic.

-Scott