< draft-qasem-roll-rpl-load-balancing-01.txt		draft-qasem-roll-rpl-load-balancing-02.txt >
	roll		roll
	Internet-Draft M.Qasem		Internet-Draft M.Qasem
	Intended Status: Standards Track A.Al-Dubai		Intended Status: Standards Track A.Al-Dubai
	Expires: February 10, 2018 I.Romdhani		Expires: May 2, 2018 I.Romdhani
	B.Ghaleb		B.Ghaleb
	Edinburgh Napier University		Edinburgh Napier University
	August 9, 2017		J. Hou
			R. Jadhav
			Huawei Technologies
			October 29, 2017
	Load Balancing Objective Function in RPL		Load Balancing Objective Function in RPL
	draft-qasem-roll-rpl-load-balancing-01		draft-qasem-roll-rpl-load-balancing-02
	Abstract		Abstract
	This document proposes an extended Objective Function(OF) that		This document proposes an extended Objective Function(OF)that
	balances the number of children nodes of the parent nodes to avoid		balances the number of child nodes of the parent nodes to avoid the
	the overloading problem and ensure node lifetime maximization in the		overloading problem and ensure node lifetime maximization in the IPv6
	IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL). The		Routing Protocol for Low-Power and Lossy Networks (RPL). The standard
	standard OFs are used to build a Destination Oriented Directed		OFs are used to build a Destination Oriented Directed Acyclic Graph
	Acyclic Graph (DODAG) where the bottleneck nodes may suffer from		(DODAG) where the bottleneck nodes may suffer from unbalanced traffic
	unbalanced traffic load. As a result, a part of the network may be		load. As a result, a part of the network may be disconnected as the
	disconnected as the energy of the overloaded preferred parent node		energy of the overloaded preferred parent node will drain much faster
	will drain much faster than other candidate parents. Thus, a new RPL		than other candidate parents. Thus, a new RPL metric has been
	metric has been introduced to balance the traffic load over the		introduced to balance the traffic load over the network. Finally, the
	network. Finally, the potential extra overhead has been mitigated		potential extra overhead has been mitigated using a new utilization
	using a new utilization technique.		technique.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	skipping to change at page 2, line 30 ¶		skipping to change at page 2, line 33 ¶
	Table of Contents		Table of Contents
	1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
	2 DODAG construction in a nutshell . . . . . . . . . . . . . . . 4		2 DODAG construction in a nutshell . . . . . . . . . . . . . . . 4
	3 Load balancing in RPL . . . . . . . . . . . . . . . . . . . . . 4		3 Load balancing in RPL . . . . . . . . . . . . . . . . . . . . . 4
	4 The proposed objective function . . . . . . . . . . . . . . . . 6		4 The proposed objective function . . . . . . . . . . . . . . . . 6
	4.1 Balancing the load traffic . . . . . . . . . . . . . . . . . 6		4.1 Balancing the load traffic . . . . . . . . . . . . . . . . . 6
	4.2 A new utilization technique for DIO message . . . . . . . . 6		4.2 A new utilization technique for DIO message . . . . . . . . 6
	4.3 The Selected Parent Option . . . . . . . . . . . . . . . . . 7		4.3 Proposed New Metric for Parent Selection . . . . . . . . . . 7
	5 Security Considerations . . . . . . . . . . . . . . . . . . . . 7		5 Security Considerations . . . . . . . . . . . . . . . . . . . . 9
	6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8		6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
	7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	7.1 Normative References . . . . . . . . . . . . . . . . . . . 8		7.1 Normative References . . . . . . . . . . . . . . . . . . . 9
	7.2 Informative References . . . . . . . . . . . . . . . . . . 9		7.2 Informative References . . . . . . . . . . . . . . . . . . 10
	Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9		Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
	1 Introduction		1 Introduction
	IPv6 Routing Protocol for LLNs (RPL) [RFC6550] defined two OFs to		IPv6 Routing Protocol for LLNs (RPL) [RFC6550] defined two OFs to
	optimize the path selection towards the root node, namely, the OF		optimize the path selection towards the root node, namely, the OF
	zero (OF0) [RFC6552], and the Minimum Rank with Hysteresis OF		zero (OF0) [RFC6552], and the Minimum Rank with Hysteresis OF
	(MRHOF)[RFC6719]. The Destination Oriented Directed Acyclic Graph		(MRHOF)[RFC6719]. The Destination Oriented Directed Acyclic Graph
	(DODAG) construction is built by the RPL OF, that specify how nodes		(DODAG) construction is built by the RPL OF, that specify how nodes
	select the preferred parent node by translating one or more metrics		select the preferred parent node by translating one or more metrics
	into the rank value.		into the rank value.
	skipping to change at page 5, line 34 ¶		skipping to change at page 5, line 34 ¶
	Figure 2 depicts the selection of the preferred parent for those nodes		Figure 2 depicts the selection of the preferred parent for those nodes
	are within the first hop from nodes A or B. Clearly, node A has more		are within the first hop from nodes A or B. Clearly, node A has more
	children as it is surrounded by the nodes (N,M,F,G,E,P). Despite the		children as it is surrounded by the nodes (N,M,F,G,E,P). Despite the
	fact that A has more children, it dominates the shred nodes (C,D,R,J)		fact that A has more children, it dominates the shred nodes (C,D,R,J)
	that are also located within the shared area of node B (i.e., within the		that are also located within the shared area of node B (i.e., within the
	transmission range of A and B). That unbalanced parent selection		transmission range of A and B). That unbalanced parent selection
	approach in RPL left node B only with two children, while node A has ten		approach in RPL left node B only with two children, while node A has ten
	children.		children.
	+----------------------------------------------------+		+----------------------------------------------------+
	| Parent | Children nodes | Shared nodes |		| Parent | Child nodes | Shared nodes |
	| nodes | |between A and B |		| nodes | |between A and B |
	|----------------------------------------------------|		|----------------------------------------------------|
	| A | N,M,F,G,E,P,C,D.R,J | C,D,R,J |		| A | N,M,F,G,E,P,C,D.R,J | C,D,R,J |
	|----------------------------------------------------|		|----------------------------------------------------|
	| B | H,K | C,D,R,J |		| B | H,K | C,D,R,J |
	+----------------------------------------------------+		+----------------------------------------------------+
	Figure 2: The selection of the preferred parents		Figure 2: The selection of the preferred parents
	It is notable that the connection of all nodes through A is fragile as		It is notable that the connection of all nodes through A is fragile as
	skipping to change at page 7, line 36 ¶		skipping to change at page 7, line 36 ¶
	overcome this problem, LB-OF using a new technique is proposed as		overcome this problem, LB-OF using a new technique is proposed as
	detailed below. In LB-OF algorithm, the received DIO from the child node		detailed below. In LB-OF algorithm, the received DIO from the child node
	is counted by the preferred parent node. Each DIO contains the IP		is counted by the preferred parent node. Each DIO contains the IP
	address of the chosen preferred parent as detailed in section 4.3. Thus,		address of the chosen preferred parent as detailed in section 4.3. Thus,
	for each received DIO, the node matches its own IP address with the		for each received DIO, the node matches its own IP address with the
	preferred parent IP address which is inserted in the DIO message, then		preferred parent IP address which is inserted in the DIO message, then
	increments the number of children by ONE for this node if there is a		increments the number of children by ONE for this node if there is a
	matching.		matching.
	Hence, this technique evades increasing any extra overhead,		Hence, this technique evades increasing any extra overhead,
	additionally, the coming DIOs from the children nodes has been utilized		additionally, the coming DIOs from the child nodes has been utilized to
	to allow each preferred parent to distinguish the number of its children		allow each preferred parent to distinguish the number of its children
	during the DODAG construction stage to optimize the routing.		during the DODAG construction stage to optimize the routing.
	4.3 The Selected Parent Option		4.3 Proposed New Metric for Parent Selection
	Typically, the DIO carries the RPL InstanceID, DODAG identifier, version		Typically, the DIO carries the RPL InstanceID, DODAG identifier, version
	number, Rank and the OF that has been used to calculate the rank, in		number, Rank and the OF that has been used to calculate the rank, in
	addition to others identifiers [RFC6550]. However, the option field		addition to other identifiers [RFC6550]. This section introduces the
	within DIO message could be utilized to inject the selected parent		number of child nodes as a new metric/constraint in the DAG Metric
	address, and its format is as shown in Figure 3.		Container, which includes the selected parent address in the option
			field within the DIO message. The newly added information is 2 octets
	5 Security Considerations		named by Child Node Count (CNC) which is per this document defined in
			the DAG Metric Container.
	Since the routing metrics/constraints are carried within RPL message,
	the security routing mechanisms defined in [RFC6550] apply here.
	6 IANA Considerations		The Child Node Count (CNC) object is used to provide information related
			to the number of child nodes in the DIO source node, and may be used as
			a metric or as constraint.
	The IANA defined in [RFC6551] apply here according to [RFC5226].		The CNC object MAY be present in the DAG Metric Container. There MUST
			NOT be more than one CNC object as a constraint per DAG Metric
			Container, and there MUST NOT be more than one CNC object as a metric
			per DAG Metric Container. The format of the CNC object body is as
			follows:
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Option Length | Flags | |		| Flags |P| CNC | CNC_MAX | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
	| |		| |
	+ +		+ +
	| |		| |
	+ Parent Address +		+ Parent Address +
	| |		| |
	+ +-+-+-+-+-+-+-+-+-+		+ +-+-+-+-+-+-+-+-+
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: Format of the Selected Parent Option		Figure 3: Child Node Count Object Body Format
			Flags field (8 bits). The following one bits of the CNC object are
			currently defined:
			'P'flag: Parent Address State. This, if set to 1, indicates there is a
			parent address field in the CNC object.
			CNC: 8-bits. The Child Node Count is encoded in 8 bits in unsigned
			integer format, expressed in number count, representing the number of
			child nodes.
			MAX_CNC: 8-bits. The Maximum Child Node Count is encoded in 8 bits. The
			MAX_CNC field indicates the maximum number of children a node can hold.
			This parameter is set by implementers based on neighbor cache entry or
			the size limit of routing table. Nodes should not hold child nodes more
			than MAX_CNC.
			Parent Address (optional): 128-bit IPv6 address of parent node. This
			field is only present when the'P'flag is set to 1.
			In the storing mode, DAO can be used for child nodes registration while
			No-PathDAO can be used for de-registration, and this gives a way to
			count the number of child nodes. Thus, to minimize traffic load, the
			Parent Address field in the CNC object should not be present in the
			storing mode.
			In the non-storing mode, NS/NA could be an optional way for child node
			counting. When the 'P' flag is set, the Parent Address in the CNC object
			should be used for child node counting according to the technique
			illustrated in section 4.2.
			When this CNC metric is used, RANK computing reflects the ability of
			each node to hold more child nodes. Also, a new way for the RANK
			computing has been suggested: RANK = CNC / CNC_MAX * 255. A node with
			smaller RANK has high priority to accept new child nodes, a node with
			RANK = 255 should not hold new child nodes any more.
			5 Security Considerations
			Since the routing metrics/constraints are carried within RPL message,
			the security routing mechanisms defined in [RFC6550] apply here.
			6 IANA Considerations
			IANA is requested to allocate a new value for the new metric type "CNC"
			in the Routing Metric/Constraint Type in the DAG Metric Container.
	7 References		7 References
	7.1 Normative References		7.1 Normative References
	[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,		[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
	Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,		Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
	JP., and R. Alexander, "RPL: IPv6 Routing Protocol for		JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
	Low-Power and Lossy Networks", RFC 6550, March 2012.		Low-Power and Lossy Networks", RFC 6550, March 2012.
	skipping to change at page 10, line 4 ¶		skipping to change at page 10, line 43 ¶
	Phone: +44 131 455 2796		Phone: +44 131 455 2796
	Email: a.al-dubai@napier.ac.uk		Email: a.al-dubai@napier.ac.uk
	Imed Romdhani		Imed Romdhani
	Edinburgh Napier University		Edinburgh Napier University
	10 Colinton Road, EH10 5DT, Edinburgh, UK		10 Colinton Road, EH10 5DT, Edinburgh, UK
	Phone: +44 131 455 2726		Phone: +44 131 455 2726
	Email: i.romdhani@napier.ac.uk		Email: i.romdhani@napier.ac.uk
	Baraq Ghaleb		Baraq Ghaleb
	Edinburgh Napier University		Edinburgh Napier University
	10 Colinton Road, EH10 5DT, Edinburgh, UK		10 Colinton Road, EH10 5DT, Edinburgh, UK
	Email: b.ghaleb@napier.ac.uk		Email: b.ghaleb@napier.ac.uk
			Jianqiang Hou (editor)
			Huawei Technologies
			101 Software Avenue,
			Nanjing 210012
			China
			Phone: +86-15852944235
			Email: houjianqiang@huawei.com
			Rahul Arvind Jadhav
			Huawei Technologies
			Kundalahalli Village, Whitefield,
			Bangalore, Karnataka 560037
			India
			Phone: +91-080-49160700
			Email: rahul.ietf@gmail.com
End of changes. 16 change blocks.
	43 lines changed or deleted		97 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/