idnits 2.17.1 draft-jadhav-lwig-nbr-mgmt-policy-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 23, 2017) is 2468 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-11 == Outdated reference: A later version (-15) exists of draft-ietf-6tisch-minimal-security-03 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LWIG R. Jadhav, Ed. 3 Internet-Draft R. Sahoo 4 Intended status: Informational Huawei 5 Expires: January 24, 2018 S. Duquennoy 6 Inria 7 J. Eriksson 8 Yanzi Networks 9 July 23, 2017 11 Neighbor Management Policy for 6LoWPAN 12 draft-jadhav-lwig-nbr-mgmt-policy-01 14 Abstract 16 This document describes the problems associated with neighbor cache 17 management in constrained multihop networks and a sample neighbor 18 management policy to deal with it. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 24, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language and Terminology . . . . . . . . . . 4 56 2. Neighbor Management . . . . . . . . . . . . . . . . . . . . . 5 57 2.1. Significance of Neighbor management policy . . . . . . . 5 58 2.2. Trivial neighbor management policies . . . . . . . . . . 6 59 2.3. Lifecycle of a NCE . . . . . . . . . . . . . . . . . . . 7 60 2.3.1. NCE Insertion . . . . . . . . . . . . . . . . . . . . 7 61 2.3.2. NCE Deletion . . . . . . . . . . . . . . . . . . . . 10 62 2.3.3. NCE Eviction . . . . . . . . . . . . . . . . . . . . 11 63 2.3.3.1. Eviction for directly connected routing entries . 11 64 2.3.4. NCE Reinforcement . . . . . . . . . . . . . . . . . . 12 65 2.4. Requirements of a good neighbor management policy . . . . 12 66 2.5. Approaches to neighbor management policy . . . . . . . . 12 67 2.5.1. Reactive Approach . . . . . . . . . . . . . . . . . . 13 68 2.5.2. Proactive Approach . . . . . . . . . . . . . . . . . 13 69 3. Reservation based Neighbor Management Policy . . . . . . . . 14 70 3.1. Limitations of such a policy . . . . . . . . . . . . . . 15 71 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 76 7.2. Informative References . . . . . . . . . . . . . . . . . 16 77 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 17 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 80 1. Introduction 82 In a wireless multihop network, the node densities (maximum number of 83 devices connected on a single hop) may vary significantly depending 84 upon deployments/scenarios. While there is some policy control 85 possible with regards to the network size in terms of maximum number 86 of devices connected, it is especially difficult to set a figure on 87 what will be the maximum node density given a deployment. For e.g. 88 A network can put an upper limit on max 1000 devices but it is 89 impossible to state what the node density will be in this 1000 node 90 network. 92 A neighbor cache is used for populating neighboring one-hop connected 93 nodes information such as MAC address, link local IP address and 94 other reachability state information. Node density has direct 95 implications on the neighbor cache and in constrained network 96 scenario the size of the neighbor cache will be limited. Thus there 97 are chances that a node may not be able to fit all the neighboring 98 nodes in its cache in which case it has to prioritize entries and 99 thus needs a neighbor management policy. 101 This draft presents problems related to neighbor management policies 102 by considering a security-enabled multi-hop 6lo network. This 103 document considers RPL [RFC6550] as a routing protocol and PANA (EAP- 104 PANA) [RFC5191] as a network access protocol. For RPL, both the 105 storing and non-storing mode of operations are considered. We also 106 provide a sample neighbor management policy which can be used in such 107 networks and its limitations. The aim of such a policy is to retain 108 set of neighbor cache entries with high quality links such that 109 routing adjacencies are stablized. 111 The problem statement and the proposed solution described is also 112 relevant to other multihop constrained scenarios such as 6TiSCH 113 [I-D.ietf-6tisch-architecture]. [I-D.ietf-6tisch-minimal-security] 114 talks about a pledge (new joinee) node authenticating via a Join 115 Proxy. The considerations mentioned in this document are applicable 116 for such networks as well. 118 +--------+ 119 | PAA/ | 120 +------| Auth | 121 | | Server | 122 | +--------+ 123 +------------|-------------+ 124 | | | 125 | (BR) | 126 | / \ | 127 | / \ | 128 | / \ | 129 | (N1) (N2) | 130 | / : / \ | 131 | / : / \ | 132 | / : / \ | 133 | (N8) (N3) (N4) | 134 | : / \ : | 135 | : / \ : | 136 | : / \ : | 137 | (N5) (New) | 138 | / \ | 139 | / \ | 140 | / \ | 141 | (N6) (N7) | 142 | | 143 | 6Lo Network | 144 +--------------------------+ 146 Figure 1: Sample Topology 148 1.1. Requirements Language and Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [RFC2119]. 154 PaC (PANA Client): New joining node which is yet to be authenticated. 156 PRE (PANA Relay Element): An already authenticated and network joined 157 node which is willing to act as a relay element for PaCs to complete 158 their authentication procedure on multi-hop networks. [RFC6345] 159 describes the details of PRE. 161 PAA (PANA Auth Agent): Auth server which hosts the credentials 162 database. PaC will handshake with PAA to complete authentication 163 procedure. 165 Routing Child: A downstream node who is part of the routing table of 166 the parent. For e.g. in the sample topology above N5 is the directly 167 connected routing child for N3. N6 and N7 are also part of N3 168 routing table, they are routing child nodes but not directly 169 connected. For N6 and N7 the document might alternatively use a term 170 grand-child. 172 Routing Parent: In Figure 1, N1 and N2 are possible routing parents 173 for N3. 175 Neighbor Cache Entry (NCE): A neighbor entry managed on behalf of 176 directly connected peer. 178 This document also uses terminology described in [RFC6550] and 179 [RFC6775]. 181 2. Neighbor Management 183 2.1. Significance of Neighbor management policy 185 Multihop mesh networks present unique challenges to neighbor 186 management especially with resource constrained nodes. In cases 187 where the node density is higher that the neighbor cache size, the 188 entries have to be prioritized. [Woo_et_al] and [Dawans_et_al] talk 189 about prioritization of neighbor entries by using link quality 190 estimation techniques. But prioritization alone may not necessarily 191 be optimal in all cases. The reason or function why neighbor entry 192 was added also needs to be taken in consideration. For example, 193 evicting a routing direct child might have a ripple effect in turn 194 impacting all the sub-childs as well. 196 In case of key management protocols deployed above MAC layer in 197 multihop network, the neighbor management kicks in early even before 198 the routing adjacencies are established. Since a new joining node 199 needs to discover/attach to a relay element for completing its 200 authentication procedure, the neighbor cache entries have to be 201 appropriately populated both on a PaC and on the PRE. If a neighbor 202 entry whose authentication is in progress is evicted, it will 203 negatively impact the authentication procedure. 205 Another important consideration is that with increased node density, 206 the prioritization based on link estimation parameters might not help 207 since there might be more well connected peers. In dense deployments 208 the number of directly attached neighbors with good quality links 209 might still be higher than the max entries in neighbor cache size. 211 2.2. Trivial neighbor management policies 213 This section investigates policies which are used by most of the 214 current operating systems for constrained nodes. While such policies 215 are trivial to implement they may not be able to deal with the 216 constrained network scenario. Note that such policies can still be 217 used if it is known apriori that the neighbor cache can hold entries 218 for maximum node density. 220 a. First Come First Serve (FCFS) policy 222 b. Least Recently Used (LRU) policy 224 The primary distinction between these policies is how it treats a new 225 entry when the neighbor cache is full. In case of FCFS policy, the 226 new entry is simply rejected while with LRU, the new entry replaces 227 the least recently used entry. 229 RPL works by initiating a downstream multicast DIO to establish 230 upstream network path. Subsequently DAO messages might be sent by 231 the nodes to establish downstream paths to the nodes. Thus the 232 network is flooded with multicast DIO messages initially and 233 similarly there are chances that the same node is ended up been 234 selected as a preferred parent by most of the child nodes and thus 235 receives a DAO message from all these child nodes. Note that once a 236 node establishes a parent entry or a routing entry on behalf of a 237 directly connected node then it has to also provision a neighbor 238 cache entry for it for subsequent unicast traffic. 240 In case of FCFS policy, a node might end up hosting all the neighbor 241 entries based on DIO or DAO messages. Once the cache is full all the 242 subsequent attempts to add an NCE will fail. 244 In case of LRU policy, a node might end up churning lot of neighbor 245 entries because once the cache gets full and there is a request for 246 new entry, it would result in evicting the least recently used (but 247 active) entry. If at later point of time, there is a traffic for the 248 evicted entry then the old entry has to be reinstated using IPv6 NDP 249 procedure. This would mean reinstating the entry by evicting another 250 least recently used entry. If the node density is very high, then 251 this churn would be substantially high to extent that it would 252 disrupt any routing adjacencies to be established in the network in a 253 stable way. 255 2.3. Lifecycle of a NCE 257 2.3.1. NCE Insertion 259 IPv6 NDP [RFC6775] defines signaling involved in resolving the IPv6 260 addresses to its corresponding MAC addresses which gets populated in 261 the neighbor cache. In case of constrained network, it is desired 262 that such control traffic is minimized and thus the neighbor cache 263 entries are populated as part of existing messaging. One example 264 would be when the node receives a DAO message from its immediate 265 child node, it not only makes an addition to the routing table but 266 also creates a neighbor cache entry for the node. Thus it eliminates 267 need for additional IPv6 NDP NS/NA messaging involved to resolve MAC 268 address. Similar hueristic is used to add neighbor entries in other 269 cases as well. Section 10.3.2 of [RFC6775] describes update and 270 addition of such NCEs based on roting information packets. 272 Following are the possible signaling scenarios in which case a 273 neighbor entry may get added. 275 Node Joining procedure: A new joinee node discovers a relay element 276 to initiate its auth procedure. At the end of the discovery phase 277 the new joinee node would have known the link local IP address of the 278 relay element. The joinee node will send an unsecured-NS to the 279 relay element to solicit its NA. The PRE may send a NA with the 280 suitable status code as defined in section 6.5.3 of [RFC6775]. 282 RPL 283 New PRE Parent PAA 284 | | | | 285 | PRE Disc | | | 286 |<----------->| | | 287 | | | | 288 | UNSEC-NS | | | 289 |------------>| | | 290 | | | | 291 | addNCE(new,reason=PANA)| | 292 | | | | 293 | UNSEC-NA(status) | | 294 |<------------| | | 295 | | | | 296 addNCE(PRE,reason=PANA) | | 297 | | | | 298 | PCI | | | 299 |------------>| | | 300 | | | | 301 | | AUTHPROC | | 302 |<----------->|<----------------------->| 303 | | | | 305 Figure 2: NCE creation between PaC and PRE during relay discovery 306 process 308 Relay element does not hold any state information on behalf of the 309 new joinee node except for its neighbor cache entry. Thus in the 310 Figure 1 the new joinee node may select node N3 as its PRE, in which 311 case N3 has to add a neighbor entry on behalf of the new joinee node. 313 Post authentication the node enters into network discovery phase. 314 The node selects one or more of its neighboring peer as its preferred 315 parent based on the DIO received from these peers. Note that the 316 node's selected relay element and its preferred parent may not be 317 same. The preferred parent serves as a default router node to which 318 all its upstream traffic is directed. Thus an NCE on behalf of 319 preferred parent needs to be added. In Figure 1 node N5 selects N3 320 as its preferred parent. N5 needs to add neighbor entry on behalf of 321 N3 which is its directly connected RPL preferred parent. 323 In case of RPL storing MOP (mode of operation), the node may send a 324 DAO message containing its reachability information to its preferred 325 parent. The parent node in turn may pass this information upstream 326 to its parent by generating a DAO retaining the child node's 327 reachability information, establishing a downstream routing path 328 towards the node who originated the DAO. The preferred parent has to 329 maintain a neighbor entry on behalf of the directly connected child 330 node. For example, in the Figure 1, node N3 needs to maintain a 331 neighbor entry on behalf of N5 which is its directly connected child 332 node. Nodes N6 and N7 are grand-child nodes for node N3 for whom no 333 neighbor entry is required. 335 As mentioned in Section 10.3.2 of [RFC6775], the NCEs on parent and 336 child can be added directly as a result of RPL DIO/DAO signalling 337 without any explicit NS/NA messaging. 339 RPL 340 New PRE Parent PAA 341 | | | | 342 | | AuthProc | | 343 |<----------->|<----------------------->| 344 | | | | 345 | | RPL-DIO | | 346 |<-------------------------| | 347 | | | | 348 addNCE(parent,reason=PARENT) | | 349 | | | | 350 | | RPL-DAO | | 351 |------------------------->| | 352 | | | | 353 | | addNCE(new,reason=CHILD) 354 | | | | 356 Figure 3: NCE creation call Flow for RPL storing MOP 358 In case of non-storing MOP, the parent node needs to know the global 359 IPv6 address of the immediate child nodes. This is needed since the 360 source routing header carries the global addresses and thus the NCE 361 of the child node should contain the global address. Secondly, the 362 RPL DAO is addressed directly to the root node in case of non-storing 363 mode. Thus RPL messaging cannot be used for creating NCE entries on 364 parent and child, unlike storing MOP. The child node may send a 365 secure unicast NS with ARO option containing its global address to be 366 registered on the parent node. The child node can still use RPL DIO 367 to create an NCE on behalf of the parent node. 369 RPL 370 New PRE Parent Root 371 | | | | 372 | | AuthProc | | 373 |<----------->|<----------------------->| 374 | | | | 375 | | RPL-DIO | | 376 |<-------------------------| | 377 | | | | 378 addNCE(parent,reason=PARENT) | | 379 | | | | 380 | sec-NS(ARO=GlobalIPv6) | | 381 |------------------------->| | 382 | | | | 383 | | addNCE(new,reason=CHILD) 384 | sec-NA(status) | | 385 |<-------------------------| | 386 | | | | 387 | | RPL-DAO | | 388 |-------------------------------------->| 389 | | | | 391 Figure 4: NCE creation call Flow for non-storing MOP 393 This document expects the neighbor management policy to remember the 394 reason why the neighbor entry is inserted. Secondly, the router may 395 remember whether the NS received was secured or unsecured and 396 accordingly use it to prioritize eviction entries. As described in 397 the next sections, this reason will help the policy to prioritize the 398 entries in case an eviction is required. 400 2.3.2. NCE Deletion 402 It is imperative that an unwanted neighbor entry be removed as soon 403 as possible. This section talks about different cases in which 404 neighbor entry can be deleted. 406 Route Invalidation: In case of storing MOP, when the child node 407 decides to switch its preferred parent, the RPL specifications allows 408 the node to send a no-path DAO message to invalidate the route along 409 the previous path(s). A directly connected parent node can use this 410 message to clear the NCE. While the entry can be immediately 411 cleared, usually the implementations choose to wait a small amount of 412 time before clearing the entry. This is to avoid any impact on the 413 in-transit traffic. Thus this also establishes the importance of 414 route invalidation to achieve optimized neighbor cache utilization. 416 In case of non-storing mode, the no-path DAO cannot be not employed 417 since the previous parent does not having any routing information to 418 be invalidated. But the previous parent may still contain the NCE on 419 behalf of the child node. This document recommends use of [RFC6775] 420 section 6.5.3. which allows sending a zero lifetime ARO option in NS 421 for deregistering the corresponding neighbor entry. 423 [RFC6775], ND optimizations for 6LoWPANs, section 5.5.3. talks about 424 deleting the entries in case the NUD (neighbor unreachability 425 detection) fails either due to no response to NS messages or due to 426 failure response. NCEs in such cases should be deleted. An example 427 where NUD NS would fail because of no response is the case where the 428 child node switches its parent due to link unavailability. The 429 parent in such a case would not receive the no-path DAO message or 430 any other traffic from the child node. Thus on NCE lifetime expiry, 431 the parent node would send NS which would fail with no response, thus 432 triggering entry deletion. 434 2.3.3. NCE Eviction 436 The eviction rules have a major impact on the neighbor management 437 policy. Eviction rules are used when the policy has to forcibly 438 remove an active neighbor entry from the cache to make space for the 439 new (hopefully higher priority) entry. The eviction policy may take 440 into account several considerations such as the reason why the entry 441 was made, is the entry in active use currently, how good (for e.g., 442 based on link estimation) the entry currently is. 444 2.3.3.1. Eviction for directly connected routing entries 446 This section talks about implications of an eviction in which a 447 parent node decides of evicting a directly connected routing child 448 NCE. In the sample topology Figure 1, lets assume N3 needs to evict 449 N5 from its neighbor cache. In case of RPL's storing MOP, eviction 450 of directly connected routing child NCE also has impact on all the 451 sub-children. Thus not only will it result in impacting N5 but also 452 nodes N6 and N7. It is important to note that such an eviction has 453 less impact on RPL's non-storing MOP i.e. in case of non-storing mode 454 N5 might end up selecting alternate parent N8 and does not result in 455 any additional control overhead for node N6 and N7. 457 Thus RPL's non-storing MOP provides additional eviction flexibility 458 for a neighbor management policy in terms evicting directly connected 459 child entries. 461 2.3.4. NCE Reinforcement 463 It is expected that the latest reachability state and metric 464 information be maintained in context to the NCE. With wireless 465 networks, the neighbor cache entries prioritization may change over a 466 period of time especially the link quality estimation parameters or 467 the routing metrics. Reinforcement refers to updating the parameters 468 in context to the NCEs which helps in prioritizing the entries when 469 it comes to handling eviction. In wireless networks, on reception of 470 incoming packet, the receiver node's physical and MAC layer may 471 derive certain signal reception parameters (such as RSSI, LQI) which 472 can be considered for reinforcement purpose if the corresponding 473 transmitter/source entry in neighbor cache is found. It should be 474 noted that the signal quality parameters may have high variance in 475 6lo networks and thus statistical techniques (such as weighted 476 averaging) are usually employed for deciding about a link quality 477 over a period of time. Reinforcement can be achieved using one or 478 more of the following techniques: 480 Passive Monitoring: Reinforcing the quality parameters using packets 481 received from the source. Trickled DIO, periodic beacons, 482 application traffic etc can be used for such monitoring. 484 Active Probing: A node may select subset of entries for active 485 probing wherein it sends a message to the neighbor entry's target 486 and can expect a response message back. An example of such 487 probing is [CONTIKI] where unicast DIS is sent to solicit a 488 unicast DIO without impacting the trickle timers. Though it adds 489 a control overhead on the link, periodic probing can help to 490 ascertain connectivity in the absence of any other traffic from 491 the neighboring node. 493 2.4. Requirements of a good neighbor management policy 495 Route Stability: Stable NCEs will result in stable routing 496 adjacencies. Thus it is important to avoid unnecessary NCE churn 497 for routing path stability. 499 Control overhead: A neighbor management policy may have to use 500 signalling messages for policy handling (such as rejection of 501 NCE). It is required that such overhead be kept as low as 502 possible. 504 2.5. Approaches to neighbor management policy 506 Neighbor management policy depends upon the neighbor cache space 507 availability and the same can be advertised proactively or can be 508 handled reactively. 510 2.5.1. Reactive Approach 512 In this approach, the nodes select their RPL parent or the relay 513 element purely based on link metrics and subsequently when they try 514 to allocate their NCE in the target node, it may fail due to 515 unavailability of the cache space. The failure can be communicated 516 depending upon the signaling involved: 518 NS failure: Section 6.5.3 of [RFC6775] defines a procedure for NS 519 failure handling in case the router's neighbor cache is full. It 520 results in a unicast NA with ARO status field set to two. 522 DAO NACK: Section 9.3 of RPL [RFC6550] specifies on how can the 523 parent node react to DAOs from child. In case the parent could 524 not make a NCE on behalf of the child node, a negative ACK with 525 status (between 127-255) should be sent to the child node. The 526 natural reaction of the child node would be to switch to an 527 alternate parent. 529 PANA Failure: PaC's auth session starts with a PaC discovering a 530 PRE. The discovery procedure is not standardized and can be based 531 upon various factors including signal strength of discovery 532 messages from PRE. Post discovery, the PaC needs to send an 533 unsecured unicast NS message with an ARO containings its link- 534 local IPv6 address. NS helps to determine whether the PRE can 535 allocate an NCE for the PaC. PRE accordingly sends a NA response 536 with appropriate status field. 538 2.5.2. Proactive Approach 540 Neighbor cache availability could be proactively advertised by the 541 parent nodes in the DIO messages and in the PRE discovery messages. 542 A child RPL node may additionally use this information from DIO as 543 part of parent selection process. In case of new joinee node, the 544 node may use PRE discovery messages with space availability 545 information to select an appropriate PRE. Proactive signaling of 546 neighbor cache space availability will help the nodes to select the 547 parent node or relay node such that the failure signaling due to 548 cache full event can be reduced. 550 Currently there is no standard way of signaling such neighbor cache 551 space availability information. RPL's DIO messages carry metric 552 information and can be augmented with neighbor cache space as an 553 additional metric. In case of PRE discovery however there is no 554 standard way of defining this information since the PRE discovery 555 procedure itself is not standardized. 557 In a wireless or shared bus network, a multicast DIO metric 558 advertisement may reach several child nodes eventually everyone 559 responding by selecting the same parent node causing neighbor cache 560 to be exhausted. Thus the failure handling approaches defined in the 561 Reactive Approach section applies here as well. But importantly the 562 failure signaling will be significantly reduced because of proactive 563 advertisement. 565 3. Reservation based Neighbor Management Policy 567 This section defines a sample neighbor management policy, with the 568 primary objective to reduce NCE churn and to ensure stability of 569 routing adjacencies. The scheme uses a reservation based policy to 570 reserve NCEs for: 572 +-----------------------------+----------------------------+--------+ 573 | NCE Entry for | MAX count | Reason | 574 +-----------------------------+----------------------------+--------+ 575 | Routing Parent | MAX_ROUTING_PARENT_NCE_NUM | PARENT | 576 | | | | 577 | Routing child | MAX_ROUTING_CHILD_NCE_NUM | CHILD | 578 | | | | 579 | Others such as pre-auth | MAX_OTHER_NCE_NUM | OTHER | 580 | sessions | | | 581 +-----------------------------+----------------------------+--------+ 583 Table 1: Neighbor Cache Entry reservation 585 Note that reservation policy depends upon identification of the 586 reason behind making an NCE . In case of pre-auth sessions, the 587 corresponding NCE is created based on the unsecured NS/NA. In case 588 of storing MOP, CHILD_ENT NCEs are created either based on DAO (as 589 shown in Figure 3) or based on secured NS/NA messaging (as shown in 590 Figure 4). In case of non-storing MOP, a secured NS/NA messaging as 591 shown in Figure 4 needs to be used. 593 <- - - - - - - - - - - Routing Parents - - - - - - - - - - - - -> 594 +---------------------------------------------------------------+ 595 | | | | 596 +-----------------------------------------------------+---------+ 597 Routing Child Routing Parents Other 599 Figure 5: Reservation of NCEs in neighbor table 601 As shown in the figure, the neighbor cache is partitioned into 602 different entry types. The routing parents can possibly occupy any 603 entry type if found vacant since in case an eviction is sought the 604 non-preferred routing parent could be evicted without much impact on 605 the functioning or on the control traffic. The eviction could be 606 done based on reasons specified in Section 2.3.3. 608 Routing Child entries are made in context to directly connected peers 609 and these entries are not deleted unless they are unreacable or there 610 is any reason for the parent node to believe that it is no longer the 611 preferred parent for the child node. Deletion may happen based on 612 reasons mentioned in Section 2.3.2. 614 Other entries (OTHER) may be made in response to temporary 615 requirement of making an NCE. One such case is the pre 616 authentication phase where in the relay node makes an entry of the 617 PaC temporarily till the time the authentication phase is completed. 618 The NCE made thus is garbage collected at the end of the lifetime. 619 Also an implementation may choose to keep a lower lifetime for such 620 NCEs depending upon the time taken to complete the authentication 621 process. 623 3.1. Limitations of such a policy 625 The reservation based policy mentioned in this section may result in 626 sub-optimal path selection due to lack of NCE resource on the parent 627 nodes. Also the restriction of maximum pre-auth sessions in the form 628 of MAX_OTHER_NCE_NUM limits the maximum relay sessions that can be 629 supported on the relay node. 631 The reservation policy allows the parent node to reject the child 632 node's DAO or NS. But the child node cannot remember this rejection 633 and may reattempt the same parent after some time depending upon 634 triggers such as reception of DIO from the same parent who rejected 635 it previously. One of the only way to stop the child node from 636 reattempting such parent selection would be to also include a 637 proactive approach wherein the parent node signals its resource 638 availability in the DIO message as mentioned in Section 2.5.2. Such 639 a scheme of signalling parent node's resource availability is 640 currently not standardized. 642 RPL's storing MOP imposes additional restrictions. One such case is 643 where a child node may have a given parent node as its only parent 644 and that parent node's NCE are all used up. In such a case, the 645 child node would keep on retrying and failing to send a DAO through 646 the parent node. Ideally the parent node could have evicted a least 647 used child node or a child node who has an alternate parent 648 available. Evicting such a child node is a complex process and may 649 increase the control overhead as described in Section 2.3.3.1. Thus 650 the reservation based policy requires that the minimum node density 651 is sufficiently high so that every child finds a parent node in its 652 vicinity with enough resources. 654 4. Acknowledgements 656 This template was derived from an initial version written by Pekka 657 Savola and contributed by him to the xml2rfc project. 659 5. IANA Considerations 661 This memo includes no request to IANA. 663 6. Security Considerations 665 Add DoS attacks possibility on NBR table on PRE and what are the 666 mechanisms already defined by standards (such as use of Enforcement 667 Point) 669 All drafts are required to have a security considerations section. 670 See RFC 3552 [RFC3552] for a guide. 672 7. References 674 7.1. Normative References 676 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 677 Requirement Levels", BCP 14, RFC 2119, 678 DOI 10.17487/RFC2119, March 1997, 679 . 681 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 682 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 683 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 684 Low-Power and Lossy Networks", RFC 6550, 685 DOI 10.17487/RFC6550, March 2012, 686 . 688 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 689 Bormann, "Neighbor Discovery Optimization for IPv6 over 690 Low-Power Wireless Personal Area Networks (6LoWPANs)", 691 RFC 6775, DOI 10.17487/RFC6775, November 2012, 692 . 694 7.2. Informative References 696 [CONTIKI] Thingsquare, "Contiki: The Open Source OS for IoT", 2012, 697 . 699 [Dawans_et_al] 700 Dawans, S., Duquennoy, S., and O. Bonaventure, "On Link 701 Estimation in Dense RPL Deployments", 2012. 703 [I-D.ietf-6tisch-architecture] 704 Thubert, P., "An Architecture for IPv6 over the TSCH mode 705 of IEEE 802.15.4", draft-ietf-6tisch-architecture-11 (work 706 in progress), January 2017. 708 [I-D.ietf-6tisch-minimal-security] 709 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 710 "Minimal Security Framework for 6TiSCH", draft-ietf- 711 6tisch-minimal-security-03 (work in progress), June 2017. 713 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 714 Text on Security Considerations", BCP 72, RFC 3552, 715 DOI 10.17487/RFC3552, July 2003, 716 . 718 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 719 and A. Yegin, "Protocol for Carrying Authentication for 720 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 721 May 2008, . 723 [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and 724 A. Yegin, "Protocol for Carrying Authentication for 725 Network Access (PANA) Relay Element", RFC 6345, 726 DOI 10.17487/RFC6345, August 2011, 727 . 729 [Woo_et_al] 730 Woo, A., Tong, T., and D. Culler, "Taming the Underlying 731 Challenges of Reliable Multihop Routing in Sensor 732 Networks", 2003. 734 Appendix A. Additional Stuff 736 This becomes an Appendix. 738 Authors' Addresses 740 Rahul Arvind Jadhav (editor) 741 Huawei 742 Kundalahalli Village, Whitefield, 743 Bangalore, Karnataka 560037 744 India 746 Phone: +91-080-49160700 747 Email: rahul.ietf@gmail.com 748 Rabi Narayan Sahoo 749 Huawei 750 Kundalahalli Village, Whitefield, 751 Bangalore, Karnataka 560037 752 India 754 Phone: +91-080-49160700 755 Email: rabinarayans@huawei.com 757 Simon Duquennoy 758 Inria 759 40 Avenue Halley 760 Building A 761 Villeneuve d'Ascq 762 France 764 Phone: +33 768227731 765 Email: simon.duquennoy@inria.fr 767 Joakim Eriksson 768 Yanzi Networks 770 Email: joakime@sics.se