draft-ietf-6tisch-6top-sfx-00.txt   draft-ietf-6tisch-6top-sfx-01.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: March 26, 2018 Politecnico di Bari Expires: September 6, 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
September 22, 2017 March 5, 2018
6TiSCH 6top Scheduling Function Zero / Experimental (SFX) 6TiSCH Experimental Scheduling Function (SFX)
draft-ietf-6tisch-6top-sfx-00 draft-ietf-6tisch-6top-sfx-01
Abstract Abstract
This document defines a Scheduling Function called "Scheduling This document defines a Scheduling Function called "Experimental
Function Zero" (SF0) in its Experimental version. SF0 dynamically Scheduling Function" (SFX). SFX dynamically adapts the number of
adapts the number of scheduled cells between neighbor nodes, based on scheduled cells between neighbor nodes, based on the amount of
the amount of currently allocated cells and the neighbor nodes' cell currently allocated cells and the neighbor nodes' cell requirements.
requirements. Neighbor nodes negotiate in a distributed neighbor-to- Neighbor nodes negotiate in a distributed neighbor-to-neighbor basis
neighbor basis the number of cell(s) to be added/deleted. SF0 uses the number of cell(s) to be added/deleted. SFX uses the 6P signaling
the 6P signaling messages to add/delete cells in the schedule. This messages to add/delete cells in the schedule. This function selects
function selects the candidate cells from the schedule, defines which the candidate cells from the schedule, defines which cells will be
cells will be added/deleted and triggers the allocation/deallocation added/deleted and triggers the allocation/deallocation process.
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 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 March 26, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. TEMPORARY EDITORIAL NOTES . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scheduling Function Identifier . . . . . . . . . . . . . . . 3
3. Scheduling Function Identifier . . . . . . . . . . . . . . . 4 3. Allocated and Used Cells . . . . . . . . . . . . . . . . . . 3
4. Allocated and Used Cells . . . . . . . . . . . . . . . . . . 4 4. Overprovisioning . . . . . . . . . . . . . . . . . . . . . . 3
5. Overprovisioning . . . . . . . . . . . . . . . . . . . . . . 4 5. Scheduling Algorithm . . . . . . . . . . . . . . . . . . . . 4
6. Scheduling Algorithm . . . . . . . . . . . . . . . . . . . . 4 5.1. SFX Triggering Events . . . . . . . . . . . . . . . . . . 4
6.1. SF0 Triggering Events . . . . . . . . . . . . . . . . . . 4 5.2. SFX Cell Estimation Algorithm . . . . . . . . . . . . . . 4
6.2. SF0 Cell Estimation Algorithm . . . . . . . . . . . . . . 5 5.3. SFX Allocation Policy . . . . . . . . . . . . . . . . . . 5
6.3. SF0 Allocation Policy . . . . . . . . . . . . . . . . . . 6 6. Rules for CellList . . . . . . . . . . . . . . . . . . . . . 7
7. Rules for CellList . . . . . . . . . . . . . . . . . . . . . 8 7. 6P Timeout Value . . . . . . . . . . . . . . . . . . . . . . 7
8. 6P Timeout Value . . . . . . . . . . . . . . . . . . . . . . 8 8. Meaning of Metadata Information . . . . . . . . . . . . . . . 8
9. Meaning of Metadata Information . . . . . . . . . . . . . . . 9 9. Node Behavior at Boot . . . . . . . . . . . . . . . . . . . . 8
10. Node Behavior at Boot . . . . . . . . . . . . . . . . . . . . 9 10. Cell Type . . . . . . . . . . . . . . . . . . . . . . . . . . 8
11. Cell Type . . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. SFX Statistics . . . . . . . . . . . . . . . . . . . . . . . 8
12. SF0 Statistics . . . . . . . . . . . . . . . . . . . . . . . 9 12. Relocating Cells . . . . . . . . . . . . . . . . . . . . . . 8
13. Relocating Cells . . . . . . . . . . . . . . . . . . . . . . 9 13. Forced Cell Deletion Policy . . . . . . . . . . . . . . . . . 9
14. Forced Cell Deletion Policy . . . . . . . . . . . . . . . . . 10 14. 6P Error Handling . . . . . . . . . . . . . . . . . . . . . . 9
15. 6P Error Handling . . . . . . . . . . . . . . . . . . . . . . 10 15. Experimental requirements . . . . . . . . . . . . . . . . . . 9
16. Experimental requirements . . . . . . . . . . . . . . . . . . 10 16. Security Considerations . . . . . . . . . . . . . . . . . . . 10
17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
18. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 17.1. SFX Scheduling Function Identifiers . . . . . . . . . . 10
19. Security Considerations . . . . . . . . . . . . . . . . . . . 11 18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
21. 6P Compliance . . . . . . . . . . . . . . . . . . . . . . . . 12 19.1. Normative References . . . . . . . . . . . . . . . . . . 11
22. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 19.2. Informative References . . . . . . . . . . . . . . . . . 11
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
23.1. Normative References . . . . . . . . . . . . . . . . . . 13
23.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. [TEMPORARY] Changelog . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. TEMPORARY EDITORIAL NOTES
This document is an Internet Draft, so it is work-in-progress by
nature. It contains the following work-in-progress elements:
o "TODO" statements are elements which have not yet been written by
the authors for some reason (lack of time, ongoing discussions
with no clear consensus, etc). The statement does indicate that
the text will be written at some time.
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. Introduction 1. Introduction
This document defines a minimal Scheduling Function using the 6P This document defines a Scheduling Function using the 6P protocol
protocol [I-D.ietf-6tisch-6top-protocol], called "Scheduling Function [I-D.ietf-6tisch-6top-protocol], called "Experimental Scheduling
Zero" (SF0). SF0 is designed to offer a number of functionalities to Function" (SFX). SFX is designed to offer a number of
be usable in a wide range of applications. SF0 defines two functionalities to be usable in a wide range of applications. SFX
algorithms: The Scheduling Algorithm defines the number of cells to defines two algorithms: the Scheduling Algorithm which defines the
allocate/delete between two neighbours and the Relocation Algorithm number of cells to allocate/delete between two neighbors, and the
defines when to relocate a cell. Relocation Algorithm defines when to relocate a cell.
To synthesize, a node running SF0 determines when to add/delete cells To synthesize, a node running SFX determines when to add/delete cells
in a three-step process: in a three-step process:
1. It waits for a triggering event (Section 6.1). 1. It waits for a triggering event (Section 5.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 6.2). neighbor (Section 5.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.3). determines the number of cells to add/delete (Section 5.3).
We expect additional SFs, offering more functionalities for a more SFX addresses the requirements for a scheduling function listed in
specific use case, to be defined in future documents. SF0 addresses Section 5.2 from [I-D.ietf-6tisch-6top-protocol], and follows the
the requirements for a scheduling function listed in Section 5.2 from recommended outline listed in Section 5.3 of
[I-D.ietf-6tisch-6top-protocol], and follows the recommended outline [I-D.ietf-6tisch-6top-protocol]. This document follows the
listed in Section 5.3 of [I-D.ietf-6tisch-6top-protocol]. This terminology defined in [I-D.ietf-6tisch-terminology].
document follows the terminology defined in
[I-D.ietf-6tisch-terminology].
3. Scheduling Function Identifier 2. Scheduling Function Identifier
The Scheduling Function Identifier (SFID) of SF0 is The Scheduling Function Identifier (SFID) of SFX is
IANA_6TISCH_SFID_SF0. IANA_6TISCH_SFID_SFX.
4. Allocated and Used Cells 3. Allocated and Used Cells
An allocated cell is assigned as a TX, RX or Shared cell on the An allocated cell is assigned as a TX, RX or Shared cell on the
schedule, as a reserved resource. This reservation does not imply schedule, as a reserved resource. This reservation does not imply
that a packet will be transmitted during the scheduled cell time. A 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 used cell is a cell where a packet has been transmitted during the
scheduled cell time on the last slotframe. scheduled cell time on the last slotframe.
5. Overprovisioning 4. Overprovisioning
Overprovisioning is the action and effect of increasing a value Overprovisioning is the action and effect of increasing a value
representing an amount of resources. In the case of SF0, representing an amount of resources. In the case of SFX,
overprovisioning is done as a provision to reduce traffic variability overprovisioning is done as a provision to reduce traffic variability
effects on packet loss, to the expense of artificially allocating a effects on packet loss, to the expense of artificially allocating a
number of cells. number of cells.
6. Scheduling Algorithm 5. Scheduling Algorithm
A number of TX cells must be allocated between neighbor nodes in A number of TX cells must be allocated between neighbor nodes in
order to enable data transmission among them. A portion of these order to enable data transmission among them. A portion of these
allocated cells will be used by neighbors, while the remaining cells allocated cells will be used by neighbors, while the remaining cells
can be over-provisioned to handle unanticipated increases in cell can be over-provisioned to handle unanticipated increases in cell
requirements. The Scheduling Algorithm collects the cell allocation/ requirements. The Scheduling Algorithm collects the cell allocation/
deallocation requests from the neighbors and the number of cells deallocation requests from the neighbors and the number of cells
which are currently under usage. First, the Cell Estimation which are currently under usage. First, the Cell Estimation
Algorithm calculates the number of required cells and second, the Algorithm calculates the number of required cells and second, the
calculated number is transferred to the Allocation Policy. In order calculated number is transferred to the Allocation Policy. In order
to reduce consumption, this algorithm is triggered only when there is to reduce consumption, this algorithm is triggered only when there is
a change on the number of used cells from a particular node. a change on the number of used cells from a particular node.
6.1. SF0 Triggering Events 5.1. SFX Triggering Events
We RECOMMEND SF0 to be triggered at by the following event: If there We RECOMMEND SFX to be triggered by the following event: if there is
is a change on the number of used cells towards any of the a change on the number of used cells towards any of the neighbors.
neighbours. The exact mechanism of when SF0 is triggered is The exact mechanism of when SFX is triggered is implementation-
implementation-specific. specific.
6.2. SF0 Cell Estimation Algorithm 5.2. SFX Cell Estimation Algorithm
The Cell Estimation Algorithm takes into account the number of The Cell Estimation Algorithm takes into account the number of
current used cells to the neighbour. This allows the algorithm to currently used cells to the neighbor. This allows the algorithm to
estimate a new number of cells to be scheduled to the neighbour. As estimate a new number of cells to be scheduled to the neighbor. As a
a consequence, the Cell Estimation Algorithm for SF0 follows the consequence, the Cell Estimation Algorithm for SFX follows the steps
steps described below: described below:
1. Collect the current number of used cells to the neighbour 1. Collect the current number of used cells to the neighbor.
2. Calculate the new number of cells to be scheduled to the 2. Calculate the new number of cells to be scheduled to the neighbor
neighbour by adding the current number of used cells plus an by adding the current number of used cells plus an OVERPROVISION
OVERPROVISION number of cells number of cells.
3. Transfer 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 Cell Estimation Algorithm is depicted on figure Figure 1. The The Cell Estimation Algorithm is depicted in Figure 1. The
OVERPROVISION parameter is calculated as a percentage of the number OVERPROVISION parameter is calculated as a percentage of the number
of currently scheduled cells to the neighbour. OVERPROVISION is of currently scheduled cells to the neighbor. OVERPROVISION is added
added to the amount of used cells to the neighbour to reduce the to the amount of used cells to the neighbor to reduce the probability
probability of packet loss given a sudden growth on the number of of packet loss given a sudden growth on the number of used cells to
used cells to the neighbour. The OVERPROVISION value is the neighbor. The OVERPROVISION value is implementation-specific. A
implementation-specific. A value of OVERPROVISION equal to zero value of OVERPROVISION equal to zero leads to queue growth and
leads to queue growth and possible packet loss: In this case, there possible packet loss. In this case, there are no overprovisioned
are no overprovisioned cells where a sudden growth on the number of cells where a sudden growth on the number of cells can absorbed and
cells can absorbed and detected. detected.
+-------------------+ +-------------------+
| Triggering | | Triggering |
| Event |<-----+ | Event |<-----+
| | | | | |
+-------------------+ | +-------------------+ |
| | | |
V | V |
+-------------------+ | +-------------------+ |
| Collect number of | | | Collect number of | |
skipping to change at page 6, line 35 skipping to change at page 5, line 35
| | | |
V | V |
+-------------------+ | +-------------------+ |
| REQUIREDCELLS | | | REQUIREDCELLS | |
| | | | | | | |
| V |------+ | V |------+
| Allocation | | Allocation |
| Policy | | Policy |
+-------------------+ +-------------------+
Figure 1: The SF0 Estimation Algorithm Figure 1: The SFX Estimation Algorithm
6.3. SF0 Allocation Policy 5.3. SFX 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 SFX 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: SFX 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 SFXTHRESH: 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 a
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 SFXTHRESH>0 causes the node to allocate at
allocate at least SF0THRESH cells to each of its' neighbors. least SFXTHRESH cells to each of its' neighbors.
The SF0 allocation policy compares REQUIREDCELLS with SCHEDULEDCELLS The SFX 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 SFXTHRESH. This
is illustrated in Figure 2. The number of cells to be added/deleted is illustrated in Figure 2. The number of cells to be added/deleted
is out of the scope of this document and it is implementation- is out of the scope of this document and it is implementation-
dependent. dependent.
SCHEDULEDCELLS SCHEDULEDCELLS
<---------------------------------> <--------------------------------->
+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+
| | | | | | | | | | | | | | | | | | | |
+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+
|<----------------->| |<----------------->|
| SF0THRESH | | SFXTHRESH |
| | | |
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 2: The SF0 Allocation Policy Figure 2: The SFX Allocation Policy
1. If REQUIREDCELLS<(SCHEDULEDCELLS-SF0THRESH), delete one or more 1. If REQUIREDCELLS<(SCHEDULEDCELLS-SFXTHRESH), delete one or more
cells. cells.
2. If (SCHEDULEDCELLS-SF0THRESH)<=REQUIREDCELLS<=SCHEDULEDCELLS, do 2. If (SCHEDULEDCELLS-SFXTHRESH)<=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 SFXTHRESH 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. The number values of SFXTHRESH reduce the number of 6P Transactions. The number
of cells to add or delete is implementation-specific. of cells to add or delete is implementation-specific.
7. Rules for CellList 6. 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 fills the CellList with the number of proposed cells to the neighbor.
neighbour, and the Blacklist, which fills the CellList with the cells The Blacklist method fills the CellList with the cells which cannot
which cannot be used by the neighbour. The rule to select the method be used by the neighbor. The rule to select the method is
is implementation-specific. When issuing a 6top ADD Request, SF0 implementation-specific. When issuing a 6top ADD Request, SFX
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 is not occupied and choose channelOffset randomly for offset is not occupied and choose 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 is not occupied from the ones on the that the slot offset is not occupied from the ones on the
CellList. CellList.
SF0 does not include any transaction retry process. If the SFX does not include any transaction retry process. If the
transaction is not successful, SF0 will be retriggered on the next transaction is not successful, SFX will be retriggered on the next
slotframe if the number of used cells changes. slotframe if the number of used cells changes.
8. 6P Timeout Value 7. 6P Timeout Value
The timeout value is implementation-specific. The timeout value MAY The timeout value is implementation-specific. The timeout value MAY
be different for each transaction and each neighbour. The timeout be different for each transaction and each neighbor. The timeout
range is from 0 to 128. The timeout MUST be added as an 7-bit on the 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 Metadata header to the neighbor. There is no measurement unit
associated to the timeout value. If the timeout expires, the node associated to the timeout value. If the timeout expires, the node
issues a RESET return code will be issued to the neighbour. SF0 has issues a RESET return code will be issued to the neighbor. SFX has
no retry policy. Timeout examples are depicted on Figure 3 and no retry policy. Timeout examples are depicted on Figure 3 and
Figure 4. Figure 4.
|Timeout Value-----------------------------------------------------| |Timeout Value-----------------------------------------------------|
|A|------First Exchange-------->|B|-----Second Exchange----->|A| |A|------First Exchange-------->|B|-----Second Exchange----->|A|
|Complete transaction------------------------------------------| |Complete transaction------------------------------------------|
Figure 3: Example Transaction where the timeout does not expire Figure 3: Example Transaction where the timeout does not expire
|Timeout Value----------------------------------------------| |Timeout Value----------------------------------------------|
|A|------First Exchange-------->|B|-----Second Exchange----->|A| |A|------First Exchange-------->|B|-----Second Exchange----->|A|
|Non-Complete transaction--------------------------------------| |Non-Complete transaction--------------------------------------|
Figure 4: Example Transaction where the timeout expires Figure 4: Example Transaction where the timeout expires
9. Meaning of Metadata Information 8. 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 [TIMEOUT] represents the Timeout value 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 9. 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 and at least a SF0THRESH number of cells MUST be allocation process and at least a SFXTHRESH number of cells MUST be
allocated to each of the neighbours. allocated to each of the neighbors.
11. Cell Type 10. Cell Type
SF0 uses TX (Transmission) cell type only, thus defining celloptions SFX uses the TX (Transmission) cell type only, thus defining
as TX=0, RX=1 and S=0 according to section 4.2.6 of celloptions 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 11. SFX Statistics
Packet Delivery Rate (PDR) is calculated per cell, as the percentage Packet Delivery Rate (PDR) is calculated per cell, as the percentage
of acknowledged packets, for the last 10 packet transmission of acknowledged packets, for the last 10 packet transmission
attempts. There is no retransmission policy on SF0. attempts. There is no retransmission policy on SFX.
13. Relocating Cells 12. Relocating Cells
Allocated cells may experience packet loss from different sources, Allocated cells may experience packet loss from different sources,
such as noise, interference or cell collision (after the same cell is such as noise, interference or cell collision (after the same cell is
allocated by other nodes in range on the network). allocated by other nodes in range on the network).
SF0 uses Packet Delivery Rate (PDR) statistics to monitor the SFX 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, SF0 relocates each of the cell(s) softcells is below PDR_THRESHOLD, SFX relocates each of the cell(s)
to a number of available cells selected randomly. PDR_THRESHOLD is to a number of available cells selected randomly. PDR_THRESHOLD is
out of the scope of this document and it is implementation-dependent. out of the scope of this document and it is implementation-dependent.
14. Forced Cell Deletion Policy 13. 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 14. 6P Error Handling
A node implementing SF0 handles a 6P Response depending on the Return A node implementing SFX 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 ADD 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
ADD 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 allocated. In that NumCells of the cells in the CellList were allocated. In that
case, the node MAY retry immediately with a different CellList if case, the node MAY retry immediately with a different CellList if
the amount of storage space permits, or build a new (random) the amount of storage space permits, or build a new (random)
CellList. CellList.
RC_EOL: If an LIST command is issued and the RC_EOL is received, the
node MUST understand what is specified on Section 3.3.5 of
[I-D.ietf-6tisch-6top-protocol].
RC_ERR_VER: 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 to 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_ERR_SFID: 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 to 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_ERR_GEN: The node MUST issue a CLEAR command to the neighbour. RC_ERR_SEQNUM: The node MUST issue a CLEAR command to the neighbor.
RC_ERR_BUSY: Wait for a timeout and restart the scheduling process. 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_CELLLIST: Wait for a timeout and restart the scheduling
RC_ERR_RESET: Abort 6P Transaction process.
RC_ERR_LOCKED: Wait for a timeout and restart the scheduling
process.
RC_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.
16. Experimental requirements 15. Experimental requirements
In order to evaluate the performance of this draft, we propose the In order to evaluate the performance of this draft, we propose the
following experimental work: following experimental work:
1. Define values for OVERPROVISION, SF0THRESH and ranges to the 1. Define values for OVERPROVISION, SFXTHRESH and ranges to the
number of cells to Add or Delete after the Allocation Policy is number of cells to Add or Delete after the Allocation Policy is
applied for typical use cases. applied for typical use cases.
2. Analyze the scheduling stability (in terms of oscillation) and 2. Analyze the scheduling stability (in terms of oscillation) and
the hysteresis effect on scheduling using SFX. A tradeoff shall the hysteresis effect on scheduling using SFX. A tradeoff shall
be found between the reactivity of the algorithm facing new be found between the reactivity of the algorithm facing new
scheduling requirements and the number of overprovisioned cells. scheduling requirements and the number of overprovisioned cells.
3. Define the PDR value below the Average which is most effective 3. Define the PDR value below the Average which is most effective
for blacklisting cells and a method to whitelist cells. Analyze for blacklisting cells and a method to whitelist cells. Analyze
the stability and long-term behavior of this algorithm. the stability and long-term behavior of this algorithm.
4. Measure the distribution of cell scheduling delay (including the 4. Measure the distribution of cell scheduling delay (including the
time taken by 6P) to estimate timeouts for different type of time taken by 6P) to estimate timeouts for different type of
transactions transactions.
17. Examples
TODO
18. Implementation Status
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC6982].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to [RFC6982], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
OpenWSN: This specification is implemented in the OpenWSN project 16. Security Considerations
[OpenWSN]. The authors of this document are collaborating with
the OpenWSN community to gather feedback about the status and
performance of the protocols described in this document. Results
from that discussion will appear in this section in future
revision of this specification.
19. Security Considerations SFX is defined as an algorithm designed to efficiently fulfill
bandwidth requirements between neighbour nodes and does not define a
new protocol SFX uses the Minimal IPv6 over the TSCH Mode of IEEE
802.15.4e (6TiSCH) Configuration standardized on [RFC8180] and the
6top Protocol (6P): [I-D.ietf-6tisch-6top-protocol]. SFX relies on
the security framework described on
[I-D.ietf-6tisch-minimal-security].
TODO 17. IANA Considerations
20. IANA Considerations 17.1. SFX Scheduling Function Identifiers
o IANA_6TiSCH_SFID_SF0 This document provide a new element to the "6P Scheduling Function
Identifiers" sub-registry, which is part of the "IPv6 over the TSCH
mode of IEEE 802.15.4e (6TiSCH) parameters" registry, as defined by
[I-D.ietf-6tisch-6top-protocol]. This Subtype is defined on figure
Figure 5
21. 6P Compliance +----------------------+--------------------------+-------------+
| SFID | Name | Reference |
+----------------------+--------------------------+-------------+
| IANA_6TISCH_SFID_SFX | Experimental Scheduling | RFCXXXX |
| | Function (SFX) | (NOTE:this) |
+----------------------+--------------------------+-------------+
o MUST specify an identifier for that SF. OK Figure 5: IETF IE Subtype '6P'
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. OK
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. OK
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. OK
22. Acknowledgments 18. 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 SFX
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).
23. References 19. References
23.1. Normative References 19.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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
23.2. Informative References [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal
IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH)
Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180,
May 2017, <https://www.rfc-editor.org/info/rfc8180>.
19.2. Informative References
[I-D.ietf-6tisch-6top-protocol] [I-D.ietf-6tisch-6top-protocol]
Wang, Q., Vilajosana, X., and T. Watteyne, "6top Protocol Wang, Q., Vilajosana, X., and T. Watteyne, "6top Protocol
(6P)", draft-ietf-6tisch-6top-protocol-07 (work in (6P)", draft-ietf-6tisch-6top-protocol-09 (work in
progress), June 2017. progress), October 2017.
[I-D.ietf-6tisch-minimal-security]
Vucinic, M., Simon, J., Pister, K., and M. Richardson,
"Minimal Security Framework for 6TiSCH", draft-ietf-
6tisch-minimal-security-04 (work in progress), October
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 "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e",
802.15.4e", draft-ietf-6tisch-terminology-09 (work in draft-ietf-6tisch-terminology-10 (work in progress), March
progress), June 2017. 2018.
[OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F.,
Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN:
a Standards-Based Low-Power Wireless Development
Environment", Transactions on Emerging Telecommunications
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,
<https://www.rfc-editor.org/info/rfc6982>.
Appendix A. [TEMPORARY] Changelog
o draft-ietf-6tisch-6top-sf0-02
* Editorial changes (figs, typos, ...)
o draft-ietf-6tisch-6top-sf0-03
* Fixed typos
* Removed references to "effectively used cells"
* Changed Cell Estimation Algorithm to the third proposed
alternative on IETF97
* Forced cell deletion becomes implementation specific
* Added PDR calculation formula
* Added PDR_THRESHOLD as implementation specific value
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
Email: diego.dujovne@mail.udp.cl Email: diego.dujovne@mail.udp.cl
 End of changes. 87 change blocks. 
272 lines changed or deleted 192 lines changed or added

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