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