Subject: RE: loop in AODV?

From: Sasuta Mike-CSM001 <[email-masked]>
Date: Wed, 31 Oct 2001 09:33:01 -0600

Dan,

It seems to me there has been some confusion of recording routes.   In the discussion of your example of [c] needing a route to [d], you correctly reflect that [a] has a route path to [d] via [b] from a previous message attempt.   However [b] will receive the packet from [a], originally from [c], seeking [d] which [b] no longer has in its route table. In processing this, [b] creates a backward route path to [c] via [a], not to [d] via [a].     [b] will then forwards the request, finding [d].   

By the way, it also seems that for [c] to get to [a] it would need to be via [b].   Thus [a] would also create a backward path to [c] via [b].   (And [b] would have also attempted to forward the request along finding [d].)

There does not seem to be a loop created in this example.

Mike

> -----Original Message-----
> From:	Dan Iregren [SMTP:[email-masked]]
> Sent:	Wednesday, October 31, 2001 2:53 AM
> To:	[email-masked]
> Subject:	loop in AODV?
> 
> Hi,
> Consider the following scenario with the four nodes, a - d, all running
> AODV as described in draft 8.
> 
> 
> 			[c]
> 	[a]	[b]
> 			[d]
> 
> 
> [a] is within range of [b].
> [b], [c] and [d] are all within range of eachother.
> All routing tables are empty and each node has sequence number 0.
> 
> Then,
> 
> [d] sends a request asking for route to [x] ([x] is not one of [a], [b],
> [c] and [d]).
> 
> Only [b] receives the request. [b] does not have a route towards [x] so it
> forwards the request but no one receives that packet. While processing the
> request [b] creates a backward route towards [d].
> 
> [d] sends another request asking for [x] since the first one failed.
> 
> Only [b] receives the (second) request, [b] still does not have a route
> towards [x] so it forwards the request.
> [b] does nothing with its route entry towards [d].
> 
> [a] receives the (second) request forwarded by [b].
> While processing the request [a] creates a backward route towards [d].
> 
> NOTE,
> [a] and [b] now both have routes towards [d], [a]'s route towards
> [d] has a longer remaining lifetime than [b]'s route towards [d].
> 
> After some time, [b] deactivates its route towards [d].
> 
> If for instance [c] sends a request asking for [d] then that request will
> be answered by [a] and that will cause [b] to set up a route towards [d]
> with nexthop [a] while [a] has a route towards [d] with nexthop [b].
> 
> 
> 
> We have a loop, so what is wrong here?
> 
> 
> /Dan