Subject: [manet] Enabling alternate metrics

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 30 Nov 2012 11:58:09 -0800

Hello folks,

As mentioned in previous email, enabling alternate metrics has been
a topic often discussed in the MANET working group.  There seems to
be wide recognition of the insufficiency of using HopCount.  However,
the selection of "best" route can be tricky, because that depends
on the application.  Also, some considerations from
"draft-ietf-manet-olsrv2-metrics-rationale-01.txt" apply.

If it is agreed that AODVv2 needs to enable specification for the
use of alternate routing metrics, there is a relatively straightforward
way to do it, as long as the purpose of doing so is also agreed as
above.
In the AODVv2 document, the main changes required are:
- include the following new section
- change discussion about HopCount to instead refer to "Cost()"
- refer to a table of Metric Types (e.g., as in RFC 6551)
- use abstract functions "Cost()" and "LoopFree()"
- allow for storage of multiple routes to the same destination
   but which allow the metric type to identify different next hops.

=======================================================================

5.6.  Enabling Alternate Metrics

    Route selection in AODVv2 MANETs depends upon associating metric
    information with each route table entry.  When presented with
    candidate route update information, deciding whether to use the
    update involves evaluating the metric.  Some applications may require
    the consideration of metric information other than Hop Count, which
    has traditionally been the default metric associated with routes in
    MANET.  In fact, it is well known that reliance on Hop Count can
    cause selection of the worst possible route in many situations.

    It is beyond the scope of this document to describe how applications
    specify route selection at the time they launch processing.  One
    possibility would be to provide a route metric preference as part of
    the library routines for opening sockets.  In view of the above
    considerations, it is important to enable route selection based on
    metric information other than Hop Count -- in other words, based on
    "alternate metrics".  Each such alternate metric identifies a "cost"
    of using the associated route, and there are many different kinds of
    cost (latency, delay, financial, energy, etc.).

    The most significant change when enabling use of alternate metrics is
    to require the possibility of multiple routes to the same
    destination, where the "cost" of each of the multiple routes is
    measured by a different alternate metric.  The other change relevant
    to AODVv2 is that the method by which route updates are tested for
    usefulness has to be slightly generalized to depend upon a more
    abstract method of evaluation which, in this document, is named
    "Cost(R)", where 'R' is the route information to be evaluated.  From
    the above, the route table information for 'R' must always include
    the type of metric by which Cost(R) is evaluated, so the metric type
    does not have to be shown as a distinct parameter for Cost(R).  Since
    determining loop freedom is known to depend on comparing the Cost(R)
    of route update information to the Cost(R) of an existing stored
    route using the same metric, AODVv2 must also be able to invoke an
    abstract routine which in this document is called "LoopFree(R1, R2)".
    LoopFree(R1, R2) returns TRUE when, given that R2 is loop-free and
    Cost(R2) is the cost of route R2, Cost(R1) is known to guarantee loop
    freedom of the route R1.  In this document, LoopFree(R1,R2) will only
    be invoked for routes R1 and R2 which use the same metric.

    Generally, HopCount may still be considered the default metric for
    use in MANETs, notwithstanding the above objections.  Each metric has
    to have a Metric Type, and the Metric Type is allocated by IANA as
    specified in [RFC6551].  Each Route has to include the Metric Type as
    part of the route table entry for that route.  Hop Count has Metric
    Type assignment 3.  The Cost of a route using Metric Type 3 is
    naturally the Hop Count between the router and the destination.  For
    routes R1 and R2 using Metric Type 3, LoopFree (R1, R2) is TRUE when
    Cost(R2) <= (Cost(R1) + 1).  The specification of Cost(R) and
    LoopFree(R1,R2) for metric types other than 3 is beyond the scope of
    this document.

=======================================================================

By the way, Ian always hated HopCount as a metric, and so there was
always an attempt to specify DYMO to enable alternate metrics.
To my understanding, however, that effort was incomplete.

-- 
Regards,
Charlie P.

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 1 Dec 2012 03:21:20 +0100

Hi Charlie,

Regarding the suggested main changes required, as one was for possible
of having multi-next-hop per dest, I am thinking to add another
requirement;

- All intermediate routers in the path to destination should have same
metric type while forwarding packets to their nexthop, otherwise an
error reported.

AB

On 11/30/12, Charles E. Perkins <[email-masked]> wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>