Internet Engineering Task Force (IETF) O. Gnawali Request for Comments: 6719 University of Houston Category: Standards Track P. Levis ISSN: 2070-1721 Stanford University September 2012 The Minimum Rank with Hysteresis Objective Function
AbstractThe Routing Protocol for Low-Power and Lossy Networks (RPL) constructs routes by using Objective Functions 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 additive metrics along a route, and the metrics it uses are determined by the metrics that the RPL Destination Information Object (DIO) messages advertise. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6719. 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 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 Simplified BSD License. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The Minimum Rank with Hysteresis Objective Function . . . . . 4 3.1. Computing the Path Cost . . . . . . . . . . . . . . . . . 4 3.2. Parent Selection . . . . . . . . . . . . . . . . . . . . . 5 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 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 RFC6550] selects paths. For example, if an RPL instance uses an Objective Function that minimizes hop count, RPL will select paths with a minimum hop count. RPL requires that all nodes in a network use a common Objective Function; 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 [RFC6551] 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. 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 the Minimum Rank with Hysteresis Objective Function (MRHOF), an Objective Function for RPL, which 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 Directed Acyclic Graph (DAG) instance [RFC6550]. The use of MRHOF with the Expected Transmission Count (ETX) metric [RFC6551] allows RPL to find the stable minimum-ETX paths from the nodes to a root in the DAG instance. In the absence of a metric in the DIO Metric Container or of a DIO Metric Container, MRHOF defaults to using ETX to compute Rank, as described in Section 3.5. Because MRHOF seeks to minimize path costs as described by metrics, it can only be used with additive metrics. MRHOF does not support metrics that are not additive. RFC2119]. The terminologies used in this document are consistent with the terminologies described in [ROLL-TERM] and [RFC6551]. The terminologies used in this document are also consistent with the terminologies described in [RFC6550], except the term Rank. In this document, Rank refers to the value of the Rank field, not DAGRank as in [RFC6550]. This document introduces three terms: Selected metric: The metric chosen for path selection by the network operator. MRHOF supports using a single metric for path selection. The decision to use a metric (other than ETX) as the selected metric is indicated by the presence of the chosen metric in the DIO Metric Container. The selection of the ETX metric is indicated by the absence of the Metric Container, in which case ETX is advertised as Rank.
Path cost: Path cost quantifies a property of an end-to-end path. Path cost is obtained by each node summing up the selected link metric to the path cost advertised by the parent. Path cost can be used by RPL to compare different paths. Worst parent: The node in the parent set with the largest path cost. RFC6551] as long as the routing objective is to minimize the given routing metric. Nodes MUST support at least one of these metrics: hop count, latency, or ETX. Nodes SHOULD support the ETX metric. MRHOF does not support non-additive metrics.
2. The value of the selected metric in the Metric Container in the DIO sent by that neighbor. In case the Metric Container is empty, ETX is the selected metric -- use the Rank advertised by that neighbor as the second component. See Section 3.5 for details on how an ETX metric is used in MRHOF. 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. However, if the node cannot compute the path cost through any neighbor, it may join the candidate neighbor 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. The path cost corresponding to a neighbor SHOULD be recomputed each time any of the following conditions are met: 1. The selected metric of the link to the candidate neighbor is updated. 2. 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 SHOULD also be performed periodically. While it is harmless to delay this computation up to a minimum Trickle interval [RFC6550], longer delays in updating the path cost after the metric is updated or a new metric advertisement is received can lead to stale information. RFC6550], a node selects the preferred parent. This process is called "parent selection". To allow hysteresis, parent selection maintains a variable, cur_min_path_cost, which is the path cost of the current preferred parent.
RFC6550]), note that doing so can delay the use of better paths available in the network.
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. +------------------+------------+ | Node/link Metric | Rank | +------------------+------------+ | Hop-Count | Cost | | Latency | Cost/65536 | | ETX | Cost | +------------------+------------+ Table 1: Conversion of Metric to Rank If MRHOF is used with other metrics, the Rank is undefined. If the Rank is undefined, the node must join one of the neighbors as a RPL Leaf node according to [RFC6550]. 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 two values. The first is the corresponding Rank value calculated with the table above, the second is that nodes' advertised Rank plus MinHopRankIncrease. A node sets its Rank to the maximum of three values: 1. The Rank calculated for the path through the preferred parent. 2. The Rank of the member of the parent set with the highest advertised Rank, rounded to the next higher integral Rank, i.e., to MinHopRankIncrease * (1 + floor(Rank/MinHopRankIncrease)). 3. The largest calculated Rank among paths through the parent set, minus MaxRankIncrease.
The first case is the Rank associated with the path through the preferred parent. The second case covers requirement 5 of Rank advertisements in Section 8.2.1 of [RFC6550]. The third case ensures that a node does not advertise a Rank, which then precludes it from using members of its parent set. Note that the third case means that a node advertises a conservative Rank value based on members of its parent set. This conservative value might be significantly higher than the Rank calculated for the path through the preferred parent. Accordingly, picking a parent set whose paths have a large range of Ranks will likely result in subptimal routing: nodes might not choose good paths because they are advertised as much worse than they actually are. The exact selection of a parent set is an implementation decision. 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 that computes to a Rank value of MinHopRankIncrease. RFC6551], i.e., assign Rank equal to ETX * 128.
The parameter values are assigned depending on the selected metric. The best values for these parameters are determined by the requirement of the specific RPL deployment. For instance, if we use ETX as the selected metric and UDP as the transport protocol, we should use a small MAX_LINK_METRIC (e.g., ETX of 1.1) so that link- layer retransmissions are sufficient to provide a good chance of end- to-end reliability. The working group has extensive experience routing with the ETX metric [Hui08b]. Based on those experiences, the following values are RECOMMENDED when ETX is the selected metric: MAX_LINK_METRIC: 512. Disallow links with greater than 4 expected transmission counts on the selected path. MAX_PATH_COST: 32768. Disallow paths with greater than 256 expected transmission counts. PARENT_SWITCH_THRESHOLD: 192. Switch to a new path only if it is expected to require at least 1.5 fewer transmissions than the current path. 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. 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. 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 in which its current preferred parent causes the node's 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 that 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 hop count. This behavior might be desirable, but it also might be unintended; care is recommended. With ETX as the selected metric, RPL's Rank advertisement rules can require a DODAG Root to advertise a Rank higher than its corresponding ETX value, as a DODAG Root advertises a Rank of MinHopRankIncrease. Because all DODAG Roots within a DODAG Version advertise the same Rank, this constant value typically does not affect route selection. Nevertheless, it means that if a DODAG Version has a MinHopRankIncrease of M and a path has an advertised ETX of E, then the actual ETX of the path is likely closer to a value of E-M than a value of E. Section 6.3.1 of [RFC6550], 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. A list of neighbors indicating the preferred parent. The list should indicate, for each neighbor, the Rank, the current Version Number, the value of the Grounded flag, and associated metrics.
RFC6550] and [ROLL-SEC]. This document does not introduce new flows or new messages, and thus requires no specific mitigation for new threats. MRHOF depends on information exchanged in a number of RPL protocol elements. If those elements were compromised, then an implementation of MRHOF might generate the wrong path for a packet, resulting in it being misrouted. Therefore, deployments are RECOMMENDED to use RPL security mechanisms if there is a risk that routing information might be modified or spoofed. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012. [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", RFC 6551, March 2012.
[Hui08b] Hui, J. and D. Culler, "IP is dead, long live IP for wireless sensor networks", Proceedings of the 6th ACM Conference on Embedded Networked Systems SenSys 2008, November 2008, <http://portal.acm.org/citation.cfm?id=1460412.1460415>. [ROLL-SEC] Tsao, T., Alexander, R., Dohler, M., Daza, V., and A. Lozano, "A Security Framework for Routing over Low Power and Lossy Networks", Work in Progress, January 2012. [ROLL-TERM] Vasseur, J., "Terminology in Low power And Lossy Networks", Work in Progress, September 2011.