Subject: Re: AODV draft issue (RERR)

From: Mahesh Marina <[email-masked]>
Date: Wed, 25 Jul 2001 15:52:34 -0400 (EDT)

Manel and Elizabeth,
I have some more to add... see below (-->).

Regards,
Mahesh

---

From: Manel Guerrero Zapata <[email-masked]>
Date: Thu, 26 Jul 2001 15:10:59 +0300

Hi Mahesh,

thanks for your suggestion.
Let me sumarize your comments.

You say:

> --> i don;t think that is exactly what elizabeth proposed. let me
> rephrase
> --> it a little bit. whenever a node (say X) receives a RERR for a
> --> valid route from the nexthop to a destination D, it ALWAYS
> invalidates
> --> the route. BUT the destination seqno for D at X is updated
> --> as follows.
> 
> --> if received destination seqno for D greater than current seqno at X
> --> for D, replace the X's copy of seqno for D with the one in RERR
> --> packet.
> --> else, increment X's copy of seqno for D by one.
> 
> --> so, the problem you mentioned above should not happen.

And also:

> --> not quite. your logic may unnecessarily invalidate a newly formed
> --> route. how? i have an example:) consider a situation where route
> from
> --> some source S to a destination D breaks. Suppose that an
> intermediate
> --> node I2 along that route, after receiving a RERR from downstream,
> --> forwards a RERR to upstream node I1 towards S. Also, suppose that
> --> I2 propagates the RREQ, it received from a downstream node, to I1
> from
> --> D (with a greater seqno for D) for some node shortly after that.
> --> Now if the link layer reorders RREQ and RERR sent by I2 to I1, then
> --> with your logic route from I1 to D would be unnecessarily
> invalidated.
> --> i don't think AODV protocol makes any assumption that link layer
> --> should preserve ordering of messages.

And:

> --> therefore, my suggestion is:
> --> consider RERRs from nexthop to destination for route invalidation
> only
> --> that contain a higher destination seqno and handle the problem
> --> mentioned by manel in sec 8.9 (ii) separately by using ideas in
> --> sec 8.10 and 8.11, for example.

Ok, I agree with your suggestion:

It solves the 'unnecessarily invalidate a newly formed route' problem.
Gives a real funtion to the DSNs in the RERR. (So I'm not gonna suggest
anymore to change the RERR packet structure ;) ).

I'm going to 'more or less' rephrase your suggestion, so I make sure
that I have understood it right.

1) A node reciving a RERR will ONLY consider the unreachable
destinations
that in adition to the conditions specified by the draft have a dsn
higher
that the correspondig in the node's routing table.

2) If the route is invalidated, then the node also copies the dsn
from the RERR to its routing entry.

And I would add:

3) We assume that, if DELETE_PERIOD is properly set we will not have a
8.9.(ii) in which the route has been already deleted. (Which I think
is true in theory). And if it happens we don't initiate a RERR,
because theoreticaly, that will never happen and because if we generate
a RERR and put 1 in the dsn, nobody is going to pay atention to it
anyway.
(This goes for the 'handle the problem mentioned by manel in sec 8.9
(ii)
separately by using ideas in sec 8.10 and 8.11, for example.')

Is that what you are suggesting, Mahesh?

What do you thing about it, Elizabeth?

BR/Manel