idnits 2.17.1 draft-ietf-roll-efficient-npdao-08.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 (September 30, 2018) is 2036 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-6tisch-architecture' is defined on line 615, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-14 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL R. Jadhav, Ed. 3 Internet-Draft Huawei 4 Intended status: Standards Track P. Thubert 5 Expires: April 3, 2019 Cisco 6 R. Sahoo 7 Z. Cao 8 Huawei 9 September 30, 2018 11 Efficient Route Invalidation 12 draft-ietf-roll-efficient-npdao-08 14 Abstract 16 This document describes the problems associated with NPDAO messaging 17 used in RPL for route invalidation and signaling changes to improve 18 route invalidation efficiency. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 3, 2019. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements Language and Terminology . . . . . . . . . . 3 56 1.2. Current NPDAO messaging . . . . . . . . . . . . . . . . . 4 57 1.3. Why NPDAO is important? . . . . . . . . . . . . . . . . . 5 58 2. Problems with current NPDAO messaging . . . . . . . . 6 59 2.1. Lost NPDAO due to link break to the previous parent . . . 6 60 2.2. Invalidate routes of dependent nodes . . . . . . . . . . 6 61 2.3. Possible route downtime caused by async operation of 62 NPDAO and DAO . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Requirements for the NPDAO Optimization . . . . . . . . . . . 6 64 3.1. Req#1: Remove messaging dependency on link to the 65 previous parent . . . . . . . . . . . . . . . 6 66 3.2. Req#2: Dependent nodes route invalidation on parent 67 switching . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.3. Req#3: Route invalidation should not impact data traffic 7 69 4. Proposed changes to RPL signaling . . . . . . . . . . . . . . 7 70 4.1. Change in RPL route invalidation semantics . . . . . . . 7 71 4.2. Transit Information Option changes . . . . . . . . . . . 7 72 4.3. Destination Cleanup Object (DCO) . . . . . . . . . . . . 8 73 4.3.1. Secure DCO . . . . . . . . . . . . . . . . . . . . . 10 74 4.3.2. DCO Options . . . . . . . . . . . . . . . . . . . . . 10 75 4.3.3. Path Sequence number in the DCO . . . . . . . . . . . 10 76 4.3.4. Destination Cleanup Option Acknowledgement (DCO-ACK) 10 77 4.3.5. Secure DCO-ACK . . . . . . . . . . . . . . . . . . . 11 78 4.4. Other considerations . . . . . . . . . . . . . . . . . . 12 79 4.4.1. Dependent Nodes invalidation . . . . . . . . . . . . 12 80 4.4.2. NPDAO and DCO in the same network . . . . . . . . . . 12 81 4.4.3. DCO with multiple preferred parents . . . . . . . . . 12 82 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 87 8.2. Informative References . . . . . . . . . . . . . . . . . 14 88 Appendix A. Example Messaging . . . . . . . . . . . . . . . . . 14 89 A.1. Example DCO Messaging . . . . . . . . . . . . . . . . . . 14 90 A.2. Example DCO Messaging with multiple preferred parents . . 15 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 RPL [RFC6550] (Routing Protocol for Low power and lossy networks) 96 specifies a proactive distance-vector based routing scheme. RPL has 97 an optional messaging in the form of DAO (Destination Advertisement 98 Object) messages using which the 6LBR (6Lo Border Router) and 6LR 99 (6Lo Router) can learn route towards the downstream nodes. In 100 storing mode, DAO messages would result in routing entries been 101 created on all intermediate 6LRs from the node's parent all the way 102 towards the 6LBR. 104 RPL allows use of No-Path DAO (NPDAO) messaging to invalidate a 105 routing path corresponding to the given target, thus releasing 106 resources utilized on that path. A NPDAO is a DAO message with route 107 lifetime of zero, originates at the target node and always flows 108 upstream towards the 6LBR. This document explains the problems 109 associated with the current use of NPDAO messaging and also discusses 110 the requirements for an optimized route invalidation messaging 111 scheme. Further a new pro-active route invalidation message called 112 as "Destination Cleanup Object (DCO)" is specified which fulfills 113 requirements of an optimized route invalidation messaging. 115 The document only caters to the RPL's storing mode of operation 116 (MOP). The non-storing MOP does not require use of NPDAO for route 117 invalidation since routing entries are not maintained on 6LRs. 119 1.1. Requirements Language and Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 6LR: 6LoWPAN Router. This is an intermediate 6lowpan router which 126 allows traffic routing through itself in a multihop 6lo network. 128 DAG: Directed Acyclic Graph. A directed graph having the property 129 that all edges are oriented in such a way that no cycles exist. 131 DODAG: Destination-oriented DAG. A DAG rooted at a single 132 destination, i.e., at a single DAG root with no outgoing edges. 134 6LBR: 6LoWPAN Border Router. A border router which is a DODAG root 135 and is the edge node for traffic flowing in and out of the 6lo 136 network. 138 DAO: Destination Advertisement Object. DAO messaging allows 139 downstream routes to the nodes to be established. 141 DIO: DODAG Information Object. DIO messaging allows upstream routes 142 to the 6LBR to be established. DIO messaging is initiated at the DAO 143 root. 145 Common Ancestor node: 6LR/6LBR node which is the first common node 146 between two paths of a target node. 148 NPDAO: No-Path DAO. A DAO message which has target with lifetime 0. 150 DCO: Destination Cleanup Object, A new RPL control message type 151 defined by this draft. DCO messaging improves proactive route 152 invalidation in RPL. 154 Regular DAO: A DAO message with non-zero lifetime. 156 LLN: Low Power and Lossy Networks. 158 Target Node: The node switching its parent whose routing adjacencies 159 are updated (created/removed). 161 This document also uses terminology described in [RFC6550]. 163 1.2. Current NPDAO messaging 165 RPL uses NPDAO messaging in the storing mode so that the node 166 changing it routing adjacencies can invalidate the previous route. 167 This is needed so that nodes along previous path can release any 168 resources (such as the routing entry) it maintains on behalf of 169 target node. 171 For the rest of this document consider the following topology: 173 (6LBR) 174 | 175 | 176 | 177 (A) 178 / \ 179 / \ 180 / \ 181 (G) (H) 182 | | 183 | | 184 | | 185 (B) (C) 186 \ ; 187 \ ; 188 \ ; 189 (D) 190 / \ 191 / \ 192 / \ 193 (E) (F) 195 Figure 1: Sample topology 197 Node (D) is connected via preferred parent (B). (D) has an alternate 198 path via (C) towards the 6LBR. Node (A) is the common ancestor for 199 (D) for paths through (B)-(G) and (C)-(H). When (D) switches from 200 (B) to (C), RPL allows sending NPDAO to (B) and regular DAO to (C). 202 1.3. Why NPDAO is important? 204 Nodes in LLNs may be resource constrained. There is limited memory 205 available and routing entry records are one of the primary elements 206 occupying dynamic memory in the nodes. Route invalidation helps 6LR 207 nodes to decide which entries could be discarded to better achieve 208 resource utilization. Thus it becomes necessary to have efficient 209 route invalidation mechanism. Also note that a single parent switch 210 may result in a "sub-tree" switching from one parent to another. 211 Thus the route invalidation needs to be done on behalf of the sub- 212 tree and not the switching node alone. In the above example, when 213 Node (D) switches parent, the route updates needs to be done for the 214 routing tables entries of (C),(H),(A),(G), and (B) with destination 215 (D),(E) and (F). Without efficient route invalidation, a 6LR may 216 have to hold a lot of stale route entries. 218 2. Problems with current NPDAO messaging 220 2.1. Lost NPDAO due to link break to the previous parent 222 When a node switches its parent, the NPDAO is to be sent to its 223 previous parent and a regular DAO to its new parent. In cases where 224 the node switches its parent because of transient or permanent parent 225 link/node failure then the NPDAO message is bound to fail. 227 2.2. Invalidate routes of dependent nodes 229 RPL does not specify how route invalidation will work for dependent 230 nodes rooted at switching node, resulting in stale routing entries of 231 the dependent nodes. The only way for 6LR to invalidate the route 232 entries for dependent nodes would be to use route lifetime expiry 233 which could be substantially high for LLNs. 235 In the example topology, when Node (D) switches its parent, Node (D) 236 generates an NPDAO on its behalf. There is no NPDAO generated by the 237 dependent child nodes (E) and (F), through the previous path via (D) 238 to (B) and (G), resulting in stale entries on nodes (B) and (G) for 239 nodes (E) and (F). 241 2.3. Possible route downtime caused by async operation of NPDAO and DAO 243 A switching node may generate both an NPDAO and DAO via two different 244 paths at almost the same time. There is a possibility that an NPDAO 245 generated may invalidate the previous route and the regular DAO sent 246 via the new path gets lost on the way. This may result in route 247 downtime impacting downward traffic for the switching node. 249 In the example topology, consider Node (D) switches from parent (B) 250 to (C). An NPDAO sent via previous route may invalidate the previous 251 route whereas there is no way to determine whether the new DAO has 252 successfully updated the route entries on the new path. 254 3. Requirements for the NPDAO Optimization 256 3.1. Req#1: Remove messaging dependency on link to the previous parent 258 When the switching node sends the NPDAO message to the previous 259 parent, it is normal that the link to the previous parent is prone to 260 failure (thats why the node decided to switch). Therefore, it is 261 required that the route invalidation does not depend on the previous 262 link which is prone to failure. The previous link referred here 263 represents the link between the node and its previous parent (from 264 whom the node is now disassociating). 266 3.2. Req#2: Dependent nodes route invalidation on parent switching 268 It should be possible to do route invalidation for dependent nodes 269 rooted at the switching node. 271 3.3. Req#3: Route invalidation should not impact data traffic 273 While sending the NPDAO and DAO messages, it is possible that the 274 NPDAO successfully invalidates the previous path, while the newly 275 sent DAO gets lost (new path not set up successfully). This will 276 result in downstream unreachability to the node switching paths. 277 Therefore, it is desirable that the route invalidation is 278 synchronized with the DAO to avoid the risk of route downtime. 280 4. Proposed changes to RPL signaling 282 4.1. Change in RPL route invalidation semantics 284 As described in Section 1.2, the NPDAO originates at the node 285 switching the parent and traverses upstream towards the root. In 286 order to solve the problems as mentioned in Section 2, the draft adds 287 new pro-active route invalidation message called as "Destination 288 Cleanup Object" (DCO) that originates at a common ancestor node 289 between the new and old path. The common ancestor node generates a 290 DCO in response to the change in the next-hop on receiving a regular 291 DAO with updated path sequence for the target. 293 In Figure 1, when node D decides to switch the path from B to C, it 294 sends a regular DAO to node C with reachability information 295 containing target as address of D and a incremented path sequence 296 number. Node C will update the routing table based on the 297 reachability information in DAO and in turn generate another DAO with 298 the same reachability information and forward it to H. Node H also 299 follows the same procedure as Node C and forwards it to node A. When 300 node A receives the regular DAO, it finds that it already has a 301 routing table entry on behalf of the target address of node D. It 302 finds however that the next hop information for reaching node D has 303 changed i.e. the node D has decided to change the paths. In this 304 case, Node A which is the common ancestor node for node D along the 305 two paths (previous and new), should generate a DCO which traverses 306 downwards in the network. 308 4.2. Transit Information Option changes 310 Every RPL message is divided into base message fields and additional 311 Options. The base fields apply to the message as a whole and options 312 are appended to add message/use-case specific attributes. As an 313 example, a DAO message may be attributed by one or more "RPL Target" 314 options which specify the reachability information for the given 315 targets. Similarly, a Transit Information option may be associated 316 with a set of RPL Target options. 318 The draft proposes a change in Transit Information option to contain 319 "Invalidate previous route" (I) bit. This I-bit signals the common 320 ancestor node to generate a DCO on behalf of the target node. The 321 I-bit is carried in the transit information option which augments the 322 reachability information for a given set of RPL Target(s). Transit 323 information option should be carried in the DAO message with I-bit 324 set in case route invalidation is sought for the correspondig 325 target(s). 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Type = 0x06 | Option Length |E|I| Flags | Path Control | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Path Sequence | Path Lifetime | | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 334 | | 335 + + 336 | | 337 + Parent Address* + 338 | | 339 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Figure 2: Updated Transit Information Option (New I flag added) 345 I (Invalidate previous route) bit: 1 bit flag. The 'I' flag is set 346 by the target node to indicate that it wishes to invalidate the 347 previous route by a common ancestor node between the two paths. 349 The common ancestor node SHOULD generate a DCO message in response to 350 this I-bit when it sees that the routing adjacencies have changed for 351 the target. I-bit governs the ownership of the DCO message in a way 352 that the target node is still in control of its own route 353 invalidation. 355 4.3. Destination Cleanup Object (DCO) 357 A new ICMPv6 RPL control message type is defined by this 358 specification called as "Destination Cleanup Object" (DCO), which is 359 used for proactive cleanup of state and routing information held on 360 behalf of the target node by 6LRs. The DCO message always traverses 361 downstream and cleans up route information and other state 362 information associated with the given target. 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | RPLInstanceID |K|D| Flags | Reserved | DCOSequence | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | | 370 + + 371 | | 372 + DODAGID(optional) + 373 | | 374 + + 375 | | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Option(s)... 378 +-+-+-+-+-+-+-+-+ 380 Figure 3: DCO base object 382 RPLInstanceID: 8-bit field indicating the topology instance 383 associated with the DODAG, as learned from the DIO. 385 K: The 'K' flag indicates that the recipient is expected to send a 386 DCO-ACK back. If the DCO-ACK is not received even after setting the 387 'K', an implementation may choose to retry the DCO at a later time. 388 The number of retries are implementation and deployment dependent. 389 This document recommends using retries similar to what will be set 390 for DAO-ACK handling. 392 D: The 'D' flag indicates that the DODAGID field is present. This 393 flag MUST be set when a local RPLInstanceID is used. 395 Flags: The 6 bits remaining unused in the Flags field are reserved 396 for future use. These bits MUST be initialized to zero by the sender 397 and MUST be ignored by the receiver. 399 Reserved: 8-bit unused field. The field MUST be initialized to zero 400 by the sender and MUST be ignored by the receiver. 402 DCOSequence: Incremented at each unique DCO message from a node and 403 echoed in the DCO-ACK message. The initial DCOSequence can be chosen 404 randomly by the node. 406 DODAGID (optional): 128-bit unsigned integer set by a DODAG root that 407 uniquely identifies a DODAG. This field is only present when the 'D' 408 flag is set. This field is typically only present when a local 409 RPLInstanceID is in use, in order to identify the DODAGID that is 410 associated with the RPLInstanceID. When a global RPLInstanceID is in 411 use, this field need not be present. Unassigned bits of the DCO Base 412 are reserved. They MUST be set to zero on transmission and MUST be 413 ignored on reception. 415 4.3.1. Secure DCO 417 A Secure DCO message follows the format in [RFC6550] figure 7, where 418 the base message format is the DCO message shown in Figure 3. 420 4.3.2. DCO Options 422 The DCO message MAY carry valid options. This specification allows 423 for the DCO message to carry the following options: 425 0x00 Pad1 426 0x01 PadN 427 0x05 RPL Target 428 0x06 Transit Information 429 0x09 RPL Target Descriptor 431 The DCO carries a Target option and an associated Transit Information 432 option with a lifetime of 0x00000000 to indicate a loss of 433 reachability to that Target. 435 4.3.3. Path Sequence number in the DCO 437 A DCO message may contain a Path Sequence in the transit information 438 option to identify the freshness of the DCO message. The Path 439 Sequence in the DCO MUST use the same Path Sequence number present in 440 the regular DAO message when the DCO is generated in response to DAO 441 message. The DAO and DCO path sequence are picked from the same 442 sequence number set. Thus if a DCO is received by a 6LR and 443 subsequently a DAO is received with old seqeunce number, then the DAO 444 should be ignored. 446 4.3.4. Destination Cleanup Option Acknowledgement (DCO-ACK) 448 The DCO-ACK message may be sent as a unicast packet by a DCO 449 recipient in response to a unicast DCO message. 451 0 1 2 3 452 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 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | RPLInstanceID |D| Reserved | DCOSequence | Status | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | | 457 + + 458 | | 459 + DODAGID(optional) + 460 | | 461 + + 462 | | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 Figure 4: DCO-ACK base object 467 RPLInstanceID: 8-bit field indicating the topology instance 468 associated with the DODAG, as learned from the DIO. 470 D: The 'D' flag indicates that the DODAGID field is present. This 471 flag MUST be set when a local RPLInstanceID is used. 473 Reserved: 7-bit unused field. The field MUST be initialized to zero 474 by the sender and MUST be ignored by the receiver. 476 DCOSequence: The DCOSequence in DCO-ACK is copied from the 477 DCOSequence received in the DCO message. 479 Status: Indicates the completion. Status 0 is defined as unqualified 480 acceptance in this specification. The remaining status values are 481 reserved as rejection codes. 483 DODAGID (optional): 128-bit unsigned integer set by a DODAG root that 484 uniquely identifies a DODAG. This field is only present when the 'D' 485 flag is set. This field is typically only present when a local 486 RPLInstanceID is in use, in order to identify the DODAGID that is 487 associated with the RPLInstanceID. When a global RPLInstanceID is in 488 use, this field need not be present. Unassigned bits of the DCO-Ack 489 Base are reserved. They MUST be set to zero on transmission and MUST 490 be ignored on reception. 492 4.3.5. Secure DCO-ACK 494 A Secure DCO-ACK message follows the format in [RFC6550] figure 7, 495 where the base message format is the DCO-ACK message shown in 496 Figure 4. 498 4.4. Other considerations 500 4.4.1. Dependent Nodes invalidation 502 Current RPL [RFC6550] does not provide a mechanism for route 503 invalidation for dependent nodes. This document allows the dependent 504 nodes invalidation. Dependent nodes will generate their respective 505 DAOs to update their paths, and the previous route invalidation for 506 those nodes should work in the similar manner described for switching 507 node. The dependent node may set the I-bit in the transit 508 information option as part of regular DAO so as to request 509 invalidation of previous route from the common ancestor node. 511 4.4.2. NPDAO and DCO in the same network 513 Even with the changed semantics, the current NPDAO mechanism in 514 [RFC6550] can still be used, for example, when the route lifetime 515 expiry of the target happens or when the node simply decides to 516 gracefully terminate the RPL session on graceful node shutdown. 517 Moreover a deployment can have a mix of nodes supporting the proposed 518 DCO and the existing NPDAO mechanism. 520 4.4.3. DCO with multiple preferred parents 522 [RFC6550] allows a node to select multiple preferred parents for 523 route establishment. Section 9.2.1 of [RFC6550] specifies, "All DAOs 524 generated at the same time for the same Target MUST be sent with the 525 same Path Sequence in the Transit Information". Thus a DAO message 526 with the same path sequence MUST be sent to all the parents. 527 Subsequently when route invalidation has to be initiated, RPL 528 mentions that an NPDAO must be initiated with updated path sequence 529 to all the routes to be invalidated. 531 With DCO, the Target node itself does not initiate the route 532 invalidation and it is left to the common ancestor node. A common 533 ancestor node when it discovers an updated DAO from a new next-hop, 534 it initiates a DCO. With multiple preferred parents, this handling 535 does not change. But in this case it is recommended that an 536 implementation initiates a DCO after a time period such that the 537 common ancestor node may receive updated DAOs from all possible next- 538 hops. This will help to reduce DCO control overhead i.e., the common 539 ancestor can wait for updated DAOs from all possible directions 540 before initiating a DCO for route invalidation. The time period for 541 initiating a DCO could be based on the depth of the network. After 542 timeout, the DCO needs to be generated for all the next-hops for whom 543 the route invalidation needs to be done. 545 5. Acknowledgements 547 Many thanks to Cenk Gundogan, Simon Duquennoy, Georgios 548 Papadopoulous, Peter Van Der Stok for their review and comments. 550 6. IANA Considerations 552 IANA is requested to allocate new ICMPv6 RPL control codes in RPL 553 [RFC6550] for DCO and DCO-ACK messages. 555 +------+---------------------------------------------+--------------+ 556 | Code | Description | Reference | 557 +------+---------------------------------------------+--------------+ 558 | 0x04 | Destination Cleanup Object | This | 559 | | | document | 560 | 0x05 | Destination Cleanup Object Acknowledgement | This | 561 | | | document | 562 | 0x84 | Secure Destination Cleanup Object | This | 563 | | | document | 564 | 0x85 | Secure Destination Cleanup Object | This | 565 | | Acknowledgement | document | 566 +------+---------------------------------------------+--------------+ 568 IANA is requested to allocate bit 18 in the Transit Information 569 Option defined in RPL [RFC6550] section 6.7.8 for Invalidate route 570 'I' flag. 572 7. Security Considerations 574 All RPL messages support a secure version of messages which allows 575 integrity protection using either a MAC or a signature. Optionally, 576 secured RPL messages also have encryption protection for 577 confidentiality. 579 The document adds new messages (DCO, DCO-ACK) which are syntactically 580 similar to existing RPL messages such as DAO, DAO-ACK. Secure 581 versions of DCO and DCO-ACK are added similar to other RPL messages 582 (such as DAO, DAO-ACK). 584 RPL supports three security modes as mentioned in Section 10.1 of 585 [RFC6550]: 587 1. Unsecured: In this mode, it is expected that the RPL control 588 messages are secured by other security mechanisms, such as link- 589 layer security. In this mode, the RPL control messages, 590 including DCO, DCO-ACK, do not have Security sections. 591 2. Preinstalled: In this mode, RPL uses secure messages. Thus 592 secure versions of DCO, DCO-ACK MUST be used in this mode. 594 3. Authenticated: In this mode, RPL uses secure messages. Thus 595 secure versions of DCO, DCO-ACK MUST be used in this mode. 597 8. References 599 8.1. Normative References 601 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 602 Requirement Levels", BCP 14, RFC 2119, 603 DOI 10.17487/RFC2119, March 1997, 604 . 606 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 607 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 608 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 609 Low-Power and Lossy Networks", RFC 6550, 610 DOI 10.17487/RFC6550, March 2012, 611 . 613 8.2. Informative References 615 [I-D.ietf-6tisch-architecture] 616 Thubert, P., "An Architecture for IPv6 over the TSCH mode 617 of IEEE 802.15.4", draft-ietf-6tisch-architecture-14 (work 618 in progress), April 2018. 620 Appendix A. Example Messaging 622 A.1. Example DCO Messaging 624 In Figure 1, node (D) switches its parent from (B) to (C). The 625 sequence of actions is as follows: 627 1. Node D switches its parent from node B to node C 628 2. D sends a regular DAO(tgt=D,pathseq=x+1,I_flag=1) in the updated 629 path to C 630 3. C checks for routing entry on behalf of D, since it cannot find 631 an entry on behalf of D it creates a new routing entry and 632 forwards the reachability information of the target D to H in a 633 DAO. 634 4. Similar to C, node H checks for routing entry on behalf of D, 635 cannot find an entry and hence creates a new routing entry and 636 forwards the reachability information of the target D to H in a 637 DAO. 638 5. Node A receives the DAO, and checks for routing entry on behalf 639 of D. It finds a routing entry but checks that the next hop for 640 target D is now changed. Node A checks the I_flag and generates 641 DCO(tgt=D,pathseq=pathseq(DAO)) to previous next hop for target D 642 which is G. Subsequently, A updates the routing entry and 643 forwards the reachability information of target D upstream 644 DAO(tgt=D,pathseq=x+1,I_flag=x) (the I_flag carries no 645 significance henceforth). 646 6. Node G receives the DCO and invalidates routing entry of target D 647 and forwards the (un)reachability information downstream to B. 648 7. Similarly, B processes the DCO by invalidating the routing entry 649 of target D and forwards the (un)reachability information 650 downstream to D. 651 8. D ignores the DCO since the target is itself. 652 9. The propagation of the DCO will stop at any node where the node 653 does not have an routing information associated with the target. 654 If the routing information is present and the pathseq associated 655 is not older, then still the DCO is dropped. 657 A.2. Example DCO Messaging with multiple preferred parents 659 (6LBR) 660 | 661 | 662 | 663 (N11) 664 / \ 665 / \ 666 / \ 667 (N21) (N22) 668 / / \ 669 / / \ 670 / / \ 671 (N31) (N32) (N33) 672 : | / 673 : | / 674 : | / 675 (N41) 677 Figure 5: Sample topology 2 679 In Figure 5, node (N41) selects multiple preferred parents (N32) and 680 (N33). The sequence of actions is as follows: 682 1. (N41) sends DAO(tgt=N41,PS=x,I_flag=1) to (N32) and (N33). Here 683 I_flag refers to the Invalidation flag and PS refers to Path 684 Sequence in Transit Information option. 685 2. (N32) sends DAO(tgt=N41,PS=x,I_flag=1) to (N22). (N33) also 686 sends DAO(tgt=N41,PS=x,I_flag=1) to (N22). (N22) learns multiple 687 routes for the same destination (N41) through multiple next-hops. 688 The route table at N22 should contain (Dst,NextHop,PS): { 689 (N41,N32,x), (N41,N33,x) }. 691 3. (N22) sends DAO(tgt=N41,PS=x,I_flag=1) to (N11). 692 4. (N11) sends DAO(tgt=N41,PS=x,I_flag=1) to (6LBR). Thus the 693 complete path is established. 694 5. (N41) decides to change preferred parent set from { N32, N33 } to 695 { N31, N32 }. 696 6. (N41) sends DAO(tgt=N41,PS=x+1,I_flag=1) to (N32). (N41) sends 697 DAO(tgt=N41,PS=x+1,I_flag=1) to (N31). 698 7. (N32) sends DAO(tgt=N41,PS=x+1,I_flag=1) to (N22). (N22) has 699 multiple routes to destination (N41). It sees that a new path 700 sequence for Target=N41 is received and thus it waits for pre- 701 determined time period to invalidate another route 702 {(N41),(N33),x}. After time period, (N22) sends 703 DCO(tgt=N41,PS=x+1) to (N33). 705 Authors' Addresses 707 Rahul Arvind Jadhav (editor) 708 Huawei 709 Kundalahalli Village, Whitefield, 710 Bangalore, Karnataka 560037 711 India 713 Phone: +91-080-49160700 714 Email: rahul.ietf@gmail.com 716 Pascal Thubert 717 Cisco Systems, Inc 718 Building D 719 45 Allee des Ormes - BP1200 720 MOUGINS - Sophia Antipolis 06254 721 France 723 Phone: +33 497 23 26 34 724 Email: pthubert@cisco.com 726 Rabi Narayan Sahoo 727 Huawei 728 Kundalahalli Village, Whitefield, 729 Bangalore, Karnataka 560037 730 India 732 Phone: +91-080-49160700 733 Email: rabinarayans@huawei.com 734 Zhen Cao 735 Huawei 736 W Chang'an Ave 737 Beijing 738 China 740 Email: zhencao.ietf@gmail.com