Subject: More AODV draft issues

From: Erik Nordström <[email-masked]>
Date: 01 Nov 2001 00:00:28 +0100

Hi.

I'm back again with more questions about the AODV draft.

Active routes
=============
First, there are some inconsistencies about what an ACTIVE route is: 

In section 3. an active route is a routing entry with finite hop count.

Meanwhile, section 8.8. implies that an ACTIVE route (or next hop) is a
route where packets has been forwarded within the last
ACTIVE_ROUTE_TIMEOUT milliseconds.

This may seem like a trivial point since most routes fulfill both
definitions most of the times. But if you use hello messages, a next hop
may not have forwarded any data packets at all, but being ACTIVE
according to the AODV terminology in section 3.

Section 8.9. in turn say that a RERR should be initiated whenever a link
break occurs for a next hop of an active route. If detected by the
absence of hello messages, we may send a RERR for a route/destination
which no one use, and that seems a bit unnecessary. One way to prevent
this would be to check if you actually have any precursors for that
route. If not, don't send a RERR.

comments?

Broadcast address
=================
Also, why is a broadcast address of 255.255.255.255 used with AODV? This
is generally just used for protocols such as bootp, because the proper
broadcast address is not known during boot. Is it used to be able to
reach hosts that don't share the same type of network address?

The problem with the 255.255.255.255 address is that depending on OS, it
may broadcast on all network interfaces or just the first one. On Linux
for example, it only broadcasts on the first interface. This prevents me
from running AODV on my computer at home, where my WaveLAN card is on
eth1. Even if it would broadcasts on all interfaces, I might not want
that, if my other interfaces are not connected to a "AODV network".

Liftime of routes
=================
When intermediate nodes send route replies to a requesting node, it may
send a ridiculously small lifetime for that route (expire time - current
time) depending on situation, i.e. route is about to expire. Is this
something you want? I could imagine that links along the forward route
that are setup while the RREP makes it back to the requesting node may
expire almost instantly so that the forward route doesn't exists anymore
once it is about to be used. We have experienced issues we believe are
related to this when testing our implementation, though I can't for sure
say that it wasn't due to other bugs ;-). As a temporary solution we
tried to always send back ACTIVE_ROUTE_TIMEOUT and that seemed to solve
the problem.
I almost assume I am missing something here... Could someone clearify
this for me?

Finally, in response to Dan Iregren's previous question about the loop
scenario, here is what I find:

In the last steps of the scenario node [c] sends a RREQ for a route to
[d]. If received and responded to by [a], the RREQ must have gone
through [b], and [b] would then have set up a reverse route to [c], the
RREQ originator. Not [d] as described in the scenario. And during the
RREP phase, [b] sets up a forward route to [a]. So, a loop would not
form.

This is my interpretation, but maybe I missed something?

regards,

Erik Nordström