[aodvv2-discuss] Follow-up #1 for proposals in December to close issues
- From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
- To: aodvv2-discuss@xxxxxxxxxxxxx
- Date: Wed, 21 Jan 2015 13:37:04 -0800
Hello folks,
This is in preparation for our discussion on Friday.
These proposed resolutions for AODVv2 open issues did not
generate any comments. I would like to go ahead with the
resolutions. In my next email, I will summarize the
discussion for the other issue resolutions that I proposed
last month.
============================================================
[manet] #2: Terminology for reactive protocol document
Close this issue with a request for more specific comments
about particular terms or definitions.
============================================================
[manet] #10: Reporting multiple broken routes whose metric types are
different
Reject the proposal suggested in the issue text, and
close the issue including the following discussion:
"Metrics for anything other than hop-count would essentially
trigger unicast RERR messages anyway and there would be little
gain from the aggregation."
============================================================
[manet] #16: The Reactive Protocol Duplicate Suppression Table
Suggest the following resolution on the mailing list in order
to solicit comments:
'Put all AODVv2 messages into the duplicate suppression table.
The change is easy, but involves replacing "RREQ" with
"AODVv2 message" in a number of places.'
============================================================
[manet] #24 (aodvv2): Ordering of processing instructions
Close the issue 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, we can close this issue.
============================================================
[manet] #30 (aodvv2): Use of word "node"
Close the issue with the following text for the resolution:
'The uses of "node" in the document have been checked, and many
were changed to "addr" instead as noted in previous emails.
More specific terminology has been used where appropriate.'
============================================================
[manet] #31 (aodvv2): Suitability for implementation on commodity OS
Close this issue and redirect comments to issue #46.
============================================================
#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.
Suggest this on the mailing list as a proper resolution.
============================================================
Other related posts:
