Subject: [manet] AODVv2: Discussion Points

From: Victoria Mercieca <[email-masked]>
Date: Thu, 10 Sep 2015 14:15:53 +0100

Hello all,

Based on Thomas Clausen's comments on AODVv2 draft 11, we have identified
some points for discussion. I've listed them here, but perhaps any
discussion on these topics could be separated into new email threads, as I
realise this email is rather large already.

Topics for discussion:
======================

Lists or Sets
-------------
* Discussion

While we no longer require any ordering from RFC5444, the AODVv2 message
representation does require a sort of ordering. We have lists, so that we
can link addresses, prefix lengths, seqnums, metrics, etc. As an example,
entry 1 in the AddressList corresponds to entry 1 in the PrefixLengthList
and entry 1 in the SeqNumList, etc. Since some of the data elements are
optional, e.g., TargSeqNum in RREQ, we still have the idea of setting a
list entry to null.
Maybe there is a more elegant way we could do this....

Router Client
-------------
* Summary of comments

Terminology is awkward. It is easy to think "client/server" which is not
the case, plus the definition is not clear enough and makes it seem like
everything in the world could be classed as a client.

* Initial resolution

This has been addressed initially by updating the text to this:
"Router Client: An address or address range configured on an AODVv2 router,
corresponding to one or more nodes which require that router to initiate
and respond to route discoveries on their behalf, so that they can send and
receive IP traffic to and from remote destinations. The AODVv2 router's
interface addresses are also configured as Router Clients."

* Discussion

In OLSRv2 there is a Locally Attached Network Set. Should we adopt a
similar term?

This topic also relates to some confusion later in the document that:
"this indicates that a random AODVv2 router R will not generate a RREQ for
a destination unless the source address of the data packet requiring a
route to that destination also appears in the AODVv2 routers’ attached
network set — correct? It strikes me as something that should be said much,
much earlier in the document.
Also, that strikes me as a policy decision, which really is not for the
routing protocol to make, but for the network operator — it is not hard to
thin up situations where this proposed policy would be a constraint. Any
technical reasons why this policy decision is enforced?"

This comment is interpreted as saying "if another router forwarded me a
packet, but I don't have a route, why wouldn't I request one?" but the
answer (and maybe it could be classed as a policy) is that if we did that,
anyone could decide to forward packets to us, and cause us to send out
route requests. This could be a way to attack a router. Plus, if we did
send a RREQ on behalf of some remote node, what seqnum would we use in the
message, what metric? Do we have a route to OrigAddr in order to forward a
RREP toward it? Also, why is another router sending packets when a route
does not exist? We have defined that only OrigAddr's router, where it is
configured as a Router Client, is supposed to initiate route discovery on
its behalf.

The comment might also hint at fixing broken routes, but in that case we'd
still have the problem of what information to use in the request. We might
not have seqnum or metric info relating to OrigAddr. If we did, are these
up-to-date? It wouldn't be right to increment the seqnum, since that seqnum
belongs to another router: the seqnum used in the RREQ is the one
associated with OrigAddr, it needs to be the originator router's seqnum and
needs to be incremented by that router when a new RREQ is sent.

Besides, in this situation we use RERR to inform OrigAddr's router that we
dont have a route and it needs to find a new one.

Perhaps by clarifying what we mean by Router Client, this becomes
clearer...?

Adjacency and Neighbor
----------------------
* Summary of comments

These terms are confusing.

* Initial resolution

Tried to make text clearer about which neighbors are monitored, and how
this is done.

* Discussion

What AODVv2 wants to do is to verify connectivity to next hops on routes
learned. For routes to OrigAddr, learnt when a RREQ arrives, it tries to
verify connectivity only if a RREP comes back using this path. To do this,
when it sends the RREP to the next hop toward OrigAddr, it requests
acknowledgement in the form of an RREP_Ack to verify that the link to the
next hop is bidirectional. For routes to TargAddr, learnt from RREP
messages, it uses the RREP itself as the indicator that the link is
bidirectional (since the RREQ must have been sent on that link in the
opposite direction). If the RREP does not come back along this path, the
route to OrigAddr isn't necessary and does not need to be confirmed.

