Hello folks,
I did not get any feedback about whether you would like an Internet
Draft about RFC 6621 considerations.
I'll write one on Monday and float it past the group. Posting the new
draft does not have to wait for this. I'll also write a latency metric
draft. Both of these will be very short. The RFC 6621 draft will be,
at best, informational. Or, even better, [manet] will decide that it's
far too trivial to deserve publication.
Regards,
Charlie P.
On 10/9/2015 12:24 AM, Victoria Mercieca wrote:
Hi all,
I did a summary for myself the other day of issues I would like cleared up before publishing version 12. They were:
seqnum arithmetic text
directional metrics
metric types
RFC 6621 multicast reduction.
SEQNUM
---------------
I'm happy with the seqnum text if you all are. To summarise, the bit about the arithmetic says this (unchanged since I pasted it last time):
Comparing the sequence number will identify which information is stale. The currently stored sequence number is subtracted from the incoming sequence number. The result of the subtraction is to be interpreted as a signed 16-bit integer, and if less than zero, then the information in the AODVv2 message is stale and MUST be discarded.
I was wondering where to put in any reference to the Newer function Charlie wrote? And if we should we add any explanation that if the incoming sequence number is greater than the current seqnum by more than half the maximum value, then the incoming will be seen as stale? But that we dont care, because if that happened, something bigger is wrong...?
METRICS
---------------
I think this is resolved with the new text, if you all agree? I havent yet replaced it or moved the hopcount specific definitions to later in the document.
# Metrics {#metrics}
Metrics measure a cost or quality associated with a route or a link, e.g., latency, delay, financial cost, energy, etc. Metric values are reported in route messages, where the goal is to determine a route between OrigAddr and TargAddr. In Route Request messages, the metric describes the cost of the route from OrigAddr (the router client) to the router sending the Route Request. The receiving router calculates the cost from OrigAddr to itself, combining the metric value from the message with knowledge of the link cost from the sender to the receiver, i.e., the incoming link cost. This updated route cost is included when regenerating the Route Request message. In Route Reply messages, the metric reflects the cost of the route from TargAddr (the router client) to the router sending the Route Reply. Routes to OrigAddr and TargAddr are installed at intermediate routers for the purposes of forwarding a Route Reply message and subsequent data traffic between OrigAddr and TargAddr. Assuming link metrics are symmetric, the cost of the routes to OrigAddr and TargAddr installed at each router will be correct.
AODVv2 enables the use of multiple metric types. Each route discovery attempt indicates which metric type is requested for the route. For each MetricType, AODVv2 requires:
* A MetricType number, to indicate the metric type of a route. MetricType numbers allocated are detailed in [](#metric-type).
* A maximum value, denoted MAX_METRIC[MetricType]. If the cost of a route exceeds MAX_METRIC[MetricType], the route is ignored. AODVv2 cannot store routes that cost more than MAX_METRIC[MetricType].
* A function for incoming link cost, denoted Cost(L). Using incoming link costs means that the route learned has a path optimized for the direction from OrigAddr to TargAddr.
* A function for route cost, denoted Cost(R).
* A function to analyze routes for potential loops, denoted LoopFree(R1, R2). LoopFree verifies that a route R2 is not a sub-section of another route R1. An AODVv2 router invokes LoopFree() as part of the process in [](#test), when an advertised route (R1) and an existing route (R2) have the same destination address, metric type, and sequence number.
AODVv2 currently supports cost metrics where Cost(R) is strictly increasing, by defining:
* Cost(R) := Sum of Cost(L) of each link in the route
* LoopFree(R1, R2) := ( Cost(R1) \<= Cost(R2) )
Definitions of Cost and LoopFree functions for other metric types are future development tasks.
6621
-------
This bit still confuses me (sorry Charlie). I will take your collective advice on this section. The previous text:
Implementations are free to choose their own heuristics for reducing multicast overhead. Some methods for doing so are described in [](#RFC6621). AODVv2 does not specify which method to use to restrict the set of AODVv2 routers that have the responsibility to regenerate multicast messages. Note that multicast messages MAY be sent via unicast. For example, this may occur for certain link-types (non-broadcast media), for manually configured router adjacencies, or in order to improve robustness.
Which received comments about interoperability if different techniques were chosen at different routers, and also comments that tie in with my own confusion about how 6621 supports "flooding an identical copy of a message to all destinations inside the MANET" rather than the ability to modify the message before retransmitting which is what we need.
Regarding interoperability:
Stan's suggested text, slightly altered by Charlie's comment:
Any text changed in the spec needs to include the above. Here’s my suggested text: “Implementations MAY choose to employ techniques to reduce the number of multicast messages sent. Use of {RFC 6621] in deployments is recommended. Employing [RFC 6621] in a subset of the operational AODVv2 routers in a network will not cause interoperability issues, but might reduce the effectiveness of the multicast reduction scheme.”
I've replaced the current text with this suggestion. Just checking though - Does the same apply if the 6621 setup uses different algorithms on different routers?...in which case I should add that to the text to make it extra clear.
If we're all in agreement on this I can make the final updates tonight. Could do with some proofreading again I think, but we could post to MANET on Monday?
Kind regards,
Vicky.
On Thu, Oct 8, 2015 at 10:02 PM, Ratliff, Stanley <sratliff@xxxxxxxxxxx <mailto:sratliff@xxxxxxxxxxx>> wrote:
Yes, unless there are pressing issues that are hanging (Pressing,
of course, being in the eye of the beholder). Hence, I guess, the
reason for the email. J
Regards,
Stan
*From:*aodvv2-discuss-bounce@xxxxxxxxxxxxx
<mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx>
[mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx
<mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx>] *On Behalf Of
*Charlie Perkins
*Sent:* Thursday, October 08, 2015 4:55 PM
*To:* aodvv2-discuss@xxxxxxxxxxxxx
<mailto:aodvv2-discuss@xxxxxxxxxxxxx>
*Subject:* [aodvv2-discuss] Re: Stock take
Shouldn't we issue the draft ASAP?
Regards,
Charlie P.
On 10/8/2015 10:45 AM, John Dowdell wrote:
Hi all
We need to be on final approach for Yokohama now. What open
issues are we facing please, and which of these do we need to
take to the manet list?
Thanks
John
_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the
individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this
in error, please delete it and immediately notify the sender.
_____________________________________________________
