idnits 2.17.1 draft-ietf-roll-of0-19.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 (August 26, 2011) is 4599 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 (-11) exists of draft-ietf-roll-minrank-hysteresis-of-04 == Outdated reference: A later version (-07) exists of draft-ietf-roll-security-framework-06 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-05 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track August 26, 2011 5 Expires: February 27, 2012 7 RPL Objective Function Zero 8 draft-ietf-roll-of0-19 10 Abstract 12 The Routing Protocol for Low Power and Lossy Networks (RPL) 13 specification defines a generic Distance Vector protocol that is 14 adapted to a variety of networks types by the application of specific 15 Objective Functions (OFs). An OF states the outcome of the process 16 used by a RPL node to select and optimize routes within a RPL 17 Instance based on the information objects available; an OF is not an 18 algorithm. 20 This document specifies a basic Objective Function that relies only 21 on the objects that are defined in RPL and does not use any protocol 22 extension 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 28 "OPTIONAL" in this document are to be interpreted as described in RFC 29 2119 [RFC2119]. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on February 27, 2012. 48 Copyright Notice 49 Copyright (c) 2011 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Objective Function Zero Overview . . . . . . . . . . . . . . . 4 67 4. OF0 Operations . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4.1. Computing Rank . . . . . . . . . . . . . . . . . . . . . . 5 69 4.2. Parent Selection . . . . . . . . . . . . . . . . . . . . . 7 70 4.2.1. Selection Of The Preferred Parent . . . . . . . . . . 7 71 4.2.2. Selection Of The Backup Feasible Successor . . . . . . 8 72 5. Abstract Interface to OF0 . . . . . . . . . . . . . . . . . . 9 73 6. OF0 Operands . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 6.1. Variables . . . . . . . . . . . . . . . . . . . . . . . . 9 75 6.2. Configurable Parameters . . . . . . . . . . . . . . . . . 10 76 6.3. Constants . . . . . . . . . . . . . . . . . . . . . . . . 10 77 7. Manageability Considerations . . . . . . . . . . . . . . . . . 10 78 7.1. Device Configuration . . . . . . . . . . . . . . . . . . . 11 79 7.2. Device Monitoring . . . . . . . . . . . . . . . . . . . . 11 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 85 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 The Routing Protocol for Low Power and Lossy Networks (RPL) 91 [I-D.ietf-roll-rpl]specification defines a generic Distance Vector 92 protocol that is adapted to a variety of Low Power and Lossy Networks 93 (LLN) types by the application of specific Objective Functions (OFs). 95 A RPL OF states the outcome of the process used by a RPL node to 96 select and optimize routes within a RPL Instance based on the 97 information objects available. As a general concept, an OF is not an 98 algorithm. For example outside RPL, "shortest path first" is an OF 99 where the least cost path between two points is derived as an 100 outcome; there are a number of algorithms that can be used to satisfy 101 the OF, of which the well-known Dijkstra algorithm is an example. 103 The separation of OFs from the core protocol specification allows RPL 104 to be adapted to meet the different optimization criteria required by 105 the wide range of deployments, applications, and network designs. 107 RPL forms Directed Acyclic Graphs (DAGs) as collections of 108 Destination Oriented DAGs (DODAGs) within instances of the protocol. 109 Each instance is associated with a specialized Objective Function. A 110 DODAG is periodically reconstructed as a new DODAG Version to enable 111 a global reoptimization of the graph. 113 An instance of RPL running on a device uses an Objective Function to 114 help it determine which DODAG and which Version of that DODAG it 115 should join. The OF is also used by the RPL instance to select a 116 number of routers within the DODAG current and subsequent Versions to 117 serve as parents or as feasible successors. 119 The RPL instance uses the OF to compute a Rank for the device. This 120 value represents an abstract distance to the root of the DODAG within 121 the DODAG Version. The Rank is exchanged between nodes using RPL and 122 allows other RPL nodes to avoid loops and verify forward progression 123 toward the destination, as specified in [I-D.ietf-roll-rpl]. 124 Regardless of the particular OF used by a node, Rank will always 125 increase and thus, post convergence, loop free paths are always 126 formed. 128 The Objective Function Zero (OF0) operates on parameters that are 129 obtained from provisioning, the RPL DODAG Configuration option and 130 the RPL DIO base container [I-D.ietf-roll-rpl]. 132 The Rank of a node is obtained by adding a stricly positive, 133 indirectly normalized scalar, rank_increase (Section 6.1), to the 134 Rank of a selected preferred parent. The rank_increase is based on a 135 step_of_rank (Section 6.1) normalized scalar that can vary with a 136 ratio from 1 (excellent) to 9 (worst acceptable) to represent the 137 link properties. The step_of_rank can be multiplied by a 138 configurable factor called rank_factor (Section 6.2) that amplifies 139 the rank_increase to reflect the relative preferences between 140 different link types that would be used in a same RPL instance. The 141 rank_increase can be further adapted as detailed in Section 4.1. By 142 default, OF0 encodes the 2-octet Rank in units of 256, and the 143 default settings allow to encode a minimum of 28 (worst acceptable) 144 hops and a maximum of 255 (excellent) hops. 146 The RPL specification [I-D.ietf-roll-rpl] requires the use of a 147 common OF by all nodes in a network. The possible use of multiple 148 OFs with a single network is for further study. 150 The RPL specification [I-D.ietf-roll-rpl] does not include any OF 151 definitions. This is left for other documents specific to different 152 deployments and application environments. Since there is no default 153 OF or metric container in the RPL main specification, it might happen 154 that, unless two given implementations follow the same guidance for a 155 specific problem or environment, those implementations will not 156 support a common OF with which they could interoperate. 158 OF0 is designed as a default OF that will allow interoperation 159 between implementations in a wide spectrum of use cases. This is why 160 OF0 does not specify how the link properties are transformed into a 161 rank_increase and leaves that responsibility to the implementation; 162 rather, OF0 enforces the values for the rank_increase by normalizing 163 the step_of_rank for a normal link and its acceptable range, as 164 opposed to formulating the details of the step_of_rank computation. 165 This is also why OF0 ignores metric containers. 167 2. Terminology 169 The Terminology used in this document is consistent with and 170 incorporates that described in `Terminology in Low power And Lossy 171 Networks' [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl]. 173 The term 'feasible successor' is used to refer to a neighbor that can 174 possibly be used as a next-hop for upwards traffic following the loop 175 avoidance and forwarding rules that the nodes implements and that are 176 defined in the RPL specification [I-D.ietf-roll-rpl]. 178 3. Objective Function Zero Overview 180 The RPL specification describes constraints on how nodes select 181 potential parents, called a parent set, from their neighbors. All 182 parents are feasible successors for upward traffic (towards the 183 root). Additionally, RPL allows the use of parents in a subsequent 184 Version of a same DODAG as feasible successors, in which case this 185 node acts as a leaf in the subsequent DODAG Version. 187 The Goal of the OF0 is for a node to join a DODAG Version that offers 188 good enough connectivity to a specific set of nodes or to a larger 189 routing infrastructure though there is no guarantee that the path 190 will be optimized according to a specific metric. This validation 191 process for the connectivity is implementation and link type 192 dependent, and is out of scope. The validation involves but is not 193 limited to application of [I-D.ietf-roll-rpl] sections 3.2.3 and 13 194 as appropriate, and may involve deployment specific policies as well. 195 Thus, for the purpose of OF0, the term Grounded [I-D.ietf-roll-rpl] 196 means that the DODAG root provides such connectivity. How that 197 connectivity is asserted and maintained is out of scope. 199 Objective Function Zero is designed to find the nearest Grounded 200 root. This can be achieved if the Rank of a node is very close to an 201 abstract function of its distance to the root. This need is balanced 202 with the other need of maintaining some path diversity, which may be 203 achieved by increasing the Rank. In the absence of a Grounded root, 204 inner connectivity within the LLN is still desirable and floating 205 DAGs will form, rooted at the nodes with the highest administrative 206 preference. 208 OF0 selects a preferred parent and a backup feasible successor if one 209 is available. All the upward traffic is normally routed via the 210 preferred parent with no attempt to perform any load balancing. When 211 the link conditions do not let an upward packet through the preferred 212 parent, the packet is passed to the backup feasible successor. 214 A RPL node monitors links to a number of neighbor nodes, and can use 215 OF0 to assign a rank_increase to each link. Though the exact method 216 for computing the rank_increase is implementation-dependent, the 217 computation must follow the rules that are specified in Section 4.1. 219 4. OF0 Operations 221 4.1. Computing Rank 223 An OF0 implementation first computes a variable step_of_rank 224 (Section 6.1) associated with a given parent from relevant link 225 properties and metrics. The step_of_rank is used to compute the 226 amount by which to increase the rank along a particular link, as 227 explained later in this section. 229 Computing a step_of_rank based on a static metric such as an 230 administrative cost implies that the OF0 implementation only 231 considers parents with good enough connectivity, and results in a 232 Rank that is analogous to hop-count. In most LLNs, this favors paths 233 with fewer but longer hops of poorer connectivity; it is thus 234 RECOMMENDED to base the computation of the step_of_rank on dynamic 235 link properties such as the expected transmission count metric (ETX) 236 as introduced in [DeCouto03] and discussed in 237 [I-D.ietf-roll-routing-metrics]. The Minimum Rank Objective Function 238 with Hysteresis [I-D.ietf-roll-minrank-hysteresis-of] provides 239 guidance on how link cost can be computed and on how hysteresis can 240 improve Rank stability. 242 OF0 allows an implementation to stretch the step_of_rank in order to 243 enable the selection of at least one feasible successor and thus 244 maintain path diversity. Stretching the step_of_rank is NOT 245 RECOMMENDED, because it augments the apparent distance from the node 246 to the root, distorts the DODAG from the optimal shape and may cause 247 instabilities due to greedy behaviors whereby depending nodes augment 248 their Ranks to use each other as parents in a loop. Still, an 249 implementation may stretch the step_of_rank with at most a 250 configurable stretch_of_rank (Section 6.2) of any value between 0 (no 251 stretch) and the fixed constant MAXIMUM_RANK_STRETCH (Section 6.3). 253 An implementation MUST maintain the stretched step_of_rank between 254 the fixed constants MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK 255 (Section 6.3). This range allows to reflect a large variation of 256 link quality. 258 The gap between MINIMUM_STEP_OF_RANK and MAXIMUM_RANK_STRETCH may not 259 be sufficient in every case to strongly distinguish links of 260 different types or categories in order to favor, say, powered over 261 battery-operated or wired over wireless, within a same DAG. An 262 implementation SHOULD allow the operator to configure a factor called 263 rank_factor (Section 6.2) and to apply the factor on all links and 264 peers to multiply the effect of the stretched step_of_rank in the 265 rank_increase computation as further detailed below. 267 Additionally, an implementation MAY recognize categories of peers and 268 links, such as different link types, in which case it SHOULD be able 269 to configure a more specific rank_factor to those categories. The 270 rank_factor MUST be set between the fixed constants 271 MINIMUM_RANK_FACTOR and MAXIMUM_RANK_FACTOR (Section 6.3) . 273 The variable rank_increase is represented in units expressed by the 274 variable MinHopRankIncrease which defaults to the fixed constant 275 DEFAULT_MIN_HOP_RANK_INCREASE ([I-D.ietf-roll-rpl]); with that 276 setting, the least significant octet in the RPL Rank field in the DIO 277 Base Object is not used. 279 The step_of_rank Sp that is computed for that link is multiplied by 280 the rank_factor Rf and then possibly stretched by a term Sr that is 281 less than or equal to the configured stretch_of_rank. The resulting 282 rank_increase is added to the Rank of preferred parent R(P) to obtain 283 that of this node R(N): 285 R(N) = R(P) + rank_increase where: 287 rank_increase = (Rf*Sp + Sr) * MinHopRankIncrease 289 Optionally, the administrative preference of a root MAY be configured 290 to supersede the goal to join a Grounded DODAG. In that case, nodes 291 will associate to the root with the highest preference available, 292 regardless of whether that root is Grounded or not. Compared to a 293 deployment with a multitude of Grounded roots that would result in 294 the same multitude of DODAGs, such a configuration may result in 295 possibly less but larger DODAGs, as many as roots configured with the 296 highest priority in the reachable vicinity. 298 4.2. Parent Selection 300 4.2.1. Selection Of The Preferred Parent 302 As it scans all the candidate neighbors, OF0 keeps the parent that is 303 the best for the following criteria (in order): 305 1. [I-D.ietf-roll-rpl] section 8 spells out the generic rules for a 306 node to re-parent and in particular the boundaries to augment 307 its Rank within a DODAG Version. A candidate that would not 308 satisfy those rules MUST NOT be considered. 310 2. An implementation SHOULD validate a router prior to selecting it 311 as preferred. In most cases, a router that does not succeed the 312 validation process can not be further considered for selection 313 as preferred parent. In any case a router that succeeded that 314 validation process SHOULD be preferred. 316 3. When multiple interfaces are available, a policy might be 317 locally configured to order them and that policy applies first; 318 that is a router on a higher order interface in the policy is 319 preferable. 321 4. If the administrative preference of the root is configured to 322 supersede the goal to join a Grounded DODAG, a router that 323 offers connectivity to a more preferable root SHOULD be 324 preferred. 326 5. A router that offers connectivity to a grounded DODAG Version 327 SHOULD be preferred over one that does not. 329 6. A router that offers connectivity to a more preferable root 330 SHOULD be preferred. 332 7. When comparing 2 parents that belong to the same DODAG, a router 333 that offers connectivity to the most recent DODAG Version SHOULD 334 be preferred. 336 8. The parent that causes the lesser resulting Rank for this node, 337 as specified in Section 4.1, SHOULD be preferred. 339 9. A DODAG Version for which there is an alternate parent SHOULD be 340 preferred. This check is OPTIONAL. It is performed by 341 computing the backup feasible successor while assuming that the 342 router that is currently examined is finally selected as 343 preferred parent. 345 10. The preferred parent that was in use already SHOULD be 346 preferred. 348 11. A router that has announced a DIO message more recently SHOULD 349 be preferred. 351 These rules and their order MAY be varied by an implementation 352 according to configured policy. 354 4.2.2. Selection Of The Backup Feasible Successor 356 When selecting a backup feasible successor, the OF performs in order 357 the following checks: 359 1. The backup feasible successor MUST NOT be the preferred parent. 361 2. The backup feasible successor MUST be either in the same DODAG 362 Version as this node or in an subsequent DODAG Version. 364 3. Along with RPL rules, a Router in the same DODAG Version as this 365 node and with a Rank that is higher than the Rank computed for 366 this node MUST NOT be selected as a feasible successor. 368 4. A router with a lesser Rank SHOULD be preferred. 370 5. A router that has been validated as usable by an implementation- 371 dependant validation process SHOULD be preferred. 373 6. When multiple interfaces are available, a router on a higher 374 order interface is preferable. 376 7. The backup feasible successor that was in use already SHOULD be 377 preferred. 379 These rules and their order MAY be varied by an implementation 380 according to configured policy. 382 5. Abstract Interface to OF0 384 Objective Function Zero interacts for its management and operations 385 in the following ways: 387 Processing DIO: When a new DIO is received, the OF that corresponds 388 to the Objective Code Point (OCP) in the DIO is triggered with the 389 content of the DIO. OF0 is identified by OCP 0 (to be validated 390 by IANA Section 8). 392 Providing DAG information: The OF0 support provides an interface 393 that returns information about a given instance. This includes 394 material from the DIO base header, the role (router, leaf), and 395 the Rank of this node. 397 Providing a Parent List: The OF0 support provides an interface that 398 returns the ordered list of the parents and feasible successors 399 for a given instance to the RPL core. This includes the material 400 that is contained in the transit option for each entry. 402 Triggered Updates: The OF0 support provides events to inform it that 403 a change in DAG information or Parent List as occurred. This can 404 be caused by an interaction with another system component such as 405 configuration, timers, and device drivers, and the change may 406 cause the RPL core to fire a new DIO or reset trickle timers. 408 6. OF0 Operands 410 On top of variables and constants defined in [I-D.ietf-roll-rpl], 411 this specification introduces the following variables and constants: 413 6.1. Variables 415 OF0 uses the following variables: 417 step_of_rank (strictly positive integer): an intermediate 418 computation based on the link properties with a certain neighbor. 420 rank_increase (strictly positive integer): delta between the Rank of 421 the preferred parent and self 423 6.2. Configurable Parameters 425 OF0 can use the following optional configurable values that are used 426 as parameters to the rank_increase computation: 428 stretch_of_rank (unsigned integer): the maximum augmentation to the 429 step-of-rank of a preferred parent to allow the selection of an 430 additional feasible successor. If none is configured to the 431 device, then the step_of_rank is not stretched. 433 rank_factor (strictly positive integer): A configurable factor that 434 is used to multiply the effect of the link properties in the 435 rank_increase computation. If none is configured, then a 436 rank_factor of 1 is used. 438 6.3. Constants 440 Section 17 of [I-D.ietf-roll-rpl] defines RPL constants. OF0 fixes 441 the values of the following constants: 443 DEFAULT_STEP_OF_RANK: 3 445 MINIMUM_STEP_OF_RANK: 1 447 MAXIMUM_STEP_OF_RANK: 9 449 DEFAULT_RANK_STRETCH: 0 451 MAXIMUM_RANK_STRETCH: 5 453 DEFAULT_RANK_FACTOR: 1 455 MINIMUM_RANK_FACTOR: 1 457 MAXIMUM_RANK_FACTOR: 4 459 7. Manageability Considerations 461 Section 18 of [I-D.ietf-roll-rpl] depicts the management of the 462 protocol. This specification inherits from that section and its 463 subsections, with the exception that metrics as specified in 465 [I-D.ietf-roll-routing-metrics] are not used and do not require 466 management. 468 7.1. Device Configuration 470 An implementation SHOULD allow to configure at least a global 471 rank_factor that applies to all links. Additionally, the 472 implementation may allow to group interfaces, links and/or neighbors 473 and configure a more specific rank_factor to such groups. 475 An implementation MAY allow to configure a maximum stretch_of_rank as 476 discussed in Section 4.1. If none is configured, a value of 0 is 477 assumed and the step_of_rank is not stretched. 479 An OF0 implementation SHOULD support the DODAG Configuration option 480 as specified in section 6.7.6 of [I-D.ietf-roll-rpl] and apply the 481 parameters contained therein. As discussed in section 16 of 482 [I-D.ietf-roll-rpl], this requirement might be overridden by further 483 guidance for certain application scenarios. When the option is used, 484 the parameters are configured to the nodes that may become DODAG 485 roots, and the nodes are configured to redistribute the information 486 using the DODAG Configuration option. In particular, the value of 487 MinHopRankIncrease can be distributed with that option and override 488 the fixed constant of DEFAULT_MIN_HOP_RANK_INCREASE that is defined 489 section 17 of [I-D.ietf-roll-rpl] with a fixed value of 256. 491 Out of the box, that is at initial factory time, the default constant 492 values SHOULD be used, that is: 494 the rank_factor is set to the fixed constant DEFAULT_RANK_FACTOR 495 (Section 6.3). 497 the maximum stretch_of_rank is set to the fixed constant 498 DEFAULT_RANK_STRETCH (Section 6.3). 500 the MinHopRankIncrease is set to the fixed constant 501 DEFAULT_MIN_HOP_RANK_INCREASE ([I-D.ietf-roll-rpl]). 503 The values can be overridden at anytime and apply at the next Version 504 of the DODAG. As discussed in section 16 of [I-D.ietf-roll-rpl], 505 this requirement might be overridden by further guidance for certain 506 application scenarios. 508 7.2. Device Monitoring 510 As discussed in Section 5, the OF support must be able to provide 511 information about its operations, and trigger events when that 512 information changes. At a minimum, the information should include: 514 DAG information as specified in Section 6.3.1 of 515 [I-D.ietf-roll-rpl], and including the DODAGID, the RPLInstanceID, 516 the Mode of Operation, the Rank of this node, the current Version 517 Number, and the value of the Grounded flag. 519 A list of neighbors indicating the preferred parent and an 520 alternate feasible if available. For each neighbor, the Rank, the 521 current Version Number, and the value of the Grounded flag should 522 be indicated. 524 8. IANA Considerations 526 This specification requires the assignment of an Objective Code Point 527 (OCP) for OF0 in the Objective Code Point Registry that is requested 528 in section 20.5. of [I-D.ietf-roll-rpl]. 530 OCP code: The value of 0 is suggested. 532 Description: A basic Objective Function that relies only on the 533 objects that are defined in [I-D.ietf-roll-rpl]. 535 Defining RFC: This. 537 9. Security Considerations 539 This specification makes simple extensions to RPL and so is 540 vulnerable to and benefits from the security issues and mechanisms 541 described in [I-D.ietf-roll-rpl] and 542 [I-D.ietf-roll-security-framework]. This document does not introduce 543 new flows or new messages, thus requires no specific mitigation for 544 new threats. 546 OF0 depends on information exchanged in the Rank and OCP protocol 547 elements. If those elements were compromised, then an implementation 548 of OF0 might generate the wrong path for a packet, resulting in it 549 being misrouted. Therefore, deployments are RECOMMENDED to use RPL 550 security mechanisms if there is a risk that routing information might 551 be modified or spoofed. 553 10. Acknowledgements 555 Most specific thanks to Philip Levis and Phoebus Chen for their help 556 in finalizing this document. 558 Many thanks also to Adrian Farrel, Tim Winter, JP Vasseur, Julien 559 Abeille, Mathilde Durvy, Teco Boot, Navneet Agarwal, Meral 560 Shirazipour and Henning Rogge for in-depth review and first hand 561 implementers' feedback. 563 11. References 565 11.1. Normative References 567 [I-D.ietf-roll-rpl] 568 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 569 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 570 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 571 Lossy Networks", draft-ietf-roll-rpl-19 (work in 572 progress), March 2011. 574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 575 Requirement Levels", BCP 14, RFC 2119, March 1997. 577 11.2. Informative References 579 [DeCouto03] 580 De Couto, Aguayo, Bicket, and Morris, "A High-Throughput 581 Path Metric for Multi-Hop Wireless Routing", MobiCom 582 '03 The 9th ACM International Conference on Mobile 583 Computing and Networking, San Diego, California,, 2003, . 586 [I-D.ietf-roll-minrank-hysteresis-of] 587 Gnawali, O. and P. Levis, "The Minimum Rank Objective 588 Function with Hysteresis", 589 draft-ietf-roll-minrank-hysteresis-of-04 (work in 590 progress), May 2011. 592 [I-D.ietf-roll-routing-metrics] 593 Vasseur, J., Kim, M., Pister, K., Dejean, N., and D. 594 Barthel, "Routing Metrics used for Path Calculation in Low 595 Power and Lossy Networks", 596 draft-ietf-roll-routing-metrics-19 (work in progress), 597 March 2011. 599 [I-D.ietf-roll-security-framework] 600 Tsao, T., Alexander, R., Dohler, M., Daza, V., and A. 601 Lozano, "A Security Framework for Routing over Low Power 602 and Lossy Networks", draft-ietf-roll-security-framework-06 603 (work in progress), June 2011. 605 [I-D.ietf-roll-terminology] 606 Vasseur, J., "Terminology in Low power And Lossy 607 Networks", draft-ietf-roll-terminology-05 (work in 608 progress), March 2011. 610 Author's Address 612 Pascal Thubert (editor) 613 Cisco Systems 614 Village d'Entreprises Green Side 615 400, Avenue de Roumanille 616 Batiment T3 617 Biot - Sophia Antipolis 06410 618 FRANCE 620 Phone: +33 497 23 26 34 621 Email: pthubert@cisco.com