idnits 2.17.1 draft-ietf-roll-minrank-hysteresis-of-11.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 (June 29, 2012) is 4316 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 University of Houston 4 Intended status: Standards Track P. Levis 5 Expires: December 31, 2012 Stanford University 6 June 29, 2012 8 The Minimum Rank with Hysteresis Objective Function 9 draft-ietf-roll-minrank-hysteresis-of-11 11 Abstract 13 The Routing Protocol for Low Power and Lossy Networks (RPL) uses 14 objective functions to construct routes that optimize or constrain 15 the routes it selects and uses. This specification describes the 16 Minimum Rank with Hysteresis Objective Function (MRHOF), an objective 17 function that selects routes that minimize a metric, while using 18 hysteresis to reduce churn in response to small metric changes. 19 MRHOF works with metrics that are additive along a route, and the 20 metric it uses is determined by the metrics RPL Destination 21 Information Object (DIO) messages advertise. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 31, 2012. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. The Minimum Rank with Hysteresis Objective Function . . . . . 4 60 3.1. Computing the Path cost . . . . . . . . . . . . . . . . . 4 61 3.2. Parent Selection . . . . . . . . . . . . . . . . . . . . . 6 62 3.2.1. When Parent Selection Runs . . . . . . . . . . . . . . 6 63 3.2.2. Parent Selection Algorithm . . . . . . . . . . . . . . 6 64 3.3. Computing Rank . . . . . . . . . . . . . . . . . . . . . . 7 65 3.4. Advertising the Path Cost . . . . . . . . . . . . . . . . 8 66 3.5. Working Without Metric Containers . . . . . . . . . . . . 9 67 4. Using MRHOF for Metric Maximization . . . . . . . . . . . . . 9 68 5. MRHOF Variables and Parameters . . . . . . . . . . . . . . . . 9 69 6. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 10 70 6.1. Device Configuration . . . . . . . . . . . . . . . . . . . 11 71 6.2. Device Monitoring . . . . . . . . . . . . . . . . . . . . 11 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 An objective function specifies how RPL [RFC6550] selects paths. For 83 example, if an RPL instance uses an objective function that minimizes 84 hop-count, RPL will select paths with minimum hop count. RPL 85 requires that all nodes in a network use a common Objective Function 86 (OF); relaxing this requirement may be a subject of future study. 88 The nodes running RPL might use a number of metrics to describe a 89 link or a node [RFC6551] and make these metrics available for route 90 selection. RPL advertises metrics in RPL Destination Information 91 Object (DIO) messages with a Metric Container suboption. An 92 objective function can use these metrics to choose routes. 94 To decouple the details of an individual metric or objective function 95 from forwarding and routing, RPL describes routes through a value 96 called Rank. Rank, roughly speaking, corresponds to the distance 97 associated with a route. RPL defines how nodes decide on paths based 98 on Rank and advertise their Rank. An objective function defines how 99 nodes calculate Rank, based on the Rank of its potential parents, 100 metrics, and other network properties. 102 This specification describes Minimum Rank with Hysteresis Objective 103 Function (MRHOF), an objective function for RPL. MRHOF uses 104 hysteresis while selecting the path with the smallest metric value. 105 The metric that MRHOF uses is determined by the metrics in the DIO 106 Metric Container. For example, the use of MRHOF with the latency 107 metric allows RPL to find stable minimum-latency paths from the nodes 108 to a root in the Directed Acyclic Graph (DAG) instance [RFC6550]. 109 The use of MRHOF with the Expected Transmission Count (ETX) 110 metric[RFC6551] allows RPL to find the stable minimum-ETX paths from 111 the nodes to a root in the DAG instance. In the absence of a metric 112 in the DIO Metric Container or the lack of a DIO Metric Container, 113 MRHOF defaults to using ETX to compute Rank, as described in 114 Section 3.5. 116 Because MRHOF seeks to minimize path costs as described by metrics, 117 it can only be used with additive metrics. MRHOF does not support 118 metrics that are not additive. 120 2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in RFC 125 2119 [RFC2119]. 127 The terminologies used in this document are consistent with the 128 terminologies described in [I-D.ietf-roll-terminology] and [RFC6551]. 130 The terminologies used in this document are also consistent with the 131 terminologies described in [RFC6550], except the term Rank. In this 132 document, Rank refers to the value of the Rank field, not DAGRank as 133 in [RFC6550]. 135 This document introduces three terms: 137 Selected metric: The metric chosen by the network operator to use 138 for path selection. MRHOF supports using a single metric for 139 path selection. The decision to use a metric (other than ETX) 140 as the selected metric is indicated by the presence of the 141 chosen metric in the DIO metric container. The selection of 142 the ETX metric is indicated by the absence of the metric 143 container. 145 Path cost: Path cost quantifies a property of an end-to-end path. 146 Path cost is obtained by each node summing up the selected link 147 metric to the path cost advertised by the parent. Path cost 148 can be used by RPL to compare different paths. 150 Worst parent: The node in the parent set with the largest path cost. 152 3. The Minimum Rank with Hysteresis Objective Function 154 The Minimum Rank with Hysteresis Objective Function, MRHOF, is 155 designed to find the paths with the smallest path cost while 156 preventing excessive churn in the network. It does so by using two 157 mechanisms. First, it finds the minimum cost path, i.e., path with 158 the minimum Rank. Second, it switches to that minimum Rank path only 159 if it is shorter (in terms of path cost) than the current path by at 160 least a given threshold. This second mechanism is called hysteresis. 162 MRHOF may be used with any additive metric listed in [RFC6551] as 163 long the routing objective is to minimize the given routing metric. 164 Nodes MUST support at least one of these metrics:hop count, latency, 165 and ETX. Nodes SHOULD support the ETX metric. MRHOF does not 166 support non-additive metrics. 168 3.1. Computing the Path cost 170 Root nodes (Grounded or Floating) set the variable cur_min_path_cost 171 to the metric value that most closely computes to a Rank of 172 MinHopRankIncrease. 174 If a non-root node does not have metrics to compute the path cost 175 through any of the candidate neighbors, it MUST join one of the 176 candidate neighbors as a RPL Leaf. 178 Otherwise, nodes compute the path cost for each candidate neighbor 179 reachable on an interface. The path cost of a neighbor represents 180 the cost of the path, in terms of the selected metric, from a node to 181 the root of the DODAG through that neighbor. A non-root node 182 computes a neighbor's path cost by adding two components: 184 1. If the selected metric is a link metric, the selected metric for 185 the link to a candidate neighbor. If the selected metric is a 186 node metric, the selected metric for the node. 188 2. The value of the selected metric in the metric container in the 189 DIO sent by that neighbor. 191 A node SHOULD compute the path cost for the path through each 192 candidate neighbor reachable through an interface. If a node cannot 193 compute the path cost for the path through a candidate neighbor, the 194 node MUST NOT select the candidate neighbor as its preferred parent, 195 except if it cannot compute the path cost through any neighbor, in 196 which case it may join as a leaf as described above. 198 If the selected metric is a link metric and the metric of the link to 199 a neighbor is not available, the path cost for the path through that 200 neighbor SHOULD be set to MAX_PATH_COST. This cost value will 201 prevent this path from being considered for path selection. 203 If the selected metric is a node metric, and the metric is not 204 available, the path cost through all the neighbors SHOULD be set to 205 MAX_PATH_COST. 207 The path cost corresponding to a neighbor SHOULD be re-computed each 208 time any of the following conditions are met: 210 1. The selected metric of the link to the candidate neighbor is 211 updated. 213 2. If the selected metric is a node metric and the metric is 214 updated. 216 3. A node receives a new metric advertisement from the candidate 217 neighbor. 219 This computation SHOULD also be performed periodically. While it is 220 harmless to delay this computation up to minimum Trickle interval 221 [RFC6550], longer delays in updating the path cost after the metric 222 is updated or a new metric advertisement is received can lead to 223 stale information. 225 3.2. Parent Selection 227 After computing the path cost for all the candidate neighbors 228 reachable through an interface for the current Destination Oriented 229 DAG iteration (DODAG) [RFC6550], a node selects the preferred parent. 230 This process is called parent selection. To allow hysteresis, parent 231 selection maintains a variable, cur_min_path_cost, which is the path 232 cost of the current preferred parent. 234 3.2.1. When Parent Selection Runs 236 A MRHOF implementation SHOULD perform Parent Selection each time: 238 1. The path cost for an existing candidate neighbor, including the 239 preferred parent, changes. This condition can be checked 240 immediately after the path cost is computed. 242 2. A new candidate neighbor is inserted into the neighbor table. 244 If, despite the above, it is necessary to defer the parent selection 245 until a later time (e.g., up to Trickle minimum interval [RFC6550]), 246 note that doing so can delay the use of better paths available in the 247 network. 249 3.2.2. Parent Selection Algorithm 251 If the selected metric for a link is greater than MAX_LINK_METRIC, 252 the node SHOULD exclude that link from consideration during parent 253 selection. 255 A node MUST select the candidate neighbor with the lowest path cost 256 as its preferred parent, except as indicated below: 258 1. A node MAY declare itself as a Floating root, and hence have no 259 preferred parent, depending on system configuration. 261 2. If cur_min_path_cost is greater than MAX_PATH_COST, the node MAY 262 declare itself as a Floating root. 264 3. If the smallest path cost for paths through the candidate 265 neighbors is smaller than cur_min_path_cost by less than 266 PARENT_SWITCH_THRESHOLD, the node MAY continue to use the current 267 preferred parent. This is the hysteresis component of MRHOF. 269 4. If ALLOW_FLOATING_ROOT is 0 and no neighbors are discovered, the 270 node does not have a preferred parent, and MUST set 271 cur_min_path_cost to MAX_PATH_COST. 273 If there are multiple neighbors which share the smallest path cost, a 274 node MAY use a different selection criteria to select which of these 275 neighbors should be considered to have the lowest cost. 277 A node MAY include up to PARENT_SET_SIZE-1 additional candidate 278 neighbors in its parent set. The cost of path through the nodes in 279 the parent set is smaller than or equal to the cost of the paths 280 through any of the nodes that are not in the parent set. If the cost 281 of the path through the preferred parent and the worst parent is too 282 large, a node MAY keep a smaller parent set than PARENT_SET_SIZE. 284 Once the preferred parent is selected, the node sets its 285 cur_min_path_cost variable to the path cost corresponding to the 286 preferred parent. The value of the cur_min_path_cost is carried in 287 the metric container corresponding to the selected metric when DIO 288 messages are sent. 290 3.3. Computing Rank 292 DAG roots set their Rank to MinHopRankIncrease. 294 Once a non-root node selects its parent set, it can use the following 295 table to covert the path cost of a parent (written as Cost in the 296 table) to a Rank value: 298 +------------------+------------+ 299 | Node/link Metric | Rank | 300 +------------------+------------+ 301 | Hop-Count | Cost | 302 | Latency | Cost/65536 | 303 | ETX | Cost | 304 +------------------+------------+ 306 Table 1: Conversion of metric to rank. 308 Rank is undefined for these node/link metrics: node state and 309 attributes, throughput, and link color. If the rank is undefined, 310 the node must join one of the neighbors as a RPL Leaf node according 311 to [RFC6550]. 313 MRHOF uses this Rank value to compute the Rank it associates with the 314 path through each member of the parent set. The Rank associated with 315 a path through a member of the parent set is the maximum of two 316 values. The first is corresponding Rank value calculated with the 317 table above, the second is that node's advertised Rank plus 318 MinHopRankIncrease. 320 A node sets its Rank to the maximum of three values: 322 1. The Rank calculated for the path through the preferred parent 324 2. The Rank of the member of the parent set with the highest 325 advertised Rank, rounded to the next higher integral Rank, ie, to 326 MinHopRankIncrease * (1 + floor(Rank/MinHopRankIncrease)). 328 3. The largest calculated Rank among paths through the parent set, 329 minus MaxRankIncrease 331 The first case is the Rank associated with the path through the 332 preferred parent. The second case covers requirement 5 of Rank 333 advertisements in Section 8.2.1 of [RFC6550]. The third case ensures 334 that a node does not advertise a Rank which then precludes it from 335 using members of its parent set. 337 Note that the third case means that a node advertises a conservative 338 Rank value based on members of its parent set. This conservative 339 value might be significantly higher than the Rank calculated for the 340 path through the preferred parent. Accordingly, picking a parent set 341 whose paths have a large range of Ranks will likely result in sub- 342 optimal routing: nodes might not choose good paths because they are 343 advertised as much worse than they actually are. The exact selection 344 of a parent set is an implementation decision. 346 3.4. Advertising the Path Cost 348 Once the preferred parent is selected, the node sets its 349 cur_min_path_cost variable to the path cost corresponding to its 350 preferred parent. It then calculates the metric it will advertise in 351 its metric container. This value is the path cost of the member of 352 the parent set with the highest path cost. Thus, while 353 cur_min_path_cost is the cost through the preferred parent, a node 354 advertises the highest cost path from the node to the root through a 355 member of the parent set. The value of the highest cost path is 356 carried in the metric container corresponding to the selected metric 357 when DIO messages are sent. 359 If ETX is the selected metric, a node SHOULD NOT advertise it in a 360 metric container. Instead, a node MUST advertise an approximation of 361 its ETX in its advertised Rank value, following the rules described 362 in Section 3.3. If a node receives a DIO with a metric container 363 holding an ETX metric, MRHOF MUST ignore the ETX metric value in its 364 Rank calculations. 366 DODAG Roots advertise a metric value which mostly closely computes to 367 a Rank value of MinHopRankIncrease. 369 3.5. Working Without Metric Containers 371 In the absence of metric container, MRHOF uses ETX as its metric. It 372 locally computes the ETX of links to its neighbors and adds this 373 value to their advertised Rank to compute the associated Rank of 374 routes. Once parent selection and rank computation is performed 375 using the ETX metric, the node advertises a Rank equal to the ETX 376 cost and MUST NOT include a metric container in its DIO messages. 378 4. Using MRHOF for Metric Maximization 380 MRHOF cannot be directly used for parent selection using metrics 381 which require finding paths with maximum value of the selected 382 metric, such as path reliability. It is possible to convert such a 383 metric maximization problem to a metric minimization problem for some 384 metrics and use MRHOF provided: 386 There is a fixed and well-known maximum metric value corresponding 387 to the best path. This is the path cost for the DAG root. For 388 example, the logarithm of the best link reliability has a value of 389 0. 391 The metrics in the maximization problem are all negative. The 392 logarithm of the link reliability is always negative. 394 For metrics meeting the above conditions, the problem of maximizing 395 the metric value is equivalent to minimizing the modified metric 396 value, e.g., logarithm of link reliability. MRHOF is not required to 397 work with these metrics. 399 5. MRHOF Variables and Parameters 401 MRHOF uses the following variable: 403 cur_min_path_cost: The cost of the path from a node through its 404 preferred parent to the root computed at the last parent 405 selection. 407 MRHOF uses the following parameters: 409 MAX_LINK_METRIC: Maximum allowed value for the selected link 410 metric for each link on the path. 412 MAX_PATH_COST: Maximum allowed value for the path metric of a 413 selected path. 415 PARENT_SWITCH_THRESHOLD: The difference between the cost of the 416 path through the preferred parent and the minimum cost path in 417 order to trigger the selection of a new preferred parent. 419 PARENT_SET_SIZE: The number of candidate parents, including the 420 preferred parent, in the parent set. 422 ALLOW_FLOATING_ROOT: If set to 1, allows a node to become a 423 floating root. 425 The parameter values are assigned depending on the selected metric. 426 The best values for these parameters are determined by the 427 requirement of the specific RPL deployment. For instance, if we use 428 ETX as the selected metric and UDP as the transport protocol, we 429 should use a small MAX_LINK_METRIC (e.g., ETX of 1.1) so that link 430 layer retransmissions are sufficient to provide a good chance of end- 431 to-end reliability. 433 The working group has long experience routing with the ETX 434 metric[Hui08b]. Based on those experiences, these values are 435 RECOMMENDED: 437 MAX_LINK_METRIC: 512. Disallow links with greater than 4 expected 438 transmission count on the selected path. 440 MAX_PATH_COST: 32768. Disallow paths with greater than 256 441 expected transmission count. 443 PARENT_SWITCH_THRESHOLD: 192. Switch to a new path only if it is 444 expected to require at least 1.5 fewer transmissions than the 445 current path. 447 PARENT_SET_SIZE: 3. If the preferred parent is not available, two 448 candidate parents are still available without triggering a new 449 round of route discovery. 451 ALLOW_FLOATING_ROOT: 0. Do not allow a node to become a floating 452 root. 454 6. Manageability 456 Section 18 of [RFC6550] depicts the management of RPL. This 457 specification inherits from that section and its subsections, with 458 the exception that metrics as specified in [RFC6551] are not used and 459 do not require management. 461 6.1. Device Configuration 463 An implementation SHOULD allow the following parameters to be 464 configured at installation time: MAX_LINK_METRIC, MAX_PATH_COST, 465 PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT. 466 An implementation MAY allow these parameters to be configured 467 dynamically at run time once a network has been deployed. 469 A MRHOF implementation MUST support the DODAG Configuration option as 470 described in [RFC6550] and apply the parameters it specifies. Care 471 should be taken in the relationship between the MRHOF 472 PARENT_SWITCH_THRESHOLD parameter and the RPL MaxRankIncrease 473 parameter. For example, if MaxRankIncrease is smaller than 474 PARENT_SWITCH_THRESHOLD, a RPL node using MRHOF could enter a 475 situation where its current preferred parent causes the nodes Rank to 476 increase more than MaxRankIncrease but MRHOF does not change 477 preferred parents: this could cause the node to leave the routing 478 topology even though there may be other members of the parent set 479 which would allow the node's Rank to remain within MaxRankIncrease. 481 Unless configured otherwise, a MRHOF implementation SHOULD use the 482 default parameters as specified in Section 5. 484 Because of the partially-coupled relationship between Rank and metric 485 values, networks using MRHOF require care in setting 486 MinHopRankIncrease. A large MinHopRankIncrease will cause MRHOF to 487 be unable to select paths with different hop counts but similar 488 metric values. If MinHopRankIncrease is large enough that its 489 increment is greater than that caused by link cost, then metrics will 490 be used to select a preferred parent but the advertised Rank will be 491 a simple hopcount. This behavior might be desirable, but it also 492 might be unintended: care is recommended. 494 RPL's Rank advertisement rules can require a DODAG Root to advertise 495 a Rank higher than its corresponding ETX value, as a DODAG Root 496 advertises a Rank of MinHopRankIncrease. Because all DODAG Roots 497 within a DODAG Version advertise the same Rank, this constant value 498 typically does not affect route selection. Nevertheless, it means 499 that if a DODAG Version has a MinHopRankIncrease of M and a path has 500 an advertised ETX of E, then the actual ETX of the path is likely 501 closer to a value of E-M than a value of E. 503 6.2. Device Monitoring 505 A MRHOF implementation should provide an interface for monitoring its 506 operation. At a minimum, the information provided should include: 508 DAG information as specified in Section 6.3.1 of [RFC6550], and 509 including the DODAGID, the RPLInstanceID, the Mode of Operation, 510 the Rank of this node, the current Version Number, and the value 511 of the Grounded flag. 513 A list of neighbors indicating the preferred parent. The list 514 should indicate, for each neighbor, the Rank, the current Version 515 Number, the value of the Grounded flag, and associated metrics. 517 7. Acknowledgements 519 Thanks to Antonio Grilo, Nicolas Tsiftes, Matteo Paris, JP Vasseur, 520 and Phoebus Chen for their comments. Thanks to Barry Leiba, Brian 521 Haberman, Martin Stiemerling, Ralph Droms, Robert Sparks, Russ 522 Housley, Stephen Farrell, Wesley Eddy, Miguel A. Garcia, Mukul Goyal, 523 and Michael Richardson for their feedback during the publication 524 phase of this document. 526 8. IANA Considerations 528 This specification requires a value allocated from the "Objective 529 Code Point (OCP)" sub-registry of the "Routing Protocol for Low Power 530 and Lossy Networks (RPL)" registry. A value of 1 is suggested. 532 9. Security Considerations 534 This specification makes simple extensions to RPL and so is 535 vulnerable to and benefits from the security issues and mechanisms 536 described in [RFC6550] and [I-D.ietf-roll-security-framework]. This 537 document does not introduce new flows or new messages, thus requires 538 no specific mitigation for new threats. 540 MRHOF depends on information exchanged in a number RPL protocol 541 elements. If those elements were compromised, then an implementation 542 of MRHOF might generate the wrong path for a packet, resulting in it 543 being misrouted. Therefore, deployments are RECOMMENDED to use RPL 544 security mechanisms if there is a risk that routing information might 545 be modified or spoofed. 547 10. References 548 10.1. Normative References 550 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 551 Requirement Levels", BCP 14, RFC 2119, March 1997. 553 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 554 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 555 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 556 Lossy Networks", RFC 6550, March 2012. 558 [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. 559 Barthel, "Routing Metrics Used for Path Calculation in 560 Low-Power and Lossy Networks", RFC 6551, March 2012. 562 10.2. Informative References 564 [Hui08b] Hui, J. and D. Culler, "IP is dead, long live IP for 565 wireless sensor networks", Proceedings of the 6th ACM 566 Conference on Embedded Networked Systems SenSys 2008, 567 November 2008, 568 . 570 [I-D.ietf-roll-security-framework] 571 Tsao, T., Alexander, R., Dohler, M., Daza, V., and A. 572 Lozano, "A Security Framework for Routing over Low Power 573 and Lossy Networks", draft-ietf-roll-security-framework-07 574 (work in progress), January 2012. 576 [I-D.ietf-roll-terminology] 577 Vasseur, J., "Terminology in Low power And Lossy 578 Networks", draft-ietf-roll-terminology-05 (work in 579 progress), March 2011. 581 Authors' Addresses 583 Omprakash Gnawali 584 University of Houston 585 PGH 577, University of Houston 586 Houston, TX 77204 587 USA 589 Phone: +1 713 743 3356 590 Email: gnawali@cs.uh.edu 591 Philip Levis 592 Stanford University 593 412 Gates Hall, Stanford University 594 Stanford, CA 94305 595 USA 597 Email: pal@cs.stanford.edu