Networking Working Group                                      O. Gnawali
Internet-Draft                                                  P. Levis
Intended status: Standards Track                     Stanford University
Expires: September 1, October 29, 2011                             February 28,                                 April 27, 2011

          The Minimum Rank Objective Function with Hysteresis
                draft-ietf-roll-minrank-hysteresis-of-01
                draft-ietf-roll-minrank-hysteresis-of-02

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 uses
   objective functions to construct routes that optimize or constrain a routing metric on
   the paths. routes it selects and uses.  This specification describes the
   Minimum Rank Objective Function with Hysteresis (MRHOF), an objective
   function that minimizes the node
   rank in terms of selects routes that minimize a given metric, while using
   hysteresis to prevent
   excessive rank churn.  The use of reduce churn in response to small metric changes.
   MRHOF works with RPL results in nodes
   selecting stable paths metrics that minimize are additive along a route, and the given routing
   metric to it uses is determined by the
   roots of a Directed Acyclic Graph (DAG). metrics RPL Destination
   Information Object (DIO) messages advertise.

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 September 1, October 29, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   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 cost  . . . . . . . . . . . . . . . . . .  4
     3.2.  Parent Selection . . . . . . . . . . . . . . . . . . . . .  5
     3.3.  Computing Rank . . . . . . . . . . . . . . . . . . . . . .  6
     3.4.  Advertising the path cost Path Cost  . . . . . . . . . . . . . . . .  7
     3.5.  Working Without Metric Containers  . . . 6 . . . . . . . . .  7
   4.  Using MRHOF for Metric Maximization  . . . . . . . . . . . . .  7
   5.  Settings of RPL parameters . . . . . . . . . . . . . . . . . .  8
   6.  MRHOF Variables and Parameters . . . . . . . . . . . . . . . . 7
   5.  8
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
   6.  9
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 8
   7.  9
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . . 8
   8.  9
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     8.1.  9
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 8
     8.2.  9
     10.2. Informative References . . . . . . . . . . . . . . . . . . 8  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 10

1.  Introduction

   An objective function allows specifies how RPL [I-D.ietf-roll-rpl] to select selects
   paths.  Objective functions can choose paths
   that are best in terms of a given based on routing metric metrics
   or select paths that
   meet certain constraints in terms of the routing metric.  RPL
   achieves this goal by selecting the parent among the alternate
   parents as dictated by that objective function. constraints.  For example, if an RPL instance uses an objective
   function that minimizes hop-count, RPL will select paths with minimum
   hop count.

   The nodes running RPL might use a number of metrics to describe a
   link or a node [I-D.ietf-roll-routing-metrics] and make it available
   for route selection.  A metric can be used by different  These metrics are advertised in RPL Destination
   Information Object (DIO) messages using a Metric Container suboption.
   An objective
   functions function can use these metrics to optimize or constrain choose routes.

   To decouple the metric in different ways.

   This specification describes MRHOF, details of an individual metric or objective function for RPL.
   MRHOF uses hysteresis while selecting
   from forwarding and routing, RPL describes routes through a value
   called Rank.  Rank, roughly speaking, corresponds to the path distance
   associated with a route.  An objective function is responsible for
   computing a node's advertised Rank value based on the Rank of its
   potential parents, metrics, and other network properties.

   This specification describes MRHOF, an objective function for RPL.
   MRHOF uses hysteresis while selecting the path with the smallest
   metric value.  The path with metric that MRHOF uses is determined by the minimum cost has different property
   depending on
   metrics in the metric used for path selection. DIO Metric Container.  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 only be used only with an 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 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] [I-D.ietf-roll-routing-metrics].

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

   Worst parent:  The node in the parent set with the largest 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 path cost while
   preventing excessive churn in the network.  It does so by switching
   to finding the
   minimum cost path and switching to that path only if the path cost it is shorter
   (in terms of the current path is
   larger cost) than the path cost of the minimum cost current path by at least 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 cost

   Nodes compute the path cost for each candidate neighbor reachable on
   all the interfaces.
   an interface.  The Path cost 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_cost
   to MIN_PATH_COST.

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

   1.  The  If the selected metric is a link metric, the selected metric for
       the link to a candidate neighbor.  If the selected metric is a
       node metric, the selected metric for the node.

   2.  The value of the selected metric in the metric container in the
       DIO sent by that neighbor.

   A node SHOULD compute the path cost for the path through each
   candidate neighbor reachable through all the interfaces. an interface.  If a node cannot
   compute the path cost for the path through a candidate neighbor, the
   node MUST NOT select the candidate neighbor as its preferred parent parent,
   with one exception.  If the node does not have metrics to compute the
   path cost through any of the candidate neighbors, it SHOULD MUST join one of
   the candidate neighbors as a leaf node.

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

   If the selected metric is a node metric, and the metric is not
   available, the path cost through all the neighbors SHOULD be set to
   MAX_PATH_COST.

   The path cost corresponding to a neighbor SHOULD be re-computed each
   time:

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

   2.  If the selected metric is a node metric and the metric is
       updated.

   3.  A node receives a new metric advertisement from the candidate
       neighbor.

   This computation MAY also be performed periodically.  Deferring  Too much delay
   in updating the path cost computation for too long after new the metric advertisements is updated or
   updates to the selected link a new metric results in nodes making parent
   selection decision based on
   advertisement is received can lead to stale link and path information. Rank or parent set.

