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, 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 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.  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.

   The nodes running RPL might use a number of metrics to describe a
   link [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 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:

   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.


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.

   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 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.

   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: gnawali@cs.stanford.edu


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

   Email: pal@cs.stanford.edu
































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