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,When would this happen? When we first learn about a neighbour and it first
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.
To enable a neighbor to be in the route table, I think the unicast RREQFair enough :) I was just pointing out what the current logic would do.
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.
In order to use a next hop in a discovered route, I really don't thinkDepends which discovered route you mean. Of course, if the RREP gets back
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.
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.
