Hi Justin,
Am 11.06.2015 um 16:34 schrieb Justin Dean <bebemaster@xxxxxxxxx>:
As this discussion is related to one of my major issues I'd like to provide
some input. If RREP messages are sent with multi-cast with the "next hop"
included in the RREP message and not the ip header there wouldn't be a need
to add the next hop route until the AckReq message is received.
Justin
On Thu, Jun 11, 2015 at 7:09 AM, Victoria Mercieca <vmercieca0@xxxxxxxxx>
wrote:
Hi Lotte,
On Thu, Jun 11, 2015 at 10:17 AM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx> wrote:
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
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?
that.
I'm not sure if I'm thinking too implementation-specific here... But in the
end, to whatever stack transporting our packets, a RREP is a data packet like
any other, so if we want to transmit it to the next hop and there's no known
route to the next hop (yet), this could end up being a problem (maybe this is
part of the “who can access the routing table” question?).
This is true (and again due to my earlier thinking that routers will be on
the same subnet. They might not be, which is why we need to install a route
to the one-hop neighbour, as Charlie said.)
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 RREP SHOULD include an AckReq data element in order to achieve
adjacency monitoring as described in Section 6.2.
OK so this should be re-worded to something like: 'if adjacency is not yet
confirmed, as described in 6.2, the RREP MUST include an AckReq data element'
on the other hand, it also says:
Until
bidirectionality is confirmed, the state is Unknown, and
acknowledgement of RREP messages MUST be requested.
(and now I'm confused :D)
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.
We have this bit in 4.3:
A neighbor list SHOULD be maintained with information about
neighboring AODVv2 routers, including an indication of the state of
the adjacency to the router. Section 6.2 discusses how to monitor
adjacency.
and in 6.2
AODVv2 routers SHOULD monitor connectivity to
neighboring AODVv2 routers along potential routes
...but nothing that says "now you add the sender to the neighbor list".
Should we add it into message processing algorithms? e.g. first step should
be "update the neighbor list" and then where necessary, reword the step about
checking if its blacklisted. We can have something in 4.3 about how exactly
to update/add to the neighbor list.
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
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!)
no unconfirmed routes and use halfway learned routes blindly :(
Well, we can leave the route to OrigAddr (learned from the RREQ) as
Unconfirmed, and we wont use that to forward data traffic to OrigAddr. But
the routes we need to add for our one-hop neighbours, they need to be valid
routes (Active/Idle), so that we can forward the RREP. We would have to set
them as valid, in order to use them, to see if the link is bidirectional.
Unfortunately this would mean that data traffic could also be forwarded if
destined for our one hop neighbours, even though we are still unsure if the
link is bidirectional. But, is it likely that there would be data packets for
the neighboring AODVv2 router? Can we get away with it? If we add the route
entry for a neighbor when we receive a RREQ from the neighbor, this route
would exist as a valid route (incorrectly, we could say) until a signal of
defniite bidirectionality arrives (after which the route is correctly valid),
or until we miss a RREP_Ack or a RREP from that neighbor and blacklist it
(and remove the route to the neighbor, and the route to OrigAddr?).
Hopefully, the state of the link to the neighbor would be found out soon
after the RREQ was received, but the RREP could go via a different path, so
the route to the one-hop neighbor router would remain as valid without the
adjacency having been confirmed.
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?
The neighbor adjacency *could* have already been confirmed as bidirectional
by another signal (eg NHDP Hello listing us as neighbor). The AckReq bit is
mandatory in a RREP, if adjacency is not yet confirmed as bidirectional. The
bit you quoted above where it says "SHOULD" needs to be reworded.
Kind regards,
Vicky.
Regards,
Lotte
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
