Vicky/Justin –
I’ll try (though my success rate these days seems terribly low… ;-))
Inline, with “SMR>” (Outlook… I hate it.)
From: aodvv2-discuss-bounce@xxxxxxxxxxxxx
[mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx] On Behalf Of Victoria Mercieca
Sent: Tuesday, June 23, 2015 10:14 AM
To: aodvv2-discuss@xxxxxxxxxxxxx
Subject: [aodvv2-discuss] Re: Routes to Neighbors / Unconfirmed Routes
Hi Justin,
Thanks... so we should only attempt to verify connectivity when there is a RREP
coming back, i.e. when the route is being established along this path, when we
NEED to verify if its a bidirectional link. So we can avoid a lot of unicasting
to confirm neighbours early on, when it might turn out that no routes are
discovered via those neighbours.
Also, I'm annoyed I didn't notice before, the unicast RREQ is going to have the
same problem - if its unicast, there needs to be a route to the destination. We
wouldnt be able to send the RREQ by unicast, in order to get the reply, in
order to confirm connectivity and install the route to the neighbor.
So we're back at the same question:
1. If we want to unicast a RREP to the next hop toward OrigAddr, IP will need a
route to the next hop.
1a) Do we install this route to the neighbor before we know if the link is
bidirectional? We could install it when we receive the RREP, just before we
regenerate the RREP, and could remove it quickly if no RREP_Ack arrived?
SMR> I’d say yes, install the route, before we know the link is bi-directional.
If the link isn’t actually bi-directional, the unicasted RREP will time out –
you won’t get a reply. And at the timeout, we can remove the route.
1b) Do we multicast a 1-hop-limited RREQ for the neighbor address? Only the
neighbor itself would reply, and the RREQ wont get regenerated by neighbors
which are not responsible for the requested address, because it's limited to
one hop. Technically we have the three way exchange (initial RREQ, 1-hop RREQ,
1-hop RREP) but this will incur a delay for the RREP we are trying to forward
to OrigAddr.
SMR> If the multicasted RREQ is sent via the 5444 parser, you can’t manipulate
the TTL (based on the other, loooooooooooooong-running discussion on setting
TTL). So you can’t really limit it to 1 hop.
Regards,
Stan
2. Do we multicast over this hop instead, include the intended next hop address
and the AckReq data element, and expect the RREP_Ack in order to verify
bidirectional connectivity, so that we can unicast in future?
Anyone?
Regards,
Vicky :)
On Tue, Jun 23, 2015 at 2:35 PM, Justin Dean
<bebemaster@xxxxxxxxx<mailto:bebemaster@xxxxxxxxx>> wrote:
I don't think this will work the way you want it to work. If, while attemption
to check bi-directionality durring route requests you send unicast route
requests (one-hop) to all neighbors you get requests from your goung to end up
with a LOT of redundant unicast messages (which still don't have unicast
routes).
To check for bi-directionality a three way exchange is needed at minimum.
A) I'm A
B) I'm B and heard A
A) I'm A and heard B
Doing this on the route reply with (udp multicast) with ack request included
for unknown neighbor (if neighbor is known for some other reason ack request
can be dropped) seems the simplest to me.
If you want to do it on route requests the whole thing gets a lot more chatty
with a bunch more overhead and complicated. Like NHDP hellos with reactive
timers..complicated and more overhead...
On Tue, Jun 23, 2015, 8:12 AM Victoria Mercieca
<vmercieca0@xxxxxxxxx<mailto:vmercieca0@xxxxxxxxx>> wrote:
Hi Lotte,
Comments in-line:
On Tue, Jun 23, 2015 at 12:50 PM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx<mailto:lotte.steenbrink@xxxxxxxxxxxx>> wrote:
Hi Vicky and Charlie,
Am 22.06.2015 um 20:07 schrieb Victoria Mercieca
<vmercieca0@xxxxxxxxx<mailto:vmercieca0@xxxxxxxxx>>:
Hi Charlie,
I have gotten a little confused. When do we put the route for our neighbor into
the route table? Comments below:
On Mon, Jun 22, 2015 at 6:24 PM, Charlie Perkins
<charles.perkins@xxxxxxxxxxxxx<mailto:charles.perkins@xxxxxxxxxxxxx>> wrote:
Hello folks,
My suggestion was specifically about how to allow neighbors to be in the route
table. I didn't mean to suggest this solution to be applied before actually
using a route discovered during route discovery.
When would this happen? When we first learn about a neighbour and it first goes
into our neighbor table? Would we try to verify connectivity immediately using
the unicast RREQ? If we're doing that, have we negated the need for AckReq and
RREP_Ack?
To enable a neighbor to be in the route table, I think the unicast RREQ will
work just fine. It's debatable how often neighbors will need this treatment,
but at least the penalty is not too severe. Moreover, in the case of putting
neighbors into the route table, I don't think the unicast RREQ ought to be
retried. If it fails (very unlikely) then normal route discovery should be
used. Maybe the most expedient way to specify that is to say that, for the
case of discovering a route to a neighbor [almost sounds silly], the first RREQ
SHOULD be unicast, and later RREQs multicast.
Fair enough :) I was just pointing out what the current logic would do.
In order to use a next hop in a discovered route, I really don't think there's
a problem. After all, the route was discovered and the RREP returned according
to procedures that have been designed to assure bidirectionality. If the RREQ
gets to the destination and the RREP gets to the originator, we can declare
that the route is valid.
Depends which discovered route you mean. Of course, if the RREP gets back to
the originator, and we've done the AckReq stuff along the way, then yes,
everybody's next hops are confirmed as bidirectional, and we dont need to RREQ
for them.
BUT, before that, when we're forwarding the RREP, the route to OrigAddr isnt
known to be bidirectional and the RREP_Ack stuff hasnt happened yet. We're
going to look at the route to OrigAddr to get the address of the next hop.
However, the next hop is a neighbor where we dont know if the link is
bidirectional. For IP to be able to forward the RREP unicast to the next hop,
the IP route table needs to have a valid route to the next hop, i.e. to our
Unconfirmed neighbor. This is fine if they're on the same subnet, but I got
told off for assuming that before...So if they're on different subnets, doesnt
IP need a route to the neighbor, in order to forward a unicast packet to it?
If so, there are two options here:
1. If there is no route to the neighbor at this point, IP cant forward the
RREP. If we now use a unicast RREQ to gain a route to the neighbor (my initial
understanding from the teleconf today), then we can forward the RREP.
2. If we confirmed the neighbor previously (maybe when the RREQ arrived to
begin with) there wont be a problem, we can immediately forward the RREP.
I think I like the second approach better out of the two approaches presented..
This way, we should know if we have a bidirectional connection by the time our
RREP arrives and don't need to unnecessarily delay the RREP forwarding.
I like it too.
In both cases, we wont need AckReq or RREP_Ack.
So we'd get rid of the entire mechanism and just say “if you get a RREQ (with
hopcount 1) from a neighbor that you don't have a confirmed route to, send a
unicast RREQ back and set the route to your neighbor to confirmed”?
So we would mandate that if you receive a RREQ from a neighbor in state
Unknown, you would forward the RREQ as usual but also send a unicast RREQ to
that neighbor, with hop limit set to 1, in order to confirm bidirectionality?
And if you receive a unicast RREQ with hopcount 1 (and/or hop limit 1?), would
you be safe to assume it came from someone you recently sent an AODVv2 message
to, someone who wishes to confirm bidirectionality, and therefore you can set
the neighbor state to Confirmed (since you know messages have been sent and
received on both sides), and send back a RREP (so that the neighbor sees that
traffic it sent has definitely been received, and it can also set neighbor
state as confirmed)?
Once neighbor state is confirmed, we can put a valid route to the neighbor in
the route table, so that any packets that need to be forwarded to the neighbor
(including potentially the RREP corresponding to the original RREQ) can be
forwarded without issue or delay. And from that point, we dont need to worry
about sending any more unicast RREQs, unless for some reason neighbor state
reverts to Unknown.
I'm still confused...
Me too :D
Regards,
Lotte
Hehe! :) Good to talk it through though, we're getting somewhere I think!
Charlie, is this what you meant, to confirm the neighbor state as early as
possible?
Regards,
Vicky.
Regards,
Vicky.
Notably, in all the simulations that I know about for lo these many years, the
issue has never been raised regarding discovered routes.
Regards,
Charlie P.
On 6/22/2015 8:52 AM, Victoria Mercieca wrote:
So the other option which Charlie mentioned on the call today is to unicast a
RREQ for the neighbor. Jumping in to the third paragraph of the example I used
before:
When IP is given the unicast RREP for OrigAddr and TargAddr, to send to the
next hop A, IP says "I dont have a route to A, can AODVv2 give me one?". AODVv2
sees that TargAddr for this request is a neighbor with Unknown state, and
decides to send a unicast RREQ for the neighbor A.
Hopefully it then receives a RREP from A almost immediately, in which case the
neighbor State changes to "Confirmed", the route to the neighbor gets
installed, and IP can forward the original RREP toward OrigAddr.
If C doesnt receive a RREP from neighbor A, and the request times out, another
RREQ may be sent for A...eventually the max number of retries is reached, the
route discovery fails, and the original RREP toward OrigAddr will be dropped
since no route has been learned. BUT, no blacklisting would occur here. Maybe
if we do send a unicast RREQ for a neighbor and we dont get a RREP, we should
blacklist the neighbor. Also we might prefer to use a shorter timeout
associated with this case. Because...probably, before C gives up on a RREP
coming back from A, OrigAddr's router would have given up on the original RREP
from TargAddr arriving, and would have sent a new RREQ for TargAddr. Hopefully
the new RREQ doesnt get forwarded by C before C can blacklist A.
Kind regards,
Vicky.
On Mon, Jun 15, 2015 at 5:41 PM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx<mailto:lotte.steenbrink@xxxxxxxxxxxx>> wrote:
Hi Vicky,
Am 15.06.2015 um 18:17 schrieb Victoria Mercieca
<vmercieca0@xxxxxxxxx<mailto:vmercieca0@xxxxxxxxx>>:
Hi all,
Trying to summarise this one...
As an example
OrigAddr ------ B ------ A ------ C ------ D ------ E ------ TargAddr
RREQ goes out using OrigAddr and TargAddr.
When Router C first receives the RREQ, it learns a potential route to OrigAddr
which is saved as an Unconfirmed route, which cannot be used for forwarding
data traffic. It also learns of a neighbor, Router A (the router that forwarded
the RREQ), and would create a neighbor entry for Router A. Probably the
neighbor state will be Unknown at this point, since bidirectionality is
unconfirmed.
When C receives the corresponding RREP, it looks up its route to OrigAddr and
finds that the next hop is Router A. It could regenerate the RREP and unicast
to Router A, but when the packet reaches IP, it might say "I dont have a route
to A, I'll request one from AODVv2" (especially if routers are on different
subnets) and that is a bit silly! So if we want to unicast the RREP, we should
probably install a valid route to the neighbor. The thing that doesnt quite
make sense here is that we would be installing a valid route when we dont know
if the route is viable, because we havent yet confirmed bidirectionality. But
we can't confirm bidirectionality without sending a RREP including AckReq, and
getting the RREP_Ack back.
So,
A) Should we install the route to the neighbor, not knowing if it is viable?
This would mean that data traffic could also be forwarded if it was destined
for our one hop neighbour, even though we are still unsure if the link is
bidirectional. Hopefully, the state of the link to the neighbor would be found
out soon after the RREQ was received, but if the RREP goes via a different
path, the route to the one-hop neighbor router would remain valid without the
adjacency having been confirmed.
Could we set the route timeout to RREP_Ack_SENT_TIMEOUT^ RREP_RETRIES?
Or
B) Should we multicast the RREP? Then we dont need to install a route to the
neighbor before it is confirmed that the link to the neighbor is bidirectional.
Using the multicast idea, if we include the intended next hop address within
the message, any routers which receive the RREP can check if they are the
intended next hop, and if not, they will not regenerate the RREP or reply with
a RREP_Ack. So in the example, when Router A receives the multicast RREP from
Router C and realises it is the intended next hop, it will regenerate it (and
will also reply with the RREP_Ack). The RREP_Ack, when it arrives at Router C,
gives the signal of bidirectionality, so the neighbour entry for Router A
becomes Confirmed, and the route to OrigAddr becomes Idle and can be used. At
this point, it's 100% correct to add a route to the neighboring Router A. Then,
future RREPs (and any other kind of packets) can safely be unicast to Router A.
Sounds like a good solution to me, but I have a feeling Charlie will not be
happy about the extra payload ;)
As a side note, Router A regenerates the RREP to its next hop, Router B. If
Router B is not confirmed to have a bidirectional link to Router A, Router A
might also need to multicast and include B as the intended next hop. In this
way, the RREP will follow the same path as the RREQ (in reverse) but some
routers along the way will have received and processed extra multicast traffic.
Is that a pretty good summary of the problem?
I think so...
Regards,
Lotte
Kind regards,
Vicky.
_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________
