idnits 2.17.00 (12 Aug 2021) /tmp/idnits52349/draft-thubert-roll-eliding-dio-information-00.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 (15 October 2019) is 949 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-01) exists of draft-ietf-roll-mopex-cap-00 ** Downref: Normative reference to an Informational RFC: RFC 7102 ** Downref: Normative reference to an Informational RFC: RFC 7228 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) D. Barthel 5 Intended status: Standards Track Orange Labs 6 Expires: 17 April 2020 R.A. Jadhav 7 Huawei Tech 8 15 October 2019 10 Eliding and Querying RPL Information 11 draft-thubert-roll-eliding-dio-information-00 13 Abstract 15 This document presents a method to elide a group of global RPL 16 options by synchonizing the state associated with each of these 17 options between parent and child using a new sequence counter in DIO 18 messages. A child that missed a DIO message with an update of any of 19 those protected options detects it by the change of sequence counter 20 and queries the update with a DIS Message. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 17 April 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 4 61 4. New RPL Configuration State Sequence . . . . . . . . . . . . 4 62 5. Protected Options . . . . . . . . . . . . . . . . . . . . . . 5 63 6. Child Operation . . . . . . . . . . . . . . . . . . . . . . . 6 64 7. Pulling Options . . . . . . . . . . . . . . . . . . . . . . . 7 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 69 12. Normative References . . . . . . . . . . . . . . . . . . . . 7 70 13. Informative References . . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 Classical Link State protocol synchronize their Link State Database 76 (LSDB) by sequencing every change. Each interested node maintains 77 the last sequence of the LSDB it is synchronizing with. If a last 78 known sequence is older than the current, the node needs to learn one 79 by one all the state changes between the last known and the current 80 state. 82 [RPL] does not operate that way. With RPL, the routing information 83 is repeated over and over in DODAG Information Object (DIO) and 84 Destination Advertisement Object (DAO) messages. There is no concept 85 of synchronization. The most recent information overrides a previous 86 one and a stale state eventually times out. 88 The RPL way was designed to enable routing from most nodes to most 89 nodes most of the time in a Low-Power Lossy Network (LLN) where the 90 quality of the links and the cost of communications does not permit 91 to maintain a permanent synchronization. This principle was applied 92 to both the routing information and non-routing state such as 93 configuration settings, prefix information, and node capabilities. 95 This non-routing state may be needed to decide whether a node can 96 join a network as a leaf or as a router, and may affect the parent 97 selection. [RPL] allows a parent to elide that information in the 98 DIO it sends repeatedly, but if it does so, a newcomer child may have 99 missed the early DIOs that contained the configuration option and 100 live with only partial information. If it is pessimistic, it may 101 query all possible information even when it is not needed. 102 Conversely, a node that slept may have missed a DIO message with a 103 change in some critical information and not be aware of it, so it may 104 fail to query for the update and operate on deprecated parameters. 106 This document uses a new sequence counter to synchronize the state in 107 a child node with that of its parent, and recursively with that of 108 the network. 110 2. Terminology 112 2.1. BCP 14 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in BCP 117 14 [RFC2119][RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 2.2. References 122 The Terminology used in this document is consistent with and 123 incorporates that described in Terms Used in Routing for Low-Power 124 and Lossy Networks (LLNs). [RFC7102]. 126 Other terms in use in LLNs are found in Terminology for 127 Constrained-Node Networks [RFC7228]. 129 A glossary of classical RPL acronyms is given in Section 2.3. 131 The term "byte" is used in its now customary sense as a synonym for 132 "octet". 134 "RPL", "RPL Packet Information" (RPI) and "RPL Instance", DIO, DAO 135 and DIS messages are defined in the "RPL: IPv6 Routing Protocol for 136 Low-Power and Lossy Networks" [RPL] specification. 138 This document uses the terms RPL-Unaware Leaf (RUL) and RPL Aware 139 Leaf (RAL) consistently with [USE_OF_RPL_INFO]. 141 The term RPL-Unaware Leaf (RUL) is used to refer to a node that uses 142 a RPL router (without necessarily knowing it) as 6LR and depends on 143 that router to obtain reachability for its addresses inside the RPL 144 domain. On the contrary, the term RPL-Aware Node (RAN) is used to 145 refer to a RAL or a RPL router that participates to RPL and 146 advertises its addresses of prefixes by itself. 148 2.3. Glossary 150 This document often uses the following acronyms: 152 DODAG Destination-Oriented Directed Acyclic Graph 154 LLN Low-Power and Lossy Network 156 RPI RPL Packet Information (an Option in the Hop-By_Hop Header) 158 RAL RPL-Aware Leaf 160 RAN RPL-Aware Node, a RPL router or a RPL-Aware Leaf 162 RS Router Solicitation 164 RPL IPv6 Routing Protocol for LLNs (pronounced ripple) 166 RUL RPL-Unaware Leaf 168 3. Updating RFC 6550 170 This document adds a sequence counter called RPL Configuration State 171 Sequence (RCSS) to the DIO message. The RCSS is set by the root and 172 operated as specified in Section 7 of [RPL], more in Section 4. 174 This document introduces a new RPL Control Message Options called the 175 Abbreviated Option Option (AOO). The AOO is an empty replacement of 176 an existing option that indicates the RCSS of the last change of that 177 option. 179 This document modifies the Solicited Information Option to enable the 180 individual query of the protected options by a node that missed a 181 change, more in Section 7. 183 4. New RPL Configuration State Sequence 185 The format of the DIO Base Object is defined in section 6.3.1 of 186 [RPL]. This specification uses a 8th octet that was previously 187 reserved to transport the RCSS. 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | RPLInstanceID |Version Number | Rank | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 |G|0| MOP | Prf | DTSN | Flags | RCSS | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | | 197 + + 198 | | 199 + DODAGID + 200 | | 201 + + 202 | | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Option(s)... 205 +-+-+-+-+-+-+-+-+ 207 Figure 1: MOdified DIO Base Object 209 Updated fields: 211 RCSS 212 One Byte, the RPL Configuration State Sequence 214 The RCSS protects network-wide options that are set by the root and 215 that are propagated without a change down the DODAG. The RCSS MUST 216 be incremented when the root sends a DIO where at least one of the 217 protected options is modified. It MUST propagated down without a 218 change together with the options that it protects. 220 During the straight part of the lollipop, a second reboot of the root 221 might not be recognized and a same value of the RCSS may appear with 222 new values in the protected options. For that reason the protected 223 options MUST be present in the DIOs during the straight part of the 224 lollipop and the root SHOULD move rapidly away from the straight part 225 once the network has settled by resetting the RCSS to 0, which places 226 the RCSS in the circular region of the lollipop. 228 5. Protected Options 230 The protected options are: 232 1. The Route Information Option (RIO) defined in section 6.7.5 of 233 [RPL] 235 2. The DODAG Configuration Option (DCO) defined in section 6.7.6 of 236 [RPL] 238 3. The Prefix Information Option (PIO) defined in section 6.7.10 of 239 [RPL] 241 4. The Extended MOP Option (MOPex) defined in [MOPEX-CAP] 243 5. The Global Capabilities Option (GCO) defined in [MOPEX-CAP] 245 When a protected option is unchanged from the previous DIOs, the root 246 MAY replace it with its abbreviated version. The abbreviated version 247 of an option is transported in a 4-bytes long Abbreviated Option 248 Option (AOO). The AOO indicates the RCSS at which the protected 249 option was last changed. 251 0 1 2 3 252 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 2 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Option Type | Option Length | Abbrev. opt. | Last Mod RCSS | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Figure 2: Abbreviated Option Option Format 259 Option fields: 261 Option Type 262 One byte indicating "Abbreviated Option", see Table 1 264 Option Length 265 MUST be set to 2 indicating Option data of 2 bytes 267 Abbreviated Option 268 The Option Type of the option being abreviated 270 Last Modification RCSS 271 The RCSS at which the option was last modified 273 6. Child Operation 275 When a field is modified in one of the protected options in a fashion 276 that may affect the routing or forwarding decision inside the DODAG, 277 the root MUST send a DIO with the protected options. Unchanged 278 options may be abreviated as discussed in Section 5. 280 The freshness of the protected options is asserted based on the RCSS. 281 RCSS values are compared as described in section 7.2 of [RPL]. When 282 a parent exposes a new RCSS, the child node SHOULD refrain from using 283 that parent until it has resynchronized all the protected fields to 284 the latest. When it is resynchronized, the child SHOULD refrain from 285 using other parents that expose an older RCSS. 287 A child MUST store the content of all the protected options and keep 288 track of the RCSS of the DIO where each of these option was last seen 289 in a non-abbreviated version. If that RCSS is fresher than the Last 290 Modification RCSS in the abbreviated version of the option then the 291 child is up-to-date for that option. If a protected option elided in 292 a DIO and not abbreviated, and the child has a stored RCSS value for 293 that option that is lower than the RCSS in the DIO, then the child 294 MUST query that option from the parent to ensure that is has the 295 latest. This is done with a DIS message as indicated in Section 7. 297 7. Pulling Options 299 8. Security Considerations 301 TBD 303 9. IANA Considerations 305 A new entries is required for the new option of type "Abbreviated 306 Option", from the "RPL Control Message Options" space defined for 307 [RPL]. 309 +----------+--------------------+-----------+ 310 | Value | Meaning | Reference | 311 +==========+====================+===========+ 312 | TBD IANA | Abbreviated Option | THIS RFC | 313 +----------+--------------------+-----------+ 315 Table 1: New Option Type 317 10. Security Considerations 319 TBD 321 11. Acknowledgments 323 12. Normative References 325 [MOPEX-CAP] 326 Jadhav, R. and P. Thubert, "Mode of Operation extension 327 and Capabilities", Internet-Draft, draft-ietf-roll-mopex- 328 cap-00, 9 August 2019, . 331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 332 Requirement Levels", BCP 14, RFC 2119, 333 DOI 10.17487/RFC2119, March 1997, 334 . 336 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 337 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 338 2014, . 340 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 341 Constrained-Node Networks", RFC 7228, 342 DOI 10.17487/RFC7228, May 2014, 343 . 345 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 346 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 347 May 2017, . 349 [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 350 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 351 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 352 Low-Power and Lossy Networks", RFC 6550, 353 DOI 10.17487/RFC6550, March 2012, 354 . 356 [USE_OF_RPL_INFO] 357 Robles, I., Richardson, M., and P. Thubert, "Using RPL 358 Option Type, Routing Header for Source Routes and IPv6-in- 359 IPv6 encapsulation in the RPL Data Plane", Internet-Draft, 360 draft-ietf-roll-useofrplinfo-31, 7 August 2019, 361 . 364 13. Informative References 366 Authors' Addresses 368 Pascal Thubert (editor) 369 Cisco Systems, Inc 370 Building D, 45 Allee des Ormes - BP1200 371 06254 Mougins - Sophia Antipolis 372 France 374 Phone: +33 497 23 26 34 375 Email: pthubert@cisco.com 377 Dominique Barthel 378 Orange Labs 379 28 chemin du Vieux Chêne 380 38243 Meylan 381 France 383 Email: dominique.barthel@orange.com 385 Rahul Arvind Jadhav 386 Huawei Tech 387 Kundalahalli Village, Whitefield, 388 Bangalore 560037 389 Karnataka 390 India 392 Phone: +91-080-49160700 393 Email: rahul.ietf@gmail.com