idnits 2.17.1 draft-iwanicki-roll-rnfd-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 date (9 November 2021) is 892 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: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL K. Iwanicki 3 Internet-Draft University of Warsaw 4 Intended status: Standards Track 9 November 2021 5 Expires: 13 May 2022 7 RNFD: Fast border router crash detection in RPL 8 draft-iwanicki-roll-rnfd-01 10 Abstract 12 By and large, a correct operation of a RPL network requires border 13 routers to be up. In many applications, it is beneficial for the 14 nodes to detect a crash of a border router as soon as possible to 15 trigger fallback actions. This document describes RNFD, an extension 16 to RPL that expedites border router failure detection, even by an 17 order of magnitude, by having nodes collaboratively monitor the 18 status of a given border router. The extension introduces an 19 additional state at each node, a new type of RPL Control Message 20 Options for synchronizing this state among different nodes, and the 21 coordination algorithm itself. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 13 May 2022. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Effects of LBR Crashes . . . . . . . . . . . . . . . . . 3 58 1.2. Design Principles . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.1. Protocol State Machine . . . . . . . . . . . . . . . . . 7 62 3.2. Counters and Communication . . . . . . . . . . . . . . . 8 63 4. The RNFD Option . . . . . . . . . . . . . . . . . . . . . . . 9 64 4.1. General CFRC Requirements . . . . . . . . . . . . . . . . 9 65 4.2. Format of the Option . . . . . . . . . . . . . . . . . . 10 66 5. RPL Router Behavior . . . . . . . . . . . . . . . . . . . . . 12 67 5.1. Joining a DODAG Version and Changing the RNFD Role . . . 12 68 5.2. Detecting and Verifying Problems with the DODAG Root . . 13 69 5.3. Disseminating Observations and Reaching Agreement . . . . 15 70 5.4. DODAG Root's Behavior . . . . . . . . . . . . . . . . . . 16 71 5.5. Activating and Deactivating the Protocol on Demand . . . 17 72 5.6. Processing CFRCs of Incompatible Lengths . . . . . . . . 17 73 5.7. Summary of RNFD's Interactions with RPL . . . . . . . . . 18 74 5.8. Summary of RNFD's Constants . . . . . . . . . . . . . . . 19 75 6. Manageability Considerations . . . . . . . . . . . . . . . . 19 76 6.1. Role Assignment and CFRC Size Adjustment . . . . . . . . 20 77 6.2. Virtual DODAG Roots . . . . . . . . . . . . . . . . . . . 20 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 83 10.2. Informative References . . . . . . . . . . . . . . . . . 23 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 86 1. Introduction 88 RPL is an IPv6 routing protocol for low-power and lossy networks 89 (LLNs) [RFC6550]. Such networks are usually constrained in device 90 energy and channel capacity. They are formed largely of nodes that 91 offer little processing power and memory, and links that are of 92 variable qualities and support low data rates. Therefore, the main 93 challenge that a routing protocol for LLNs has to address is 94 minimizing resource consumption without sacrificing reaction time to 95 network changes. 97 One of the main design principles adopted in RPL to minimize node 98 resource consumption is delegating much of the responsibility for 99 routing to LLN border routers (LBRs). A network is organized into 100 destination-oriented directed acyclic graphs (DODAGs), each 101 corresponding to an LBR and having all its paths terminate at the 102 LBR. To this end, every node is dynamically assigned a rank 103 representing its distance, measured in some metric, to a given LBR, 104 with the LBR having the minimal rank, which reflects its role as the 105 DODAG root. The ranks allow each non-LBR node to select from among 106 its neighbors (i.e., nodes to which the node has links) those ones 107 that are closer to the LBR than the node itself: the node's parents 108 in the graph. The resulting DODAG paths, consisting of the node- 109 parent links, are utilized for routing packets upward: to the LBR and 110 outside the LLN. They are also used by nodes to periodically report 111 their connectivity upward to the LBR, which allows in turn for 112 directing packets downward, from the LBR to these nodes, for 113 instance, by means of source routing [RFC6554]. All in all, not only 114 do LBRs participate in routing but also drive the process of DODAG 115 construction and maintenance underlying the protocol. 117 To play this central role, LBRs are expected to be more capable than 118 regular LLN nodes. They are assumed not to be constrained in 119 computing power, memory, and energy, which often entails a more 120 involved hardware-software architecture and tethered power supply. 121 This, however, also makes them more prone to failures, especially 122 since in large deployments it is often difficult to ensure a backup 123 power supply for every LBR. 125 1.1. Effects of LBR Crashes 127 When an LBR crashes, the nodes in its DODAG lose the ability to 128 communicate with other Internet hosts. In addition, a significant 129 fraction of DODAG paths interconnecting the nodes become invalid, as 130 they pass through the LBR. The others also degenerate as a result of 131 DODAG repair attempts, which are bound to fail. In effect, routing 132 inside the DODAG also becomes largely impossible. Consequently, it 133 is desirable that an LBR crash be detected by the nodes fast, so that 134 they can leave the broken DODAG and join another one or trigger 135 additional application- or deployment-dependent fallback mechanisms, 136 thereby minimizing the negative impact of the disconnection. 138 Since all DODAG paths lead to the corresponding LBR, detecting its 139 crash by a node entails dropping all parents and adopting an infinite 140 rank, which reflects the node's inability to reach the LBR. 141 Depending on the deployment settings, the node can then remain in 142 such a state, join a different DODAG, or even become itself the root 143 of a floating DODAG. In any case, however, achieving this state for 144 all nodes is slow, can generate heavy traffic, and is difficult to 145 implement correctly [Iwanicki16] [Paszkowska19] [Ciolkosz19]. 147 To start with, tearing down all DODAG paths requires each of the 148 LBR's neighbors to detect that its link with the LBR is no longer up. 149 Otherwise, any of the neighbors unaware of this fact can keep 150 advertising a finite rank and can thus be other nodes' parent or 151 ancestor in the DODAG: such nodes will incorrectly believe they have 152 a valid path to the LBR. Detecting a crash of a link by a node 153 normally happens when the node has observed sufficiently many 154 forwarding failures over the link. Therefore, considering the low- 155 data-rate applications of LLNs, the period from the crash to the 156 moment of eliminating from the DODAG the last link to the LBR may be 157 long. Subsequently learning by all nodes that none of their links 158 can form any path leading to the LBR also adds latency, partly due to 159 parent changes that the nodes independently perform in attempts to 160 repair their broken paths locally. Since a non-LBR node has only 161 local knowledge of the network, potentially inconsistent with that of 162 other nodes, such parent changes often produce paths containing 163 loops, which have to be broken before all nodes can conclude that no 164 path to the LBR exists globally. Even with RPL's dedicated loop 165 detection mechanisms [RFC6553], this also requires traffic, and hence 166 time. Finally, switching a parent or discovering a loop can also 167 generate cascaded bursts of control traffic, owing to the adaptive 168 Trickle algorithm for exchanging DODAG information [RFC6202]. 169 Overall, the behavior of the network when handling an LBR crash is 170 highly suboptimal, thereby not being in line with RPL's goal of 171 minimizing resource consumption and reaction latencies. 173 1.2. Design Principles 175 To address this issue, this document proposes an extension to RPL, 176 dubbed Root Node Failure Detector (RNFD). To minimize the time and 177 traffic required to handle an LBR crash, the RNFD algorithm adopts 178 the following design principles, derived directly from the previous 179 observations: 181 1. Explicitly coordinating LBR monitoring between nodes instead of 182 relying only on the emergent behavior resulting from their 183 independent operation. 185 2. Avoiding probing all links to the dead LBR so as to reduce the 186 tail latency when eliminating these links from the DODAG. 188 3. Exploiting concurrency by prompting proactive checking for a 189 possible LBR crash when some nodes suspect such a failure may 190 have taken place, which aims to further reduce the critical path. 192 4. Minimizing changes to RPL's existing algorithms by operating in 193 parallel and largely independently (in the background), and 194 introducing few additional assumptions. 196 While these principles do improve RPL's performance under a wide 197 range of LBR crashes, their probabilistic nature precludes hard 198 guarantees for all possible corner cases. In particular, in some 199 scenarios, RNFD's operation may result in false negatives, but these 200 situations are peculiar and will eventually be handled by RPL's own 201 aforementioned mechanisms. Likewise, in some scenarios, notably 202 involving highly unstable links, false positives may occur, but they 203 can be alleviated as well. In any case, the principles also 204 guarantee that RNFD can be deactivated at any time, if needed, in 205 which case RPL's operation is unaffected. 207 2. Terminology 209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 211 "OPTIONAL" in this document are to be interpreted as described in BCP 212 14 [RFC2119] [RFC8174] when, and only when, they appear in all 213 capitals, as shown here. 215 The Terminology used in this document is consistent with and 216 incorporates that described in "Terms Used in Routing for Low-Power 217 and Lossy Networks (LLNs)" [RFC7102], "RPL: IPv6 Routing Protocol for 218 Low-Power and Lossy Networks" [RFC6550], and "The Routing Protocol 219 for Low-Power and Lossy Networks (RPL) Option for Carrying RPL 220 Information in Data-Plane Datagrams" [RFC6553]. Other terms in use 221 in LLNs can be found in "Terminology for Constrained-Node Networks" 222 [RFC7228]. 224 In particular, the following acronyms appear in the document: 226 DIO DODAG Information Object (a RPL message) 228 DIS DODAG Information Solicitation (a RPL message) 230 DODAG Destination-Oriented Directed Acyclic Graph 232 LLN Low-power and Lossy Network 233 LBR LLN Border Router 235 In addition, the document introduces the following concepts: 237 Sentinel One of the two roles that a node can play in RNFD. For a 238 given DODAG Version, a Sentinel node is the DODAG root's neighbor 239 that monitors the DODAG root's status. There are normally 240 multiple Sentinels for a DODAG root. However, being the DODAG 241 root's neighbor need not imply being Sentinel. 243 Acceptor The other of the two roles that a node can play in RNFD. 244 For a given DODAG Version, an Acceptor node is a node that is not 245 Sentinel. 247 Locally Observed DODAG Root's State (LORS) A node's local knowledge 248 of the DODAG root's status, specifying in particular whether the 249 DODAG root is up. 251 Conflict-Free Replicated Counter (CFRC) Conceptually represents a 252 dynamic set whose cardinality can be estimated. It defines a 253 partial order on its values and supports element addition and 254 union. The union operation is order- and duplicate-insensitive, 255 that is, idempotent, commutative, and associative. 257 3. Overview 259 As mentioned previously, LBRs are DODAG roots in RPL, and hence a 260 crash of an LBR is global in that it affects all nodes in the 261 corresponding DODAG. Therefore, each node running RNFD for a given 262 DODAG explicitly tracks the DODAG root's current condition, which is 263 referred to as Locally Observed DODAG Root's State (LORS), and 264 synchronizes its local knowledge with other nodes. 266 Since monitoring the condition of the DODAG root is performed by 267 tracking the status of its links (i.e., whether they are up or down), 268 it must be done by the root's neighbors; other nodes must accept 269 their observations. Consequently, depending on their roles, non-root 270 nodes are divided in RNFD into two disjoint groups: Sentinels and 271 Acceptors. A Sentinel node is the DODAG root's neighbor that 272 monitors its link with the root. The DODAG root thus normally has 273 multiple Sentinels but being its neighbor need not imply being 274 Sentinel. An Acceptor node is in turn a node that is not Sentinel. 275 Acceptors thus mainly collect and propagate Sentinels' observations. 276 More information on Sentinel selection can be found in Section 6.1. 278 3.1. Protocol State Machine 280 The possible values of LORS and transitions between them are depicted 281 in Figure 1. States "UP" and "GLOBALLY DOWN" can be attained by both 282 Sentinels and Acceptors; states "SUSPECTED DOWN" and "LOCALLY DOWN"-- 283 by Sentinels only. 285 +---------------------------------------------------------+ 286 | |---------------------------+ 3a | 287 | +-----------------+---------+ 3b | | 288 | | 2b | v v v 289 +-+----+-+ 1 +---------+-+ +-----------+ +-+------+-+ 290 | UP +---->+ SUSPECTED +---->+ LOCALLY +---->+ GLOBALLY | 291 | +<----+ DOWN | 2a | DOWN | 3c | DOWN | 292 +-+----+-+ 4a +-----------+ +-+---------+ +-+--------+ 293 ^ ^ | | 294 | | 4b | | 295 | +---------------------------+ 5 | 296 +--------------------------------------------------+ 298 Figure 1: RNFD States and Transitions 300 To begin with, when any node joins a DODAG Version, the DODAG root 301 must appear alive, so the node initializes RNFD with its LORS equal 302 to "UP". For a properly working DODAG root, the node remains in 303 state "UP". 305 However, when a node--acting as Sentinel--starts suspecting that the 306 root may have crashed, it changes its LORS to "SUSPECTED DOWN" 307 (transition 1 in Figure 1). The transition from "UP" to "SUSPECTED 308 DOWN" can happen based on the node's observations at either the data 309 plane, for instance, link-layer triggers about missing hop-by-hop 310 acknowledgments for packets forwarded over the node's link to the 311 root, or the control plane, for example, a significant growth in the 312 number of Sentinels already suspecting the root to be dead. In state 313 "SUSPECTED DOWN", the Sentinel node may verify its suspicion and/or 314 inform other nodes about the suspicion. When this has been done, it 315 changes its LORS to "LOCALLY DOWN" (transition 2a). In some cases, 316 the verification need not be performed and, as an optimization, a 317 direct transition from "UP" to "LOCALLY DOWN" (transition 2b) can be 318 done instead. 320 If sufficiently many Sentinels have their LORS equal to "LOCALLY 321 DOWN", all nodes--Sentinels and Acceptors--consent globally that the 322 DODAG root must have crashed and set their LORS to "GLOBALLY DOWN", 323 irrespective of the previous value (transitions 3a, 3b, and 3c). 324 State "GLOBALLY DOWN" is terminal in that the only transition any 325 node can perform from this to another state (transition 5) takes 326 place when the node joins a new DODAG version. When a node is in 327 state "GLOBALLY DOWN", RNFD forces RPL to maintain an infinite rank 328 and no parent, thereby preventing routing packets upward in the 329 DODAG. In other words, this state represents a situation in which 330 all non-root nodes agree that the current DODAG version is unusable, 331 and hence, to recover, the root has to give a proof of being alive by 332 initiating a new DODAG Version. 334 In contrast, if a node--either Sentinel or Acceptor--is in state 335 "UP", RNFD does not influence RPL's packet forwarding: a node can 336 route packets upward if it has a parent. The same is true for a 337 Sentinel node in states "SUSPECTED DOWN" and "LOCALLY DOWN". 338 Finally, while in any of the two states, a Sentinel node may observe 339 some activity of the DODAG root, and hence decide that its suspicion 340 is a mistake. In such a case, it returns to state "UP" (transitions 341 4a and 4b). 343 3.2. Counters and Communication 345 To enable arriving at a global conclusion that the DODAG root has 346 crashed (i.e., transiting to state "GLOBALLY DOWN"), all nodes count 347 locally and synchronize among each other the number of Sentinels 348 considering the root to be dead (i.e., those in state "LOCALLY 349 DOWN"). This process employs structures referred to as conflict-free 350 replicated counters (CFRCs). They are stored and modified 351 independently by each node and are disseminated throughout the 352 network in options added to RPL link-local control messages: DODAG 353 Information Objects (DIOs) and DODAG Information Solicitations 354 (DISs). Upon reception of such an option from its neighbor, a node 355 merges the received counter with its local one, thereby obtaining a 356 new content for its local counter. 358 The merging operation is idempotent, commutative, and associative. 359 Moreover, all possible counter values are partially ordered. This 360 enables ensuring eventual consistency of the counters acros all 361 nodes, irrespective of the particular sequence of merges, shape of 362 the DODAG, or general network topology. 364 Each node in RNFD maintains two CFRCs for a DODAG: 366 * PositiveCFRC, counting Sentinels that have considered or still 367 consider the root node as alive in the current DODAG Version, 369 * NegativeCFRC, counting Sentinels that have considered or still 370 consider the root node as dead in the current DODAG Version. 372 PositiveCFRC is always greater than or equal to the NegativeCFRC in 373 terms of the partial order defined for the counters. The difference 374 between the value of PositiveCFRC and the value of NegativeCFRC is 375 thus nonnegative and estimates the number of Sentinels that still 376 consider the DODAG root node as alive. 378 4. The RNFD Option 380 RNFD state synchronization between nodes takes place through the RNFD 381 Option. It is a new type of RPL Control Message Options that is 382 carried in link-local RPL control messages, notably DIOs and DISs. 383 Its main task is allowing the receivers to merge their two CFRCs with 384 the sender's CFRCs. 386 4.1. General CFRC Requirements 388 CFRCs in RNFD MUST support the following operations: 390 value(c) Returns a non-negative integer value corresponding to the 391 number of nodes counted by a given CFRC, c. 393 zero() Returns a CFRC that counts no nodes, that is, has its value 394 equal to 0. 396 self() Returns a CFRC that counts only the node executing the 397 operation. 399 infinity() Returns a CFRC that counts all possible nodes and 400 represents a special value, infinity. 402 merge(c1, c2) Returns a CFRC that is a union of c1 and c2 (i.e., 403 counts all nodes that are counted by either c1, c2, or both c1 and 404 c2). 406 compare(c1, c2) Returns the result of comparing c1 to c2. 408 saturated(c) Returns TRUE if a given CFRC, c, is saturated (i.e., no 409 more new nodes should be counted by it), or FALSE otherwise. 411 The partial ordering of CFRCs implies that the result of compare(c1, 412 c2) can be either: 414 * smaller, if c1 is ordered before c2 (i.e., c2 counts all nodes 415 that c1 counts and at least one node that c1 does not count); 417 * greater, if c1 is ordered after c2 (i.e., c1 counts all nodes that 418 c2 counts and at least one node that c2 does not count); 420 * equal, if c1 and c2 are the same (i.e., they count the same 421 nodes); 423 * incomparable, otherwise. 425 In particular, zero() is smaller than all other values and infinity() 426 is greater than any other value. 428 The properties of merging in turn can be formalized as follows for 429 any c1, c2, and c3: 431 * idempotence: c1 = merge(c1, c1); 433 * commutativity: merge(c1, c2) = merge(c2, c1); 435 * associativity: merge(c1, merge(c2, c3)) = merge(merge(c1, c2), 436 c3). 438 In particular, merge(c, zero()) always equals c while merge(c, 439 infinity()) always equals infinity(). 441 There are many algorithmic structures that can provide the 442 aforementioned properties of CFRC. Although in principle RNFD does 443 not rely on any specific one, the option adopts so-called linear 444 counting [Whang90]. 446 4.2. Format of the Option 448 The format of the RNFD Option conforms to the generic format of RPL 449 Control Message Options: 451 0 1 2 3 452 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 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Type = TBD1 | Option Length | | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 456 | | 457 + + 458 | PosCFRC, NegCFRC (Variable Length*) | 459 . . 460 . . 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 The '*' denotes that the fields have equal lengths of at least one 464 octet each. In effect, together they occupy at least two octets. 466 Figure 2: Format of the RNFD Option 468 Option Type TBD1 470 Option Length 8-bit unsigned integer. Denotes the length of the 471 option in octets excluding the Option Type and Option Length 472 fields. Its value MUST be even. A value of 0 denotes that RNFD 473 is disabled in the current DODAG Version. 475 PosCFRC, NegCFRC Two variable-length, octet-aligned bit arrays 476 carrying the sender's PositiveCFRC and NegativeCFRC, respectively. 478 The length of the arrays constituting the PosCFRC and NegCFRC fields 479 is the same and is derived from Option Length as follows. The value 480 of Option Length is divided by 2 to obtain the number of octets each 481 of the two arrays occupies. The resulting number of octets is 482 multiplied by 8 which yields an upper bound on the number of bits in 483 each array. As the actual bit length of each of the arrays, the 484 largest prime number less than the upper bound is assumed. For 485 example, if the value of Option Length is 16, then each array 486 occupies 8 octets, and its actual bit length is 61, as this is the 487 largest prime number less than 64. 489 Furthermore, for any bit equal to 1 in the NegCFRC, the bit with the 490 same index MUST be equal to 1 also in the PosCFRC. Any unused bits 491 (i.e., the bits beyond the actual bit length of each of the arrays) 492 MUST be equal to 0. Finally, if PosCFRC has all its bits equal to 1, 493 then NegCFRC MUST also have all its bits equal to 1. 495 The CFRC operations are defined for such bit arrays of a given length 496 as follows: 498 value(c) Returns the smallest integer value not less than -LT*ln(L0/ 499 LT), where ln() is the natural logarithm function, L0 is the 500 number of bits equal to 0 in the array corresponding to c and LT 501 is the bit length of the array. 503 zero() Returns an array with all bits equal to 0. 505 self() Returns an array with a single bit, selected uniformly at 506 random, equal to 1. 508 infinity() Returns an array with all bits equal to 1. 510 merge(c1, c2) Returns a bit array that constitutes a bitwise OR of 511 c1 and c2, that is, a bit in the resulting array is equal to 0 512 only if the same bit is equal to 0 in both c1 and c2. 514 compare(c1, c2) Returns: 516 * equal if each bit of c1 is equal to the corresponding bit of c2; 518 * less if c1 and c2 are not equal and, for each bit equal to 1 in 519 c1, the corresponding bit in c2 is also equal to 1; 521 * greater if c1 and c2 are not equal and, for each bit equal to 1 in 522 c2, the corresponding bit in c1 is also equal to 1; 524 * incomparable, otherwise. 526 saturated(c) Returns TRUE, if more than 63% of the bits in c are 527 equal to 1, or FALSE, otherwise. 529 5. RPL Router Behavior 531 Although RNFD operates largely independently of RPL, it does need 532 interact with RPL and the overall protocol stack. These interactions 533 are described next and can be realized, for instance, by means of 534 event triggers. 536 5.1. Joining a DODAG Version and Changing the RNFD Role 538 Whenever RPL running at a node joins a DODAG Version, RNFD--if 539 active--MUST assume for the node the role of Acceptor. Accordingly, 540 it MUST set its LORS to "UP" and its PositiveCFRC and NegativeCFRC to 541 zero(). 543 The role MAY then change between Acceptor and Sentinel at any time. 544 However, while a switch from Sentinel to Acceptor has no 545 preconditions, for a switch from Acceptor to Sentinel to be possible, 546 _all_ of the following conditions MUST hold: 548 1. LORS is "UP"; 550 2. saturated(PositiveCFRC) is FALSE; 552 3. a neighbor entry for the DODAG root is present in RPL's DODAG 553 parent set; 555 4. the neighbor is considered reachable via its link-local IPv6 556 address. 558 A role change also REQUIRES appropriate updates to LORS and CFRCs, so 559 that the node is properly accounted for. More specifically, when 560 changing its role from Acceptor to Sentinel, the node MUST add itself 561 to its PositiveCFRC as follows. It MUST generate a new CFRC value, 562 selfc = self(), and MUST replace its PositiveCFRC, denoted oldpc, 563 with newpc = merge(oldpc, selfc). In contrast, the effects of a 564 switch from Sentinel to Acceptor vary depending on the node's value 565 of LORS before the switch: 567 * for "GLOBALLY DOWN", the node MUST NOT modify its LORS, 568 PositiveCFRC, and NegativeCFRC; 570 * for "LOCALLY DOWN", the node MUST set its LORS to "UP" but MUST 571 NOT modify its PositiveCFRC and NegativeCFRC; 573 * for "UP" and "SUSPECTED DOWN", the node MUST set its LORS to "UP", 574 MUST NOT modify it PositiveCFRC, but MUST add itself to 575 NegativeCFRC, that is, replace its NegativeCFRC, denoted oldnc, 576 with newnc = merge(oldnc, selfc), where selfc is the counter 577 generated with self() when the node last added itself to its 578 PositiveCFRC. 580 5.2. Detecting and Verifying Problems with the DODAG Root 582 Only nodes that are Sentinels take active part in detecting crashes 583 of the DODAG Root; Acceptors just disseminate their observations, 584 reflected in the CFRCs. 586 The DODAG root monitoring SHOULD be based on both internal inputs, 587 notably the values of CFRCs and LORS, and external inputs, such as 588 triggers from RPL and other protocols. External input monitoring 589 SHOULD be performed preferably in a reactive fashion, also 590 independently of RPL, and at both data plane and control plane. In 591 particular, it is RECOMMENDED that RNFD be directly notified of 592 events relevant to the routing adjacency maintenance mechanisms on 593 which RPL relies, such as Layer 2 triggers [RFC5184] or the Neighbor 594 Unreachability Detection [RFC4861] mechanism. Only events concerning 595 the DODAG root need be monitored to this end. For example, RNFD can 596 conclude that there may be problems with the DODAG root if it 597 observes a lack of multiple consecutive L2 acknowledgments for 598 packets transmitted by the node via the link to the DODAG root. 599 Internally, in turn, it is RECOMMENDED that RNFD take action whenever 600 there is a change to its local CFRCs, so that a node can have a 601 chance to participate in detecting potential problems even when 602 normally it would not exchange packets over the link with the DODAG 603 root during some period. In particular, RNFD SHOULD conclude that 604 there may be problems with the DODAG root, when the fraction 605 value(NegativeCFRC)/value(PositiveCFRC) has grown by at least 606 RNFD_SUSPICION_GROWTH_THRESHOLD since the node last set its LORS to 607 "UP". 609 Whenever having its LORS set to "UP" RNFD concludes--based on either 610 external or internal inputs--that there may be problems with the link 611 with the DODAG root, it MUST set its LORS to either "SUSPECTED DOWN" 612 or, as an optimization, to "LOCALLY DOWN". 614 The "SUSPECTED DOWN" value of LORS is temporary: its aim is to give 615 RNFD an additional opportunity to verify whether the link with the 616 DODAG root is indeed down. Depending on the outcome of such 617 verification, RNFD MUST set its LORS to either "UP", if the link has 618 been confirmed not to be down, or "LOCALLY DOWN", otherwise. The 619 verification can be performed, for example, by transmitting RPL DIS 620 or ICMPv6 Echo Request messages to the DODAG root's link-local IPv6 621 address and expecting replies confirming that the root is up and 622 reachable through the link. Care SHOULD be taken not to overload the 623 DODAG root with traffic due to simultaneous probes, for instance, 624 random backoffs can be employed to this end. It is RECOMMENDED that 625 the "SUSPECTED DOWN" value of LORS is attained and verification takes 626 place if RNFD's conclusion on the state of the DODAG root is based 627 only on indirect observations, for example, the aforementioned growth 628 of the CFRC values. In contrast, for direct observations, such as 629 missing L2 acknowledgments, the verification MAY be skipped, with the 630 node's LORS effectively changing from "UP" directly to "LOCALLY 631 DOWN". 633 For consistency with RPL, when detecting potential problems with the 634 DODAG root, RNFD also MUST make use of RPL's independent knowledge. 635 More specifically, a node MUST switch its LORS from "UP" or 636 "SUSPECTED DOWN" directly to "LOCALLY DOWN" if a neighbor entry for 637 the DODAG root is removed from RPL's DODAG parent set or the neighbor 638 ceases to be considered reachable via its link-local IPv6 address. 640 Finally, while having its LORS already equal to "LOCALLY DOWN", a 641 node may make an observation confirming that its link with the DODAG 642 root is actually up. In such a case, it SHOULD set its LORS back to 643 "UP" but MUST NOT do this before the previous conditions 2-4 644 necessary for a node to change its role from Acceptor to Sentinel all 645 hold. 647 To appropriately account for the node's observations on the state of 648 the DODAG root, the aforementioned LORS transitions are accompanied 649 by changes to the node's local CFRCs as follows. Changes between 650 "UP" and "SUSPECTED DOWN" do not affect any of the two CFRCs. During 651 a switch from "UP" or "SUSPECTED DOWN" to "LOCALLY DOWN", in turn, 652 the node MUST add itself to its NegativeCFRC, as explained 653 previously. By symmetry, a transition from "LOCALLY DOWN" to "UP" 654 REQUIRES the node to add itself to its PositiveCFRC, again, as 655 explained previously. 657 5.3. Disseminating Observations and Reaching Agreement 659 Nodes disseminate their observations by exchanging CFRCs in the RNFD 660 Options embedded in link-local RPL control messages, notably DIOs and 661 DISs. When processing such a received option, a node--acting as 662 Sentinel or Acceptor--MUST update its PositiveCFRC and NegativeCFRC 663 to respectively newpc = merge(oldpc, recvpc) and newnc = merge(oldnc, 664 recvnc), where oldpc and oldnc are the values of the node's 665 PositiveCFRC and NegativeCFRC before the update, while recvpc and 666 recvnc are the received values of option fields PosCFRC and NegCFRC, 667 respectively. 669 In effect, the node's value of fraction 670 value(NegativeCFRC)/value(PositiveCFRC) may change. If the fraction 671 reaches at least RNFD_CONSENSUS_THRESHOLD (with value(PositiveCFRC) 672 being greater than zero), then the node consents on the DODAG root 673 being down. Accordingly, it MUST change its LORS to "GLOBALLY DOWN" 674 and set its PositiveCFRC and NegativeCFRC both to infinity(). 676 The "GLOBALLY DOWN" value of LORS is terminal: the node MUST NOT 677 change it and MUST NOT modify its CFRCs until it joins a new DODAG 678 Version. With this value of LORS, RNFD at the node MUST also prevent 679 RPL from having any DODAG parent and advertising any Rank other than 680 INFINITE_RANK. 682 Since the RNFD Option is embedded, among others, in RPL DIO control 683 messages, updates to a node's CFRCs may affect the sending schedule 684 of these messages, which is driven by the DIO Trickle timer 685 [RFC6206]. It is RECOMMENDED to use for RNFD a dedicated Trickle 686 timer, different from RPL's DIO Trickle timer. In such a setting, 687 whenever RNFD's timer fires and no DIO message containing the RNFD 688 Option has been sent to the link-local all-RPL-nodes multicast IPv6 689 address since the previous firing, the node sends a DIO message 690 containing the RNFD Option to the address. In contrast, in the 691 absence of a dedicated Trickle timer for RNFD, an implementation 692 SHOULD ensure that the RNFD Option is present in multicast DIO 693 messages sufficiently often to quickly propagate changes to the 694 node's CFRCs. In either case, a node MUST reset its Trickle timer 695 when it changes its LORS to "GLOBALLY DOWN", so that information 696 about the detected crash of the DODAG root is disseminated in the 697 DODAG fast. Likewise, a node SHOULD reset its Trickle timer when any 698 of its local CFRCs changes significantly. 700 5.4. DODAG Root's Behavior 702 The DODAG root node MUST assume the role of Acceptor in RNFD and MUST 703 NOT ever switch this role. It MUST also monitor its LORS and local 704 CFRCs, so that it can react to various events. 706 To start with, the DODAG root MUST generate a new DODAG Version, 707 thereby restarting the protocol, if it changes its LORS to "GLOBALLY 708 DOWN", which may happen when the root has restarted after a crash or 709 the nodes have falsely detected its crash. It MAY also generate a 710 new DODAG Version if fraction value(NegativeCFRC)/value(PositiveCFRC) 711 approaches RNFD_CONSENSUS_THRESHOLD, so as to avoid potential 712 interruptions to routing. 714 Furthermore, the DODAG root SHOULD either generate a new DODAG 715 Version or increase the bit length of its CFRCs if 716 saturated(PositiveCFRC) becomes TRUE. This is a self-regulation 717 mechanism that helps adjust the CFRCs to a potentially large number 718 of Sentinels (see Section 6.1). 720 In general, issuing a new DODAG Version effectively restarts RNFD. 721 The DODAG root MAY thus perform this operation also in other 722 situations. 724 5.5. Activating and Deactivating the Protocol on Demand 726 RNFD CAN be activated and deactivated on demand, once per DODAG 727 Version. The particular policies for activating and deactivating the 728 protocol are outside the scope of this document. However, the 729 activation and deactivation SHOULD be done at the DODAG root node; 730 other nodes MUST comply. 732 More specifically, when a non-root node joins a DODAG Version, RNFD 733 at the node is initially inactive. The node MUST NOT activate the 734 protocol unless it receives for this DODAG Version a valid RNFD 735 Option containing some CFRCs, that is, having its Option Length field 736 positive. In particular, if the option accompanies the message that 737 causes the node to join the DODAG Version, the protocol SHOULD be 738 active from the moment of the joining. RNFD then remains active at 739 the node until it is explicitly deactivated or the node joins a new 740 DODAG Version. An explicit deactivation MUST take place when the 741 node receives an RNFD Option for the DODAG Version with no CFRCs, 742 that is, having its Option Length field equal to zero. When 743 explicitly deactivated, RNFD MUST NOT be reactivated unless the node 744 joins a new DODAG Version. In particular, when the first RNFD Option 745 received by the node has its Option Length field equal to zero, the 746 protocol MUST remain deactivated for the entire time the node belongs 747 to the current DODAG Version. 749 When RNFD at a node is initially inactive for a DODAG Version, the 750 node MUST NOT attach any RNFD Option to the messages it sends (in 751 particular, because it may not know the desired CFRC length--see 752 Section 5.6). When the protocol has been explicitly deactivated, the 753 node MAY also decide not to attach the option to its outgoing 754 messages. However, it is RECOMMENDED that it sends sufficiently many 755 messages with the option to the link-local all-RPL-nodes multicast 756 IPv6 address to allow its neighbors to learn that RNFD has been 757 deactivated in the current DODAG version. In particular, it MAY 758 reset its Trickle timer to this end but also MAY use some reactive 759 mechanisms, for example, replying with a unicast DIO or DIS 760 containing the RNFD Option with no CFRCs to a message from a neighbor 761 that contains the option with some CFRCs, as such a neighbor appears 762 not to have learned about the deactivation of RNFD. 764 5.6. Processing CFRCs of Incompatible Lengths 766 The merge() and compare() operations on CFRCs require both arguments 767 to be compatible, that is, to have the same bit length. However, the 768 processing rules for the RNFD Option (see Section 4.2) do not 769 necessitate this. This fact is made use of not only in the 770 mechanisms for activating and deactivating the protocol (see 771 Section 5.5), but also in mechanisms for dynamic adjustments of 772 CFRCs, which aim to enable deployment-specific policies (see 773 Section 6.1). A node thus MUST be prepared to receive the RNFD 774 Option with fields PosCFRC and NegCFRC of a different bit length than 775 the node's own PositiveCFRC and NegativeCFRC. Assuming that it has 776 RNFD active and that fields PosCFRC and NegCFRC in the option have a 777 positive length, the node MUST react as follows. 779 If the bit length of fields PosCFRC and NegCFRC is the same as that 780 of the node's local PositiveCFRC and NegativeCFRC, then the node MUST 781 perform the merges, as detailed previously (see Section 5.3). 783 If the bit length of fields PosCFRC and NegCFRC is smaller than that 784 of the node's local PositiveCFRC and NegativeCFRC, then the node MUST 785 ignore the option and MAY reset its Trickle timer. 787 If the bit length of fields PosCFRC and NegCFRC is greater than that 788 of the node's local PositiveCFRC and NegativeCFRC, then the node MUST 789 extend the bit length of its local CFRCs to be equal to that in the 790 option and set the CFRCs as follows: 792 * If the node's LORS is "GLOBALLY DOWN", then both its local CFRCs 793 MUST be set to infinity(). 795 * Otherwise, they both MUST be set to zero(), and the node MUST 796 account for itself in so initialized CFRCs. More specifically, if 797 the node is Sentinel, then it MUST add itself to its PositiveCFRC, 798 as detailed previously. In addition, if its LORS is "LOCALLY 799 DOWN", then it MUST also add itself to its NegativeCFRC, again, as 800 explained previously. Finally, the node MUST perform merges of 801 its local CFRCs and the ones received in the option (see 802 Section 5.3) and MAY reset its Trickle timer. 804 In contrast, if the node is unable to extend its local CFRCs, for 805 example, because it lacks resources, then it MUST stop participating 806 in RNFD, that is, until it joins a new DODAG Version, it MUST NOT 807 send the RNFD Option and MUST ignore this option in received 808 messages. 810 5.7. Summary of RNFD's Interactions with RPL 812 In summary, RNFD interacts with RPL in the following manner: 814 * While having its LORS equal to "GLOBALLY DOWN", RNFD prevents RPL 815 from routing packets and advertising upward routes in the 816 corresponding DODAG (see Section 5.3). 818 * In some scenarios, RNFD triggers RPL to issue a new DODAG Version 819 (see Section 5.4). 821 * Depending on the implementation, RNFD may cause RPL's DIO Trickle 822 timer resets (see Section 5.3, Section 5.5, and Section 5.6). 824 * RNFD monitors events relevant to routing adjacency maintenance as 825 well as those affecting RPL's DODAG parent set (see Section 5.1 826 and Section 5.2). 828 * Using RNFD entails embedding the RNFD Option into link-local RPL 829 control messages (see Section 4.2). 831 5.8. Summary of RNFD's Constants 833 The following is a summary of RNFD's constants: 835 RNFD_SUSPICION_GROWTH_THRESHOLD A threshold concerning the value of 836 fraction value(NegativeCFRC)/value(PositiveCFRC). If the value at 837 a Sentinel node grows at least by this threshold since the time 838 the node's LORS was last set to "UP", then the node's LORS is set 839 to "SUSPECTED DOWN" or "LOCALLY DOWN", which implies that the node 840 suspects or assumes a crash of the DODAG root (see Section 5.2). 841 The default value of the threshold is 0.12. The higher the value 842 the longer the detection period but the lower risk of increased 843 traffic due suspicion verification. 845 RNFD_CONSENSUS_THRESHOLD A threshold concerning the value of 846 fraction value(NegativeCFRC)/value(PositiveCFRC). If the value at 847 a Sentinel or Acceptor node reaches the threshold, then the node's 848 LORS is set to "GLOBALLY DOWN", which implies that consensus has 849 been reached on the DODAG root node being down (see Section 5.3). 850 The default value of the threshold is 0.51. The higher the value 851 the longer the detection period but the lower the risk of false 852 positives. 854 The means of configuring the constants at individual nodes are 855 outside the scope of this document. 857 6. Manageability Considerations 859 RNFD is largely self-managed, with the exception of protocol 860 activation and deactivation, as well as node role assignment and the 861 related CFRC size adjustment, for which only the aforementioned 862 mechanisms are defined, so as to enable adopting deployment-specific 863 policies. This section outlines some of the possible policies. 865 6.1. Role Assignment and CFRC Size Adjustment 867 One approach to node role and CFRC size selection is to manually 868 designate specific nodes as Sentinels in RNFD, assuming that they 869 will have chances to satisfy the necessary conditions for attaining 870 this role (see Section 5.1), and fixing the CFRC bit length to 871 accommodate these nodes. 873 Another approach is to automate the selection process: in principle, 874 any node satisfying the necessary conditions for becoming Sentinel 875 (see Section 5.1) can attain this role. However, in networks where 876 the DODAG root node has many neighbors, this approach may lead to 877 saturated(PositiveCFRC) quickly becoming TRUE, which--without 878 additional measures--may degrade RNFD's performance. This issue can 879 be handled with a probabilistic solution: if PositiveCFRC becomes 880 saturated with little or no increase in NegativeCFRC, then a new 881 DODAG Version can be issued and a node satisfying the necessary 882 conditions can become Sentinel in this version only with probability 883 1/2. This process can be continued with the probability being halved 884 in each new DODAG Version until PositiveCFRC is no longer quickly 885 saturated. Another solution is to increase, potentially multiple 886 times the bit length of the CFRCs by the DODAG root if PositiveCFRC 887 becomes saturated with little or no growth in NegativeCFRC, which 888 does not require issuing a new DODAG Version but lengthens the RNFD 889 Option. In this way, again, a sufficient bit length can be 890 dynamically discovered or the root can conclude that a given bit 891 length is excessive for (some) nodes and resort to the previous 892 solution. Increasing the bit length can be done, for instance, by 893 doubling it, respecting the condition that it has to be a prime 894 number (see Section 4.2). 896 In either of the solutions, Sentinel nodes SHOULD preferably be 897 stable themselves and have stable links to the DODAG root. 898 Otherwise, they may often exhibit LORS transitions between "UP" and 899 "LOCALLY DOWN" or switches between Acceptor and Sentinel roles, which 900 gradually saturates CFRCs. Although as a mitigation the number of 901 such transitions and switches per node MAY be limited, having 902 Sentinels stable SHOULD be preferred. 904 6.2. Virtual DODAG Roots 906 RPL allows a DODAG to have a so-called virtual root, that is, a 907 collection of nodes coordinating to act as a single root of the 908 DODAG. The details of the coordination process are left open in the 909 specification [RFC6550] but, from RNFD's perspective, two possible 910 realizations are worth consideration: 912 * Just a single (primary) node of the nodes comprising the virtual 913 root acts as the actual root of the DODAG. Only when this node 914 fails, does another (backup) node take over. As a result, at any 915 time, at most one of the nodes comprising the virtual root is the 916 actual root. 918 * More than one of the nodes comprising the virtual root act as 919 actual roots of the DODAG, all advertising the same Rank in the 920 DODAG. When some of the nodes fail, the other nodes may or may 921 not react in any specific way. In other words, at any time, more 922 than one node can be the actual root. 924 In the first realization, RNFD's operation is largely unaffected. 925 The necessary conditions for a node to become Sentinel (Section 5.1) 926 guarantee that only the current primary root node is monitored by the 927 protocol. This SHOULD be taken into account in the policies for node 928 role assignment, CFRC size selection, and, possibly, the setting of 929 the two thresholds (Section 5.8). Moreover, when a new primary has 930 been elected, to avoid polluting CFRCs with observations on the 931 previous primary, it is RECOMMENDED to issue a new DODAG Version, 932 especially if the new primary has different neighbors compared to the 933 old one. 935 In the second realization, the fact that the virtual root consists of 936 multiple nodes is transparent to RNFD. Therefore, employing RNFD is 937 such a setting can be beneficial only if the nodes comprising the 938 virtual root may suffer from correlated crashes, for instance, due to 939 global power outages. 941 7. Security Considerations 943 RNFD is an extension to RPL and is thus both vulnerable to and 944 benefits from the security issues and solutions described in 945 [RFC6550] and [RFC7416]. Its specification in this document does not 946 introduce new traffic patterns or new messages, for which specific 947 mitigation techniques would be required beyond what can already be 948 adopted for RPL. 950 In particular, RNFD depends on information exchanged in the RNFD 951 Option. If the contents of this option were compromised, then 952 failure misdetection may occur. One possibility is that the DODAG 953 root may be falsely detected as crashed, which would result in an 954 inability of the nodes to route packets, at least until a new DODAG 955 Version is issued by the root. Another possibility is that a crash 956 of the DODAG root may not be detected by RNFD, in which case RPL 957 would have to rely on its own mechanisms. Moreover, compromising the 958 contents of the RNFD Option may also lead to increased traffic due to 959 DIO Trickle timer resets. Consequently, RNFD deployments are 960 RECOMMENDED to use RPL security mechanisms if there is a risk that 961 control information might be modified or spoofed. 963 In this context, RNFD's two features are worth highlighting. First, 964 unless a DODAG root's all neighbors are compromised, a false positive 965 can always be detected by the root based on its local CFRCs. If the 966 frequency of such false positives becomes problematic, RNFD can be 967 disabled altogether, for instance, until the problem has been 968 diagnosed. This procedure can be largely automated at LBRs. Second, 969 some types of false negatives can also be detected this way. Those 970 that pass undetected, in turn, are likely not to have major negative 971 consequences on RPL apart from the lack of improvement to its 972 performance upon a DODAG root's crash, at least if RPL's other 973 components are not attacked as well. 975 8. IANA Considerations 977 To represent the RNFD Option, IANA is requested to allocate the value 978 TBD1 from the "RPL Control Message Options" sub-registry 979 (https://www.iana.org/assignments/rpl/rpl.xhtml#control-message- 980 options) of the "Routing Protocol for Low Power and Lossy Networks 981 (RPL)" registry. 983 9. Acknowledgements 985 The authors would like to acknowledge Piotr Ciolkosz and Agnieszka 986 Paszkowska. Agnieszka contributed to deeper understanding and 987 formally proving various aspects of RPL's behavior upon an LBR crash. 988 Piotr in turn developed a prototype implementation of RNFD dedicated 989 for RPL to verify earlier performance claims. 991 _TODO_ More likely to follow. 993 10. References 995 10.1. Normative References 997 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 998 Requirement Levels", BCP 14, RFC 2119, 999 DOI 10.17487/RFC2119, March 1997, 1000 . 1002 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 1003 "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, 1004 March 2011, . 1006 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1007 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1008 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1009 Low-Power and Lossy Networks", RFC 6550, 1010 DOI 10.17487/RFC6550, March 2012, 1011 . 1013 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 1014 Power and Lossy Networks (RPL) Option for Carrying RPL 1015 Information in Data-Plane Datagrams", RFC 6553, 1016 DOI 10.17487/RFC6553, March 2012, 1017 . 1019 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1020 Routing Header for Source Routes with the Routing Protocol 1021 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1022 DOI 10.17487/RFC6554, March 2012, 1023 . 1025 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1026 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1027 May 2017, . 1029 10.2. Informative References 1031 [Ciolkosz19] 1032 Ciolkosz, P., "Integration of the RNFD Algorithm for 1033 Border Router Failure Detection with the RPL Standard for 1034 Routing IPv6 Packets", Master's Thesis, University of 1035 Warsaw, 2019. 1037 [Iwanicki16] 1038 Iwanicki, K., "RNFD: Routing-layer detection of DODAG 1039 (root) node failures in low-power wireless networks", 1040 In IPSN 2016: Proceedings of the 15th ACM/IEEE 1041 International Conference on Information Processing in 1042 Sensor Networks, IEEE, pp. 1--12, 1043 DOI 10.1109/IPSN.2016.7460720, 2016, 1044 . 1046 [Paszkowska19] 1047 Paszkowska, A. and K. Iwanicki, "Failure Handling in RPL 1048 Implementations: An Experimental Qualitative Study", In 1049 Mission-Oriented Sensor Networks and Systems: Art and 1050 Science (Habib M. Ammari ed.), Springer International 1051 Publishing, pp. 49--95, DOI 10.1007/978-3-319-91146-5_3, 1052 2019, . 1054 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1055 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1056 DOI 10.17487/RFC4861, September 2007, 1057 . 1059 [RFC5184] Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K. 1060 Mitani, "Unified Layer 2 (L2) Abstractions for Layer 3 1061 (L3)-Driven Fast Handover", RFC 5184, 1062 DOI 10.17487/RFC5184, May 2008, 1063 . 1065 [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, 1066 "Known Issues and Best Practices for the Use of Long 1067 Polling and Streaming in Bidirectional HTTP", RFC 6202, 1068 DOI 10.17487/RFC6202, April 2011, 1069 . 1071 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 1072 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 1073 2014, . 1075 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1076 Constrained-Node Networks", RFC 7228, 1077 DOI 10.17487/RFC7228, May 2014, 1078 . 1080 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 1081 and M. Richardson, Ed., "A Security Threat Analysis for 1082 the Routing Protocol for Low-Power and Lossy Networks 1083 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 1084 . 1086 [Whang90] Whang, K.-Y., Vander-Zanden, B.T., and H.M. Taylor, "A 1087 Linear-time Probabilistic Counting Algorithm for Database 1088 Applications", In ACM Transactions on Database Systems, 1089 DOI 10.1145/78922.78925, 1990, 1090 . 1092 Author's Address 1093 Konrad Iwanicki 1094 University of Warsaw 1095 Banacha 2 1096 02-097 Warszawa 1097 Poland 1099 Phone: +48 22 55 44 428 1100 Email: iwanicki@mimuw.edu.pl