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

  • From: Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Wed, 10 Jun 2015 20:27:58 +0200

Hi Vicky,

Am 03.06.2015 um 13:01 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:

Hi Lotte,

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


Okay. Do you want me to send you some text to integrate?

Also, while talking to a friend about AODVv2, it occurred to me that I think
unconfirmed routes could actually prevent RREPs from being delivered... Stop me
if I'm wrong here:

Say we have this (very simplified) setup:
OrigNode <-> A <-> B <-> TargNode

When B receives a RREP from TargNode, it needs to send it along towards
OrigNode. IntermediateNode has a route table entry that says A is the next hop
towards OrigNode from the RREQ that was sent before, but the route is set to
Unconfirmed, so B can't actually use this entry to send the RREP back.
Now, even if we say “Unconfirmed routes can be used to send RREPs”, we still
have a problem if there's no Neighbor checking mechanism enabled. If, for
example, I don't have a neighbor cache telling B “A (which is now set as the
recipient of our RREQ) is a next-hop neighbor, you can safely send this”,
AODVv2 will be asked for a route towards A by the network stack, and this time
we don't have the context that we're trying to send a RREP, so AODVv2 will
start a route discovery for A. AckReq/RREP_Acks wouldn't help here either
because this mechanism only kicks in *after* the RREQ has ben sent (which it
can't because... see above.)

Am I missing something or is this an issue we need to address?

regards,
Lotte

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