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