--- 1/draft-ietf-lwig-nbr-mgmt-policy-02.txt 2019-02-21 02:13:10.016644277 -0800 +++ 2/draft-ietf-lwig-nbr-mgmt-policy-03.txt 2019-02-21 02:13:10.060645335 -0800 @@ -1,22 +1,22 @@ LWIG R. Jadhav, Ed. Internet-Draft R. Sahoo Intended status: Informational Huawei -Expires: February 25, 2019 S. Duquennoy +Expires: August 25, 2019 S. Duquennoy Inria J. Eriksson Yanzi Networks - August 24, 2018 + February 21, 2019 Neighbor Management Policy for 6LoWPAN - draft-ietf-lwig-nbr-mgmt-policy-02 + draft-ietf-lwig-nbr-mgmt-policy-03 Abstract This document describes the problems associated with neighbor cache management in multihop networks involving resource-constrained devices. Thereafter, it also presents a sample neighbor management policy that allows efficient cache management in multihop LLNs (low- power and lossy networks such as LoWPAN) with resource-constrained devices. @@ -28,25 +28,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on February 25, 2019. + This Internet-Draft will expire on August 25, 2019. Copyright Notice - Copyright (c) 2018 IETF Trust and the persons identified as the + Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -63,28 +63,29 @@ 2.3.1. NCE Insertion . . . . . . . . . . . . . . . . . . . . 7 2.3.2. NCE Deletion . . . . . . . . . . . . . . . . . . . . 10 2.3.3. NCE Eviction . . . . . . . . . . . . . . . . . . . . 11 2.3.3.1. Eviction for directly connected routing entries . 11 2.3.4. NCE Reinforcement . . . . . . . . . . . . . . . . . . 12 2.4. Requirements of a good neighbor management policy . . . . 12 2.5. Approaches to neighbor management policy . . . . . . . . 13 2.5.1. Reactive Approach . . . . . . . . . . . . . . . . . . 13 2.5.2. Proactive Approach . . . . . . . . . . . . . . . . . 13 3. Reservation based Neighbor Management Policy . . . . . . . . 14 - 3.1. Limitations of such a policy . . . . . . . . . . . . . . 15 + 3.1. Limitations of such a policy . . . . . . . . . . . . . . 16 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 - 7.2. Informative References . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 + 7.2. Informative References . . . . . . . . . . . . . . . . . 18 + Appendix A. Performance Result . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction In a wireless multihop LLN, the node densities (maximum nodes reachable on the same hop) may vary significantly depending upon deployments and scenarios. Examples of such networks is LoWPAN [REF] networks. While there is some policy control possible with regards to the network size in terms of maximum number of devices connected, it is especially difficult to set a figure on what will be the maximum node density given a deployment. For e.g. A network can put @@ -426,20 +427,28 @@ Route Invalidation: In case of storing MOP, when the child node decides to switch its preferred parent, the RPL specifications allows the node to send a no-path DAO message to invalidate the route along the previous path(s). A directly connected parent node can use this message to clear the NCE. While the entry can be immediately cleared, usually the implementations choose to wait a small amount of time before clearing the entry. This is to avoid any impact on the in-transit traffic. Thus this also establishes the importance of route invalidation to achieve optimized neighbor cache utilization. + Efficient neighbor cache management depends upon efficient route + invalidation since the neighbor cache entries are associated with + routing entries. With regards to RPL, issues with the route + invalidation has been highlighted in [I-D.ietf-roll-efficient-npdao]. + [I-D.ietf-roll-efficient-npdao] also defines a new mechanism for + improved route invalidation in storing MOP which helps optimized + cleanup of neighbor cache entries. + In case of non-storing mode, the no-path DAO cannot be not employed since the previous parent does not having any routing information to be invalidated. But the previous parent may still contain the NCE on behalf of the child node. This document recommends use of [RFC6775] section 6.5.3. which allows sending a zero lifetime ARO option in NS for deregistering the corresponding neighbor entry. [RFC6775], ND optimizations for 6LoWPANs, section 5.5.3. talks about deleting the entries in case the NUD (neighbor unreachability detection) fails either due to no response to NS messages or due to @@ -556,26 +565,44 @@ unsecured unicast NS message with an ARO containings its link- local IPv6 address. NS helps to determine whether the PRE can allocate an NCE for the PaC. PRE accordingly sends a NA response with appropriate status field. 2.5.2. Proactive Approach Neighbor cache availability could be proactively advertised by the parent nodes in the DIO messages and in the PRE discovery messages. A child RPL node may additionally use this information from DIO as - part of parent selection process. In case of new joinee node, the - node may use PRE discovery messages with space availability - information to select an appropriate PRE. Proactive signaling of - neighbor cache space availability will help the nodes to select the - parent node or relay node such that the failure signaling due to - cache full event can be reduced. + part of parent selection process. + + [I-D.richardson-6tisch-roll-enrollment-priority] defines a signalling + change in DIO messages to inform child nodes of the priority of the + 6LR. The priority field signals whether the 6LR is ready and has + enough resources to serve new child nodes. If 6LR's neighbor cache + gets full it can set the min priority to 0x7f(127) to stop the + joining process via it. When a LR or leaf node receives DIO from a + parent LR with min priority set to 127 the below actions + + 1. If its not yet joined the DODAG don't choose this LR as preferred + parent to join the DODAG. + + 2. If the node is already in the DODAG and this LR is not in the + parent list don't add it to parent list. + + 3. If node is already in the DODAG and the LR is in its standby + parent list remove the LR from its standby parent list. + + In case of new joinee node, the node may use PRE discovery messages + with space availability information to select an appropriate PRE. + Proactive signaling of neighbor cache space availability will help + the nodes to select the parent node or relay node such that the + failure signaling due to cache full event can be reduced. Currently there is no standard way of signaling such neighbor cache space availability information. RPL's DIO messages carry metric information and can be augmented with neighbor cache space as an additional metric. In case of PRE discovery however there is no standard way of defining this information since the PRE discovery procedure itself is not standardized. In a wireless or shared bus network, a multicast DIO metric advertisement may reach several child nodes eventually everyone @@ -738,44 +764,107 @@ [CONTIKI] Thingsquare, "Contiki: The Open Source OS for IoT", 2012, . [Dawans_et_al] Dawans, S., Duquennoy, S., and O. Bonaventure, "On Link Estimation in Dense RPL Deployments", 2012. [I-D.ietf-6tisch-architecture] Thubert, P., "An Architecture for IPv6 over the TSCH mode - of IEEE 802.15.4", draft-ietf-6tisch-architecture-14 (work - in progress), April 2018. + of IEEE 802.15.4", draft-ietf-6tisch-architecture-19 (work + in progress), December 2018. [I-D.ietf-6tisch-minimal-security] Vucinic, M., Simon, J., Pister, K., and M. Richardson, "Minimal Security Framework for 6TiSCH", draft-ietf- - 6tisch-minimal-security-06 (work in progress), May 2018. + 6tisch-minimal-security-09 (work in progress), November + 2018. + + [I-D.ietf-roll-efficient-npdao] + Jadhav, R., Thubert, P., Sahoo, R., and Z. Cao, "Efficient + Route Invalidation", draft-ietf-roll-efficient-npdao-09 + (work in progress), October 2018. + + [I-D.richardson-6tisch-roll-enrollment-priority] + Richardson, M., "Enabling secure network enrollment in RPL + networks", draft-richardson-6tisch-roll-enrollment- + priority-02 (work in progress), February 2019. + + [LWIP] "lwIP: A Lightweight TCP/IP stack", + . [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, May 2008, . [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA) Relay Element", RFC 6345, DOI 10.17487/RFC6345, August 2011, . + [WHITEFIELD] + "Whitefield Framework", + . + [Woo_et_al] Woo, A., Tong, T., and D. Culler, "Taming the Underlying Challenges of Reliable Multihop Routing in Sensor Networks", 2003. +Appendix A. Performance Result + + This appendix provides the details of the performance evaluation of + this draft. + + Setup: To perform the test [WHITEFIELD] framework was used with LwIP + [LWIP] as the network stack. A version of this draft is + implemented in the lwip to provide efficient neighbor cache + management policy that will work with relatively lower neighbor + cache size. RPL is used as routing protocol to form mesh network. + The available neighbor table size was split 60%, 30% and 10% among + direct child entries, parent entries and others respectively. + + Topology: Test was performed with a 64 nodes network including the + border router. Grid topology based network was used and all the + nodes were in close range with each other simulating a dense + condition. 802.15.4 in 2.4GHz range with single channel and un- + slotted CSMA wireless RF was used. + + Steps: Experiment has been conducted with different neighbor cache + sizes 10, 20 and 40. For each NC size we have collected sample + readings for packet delivery rate by enabling and disabling the + new neighbor Cache Management Policy. + + Data transmission frequency: Each node in the network sends 104 + bytes (IPv6 Header + RPI + UDP + Data) of UDP request to BR at + each 10 second interval. udp Server running at BR process these + requests and sends the response back , which is also of same size + 104 bytes. A duration of 2 minutes delay is added, for network to + get stable, before nodes starts sending request messages at 10 sec + interval.To calculate PDR one request and response pair is + considered as one successful transaction. + + Packet Delivery Rate Performance + +---------------------+---------------------+-----------------------+ + | Neighbor Cache Size | PDR With New policy | PDR Without New | + | | | policy | + +---------------------+---------------------+-----------------------+ + | 10 | 96.3 | 7.8 | + | 20 | 97.5 | 31.3 | + | 40 | 98.7 | 98.6 | + +---------------------+---------------------+-----------------------+ + + Table 2: Packet delivery rate + Authors' Addresses Rahul Arvind Jadhav (editor) Huawei Kundalahalli Village, Whitefield, Bangalore, Karnataka 560037 India Phone: +91-080-49160700 Email: rahul.ietf@gmail.com