Subject: scope of group

From: "M. Scott Corson" <[email-masked]>
Date: Mon, 18 Mar 1996 15:00:12 -0500 (EST)

Folks,

In LA, several of us (John Orr from TRW, Joe Macker from NRL, Dave
Johnson from CMU and myself) got together to discuss what should be
the "scope" of the mobile mesh networking working group.

Our discussion identified that mobile mesh networking group should:
o focus primarily on "routing"
o provide an "extension" of IP routing to the mobile mesh environment

The routing solution should be "hybrid" in that it should include:
o "multipath" routing to commonly accessed destinations to facilitate 
  congestion avoidance (bandwidth is scarce in wireless nets)
o on-demand "dynamic source" routing between infrequent source-destination
  pairs to reduce routing overhead (don't maintain routes which may
  not be needed)
o "multicast" routing for efficient distribution to large receiver sets
o "flooding" only when necessary because of bandwidth inefficiency

Such a hybrid protocol poses some interesting challenges; mainly, how
to merge the various components into a seamless, hybrid protocol and
how to dynamically switch between these various aspects during operation.  

Other issues:

o routing should be "independent" of the link layer.  An API should be
  defined between the two layers.
o compatibility with RSVP should be achieved, and methods for
  "reservation-based" routing developed to avoid congestion when
  establishing QoS-based flows.

Sticky issues:

o security
o operation at the boundary/intersection of two mobile mesh nets.

Any comments/questions regarding the preceding?

-Scott

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

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

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

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 19 Mar 96 08:12:00 -0500

> o provide an "extension" of IP routing to the mobile mesh environment

This sounds fine.  Can it be phrased that we're looking for new
routing protocols appropriate for the "mobile-mesh" environment?

>   congestion avoidance (bandwidth is scarce in wireless nets)

Of course, "single path" is a degenerate case of "multipath",
so there isn't necessarily a requirement for a "hybrid" solution here.

>   pairs to reduce routing overhead (don't maintain routes which may

Other strategies besides source routing may be better.

> o "multicast" routing for efficient distribution to large receiver sets

Of course, multicast is desirable.  However, it may be so much
harder to provide that we shouldn't hold up a simpler unicast
protocol if multicast seems out of reach.

> o "flooding" only when necessary because of bandwidth inefficiency

Agreed!  One of our goals should be to make efficient use of
available bandwidth, so that we reduce as much as possible the
need for flooding.

> how to dynamically switch between these various aspects during operation.  

As suggested, perhaps a hybrid protocol isn't needed for
the above requirements.

>   defined between the two layers.

If it's a routing protocol, an API may not be needed.  Besides,
the IETF "doesn't do" APIs.

>   establishing QoS-based flows.

As above, I stronly suggest that we do basic unicast routing
first and then see if the result is appropriate for RSVP.

> o security

Security is always sticky.  But if we assume manual distribution
of a symmetric or group key, we can use the same authentication
and/or privacy mechanisms already being implemented elsewhere.
Do we really need to get into the key distribution problem yet?

> o operation at the boundary/intersection of two mobile mesh nets.

This is indeed a problem.

> Any comments/questions regarding the preceding?

I'd like to suggest discussion on the appropriateness of
"mobile mesh" as a name for the working group.  "Ad-hoc"
networking is something I'm more used to, and for multiple reasons
seems more natural to me.  A "mesh" is a somewhat more "regular"
kind of connectivity than what I'm imagining, and seems to imply
more permanence of the links than "ad-hoc" implies.  Another candidate
might be "instant infrastructure", although that term seems a little
grandiose to me.

> -Scott

Charlie P.

---

From: "Ronald N. Orr" <[email-masked]>
Date: Wed, 20 Mar 1996 12:00:05 -0800

>   defined between the two layers.

"independence" may be expensive in terms of bandwidth if you limit 
yourself to not using link information developed at lower levels.

>   establishing QoS-based flows.

Can this be ignored in an initial protocol version if you make the
assumption that security will be enforced at the link level?

> Any comments/questions regarding the preceding?

As to a name other than "mobile mesh". The Army uses "tactical internet".
 
> -Scott

As you probably noice, my interests are more parochial. We (Army
digitalization office, TRW, Hughes, ITT, et al.) are going to have
to come up with a workable routing protocol to replace a kludge of
static and OSPF routing which we will use for a 1200 node tactical 
internet field exercise early next year.

When the inadequacies of the above approach become all too clear,
there should be monies available for this working group or somebody
very much like it to develop and test the protocol really needed.

Ron
-- 
Ronald N. Orr, TRW SEDD, PO Box 3099, Manhattan Beach CA 90266-1099
voice: (310)764-9138 fax:(310)764-9094, [email-masked]

---

From: "M. Scott Corson" <[email-masked]>
Date: Thu, 21 Mar 1996 16:32:31 -0500 (EST)

> routing protocols appropriate for the "mobile-mesh" environment?

Ok, hows this.

Our discussion identified that mobile mesh networking should:
o focus primarily on "routing"
o develop routing protocols appropriate for the "mobile-mesh" environment,
  thus extending IP connectivity into the mobile network.

> so there isn't necessarily a requirement for a "hybrid" solution here.

I understand.

I mean "hybrid" in terms of the potential usage of either multipath routing, 
source-directed routing, flooding and multicast routing as appropriate within
the scope of a single protocol (these are subprotocols to be used depending
on the destination, set of destinations or dynamic state of the network).

> Other strategies besides source routing may be better.

Agreed.

> protocol if multicast seems out of reach.

I don't think so.  In fact, I envision a fairly straightforward way 
of piggybacking multicast routing on the reverse path information of a 
multipath protocol.

> the IETF "doesn't do" APIs.

Wrong term I guess.  Some sort of boundary/service specification is needed.

> first and then see if the result is appropriate for RSVP.

I agree - sort of.  

We should stick to routing at first, but it need not simply be unicast, and
we will need ways to "route around" congestion.

> might be "instant infrastructure", although that term seems a little

I took the term "mesh" largely from graph theory, where a mesh topology
is generally known to be any unstructured, random graph.  There was also
an interesting survey article in The Economist last Summer referring to
military communication nets of the future.  The basic notion was one of 
"disperse or perish" saying that, in future wars, large targets would be very
vulnerable and quickly destroyed.  Thus, to survive, an effective force 
would consist of many small, highly mobile entities connected via, you
guessed it, a "mobile mesh network".  Perhaps it's not the most appropriate
name, but I kind of like it based on that description - and it does follow
from graph theory.  "Ad hoc" somehow says more (regarding the random nature of 
the network's construction) and less (regarding the nature of the
network's topology) at the same time.  I dunno.

-Scott