[aodvv2-discuss] Responding to MANET comments
- From: Victoria Mercieca <vmercieca0@xxxxxxxxx>
- To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
- Date: Fri, 14 Aug 2015 15:52:11 +0100
On Fri, Aug 14, 2015 at 3:17 PM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:
Hello folks,
Shall I summarize the resolution for Chris's comments?
I'd rather someone else do it, but it has to be done very soon...
Regards,
Charlie P.
Hi Charlie,
I was just looking at that. I didnt realise we hadnt responded to Chris.
I'd say the ones we havent fully resolved are:
- same address on multiple interfaces
- not including non hopcount metrics
- we could explain the reason for why a stored invalid route can’t be
overwritten by a new higher metric route, from our earlier emails, I think
i did update the draft too with a bit of explanation.
- IP’s routing table being separate, and forwarding rules
- situations where RREQs are not regenerated?
- IANA comments may not be completely addressed as Chris wanted
- security section hasnt been changed:
(Section 13, para 4, what’s said is true, but it’s not as simple as this
makes it appear. (And there are issues of information leakage in other
layers.)
Section 13, use of sequence number as timestamp is good. Should think about
how fast 16 bits wraps and if that’s an issue. (Not saying it is, just food
for thought.)
Section 13, specifying TIMESTAMP data, suggest indicate algorithm number.)
- Appendix A hasnt changed.
This actually looks like a lot of unresolved points :( but they mostly
overlap with Thomas Clausen's comments which I guess we will go to the
mailing list to discuss...
In regards to Thomas' comments, I was drafting an email to respond and
start discussion on the recurring issues he highlighted. I should also go
through our most recent emails to identify anything outstanding. If you
would like to respond to Chris, I could respond to Thomas? My summary is
included below in case anyone wants to check it before I send?
Regards,
Vicky.
Summary of Thomas's points for discussion:
Router Client
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. 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."
Could be further improved. In OLSR there is a Locally Attached Network Set.
Adjacency and Neighbor
These terms are confusing.
-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, and when it
sends the RREP to the next hop toward OrigAddr, it requests the 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 routes to OrigAddr and TargAddr aren't necessary.
-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.
Multiple IP addresses, and same IP address on different interfaces
It's hard to be certain, from reading the -11 revision, how these are
handled.
-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.
-If the same IP address was used on multiple interfaces of a host, it might
be necessary that multiple AODVv2 routers would then have that 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. In this case, a
router receiving a route message from each 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. The
multihoming appendix needs to be included
-A router might have multiple IP addresses per interface. 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 revert to using 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?
Forwarding plane interaction
Clearly we need to address this, in its own section. Which signals are
needed to/from, how to update route table, how queueing would work.
-Routing Table: could have the idea of a Routing Set of AODVv2 knowledge of
routes, valid or otherwise, and separately how these get reflected in the
forwarding table.
Lists or Sets
While we no longer require any ordering from RFC5444, the AODVv2 data
elements do require a sort of ordering. We have lists, so that we can match
addresses, prefix lengths, seqnums, metrics, etc. 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, we still
have the idea of setting a list entry to null.
Maybe we need to rethink the way we do this.
Applicability statement
Should point out issues, e.g., in providing security, and let reader decide
if this makes AODVv2 applicable to their situation. This section needs work
in other areas too...asymmetric links, ...
Directional metrics, asymmetric links
How would the current version of AODVv2 work if link costs were different
in each direction? Currently TargRtr would install a route to OrigAddr with
the cost of OrigRtr's path to TargRtr, and OrigRtr would install a route to
TargAddr with cost of path from TargRtr to OrigRtr. Wrong way round.
-We could define that we add up outgoing link metrics for links traversed.
So for the route to OrigAddr, at each router we keep adding the cost to get
back to the next hop toward OrigAddr.
-Since RREP goes back the way it came, it doesnt necessarily learn the best
path.
Requirements for adding new metric types
We need a section on this.
-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.
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 specific metric types (hopcount,
bandwidth). The code could then be in place and people can classify their
metrics according to this idea?
LoopFree and metric comparisons
Confusion because sequence number not mentioned in this section. A newer
SeqNum is seen to be a guarantee of loop free information but this section
only talks about metric values.
MAX_TIME and route timeouts are confusing.
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've edited the section on timeouts a bit to avoid confusion but we need to
make sure its easily understood.
----
Other related posts:
