Hi all,
Hows this...?
AODVv2 enables the use of multiple metric types. Each route discovery
attempt indicates the metric type which
is requested for the route. Only one metric type may be used in each route
discovery attempt. However, routes
to a single destination might be requested for different metric types. The
decision of which of these routes
to use for forwarding is outside the scope of AODVv2.
Regards,
Vicky.
On Tue, Oct 13, 2015 at 4:58 AM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:
Hello Justin,
Vicky was going to post release 12 right away. I don't know if she can
incorporate updates for these points.
Follow-up below:
On 10/12/2015 7:08 PM, Justin Dean wrote:
Can a route request contain more than one metric requested? (I think the
answer should be no)
Correct. The answer is no. This restriction should be put into the
specification if it is not already there.
I would be O.K. with silently discarding offending RREQs, but a more
complicated idea would be to create a new class of RERR messages.
What happens if a new route request with a different metric type is
requested?
It would make a new route without affecting the old route.
Shouldn't the first different metric route be removed somehow first?
I don't think so.
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.
Usually it's done by offering a layer-2 interface to put the special
handling into effect, for instance if priority handling is required.
How that is made accessible to the application is not within the
jurisdiction of AODVv2, but using different port numbers and special socket
parameters would be a good option.
Regards,
Charlie P.
On Wed, Oct 7, 2015 at 5:09 AM, Victoria Mercieca < <vmercieca0@xxxxxxxxx>
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.
