Hi all,
Sorry, just to clarify what I meant with the intended recipient thing... I
meant that instead of having one TLV named PktSource to identify the final
recipient of the RERR, and defining another NextHop TLV for the idea we are
discussing, I thought maybe we could refer to both with one TLV named
something like IntendedRecipient. So in a RREP it would identify the
intended next hop, and when used in a RERR it would identify the PktSource.
For RREP we want to send to the next hop on the route to OrigAddr. For RERR
we want to send to next hop on route to PktSource. We could multicast RERR
and RREP for the same reason, ie that the next hop is an unconfirmed
neighbor.
When the message reaches that one hop neighbor via multicast, the decision
on whether to unicast or multicast from there to the next hop can be
dependent on its own view of its link to the next hop it's own route for
OrigAddr or PktSource.
Actually, that might result in the RERR being sent on a few different paths
simultaneously. Do we need to specify the next hop in that case too, to
make sure the RERR only follows one path even if it gets multicast on links
where bidirectionality isn't known? In which case maybe we can't use the
same IntendedRecipient idea.
Hmm...sorry for the confusion.
Regards,
Vicky.
On 11 Jun 2015 19:31, "Charlie Perkins" <charles.perkins@xxxxxxxxxxxxx>
wrote:
Hello Vicky,
The downside of including another IPv6 address in the message is another
8-16 bytes in the packet, plus attendant overhead, depending on topology.
I'll have to go back and see what problem this is solving to understand
whether the price is really worth the benefit. How often does the problem
occur, compared to how often the cost is expended? If the problem is rare,
and the cost significant, the cost might not be worthwhile. Plus we have
to keep in mind that these are wireless networks, subject to failures even
with the most expensive protocol design imaginable. One has to count
battery depletion as a failure as well.
For RERR, would the extra 8-16 bytes be inserted in addition to the
PktSource? One is neighborly, the other usually not. Or maybe I am
missing something.
Regards,
Charlie P.
On 6/11/2015 7:56 AM, Victoria Mercieca wrote:
Hi both,
Well I know Charlie has been keen to avoid extra multicast messages in
the past, since I thought it would be a good idea for a RERR which includes
a PktSource to be multicast. Actually this same issue will apply to that
message as well as RREP. We could multicast initially, if the link to the
next hop neighbor was not yet confirmed to be bidirectional, then when the
AckReq is received (or other signal of bidirectionality), future RREPs
going to that neighbor could be unicast.
If we include the "next hop" inside the message, I guess the receiving
routers check if that's them, then only continue processing if it is? Only
the identified next hop should regenerate and should also reply if
acknowledgement was requested. We already decided there were problems with
the multicast RREP and we removed it. Receiving routers could learn the
route to TargAddr and then stop processing.
We could rename the PktSource TLV to be more of an "Intended recipient"
address, to avoid defining a new TLV again. If that is the chosen solution,
we can apply this to the RERR I mentioned above.
Regards,
Vicky.
On Thu, Jun 11, 2015 at 3:38 PM, Lotte Steenbrink <
lotte.steenbrink@xxxxxxxxxxxx> wrote:
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.
Ooooh, that would simplify things a lot. I really like this approach.
Vicky, what do you think?
Regards,
Lotte
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,
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?
I don't think so either, but I'm not sure if the resolution is as easy
as 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 thenot yet confirmed, as described in 6.2, the RREP MUST include an AckReq
wording we used, but when B receives the RREQ via A, doesnt it save A as a
neighbor?
The draft says:
The RREP SHOULD include an AckReq data element in order to achieve
adjacency monitoring as described in Section 6.2
<https://tools.ietf.org/html/draft-ietf-manet-aodvv2-09#section-6.2>.
OK so this should be re-worded to something like: 'if adjacency is
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 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.
I can't find any text in the draft that allows this...
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 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!)
Pretty much... But that would mean reverting back to the state where we
have 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, 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?
That would only work with mandatory AckReq/RREP_ACKs, right?
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
