--- 1/draft-ietf-roll-minrank-hysteresis-of-00.txt 2011-03-01 02:16:32.000000000 +0100 +++ 2/draft-ietf-roll-minrank-hysteresis-of-01.txt 2011-03-01 02:16:32.000000000 +0100 @@ -1,18 +1,18 @@ Networking Working Group O. Gnawali Internet-Draft P. Levis Intended status: Standards Track Stanford University -Expires: April 14, 2011 October 11, 2010 +Expires: September 1, 2011 February 28, 2011 The Minimum Rank Objective Function with Hysteresis - draft-ietf-roll-minrank-hysteresis-of-00 + draft-ietf-roll-minrank-hysteresis-of-01 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 the Minimum Rank Objective Function with Hysteresis (MRHOF), an objective function that minimizes the node @@ -35,24 +35,24 @@ 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 April 14, 2011. + This Internet-Draft will expire on September 1, 2011. Copyright Notice - Copyright (c) 2010 IETF Trust and the persons identified as the + 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 @@ -60,24 +60,24 @@ 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 . . . . . . . . . . . . . . . . . 6 - 4. MRHOF Variables and Parameters . . . . . . . . . . . . . . . . 6 - 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 + 4. MRHOF Variables and Parameters . . . . . . . . . . . . . . . . 7 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction An objective function allows RPL [I-D.ietf-roll-rpl] to select paths that are best in terms of a given routing metric or select paths that meet certain constraints in terms of the routing metric. RPL @@ -93,23 +93,24 @@ 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 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. + MRHOF can be used only 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], @@ -172,32 +173,41 @@ 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. A node receives a new 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 metric advertisements or updates to the - selected link metric prevents results in node making parent selection - based on stale link and path information. + This computation MAY also be performed periodically. Deferring the + path cost computation for too long after new metric advertisements or + updates to the selected link metric results in nodes making parent + selection decision based on stale link and path information. 3.2. Parent Selection After computing the path cost 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. + 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 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. @@ -215,40 +225,47 @@ 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 is the only node in the parent set at a given + time. Any candidate neighbor may become the preferred parent as + indicated above. + 3.3. Computing Rank - Once a node selects its preferred parent, it can use the following - table to covert its path cost to the DAG root through its preferred - parent (written as Cost in the table) to its rank: + The DAG roots set their rank to MIN_PATH_COST for the selected + metric. + + Once a non-root node selects its preferred parent, it can use the + following table to covert its path cost to the DAG root through its + preferred 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. Node rank is undefined for these node/link metrics: Node state and - attributes, node fanout ratio, throughput, and link color. + attributes, throughput, and link color. 3.4. Advertising the 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 DIO messages are sent. @@ -269,35 +286,42 @@ 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 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: + 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.0. Switch to a new path only if it is - requires at least one fewer transmission than the current path. + 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. Acknowledgements + Thanks to Antonio Grilo, Nicolas Tsiftes, Matteo Paris, JP Vasseur + for their comments. + 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.