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.
In both cases, we wont need AckReq or RREP_Ack.
I'm still confused...
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.
