< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/