[aodvv2-discuss] Re: Section 6.5.2/Unconfirmed routes

  • From: Victoria Mercieca <vmercieca0@xxxxxxxxx>
  • To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
  • Date: Wed, 3 Jun 2015 12:01:18 +0100

Hi Lotte,

You are right, it would be better to explicitly define it, and we should
incorporate this text.

Kind regards,
Vicky.

On Wed, Jun 3, 2015 at 9:39 AM, Lotte Steenbrink <
lotte.steenbrink@xxxxxxxxxxxx> wrote:

Hi all,
while implementing Unconfirmed routes, I had a bit of a hang up with
section 6.5.2., which says:

If the RteMsg containing AdvRte is a RREQ, the route is not yet
confirmed. It should be stored, so that a corresponding RREP can be
sent, but should not be used to forward data. If there is already a
matching route, this new route should be saved as an additional route
using the process below, and can replace the original route when
adjacency with the next hop is confirmed.

Because there is no mention of the word Unconfirmed, I first missed this
part while searching through the Draft for cues how to implement
Unconfirmed routes...
I'm wondering, would it make sense to explicitly write down the process
hinted at above? After all, it is a routing table ,not a FIB... It could
have several entries for one route. So the process could be something like
this:

- if no other route exists and the RteMsg is a RREQ, add the entry and set
it to Unconfirmed.
- if another route exists and the RteMsg is a RREQ, add another entry and
set it to Unconfirmed
- if other route(s) exist and the RteMsg is a RREP:
- if the only other route is Unconfirmed, set it to confirmed.
- if there is an Active/Idle/Invalid route and an Unconfirmed
route, set the Unconfirmed route and expunge the old Active/Idle/Invalid
route.

(maybe the third point plus subpoints could also be woven into section
6.5.1.)

Regards,
Lotte

Other related posts:

  1. Home
  2. aodvv2-discuss
  3. Archive
  4. 06-2015