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.
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.
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?
Kind regards,
Vicky.
