< draft-ietf-6tisch-6top-sf0-04.txt		draft-ietf-6tisch-6top-sf0-05.txt >
	6TiSCH D. Dujovne, Ed.		6TiSCH D. Dujovne, Ed.
	Internet-Draft Universidad Diego Portales		Internet-Draft Universidad Diego Portales
	Intended status: Experimental LA. Grieco		Intended status: Experimental LA. Grieco
	Expires: October 30, 2017 Politecnico di Bari		Expires: January 3, 2018 Politecnico di Bari
	MR. Palattella		MR. Palattella
	Luxembourg Institute of Science and Technology (LIST)		Luxembourg Institute of Science and Technology (LIST)
	N. Accettura		N. Accettura
	LAAS-CNRS		LAAS-CNRS
	April 28, 2017		July 2, 2017
	6TiSCH 6top Scheduling Function Zero (SF0)		6TiSCH 6top Scheduling Function Zero (SF0)
	draft-ietf-6tisch-6top-sf0-04		draft-ietf-6tisch-6top-sf0-05
	Abstract		Abstract
	This document defines a Scheduling Function called "Scheduling		This document defines a Scheduling Function called "Scheduling
	Function Zero" (SF0). SF0 dynamically adapts the number of allocated		Function Zero" (SF0). SF0 dynamically adapts the number of scheduled
	cells between neighbor nodes, based on the amount of currently		cells between neighbor nodes, based on the amount of currently
	allocated cells and the neighbor nodes' cell requirements. Neighbor		allocated cells and the neighbor nodes' cell requirements. Neighbor
	nodes negotiate in a distributed neighbor-to-neighbor basis the		nodes negotiate in a distributed neighbor-to-neighbor basis the
	number of cell(s) to be added/deleted. SF0 uses the 6P signaling		number of cell(s) to be added/deleted. SF0 uses the 6P signaling
	messages to add/delete cells in the schedule. This function selects		messages to add/delete cells in the schedule. This function selects
	the candidate cells from the schedule, defines which cells will be		the candidate cells from the schedule, defines which cells will be
	added/deleted and triggers the allocation/deallocation process.		added/deleted and triggers the allocation/deallocation process.
	Requirements Language		Requirements Language
	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 October 30, 2017.		This Internet-Draft will expire on January 3, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	skipping to change at page 2, line 26 ¶		skipping to change at page 2, line 26 ¶
	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. TEMPORARY EDITORIAL NOTES . . . . . . . . . . . . . . . . . . 3		1. TEMPORARY EDITORIAL NOTES . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Scheduling Function Identifier . . . . . . . . . . . . . . . 4		3. Scheduling Function Identifier . . . . . . . . . . . . . . . 4
	4. SF0 Triggering Events . . . . . . . . . . . . . . . . . . . . 4		4. Allocated and Used Cells . . . . . . . . . . . . . . . . . . 4
	5. SF0 Cell Estimation Algorithm . . . . . . . . . . . . . . . . 4		5. Overprovisioning . . . . . . . . . . . . . . . . . . . . . . 4
	6. SF0 Allocation Policy . . . . . . . . . . . . . . . . . . . . 5		6. Scheduling Algorithm . . . . . . . . . . . . . . . . . . . . 4
	7. Rules for CellList . . . . . . . . . . . . . . . . . . . . . 6		6.1. SF0 Triggering Events . . . . . . . . . . . . . . . . . . 4
	8. 6P Timeout Value . . . . . . . . . . . . . . . . . . . . . . 7		6.2. SF0 Cell Estimation Algorithm . . . . . . . . . . . . . . 4
	9. Meaning of Metadata Information . . . . . . . . . . . . . . . 7		6.3. SF0 Allocation Policy . . . . . . . . . . . . . . . . . . 6
	10. Node Behavior at Boot . . . . . . . . . . . . . . . . . . . . 7		7. Rules for CellList . . . . . . . . . . . . . . . . . . . . . 8
	11. Cell Type . . . . . . . . . . . . . . . . . . . . . . . . . . 7		8. 6P Timeout Value . . . . . . . . . . . . . . . . . . . . . . 8
	12. SF0 Statistics . . . . . . . . . . . . . . . . . . . . . . . 8		9. Meaning of Metadata Information . . . . . . . . . . . . . . . 9
	13. Relocating Cells . . . . . . . . . . . . . . . . . . . . . . 8		10. Node Behavior at Boot . . . . . . . . . . . . . . . . . . . . 9
	14. Forced Cell Deletion Policy . . . . . . . . . . . . . . . . . 8		11. Cell Type . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	15. 6P Error Handling . . . . . . . . . . . . . . . . . . . . . . 8		12. SF0 Statistics . . . . . . . . . . . . . . . . . . . . . . . 9
	16. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9		13. Relocating Cells . . . . . . . . . . . . . . . . . . . . . . 9
	17. Implementation Status . . . . . . . . . . . . . . . . . . . . 9		14. Forced Cell Deletion Policy . . . . . . . . . . . . . . . . . 10
	18. Security Considerations . . . . . . . . . . . . . . . . . . . 9		15. 6P Error Handling . . . . . . . . . . . . . . . . . . . . . . 10
	19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		16. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	20. 6P Compliance . . . . . . . . . . . . . . . . . . . . . . . . 10		17. Implementation Status . . . . . . . . . . . . . . . . . . . . 10
	21. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		18. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	22. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	22.1. Normative References . . . . . . . . . . . . . . . . . . 10		20. 6P Compliance . . . . . . . . . . . . . . . . . . . . . . . . 11
	22.2. Informative References . . . . . . . . . . . . . . . . . 11		21. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
	Appendix A. [TEMPORARY] Changelog . . . . . . . . . . . . . . . 11		22. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		22.1. Normative References . . . . . . . . . . . . . . . . . . 12
			22.2. Informative References . . . . . . . . . . . . . . . . . 12
			Appendix A. [TEMPORARY] Changelog . . . . . . . . . . . . . . . 13
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. TEMPORARY EDITORIAL NOTES		1. TEMPORARY EDITORIAL NOTES
	This document is an Internet Draft, so it is work-in-progress by		This document is an Internet Draft, so it is work-in-progress by
	nature. It contains the following work-in-progress elements:		nature. It contains the following work-in-progress elements:
	o "TODO" statements are elements which have not yet been written by		o "TODO" statements are elements which have not yet been written by
	the authors for some reason (lack of time, ongoing discussions		the authors for some reason (lack of time, ongoing discussions
	with no clear consensus, etc). The statement does indicate that		with no clear consensus, etc). The statement does indicate that
	the text will be written at some time.		the text will be written at some time.
	skipping to change at page 3, line 27 ¶		skipping to change at page 3, line 27 ¶
	o "IANA_" identifiers are placeholders for numbers assigned by IANA.		o "IANA_" identifiers are placeholders for numbers assigned by IANA.
	These placeholders are to be replaced by the actual values they		These placeholders are to be replaced by the actual values they
	represent after their assignment by IANA.		represent after their assignment by IANA.
	o The string "REMARK" is put before a remark (questions, suggestion,		o The string "REMARK" is put before a remark (questions, suggestion,
	etc) from an author, editor of contributor. These are on-going		etc) from an author, editor of contributor. These are on-going
	discussions at the time to writing, NOT part of the final text.		discussions at the time to writing, NOT part of the final text.
	o This section will be removed in the final text.		o This section will be removed in the final text.
	2. Introduction		2. Introduction
	This document defines a minimal Scheduling Function for the 6top		This document defines a minimal Scheduling Function using the 6P
	sublayer [I-D.ietf-6tisch-6top-protocol], called "Scheduling Function		protocol [I-D.ietf-6tisch-6top-protocol], called "Scheduling Function
	Zero" (SF0). SF0 is designed to offer the minimal set of		Zero" (SF0). SF0 is designed to offer a number of functionalities to
	functionalities to be usable in a wide range of applications. SF0		be usable in a wide range of applications. SF0 defines two
	defines two algorithms: The Scheduling Algorithm defines the number		algorithms: The Scheduling Algorithm defines the number of cells to
	of cells to allocate/delete between two neighbours and the relocation		allocate/delete between two neighbours and the Relocation Algorithm
	algorithm defines when to relocate a cell.		defines when to relocate a cell.
	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. A portion of these allocated cells will be utilized by
	neighbors, while the remaining cells can be over-provisioned to
	handle unanticipated increases in cell requirements. The Scheduling
	Algorithm collects the cell allocation/deletion requests from the
	neighbors and the number of cells which are currently under usage.
	First, the 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.
	The Relocation Algorithm: Allocated cells may experience packet loss
	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.
	To synthesize, a node running SF0 determines when to add/delete cells		To synthesize, a node running SF0 determines when to add/delete cells
	in a three-step process:		in a three-step process:
	1. It waits for a triggering event (Section 4).		1. It waits for a triggering event (Section 6.1).
	2. It applies the Cell Estimation Algorithm (CEA) for a particular		2. It applies the Cell Estimation Algorithm (CEA) for a particular
	neighbor to determine how many cells are required to that		neighbor to determine how many cells are required to that
	neighbor (Section 5).		neighbor (Section 6.2).
	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
	determines the number of cells to add/delete (Section 6).		determines the number of cells to add/delete (Section 6.3).
	We expect additional SFs, offering more functionalities for a more		We expect additional SFs, offering more functionalities for a more
	specific use case, to be defined in future documents. SF0 addresses		specific use case, to be defined in future documents. SF0 addresses
	the requirements for a scheduling function listed in Section 5.2 from		the requirements for a scheduling function listed in Section 5.2 from
	[I-D.ietf-6tisch-6top-protocol], and follows the recommended outline		[I-D.ietf-6tisch-6top-protocol], and follows the recommended outline
	listed in Section 5.3 of [I-D.ietf-6tisch-6top-protocol]. This		listed in Section 5.3 of [I-D.ietf-6tisch-6top-protocol]. This
	document follows the terminology defined in		document follows the terminology defined in
	[I-D.ietf-6tisch-terminology].		[I-D.ietf-6tisch-terminology].
	3. Scheduling Function Identifier		3. Scheduling Function Identifier
	The Scheduling Function Identifier (SFID) of SF0 is IANA_SFID_SF0.		The Scheduling Function Identifier (SFID) of SF0 is
			IANA_6TISCH_SFID_SF0.
	4. SF0 Triggering Events		4. Allocated and Used Cells
	We RECOMMEND SF0 to be triggered at least by the following events:		An allocated cell is assigned as a TX, RX or Shared cell on the
			schedule, as a reserved resource. This reservation does not imply
			that a packet will be transmitted during the scheduled cell time. A
			used cell is a cell where a packet has been transmitted during the
			scheduled cell time on the last slotframe.
	1. If there is a change in the current number of required cells		5. Overprovisioning
	2. If there is a successful cell allocation/deallocation process
	with the neighbour.
	This allows SF0 to be triggered by any change in locally generated or		Overprovisioning is the action and effect of increasing a value
	incoming traffic. The exact mechanism of when SF0 is triggered is		representing an amount of resources. In the case of SF0,
			overprovisioning is done as a provision to reduce traffic variability
			effects on packet loss, to the expense of artificially allocating a
			number of cells.
			6. Scheduling Algorithm
			A number of TX cells must be allocated between neighbor nodes in
			order to enable data transmission among them. A portion of these
			allocated cells will be used by neighbors, while the remaining cells
			can be over-provisioned to handle unanticipated increases in cell
			requirements. The Scheduling Algorithm collects the cell allocation/
			deallocation requests from the neighbors and the number of cells
			which are currently under usage. First, the Cell Estimation
			Algorithm calculates the number of required cells and second, the
			calculated number is transferred to the Allocation Policy. In order
			to reduce consumption, this algorithm is triggered only when there is
			a change on the number of used cells from a particular node.
			6.1. SF0 Triggering Events
			We RECOMMEND SF0 to be triggered at by the following event: If there
			is a change on the number of used cells towards any of the
			neighbours. The exact mechanism of when SF0 is triggered is
	implementation-specific.		implementation-specific.
	5. SF0 Cell Estimation Algorithm		6.2. SF0 Cell Estimation Algorithm
	The Cell Estimation Algorithm takes into account the new incoming		The Cell Estimation Algorithm takes into account the number of
	cell requirements from the neighbor node and the current outgoing		current used cells to the neighbour. This allows the algorithm to
	number of used cells. This allows the algorithm to estimate a new		estimate a new number of cells to be scheduled to the neighbour. As
	number of cells to be allocated. As a consequence, the Cell		a consequence, the Cell Estimation Algorithm for SF0 follows the
	Estimation Algorithm for SF0 follows the steps described below:		steps described below:
	1. Collect the current number of used cells		1. Collect the current number of used cells to the neighbour
	2. Calculate the new number of cells to be allocated by adding the		2. Calculate the new number of cells to be scheduled to the
	current number of used cells plus an OVERPROVISION number of		neighbour by adding the current number of used cells plus an
	cells		OVERPROVISION number of cells
	3. Submit the request to the allocation policy as REQUIREDCELLS		3. Transfer the request to the allocation policy as REQUIREDCELLS
	4. Return to step 1 and wait for a triggering event.		4. Return to step 1 and wait for a triggering event.
	The OVERPROVISION parameter is a percentage of the currently		The Cell Estimation Algorithm is depicted on figure Figure 1. The
	allocated cells which is added to the used cells to guarantee that		OVERPROVISION parameter is calculated as a percentage of the number
	the growth on the number of used cells can be detected without packet		of currently scheduled cells to the neighbour. OVERPROVISION is
	loss. This percentage value is implementation-specific. A value of		added to the amount of used cells to the neighbour to reduce the
	OVERPROVISION equal to zero leads to queue growth and possible packet		probability of packet loss given a sudden growth on the number of
	loss, since there are no overprovisioned cells to detect if there is		used cells to the neighbour. The OVERPROVISION value is
	a growth on the number of used cells.		implementation-specific. A value of OVERPROVISION equal to zero
			leads to queue growth and possible packet loss: In this case, there
			are no overprovisioned cells where a sudden growth on the number of
			cells can absorbed and detected.
	6. SF0 Allocation Policy		+-------------------+
			| Triggering |
			| Event |<-----+
			| | |
			+-------------------+ |
			| |
			V |
			+-------------------+ |
			| Collect number of | |
			| used cells | |
			+-------------------+ |
			| |
			V |
			+-------------------+ |
			| used cells | |
			| + | |
			| OVERPROVISION | |
			| = | |
			| REQUIREDCELLS | |
			+-------------------+ |
			| |
			V |
			+-------------------+ |
			| REQUIREDCELLS | |
			| | | |
			| V |------+
			| Allocation |
			| Policy |
			+-------------------+
			Figure 1: The SF0 Estimation Algorithm
			6.3. 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 cell		when to add/delete cells to a particular neighbor to satisfy the cell
	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 Cell Estimation		REQUIREDCELLS: The number of cells calculated by the Cell 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' neighbors.		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. The number of cells to be scheduled/		is illustrated in Figure 2. The number of cells to be added/deleted
	deleted is out of the scope of this document and it is		is out of the scope of this document and it is implementation-
	implementation-dependent.		dependent.
	SCHEDULEDCELLS		SCHEDULEDCELLS
	<--------------------------------->		<--------------------------------->
	+---+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+---+
	| | | | | | | | | |		| | | | | | | | | |
	+---+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+---+
	|<----------------->|		|<----------------->|
	| SF0THRESH |		| SF0THRESH |
	| |		| |
	REQUIREDCELLS | |		REQUIREDCELLS | |
	skipping to change at page 6, line 28 ¶		skipping to change at page 7, line 36 ¶
	REQUIREDCELLS |		REQUIREDCELLS |
	+---+---+---+---+---+---+ | DO		+---+---+---+---+---+---+ | DO
	| | | | | | | | NOTHING		| | | | | | | | NOTHING
	+---+---+---+---+---+---+ |		+---+---+---+---+---+---+ |
	| |		| |
	REQUIREDCELLS |		REQUIREDCELLS |
	+---+---+---+---+---+---+---+---+---+---+ ADD		+---+---+---+---+---+---+---+---+---+---+ ADD
	| | | | | | | | | | | ONE/MORE		| | | | | | | | | | | ONE/MORE
	+---+---+---+---+---+---+---+---+---+---+ CELLS		+---+---+---+---+---+---+---+---+---+---+ CELLS
	Figure 1: The SF0 Allocation Policy		Figure 2: 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 number
			of cells to add or delete is implementation-specific.
	7. Rules for CellList		7. Rules for CellList
	There are two methods to define the CellList: The Whitelist method,		There are two methods to define the CellList: The Whitelist method,
	which fills the CellList with the number of proposed cells to the		which fills the CellList with the number of proposed cells to the
	neighbour, and the Blacklist, which fills the CellList with the cells		neighbour, and the Blacklist, which fills the CellList with the cells
	which cannot be used by the neighbour. The rule to select the method		which cannot be used by the neighbour. The rule to select the method
	is implementation-specific. When issuing a 6top ADD Request, SF0		is implementation-specific. When issuing a 6top ADD Request, SF0
	executes the following sequence:		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 is not occupied and choose channelOffset randomly for
	channelOffset randomly for each cell.		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 is not occupied from the ones on the
	the ones on the CellList.		CellList.
			SF0 does not include any transaction retry process. If the
			transaction is not successful, SF0 will be retriggered on the next
			slotframe if the number of used cells changes.
	8. 6P Timeout Value		8. 6P Timeout Value
	The general timeout equals the equivalent time of the number of slots		The timeout value is implementation-specific. The timeout value MAY
	until the next scheduled cell. TODO/REMARK: The exact calculation is		be different for each transaction and each neighbour. The timeout
	currently under discussion on the Mailing List.		range is from 0 to 128. The timeout MUST be added as an 7-bit on the
			Metadata header to the neighbour. There is no measurement unit
			associated to the timeout value. If the timeout expires, the node
			issues a RESET return code will be issued to the neighbour. SF0 has
			no retry policy. Timeout examples are depicted on Figure 3 and
			Figure 4.
			|Timeout Value-----------------------------------------------------|
			|A|------First Exchange-------->|B|-----Second Exchange----->|A|
			|Complete transaction------------------------------------------|
			Figure 3: Example Transaction where the timeout does not expire
			|Timeout Value----------------------------------------------|
			|A|------First Exchange-------->|B|-----Second Exchange----->|A|
			|Non-Complete transaction--------------------------------------|
			Figure 4: Example Transaction where the timeout expires
	9. 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 [TIMEOUT] represents the Timeout value
	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).
	10. Node Behavior at Boot		10. 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 neighbor 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 and at least a SF0THRESH number of cells MUST be
	should allow for the maximum number of TSCH link-layer retries, as		allocated to each of the neighbours.
	defined by Section 4.3.4 of [I-D.ietf-6tisch-6top-protocol]. TODO/
	REMARK: The initial timeout is currently under discussion on the
	Mailing List.
	11. Cell Type		11. Cell Type
	SF0 uses TX (Transmission) cell type only, thus defining celloptions		SF0 uses TX (Transmission) cell type only, thus defining celloptions
	as TX=0, RX=1 and S=0 according to section 4.2.6 of		as TX=0, RX=1 and S=0 according to section 4.2.6 of
	[I-D.ietf-6tisch-6top-protocol].		[I-D.ietf-6tisch-6top-protocol].
	12. SF0 Statistics		12. SF0 Statistics
	Packet Delivery Rate (PDR) is calculated per cell, as the quotient of		Packet Delivery Rate (PDR) is calculated per cell, as the percentage
	the number of successfully delivered packets to 10, for the last 10		of acknowledged packets, for the last 10 packet transmission
	packet transmission attempts, without counting retransmissions.		attempts. There is no retransmission policy on SF0.
	13. Relocating Cells		13. Relocating Cells
			Allocated cells may experience packet loss from different sources,
			such as noise, interference or cell collision (after the same cell is
			allocated by other nodes in range on the network).
	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 relocation (by changing their		currently allocated cells for cell relocation (by changing their
	slotOffset and/or channelOffset). When the PDR of one or more		slotOffset and/or channelOffset). When the PDR of one or more
	softcells is below PDR_THRESHOLD, defined as a percentage of the		softcells is below PDR_THRESHOLD, SF0 relocates each of the cell(s)
	average of the PDR of the rest of the scheduled cells, SF0 relocates		to a number of available cells selected randomly. PDR_THRESHOLD is
	each of the cell(s) to a number of available cells selected randomly.		out of the scope of this document and it is implementation-dependent.
	PDR_THRESHOLD is out of the scope of this document and it is
	implementation-dependent.
	14. Forced Cell Deletion Policy		14. Forced Cell Deletion Policy
	When all the cells are scheduled, we need a policy to free cells, for		When all the cells are scheduled, we need a policy to free cells, for
	example, under alarm conditions or if a node disappears from the		example, under alarm conditions or if a node disappears from the
	neighbor list. The action to follow this condition is out of scope		neighbor list. The action to follow this condition is out of scope
	of this document and it is implementation-dependent.		of this document and it is implementation-dependent.
	15. 6P Error Handling		15. 6P Error Handling
	skipping to change at page 9, line 49 ¶		skipping to change at page 11, line 31 ¶
	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.
	18. Security Considerations		18. Security Considerations
	TODO		TODO
	19. IANA Considerations		19. IANA Considerations
	o IANA_SFID_SF0		o IANA_6TiSCH_SFID_SF0
	20. 6P Compliance		20. 6P Compliance
	o MUST specify an identifier for that SF. OK		o MUST specify an identifier for that SF. OK
	o MUST specify the rule for a node to decide when to add/delete one		o MUST specify the rule for a node to decide when to add/delete one
	or more cells to a neighbor. OK		or more cells to a neighbor. OK
	o MUST specify the rule for a Transaction source to select cells to		o MUST specify the rule for a Transaction source to select cells to
	add to the CellList field in the 6P ADD Request. OK		add to the CellList field in the 6P ADD Request. OK
	o MUST specify the rule for a Transaction destination to select		o MUST specify the rule for a Transaction destination to select
	cells from CellList to add to its schedule. OK		cells from CellList to add to its schedule. OK
	skipping to change at page 11, line 12 ¶		skipping to change at page 12, line 39 ¶
	22.1. Normative References		22.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>.
	22.2. Informative References		22.2. Informative References
	[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running		[I-D.ietf-6tisch-6top-protocol]
	Code: The Implementation Status Section", RFC 6982,		Wang, Q., Vilajosana, X., and T. Watteyne, "6top Protocol
	DOI 10.17487/RFC6982, July 2013,		(6P)", draft-ietf-6tisch-6top-protocol-07 (work in
	<http://www.rfc-editor.org/info/rfc6982>.		progress), June 2017.
	[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-08 (work in		802.15.4e", draft-ietf-6tisch-terminology-09 (work in
	progress), December 2016.		progress), June 2017.
	[I-D.ietf-6tisch-6top-protocol]
	Wang, Q., Vilajosana, X., and T. Watteyne, "6top Protocol
	(6P)", draft-ietf-6tisch-6top-protocol-04 (work in
	progress), March 2017.
	[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.
			[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
			Code: The Implementation Status Section", RFC 6982,
			DOI 10.17487/RFC6982, July 2013,
			<http://www.rfc-editor.org/info/rfc6982>.
	Appendix A. [TEMPORARY] Changelog		Appendix A. [TEMPORARY] Changelog
	o draft-ietf-6tisch-6top-sf0-02		o draft-ietf-6tisch-6top-sf0-02
	* Editorial changes (figs, typos, ...)		* Editorial changes (figs, typos, ...)
	o draft-ietf-6tisch-6top-sf0-03		o draft-ietf-6tisch-6top-sf0-03
	* Fixed typos		* Fixed typos
	* Removed references to "effectively used cells"		* Removed references to "effectively used cells"
	* Changed Cell Estimation Algorithm to the third proposed		* Changed Cell Estimation Algorithm to the third proposed
End of changes. 36 change blocks.
	129 lines changed or deleted		189 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/