Subject: [Roll] Comments on draft-gnawali-roll-minrank-hysteresis-of-00

From: JP Vasseur <[email-masked]>
Date: Wed, 16 Jun 2010 15:29:29 +0200

Dear authors,

Please find some comments in line. Several comments are cosmetic and  
editorial.
The main two comments are:
1) why standardizing the hysteresis mechanism (other mechanisms may  
apply), this is a local
decision, ...
2) at least parameters should not be tied to a specific routing metric.

[Docs] [txt|pdf|html] [Email] [Nits]

Versions: 00

Networking Working Group                                      O. Gnawali
Internet-Draft                                                  P. Levis
Intended status: Standards Track                     Stanford University
Expires: December 16, 2010                                 June 14, 2010

           The Minimum Rank Objective Function with Hysteresis
               draft-gnawali-roll-minrank-hysteresis-of-00

Abstract

    Hysteresis delays the effect of changes in link metric on parent
    selection.  Such delay makes the topology stable despite jitters in
    link metrics.  The Routing Protocol for Low Power and Lossy Networks
    (RPL) allows the use of objective functions to construct routes that
    optimize or constrain a routing metric on the paths.  This
    specification describes MRHOF,

JP> Expand acronym when first used

an objective function that minimizes
    the node rank in terms of a given metric, while using hysteresis to
    prevent excessive rank churn.  The use of MRHOF with RPL results in
    nodes selecting stable paths that minimize the given routing metric
    to the DAG

JP> Expand acronym when first used
roots.

Status of this Memo

    This Internet-Draft is submitted to IETF in full conformance with  
the
    provisions of BCP 78 and BCP 79.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.

    Internet-Drafts are draft documents valid for a maximum of six  
months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt.

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.

    This Internet-Draft will expire on December 16, 2010.

Copyright Notice

    Copyright (c) 2010 IETF Trust and the persons identified as the

Gnawali & Levis         Expires December 16, 2010               [Page 1]

Internet-Draft  draft-gnawali-roll-minrank-hysteresis-of       June 2010

    document authors.  All rights reserved.

    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
    carefully, as they describe your rights and restrictions with  
respect
    to this document.  Code Components extracted from this document must
    include Simplified BSD License text as described in Section 4.e of
    the Trust Legal Provisions and are provided without warranty as
    described in the BSD License.

Table of Contents

    1.   
Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
    2.   
Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
    3.  The Minimum Rank Objective Function with  
Hysteresis . . . . . . 4
      3.1.  Computing the Path  
metric . . . . . . . . . . . . . . . . . 4
      3.2.  Parent  
Selection  . . . . . . . . . . . . . . . . . . . . . 5
      3.3.  Advertising the path  
metric . . . . . . . . . . . . . . . . 6
    4.  MRHOF Variables and  
Parameters  . . . . . . . . . . . . . . . . 6
    5.   
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
    6.  IANA  
Considerations . . . . . . . . . . . . . . . . . . . . . . 7
    7.  Security  
Considerations . . . . . . . . . . . . . . . . . . . . 7
    8.   
References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
      8.1.  Normative  
References  . . . . . . . . . . . . . . . . . . . 7
      8.2.  Informative  
References  . . . . . . . . . . . . . . . . . . 7
    Authors'  
Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7

Gnawali & Levis         Expires December 16, 2010               [Page 2]

Internet-Draft  draft-gnawali-roll-minrank-hysteresis-of       June 2010

1.  Introduction

    An objective function allows RPL [I-D.ietf-roll-rpl] to optimize or
    constrain the routing metric of a path.

JP> Just a comment on terminology. I guess that you meant "to optimize  
a path against a routing metric and
optionally support constraints"

RPL achieves this goal by
    selecting the parent among the alternate parents as dictated by that
    objective function.  For example, if an RPL instance uses an
    objective function that minimizes hop-count, RPL will select paths
    with minimum hop count.  Different objective functions optimize or
    constrain metrics differently.

JP> The OF being decoupled from the metric, does not indicate which  
metric to optimize or which constraint to
use. I know that you know but the text might be a bit confusing in  
that respect.

    The nodes running RPL might use a number of metrics to describe a
    link

JP> or a node

[I-D.ietf-roll-routing-metrics] and make it available for route
    selection.  A metric can be used by different objective functions to
    optimize or constrain the metric in different ways.

    This specification describes MRHOF, an objective function for RPL.
    MRHOF uses hysteresis while selecting the path with the smallest
    metric value.  The path with the minimum metric value

