Subject: [manet] AODVv2 comments

From: Justin Dean <[email-masked]>
Date: Tue, 24 Mar 2015 14:32:24 -0500

Overview: There are uses of unicast and multicast which (I don't think) are
correct.  The flow of information and messages might be similar to unicast
and multicast but I believe that there is processing happening at each hop
based on the flow of information.  Disseminated throughout and forwarded
would be more appropriate IMO.

Route maintenance consists of two operations.....(It's not clear what they
are)

It's also a bit verbose for an overview, for example

When a data packet is received to be forwarded
   but there is no valid route for the destination, then the AODVv2
   router of the source of the packet is notified via a Route Error
   (RERR) message.  Each upstream router that receives the RERR marks
   the route as Invalid.  Before such an upstream AODVv2 router could
   forward a packet to the same destination, it would have to perform
   route discovery again for that destination.  RERR messages are also

When a data packet is received to be forwarded, and no valid route exists,
a error message is generated to inform upstream routers of the error. Route
discovery would re-establish the route.

(I'm jumping around a bit now) Bi-directional requirement and text in
document isn't IMO sufficient (there are too many "optional" ways without
guidance on how to configure them and what happens if things are miss
configured. What happens if I'm using AODVv2 with NHDP for neighbor
discovery but another version is using the AckReq method. Do things break?
I think they do based on 9.2.2 RREP Reception step "1. A router MUST handle
RREPs only from neighbors. RREPs from nodes that are not neighbors MUST be
disregarded." You won't be my neighbor via NHDP so I disregard
it...Actually I don't see how AckReq method would work at all with this
first step. The change might be as easy as formally defining neighbor (i.e.
an AODVv2 router without an address not on the blacklist from which a
message was received), but I could be wrong...I'm wrong 9.4.2 RREP_Ack
Reception has the same first step so if the address is in the blacklist it
would get dropped before removing itself from the blacklist (if that
definition was used). Another functionality issue with RREP_Ack method...
Step 3. ..."the required RREP_Ack has been received (how is it known it's
required nothing was recorded in the generation section on which Acks were
requested in section RREP_Ack Generation) and cancels the associated
timeout." (which timeout? assuming RREP_Ack_SENT_TIMEOUT but it should be
specified) Also the neighbor gets added to the blacklist but won't the
previous hops still have invalid upstream routes to the source?

4. Applicability Statement

"each AODVv2 router can also route on behalf of other non-routing
nodes that are directly reachable via its network interfaces."

and

"When AODVv2 is
   the only protocol interacting with the forwarding table, AODVv2 MAY
   be configured to perform route discovery for all unknown unicast
   destinations."

Means that all "gateway routers" will reply for EACH address request.
Is my guess correct?  At the very least it could be more clear.  Also
how does the "Router Client and Client Networks" know where the AODVv2
router addresses are reachable via the AODV router.  I assume this has
to be manually configured with a set of "known" aodv addresses or some
sort of route injection.

And I'm done for now...this is not a full review, but hits on my major
issues I have with the current document.

Justin

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 24 Mar 2015 19:46:40 -0700

Hello Justin,

Thanks for your comments.  Here is some follow-up.

On 3/24/2015 12:32 PM, Justin Dean wrote:
> Overview: There are uses of unicast and multicast which (I don't 
> think) are correct.  The flow of information and messages might be 
> similar to unicast and multicast but I believe that there is 
> processing happening at each hop based on the flow of information.  
> Disseminated throughout and forwarded would be more appropriate IMO.

The use of the word "multicast" can properly be replaced by 
"disseminated".  However, the RREP is indeed unicast towards OrigAddr.  
The description makes it clear that the message is regenerated at each hop.

>
> Route maintenance consists of two operations.....(It's not clear what 
> they are)

Route maintenance consists of two operations: continuously
       extending the lifetime of active routes, and invalidating
       routes that cannot be used to forward packets.
> When a data packet is received to be forwarded, and no valid route 
> exists, a error message is generated to inform upstream routers of the 
> error. Route discovery would re-establish the route.

I basically used your wording but included the idea that the RERR message
is used for this.

> configured.

Mainly what goes wrong from the AODVv2 point of view is that RREQs
can get forwarded in circumstances that would never allow a RREP to be
returned to the router originating the RREQ.  The AckReq / RREP_Ack
mechanism just has to protect against that.

> What happens if I'm using AODVv2 with NHDP for neighbor
> discovery but another version is using the AckReq method.

AckReq and RREP_Ack are mandated for implementation.  We wanted to
allow for NHDP to be used if available.  What's the best way to say that
without requiring NHDP for every implementation of AODVv2?

> Do things
> break? I think they do based on 9.2.2 RREP Reception step "1. A router
> MUST handle RREPs only from neighbors. RREPs from nodes that are not
> neighbors MUST be disregarded." You won't be my neighbor via NHDP so
> I disregard it...Actually I don't see how AckReq method would work at
> all with this first step.

Step 1 should simply be deleted.  If a node is receiving
a RREP, the sender thinks it's a neighbor.  The AckReq in the RREP would be
for the purpose of verifying bidirectional connectivity to the sender.

> The change might be as easy as formally defining
> neighbor (i.e. an AODVv2 router without an address not on the blacklist
> from which a message was received), but I could be wrong...I'm wrong
> 9.4.2 RREP_Ack Reception has the same first step so if the address is in
> the blacklist it would get dropped before removing itself from the 
> blacklist
> (if that definition was used).

Similarly,  step one in 9.4.2 can simply be deleted.  There is no 
specification
for regeneration of RREP_Ack, so compliant devices would not do such a
bad thing.  Plus, RREP_Ack is generated with msg_hop_limit := 1.

These verification steps would make more sense when RFC 5082 can be
employed.

> Another functionality issue with RREP_Ack method... Step 3. ..."the 
> required RREP_Ack has been received (how is it known it's required 
> nothing was recorded in the generation section on which Acks were 
> timeout." (which timeout? assuming RREP_Ack_SENT_TIMEOUT but it should 
> be specified) Also the neighbor gets added to the blacklist but won't 
> the previous hops still have invalid upstream routes to the source?

Section 9.2.1 has the following specification:
    The AckReq data element indicates that an acknowledgement to the RREP
    has been requested.  If no corresponding RREP_Ack is received within
    the RREP_Ack_SENT_TIMEOUT, the next hop is added to the blacklist as
    discussed in Section 6.2.

I will add some text to Step 3 cross-referencing this requirement:
      " , in response to an AckReq data element that the
       router included in a preceding RREP message as specified in 
Section 9.2.1"

This should clarify the need.

> "each AODVv2 router can also route on behalf of other non-routing nodes that are directly reachable via its network interfaces."
> and
> "When AODVv2 is
> Means that all "gateway routers" will reply for EACH address request.  Is my guess correct?

Yes, that is correct.  I added text for your observation.

> Also how does the "Router Client and Client Networks" know where the 
> AODVv2 router addresses are reachable via the AODV router. I assume 
> this has to be manually configured with a set of "known" aodv 
> addresses or some sort of route injection.

In the previous paragraph, it is stated:
       Each AODVv2 router,
       if serving router clients other than itself, SHOULD be configured 
with
       information about the IP addresses of its clients, using any suitable
       method.

Doesn't this say what you requested?

Regards,
Charlie P.