< draft-ietf-6tisch-msf-04.txt   draft-ietf-6tisch-msf-05.txt >
6TiSCH T. Chang, Ed. 6TiSCH T. Chang, Ed.
Internet-Draft M. Vucinic Internet-Draft M. Vucinic
Intended status: Standards Track Inria Intended status: Standards Track Inria
Expires: January 3, 2020 X. Vilajosana Expires: January 9, 2020 X. Vilajosana
Universitat Oberta de Catalunya Universitat Oberta de Catalunya
S. Duquennoy S. Duquennoy
RISE SICS RISE SICS
D. Dujovne D. Dujovne
Universidad Diego Portales Universidad Diego Portales
July 2, 2019 July 8, 2019
6TiSCH Minimal Scheduling Function (MSF) 6TiSCH Minimal Scheduling Function (MSF)
draft-ietf-6tisch-msf-04 draft-ietf-6tisch-msf-05
Abstract Abstract
This specification defines the 6TiSCH Minimal Scheduling Function This specification defines the 6TiSCH Minimal Scheduling Function
(MSF). This Scheduling Function describes both the behavior of a (MSF). This Scheduling Function describes both the behavior of a
node when joining the network, and how the communication schedule is node when joining the network, and how the communication schedule is
managed in a distributed fashion. MSF builds upon the 6TiSCH managed in a distributed fashion. MSF builds upon the 6TiSCH
Operation Sublayer Protocol (6P) and the Minimal Security Framework Operation Sublayer Protocol (6P) and the Minimal Security Framework
for 6TiSCH. for 6TiSCH.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 January 3, 2020. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Interface to the Minimal 6TiSCH Configuration . . . . . . . . 4 2. Interface to the Minimal 6TiSCH Configuration . . . . . . . . 4
3. Autonomous Cells . . . . . . . . . . . . . . . . . . . . . . 4 3. Autonomous Cells . . . . . . . . . . . . . . . . . . . . . . 4
4. Node Behavior at Boot . . . . . . . . . . . . . . . . . . . . 6 4. Node Behavior at Boot . . . . . . . . . . . . . . . . . . . . 6
4.1. Start State . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Start State . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Step 1 - Choosing Frequency . . . . . . . . . . . . . . . 6 4.2. Step 1 - Choosing Frequency . . . . . . . . . . . . . . . 6
4.3. Step 2 - Receiving EBs . . . . . . . . . . . . . . . . . 6 4.3. Step 2 - Receiving EBs . . . . . . . . . . . . . . . . . 6
4.4. Step 3 - Setting up Autonomous Cells for the Join Process 7 4.4. Step 3 - Setting up Autonomous Cells for the Join Process 7
4.5. Step 4 - Acquiring a RPL rank . . . . . . . . . . . . . . 7 4.5. Step 4 - Acquiring a RPL Rank . . . . . . . . . . . . . . 7
4.6. Step 5 - Setting up first Tx and Rx negotiated Cells . . 7 4.6. Step 5 - Setting up first Tx and Rx negotiated Cells . . 7
4.7. Step 6 - Send EBs and DIOs . . . . . . . . . . . . . . . 8 4.7. Step 6 - Send EBs and DIOs . . . . . . . . . . . . . . . 8
4.8. End State . . . . . . . . . . . . . . . . . . . . . . . . 8 4.8. End State . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Rules for Adding/Deleting Cells . . . . . . . . . . . . . . . 8 5. Rules for Adding/Deleting Cells . . . . . . . . . . . . . . . 8
5.1. Adapting to Traffic . . . . . . . . . . . . . . . . . . . 9 5.1. Adapting to Traffic . . . . . . . . . . . . . . . . . . . 9
5.2. Switching Parent . . . . . . . . . . . . . . . . . . . . 10 5.2. Switching Parent . . . . . . . . . . . . . . . . . . . . 10
5.3. Handling Schedule Collisions . . . . . . . . . . . . . . 11 5.3. Handling Schedule Collisions . . . . . . . . . . . . . . 11
6. 6P SIGNAL command . . . . . . . . . . . . . . . . . . . . . . 12 6. 6P SIGNAL command . . . . . . . . . . . . . . . . . . . . . . 12
7. Scheduling Function Identifier . . . . . . . . . . . . . . . 12 7. Scheduling Function Identifier . . . . . . . . . . . . . . . 12
8. Rules for CellList . . . . . . . . . . . . . . . . . . . . . 12 8. Rules for CellList . . . . . . . . . . . . . . . . . . . . . 12
skipping to change at page 4, line 27 skipping to change at page 4, line 27
MSF uses the minimal cell to exchange the following packets: MSF uses the minimal cell to exchange the following packets:
1. Enhanced Beacons (EBs), defined by [IEEE802154-2015]. These are 1. Enhanced Beacons (EBs), defined by [IEEE802154-2015]. These are
broadcast frames. broadcast frames.
2. Broadcast DODAG Information Objects (DIOs), defined by [RFC6550]. 2. Broadcast DODAG Information Objects (DIOs), defined by [RFC6550].
Unicast DIOs SHOULD NOT be sent on minimal cell. Unicast DIOs SHOULD NOT be sent on minimal cell.
To ensure there is enough bandwidth available on the minimal cell, a To ensure there is enough bandwidth available on the minimal cell, a
node implementing MSF SHOULD enforce some rules for limiting the node implementing MSF SHOULD enforce some rules for limiting the
traffic of broadcast frames. For example, a Trickle Timer defined in traffic of broadcast frames. For example, a Trickle Timer defined in
[RFC6550] MAY be applied on DIOs. However, this behvaior is [RFC6550] MAY be applied on DIOs. However, this behavior is
implementation-specific which is out of the scope of MSF. implementation-specific which is out of the scope of MSF.
MSF RECOMMENDS the use of 3 slotframes. MSF schedules autonomous MSF RECOMMENDS the use of 3 slotframes. MSF schedules autonomous
cells at Slotframe 1 (Section 3) and 6P negotiated cells at Slotframe cells at Slotframe 1 (Section 3) and 6P negotiated cells at Slotframe
2 (Section 5) , while Slotframe 0 is used for the boostrap traffic as 2 (Section 5) , while Slotframe 0 is used for the bootstrap traffic
defined in the Minimal 6TiSCH Configuration. It is RECOMMENDED to as defined in the Minimal 6TiSCH Configuration. It is RECOMMENDED to
use the same slotframe length for Slotframe 0, 1 and 2. Thus it is use the same slotframe length for Slotframe 0, 1 and 2. Thus it is
possible to avoid the sheduling collision between the autonomous possible to avoid the scheduling collision between the autonomous
cells and 6P negotiated cells (Section 3). The default slotframe cells and 6P negotiated cells (Section 3). The default slotframe
length (SLOTFRAME_LENGTH) is RECOMMENDED for Slotframe 0, 1 and 2, length (SLOTFRAME_LENGTH) is RECOMMENDED for Slotframe 0, 1 and 2,
although any value can be advertised in the EBs. although any value can be advertised in the EBs.
3. Autonomous Cells 3. Autonomous Cells
MSF nodes initialize Slotframe 1 with a set of default cells for MSF nodes initialize Slotframe 1 with a set of default cells for
unicast communication with their neighbors. These cells are called unicast communication with their neighbors. These cells are called
'autonomous cells', because they are maintained autonomously by each 'autonomous cells', because they are maintained autonomously by each
node without negotiation through 6P. Cells scheduled by 6P node without negotiation through 6P. Cells scheduled by 6P
transaction are called 'negotiated cells' which are reserved on transaction are called 'negotiated cells' which are reserved on
Slotframe 2. How to schedule negotiated cells is detailed in Slotframe 2. How to schedule negotiated cells is detailed in
Section 5. There are two types of autonomous cells: Section 5. There are two types of autonomous cells:
o Autonomous Rx Cell (AutoRxCell), one cell at a o Autonomous Rx Cell (AutoRxCell), one cell at a
[slotOffset,channelOffset] computed as a hash of the EUI64 of the [slotOffset,channelOffset] computed as a hash of the EUI64 of the
node itself (detailed next). Its cell options bits are assigned node itself (detailed next). Its cell options bits are assigned
as TX=0, RX=1, SHARED=0. as TX=0, RX=1, SHARED=0.
o Autonomous Tx Cell (AutoTxCell), one cell at a o Autonomous Tx Cell (AutoTxCell), one cell at a
[slotOffset,channelOffset] computed as a hash of the layer 2 EUI64 [slotOffset,channelOffset] computed as a hash of the layer 2 EUI64
source address in the frame to be transmitted (detailed in destination address in the frame to be transmitted (detailed in
Section 4.4). Its cell options bits are assigned as TX=1, RX=0, Section 4.4). Its cell options bits are assigned as TX=1, RX=0,
SHARED=1. SHARED=1.
To compute a [slotOffset,channelOffset] from an EUI64 address, nodes To compute a [slotOffset,channelOffset] from an EUI64 address, nodes
MUST use the hash function SAX [SAX-DASFAA]. The coordinates are MUST use the hash function SAX [SAX-DASFAA]. The coordinates are
computed to distribute the cells across all channel offsets, and all computed to distribute the cells across all channel offsets, and all
but the first time offsets of Slotframe 1. The first time offset is but the first time offsets of Slotframe 1. The first time offset is
skipped to avoid colliding with the minimal cell in Slotframe 0. The skipped to avoid colliding with the minimal cell in Slotframe 0. The
slot coordinates derived from a given EUI64 address are computed as slot coordinates derived from a given EUI64 address are computed as
follows: follows:
skipping to change at page 5, line 32 skipping to change at page 5, line 32
The second input parameter defines the maximum return value of the The second input parameter defines the maximum return value of the
hash function. Other optional parameters defined in SAX determine hash function. Other optional parameters defined in SAX determine
the performance of SAX hash function. Those parameters could be the performance of SAX hash function. Those parameters could be
broadcasted in EB frame or pre-configured. For interoperability broadcasted in EB frame or pre-configured. For interoperability
purposes, an example how the hash function is implemented is detailed purposes, an example how the hash function is implemented is detailed
in Appendix B. in Appendix B.
AutoTxCell is not permanent in the schedule but added/deleted on AutoTxCell is not permanent in the schedule but added/deleted on
demand when there is a frame to sent. Throughout the network demand when there is a frame to sent. Throughout the network
lifetime, nodes MUST maintain the autonomous cells as follows: lifetime, nodes maintain the autonomous cells as follows:
o Add an AutoTxCell to the layer 2 source address which is indicated o Add an AutoTxCell to the layer 2 destination address which is
in a frame when: indicated in a frame when:
* there is no 6P negotiated Tx cell in schedule for that frame to * there is no 6P negotiated Tx cell in schedule for that frame to
transmit, and transmit, and
* the frame is used for protocol management purposes , such as * the frame is used for protocol management purposes , such as
Join Request/Response, 6P Request/Response and any link-local Join Request/Response, 6P Request/Response and any link-local
communication for RPL routing control. communication for RPL routing control.
o Remove an AutoTxCell when: o Remove an AutoTxCell when:
* there is no frame for protocol management purposes to transmit, * there is no frame for protocol management purposes to transmit,
or or
* there is at least one 6P negotiated Tx cell in the schedule to * there is at least one 6P negotiated Tx cell in the schedule to
transmit a management purpose frame. transmit a management purpose frame.
o The AutoRxCell MUST always remain scheduled. o The AutoRxCell MUST always remain scheduled after synchronized.
o 6P CLEAR MUST NOT erase any autonomous cells. o 6P CLEAR MUST NOT erase any autonomous cells.
Because of hash collisions, there will be cases when the AutoTxCell Because of hash collisions, there will be cases when the AutoTxCell
and AutoRxCell are scheduled at the same slot offset and/or channel and AutoRxCell are scheduled at the same slot offset and/or channel
offset. In such cases, AutoTxCell always take precedence over offset. In such cases, AutoTxCell always take precedence over
AutoRxCell. In case of conflicting with a negotiated cell, AutoRxCell. In case of conflicting with a negotiated cell,
autonomous cells take precedence over negotiated cell. However, when autonomous cells take precedence over negotiated cell, which is
the Slotframe 0, 1 and 2 use the same length value, it is possible stated in [IEEE802154-2015]. However, when the Slotframe 0, 1 and 2
for negoitated cell to avoid the collision with AutoRxCell. use the same length value, it is possible for negotiated cell to
avoid the collision with AutoRxCell.
4. Node Behavior at Boot 4. Node Behavior at Boot
This section details the behavior the node SHOULD follow from the This section details the behavior the node SHOULD follow from the
moment it is switched on, until it has successfully joined the moment it is switched on, until it has successfully joined the
network. Section 4.1 details the start state; Section 4.8 details network. Section 4.1 details the start state; Section 4.8 details
the end state. The other sections detail the 6 steps of the joining the end state. The other sections detail the 6 steps of the joining
process. We use the term "pledge" and "joined node", as defined in process. We use the term "pledge" and "joined node", as defined in
[I-D.ietf-6tisch-minimal-security]. [I-D.ietf-6tisch-minimal-security].
skipping to change at page 7, line 5 skipping to change at page 7, line 5
1. the number of neighbors N in its vicinity 1. the number of neighbors N in its vicinity
2. which neighbor to choose as a Join Proxy (JP) for the joining 2. which neighbor to choose as a Join Proxy (JP) for the joining
process process
While the exact behavior is implementation-specific, the RECOMMENDED While the exact behavior is implementation-specific, the RECOMMENDED
behavior is to follow [RFC8180], and listen until EBs sent by behavior is to follow [RFC8180], and listen until EBs sent by
NUM_NEIGHBOURS_TO_WAIT nodes (defined in [RFC8180]) have been NUM_NEIGHBOURS_TO_WAIT nodes (defined in [RFC8180]) have been
received. received.
During this step, the pledge MAY synchronize to any EB it receives During this step, the pledge SHOULD NOT synchronize until it received
from the network it wishes to join. How to decide whether an EB enough EB from the network it wishes to join. How to decide whether
originates from a node from the network it wishes to join is an EB originates from a node from the network it wishes to join is
implementation-specific, but MAY involve filtering EBs by the PAN ID implementation-specific, but MAY involve filtering EBs by the PAN ID
field it contains, the presence and contents of the IE defined in field it contains, the presence and contents of the IE defined in
[I-D.richardson-6tisch-join-enhanced-beacon], or the key used to [I-D.richardson-6tisch-join-enhanced-beacon], or the key used to
authenticate it. authenticate it.
The decision of which neighbor to use as a JP is implementation- The decision of which neighbor to use as a JP is implementation-
specific, and discussed in [I-D.ietf-6tisch-minimal-security]. specific, and discussed in [I-D.ietf-6tisch-minimal-security].
4.4. Step 3 - Setting up Autonomous Cells for the Join Process 4.4. Step 3 - Setting up Autonomous Cells for the Join Process
skipping to change at page 7, line 33 skipping to change at page 7, line 33
JRC, possibly over multiple hops, over the 6P negotiated Tx cell. JRC, possibly over multiple hops, over the 6P negotiated Tx cell.
Similarly, the JRC sends the Join Response to the JP, possibly over Similarly, the JRC sends the Join Response to the JP, possibly over
multiple hops, over the 6P negotiated Tx cell. When JP received the multiple hops, over the 6P negotiated Tx cell. When JP received the
Join Response from the JRC, it installs an AutoTxCell to the pledge Join Response from the JRC, it installs an AutoTxCell to the pledge
and sends that Join Response to the pledge over AutoTxCell. The and sends that Join Response to the pledge over AutoTxCell. The
AutoTxCell is removed by the JP when the Join Response is sent out. AutoTxCell is removed by the JP when the Join Response is sent out.
The pledge receives the Join Response from its AutoRxCell, thereby The pledge receives the Join Response from its AutoRxCell, thereby
learns the keying material used in the network, as well as other learns the keying material used in the network, as well as other
configurations, and becomes a "joined node". configurations, and becomes a "joined node".
4.5. Step 4 - Acquiring a RPL rank When 6LoWPAN Neighbor Dicovery ([RFC8505]) (ND) is implemented, the
unicast packets used by ND are sent on the AutoTxCell. The specific
process how the ND works during the Join process is detailed in
[I-D.ietf-6tisch-architecture].
Per [RFC6550], the joined node receives DIOs, computes its own rank, 4.5. Step 4 - Acquiring a RPL Rank
Per [RFC6550], the joined node receives DIOs, computes its own Rank,
and selects a preferred parent. and selects a preferred parent.
4.6. Step 5 - Setting up first Tx and Rx negotiated Cells 4.6. Step 5 - Setting up first Tx and Rx negotiated Cells
After selected a preferred parent, the joined node MUST generate a 6P After selected a preferred parent, the joined node MUST generate a 6P
ADD Request and install an AutoTxCell to that parent. The 6P ADD ADD Request and install an AutoTxCell to that parent. The 6P ADD
Request is sent out through the AutoTxCell with the following fields: Request is sent out through the AutoTxCell with the following fields:
o CellOptions: set to TX=1,RX=0,SHARED=0 o CellOptions: set to TX=1,RX=0,SHARED=0
o NumCells: set to 1 o NumCells: set to 1
skipping to change at page 8, line 18 skipping to change at page 8, line 23
After the first negotiated Tx Cell is installed, the joined node After the first negotiated Tx Cell is installed, the joined node
SHOULD send another 6P ADD Request with the following fields: SHOULD send another 6P ADD Request with the following fields:
o CellOptions: set to TX=0,RX=1,SHARED=0 o CellOptions: set to TX=0,RX=1,SHARED=0
o NumCells: set to 1 o NumCells: set to 1
o CellList: at least 5 cells, chosen according to Section Section 8 o CellList: at least 5 cells, chosen according to Section Section 8
The process to install a negotiated Rx cell is the similar with the The process to install a negotiated Rx cell is the similar with the
process to install a negotiated Tx cell. The only difference is that process to install a negotiated Tx cell. The only difference is that
the 6P ADD Request is sent on the neogtiated Tx cell installed the 6P ADD Request is sent on the negotiated Tx cell installed
previously, instead of the AutoTxCell. previously, instead of the AutoTxCell.
4.7. Step 6 - Send EBs and DIOs 4.7. Step 6 - Send EBs and DIOs
The node SHOULD start sending EBs and DIOs on the minimal cell, while The node SHOULD start sending EBs and DIOs on the minimal cell, while
following the transmit rules for broadcast frames from Section 2. following the transmit rules for broadcast frames from Section 2.
4.8. End State 4.8. End State
For a new node, the end state of the joining process is: For a new node, the end state of the joining process is:
skipping to change at page 9, line 45 skipping to change at page 10, line 4
parent, NumCellsElapsed is incremented by exactly 1, regardless parent, NumCellsElapsed is incremented by exactly 1, regardless
of whether the cell is used to transmit/receive a frame. of whether the cell is used to transmit/receive a frame.
NumCellsUsed: Counts the number of negotiated cells that have been NumCellsUsed: Counts the number of negotiated cells that have been
used. This counter is initialized at 0. NumCellsUsed is used. This counter is initialized at 0. NumCellsUsed is
incremented by exactly 1 when, during a negotiated cell to the incremented by exactly 1 when, during a negotiated cell to the
preferred parent, either of the following happens: preferred parent, either of the following happens:
* The node sends a frame to its preferred parent. The counter * The node sends a frame to its preferred parent. The counter
increments regardless of whether a link-layer acknowledgment increments regardless of whether a link-layer acknowledgment
was received or not. was received or not.
* The node receives a frame from its preferred parent. The * The node receives a frame from its preferred parent. The
counter increments regardless of whether the frame is a valid counter increments regardless of whether the frame is a valid
IEEE802.15.4 frame or not. IEEE802.15.4 frame or not.
Both NumCellsElapsed and NumCellsUsed counters can be used to The cell option of the cell listed CellList in 6P Request SHOULD be
negotiated cells with cell option TX=1 or Rx=1. All the frames used either Tx=1 only or Rx=1 only. Both NumCellsElapsed and NumCellsUsed
for increasing/decreasing the counters MUST be encrypted or counters can be used to both type of negotiated cells.
decryptable with the key get from joining process.
Implementors MAY choose to create the same counters for each Implementors MAY choose to create the same counters for each
neighbor, and add them as additional statistics in the neighbor neighbor, and add them as additional statistics in the neighbor
table. table.
The counters are used as follows: The counters are used as follows:
1. Both NumCellsElapsed and NumCellsUsed are initialized to 0 when 1. Both NumCellsElapsed and NumCellsUsed are initialized to 0 when
the node boots. the node boots.
2. When the value of NumCellsElapsed reaches MAX_NUMCELLS: 2. When the value of NumCellsElapsed reaches MAX_NUMCELLS:
* If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to add a * If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to add a
single cell to the preferred parent single cell to the preferred parent
* If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to remove a * If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to remove a
single cell to the preferred parent single cell to the preferred parent
* Reset both NumCellsElapsed and NumCellsUsed to 0 and go to * Reset both NumCellsElapsed and NumCellsUsed to 0 and go to
step 2. step 2.
The value of MAX_NUMCELLS is chosen according to the traffic type of The value of MAX_NUMCELLS is chosen according to the traffic type of
the network. Generally speaking, the larger the value MAX_NUMCELLS the network. Generally speaking, the larger the value MAX_NUMCELLS
is, the more accurate the cell usage is calulated. The 6P traffic is, the more accurate the cell usage is calculated. The 6P traffic
overhead using a larger value of MAX_NUMCELLS could be reduced as overhead using a larger value of MAX_NUMCELLS could be reduced as
well. Meanwhile, the latency won't increaase much by using a larger well. Meanwhile, the latency won't increaase much by using a larger
value of MAX_NUMCELLS for periodic traffic type. For burst traffic value of MAX_NUMCELLS for periodic traffic type. For burst traffic
type, larger value of MAX_NUMCELLS indeed introduces higher latency. type, larger value of MAX_NUMCELLS indeed introduces higher latency.
The latency caused by slight changes of traffic load can be absolved The latency caused by slight changes of traffic load can be absolved
by the additional scheduled cells. In this sense, MSF is a by the additional scheduled cells. In this sense, MSF is a
scheduling function trading latency with energy by scheduling more scheduling function trading latency with energy by scheduling more
cells than needed. It is recommended to set MAX_NUMCELLS value at cells than needed. It is recommended to set MAX_NUMCELLS value at
least 4 times than the maximum link traffic load of the network in least 4 times than the maximum link traffic load of the network in
packets per slotframe. For example, a 2 packets/slotframe traffic packets per slotframe. For example, a 2 packets/slotframe traffic
skipping to change at page 11, line 5 skipping to change at page 11, line 9
5.2. Switching Parent 5.2. Switching Parent
A node implementing MSF SHOULD implement the behavior described in A node implementing MSF SHOULD implement the behavior described in
this section. this section.
Part of its normal operation, the RPL routing protocol can have a Part of its normal operation, the RPL routing protocol can have a
node switch preferred parent. The procedure for switching from the node switch preferred parent. The procedure for switching from the
old preferred parent to the new preferred parent is: old preferred parent to the new preferred parent is:
1. if there is negotiated cell conflicted with the AutoUpCells to be 1. the node counts the number of negotiated cells it has per
installed, the node MUST issue a 6P RELOCATE command to relocate
the conflicted cell
2. if there is no conflicted cell, the node installs the AutoUpCells
to its new parent
3. the node counts the number of negotiated cells it has per
slotframe to the old preferred parent slotframe to the old preferred parent
4. the node triggers one or more 6P ADD commands to schedule the 2. the node triggers one or more 6P ADD commands to schedule the
same number of negotiated cells to the new preferred parent same number of negotiated cells to the new preferred parent
5. when that successfully completes, the node issues a 6P CLEAR 3. when that successfully completes, the node issues a 6P CLEAR
command to its old preferred parent command to its old preferred parent
5.3. Handling Schedule Collisions 5.3. Handling Schedule Collisions
A node implementing MSF SHOULD implement the behavior described in A node implementing MSF SHOULD implement the behavior described in
this section. The "MUST" statements in this section hence only apply this section. The "MUST" statements in this section hence only apply
if the node implements schedule collision handling. if the node implements schedule collision handling.
Since scheduling is entirely distributed, there is a non-zero Since scheduling is entirely distributed, there is a non-zero
probability that two pairs of nearby neighbor nodes schedule a probability that two pairs of nearby neighbor nodes schedule a
skipping to change at page 11, line 52 skipping to change at page 11, line 51
Since both NumTx and NumTxAck are initialized to 0, we necessarily Since both NumTx and NumTxAck are initialized to 0, we necessarily
have NumTxAck <= NumTx. We call Packet Delivery Ratio (PDR) the have NumTxAck <= NumTx. We call Packet Delivery Ratio (PDR) the
ratio NumTxAck/NumTx; and represent it as a percentage. A cell with ratio NumTxAck/NumTx; and represent it as a percentage. A cell with
PDR=50% means that half of the frames transmitted are not PDR=50% means that half of the frames transmitted are not
acknowledged (and need to be retransmitted). acknowledged (and need to be retransmitted).
Each time the node switches preferred parent (or during the join Each time the node switches preferred parent (or during the join
process when the node selects a preferred parent for the first time), process when the node selects a preferred parent for the first time),
both NumTx and NumTxAck MUST be reset to 0. They increment over both NumTx and NumTxAck MUST be reset to 0. They increment over
time, as the schedule is executed and the node sends frames to its time, as the schedule is executed and the node sends frames to its
preferred parent. When NumTx reaches 256, both NumTx and NumTxAck preferred parent. When NumTx reaches MAX_NUMTX, both NumTx and
MUST be divided by 2. That is, for example, from NumTx=256 and NumTxAck MUST be divided by 2. That is, for example, from NumTx=256
NumTxAck=128, they become NumTx=128 and NumTxAck=64. This operation and NumTxAck=128, they become NumTx=128 and NumTxAck=64. This
does not change the value of the PDR, but allows the counters to keep operation does not change the value of the PDR, but allows the
incrementing. counters to keep incrementing. The value of MAX_NUMTX is
implementation-specific.
The key for detecting a schedule collision is that, if a node has The key for detecting a schedule collision is that, if a node has
several cells to the same preferred parent, all cells should exhibit several cells to the same preferred parent, all cells should exhibit
the same PDR. A cell which exhibits a PDR significantly lower than the same PDR. A cell which exhibits a PDR significantly lower than
the others indicates than there are collisions on that cell. the others indicates than there are collisions on that cell.
Every HOUSEKEEPINGCOLLISION_PERIOD, the node executes the following Every HOUSEKEEPINGCOLLISION_PERIOD, the node executes the following
steps: steps:
1. It computes, for each managed unicast cell with its preferred 1. It computes, for each managed unicast cell with its preferred
parent (not for the autonomous cell), that cell's PDR. parent (not for the autonomous cell), that cell's PDR.
2. Any cell that hasn't yet had NumTx divided by 2 since it was last 2. Any cell that hasn't yet had NumTx divided by 2 since it was last
reset is skipped in steps 3 and 4. This avoids triggering cell reset is skipped in steps 3 and 4. This avoids triggering cell
relocation when the values of NumTx and NumTxAck are not relocation when the values of NumTx and NumTxAck are not
statistically significant yet. statistically significant yet.
3. It identifies the cell with the highest PDR. 3. It identifies the cell with the highest PDR.
4. For any other cell, it compares its PDR against that of the cell 4. For any other cell, it compares its PDR against that of the cell
with the highest PDR. If the difference is less than with the highest PDR. If the difference is larger than
RELOCATE_PDRTHRES, it triggers the relocation of that cell using RELOCATE_PDRTHRES, it triggers the relocation of that cell using
a 6P RELOCATE command. a 6P RELOCATE command.
6. 6P SIGNAL command 6. 6P SIGNAL command
The 6P SIGNAL command is not used by MSF. The 6P SIGNAL command is not used by MSF.
7. Scheduling Function Identifier 7. Scheduling Function Identifier
The Scheduling Function Identifier (SFID) of MSF is The Scheduling Function Identifier (SFID) of MSF is
IANA_6TISCH_SFID_MSF. IANA_6TISCH_SFID_MSF.
8. Rules for CellList 8. Rules for CellList
MSF uses 2-step 6P Transactions exclusively. 6P Transactions are MSF uses 2-step 6P Transactions exclusively. 6P Transactions are
only initiated by a node towards its preferred parent. As a result, only initiated by a node towards its preferred parent. As a result,
the cells to put in the CellList of a 6P ADD command, and in the the cells to put in the CellList of a 6P ADD command, and in the
candidate CellList of a RELOCATE command, are chosen by the node candidate CellList of a RELOCATE command, are chosen by the node
initiating the 6P Transaction. In both cases, the same rules apply: initiating the 6P Transaction. In both cases, the same rules apply:
o The CellList SHOULD contain 5 or more cells. o The CellList is RECOMMENDED to have 5 or more cells.
o Each cell in the CellList MUST have a different slotOffset value. o Each cell in the CellList MUST have a different slotOffset value.
o For each cell in the CellList, the node MUST NOT have any o For each cell in the CellList, the node MUST NOT have any
scheduled cell on the same slotOffset. scheduled cell on the same slotOffset.
o The slotOffset value of any cell in the CellList MUST NOT be the o The slotOffset value of any cell in the CellList MUST NOT be the
same as the slotOffset of the minimal cell (slotOffset=0). same as the slotOffset of the minimal cell (slotOffset=0).
o The slotOffset of a cell in the CellList SHOULD be randomly and o The slotOffset of a cell in the CellList SHOULD be randomly and
uniformly chosen among all the slotOffset values that satisfy the uniformly chosen among all the slotOffset values that satisfy the
restrictions above. restrictions above.
o The channelOffset of a cell in the CellList SHOULD be randomly and o The channelOffset of a cell in the CellList SHOULD be randomly and
uniformly chosen in [0..numFrequencies], where numFrequencies uniformly chosen in [0..numFrequencies], where numFrequencies
represents the number of frequencies a node can communicate on. represents the number of frequencies a node can communicate on.
9. 6P Timeout Value 9. 6P Timeout Value
It is calculated for the worst case that a 6P response is received, It is calculated for the worst case that a 6P response is received,
which means the 6P response is sent out successfully at the very which means the 6P response is sent out successfully at the very
latest retransmission. And for each retransmission, it backs-off latest retransmission. And for each retransmission, it backs-off
with largest value. Hence the 6P timeout value is calculated as with largest value. Hence the 6P timeout value is calculated as
((2^MAXBE)-1)*SLOTFRAME_LENGTH, where: ((2^MAXBE)-1)*MAXRETRIES*SLOTFRAME_LENGTH, where:
o MAXBE is the maximum backoff exponent used o MAXBE is the maximum backoff exponent used
o MAXRETRIES is the maximum retransmission times
o SLOTFRAME_LENGTH represents the length of slotframe o SLOTFRAME_LENGTH represents the length of slotframe
10. Rule for Ordering Cells 10. Rule for Ordering Cells
Cells are ordered slotOffset first, channelOffset second. Cells are ordered slotOffset first, channelOffset second.
The following sequence is correctly ordered (each element represents The following sequence is correctly ordered (each element represents
the [slottOffset,channelOffset] of a cell in the schedule): the [slottOffset,channelOffset] of a cell in the schedule):
[1,3],[1,4],[2,0],[5,3],[6,0],[6,3],[7,9] [1,3],[1,4],[2,0],[5,3],[6,0],[6,3],[7,9]
skipping to change at page 16, line 17 skipping to change at page 16, line 17
17.1. MSF Scheduling Function Identifiers 17.1. MSF Scheduling Function Identifiers
This document adds the following number to the "6P Scheduling This document adds the following number to the "6P Scheduling
Function Identifiers" sub-registry, part of the "IPv6 over the TSCH Function Identifiers" sub-registry, part of the "IPv6 over the TSCH
mode of IEEE 802.15.4e (6TiSCH) parameters" registry, as defined by mode of IEEE 802.15.4e (6TiSCH) parameters" registry, as defined by
[RFC8480]: [RFC8480]:
+----------------------+-----------------------------+-------------+ +----------------------+-----------------------------+-------------+
| SFID | Name | Reference | | SFID | Name | Reference |
+----------------------+-----------------------------+-------------+ +----------------------+-----------------------------+-------------+
| IANA_6TISCH_SFID_MSF | Minimal Scheduling Function | RFCXXXX | | IANA_6TISCH_SFID_MSF | Minimal Scheduling Function | RFC_THIS |
| | (MSF) | (NOTE:this) | | | (MSF) | |
+----------------------+-----------------------------+-------------+ +----------------------+-----------------------------+-------------+
Figure 4: IETF IE Subtype '6P'. Figure 4: IETF IE Subtype '6P'.
18. References 18. References
18.1. Normative References 18.1. Normative References
[I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-24 (work
in progress), July 2019.
[I-D.ietf-6tisch-dtsecurity-zerotouch-join] [I-D.ietf-6tisch-dtsecurity-zerotouch-join]
Richardson, M., "6tisch Zero-Touch Secure Join protocol", Richardson, M., "6tisch Zero-Touch Secure Join protocol",
draft-ietf-6tisch-dtsecurity-zerotouch-join-03 (work in draft-ietf-6tisch-dtsecurity-zerotouch-join-03 (work in
progress), October 2018. progress), October 2018.
[I-D.ietf-6tisch-minimal-security] [I-D.ietf-6tisch-minimal-security]
Vucinic, M., Simon, J., Pister, K., and M. Richardson, Vucinic, M., Simon, J., Pister, K., and M. Richardson,
"Minimal Security Framework for 6TiSCH", draft-ietf- "Minimal Security Framework for 6TiSCH", draft-ietf-
6tisch-minimal-security-11 (work in progress), June 2019. 6tisch-minimal-security-11 (work in progress), June 2019.
skipping to change at page 17, line 22 skipping to change at page 17, line 27
[RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal
IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH)
Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180,
May 2017, <https://www.rfc-editor.org/info/rfc8180>. May 2017, <https://www.rfc-editor.org/info/rfc8180>.
[RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH
Operation Sublayer (6top) Protocol (6P)", RFC 8480, Operation Sublayer (6top) Protocol (6P)", RFC 8480,
DOI 10.17487/RFC8480, November 2018, DOI 10.17487/RFC8480, November 2018,
<https://www.rfc-editor.org/info/rfc8480>. <https://www.rfc-editor.org/info/rfc8480>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>.
18.2. Informative References 18.2. Informative References
[SAX-DASFAA] [SAX-DASFAA]
Ramakrishna, M. and J. Zobel, "Performance in Practice of Ramakrishna, M. and J. Zobel, "Performance in Practice of
String Hashing Functions", DASFAA , 1997. String Hashing Functions", DASFAA , 1997.
Appendix A. Contributors Appendix A. Contributors
Beshr Al Nahas (Chalmers University, beshr@chalmers.se) Olaf Beshr Al Nahas (Chalmers University, beshr@chalmers.se) Olaf
Landsiedel (Chalmers University, olafl@chalmers.se) Yasuyuki Tanaka Landsiedel (Chalmers University, olafl@chalmers.se) Yasuyuki Tanaka
 End of changes. 31 change blocks. 
46 lines changed or deleted 60 lines changed or added

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