idnits 2.17.1 draft-ietf-roll-rpl-observations-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 20, 2019) is 1674 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) == Missing Reference: 'RIOT' is mentioned on line 695, but not defined == Missing Reference: 'CONTIKI' is mentioned on line 695, but not defined == Unused Reference: 'RFC6551' is defined on line 742, but no explicit reference was found in the text == Unused Reference: 'RFC6552' is defined on line 748, but no explicit reference was found in the text == Unused Reference: 'RFC6997' is defined on line 759, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 6997 == Outdated reference: A later version (-18) exists of draft-ietf-roll-aodv-rpl-07 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL R. Jadhav, Ed. 3 Internet-Draft R. Sahoo 4 Intended status: Standards Track Y. Wu 5 Expires: March 23, 2020 Huawei 6 September 20, 2019 8 RPL Observations 9 draft-ietf-roll-rpl-observations-02 11 Abstract 13 This document describes RPL protocol design issues, various 14 observations and possible consequences of the design and 15 implementation choices. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on March 23, 2020. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Requirements Language and Terminology . . . . . . . . . . 3 54 3. DTSN increment in storing MOP . . . . . . . . . . . . . . . . 4 55 3.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 5 56 4. DAO retransmission and use of DAO-ACK in storing MOP . . . . 5 57 4.1. Significance of bidirectional Path establishment 58 indication and relevance of DAO-ACK . . . . . . . . . . . 6 59 4.2. Problems with hop-by-hop DAO-ACK . . . . . . . . . . . . 6 60 4.3. Problems with end-to-end DAO-ACK . . . . . . . . . . . . 6 61 4.4. Deliberations . . . . . . . . . . . . . . . . . . . . . . 6 62 4.5. Implementation Notes . . . . . . . . . . . . . . . . . . 7 63 5. Handling resource unavailability . . . . . . . . . . . . . . 7 64 5.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 7 65 6. Handling aggregated targets . . . . . . . . . . . . . . . . . 7 66 6.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 8 67 7. RPL Transit Information in DAO . . . . . . . . . . . . . . . 8 68 7.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 8 69 8. Upgrades or Extensions to RPL protocol . . . . . . . . . . . 9 70 9. Asymmetric Links and RPL . . . . . . . . . . . . . . . . . . 9 71 10. Adjacencies probing with RPL . . . . . . . . . . . . . . . . 9 72 10.1. Deliberations . . . . . . . . . . . . . . . . . . . . . 10 73 11. Control Options eliding mechanism in RPL . . . . . . . . . . 10 74 12. Managing persistent variables across node reboots . . . . . . 10 75 12.1. Persistent storage and RPL state information . . . . . . 10 76 12.2. Lollipop Counters . . . . . . . . . . . . . . . . . . . 11 77 12.3. RPL State variables . . . . . . . . . . . . . . . . . . 12 78 12.3.1. DODAG Version . . . . . . . . . . . . . . . . . . . 12 79 12.3.2. DTSN field in DIO . . . . . . . . . . . . . . . . . 12 80 12.3.3. PathSequence . . . . . . . . . . . . . . . . . . . . 13 81 12.4. State variables update frequency . . . . . . . . . . . . 13 82 12.5. Deliberations . . . . . . . . . . . . . . . . . . . . . 13 83 12.6. Implementation Notes . . . . . . . . . . . . . . . . . . 14 84 13. Capabilities and its role in RPL . . . . . . . . . . . . . . 14 85 13.1. Handshaking node capabilities . . . . . . . . . . . . . 14 86 13.2. How do Capabilities differ from MOP and Configuration 87 Option? . . . . . . . . . . . . . . . . . . . . . . . . 15 88 13.3. Deliberations . . . . . . . . . . . . . . . . . . . . . 15 89 14. RPL under-specification . . . . . . . . . . . . . . . . . . . 15 90 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 91 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 92 17. Security Considerations . . . . . . . . . . . . . . . . . . . 16 93 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 18.1. Normative References . . . . . . . . . . . . . . . . . . 16 95 18.2. Informative References . . . . . . . . . . . . . . . . . 17 96 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 17 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 99 1. Motivation 101 The primary motivation for this draft is to enlist different issues 102 with RPL operation and invoke a discussion within the working group. 103 This draft by itself is not intended for RFC tracks but as a WG 104 discussion track. This draft may in turn result in other work items 105 taken up by the WG which may improvise on the issues mentioned 106 herewith. 108 2. Introduction 110 RPL [RFC6550] specifies a proactive distance-vector routing scheme 111 designed for LLNs (Low Power and Lossy Networks). RPL enables the 112 network to be formed as a DODAG and supports storing mode and non- 113 storing mode of operations. Non-storing mode allows reduced memory 114 resource usage on the nodes by allowing non-BR nodes to operate 115 without managing a routing table and involves use of source routing 116 by the 6LBR to direct the traffic along a specific path. In storing 117 mode of operation intermediate routers maintain routing tables. 119 This work aims to highlight various issues with RPL which makes it 120 difficult to handle certain scenarios. This work will highlight such 121 issues in context to RPL's mode of operations (storing versus non- 122 storing). There are cases where RPL does not provide clear rules and 123 implementations have to make their choices hindering interoperability 124 and performance. 126 [I-D.clausen-lln-rpl-experiences] provides some interesting points. 127 Some sections in this draft may overlap with some observations in 128 [clausen], but this is been done to further extend some scenarios or 129 observations. It is highly encouraged that readers should also visit 130 [I-D.clausen-lln-rpl-experiences] for other insights. Regardless, 131 this draft is self-sufficient in a way that it does not expect to 132 have read [clausen-draft]. 134 2.1. Requirements Language and Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 NS-MOP = RPL Non-storing Mode of Operation 142 S-MOP = RPL Storing Mode of Operation 144 This document uses terminology described in [RFC6550] and [RFC6775]. 146 3. DTSN increment in storing MOP 148 DTSN increment has major impact on the overall RPL control traffic 149 and on the efficiency of downstream route update. DTSN is sent as 150 part of DIO message and signals the downstream nodes to trigger the 151 target advertisement. The 6LR needs to decide when to update the 152 DTSN and usually it should do it in a conservative way. The DTSN 153 update mechanism determines how soon the downward routes are 154 established along the new path. RPL specifications does not provide 155 any clear mechanism on how the DTSN update should happen in case of 156 storing mode. 158 (6LBR) 159 | 160 | 161 | 162 (A) 163 / \ 164 / \ 165 / \ 166 (B) -(C) 167 | / | 168 | / | 169 | / | 170 (D)- (E) 171 \ ; 172 \ ; 173 \ ; 174 (F) 175 / \ 176 / \ 177 / \ 178 (G) (H) 180 Figure 1: Sample topology 182 Consider example topology shown in Figure 1, assume that node D 183 switches the parent from node B to C. Ideally the downstream nodes D 184 and its sub-childs should send their target advertisement to the new 185 path via node C. To achieve this result in a efficient way is a 186 challenge. Incrementing DTSN is the only way to trigger the DAO on 187 downstream nodes. But this trigger should be sent not only on the 188 first hop but to all the grand-child nodes. Thus DTSN has to be 189 incremented in the complete sub-DODAG rooted at node D thus resulting 190 in DIO/DAO storm along the sub-DODAG. This is specifically a big 191 issue in high density networks where the metric deteoration might 192 happen transiently even though the signal strength is good. 194 The primary implementation issue is whether a child node increment 195 its own DTSN when it receives DTSN update from its parent node? This 196 would result in DAO-updates in the sub-DODAG, thus the cost could be 197 very high. If not incremented it may result in serious loss of 198 connectivity for nodes in the sub-DODAG. 200 3.1. Deliberations 202 (1) In S-MOP, should the child node increment its DTSN on seeing 203 that its preferred parent has updated its DTSN? 205 (2) What are rules for DTSN increment for S-MOP, which multiple 206 implementations can follow thus allowing consistent performance 207 across different implementations? 209 4. DAO retransmission and use of DAO-ACK in storing MOP 211 [RFC6550] has an optional DAO-ACK mechanism using which an upstream 212 parent confirms the reception of a DAO from the downstream child. In 213 case of storing mode, the DAO is addressed to the immediate hop 214 upstream parent resulting in DAO-ACK from the parent. There are two 215 implementations possible: 217 (1) Hop-by-hop ACK: A parent responds with a DAO-ACK immedetialy 218 after receiving the DAO. 220 (2) End-to-End ACK: A node waits for the upstream parent to send 221 DAO-ACK to respond with a DAO-ACK downstream. The upstream 222 parent may do as many attempts to successfully send this DAO 223 upstream. In other words, the parent node accepts the 224 responsibilty of sending the DAO upstream till the point it is 225 ACKed the moment it responds back with its own ACK to the child. 227 1-> 3-> 228 DAO DAO 229 (TgtNode)--------(6LR)-------(root) 230 ACK ACK 231 <-2 <-4 233 Figure 2: Hop-by-hop DAO-ACK 235 1-> 2-> 236 DAO DAO 237 (TgtNode)--------(6LR)-------(root) 238 ACK ACK 239 <-4 <-3 241 Figure 3: End-to-End DAO-ACK 243 4.1. Significance of bidirectional Path establishment indication and 244 relevance of DAO-ACK 246 Lot of application traffic patterns requires that the bidirectional 247 path be established between the target node and the root. A typical 248 example is that COAP request with ACK bit set would require an 249 acknowledgement from the end receiver and thus warrants bidirectional 250 path establishment. It is imperative that the target node first 251 ascertains whether such a bidirectional path is established before 252 initiating such application traffic. In case of non-storing MOP, the 253 DAO-ACK works perfectly fine to ascertain such bidirectional 254 connectivity since it is an indication that the root which usually is 255 the direct destination of the DAO has received the DAO. But in case 256 of storing MOP, things are more complicated since DAO is sent hop-by- 257 hop and the DAO-ACK semantics are not clear enough as per the current 258 specification. As mentioned in above section, an implementation can 259 choose to implement hop-by-hop ACK or end-to-end ACK. 261 4.2. Problems with hop-by-hop DAO-ACK 263 The primary issue with this mode is that target node cannot ascertain 264 bidirection path connectivity on the reception of the DAO-ACK. 266 4.3. Problems with end-to-end DAO-ACK 268 In this case, it is possible for the target node to ascertain if the 269 DAO has indeed reached the root since the reception of DAO-ACK on 270 target node confirms this. However there is extra state information 271 that needs to be maintained on the 6LRs on behalf of all the child 272 nodes. Also it is very difficult for the target node to ascertain a 273 timer value to decide whether the DAO transmission has failed to 274 reach the root. 276 4.4. Deliberations 278 (1) How should an implementation interpret the DAO-ACK semantics? 280 (2) What is the best way for the target node to know that the end to 281 end bidirectional path is successfully installed or updated? In 282 NS-MOP, the DAO-ACK provides a clear way to do this. Can the 283 same be achieved for storing-MOP? 285 (3) What happens if the DAO-ACK with Status!=0 is responded by 286 ancestor node? 288 (4) How to selectively NACK subset of targets in case target 289 containers are aggregated? 291 4.5. Implementation Notes 293 Current RPL open source implementations have both types of DAO-ACK 294 implementations. For e.g. RIOT supports hop-by-hop DAO-ACK. 295 Contiki older versions supported hop-by-hop ACK but the recent 296 version have changed to end-to-end ACK implementation. 298 The sequence of sending no-path DAO and DAO matters when updating the 299 routing adjacencies on a parent switch. If an implementation chooses 300 to send no-path DAO before DAO then it results in significantly more 301 overhead for route invalidation. This is because no-path DAO would 302 traverse all the way up to the BR clearing the routes on the way. In 303 case there is a common ancestor post which the old and new path 304 remains same then it is better to send regular DAO first thus 305 limiting the propagation of subsequent no-path DAO till this common 306 ancestor. 308 5. Handling resource unavailability 310 The nodes in the constrained networks have to maintain various 311 records such as neighbor cache entries and routing entries on behalf 312 of other targets to facilitate packet forwarding. Because of the 313 constrained nature of the devices the memory available may be very 314 limited and thus the path selection algorithm may have to take into 315 consideration such resource constraints as well. 317 RPL currently does not have any mechanism to advertise such resource 318 indicator metrics. The primary tables associated with RPL are 319 routing table and the neighbor cache. Even though neighbor cache is 320 not directly linked with RPL protocol, the maintenance of routing 321 adjacencies results in updates to neigbor cache. 323 5.1. Deliberations 325 Is it possible to know that an upstream parent/ancestor cannot 326 hold enough routing entries and thus this path should not be used? 328 Is it possible to know that an upstream parent cannot hold any 329 more neighbor cache entry and thus this upstream parent should not 330 be used? 332 6. Handling aggregated targets 334 RPL allows and defines specific procedures so as to aid target 335 aggregation in DAO. Having said that, the specification does not 336 mandate use of aggregated targets nor does it make any comment on 337 whether a receiving node needs to handle it. Target aggregation is 338 an useful tool and especially helps with link layer technologies that 339 does not suffer from low MTUs such as PLC. Even if the 340 implementation does not support aggregating targets, it should 341 atleast mandate reception of aggregated targets in DAO. 343 RPL has a mechanism currently to ACK the DAO but it does not have a 344 mechanism to ACK the target container. Thus in case of aggregated 345 targets in the DAO, if the subset of the targets fail then it is 346 impossible for the DAO-ACK to signal this to the DAO sender. 348 6.1. Deliberations 350 Even if the implementation does not support aggregating targets, 351 should it atleast mandate reception and handling of aggregated 352 targets in DAO? 354 There is a good scope for compressing aggregated targets which can 355 significantly reduce the RPL control overhead. 357 How to selectively NACK subset of targets in case target 358 containers are aggregated? 360 The DEFAULT_DAO_DELAY of 1sec does not help much with aggregation. 361 The upstream parent nodes should wait for more time then the child 362 nodes so as to effectively aggregate. Can we have 363 DEFAULT_DAO_DELAY a function of the level/rank the node is at? 365 7. RPL Transit Information in DAO 367 RPL allows associating a target or set of targets with a Transit 368 information container which contains attributes for a path to one or 369 more destinations identified by the set of targets. In case of NS- 370 MOP, the transit Information will contain the all critical Parent 371 Address which allows the common ancestor usually the root to identify 372 the source route header for the target node. The Transit Information 373 also contains other information such as Path Sequence and Path 374 Lifetime which are critical for maintaining route adjacencies. 376 RPL however does not mandate the use of Transit Information container 377 for targets. 379 7.1. Deliberations 381 Is it ok to let implementations decide on the inclusion of Transit 382 Information container? 384 Is it possible to achieve interop without mandating use of Transit 385 Information Container? 386 If the Transit Information container is sent, should the handling 387 of PathSequence be mandated? 389 8. Upgrades or Extensions to RPL protocol 391 RPL extensibility is highly desirable and is controlled by protocol 392 elements within the messaging framework. In the pursuit to keep the 393 signalling overhead less, RPL specification has been restricting in 394 its approach to extend its field ranges, thus in some cases putting 395 extensibility at stakes. Consider for example, the mode of operation 396 bits which is three bits in the RPL specification. These bits are 397 already saturated and it may be difficult to add major upgrades 398 without extending these bits. 400 9. Asymmetric Links and RPL 402 Section 3.1 of [I-D.ietf-intarea-adhoc-wireless-com] explains 403 asymmetric link characteristics and what it takes for a protocol to 404 support asymmetric links. RPL depends on bi-directional links for 405 control even though near-perfect symmetry is not expected. The 406 implication of this is that the upstream and downstream path remains 407 same within a given RPL instance for any pair of nodes. There are 408 following questions sprouting of this design: 410 (1) Is it possible to detect asymmetric links? 412 (2) In the presence of asymmetric links what is the impact on the 413 control overhead and is there a way to possibly mitigate or 414 alleviate any negative impact? 416 [I-D.ietf-roll-aodv-rpl] defines a mechanism to use a pair of 417 instances which are coupled. This allows disjoint upstream and 418 downstream paths between pair of nodes assuming that the link 419 asymmetricity is detected using some outside techniques. The link 420 assumes that the link asymmetricity is already known to the nodes in 421 the form of static configuration. In case of 6tisch networks, the 422 availability of transmission slots information can be used to 423 identify link asymmetricity. The challenge with regards to detecting 424 link asymmetricity arises from scenarios where, for example, the 425 nodes transmit with unequal power levels. 427 10. Adjacencies probing with RPL 429 RPL avoids periodic hello messaging as compared to other distance- 430 vector protocols. It uses trickle timer based mechanism to update 431 configuration parameters. This significantly reduces the RPL control 432 overhead. One of the fallout of this design choice is that, in the 433 absence of regular traffic, the adjacencies could not be tested and 434 repaired if broken. 436 RPL provides a mechanism in the form of unicast DIS to query a 437 particular node for its DIO. A node receiving a unicast DIS MUST 438 respond with a unicast DIO with Configuration Option. This mechanism 439 could as well be made use of for probing adjacencies and certain 440 implementations such as Contiki uses this. The periodicity of the 441 probing is implementation dependent, but the node is expected to 442 invoke probing only when 444 (1) There is no data traffic based on which the links could be 445 tested. 447 (2) There is no L2 feedback. In some case, L2 might provide 448 periodic beacons at link layer and the absence of beacons could 449 be used for link tests. 451 10.1. Deliberations 453 (1) Should the probing scheme be standardized? In some cases using 454 multicast based probing may prove advantageous. 456 (2) In some cases using multicast based probing may prove 457 advantageous. Currently RPL does not have multicast based 458 probing. Multicast DIS/DIO may not be suitable for probing 459 because it could possibly lead to change of states. 461 11. Control Options eliding mechanism in RPL 463 RPL configuration changes are rare and thus various configuration 464 options may not change over a long period of time. RPL provides a 465 way for the configuration options to be elided but there are no clear 466 guidelines on how the eliding should be handled. In the absence of 467 such guidelines, it is possible that certain nodes may end up using 468 stale configuration in the event of transient link failures. 470 12. Managing persistent variables across node reboots 472 12.1. Persistent storage and RPL state information 474 Devices are required to be functional for several years without 475 manual maintanence. Usually battery power consumption is considered 476 key for operating the devices for several (tens of) years. But apart 477 from battery, flash memory endurance may prove to be a lifetime 478 bottleneck in constrained networks. Endurance is defined as maximum 479 number of erase-write cycles that a NAND/NOR cell can undergo before 480 losing its 'gauranteed' write operation. In some cases (cheaper 481 NAND-MLC/TLC), the endurance can be as less as 2K cycles. Thus for 482 e.g. if a given cell is written 5 times a day, that NAND-flash cell 483 assuming an endurance of 10K cycles may last for less than 6 years. 485 Wear leveling is a popular technique used in flash memory to minimize 486 the impact of limited cell endurance. Wear leveling works by 487 arranging data so that erasures and re-writes are distributed evenly 488 across the medium. The memory sectors are over-provisioned so that 489 the writes are distributed across multiple sectors. Many IoT 490 platforms do not necessarily consider this over-provisioning and 491 usually provision the memory only to what is required. Some 492 scenarios such as street-lighting may not require the application 493 layer to write any information to the persistent storage and thus the 494 over-provisioning is often ignored. In such cases if the network 495 stack ends up using persistent storage for maintaining its state 496 information then it becomes counter-productive. 498 In a star topology, the amount of persistent data write done by 499 network protocols is very limited. But ad-hoc networks employing 500 routing protocols such as RPL assume certain state information to be 501 retained across node reboots. In case of IoT devices this storage is 502 mostly floating gate based NAND/NOR based flash memory. The impact 503 of loss of this state information differs depending upon the type 504 (6LN/6LR/6LBR) of the node. 506 12.2. Lollipop Counters 508 [RFC6550] Section 7.2. explains sequence counter operation defining 509 lollipop [Perlman83] style counters. Lollipop counters specify 510 mechanism in which even if the counter value wraps, the algorithm 511 would be able to tell whether the received value is the latest or 512 not. This mechanism also helps in "some cases" to recover from node 513 reboot, but is not foolproof. 515 Consider an e.g. where Node A boots up and initialises the seqcnt to 516 240 as recommended in [RFC6550]. Node A communicates to Node B using 517 this seqcnt and node B uses this seqcnt to determine whether the 518 information node A sent in the packet is latest. Now lets assume, 519 the counter value reaches 250 after some operations on Node A, and 520 node B keeps receiving updated seqcnt from node A. Now consider that 521 node A reboots, and since it reinitializes the seqcnt value to 240 522 and sends the information to node B (who has seqcnt of 250 stored on 523 behalf of node A). As per section 7.2. of [RFC6550], when node B 524 receives this packet it will consider the information to be old 525 (since 240 < 250). 527 +-----+-----+----------+ 528 | A | B | Output | 529 +-----+-----+----------+ 530 | 240 | 240 | AB, new | 536 | 240 | :: | A>B, new | 537 | 240 | 127 | A>B, new | 538 +-----+-----+----------+ 540 Default values for lollipop counters considered from [RFC6550] 541 Section 7.2. 543 Table 1: Example lollipop counter operation 545 Based on this figure, there is dead zone (240 to 0) in which if A 546 operates after reboot then the seqcnt will always be considered 547 smaller. Thus node A needs to maintain the seqcnt in persistent 548 storage and reuse this on reboot. 550 12.3. RPL State variables 552 The impact of loss of RPL state information differs depending upon 553 the node type (6LN/6LR/6LBR). Following sections explain different 554 state variables and the impact in case this information is lost on 555 reboot. 557 12.3.1. DODAG Version 559 The tuple (RPLInstanceID, DODAGID, DODAGVersionNumber) uniquely 560 identifies a DODAG Version. DODAGVersionNumber is incremented 561 everytime a global repair is initiated for the instance (global or 562 local). A node receiving an older DODAGVersionNumber will ignore the 563 DIO message assuming it to be from old DODAG version. Thus a 6LBR 564 node (and 6LR node in case of local DODAG) needs to maintain the 565 DODAGVersionNumber in the persistent storage, so as to be available 566 on reboot. In case the 6LBR could not use the latest 567 DODAGVersionNumber the implication are that it won't be able to 568 recover/re-establish the routing table. 570 12.3.2. DTSN field in DIO 572 DTSN (Destination advertisement Trigger Sequence Number) is a DIO 573 message field used as part of procedure to maintain Downward routes. 574 A 6LBR/6LR node may increment a DTSN in case it requires the 575 downstream nodes to send DAO and thus update downward routes on the 576 6LBR/6LR node. In case of RPL NS-MOP, only the 6LBR maintains the 577 downward routes and thus controls this field update. In case of 578 S-MOP, 6LRs additionally keep downward routes and thus control this 579 field update. 581 In S-MOP, when a 6LR node switches parent it may have to issue a DIO 582 with incremented DTSN to trigger downstream child nodes to send DAO 583 so that the downward routes are established in all parent/ancestor 584 set. Thus in S-MOP, the frequency of DTSN update might be relatively 585 high (given the node density and hysteresis set by objective function 586 to switch parent). 588 12.3.3. PathSequence 590 PathSequence is part of RPL Transit Option, and associated with RPL 591 Target option. A node whichs owns a target address can associate a 592 PathSequence in the DAO message to denote freshness of the target 593 information. This is especially useful when a node uses multiple 594 paths or multiple parents to advertise its reachability. 596 Loss of PathSequence information maintained on the target node can 597 result in routing adjacencies been lost on 6LRs/6LBR/6BBR. 599 12.4. State variables update frequency 601 +--------------------+-------------------+------------------------+ 602 | State variable | Update frequency | Impacts node type | 603 +--------------------+-------------------+------------------------+ 604 | DODAGVersionNumber | Low | 6LBR, 6LR(local DODAG) | 605 | DTSN | High(SM),Low(NSM) | 6LBR, 6LR | 606 | PathSequence | High(SM),Low(NSM) | 6LR, 6LN | 607 +--------------------+-------------------+------------------------+ 609 Low=<5 per day, High=>5 per day; SM=Storing MOP, NSM=Non-Storing MOP 611 Table 2: RPL State variables 613 12.5. Deliberations 615 (1) Is it possible that RPL reduces the use of persistent storage 616 for maintaining state information? 618 (2) In most cases, the node reboots will happen very rarely. Thus 619 doing a persistent storage book-keeping for handling node reboot 620 might not make sense. Is it possible to consider signaling 621 (especially after the node reboots) so as to avoid maintaining 622 this persistent state? Is it possible to use one-time on-reboot 623 signalling to recover some state information? 625 (3) It is necessary that RPL avoids using persistent storage as far 626 as possible. Ideally, extensions to RPL should consider this as 627 a design requirement especially for 6LR and 6LN nodes. DTSN and 628 PathSequence are the primary state variables which have major 629 impact. 631 12.6. Implementation Notes 633 An implementation should use a random DAOSequence number on reboot so 634 as to avoid a risk of reusing the same DAOSequence on reboot. 635 Regardless the sequence counter size of 8bits does not provide much 636 gurantees towards choosing a good random number. A parent node will 637 not respond with a DAO-ACK in case it sees a DAO with the same 638 previous DAOSequence. 640 Write-Before-Use: The state information should be written to the 641 flash before using it in the messaging. If it is done the other way, 642 then the chances are that the node power downs before writing to the 643 persistent storage. 645 13. Capabilities and its role in RPL 647 RPL is a distributed protocol and it requires that the participating 648 nodes agree on basic set of primitives to follow. RPL currently 649 handles this using MOP (Mode of Operation) bits in the DIO. MOP bits 650 inform the nodes the basic mode of operation a node MUST support to 651 join the Instance as a 6LR. The MOP is decided and advertised by the 652 root of the RPL Instance. A node not supporting the given MOP may 653 still join the Instance as a leaf node or 6LN. 655 RPL further uses DIO Configuration Option to advertise the 656 configuration each node needs to use (for e.g., for trickle timer). 658 13.1. Handshaking node capabilities 660 Currently there exist no mechanism to handshake capabilities of the 661 root or 6LRs or 6LNs. If a feature is optional and is supported by 662 6LRs/6LNs then currently there exists no mechanism to signal it. 663 There are several RPL extension proposals which are possibly optional 664 features. Root needs to know if the 6LR/6LN supports these optional 665 features to enable the extension in that path context. Similarly 666 6LRs and 6LNs need to know whether the root supports certain 667 extensions that it can make use of. 669 13.2. How do Capabilities differ from MOP and Configuration Option? 671 Unlike MOP and Configuration Option which are issued by the root of 672 the Instance, Capabilities can be issued by any node. A 6LN/6LR node 673 can advertise its capabilities such that those can be seen by 674 intermediate 6LRs and the root of the Instance. 676 13.3. Deliberations 678 (1) Is it possible for leaf nodes to advertise their set of 679 capabilities, which can be used by root and/or intermediate 6LRs 680 to make run time decisions? 682 (2) How should these capabilities be carried? Should it be carried 683 in DAO/DIO/DAO-ACK? 685 (3) Should the definition of capabilities be same in both directions 686 (upstream/downstream)? 688 14. RPL under-specification 690 (a) PathSequence: Is it mandatory to use PathSequence in DAO Transit 691 container? RPL mentions that a 6LR/6LBR hosting the routing 692 entry on behalf of target node should refresh the lifetime on 693 reception of a new Path Sequence. But RPL does not necessarily 694 mandate use of Path Sequence. Most of the open source 695 implementation [RIOT] [CONTIKI] currently do not issue Path 696 Sequence in the DAO message. 698 (b) Target Container aggregation in DAO: RPL allows multiple targets 699 to be aggregated in a single DAO message and has introduced a 700 notion of DelayDAO using which a 6LR node could delay its DAO to 701 enable such aggregation. But RPL does not have clear text on 702 handling of aggregated DAOs and thus it hinders 703 interoperability. 705 (c) DTSN Update: RPL does not clearly define in which cases DTSN 706 should be updated in case of storing mode of operation. More 707 details for this are presented in Section 3. 709 15. Acknowledgements 711 Many thanks to Pascal Thubert for hallway chats and for helping 712 understand the existing design rationales. Thanks to Michael 713 Richardson for Unstrung RPL implementation rationale. Thanks to ML 714 discussions, in particular (https://www.ietf.org/mail- 715 archive/web/roll/current/msg09443.html). 717 16. IANA Considerations 719 This memo includes no request to IANA. 721 17. Security Considerations 723 This is an information draft and does add any changes to the existing 724 specifications. 726 18. References 728 18.1. Normative References 730 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 731 Requirement Levels", BCP 14, RFC 2119, 732 DOI 10.17487/RFC2119, March 1997, 733 . 735 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 736 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 737 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 738 Low-Power and Lossy Networks", RFC 6550, 739 DOI 10.17487/RFC6550, March 2012, 740 . 742 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 743 and D. Barthel, "Routing Metrics Used for Path Calculation 744 in Low-Power and Lossy Networks", RFC 6551, 745 DOI 10.17487/RFC6551, March 2012, 746 . 748 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 749 Protocol for Low-Power and Lossy Networks (RPL)", 750 RFC 6552, DOI 10.17487/RFC6552, March 2012, 751 . 753 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 754 Bormann, "Neighbor Discovery Optimization for IPv6 over 755 Low-Power Wireless Personal Area Networks (6LoWPANs)", 756 RFC 6775, DOI 10.17487/RFC6775, November 2012, 757 . 759 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 760 J. Martocci, "Reactive Discovery of Point-to-Point Routes 761 in Low-Power and Lossy Networks", RFC 6997, 762 DOI 10.17487/RFC6997, August 2013, 763 . 765 18.2. Informative References 767 [I-D.clausen-lln-rpl-experiences] 768 Clausen, T., Verdiere, A., Yi, J., Herberg, U., and Y. 769 Igarashi, "Observations on RPL: IPv6 Routing Protocol for 770 Low power and Lossy Networks", draft-clausen-lln-rpl- 771 experiences-11 (work in progress), March 2018. 773 [I-D.ietf-intarea-adhoc-wireless-com] 774 Baccelli, E. and C. Perkins, "Multi-hop Ad Hoc Wireless 775 Communication", draft-ietf-intarea-adhoc-wireless-com-02 776 (work in progress), July 2016. 778 [I-D.ietf-roll-aodv-rpl] 779 Anamalamudi, S., Zhang, M., Perkins, C., Anand, S., and B. 780 Liu, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy 781 Networks (LLNs)", draft-ietf-roll-aodv-rpl-07 (work in 782 progress), April 2019. 784 [Perlman83] 785 Perlman, R., "Fault-Tolerant Broadcast of Routing 786 Information", North-Holland Computer Networks, Vol.7, 787 December 1983. 789 Appendix A. Additional Stuff 791 Authors' Addresses 793 Rahul Arvind Jadhav (editor) 794 Huawei 795 Kundalahalli Village, Whitefield, 796 Bangalore, Karnataka 560037 797 India 799 Phone: +91-080-49160700 800 Email: rahul.ietf@gmail.com 802 Rabi Narayan Sahoo 803 Huawei 804 Kundalahalli Village, Whitefield, 805 Bangalore, Karnataka 560037 806 India 808 Phone: +91-080-49160700 809 Email: rabinarayans@huawei.com 810 Yuefeng Wu 811 Huawei 812 No.101, Software Avenue, Yuhuatai District, 813 Nanjing, Jiangsu 210012 814 China 816 Phone: +86-15251896569 817 Email: wuyuefeng@huawei.com