[aodvv2-discuss] Re: [manet] AODVv2 comments
- From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
- To: aodvv2-discuss@xxxxxxxxxxxxx
- Date: Wed, 25 Mar 2015 15:08:47 -0700
Hello Vicky,
I have been updating the draft corresponding to your suggestions, even
though it would
not be released for a while under the current plan.
Comments below:
On 3/25/2015 4:21 AM, Victoria Mercieca wrote:
Hi all,
A couple of comments based on Justin Dean's points:
On bidirectional connectivity:
.....
Suggested text for first paragraph in Section 6.2:
"AODVv2 routers SHOULD monitor connectivity to neighboring AODVv2
routers along active routes. If bidirectional connectivity does not
exist, routers should not share routing information using AODVv2. The
default approach for AODVv2 routers to monitor connectivity is to
request acknowledgement of Route Reply messages. To achieve this, the
RREP message includes an AckReq data element, to indicate that a
RREP_Ack message is required in response. The receiver of the RREP
will reply with a RREP_Ack message. Receipt of the acknowledgement
proves that bidirectional connectivity exists. See Sections 9.2 and
9.4 for further details.
Additionally, when routers perform other operations such as those from
the list below, these can be used as extra indications of connectivity."
Done.
Also, the bit that says
"For example, receipt of a Neighborhood Discovery message would signal
a connection to the sender. "
Should it be clarified like this:
"For example, receipt of a Neighborhood Discovery HELLO message with
the receiving router listed as a neighbour is a signal of
bidirectional connectivity." Connectivity isn't enough, we want
bidirectional, and a message on its own is not a signal of
bidirectional connectivity.
Done.
On the message reception and "only from neighbors":
Check 9.1.2 for RREQ. Is it correct to say "only from neighbours"
there? Step 2 checks the blacklist. I think we can delete Step 1.
I agree, and wish I would have caught this before submitting version 08.
9.3.2 for RERR - we always process RERR even if it comes from a
blacklisted router. Is that correct?
Right, but I don't think it needs to be made explicit. We could
conceivably remove the router from the blacklist. This could be done
already according to existing text at the end of section 6.2:
..................... If other
indications are received that a blacklisted router has restored
bidirectional connectivity, ......
then the router SHOULD be immediately removed from the
blacklist.
9.4.2 for RREP_Ack - should we always remove from the blacklist, even
if we didnt request the RREP_Ack? If a router was to send an
unsolicited RREP_Ack they could force removal of themselves from our
blacklist. Should step 1 and 2 be the other way around?
I think the argument could be made either way. If we receive RREP_Ack,
and the one-hop restriction is faithfully observed according to
msg_hop_limit, then we should not have the neighbor in the blacklist.
On the other hand, if a malicious neighbor were blasting out RREP_Ack
without ever intending to forward RREP, then we wouldn't want to help
it. On the third hand, such a neighbor would simply do the wrong thing
and nevertheless return RREP_Ack anyway upon AckReq, so worrying over
whether it was requested does not help at all.
I swapped the order of step 1 and step 2.
Regards,
Charlie P.
Other related posts:
