Subject: scope

From: Mathew Scott Corson <[email-masked]>
Date: Mon, 5 Feb 1996 16:13:01 -0500 (EST)

Everyone,

Regarding Joe's comment...

> 
> My initial vote is to hold off until June so that we may further
> discuss/define the focus of this effort.  I am willing to meet in LA if we
> decide it is a good thing. If we postpone until June, we can use the time
> to kick up more active technical exchange on this mailing list.
> 

...postponement is probably best in my opinion.  I'll also be in LA if 
anyone wants to meet and discuss things offline.

Regarding what Steve said...

> 
> Joel Halpern, the routing area chair, has requested that before we can start a
> working group we need to bound the scope of the problem  we will be addressing
> in the working group.  This will include:
> 
> 1. How rapid the motion can be and still expect the routing protocol to work?
> 
> < We covered several cases at Dallas including flooding>
> 
> 2. How large an area must the protocol operate over?
> 
> 3. How many nodes are expected to be in this area?
> 
> 4. What type of hierarchy will be imposed on the system?
> 
> < The Army has a specific hierarchy they wish to operate within.>
> 

...the group could use some input from people with specific numbers in mind
regarding the preceding items for particular applications.

Personally, I feel this is not the best way to specify the group's scope.
I think any numbers we come up with should be viewed as food for thought, 
but not as absolute requirements.  Routing protocol design will be driven 
by the need to operate within highly dynamic topologies over congested 
links with potentially differing link level access schemes.  The best 
(i.e. most efficient in terms of complexity) solution will be adopted 
and the numbers, which can truthfully become known only after simulation, 
will reflect our best design.  In retrospect, this will tell us whether 
the numbers were realistic or not with given technology.

I think it better if we first define our scope "qualitatively" in 
architectural terms.  This is basically the theme of the draft RFC which
was authored.  The group's preliminary charter defined a mobile mesh network
(mmnet) essentially as an ad hoc network consisting of mobile routers 
connected by wireless links, typically characterized by a dynamic topology 
and congested operation. 

At the BOF, Joe Cleveland gave a presentation on the usefulness of
flooding in this situation.  Also, Dave Johnson mentioned the possibility 
of using dynamic source routing.

I gave a presentation which:
o motivated the need for multipath routing for congestion
  avoidance in mobile networks;
o motivated the need for highly adaptive, light-weight,
  routing to quickly react to connectivity changes
o gave a preliminary set of broad design assumptions:
	- flat routing architecture (intradomain)
	- decoupling of routing and multiple access (necessary for operation
		across multiple subnetwork technologies)
	- multipath routing desired when possible
	- quick, non-optimal route construction necessary
	- limited use of flooding

Each of the three approaches mentioned at the BOF (flooding, dynamic source 
routing and highly adaptive routing) have merits and limitations with 
respect to one another in various situations.  

At present, my feeling is that a "hybrid" protocol which combines the 
best features of these three approaches may be a good solution.

Does anyone have any comments on this or other architectural issues, or 
have any specific numbers for the group's scope mentioned previously?

-Scott