JP> Just to be consistent with the usual terminology in routing, call  
it "the path with minimum cost"

has different
    property depending on the metric used for path selection.  For
    example, the use of MRHOF with the latency metric allows RPL to find
    stable minimum-latency paths from the nodes to a root in the DAG
    instance.  The use of MRHOF with the ETX metric allows RPL to find
    the stable minimum-ETX paths from the nodes to a root in the DAG
    instance.

    MRHOF can be used with additive metric that must be minimized on the
    paths selected for routing.  Although MRHOF can be used with a  
number
    of metrics, this draft is based on experiences with the ETX metric.

2.  Terminology

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
    "OPTIONAL" in this document are to be interpreted as described in  
RFC
    2119 [RFC2119].

    This terminology used in this document is consistent with the
    terminologies described in [I-D.ietf-roll-terminology],
    [I-D.ietf-roll-rpl], and [I-D.ietf-roll-routing-metrics].

    This document introduces two term:

JP> s/term/terms

    Selected metric:  The metric chosen by the network operator to use
          for path selection.  This metric can be any additive metric
          listed in [I-D.ietf-roll-routing-metrics]

Gnawali & Levis         Expires December 16, 2010               [Page 3]

Internet-Draft  draft-gnawali-roll-minrank-hysteresis-of       June 2010

    Path metric:  Path metric quantifies a property of an end-to-end
          path.  Path metric is composed using the selected metric of  
the
          links along the path.  Path metrics can be used by RPL to
          compare different paths.

JP> want to call it Path Cost ?

3.  The Minimum Rank Objective Function with Hysteresis

    The Minimum Rank Objective Function with Hysteresis, MRHOF, is
    designed to find the paths with the smallest metric values while
    preventing excessive churn in the network.  It does so by switching
    to the minimum metric path only if the path metric of the current
    path is larger than the path metric of the minimum metric path by a
    given threshold.  MRHOF may be used with any additive metric listed
    in [I-D.ietf-roll-routing-metrics] as long the routing objective is
    to minimize the given routing metric.  MRHOF cannot be used if the
    routing objective is to maximize the metric.

3.1.  Computing the Path metric

    Nodes compute the path metric for each candidate neighbor reachable
    on all the interfaces.  The Path metric represents the cost of the
    path, in terms of the selected metric, from a node to the root of  
the
    DODAG through the neighbor.

    Root nodes (Grounded or Floating) set the variable
    cur_min_path_metric to MIN_PATH_METRIC.

    A non-root node computes the path metric for a path to the root
    through each candidate neighbor by adding these two components:

    1.  The selected metric for the link to a candidate neighbor.

    2.  The cur_min_path_metric advertised by that neighbor.

JP> What you call cur_min_path_metric is the value of the metric field  
for a global metric.

    A node SHOULD compute the path metric for the path through each
    candidate neighbor reachable through all interfaces.  If a node
    cannot compute the path metric for the path through a candidate
    neighbor, the node MUST NOT make that candidate neighbor its
    preferred parent.

    If the selected metric of the link to a neighbor is not available,
    the path metric for the path through that neighbor SHOULD be set to
    MAX_PATH_METRIC.  This metric value will prevent this path from  
being
    considered for path selection.

    The path metric corresponding to a neighbor MUST be re-computed each
    time:

Gnawali & Levis         Expires December 16, 2010               [Page 4]

Internet-Draft  draft-gnawali-roll-minrank-hysteresis-of       June 2010

    1.  The selected metric of the link to the candidate neighbor is
        updated.

    2.  A node receives a new cur_min_path_metric advertisement from the
        candidate neighbor.

    This computation MAY also be performed periodically.  However, long
    intervals between periodic computation or deferring the computation
    for too long after new cur_min_path_metric advertisements or updates
    to the selected link metric prevents results in node making parent
    selection based on stale link and path information.

3.2.  Parent Selection

    After computing the path metric for all the candidate neighbors
    reachable through all the interfaces for the current DODAG  
iteration,
    a node selects the preferred parent.  This process is called parent
    selection.

    A node MUST select a candidate neighbor as its preferred parent if
    the path metric corresponding to that neighbor is smaller than the
    path metric corresponding to the rest of the neighbors, except as
    indicated below:

    1.  If the smallest path metric for paths through the candidate
        neighbors is smaller than cur_min_path_metric by less than
        PARENT_SWITCH_THRESHOLD, the node MAY continue to use the  
