--- 1/draft-ietf-roll-minrank-hysteresis-of-07.txt 2012-04-21 06:13:59.314756070 +0200 +++ 2/draft-ietf-roll-minrank-hysteresis-of-08.txt 2012-04-21 06:13:59.338754835 +0200 @@ -1,25 +1,26 @@ Networking Working Group O. Gnawali -Internet-Draft P. Levis -Intended status: Standards Track Stanford University -Expires: September 10, 2012 March 9, 2012 +Internet-Draft University of Houston +Intended status: Standards Track P. Levis +Expires: October 22, 2012 Stanford University + April 20, 2012 The Minimum Rank with Hysteresis Objective Function - draft-ietf-roll-minrank-hysteresis-of-07 + draft-ietf-roll-minrank-hysteresis-of-08 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 + 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 metric it uses is determined by the metrics RPL Destination Information Object (DIO) messages advertise. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -27,69 +28,69 @@ 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 10, 2012. + This Internet-Draft will expire on October 22, 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 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. The Minimum Rank Objective Function with Hysteresis . . . . . 4 + 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 + 3.5. Working Without Metric Containers . . . . . . . . . . . . 9 4. Using MRHOF for Metric Maximization . . . . . . . . . . . . . 9 5. MRHOF Variables and Parameters . . . . . . . . . . . . . . . . 9 6. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 10 - 6.1. Device Configuration . . . . . . . . . . . . . . . . . . . 10 + 6.1. Device Configuration . . . . . . . . . . . . . . . . . . . 11 6.2. Device Monitoring . . . . . . . . . . . . . . . . . . . . 11 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction - An objective function specifies how RPL [I-D.ietf-roll-rpl] 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. + 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. 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 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 @@ -105,48 +106,53 @@ 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. 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. Because MRHOF seeks to minimize path costs as described by metrics, - it can only be used with additive metrics. MRHOF ignores metrics t + it can only be used with additive metrics. MRHOF ignores metrics + that are not additive. 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], + The terminologies used in this document are consistent with the + terminologies described in [I-D.ietf-roll-terminology] and + [I-D.ietf-roll-routing-metrics]. - [I-D.ietf-roll-rpl], and [I-D.ietf-roll-routing-metrics]. + The terminologies used in this document are also consistent with the + terminologies described in RFC 6550 [RFC6550], except the term Rank. + In this document, Rank refers to the value of the Rank field, not + DAGRank as in RFC 6550 [RFC6550]. This document introduces three 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]. 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 +3. The Minimum Rank with Hysteresis Objective Function 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 [I-D.ietf-roll-routing-metrics] as long the routing objective is to @@ -289,53 +295,54 @@ | Latency | Cost/65536 | | Link Quality Level | Cost | | ETX | Cost | +--------------------+------------+ Table 1: Conversion of metric to rank. 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]. + to [RFC6550]. MRHOF uses this Rank value to compute the Rank it associates with the - path through each meqber of the parent set. The Rank associated with + 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 corresponding Rank value calculated with the - table above, the second is the that node's advertised Rank plus + table above, the second is that node's 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 plus one + advertised Rank, rounded to the next higher integral Rank, ie, 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 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. + 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, which 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 sub-optimal - routing: nodes will 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. + 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 sub- + optimal 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. 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 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 @@ -433,39 +440,39 @@ 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 - Section 18 of [I-D.ietf-roll-rpl] depicts the management of RPL. - This specification inherits from that section and its subsections, - with the exception that metrics as specified in + 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 [I-D.ietf-roll-routing-metrics] 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. A MRHOF implementation SHOULD support the DODAG Configuration option - as described in [I-D.ietf-roll-rpl] and apply the parameters it - specifies. Care should be taken in the relationship between the - MRHOF PARENT_SWITCH_THRESHOLD parameter and the RPL MaxRankIncrease + 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. Unless configured otherwise, a MRHOF implementation SHOULD use the default parameters as specified in Section 5. @@ -478,98 +485,95 @@ 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. + DAG information as specified in Section 6.3.1 of [RFC6550], 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. 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. 7. Acknowledgements Thanks to Antonio Grilo, Nicolas Tsiftes, Matteo Paris, JP Vasseur, and Phoebus Chen for their comments. 8. IANA Considerations This specification requires a value allocated from the "Objective Code Point (OCP)" sub-registry of the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry. A value of 1 is suggested. 9. Security Considerations This specification makes simple extensions to RPL and so is vulnerable to and benefits from the security issues and mechanisms - described in [I-D.ietf-roll-rpl] and - [I-D.ietf-roll-security-framework]. This document does not introduce - new flows or new messages, thus requires no specific mitigation for - new threats. + described in [RFC6550] and [I-D.ietf-roll-security-framework]. This + document does not introduce new flows or new messages, thus requires + no specific mitigation for new threats. MRHOF depends on information exchanged in a number 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. 10. References 10.1. Normative References [I-D.ietf-roll-routing-metrics] Barthel, D., Vasseur, J., Pister, K., Kim, M., and N. Dejean, "Routing Metrics used for Path Calculation in Low Power and Lossy Networks", draft-ietf-roll-routing-metrics-19 (work in progress), March 2011. - [I-D.ietf-roll-rpl] - Brandt, A., Vasseur, J., Hui, J., Pister, K., Thubert, P., - Levis, P., Struik, R., Kelsey, R., Clausen, T., and T. - Winter, "RPL: IPv6 Routing Protocol for Low power and - Lossy Networks", draft-ietf-roll-rpl-19 (work in - progress), March 2011. - [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. + 10.2. Informative References [I-D.ietf-roll-security-framework] Tsao, T., Alexander, R., Dohler, M., Daza, V., and A. Lozano, "A Security Framework for Routing over Low Power and Lossy Networks", draft-ietf-roll-security-framework-07 (work in progress), January 2012. [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-05 (work in progress), March 2011. Authors' Addresses Omprakash Gnawali - Stanford University - S255 Clark Center, 318 Campus Drive - Stanford, CA 94305 + University of Houston + PGH 577, University of Houston + Houston, TX 77204 USA - Phone: +1 650 725 6086 - Email: gnawali@cs.stanford.edu + Phone: +1 713 743 3356 + Email: gnawali@cs.uh.edu Philip Levis Stanford University 412 Gates Hall, Stanford University Stanford, CA 94305 USA Email: pal@cs.stanford.edu