The Neighbor Table would contain info on all the AODVv2 routers which have
been heard from. AODVv2 routers dont advertise themselves in order to
populate a neighbor table, but fill in the table if and when messages
arrive from nearby routers.

Currently, we assume, as Thomas notes, "that link bidirectionality
properties are not time-varying? And so, once you have confirmed a link as
bidirectional, then it will remain so forever?" We could use
Neighbor.ResetTime to make Neighbor.State revert to Unknown from Confirmed
after a certain time, in order to force a new check for bidirectionality of
the link to the neighbor, the next time a RREP is sent to it. But any
routes using that neighbor as next hop should remain valid, I think.

With the list of other mechanisms that influence our neighbor state, we
wanted to allow that other processes may signal to AODVv2 that a link is
bidirectional, or is not bidirectional, or whether this is unknown. We've
given a couple of examples of when this may occur, but how other processes
would determine this information does not really matter. It matters that we
could react to these signals. I've made all this bit say MAY. It's really
optional. It could help, and if these signals mean that we avoid the
traffic and processing relating to acknowledgement messages, that's a good
thing. But AODVv2 is ultimately be able to figure out the bidirectionality
by itself using AckReq and RREP_Ack (which is mandatory to support).

Using Multiple Sequence Numbers
(see also "Multiple IP addresses, and Same IP Address on Different
Interfaces")
-------------------------------
* Summary of comments

Clarification is necessary. Should it be a seqnum per router client? That
would result in many different sequence numbers. Per router IP address? Per
router interface? Is the seqnum used in a message then the seqnum
associated with the interface on which the router client resides? Or the
outgoing interface/IP address of the AODVv2 message? It's currently not
clear.

* Initial resolution

We have reverted to having one sequence number per router.

* Discussion

Is there a benefit to multiple sequence numbers? It could be used for
logging on different interfaces or other purposes?

If multi-homing was to be supported in future, does it matter if one or
multiple seqnums are used per router? If the same seqnum (eg interface
seqnum, or router client seqnum, etc) is used in all messages about a
particular router client, I doubt it has an effect how many different
seqnums the router maintains. [The important part will be determining which
router originated the message and trying to compare against previously used
seqnums for that route from that originator to see if information is new.
This is covered in the discussion about "Multiple IP Addresses"...]

Multiple IP addresses, and Same IP Address on Different Interfaces
------------------------------------------------------------------
* Summary of comments

It's hard to be certain, from reading the -11 revision, how these are
handled. Also the multihoming appendix needs work.

* Discussion

Host with multiple IP addresses (on one interface)
A host which requires an AODVv2 router to perform route discovery may have
multiple IP addresses. Currently each IP address would be configured as a
Router Client. It wouldnt matter if these were multiple IP addresses on the
same interface. Each one would look like a different Router Client. This is
a feature.

Host with multiple IP addresses (on different interfaces)
This is also fine. If connected to an AODVv2 router on each interface, they
do not have an identical Router Client entry since the IP address on each
interface is different

Host with the same IP address on multiple interfaces
If connected to an AODVv2 router on each interface, each router would have
that same IP address as a Router Client. This is currently disallowed by
the draft. It could result in two AODVv2 routers advertising a route to
this address. As it stands, seqnums from different routers won't look
monotonic. In this case, a router receiving a route message from both
routers would decide based on sequence number which route it would install.
This would be non-optimal, since comparing sequence numbers from different
routers is meaningless, and the metric would not be tested. If Router A
issues the higher sequence number, it will always be preferred. Then,
Router B issuing the lower sequence number will be ignored as information
will look stale. This stops the Router B discovering routes on behalf of
the router client, if Router A has already requested it with a higher
seqnum. Hopefully Router A did find a route, and the router client chooses
to send data via Router A. Or maybe with a number of retries, Router B will
manage to send a RREQ on behalf of the router client, using a seqnum which
is higher than the matching RREQ Router A sent. This is all pretty ugly.

Router with multiple IP addresses (on one interface)
This affects how we deal with sequence numbers. The sequence number per
interface doesnt make sense here, since if multicasting, the message will
go out on multiple interfaces, so which seqnum would be used? Is it better
to use one sequence number per router? Or have a seqnum relating to each
interface where router clients are connected, and use the seqnum of the
relevant interface depending on the router client which is being advertised?

Router with the same IP address on multiple interfaces
This affects how we deal with sequence numbers. Again, if we had a seqnum
per interface, how would we know which interface seqnum to use in the
AODVv2 message? If we have a seqnum per router IP address, and we know
which IP address will be used as source IP of the RFC5444 packet, maybe its
easy to determine what seqnum to use. If we use a seqnum based on the
router client or interface on which the router client is attached, this
would also be OK.

Forwarding plane interaction
----------------------------
* Summary of comments

We have information that fits into this category sprinkled all over the
draft. We only have an appendix which details Features Required of IP. We
should collect all this info into one section, probably within the main
draft, and refer to it in the applicability statement.
Multiple comments that we need to address this in its own section. Which
signals are needed to/from, how to update route table, how queueing would
work.

* Discussion

If it would be clearer, we could create a new conceptual table of signals,
like:

    AODVV2_ROUTE_NEEDED      /* triggering RREQ */
    AODVV2_ROUTE_MISSING     /* for RERR */

AODVv2 Routing Set / FIB
------------------------
* Summary of comments

We need to be consistently clear that protocol operations are on a “routing
set only” and that said data structure is different from the routing table
/ FIB.

* Discussion

We could borrow the idea of a Routing Set of AODVv2 knowledge of routes,
valid or otherwise, and separately state how these get reflected in the
forwarding table, i.e. Unconfirmed and Invalid routes not to go in the
forwarding table.

There is also a comment that the information stored in Invalid routes is
available in the RteMsg table, so maybe we do not need an Invalid route.
This could also apply for Unconfirmed routes. Needs some careful analysis,
and we'd need to store extra info in the RteMsg table entries. If we have
the idea of the "Routing Set", this wouldnt be necessary.

Implementations can really put what routes they like where they like. We
already say "this is a conceptual structure which allows access to the
following information". If the draft refers to a Local Routing Set or
something similar, but clearly identifies which routes can be used for
forwarding and when, an implementation can store it how it likes.  Some
implementations may store this all in the forwarding table. I think its
just terminology, but think we need WG consensus on how we phrase/explain
this.

Applicability statement
-----------------------
* Summary of comments

Should point out issues, e.g., instead of “the ability to communicate is
more important than being assured of secure operations”, point out problems
in providing security, and let reader decide if this makes AODVv2
applicable to their situation.

This section needs work in other areas too...asymmetric link metrics, ...

Directional metrics, asymmetric links
-------------------------------------
* Summary of comments

How would the current version of AODVv2 work if link costs were different
in each direction?

* Discussion

Currently, TargRtr would install a route to OrigAddr with the cost of
OrigRtr's best path to TargRtr, and OrigRtr would install a route to
TargAddr with cost of the best path from TargRtr to OrigRtr. Wrong way
round. Intermediate nodes have the same problem. Their route to OrigAddr
has "cost = cost from OrigAddr to me" not the best path or the right cost
from its perspective to reach OrigAddr.

We could define that when processing a RREQ, we add up incoming link
metrics for links already traversed, i.e., at each router we keep adding
the cost to get from the message's previous hop to the current router.
After all the regenerated RREQs have been received, TargRtr will have
learned the route to OrigAddr which reflects the best path (lowest cost)
from OrigAddr to TargAddr. It's not correct for RREP_Gen to store a route
to OrigAddr with that cost, it's cost in the wrong direction. Anyway,
continuing...when regenerating the RREP, we should add up outgoing link
metrics back toward TargAddr, so that RREQ_Gen learns the outgoing cost
toward TargAddr. Then, OrigRtr has the best route to TargAddr, with the
correct cost.

We assume that the RREP follows the reverse of path the RREQ took. This may
not always be true. If any router receiving a RREQ already has a route to
OrigAddr, and the route is better than that offered by the RREQ, the better
route will remain in the routing table. The actual path the RREQ has
followed will be unknown when it reaches TargAddr's router, only the metric
will reflect the path. The RREP will then follow any existing routes to
OrigAddr, which may mean it does not go backwards along the same path of
routers which forwarded the RREQ. So the metric when the RREP reaches
RREQ_Gen might actually reflect a better path to TargAddr than the path the
RREQ followed. That's OK for RREQ_Gen and for OrigAddr, but there's a
mismatch between info at TargAddr's router about the route to OrigAddr, and
possibly other intermediate routers too.

If we calculated outgoing AND incoming route costs, including both costs in
every RteMsg, then each router could learn from an RREQ the best path to
OrigAddr by looking at the outgoing metrics toward OrigAddr, and from an
RREP, the best path to TargAddr by looking at the outgoing metrics toward
TargAddr. RREP_Gen could determine which RREQ gave the best incoming
metric, i.e., which one had followed the best path from OrigAddr toward
TargAddr, and would need to try to send the RREP back on that path, so that
RREQ_Gen and intermediate routers would learn the optimal path to TargAddr,
by looking at outgoing metrics toward TargAddr. However, if we've installed
the best route to OrigAddr based on outgoing metrics toward OrigAddr (which
of course we would do), then the next hops will all be for the best
outgoing route, resulting in the RREP following the best path in the
direction from TargAddr to OrigAddr, and so RREQ_Gen would not necessarily
learn the optimal path from OrigAddr to TargAddr. We'd need to store an
"incoming" route too, to say "this is the best way OrigAddr could route to
us", so that we could work out the reverse path on which to send any
RREPs....?

We need to write the draft to be generic enough to handle directional
metrics. We cant handle all this just by defining cost functions for each
metric type.

It may be more expedient to restrict the current draft to metrics that
don't have this problem.  The restriction would need to be added to the
Applicability Section.

New metric types
----------------------------------------
* Summary of comments

Requests for a separate section on how "requirements for adding new metric
types".

Also comments about having to write new code for different metric types in
future.

"For some metric types the best route is the one with lowest metric value,
for other metric types the best route is the one with highest metric value."
-"Ouch, this is not pleasant. Could we discuss this design decision with
the WG, please?"
-"Reading this, I understand Chris’ comment on “requiring to write new
code” — I do not like it. It would be nice, and it is indeed possible to,
construct the protocol such that you have a simple comparison of values,
with “shorter being better”. Of course, that would then impose that also as
applicable to the link metric definitions, which would have to be
accordingly (which is possible). That way, I would not need to “write new
code” in the routing process, when I come up with a new and fancy way of
setting a link metric; rather, it’d be a configuration and interface
matter, more than a “routing process” matter. But, even if one disregards
that point,having to stop and think “wait, is a big value good, or bad” is
unfortunate, [and, I think, rather untraditional]"

* Discussion

Should we restrict metric types to be only "cost" metrics?

Metrics which determine best routes based on *maximal* values (i.e., a
"benefit" metric) may not be required because if metric M is a "benefit"
metric, then metric N = 1/M will be a "cost" metric (i.e., measure routes
based on *minimal* values).

Otherwise, should (and could) we try to define the Cost and LoopFree
functions for when we are looking at additive/concave/convex/multiplicative
metrics? So that AODVv2 has in its implementation a way to deal with these
generic metric types rather than defining all specific metric types
(hopcount, bandwidth). The code could then be in place and people can
classify their metrics according to this idea?

MAX_TIME and route timeouts:
----------------------------
* Summary of comments

This is confusing.

Also, regarding ACTIVE_INTERVAL and MAX_IDLETIME: "According to the
parameters in the document, the former is 200s and the latter is 300s…I
wonder if there’s anything suggesting that this is worth it — secondarily,
I wonder if those figures/recommendations are not exceptionally large in
general?"

* Initial resolution

Edited the section on timeouts to try to avoid confusion, but could make
further changes to make sure its easily understood.

The timeouts are configurable.

* Discussion

Should we:
a) change MAX_TIME to INFINITY
b) set ExpirationTime to zero for a non-timed route and explain that zero
means there's no fixed time limit
c) keep resetting ExpirationTime to CurrentTime + ACTIVE_INTERVAL +
MAX_IDLETIME every time the route is used?

I would like to thank you in advance for any input which will help us
improve the draft.

Kind regards,
Victoria Mercieca.