draft-ietf-6tisch-6top-sf0-02.txt   draft-ietf-6tisch-6top-sf0-03.txt 
6TiSCH D. Dujovne, Ed. 6TiSCH D. Dujovne, Ed.
Internet-Draft Universidad Diego Portales Internet-Draft Universidad Diego Portales
Intended status: Standards Track LA. Grieco Intended status: Standards Track LA. Grieco
Expires: May 4, 2017 Politecnico di Bari Expires: September 14, 2017 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
October 31, 2016 March 13, 2017
6TiSCH 6top Scheduling Function Zero (SF0) 6TiSCH 6top Scheduling Function Zero (SF0)
draft-ietf-6tisch-6top-sf0-02 draft-ietf-6tisch-6top-sf0-03
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 allocated
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
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 May 4, 2017. This Internet-Draft will expire on September 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
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. 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. SF0 Triggering Events . . . . . . . . . . . . . . . . . . . . 4
5. SF0 Cell Estimation Algorithm . . . . . . . . . . . . . . . . 5 5. SF0 Cell Estimation Algorithm . . . . . . . . . . . . . . . . 4
6. SF0 Allocation Policy . . . . . . . . . . . . . . . . . . . . 5 6. SF0 Allocation Policy . . . . . . . . . . . . . . . . . . . . 5
7. Rules for CellList . . . . . . . . . . . . . . . . . . . . . 6 7. Rules for CellList . . . . . . . . . . . . . . . . . . . . . 6
8. 6P Timeout Value . . . . . . . . . . . . . . . . . . . . . . 7 8. 6P Timeout Value . . . . . . . . . . . . . . . . . . . . . . 7
9. Meaning of Metadata Information . . . . . . . . . . . . . . . 7 9. Meaning of Metadata Information . . . . . . . . . . . . . . . 7
10. Node Behavior at Boot . . . . . . . . . . . . . . . . . . . . 7 10. Node Behavior at Boot . . . . . . . . . . . . . . . . . . . . 7
11. Relocating Cells . . . . . . . . . . . . . . . . . . . . . . 7 11. Cell Type . . . . . . . . . . . . . . . . . . . . . . . . . . 7
12. Forced Cell Deletion Policy . . . . . . . . . . . . . . . . . 8 12. SF0 Statistics . . . . . . . . . . . . . . . . . . . . . . . 8
13. 6P Error Handling . . . . . . . . . . . . . . . . . . . . . . 8 13. Relocating Cells . . . . . . . . . . . . . . . . . . . . . . 8
14. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 14. Forced Cell Deletion Policy . . . . . . . . . . . . . . . . . 8
15. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 15. 6P Error Handling . . . . . . . . . . . . . . . . . . . . . . 8
16. Security Considerations . . . . . . . . . . . . . . . . . . . 9 16. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 17. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
18. 6P Compliance . . . . . . . . . . . . . . . . . . . . . . . . 9 18. Security Considerations . . . . . . . . . . . . . . . . . . . 9
19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 20. 6P Compliance . . . . . . . . . . . . . . . . . . . . . . . . 10
20.1. Normative References . . . . . . . . . . . . . . . . . . 10 21. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
20.2. Informative References . . . . . . . . . . . . . . . . . 10 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
22.1. Normative References . . . . . . . . . . . . . . . . . . 10
22.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. [TEMPORARY] Changelog . . . . . . . . . . . . . . . 11 Appendix A. [TEMPORARY] Changelog . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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 37 skipping to change at page 3, line 37
This document defines a minimal Scheduling Function for the 6top This document defines a minimal Scheduling Function for the 6top
sublayer [I-D.ietf-6tisch-6top-protocol], called "Scheduling Function sublayer [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 the minimal set of
functionalities to be usable in a wide range of applications. SF0 functionalities to be usable in a wide range of applications. SF0
defines two algorithms: The Scheduling Algorithm defines the number defines two algorithms: The Scheduling Algorithm defines the number
of cells to allocate/delete between two neighbours and the relocation of cells to allocate/delete between two neighbours and the relocation
algorithm defines when to relocate a cell. algorithm defines when to relocate a cell.
The Scheduling Algorithm: A number of TX and/or RX cells must be The Scheduling Algorithm: A number of TX and/or RX cells must be
allocated between neighbor nodes in order to enable data transmission allocated between neighbor nodes in order to enable data transmission
among them. From the allocated cells, a part of them can be under among them. A portion of these allocated cells will be utilized by
effective use by the neighbours, while the rest of cells are over- neighbors, while the remaining cells can be over-provisioned to
provisioned to detect an increase in cell usage without packet loss. handle unanticipated increases in cell requirements. The Scheduling
The Scheduling Algorithm collects the cell allocation/deletion Algorithm collects the cell allocation/deletion requests from the
requests from the neighbors and the number of cells which are neighbors and the number of cells which are currently under usage.
currently under usage. First, a Cell Estimation Algotithm calculates First, the Cell Estimation Algotithm calculates the number of
the number of required cells by adding the collected values and required cells by adding the collected values and second, the
second, the calculated value is given to the Allocation Policy, which calculated value is given to the Allocation Policy, which provides
provides stability by adding hystheresis and overprovisioning by stability by adding hystheresis and overprovisioning by deciding when
deciding when to schedule the new number of cells, according to a to schedule the new number of cells, according to a threshold. In
threshold. In order to reduce consumption, this algorithm is order to reduce consumption, this algorithm is triggered only when
triggered only when there is a change on the number of effectively there is a change on the number of effectively used cells or if there
used cells or if there is a change on the number of requested cells is a change on the number of requested cells from a particular node.
from a particular node.
The Relocation Algorithm: Allocated cells may experiment packet loss The Relocation Algorithm: Allocated cells may experience packet loss
from different sources, such as noise, interference or cell collision from different sources, such as noise, interference or cell collision
(after the same cell is allocated by other nodes in range on the (after the same cell is allocated by other nodes in range on the
network). In order to avoid this problem, Packet Delivery Rate (PDR) network). In order to avoid this problem, Packet Delivery Rate (PDR)
is monitored periodically for each allocated cell. A relocation is is monitored periodically for each allocated cell. A relocation is
triggered when the PDR value drops below a certain threshold, triggered when the PDR value drops below a certain threshold,
compared to the average PDR of the rest of allocated cells. The compared to the average PDR of the rest of allocated cells. The
destination location on the schedule is defined randomly. 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:
skipping to change at page 4, line 27 skipping to change at page 4, line 24
1. It waits for a triggering event (Section 4). 1. It waits for a triggering event (Section 4).
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 5).
3. It applies the Allocation Policy to compare the number of 3. It applies the Allocation Policy to compare the number of
required cells to the number of already scheduled cells, and required cells to the number of already scheduled cells, and
determines the number of cells to add/delete (Section 6). determines the number of cells to add/delete (Section 6).
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 the requirements for a scheduling function listed in Section 5.2 from
[TODO: update if needed] from [I-D.ietf-6tisch-6top-protocol], and [I-D.ietf-6tisch-6top-protocol], and follows the recommended outline
follows the recommended outline listed in Section 5.3 [TODO: update listed in Section 5.3 of [I-D.ietf-6tisch-6top-protocol]. This
if needed] of [I-D.ietf-6tisch-6top-protocol]. This document follows document follows the terminology defined in
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_SFID_SF0.
4. SF0 Triggering Events 4. SF0 Triggering Events
We RECOMMEND SF0 to be triggered at least by the following events: We RECOMMEND SF0 to be triggered at least by the following events:
1. If there is a change in the current number of used cells 1. If there is a change in the current number of required cells
2. If there is a successful cell allocation/deallocation process 2. If there is a successful cell allocation/deallocation process
with the neighbour. with the neighbour.
This allows SF0 to be triggered by any change in locally generated or This allows SF0 to be triggered by any change in locally generated or
incoming traffic. The exact mechanism of when SF0 is triggered is incoming traffic. The exact mechanism of when SF0 is triggered is
implementation-specific. implementation-specific.
5. SF0 Cell Estimation Algorithm 5. SF0 Cell Estimation Algorithm
The Cell Estimation Algorithm takes into account the new incoming The Cell Estimation Algorithm takes into account the new incoming
cell requirements from the neighbor node and the current outgoing cell requirements from the neighbor node and the current outgoing
number of effectively used cells. 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 allocated. As a consequence, number of cells to be allocated. As a consequence, the Cell
the Cell Estimation Algorithm for SF0 follows the steps described Estimation Algorithm for SF0 follows the steps described below:
below:
1. Collect the new incoming cell requirements from the neighbor 1. Collect the current number of used cells
2. Collect the current number of effectively used cells 2. Calculate the new number of cells to be allocated by adding the
3. Calculate the new number of cells to be allocated by adding the current number of used cells plus an OVERPROVISION number of
current number of effectively used cells and the new incoming cells
cells requirement 3. Submit the request to the allocation policy as REQUIREDCELLS
4. Submit the request to the allocation policy as REQUIREDCELLS 4. Return to step 1 and wait for a triggering event.
5. Return to step 1 and wait for a triggering event.
A new incoming cell requirement is the result of a successful The OVERPROVISION parameter is a percentage of the currently
allocation process from the neighbor. TODO/REMARK: Add a number of allocated cells which is added to the used cells to guarantee that
cells to the required cells as OVERPROVISION to guarantee that the the growth on the number of used cells can be detected without packet
growth on the effectively used cells can be identified without packet loss. This percentage value is implementation-specific. A value of
loss. This value is implementation specific. A value of
OVERPROVISION equal to zero leads to queue growth and possible packet OVERPROVISION equal to zero leads to queue growth and possible packet
loss, since there are no overprovisioned cells to detect if there is loss, since there are no overprovisioned cells to detect if there is
a growth of effectively used cells. a growth on the number of used cells.
6. SF0 Allocation Policy 6. SF0 Allocation Policy
The "Allocation Policy" is the set of rules used by SF0 to decide The "Allocation Policy" is the set of rules used by SF0 to decide
when to add/delete cells to a particular neighbor to satisfy the 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
skipping to change at page 5, line 51 skipping to change at page 5, line 42
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. is illustrated in Figure 1. The number of cells to be scheduled/
deleted is out of the scope of this document and it is
implementation-dependent.
SCHEDULEDCELLS SCHEDULEDCELLS
<---------------------------------> <--------------------------------->
+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+
| | | | | | | | | | | | | | | | | | | |
+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+
|<----------------->| |<----------------->|
| SF0THRESH | | SF0THRESH |
| | | |
REQUIREDCELLS | | REQUIREDCELLS | |
skipping to change at page 7, line 40 skipping to change at page 7, line 40
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. The 6P Initial Timeout Value provided by SF0
should allow for the maximum number of TSCH link-layer retries, as should allow for the maximum number of TSCH link-layer retries, as
defined by Section 4.3.4 of [I-D.ietf-6tisch-6top-protocol]. TODO/ defined by Section 4.3.4 of [I-D.ietf-6tisch-6top-protocol]. TODO/
REMARK: The initial timeout is currently under discussion. REMARK: The initial timeout is currently under discussion on the
Mailing List.
11. Relocating Cells 11. Cell Type
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
[I-D.ietf-6tisch-6top-protocol].
12. SF0 Statistics
Packet Delivery Rate (PDR) is calculated per cell, as the quotient of
the number of successfully delivered packets to 10, for the last 10
packet transmission attempts, without counting retransmissions.
13. Relocating Cells
SF0 uses Packet Delivery Rate (PDR) statistics to monitor the SF0 uses Packet Delivery Rate (PDR) statistics to monitor the
currently allocated cells for cell 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 20% of the average PDR of the rest of the softcells is below PDR_THRESHOLD, defined as a percentage of the
scheduled cells, SF0 relocates the cell(s) to a number of available average of the PDR of the rest of the scheduled cells, SF0 relocates
cells selected randomly. REMARK: This criteria is currently under each of the cell(s) to a number of available cells selected randomly.
discussion; simulation/experimentation is required to either adjust PDR_THRESHOLD is out of the scope of this document and it is
the threshold or to change the process. implementation-dependent.
12. Forced Cell Deletion Policy 14. Forced Cell Deletion Policy
TODO: When all the cells are scheduled, we need a policy to free When all the cells are scheduled, we need a policy to free cells, for
cells, for example, under alarm conditions or if a node disappears example, under alarm conditions or if a node disappears from the
from the neighbor list. neighbor list. The action to follow this condition is out of scope
of this document and it is implementation-dependent.
13. 6P Error Handling 15. 6P Error Handling
A node implementing SF0 handles a 6P Response depending on the Return A node implementing SF0 handles a 6P Response depending on the Return
Code it contains: Code it contains:
RC_SUCCESS: RC_SUCCESS:
If the number of elements in the CellList is the number of cells If the number of elements in the CellList is the number of cells
specified in the NumCells field of the 6P 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. In that case, the NumCells of the cells in the CellList were allocated. In that
node MAY retry immediately with a different CellList if the amount case, the node MAY retry immediately with a different CellList if
of storage space permits, or build a new (random) CellList. the amount of storage space permits, or build a new (random)
CellList.
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 tot he neighbour. RC_ERR_GEN: The node MUST issue a CLEAR command to the neighbour.
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_NORES: Wait for a timeout and restart the scheduling process.
RC_ERR_RESET: Abort 6P Transaction RC_ERR_RESET: Abort 6P Transaction
RC_ERR: Abort 6P Transaction. The node MAY retry to contact this RC_ERR: Abort 6P Transaction. The node MAY retry to contact this
neighbor later. neighbor later.
14. Examples 16. Examples
TODO TODO
15. Implementation Status 17. Implementation Status
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC6982]. Internet-Draft, and is based on a proposal described in [RFC6982].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not supplied by IETF contributors. This is not intended as, and must not
skipping to change at page 9, line 23 skipping to change at page 9, line 43
It is up to the individual working groups to use this information as It is up to the individual working groups to use this information as
they see fit". they see fit".
OpenWSN: This specification is implemented in the OpenWSN project OpenWSN: This specification is implemented in the OpenWSN project
[OpenWSN]. The authors of this document are collaborating with [OpenWSN]. The authors of this document are collaborating with
the OpenWSN community to gather feedback about the status and the OpenWSN community to gather feedback about the status and
performance of the protocols described in this document. Results performance of the protocols described in this document. Results
from that discussion will appear in this section in future from that discussion will appear in this section in future
revision of this specification. revision of this specification.
16. Security Considerations 18. Security Considerations
TODO TODO
17. IANA Considerations 19. IANA Considerations
o IANA_SFID_SF0 o IANA_SFID_SF0
18. 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
o MUST specify a value for the 6P Timeout, or a rule/equation to o MUST specify a value for the 6P Timeout, or a rule/equation to
calculate it. calculate it. OK
o MUST specify a meaning for the "Metadata" field in the 6P ADD o MUST specify a meaning for the "Metadata" field in the 6P ADD
Request. OK Request. OK
o MUST specify the behavior of a node when it boots. 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 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 node sent a 6P Response with an error code, or received one). OK
o MUST specify the list of statistics to gather. An example o MUST specify the list of statistics to gather. An example
statistic if the number of transmitted frames to each neighbor. statistic if the number of transmitted frames to each neighbor.
In case the SF requires no statistics to be gathered, the specific In case the SF requires no statistics to be gathered, the specific
of the SF MUST explicitly state so. of the SF MUST explicitly state so. OK
o SHOULD clearly state the application domain the SF is created for. o SHOULD clearly state the application domain the SF is created for.
OK OK
o SHOULD contain examples which highlight normal and error o SHOULD contain examples which highlight normal and error
scenarios. scenarios.
o SHOULD contain a list of current implementations, at least during o SHOULD contain a list of current implementations, at least during
the I-D state of the document, per [RFC6982]. the I-D state of the document, per [RFC6982].
o SHOULD contain a performance evaluation of the scheme, possibly o SHOULD contain a performance evaluation of the scheme, possibly
through references to external documents. through references to external documents.
o MAY redefine the format of the CellList? field. o MAY redefine the format of the CellList? field. OK
19. Acknowledgments 21. Acknowledgments
Thanks to Kris Pister for his contribution in designing the default Thanks to Kris Pister for his contribution in designing the default
Bandwidth Estimation Algorithm. Thanks to Qin Wang and Thomas Bandwidth Estimation Algorithm. Thanks to Qin Wang and Thomas
Watteyne for their support in defining the interaction between SF0 Watteyne for their support in defining the interaction between SF0
and the 6top sublayer. and the 6top sublayer.
This work is partially supported by the Fondecyt 1121475 Project, the This work is partially supported by the Fondecyt 1121475 Project, the
Inria-Chile "Network Design" group, and the IoT6 European Project Inria-Chile "Network Design" group, and the IoT6 European Project
(STREP) of the 7th Framework Program (Grant 288445). (STREP) of the 7th Framework Program (Grant 288445).
20. References 22. References
20.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>.
20.2. Informative References 22.2. Informative References
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982, Code: The Implementation Status Section", RFC 6982,
DOI 10.17487/RFC6982, July 2013, DOI 10.17487/RFC6982, July 2013,
<http://www.rfc-editor.org/info/rfc6982>. <http://www.rfc-editor.org/info/rfc6982>.
[I-D.ietf-6tisch-terminology] [I-D.ietf-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terminology in IPv6 over the TSCH mode of IEEE "Terminology in IPv6 over the TSCH mode of IEEE
802.15.4e", draft-ietf-6tisch-terminology-07 (work in 802.15.4e", draft-ietf-6tisch-terminology-08 (work in
progress), March 2016. progress), December 2016.
[I-D.ietf-6tisch-6top-protocol] [I-D.ietf-6tisch-6top-protocol]
Wang, Q. and X. Vilajosana, "6top Protocol (6P)", draft- Wang, Q. and X. Vilajosana, "6top Protocol (6P)", draft-
ietf-6tisch-6top-protocol-02 (work in progress), July ietf-6tisch-6top-protocol-03 (work in progress), October
2016. 2016.
[OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F.,
Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN:
a Standards-Based Low-Power Wireless Development a Standards-Based Low-Power Wireless Development
Environment", Transactions on Emerging Telecommunications Environment", Transactions on Emerging Telecommunications
Technologies , August 2012. Technologies , August 2012.
Appendix A. [TEMPORARY] Changelog 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
* 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
 End of changes. 41 change blocks. 
90 lines changed or deleted 114 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/