idnits 2.17.1 draft-thubert-roll-asymlink-02.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 9, 2011) is 4520 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-06 ** Downref: Normative reference to an Informational draft: draft-ietf-roll-terminology (ref. 'I-D.ietf-roll-terminology') Summary: 1 error (**), 0 flaws (~~), 2 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 9, 2011 5 Expires: June 11, 2012 7 RPL adaptation for asymmetrical links 8 draft-thubert-roll-asymlink-02 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 June 11, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 7. Backwards Compatibility . . . . . . . . . . . . . . . . . . . . 7 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 68 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 11.1. Normative References . . . . . . . . . . . . . . . . . . . 8 71 11.2. Informative References . . . . . . . . . . . . . . . . . . 9 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 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 specification or guidance, by adding new metrics, 85 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 On one hand, RPL requires bi-directional links for the control, but 93 on the other hand, there is no requirement that the properties of a 94 link are the same in both directions. In fact, a perfect symmetry is 95 rarely present in Low Power and Lossy Networks (LLNs) such as 96 wireless radio or power-line links. 98 Some initial implementations require that the quality of both 99 directions of a link is evaluated as operational at an acceptable 100 level so that the link can be used for control and data in both 101 directions. This eliminates asymmetrical links that are not 102 operational at an acceptable level in one direction. 104 In practice, a DAG that is built to optimize upwards traffic is 105 generally not congruent with a DAG that is built to optimize 106 downwards traffic. This is why this specification is designed to 107 enable asymmetrical routing DAGs that are bound together to get the 108 maximum benefits of all types of bi-directional links. 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 The term upwards qualifies a link, a DODAG or a RPL instance that is 117 optimal for sending traffic towards the root, though may be usable 118 but suboptimal for traffic coming from the direction of the root. 119 The term downwards qualifies the same wording, only for opposite 120 directions. 122 The term parenting applied to instances refers to the directional 123 association of two instances. The meta graph formed by parented 124 instances must be a DAG. Traffic may be transferred from an instance 125 onto a parent instance under specified circumstances. 127 The draft also uses the following terminology: 129 bi-directional: A link is bi-directional when traffic is confirmed 130 possible in both directions, in a fashion that is sufficient to 131 operate RPL control. 133 asymmetric: A link is asymmetric if it is bi-directional, yet 134 exhibits major differences in link characteristics for both 135 directions. 137 3. The Asymmetrical Link Problem 139 4. Solution Overview 141 With the core RPL specification, [I-D.ietf-roll-rpl] each instance is 142 a separate routing topology, and packets must be forwarded within the 143 same topology / same instance. One direct consequence of that design 144 choice is that a topology must be operational at an acceptable level 145 for both upwards and downwards traffic; otherwise, traffic between 146 two nodes in the RPL instance may suffer. 148 RPL is designed to operate on bi-directional links. When the link 149 properties do not widely differ between the upwards and the downwards 150 directions, a single DAG is adequate as the routing topology for both 151 upwards and downwards traffic. In that case, an asymmetrical link, 152 that can only be used for traffic in one direction, cannot 153 participate to the routing topology. This results in an sub-optimal 154 bandwidth utilization and/or a reduction of the possible path 155 diversity. 157 This issue can be addressed with [I-D.ietf-roll-rpl], by constructing 158 two DAGs, one that is used for upwards traffic and one that is used 159 for downwards traffic. This solves the issue for all traffic that 160 transits through the root of the DODAG, whether it is originated in 161 the DODAG going out or is injected into the DODAG from the outside, 162 since in both cases a packet will mostly use the asymmetric links in 163 the appropriate direction. 165 On the other hand, with RPL as it is specified, a packet follows the 166 topology that is generated for its instance all the way through a 167 DAG, and transferring a packet from an instance to another is not 168 permitted. As a result, the 2 DAGs solution would penalize Peer to 169 peer traffic that would have to go through the root in order to leave 170 the upward instance and then reenter at the root in order to join the 171 downwards instance. This is not an issue in non-storing mode since 172 the packet has to go through the root to load the routing header 173 downwards anyway, but going through the root stretches the path in 174 storing mode. 176 In order to benefit from both instances and yet avoid extra stretch 177 through the root in storing mode, it is required to extend RPL rules 178 so as to allow traffic to be transferred from one instance to the 179 next before reaching the root on the way up. This document specifies 180 conditions under which 2 instances can be bound together so that a 181 node may transfer traffic from a RPL instance onto another, e.g. from 182 an upwards RPL instance onto the downwards RPL instance. 184 It can be noted at this point that with [I-D.ietf-roll-rpl], traffic 185 that goes down does not generally go back up again, whereas P2P 186 traffic within a DODAG might go up to a common parent and then down 187 to the destination. In terms of instance relationship, this means 188 that when an upwards and a downwards instances are bound together, 189 traffic from the former may be transferred to the latter, but not the 190 other way around. In other words, there is an order, a parent-child 191 relationship, between the two instances. 193 Additionally, if there is no next-hop for a packet going down within 194 the instance, then with [I-D.ietf-roll-rpl] the packet will be 195 dropped or sent back with an error along the wrong direction of an 196 asymmetric link. In order to avoid those unwanted behaviors, it is 197 tempting though inefficient to lower the constraints that are applied 198 to build the topology. It can be more efficient to actually keep the 199 constraints as they should be, but, instead, enable a less 200 constrained, more spanning, fallback topology into which traffic can 201 be transferred. 203 For that reason, this solution allows for more complex instance 204 relationships than plain child-parent associations. In order to 205 avoids loops which could be created when transferring packets from 206 one instance to the next, this solution requires that the instances 207 be themselves organized as a Directed Acyclic Graph, and enforce that 208 inter-DAG transfers occur only within that meta DAG. 210 5. Modified DODAG Information Object (DIO) 212 The DODAG Information Object [I-D.ietf-roll-rpl] carries information 213 that allows a node to discover a RPL instance, learn its 214 configuration parameters, select a DODAG parent set, and maintain the 215 DODAG. This specification defines a new flag bit to indicate that 216 the DAG is directional. 218 0 1 2 3 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | RPLInstanceID |Version Number | Rank | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 |G|D| MOP | Prf | DTSN | Flags | Reserved | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | | 226 + + 227 | | 228 + DODAGID + 229 | | 230 + + 231 | | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Option(s)... 234 +-+-+-+-+-+-+-+-+ 236 Figure 1: The DIO Base Object 238 Directional (D): The Directional (D) flag is set to indicate that 239 the instance is intended for directional operation, and is 240 reset otherwise. When the Directional (D) flag is set a value 241 of 0 for the MOP field indicates upwards whereas any other 242 value specified in [I-D.ietf-roll-rpl] indicates downwards. 243 All other values of MOP shall be considered downwards unless 244 explicitly specified otherwise. 246 6. Operations 248 This specification allows an organization of Instances as follows: 250 Instances MUST be organized as a Directed Acyclic Graph. This 251 information MUST be commissioned into the devices so they know 252 both which instances they should participate in, and which 253 direction of transfer is allowed between instances. 255 A spanning instance using OF0 [I-D.ietf-roll-of0] MAY be used as 256 root in that instance DAG. 258 This specification defines a new bit in the RPL [I-D.ietf-roll-rpl] 259 DODAG Information Object (DIO) with the Directional (D) flag that 260 indicates a directional operation for a given instance. An 261 implementation that does not support that new bit will not be able to 262 propagate it. 264 In case of a directional operation, 266 The direction is indicated by the MOP field, a MOP set to a value 267 0 means upwards and any other setting indicates downwards. 269 Links are still REQUIRED to allow bidirectional operations 271 Only the metrics that correspond to the DAG direction are used for 272 the parent selection. 274 An upward instance SHOULD install routes that lead to the root and 275 beyond - typically the default route. 277 A downwards instance MAY ONLY install more specific routes that 278 are injected by nodes in the DODAG through the DAO process. 280 P2P operations are achieved by associating a child upwards 281 instance with a parent downwards instance. 283 A packet MUST NOT be transferred from a parent instance to a child 284 instance. 286 A packet MAY be transferred from a child instance to its parent 287 instance if and only if the child instance does not provide a 288 route to the destination, or the parent instance provides a more 289 specific route (longer match) to the destination. 291 Transferring from an upwards instance to a downwards instance is 292 desirable for Point to Point communication within a RPL domain. 294 Other forms of transfer do not denote a classical operation of the 295 protocol and as a general guidance they SHOULD be avoided. It is 296 possible, though, that such transfer becomes useful in a 297 controlled environment, for instance in the case of a transfer 298 onto a last resort spanning instance. Policies MAY be put in 299 place to override the general guidance and allow such transfers. 301 7. Backwards Compatibility 303 An OF is generally designed to compute a Rank of a directional link 304 in a fashion that is different from a bidirectional link, and in 305 particular will not use the same metrics and thus obtain different 306 ranks for a same situation. For that reason, it is important that 307 the OF is aware that an instance is supposed to define a directional 308 DODAG, and it is RECOMMENDED that only devices that support 309 directional DODAGs are allowed in a directional instance. 311 It might happen that for some purposes like higher availability, an 312 implementation that does not support directional links is 313 administratively allowed to join a directional DODAG. In that case, 314 the extension of the DODAG that starts at that device will not be 315 directional, but the instance will still be functional. 317 In that case, it might also happen that a device that supports 318 directional DODAGs per this specification sees candidate neighbors 319 that expose the Directional flag and some others that do not. An OF 320 that supports directional links SHOULD favor directional links over 321 non directional links, in a fashion that is to be specified by the 322 OF. In the case of OF0 [I-D.ietf-roll-of0], the 'D' flag should be 323 accounted for before the computation of item 8 in the "Selection Of 324 The Preferred Parent" section 4.2.1, that is before ranks are 325 calculated and can be compared. 327 8. IANA Considerations 329 This specification requires that a bit in DIO shall be assigned to 330 indicate directional link operations as specified in Section 5 332 9. Security Considerations 334 Security considerations for this proposal are to be developed in 335 accordance with recommendations laid out in, for example, 336 [I-D.tsao-roll-security-framework]. 338 10. Acknowledgements 340 The author wishes to recognize Richard Kelsey, JP Vasseur, Tom 341 Phinney, Robert Assimiti, Don Sturek, Thomas Clausen and Yoav Ben- 342 Yehezkel for their various contributions. 344 11. References 346 11.1. Normative References 348 [I-D.ietf-roll-rpl] 349 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 350 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 351 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 352 Lossy Networks", draft-ietf-roll-rpl-19 (work in 353 progress), March 2011. 355 [I-D.ietf-roll-terminology] 356 Vasseur, J., "Terminology in Low power And Lossy 357 Networks", draft-ietf-roll-terminology-06 (work in 358 progress), September 2011. 360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", BCP 14, RFC 2119, March 1997. 363 11.2. Informative References 365 [I-D.ietf-roll-of0] 366 Thubert, P., "RPL Objective Function Zero", 367 draft-ietf-roll-of0-20 (work in progress), September 2011. 369 [I-D.tsao-roll-security-framework] 370 Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A 371 Security Framework for Routing over Low Power and Lossy 372 Networks", draft-tsao-roll-security-framework-02 (work in 373 progress), March 2010. 375 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 376 "Routing Requirements for Urban Low-Power and Lossy 377 Networks", RFC 5548, May 2009. 379 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 380 "Industrial Routing Requirements in Low-Power and Lossy 381 Networks", RFC 5673, October 2009. 383 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 384 Routing Requirements in Low-Power and Lossy Networks", 385 RFC 5826, April 2010. 387 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 388 "Building Automation Routing Requirements in Low-Power and 389 Lossy Networks", RFC 5867, June 2010. 391 Author's Address 393 Pascal Thubert (editor) 394 Cisco Systems 395 Village d'Entreprises Green Side 396 400, Avenue de Roumanille 397 Batiment T3 398 Biot - Sophia Antipolis 06410 399 FRANCE 401 Phone: +33 497 23 26 34 402 Email: pthubert@cisco.com