idnits 2.17.1 draft-zhong-roll-dis-modifications-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6550]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 4, 2015) is 3067 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Zhong, Ed. 3 Internet-Draft INSA Lyon 4 Intended status: Standards Track D. Barthel 5 Expires: May 7, 2016 Orange 6 E. Baccelli 7 INRIA 8 November 4, 2015 10 DIS Modifications 11 draft-zhong-roll-dis-modifications-00 13 Abstract 15 This document augments [RFC6550] with DIS flags and options that 16 allow a RPL node to better control how neighbor RPL routers respond 17 to its solicitation for DIOs. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 7, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. RFC6550 refresher . . . . . . . . . . . . . . . . . . . . 2 55 1.2. Undesirable effects . . . . . . . . . . . . . . . . . . . 3 56 1.3. Desired improvments . . . . . . . . . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. DIS Base Object flags . . . . . . . . . . . . . . . . . . . . 5 59 4. DIS Options . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.1. Metric Container . . . . . . . . . . . . . . . . . . . . 5 61 4.2. Response Spreading . . . . . . . . . . . . . . . . . . . 6 62 5. Full behavior illustration . . . . . . . . . . . . . . . . . 7 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 6.1. DIS Flags . . . . . . . . . . . . . . . . . . . . . . . . 8 65 6.2. RPL Control Message Options . . . . . . . . . . . . . . . 8 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 9.2. Informative References . . . . . . . . . . . . . . . . . 10 71 Appendix A. Applications . . . . . . . . . . . . . . . . . . . . 10 72 A.1. A Leaf Node Joining a DAG . . . . . . . . . . . . . . . . 10 73 A.2. Identifying A Defunct DAG . . . . . . . . . . . . . . . . 11 74 Appendix B. Experimental data . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 This document augments [RFC6550], the RPL routing protocol 80 specification. 82 1.1. RFC6550 refresher 84 Per [RFC6550], a RPL node can send a DODAG Information Solicitation 85 (DIS) message to solicit DODAG Information Object (DIO) messages from 86 neighbor RPL routers. 88 A DIS can be multicast to all the routers in range or it can be 89 unicast to a specific neighbor router. 91 A DIS may carry a Solicited Information option that specifies the 92 predicates of the DAG(s) the soliciting node is interested in. In 93 the absence of such Solicited Information option, the soliciting node 94 is deemed interested in receiving DIOs for all the DAGs known by the 95 solicited router(s). 97 [RFC6550] requires a router to treat the receipt of a multicast DIS 98 as an inconsistency and hence reset its Trickle timers for the 99 matching DAGs. As a result of the general Trickle timer mechanism, 100 future DIOs will be sent at a higher rate. See [RFC6206] for the 101 specification of Trickle timers and the definition of 102 "inconsistency". 104 [RFC6550] requires a router that receives a unicast DIS to respond by 105 unicasting a DIO for each matching DAG and to not reset the 106 associated Trickle timer. Such a DIO generated in response to a 107 unicast DIS must contain a Configuration option. 109 This description is summarized in Table 1. 111 +----------------------------+----------------------+---------------+ 112 | | Unicast DIS | Multicast DIS | 113 +----------------------------+----------------------+---------------+ 114 | no option present | unicast DIO, don't | do reset | 115 | | reset Trickle timer | Trickle timer | 116 | -------------------------- | -------------------- | ------------- | 117 | Solicited Information | do nothing | do nothing | 118 | option present, not | | | 119 | matching | | | 120 | -------------------------- | -------------------- | ------------- | 121 | Solicited Information | unicast DIO, don't | do reset | 122 | option present, matching | reset Trickle timer | Trickle timer | 123 +----------------------------+----------------------+---------------+ 125 Table 1: Router behavior on receiving a DIS, as per RFC6550 127 More precisely, Table 1 describes the behavior of routers for each 128 DAG they belong to. In the general case where multiple RPL instances 129 co-exist in a network, routers will maintain a Trickle timer for the 130 one DAG of each RPL instance they belong to, and nodes may send a DIS 131 with multiple Solicited Information options pertaining to different 132 DAGs or instances. In this more general case, routers will respond 133 for each individual DAG/instance they belong to as per Table 1. 135 1.2. Undesirable effects 137 Now, consider a RPL leaf node that desires to join a certain DAG. 138 This node can either wait for its neighbor RPL routers to voluntarily 139 transmit DIOs or it can proactively solicit DIOs using a DIS message. 140 Voluntary DIO transmissions may happen after a very long time if the 141 network is stable and the Trickle timer intervals have reached large 142 values. Thus, proactively seeking DIOs using a DIS may be the only 143 reasonable option. Since the node does not know which neighbor 144 routers belong to the DAG, it must solicit the DIOs using a multicast 145 DIS (with predicates of the desired DAG specified inside a Solicited 146 Information option). On receiving this DIS, the neighbor routers 147 that belong to the desired DAG will reset their Trickle timers and 148 quickly transmit their DIOs. The downside of resetting Trickle 149 timers is that the routers will keep transmitting frequent DIOs for a 150 considerable duration until the Trickle timers again reach long 151 intervals. These DIO transmissions are unnecessary, consume precious 152 energy and may contribute to congestion in the network. 154 There are other scenarios where resetting of Trickle timer following 155 the receipt of a multicast DIS is not appropriate. For example, 156 consider a RPL router that desires to free up memory by deleting 157 state for the defunct DAGs it belongs to. Identifying a defunct DAG 158 may require the node to solicit DIOs from its DAG parents using a 159 multicast DIS. 161 1.3. Desired improvments 163 To deal with the situations described above, there is a need in the 164 industry for DIS flags and options that allow a RPL node to control 165 how neighbor RPL routers respond to its solicitation for DIOs, for 166 example by expressing: 168 o the routing constraints that routers should meet to be allowed to 169 respond, thereby lowering the number of responders 171 o whether the responding routers should reset their Trickle timers 172 or not, thereby limiting the cumulated number of transmitted DIOs 174 o whether the responding routers should respond with a unicast DIO 175 instead of a multicast one, thereby lowering the overhearing cost 176 in the network 178 o the time interval over which the responding routers should 179 schedule their DIO transmissions, thereby lowering the occurence 180 of collisions. 182 2. Terminology 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 186 "OPTIONAL" in this document are to be interpreted as described in 187 [RFC2119]. 189 Additionally, this document uses terminology from [RFC6550]. 190 Specifically, the term RPL node refers to a RPL router or a RPL host 191 as defined in [RFC6550]. 193 3. DIS Base Object flags 195 This document defines two new flags inside the DIS base object: 197 o the "No Inconsistency" (N) flag: On receiving a multicast DIS with 198 the N flag set, a RPL router MUST NOT reset the Trickle timers for 199 the matching DAGs. In addition, it MUST take specific action, 200 which is to respond by explicitely sending a DIO. This DIO MUST 201 include a Configuration option. This behavior augments [RFC6550], 202 which had provision for such flag. Since this specific, one-shot 203 DIO is not a consequence of the general Trickle timer mechanism, 204 it will be sent right away if no Response Spreading option is 205 present or it will be scheduled according to the Response 206 Spreading option if one is present in the DIS (see Section 4.2). 208 o the "DIO Type" (T) flag: In case the N flag is set, this T flag 209 specifies what type of DIO is sent in response. It MUST be a 210 unicast DIO if this flag is set and it MUST be a multicast DIO if 211 this flag is reset. 213 When a unicast DIS is transmitted, both its N and T flags SHOULD be 214 0, which are the default values per [RFC6550]. On receiving a 215 unicast DIS, the N and T flags MUST be ignored and treated as 00. 217 The modified DIS base object is shown in Figure 1. 219 0 1 2 3 220 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Flags |N|T| Reserved | Option(s)... 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Figure 1: Modified DIS Base Object 227 4. DIS Options 229 4.1. Metric Container 231 In order to lower the number of routers that will respond to a DIS, 232 this document allows routing constraints to be carried by a DIS. 233 Only the router(s) that satisfy these constraints is (are) allowed to 234 respond to the DIS. 236 These routing constraints are described using a Metric Container 237 option contained in the DIS. Metric Containers are defined in 238 [RFC6550] and [RFC6551]. Metric Containers options were previously 239 only allowed in DIOs. This document augments [RFC6550] by allowing 240 the inclusion of a Metric Container option inside a DIS as well. 242 A RPL router that receives a DIS with a Metric Container option MUST 243 ignore any Metric object in it, and MUST evaluate the "mandatory" 244 Constraint objects in it by comparing the constraint value to the 245 value of the corresponding routing metric that the router maintains 246 for the matching DAG(s). These routing metric values MUST satisfy 247 all the mandatory constraints in order for the router to consider the 248 solicitation successful for the matching DAG(s). This augments the 249 behavior already present in [RFC6550] with the Solicited Information 250 option. 252 This option can be used in both unicast and multicast DIS. 254 4.2. Response Spreading 256 0 1 2 257 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Type = 0x0A | Length | Spread. Inter.| 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 Figure 2: The Response Spreading option 264 Even with the use of the Solicited Information and the Section 4.1 265 options, a multicast DIS may still lead to a large number of RPL 266 routers taking immediate action and responding with DIOs. Concurrent 267 transmissions by multiple routers are not desirable since they may 268 lead to poor channel utilization or even to packet loss. Unicast 269 DIOs may be able to avail of link-level retransmissions. However, 270 multicast DIOs usually have no such protection, since they commonly 271 make use of link layer broadcast. To avoid such problems, this 272 document specifies an optional DIO response spreading mechanism. 274 This document defines a new RPL control message option called 275 Response Spreading option, shown in Figure 2, with a recommended Type 276 value 0x0A (to be confirmed by IANA). A RPL router that explicitely 277 responds with a specific, one-shot DIO to a DIS that includes a 278 Response Spreading option, MUST wait for a time uniformly chosen in 279 the interval [O..2^SpreadingInterval], expressed in ms, before 280 attempting to transmit its DIO. If the DIS does not include a 281 Response Spreading option, the node is free to transmit the DIO as it 282 otherwise would. 284 A Response Spreading option MAY be included inside a unicast DIS 285 message, but there is no benefit in doing so. 287 Multiple Response Spreading options SHOULD NOT be used inside a same 288 DIS message. 290 This mechanism MUST NOT affect the Trickle timer mechanism. 292 5. Full behavior illustration 294 Figure 3 and Figure 4 illustrate the normative behavior described in 295 Section 3 and Section 4.1. 297 +--------------------+---------------------- 298 | Unicast DIS | Multicast DIS 299 +--------------------+--------------------+- 300 | | N=0 | 301 +--------------------+--------------------+--------------------+- 302 | | unicast DIO, | | 303 | no option present | don't | do | 304 | | reset Trickle timer| reset Trickle timer| 305 +--------------------+--------------------+--------------------+- 306 | Solicited Informa- | | | 307 | tion/Metric Contai-| do nothing | do nothing | 308 | ner option present,| | | 309 | not matching. | | | 310 +--------------------+--------------------+--------------------+- 311 | Solicited Informa- | unicast DIO, | | 312 | tion/Metric Contai-| don't | do | 313 | ner option present,| reset Trickle timer| reset Trickle timer| 314 | matching. | | | 315 +--------------------+--------------------+--------------------+- 317 Figure 3: Overall DIS behavior, part 1 319 Notice that Figure 3 is indeed identical to Table 1 when Metric 320 Container options are not used in DIS. 322 -------------------------------------------+ 323 Multicast DIS | 324 ----------------------+--------------------+ 325 | N=1, T=0 | N=1, T=1 | 326 -+--------------------+--------------------+ 327 | multicast DIO, | unicast DIO, | 328 | don't | don't | 329 | reset Trickle timer| reset Trickle timer| 330 -+--------------------+--------------------+ 331 | | | 332 | do nothing | do nothing | 333 | | | 334 | | | 335 -+--------------------+--------------------+ 336 | multicast DIO, | unicast DIO, | 337 | don't | don't | 338 | reset Trickle timer| reset Trickle timer| 339 | | | 340 -+--------------------+--------------------+ 342 Figure 4: Overall DIS behavior, part 2 344 For the sake of completeness, let's remind here that a specific, one- 345 shot DIO generated in response to a DIS must contain a Configuration 346 option and that its transmission is delayed according to the Delay 347 Spreading option of the DIS, if one such option is present. 349 6. IANA Considerations 351 6.1. DIS Flags 353 IANA is requested to allocate bits 6 and 7 of the DIS Flag Field to 354 become the "No Inconsistency" and "DIO Type" bits, the functionality 355 of which is described in Section 3 of this document. 357 +-------+------------------+---------------+ 358 | Value | Meaning | Reference | 359 +-------+------------------+---------------+ 360 | 6 | No Inconsistency | This document | 361 | 7 | DIO Type | This document | 362 +-------+------------------+---------------+ 364 6.2. RPL Control Message Options 366 IANA is requested to allocate a new code point in the "RPL Control 367 Message Options" registry for the "Response Spreading" option, the 368 behavior of which is described in Section 4.2. 370 +-------+--------------------+---------------+ 371 | Value | Meaning | Reference | 372 +-------+--------------------+---------------+ 373 | 0x0A | Response Spreading | This document | 374 +-------+--------------------+---------------+ 376 RPL Control Message Options 378 7. Security Considerations 380 TBA 382 8. Acknowledgements 384 A lot of text in this document originates from now-expired [I- 385 D.goyal-roll-dis-modifications] co-authored with M. Goyal. The 386 requirements and solutions also draw from now-expired [I-D.dejean- 387 roll-selective-dis] co-authored with N. Dejean. Their contribution 388 is deeply acknowledged. 390 We also thank (TBA) for their useful feedback and discussion. 392 9. References 394 9.1. Normative References 396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 398 RFC2119, March 1997, 399 . 401 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 402 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 403 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 404 Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/ 405 RFC6550, March 2012, 406 . 408 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 409 and D. Barthel, "Routing Metrics Used for Path Calculation 410 in Low-Power and Lossy Networks", RFC 6551, DOI 10.17487/ 411 RFC6551, March 2012, 412 . 414 9.2. Informative References 416 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 417 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 418 DOI 10.17487/RFC4861, September 2007, 419 . 421 [RFC5184] Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K. 422 Mitani, "Unified Layer 2 (L2) Abstractions for Layer 3 423 (L3)-Driven Fast Handover", RFC 5184, DOI 10.17487/ 424 RFC5184, May 2008, 425 . 427 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 428 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 429 10.17487/RFC5881, June 2010, 430 . 432 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 433 "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, 434 March 2011, . 436 Appendix A. Applications 438 This section details two example mechanisms that use the DIS flags 439 and options defined in this document. The first mechanism describes 440 how a leaf node may join a desired DAG in an energy efficient manner. 441 The second mechanism details how a node may identify defunct DAGs for 442 which it still maintains state. 444 A.1. A Leaf Node Joining a DAG 446 A new leaf node that joins an established LLN runs an iterative 447 algorithm in which it requests (using multicast DIS) DIOs from 448 routers belonging to the desired DAG. 450 The DIS message has the "No Inconsistency" flag set to prevent 451 resetting of Trickle timer in responding routers, thereby keeping the 452 aggregated number of transmissions low. It also has the "DIO Type" 453 flag set to make responding routers send unicast DIOs back, thereby 454 not triggering full reception in nearby nodes that have state-of-the- 455 art radio receivers with hardware-based address filtering. 457 The DIS message can include a Response Spreading option prescribing a 458 suitable spreading interval based on the expected density of nearby 459 routers and on the expected Layer 2 technology. 461 The DIS will likely include a Metric Container listing the routing 462 constraints that the responding routers must satisfy in order to be 463 allowed to respond. 465 At each iteration, the node multicasts such a DIS and waits for 466 forthcoming DIOs. After a time equal to the spreading interval, the 467 node considers the current iteration to be unsuccessful. The node 468 consequently relaxes the routing constraints somewhat and proceeds to 469 the next iteration. 471 The cycle repeats until the node receives one or more DIOs or until 472 it has relaxed the constraints to the lowest acceptable values. 474 This algorithm has been proven in the field to be extremely energy- 475 efficient, especially when routers have a wide communication range. 477 A.2. Identifying A Defunct DAG 479 A RPL node may remove a neighbor from its parent set for a DAG for a 480 number of reasons: 482 o The neighbor is no longer reachable, as determined using a 483 mechanism such as Neighbor Unreachanility Detection (NUD) 484 [RFC4861], Bidirectional Forwarding Detection (BFD) [RFC5881] or 485 L2 triggers [RFC5184]; or 487 o The neighbor advertises an infinite rank in the DAG; or 489 o Keeping the neighbor as a parent would required the node to 490 increase its rank beyond L + DAGMaxRankIncrease, where L is the 491 minimum rank the node has had in this DAG; or 493 o The neighbor advertises membership in a different DAG within the 494 same RPL Instance, where a different DAG is recognised by a 495 different DODAGID or a different DODAGVersionNumber. 497 Even if the conditions listed above exist, a RPL node may fail to 498 remove a neighbor from its parent set because: 500 o The node may fail to receive the neighbor's DIOs advertising an 501 increased rank or the neighbor's membership in a different DAG; 503 o The node may not check, and hence may not detect, the neighbor's 504 unreachability for a long time. For example, the node may not 505 have any data to send to this neighbor and hence may not encounter 506 any event (such as failure to send data to this neighbor) that 507 would trigger a check for the neighbor's reachability. 509 In such cases, a node would continue to consider itself attached to a 510 DAG even if all its parents in the DAG are unreachable or have moved 511 to different DAGs. Such a DAG can be characterized as being defunct 512 from the node's perspective. If the node maintains state about a 513 large number of defunct DAGs, such state may prevent a considerable 514 portion of the total memory in the node from being available for more 515 useful purposes. 517 To alleviate the problem described above, a RPL node may invoke the 518 following procedure to identify a defunct DAG and delete the state it 519 maintains for this DAG. Note that, given the proactive nature of RPL 520 protocol, the lack of data traffic using a DAG can not be considered 521 a reliable indication of the DAG's defunction. Further, the Trickle 522 timer based control of DIO transmissions means the possibility of an 523 indefinite delay in the receipt of a new DIO from a functional DAG 524 parent. Hence, the mechanism described here is based on the use of a 525 DIS message to solicit DIOs about a DAG suspected of defunction. 526 Further, a multicast DIS is used so as to avoid the need to query 527 each parent individually and also to discover other neighbor routers 528 that may serve as the node's new parents in the DAG. 530 When a RPL node has not received a DIO from any of its parents in a 531 DAG for more than a locally configured time duration: 533 o The node generates a multicast DIS message with: 535 * the "No Inconsistency" flag set so that the responding routers 536 do not reset their Trickle timers. 538 * the "DIO Type" flag not set so that the responding routers send 539 multicast DIOs and other nodes in the vicinity do not need to 540 invoke this procedure. 542 * a Solicited Information option to identify the DAG in question. 543 This option must have the I and D flags set and the 544 RPLInstanceID/DODAGID fields must be set to values identifying 545 the DAG. The V flag inside the Solicited Information option 546 should not be set so as to allow the neighbors to send DIOs 547 advertising the latest version of the DAG. 549 * a Response Spreading option specifying a suitable time interval 550 over which the DIO responses may arrive. 552 o After sending the DIS, the node waits for the duration specified 553 inside the Response Spreading option to receive the DIOs generated 554 by its neighbors. At the conclusion of the wait duration: 556 * If the node has received one or more DIOs advertising newer 557 version(s) of the DAG, it joins the latest version of the DAG, 558 selects a new parent set among the neighbors advertising the 559 latest DAG version and marks the DAG status as functional. 561 * Otherwise, if the node has not received a DIO advertising the 562 current version of the DAG from a neighbor in the parent set, 563 it removes that neighbor from the parent set. As a result, if 564 the node has no parent left in the DAG, it marks the DAG as 565 defunct and schedule the deletion of the state it has 566 maintained for the DAG after a locally configured "hold" 567 duration. (This is because, as per RPL specification, when a 568 node no longer has any parents left in a DAG, it is still 569 required to remember the DAG's identity (RPLInstanceID, 570 DODAGID, DODAGVersionNumber), the lowest rank (L) it has had in 571 this DAG and the DAGMaxRankIncrease value for the DAG for a 572 certain time interval to ensure that the node does not join an 573 earlier version of the DAG and does not rejoin the current 574 version of the DAG at a rank higher than L + 575 DAGMaxRankIncrease.) 577 Appendix B. Experimental data 579 The effectiveness of these flags and options has been measured on 580 real industrial hardware. 582 Data to be added 584 Authors' Addresses 586 Zhong Denglin (editor) 587 INSA Lyon 588 20 Avenue Albert Einstein 589 Villeurbanne 69621 590 France 592 Email: denglin.zhong@insa-lyon.fr 594 Dominique Barthel 595 Orange 596 28 Chemin Du Vieux Chene, BP 98 597 Meylan 38243 598 France 600 Email: dominique.barthel@orange.com 601 Emmanuel Baccelli 602 INRIA 604 Phone: +33-169-335-511 605 Email: Emmanuel.Baccelli@inria.fr 606 URI: http://www.emmanuelbaccelli.org/