Re: [Autoconf] aspects of multi-hop wireless communication

[Rex Buddenberg <[e-mail]>]

Emmanuel,  You've managed to generate a lot of discussion.  But a lot of
it is 'micro' and tends to blast past some of the macro -- just why are
we doing all this?  So let me try this: a use case from which we can
derive some requirements that places some context around.  Sense?
	This by no means invalidates your draft.

Objective: extend the internet to mobile platforms.

First, a sorting model.  In 15 years of teaching plowshares-into-swords
internet (and 20 years as a practitioner prior), I've found that all the
requirements differences fall into four categories:
	- high availability (Ao in the lingo)
	- security
	- Quality of Service control
	- reach to mobile platforms.
These categories aren't orthogonal but I've never found diffs that fall
outside them so makes a good mental checklist.  You can use it to get a
feel for priorities too -- I've had to browbeat a lot of folks who start
a discussion with QoS and immediately leap to the need for RSVP or
something similar that reintroduces state at layer 3 ... Ao is always a
trumping requirement.  

Now to a use case.  A fire engine -- it's a good example to illustrate
the interplay:
        - we want a good robust wired internet as far as it can go.  The
problems are always easier there than when radios get in the act.
(We'll assume that the fire engine's dispatching and supervisory command
are on the net).  
        - a reach to emergency services vehicles.  This is not
necessarily a 'mesh' job but one that IEEE 802.16 is well suited for.
While some automated config features are useful; they're not essential
to getting something that works.  Possible to construct mesh use cases
where one fire truck becomes a relay between a fixed POP and a second
fire truck (and yes, all the transitivity discussion can get in here).
But the mesh issues are not necessary to get real value.  
        - a WiFi splotch around the fire engine, to support several end
systems, is useful.  Again, no meshing here -- just plant an AP on the
truck.  But the thread should start to show you why you want a router on
the fire truck, not a bridge.  
        - now to the firemen working in a burning building.  Here's
where the mesh issues start to be useful.  What we want to do is
continue to extend the internet, this time from the fire truck to the
firemen in the building.  
        It is entirely practical that this network be homogeneous (e.g.
all WiFi).  And we can argue about whether the meshing should be solved
at layer 2 or 3 ... the central point in the argument is whether I can
meet 2nd principle of High Ao engineering (support multiple altroutes,
if the meshing arrangement can only be cognizant of one at a time, take
it out behind the paint locker). 
	- but we're not finished.  We've passed the stage where the fireman has
only one end system on his person (e.g. a VOIP rig).  In this particular
use case, he needs a location sensor too -- knowing where firefighters
are in a smoke-filled, blacked out building is a critical safety issue.
And he may need a PDA to see where his buddies are.  And he may have a
heat sensor to detect hot spots (which also should be exporting its
data).  So we have a LAN problem on the firefighter's person, which then
routes into the mesh that reaches to him.  

Now, gander at the sorting model and see what we can derive:
	- anyone disagree that this is a high Ao situation?  So we need
altroutes (principle 1) and we can't use protocols that ace out their
use (e.g. spanning tree)(principle 2), and we need a monitoring system
(SNMP does this) to detect failures as they occur (principle 3).  
	- security divides into two issues: 1) security of the content, a layer
7 issue which is outside of our scope here (e.g. signed e-mail).  2)
infrastructure protection security -- we don't want the neighborhood
script kiddies to get into the network while we're trying to fight a
fire (but we may want to open the door to another fire department --
don't raise this bar indiscriminately).
	- QoS is, of course, important.  Especially in radio-WANs which are
four orders of magnitude less capacious than the wired internet they're
extending from.  Diff-serve is fine; it doesn't interfere with the Ao
issues above.  Emergency services data has a much higher multicast
content than 'civilian' and once you factor in the high Ao ...
everything becomes multicast.  
	And now you have a requirements context to tackle the reach to mobile
platforms subject.  


Any help?


On Fri, 2008-12-19 at 10:19 +0100, Emmanuel Baccelli wrote:
> Hi all,
> 
> here's a draft that aims at describing important aspects of multi-hop
> wireless communication, as observed over the past decade of experience
> with such networks.
> 
> 
> The goal of this document is to identify a consensus about this topic,
> and then use this to move on quicker with the working group documents.
> 
> 
> 
> Please review it, and provide feedback as soon as possible. 
> 
> 
> http://tools.ietf.org/html/draft-baccelli-multi-hop-wireless-communication-00
> 
> 
> 
> cheers
> Emmanuel
> _______________________________________________
> Autoconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/autoconf

_______________________________________________
Autoconf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/autoconf