--- 1/draft-ietf-roll-minrank-hysteresis-of-05.txt 2012-03-07 02:13:57.558671596 +0100 +++ 2/draft-ietf-roll-minrank-hysteresis-of-06.txt 2012-03-07 02:13:57.582670601 +0100 @@ -1,18 +1,18 @@ Networking Working Group O. Gnawali Internet-Draft P. Levis Intended status: Standards Track Stanford University -Expires: September 5, 2012 March 4, 2012 +Expires: September 7, 2012 March 6, 2012 The Minimum Rank with Hysteresis Objective Function - draft-ietf-roll-minrank-hysteresis-of-05 + draft-ietf-roll-minrank-hysteresis-of-06 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 Objective Function with Hysteresis (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 @@ -27,21 +27,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 September 5, 2012. + This Internet-Draft will expire on September 7, 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 @@ -51,72 +51,75 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified 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 . . . . . . . . . . . . . . . . 7 - 3.5. Working Without Metric Containers . . . . . . . . . . . . 7 + 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 . . . . . . . . . . . . . 8 - 5. MRHOF Variables and Parameters . . . . . . . . . . . . . . . . 8 - 6. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 9 - 6.1. Device Configuration . . . . . . . . . . . . . . . . . . . 9 - 6.2. Device Monitoring . . . . . . . . . . . . . . . . . . . . 10 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 + 5. MRHOF Variables and Parameters . . . . . . . . . . . . . . . . 9 + 6. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6.1. Device Configuration . . . . . . . . . . . . . . . . . . . 10 + 6.2. Device Monitoring . . . . . . . . . . . . . . . . . . . . 11 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction An objective function specifies how RPL [I-D.ietf-roll-rpl] selects - paths. Objective functions can choose paths based on routing metrics - or constraints. For example, if an RPL instance uses an objective - function that minimizes hop-count, RPL will select paths with minimum - hop count. The RPL specification requires the use of a common OF by - all nodes in a network. The possible use of multiple OFs with a - single network is for further study. + 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. 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. These metrics are advertised in RPL Destination - Information Object (DIO) messages using a Metric Container suboption. - An objective function can use these metrics to choose routes. The - only exception is the ETX metric, which is used without the metric - container as described in Section 3.5. + link or a node [I-D.ietf-roll-routing-metrics] and make these metrics + available for route selection. RPL advertises metrics in RPL + Destination Information Object (DIO) messages with a Metric Container + suboption. An objective function can use these metrics to choose + routes. To decouple the details of an individual metric or objective function from forwarding and routing, RPL describes routes through a value called Rank. Rank, roughly speaking, corresponds to the 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. + associated with a route. RPL defines how nodes decide on paths based + on Rank and advertise their Rank. An objective function defines how + nodes calculate Rank, 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 metric that MRHOF uses is determined by the metrics in the 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. + from the nodes to a root in the DAG instance. In the absence of a + metric in the DIO Metric Container or the lack of a DIO Metric + Container, MRHOF defaults to using ETX to compute Rank, as described + in Section 3.5. - MRHOF can only be used with an additive metric that must be minimized - on the paths selected for routing. + Because MRHOF seeks to minimize path costs as described by metrics, + it can only be used with additive metrics. MRHOF ignores metrics t 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], @@ -130,56 +134,62 @@ Path cost: Path cost quantifies a property of an end-to-end path. Path cost is 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 + The Minimum Rank with Hysteresis Objective Function, MRHOF, is designed to find the paths with the smallest path cost while preventing excessive churn in the network. It does so by finding the minimum cost path and switching to that path only if it is shorter (in terms of path cost) than the current path by at least a given - threshold. MRHOF may be used with any additive metric listed in + 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. + 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 - Nodes compute the path cost for each candidate neighbor reachable on - 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 MinHopRankIncrease. + 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: + 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: 1. 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 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, - with one exception. If the 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 leaf node. + except if it cannot compute the path cost through any neighbor, in + which case it may join as a leaf as described above. 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. @@ -190,124 +200,152 @@ 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. Too much delay in updating the path cost after the metric is updated or a new metric - advertisement is received can lead to stale Rank or parent set. + advertisement is received can lead to stale information. 3.2. Parent Selection After computing the path cost for all the candidate neighbors reachable through 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: + selection. To allow hysteresis, parent selection maintains a + variable, cur_min_path_cost, which is the path cost of the current + preferred parent. + +3.2.1. When Parent Selection Runs + + A MRHOF implementation SHOULD perform Parent Selection 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 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. +3.2.2. Parent Selection Algorithm - 2. If there are multiple paths with the smallest path cost and 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 candidate - neighbors on the path with the minimum cost. + If the selected metric for a link is greater than MAX_LINK_METRIC, + the node SHOULD exclude that link from consideration during parent + selection. - 3. A node MAY declare itself as a Floating root, and hence no - preferred parent, depending on the configuration. + A node MUST select the candidate neighbor with the lowest path cost + as its preferred parent, except as indicated below: - 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. + 1. A node MAY declare itself as a Floating root, and hence have no + preferred parent, depending on system configuration. - 5. If cur_min_path_cost is greater than MAX_PATH_COST, the node MAY + 2. If cur_min_path_cost is greater than MAX_PATH_COST, the node MAY declare itself as a Floating root. - 6. If ALLOW_FLOATING_ROOT is 0 and no neighbors are discovered, the + 3. 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. This is the hysteresis component of MRHOF. + + 4. If ALLOW_FLOATING_ROOT is 0 and no neighbors are discovered, the node does not have a preferred parent, and MUST set cur_min_path_cost to MAX_PATH_COST. - Except in the cases above, the candidate neighbor on the path with - the smallest path cost is the 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 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 and the worst parent is too large, a node MAY keep a smaller - parent set. + If there are multiple neighbors which share the smallest path cost, a + node MAY use a different objective function to select which of these + neighbors should be considered to have the lowest cost. + + A node MAY include up to PARENT_SET_SIZE-1 additional candidate + neighbors in its parent set. The cost of path through the nodes in + the parent set 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 and the worst parent is too + large, a node MAY keep a smaller parent set than PARENT_SET_SIZE. + + Once the preferred parent is selected, the node sets its + cur_min_path_cost variable to the path cost corresponding to the + preferred parent. The value of the cur_min_path_cost is carried in + the metric container corresponding to the selected metric when DIO + messages are sent. 3.3. Computing Rank - The DAG roots set their rank to MinHopRankIncrease. + DAG roots set their Rank to MinHopRankIncrease. Once a non-root node selects its parent set, it can use the following - table to covert the path cost of the worst parent (written as Cost in - the table) to its Rank: + table to covert the path cost of a parent (written as Cost in the + table) to a Rank value: +--------------------+------------+ | 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. + 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 RPL Leaf node according + to [I-D.ietf-roll-rpl]. - If this Rank calculation causes the increase in Rank between a node - and its worst parent to be less than MinHopRankIncrease, the node - sets its Rank to the Rank of its worst parent plus - MinHopRankIncrease. + MRHOF uses this Rank value to compute the Rank it associates with the + path through each member of the parent set. The Rank associated with + a path through a member of the parent set is the maximum of the + corresponding calculated Rank value from above and that node's + advertised Rank plus MinHopRankIncrease. - 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 according to - [I-D.ietf-roll-rpl]. + A node sets its Rank to the maximum of three values: + + 1. The Rank associated with the path through the preferred parent + + 2. The Rank of the member of the parent set with the highest + advertised Rank plus one + + 3. The Rank of the path through the member of the parent set with + the highest path cost, minus MaxRankIncrease + + The first case is the Rank associated with the path through the + preferred parent. The second case covers requirement 4 of Rank + advertisements in Section 8.2.1 of [I-D.ietf-roll-rpl]. The third + case ensures that a node does not advertise a Rank which then + precludes it from using members of its parent set. 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 - highest cost element of the parent set. Thus, cur_min_path_cost is - the cost of the highest cost path from the node to the root through a - member of the parent set. The value of the cur_min_path_cost is + cur_min_path_cost variable to the path cost corresponding to its + preferred parent. It then calculates the metric it will advertise in + its metric container. This value is the path cost of the member of + the parent set with the highest path cost. Thus, while + cur_min_path_cost is the cost through the preferred parent, a node + advertises the highest cost path from the node to the root through a + member of the parent set. The value of the highest cost path is carried in the metric container corresponding to the selected metric when DIO messages are sent. If ETX is the selected metric, cur_min_path_cost is directly used as Rank and never advertised in a metric container. + DODAG Roots advertise a metric value which computes to a cost of + MIN_PATH_COST. + 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. 4. Using MRHOF for Metric Maximization @@ -343,23 +381,23 @@ 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_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. 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 @@ -367,23 +405,24 @@ 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: 1.5. Switch to a new path only if it is - expected to require at least 1.5 fewer transmission than the - current path. + 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 root. 6. Manageability @@ -410,20 +449,30 @@ 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. Unless configured otherwise, a MRHOF implementation SHOULD use the default parameters as specified in Section 5. + Because of the partially-coupled relationship between Rank and metric + values, networks using MRHOF require care in setting + MinHopRankIncrease. A large MinHopRankIncrease will cause MRHOF to + be unable to select paths with different hop counts but similar + metric values. If MinHopRankIncrease is large enough that its + increment is greater than that caused by link cost, then metrics will + be used to select a preferred parent but the advertised Rank will be + a simple hopcount. This behavior might be desirable, but it also + might be unintended: care is recommended. + 6.2. Device Monitoring A MRHOF implementation should provide an interface for monitoring its operation. At a minimum, the information provided should include: DAG information as specified in Section 6.3.1 of [I-D.ietf-roll-rpl], and including the DODAGID, the RPLInstanceID, the Mode of Operation, the Rank of this node, the current Version Number, and the value of the Grounded flag. @@ -498,15 +547,15 @@ 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 + 412 Gates Hall, Stanford University Stanford, CA 94305 USA Email: pal@cs.stanford.edu