Hi Vicky,
Am 10.06.2015 um 21:29 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:
Hi Lotte,I don't think so either, but I'm not sure if the resolution is as easy as that.
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 weThe draft says:
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 notI can't find any text in the draft that allows this...
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 aPretty much... But that would mean reverting back to the state where we have no
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,That would only work with mandatory AckReq/RREP_ACKs, right?
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
