Subject: Re: AODV draft issue (RERR)

From: "Elizabeth M. Royer" <[email-masked]>
Date: Thu, 26 Jul 2001 10:28:31 -0700 (PDT)

Manel and Mahesh,

So you are proposing that, when a node receives a RERR, that it
invalidates its route entry for that destination if both the source
of the RERR is the next hop on that route, AND the dest seqno in 
the RERR for that dest is >= that which the node has for the dest
in its route table, correct?  So we would have to add the second
condition to the draft.  And this will prevent the re-ordering of
control packets at the MAC layer that Mahesh pointed out.

I'm not yet quite convinced about the original problem, however.
If a node reboots, it loses its dest. seqnos.  If it receives a data
packet for some destination for which it does not have a route,
it sends a RERR.  But there is still the question of what seqno
to put in that RERR for the destination, so that the upstream node
will take note of the RERR and stop using that route.  Suggestions
for how to handle this?  The rebooted node will not have a way to
obtain the current seqno for that destination.  

Elizabeth

~> 
~> 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

---

From: Manel Guerrero Zapata <[email-masked]>
Date: Tue, 24 Jul 2001 12:20:57 +0300

Hi Elizabeth,

I've been thinking about it, and my opinion is that RERR message
should not include destination sequence numbers at all.

--> you are right that ignoring destination seqnos while invalidating
--> routes is not a problem because you only break routes by
--> invalidation and loops are not created as a result! however, the
--> question is whether any unnecessary invalidations may occur by
--> ignoring seqnos. more below...

 Let me explain you why:

First of all, in the case (ii) puting dsn to 0 or 1 does not make
much sense, because it is (quite likely) gonna be an old dsn anyway.
If nodes pay atention to dsn (comparing it to its own dsn), everybody
is gonna discard this destination.

--> 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.

But anyway, what a RERR says is: You used to route packets to this
destination though me, but now I don't have the route for that
destination.
So, don't send them to my anymore.
Well, this is independent of DSNs. Whatever was his DSN and yours it was
using you as a next hop for a route that you don't have (anymore).

--> 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.

So, my sugestion is: Let's not put DSNs at all. RERRs will be shorter
and we will not put on the packet information that is not really needed.

--> in summary, what you pointed out is a problem not just specific to
--> RERRs but has to do with the problems that arise when a route entry
--> is deleted and seqno for the destination is lost. from the past
--> discussions, such route entry deletions unless properly taken care
--> can cause loops too. the current draft outlines solutions in such
--> cases (see section 8.10 and 8.11)

--> 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.

--> Regards,
--> Mahesh

 BR/Manel

"ext Elizabeth M. Royer" wrote:
>
> Hi Manel,
>
> In problem 1 below, we do still need to send a RERR message so
> that the upstream nodes (including the source) will stop transmitting
> the data packet along that path, and the path will be invalidated.
> The question of which RERR to use in case (ii) is a good one.
> Since there is no route entry for the destination, my inclination
> is to say that the default seqno for a destination is zero,
> and so zero + 1 = 1.  Hence the dest seqno in the RRER should
> equal 1.  According to the reading of the  specification, when a
> node receives a RERR from its neighbors, it only checks if that
> neighbor is the next hop for its path to the destination.  It does not
> do a seqno check.  Hence, the node receiving the RERR should still
> delete the route.  Perhaps we should add some text, though, for part (a)
> in section 8.9 to read that the node receiving the RERR only updates
> the corresponding dest seqno with the Dest Seqno in the RERR IF that
> seqno is > its recorded value of the dest seqno.  Otherwise, the
> receiving node modifies its record of the dest seqno by adding one
> to it, because of the invalidation.  Then when it rebroadcasts the
> RERR, it uses its record of the dest seqno, because this value is either
>
> the value in the RERR it received, or it is the recorded value in the
> route table, which has now been incremented by one.
>
> What do you think?  Assuming you agree, we can make the corresponding
> modification whenever we are able to do so (IESG Experimental RFC
> evaluation is currently ongoing...)
>
> As for your second comment below, I agree.  We can make the change.
>
> Thanks for pointing these out,
> Elizabeth
>
> ~> >
> ~> > In the section '8.9. Route Error Messages' of the
> ~> > 'draft-ietf-manet-aodv-08.txt':
> ~> >
> ~> > In the case (ii), what hapens if the 'node
> ~> > for which it does not have an active route'
> ~> > it is not at all in the aodv routing table at all?
> ~> > Then, we don't have a dsn to put in the RERR.
> ~> > So, what do we do? Do we send the RERR anyway?
> ~> > And, if so, with which dsn?
> ~> >
> ~> >
> ~> >
> ~> > BR/
> ~> >         Manel Guerrero
> ~>
> ~> Another thing:
> ~>
> ~>
> ~> In the same section says:
> ~>
> ~> 8<--------------
> ~>
> ~>    For cases (i) and (ii), for each unreachable destination the node
> ~>    copies the value in the Hop Count route table field into the Last
> ~>    Hop Count field, and marks the Hop Count for this destination as
> ~>    infinity, and thus invalidates the route.
> ~>
> ~> -------------->8
> ~>
> ~> But in (ii) there is no active route for the unreachable destination.
> ~> So, then all this has been already done.
> ~>
> ~> So I thing it should say:
> ~>
> ~> 8<--------------
> ~>
> ~>    For the case (i), for each unreachable destination the node
> ~>    copies the value in the Hop Count route table field into the Last
> ~>    Hop Count field, and marks the Hop Count for this destination as
> ~>    infinity, and thus invalidates the route.
> ~>
> ~> -------------->8
> ~>
> ~> Am I wrong?
> ~>
> ~>
> ~> BR/Manel

---

From: "Elizabeth M. Royer" <[email-masked]>
Date: Mon, 23 Jul 2001 17:33:09 -0700 (PDT)

Hi Manel,

~> >

---

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: Tue, 24 Jul 2001 12:20:57 +0300

Hi Elizabeth,

 Let me explain you why:

--> Regards,
--> Mahesh

 BR/Manel

---

From: "Elizabeth M. Royer" <[email-masked]>
Date: Thu, 26 Jul 2001 10:28:31 -0700 (PDT)

Manel and Mahesh,

Elizabeth

~>