Subject: Re: AODV draft issue (RERR)

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

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: Manel Guerrero Zapata <[email-masked]>
Date: Mon, 13 Aug 2001 18:34:17 +0300

Opsssss.

And for case (i) dsn should be incremented in the routing table.
But remember that you are already incrementing it by making the
the route to expire, because in the expiry section it is also
said that dsn should be incremented.
(let's not increment the dsn twice in different draft sections).

So maybe what could be said is that in case (i) the destination
sequence number that is put in the packet is the dsn that has been
incremented when making this route to expire. (or something like that)

What do you think?

BR/ManelG

Manel Guerrero Zapata wrote:
> 
> Hi Elizabeth,
> 
> In "8.9. Route Error Messages"  it says:
> 
>    "For cases (i) and (ii), the destination sequence numbers in the
>    routing table for the unreachable destination(s) are incremented by
>    one.  Then RERR is broadcast with the unreachable destination(s) and
>    their incremented destination sequence number(s) included in the
>    packet."
> 
> There is a problem in case (ii). For every "data packet destined to a
> node for which it does not have an active route" it will increment the
> dsn. If you receive several of those packets, you will increment a lot
> the dsn (and send RERRs with huge dsn for the Un.Dest.).
> 
> And anyway, since it is a "node for which it does not have an active
> route" its dsn has been already incremented
> 
> (
> 8.10 Route Expiry and Deletion:
> 
>    If the Lifetime of an active routing entry expires, the following
>    actions are taken.
> 
>     1. The entry is invalidated by copying the Hop Count to the Last Hop
>        Count field and then making the Hop Count infinity.
> 
>     2. The destination sequence number of this routing entry is
>        incremented by one.
> )
> 
> So I think that the dsn should be incremented only in the case (i).
> In the case (ii) it has already been incremented (when the route
> expired).
> 
> What do you think about it?
> 
> BR/ManelG

---

From: Manel Guerrero Zapata <[email-masked]>
Date: Mon, 13 Aug 2001 18:20:13 +0300

Hi Elizabeth,

(

BR/ManelG

---

From: Manel Guerrero Zapata <[email-masked]>
Date: Thu, 16 Aug 2001 17:02:34 +0300

Hi, it's me again ;)

Two things,

- AODV has this list of received RREQs. I thing that it should also
contain
the generated RREQs, otherwise you are forwarding a RREQ that you should
not.

H1     H2      H3
|----->| RREQ  |
|      |       |
|<-----|------>| Forwards RREQ
|      |       |
|----->| Forwards RREQ again!
|      |

- 8.9. (ii) should only generate a RERR if, in addition, dst is not in
the received RREQs list.
Otherwise you will generate a RERR to cancel a route that you are
discovering.

H1      H2     H3     H4
(RREQ H1->H4)
----------------------->

---------------><-------(RREP H1->H4)
(RERR H4)       ^
                |---Route deleted !!!

BR/ManelG