Hi all,
Just refreshing this thread...
There were a couple of replies making it clear that we (I) should not
assume routers are on the same subnet, but we didnt reach a conclusion on
adding routes to the route table for each neighbour.
Also in the lower part of the email I described an idea that we could check
that we were expecting a RREP or RREP_Ack before we use it to confirm
adjacency. But unsure if the effort involved gives enough benefit?
Kind regards,
Vicky.
On Fri, May 8, 2015 at 9:03 AM, Victoria Mercieca <vmercieca0@xxxxxxxxx>
wrote:
Hi Charlie,
Comments in-line:
On Thu, May 7, 2015 at 5:45 PM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:
Hello Vicky,I was thinking all neighbouring AODVv2 routers would be on the same subnet
Follow-up below (some text deleted...):
On 5/7/2015 3:04 AM, Victoria Mercieca wrote:
Hi Charlie,
Comments in-line:
On Thu, Apr 30, 2015 at 7:59 PM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:
- Further to point 6, If the new RREQ follows the same path, andavoids the need for changes to RteMsg table entries and the related extra
the same router forwards it to us, we will ignore it because that
router is
now on the blacklist. If the RREQ comes to us from another router, will
it
have a newer SeqNum? Otherwise we'll think it was redundant. Or... do we
remove entries from the RteMsg table if they are from blacklisted
routers?
We don't actually save enough information to work out which ones came
from
the neighbor we have blacklisted.
No one has ever requested this feature, but it might be a good
idea. Adding a field to
the RteMsg table would be a small cost for the additional robustness of
the algorithm.
If the RREQ comes from the same route discovery but another router, it
would have the
same SeqNum and thus might get dropped, and so if we avoid that, it
would be better.
At minimum, if we get a RREQ from a blacklisted neighbor, that RREQ
should NOT go into
the RteMsg table.
I've written that retries should increase the sequence number. This
processing.
Right now, I won't complain. Eventually, someone will probably want to
revert that behavior
because (as noted in earlier email) increasing sequence number partially
invalidates all routes
at other nodes that only have the earlier sequence number.
My problem with not increasing the SeqNum is that if we had a RREQ go
out, and RREP come back, but hit a non-bidirectional link, the RREP wont
reach RREQ_Gen. It will timeout and retry. If the retry has the same
OrigSeqNum, it would be seen as a redundant RREQ by any router which
received the previous RREQ and would not be regenerated, likely causing the
route discovery to fail.
Check. One alternative would be to define a "retry" TLV which would
require
such RREQs to be forwarded anyway, which would also require adding the
retry
field to the Multicast RteMsg Table. But, not now :-)
I'm not sure what you mean here....?- What do we mean by "route timeout" in the list in this section?
It would mean that routes using that next hop have timed out.
However, I am not
sure it's such a great idea to do that, especially if we maintain a
neighbor list.
By the way, for every address in the neighbor list, we ought to have a
route
in the route table (with hopcount metric == 1). Unfortunately, we
would not
necessarily have sequence number information for that route.
I have left this as it was.
Can we specify that packets can be forwarded to known neighbors? I
think it would
be possible to do this as an initial step in the RREQ generation process.
I mean that if an address is in the Neighbor Table, we can send data
packets
to that Destination Address even though Route Discovery had never been
performed for that neighbor's address. If we put a route for that
neighbor
in the route table, we would not have a Sequence Number. And I am O.K.
with that, especially if you have already made the modifications to allow
routing to continue using Active Routes even after their SeqNum has
expired.
anyway? In which case, as you say below, there is no need for route
discovery, and these routers can all communicate already, without the need
for us to make any statement about forwarding data packets if an address is
in the Neighbor Table? I feel like I'm missing something...
Do you mean forwarding data packets? If we had two AODVv2 routers onbidirectional connectivity, i.e. was this RREP expected based on a RREQ we
the same IP subnet, and they wanted to send data packets to each other,
would they just go ahead and send them, since they are on the same subnet,
or do they need an explicit route to show that they are in range of each
other? Would they need to RREQ for a route to each other (if a route is not
already added from a neighbour table entry)?
In networks without any subnets, we will still have the same adjacency
forming
and neighborhood determination. Communication between addresses on the
same
subnet should never trigger Route Discovery. That would imply something
was
wrong with the router for that subnet.
I seem to remember that this was also a justification for a previous
specification
to enable unicast RREQ (i.e., to the neighbor, to get the sequence
number). Maybe
we should not go there before July :-) I could write it up as a short
new document
afterwards.
As above, my point was that is a router sent an unsolicited RREP_Ack to
try to get a router to take it off a blacklist, maybe this could disrupt
things. I wondered if we should test for this. Follow on is the point below.
multicast suppression table?
- Without being sure that we previously sent a message in the
opposite direction on this link, we cant be sure the link is
bidirectional.
Similarly for RREP - if a router sent an unexpected RREP (i.e. we didnt
forward the corresponding RREQ) we shouldn't assume this is proof of
bidirectional connectivity. Should we keep a list of RREQ's forwarded to
avoid this?
How much extra work is it to do this, given that we already have the
At the moment we store multicast RREQ or RREPs we have received and
regenerated. We'd need to also store any unicast RREQ we regenerate, and
also store RREQs we generated (both multicast and unicast) and RREPs we
generated (all multicast ones, but unicast ones only if AckReq is included
since we wouldnt be expecting a RREP_Ack otherwise) For all RREPs,
generated or regenerated, we will need to note whether we sent them with
AckReq included, so we need to add a flag to RteMsg entries for this.
At that point, I think we have to find a new name for the table.
Then for a received RREP, look for recently sent RREQ with matching
OrigAddr and TargAddr and MetricType, and if the entry has a TargSeqNum, it
should be a lower value than in the received RREP?
Well, O.K., but just regenerating the RREP hasn't been a problem in the
past even
without these consistency checks. I am O.K. either way, but on average
make more
mandates just in response to known problems.
The check I describe is the one that determines if this is a signal of
previously sent/regenerated. The regeneration function would happen as
normal. Although really, if the TargSeqNum in a RREP was lower than the
TargSeqNum in the corresponding RREQ, there's no point regenerating it.
And for a received RREP_Ack, look for recently sent RREP (which
included an AckReq), with an OrigAddr where Route[OrigAddr].NextHop =
RREP_Ack sender. Or really, should the RteMsg table store who we sent the
RREP to and we test for a match with that?
Either way... the second one is probably easier...
We'd also need to define what we mean by "recent". And we might need to
rename to "RteMsg Table" instead of "Multicast RteMsg Table", since we'll
be storing unicast messages too. The text would be updated to reflect that
it contains multicast messages for the purposes of avoiding regeneration of
redundant messages, and unicast messages to match any incoming replies to
verify bidirectional connectivity.
Maybe even add RERRs as discussed in previous emails, and call it the
Transmitted Message Table.
True, we could avoid processing a RERR if we received it before, but to
figure out if we'd received it before, we'd probably do as much work as we
would do by processing it anyway. And we only regenerate a RERR using the
routes that we deleted anyway, so if we have already processed it, a
duplicate RERR would result in no routes being deleted, and no
regeneration. I dont think we need to store RERRs...?
Also, "recent" would be within the timeouts associated with route
discovery (RREQ_WAIT_TIME) and RREP_Ack (RREP_Ack_SENT_TIMEOUT).
What do you think about adding this to the draft? It's a way to be sure
that a received RREP or RREP_Ack is indeed an indication of bidirectional
connectivity, and not a malicious RREP/RREP_Ack sent to fool us into
thinking this connectivity exists, but this email sums up all the changes
necessary...Is it worth it, or do we just talk about the threats?
Kind regards,
Vicky.
Regards,
Charlie P.
