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>
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] *On Behalf Of *Charlie Perkins
*Sent:* Thursday, October 08, 2015 4:55 PM
*To:* 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 email
in error, please delete it and immediately notify the sender.
_____________________________________________________
