idnits 2.17.1 draft-thubert-roll-eliding-dio-information-03.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 491 has weird spacing: '...ed form then ...' == Line 495 has weird spacing: '...in full then ...' == Line 498 has weird spacing: '... elided then ...' -- The document date (17 November 2019) is 1622 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 Summary: 2 errors (**), 0 flaws (~~), 5 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: 20 May 2020 L. Zhao 7 Cisco Systems 8 D. Barthel 9 Orange Labs 10 17 November 2019 12 Eliding and Querying RPL Information 13 draft-thubert-roll-eliding-dio-information-03 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 20 May 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 . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . 14 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 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 information even when 122 it is not needed. Conversely, a node that slept may have missed a 123 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 Leaf, RPL Aware Leaf (RAL), RPL- 183 Aware Node (RAN) and RPL-Unaware Leaf (RUL) as defined in section 2 184 of [USE_OF_RPL_INFO]. 186 A RPL-Unaware Leaf (RUL) thus refers to a host that does not 187 understand RPL but uses a RPL router (without necessarily knowing it) 188 as 6LR and depends on that router to obtain reachability for its 189 addresses inside the RPL domain. On the contrary, the term RPL-Aware 190 Node (RAN) is used to refer to a node that participates to RPL and 191 advertises its addresses or prefixes by itself. 193 2.3. Glossary 195 This document often uses the following acronyms: 197 DODAG Destination-Oriented Directed Acyclic Graph 199 LLN Low-Power and Lossy Network 201 RPI RPL Packet Information (an Option in the Hop-By_Hop Header) 203 RAL RPL-Aware Leaf 205 RAN RPL-Aware Node 207 RS Router Solicitation 209 RCSS RPL Configuration State Sequence 211 RPL IPv6 Routing Protocol for LLNs (pronounced ripple) 213 RUL RPL-Unaware Leaf 215 3. Updating RFC 6550 217 This document adds a new field called RCSS to the DIO message. The 218 RCSS is a sequence counter set by the Root and operated as specified 219 in Section 7 of [RPL], more in Section 5. 221 This document also introduces a new RPL Control Message Option called 222 the Abbreviated Option Option (AOO). The AOO is the compressed 223 replacement of a protected option that indicates the RCSS of the last 224 change of that option, but elides its content, more in Section 4.3. 226 This document modifies the DIS Base Object to enable the individual 227 query of the protected options by a node that missed a change, more 228 in Section 4.2. 230 This document also enables to abbreviate a full DAO message when all 231 the options are unchanged from the previous DAO message that was 232 positively acknowledged. In that case the DAO is resent with the 233 same DAOSequence and all the options are elided. A new flag in the 234 DAO Base Object indicates that this is an abbreviated DAO message, 235 more in Section 7. 237 4. Message Formats 239 4.1. Updated DIO Base Object 241 The format of the DIO Base Object is defined in section 6.3.1 of 242 [RPL]. In order to transport the RCSS, this specification uses an 243 8th octet that was reserved in [RPL]. 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | RPLInstanceID |Version Number | Rank | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 |G|0| MOP | Prf | DTSN | Flags | RCSS | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | | 253 + + 254 | | 255 + DODAGID + 256 | | 257 + + 258 | | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Option(s)... 261 +-+-+-+-+-+-+-+-+ 263 Figure 1: Updated DIO Base Object 265 Updated fields: 267 RCSS 268 One Byte, the RPL Configuration State Sequence 270 4.2. Updated DIS Base Object 272 The DIS Base Object is use by a child to query from a parent the most 273 recent changes in protected options. This specification adds flags 274 to indicate which options are requested and the freshest RCSS to 275 which the querying node was synchronized. 277 0 1 2 278 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 |R|D|P[M|O| Flg | LastSync RCSS | Option(s)... 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Figure 2: Updated DIS Base Object 285 Updated fields: 287 R 288 One Bit, indicates that the RIO is requested 290 D 291 One Bit, indicates that the DCO is requested 293 P 294 One Bit, indicates that the PIO(s) is(are) requested 296 M 297 One Bit, indicates that the MOPex is requested 299 O 300 One Bit, indicates that the GCO is requested 302 Last Synchronized RCSS 303 One Byte, indicates the freshest RCSS to which the querier was 304 synchronized 306 4.3. New Abbreviated Option Option 308 The abbreviated version of an option is a replacement for any option. 309 It does not advertise the content of the option but indicates the 310 sender's value for the RCSS of that option. It is transported in a 311 4-bytes long Abbreviated Option Option (AOO) with a format as below: 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Option Type | Option Length | Abbrev. opt. | Last Mod RCSS | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 Figure 3: Abbreviated Option Option Format 321 Option fields: 323 Option Type 324 One byte indicating "Abbreviated Option", see Table 3 in 325 Section 9.3 327 Option Length 328 MUST be set to 2 indicating Option data of 2 bytes 330 Abbreviated Option 331 The Option Type of the option being abbreviated 333 Last Modification RCSS 334 The RCSS at which the option was last modified 336 4.4. Updated DAO Base Object 338 The format of the DAO Base Object is defined in section 6.4.1 of 339 [RPL]. This specification adds a 'A' flag in to indicate the DAO 340 options eliding. 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | RPLInstanceID |K|D|A| Flags | Reserved | DAOSequence | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | | 348 + + 349 | | 350 + DODAGID* + 351 | | 352 + + 353 | | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Option(s)... 356 +-+-+-+-+-+-+-+-+ 358 Figure 4: Updated DAO Base Object 360 Updated fields: 362 A 363 One Bit, indicates DAO in abbreviated version 365 5. RCSS Operation 367 Settings and updates to network-wide parameters are initiated by the 368 Root and propagated down the DODAG in RPL Control Message Options in 369 DIO messages. The DIO messages arrive asynchronously via different 370 parents and may confuse a child. The RCSS allows the child to keep 371 synchronized to the latest settings network-wide parameters that are 372 propagated in protected options. 374 The RCSS is a sequence number that is operated as specified in 375 section 7.2 of [RPL]. The scope of an RCSS is one DODAG within one 376 RPL Instance. The RCSS applies to a DIO Message and a same value of 377 the RCSS can be used in DIO messages that are sent consecutively with 378 no change in the protected options. 380 The Root of the DODAG is autoritative to set and update the RCSS and 381 the options that it protects. The RCSS and the protected options are 382 propagated together down the DODAG without a change, more in 383 Section 5.1. 385 The RCSS allows a child node to recognize the fresher DIO Message(s) 386 as received from one or more advertising parents and to use only 387 parents with a consistent state of network-wide parameters, more in 388 Section 5.2. 390 By extension, the RCSS is also defined for each protected option. A 391 child associates an option with the values of the RCSS indicated in 392 DIO Messages in which the option is advertised and uses it to assess 393 the relative freshness of different versions of an option, more in 394 Section 5.3. 396 Unchanged options may be sent in full, elided, or in the abbreviated 397 form specified in Section 4.3. Which form to use depends on the 398 RCSS, more in Section 5.3 400 If the link MTU does not permit to send a single DIO message with all 401 the options packaged then the options may be spread over multiple 402 consecutive DIO messages with the same RCSS that are sent in a rapid 403 sequence. 405 5.1. Updating the RCSS 407 The RCSS is incremented by the Root using a lollipop technique as 408 specified in section 7.2 of [RPL]. RCSS values are comparable if 409 they are within a window of comparison of SEQUENCE_WINDOW increments 410 or one indicates a reboot. 412 A reboot of the Root is detected when the RCSS moves from the 413 circular to the straight part of the lollipop. In order to maximize 414 the chances of detection, the straight part should be kept very short 415 with a RECOMMENDED initialization at 252 or above. 417 During the straight part of the lollipop, a second reboot of the Root 418 might not be recognized and a same value of the RCSS may reappear 419 with different settings in the protected options. For that reason 420 the protected options MUST be provided in full with each increment on 421 the RCSS during the straight part of the lollipop. 423 When a field is modified in one of the protected options, the Root 424 MUST send a DIO with an incremented RCSS and the modified protected 425 option(s) in full. The Root MAY also update the Version Number to 426 form a new DODAG altogether. 428 The Root SHOULD jump rapidly away from the straight part once the 429 network has sufficiently settled by resetting the RCSS to 0, which 430 places the RCSS in the circular region of the lollipop, where the 431 protected options MAY be elided or abbreviated. 433 5.2. RCSS Freshness and Parent selection 435 A child node maintains the freshest RCSS received from its parents in 436 each of the RPL Instances that it participates to, and uses that RCSS 437 for its own DIO messages once it has all the protected options 438 synchronized to it. 440 A child and a candidate parent are out-of-sync when the RCSS values 441 that they maintain for a RPL Instance are not comparable. A child 442 MUST NOT use a parent that is out-of-sync unless no other parent is 443 available, in which case it MAY align its RCSS and resynchronize to 444 that parent. 446 When a child receives from a candidate parent a DIO with an RCSS that 447 is fresher than the one it is using, the child MUST synchronize the 448 state relative to the protected options with that parent. The child 449 node MUST refrain from using that parent and the new state including 450 the RCSS, until it has synchronized all of the protected options to 451 that RCSS. When it is fully synchronized, the child may then use 452 that parent and the new RCSS. 454 Using a back-level parent may cause packets to be dropped, 455 misunderstood or misrouted. The child SHOULD refrain from using a 456 parent that exposes an older RCSS if the change causes an 457 incompatibility issue. 459 5.3. RCSS of an Option 461 By extension, the RCSS of an option is maintained by all nodes and is 462 defined for all but the root as the freshest RCSS indicated by a DIO 463 message from a candidate parent in which the option was present, in 464 the abbreviated form or in full. A child maintains a state for the 465 RCSS of each of the protected options and synchronizes its state for 466 the options by comparing that RCSS with the one found in new DIO 467 messages for the option. 469 Protected options may be sent in full, elided, or in the abbreviated 470 form. Which form to use depends on the RCSS of the option that a 471 parent maintains: 473 * A parent MAY use either form when the RCSS is not changed from a 474 previous DIO; eliding options is PREFERRED in stable conditions to 475 save resources. 477 * When a protected option is updated, the RCSS is mechanically 478 incremented, and the new option MUST be sent in full on the first 479 DIO that advertises that new RCSS and the corresponding AOO SHOULD 480 NOT be added. 482 * When the RCSS is updated but a protected option is unchanged, the 483 parent SHOULD NOT fully elide the option as it may cause multiple 484 children to resynchronize it to no avail. The use of AOO is 485 RECOMMENDED unless it may cause a desynchronization for that 486 option, in which case the option SHOULD be placed in full more in 487 Section 5.3. 489 When a child receives a DIO from a candidate parent, for each option: 491 If the Option is advertised in the abbreviated form then the RCSS 492 that the DIO advertises for the option is the Last Modification 493 RCSS of the AOO, else 495 If the Option is advertised in full then the RCSS that the DIO 496 advertises for the option is the RCSS of the DIO, else 498 If the Option is elided then the RCSS is unspecified but it is at 499 most as fresh as the RCSS of the DIO, and the RCSS of the DIO is 500 assumed for the comparison 502 This means that if an Option is advertised in both the abbreviated 503 form and in full in a same DIO message then the RCSS in the AOO has 504 precedence. 506 To keep the RCSS comparable for each option, the RCSS of an option 507 must lazily progress along with the global RCSS even if there was no 508 change in the options. Each parent including the Root MUST advertise 509 a new RCSS for each of the protected options at least once within a 510 sliding window of SEQUENCE_WINDOW increments. 512 When an option was not changed for a new RCSS, one parent may 513 advertise it in the abbreviated form while another sends the option 514 in full only, e.g., in response to a DIS message. A fresher RCSS 515 indicates that the option is either the same or carries a more recent 516 update than the one with an older RCSS. 518 The RCSS of an option may be obtained from a DIO message that carries 519 the option in full even if the RCSS of the DIO is not the freshest 520 across parents, as long as the RCSS of the DIO is fresher than the 521 current one for that option. 523 If the current value of the maintained RCSS for a given option is not 524 fresher or as fresh as that advertised in a DIO message, then the 525 child MUST update its state for that option as specified in 526 Section 6. 528 6. Synchronizing Options 530 As the value of the RCSS progresses, it is NOT RECOMMENDED for a 531 child to attempt to resynchronize to an intermediate value of a RCSS 532 with a parent that is already back level vs. the lastest known RCSS 533 or the RCSS that this child is currently using, or a parent that is 534 out-of-sync with self. The child MAY only do so if it lost 535 reachability to all the candidate parents that advertise a fresher 536 and not out-of-sync value of RCSS. 538 A child can resynchronize any of the protected options to the latest 539 RCSS by sending a DIS Message to a candidate parent that advertises 540 that RCSS in DIO messages. The child MUST set the desired 541 combination of 'R', 'D', 'P', 'M' and 'O' flags to indicate the 542 option(s) that it needs updated. The child MUST signal in the Last 543 Synchronized RCSS field of the DIS the freshest value of RCSS for 544 which it was fully synchronized, or a conventional value of OUT-OF- 545 SYNC-RCSS of 129 if it was never synchronized or is out-of-sync with 546 the parent. 548 The DIO message that is sent in response MUST contain in full all the 549 options that are requested and that were updated since the Last 550 Synchronized RCSS in the DIS Message. This means all of the 551 protected options if the child was never synchronized or is out-of- 552 sync with the parent. The other options MUST be added in the 553 abbreviated form. The options MAY be spread over more than one DIO 554 message sent in a quick sequence. It is possible that the DIS is not 555 received by the parent or that a DIO that carries all or subset of 556 the requested options is lost in return. In that case the child MUST 557 resend a DIS with the bits associated to the options that are still 558 missing after a reasonable technology-dependent time before it 559 retries the request. The child MAY use any parent that advertises 560 the RCSS to get any of the options up to that level. 562 7. Abbreviating the DAO Message 564 When a node receives a positive DAO-ACK upon a DAO message for a 565 given DAOSequence, The DAO-ACK indicates that the DAO was fully 566 processed by its destination (parent or Root). Until there's a 567 change in one of the DAO options since that DAOSequence, the next DAO 568 messages merely refresh the lifetime of the routes. In that case, 569 increasing the DAOSequence creates undesirable churn up the DODAG for 570 no added value. 572 This specification enables a node to refresh the state in a 573 destination that is associated to one or more DAO message(s) that 574 were acknowledged by that destination without resending the DAO 575 message(s) in full. Instead, the node MAY use a single abbreviated 576 DAO message that is sent to the same destination and with the same 577 DAOSequence as the DAO message(s) that it refreshes, and with the 'A' 578 flag set (see Section 4.4) 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 resynchronizes to that 607 level. 609 It is RECOMMENDED to use an abbreviated DAO messages whenever 610 possible, because a smaller DAO message consumes less energy and 611 bandwidth and has better chances of delivery. In Non-Storing Mode 612 the benefits increases with the number of hops to the Root, and in 613 Storing Mode with the amount of state that is implicitely refreshed. 615 8. Security Considerations 617 TBD 619 9. IANA Considerations 621 9.1. New DODAG Information Solicitation Flags 623 5 new bits are allocated in the Registry for the DODAG Information 624 Solicitation (DIS) Flags defined for [RPL]. 626 +------------+----------------------------+-----------+ 627 | Bit Number | Capability description | Reference | 628 +============+============================+===========+ 629 | 0 | 'R' bit "RIO requested" | THIS RFC | 630 +------------+----------------------------+-----------+ 631 | 1 | 'D' bit "DCO requested" | THIS RFC | 632 +------------+----------------------------+-----------+ 633 | 2 | 'P' bit "PIO(s) requested" | THIS RFC | 634 +------------+----------------------------+-----------+ 635 | 3 | 'M' bit "MOPex requested" | THIS RFC | 636 +------------+----------------------------+-----------+ 637 | 4 | 'O' bit "GCO irequested" | THIS RFC | 638 +------------+----------------------------+-----------+ 640 Table 1: New DIS Flags 642 9.2. New DODAG Advertisement Object Flag 644 1 new bit is allocated in the Registry for the Destination 645 Advertisement Object(DAO) Flags defined for[RPL]. 647 +------------+---------------------------+-----------+ 648 | Bit Number | Capability description | Reference | 649 +============+===========================+===========+ 650 | 2 | 'A' bit "DAO abbreviated" | THIS RFC | 651 +------------+---------------------------+-----------+ 653 Table 2: New DAO Flag 655 9.3. New RPL Control Message Option 657 A new entry is required for the new option of type "Abbreviated 658 Option", from the "RPL Control Message Options" space defined for 659 [RPL]. 661 +----------+--------------------+-----------+ 662 | Code | Description | Reference | 663 +==========+====================+===========+ 664 | TBD IANA | Abbreviated Option | THIS RFC | 665 +----------+--------------------+-----------+ 667 Table 3: New Option Type 669 10. Acknowledgments 671 11. Normative References 673 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 674 Requirement Levels", BCP 14, RFC 2119, 675 DOI 10.17487/RFC2119, March 1997, 676 . 678 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 679 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 680 May 2017, . 682 [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 683 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 684 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 685 Low-Power and Lossy Networks", RFC 6550, 686 DOI 10.17487/RFC6550, March 2012, 687 . 689 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 690 Constrained-Node Networks", RFC 7228, 691 DOI 10.17487/RFC7228, May 2014, 692 . 694 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 695 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 696 2014, . 698 [MOPEX-CAP] 699 Jadhav, R., Thubert, P., and M. Richardson, "Mode of 700 Operation extension and Capabilities", Work in Progress, 701 Internet-Draft, draft-ietf-roll-mopex-cap-01, 2 November 702 2019, . 705 [USE_OF_RPL_INFO] 706 Robles, I., Richardson, M., and P. Thubert, "Using RPL 707 Option Type, Routing Header for Source Routes and IPv6-in- 708 IPv6 encapsulation in the RPL Data Plane", Work in 709 Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-31, 710 7 August 2019, . 713 12. Informative References 715 Authors' Addresses 717 Pascal Thubert (editor) 718 Cisco Systems, Inc 719 Building D, 45 Allee des Ormes - BP1200 720 06254 Mougins - Sophia Antipolis 721 France 723 Phone: +33 497 23 26 34 724 Email: pthubert@cisco.com 726 Rahul Arvind Jadhav 727 Huawei Tech 728 Kundalahalli Village, Whitefield, 729 Bangalore 560037 730 Karnataka 731 India 733 Phone: +91-080-49160700 734 Email: rahul.ietf@gmail.com 736 Li Zhao 737 China 738 200233 739 SHANGHAI 740 Xinsi Building, No. 926 Yi Shan Rd 741 Cisco Systems, Inc 743 Email: liz3@cisco.com 745 Dominique Barthel 746 Orange Labs 747 28 chemin du Vieux Chêne 748 38243 Meylan 749 France 751 Email: dominique.barthel@orange.com