--- 1/draft-ietf-roll-minrank-hysteresis-of-09.txt 2012-04-26 19:13:51.822670915 +0200 +++ 2/draft-ietf-roll-minrank-hysteresis-of-10.txt 2012-04-26 19:13:51.846670750 +0200 @@ -1,19 +1,19 @@ Networking Working Group O. Gnawali Internet-Draft University of Houston Intended status: Standards Track P. Levis -Expires: October 24, 2012 Stanford University - April 22, 2012 +Expires: October 28, 2012 Stanford University + April 26, 2012 The Minimum Rank with Hysteresis Objective Function - draft-ietf-roll-minrank-hysteresis-of-09 + draft-ietf-roll-minrank-hysteresis-of-10 Abstract The Routing Protocol for Low Power and Lossy Networks (RPL) uses objective functions to construct routes that optimize or constrain the routes it selects and uses. This specification describes the Minimum Rank with Hysteresis Objective Function (MRHOF), an objective function that selects routes that minimize a metric, while using hysteresis to reduce churn in response to small metric changes. MRHOF works with metrics that are additive along a route, and the @@ -28,21 +28,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on October 24, 2012. + This Internet-Draft will expire on October 28, 2012. Copyright Notice Copyright (c) 2012 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 @@ -62,26 +62,26 @@ 3.2.1. When Parent Selection Runs . . . . . . . . . . . . . . 6 3.2.2. Parent Selection Algorithm . . . . . . . . . . . . . . 6 3.3. Computing Rank . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Advertising the Path Cost . . . . . . . . . . . . . . . . 8 3.5. Working Without Metric Containers . . . . . . . . . . . . 8 4. Using MRHOF for Metric Maximization . . . . . . . . . . . . . 9 5. MRHOF Variables and Parameters . . . . . . . . . . . . . . . . 9 6. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Device Configuration . . . . . . . . . . . . . . . . . . . 10 6.2. Device Monitoring . . . . . . . . . . . . . . . . . . . . 11 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction An objective function specifies how RPL [RFC6550] selects paths. For example, if an RPL instance uses an objective function that minimizes hop-count, RPL will select paths with minimum hop count. RPL requires that all nodes in a network use a common OF; relaxing this requirement may be a subject of future study. @@ -154,21 +154,22 @@ MRHOF may be used with any additive metric listed in [RFC6551] as long the routing objective is to minimize the given routing metric. Nodes MUST support at least one of these metrics: node energy, hop count, latency, link quality level, and ETX. Nodes SHOULD support the ETX metric. MRHOF does not support non-additive metrics. 3.1. Computing the Path cost Root nodes (Grounded or Floating) set the variable cur_min_path_cost - to MIN_PATH_COST. + to the metric value that most closely computes to a Rank of + MinHopRankIncrease. If a non-root node does not have metrics to compute the path cost through any of the candidate neighbors, it MUST join one of the candidate neighbors as a RPL Leaf. Otherwise, nodes compute the path cost for each candidate neighbor reachable on an interface. The path cost of a neighbor represents the cost of the path, in terms of the selected metric, from a node to the root of the DODAG through that neighbor. A non-root node computes a neighbor's path cost by adding two components: @@ -347,22 +348,22 @@ carried in the metric container corresponding to the selected metric when DIO messages are sent. If ETX is the selected metric, a node SHOULD NOT advertise it in a metric container. Instead, a node MUST advertise an approximation of its ETX in its advertised Rank value, following the rules described in Section 3.3. If a node receives a DIO with a metric container holding an ETX metric, MRHOF MUST ignore the ETX metric value in its Rank calculations. - DODAG Roots advertise a metric value which computes to a cost of - MIN_PATH_COST. + DODAG Roots advertise a metric value which mostly closely computes to + a Rank value of MinHopRankIncrease. 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 MUST NOT include a metric container in its DIO messages. @@ -396,23 +397,20 @@ 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 the cost of the path through the preferred parent and the minimum cost 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 set. ALLOW_FLOATING_ROOT: If set to 1, allows a node to become a floating root. @@ -421,22 +419,20 @@ determined. The working group has long experience routing with the ETX metric. Based on those experiences, these values are RECOMMENDED: 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: 172. Switch to a new path only if it is expected to require at least 1.5 fewer transmissions than the current path. As ETX is encoded as number of transmissions times 128, this is a threshold of 172. 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. ALLOW_FLOATING_ROOT: 0. Do not allow a node to become a floating @@ -446,28 +442,26 @@ Section 18 of [RFC6550] depicts the management of RPL. This specification inherits from that section and its subsections, with the exception that metrics as specified in [RFC6551] are not used and do not require management. 6.1. Device Configuration An implementation SHOULD allow the following parameters to be configured at installation time: MAX_LINK_METRIC, MAX_PATH_COST, - MIN_PATH_COST, PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and - ALLOW_FLOATING_ROOT. An implementation MAY allow these parameters to - be configured dynamically at run time once a network has been - deployed. + PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT. + An implementation MAY allow these parameters to be configured + dynamically at run time once a network has been deployed. A MRHOF implementation SHOULD support the DODAG Configuration option as described in [RFC6550] and apply the parameters it specifies. - Care should be taken in the relationship between the MRHOF PARENT_SWITCH_THRESHOLD parameter and the RPL MaxRankIncrease parameter. For example, if MaxRankIncrease is smaller than PARENT_SWITCH_THRESHOLD, a RPL node using MRHOF could enter a situation where its current preferred parent causes the nodes Rank to increase more than MaxRankIncrease but MRHOF does not change preferred parents: this could cause the node to leave the routing topology even though there may be other members of the parent set which would allow the node's Rank to remain within MaxRankIncrease.