draft-ietf-lwig-nbr-mgmt-policy-02.txt   draft-ietf-lwig-nbr-mgmt-policy-03.txt 
LWIG R. Jadhav, Ed. LWIG R. Jadhav, Ed.
Internet-Draft R. Sahoo Internet-Draft R. Sahoo
Intended status: Informational Huawei Intended status: Informational Huawei
Expires: February 25, 2019 S. Duquennoy Expires: August 25, 2019 S. Duquennoy
Inria Inria
J. Eriksson J. Eriksson
Yanzi Networks Yanzi Networks
August 24, 2018 February 21, 2019
Neighbor Management Policy for 6LoWPAN Neighbor Management Policy for 6LoWPAN
draft-ietf-lwig-nbr-mgmt-policy-02 draft-ietf-lwig-nbr-mgmt-policy-03
Abstract Abstract
This document describes the problems associated with neighbor cache This document describes the problems associated with neighbor cache
management in multihop networks involving resource-constrained management in multihop networks involving resource-constrained
devices. Thereafter, it also presents a sample neighbor management devices. Thereafter, it also presents a sample neighbor management
policy that allows efficient cache management in multihop LLNs (low- policy that allows efficient cache management in multihop LLNs (low-
power and lossy networks such as LoWPAN) with resource-constrained power and lossy networks such as LoWPAN) with resource-constrained
devices. devices.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 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. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 28 skipping to change at page 2, line 28
2.3.1. NCE Insertion . . . . . . . . . . . . . . . . . . . . 7 2.3.1. NCE Insertion . . . . . . . . . . . . . . . . . . . . 7
2.3.2. NCE Deletion . . . . . . . . . . . . . . . . . . . . 10 2.3.2. NCE Deletion . . . . . . . . . . . . . . . . . . . . 10
2.3.3. NCE Eviction . . . . . . . . . . . . . . . . . . . . 11 2.3.3. NCE Eviction . . . . . . . . . . . . . . . . . . . . 11
2.3.3.1. Eviction for directly connected routing entries . 11 2.3.3.1. Eviction for directly connected routing entries . 11
2.3.4. NCE Reinforcement . . . . . . . . . . . . . . . . . . 12 2.3.4. NCE Reinforcement . . . . . . . . . . . . . . . . . . 12
2.4. Requirements of a good neighbor management policy . . . . 12 2.4. Requirements of a good neighbor management policy . . . . 12
2.5. Approaches to neighbor management policy . . . . . . . . 13 2.5. Approaches to neighbor management policy . . . . . . . . 13
2.5.1. Reactive Approach . . . . . . . . . . . . . . . . . . 13 2.5.1. Reactive Approach . . . . . . . . . . . . . . . . . . 13
2.5.2. Proactive Approach . . . . . . . . . . . . . . . . . 13 2.5.2. Proactive Approach . . . . . . . . . . . . . . . . . 13
3. Reservation based Neighbor Management Policy . . . . . . . . 14 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 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . 17 7.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Performance Result . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
In a wireless multihop LLN, the node densities (maximum nodes In a wireless multihop LLN, the node densities (maximum nodes
reachable on the same hop) may vary significantly depending upon reachable on the same hop) may vary significantly depending upon
deployments and scenarios. Examples of such networks is LoWPAN [REF] deployments and scenarios. Examples of such networks is LoWPAN [REF]
networks. While there is some policy control possible with regards networks. While there is some policy control possible with regards
to the network size in terms of maximum number of devices connected, 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 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 maximum node density given a deployment. For e.g. A network can put
skipping to change at page 11, line 5 skipping to change at page 11, line 5
Route Invalidation: In case of storing MOP, when the child node Route Invalidation: In case of storing MOP, when the child node
decides to switch its preferred parent, the RPL specifications allows 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 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 the previous path(s). A directly connected parent node can use this
message to clear the NCE. While the entry can be immediately message to clear the NCE. While the entry can be immediately
cleared, usually the implementations choose to wait a small amount of cleared, usually the implementations choose to wait a small amount of
time before clearing the entry. This is to avoid any impact on the time before clearing the entry. This is to avoid any impact on the
in-transit traffic. Thus this also establishes the importance of in-transit traffic. Thus this also establishes the importance of
route invalidation to achieve optimized neighbor cache utilization. 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 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 since the previous parent does not having any routing information to
be invalidated. But the previous parent may still contain the NCE on be invalidated. But the previous parent may still contain the NCE on
behalf of the child node. This document recommends use of [RFC6775] 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 section 6.5.3. which allows sending a zero lifetime ARO option in NS
for deregistering the corresponding neighbor entry. for deregistering the corresponding neighbor entry.
[RFC6775], ND optimizations for 6LoWPANs, section 5.5.3. talks about [RFC6775], ND optimizations for 6LoWPANs, section 5.5.3. talks about
deleting the entries in case the NUD (neighbor unreachability deleting the entries in case the NUD (neighbor unreachability
detection) fails either due to no response to NS messages or due to detection) fails either due to no response to NS messages or due to
skipping to change at page 13, line 44 skipping to change at page 13, line 47
unsecured unicast NS message with an ARO containings its link- unsecured unicast NS message with an ARO containings its link-
local IPv6 address. NS helps to determine whether the PRE can local IPv6 address. NS helps to determine whether the PRE can
allocate an NCE for the PaC. PRE accordingly sends a NA response allocate an NCE for the PaC. PRE accordingly sends a NA response
with appropriate status field. with appropriate status field.
2.5.2. Proactive Approach 2.5.2. Proactive Approach
Neighbor cache availability could be proactively advertised by the Neighbor cache availability could be proactively advertised by the
parent nodes in the DIO messages and in the PRE discovery messages. parent nodes in the DIO messages and in the PRE discovery messages.
A child RPL node may additionally use this information from DIO as A child RPL node may additionally use this information from DIO as
part of parent selection process. In case of new joinee node, the part of parent selection process.
node may use PRE discovery messages with space availability
information to select an appropriate PRE. Proactive signaling of [I-D.richardson-6tisch-roll-enrollment-priority] defines a signalling
neighbor cache space availability will help the nodes to select the change in DIO messages to inform child nodes of the priority of the
parent node or relay node such that the failure signaling due to 6LR. The priority field signals whether the 6LR is ready and has
cache full event can be reduced. 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 Currently there is no standard way of signaling such neighbor cache
space availability information. RPL's DIO messages carry metric space availability information. RPL's DIO messages carry metric
information and can be augmented with neighbor cache space as an information and can be augmented with neighbor cache space as an
additional metric. In case of PRE discovery however there is no additional metric. In case of PRE discovery however there is no
standard way of defining this information since the PRE discovery standard way of defining this information since the PRE discovery
procedure itself is not standardized. procedure itself is not standardized.
In a wireless or shared bus network, a multicast DIO metric In a wireless or shared bus network, a multicast DIO metric
advertisement may reach several child nodes eventually everyone advertisement may reach several child nodes eventually everyone
skipping to change at page 17, line 38 skipping to change at page 18, line 16
[CONTIKI] Thingsquare, "Contiki: The Open Source OS for IoT", 2012, [CONTIKI] Thingsquare, "Contiki: The Open Source OS for IoT", 2012,
<http://www.contiki-os.org>. <http://www.contiki-os.org>.
[Dawans_et_al] [Dawans_et_al]
Dawans, S., Duquennoy, S., and O. Bonaventure, "On Link Dawans, S., Duquennoy, S., and O. Bonaventure, "On Link
Estimation in Dense RPL Deployments", 2012. Estimation in Dense RPL Deployments", 2012.
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-14 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-19 (work
in progress), April 2018. in progress), December 2018.
[I-D.ietf-6tisch-minimal-security] [I-D.ietf-6tisch-minimal-security]
Vucinic, M., Simon, J., Pister, K., and M. Richardson, Vucinic, M., Simon, J., Pister, K., and M. Richardson,
"Minimal Security Framework for 6TiSCH", draft-ietf- "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",
<https://savannah.nongnu.org/projects/lwip/>.
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
and A. Yegin, "Protocol for Carrying Authentication for and A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
May 2008, <https://www.rfc-editor.org/info/rfc5191>. May 2008, <https://www.rfc-editor.org/info/rfc5191>.
[RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and
A. Yegin, "Protocol for Carrying Authentication for A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA) Relay Element", RFC 6345, Network Access (PANA) Relay Element", RFC 6345,
DOI 10.17487/RFC6345, August 2011, DOI 10.17487/RFC6345, August 2011,
<https://www.rfc-editor.org/info/rfc6345>. <https://www.rfc-editor.org/info/rfc6345>.
[WHITEFIELD]
"Whitefield Framework",
<https://github.com/whitefield-framework/whitefield>.
[Woo_et_al] [Woo_et_al]
Woo, A., Tong, T., and D. Culler, "Taming the Underlying Woo, A., Tong, T., and D. Culler, "Taming the Underlying
Challenges of Reliable Multihop Routing in Sensor Challenges of Reliable Multihop Routing in Sensor
Networks", 2003. 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 Authors' Addresses
Rahul Arvind Jadhav (editor) Rahul Arvind Jadhav (editor)
Huawei Huawei
Kundalahalli Village, Whitefield, Kundalahalli Village, Whitefield,
Bangalore, Karnataka 560037 Bangalore, Karnataka 560037
India India
Phone: +91-080-49160700 Phone: +91-080-49160700
Email: rahul.ietf@gmail.com Email: rahul.ietf@gmail.com
 End of changes. 14 change blocks. 
19 lines changed or deleted 109 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/