Subject: AODV unidirectional link support.

From: Erik Nordström <[email-masked]>
Date: Thu, 13 Dec 2001 16:05:45 +0100 (MET)

Hello

I have got some questions about undirectional link support in AODV.

Consider the following setup illustrated below. B can hear A and C's
transmissions while there is a unidirectional link between A and C,
where only A can hear C's transmission.

     B
    /  \
  A ---- C
 
Assume that an AODV implementation with HELLO messages is used,
without any link layer support (for detecting broken links and
more...).

Section 8.9 of the draft says that when receiving a hello message an
active route entry to that neighbor should be created. Therefore A
should, due to receiving C's hello messages, have a route to C. If A
wants to communicate with C, it immediately starts to send data
directly to C, but that data will never reach its destination due to
the unidirectional link. A will never know its transmission fails...

I have not found anything in the draft (v9) that propose to solve this
problem. (Maybe I missed it?). 

Without being an expert in any way, these are my thoughts on ways to
solve this:

1.) Listen to ARP solicitation messages. If ARP fails remove the
route entry and initiate a RREQ.

Problems: A will continue to receive HELLO's from C. How do we know
that we should ignore them, and for how long?

2.) Never add neighboring route entries if not actively used
(i.e. data is sent to/via that neighbor). This will force a RREQ-RREP
phase from A where a route over B will created. This solution will
increase the AODV administrative traffic overhead compared to always
keeping "hello neighbors" in the routing table. Route lookups will also
take longer due to the need to send a RREQ.

Problems: After A initiates a RREQ for a route to C and receives a RREP
via B it should add both B and C to its routing table. The B entry is used
to detect a link break in the next hop towards C using hello messages. But
how do A know when to remove the B neighbor entry? C times out when no
data is sent over that route anymore, but A keeps on receiving HELLO's
from B and it could also be used by another route as a next hop. Clearly
there is a risk of stale neighbor entries being kept in the routing table,
which brings us back to the unidirectional link problem we are trying to
solve. Also, as A starts to send data to C over B it will still receive
HELLO messages from C, but since there is a unidirectional link there, the
HELLO messages should be ignored by A, else it will update its route to go
to C directly. But for how long should C's hellos be ignored by A? What if
the link becomes bidirectional?

3.) Use two-way hello messages. This will ensure bidirectional links,
but may severely increase the traffic load of hello messages.

Problems: Nodes will be forced to use bidirectional paths, instead of
exploiting a shorter path with one or more unidirectional links.

So what are the experts take on this problem? Have I missed something
here?

Regards,

Erik Nordström

IT-department, 
University of Uppsala, 
Sweden.