RE: [manet] DYMO and other routing protocols

["Mullen, John" <jomullen at ad.nmsu.edu>]

I've been lurking on current topics and agree with most comments.
Nevertheless, I decided to peep up.

I think, in the end, at the least there will be a common framework for a
MANET routing protocol which employs a mix of strategies. A proactive
protocol has its advantages, but is not practical for very large
networks, due to the fact that the status of a wireless link is often
not easily determined and that it takes time for updates to propagate.
At some point, few, if any, nodes in the network will have an accurate
set of tables and no node will be sure that the data it has is accurate.
On top of that, you have bandwidth being used to propagate routing
information that may never be used.

On the other hand, while on-demand protocols address these issues, there
is an initial latency for establishing a new route. In addition,
bandwidth is consumed in searches and nodes are not much more confident
in their data. 

In the "real" world, MANETS differ greatly in a number of features,
including node density, propagation characteristics, traffic patterns
and intensity, etc. In addition, one can expect MANETs to be
heterogeneous. There may be a few clusters of nodes in an otherwise
sparse network, much like the manner in which human population is
distributed. Propagation conditions may vary within the range of the
network. Traffic patterns and intensity may change drastically from time
to time.

While Hello messages can be useful, I think we have to be careful. For
several reasons, they can be reliably received over significantly
greater distances than data packets. I do think they should be used, but
not without some independent assessment of the ability of the connection
to transfer data.

I suspect that in the end, the design will be to have a table-driven
proactive mode for nearby nodes and an on-demand mode for the long haul.
It should be relatively easy for nodes to maintain tables of one-hop
neighbors and two-hop is not that much more difficult. Clustering is a
possible approach here, as well, though it does require a bit more
sophistication. If there are also shared records of current long-haul
routes, the combination can reduce the time and bandwidth needed to find
or repair a route. 

It took a long time for people to work out the nasty details for radio
communications and in the beginning, operators relied on a few basic
controls and their skill. Now, we know enough to reliably handle that
mess through hardware and software. A basic MANET protocol in which
different features can be "tweaked," either manually or through
algorithms, would provide a sound basis on which to study the messier
problems and, over time, find good solutions. That is, a common protocol
would provide a common framework in which to conduct experiments and
report results in a manner that all involved could understand and
evaluate. Establishing that common protocol would be a giant step in the
direction we all want to go.

Bye for now,

John P. Mullen, Ph.D.
(505) 646-2958
jomullen at nmsu.edu
 
-----Original Message-----
From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove at baesystems.com] 
Sent: Friday, June 08, 2007 6:47 AM
To: Alexandru Petrescu; Philippe Jacquet
Cc: manet at ietf.org
Subject: RE: [manet] DYMO and other routing protocols


> OLSRv2 document says it's proactive but I think an OLSRv2
implementation
> must be able to obtain a route if it receives a app packet whose dst
it
> doesn't know, and if it doesn't have a default route.

Not in that way.

Using the protocol as to be standardised, if an OLSR (v1 or v2) node
receives a packet from destination it doesn't know, it does nothing
to find that route.

There is allowed to be responsiveness (a term we use as say
reactiveness would be confusing) in the protocol at the signalling
level. If an OLSR (v1 or v2) node receives a HELLO message containing
information about a neighbour it's never heard of, it doesn't
have to maintain its current fixed schedule to send a HELLO
message containing this extra information, but can do so early.
This will accelerate what you want here, and may even look reactive.
But it's more than just subtly different. A node that wants to
find node X can't make that happen, it has to wait for node X to
inform it (directly or, more usually, via other nodes).

> Similary, DYMO says it's on-demand but it should advertise RREP (or
> RREQs) periodically if it needs to maintain up to date information at
> all times.

But maintaining up to date information about all destinations at all
times is not necessarily desirable. (Talk to 6LoWPAN people about this,
for example.)

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************



_______________________________________________
manet mailing list
manet at ietf.org
https://www1.ietf.org/mailman/listinfo/manet


_______________________________________________
manet mailing list
manet at ietf.org
https://www1.ietf.org/mailman/listinfo/manet