current
        preferred parent.

    2.  If there are multiple paths with the smallest path metric and
        that smallest path metric is smaller than cur_min_path_metric by
        at least PARENT_SWITCH_THRESHOLD, a node MAY use a different
        objective function to select the preferred parent among the
        candidates

JP> Not sure of what you mean here ... Why using a different OF ? Did  
you mean "MAY use a different preferred parent" ?

which are first hop on the path with the smallest path
        metric.

    3.  A node MAY declare itself as a Floating root, and hence no
        preferred parent, depending on the configuration.

    4.  If the selected metric for a link is greater than
        MAX_LINK_METRIC, the node SHOULD exclude that link from
        consideration for parent selection.

JP> I see two issues here;
1) This is tied to the ETX metric
2) Why should we standardize such a local decision?

    5.  If cur_min_path_metric is greater than MAX_PATH_METRIC, the node
        MAY declare itself as a Floating root.

    6.  If the configuration disallows a node to be a Floating root and
        no neighbors are discovered, the node does not have a preferred

Gnawali & Levis         Expires December 16, 2010               [Page 5]

Internet-Draft  draft-gnawali-roll-minrank-hysteresis-of       June 2010

        parent, and MUST set cur_min_path_metric to MAX_PATH_METRIC.

3.3.  Advertising the path metric

    Once the preferred parent is selected, the node sets its
    cur_min_path_metric variable to the path metric corresponding to the
    preferred parent.  Thus, cur_min_path_metric is the cost of the path
    with the smallest path metric from the node to the root.  The value
    of the cur_min_path_metric is carried in the metric container
    whenever DIO messages are sent.

4.  MRHOF Variables and Parameters

    MRHOF uses the following variable:

       cur_min_path_metric: The path metric of the path from a node
       through its preferred parent to the root computed at the last
       parent selection.

    MRHOF uses the following parameters:

       MAX_LINK_METRIC: Maximum allowed value for the selected link
       metric for each link on the path.

       MAX_PATH_METRIC: Maximum allowed value for the path metric of a
       selected path.

       MIN_PATH_METRIC: The minimum allowed value for the path metric of
       the selected path.

       PARENT_SWITCH_THRESHOLD: The difference between metric of the  
path
       through the preferred parent and the minimum-metric path to
       trigger new preferred parent selection.

    The parameter values are assigned depending on the selected metric.
    Here is an example parameter assignment for the ETX metric:

       MAX_LINK_METRIC: 10.  Disallow links with greater than 10  
expected
       transmission count on the selected path.

       MAX_PATH_METRIC: 100.  Disallow paths with greater than 100
       expected transmission count.

       MIN_PATH_METRIC: 0.  At root, the expected transmission count is
       0.

Gnawali & Levis         Expires December 16, 2010               [Page 6]

Internet-Draft  draft-gnawali-roll-minrank-hysteresis-of       June 2010

       PARENT_SWITCH_THRESHOLD: 1.0.  Switch to a new path only if it is
       requires at least one fewer transmission than the current path.

5.  Acknowledgements

6.  IANA Considerations

    This specification requires an allocated OCP.  A value of 1 is
    requested.

7.  Security Considerations

    Security considerations to be developed in accordance to the output
    of the WG.

8.  References

8.1.  Normative References

    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2.  Informative References

    [I-D.ietf-roll-routing-metrics]
               Vasseur, J. and D. Networks, "Routing Metrics used for
               Path Calculation in Low Power and Lossy Networks",
               draft-ietf-roll-routing-metrics-01 (work in progress),
               October 2009.

    [I-D.ietf-roll-rpl]
               Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing
               Protocol for Low power and Lossy Networks",
               draft-ietf-roll-rpl-05 (work in progress), December 2009.

    [I-D.ietf-roll-terminology]
               Vasseur, J., "Terminology in Low power And Lossy
               Networks", draft-ietf-roll-terminology-01 (work in
               progress), May 2009.

Gnawali & Levis         Expires December 16, 2010               [Page 7]

Internet-Draft  draft-gnawali-roll-minrank-hysteresis-of       June 2010

Authors' Addresses

    Omprakash Gnawali
    Stanford University
    S255 Clark Center, 318 Campus Drive
    Stanford, CA  94305
    USA

    Phone: +1 650 725 6086
    Email: [email-masked]

    Philip Levis
    Stanford University
    358 Gates Hall, Stanford University
    Stanford, CA  94305
    USA

    Email: [email-masked]

Gnawali & Levis         Expires December 16, 2010               [Page 8]

Html markup produced by rfcmarkup 1.90, available from http://tools.ietf.org/tools/rfcmarkup/