idnits 2.17.1 draft-ietf-roll-minrank-hysteresis-of-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 4, 2012) is 4435 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-05 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group O. Gnawali 3 Internet-Draft P. Levis 4 Intended status: Standards Track Stanford University 5 Expires: September 5, 2012 March 4, 2012 7 The Minimum Rank with Hysteresis Objective Function 8 draft-ietf-roll-minrank-hysteresis-of-05 10 Abstract 12 The Routing Protocol for Low Power and Lossy Networks (RPL) uses 13 objective functions to construct routes that optimize or constrain 14 the routes it selects and uses. This specification describes the 15 Minimum Rank Objective Function with Hysteresis (MRHOF), an objective 16 function that selects routes that minimize a metric, while using 17 hysteresis to reduce churn in response to small metric changes. 18 MRHOF works with metrics that are additive along a route, and the 19 metric it uses is determined by the metrics RPL Destination 20 Information Object (DIO) messages advertise. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 5, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. The Minimum Rank Objective Function with Hysteresis . . . . . 4 59 3.1. Computing the Path cost . . . . . . . . . . . . . . . . . 4 60 3.2. Parent Selection . . . . . . . . . . . . . . . . . . . . . 5 61 3.3. Computing Rank . . . . . . . . . . . . . . . . . . . . . . 6 62 3.4. Advertising the Path Cost . . . . . . . . . . . . . . . . 7 63 3.5. Working Without Metric Containers . . . . . . . . . . . . 7 64 4. Using MRHOF for Metric Maximization . . . . . . . . . . . . . 8 65 5. MRHOF Variables and Parameters . . . . . . . . . . . . . . . . 8 66 6. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 9 67 6.1. Device Configuration . . . . . . . . . . . . . . . . . . . 9 68 6.2. Device Monitoring . . . . . . . . . . . . . . . . . . . . 10 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 74 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 An objective function specifies how RPL [I-D.ietf-roll-rpl] selects 80 paths. Objective functions can choose paths based on routing metrics 81 or constraints. For example, if an RPL instance uses an objective 82 function that minimizes hop-count, RPL will select paths with minimum 83 hop count. The RPL specification requires the use of a common OF by 84 all nodes in a network. The possible use of multiple OFs with a 85 single network is for further study. 87 The nodes running RPL might use a number of metrics to describe a 88 link or a node [I-D.ietf-roll-routing-metrics] and make it available 89 for route selection. These metrics are advertised in RPL Destination 90 Information Object (DIO) messages using a Metric Container suboption. 91 An objective function can use these metrics to choose routes. The 92 only exception is the ETX metric, which is used without the metric 93 container as described in Section 3.5. 95 To decouple the details of an individual metric or objective function 96 from forwarding and routing, RPL describes routes through a value 97 called Rank. Rank, roughly speaking, corresponds to the distance 98 associated with a route. An objective function is responsible for 99 computing a node's advertised Rank value based on the Rank of its 100 potential parents, metrics, and other network properties. 102 This specification describes MRHOF, an objective function for RPL. 103 MRHOF uses hysteresis while selecting the path with the smallest 104 metric value. The metric that MRHOF uses is determined by the 105 metrics in the DIO Metric Container. For example, the use of MRHOF 106 with the latency metric allows RPL to find stable minimum-latency 107 paths from the nodes to a root in the DAG instance. The use of MRHOF 108 with the ETX metric allows RPL to find the stable minimum-ETX paths 109 from the nodes to a root in the DAG instance. 111 MRHOF can only be used with an additive metric that must be minimized 112 on the paths selected for routing. 114 2. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in RFC 119 2119 [RFC2119]. 121 This terminology used in this document is consistent with the 122 terminologies described in [I-D.ietf-roll-terminology], 123 [I-D.ietf-roll-rpl], and [I-D.ietf-roll-routing-metrics]. 125 This document introduces three terms: 127 Selected metric: The metric chosen by the network operator to use 128 for path selection. This metric can be any additive metric 129 listed in [I-D.ietf-roll-routing-metrics]. 131 Path cost: Path cost quantifies a property of an end-to-end path. 132 Path cost is obtained by summing up the selected metric of the 133 links or nodes along the path. Path cost can be used by RPL to 134 compare different paths. 136 Worst parent: The node in the parent set with the largest path cost. 138 3. The Minimum Rank Objective Function with Hysteresis 140 The Minimum Rank Objective Function with Hysteresis, MRHOF, is 141 designed to find the paths with the smallest path cost while 142 preventing excessive churn in the network. It does so by finding the 143 minimum cost path and switching to that path only if it is shorter 144 (in terms of path cost) than the current path by at least a given 145 threshold. MRHOF may be used with any additive metric listed in 146 [I-D.ietf-roll-routing-metrics] as long the routing objective is to 147 minimize the given routing metric. 149 3.1. Computing the Path cost 151 Nodes compute the path cost for each candidate neighbor reachable on 152 an interface. The Path cost represents the cost of the path, in 153 terms of the selected metric, from a node to the root of the DODAG 154 through the neighbor. 156 Root nodes (Grounded or Floating) set the variable cur_min_path_cost 157 to MinHopRankIncrease. 159 A non-root node computes the path cost for a path to the root through 160 each candidate neighbor by adding these two components: 162 1. If the selected metric is a link metric, the selected metric for 163 the link to a candidate neighbor. If the selected metric is a 164 node metric, the selected metric for the node. 166 2. The value of the selected metric in the metric container in the 167 DIO sent by that neighbor. 169 A node SHOULD compute the path cost for the path through each 170 candidate neighbor reachable through an interface. If a node cannot 171 compute the path cost for the path through a candidate neighbor, the 172 node MUST NOT select the candidate neighbor as its preferred parent, 173 with one exception. If the node does not have metrics to compute the 174 path cost through any of the candidate neighbors, it MUST join one of 175 the candidate neighbors as a leaf node. 177 If the selected metric is a link metric and the metric of the link to 178 a neighbor is not available, the path cost for the path through that 179 neighbor SHOULD be set to MAX_PATH_COST. This cost value will 180 prevent this path from being considered for path selection. 182 If the selected metric is a node metric, and the metric is not 183 available, the path cost through all the neighbors SHOULD be set to 184 MAX_PATH_COST. 186 The path cost corresponding to a neighbor SHOULD be re-computed each 187 time: 189 1. The selected metric of the link to the candidate neighbor is 190 updated. 192 2. If the selected metric is a node metric and the metric is 193 updated. 195 3. A node receives a new metric advertisement from the candidate 196 neighbor. 198 This computation MAY also be performed periodically. Too much delay 199 in updating the path cost after the metric is updated or a new metric 200 advertisement is received can lead to stale Rank or parent set. 202 3.2. Parent Selection 204 After computing the path cost for all the candidate neighbors 205 reachable through an interface for the current DODAG iteration, a 206 node selects the preferred parent. This process is called parent 207 selection. Parent Selection SHOULD be performed each time: 209 1. The path cost for an existing candidate neighbor, including the 210 preferred parent, changes. This condition can be checked 211 immediately after the path cost is computed. 213 2. A new candidate neighbor is inserted into the neighbor table. 215 The parent selection MAY be deferred until a later time. Deferring 216 the parent selection can delay the use of better paths available in 217 the network. 219 A node MUST select a candidate neighbor as its preferred parent if 220 the path cost corresponding to that neighbor is smaller than the path 221 cost corresponding to the rest of the neighbors, except as indicated 222 below: 224 1. If the smallest path cost for paths through the candidate 225 neighbors is smaller than cur_min_path_cost by less than 226 PARENT_SWITCH_THRESHOLD, the node MAY continue to use the current 227 preferred parent. 229 2. If there are multiple paths with the smallest path cost and the 230 smallest path cost is smaller than cur_min_path_cost by at least 231 PARENT_SWITCH_THRESHOLD, a node MAY use a different objective 232 function to select the preferred parent among the candidate 233 neighbors on the path with the minimum cost. 235 3. A node MAY declare itself as a Floating root, and hence no 236 preferred parent, depending on the configuration. 238 4. If the selected metric for a link is greater than 239 MAX_LINK_METRIC, the node SHOULD exclude that link from 240 consideration for parent selection. 242 5. If cur_min_path_cost is greater than MAX_PATH_COST, the node MAY 243 declare itself as a Floating root. 245 6. If ALLOW_FLOATING_ROOT is 0 and no neighbors are discovered, the 246 node does not have a preferred parent, and MUST set 247 cur_min_path_cost to MAX_PATH_COST. 249 Except in the cases above, the candidate neighbor on the path with 250 the smallest path cost is the preferred parent. A node MAY include a 251 total of PARENT_SET_SIZE candidate neighbors in the parent set. The 252 cost of path through the nodes in the parent set is smaller than or 253 equal to the cost of the paths through any of the nodes that are not 254 in the parent set. If the cost of the path through the preferred 255 parent and the worst parent is too large, a node MAY keep a smaller 256 parent set. 258 3.3. Computing Rank 260 The DAG roots set their rank to MinHopRankIncrease. 262 Once a non-root node selects its parent set, it can use the following 263 table to covert the path cost of the worst parent (written as Cost in 264 the table) to its Rank: 266 +--------------------+------------+ 267 | Node/link Metric | Rank | 268 +--------------------+------------+ 269 | Node Energy | 255 - Cost | 270 | Hop-Count | Cost | 271 | Latency | Cost/65536 | 272 | Link Quality Level | Cost | 273 | ETX | Cost | 274 +--------------------+------------+ 276 Table 1: Conversion of metric to rank. 278 Nodes MUST support at least one of the above metrics. Nodes SHOULD 279 support the ETX metric. 281 If this Rank calculation causes the increase in Rank between a node 282 and its worst parent to be less than MinHopRankIncrease, the node 283 sets its Rank to the Rank of its worst parent plus 284 MinHopRankIncrease. 286 Node rank is undefined for these node/link metrics: Node state and 287 attributes, throughput, and link color. If the rank is undefined, 288 the node must join one of the neighbors as a leaf node according to 289 [I-D.ietf-roll-rpl]. 291 3.4. Advertising the Path Cost 293 Once the preferred parent is selected, the node sets its 294 cur_min_path_cost variable to the path cost corresponding to the 295 highest cost element of the parent set. Thus, cur_min_path_cost is 296 the cost of the highest cost path from the node to the root through a 297 member of the parent set. The value of the cur_min_path_cost is 298 carried in the metric container corresponding to the selected metric 299 when DIO messages are sent. 301 If ETX is the selected metric, cur_min_path_cost is directly used as 302 Rank and never advertised in a metric container. 304 3.5. Working Without Metric Containers 306 In the absence of metric container, MRHOF uses ETX as its metric. It 307 locally computes the ETX of links to its neighbors and adds this 308 value to their advertised Rank to compute the associated Rank of 309 routes. Once parent selection and rank computation is performed 310 using the ETX metric, the node advertises a Rank equal to the ETX 311 cost and MUST NOT include a metric container in its DIO messages. 313 4. Using MRHOF for Metric Maximization 315 MRHOF cannot be directly used for parent selection using metrics 316 which require finding paths with maximum value of the selected 317 metric, such as path reliability. It is possible to convert such a 318 metric maximization problem to a metric minimization problem for some 319 metrics and use MRHOF provided: 321 There is a fixed and well-known maximum metric value corresponding 322 to the best path. This is the path cost for the DAG root. For 323 example, the logarithm of the best link reliability has a value of 324 0. 326 The metrics in the maximization problem are all negative. The 327 logarithm of the link reliability is always negative. 329 For metrics meeting the above conditions, the problem of maximizing 330 the metric value is equivalent to minimizing the modified metric 331 value, e.g., logarithm of link reliability. MRHOF is not required to 332 work with these metrics. 334 5. MRHOF Variables and Parameters 336 MRHOF uses the following variable: 338 cur_min_path_cost: The cost of the path from a node through its 339 preferred parent to the root computed at the last parent 340 selection. 342 MRHOF uses the following parameters: 344 MAX_LINK_METRIC: Maximum allowed value for the selected link 345 metric for each link on the path. 347 MAX_PATH_COST: Maximum allowed value for the path metric of a 348 selected path. 350 MIN_PATH_COST: The minimum allowed value for the path metric of 351 the selected path. 353 PARENT_SWITCH_THRESHOLD: The difference between metric of the path 354 through the preferred parent and the minimum-metric path in order 355 to trigger the selection of a new preferred parent. 357 PARENT_SET_SIZE: The number of candidate parents, including the 358 preferred parent, in the parent set. 360 ALLOW_FLOATING_ROOT: If set to 1, allows a node to become a 361 floating root. 363 The parameter values are assigned depending on the selected metric. 364 The best values for these parameters should be experimentally 365 determined. The working group has long experience routing with the 366 ETX metric. Based on those experiences, these values are 367 RECOMMENDED: 369 MAX_LINK_METRIC: 10. Disallow links with greater than 10 expected 370 transmission count on the selected path. 372 MAX_PATH_COST: 100. Disallow paths with greater than 100 expected 373 transmission count. 375 MIN_PATH_COST: 0. At root, the expected transmission count is 0. 377 PARENT_SWITCH_THRESHOLD: 1.5. Switch to a new path only if it is 378 expected to require at least 1.5 fewer transmission than the 379 current path. 381 PARENT_SET_SIZE: 3. If the preferred parent is not available, two 382 candidate parents are still available without triggering a new 383 round of route discovery. 385 ALLOW_FLOATING_ROOT: 0. Do not allow a node to become a floating 386 root. 388 6. Manageability 390 Section 18 of [I-D.ietf-roll-rpl] depicts the management of RPL. 391 This specification inherits from that section and its subsections, 392 with the exception that metrics as specified in 393 [I-D.ietf-roll-routing-metrics] are not used and do not require 394 management. 396 6.1. Device Configuration 398 An implementation SHOULD allow the following parameters to be 399 configured at installation time: MAX_LINK_METRIC, MAX_PATH_COST, 400 MIN_PATH_COST, PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and 401 ALLOW_FLOATING_ROOT. An implementation MAY allow these parameters to 402 be configured dynamically at run time once a network has been 403 deployed. 405 A MRHOF implementation SHOULD support the DODAG Configuration option 406 as described in [I-D.ietf-roll-rpl] and apply the parameters it 407 specifies. Care should be taken in the relationship between the 408 MRHOF PARENT_SWITCH_THRESHOLD parameter and the RPL MaxRankIncrease 409 parameter. For example, if MaxRankIncrease is smaller than 410 PARENT_SWITCH_THRESHOLD, a RPL node using MRHOF could enter a 411 situation where its current preferred parent causes the nodes Rank to 412 increase more than MaxRankIncrease but MRHOF does not change 413 preferred parents: this could cause the node to leave the routing 414 topology even though there may be other members of the parent set 415 which would allow the node's Rank to remain within MaxRankIncrease. 417 Unless configured otherwise, a MRHOF implementation SHOULD use the 418 default parameters as specified in Section 5. 420 6.2. Device Monitoring 422 A MRHOF implementation should provide an interface for monitoring its 423 operation. At a minimum, the information provided should include: 425 DAG information as specified in Section 6.3.1 of 426 [I-D.ietf-roll-rpl], and including the DODAGID, the RPLInstanceID, 427 the Mode of Operation, the Rank of this node, the current Version 428 Number, and the value of the Grounded flag. 430 A list of neighbors indicating the preferred parent. The list 431 should indicate, for each neighbor, the Rank, the current Version 432 Number, the value of the Grounded flag, and associated metrics. 434 7. Acknowledgements 436 Thanks to Antonio Grilo, Nicolas Tsiftes, Matteo Paris, JP Vasseur, 437 and Phoebus Chen for their comments. 439 8. IANA Considerations 441 This specification requires a value allocated from the "Objective 442 Code Point (OCP)" sub-registry of the "Routing Protocol for Low Power 443 and Lossy Networks (RPL)" registry. A value of 1 is suggested. 445 9. Security Considerations 447 This specification makes simple extensions to RPL and so is 448 vulnerable to and benefits from the security issues and mechanisms 449 described in [I-D.ietf-roll-rpl] and 450 [I-D.ietf-roll-security-framework]. This document does not introduce 451 new flows or new messages, thus requires no specific mitigation for 452 new threats. 454 MRHOF depends on information exchanged in a number RPL protocol 455 elements. If those elements were compromised, then an implementation 456 of MRHOF might generate the wrong path for a packet, resulting in it 457 being misrouted. Therefore, deployments are RECOMMENDED to use RPL 458 security mechanisms if there is a risk that routing information might 459 be modified or spoofed. 461 10. References 463 10.1. Normative References 465 [I-D.ietf-roll-routing-metrics] 466 Barthel, D., Vasseur, J., Pister, K., Kim, M., and N. 467 Dejean, "Routing Metrics used for Path Calculation in Low 468 Power and Lossy Networks", 469 draft-ietf-roll-routing-metrics-19 (work in progress), 470 March 2011. 472 [I-D.ietf-roll-rpl] 473 Brandt, A., Vasseur, J., Hui, J., Pister, K., Thubert, P., 474 Levis, P., Struik, R., Kelsey, R., Clausen, T., and T. 475 Winter, "RPL: IPv6 Routing Protocol for Low power and 476 Lossy Networks", draft-ietf-roll-rpl-19 (work in 477 progress), March 2011. 479 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 480 Requirement Levels", BCP 14, RFC 2119, March 1997. 482 10.2. Informative References 484 [I-D.ietf-roll-security-framework] 485 Tsao, T., Alexander, R., Dohler, M., Daza, V., and A. 486 Lozano, "A Security Framework for Routing over Low Power 487 and Lossy Networks", draft-ietf-roll-security-framework-07 488 (work in progress), January 2012. 490 [I-D.ietf-roll-terminology] 491 Vasseur, J., "Terminology in Low power And Lossy 492 Networks", draft-ietf-roll-terminology-05 (work in 493 progress), March 2011. 495 Authors' Addresses 497 Omprakash Gnawali 498 Stanford University 499 S255 Clark Center, 318 Campus Drive 500 Stanford, CA 94305 501 USA 503 Phone: +1 650 725 6086 504 Email: gnawali@cs.stanford.edu 506 Philip Levis 507 Stanford University 508 358 Gates Hall, Stanford University 509 Stanford, CA 94305 510 USA 512 Email: pal@cs.stanford.edu