Subject: Re: scope of group

From: "David Blauvelt" <[email-masked]>
Date: Tue, 19 Mar 96 13:04:45 EST

______________________________ Reply Separator _________________________________
Subject: scope of group
Author:  "M. Scott Corson" <[email-masked]> at ccminet
Date:    3/18/96 3:12 PM

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 

Reliable source directed multidestination messages are more important 
to the mobile tactical user than multicast messages and they must be 
handled efficiently because of their common occurrence.

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.
  
  Impact of mobility on the operation of OSPF must be accommodated. 
  The resulting increase in network overhead traffic and routing table 
  settling time must be addressed for low bandwidth high error 
  networks.
     
Sticky issues:
     
o security

Multilevel security becomes an issue because different classification levels 
must be supported on the single net that is available to the tactical users. 
However this is something that might be delayed to a later time.

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: "David Blauvelt" <[email-masked]>
Date: Wed, 20 Mar 96 08:32:22 EST

Folks,

     

     
     
Other issues:

     
Sticky issues:
     
o security

     
     
-Scott

---

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

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

Definitely true.  One can take advantage of information available through
some standardized interface with the link layer, but one cannot make the
routing protocol's operation dependent on the functionality of some
particular link layer "implementation".  In our interface definitition,
we can define functions whereby link layers can send information to the 
routing layer, and where the routing protocol can query the link layer for 
information.  The key is that the same interface is supported across all
link layers.

-Scott