Subject: local connectivity information in DSR and AODV

From: "Chih-fan Hsin" <[email-masked]>
Date: Mon, 9 Jul 2001 14:51:17 -0300

I want to implement DSR and AODV.
There are some things about which I am not clear. I am not sure if the following understanding is correct.
In AODV, the neighbor connectivity information is obtained by periodic hello packets. However, in DSR, that information is obtained by the link layer.
How does DSR get that information from the link layer? Does it need any extra link layer packets?
Could anyone give me a hand?

Thanks,
Charles

---

From: Aaditeshwar Seth <[email-masked]>
Date: Tue, 10 Jul 2001 06:16:50 +0800 (SGT)

Hi Charles,

Getting link-layer feedback on local connectivity is easy in something
like a 802.11 MAC, which uses the RTS/CTS/DATA/ACK mechanism for
transmission. If a RTS is not followed by a CTS, or DATA not followed by
an ACK, it essentially implies that something is wrong with the
bidirectionality of the link - either the link has become one-way only
now, or it has completely broken down.
However, you will realise that this kind of a feedback is on-demand in
nature - only when a node has something to transmit to another node, does
it get aware of a possible link-faliure. HELLO messages on the other-hand,
provide something like a proactive link-faliure detection.

Coming back to your question, AODV assumes all links to be bidirectional.
Infact, although it does not make any use of any unidirectional links
that might exist, it still has to specifically maintain a `blank-list'
(refer to the AODV draft) in order to avoid lots of misunderstandings.
Therefore, AODV is able to detect link-faliures both by the HELLO
mechanism and also by the MAC-callbacks - it is just a performance
issue whether to incur the additional HELLO cost and obtain proactive
knowledge, or just manage with ondemand knowledge.
DSR on the other hand does not rely on any kind of periodic beacons like
HELLOs, and is completely ondemand in nature. Unlike AODV, it is capable
of including unidirectional links along routes too, and therefore it can
use the MAC-callback feature over bidirectional links only. The DSR-draft
says that a special type of software DSR-ACK can be used to ensure
reliable delivery over unidirectional links, and this DSR-ACK can travel
back from a next-hop node to a previous-hop node along some different
path.

Ofcourse, apart from the RTS/CTS mechnism generating callbacks, etc, other
mechanisms can also be used at the link-layer. For example, passively
listening to the interface, or maybe building a similar HELLO mechanism at
the link-layer itself.

Finally, I would add in a few comments of my own too. In the case of
unidirectional links existing with DSR - how does DSR figure out whether
a link is unidirectional or bidirectional? If the normal flow of sequence
of a route-discovery is followed, then it is always possible to establish
routes that consist of unidirectional links inbetween. In this case, both
the ARP problem that I mentioned in a previous mail, and the problem of
relying on MAC-callbacks for reliable delivery to the next-hop become an
issue - when should a DSR-ACK be specifically requested from the next-hop
node and when should simple MAC-callback be relied upon? Ofcourse, both
the problems are interrelated - if ARP for the next-hop fails, then either
the link is unidirectional or the source has got some incorrect
information and is sending the wrong source-route, and in both the cases
the problem can be resolved by requesting a DSR-ACK by default. But the
issue of ARP is still an issue - a solution suggessted is to develop a
MANET level protocol for ARP - this is ofcourse possible, but has lots of
additional overheads...

Hope that answers your queries...

- Aaditeshwar.