Subject: AODV draft issue (RERR)

From: Manel Guerrero Zapata <[email-masked]>
Date: Thu, 24 May 2001 19:13:40 +0300

Hi Elizabeth,

In the section '8.5. Forwarding Route Replies' of the
'draft-ietf-manet-aodv-08.txt' it says:

[...]
   When any node generates or forwards a RREP, the precursor list for
   the corresponding destination node is updated by adding to it the
   next hop node to which the RREP is forwarded. [...]

But there is nothing like that for Gratuitous RREPs or for RREQs.
So the error recovery system that AODV has now will never work with
routes that where created as reverse routes. The nodes will never
forward RERRs.

I think there should be something like this in the section
'8.4.3. Generating Gratuitous RREPs':

   When any node generates or forwards a _Gratuitous_ RREP, the
   precursor list for the corresponding _source_ node is updated
   by adding to it the next hop node to which the RREP is forwarded.

And something like this in the section
'8.3.1. Processing Route Requests':

>   When a reverse route is created or updated, the following actions are
>   carried out:
>
>    1. [...]
>    2. [...]
>    3. [...]
>    4. [...]

    5. When any node generates or forwards a _RREQ_, the precursor list
       for the corresponding _source_ node is updated by adding to it
       the next hop nodes to which the _RREQ_ is forwarded (tipicaly
       255.255.255.255).

-----------------------

Another solution would be to not use precursor lists:

Then, in section '8.9. Route Error Messages', instead of:

>      (c)       checks the precursor list for this destination for
>                emptiness.  If one or more of the precursor lists for
>                the unreachable destinations are non-empty, the node
>                creates a RERR message, including as unreachable each
>                destination with a non-empty precursor list.  It also
>                includes their destination sequence numbers, and then
>                broadcasts this RERR message.

it would be

      (c)       the node rebroadcasts the RERR message.

In this case there is going to be a little bit more traffic.

-----------------------

What do you think about it?

BR/
	Manel Guerrero

---

From: "Elizabeth M. Royer" <[email-masked]>
Date: Tue, 29 May 2001 09:57:36 -0700 (PDT)

Hi Manel,

Thanks for pointing this out to us, and for suggesting a solution.
We are not going to get rid of the precursor lists, because we think
they are useful.  We will change the draft to incorporate precursor
lists for Gratuitous RREPs and RREQs.

Elizabeth

~> 
~> Hi Elizabeth,
~> 
~> In the section '8.5. Forwarding Route Replies' of the
~> 'draft-ietf-manet-aodv-08.txt' it says:
~> 
~> [...]
~>    When any node generates or forwards a RREP, the precursor list for
~>    the corresponding destination node is updated by adding to it the
~>    next hop node to which the RREP is forwarded. [...]
~> 
~> But there is nothing like that for Gratuitous RREPs or for RREQs.
~> So the error recovery system that AODV has now will never work with
~> routes that where created as reverse routes. The nodes will never
~> forward RERRs.
~> 
~> I think there should be something like this in the section
~> '8.4.3. Generating Gratuitous RREPs':
~> 
~>    When any node generates or forwards a _Gratuitous_ RREP, the
~>    precursor list for the corresponding _source_ node is updated
~>    by adding to it the next hop node to which the RREP is forwarded.
~> 
~> And something like this in the section
~> '8.3.1. Processing Route Requests':
~> 
~> >   When a reverse route is created or updated, the following actions are
~> >   carried out:
~> >
~> >    1. [...]
~> >    2. [...]
~> >    3. [...]
~> >    4. [...]
~> 
~>     5. When any node generates or forwards a _RREQ_, the precursor list
~>        for the corresponding _source_ node is updated by adding to it
~>        the next hop nodes to which the _RREQ_ is forwarded (tipicaly
~>        255.255.255.255).
~> 
~> -----------------------
~> 
~> Another solution would be to not use precursor lists:
~> 
~> Then, in section '8.9. Route Error Messages', instead of:
~> 
~> >      (c)       checks the precursor list for this destination for
~> >                emptiness.  If one or more of the precursor lists for
~> >                the unreachable destinations are non-empty, the node
~> >                creates a RERR message, including as unreachable each
~> >                destination with a non-empty precursor list.  It also
~> >                includes their destination sequence numbers, and then
~> >                broadcasts this RERR message.
~> 
~> it would be
~> 
~>       (c)       the node rebroadcasts the RERR message.
~> 
~> In this case there is going to be a little bit more traffic.
~> 
~> -----------------------
~> 
~> 
~> What do you think about it?
~> 
~> BR/
~> 	Manel Guerrero