3.2.  Parent Selection

   After computing the path cost for all the candidate neighbors
   reachable through all the interfaces an interface for the current DODAG iteration, a
   node selects the preferred parent.  This process is called parent
   selection.  Parent Selection SHOULD be performed each time:

   1.  The path cost for an existing candidate neighbor, including the
       preferred parent, changes.  This condition can be checked
       immediately after the path cost is computed.

   2.  A new candidate neighbor is inserted into the neighbor table.

   The parent selection MAY be deferred until a later time.  Deferring
   the parent selection can delay the use of better paths or stopping
   the use of worse paths than what is available in available in
   the network.

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

   1.  If the smallest path cost for paths through the candidate
       neighbors is smaller than cur_min_path_cost 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 cost and that the
       smallest path cost is smaller than cur_min_path_cost 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 candidate
       neighbors on the path with the minimum cost.

   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_cost is greater than MAX_PATH_COST, 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
       parent, and MUST set cur_min_path_cost to MAX_PATH_COST.

   The preferred parent

   Except in the cases above, the candidate neighbor on the path with
   the smallest path cost is the only preferred parent.  A node MAY include a
   total of PARENT_SET_SIZE candidate neighbors in the parent set.  The
   cost of path through the nodes in the parent set at a given
   time.  Any candidate neighbor may become is smaller than or
   equal to the cost of the paths through any of the nodes that are not
   in the parent set.  If the cost of the path through the preferred
   parent as
   indicated above. and the worst parent is too large, a node MAY keep a smaller
   parent set.

3.3.  Computing Rank

   The DAG roots set their rank to MIN_PATH_COST for the selected
   metric.

   Once a non-root node selects its preferred parent, parent set, it can use the following
   table to covert its the the path cost to of the DAG root through its
   preferred worst parent (written as
   Cost in the table) to its rank:

                    +--------------------+------------+
                    |  Node/link Metric  |    Rank    |
                    +--------------------+------------+
                    |     Node Energy    | 255 - Cost |
                    |      Hop-Count     |    Cost    |
                    |       Latency      | Cost/65536 |
                    | Link Quality Level |    Cost    |
                    |         ETX        |    Cost    |
                    +--------------------+------------+

                  Table 1: Conversion of metric to rank.

   Nodes MUST support at least one of the above metrics.  Nodes SHOULD
   support the ETX metric.

   Node rank is undefined for these node/link metrics: Node state and
   attributes, throughput, and link color.  If the rank is undefined,
   the node MUST join one of the neighbors as a leaf node.

3.4.  Advertising the path cost Path Cost

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

3.5.  Working Without Metric Containers

   In the absence of metric container, MRHOF uses ETX as its metric.  It
   locally computes the ETX of links to its neighbors and adds this
   value to their advertised Rank to compute the associated Rank of
   routes.  Once parent selection and rank computation is performed
   using the ETX metric, the node advertises a Rank equal to the ETX
   cost and SHOULD NOT include a metric container in its DIO messages.

4.  Using MRHOF for Metric Maximization

   MRHOF cannot be directly used for parent selection using metrics
   which require finding paths with maximum value of the selected
   metric, such as path reliability.  It is possible to convert such a
   metric maximization problem to a metric minimization problem and use
   MRHOF provided:

      There is a fixed and well-known maximum metric value corresponding
      to the best path.  This is the path cost for the DAG root.
      Example, the best link reliability has a value of 1.

      Metrics are all positive.  Example, link reliability is always
      positive.

   For metrics meeting the above conditions, the problem of maximizing
   the metric value is equivalent to minimizing the negative of the
   metric value.  MRHOF is not required to work with these metrics.

5.  Settings of RPL parameters

   The MinHopRankIncrease parameter MUST be set to 1.

6.  MRHOF Variables and Parameters

   MRHOF uses the following variable:

      cur_min_path_cost: The cost 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_COST: Maximum allowed value for the path metric of a
      selected path.

      MIN_PATH_COST: 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 in order
      to trigger the selection of a new preferred parent.

      PARENT_SET_SIZE: The number of candidate parents, including the
      preferred parent, in the parent selection. set.

   The parameter values are assigned depending on the selected metric.
   The best values for these parameters should be experimentally
   determined.  The working group has long experience routing with the
   ETX metric.  Based on those experiences, these ETX parameters are
   known to work in many settings:

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

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

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

      PARENT_SWITCH_THRESHOLD: 1.5.  Switch to a new path only if it is
      expected to require at least 1.5 fewer transmission than the
      current path.

5.

      PARENT_SET_SIZE: 3.  If the preferred parent is not available, two
      candidate parents are still available without triggering a new
      round of route discovery.

7.  Acknowledgements

   Thanks to Antonio Grilo, Nicolas Tsiftes, Matteo Paris, JP Vasseur Vasseur,
   and Phoebus Chen for their comments.

6.

8.  IANA Considerations

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

7.

9.  Security Considerations

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

8.

10.  References

8.1.

10.1.  Normative References

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

8.2.

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

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