idnits 2.17.1 draft-ietf-roll-rpl-observations-01.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 25, 2019) is 1857 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 621, but not defined == Missing Reference: 'CONTIKI' is mentioned on line 621, but not defined == Unused Reference: 'RFC6551' is defined on line 668, but no explicit reference was found in the text == Unused Reference: 'RFC6552' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'RFC6997' is defined on line 685, 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-06 Summary: 1 error (**), 0 flaws (~~), 8 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: September 26, 2019 D. Zhang 6 Huawei 7 March 25, 2019 9 RPL Observations 10 draft-ietf-roll-rpl-observations-01 12 Abstract 14 This document describes RPL protocol design issues, various 15 observations and possible consequences of the design and 16 implementation choices. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 26, 2019. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Requirements Language and Terminology . . . . . . . . . . 3 55 3. DTSN increment in storing MOP . . . . . . . . . . . . . . . . 3 56 3.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 5 57 4. DAO retransmission and use of DAO-ACK in storing MOP . . . . 5 58 4.1. Significance of bidirectional Path establishment 59 indication and relevance of DAO-ACK . . . . . . . . . . . 6 60 4.2. Problems with hop-by-hop DAO-ACK . . . . . . . . . . . . 6 61 4.3. Problems with end-to-end DAO-ACK . . . . . . . . . . . . 6 62 4.4. Deliberations . . . . . . . . . . . . . . . . . . . . . . 6 63 4.5. Implementation Notes . . . . . . . . . . . . . . . . . . 7 64 5. Handling resource unavailability . . . . . . . . . . . . . . 7 65 5.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 7 66 6. Handling aggregated targets . . . . . . . . . . . . . . . . . 7 67 6.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 8 68 7. RPL Transit Information in DAO . . . . . . . . . . . . . . . 8 69 7.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 8 70 8. Upgrades or Extensions to RPL protocol . . . . . . . . . . . 9 71 8.1. Handshaking optional node capabilities . . . . . . . . . 9 72 9. Asymmetric Links and RPL . . . . . . . . . . . . . . . . . . 9 73 10. Managing persistent variables across node reboots . . . . . . 10 74 10.1. Persistent storage and RPL state information . . . . . . 10 75 10.2. Lollipop Counters . . . . . . . . . . . . . . . . . . . 11 76 10.3. RPL State variables . . . . . . . . . . . . . . . . . . 12 77 10.3.1. DODAG Version . . . . . . . . . . . . . . . . . . . 12 78 10.3.2. DTSN field in DIO . . . . . . . . . . . . . . . . . 12 79 10.3.3. PathSequence . . . . . . . . . . . . . . . . . . . . 12 80 10.4. State variables update frequency . . . . . . . . . . . . 13 81 10.5. Deliberations . . . . . . . . . . . . . . . . . . . . . 13 82 10.6. Implementation Notes . . . . . . . . . . . . . . . . . . 13 83 11. RPL under-specification . . . . . . . . . . . . . . . . . . . 14 84 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 85 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 86 14. Security Considerations . . . . . . . . . . . . . . . . . . . 14 87 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 15.1. Normative References . . . . . . . . . . . . . . . . . . 14 89 15.2. Informative References . . . . . . . . . . . . . . . . . 15 90 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 16 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Motivation 95 The primary motivation for this draft is to enlist different issues 96 with RPL operation and invoke a discussion within the working group. 97 This draft by itself is not intended for RFC tracks but as a WG 98 discussion track. This draft may in turn result in other work items 99 taken up by the WG which may improvise on the issues mentioned 100 herewith. 102 2. Introduction 104 RPL [RFC6550] specifies a proactive distance-vector routing scheme 105 designed for LLNs (Low Power and Lossy Networks). RPL enables the 106 network to be formed as a DODAG and supports storing mode and non- 107 storing mode of operations. Non-storing mode allows reduced memory 108 resource usage on the nodes by allowing non-BR nodes to operate 109 without managing a routing table and involves use of source routing 110 by the 6LBR to direct the traffic along a specific path. In storing 111 mode of operation intermediate routers maintain routing tables. 113 This work aims to highlight various issues with RPL which makes it 114 difficult to handle certain scenarios. This work will highlight such 115 issues in context to RPL's mode of operations (storing versus non- 116 storing). There are cases where RPL does not provide clear rules and 117 implementations have to make their choices hindering interoperability 118 and performance. 120 [I-D.clausen-lln-rpl-experiences] provides some interesting points. 121 Some sections in this draft may overlap with some observations in 122 [clausen], but this is been done to further extend some scenarios or 123 observations. It is highly encouraged that readers should also visit 124 [I-D.clausen-lln-rpl-experiences] for other insights. Regardless, 125 this draft is self-sufficient in a way that it does not expect to 126 have read [clausen-draft]. 128 2.1. Requirements Language and Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119 [RFC2119]. 134 NS-MOP = RPL Non-storing Mode of Operation 136 S-MOP = RPL Storing Mode of Operation 138 This document uses terminology described in [RFC6550] and [RFC6775]. 140 3. DTSN increment in storing MOP 142 DTSN increment has major impact on the overall RPL control traffic 143 and on the efficiency of downstream route update. DTSN is sent as 144 part of DIO message and signals the downstream nodes to trigger the 145 target advertisement. The 6LR needs to decide when to update the 146 DTSN and usually it should do it in a conservative way. The DTSN 147 update mechanism determines how soon the downward routes are 148 established along the new path. RPL specifications does not provide 149 any clear mechanism on how the DTSN update should happen in case of 150 storing mode. 152 (6LBR) 153 | 154 | 155 | 156 (A) 157 / \ 158 / \ 159 / \ 160 (B) -(C) 161 | / | 162 | / | 163 | / | 164 (D)- (E) 165 \ ; 166 \ ; 167 \ ; 168 (F) 169 / \ 170 / \ 171 / \ 172 (G) (H) 174 Figure 1: Sample topology 176 Consider example topology shown in Figure 1, assume that node D 177 switches the parent from node B to C. Ideally the downstream nodes D 178 and its sub-childs should send their target advertisement to the new 179 path via node C. To achieve this result in a efficient way is a 180 challenge. Incrementing DTSN is the only way to trigger the DAO on 181 downstream nodes. But this trigger should be sent not only on the 182 first hop but to all the grand-child nodes. Thus DTSN has to be 183 incremented in the complete sub-DODAG rooted at node D thus resulting 184 in DIO/DAO storm along the sub-DODAG. This is specifically a big 185 issue in high density networks where the metric deteoration might 186 happen transiently even though the signal strength is good. 188 The primary implementation issue is whether a child node increment 189 its own DTSN when it receives DTSN update from its parent node? This 190 would result in DAO-updates in the sub-DODAG, thus the cost could be 191 very high. If not incremented it may result in serious loss of 192 connectivity for nodes in the sub-DODAG. 194 3.1. Deliberations 196 (1) In S-MOP, should the child nodes increment its DIO on seeing 197 that its preferred parent has updated its DTSN? 199 (2) What are rules for DTSN increment for storing MOP, which 200 multiple implementations can follow thus allowing consistent 201 performance across different implementations? 203 4. DAO retransmission and use of DAO-ACK in storing MOP 205 [RFC6550] has an optional DAO-ACK mechanism using which an upstream 206 parent confirms the reception of a DAO from the downstream child. In 207 case of storing mode, the DAO is addressed to the immediate hop 208 upstream parent resulting in DAO-ACK from the parent. There are two 209 implementations possible: 211 (1) Hop-by-hop ACK: A parent responds with a DAO-ACK immedetialy 212 after receiving the DAO. 214 (2) End-to-End ACK: A node waits for the upstream parent to send 215 DAO-ACK to respond with a DAO-ACK downstream. The upstream 216 parent may do as many attempts to successfully send this DAO 217 upstream. In other words, the parent node accepts the 218 responsibilty of sending the DAO upstream till the point it is 219 ACKed the moment it responds back with its own ACK to the child. 221 1-> 3-> 222 DAO DAO 223 (TgtNode)--------(6LR)-------(root) 224 ACK ACK 225 <-2 <-4 227 Figure 2: Hop-by-hop DAO-ACK 229 1-> 2-> 230 DAO DAO 231 (TgtNode)--------(6LR)-------(root) 232 ACK ACK 233 <-4 <-3 235 Figure 3: End-to-End DAO-ACK 237 4.1. Significance of bidirectional Path establishment indication and 238 relevance of DAO-ACK 240 Lot of application traffic patterns requires that the bidirectional 241 path be established between the target node and the root. A typical 242 example is that COAP request with ACK bit set would require an 243 acknowledgement from the end receiver and thus warrants bidirectional 244 path establishment. It is imperative that the target node first 245 ascertains whether such a bidirectional path is established before 246 initiating such application traffic. In case of non-storing MOP, the 247 DAO-ACK works perfectly fine to ascertain such bidirectional 248 connectivity since it is an indication that the root which usually is 249 the direct destination of the DAO has received the DAO. But in case 250 of storing MOP, things are more complicated since DAO is sent hop-by- 251 hop and the DAO-ACK semantics are not clear enough as per the current 252 specification. As mentioned in above section, an implementation can 253 choose to implement hop-by-hop ACK or end-to-end ACK. 255 4.2. Problems with hop-by-hop DAO-ACK 257 The primary issue with this mode is that target node cannot ascertain 258 bidirection path connectivity on the reception of the DAO-ACK. 260 4.3. Problems with end-to-end DAO-ACK 262 In this case, it is possible for the target node to ascertain if the 263 DAO has indeed reached the root since the reception of DAO-ACK on 264 target node confirms this. However there is extra state information 265 that needs to be maintained on the 6LRs on behalf of all the child 266 nodes. Also it is very difficult for the target node to ascertain a 267 timer value to decide whether the DAO transmission has failed to 268 reach the root. 270 4.4. Deliberations 272 (1) How should an implementation interpret the DAO-ACK semantics? 274 (2) What is the best way for the target node to know that the end to 275 end bidirectional path is successfully installed or updated? In 276 NS-MOP, the DAO-ACK provides a clear way to do this. Can the 277 same be achieved for storing-MOP? 279 (3) What happens if the DAO-ACK with Status!=0 is responded by 280 ancestor node? 282 (4) How to selectively NACK subset of targets in case target 283 containers are aggregated? 285 4.5. Implementation Notes 287 Current RPL open source implementations have both types of DAO-ACK 288 implementations. For e.g. RIOT supports hop-by-hop DAO-ACK. 289 Contiki older versions supported hop-by-hop ACK but the recent 290 version have changed to end-to-end ACK implementation. 292 The sequence of sending no-path DAO and DAO matters when updating the 293 routing adjacencies on a parent switch. If an implementation chooses 294 to send no-path DAO before DAO then it results in significantly more 295 overhead for route invalidation. This is because no-path DAO would 296 traverse all the way up to the BR clearing the routes on the way. In 297 case there is a common ancestor post which the old and new path 298 remains same then it is better to send regular DAO first thus 299 limiting the propagation of subsequent no-path DAO till this common 300 ancestor. 302 5. Handling resource unavailability 304 The nodes in the constrained networks have to maintain various 305 records such as neighbor cache entries and routing entries on behalf 306 of other targets to facilitate packet forwarding. Because of the 307 constrained nature of the devices the memory available may be very 308 limited and thus the path selection algorithm may have to take into 309 consideration such resource constraints as well. 311 RPL currently does not have any mechanism to advertise such resource 312 indicator metrics. The primary tables associated with RPL are 313 routing table and the neighbor cache. Even though neighbor cache is 314 not directly linked with RPL protocol, the maintenance of routing 315 adjacencies results in updates to neigbor cache. 317 5.1. Deliberations 319 Is it possible to know that an upstream parent/ancestor cannot 320 hold enough routing entries and thus this path should not be used? 322 Is it possible to know that an upstream parent cannot hold any 323 more neighbor cache entry and thus this upstream parent should not 324 be used? 326 6. Handling aggregated targets 328 RPL allows and defines specific procedures so as to aid target 329 aggregation in DAO. Having said that, the specification does not 330 mandate use of aggregated targets nor does it make any comment on 331 whether a receiving node needs to handle it. Target aggregation is 332 an useful tool and especially helps with link layer technologies that 333 does not suffer from low MTUs such as PLC. Even if the 334 implementation does not support aggregating targets, it should 335 atleast mandate reception of aggregated targets in DAO. 337 RPL has a mechanism currently to ACK the DAO but it does not have a 338 mechanism to ACK the target container. Thus in case of aggregated 339 targets in the DAO, if the subset of the targets fail then it is 340 impossible for the DAO-ACK to signal this to the DAO sender. 342 6.1. Deliberations 344 Even if the implementation does not support aggregating targets, 345 should it atleast mandate reception and handling of aggregated 346 targets in DAO? 348 There is a good scope for compressing aggregated targets which can 349 significantly reduce the RPL control overhead. 351 How to selectively NACK subset of targets in case target 352 containers are aggregated? 354 The DEFAULT_DAO_DELAY of 1sec does not help much with aggregation. 355 The upstream parent nodes should wait for more time then the child 356 nodes so as to effectively aggregate. Can we have 357 DEFAULT_DAO_DELAY a function of the level/rank the node is at? 359 7. RPL Transit Information in DAO 361 RPL allows associating a target or set of targets with a Transit 362 information container which contains attributes for a path to one or 363 more destinations identified by the set of targets. In case of NS- 364 MOP, the transit Information will contain the all critical Parent 365 Address which allows the common ancestor usually the root to identify 366 the source route header for the target node. The Transit Information 367 also contains other information such as Path Sequence and Path 368 Lifetime which are critical for maintaining route adjacencies. 370 RPL however does not mandate the use of Transit Information container 371 for targets. 373 7.1. Deliberations 375 Is it ok to let implementations decide on the inclusion of Transit 376 Information container? 378 Is it possible to achieve interop without mandating use of Transit 379 Information Container? 380 If the Transit Information container is sent, should the handling 381 of PathSequence be mandated? 383 The DEFAULT_DAO_DELAY of 1sec does not help much with aggregation. 384 The upstream parent nodes should wait for more time then the child 385 nodes so as to effectively aggregate. Can we have 386 DEFAULT_DAO_DELAY a function of the level/rank the node is at? 388 8. Upgrades or Extensions to RPL protocol 390 RPL extensibility is highly desirable and is controlled by protocol 391 elements within the messaging framework. In the pursuit to keep the 392 signalling overhead less, RPL specification has been restricting in 393 its approach to extend its field ranges, thus in some cases putting 394 extensibility at stakes. Consider for example, the mode of operation 395 bits which is three bits in the RPL specification. These bits are 396 already saturated and it may be difficult to add major upgrades 397 without extending these bits. 399 8.1. Handshaking optional node capabilities 401 Currently there exist no mechanism to handshake optional capabilities 402 of the border router or 6LRs or 6LNs. Current MOP deals with 403 signalling mandatory set of primitives that needs to be supported by 404 all the 6LRs in the network. If a feature is optional and is 405 supported by 6LRs/6LNs then currently there exists no mechanism to 406 signal it. There are several RPL extension proposals which are 407 possibly optional features. Border router needs to know if the 408 6LR/6LN supports these optional features to enable the extension in 409 that path context. Similarly 6LRs and 6LNs need to know whether the 410 border router supports certain extensions that it can make use of. 412 9. Asymmetric Links and RPL 414 Section 3.1 of [I-D.ietf-intarea-adhoc-wireless-com] explains 415 asymmetric link characteristics and what it takes for a protocol to 416 support asymmetric links. RPL depends on bi-directional links for 417 control even though near-perfect symmetry is not expected. The 418 implication of this is that the upstream and downstream path remains 419 same within a given RPL instance for any pair of nodes. There are 420 following questions sprouting of this design: 422 (1) Is it possible to detect asymmetric links? 424 (2) In the presence of asymmetric links what is the impact on the 425 control overhead and is there a way to possibly mitigate or 426 alleviate any negative impact? 428 [I-D.ietf-roll-aodv-rpl] defines a mechanism to use a pair of 429 instances which are coupled. This allows disjoint upstream and 430 downstream paths between pair of nodes assuming that the link 431 asymmetricity is detected using some outside techniques. The link 432 assumes that the link asymmetricity is already known to the nodes in 433 the form of static configuration. In case of 6tisch networks, the 434 availability of transmission slots information can be used to 435 identify link asymmetricity. The challenge with regards to detecting 436 link asymmetricity arises from scenarios where, for example, the 437 nodes transmit with unequal power levels. 439 10. Managing persistent variables across node reboots 441 10.1. Persistent storage and RPL state information 443 Devices are required to be functional for several years without 444 manual maintanence. Usually battery power consumption is considered 445 key for operating the devices for several (tens of) years. But apart 446 from battery, flash memory endurance may prove to be a lifetime 447 bottleneck in constrained networks. Endurance is defined as maximum 448 number of erase-write cycles that a NAND/NOR cell can undergo before 449 losing its 'gauranteed' write operation. In some cases (cheaper 450 NAND-MLC/TLC), the endurance can be as less as 2K cycles. Thus for 451 e.g. if a given cell is written 5 times a day, that NAND-flash cell 452 assuming an endurance of 10K cycles may last for less than 6 years. 454 Wear leveling is a popular technique used in flash memory to minimize 455 the impact of limited cell endurance. Wear leveling works by 456 arranging data so that erasures and re-writes are distributed evenly 457 across the medium. The memory sectors are over-provisioned so that 458 the writes are distributed across multiple sectors. Many IoT 459 platforms do not necessarily consider this over-provisioning and 460 usually provision the memory only to what is required. Some 461 scenarios such as street-lighting may not require the application 462 layer to write any information to the persistent storage and thus the 463 over-provisioning is often ignored. In such cases if the network 464 stack ends up using persistent storage for maintaining its state 465 information then it becomes counter-productive. 467 In a star topology, the amount of persistent data write done by 468 network protocols is very limited. But ad-hoc networks employing 469 routing protocols such as RPL assume certain state information to be 470 retained across node reboots. In case of IoT devices this storage is 471 mostly floating gate based NAND/NOR based flash memory. The impact 472 of loss of this state information differs depending upon the type 473 (6LN/6LR/6LBR) of the node. 475 10.2. Lollipop Counters 477 [RFC6550] Section 7.2. explains sequence counter operation defining 478 lollipop [Perlman83] style counters. Lollipop counters specify 479 mechanism in which even if the counter value wraps, the algorithm 480 would be able to tell whether the received value is the latest or 481 not. This mechanism also helps in "some cases" to recover from node 482 reboot, but is not foolproof. 484 Consider an e.g. where Node A boots up and initialises the seqcnt to 485 240 as recommended in [RFC6550]. Node A communicates to Node B using 486 this seqcnt and node B uses this seqcnt to determine whether the 487 information node A sent in the packet is latest. Now lets assume, 488 the counter value reaches 250 after some operations on Node A, and 489 node B keeps receiving updated seqcnt from node A. Now consider that 490 node A reboots, and since it reinitializes the seqcnt value to 240 491 and sends the information to node B (who has seqcnt of 250 stored on 492 behalf of node A). As per section 7.2. of [RFC6550], when node B 493 receives this packet it will consider the information to be old 494 (since 240 < 250). 496 +-----+-----+----------+ 497 | A | B | Output | 498 +-----+-----+----------+ 499 | 240 | 240 | AB, new | 505 | 240 | :: | A>B, new | 506 | 240 | 127 | A>B, new | 507 +-----+-----+----------+ 509 Default values for lollipop counters considered from [RFC6550] 510 Section 7.2. 512 Table 1: Example lollipop counter operation 514 Based on this figure, there is dead zone (240 to 0) in which if A 515 operates after reboot then the seqcnt will always be considered 516 smaller. Thus node A needs to maintain the seqcnt in persistent 517 storage and reuse this on reboot. 519 10.3. RPL State variables 521 The impact of loss of RPL state information differs depending upon 522 the node type (6LN/6LR/6LBR). Following sections explain different 523 state variables and the impact in case this information is lost on 524 reboot. 526 10.3.1. DODAG Version 528 The tuple (RPLInstanceID, DODAGID, DODAGVersionNumber) uniquely 529 identifies a DODAG Version. DODAGVersionNumber is incremented 530 everytime a global repair is initiated for the instance (global or 531 local). A node receiving an older DODAGVersionNumber will ignore the 532 DIO message assuming it to be from old DODAG version. Thus a 6LBR 533 node (and 6LR node in case of local DODAG) needs to maintain the 534 DODAGVersionNumber in the persistent storage, so as to be available 535 on reboot. In case the 6LBR could not use the latest 536 DODAGVersionNumber the implication are that it won't be able to 537 recover/re-establish the routing table. 539 10.3.2. DTSN field in DIO 541 DTSN (Destination advertisement Trigger Sequence Number) is a DIO 542 message field used as part of procedure to maintain Downward routes. 543 A 6LBR/6LR node may increment a DTSN in case it requires the 544 downstream nodes to send DAO and thus update downward routes on the 545 6LBR/6LR node. In case of RPL NS-MOP, only the 6LBR maintains the 546 downward routes and thus controls this field update. In case of 547 S-MOP, 6LRs additionally keep downward routes and thus control this 548 field update. 550 In S-MOP, when a 6LR node switches parent it may have to issue a DIO 551 with incremented DTSN to trigger downstream child nodes to send DAO 552 so that the downward routes are established in all parent/ancestor 553 set. Thus in S-MOP, the frequency of DTSN update might be relatively 554 high (given the node density and hysteresis set by objective function 555 to switch parent). 557 10.3.3. PathSequence 559 PathSequence is part of RPL Transit Option, and associated with RPL 560 Target option. A node whichs owns a target address can associate a 561 PathSequence in the DAO message to denote freshness of the target 562 information. This is especially useful when a node uses multiple 563 paths or multiple parents to advertise its reachability. 565 Loss of PathSequence information maintained on the target node can 566 result in routing adjacencies been lost on 6LRs/6LBR/6BBR. 568 10.4. State variables update frequency 570 +--------------------+-------------------+------------------------+ 571 | State variable | Update frequency | Impacts node type | 572 +--------------------+-------------------+------------------------+ 573 | DODAGVersionNumber | Low | 6LBR, 6LR(local DODAG) | 574 | DTSN | High(SM),Low(NSM) | 6LBR, 6LR | 575 | PathSequence | High(SM),Low(NSM) | 6LR, 6LN | 576 +--------------------+-------------------+------------------------+ 578 Low=<5 per day, High=>5 per day; SM=Storing MOP, NSM=Non-Storing MOP 580 Table 2: RPL State variables 582 10.5. Deliberations 584 (1) Is it possible that RPL reduces the use of persistent storage 585 for maintaining state information? 587 (2) In most cases, the node reboots will happen very rarely. Thus 588 doing a persistent storage book-keeping for handling node reboot 589 might not make sense. Is it possible to consider signaling 590 (especially after the node reboots) so as to avoid maintaining 591 this persistent state? Is it possible to use one-time on-reboot 592 signalling to recover some state information? 594 (3) It is necessary that RPL avoids using persistent storage as far 595 as possible. Ideally, extensions to RPL should consider this as 596 a design requirement especially for 6LR and 6LN nodes. DTSN and 597 PathSequence are the primary state variables which have major 598 impact. 600 10.6. Implementation Notes 602 An implementation should use a random DAOSequence number on reboot so 603 as to avoid a risk of reusing the same DAOSequence on reboot. 604 Regardless the sequence counter size of 8bits does not provide much 605 gurantees towards choosing a good random number. A parent node will 606 not respond with a DAO-ACK in case it sees a DAO with the same 607 previous DAOSequence. 609 Write-Before-Use: The state information should be written to the 610 flash before using it in the messaging. If it is done the other way, 611 then the chances are that the node power downs before writing to the 612 persistent storage. 614 11. RPL under-specification 616 (a) PathSequence: Is it mandatory to use PathSequence in DAO Transit 617 container? RPL mentions that a 6LR/6LBR hosting the routing 618 entry on behalf of target node should refresh the lifetime on 619 reception of a new Path Sequence. But RPL does not necessarily 620 mandate use of Path Sequence. Most of the open source 621 implementation [RIOT] [CONTIKI] currently do not issue Path 622 Sequence in the DAO message. 624 (b) Target Container aggregation in DAO: RPL allows multiple targets 625 to be aggregated in a single DAO message and has introduced a 626 notion of DelayDAO using which a 6LR node could delay its DAO to 627 enable such aggregation. But RPL does not have clear text on 628 handling of aggregated DAOs and thus it hinders 629 interoperability. 631 (c) DTSN Update: RPL does not clearly define in which cases DTSN 632 should be updated in case of storing mode of operation. More 633 details for this are presented in Section 3. 635 12. Acknowledgements 637 Many thanks to Pascal Thubert for hallway chats and for helping 638 understand the existing design rationales. Thanks to Michael 639 Richardson for Unstrung RPL implementation rationale. Thanks to ML 640 discussions, in particular (https://www.ietf.org/mail- 641 archive/web/roll/current/msg09443.html). 643 13. IANA Considerations 645 This memo includes no request to IANA. 647 14. Security Considerations 649 This is an information draft and does add any changes to the existing 650 specifications. 652 15. References 654 15.1. Normative References 656 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 657 Requirement Levels", BCP 14, RFC 2119, 658 DOI 10.17487/RFC2119, March 1997, 659 . 661 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 662 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 663 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 664 Low-Power and Lossy Networks", RFC 6550, 665 DOI 10.17487/RFC6550, March 2012, 666 . 668 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 669 and D. Barthel, "Routing Metrics Used for Path Calculation 670 in Low-Power and Lossy Networks", RFC 6551, 671 DOI 10.17487/RFC6551, March 2012, 672 . 674 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 675 Protocol for Low-Power and Lossy Networks (RPL)", 676 RFC 6552, DOI 10.17487/RFC6552, March 2012, 677 . 679 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 680 Bormann, "Neighbor Discovery Optimization for IPv6 over 681 Low-Power Wireless Personal Area Networks (6LoWPANs)", 682 RFC 6775, DOI 10.17487/RFC6775, November 2012, 683 . 685 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 686 J. Martocci, "Reactive Discovery of Point-to-Point Routes 687 in Low-Power and Lossy Networks", RFC 6997, 688 DOI 10.17487/RFC6997, August 2013, 689 . 691 15.2. Informative References 693 [I-D.clausen-lln-rpl-experiences] 694 Clausen, T., Verdiere, A., Yi, J., Herberg, U., and Y. 695 Igarashi, "Observations on RPL: IPv6 Routing Protocol for 696 Low power and Lossy Networks", draft-clausen-lln-rpl- 697 experiences-11 (work in progress), March 2018. 699 [I-D.ietf-intarea-adhoc-wireless-com] 700 Baccelli, E. and C. Perkins, "Multi-hop Ad Hoc Wireless 701 Communication", draft-ietf-intarea-adhoc-wireless-com-02 702 (work in progress), July 2016. 704 [I-D.ietf-roll-aodv-rpl] 705 Anamalamudi, S., Zhang, M., Perkins, C., Anand, S., and B. 706 Liu, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy 707 Networks (LLNs)", draft-ietf-roll-aodv-rpl-06 (work in 708 progress), March 2019. 710 [Perlman83] 711 Perlman, R., "Fault-Tolerant Broadcast of Routing 712 Information", North-Holland Computer Networks, Vol.7, 713 December 1983. 715 Appendix A. Additional Stuff 717 Authors' Addresses 719 Rahul Arvind Jadhav (editor) 720 Huawei 721 Kundalahalli Village, Whitefield, 722 Bangalore, Karnataka 560037 723 India 725 Phone: +91-080-49160700 726 Email: rahul.ietf@gmail.com 728 Rabi Narayan Sahoo 729 Huawei 730 Kundalahalli Village, Whitefield, 731 Bangalore, Karnataka 560037 732 India 734 Phone: +91-080-49160700 735 Email: rabinarayans@huawei.com 737 Yuefeng Wu 738 Huawei 739 No.101, Software Avenue, Yuhuatai District, 740 Nanjing, Jiangsu 210012 741 China 743 Phone: +86-15251896569 744 Email: wuyuefeng@huawei.com 746 Dacheng Zhang 747 Huawei 748 W Chang'an Ave 749 Beijing, Hebei 210012 750 China 752 Phone: +86-13621142434 753 Email: dacheng.zhang@huawei.com