idnits 2.17.00 (12 Aug 2021) /tmp/idnits53855/draft-thubert-roll-eliding-dio-information-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: ---------------------------------------------------------------------------- == 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 == Line 489 has weird spacing: '...ed form then ...' == Line 493 has weird spacing: '...in full then ...' == Line 496 has weird spacing: '... elided then ...' -- The document date (25 October 2019) is 939 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 (-01) exists of draft-ietf-roll-mopex-cap-00 Summary: 2 errors (**), 0 flaws (~~), 6 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: 27 April 2020 L. Zhao 7 Cisco Systems 8 D. Barthel 9 Orange Labs 10 25 October 2019 12 Eliding and Querying RPL Information 13 draft-thubert-roll-eliding-dio-information-02 15 Abstract 17 This document presents a method to safely elide a group of RPL 18 options in a DIO message by synchonizing the state associated with 19 each of these options between parent and child using a new sequence 20 counter in DIO or DAO messages. A child that missed a DIO message 21 with an update of any of those protected options detects it by the 22 change of sequence counter and queries the update with a DIS Message. 23 The 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 27 April 2020. 43 Copyright Notice 45 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.1. Updated DIO Base Object . . . . . . . . . . . . . . . . . 6 67 4.2. Updated DIS Base Object . . . . . . . . . . . . . . . . . 6 68 4.3. New Abbreviated Option Option . . . . . . . . . . . . . . 7 69 4.4. Updated DAO Base Object . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 15 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 86 1. Introduction 88 Classical Link State protocol 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] does not operate that way. With RPL, the routing information 96 is repeated over and over in DODAG Information Object (DIO) and 97 Destination Advertisement Object (DAO) messages. There is no concept 98 of synchronization. The most recent information overrides a previous 99 one and a stale state eventually times out. 101 The RPL way was designed to enable routing from most nodes to most 102 nodes most of the time in a Low-Power Lossy Network (LLN) where the 103 quality of the links and the cost of communications does not permit 104 to maintain a permanent synchronization. 106 This principle was applied to both the routing and non-routing 107 information such as configuration settings, prefix information, and 108 node capabilities. 110 This non-routing state is carried in RPL Messages as options. Some 111 of the DIO options may be needed to decide whether a node can join a 112 network as a leaf or as a router, and may affect the parent selection 113 or the address selection. It is thus critical that each node 114 maintains its state to the freshest and selects parents that are also 115 synchronized to the freshest. 117 [RPL] allows a parent to elide options in the DIO messages that it 118 sends repeatedly, to conserve battery and save bandwidth. When it 119 does so, a newcomer child that missed DIOs that contained the 120 configuration option may operate on default or partial information. 121 If it is pessimistic, it may query all possible the information even 122 when it is not needed. Conversely, a node that slept may have missed 123 a DIO with a change in some critical information and may not be even 124 aware of it, so it may fail to query for the update and operate on 125 deprecated parameters. 127 This document uses a new sequence counter called RCSS to synchronize 128 the state in a child node with that of its parent, and recursively 129 with that of the whole network, to the latest setting from the Root. 131 The protected options are: 133 1. The Route Information Option (RIO) defined in section 6.7.5 of 134 [RPL] 136 2. The DODAG Configuration Option (DCO) defined in section 6.7.6 of 137 [RPL] 139 3. The Prefix Information Option (PIO) defined in section 6.7.10 of 140 [RPL] 142 4. The Extended MOP Option (MOPex) defined in [MOPEX-CAP] 143 5. The Global Capabilities Option (GCO) defined in [MOPEX-CAP] 145 Any change in those options causes an increment of the RCSS and 146 enables a network-wide synchronization to the new state. If the 147 change impacts the routing substantially, the Root should decide to 148 increment the Version Number at the same time to fully rebuild the 149 DODAG with the new settings of the options. It must be noted that 150 the operation of the Version Number in itself provides no guarantee 151 that the non-routing state is fully resynchronized everywhere unless 152 all the options are present in all the DIO messages. 154 2. Terminology 156 2.1. BCP 14 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 160 "OPTIONAL" in this document are to be interpreted as described in BCP 161 14 [RFC2119][RFC8174] when, and only when, they appear in all 162 capitals, as shown here. 164 2.2. References 166 The Terminology used in this document is consistent with and 167 incorporates that described in Terms Used in Routing for Low-Power 168 and Lossy Networks [RFC7102]. 170 Other terms in use in LLNs are found in Terminology for 171 Constrained-Node Networks [RFC7228]. 173 A glossary of classical RPL acronyms is given in Section 2.3. 175 The term "byte" is used in its now customary sense as a synonym for 176 "octet". 178 "RPL", "RPL Packet Information" (RPI) and "RPL Instance", DIO, DAO 179 and DIS messages are defined in the "RPL: IPv6 Routing Protocol for 180 Low-Power and Lossy Networks" [RPL] specification. 182 This document uses the terms RPL-Unaware Leaf (RUL) and RPL Aware 183 Leaf (RAL) consistently with [USE_OF_RPL_INFO]. 185 The term RPL-Unaware Leaf (RUL) is used to refer to a node that uses 186 a RPL router (without necessarily knowing it) as 6LR and depends on 187 that router to obtain reachability for its addresses inside the RPL 188 domain. On the contrary, the term RPL-Aware Node (RAN) is used to 189 refer to a RAL or a RPL router that participates to RPL and 190 advertises its addresses of prefixes by itself. 192 2.3. Glossary 194 This document often uses the following acronyms: 196 DODAG Destination-Oriented Directed Acyclic Graph 198 LLN Low-Power and Lossy Network 200 RPI RPL Packet Information (an Option in the Hop-By_Hop Header) 202 RAL RPL-Aware Leaf 204 RAN RPL-Aware Node, a RPL router or a RPL-Aware Leaf 206 RS Router Solicitation 208 RCSS RPL Configuration State Sequence 210 RPL IPv6 Routing Protocol for LLNs (pronounced ripple) 212 RUL RPL-Unaware Leaf 214 3. Updating RFC 6550 216 This document adds a new field called RCSS to the DIO message. The 217 RCSS is a sequence counter set by the Root and operated as specified 218 in Section 7 of [RPL], more in Section 5. 220 This document also introduces a new RPL Control Message Option called 221 the Abbreviated Option Option (AOO). The AOO is the compressed 222 replacement of a protected option that indicates the RCSS of the last 223 change of that option, but elides its content, more in Section 4.3. 225 This document modifies the DIS Base Object to enable the individual 226 query of the protected options by a node that missed a change, more 227 in Section 4.2. 229 This document also enables to abbreviate a full DAO message when all 230 the options are unchanged from the previous DAO message that was 231 positively acknowledged. In that case the DAO is resent with the 232 same DAOSequence and all the options are elided. A new flag in the 233 DAO Base Object indicates that this is an abbreviated DAO message, 234 more in Section 7. 236 4. Message Formats 237 4.1. Updated DIO Base Object 239 The format of the DIO Base Object is defined in section 6.3.1 of 240 [RPL]. This specification uses a 8th octet that was reserved in 241 [RPL] to transport the RCSS. 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | RPLInstanceID |Version Number | Rank | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 |G|0| MOP | Prf | DTSN | Flags | RCSS | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | | 251 + + 252 | | 253 + DODAGID + 254 | | 255 + + 256 | | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Option(s)... 259 +-+-+-+-+-+-+-+-+ 261 Figure 1: Updated DIO Base Object 263 Updated fields: 265 RCSS 266 One Byte, the RPL Configuration State Sequence 268 4.2. Updated DIS Base Object 270 The DIS Base Object is use by a child to query from a parent the most 271 recent changes in protected options. This specification adds flags 272 to indicate which options are requested and the freshest RCSS to 273 which the querying node was synchronized. 275 0 1 2 276 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 |R|D|P[M|O| Flg | LastSync RCSS | Option(s)... 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Figure 2: Updated DIS Base Object 283 Updated fields: 285 R 286 One Bit, indicates that the RIO is requested 288 D 289 One Bit, indicates that the DCO is requested 291 P 292 One Bit, indicates that the PIO(s) is(are) requested 294 M 295 One Bit, indicates that the MOPex is requested 297 O 298 One Bit, indicates that the GCO is requested 300 Last Synchronized RCSS 301 One Byte, indicates the freshest RCSS to which the querier was 302 synchronized 304 4.3. New Abbreviated Option Option 306 The abbreviated version of an option is a replacement for any option. 307 It does not advertise the content of the option but indicates the 308 sender's value for the RCSS of that option. It is transported in a 309 4-bytes long Abbreviated Option Option (AOO) with a format as below: 311 0 1 2 3 312 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 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Option Type | Option Length | Abbrev. opt. | Last Mod RCSS | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Figure 3: Abbreviated Option Option Format 319 Option fields: 321 Option Type 322 One byte indicating "Abbreviated Option", see Table 3 in 323 Section 9.3 325 Option Length 326 MUST be set to 2 indicating Option data of 2 bytes 328 Abbreviated Option 329 The Option Type of the option being abbreviated 331 Last Modification RCSS 332 The RCSS at which the option was last modified 334 4.4. Updated DAO Base Object 336 The format of the DAO Base Object is defined in section 6.4.1 of 337 [RPL]. This specification adds a 'A' flag in to indicate the DAO 338 options eliding. 340 0 1 2 3 341 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 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | RPLInstanceID |K|D|A| Flags | Reserved | DAOSequence | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | | 346 + + 347 | | 348 + DODAGID* + 349 | | 350 + + 351 | | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Option(s)... 354 +-+-+-+-+-+-+-+-+ 356 Figure 4: Updated DAO Base Object 358 Updated fields: 360 A 361 One Bit, indicates DAO in abbreviated version 363 5. RCSS Operation 365 Settings and updates to network-wide parameters are initiated by the 366 Root and propagated down the DODAG in RPL Control Message Options in 367 DIO messages. The DIO messages arrive asynchronously via different 368 parents and may confuse a child. The RCSS allows the child to keep 369 synchronized to the latest settings network-wide parameters that are 370 propagated in protected options. 372 The RCSS is a sequence number that is operated as specified in 373 section 7.2 of [RPL]. The scope of an RCSS is one DODAG within one 374 RPL Instance. The RCSS applies to a DIO Message and a same value of 375 the RCSS can be used in DIO messages that are sent consecutively with 376 no change in 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 RCSS and the protected options are 380 propagated together down the DODAG without a change, more in 381 Section 5.1. 383 The RCSS allows a child node to recognize the fresher DIO Message(s) 384 as received from one or more advertising parents and to use only 385 parents with a consistent state of network-wide parameters, more in 386 Section 5.2. 388 By extension, the RCSS is also defined for each protected option. A 389 child associates an option with the values of the RCSS indicated in 390 DIO Messages in which the option is advertised and uses it to assess 391 the relative freshness of different versions of an option, more in 392 Section 5.3. 394 Unchanged options may be sent in full, elided, or in the abbreviated 395 form specified in Section 4.3. Which form to use depends on the 396 RCSS, more in Section 5.3 398 If the link MTU does not permit to send a single DIO message with all 399 the options packaged then the options may be spread over multiple 400 consecutive DIO messages with the same RCSS that are sent in a rapid 401 sequence. 403 5.1. Updating the RCSS 405 The RCSS is incremented by the Root using a lollipop technique as 406 specified in section 7.2 of [RPL]. RCSS values are comparable if 407 they are within a window of comparison of SEQUENCE_WINDOW increments 408 or one indicates a reboot. 410 A reboot of the Root is detected when the RCSS moves from the 411 circular to the straight part of the lollipop. In order to maximize 412 the chances of detection, the straight part should be kept very short 413 with a RECOMMENDED initialization at 252 or above. 415 During the straight part of the lollipop, a second reboot of the Root 416 might not be recognized and a same value of the RCSS may reappear 417 with different settings in the protected options. For that reason 418 the protected options MUST be provided in full with each increment on 419 the RCSS during the straight part of the lollipop. 421 When a field is modified in one of the protected options, the Root 422 MUST send a DIO with an incremented RCSS and the modified protected 423 option(s) in full. The Root MAY also update the Version Number to 424 form a new DODAG altogether. 426 The Root SHOULD jump rapidly away from the straight part once the 427 network has sufficiently settled by resetting the RCSS to 0, which 428 places the RCSS in the circular region of the lollipop, where the 429 protected options MAY be elided or abbreviated. 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 all the protected options 436 synchronized to it. 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 resynchronize 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 resynchronize 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, it is NOT RECOMMENDED for a 529 child to attempt to resynchronize to an intermediate value of a RCSS 530 with a parent that is already back level vs. the lastest known RCSS 531 or the RCSS that this child is currently using, or a parent that is 532 out-of-sync with self. The child MAY only do so if it lost 533 reachability to all the candidate parents that advertise a fresher 534 and not out-of-sync value of RCSS. 536 A child can resynchronize any of the protected options to the latest 537 RCSS by sending a DIS Message to a candidate parent that advertises 538 that RCSS in DIO messages. The child MUST set the desired 539 combination of 'R', 'D', 'P', 'M' and 'O' flags to indicate the 540 option(s) that it needs updated. The child MUST signal in the Last 541 Synchronized RCSS field of the DIS the freshest value of RCSS for 542 which it was fully synchronized, or a conventional value of OUT-OF- 543 SYNC-RCSS of 129 if it was never synchronized or is out-of-sync with 544 the parent. 546 The DIO message that is sent in response MUST contain in full all the 547 options that are requested and that were updated since the Last 548 Synchronized RCSS in the DIS Message. This means all of the 549 protected options of the child was never synchronized or is out-of- 550 sync with the parent. The other options MUST be added in the 551 abbreviated form. The options MAY be spread over more than one DIO 552 message sent in a quick sequence. It is possible that the DIS is not 553 received by the parent or that a DIO that carries all or subset of 554 the requested options is lost in return. In that case the child MUST 555 resend a DIS with the bits associated to the options that are still 556 missing after a reasonable technology-dependent time before it 557 retries the request. The child MAY use any parent that advertises 558 the RCSS to get any of the options up to that level. 560 7. Abbreviating the DAO Message 562 When a node receives a positive DAO-ACK upon a DAO message for a 563 given DAOSequence, The DAO-ACK indicates that the DAO was fully 564 processed by its destination (parent or Root). Until there's a 565 change in one of the DAO options since that DAOSequence, the next DAO 566 messages merely refresh the lifetime of the routes. In that case, 567 increasing the DAOSequence creates undesirable churn up the DODAG for 568 no added value. 570 This specification enables a node to refresh the state in a 571 destination that is associated to one or more DAO message(s) that 572 were acknowledged by that destination without resending the DAO 573 message(s) in full. Instead, the node MAY use a single abbreviated 574 DAO message that is sent to the same destination and with the same 575 DAOSequence as the DAO message(s) that it refreshes, and with the 'A' 576 flag set (see Section 4.4) to signal it is an abbreviated DAO. 578 This can be more than one message if the node could not package all 579 its state in a single message, e.g., due to MTU restrictions. In 580 that case the DAO state that is refreshed is the aggregation of the 581 DAO messages that were acknowledged for the provided DAOSequence by 582 that destination. 584 Upon the abbreviated DAO, the destination refreshes the state 585 associated to the original DAO message(s) received with that 586 DAOSequence, typically by extending the lifetimes of the routes that 587 were advertised with the same duration. 589 A node MAY also unset 'K' flag in the abbreviated DAP message and not 590 expect a DAO-ACK, if the node can assume the risk that the DAO is 591 lost, e.g., if the routes will be refreshed again before the lifetime 592 expires. 594 Only the DAO message(s) with the last (freshest) DAOSequence can be a 595 abbreviated. A nod MUST NOT use an abbreviated DAO with a 596 DAOSequence that is not the freshest and it MUST NOT use the 597 abbreviated form of the DAO until the destination has acknowledged 598 all state associated with that DAOSequence. If a destination 599 receives an abbreviated DAO with a DAOSequence that is not the 600 freshest from that node, or the destination does not have a state for 601 that node, then MUST send a DAO-ACK with a DAO Status indicating an 602 error. The destination MAY use a new Status of 'Out-of-Sync' in 603 which case the node MUST resent the DAO Message(s) in full with its 604 freshest DAOSequence and the destination resynchronizes to that 605 level. 607 It is RECOMMENDED to use an abbreviated DAO messages whenever 608 possible, because a smaller DAO message consumes less energy and 609 bandwidth and has better chances of delivery. In Non-Storing Mode 610 the benefits increases with the number of hops to the Root, and in 611 Storing Mode with the amount of state that is implicitely refreshed. 613 8. Security Considerations 615 TBD 617 9. IANA Considerations 618 9.1. New DODAG Information Solicitation Flags 620 5 new bits are allocated in the Registry for the DODAG Information 621 Solicitation (DIS) Flags defined for [RPL]. 623 +------------+----------------------------+--------------+ 624 | Bit Number | Capability description | Defining RFC | 625 +============+============================+==============+ 626 | 0 | 'R' bit "RIO requested" | THIS RFC | 627 +------------+----------------------------+--------------+ 628 | 1 | 'D' bit "DCO requested" | THIS RFC | 629 +------------+----------------------------+--------------+ 630 | 2 | 'P' bit "PIO(s) requested" | THIS RFC | 631 +------------+----------------------------+--------------+ 632 | 3 | 'M' bit "MOPex requested" | THIS RFC | 633 +------------+----------------------------+--------------+ 634 | 4 | 'O' bit "GCO irequested" | THIS RFC | 635 +------------+----------------------------+--------------+ 637 Table 1: New DIS Flags 639 9.2. New DODAG Advertisement Object Flag 641 1 new bit is allocated in the Registry for the Destination 642 Advertisement Object(DAO) Flags defined for[RPL]. 644 +------------+---------------------------+--------------+ 645 | Bit Number | Capability description | Defining RFC | 646 +============+===========================+==============+ 647 | 2 | 'A' bit "DAO abbreviated" | THIS RFC | 648 +------------+---------------------------+--------------+ 650 Table 2: New DAO Flag 652 9.3. New RPL Control Message Option 654 A new entry is required for the new option of type "Abbreviated 655 Option", from the "RPL Control Message Options" space defined for 656 [RPL]. 658 +----------+--------------------+--------------+ 659 | Code | Description | Defining RFC | 660 +==========+====================+==============+ 661 | TBD IANA | Abbreviated Option | THIS RFC | 662 +----------+--------------------+--------------+ 664 Table 3: New Option Type 666 10. Acknowledgments 668 11. Normative References 670 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 671 Requirement Levels", BCP 14, RFC 2119, 672 DOI 10.17487/RFC2119, March 1997, 673 . 675 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 676 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 677 May 2017, . 679 [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 680 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 681 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 682 Low-Power and Lossy Networks", RFC 6550, 683 DOI 10.17487/RFC6550, March 2012, 684 . 686 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 687 Constrained-Node Networks", RFC 7228, 688 DOI 10.17487/RFC7228, May 2014, 689 . 691 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 692 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 693 2014, . 695 [MOPEX-CAP] 696 Jadhav, R. and P. Thubert, "Mode of Operation extension 697 and Capabilities", Work in Progress, Internet-Draft, 698 draft-ietf-roll-mopex-cap-00, 9 August 2019, 699 . 702 [USE_OF_RPL_INFO] 703 Robles, I., Richardson, M., and P. Thubert, "Using RPL 704 Option Type, Routing Header for Source Routes and IPv6-in- 705 IPv6 encapsulation in the RPL Data Plane", Work in 706 Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-31, 707 7 August 2019, . 710 12. Informative References 711 Authors' Addresses 713 Pascal Thubert (editor) 714 Cisco Systems, Inc 715 Building D, 45 Allee des Ormes - BP1200 716 06254 Mougins - Sophia Antipolis 717 France 719 Phone: +33 497 23 26 34 720 Email: pthubert@cisco.com 722 Rahul Arvind Jadhav 723 Huawei Tech 724 Kundalahalli Village, Whitefield, 725 Bangalore 560037 726 Karnataka 727 India 729 Phone: +91-080-49160700 730 Email: rahul.ietf@gmail.com 732 Li Zhao 733 China 734 200233 735 SHANGHAI 736 Xinsi Building, No. 926 Yi Shan Rd 737 Cisco Systems, Inc 739 Email: liz3@cisco.com 741 Dominique Barthel 742 Orange Labs 743 28 chemin du Vieux Chêne 744 38243 Meylan 745 France 747 Email: dominique.barthel@orange.com