Hi Lotte,
Let me first apologise for the fact I haven't been following this very
closely. I'm just reading this one quick on my phone but if I've missed
something, just shout at me and I'll read the thread properly.
When the RREP comes back to B, B regenerates that and sends to the next hop
towards OrigAddr. If the RREP was to be forwarded like a data packet then
the unconfirmed route to OrigAddr wouldn't allow this. But we are
regenerating, and we know the next hop we should use to send the RREP
towards OrigAddr. I don't think there's a problem using this info to send a
regenerated RREP?
Do we allow neighbor checking to not be used? I cant remember the wording
we used, but when B receives the RREQ via A, doesnt it save A as a neighbor?
The router B, in the example, should have a neighbor entry for A. It may
not be confirmed to be bidirectional, which is why we might request a
RREP_Ack, but we should have no problem sending a RREP to A. Or does this
link into Charlie's comment a while ago that we should have a route
installed for each neighbor AODVv2 router? We still need to add that to the
draft. Actually, those routes to neighbors, even if not known to have a
bidirectional link, would have to be set as valid routes in the routing
table, in order to regenerate the RREP to them, to request the RREP_Ack to
confirm bidirectionality! (I guess that's what you meant? Good catch!) So
the question is, is it ok to add a valid route to each one hop neighbor,
before we have confirmation that the link to the neighbor is bidirectional?
If bidirectionality was not then confirmed, do we blacklist the neighbor,
in which case we probably should remove the route to the neighbor? Then
when un-blacklisted, reinstall it?
Kind regards,
Vicky.
On 10 Jun 2015 19:28, "Lotte Steenbrink" <lotte.steenbrink@xxxxxxxxxxxx>
wrote:
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
