[aodvv2-discuss] Some proposed resolutions for AODVv2 issues in the issue tracker
- From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
- To: aodvv2-discuss@xxxxxxxxxxxxx
- Date: Wed, 31 Dec 2014 07:54:11 -0800
Hello folks,
Here are some proposed resolutions for AODVv2 open issues.
Let's have another teleconference as soon as people are back from
holiday revelry.
============================================================
[manet] #2: Terminology for reactive protocol document
I propose to close this issue with a request for more specific comments
about particular terms or definitions.
Alternatively we could request more specific comments but leave the
issue open.
============================================================
[manet] #10: Reporting multiple broken routes whose metric types are
different
The simplest thing to do would be to simply require multiple RERR messages.
If that's not sufficient, then additional functionality could be added
in the future.
My guess is that metrics for anything other than hop-count would essentially
trigger unicast RERR messages anyway and there would be little gain from the
aggregation.
This would mean "rejecting" the proposal suggested in the issue text, and
closing the issue.
============================================================
[manet] #16: The Reactive Protocol Duplicate Suppression Table
It is quite easy to put RREPs into the duplicate suppression table as well.
In fact, it should be done for any AODVv2 message regardless of type, as
best I can tell.
The change is easy, but involves replacing "RREQ" with "AODVv2 message"
in a number of places.
============================================================
[manet] #23 (aodvv2): Format of processing algorithms
Proposal was to await input from Vicky. However, I can also do this.
It needs more eyes than mine, though, regardless of who writes it.
============================================================
[manet] #24 (aodvv2): Ordering of processing instructions
Close the issue after resolving issue #23. Or close it now, with a
request for
people to append relevant comments to issue #23 instead of this issue.
============================================================
[manet] #27 (aodvv2): Processing AckReq
Recent drafts have included the requested clarification.
To avoid repeated failure of Route Discovery, an AODVv2 router
(HandlingRtr) handling a RREP message MUST attempt to verify
connectivity towards RREQ_Gen. This MAY be done by including the
Acknowledgement Request (AckReq) data element in the RREP. In reply
to an AckReq, an RREP_ACK message message MUST be sent.
With this clarification, the issue may reasonably be considered to be
resolved.
I updated the issue tracker with the above text, but did not yet close the
issue. I propose to go ahead and close the issue after a week or two have
gone by, but leave it open for now in case anyone has more comments.
============================================================
[manet] #30 (aodvv2): Use of word "node"
I updated the issue tracker with the discussion from various people.
This is mainly an idiotic issue. I have refrained from comment because
I just get so aggravated.
For example, RFC 4294. Anyone who claims that "node" is mysterious
terminology is either unqualified to be in the IETF or else just being a
(well, the proper word does not fit in polite email).
I have checked on uses of "node" in the document, and many were changed
to "addr" instead as noted in previous emails. More specific terminology
has been used where appropriate.
I think we can close the issue.
============================================================
[manet] #31 (aodvv2): Suitability for implementation on commodity OS
I propose to close this issue contingent upon proper resolution of issue
#46.
============================================================
[manet] #32 (aodvv2): Multicast transmission
I updated the issue tracker with some discussion from Abdussalam.
We should ask Adrian if we can close this issue.
============================================================
[manet] #34 (aodvv2): Section 13 must be removed
I updated the issue tracker with the discussion from Abdussalam.
I propose to review the suggested section and close the issue. But we
should definitely discuss this.
============================================================
[manet] #35 (aodvv2): A constant is constant
I updated the issue tracker but did not yet close the
issue. I propose to go ahead and close the issue after a week or two have
gone by, but leave it open for now in case anyone has more comments.
This would amount to essentially rejecting the proposed issue
("wontfix").
============================================================
#46 (aodvv2): What is needed from IP and ICMP
Write an appendix with the following text:
AODVv2 needs the following:
* information that IP routes are requested
* information that packets are flowing
* the ability to queue packets.
Tautologically, a reactive protocol reacts when a route is needed. One
might say that a route is requested when an application tries to send
a packet. The fundamental concept of reactive routing is to avoid
creating routes that are not needed, and the way that has been used to
know whether a route is needed is when an application tries to send a
packet.
If an application tries to send a packet, and the route is available,
the packet has to wait until the route is available.
============================================================
Other related posts:
