idnits 2.17.1 draft-ietf-roll-of0-04.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 (December 8, 2010) is 4887 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 (-09) exists of draft-ietf-roll-building-routing-reqs-07 == Outdated reference: A later version (-11) exists of draft-ietf-roll-home-routing-reqs-08 == Outdated reference: A later version (-19) exists of draft-ietf-roll-routing-metrics-13 == Outdated reference: A later version (-19) exists of draft-ietf-roll-rpl-15 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-04 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 December 8, 2010 5 Expires: June 11, 2011 7 RPL Objective Function 0 8 draft-ietf-roll-of0-04 10 Abstract 12 The Routing Protocol for Low Power and Lossy Networks (RPL) defines a 13 generic Distance Vector protocol for Low Power and Lossy Networks 14 (LLNs). RPL is instantiated to honor a particular routing objective/ 15 constraint by the adding a specific Objective Function (OF) that is 16 designed to solve that problem. This specification defines a basic 17 OF, OF0, that uses only the abstract properties exposed in RPL 18 messages to maximize connectivity. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on June 11, 2011. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Selection of the Preferred Parent . . . . . . . . . . . . . . . 5 64 5. Selection of the Backup next_hop . . . . . . . . . . . . . . . 6 65 6. Abstract Interface with RPL core . . . . . . . . . . . . . . . 6 66 7. OF0 Constants and Variables . . . . . . . . . . . . . . . . . . 7 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 69 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 11.1. Normative References . . . . . . . . . . . . . . . . . . . 8 72 11.2. Informative References . . . . . . . . . . . . . . . . . . 8 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 The IETF ROLL Working Group has defined application-specific routing 78 requirements for a Low Power and Lossy Network (LLN) routing 79 protocol, specified in [I-D.ietf-roll-building-routing-reqs], 80 [I-D.ietf-roll-home-routing-reqs], [RFC5673], and [RFC5548]. 82 Considering the wide variety of use cases, link types and metrics, 83 the Routing Protocol for Low Power and Lossy Networks 84 [I-D.ietf-roll-rpl] was designed as a generic core that is agnostic 85 to metrics and instantiated using Objective Functions. 87 RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) 88 within instances of the protocol, each instance being set up to honor 89 a particular routing objective/constraint of a given deployment. 90 This instantiation is achieved by plugging into the RPL core a 91 specific Objective Function (OF) that is designed to solve that 92 problem to be addressed by that instance. 94 the Objective Function selects the DODAG iteration that a device 95 joins, and a number of neighbor routers within that iteration as 96 parents and siblings. The OF is also responsible for computing the 97 Rank of the device, that abstracts a relative position within the 98 DODAG and is used by the RPL core to enable a degree of loop 99 avoidance and verify forward progression towards a destination, as 100 specified in [I-D.ietf-roll-rpl]. 102 This specification defines the Objective Function 0 (OF0), that 103 corresponds to the Objective Code Point 0. OF0 does not leverage 104 link layer metrics such as described in the metrics draft 105 [I-D.ietf-roll-routing-metrics], but is only based on abstract 106 information from the DIO base container, such as Rank and an 107 administrative preference, that is transported in DIOs as 108 DODAGPreference in [I-D.ietf-roll-rpl]. 110 2. Terminology 112 The terminology used in this document is consistent with and 113 incorporates that described in `Terminology in Low power And Lossy 114 Networks' [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl]. 116 3. Goal 118 The Goal of the OF0 is to join a DODAG iteration that offers 119 connectivity to a specific set of nodes or to a larger routing 120 infrastructure. For the purpose of OF0, Grounded thus means that the 121 root provides such connectivity. How that connectivity is asserted 122 and maintained is out of scope. 124 Objective Function 0 is designed to find the nearest Grounded root. 125 In the absence of a Grounded root, LLN inner connectivity is still 126 desirable and floating DAGs will form, rooted at the nodes with the 127 highest administrative preference. 129 The metric used in OF0 is an administratively defined scalar cost 130 that is trivially added up along a path to compute the RPL Rank, as 131 defined in [I-D.ietf-roll-rpl]. As a result, the Rank if a node is 132 analogous to a weighted hop count of the path to the root. Using a 133 metric that in essence is similar to hop count implies that the 134 quality of the connectivity should be asserted so that only neighbors 135 with a good enough connectivity are presented to the OF. How that 136 connectivity is asserted and maintained is out of scope. 138 Hop count used in wireless networks will tend to favor paths with 139 long distance links and non optimal connectivity properties. As a 140 result, the link selection must be very conservative, and the 141 available link set is thus constrained. In some situations, this 142 might end up partitioning the network. For those reasons, though it 143 can be used on wired links and wired link emulations such as WIFI 144 infrastructure mode, OF0 is generally not recommended for wireless 145 networks. 147 The default step of Rank is DEFAULT_RANK_INCREMENT for each hop. An 148 implementation MAY allow a step between MINIMUM_RANK_INCREMENT and 149 MAXIMUM_RANK_INCREMENT to reflect a large variation of link quality 150 by units of MINIMUM_RANK_INCREMENT. In other words, the least 151 significant octet in the Rank is not used. 153 It MAY stretch its step of Rank by up to MAXIMUM_RANK_STRETCH in 154 order to enable the selection of a sibling when only one parent is 155 available. For instance, say that a node computes a step of Rank of 156 4 units of MINIMUM_RANK_INCREMENT from a preferred parent with a Rank 157 of 6 units resulting in a Rank of 10 units for this node. Say that 158 with that Rank of 10 units, this node would end up with only one 159 parent and no sibling, though there is a neighbor with a Rank of 12 160 units. In that case, the node is entitled to stretch its step of 161 Rank by a value of 2 units, thus using a step of Rank of 6 units so 162 as to reach a Rank of 12 units and find a sibling. But the node is 163 not entitled to use a step of Rank larger than 6 units since that 164 would be a greedy behavior that would deprive the neighbor of this 165 node of a successor. Also, if the neighbor had exposed a Rank of 16 166 units, the stretch of Rank from 10 to 16 units would have exceeded 167 MAXIMUM_RANK_STRETCH of 4 units and thus the neighbor would not have 168 been selectable even as a sibling. 170 Optionally, the administrative preference of a root MAY be configured 171 to supercede the goal to reach Grounded root. In that case, nodes 172 will associate to the root with the highest preference available, 173 regardless of whether that root is Grounded or not. Compared to a 174 deployment with a multitude of Grounded roots that would result in a 175 same multitude of DODAGs, such a configuration may result in possibly 176 less but larger DODAGs, as many as roots configured with the highest 177 priority in the reachable vincinity. 179 OF0 selects a preferred parent and a backup next_hop if one is 180 available. The backup next_hop might be a parent or a sibling. All 181 the traffic is routed via the preferred parent. When the link 182 conditions do not let a packet through the preferred parent, the 183 packet is passed to the backup next_hop. 185 4. Selection of the Preferred Parent 187 As it scans all the candidate neighbors, OF0 keeps the parent that is 188 the best for the following criteria (in order): 190 1. [I-D.ietf-roll-rpl] spells out the generic rules for a node to 191 reparent and in particular the boundaries to augment its Rank 192 within a DODAG iteration. A candidate that would not satisfy 193 those rules MUST NOT be considered. 195 2. An implementation should validate a router prior to selecting it 196 as preferred. This validation process is implementation and 197 link type dependent, and is out of scope. A router that has 198 been validated is preferrable. 200 3. When multiple interfaces are available, a policy might be 201 locally configured to prioritize them and that policy applies 202 first; that is a router on a higher order interface is 203 preferable. 205 4. In the absence of a Grounded DODAG iteration, the router with a 206 higher administrative preference SHOULD be preferred. 207 Optionally, this selection applies regardless of whether the 208 DODAG is Grounded or not. 210 5. A router that offers connectivity to a grounded DODAG iteration 211 SHOULD be preferred over one that does not. 213 6. When comparing 2 routers that belong to the same DODAG, a router 214 that offers connectivity to the freshest sequence SHOULD be 215 preferred. 217 7. When computing a resulting Rank for this node from a parent Rank 218 and a Step of Rank from that parent, the parent that causes the 219 lesser resulting Rank SHOULD be preferred. 221 8. A DODAG iteration for which there is an alternate parent SHOULD 222 be preferred. This check is optional. It is performed by 223 computing the backup next_hop while assuming that the router 224 that is currently examined is finally selected as preferred 225 parent. 227 9. The DODAG iteration that was in use already SHOULD be preferred. 229 10. The preferred parent that was in use already SHOULD be 230 preferred. 232 11. A router that has announced a DIO message more recently SHOULD 233 be preferred. 235 5. Selection of the Backup next_hop 237 o When multiple interfaces are available, a router on a higher order 238 interface is preferable. 240 o The preferred parent MUST be ignored. 242 o A Router that is not in the same DODAG as the preferred parent, 243 either in the current or a subsequent iteration, MUST be ignored. 245 o A Router with a Rank that is higher than the Rank computed for 246 this node out of the preferred parent SHOULD NOT be selected as 247 parent, to avoid greedy behaviors. It MAY still be selected as 248 sibling if no better Back-up next hop is found. 250 o A router with a lesser Rank SHOULD be preferred. 252 o A router that has been validated as usable by an implementation 253 dependant validation process SHOULD be preferred. 255 o The backup next_hop that was in use already SHOULD be preferred. 257 6. Abstract Interface with RPL core 259 Objective Function 0 interacts with the core RPL in the following 260 ways: 262 Processing DIO: This core RPL triggers the OF when a new DIO was 263 received. OF0 analyses the information in the DIO and may 264 select the source as a parent or sibling. 266 Providing DAG information The OF0 support can be required to provide 267 the DAG information for a given instance to the RPL core. 268 This includes the material that is contained in a DIO base 269 header. 271 Providing a Parent List The OF0 support can be required to provide 272 the list of the parents for a given instance to the RPL 273 core. This includes the material that is contained in the 274 transit option for that parent. 276 Trigger The OF0 support may trigger the RPL core to inform it that 277 a change occurred. This indicates whether the change 278 requires a new DIO to be fired, trickle timers to be 279 reset, etc... 281 7. OF0 Constants and Variables 283 OF0 uses the following constants: 285 MinHopRankIncrease: 256 287 DEFAULT_RANK_INCREMENT: 4 * MinHopRankIncrease 289 MINIMUM_RANK_INCREMENT: 1 * MinHopRankIncrease 291 MAXIMUM_RANK_INCREMENT: 16 * MinHopRankIncrease 293 MAXIMUM_RANK_STRETCH: 4 * MinHopRankIncrease 295 8. IANA Considerations 297 IThis specification requires the assignment of an OCP for OF0. The 298 value of 0 is suggested. 300 9. Security Considerations 302 Security Considerations for OCP/OF are to be developed in accordance 303 with recommendations laid out in, for example, 304 [I-D.tsao-roll-security-framework]. 306 10. Acknowledgements 308 Most specific thanks to Tim Winter, JP Vasseur, Julien Abeille, 309 Mathilde Durvy, Teco Boot, Navneet Agarwal and Henning Rogge for in- 310 depth review and first hand implementer's feedback. 312 11. References 314 11.1. Normative References 316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 317 Requirement Levels", BCP 14, RFC 2119, March 1997. 319 11.2. Informative References 321 [I-D.ietf-roll-building-routing-reqs] 322 Martocci, J., Riou, N., Mil, P., and W. Vermeylen, 323 "Building Automation Routing Requirements in Low Power and 324 Lossy Networks", draft-ietf-roll-building-routing-reqs-07 325 (work in progress), September 2009. 327 [I-D.ietf-roll-home-routing-reqs] 328 Brandt, A., Buron, J., and G. Porcu, "Home Automation 329 Routing Requirements in Low Power and Lossy Networks", 330 draft-ietf-roll-home-routing-reqs-08 (work in progress), 331 September 2009. 333 [I-D.ietf-roll-routing-metrics] 334 Vasseur, J., Kim, M., Pister, K., Dejean, N., and D. 335 Barthel, "Routing Metrics used for Path Calculation in Low 336 Power and Lossy Networks", 337 draft-ietf-roll-routing-metrics-13 (work in progress), 338 December 2010. 340 [I-D.ietf-roll-rpl] 341 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 342 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 343 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 344 Lossy Networks", draft-ietf-roll-rpl-15 (work in 345 progress), November 2010. 347 [I-D.ietf-roll-terminology] 348 Vasseur, J., "Terminology in Low power And Lossy 349 Networks", draft-ietf-roll-terminology-04 (work in 350 progress), September 2010. 352 [I-D.tsao-roll-security-framework] 353 Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A 354 Security Framework for Routing over Low Power and Lossy 355 Networks", draft-tsao-roll-security-framework-02 (work in 356 progress), March 2010. 358 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 359 "Routing Requirements for Urban Low-Power and Lossy 360 Networks", RFC 5548, May 2009. 362 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 363 "Industrial Routing Requirements in Low-Power and Lossy 364 Networks", RFC 5673, October 2009. 366 Author's Address 368 Pascal Thubert (editor) 369 Cisco Systems 370 Village d'Entreprises Green Side 371 400, Avenue de Roumanille 372 Batiment T3 373 Biot - Sophia Antipolis 06410 374 FRANCE 376 Phone: +33 497 23 26 34 377 Email: pthubert@cisco.com