idnits 2.17.00 (12 Aug 2021) /tmp/idnits65437/draft-thubert-roll-eliding-dio-information-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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6550, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (27 March 2020) is 778 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) ** Downref: Normative reference to an Informational RFC: RFC 7228 ** Downref: Normative reference to an Informational RFC: RFC 7102 == Outdated reference: A later version (-09) exists of draft-ietf-roll-capabilities-02 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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 Updates: 6550 (if approved) R.A. Jadhav 5 Intended status: Standards Track Huawei Tech 6 Expires: 28 September 2020 L. Zhao 7 Cisco Systems 8 D. Barthel 9 Orange Labs 10 27 March 2020 12 Eliding and Querying RPL Information 13 draft-thubert-roll-eliding-dio-information-04 15 Abstract 17 This document presents a method to safely elide a group of RPL 18 options in a DIO message by synchronizing the state associated with 19 each of these options between parent and child using a new sequence 20 counter in DIO messages. A child that missed a DIO message with an 21 update of any of those protected options detects it by the change of 22 sequence counter and queries the update with a DIS Message. The 23 draft also provides a method to fully elide the options in a DAO 24 message. 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 https://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 28 September 2020. 43 Copyright Notice 45 Copyright (c) 2020 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 (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1. Updated DIO Base Object . . . . . . . . . . . . . . . . . 6 67 4.2. Updated DIS Base Object . . . . . . . . . . . . . . . . . 6 68 4.3. Updated DAO Base Object . . . . . . . . . . . . . . . . . 7 69 4.4. New Abbreviated Option Option . . . . . . . . . . . . . . 8 70 5. RCSS Operation . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.1. Updating the RCSS . . . . . . . . . . . . . . . . . . . . 9 72 5.2. RCSS Freshness and Parent selection . . . . . . . . . . . 10 73 5.3. RCSS of an Option . . . . . . . . . . . . . . . . . . . . 10 74 6. Synchronizing Options . . . . . . . . . . . . . . . . . . . . 12 75 7. Abbreviating the DAO Message . . . . . . . . . . . . . . . . 12 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 9.1. New DODAG Information Solicitation Flags . . . . . . . . 14 79 9.2. New DODAG Advertisement Object Flag . . . . . . . . . . . 14 80 9.3. New RPL Control Message Option . . . . . . . . . . . . . 14 81 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 82 11. Normative References . . . . . . . . . . . . . . . . . . . . 15 83 12. Informative References . . . . . . . . . . . . . . . . . . . 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 86 1. Introduction 88 Classical Link State protocols synchronize their Link State Database 89 (LSDB) by sequencing every change. Each interested node maintains 90 the last sequence of the LSDB it is synchronizing with. If the last 91 known sequence number is older than the current, the node needs to 92 learn one by one all the state changes between the last known and the 93 current state. 95 "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" (LLNs) 96 [RPL] does not operate that way. With RPL, the routing information 97 is repeated over and over in DODAG Information Object (DIO) and 98 Destination Advertisement Object (DAO) messages. There is no concept 99 of synchronization. Still there is a concept of sequence to ensure 100 that the most recent information is recognized and overrides a 101 previous one. A stale state may exist in dead branches of the 102 network and eventually time out. 104 The RPL way was designed to enable routing from most nodes to most 105 nodes most of the time in a Low-Power Lossy Network (LLN) where the 106 quality of the links and the cost of communications does not permit 107 to maintain a permanent synchronization. This principle was applied 108 to both the routing and non-routing information such as configuration 109 settings, prefix information, and node capabilities. 111 This non-routing state is carried in RPL Messages as options. Some 112 of the DIO options may be needed to decide whether a node can join a 113 network as a leaf or as a router, and may affect the parent selection 114 or the address selection. It is thus critical that each node 115 maintains its state to the freshest and selects parents that are also 116 synchronized to the freshest. 118 [RPL] allows a parent to elide options in the DIO messages that it 119 sends repeatedly, to conserve battery and save bandwidth. When it 120 does so, a newcomer child that missed DIOs that contained the 121 configuration option may operate on default or partial information. 122 If it is pessimistic, it may query all possible information even when 123 it is not needed. Likewise, a node that slept may have missed a DIO 124 with a change in some critical information and may not be even aware 125 of it, so it may fail to query for the update and operate on 126 deprecated parameters. 128 This document uses a new sequence counter called the RPL 129 Configuration State Sequence (RCSS) to synchronize the state in a 130 child node with that of its parent, and recursively with that of the 131 whole network, to the latest setting from the Root. 133 The protected options are: 135 * The Route Information Option (RIO) defined in section 6.7.5 of 136 [RPL] 137 * The DODAG Configuration Option (DCO) defined in section 6.7.6 of 138 [RPL] 139 * The Prefix Information Option (PIO) defined in section 6.7.10 of 140 [RPL] 141 * The Extended MOP Option (MOPex) defined in [MOPEX] 142 * The Capability Option and TLVs defined in [CAPABILITIES] 143 Any change in those options causes an increment of the RCSS and 144 enables a network-wide synchronization to the new state. If the 145 change impacts the routing substantially, the Root should decide to 146 increment the Version Number at the same time to fully rebuild the 147 DODAG with the new settings of the options. It must be noted that 148 rebuilding the DODAG does not guarantee that the non-routing state is 149 fully synchronized unless all the options were present in all the DIO 150 messages since the new Version is used. 152 2. Terminology 154 2.1. BCP 14 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 158 "OPTIONAL" in this document are to be interpreted as described in BCP 159 14 [RFC2119][RFC8174] when, and only when, they appear in all 160 capitals, as shown here. 162 2.2. References 164 The Terminology used in this document is consistent with and 165 incorporates that described in Terms Used in Routing for Low-Power 166 and Lossy Networks [RFC7102]. 168 Other terms in use in LLNs are found in Terminology for 169 Constrained-Node Networks [RFC7228]. 171 A glossary of classical RPL acronyms is given in Section 2.3. 173 The term "byte" is used in its now customary sense as a synonym for 174 "octet". 176 "RPL", "RPL Packet Information" (RPI) and "RPL Instance", DIO, DAO 177 and DIS messages are defined in the "RPL: IPv6 Routing Protocol for 178 Low-Power and Lossy Networks" [RPL] specification. 180 This document uses the terms RPL Leaf, RPL Aware Leaf (RAL), RPL- 181 Aware Node (RAN) and RPL-Unaware Leaf (RUL) as defined in section 2 182 of [USE_OF_RPL_INFO]. 184 A RPL-Unaware Leaf (RUL) thus refers to a host that does not 185 understand RPL but uses a RPL router (without necessarily knowing it) 186 as default gateway and depends on that router to obtain reachability 187 for its addresses inside the RPL domain. Conversely, the term RPL- 188 Aware Node (RAN) is used to refer to a node that participates to RPL 189 and advertises its addresses or prefixes by itself. 191 2.3. Glossary 193 This document often uses the following acronyms: 195 DODAG: Destination-Oriented Directed Acyclic Graph 197 LLN: Low-Power and Lossy Network 199 RPI: RPL Packet Information (an Option in the Hop-By_Hop Header) 201 RAL: RPL-Aware Leaf 203 RAN: RPL-Aware Node 205 RS: Router Solicitation 207 RCSS: RPL Configuration State Sequence 209 RPL: IPv6 Routing Protocol for LLNs (pronounced ripple) 211 RUL: RPL-Unaware Leaf 213 3. Updating RFC 6550 215 This document adds a new field called RCSS to the DIO message. The 216 RCSS is a sequence counter that is set by the Root and incremented as 217 specified in Section 7 of [RPL], more in Section 5. 219 This document also introduces a new RPL Control Message Option called 220 the Abbreviated Option Option (AOO). The AOO is the compressed 221 replacement of a protected option that indicates the RCSS of the last 222 change of that option, but elides its content, more in Section 4.4. 224 This document modifies the DIS Base Object to enable the individual 225 query of the protected options by a node that missed a change, more 226 in Section 4.2. 228 This document also enables to abbreviate a full DAO message when all 229 the options are unchanged from the most recent DAO message that was 230 positively acknowledged. In that case the DAO is resent with the 231 same DAOSequence and all the options are elided. A new flag in the 232 DAO Base Object indicates that this is an abbreviated DAO message, 233 more in Section 7. 235 The abbreviated DAO renews the lifetime of a DAO state but does not 236 change any information therein. 238 4. Message Formats 240 4.1. Updated DIO Base Object 242 The format of the DIO Base Object is defined in section 6.3.1 of 243 [RPL]. This specification uses the 8th octet, which was reserved in 244 [RPL], to transport the RCSS. 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | RPLInstanceID |Version Number | Rank | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 |G|0| MOP | Prf | DTSN | Flags | RCSS | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | | 254 + + 255 | | 256 + DODAGID + 257 | | 258 + + 259 | | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Option(s)... 262 +-+-+-+-+-+-+-+-+ 264 Figure 1: Updated DIO Base Object 266 Updated fields: 268 RCSS: 269 One Byte, the RPL Configuration State Sequence 271 4.2. Updated DIS Base Object 273 The DIS Base Object is use by a child to query from a parent the most 274 recent changes in protected options. This specification adds flags 275 to indicate which options are requested and the freshest RCSS to 276 which the querying node was synchronized. 278 0 1 2 279 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 |R|D|P[M|O| Flg | LastSync RCSS | Option(s)... 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 Figure 2: Updated DIS Base Object 286 Updated fields: 288 R: 289 One Bit, indicates that the RIO is requested 291 D: 292 One Bit, indicates that the DCO is requested 294 P: 295 One Bit, indicates that the PIO(s) is(are) requested 297 M: 298 One Bit, indicates that the MOPex is requested 300 O: 301 One Bit, indicates that the GCO is requested 303 Last Synchronized RCSS: 304 One Byte, the freshest RCSS to which the sender was synchronized 306 4.3. Updated DAO Base Object 308 The format of the DAO Base Object is defined in section 6.4.1 of 309 [RPL]. This specification adds the 'A' flag to indicate that the DAO 310 options are elided. 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | RPLInstanceID |K|D|A| Flags | Reserved | DAOSequence | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | | 318 + + 319 | | 320 + DODAGID* + 321 | | 322 + + 323 | | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Option(s)... 326 +-+-+-+-+-+-+-+-+ 328 Figure 3: Updated DAO Base Object 330 Updated fields: 332 A: 333 One Bit, indicates DAO in abbreviated version 335 4.4. New Abbreviated Option Option 337 The Abbreviated Option Option (AOO) is a generic replacement for an 338 option that only indicates the sender's value of the RCSS for that 339 option. The format of the AOO is represented in Figure 4: 341 0 1 2 3 342 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 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Option Type | Option Length | Abbrev. opt. | Last Mod RCSS | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 Figure 4: Abbreviated Option Option Format 349 Option fields: 351 Option Type: 352 One byte indicating "Abbreviated Option", see Table 3 in 353 Section 9.3 355 Option Length: 356 MUST be set to 2 indicating Option data of 2 bytes 358 Abbreviated Option: 359 The Option Type of the option being abbreviated 361 Last Modification RCSS: 362 The RCSS at which the option was last modified 364 5. RCSS Operation 366 Settings and updates to network-wide parameters are initiated by the 367 Root and propagated down the DODAG in RPL Control Message Options in 368 DIO messages. The DIO messages arrive asynchronously via different 369 parents and may confuse a child when they are not ordered. 371 The RCSS is a sequence number that is operated as specified in 372 section 7.2 of [RPL]. The RCSS sequences the atomic state that is 373 transported in the protected options in one or a burst of DIO 374 Messages. The same value of the RCSS is used in the initial burst 375 and in the subsequent DIO messages that are sent with no change in 376 the protected options. 378 The Root of the DODAG is autoritative to set and update the RCSS and 379 the options that it protects. The scope of an RCSS is one DODAG 380 within one RPL Instance. 382 The RCSS and the sequenced state in the protected options are 383 propagated together down the DODAG without a change, more in 384 Section 5.1. 386 The RCSS allows a child to remain synchronized to a most recent 387 settings of the network-wide parameters that are propagated in the 388 protected options. The child recognizes stale DIO message(s) and 389 only uses parents with a consistent state, more in Section 5.2. 391 By extension, the RCSS is also defined for each protected option. A 392 child associates an option with the values of the RCSS indicated in 393 DIO Messages in which the option was advertised and uses it to assess 394 the relative freshness of different versions of an option, more in 395 Section 5.3. 397 Unchanged options may be sent in full, elided, or in the abbreviated 398 form specified in Section 4.4. Which form to use depends on the 399 RCSS, more in Section 5.3 401 If the link MTU does not permit to send a single DIO message with all 402 the options packaged then the options may be spread over multiple 403 consecutive DIO messages with the same RCSS that are sent in a rapid 404 sequence. 406 5.1. Updating the RCSS 408 The RCSS is incremented by the Root using a lollipop technique as 409 specified in section 7.2 of [RPL]. RCSS values are comparable if 410 they are within a window of comparison of SEQUENCE_WINDOW increments 411 or one indicates a reboot. A reboot of the Root is detected when the 412 RCSS moves from the circular to the straight part of the lollipop. 414 During the straight part of the lollipop, a second reboot of the Root 415 might not be recognized and a same value of the RCSS may reappear 416 with different settings in the protected options. For that reason 417 the protected options MUST be provided in full with each increment on 418 the RCSS during the straight part of the lollipop. 420 The straight part should be kept short with a RECOMMENDED initial 421 value of 252 or above. The Root SHOULD jump rapidly away from the 422 straight part once the network has sufficiently settled by resetting 423 the RCSS to 0, which places the RCSS in the circular region of the 424 lollipop, where the protected options MAY be elided or abbreviated. 426 When a field is modified in one of the protected options, the Root 427 MUST send a DIO with the RCSS incremented and the modified protected 428 option(s) in full. The Root MAY also update the Version Number to 429 form a new DODAG altogether. 431 5.2. RCSS Freshness and Parent selection 433 A child node maintains the freshest RCSS received from its parents in 434 each of the RPL Instances that it participates to, and uses that RCSS 435 for its own DIO messages once it has synchronized all the protected 436 options to that RCSS. 438 A child and a candidate parent are out-of-sync when the RCSS values 439 that they maintain for a RPL Instance are not comparable. A child 440 MUST NOT use a parent that is out-of-sync unless no other parent is 441 available, in which case it MAY align its RCSS and synchronize to 442 that parent. 444 When a child receives from a candidate parent a DIO with an RCSS that 445 is fresher than the one it is using, the child MUST synchronize the 446 state relative to the protected options with that parent. The child 447 node MUST refrain from using that parent and the new state including 448 the RCSS, until it has synchronized all of the protected options to 449 that RCSS. When it is fully synchronized, the child may then use 450 that parent and the new RCSS. 452 Using a back-level parent may cause packets to be dropped, 453 misunderstood or misrouted. The child SHOULD refrain from using a 454 parent that exposes an older RCSS if the change causes an 455 incompatibility issue. 457 5.3. RCSS of an Option 459 By extension, the RCSS of an option is maintained by all nodes and is 460 defined for all but the Root as the freshest RCSS indicated by a DIO 461 message from a candidate parent in which the option was present, in 462 the abbreviated form or in full. A child maintains a state for the 463 RCSS of each of the protected options and synchronizes its state for 464 the options by comparing that RCSS with the one found in new DIO 465 messages for the option. 467 Protected options may be sent in full, elided, or in the abbreviated 468 form. Which form to use depends on the RCSS of the option that a 469 parent maintains: 471 * A parent MAY use either form when the RCSS is not changed from a 472 previous DIO; eliding options is PREFERRED in stable conditions to 473 save resources. 475 * When a protected option is updated, the RCSS is mechanically 476 incremented, and the new option MUST be sent in full on the first 477 DIO that advertises that new RCSS and the corresponding AOO SHOULD 478 NOT be added. 480 * When the RCSS is updated but a protected option is unchanged, the 481 parent SHOULD NOT fully elide the option as it may cause multiple 482 children to synchronize it to no avail. The use of AOO is 483 RECOMMENDED unless it may cause a desynchronization for that 484 option, in which case the option SHOULD be placed in full, more in 485 Section 5.3. 487 When a child receives a DIO from a candidate parent, for each option: 489 If the Option is advertised in the abbreviated form, then the RCSS 490 that the DIO advertises for the option is the Last Modification 491 RCSS of the AOO, else 493 If the Option is advertised in full, then the RCSS that the DIO 494 advertises for the option is the RCSS of the DIO, else 496 If the Option is elided, then the RCSS is unspecified but it is at 497 most as fresh as the RCSS of the DIO, and the RCSS of the DIO is 498 assumed for the comparison 500 This means that if an Option is advertised in both the abbreviated 501 form and in full in a same DIO message then the RCSS in the AOO has 502 precedence. 504 To keep the RCSS comparable for each option, the RCSS of an option 505 must lazily progress along with the global RCSS even if there was no 506 change in the options. Each parent including the Root MUST advertise 507 a new RCSS for each of the protected options at least once within a 508 sliding window of SEQUENCE_WINDOW increments. 510 When an option was not changed for a new RCSS, one parent may 511 advertise it in the abbreviated form while another sends the option 512 in full only, e.g., in response to a DIS message. A fresher RCSS 513 indicates that the option is either the same or carries a more recent 514 update than the one with an older RCSS. 516 The RCSS of an option may be obtained from a DIO message that carries 517 the option in full even if the RCSS of the DIO is not the freshest 518 across parents, as long as the RCSS of the DIO is fresher than the 519 current one for that option. 521 If the current value of the maintained RCSS for a given option is not 522 fresher or as fresh as that advertised in a DIO message, then the 523 child MUST update its state for that option as specified in 524 Section 6. 526 6. Synchronizing Options 528 As the value of the RCSS progresses, a child MUST NOT attempt to 529 synchronize its state with a parent that advertises a value of RCSS 530 that is out-of-sync with self, or that is already back level vs. the 531 most recent known RCSS for each protected option, unless it lost 532 reachability to all the candidate parents that advertise a fresher 533 and not out-of-sync value of RCSS. 535 A child can synchronize any of the protected options to the latest 536 RCSS by sending a DIS Message to a candidate parent that advertises 537 that RCSS in DIO messages. The child MUST set the desired 538 combination of 'R', 'D', 'P', 'M' and 'O' flags to indicate the 539 option(s) that it needs updated. The child MUST signal in the Last 540 Synchronized RCSS field of the DIS the freshest value of RCSS for 541 which it was fully synchronized, or a conventional value of OUT-OF- 542 SYNC-RCSS of 129 if it was never synchronized or is out-of-sync with 543 the parent. 545 The DIO message that is sent in response MUST contain in full all the 546 options that are requested and that were updated since the Last 547 Synchronized RCSS in the DIS Message. This means all of the 548 protected options if the child was never synchronized or is out-of- 549 sync with the parent. The other options MUST be added in the 550 abbreviated form. 552 The options MAY be spread over more than one DIO message sent in a 553 quick sequence. It is possible that the DIS is not received by the 554 parent or that a DIO that carries all or subset of the requested 555 options is lost in return. In that case the child MUST resend a DIS 556 with the bits associated to the options that are still missing after 557 a reasonable technology-dependent time before it retries the request. 558 The child MAY use any parent that advertises the RCSS to get any of 559 the options up to that level. 561 7. Abbreviating the DAO Message 563 When a node receives a positive DAO-ACK upon a DAO message for a 564 given DAOSequence, The DAO-ACK indicates that the DAO was fully 565 processed by its destination (parent or Root). 567 Until there is a change in one of the DAO options since that 568 DAOSequence, the next DAO messages merely refresh the lifetime of the 569 routes. In that case, increasing the DAOSequence creates undesirable 570 churn up the DODAG for no added value. This specification enables a 571 node to refresh the state in a destination that is associated to one 572 or more DAO message(s) that were acknowledged by that destination 573 without resending the DAO message(s) in full. 575 Instead, the node MAY use a single abbreviated DAO message that is 576 sent to the same destination and with the same DAOSequence as the DAO 577 message(s) that it refreshes, and with the 'A' flag set (see 578 Section 4.3) to signal it is an abbreviated DAO. 580 This can be more than one message if the node could not package all 581 its state in a single message, e.g., due to MTU restrictions. In 582 that case the DAO state that is refreshed is the aggregation of the 583 DAO messages that were acknowledged for the provided DAOSequence by 584 that destination. 586 Upon the abbreviated DAO, the destination refreshes the state 587 associated to the original DAO message(s) received with that 588 DAOSequence, typically by extending the lifetimes of the routes that 589 were advertised with the same duration. 591 A node MAY also unset 'K' flag in the abbreviated DAP message and not 592 expect a DAO-ACK, if the node can assume the risk that the DAO is 593 lost, e.g., if the routes will be refreshed again before the lifetime 594 expires. 596 Only the DAO message(s) with the last (freshest) DAOSequence can be a 597 abbreviated. A nod MUST NOT use an abbreviated DAO with a 598 DAOSequence that is not the freshest and it MUST NOT use the 599 abbreviated form of the DAO until the destination has acknowledged 600 all state associated with that DAOSequence. If a destination 601 receives an abbreviated DAO with a DAOSequence that is not the 602 freshest from that node, or the destination does not have a state for 603 that node, then MUST send a DAO-ACK with a DAO Status indicating an 604 error. The destination MAY use a new Status of 'Out-of-Sync' in 605 which case the node MUST resent the DAO Message(s) in full with its 606 freshest DAOSequence and the destination synchronizes to that level. 608 It is RECOMMENDED to use an abbreviated DAO messages whenever 609 possible, because a smaller DAO message consumes less energy and 610 bandwidth and has better chances of delivery. In Non-Storing Mode 611 the benefits increases with the number of hops to the Root, and in 612 Storing Mode with the amount of state that is implicitely refreshed. 614 8. Security Considerations 616 TBD 618 9. IANA Considerations 619 9.1. New DODAG Information Solicitation Flags 621 5 new bits are allocated in the Registry for the DODAG Information 622 Solicitation (DIS) Flags defined for [RPL]. 624 +------------+----------------------------+-----------+ 625 | Bit Number | Capability description | Reference | 626 +============+============================+===========+ 627 | 0 | 'R' bit "RIO requested" | THIS RFC | 628 +------------+----------------------------+-----------+ 629 | 1 | 'D' bit "DCO requested" | THIS RFC | 630 +------------+----------------------------+-----------+ 631 | 2 | 'P' bit "PIO(s) requested" | THIS RFC | 632 +------------+----------------------------+-----------+ 633 | 3 | 'M' bit "MOPex requested" | THIS RFC | 634 +------------+----------------------------+-----------+ 635 | 4 | 'O' bit "GCO irequested" | THIS RFC | 636 +------------+----------------------------+-----------+ 638 Table 1: New DIS Flags 640 9.2. New DODAG Advertisement Object Flag 642 1 new bit is allocated in the Registry for the Destination 643 Advertisement Object(DAO) Flags defined for[RPL]. 645 +------------+---------------------------+-----------+ 646 | Bit Number | Capability description | Reference | 647 +============+===========================+===========+ 648 | 2 | 'A' bit "DAO abbreviated" | THIS RFC | 649 +------------+---------------------------+-----------+ 651 Table 2: New DAO Flag 653 9.3. New RPL Control Message Option 655 A new entry is required for the new option of type "Abbreviated 656 Option", from the "RPL Control Message Options" space defined for 657 [RPL]. 659 +----------+--------------------+-----------+ 660 | Code | Description | Reference | 661 +==========+====================+===========+ 662 | TBD IANA | Abbreviated Option | THIS RFC | 663 +----------+--------------------+-----------+ 665 Table 3: New Option Type 667 10. Acknowledgments 669 11. Normative References 671 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 672 Requirement Levels", BCP 14, RFC 2119, 673 DOI 10.17487/RFC2119, March 1997, 674 . 676 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 677 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 678 May 2017, . 680 [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 681 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 682 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 683 Low-Power and Lossy Networks", RFC 6550, 684 DOI 10.17487/RFC6550, March 2012, 685 . 687 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 688 Constrained-Node Networks", RFC 7228, 689 DOI 10.17487/RFC7228, May 2014, 690 . 692 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 693 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 694 2014, . 696 [USE_OF_RPL_INFO] 697 Robles, I., Richardson, M., and P. Thubert, "Using RPI 698 Option Type, Routing Header for Source Routes and IPv6-in- 699 IPv6 encapsulation in the RPL Data Plane", Work in 700 Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-38, 701 23 March 2020, . 704 [CAPABILITIES] 705 Jadhav, R., Thubert, P., Richardson, M., and R. Sahoo, 706 "RPL Capabilities", Work in Progress, Internet-Draft, 707 draft-ietf-roll-capabilities-02, 11 March 2020, 708 . 711 [MOPEX] Jadhav, R., Thubert, P., and M. Richardson, "Mode of 712 Operation extension", Work in Progress, Internet-Draft, 713 draft-jadhav-roll-mopex-02, 6 March 2020, 714 . 716 12. Informative References 718 Authors' Addresses 720 Pascal Thubert (editor) 721 Cisco Systems, Inc 722 Building D 723 45 Allee des Ormes - BP1200 724 06254 Mougins - Sophia Antipolis 725 France 727 Phone: +33 497 23 26 34 728 Email: pthubert@cisco.com 730 Rahul Arvind Jadhav 731 Huawei Tech 732 Kundalahalli Village, Whitefield, 733 Bangalore 560037 734 Karnataka 735 India 737 Phone: +91-080-49160700 738 Email: rahul.ietf@gmail.com 740 Li Zhao 741 Cisco Systems, Inc 742 Xinsi Building 743 No. 926 Yi Shan Rd 744 SHANGHAI 745 200233 746 China 748 Email: liz3@cisco.com 750 Dominique Barthel 751 Orange Labs 752 28 chemin du Vieux ChĂȘne 753 38243 Meylan 754 France 756 Email: dominique.barthel@orange.com