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