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?
I'd say 2 works well with little fuss.
A<--->B<--->C
D
A sends RREQ for C
B & D receive and install unknown neighbor A
B sends RREQ for C
A & C receive: A installs bi-directional neighbor B; C installs unknown
neighbor B
D sends RREQ for C
A & C receive: A installs bi-directional neighbor D; C installs unknown
neighbor D
C sends RREP with B tagged with RREP_Ack request
B & D receive: B installs bi-directional neighbor C; D ignores
B sends RREP with A tagged with RREP_Ack request and C tagged with RREP_Ack
A & C receive: C installs bi-directional neighbor B (previously unknown);
A installs route (neighbor was already bi-directional) and sends RREP_Ack
A sends message with B tagged with RREP_Ack
Everything is done with multicast with intended addresses tagged as
appropriate. By doing it this way you can get double use out of single
messages route reply upstream and and ack downstream in a single
packet/message with very little overhead and no fuss about installing
routes before bi-directionality is known and retroactively timing them
out. You could do this in the forward direction but it'd be more
complicated as you would have to send ack requests to all neighbors sending
out RREQ which introduces delay or extra messaging. The only overhead with
this is the added address in the RREP tagged with the RREP_Ack, a TLV to
request a RREP_Ack, and one extra message at the source to send the
RREP_Ack that last hop.
On Tue, Jun 23, 2015 at 10:19 AM, Ratliff, Stanley <sratliff@xxxxxxxxxxx>
wrote:
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> 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>
wrote:
Hi Lotte,
Comments in-line:
On Tue, Jun 23, 2015 at 12:50 PM, Lotte Steenbrink <
lotte.steenbrink@xxxxxxxxxxxx> wrote:
Hi Vicky and Charlie,
Am 22.06.2015 um 20:07 schrieb Victoria Mercieca <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> 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> wrote:
Hi Vicky,
Am 15.06.2015 um 18:17 schrieb Victoria Mercieca <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.
_____________________________________________________
