Subject: [Fwd: AODV draft issue (RERR)]

From: Manel Guerrero Zapata <[email-masked]>
Date: Tue, 24 Jul 2001 17:36:54 +0300

Subject: Re: AODV draft issue (RERR)
From: Manel Guerrero Zapata <[email-masked]>
To: "Elizabeth M. Royer" <[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.

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.

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

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.

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