draft-ietf-6tisch-6top-sf0-01.txt		draft-ietf-6tisch-6top-sf0-02.txt
	6TiSCH D. Dujovne, Ed.		6TiSCH D. Dujovne, Ed.
	Internet-Draft Universidad Diego Portales		Internet-Draft Universidad Diego Portales
	Intended status: Informational LA. Grieco		Intended status: Standards Track LA. Grieco
	Expires: January 9, 2017 Politecnico di Bari		Expires: May 4, 2017 Politecnico di Bari
	MR. Palattella		MR. Palattella
	University of Luxembourg		Luxembourg Institute of Science and Technology (LIST)
	N. Accettura		N. Accettura
	University of California Berkeley		LAAS-CNRS
	July 8, 2016		October 31, 2016
	6TiSCH 6top Scheduling Function Zero (SF0)		6TiSCH 6top Scheduling Function Zero (SF0)
	draft-ietf-6tisch-6top-sf0-01		draft-ietf-6tisch-6top-sf0-02
	Abstract		Abstract
	This document defines a 6top Scheduling Function called "Scheduling		This document defines a Scheduling Function called "Scheduling
	Function Zero" (SF0). SF0 dynamically adapts the number of reserved		Function Zero" (SF0). SF0 dynamically adapts the number of allocated
	cells between neighbor nodes, based on the currently allocated		cells between neighbor nodes, based on the amount of currently
	bandwidth and the neighbour nodes' requirements. Neighbor nodes		allocated cells and the neighbor nodes' cell requirements. Neighbor
	negotiate in a distributed neighbor-to-neighbor basis the cell(s) to		nodes negotiate in a distributed neighbor-to-neighbor basis the
	be added/deleted. SF0 uses the 6P signaling messages to add/delete		number of cell(s) to be added/deleted. SF0 uses the 6P signaling
	cells in the schedule. Some basic rules for deciding when to add/		messages to add/delete cells in the schedule. This function selects
	delete cells and for selecting the cells to be added/deleted within		the candidate cells from the schedule, defines which cells will be
	the schedule are also provided.		added/deleted and triggers the allocation/deallocation process.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in RFC		"OPTIONAL" in this document are to be interpreted as described in RFC
	2119 [RFC2119].		2119 [RFC2119].
	Status of This Memo		Status of This Memo
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 January 9, 2017.		This Internet-Draft will expire on May 4, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. TEMPORARY EDITORIAL NOTES . . . . . . . . . . . . . . . . . . 3
	2. Scheduling Function Identifier . . . . . . . . . . . . . . . 3		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Rules for Adding/Deleting Cells . . . . . . . . . . . . . . . 3		3. Scheduling Function Identifier . . . . . . . . . . . . . . . 4
	3.1. SF0 Triggering Events . . . . . . . . . . . . . . . . . . 3		4. SF0 Triggering Events . . . . . . . . . . . . . . . . . . . . 4
	3.2. SF0 Bandwidth Estimation Algorithm . . . . . . . . . . . 3		5. SF0 Cell Estimation Algorithm . . . . . . . . . . . . . . . . 5
	3.3. SF0 Allocation Policy . . . . . . . . . . . . . . . . . . 4		6. SF0 Allocation Policy . . . . . . . . . . . . . . . . . . . . 5
	4. Rules for CellList . . . . . . . . . . . . . . . . . . . . . 5		7. Rules for CellList . . . . . . . . . . . . . . . . . . . . . 6
	5. 6P Timeout Value . . . . . . . . . . . . . . . . . . . . . . 6		8. 6P Timeout Value . . . . . . . . . . . . . . . . . . . . . . 7
	6. Meaning of Metadata Information . . . . . . . . . . . . . . . 6		9. Meaning of Metadata Information . . . . . . . . . . . . . . . 7
	7. Node Behavior at Boot . . . . . . . . . . . . . . . . . . . . 6		10. Node Behavior at Boot . . . . . . . . . . . . . . . . . . . . 7
	8. Relocating Cells . . . . . . . . . . . . . . . . . . . . . . 6		11. Relocating Cells . . . . . . . . . . . . . . . . . . . . . . 7
	9. Forced Cell Deletion Policy . . . . . . . . . . . . . . . . . 7		12. Forced Cell Deletion Policy . . . . . . . . . . . . . . . . . 8
	10. 6P Error Handling . . . . . . . . . . . . . . . . . . . . . . 7		13. 6P Error Handling . . . . . . . . . . . . . . . . . . . . . . 8
	11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7		14. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	12. Implementation Status . . . . . . . . . . . . . . . . . . . . 7		15. Implementation Status . . . . . . . . . . . . . . . . . . . . 8
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 8		16. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		18. 6P Compliance . . . . . . . . . . . . . . . . . . . . . . . . 9
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
	16.1. Normative References . . . . . . . . . . . . . . . . . . 8		20. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	16.2. Informative References . . . . . . . . . . . . . . . . . 9		20.1. Normative References . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		20.2. Informative References . . . . . . . . . . . . . . . . . 10
			Appendix A. [TEMPORARY] Changelog . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. TEMPORARY EDITORIAL NOTES
	This document defines the Scheduling Function for the 6top sublayer		This document is an Internet Draft, so it is work-in-progress by
	[I-D.wang-6tisch-6top-sublayer] called "Scheduling Function Zero"		nature. It contains the following work-in-progress elements:
	(SF0).
	This document addresses the requirements for a scheduling function		o "TODO" statements are elements which have not yet been written by
	listed in [I-D.wang-6tisch-6top-sublayer], Section 4.2, and follows		the authors for some reason (lack of time, ongoing discussions
	the recommended outline from Section 4.3. This draft agrees with the		with no clear consensus, etc). The statement does indicate that
	terminology defined on [I-D.ietf-6tisch-terminology] and is designed		the text will be written at some time.
	within the context of [RFC7554]		o "TEMPORARY" appendices are there to capture current ongoing
			discussions, or the changelog of the document. These appendices
			will be removed in the final text.
			o "IANA_" identifiers are placeholders for numbers assigned by IANA.
			These placeholders are to be replaced by the actual values they
			represent after their assignment by IANA.
			o The string "REMARK" is put before a remark (questions, suggestion,
			etc) from an author, editor of contributor. These are on-going
			discussions at the time to writing, NOT part of the final text.
			o This section will be removed in the final text.
	2. Scheduling Function Identifier		2. Introduction
	The Scheduling Function Identifier (SFID) of SF0 is IANA_SFID_SF0.		This document defines a minimal Scheduling Function for the 6top
			sublayer [I-D.ietf-6tisch-6top-protocol], called "Scheduling Function
			Zero" (SF0). SF0 is designed to offer the minimal set of
			functionalities to be usable in a wide range of applications. SF0
			defines two algorithms: The Scheduling Algorithm defines the number
			of cells to allocate/delete between two neighbours and the relocation
			algorithm defines when to relocate a cell.
	3. Rules for Adding/Deleting Cells		The Scheduling Algorithm: A number of TX and/or RX cells must be
			allocated between neighbor nodes in order to enable data transmission
			among them. From the allocated cells, a part of them can be under
			effective use by the neighbours, while the rest of cells are over-
			provisioned to detect an increase in cell usage without packet loss.
			The Scheduling Algorithm collects the cell allocation/deletion
			requests from the neighbors and the number of cells which are
			currently under usage. First, a Cell Estimation Algotithm calculates
			the number of required cells by adding the collected values and
			second, the calculated value is given to the Allocation Policy, which
			provides stability by adding hystheresis and overprovisioning by
			deciding when to schedule the new number of cells, according to a
			threshold. In order to reduce consumption, this algorithm is
			triggered only when there is a change on the number of effectively
			used cells or if there is a change on the number of requested cells
			from a particular node.
	A node running SF0 determines when to add/delete cells in a three-		The Relocation Algorithm: Allocated cells may experiment packet loss
	step process:		from different sources, such as noise, interference or cell collision
			(after the same cell is allocated by other nodes in range on the
			network). In order to avoid this problem, Packet Delivery Rate (PDR)
			is monitored periodically for each allocated cell. A relocation is
			triggered when the PDR value drops below a certain threshold,
			compared to the average PDR of the rest of allocated cells. The
			destination location on the schedule is defined randomly.
	1. It waits for a triggering event (Section 3.1).		To synthesize, a node running SF0 determines when to add/delete cells
	2. It applies the Bandwidth Estimation Algorithm (BEA) for a		in a three-step process:
	particular neighbor to determine how much bandwidth is required
	to that neighbor (Section 3.2).		1. It waits for a triggering event (Section 4).
			2. It applies the Cell Estimation Algorithm (CEA) for a particular
			neighbor to determine how many cells are required to that
			neighbor (Section 5).
	3. It applies the Allocation Policy to compare the number of		3. It applies the Allocation Policy to compare the number of
	required cells to the number of already scheduled cells, and		required cells to the number of already scheduled cells, and
	determine the number of cells to add/delete (Section 3.3).		determines the number of cells to add/delete (Section 6).
	3.1. SF0 Triggering Events		We expect additional SFs, offering more functionalities for a more
			specific use case, to be defined in future documents. SF0 addresses
			the requirements for a scheduling function listed in Section 5.2
			[TODO: update if needed] from [I-D.ietf-6tisch-6top-protocol], and
			follows the recommended outline listed in Section 5.3 [TODO: update
			if needed] of [I-D.ietf-6tisch-6top-protocol]. This document follows
			the terminology defined in [I-D.ietf-6tisch-terminology].
			3. Scheduling Function Identifier
			The Scheduling Function Identifier (SFID) of SF0 is IANA_SFID_SF0.
			4. SF0 Triggering Events
	We RECOMMEND SF0 to be triggered at least by the following events:		We RECOMMEND SF0 to be triggered at least by the following events:
	1. If there is a change in the Current Outgoing Bandwidth Usage		1. If there is a change in the current number of used cells
	(COBU)		2. If there is a successful cell allocation/deallocation process
	2. If there is any New Incoming Bandwidth Requirements from		with the neighbour.
	neighbour nodes (NIBR)
	This allows SF0 to be triggered by any change in local outgoing		This allows SF0 to be triggered by any change in locally generated or
	bandwidth and/or incoming bandwidth. A relocation request from the		incoming traffic. The exact mechanism of when SF0 is triggered is
	neighbour is considered as an Incoming Bandwidth Request, given that		implementation-specific.
	it is expected to increase packet delivery rate on the relocated
	cells, thus increasing the required bandwidth. The exact mechanism
	of when SF0 is triggered is implementation-specific.
	3.2. SF0 Bandwidth Estimation Algorithm		5. SF0 Cell Estimation Algorithm
	The Bandwidth Estimation Algorithm takes into account the sum of the		The Cell Estimation Algorithm takes into account the new incoming
	incoming bandwidth requirements from the neighbour nodes and also the		cell requirements from the neighbor node and the current outgoing
	current outgoing bandwidth value. This allows the node to estimate		number of effectively used cells. This allows the algorithm to
	the total outgoing bandwidth requirement. As a consequence, the		estimate a new number of cells to be allocated. As a consequence,
	Bandwidth Estimation Algorithm for SF0 follows the steps described		the Cell Estimation Algorithm for SF0 follows the steps described
	below:		below:
	1. Collect the New Incoming Bandwidth Requirements from neighbour		1. Collect the new incoming cell requirements from the neighbor
	nodes (NIBR)		2. Collect the current number of effectively used cells
	2. Obtain the Current Outgoing Bandwidth Usage (COBU)		3. Calculate the new number of cells to be allocated by adding the
	3. Calculate the New Outgoing Bandwidth (NOB) as: NOB=COBU+NIBR		current number of effectively used cells and the new incoming
	4. Submit the request to the allocation policy		cells requirement
			4. Submit the request to the allocation policy as REQUIREDCELLS
	5. Return to step 1 and wait for a triggering event.		5. Return to step 1 and wait for a triggering event.
	3.3. SF0 Allocation Policy		A new incoming cell requirement is the result of a successful
			allocation process from the neighbor. TODO/REMARK: Add a number of
			cells to the required cells as OVERPROVISION to guarantee that the
			growth on the effectively used cells can be identified without packet
			loss. This value is implementation specific. A value of
			OVERPROVISION equal to zero leads to queue growth and possible packet
			loss, since there are no overprovisioned cells to detect if there is
			a growth of effectively used cells.
			6. SF0 Allocation Policy
	The "Allocation Policy" is the set of rules used by SF0 to decide		The "Allocation Policy" is the set of rules used by SF0 to decide
	when to add/delete cells to a particular neighbor to satisfy the		when to add/delete cells to a particular neighbor to satisfy the cell
	bandwidth requirements.		requirements.
	SF0 uses the following parameters:		SF0 uses the following parameters:
	SCHEDULEDCELLS: The number of cells scheduled from the current node		SCHEDULEDCELLS: The number of cells scheduled from the current node
	to a particular neighbor.		to a particular neighbor.
	REQUIREDCELLS: The number of cells calculated by the Bandwidth		REQUIREDCELLS: The number of cells calculated by the Cell Estimation
	Estimation Algorithm from the current node to that neighbor.		Algorithm from the current node to that neighbor.
	SF0THRESH: Threshold parameter introducing cell over-provisioning in		SF0THRESH: Threshold parameter introducing cell over-provisioning in
	the allocation policy. It is a non-negative value expressed as		the allocation policy. It is a non-negative value expressed as
	number of cells. The definition of this value is implementation-		number of cells. The definition of this value is implementation-
	specific. A setting of SF0THRESH>0 will cause the node to		specific. A setting of SF0THRESH>0 will cause the node to
	allocate at least SF0THRESH cells to each of its' neighbours.		allocate at least SF0THRESH cells to each of its' neighbors.
	The SF0 allocation policy compares REQUIREDCELLS with SCHEDULEDCELLS		The SF0 allocation policy compares REQUIREDCELLS with SCHEDULEDCELLS
	and decides to add/delete cells taking into account SF0THRESH. This		and decides to add/delete cells taking into account SF0THRESH. This
	is illustrated in Figure 1.		is illustrated in Figure 1.
	SCHEDULEDCELLS		SCHEDULEDCELLS
	<--------------------------------->		<--------------------------------->
	+---+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+---+
	| | | | | | | | | |		| | | | | | | | | |
	+---+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+---+
	|<--------->|		|<----------------->|
	| SF0THRESH |		| SF0THRESH |
	| |		| |
	REQUIREDCELLS | |		REQUIREDCELLS | |
	+---+---+ | | DELETE		+---+---+ | | DELETE
	| | | | | ONE/MORE		| | | | | ONE/MORE
	+---+---+ | | CELLS		+---+---+ | | CELLS
	| |		| |
	REQUIREDCELLS |		REQUIREDCELLS |
	+---+---+---+---+---+---+ | DO		+---+---+---+---+---+---+ | DO
	| | | | | | | | NOTHING		| | | | | | | | NOTHING
	+---+---+---+---+---+---+ |		+---+---+---+---+---+---+ |
	| |		| |
	REQUIREDCELLS |		REQUIREDCELLS |
	+---+---+---+---+---+---+---+---+---+---+ ADD		+---+---+---+---+---+---+---+---+---+---+ ADD
	| | | | | | | | | | | ONE/MORE		| | | | | | | | | | | ONE/MORE
	+---+---+---+---+---+---+---+---+---+---+ CELLS		+---+---+---+---+---+---+---+---+---+---+ CELLS
	Figure 1: The SF0 Allocation Policy		Figure 1: The SF0 Allocation Policy
	1. If REQUIREDCELLS<(SCHEDULEDCELLS-SF0THRESH), delete one or more		1. If REQUIREDCELLS<(SCHEDULEDCELLS-SF0THRESH), delete one or more
	cells.		cells.
	2. If (SCHEDULEDCELLS-SF0THRESH)<=REQUIREDCELLS<=SCHEDULEDCELLS, do		2. If (SCHEDULEDCELLS-SF0THRESH)<=REQUIREDCELLS<=SCHEDULEDCELLS, do
	nothing.		nothing.
	3. If SCHEDULEDCELLS<=REQUIREDCELLS, add one or more cells.		3. If SCHEDULEDCELLS<=REQUIREDCELLS, add one or more cells.
	When SF0THRESH equals 0, any discrepancy between REQUIREDCELLS and		When SF0THRESH equals 0, any discrepancy between REQUIREDCELLS and
	SCHEDULEDCELLS triggers an action to add/delete cells. Positive		SCHEDULEDCELLS triggers an action to add/delete cells. Positive
	values of SF0THRESH reduce the number of 6P Transactions.		values of SF0THRESH reduce the number of 6P Transactions.
	The Allocation Policy also translates the bandwidth requirement into		7. Rules for CellList
	cells according to their PDR. For example, if a cell with a 100% PDR
	is equivalent to 1Kbps, and the required bandwith is 8Kbps, then, the
	number of scheduled cells will be 8. However, if two of the
	allocated cells have a 70% PDR, there number of scheduled cells will
	be 9.
	4. Rules for CellList
	When issuing a 6top ADD Request, SF0 executes the following sequence:		There are two methods to define the CellList: The Whitelist method,
			which fills the CellList with the number of proposed cells to the
			neighbour, and the Blacklist, which fills the CellList with the cells
			which cannot be used by the neighbour. The rule to select the method
			is implementation-specific. When issuing a 6top ADD Request, SF0
			executes the following sequence:
	Whitelist case:		Whitelist case:
	The Transaction Source node: Prepares the CellList field by		The Transaction Source node: Prepares the CellList field by
	selecting randomly the required cells, verifying that the slot		selecting randomly the required cells, verifying that the slot
	offset and channel offset are not occupied and choose		offset and channel offset are not occupied and choose
	channelOffset randomly for each cell.		channelOffset randomly for each cell.
	The Transaction Destination node: Goes through the cells in the		The Transaction Destination node: Goes through the cells in the
	CellList in order, verifying whether there are no slotOffset		CellList in order, verifying whether there are no slotOffset
	conflicts.		conflicts.
	Blacklist case:		Blacklist case:
	The Transaction Source node: Prepares the CellList field by		The Transaction Source node: Prepares the CellList field by
	building a list of currently scheduled cells into the CellList.		building a list of currently scheduled cells into the CellList.
	The Transaction Destination node: Selects randomly the required		The Transaction Destination node: Selects randomly the required
	cells from the unallocated cells on the schedule, verifying		cells from the unallocated cells on the schedule, verifying
	that the slot offset and channel offset are not occupied from		that the slot offset and channel offset are not occupied from
	the ones on the CellList.		the ones on the CellList.
	5. 6P Timeout Value		8. 6P Timeout Value
	The general timeout equals the equivalent time of the number of slots		The general timeout equals the equivalent time of the number of slots
	until the next scheduled cell.		until the next scheduled cell. TODO/REMARK: The exact calculation is
			currently under discussion on the Mailing List.
	6. Meaning of Metadata Information		9. Meaning of Metadata Information
	The Metadata 16-bit field is used as follows:		The Metadata 16-bit field is used as follows:
	BITS 0-7 [SLOTFRAME] are used to identify the slotframe number		BITS 0-7 [SLOTFRAME] are used to identify the slotframe number
	BITS 8-14 are RESERVED		BITS 8-14 are RESERVED
	BIT 15 [WBLIST] is used to indicate that the CellList provided is		BIT 15 [WBLIST] is used to indicate that the CellList provided is
	a Whitelist (value=0) or a Blacklist (value=1).		a Whitelist (value=0) or a Blacklist (value=1).
	TODO: length of the SlotFrame SHOULD be an integer multiple of the		10. Node Behavior at Boot
	length of the minimal SlotFrame.
	7. Node Behavior at Boot
	In order to define a known state after the node is restarted, a CLEAR		In order to define a known state after the node is restarted, a CLEAR
	command is issued to each of the neighbour nodes to enable a new		command is issued to each of the neighbor nodes to enable a new
	allocation process. The 6P Initial Timeout Value provided by SF0		allocation process. The 6P Initial Timeout Value provided by SF0
	allows the maximum number of TSCH link-layer retries. Given the TSCH		should allow for the maximum number of TSCH link-layer retries, as
	parameters for the backoff mechanism, macMinBE and macMaxBE, and the		defined by Section 4.3.4 of [I-D.ietf-6tisch-6top-protocol]. TODO/
	length in seconds of the minimal Slotframe, SM, the timeout value is		REMARK: The initial timeout is currently under discussion.
	computed as: timeout = (2^(macMaxBE+1)-2^macMinBE) * SM
	8. Relocating Cells		11. Relocating Cells
	SF0 uses Packet Delivery Rate (PDR) statistics to monitor the		SF0 uses Packet Delivery Rate (PDR) statistics to monitor the
	currently allocated cells for cell re-allocation (by changing their		currently allocated cells for cell relocation (by changing their
	slotOffset and/or channelOffset) when it finds out that the PDR of		slotOffset and/or channelOffset). When the PDR of one or more
	one or more softcells below 20% of the average PDR.		softcells is below 20% of the average PDR of the rest of the
			scheduled cells, SF0 relocates the cell(s) to a number of available
			cells selected randomly. REMARK: This criteria is currently under
			discussion; simulation/experimentation is required to either adjust
			the threshold or to change the process.
	9. Forced Cell Deletion Policy		12. Forced Cell Deletion Policy
	TODO: When all the cells are scheduled, we need a policy to free		TODO: When all the cells are scheduled, we need a policy to free
	cells, for example, under alarm conditions or if a node dissappears		cells, for example, under alarm conditions or if a node disappears
	from the neighbour list.		from the neighbor list.
	10. 6P Error Handling		13. 6P Error Handling
	A node implementing SF0 handles a 6P Response depending on the Return		A node implementing SF0 handles a 6P Response depending on the Return
	Code it contains:		Code it contains:
	RC_SUCCESS:		RC_SUCCESS:
	If the number of elements in the CellList is the number of cells		If the number of elements in the CellList is the number of cells
	specified in the NumCells field of the 6P ALL Request, the		specified in the NumCells field of the 6P ADD Request, the
	operation is complete. The node does not take further action.		operation is complete. The node does not take further action.
	If the number of elements in the CellList is smaller (possibly 0)		If the number of elements in the CellList is smaller (possibly 0)
	than the number of cells specified in the NumCells field of the 6P		than the number of cells specified in the NumCells field of the 6P
	ALL Request, the neighbor has received the request, but less than		ADD Request, the neighbor has received the request, but less than
	NumCells of the cells in the CellList were. In that case, the		NumCells of the cells in the CellList were. In that case, the
	node MAY retry immediately with a different CellList if the amount		node MAY retry immediately with a different CellList if the amount
	of storage space permits, or build a new (random) CellList.		of storage space permits, or build a new (random) CellList.
	RC_VER_ERR: The node MUST NOT retry immediately. The node MAY add		RC_ERR_VER: The node MUST NOT retry immediately. The node MAY add
	the neighbor node on a blacklist. The node MAY retry to contact		the neighbor node to a blacklist. The node MAY retry to contact
	this neighbor later.		this neighbor later.
	RC_SFID_ERR: The node MUST NOT retry immediately. The node MAY add		RC_ERR_SFID: The node MUST NOT retry immediately. The node MAY add
	the neighbor node on a blacklist. The node MAY retry to contact		the neighbor node to a blacklist. The node MAY retry to contact
	this neighbor later.		this neighbor later.
	RC_BUSY: Wait for a timeout and restart the scheduling process.		RC_ERR_GEN: The node MUST issue a CLEAR command tot he neighbour.
	RC_RESET: Abort 6P Transaction		RC_ERR_BUSY: Wait for a timeout and restart the scheduling process.
			RC_ERR_NORES: Wait for a timeout and restart the scheduling process.
			RC_ERR_RESET: Abort 6P Transaction
	RC_ERR: Abort 6P Transaction. The node MAY retry to contact this		RC_ERR: Abort 6P Transaction. The node MAY retry to contact this
	neighbor later.		neighbor later.
	11. Examples		14. Examples
	TODO		TODO
	12. Implementation Status		15. Implementation Status
	This section records the status of known implementations of the		This section records the status of known implementations of the
	protocol defined by this specification at the time of posting of this		protocol defined by this specification at the time of posting of this
	Internet-Draft, and is based on a proposal described in [RFC6982].		Internet-Draft, and is based on a proposal described in [RFC6982].
	The description of implementations in this section is intended to		The description of implementations in this section is intended to
	assist the IETF in its decision processes in progressing drafts to		assist the IETF in its decision processes in progressing drafts to
	RFCs. Please note that the listing of any individual implementation		RFCs. Please note that the listing of any individual implementation
	here does not imply endorsement by the IETF. Furthermore, no effort		here does not imply endorsement by the IETF. Furthermore, no effort
	has been spent to verify the information presented here that was		has been spent to verify the information presented here that was
	supplied by IETF contributors. This is not intended as, and must not		supplied by IETF contributors. This is not intended as, and must not
	skipping to change at page 8, line 24 ¶		skipping to change at page 9, line 23 ¶
	It is up to the individual working groups to use this information as		It is up to the individual working groups to use this information as
	they see fit".		they see fit".
	OpenWSN: This specification is implemented in the OpenWSN project		OpenWSN: This specification is implemented in the OpenWSN project
	[OpenWSN]. The authors of this document are collaborating with		[OpenWSN]. The authors of this document are collaborating with
	the OpenWSN community to gather feedback about the status and		the OpenWSN community to gather feedback about the status and
	performance of the protocols described in this document. Results		performance of the protocols described in this document. Results
	from that discussion will appear in this section in future		from that discussion will appear in this section in future
	revision of this specification.		revision of this specification.
	13. Security Considerations		16. Security Considerations
	TODO		TODO
	14. IANA Considerations		17. IANA Considerations
	o IANA_SFID_SF0		o IANA_SFID_SF0
	15. Acknowledgments		18. 6P Compliance
			o MUST specify an identifier for that SF. OK
			o MUST specify the rule for a node to decide when to add/delete one
			or more cells to a neighbor. OK
			o MUST specify the rule for a Transaction source to select cells to
			add to the CellList field in the 6P ADD Request. OK
			o MUST specify the rule for a Transaction destination to select
			cells from CellList to add to its schedule. OK
			o MUST specify a value for the 6P Timeout, or a rule/equation to
			calculate it.
			o MUST specify a meaning for the "Metadata" field in the 6P ADD
			Request. OK
			o MUST specify the behavior of a node when it boots. OK
			o MUST specify what to do after an error has occurred (either the
			node sent a 6P Response with an error code, or received one). OK
			o MUST specify the list of statistics to gather. An example
			statistic if the number of transmitted frames to each neighbor.
			In case the SF requires no statistics to be gathered, the specific
			of the SF MUST explicitly state so.
			o SHOULD clearly state the application domain the SF is created for.
			OK
			o SHOULD contain examples which highlight normal and error
			scenarios.
			o SHOULD contain a list of current implementations, at least during
			the I-D state of the document, per [RFC6982].
			o SHOULD contain a performance evaluation of the scheme, possibly
			through references to external documents.
			o MAY redefine the format of the CellList? field.
			19. Acknowledgments
	Thanks to Kris Pister for his contribution in designing the default		Thanks to Kris Pister for his contribution in designing the default
	Bandwidth Estimation Algorithm. Thanks to Qin Wang and Thomas		Bandwidth Estimation Algorithm. Thanks to Qin Wang and Thomas
	Watteyne for their support in defining the interaction between SF0		Watteyne for their support in defining the interaction between SF0
	and the 6top sublayer.		and the 6top sublayer.
	This work is partially supported by the Fondecyt 1121475 Project, the		This work is partially supported by the Fondecyt 1121475 Project, the
	Inria-Chile "Network Design" group, and the IoT6 European Project		Inria-Chile "Network Design" group, and the IoT6 European Project
	(STREP) of the 7th Framework Program (Grant 288445).		(STREP) of the 7th Framework Program (Grant 288445).
	16. References		20. References
	16.1. Normative References		20.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	16.2. Informative References		20.2. Informative References
	[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
	IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
	Internet of Things (IoT): Problem Statement", RFC 7554,
	DOI 10.17487/RFC7554, May 2015,
	<http://www.rfc-editor.org/info/rfc7554>.
	[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running		[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
	Code: The Implementation Status Section", RFC 6982,		Code: The Implementation Status Section", RFC 6982,
	DOI 10.17487/RFC6982, July 2013,		DOI 10.17487/RFC6982, July 2013,
	<http://www.rfc-editor.org/info/rfc6982>.		<http://www.rfc-editor.org/info/rfc6982>.
	[I-D.ietf-6tisch-terminology]		[I-D.ietf-6tisch-terminology]
	Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,		Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
	"Terminology in IPv6 over the TSCH mode of IEEE		"Terminology in IPv6 over the TSCH mode of IEEE
	802.15.4e", draft-ietf-6tisch-terminology-07 (work in		802.15.4e", draft-ietf-6tisch-terminology-07 (work in
	progress), March 2016.		progress), March 2016.
	[I-D.wang-6tisch-6top-sublayer]		[I-D.ietf-6tisch-6top-protocol]
	Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer		Wang, Q. and X. Vilajosana, "6top Protocol (6P)", draft-
	(6top)", draft-wang-6tisch-6top-sublayer-04 (work in		ietf-6tisch-6top-protocol-02 (work in progress), July
	progress), November 2015.		2016.
	[OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F.,		[OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F.,
	Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN:		Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN:
	a Standards-Based Low-Power Wireless Development		a Standards-Based Low-Power Wireless Development
	Environment", Transactions on Emerging Telecommunications		Environment", Transactions on Emerging Telecommunications
	Technologies , August 2012.		Technologies , August 2012.
			Appendix A. [TEMPORARY] Changelog
			o draft-ietf-6tisch-6top-sf0-02
			* Editorial changes (figs, typos, ...)
	Authors' Addresses		Authors' Addresses
	Diego Dujovne (editor)		Diego Dujovne (editor)
	Universidad Diego Portales		Universidad Diego Portales
	Escuela de Informatica y Telecomunicaciones		Escuela de Informatica y Telecomunicaciones
	Av. Ejercito 441		Av. Ejercito 441
	Santiago, Region Metropolitana		Santiago, Region Metropolitana
	Chile		Chile
	Phone: +56 (2) 676-8121		Phone: +56 (2) 676-8121
	skipping to change at page 10, line 15 ¶		skipping to change at page 11, line 40 ¶
	Politecnico di Bari		Politecnico di Bari
	Department of Electrical and Information Engineering		Department of Electrical and Information Engineering
	Via Orabona 4		Via Orabona 4
	Bari 70125		Bari 70125
	Italy		Italy
	Phone: 00390805963911		Phone: 00390805963911
	Email: a.grieco@poliba.it		Email: a.grieco@poliba.it
	Maria Rita Palattella		Maria Rita Palattella
	University of Luxembourg		Luxembourg Institute of Science and Technology (LIST)
	Interdisciplinary Centre for Security, Reliability and Trust		Department 'Environmental Research and Innovation' (ERIN)
	4, rue Alphonse Weicker		41, rue du Brill
	Luxembourg L-2721		Belvaux L-4422
	LUXEMBOURG		Grand-duchy of Luxembourg
	Phone: (+352) 46 66 44 5841
	Email: maria-rita.palattella@uni.lu
			Phone: +352 275 888-5055
			Email: mariarita.palattella@list.lu
	Nicola Accettura		Nicola Accettura
	University of California Berkeley		LAAS-CNRS
	Berkeley Sensor & Actuator Center		7, avenue du Colonel Roche
	490 Cory Hall		Toulouse 31400
	Berkeley, California 94720		France
	USA
	Email: nicola.accettura@eecs.berkeley.edu		Phone: +33 5 61 33 69 76
			Email: nicola.accettura@laas.fr
End of changes. 59 change blocks.
	175 lines changed or deleted		263 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/