idnits 2.17.00 (12 Aug 2021) /tmp/idnits27905/draft-thubert-roll-asymlink-00.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 (October 17, 2011) is 3869 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: draft-ietf-roll-rpl has been published as RFC 6550 == Outdated reference: draft-ietf-roll-terminology has been published as RFC 7102 ** Downref: Normative reference to an Informational draft: draft-ietf-roll-terminology (ref. 'I-D.ietf-roll-terminology') == Outdated reference: draft-ietf-roll-of0 has been published as RFC 6552 Summary: 1 error (**), 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 October 17, 2011 5 Expires: April 19, 2012 7 RPL adaptation for asymmetrical links 8 draft-thubert-roll-asymlink-00 10 Abstract 12 The Routing Protocol for Low Power and Lossy Networks defines a 13 generic Distance Vector protocol for Low Power and Lossy Networks, 14 many of which exhibit strongly asymmetrical characteristics. This 15 draft proposes an extension for that optimizes RPL operations whereby 16 upwards and downwards direction-optimized RPL instances are 17 associated. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 19, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. The asymmetrical link problem . . . . . . . . . . . . . . . . . 4 62 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Modified DODAG Information Object (DIO) . . . . . . . . . . . . 5 64 6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 7. Backward compatibility . . . . . . . . . . . . . . . . . . . . 6 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 68 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 11.1. Normative References . . . . . . . . . . . . . . . . . . . 8 71 11.2. Informative References . . . . . . . . . . . . . . . . . . 8 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 The IETF ROLL Working Group has defined application-specific routing 77 requirements for a Low Power and Lossy Network (LLN) routing 78 protocol, specified in [RFC5548], [RFC5673], [RFC5826], and 79 [RFC5867], many of which explicitly or implicitly refer to links with 80 asymmetrical properties. 82 Upon those requirements, the Routing Protocol for Low Power and Lossy 83 Network [I-D.ietf-roll-rpl] was designed as a platform that can be 84 extended by further specifications or guidances, by adding new 85 metrics, Objective Functions, or additional options. 87 RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) 88 within instances of the protocol. Each instance is associated with 89 an Objective Function that is designed to solve the problem that is 90 addressed by that instance. 92 In one hand, RPL requires bidirectional links for the control, but on 93 the other, there is no requirement that the properties of a link are 94 the same in both directions. In fact, such a symmetry is rarely 95 present in LLNs, whether links are based on radios or power-line. 97 Some initial implementations require that the quality of both 98 directions of a link is evaluated as very good so that the link can 99 be used for control and data in both directions. This eliminates 100 asymmetrical links that are very good in one direction, but only good 101 enough for scarce activity in the other direction. 103 In practice, a DAG that is built to optimize upwards traffic is 104 generally not congruent with a DAG that is built to optimize 105 downwards traffic. This is why this specification is designed to 106 enable asymmetrical routing DAGs that are bound together to get the 107 maximum benefits of all bidirectional links. 109 2. Terminology 111 The terminology used in this document is consistent with and 112 incorporates that described in `Terminology in Low power And Lossy 113 Networks' [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl]. 115 The term upwards qualifies a link, a DODAG or an instance that is 116 optimal for sending traffic in the general direction of the root, 117 though may be usable but suboptimal for traffic coming form the 118 direction of the root. The term downwards qualifies the same words 119 for the opposite direction. 121 The term parenting applied to instances refers to the directional 122 association of two instances. The graph formed by parented instances 123 must be a DAG. Traffic may be transferred from an instance onto a 124 parent instance under specified circumstances. 126 3. The asymmetrical link problem 128 4. Solution Overview 130 With the core RPL specification, [I-D.ietf-roll-rpl] each instance is 131 a separate routing topology, and packets must be forwarded within the 132 same topology / same instance. One direct consequence of that design 133 choice is that a topology must be very good for both upwards and 134 downwards traffic; otherwise, traffic between two nodes in the 135 instance may suffer. 137 A simple approach to address bidirectional but asymmetrical links 138 with RPL is to construct two DAGs, one for upwards traffic and one 139 for downwards traffic, each DAG a separate instance, and then bind 140 the two together. In order to benefit from both instances for a same 141 packet, this solution extends RPL to allow traffic to be transferred 142 from one instance to the next. 144 It can be noted at this point that with [I-D.ietf-roll-rpl], traffic 145 that goes down does not generally go back up again, whereas P2P 146 traffic within a DODAG might go up to a common parent and then down 147 to the destination. In terms of instance relationship, this means 148 that when an upwards and a downwards instance are bound together, 149 traffic from the former may be transferred to the latter, but not the 150 other way around. In other words, there is an order, a parent-child 151 relationship, between the two instances. 153 Additionally, if there is no next-hop for a packet going down within 154 the instance, then with [I-D.ietf-roll-rpl] the packet must be 155 dropped. In order to limit that risk, it is tempting though 156 inefficient to lower the constraints that are applied to build the 157 topology. It can be more efficient to actually keep the constraints 158 as they should be, but, instead, enable a less constrained, more 159 spanning, fall-back topology into which traffic can be transferred. 161 For that reason, this solution allows for more complex instance 162 relationships than plain child-parent associations. In order to 163 avoids loops which could be created when transferring packets from 164 one instance to the next, this solution requires that the instances 165 be themselves organized as a superior Directed Acyclic Graph, and 166 enforce that inter-DAG transfers occur only within that superior 167 super-DAG of DAG instances. 169 5. Modified DODAG Information Object (DIO) 171 The DODAG Information Object [I-D.ietf-roll-rpl] carries information 172 that allows a node to discover a RPL Instance, learn its 173 configuration parameters, select a DODAG parent set, and maintain the 174 DODAG. This specification defines a new flag bit to indicate that 175 the DAG is directional. 177 0 1 2 3 178 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | RPLInstanceID |Version Number | Rank | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 |G|D| MOP | Prf | DTSN | Flags | Reserved | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | | 185 + + 186 | | 187 + DODAGID + 188 | | 189 + + 190 | | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Option(s)... 193 +-+-+-+-+-+-+-+-+ 195 Figure 1: The DIO Base Object 197 Directional (D): The Directional (D) flag is set to indicate that 198 the instance is intended for directional operation, and reset 199 otherwise. When it is set, a MOP of 0 indicates the upwards 200 direction whereas any other value specified in 201 [I-D.ietf-roll-rpl] indicates downwards. All other values of 202 MOP will be considered downwards unless explicitly specified 203 otherwise. 205 6. Operations 207 This specification allows an organization of Instances as follows: 209 Instances MUST be organized as a Directed Acyclic Graph. This 210 information MUST be commissioned into the devices so they know 211 both which instances they should participate in, and which 212 direction of transfer is allowed between instances. 214 A spanning instance using OF0 [I-D.ietf-roll-of0] MAY be used as 215 root in that instance DAG. 217 This specification defines a new bit in the RPL [I-D.ietf-roll-rpl] 218 DODAG Information Object (DIO) with the Directional (D) flag that 219 indicates a directional operation for a given instance. An 220 implementation that does not support that new bit will not be able to 221 propagate it. 223 In case of a directional operation, 225 The direction is indicated by the MOP field, a MOP of 0 means 226 upwards and otherwise is downwards. 228 Links are still REQUIRED to allow bidirectional operations 230 Only the metrics that correspond to the DAG direction are used for 231 the parent selection. 233 An upward instance SHOULD install routes that lead to the root and 234 beyond - typically the default route. 236 A downwards instance MAY ONLY install more specific routes that 237 are injected by nodes in the DODAG through the DAO process. 239 P2P operations are achieved by associating a child upwards 240 instance with a parent downwards instance. 242 A packet MUST NOT be transferred from a parent instance to a child 243 instance. 245 A packet MAY be transferred from a child instance to its parent 246 instance if and only if the child instance does not provide a 247 route to the destination, or the parent instance provides a more 248 specific route (longer match) to the destination. 250 Transferring from an upwards instance to a downwards instance if 251 generally desirable. Other forms of transfers are generally not 252 desirable. Policies MAY be put in place to ovreride that general 253 guidance. 255 7. Backward compatibility 257 An OF is generally designed to compute a Rank of a directional link 258 in a fashion that is diffent from a bidirectional link, and in 259 particular will not use the same metrics and thusobtain different 260 ranks for a same situation. For that reason, it is important that 261 the OF is aware that an instance is supposed to define a directional 262 DODAG, and it is RECOMMENDED that only devices that support 263 directional DODAGs are allowed in a directional instance. 265 It might happen that for some purposes like higher availability, an 266 implementation that does not support directional links is 267 administratively allowed to join a directional DODAG. In that case, 268 the extension of the DODAG that starts at that device will not be 269 directional, but the instance will still be functional. 271 In that case, it might also happen that a device that supports 272 directional DODAGs per this specification sees candidate neighbors 273 that expose the Directional flag and some others that do not. An OF 274 that supports directional links SHOULD favor directional links over 275 non directional links, in a fashion that is to be specified with the 276 OF. In the case of OF0 [I-D.ietf-roll-of0], the 'D' flag should be 277 accounted for before the computation of item 8 in the "Selection Of 278 The Preferred Parent" section 4.2.1., that is before Ranks and be 279 calculated and compared. 281 8. IANA Considerations 283 This specification requires that a bit in DIO be assigned to indicate 284 directional link operations as specified in section 286 9. Security Considerations 288 Security Considerations for this proposal are to be developed in 289 accordance with recommendations laid out in, for example, 290 [I-D.tsao-roll-security-framework]. 292 10. Acknowledgements 294 The author wishes to recognize Richard Kelsey, JP Vasseur, Tom 295 Phinney, Robert Assimiti, Don Sturek and Yoav Ben-Yehezkel for their 296 various contributions. 298 11. References 299 11.1. Normative References 301 [I-D.ietf-roll-rpl] 302 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 303 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 304 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 305 Lossy Networks", draft-ietf-roll-rpl-19 (work in 306 progress), March 2011. 308 [I-D.ietf-roll-terminology] 309 Vasseur, J., "Terminology in Low power And Lossy 310 Networks", draft-ietf-roll-terminology-06 (work in 311 progress), September 2011. 313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 314 Requirement Levels", BCP 14, RFC 2119, March 1997. 316 11.2. Informative References 318 [I-D.ietf-roll-of0] 319 Thubert, P., "RPL Objective Function Zero", 320 draft-ietf-roll-of0-20 (work in progress), September 2011. 322 [I-D.tsao-roll-security-framework] 323 Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A 324 Security Framework for Routing over Low Power and Lossy 325 Networks", draft-tsao-roll-security-framework-02 (work in 326 progress), March 2010. 328 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 329 "Routing Requirements for Urban Low-Power and Lossy 330 Networks", RFC 5548, May 2009. 332 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 333 "Industrial Routing Requirements in Low-Power and Lossy 334 Networks", RFC 5673, October 2009. 336 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 337 Routing Requirements in Low-Power and Lossy Networks", 338 RFC 5826, April 2010. 340 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 341 "Building Automation Routing Requirements in Low-Power and 342 Lossy Networks", RFC 5867, June 2010. 344 Author's Address 346 Pascal Thubert (editor) 347 Cisco Systems 348 Village d'Entreprises Green Side 349 400, Avenue de Roumanille 350 Batiment T3 351 Biot - Sophia Antipolis 06410 352 FRANCE 354 Phone: +33 497 23 26 34 355 Email: pthubert@cisco.com