A few questions from an outside observer (and a bit late to the party).
Can a route request contain more than one metric requested? (I think the
answer should be no) What happens if a new route request with a different
metric type is requested? Shouldn't the first different metric route be
removed somehow first? Unless there is something going on with TOS bits in
packets (and a way to transmit that information via AODVv2) I'm not sure
how multiple different metric types are going to work cleanly.
On Wed, Oct 7, 2015 at 5:09 AM, Victoria Mercieca <vmercieca0@xxxxxxxxx>
wrote:
Hi all,
I've been fussing over this for a while but I think it's ready... here is
what I have come up with to update the metrics section (pandoc style,
forgive the {#references}):
# 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.
I thought the hopcount-specific bit should go in a later section near the
metric type number allocations?:
The HopCount MetricType defines:
* MAX_METRIC[HopCount] := MAX_HOPCOUNT. A constant defined in
[](#constants). MAX_HOPCOUNT is also used to limit the number of hops an
AODVv2 message can travel, regardless of the MetricType in use. It MUST be
larger than the AODVv2 network diameter, in order that AODVv2 protocol
messages may reach their intended destinations.
* Cost(L) := 1
* Cost(R) := Sum of Cost(L) of each link in the route, i.e., the hop count
between the router calculating the cost, and the destination of the route
(OrigAddr if RREQ, TargAddr if RREP)
* LoopFree(R1, R2) := ( Cost(R1) \<= Cost(R2) ). This is derived from the
fact that route cost increases with number of hops. Therefore, an
advertised route with higher cost than the corresponding existing route
could include the existing route as a sub-section. Replacing the existing
route with the advertised route could form a routing loop. LoopFree returns
FALSE to indicate that an advertised route with higher cost is not to be
used to update a stored route. In the case where the existing route is
Invalid, it is possible that the advertised route includes the existing
route and came from a router which did not yet receive notification of the
route becoming Invalid, so the advertised route should not be used in case
it forms a loop to a broken route.
Comments welcome :-)
Kind regards,
Vicky.
