I've snipped a lot out of the metrics section, but to really accomplish
removing references to other metric types we should get rid of stuff
throughout the draft - Metric Type number allocations, references to the
MetricType data element in the message processing sections? - do we want
to do that?
Here's my cut down version so far if you would like to skim over it? Should
I cut more out of here, and cut Metric Type number allocations and
references to the MetricType data element too?
Regards,
Vicky.
# Metrics {#metrics}
Metrics measure a cost or quality associated with a route or a link, e.g.,
latency, delay, financial cost, energy, etc. AODVv2 enables the use of
multiple metric types. Each metric type that can be used in AODVv2 has a
MetricType number. Numbers allocated are detailed in [](#metric-type).
However, the mechanisms documented here may not be sufficient to deal with
asymmetric links.
A DEFAULT_METRIC_TYPE is configured on each AODVv2 router so that any
AODVv2 messages generated which are associated with that metric type do not
need to explicitly include an indication of that metric type. This means
that when a metric type is not included in a message, DEFAULT_METRIC_TYPE
is assumed. When sending information about routes with non-default metric
types, the MetricType data element MUST be included.
AODVv2 defines a maximum value for each MetricType, denoted
MAX_METRIC[MetricType]. When the cost of a route is calculated, and it
exceeds
MAX_METRIC[MetricType], the route is ignored. AODVv2 cannot store routes
that cost more than MAX_METRIC[MetricType].
* 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.
Metric values are reported in route messages. In Route Request messages,
where the goal is to determine a route between OrigAddr and TargAddr, the
metric describes the cost of the route from OrigAddr to the sending router.
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 route cost is
used to determine whether to update an existing route, and is included in
regenerated Route Request messages. In Route Reply messages, the metric
reflects the cost of the route from OrigAddr to TargAddr.
AODVv2 defines cost functions for both link cost and route cost. <!--
Cost(Li) and Cost(Lo) in future? -->
* Cost(L) for incoming link cost. Using incoming link costs means that the
route learned has a path optimized for the direction from OrigAddr to
TargAddr. For the HopCount metric type, Cost(L) := 1
* Cost(R) for route cost. For the HopCount metric type, 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)
AODVv2 defines a LoopFree function to assist in route evaluations, to
verify that a route R2 is not a part of another route R1. LoopFree returns
TRUE if
R2 cannot be a sub-section of the route R1. When comparing an advertised
route to an existing route for the same destination and the same metric
type,
and when the sequence numbers are equal, the metric value MUST be examined
to ensure that using the advertised route does not create any routing
loops.
An AODVv2 router invokes LoopFree() as part of the process in [](#test).
The advertised route (AdvRte) is used as parameter R1, and the existing
route
(Route) is used as parameter R2.
* LoopFree(R1, R2) for the HopCount metric type, returns TRUE when the cost
of R1 is less than or equal to the cost of R2, i.e., Cost(R1) \<= Cost(R2)
The LoopFree function for the HopCount metric type 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.
Definitions of Cost and LoopFree functions for other metric types are
future development tasks.
