Loop Prevention in AODV

Question

we're supposed to do a presentation on AODV, and even having read all the official documentation and some additional sources, we're stumped by the question of how sequence numbers prevent loops.

Imagine the following crude network:

Aussuming that initially the link between C and D works and all nodes start out with a sequence number of 1. Now, the following happens:

1. A sends a RREQ to get to D. A's sequence # increases to 2.

2. D receives the RREQ, increments its own #. D sends a RREP to A.

3. A's latest information on D's sequence # is 2.

4. Now, the link between C and D breaks.

5. C still wants to send to D, sends a RREQ, with the last known destination sequence # for D, which should be 2.

6. A receives the RREQ, remembers having a route to D with the same destination sequence # (2) as in the RREQ. A sends a RREP for the route to D, creating the loop.

Can anyone tell us where we're mistaken in this scenario? Wrong information, wrong assumptions?

Thanks in advance!

Answer 1

You say you've read "the official documentation", but does that include the actual RFC, RFC 3561?

I believe your concerns are addressed in Section 6.1, Maintaining Sequence Numbers. It says, in part:

The only other circumstance in which a node may change the destination sequence number in one of its route table entries is in response to a lost or expired link to the next hop towards that destination. The node determines which destinations use a particular next hop by consulting its routing table. In this case, for each destination that uses the next hop, the node increments the sequence number and marks the route as invalid (see also sections 6.11, 6.12).

This means that in your example, after Step 4, C knows that the link to D is down and increments the Sequence number appropriately.

Then, utilizing the RERR method described in section 6.11, C sends a message to the other routers letting them know that the route to D is bad. Thus avoiding the loop.

(It has been many years since I've looked at AODV, I might be wrong/rusty...)