idnits 2.17.1 draft-rahul-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 24, 2018) is 2070 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 566, but not defined == Missing Reference: 'CONTIKI' is mentioned on line 566, but not defined == Unused Reference: 'RFC6551' is defined on line 613, but no explicit reference was found in the text == Unused Reference: 'RFC6552' is defined on line 619, but no explicit reference was found in the text == Unused Reference: 'RFC6997' is defined on line 630, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 6997 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: February 25, 2019 Huawei 6 August 24, 2018 8 RPL Observations 9 draft-rahul-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 February 25, 2019. 34 Copyright Notice 36 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Requirements Language and Terminology . . . . . . . . . . 3 54 3. DTSN increment in storing MOP . . . . . . . . . . . . . . . . 3 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. Managing persistent variables across node reboots . . . . . . 9 70 8.1. Persistent storage and RPL state information . . . . . . 9 71 8.2. Lollipop Counters . . . . . . . . . . . . . . . . . . . . 10 72 8.3. RPL State variables . . . . . . . . . . . . . . . . . . . 11 73 8.3.1. DODAG Version . . . . . . . . . . . . . . . . . . . . 11 74 8.3.2. DTSN field in DIO . . . . . . . . . . . . . . . . . . 11 75 8.3.3. PathSequence . . . . . . . . . . . . . . . . . . . . 11 76 8.4. State variables update frequency . . . . . . . . . . . . 12 77 8.5. Deliberations . . . . . . . . . . . . . . . . . . . . . . 12 78 8.6. Implementation Notes . . . . . . . . . . . . . . . . . . 12 79 9. RPL under-specification . . . . . . . . . . . . . . . . . . . 13 80 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 81 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 82 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 13.1. Normative References . . . . . . . . . . . . . . . . . . 13 85 13.2. Informative References . . . . . . . . . . . . . . . . . 14 86 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 14 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 89 1. Motivation 91 The primary motivation for this draft is to enlist different issues 92 with RPL operation and invoke a discussion within the working group. 93 This draft by itself is not intended for RFC tracks but as a WG 94 discussion track. This draft may in turn result in other work items 95 taken up by the WG which may improvise on the issues mentioned 96 herewith. 98 2. Introduction 100 RPL [RFC6550] specifies a proactive distance-vector routing scheme 101 designed for LLNs (Low Power and Lossy Networks). RPL enables the 102 network to be formed as a DODAG and supports storing mode and non- 103 storing mode of operations. Non-storing mode allows reduced memory 104 resource usage on the nodes by allowing non-BR nodes to operate 105 without managing a routing table and involves use of source routing 106 by the 6LBR to direct the traffic along a specific path. In storing 107 mode of operation intermediate routers maintain routing tables. 109 This work aims to highlight various issues with RPL which makes it 110 difficult to handle certain scenarios. This work will highlight such 111 issues in context to RPL's mode of operations (storing versus non- 112 storing). There are cases where RPL does not provide clear rules and 113 implementations have to make their choices hindering interoperability 114 and performance. 116 [I-D.clausen-lln-rpl-experiences] provides some interesting points. 117 Some sections in this draft may overlap with some observations in 118 [clausen], but this is been done to further extend some scenarios or 119 observations. It is highly encouraged that readers should also visit 120 [I-D.clausen-lln-rpl-experiences] for other insights. Regardless, 121 this draft is self-sufficient in a way that it does not expect to 122 have read [clausen-draft]. 124 2.1. Requirements Language and Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 NS-MOP = RPL Non-storing Mode of Operation 132 S-MOP = RPL Storing Mode of Operation 134 This document uses terminology described in [RFC6550] and [RFC6775]. 136 3. DTSN increment in storing MOP 138 DTSN increment has major impact on the overall RPL control traffic 139 and on the efficiency of downstream route update. DTSN is sent as 140 part of DIO message and signals the downstream nodes to trigger the 141 target advertisement. The 6LR needs to decide when to update the 142 DTSN and usually it should do it in a conservative way. The DTSN 143 update mechanism determines how soon the downward routes are 144 established along the new path. RPL specifications does not provide 145 any clear mechanism on how the DTSN update should happen in case of 146 storing mode. 148 (6LBR) 149 | 150 | 151 | 152 (A) 153 / \ 154 / \ 155 / \ 156 (B) -(C) 157 | / | 158 | / | 159 | / | 160 (D)- (E) 161 \ ; 162 \ ; 163 \ ; 164 (F) 165 / \ 166 / \ 167 / \ 168 (G) (H) 170 Figure 1: Sample topology 172 Consider example topology shown in Figure 1, assume that node D 173 switches the parent from node B to C. Ideally the downstream nodes D 174 and its sub-childs should send their target advertisement to the new 175 path via node C. To achieve this result in a efficient way is a 176 challenge. Incrementing DTSN is the only way to trigger the DAO on 177 downstream nodes. But this trigger should be sent not only on the 178 first hop but to all the grand-child nodes. Thus DTSN has to be 179 incremented in the complete sub-DODAG rooted at node D thus resulting 180 in DIO/DAO storm along the sub-DODAG. This is specifically a big 181 issue in high density networks where the metric deteoration might 182 happen transiently even though the signal strength is good. 184 The primary implementation issue is whether a child node increment 185 its own DTSN when it receives DTSN update from its parent node? This 186 would result in DAO-updates in the sub-DODAG, thus the cost could be 187 very high. If not incremented it may result in serious loss of 188 connectivity for nodes in the sub-DODAG. 190 3.1. Deliberations 192 (1) In S-MOP, should the child nodes increment its DIO on seeing 193 that its preferred parent has updated its DTSN? 195 (2) What are rules for DTSN increment for storing MOP, which 196 multiple implementations can follow thus allowing consistent 197 performance across different implementations? 199 4. DAO retransmission and use of DAO-ACK in storing MOP 201 [RFC6550] has an optional DAO-ACK mechanism using which an upstream 202 parent confirms the reception of a DAO from the downstream child. In 203 case of storing mode, the DAO is addressed to the immediate hop 204 upstream parent resulting in DAO-ACK from the parent. There are two 205 implementations possible: 207 (1) Hop-by-hop ACK: A parent responds with a DAO-ACK immedetialy 208 after receiving the DAO. 210 (2) End-to-End ACK: A node waits for the upstream parent to send 211 DAO-ACK to respond with a DAO-ACK downstream. The upstream 212 parent may do as many attempts to successfully send this DAO 213 upstream. In other words, the parent node accepts the 214 responsibilty of sending the DAO upstream till the point it is 215 ACKed the moment it responds back with its own ACK to the child. 217 1-> 3-> 218 DAO DAO 219 (TgtNode)--------(6LR)-------(root) 220 ACK ACK 221 <-2 <-4 223 Figure 2: Hop-by-hop DAO-ACK 225 1-> 2-> 226 DAO DAO 227 (TgtNode)--------(6LR)-------(root) 228 ACK ACK 229 <-4 <-3 231 Figure 3: End-to-End DAO-ACK 233 4.1. Significance of bidirectional Path establishment indication and 234 relevance of DAO-ACK 236 Lot of application traffic patterns requires that the bidirectional 237 path be established between the target node and the root. A typical 238 example is that COAP request with ACK bit set would require an 239 acknowledgement from the end receiver and thus warrants bidirectional 240 path establishment. It is imperative that the target node first 241 ascertains whether such a bidirectional path is established before 242 initiating such application traffic. In case of non-storing MOP, the 243 DAO-ACK works perfectly fine to ascertain such bidirectional 244 connectivity since it is an indication that the root which usually is 245 the direct destination of the DAO has received the DAO. But in case 246 of storing MOP, things are more complicated since DAO is sent hop-by- 247 hop and the DAO-ACK semantics are not clear enough as per the current 248 specification. As mentioned in above section, an implementation can 249 choose to implement hop-by-hop ACK or end-to-end ACK. 251 4.2. Problems with hop-by-hop DAO-ACK 253 The primary issue with this mode is that target node cannot ascertain 254 bidirection path connectivity on the reception of the DAO-ACK. 256 4.3. Problems with end-to-end DAO-ACK 258 In this case, it is possible for the target node to ascertain if the 259 DAO has indeed reached the root since the reception of DAO-ACK on 260 target node confirms this. However there is extra state information 261 that needs to be maintained on the 6LRs on behalf of all the child 262 nodes. Also it is very difficult for the target node to ascertain a 263 timer value to decide whether the DAO transmission has failed to 264 reach the root. 266 4.4. Deliberations 268 (1) How should an implementation interpret the DAO-ACK semantics? 270 (2) What is the best way for the target node to know that the end to 271 end bidirectional path is successfully installed or updated? In 272 NS-MOP, the DAO-ACK provides a clear way to do this. Can the 273 same be achieved for storing-MOP? 275 (3) What happens if the DAO-ACK with Status!=0 is responded by 276 ancestor node? 278 (4) How to selectively NACK subset of targets in case target 279 containers are aggregated? 281 4.5. Implementation Notes 283 Current RPL open source implementations have both types of DAO-ACK 284 implementations. For e.g. RIOT supports hop-by-hop DAO-ACK. 285 Contiki older versions supported hop-by-hop ACK but the recent 286 version have changed to end-to-end ACK implementation. 288 The sequence of sending no-path DAO and DAO matters when updating the 289 routing adjacencies on a parent switch. If an implementation chooses 290 to send no-path DAO before DAO then it results in significantly more 291 overhead for route invalidation. This is because no-path DAO would 292 traverse all the way up to the BR clearing the routes on the way. In 293 case there is a common ancestor post which the old and new path 294 remains same then it is better to send regular DAO first thus 295 limiting the propagation of subsequent no-path DAO till this common 296 ancestor. 298 5. Handling resource unavailability 300 The nodes in the constrained networks have to maintain various 301 records such as neighbor cache entries and routing entries on behalf 302 of other targets to facilitate packet forwarding. Because of the 303 constrained nature of the devices the memory available may be very 304 limited and thus the path selection algorithm may have to take into 305 consideration such resource constraints as well. 307 RPL currently does not have any mechanism to advertise such resource 308 indicator metrics. The primary tables associated with RPL are 309 routing table and the neighbor cache. Even though neighbor cache is 310 not directly linked with RPL protocol, the maintenance of routing 311 adjacencies results in updates to neigbor cache. 313 5.1. Deliberations 315 Is it possible to know that an upstream parent/ancestor cannot 316 hold enough routing entries and thus this path should not be used? 318 Is it possible to know that an upstream parent cannot hold any 319 more neighbor cache entry and thus this upstream parent should not 320 be used? 322 6. Handling aggregated targets 324 RPL allows and defines specific procedures so as to aid target 325 aggregation in DAO. Having said that, the specification does not 326 mandate use of aggregated targets nor does it make any comment on 327 whether a receiving node needs to handle it. Target aggregation is 328 an useful tool and especially helps with link layer technologies that 329 does not suffer from low MTUs such as PLC. Even if the 330 implementation does not support aggregating targets, it should 331 atleast mandate reception of aggregated targets in DAO. 333 RPL has a mechanism currently to ACK the DAO but it does not have a 334 mechanism to ACK the target container. Thus in case of aggregated 335 targets in the DAO, if the subset of the targets fail then it is 336 impossible for the DAO-ACK to signal this to the DAO sender. 338 6.1. Deliberations 340 Even if the implementation does not support aggregating targets, 341 should it atleast mandate reception and handling of aggregated 342 targets in DAO? 344 There is a good scope for compressing aggregated targets which can 345 significantly reduce the RPL control overhead. 347 How to selectively NACK subset of targets in case target 348 containers are aggregated? 350 The DEFAULT_DAO_DELAY of 1sec does not help much with aggregation. 351 The upstream parent nodes should wait for more time then the child 352 nodes so as to effectively aggregate. Can we have 353 DEFAULT_DAO_DELAY a function of the level/rank the node is at? 355 7. RPL Transit Information in DAO 357 RPL allows associating a target or set of targets with a Transit 358 information container which contains attributes for a path to one or 359 more destinations identified by the set of targets. In case of NS- 360 MOP, the transit Information will contain the all critical Parent 361 Address which allows the common ancestor usually the root to identify 362 the source route header for the target node. The Transit Information 363 also contains other information such as Path Sequence and Path 364 Lifetime which are critical for maintaining route adjacencies. 366 RPL however does not mandate the use of Transit Information container 367 for targets. 369 7.1. Deliberations 371 Is it ok to let implementations decide on the inclusion of Transit 372 Information container? 374 Is it possible to achieve interop without mandating use of Transit 375 Information Container? 376 If the Transit Information container is sent, should the handling 377 of PathSequence be mandated? 379 The DEFAULT_DAO_DELAY of 1sec does not help much with aggregation. 380 The upstream parent nodes should wait for more time then the child 381 nodes so as to effectively aggregate. Can we have 382 DEFAULT_DAO_DELAY a function of the level/rank the node is at? 384 8. Managing persistent variables across node reboots 386 8.1. Persistent storage and RPL state information 388 Devices are required to be functional for several years without 389 manual maintanence. Usually battery power consumption is considered 390 key for operating the devices for several (tens of) years. But apart 391 from battery, flash memory endurance may prove to be a lifetime 392 bottleneck in constrained networks. Endurance is defined as maximum 393 number of erase-write cycles that a NAND/NOR cell can undergo before 394 losing its 'gauranteed' write operation. In some cases (cheaper 395 NAND-MLC/TLC), the endurance can be as less as 2K cycles. Thus for 396 e.g. if a given cell is written 5 times a day, that NAND-flash cell 397 assuming an endurance of 10K cycles may last for less than 6 years. 399 Wear leveling is a popular technique used in flash memory to minimize 400 the impact of limited cell endurance. Wear leveling works by 401 arranging data so that erasures and re-writes are distributed evenly 402 across the medium. The memory sectors are over-provisioned so that 403 the writes are distributed across multiple sectors. Many IoT 404 platforms do not necessarily consider this over-provisioning and 405 usually provision the memory only to what is required. Some 406 scenarios such as street-lighting may not require the application 407 layer to write any information to the persistent storage and thus the 408 over-provisioning is often ignored. In such cases if the network 409 stack ends up using persistent storage for maintaining its state 410 information then it becomes counter-productive. 412 In a star topology, the amount of persistent data write done by 413 network protocols is very limited. But ad-hoc networks employing 414 routing protocols such as RPL assume certain state information to be 415 retained across node reboots. In case of IoT devices this storage is 416 mostly floating gate based NAND/NOR based flash memory. The impact 417 of loss of this state information differs depending upon the type 418 (6LN/6LR/6LBR) of the node. 420 8.2. Lollipop Counters 422 [RFC6550] Section 7.2. explains sequence counter operation defining 423 lollipop [Perlman83] style counters. Lollipop counters specify 424 mechanism in which even if the counter value wraps, the algorithm 425 would be able to tell whether the received value is the latest or 426 not. This mechanism also helps in "some cases" to recover from node 427 reboot, but is not foolproof. 429 Consider an e.g. where Node A boots up and initialises the seqcnt to 430 240 as recommended in [RFC6550]. Node A communicates to Node B using 431 this seqcnt and node B uses this seqcnt to determine whether the 432 information node A sent in the packet is latest. Now lets assume, 433 the counter value reaches 250 after some operations on Node A, and 434 node B keeps receiving updated seqcnt from node A. Now consider that 435 node A reboots, and since it reinitializes the seqcnt value to 240 436 and sends the information to node B (who has seqcnt of 250 stored on 437 behalf of node A). As per section 7.2. of [RFC6550], when node B 438 receives this packet it will consider the information to be old 439 (since 240 < 250). 441 +-----+-----+----------+ 442 | A | B | Output | 443 +-----+-----+----------+ 444 | 240 | 240 | AB, new | 450 | 240 | :: | A>B, new | 451 | 240 | 127 | A>B, new | 452 +-----+-----+----------+ 454 Default values for lollipop counters considered from [RFC6550] 455 Section 7.2. 457 Table 1: Example lollipop counter operation 459 Based on this figure, there is dead zone (240 to 0) in which if A 460 operates after reboot then the seqcnt will always be considered 461 smaller. Thus node A needs to maintain the seqcnt in persistent 462 storage and reuse this on reboot. 464 8.3. RPL State variables 466 The impact of loss of RPL state information differs depending upon 467 the node type (6LN/6LR/6LBR). Following sections explain different 468 state variables and the impact in case this information is lost on 469 reboot. 471 8.3.1. DODAG Version 473 The tuple (RPLInstanceID, DODAGID, DODAGVersionNumber) uniquely 474 identifies a DODAG Version. DODAGVersionNumber is incremented 475 everytime a global repair is initiated for the instance (global or 476 local). A node receiving an older DODAGVersionNumber will ignore the 477 DIO message assuming it to be from old DODAG version. Thus a 6LBR 478 node (and 6LR node in case of local DODAG) needs to maintain the 479 DODAGVersionNumber in the persistent storage, so as to be available 480 on reboot. In case the 6LBR could not use the latest 481 DODAGVersionNumber the implication are that it won't be able to 482 recover/re-establish the routing table. 484 8.3.2. DTSN field in DIO 486 DTSN (Destination advertisement Trigger Sequence Number) is a DIO 487 message field used as part of procedure to maintain Downward routes. 488 A 6LBR/6LR node may increment a DTSN in case it requires the 489 downstream nodes to send DAO and thus update downward routes on the 490 6LBR/6LR node. In case of RPL NS-MOP, only the 6LBR maintains the 491 downward routes and thus controls this field update. In case of 492 S-MOP, 6LRs additionally keep downward routes and thus control this 493 field update. 495 In S-MOP, when a 6LR node switches parent it may have to issue a DIO 496 with incremented DTSN to trigger downstream child nodes to send DAO 497 so that the downward routes are established in all parent/ancestor 498 set. Thus in S-MOP, the frequency of DTSN update might be relatively 499 high (given the node density and hysteresis set by objective function 500 to switch parent). 502 8.3.3. PathSequence 504 PathSequence is part of RPL Transit Option, and associated with RPL 505 Target option. A node whichs owns a target address can associate a 506 PathSequence in the DAO message to denote freshness of the target 507 information. This is especially useful when a node uses multiple 508 paths or multiple parents to advertise its reachability. 510 Loss of PathSequence information maintained on the target node can 511 result in routing adjacencies been lost on 6LRs/6LBR/6BBR. 513 8.4. State variables update frequency 515 +--------------------+-------------------+------------------------+ 516 | State variable | Update frequency | Impacts node type | 517 +--------------------+-------------------+------------------------+ 518 | DODAGVersionNumber | Low | 6LBR, 6LR(local DODAG) | 519 | DTSN | High(SM),Low(NSM) | 6LBR, 6LR | 520 | PathSequence | High(SM),Low(NSM) | 6LR, 6LN | 521 +--------------------+-------------------+------------------------+ 523 Low=<5 per day, High=>5 per day; SM=Storing MOP, NSM=Non-Storing MOP 525 Table 2: RPL State variables 527 8.5. Deliberations 529 (1) Is it possible that RPL reduces the use of persistent storage 530 for maintaining state information? 532 (2) In most cases, the node reboots will happen very rarely. Thus 533 doing a persistent storage book-keeping for handling node reboot 534 might not make sense. Is it possible to consider signaling 535 (especially after the node reboots) so as to avoid maintaining 536 this persistent state? Is it possible to use one-time on-reboot 537 signalling to recover some state information? 539 (3) It is necessary that RPL avoids using persistent storage as far 540 as possible. Ideally, extensions to RPL should consider this as 541 a design requirement especially for 6LR and 6LN nodes. DTSN and 542 PathSequence are the primary state variables which have major 543 impact. 545 8.6. Implementation Notes 547 An implementation should use a random DAOSequence number on reboot so 548 as to avoid a risk of reusing the same DAOSequence on reboot. 549 Regardless the sequence counter size of 8bits does not provide much 550 gurantees towards choosing a good random number. A parent node will 551 not respond with a DAO-ACK in case it sees a DAO with the same 552 previous DAOSequence. 554 Write-Before-Use: The state information should be written to the 555 flash before using it in the messaging. If it is done the other way, 556 then the chances are that the node power downs before writing to the 557 persistent storage. 559 9. RPL under-specification 561 (a) PathSequence: Is it mandatory to use PathSequence in DAO Transit 562 container? RPL mentions that a 6LR/6LBR hosting the routing 563 entry on behalf of target node should refresh the lifetime on 564 reception of a new Path Sequence. But RPL does not necessarily 565 mandate use of Path Sequence. Most of the open source 566 implementation [RIOT] [CONTIKI] currently do not issue Path 567 Sequence in the DAO message. 569 (b) Target Container aggregation in DAO: RPL allows multiple targets 570 to be aggregated in a single DAO message and has introduced a 571 notion of DelayDAO using which a 6LR node could delay its DAO to 572 enable such aggregation. But RPL does not have clear text on 573 handling of aggregated DAOs and thus it hinders 574 interoperability. 576 (c) DTSN Update: RPL does not clearly define in which cases DTSN 577 should be updated in case of storing mode of operation. More 578 details for this are presented in Section 3. 580 10. Acknowledgements 582 Many thanks to Pascal Thubert for hallway chats and for helping 583 understand the existing design rationales. Thanks to Michael 584 Richardson for Unstrung RPL implementation rationale. Thanks to ML 585 discussions, in particular (https://www.ietf.org/mail- 586 archive/web/roll/current/msg09443.html). 588 11. IANA Considerations 590 This memo includes no request to IANA. 592 12. Security Considerations 594 This is an information draft and does add any changes to the existing 595 specifications. 597 13. References 599 13.1. Normative References 601 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 602 Requirement Levels", BCP 14, RFC 2119, 603 DOI 10.17487/RFC2119, March 1997, 604 . 606 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 607 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 608 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 609 Low-Power and Lossy Networks", RFC 6550, 610 DOI 10.17487/RFC6550, March 2012, 611 . 613 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 614 and D. Barthel, "Routing Metrics Used for Path Calculation 615 in Low-Power and Lossy Networks", RFC 6551, 616 DOI 10.17487/RFC6551, March 2012, 617 . 619 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 620 Protocol for Low-Power and Lossy Networks (RPL)", 621 RFC 6552, DOI 10.17487/RFC6552, March 2012, 622 . 624 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 625 Bormann, "Neighbor Discovery Optimization for IPv6 over 626 Low-Power Wireless Personal Area Networks (6LoWPANs)", 627 RFC 6775, DOI 10.17487/RFC6775, November 2012, 628 . 630 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 631 J. Martocci, "Reactive Discovery of Point-to-Point Routes 632 in Low-Power and Lossy Networks", RFC 6997, 633 DOI 10.17487/RFC6997, August 2013, 634 . 636 13.2. Informative References 638 [I-D.clausen-lln-rpl-experiences] 639 Clausen, T., Verdiere, A., Yi, J., Herberg, U., and Y. 640 Igarashi, "Observations on RPL: IPv6 Routing Protocol for 641 Low power and Lossy Networks", draft-clausen-lln-rpl- 642 experiences-11 (work in progress), March 2018. 644 [Perlman83] 645 Perlman, R., "Fault-Tolerant Broadcast of Routing 646 Information", North-Holland Computer Networks, Vol.7, 647 December 1983. 649 Appendix A. Additional Stuff 650 Authors' Addresses 652 Rahul Arvind Jadhav (editor) 653 Huawei 654 Kundalahalli Village, Whitefield, 655 Bangalore, Karnataka 560037 656 India 658 Phone: +91-080-49160700 659 Email: rahul.ietf@gmail.com 661 Rabi Narayan Sahoo 662 Huawei 663 Kundalahalli Village, Whitefield, 664 Bangalore, Karnataka 560037 665 India 667 Phone: +91-080-49160700 668 Email: rabinarayans@huawei.com 670 Yuefeng Wu 671 Huawei 672 No.101, Software Avenue, Yuhuatai District, 673 Nanjing, Jiangsu 210012 674 China 676 Phone: +86-15251896569 677 Email: wuyuefeng@huawei.com