rfc9033.original.xml   rfc9033.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="
<?rfc comments="yes"?> draft-ietf-6tisch-msf-18" number="9033" obsoletes="" updates="" submissionT
<?rfc inline="yes"?> ype="IETF" category="std" consensus="true" sortRefs="true" symRefs="true" x
<?rfc subcompact="yes"?> ml:lang="en" tocInclude="true" version="3">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust20
0902" docName="draft-ietf-6tisch-msf-18" obsoletes="" updates="" consensus=
"true" submissionType="IETF" xml:lang="en" tocInclude="true" version="3">
<!-- xml2rfc v2v3 conversion 2.35.0 --> <!-- xml2rfc v2v3 conversion 2.35.0 -->
<front> <front>
<title> <title abbrev="6TiSCH MSF">
6TiSCH Minimal Scheduling Function (MSF) 6TiSCH Minimal Scheduling Function (MSF)
</title> </title>
<seriesInfo name="Internet-Draft" value="draft-ietf-6tisch-msf-18"/ > <seriesInfo name="RFC" value="9033"/>
<author initials="T" surname="Chang" fullname="Tengfei Chang" role= "editor"> <author initials="T" surname="Chang" fullname="Tengfei Chang" role= "editor">
<organization>Inria</organization> <organization>Inria</organization>
<address> <address>
<postal> <postal>
<street>2 rue Simone Iff</street> <street>2 rue Simone Iff</street>
<city>Paris</city> <city>Paris</city>
<code>75012</code> <code>75012</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>tengfei.chang@inria.fr</email> <email>tengfei.chang@inria.fr</email>
</address> </address>
</author> </author>
<author initials="M." surname="Vucinic" fullname="Malisa Vucinic"> <author initials="M." surname="Vučinić" fullname="Mališa Vučinić">
<organization>Inria</organization> <organization>Inria</organization>
<address> <address>
<postal> <postal>
<street>2 rue Simone Iff</street> <street>2 rue Simone Iff</street>
<city>Paris</city> <city>Paris</city>
<code>75012</code> <code>75012</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>malisa.vucinic@inria.fr</email> <email>malisa.vucinic@inria.fr</email>
</address> </address>
skipping to change at line 56 skipping to change at line 53
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<email>xvilajosana@uoc.edu</email> <email>xvilajosana@uoc.edu</email>
</address> </address>
</author> </author>
<author initials="S" surname="Duquennoy" fullname="Simon Duquennoy" > <author initials="S" surname="Duquennoy" fullname="Simon Duquennoy" >
<organization>RISE SICS</organization> <organization>RISE SICS</organization>
<address> <address>
<postal> <postal>
<street>Isafjordsgatan 22</street> <street>Isafjordsgatan 22</street>
<city>164 29 Kista</city> <city>Kista</city>
<code>164 29</code>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<email>simon.duquennoy@gmail.com</email> <email>simon.duquennoy@gmail.com</email>
</address> </address>
</author> </author>
<author initials="D" surname="Dujovne" fullname="Diego Dujovne"> <author initials="D" surname="Dujovne" fullname="Diego Dujovne">
<organization>Universidad Diego Portales</organization> <organization>Universidad Diego Portales</organization>
<address> <address>
<postal> <postal>
<street>Escuela de Informatica y Telecomunicaciones</st <street>Escuela de Informática y Telecomunicaciones</st
reet> reet>
<street>Av. Ejercito 441</street> <street>Av. Ejército 441</street>
<city>Santiago</city> <city>Santiago</city>
<region>Region Metropolitana</region> <region>Región Metropolitana</region>
<country>Chile</country> <country>Chile</country>
</postal> </postal>
<phone>+56 (2) 676-8121</phone> <phone>+56 (2) 676-8121</phone>
<email>diego.dujovne@mail.udp.cl</email> <email>diego.dujovne@mail.udp.cl</email>
</address> </address>
</author> </author>
<date/> <date year="2021" month="April"/>
<area>Internet Area</area> <area>Internet Area</area>
<workgroup>6TiSCH</workgroup> <workgroup>6TiSCH</workgroup>
<keyword>Draft</keyword>
<keyword>TSCH</keyword>
<keyword>communication schedule</keyword>
<keyword>6P</keyword>
<abstract> <abstract>
<!-- [rfced] May we expand the 6TiSCH acronym in the abstract?
Current:
This specification defines the 6TiSCH Minimal Scheduling Function
(MSF).
Perhaps:
This specification defines the "IPv6 over the TSCH mode of
IEEE 802.15.4e" (6TiSCH) Minimal Scheduling Function (MSF).
-->
<t> <t>
This specification defines the 6TiSCH Minimal Scheduling Fu nction (MSF). This specification defines the 6TiSCH Minimal Scheduling Fu nction (MSF).
This Scheduling Function describes both This Scheduling Function describes both
the behavior of a node when joining the network, and the behavior of a node when joining the network and
how the communication schedule is managed in a distributed fashion. how the communication schedule is managed in a distributed fashion.
MSF is built upon MSF is built upon
the 6TiSCH Operation Sublayer Protocol (6P) and the 6TiSCH Operation Sublayer Protocol (6P) and
the Minimal Security Framework for 6TiSCH. the minimal security framework for 6TiSCH.
</t> </t>
</abstract> </abstract>
<note>
<name>Requirements Language</name>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHA
LL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", a
nd "OPTIONAL" in this document are to be interpreted as described in BCP 14
<xref target="RFC2119" format="default"/> <xref target="RFC8174" format="d
efault"/> when, and only when, they appear in all capitals, as shown here.
</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="sec_intro" numbered="true" toc="default"> <section anchor="sec_intro" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t> <t>
The 6TiSCH Minimal Scheduling Function (MSF), defined in th is specification, is a 6TiSCH Scheduling Function (SF). The 6TiSCH Minimal Scheduling Function (MSF), defined in th is specification, is a 6TiSCH Scheduling Function (SF).
The role of an SF is entirely defined in <xref target="RFC8 480" format="default"/>. The role of an SF is entirely defined in <xref target="RFC8 480" format="default"/>.
This specification complements <xref target="RFC8480" forma This specification complements <xref target="RFC8480" forma
t="default"/> by providing the rules of when to add/delete cells in the com t="default"/> by providing the rules of when to add and delete cells in the
munication schedule. communication schedule.
This specification satisfies all the requirements for an SF This specification satisfies all the requirements for an SF
listed in Section 4.2 of <xref target="RFC8480" format="default"/>. listed in <xref target="RFC8480" section="4.2" sectionFormat="of"/>.
</t> </t>
<t> <t>
MSF builds on top of the following specifications: MSF builds on top of the following specifications:
the Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiS "<xref target="RFC8180" format="title"/>" <xref target="RFC
CH) Configuration <xref target="RFC8180" format="default"/>, 8180" format="default"/>,
the 6TiSCH Operation Sublayer Protocol (6P) <xref target="R "<xref target="RFC8480" format="title"/>" <xref target="RF
FC8480" format="default"/>, and C8480" format="default"/>, and
the Minimal Security Framework for 6TiSCH <xref target="I-D "<xref target="RFC9031" format="title"/>" <xref target="RF
.ietf-6tisch-minimal-security" format="default"/>. C9031" format="default"/>.
</t> </t>
<t> <t>
MSF defines both MSF defines both
the behavior of a node when joining the network, and the behavior of a node when joining the network, and
how the communication schedule is managed in a distributed fashion. how the communication schedule is managed in a distributed fashion.
When a node running MSF boots up, it joins the network by f ollowing the 6 steps described in <xref target="sec_boot" format="default"/ >. When a node running MSF boots up, it joins the network by f ollowing the six steps described in <xref target="sec_boot" format="default "/>.
The end state of the join process is that the node The end state of the join process is that the node
is synchronized to the network, is synchronized to the network,
has mutually authenticated with the network, has mutually authenticated with the network,
has identified a routing parent, has identified a routing parent,
and has scheduled one negotiated Tx cell (defined in <xref target="sec_traffic" format="default"/>) to/from its routing parent. and has scheduled one negotiated Tx cell (defined in <xref target="sec_traffic" format="default"/>) to/from its routing parent.
After the join process, the node can continuously add/delet After the join process, the node can continuously add, dele
e/relocate cells, as described in <xref target="sec_add_delete" format="def te, and relocate cells as described in <xref target="sec_add_delete" format
ault"/>. ="default"/>.
It does so for 3 reasons:
It does so for three reasons:
to match the link-layer resources to the traffic, to match the link-layer resources to the traffic,
to handle changing parent and to handle changing parent, and
to handle a schedule collision. to handle a schedule collision.
</t> </t>
<t> <t>
MSF works closely with the IPv6 Routing Protocol for Low-Po wer and Lossy Networks (RPL), specifically the routing parent defined in <x ref target="RFC6550" format="default"/>. MSF works closely with the IPv6 Routing Protocol for Low-Po wer and Lossy Networks (RPL), specifically the routing parent defined in <x ref target="RFC6550" format="default"/>.
This specification only describes how MSF works with the ro uting parent; this parent is referred to as the "selected parent". This specification only describes how MSF works with the ro uting parent; this parent is referred to as the "selected parent".
The activity of MSF towards the single routing parent is ca lled a "MSF session". The activity of MSF towards the single routing parent is ca lled a "MSF session".
Though the performance of MSF is evaluated only when the "s elected parent" represents the node's preferred parent, there should be no restrictions to use multiple MSF sessions, one per parent. Though the performance of MSF is evaluated only when the "s elected parent" represents the node's preferred parent, there should be no restrictions to use multiple MSF sessions, one per parent.
The distribution of traffic over multiple parents is a rout ing decision that is out of scope for MSF. The distribution of traffic over multiple parents is a rout ing decision that is out of scope for MSF.
</t> </t>
<t> <t>
MSF is designed to operate in a wide range of application d omains. MSF is designed to operate in a wide range of application d omains.
It is optimized for applications with regular upstream traf fic, from the nodes to the Destination-Oriented Directed Acyclic Graph (DOD AG <xref target="RFC6550" format="default"/>) root. It is optimized for applications with regular upstream traf fic, from the nodes to the Destination-Oriented Directed Acyclic Graph (DOD AG) root <xref target="RFC6550" format="default"/>.
</t> </t>
<t> <t>
This specification follows the recommended structure of an SF specification, given in Appendix A of <xref target="RFC8480" format="def ault"/>, with the following adaptations: This specification follows the recommended structure of an SF specification, given in <xref target="RFC8480" section="A" sectionFormat ="of" format="default"/>, with the following adaptations:
</t> </t>
<ul spacing="compact"> <ul spacing="normal">
<li> <li>
We have reordered some sections, in particular to have the section on the node behavior at boot (<xref target="sec_boot" format="d efault"/>) appear early in this specification. We have reordered some sections, in particular to have the section on the node behavior at boot (<xref target="sec_boot" format="d efault"/>) appear early in this specification.
</li> </li>
<li> <li>
We added sections on We added sections on
the interface to the minimal 6TiSCH configuration (<xre f target="sec_minimal" format="default"/>), the interface to the minimal 6TiSCH configuration (<xre f target="sec_minimal" format="default"/>),
the use of the SIGNAL command (<xref target="sec_signal " format="default"/>), the use of the SIGNAL command (<xref target="sec_signal " format="default"/>),
the MSF constants (<xref target="sec_constants" format= "default"/>) and the MSF constants (<xref target="sec_constants" format= "default"/>), and
the MSF statistics (<xref target="sec_stats" format="de fault"/>). the MSF statistics (<xref target="sec_stats" format="de fault"/>).
</li> </li>
</ul> </ul>
<section>
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</
bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL N
OT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>
", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119" format="default"/> <xref ta
rget="RFC8174" format="default"/> when, and only when, they appear in all c
apitals, as shown here.
</t>
</section>
</section> </section>
<section anchor="sec_minimal" numbered="true" toc="default"> <section anchor="sec_minimal" numbered="true" toc="default">
<name>Interface to the Minimal 6TiSCH Configuration</name> <name>Interface to the Minimal 6TiSCH Configuration</name>
<t> <t>
In a TSCH network, time is sliced up into time slots. In a Time-Slotted Channel Hopping (TSCH) network, time is s
The time slots are grouped as one or multiple slotframes wh liced up into time slots.
ich repeat over time. The time slots are grouped as one or multiple slotframes th
The TSCH schedule instructs a node what to do at each time at repeat over time.
slot, such as transmit, receive or sleep <xref target="RFC7554" format="def The TSCH schedule instructs a node what to do at each time
ault"/>. slot, such as transmit, receive, or sleep <xref target="RFC7554" format="de
In case of a slot to transmit or receive, a channel is assi fault"/>.
gned to the time slot. For time slots for transmitting or receiving, a channel is
The tuple (slot, channel) is indicated as a cell of TSCH sc assigned to the time slot.
hedule. The tuple (slot, channel) is indicated as a cell of the TSC
H schedule.
MSF is one of the policies defining how to manage the TSCH schedule. MSF is one of the policies defining how to manage the TSCH schedule.
</t> </t>
<t> <t>
A node implementing MSF SHOULD implement the Minimal 6TiSCH A node implementing MSF <bcp14>SHOULD</bcp14> implement the
Configuration <xref target="RFC8180" format="default"/>, which defines the minimal 6TiSCH configuration <xref target="RFC8180" format="default"/>, wh
"minimal cell", a single shared cell providing minimal connectivity betwee ich defines the "minimal cell", a single shared cell providing minimal conn
n the nodes in the network. ectivity between the nodes in the network.
The MSF implementation provided in this specification is ba The MSF implementation provided in this specification is ba
sed on the implementation of the Minimal 6TiSCH Configuration. sed on the implementation of the minimal 6TiSCH configuration.
However, an implementor MAY implement MSF based on other sp However, an implementor <bcp14>MAY</bcp14> implement MSF ba
ecifications as long as the specification defines a way to advertise the EB sed on other specifications as long as the specification defines a way to a
/DIO among the network. dvertise the Enhanced Beacons (EBs) and DODAG Information Objects (DIOs) am
ong the network.
</t> </t>
<t> <t>
MSF uses the minimal cell for broadcast frames such as Enha nced Beacons (EBs) <xref target="IEEE802154" format="default"/> and broadca st DODAG Information Objects (DIOs) <xref target="RFC6550" format="default" />. MSF uses the minimal cell for broadcast frames such as Enha nced Beacons (EBs) <xref target="IEEE802154" format="default"/> and broadca st DODAG Information Objects (DIOs) <xref target="RFC6550" format="default" />.
Cells scheduled by MSF are meant to be used only for unicas t frames. Cells scheduled by MSF are meant to be used only for unicas t frames.
</t> </t>
<t> <t>
To ensure there is enough bandwidth available on the minima To ensure there is enough bandwidth available on the minima
l cell, a node implementing MSF SHOULD enforce some rules for limiting the l cell, a node implementing MSF <bcp14>SHOULD</bcp14> enforce some rules fo
traffic of broadcast frames. r limiting the traffic of broadcast frames.
For example, the overall broadcast traffic among the node a For example, the overall broadcast traffic among the node a
nd its neighbors SHOULD NOT exceed 1/3 of the bandwidth of minimal cell. nd its neighbors <bcp14>SHOULD NOT</bcp14> exceed one-third of the bandwidt
One of the algorithms that fulfills this requirement is the h of minimal cell.
Trickle timer defined in <xref target="RFC6206" format="default"/> which One of the algorithms that fulfills this requirement is the
is applied on DIO messages <xref target="RFC6550" format="default"/>. Trickle timer defined in <xref target="RFC6206" format="default"/>, which
is applied to DIO messages <xref target="RFC6550" format="default"/>.
However, any such algorithm of limiting the broadcast traff ic to meet those rules is implementation-specific and is out of the scope o f MSF. However, any such algorithm of limiting the broadcast traff ic to meet those rules is implementation-specific and is out of the scope o f MSF.
</t> </t>
<t> <t>
3 slotframes are used in MSF. Three slotframes are used in MSF.
MSF schedules autonomous cells at Slotframe 1 (<xref target MSF schedules autonomous cells at Slotframe 1 (<xref target
="sec_autonomous_cells" format="default"/>) and 6P negotiated cells at Slot ="sec_autonomous_cells" format="default"/>) and 6P negotiated cells at Slot
frame 2 (<xref target="sec_add_delete" format="default"/>) ,while Slotframe frame 2 (<xref target="sec_add_delete" format="default"/>), while Slotframe
0 is used for the bootstrap traffic as defined in the Minimal 6TiSCH Confi 0 is used for the bootstrap traffic as defined in the minimal 6TiSCH confi
guration. guration.
The same slotframe length for Slotframe 0, 1 and 2 is RECOM The same slotframe length for Slotframe 0, 1, and 2 is <bcp
MENDED. 14>RECOMMENDED</bcp14>.
Thus it is possible to avoid the scheduling collision betwe en the autonomous cells and 6P negotiated cells (<xref target="sec_autonomo us_cells" format="default"/>). Thus it is possible to avoid the scheduling collision betwe en the autonomous cells and 6P negotiated cells (<xref target="sec_autonomo us_cells" format="default"/>).
The default slotframe length (SLOTFRAME_LENGTH) is RECOMMEN DED for Slotframe 0, 1 and 2, although any value can be advertised in the E Bs. The default slotframe length (SLOTFRAME_LENGTH) is <bcp14>R ECOMMENDED</bcp14> for Slotframe 0, 1, and 2, although any value can be adv ertised in the EBs.
</t> </t>
</section> </section>
<section anchor="sec_autonomous_cells" numbered="true" toc="default "> <section anchor="sec_autonomous_cells" numbered="true" toc="default ">
<name>Autonomous Cells</name> <name>Autonomous Cells</name>
<t> <t>
MSF nodes initialize Slotframe 1 with a set of default cell s for unicast communication with their neighbors. MSF nodes initialize Slotframe 1 with a set of default cell s for unicast communication with their neighbors.
These cells are called 'autonomous cells', because they are These cells are called "autonomous cells", because they are
maintained autonomously by each node without negotiation through 6P. maintained autonomously by each node without negotiation through 6P.
Cells scheduled by 6P transaction are called 'negotiated ce Cells scheduled by 6P Transaction are called "negotiated ce
lls' which are reserved on Slotframe 2. lls", which are reserved on Slotframe 2.
How to schedule negotiated cells is detailed in <xref targe t="sec_add_delete" format="default"/>. How to schedule negotiated cells is detailed in <xref targe t="sec_add_delete" format="default"/>.
There are two types of autonomous cells: There are two types of autonomous cells:
</t> </t>
<ul spacing="compact"> <dl spacing="normal">
<li> <dt>
Autonomous Rx Cell (AutoRxCell), one cell at a [slotOff Autonomous Rx Cell (AutoRxCell):</dt><dd> One cell at a
set,channelOffset] computed as a hash of the EUI64 of the node itself (deta [slotOffset,channelOffset] computed as a hash of the 64-bit Extended Uniqu
iled next). e Identifier (EUI-64) of the node itself (detailed next).
Its cell options bits are assigned as TX=0, RX=1, SHARE D=0. Its cell options bits are assigned as TX=0, RX=1, SHARE D=0.
</li> </dd>
<li> <dt>
Autonomous Tx Cell (AutoTxCell), one cell at a [slotOff Autonomous Tx Cell (AutoTxCell):</dt><dd> One cell at a
set,channelOffset] computed as a hash of the layer 2 EUI64 destination addr [slotOffset,channelOffset] computed as a hash of the Layer 2 EUI-64 destin
ess in the unicast frame to be transmitted (detailed in <xref target="sec_j ation address in the unicast frame to be transmitted (detailed in <xref tar
oin" format="default"/>). get="sec_join" format="default"/>).
Its cell options bits are assigned as TX=1, RX=0, SHARE D=1. Its cell options bits are assigned as TX=1, RX=0, SHARE D=1.
</li> </dd>
</ul> </dl>
<t> <t>
To compute a [slotOffset,channelOffset] from an EUI64 addre ss, nodes MUST use the hash function SAX as defined in Section 2 of <xref t arget="SAX-DASFAA" format="default"/> with consistent input parameters, for example, those defined in <xref target="sec_hash_function" format="default "/>. To compute a [slotOffset,channelOffset] from an EUI-64 addr ess, nodes <bcp14>MUST</bcp14> use the hash function SAX as defined in Sect ion 2 of <xref target="SAX-DASFAA" format="default"/> with consistent input parameters, for example, those defined in <xref target="sec_hash_function" format="default"/>.
The coordinates are computed to distribute the cells across all channel offsets, and all but the first slot offset of Slotframe 1. The coordinates are computed to distribute the cells across all channel offsets, and all but the first slot offset of Slotframe 1.
The first time offset is skipped to avoid colliding with th e minimal cell in Slotframe 0. The first time offset is skipped to avoid colliding with th e minimal cell in Slotframe 0.
The slot coordinates derived from a given EUI64 address are computed as follows: The slot coordinates derived from a given EUI-64 address ar e computed as follows:
</t> </t>
<ul spacing="compact"> <t indent="6">slotOffset(MAC) = 1 + hash(EUI64, length(Slot
<li>slotOffset(MAC) = 1 + hash(EUI64, length(Slotframe_1) - frame_1) - 1) </t>
1) </li> <t indent="6">channelOffset(MAC) = hash(EUI64, NUM_CH_OFFSE
<li>channelOffset(MAC) = hash(EUI64, NUM_CH_OFFSET)</li> T)</t>
</ul>
<t> <t>
The second input parameter defines the maximum return value of the hash function. The second input parameter defines the maximum return value of the hash function.
Other optional parameters defined in SAX determine the perf ormance of SAX hash function. Other optional parameters defined in SAX determine the perf ormance of SAX hash function.
Those parameters could be broadcasted in EB frame or pre-co Those parameters could be broadcast in an EB frame or preco
nfigured. nfigured.
For interoperability purposes, the values of those paramete For interoperability purposes, <xref target="sec_hash_funct
rs can be referred from <xref target="sec_hash_function" format="default"/> ion" format="default"/> provides the reference values of those parameters.
.
</t> </t>
<t> <t>
AutoTxCell is not permanently installed in the schedule but added/deleted on demand when there is a frame to be sent. AutoTxCell is not permanently installed in the schedule but is added or deleted on demand when there is a frame to be sent.
Throughout the network lifetime, nodes maintain the autonom ous cells as follows: Throughout the network lifetime, nodes maintain the autonom ous cells as follows:
</t> </t>
<ul spacing="compact"> <ul spacing="normal">
<li> <li>
Add an AutoTxCell to the layer 2 destination address wh ich is indicated in a frame when there is no 6P negotiated Tx cell in sched ule for that frame to transmit. Add an AutoTxCell to the Layer 2 destination address, w hich is indicated in a frame when there is no 6P negotiated Tx cell in the schedule for that frame to transmit.
</li> </li>
<li> <li>
<t> <t>
Remove an AutoTxCell when: Remove an AutoTxCell when:
</t> </t>
<ul spacing="compact"> <ul spacing="normal">
<li>there is no frame to transmit on that cell, or< /li> <li>there is no frame to transmit on that cell, or< /li>
<li>there is at least one 6P negotiated Tx cell in the schedule for the frames to transmit.</li> <li>there is at least one 6P negotiated Tx cell in the schedule for the frames to transmit.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t> <t>
The AutoRxCell MUST always remain scheduled after synchroni The AutoRxCell <bcp14>MUST</bcp14> always remain scheduled
zation. after synchronization.
6P CLEAR MUST NOT erase any autonomous cells. 6P CLEAR <bcp14>MUST NOT</bcp14> erase any autonomous cells
.
</t> </t>
<t> <t>
Because of hash collisions, there will be cases that the Au toTxCell and AutoRxCell are scheduled at the same slot offset and/or channe l offset. Because of hash collisions, there will be cases that the Au toTxCell and AutoRxCell are scheduled at the same slot offset and/or channe l offset.
In such cases, AutoTxCell always take precedence over AutoR xCell. In such cases, AutoTxCell always take precedence over AutoR xCell.
Notice AutoTxCell is a shared type cell which applies backs -off mechanism. Notice AutoTxCell is a shared type cell that applies a back -off mechanism.
When the AutoTxCell and AutoRxCell collide, AutoTxCell tak es precedence if there is a packet to transmit. When the AutoTxCell and AutoRxCell collide, AutoTxCell tak es precedence if there is a packet to transmit.
When in a back-off period, AutoRxCell is used. When in a back-off period, AutoRxCell is used.
In case of conflicting with a negotiated cell, autonomous c In the case of conflict with a negotiated cell, autonomous
ells take precedence over negotiated cells, which is stated in <xref target cells take precedence over negotiated cells, which is stated in <xref targe
="IEEE802154" format="default"/>. t="IEEE802154" format="default"/>.
However, when the Slotframe 0, 1 and 2 use the same length However, when the Slotframe 0, 1, and 2 use the same length
value, it is possible for a negotiated cell to avoid the collision with Aut value, it is possible for a negotiated cell to avoid the collision with Au
oRxCell. toRxCell.
Hence, the same slotframe length for Slotframe 0, 1 and 2 i Hence, the same slotframe length for Slotframe 0, 1, and 2
s RECOMMENDED. is <bcp14>RECOMMENDED</bcp14>.
</t> </t>
<t> <t>
</t> </t>
</section> </section>
<section anchor="sec_boot" numbered="true" toc="default"> <section anchor="sec_boot" numbered="true" toc="default">
<name>Node Behavior at Boot</name> <name>Node Behavior at Boot</name>
<t> <t>
This section details the behavior the node SHOULD follow fr om the moment it is switched on, until it has successfully joined the netwo rk. This section details the behavior the node <bcp14>SHOULD</b cp14> follow from the moment it is switched on until it has successfully jo ined the network.
Alternative behaviors may be involved, for example, when al ternative security solutions are used for the network. Alternative behaviors may be involved, for example, when al ternative security solutions are used for the network.
<xref target="sec_start_state" format="default"/> details t he start state; <xref target="sec_start_state" format="default"/> details t he start state;
<xref target="sec_end_state" format="default"/> details t he end state. <xref target="sec_end_state" format="default"/> details t he end state.
The other sections detail the 6 steps of the joining proces The other sections detail the six steps of the joining proc
s. ess.
We use the term "pledge" and "joined node", as defined in < We use the term "pledge" and "joined node", as defined in <
xref target="I-D.ietf-6tisch-minimal-security" format="default"/>. xref target="RFC9031" format="default"/>.
</t> </t>
<section anchor="sec_start_state" numbered="true" toc="default" > <section anchor="sec_start_state" numbered="true" toc="default" >
<name>Start State</name> <name>Start State</name>
<t> <t>
A node implementing MSF SHOULD implement the Constraine A node implementing MSF <bcp14>SHOULD</bcp14> implement
d Join Protocol (CoJP) for 6TiSCH <xref target="I-D.ietf-6tisch-minimal-sec the Constrained Join Protocol (CoJP) for 6TiSCH <xref target="RFC9031" for
urity" format="default"/>. mat="default"/>.
As a corollary, this means that a pledge, before being As a corollary, this means that a pledge, before being
switched on, may be pre-configured with the Pre-Shared Key (PSK) for joinin switched on, may be preconfigured with the Pre-Shared Key (PSK) for joining
g, as well as any other configuration detailed in (<xref target="I-D.ietf-6 , as well as any other configuration detailed in <xref target="RFC9031" for
tisch-minimal-security" format="default"/>). mat="default"/>.
This is not necessary if the node implements a security This is not necessary if the node implements a security
solution not based on PSKs, such as (<xref target="I-D.ietf-6tisch-dtsecur solution that is not based on PSKs, such as <xref target="I-D.ietf-6tisch-
ity-zerotouch-join" format="default"/>). dtsecurity-zerotouch-join" format="default"/>.
</t> </t>
</section> </section>
<section anchor="sec_frequency" numbered="true" toc="default"> <section anchor="sec_frequency" numbered="true" toc="default">
<name>Step 1 - Choosing Frequency</name> <name>Step 1 - Choosing Frequency</name>
<t> <t>
When switched on, the pledge randomly chooses a frequen cy from the channels that the network cycles amongst, and starts listening for EBs on that frequency. When switched on, the pledge randomly chooses a frequen cy from the channels through which the network cycles and starts listening for EBs on that frequency.
</t> </t>
</section> </section>
<section anchor="sec_ebs" numbered="true" toc="default"> <section anchor="sec_ebs" numbered="true" toc="default">
<name>Step 2 - Receiving EBs</name> <name>Step 2 - Receiving EBs</name>
<t> <t>
Upon receiving the first EB, the pledge continues liste ning for additional EBs to learn: Upon receiving the first EB, the pledge continues liste ning for additional EBs to learn:
</t> </t>
<ol spacing="compact" type="1"> <ol spacing="normal" type="1">
<li>the number of neighbors N in its vicinity</li> <li>the number of neighbors N in its vicinity, and </li
<li>which neighbor to choose as a Join Proxy (JP) for t >
he joining process</li> <li>which neighbor to choose as a Join Proxy (JP) for t
he joining process.</li>
</ol> </ol>
<t> <t>
After having received the first EB, a node MAY keep lis tening for at most MAX_EB_DELAY seconds or until it has received EBs from N UM_NEIGHBOURS_TO_WAIT distinct neighbors. After having received the first EB, a node <bcp14>MAY</ bcp14> keep listening for at most MAX_EB_DELAY seconds or until it has rece ived EBs from NUM_NEIGHBOURS_TO_WAIT distinct neighbors.
This behavior is defined in <xref target="RFC8180" form at="default"/>. This behavior is defined in <xref target="RFC8180" form at="default"/>.
</t> </t>
<t> <t>
During this step, the pledge only gets synchronized whe During this step, the pledge only gets synchronized whe
n it received enough EB from the network it wishes to join. n it has received enough EB from the network it wishes to join.
How to decide whether an EB originates from a node from How to decide whether an EB originates from a node from
the network it wishes to join is implementation-specific, but MAY involve the network it wishes to join is implementation-specific, but <bcp14>MAY</
filtering EBs by bcp14> involve filtering EBs by
the PAN ID field it contains, the PANID field it contains,
the presence and contents of the IE defined in <xref ta the presence and contents of the Information Element (I
rget="I-D.ietf-6tisch-enrollment-enhanced-beacon" format="default"/>, or E) defined in <xref target="RFC9032" format="default"/>, or
the key used to authenticate it. the key used to authenticate it.
</t> </t>
<t> <t>
The decision of which neighbor to use as a JP is implem entation-specific, and discussed in <xref target="I-D.ietf-6tisch-minimal-s ecurity" format="default"/>. The decision of which neighbor to use as a JP is implem entation-specific and is discussed in <xref target="RFC9031" format="defaul t"/>.
</t> </t>
</section> </section>
<section anchor="sec_join" numbered="true" toc="default"> <section anchor="sec_join" numbered="true" toc="default">
<name>Step 3 - Setting up Autonomous Cells for the Join Pro cess</name> <name>Step 3 - Setting up Autonomous Cells for the Join Pro cess</name>
<t> <t>
After having selected a JP, a node generates a Join Req uest and installs an AutoTxCell to the JP. After having selected a JP, a node generates a Join Req uest and installs an AutoTxCell to the JP.
The Join Request is then sent by the pledge to its sele cted JP over the AutoTxCell. The Join Request is then sent by the pledge to its sele cted JP over the AutoTxCell.
The AutoTxCell is removed by the pledge when the Join R equest is sent out. The AutoTxCell is removed by the pledge when the Join R equest is sent out.
The JP receives the Join Request through its AutoRxCell . The JP receives the Join Request through its AutoRxCell .
Then it forwards the Join Request to the join registrar /coordinator (JRC), possibly over multiple hops, over the 6P negotiated Tx cells. Then it forwards the Join Request to the Join Registrar /Coordinator (JRC), possibly over multiple hops, over the 6P negotiated Tx cells.
Similarly, the JRC sends the Join Response to the JP, p ossibly over multiple hops, over AutoTxCells or the 6P negotiated Tx cells. Similarly, the JRC sends the Join Response to the JP, p ossibly over multiple hops, over AutoTxCells or the 6P negotiated Tx cells.
When the JP received the Join Response from the JRC, it installs an AutoTxCell to the pledge and sends that Join Response to the p ledge over AutoTxCell. When the JP receives the Join Response from the JRC, it installs an AutoTxCell to the pledge and sends that Join Response to the p ledge over AutoTxCell.
The AutoTxCell is removed by the JP when the Join Respo nse is sent out. The AutoTxCell is removed by the JP when the Join Respo nse is sent out.
The pledge receives the Join Response from its AutoRxCe ll, thereby learns the keying material used in the network, as well as othe r configuration settings, and becomes a "joined node". The pledge receives the Join Response from its AutoRxCe ll, thereby learns the keying material used in the network, as well as othe r configuration settings, and becomes a "joined node".
</t> </t>
<t> <t>
When 6LoWPAN Neighbor Discovery (<xref target="RFC8505" When 6LoWPAN Neighbor Discovery (ND) <xref target="RFC8
format="default"/>) (ND) is implemented, the unicast packets used by ND ar 505" format="default"/> is implemented, the unicast packets used by ND are
e sent on the AutoTxCell. sent on the AutoTxCell.
The specific process how the ND works during the Join p The specific process how the ND works during the join p
rocess is detailed in <xref target="I-D.ietf-6tisch-architecture" format="d rocess is detailed in <xref target="RFC9030" format="default"/>.
efault"/>.
</t> </t>
</section> </section>
<section anchor="sec_rank" numbered="true" toc="default"> <section anchor="sec_rank" numbered="true" toc="default">
<name>Step 4 - Acquiring a RPL Rank</name> <name>Step 4 - Acquiring a RPL Rank</name>
<t> <t>
Per <xref target="RFC6550" format="default"/>, the join ed node Per <xref target="RFC6550" format="default"/>, the join ed node
receives DIOs, receives DIOs,
computes its own Rank, and computes its own Rank, and
selects a routing parent. selects a routing parent.
</t> </t>
</section> </section>
<section anchor="sec_negotiated_cells" numbered="true" toc="def ault"> <section anchor="sec_negotiated_cells" numbered="true" toc="def ault">
<name>Step 5 - Setting up first Tx negotiated Cells</name> <name>Step 5 - Setting up First Tx Negotiated Cells</name>
<t> <t>
Once it has selected a routing parent, the joined node MUST generate a 6P ADD Request and install an AutoTxCell to that parent. Once it has selected a routing parent, the joined node <bcp14>MUST</bcp14> generate a 6P ADD Request and install an AutoTxCell to that parent.
The 6P ADD Request is sent out through the AutoTxCell, containing the following fields: The 6P ADD Request is sent out through the AutoTxCell, containing the following fields:
</t> </t>
<ul spacing="compact"> <dl newline="false">
<li>CellOptions: set to TX=1,RX=0,SHARED=0</li> <dt>CellOptions:</dt><dd>Set to TX=1, RX=0, SHARED=0.</
<li>NumCells: set to 1</li> dd>
<li>CellList: at least 5 cells, chosen according to <xr <dt>NumCells:</dt><dd>Set to 1.</dd>
ef target="sec_celllist" format="default"/></li> <dt>CellList:</dt><dd>At least 5 cells, chosen accordin
</ul> g to <xref target="sec_celllist" format="default"/>.</dd>
</dl>
<t> <t>
The joined node removes the AutoTxCell to the selected parent when the 6P Request is sent out. The joined node removes the AutoTxCell to the selected parent when the 6P Request is sent out.
That parent receives the 6P ADD Request from its AutoRx Cell. That parent receives the 6P ADD Request from its AutoRx Cell.
Then it generates a 6P ADD Response and installs an Aut oTxCell to the joined node. Then it generates a 6P ADD Response and installs an Aut oTxCell to the joined node.
When the parent sends out the 6P ADD Response, it MUST When the parent sends out the 6P ADD Response, it <bcp1
remove that AutoTxCell. 4>MUST</bcp14> remove that AutoTxCell.
The joined node receives the 6P ADD Response from its A The joined node receives the 6P ADD Response from its A
utoRxCell and completes the 6P transaction. utoRxCell and completes the 6P Transaction.
In case the 6P ADD transaction failed, the node MUST is In the case that the 6P ADD transaction failed, the nod
sue another 6P ADD Request and repeat until the Tx cell is installed to the e <bcp14>MUST</bcp14> issue another 6P ADD Request and repeat until the Tx
parent. cell is installed to the parent.
</t> </t>
</section> </section>
<section anchor="sec_eb_dio" numbered="true" toc="default"> <section anchor="sec_eb_dio" numbered="true" toc="default">
<name>Step 6 - Send EBs and DIOs</name> <name>Step 6 - Sending EBs and DIOs</name>
<t> <t>
The node starts sending EBs and DIOs on the minimal cel l, while following the transmit rules for broadcast frames from <xref targe t="sec_minimal" format="default"/>. The node starts sending EBs and DIOs on the minimal cel l, while following the transmit rules for broadcast frames from <xref targe t="sec_minimal" format="default"/>.
</t> </t>
</section> </section>
<section anchor="sec_end_state" numbered="true" toc="default"> <section anchor="sec_end_state" numbered="true" toc="default">
<name>End State</name> <name>End State</name>
<t> <t>
For a new node, the end state of the joining process is : At the end state of the joining process, a new node:
</t> </t>
<ul spacing="compact"> <ul spacing="normal">
<li>it is synchronized to the network</li> <li>is synchronized to the network,</li>
<li>it is using the link-layer keying material it learn <li>is using the link-layer keying material it learned
ed through the secure joining process</li> through the secure joining process,</li>
<li>it has selected one neighbor as its routing parent< <li>has selected one neighbor as its routing parent,</l
/li> i>
<li>it has one AutoRxCell</li> <li>has one AutoRxCell,</li>
<li>it has one negotiated Tx cell to the selected paren <li>has one negotiated Tx cell to the selected parent,<
t</li> /li>
<li>it starts to send DIOs, potentially serving as a ro <li>starts to send DIOs, potentially serving as a route
uter for other nodes' traffic</li> r for other nodes' traffic, and</li>
<li>it starts to send EBs, potentially serving as a JP <li>starts to send EBs, potentially serving as a JP fo
for new pledges</li> r new pledges.</li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="sec_add_delete" numbered="true" toc="default"> <section anchor="sec_add_delete" numbered="true" toc="default">
<name>Rules for Adding/Deleting Cells</name> <name>Rules for Adding and Deleting Cells</name>
<t> <t>
Once a node has joined the 6TiSCH network, it adds/deletes/ relocates cells with the selected parent for three reasons: Once a node has joined the 6TiSCH network, it adds/deletes/ relocates cells with the selected parent for three reasons:
</t> </t>
<ul spacing="compact"> <ul spacing="normal">
<li>to match the link-layer resources to the traffic betwee <li>to match the link-layer resources to the traffic betwee
n the node and the selected parent (<xref target="sec_traffic" format="defa n the node and the selected parent (<xref target="sec_traffic" format="defa
ult"/>)</li> ult"/>),</li>
<li>to handle switching parent or(<xref target="sec_switchi <li>to handle switching the parent (<xref target="sec_switc
ng_parent" format="default"/>)</li> hing_parent" format="default"/>), or</li>
<li>to handle a schedule collision (<xref target="sec_colli <li>to handle a schedule collision (<xref target="sec_colli
sion" format="default"/>)</li> sion" format="default"/>).</li>
</ul> </ul>
<t> <t>
Those cells are called 'negotiated cells' as they are sched These cells are called "negotiated cells" as they are sched
uled through 6P, negotiated with the node's parent. uled through 6P and negotiated with the node's parent.
Without specific declaration, all cells mentioned in this s Without specific declaration, all cells mentioned in this s
ection are negotiated cells and they are installed at Slotframe 2. ection are negotiated cells, and they are installed at Slotframe 2.
</t> </t>
<section anchor="sec_traffic" numbered="true" toc="default"> <section anchor="sec_traffic" numbered="true" toc="default">
<name>Adapting to Traffic</name> <name>Adapting to Traffic</name>
<t> <t>
A node implementing MSF MUST implement the behavior des cribed in this section. A node implementing MSF <bcp14>MUST</bcp14> implement t he behavior described in this section.
</t> </t>
<t> <t>
The goal of MSF is to manage the communication schedule in the 6TiSCH schedule in a distributed manner. The goal of MSF is to manage the communication schedule in the 6TiSCH schedule in a distributed manner.
For a node, this translates into monitoring the current usage of the cells it has to one of its neighbors, in most cases to the se lected parent. For a node, this translates into monitoring the current usage of the cells it has to one of its neighbors, in most cases to the se lected parent.
</t> </t>
<ul spacing="compact"> <ul spacing="normal">
<li> <li>
If the node determines that the number of link-laye r frames it is attempting to exchange with the selected parent per unit of time is larger than the capacity offered by the TSCH negotiated cells it ha s scheduled with it, the node issues a 6P ADD command to that parent to add cells to the TSCH schedule. If the node determines that the number of link-laye r frames it is attempting to exchange with the selected parent per unit of time is larger than the capacity offered by the TSCH negotiated cells it ha s scheduled with it, the node issues a 6P ADD command to that parent to add cells to the TSCH schedule.
</li> </li>
<li> <li>
If the traffic is lower than the capacity, the node issues a 6P DELETE command to that parent to delete cells from the TSCH sc hedule. If the traffic is lower than the capacity, the node issues a 6P DELETE command to that parent to delete cells from the TSCH sc hedule.
</li> </li>
</ul> </ul>
<t> <t>
The node MUST maintain two separate pairs of the follow ing counters for the selected parent, The node <bcp14>MUST</bcp14> maintain two separate pair s of the following counters for the selected parent:
one for the negotiated Tx cells to that parent and one for the negotiated Tx cells to that parent and
one for the negotiated Rx cells to that parent. one for the negotiated Rx cells to that parent.
</t> </t>
<dl newline="false" spacing="compact" indent="4"> <dl newline="false">
<dt>NumCellsElapsed :</dt> <dt>NumCellsElapsed:</dt>
<dd> <dd>
Counts the number of negotiated cells that have ela psed since the counter was initialized. Counts the number of negotiated cells that have ela psed since the counter was initialized.
This counter is initialized at 0. This counter is initialized at 0.
When the current cell is declared as a negotiated c ell to the selected parent, NumCellsElapsed is incremented by exactly 1, re gardless of whether the cell is used to transmit/receive a frame. When the current cell is declared as a negotiated c ell to the selected parent, NumCellsElapsed is incremented by exactly 1, re gardless of whether the cell is used to transmit or receive a frame.
</dd> </dd>
<dt>NumCellsUsed:</dt> <dt>NumCellsUsed:</dt>
<dd> <dd>
<t> <t>
Counts the number of negotiated cells that have been used. Counts the number of negotiated cells that have been used.
This counter is initialized at 0. This counter is initialized at 0.
NumCellsUsed is incremented by exactly 1 when, during a negotiated cell to the selected parent, either of the following ha ppens: NumCellsUsed is incremented by exactly 1 when, during a negotiated cell to the selected parent, either of the following ha ppens:
</t> </t>
<ul spacing="compact"> <ul spacing="normal">
<li> <li>
The node sends a frame to the parent. The node sends a frame to the parent.
The counter increments regardless of whethe r a link-layer acknowledgment was received or not. The counter increments regardless of whethe r a link-layer acknowledgment was received or not.
</li> </li>
<!-- [rfced] We have updated the following sentence in Section 5.1:
Original:
* The node receives a valid frame from the parent. The counter
increments only when the frame is a valid [IEEE802154] frame.
Current:
* The node receives a valid frame from the parent. The counter
increments only when a valid frame per [IEEE802154] is received by
the node from its parent.
-->
<li> <li>
The node receives a valid frame from the pa rent. The node receives a valid frame from the pa rent.
The counter increments only when the frame is a valid IEEE802.15.4 frame. The counter increments only when a valid fr ame per <xref target="IEEE802154" format="default"/> is received by the nod e from its parent.
</li> </li>
</ul> </ul>
</dd> </dd>
</dl> </dl>
<t> <t>
The cell option of cells listed in CellList in 6P Reque The cell option of cells listed in CellList in a 6P Req
st frame SHOULD be either (Tx=1, Rx=0) only or (Tx=0, Rx=1) only. uest frame <bcp14>SHOULD</bcp14> be either (Tx=1, Rx=0) only or (Tx=0, Rx=1
Both NumCellsElapsed and NumCellsUsed counters can be u ) only.
sed for both type of negotiated cells. Both NumCellsElapsed and NumCellsUsed counters can be u
sed for both types of negotiated cells.
</t> </t>
<t> <t>
As there is no negotiated Rx Cell installed at initial time, the AutoRxCell is taken into account as well for downstream traffic a daptation. As there is no negotiated Rx cell installed at initial time, the AutoRxCell is taken into account as well for downstream traffic a daptation.
In this case: In this case:
</t> </t>
<ul spacing="compact"> <ul spacing="normal">
<li> <li>
NumCellsElapsed is incremented by exactly 1 when th e current cell is AutoRxCell. NumCellsElapsed is incremented by exactly 1 when th e current cell is AutoRxCell.
</li> </li>
<li> <li>
NumCellsUsed is incremented by exactly 1 when the n ode receives a frame from the selected parent on AutoRxCell. NumCellsUsed is incremented by exactly 1 when the n ode receives a frame from the selected parent on AutoRxCell.
</li> </li>
</ul> </ul>
<t> <t>
Implementors MAY choose to create the same counters for each neighbor, and add them as additional statistics in the neighbor table . Implementors <bcp14>MAY</bcp14> choose to create the sa me counters for each neighbor and add them as additional statistics in the neighbor table.
</t> </t>
<t> <t>
The counters are used as follows: The counters are used as follows:
</t> </t>
<ol spacing="compact" type="1"> <ol spacing="normal" type="1">
<li> <li>
Both NumCellsElapsed and NumCellsUsed are initializ ed to 0 when the node boots. Both NumCellsElapsed and NumCellsUsed are initializ ed to 0 when the node boots.
</li> </li>
<li> <li anchor="counter_step2">
<t> <t>
When the value of NumCellsElapsed reaches MAX_N UM_CELLS: When the value of NumCellsElapsed reaches MAX_N UM_CELLS:
</t> </t>
<ul spacing="compact"> <ul spacing="normal">
<li>If NumCellsUsed &gt; LIM_NUMCELLSUSED_HIGH, <li>If NumCellsUsed is greater than LIM_NUMCELL
trigger 6P to add a single cell to the selected parent</li> SUSED_HIGH, trigger 6P to add a single cell to the selected parent.</li>
<li>If NumCellsUsed &lt; LIM_NUMCELLSUSED_LOW, <li>If NumCellsUsed is less than LIM_NUMCELLSUS
trigger 6P to remove a single cell to the selected parent</li> ED_LOW, trigger 6P to remove a single cell to the selected parent.</li>
<li>Reset both NumCellsElapsed and NumCellsUse <!-- [rfced] In Section 5.1, the hyperlinked "Step 2" in the
d to 0 and go to step 2.</li> following sentence goes to "2. When the value of NumCellsElapsed
reaches MAX_NUM_CELLS:"
* Reset both NumCellsElapsed and NumCellsUsed to 0 and go to
Step 2.
Should it instead go to Section 4.3 ("Step 2 - Receiving EBs")?
If the link is correct (go to #2), then perhaps it should be
rephrased as "restart #2"?
* Reset both NumCellsElapsed and NumCellsUsed to 0 and restart
#2.
-->
<li>Reset both NumCellsElapsed and NumCellsUsed
to 0 and go to <xref target="counter_step2" format="none">Step 2</xref>.</
li>
</ul> </ul>
</li> </li>
</ol> </ol>
<t> <t>
The value of MAX_NUM_CELLS is chosen according to the t raffic type of the network. The value of MAX_NUM_CELLS is chosen according to the t raffic type of the network.
Generally speaking, the larger the value MAX_NUM_CELLS Generally speaking, the larger the value MAX_NUM_CELLS
is, the more accurate the cell usage is calculated. is, the more accurately the cell usage is calculated.
The 6P traffic overhead using a larger value of MAX_NUM By using a larger value of MAX_NUM_CELLS, the 6P traffi
_CELLS could be reduced as well. c overhead could be reduced as well.
Meanwhile, the latency won't increase much by using a l arger value of MAX_NUM_CELLS for periodic traffic type. Meanwhile, the latency won't increase much by using a l arger value of MAX_NUM_CELLS for periodic traffic type.
For bursty traffic, larger value of MAX_NUM_CELLS indee For bursty traffic, a larger value of MAX_NUM_CELLS ind
d introduces higher latency. eed introduces higher latency.
The latency caused by slight changes of traffic load ca The latency caused by slight changes of traffic load ca
n be absolved by the additional scheduled cells. n be alleviated by the additional scheduled cells.
In this sense, MSF is a scheduling function trading lat In this sense, MSF is a Scheduling Function that trades
ency with energy by scheduling more cells than needed. latency with energy by scheduling more cells than needed.
Setting MAX_NUM_CELLS to a value at least 4x of the rec Setting MAX_NUM_CELLS to a value at least four times th
ent maximum number of cells used in a slot frame is RECOMMENDED. e recent maximum number of cells used in a slotframe is <bcp14>RECOMMENDED<
For example, a 2 packets/slotframe traffic load results /bcp14>.
an average 4 cells scheduled (2 cells are used), using at least the value For example, a two packets/slotframe traffic load resul
of double number of scheduled cells (which is 8) as MAX_NUM_CELLS gives a g ts in an average of four cells scheduled (two cells are used), using at lea
ood resolution on cell usage calculation. st the value of double the number of scheduled cells (which is eight) as MA
X_NUM_CELLS gives a good resolution on the cell usage calculation.
</t> </t>
<t> <t>
In case that a node booted or disappeared from the netw In the case that a node has booted or has disappeared f
ork, the cell reserved at the selected parent may be kept in the schedule f rom the network, the cell reserved at the selected parent may be kept in th
orever. e schedule forever.
A clean-up mechanism MUST be provided to resolve this i A cleanup mechanism <bcp14>MUST</bcp14> be provided to
ssue. resolve this issue.
The clean-up mechanism is implementation-specific. The cleanup mechanism is implementation-specific.
The goal is to confirm those negotiated cells are not u The goal is to confirm that those negotiated cells are
sed anymore by the associated neighbors and remove them from the schedule. not used anymore by the associated neighbors and remove them from the sched
ule.
</t> </t>
</section> </section>
<section anchor="sec_switching_parent" numbered="true" toc="def ault"> <section anchor="sec_switching_parent" numbered="true" toc="def ault">
<name>Switching Parent</name> <name>Switching Parent</name>
<t> <t>
A node implementing MSF SHOULD implement the behavior d escribed in this section. A node implementing MSF <bcp14>SHOULD</bcp14> implement the behavior described in this section.
</t> </t>
<t> <t>
Part of its normal operation, the RPL routing protocol As part of its normal operation, RPL can have a node sw
can have a node switch parent. itch parent.
The procedure for switching from the old parent to the The procedure for switching from the old parent to the
new parent is: new parent is the following:
</t> </t>
<ol spacing="compact" type="1"> <ol spacing="normal" type="1">
<li>the node counts the number of negotiated cells it h <li>The node counts the number of negotiated cells it h
as per slotframe to the old parent</li> as per slotframe to the old parent.</li>
<li>the node triggers one or more 6P ADD commands to sc <li>The node triggers one or more 6P ADD commands to sc
hedule the same number of negotiated cells with same cell options to the ne hedule the same number of negotiated cells with same cell options to the ne
w parent</li> w parent.</li>
<li>when that successfully completes, the node issues a <li>When that successfully completes, the node issues a
6P CLEAR command to its old parent</li> 6P CLEAR command to its old parent.</li>
</ol> </ol>
<t> <t>
For what type of negotiated cell should be installed fi rst, it depends on which traffic has the higher priority, upstream or downs tream, which is application-specific and out-of-scope of MSF. The type of negotiated cell that should be installed fir st depends on which traffic has the higher priority, upstream or downstream , which is application-specific and out of scope of MSF.
</t> </t>
</section> </section>
<section anchor="sec_collision" numbered="true" toc="default"> <section anchor="sec_collision" numbered="true" toc="default">
<name>Handling Schedule Collisions</name> <name>Handling Schedule Collisions</name>
<t> <t>
A node implementing MSF SHOULD implement the behavior d A node implementing MSF <bcp14>SHOULD</bcp14> implement
escribed in this section. the behavior described in this section.
Other schedule collisions handling algorithm can be an Other algorithms for handling schedule collisions can b
alternative of the algorithm proposed in this section. e an alternative to the algorithm proposed in this section.
</t> </t>
<t> <t>
Since scheduling is entirely distributed, there is a no n-zero probability that two pairs of nearby neighbor nodes schedule a negot iated cell at the same [slotOffset,channelOffset] location in the TSCH sche dule. Since scheduling is entirely distributed, there is a no nzero probability that two pairs of nearby neighbor nodes schedule a negoti ated cell at the same [slotOffset,channelOffset] location in the TSCH sched ule.
In that case, data exchanged by the two pairs may colli de on that cell. In that case, data exchanged by the two pairs may colli de on that cell.
We call this case a "schedule collision". We call this case a "schedule collision".
</t> </t>
<t> <t>
The node MUST maintain the following counters for each negotiated Tx cell to the selected parent: The node <bcp14>MUST</bcp14> maintain the following cou nters for each negotiated Tx cell to the selected parent:
</t> </t>
<dl newline="false" spacing="compact" indent="4"> <dl newline="false">
<dt>NumTx:</dt> <dt>NumTx:</dt>
<dd> <dd>
Counts the number of transmission attempts on that cell. Counts the number of transmission attempts on that cell.
Each time the node attempts to transmit a frame on that cell, NumTx is incremented by exactly 1. Each time the node attempts to transmit a frame on that cell, NumTx is incremented by exactly 1.
</dd> </dd>
<dt>NumTxAck:</dt> <dt>NumTxAck:</dt>
<dd> <dd>
Counts the number of successful transmission attemp ts on that cell. Counts the number of successful transmission attemp ts on that cell.
Each time the node receives an acknowledgment for a transmission attempt, NumTxAck is incremented by exactly 1. Each time the node receives an acknowledgment for a transmission attempt, NumTxAck is incremented by exactly 1.
</dd> </dd>
</dl> </dl>
<t> <t>
Since both NumTx and NumTxAck are initialized to 0, we Since both NumTx and NumTxAck are initialized to 0, we
necessarily have NumTxAck &lt;= NumTx. necessarily have NumTxAck less than or equal to NumTx.
We call Packet Delivery Ratio (PDR) the ratio NumTxAck/ We call Packet Delivery Ratio (PDR) the ratio NumTxAck/
NumTx; and represent it as a percentage. NumTx and represent it as a percentage.
A cell with PDR=50% means that half of the frames trans A cell with a PDR equal to 50% means that half of the f
mitted are not acknowledged. rames transmitted are not acknowledged.
</t> </t>
<t> <t>
Each time the node switches parent (or during the join Each time the node switches parent (or during the join
process when the node selects a parent for the first time), both NumTx and process when the node selects a parent for the first time), both NumTx and
NumTxAck MUST be reset to 0. NumTxAck <bcp14>MUST</bcp14> be reset to 0.
They increment over time, as the schedule is executed a They increment over time, as the schedule is executed,
nd the node sends frames to that parent. and the node sends frames to that parent.
When NumTx reaches MAX_NUMTX, both NumTx and NumTxAck M When NumTx reaches MAX_NUMTX, both NumTx and NumTxAck <
UST be divided by 2. bcp14>MUST</bcp14> be divided by 2.
MAX_NUMTX needs to be a power of two to avoid division error. MAX_NUMTX needs to be a power of two to avoid division error.
For example, when MAX_NUMTX is set to 256, from NumTx=2 For example, when MAX_NUMTX is set to 256, and NumTx=25
55 and NumTxAck=127, the counters become NumTx=128 and NumTxAck=64 if one f 5 and NumTxAck=127, the counters become NumTx=128 and NumTxAck=64 if one fr
rame is sent to the parent with an Acknowledgment received. ame is sent to the parent with an acknowledgment received.
This operation does not change the value of the PDR, bu This operation does not change the value of the PDR but
t allows the counters to keep incrementing. allows the counters to keep incrementing.
The value of MAX_NUMTX is implementation-specific. The value of MAX_NUMTX is implementation-specific.
</t> </t>
<t> <t>
The key for detecting a schedule collision is that, if a node has several cells to the selected parent, all cells should exhibit t he same PDR. The key for detecting a schedule collision is that, if a node has several cells to the selected parent, all cells should exhibit t he same PDR.
A cell which exhibits a PDR significantly lower than th e others indicates than there are collisions on that cell. A cell that exhibits a PDR significantly lower than the others indicates that there are collisions on that cell.
</t> </t>
<t> <t>
Every HOUSEKEEPINGCOLLISION_PERIOD, the node executes t he following steps: Every HOUSEKEEPINGCOLLISION_PERIOD, the node executes t he following steps:
</t> </t>
<ol spacing="compact" type="1"> <ol spacing="normal">
<li> <li>
It computes, for each negotiated Tx cell with the p arent (not for the autonomous cell), that cell's PDR. It computes, for each negotiated Tx cell with the p arent (not for the autonomous cell), that cell's PDR.
</li> </li>
<li> <li>
Any cell that hasn't yet had NumTx divided by 2 sin ce it was last reset is skipped in steps 3 and 4. Any cell that hasn't yet had NumTx divided by 2 sin ce it was last reset is skipped in steps 3 and 4.
This avoids triggering cell relocation when the val ues of NumTx and NumTxAck are not statistically significant yet. This avoids triggering cell relocation when the val ues of NumTx and NumTxAck are not statistically significant yet.
</li> </li>
<li> <li>
It identifies the cell with the highest PDR. It identifies the cell with the highest PDR.
</li> </li>
skipping to change at line 581 skipping to change at line 621
For any other cell, it compares its PDR against tha t of the cell with the highest PDR. For any other cell, it compares its PDR against tha t of the cell with the highest PDR.
If the subtraction difference between the PDR of th e cell and the highest PDR is larger than RELOCATE_PDRTHRES, it triggers th e relocation of that cell using a 6P RELOCATE command. If the subtraction difference between the PDR of th e cell and the highest PDR is larger than RELOCATE_PDRTHRES, it triggers th e relocation of that cell using a 6P RELOCATE command.
</li> </li>
</ol> </ol>
<t> <t>
The RELOCATION for negotiated Rx cells is not supported by MSF. The RELOCATION for negotiated Rx cells is not supported by MSF.
</t> </t>
</section> </section>
</section> </section>
<section anchor="sec_signal" numbered="true" toc="default"> <section anchor="sec_signal" numbered="true" toc="default">
<name>6P SIGNAL command</name> <name>6P SIGNAL Command</name>
<t> <t>
The 6P SIGNAL command is not used by MSF. The 6P SIGNAL command is not used by MSF.
</t> </t>
</section> </section>
<section anchor="sec_sfid" numbered="true" toc="default"> <section anchor="sec_sfid" numbered="true" toc="default">
<name>Scheduling Function Identifier</name> <name>Scheduling Function Identifier</name>
<t> <t>
The Scheduling Function Identifier (SFID) of MSF is IANA_6T The Scheduling Function Identifier (SFID) of MSF is 0.
ISCH_SFID_MSF. How the value of 0 was chosen is described in <xref target=
How the value of IANA_6TISCH_SFID_MSF is chosen is describe "sec_iana" format="default"/>.
d in <xref target="sec_iana" format="default"/>.
</t> </t>
</section> </section>
<section anchor="sec_celllist" numbered="true" toc="default"> <section anchor="sec_celllist" numbered="true" toc="default">
<name>Rules for CellList</name> <name>Rules for CellList</name>
<t> <t>
MSF uses 2-step 6P Transactions exclusively. MSF uses two-step 6P Transactions exclusively.
6P transactions are only initiated by a node towards its pa 6P Transactions are only initiated by a node towards its pa
rent. rent.
As a result, the cells to put in the CellList of a 6P ADD c As a result, the cells to put in the CellList of a 6P ADD c
ommand, and in the candidate CellList of a RELOCATE command, are chosen by ommand, and in the candidate CellList of a RELOCATE command, are chosen by
the node initiating the 6P transaction. the node initiating the 6P Transaction.
In both cases, the same rules apply: In both cases, the same rules apply:
</t> </t>
<ul spacing="compact"> <ul spacing="normal">
<li>The CellList is RECOMMENDED to have 5 or more cells.</l <li>The CellList is <bcp14>RECOMMENDED</bcp14> to have five
i> or more cells.</li>
<li>Each cell in the CellList MUST have a different slotOff <li>Each cell in the CellList <bcp14>MUST</bcp14> have a di
set value.</li> fferent slotOffset value.</li>
<li>For each cell in the CellList, the node MUST NOT have a <li>For each cell in the CellList, the node <bcp14>MUST NOT
ny scheduled cell on the same slotOffset.</li> </bcp14> have any scheduled cell on the same slotOffset.</li>
<li>The slotOffset value of any cell in the CellList MUST N <li>The slotOffset value of any cell in the CellList <bcp14
OT be the same as the slotOffset of the minimal cell (slotOffset=0).</li> >MUST NOT</bcp14> be the same as the slotOffset of the minimal cell (slotOf
<li>The slotOffset of a cell in the CellList SHOULD be r fset=0).</li>
andomly and uniformly chosen among all the slotOffset values that satisfy t <li>The slotOffset of a cell in the CellList <bcp14>SHOU
he restrictions above.</li> LD</bcp14> be randomly and uniformly chosen among all the slotOffset values
<li>The channelOffset of a cell in the CellList SHOULD be r that satisfy the restrictions above.</li>
andomly and uniformly chosen in [0..numFrequencies], where numFrequencies r <li>The channelOffset of a cell in the CellList <bcp14>SHOU
epresents the number of frequencies a node can communicate on.</li> LD</bcp14> be randomly and uniformly chosen from [0..numFrequencies], where
numFrequencies represents the number of frequencies a node can communicate
on.</li>
</ul> </ul>
<!-- [rfced] May we move the following citation tag in Section 8 to
improve readability?
Current:
If [IEEE802154] transmissions are observed ...
Perhaps:
If transmissions that rely on [IEEE802154] are observed ... or
If transmissions that rely on LR-WPANs [IEEE802154] are observed ...
-->
<t> <t>
As a consequence of random cell selection, there is a non-z As a consequence of random cell selection, there is a nonze
ero chance that nodes in the vicinity installed cells with same slotOffset ro chance that nodes in the vicinity have installed cells with same slotOff
and channelOffset. set and channelOffset.
An implementer MAY implement a strategy to monitor the cand An implementer <bcp14>MAY</bcp14> implement a strategy to m
idate cells before adding them in CellList to avoid collision. onitor the candidate cells before adding them in CellList to avoid collisio
For example, a node MAY maintain a candidate cell pool for n.
the CellList. For example, a node <bcp14>MAY</bcp14> maintain a candidate
The candidate cells in the pool are pre-configured as Rx ce cell pool for the CellList.
lls to promiscuously listen to detect transmissions on those cells. The candidate cells in the pool are preconfigured as Rx cel
If IEEE802.15.4 transmissions are observed on one cell over ls to promiscuously listen to detect transmissions on those cells.
multiple iterations of the schedule, that cell is probably used by a TSCH If <xref target="IEEE802154" format="default"/> transmissio
neighbor. ns are observed on one cell over multiple iterations of the schedule, that
It is moved out from the pool and a new cell is selected as cell is probably used by a TSCH neighbor.
a candidate cell. It is moved out from the pool, and a new cell is selected a
s a candidate cell.
The cells in CellList are picked from the candidate pool di rectly when required. The cells in CellList are picked from the candidate pool di rectly when required.
</t> </t>
</section> </section>
<section anchor="sec_timeout" numbered="true" toc="default"> <section anchor="sec_timeout" numbered="true" toc="default">
<name>6P Timeout Value</name> <name>6P Timeout Value</name>
<t> <t>
The timeout value is calculated for the worst case that a 6 P response is received, which means the 6P response is sent out successfull y at the very latest retransmission. The timeout value is calculated for the worst case that a 6 P response is received, which means the 6P response is sent out successfull y at the very latest retransmission.
And for each retransmission, it backs-off with largest valu And for each retransmission, it backs off with largest valu
e. e.
Hence the 6P timeout value is calculated as ((2^MAXBE)-1)*M Hence the 6P timeout value is calculated as ((2<sup>MAXBE</
AXRETRIES*SLOTFRAME_LENGTH, where: sup>) - 1) * MAXRETRIES * SLOTFRAME_LENGTH, where:
</t> </t>
<ul spacing="compact"> <ul spacing="normal">
<li>MAXBE, defined in IEEE802.15.4, is the maximum backoff <li>MAXBE, defined in <xref target="IEEE802154" format="def
exponent used</li> ault"/>, is the maximum backoff exponent used.</li>
<li>MAXRETRIES, defined in IEEE802.15.4, is the maximum ret <li>MAXRETRIES, defined in <xref target="IEEE802154" format
ransmission times</li> ="default"/>, is the maximum retransmission times.</li>
<li>SLOTFRAME_LENGTH represents the length of slotframe</li <li>SLOTFRAME_LENGTH represents the length of slotframe.</l
> i>
</ul> </ul>
</section> </section>
<section anchor="sec_ordering" numbered="true" toc="default"> <section anchor="sec_ordering" numbered="true" toc="default">
<name>Rule for Ordering Cells</name> <name>Rule for Ordering Cells</name>
<t> <t>
Cells are ordered slotOffset first, channelOffset second. Cells are ordered by slotOffset first, channelOffset second .
</t> </t>
<t> <t>
The following sequence is correctly ordered (each element r epresents the [slottOffset,channelOffset] of a cell in the schedule): The following sequence is correctly ordered (each element r epresents the [slottOffset,channelOffset] of a cell in the schedule):
</t> </t>
<t> <t>
[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]
</t> </t>
</section> </section>
<section anchor="sec_metadata" numbered="true" toc="default"> <section anchor="sec_metadata" numbered="true" toc="default">
<name>Meaning of the Metadata Field</name> <name>Meaning of the Metadata Field</name>
<t> <t>
The Metadata field is not used by MSF. The Metadata field is not used by MSF.
</t> </t>
</section> </section>
<section anchor="sec_error" numbered="true" toc="default"> <section anchor="sec_error" numbered="true" toc="default">
<name>6P Error Handling</name> <name>6P Error Handling</name>
<t> <t>
Section 6.2.4 of <xref target="RFC8480" format="default"/> <xref target="RFC8480" section="6.2.4" sectionFormat="of"/>
lists the 6P Return Codes. lists the 6P return codes.
<xref target="tab_error" format="default"/> lists the same <xref target="tab_error" format="default"/> lists the same
error codes, and the behavior a node implementing MSF SHOULD follow. error codes and the behavior a node implementing MSF <bcp14>SHOULD</bcp14>
follow.
</t> </t>
<figure anchor="tab_error"> <table anchor="tab_error">
<name>Recommended behavior for each 6P Error Code.</name> <name>Recommended Behavior for Each 6P Error Code</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-----------------+----------------------+ <thead>
| Code | RECOMMENDED behavior | <tr>
+-----------------+----------------------+
| RC_SUCCESS | nothing | <th>Code</th>
| RC_EOL | nothing | <th><bcp14>RECOMMENDED</bcp14> Behavior</th>
| RC_ERR | quarantine | </tr>
| RC_RESET | quarantine | </thead>
| RC_ERR_VERSION | quarantine | <tbody>
| RC_ERR_SFID | quarantine | <tr>
| RC_ERR_SEQNUM | clear | <td> RC_SUCCESS
| RC_ERR_CELLLIST | clear | </td><td> nothing</td>
| RC_ERR_BUSY | waitretry | </tr>
| RC_ERR_LOCKED | waitretry | <tr>
+-----------------+----------------------+
]]></artwork> <td> RC_EOL
</figure> </td><td> nothing</td>
</tr>
<tr>
<td> RC_ERR
</td><td> quarantine</td>
</tr>
<tr>
<td> RC_RESET
</td><td> quarantine </td>
</tr>
<tr>
<td> RC_ERR_VERSION</td>
<td> quarantine</td>
</tr>
<tr>
<td> RC_ERR_SFID</td>
<td> quarantine</td>
</tr>
<tr>
<td> RC_ERR_SEQNUM</td>
<td> clear</td>
</tr>
<tr>
<td> RC_ERR_CELLLIST </td>
<td> clear</td>
</tr>
<tr>
<td> RC_ERR_BUSY</td>
<td> waitretry</td>
</tr>
<tr>
<td> RC_ERR_LOCKED</td>
<td> waitretry</td>
</tr>
</tbody>
</table>
<t> <t>
The meaning of each behavior from <xref target="tab_error" format="default"/> is: The meaning of each behavior from <xref target="tab_error" format="default"/> is:
</t> </t>
<dl newline="false" spacing="compact" indent="4"> <dl newline="false">
<dt>nothing:</dt> <dt>nothing:</dt>
<dd> <dd>
Indicates that this Return Code is not an error. Indicates that this return code is not an error.
No error handling behavior is triggered. No error handling behavior is triggered.
</dd> </dd>
<dt>clear:</dt> <dt>clear:</dt>
<dd> <dd>
Abort the 6P Transaction. Abort the 6P Transaction.
Issue a 6P CLEAR command to that neighbor (this command may fail at the link layer). Issue a 6P CLEAR command to that neighbor (this command may fail at the link layer).
Remove all cells scheduled with that neighbor from the local schedule. Remove all cells scheduled with that neighbor from the local schedule.
</dd> </dd>
<dt>quarantine:</dt> <dt>quarantine:</dt>
<dd> <dd>
Same behavior as for "clear". Same behavior as for "clear".
In addition, remove the node from the neighbor and rout ing tables. In addition, remove the node from the neighbor and rout ing tables.
Place the node's identifier in a quarantine list for QU ARANTINE_DURATION. Place the node's identifier in a quarantine list for QU ARANTINE_DURATION.
When in quarantine, drop all frames received from that node. When in quarantine, drop all frames received from that node.
</dd> </dd>
<dt>waitretry:</dt> <dt>waitretry:</dt>
<dd> <dd>
Abort the 6P Transaction. Abort the 6P Transaction.
Wait for a duration randomly and uniformly chosen in [W AIT_DURATION_MIN,WAIT_DURATION_MAX]. Wait for a duration randomly and uniformly chosen from [WAIT_DURATION_MIN,WAIT_DURATION_MAX].
Retry the same transaction. Retry the same transaction.
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="sec_inconsistency" numbered="true" toc="default"> <section anchor="sec_inconsistency" numbered="true" toc="default">
<name>Schedule Inconsistency Handling</name> <name>Schedule Inconsistency Handling</name>
<t> <t>
The behavior when schedule inconsistency is detected is exp lained in <xref target="tab_error" format="default"/>, for 6P Return Code R C_ERR_SEQNUM. The behavior when schedule inconsistency is detected is exp lained in <xref target="tab_error" format="default"/>, for 6P return code R C_ERR_SEQNUM.
</t> </t>
</section> </section>
<section anchor="sec_constants" numbered="true" toc="default"> <section anchor="sec_constants" numbered="true" toc="default">
<name>MSF Constants</name> <name>MSF Constants</name>
<t> <t>
<xref target="tab_constants" format="default"/> lists MSF C onstants and their RECOMMENDED values. <xref target="tab_constants" format="default"/> lists MSF c onstants and their <bcp14>RECOMMENDED</bcp14> values.
</t> </t>
<figure anchor="tab_constants"> <table anchor="tab_constants">
<name>MSF Constants and their RECOMMENDED values.</name> <name>MSF Constants and Their <bcp14>RECOMMENDED</bcp14> Valu
<artwork name="" type="" align="left" alt=""><![CDATA[ es</name>
+------------------------------+-------------------+ <thead>
| Name | RECOMMENDED value | <tr>
+------------------------------+-------------------+ <th>Name</th>
| SLOTFRAME_LENGTH | 101 slots | <th><bcp14>RECOMMENDED</bcp14> value</th>
| NUM_CH_OFFSET | 16 | </tr>
| MAX_NUM_CELLS | 100 | </thead>
| LIM_NUMCELLSUSED_HIGH | 75 | <tbody>
| LIM_NUMCELLSUSED_LOW | 25 | <tr>
| MAX_NUMTX | 256 |
| HOUSEKEEPINGCOLLISION_PERIOD | 1 min | <td> SLOTFRAME_LENGTH</td>
| RELOCATE_PDRTHRES | 50 % | <td>101 slots</td>
| QUARANTINE_DURATION | 5 min | </tr>
| WAIT_DURATION_MIN | 30 s | <tr>
| WAIT_DURATION_MAX | 60 s |
+------------------------------+-------------------+ <td> NUM_CH_OFFSET </td>
]]></artwork> <td>16</td>
</figure> </tr>
<tr>
<td> MAX_NUM_CELLS</td>
<td>100</td>
</tr>
<tr>
<td> LIM_NUMCELLSUSED_HIGH</td>
<td>75</td>
</tr>
<tr>
<td> LIM_NUMCELLSUSED_LOW </td>
<td>25</td>
</tr>
<tr>
<td> MAX_NUMTX</td>
<td>256</td>
</tr>
<tr>
<td> HOUSEKEEPINGCOLLISION_PERIOD</td>
<td>1 min</td>
</tr>
<tr>
<td> RELOCATE_PDRTHRES</td>
<td>50 %</td>
</tr>
<tr>
<td> QUARANTINE_DURATION</td>
<td>5 min</td>
</tr>
<tr>
<td> WAIT_DURATION_MIN</td>
<td>30 s</td>
</tr>
<tr>
<td> WAIT_DURATION_MAX </td>
<td>60 s</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="sec_stats" numbered="true" toc="default"> <section anchor="sec_stats" numbered="true" toc="default">
<name>MSF Statistics</name> <name>MSF Statistics</name>
<t> <t>
<xref target="tab_stats" format="default"/> lists MSF Stati stics and their RECOMMENDED width. <xref target="tab_stats" format="default"/> lists MSF stati stics and their <bcp14>RECOMMENDED</bcp14> widths.
</t> </t>
<figure anchor="tab_stats"> <table anchor="tab_stats">
<name>MSF Statistics and their RECOMMENDED width.</name> <name>MSF Statistics and Their <bcp14>RECOMMENDED</bcp14> W
<artwork name="" type="" align="left" alt=""><![CDATA[ idths</name>
+-----------------+-------------------+
| Name | RECOMMENDED width | <thead>
+-----------------+-------------------+ <tr>
| NumCellsElapsed | 1 byte | <th>Name</th>
| NumCellsUsed | 1 byte | <th><bcp14>RECOMMENDED</bcp14> width</th>
| NumTx | 1 byte | </tr>
| NumTxAck | 1 byte | </thead>
+-----------------+-------------------+ <tbody>
]]></artwork> <tr>
</figure> <td> NumCellsElapsed</td>
<td>1 byte</td>
</tr>
<tr>
<td> NumCellsUsed</td>
<td>1 byte</td>
</tr>
<tr>
<td> NumTx</td>
<td>1 byte</td>
</tr>
<tr>
<td> NumTxAck</td>
<td>1 byte</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="sec_security" numbered="true" toc="default"> <section anchor="sec_security" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>
MSF defines a series of "rules" for the node to follow. MSF defines a series of "rules" for the node to follow.
It triggers several actions, that are carried out by the pr It triggers several actions that are carried out by the pro
otocols defined in the following specifications: tocols defined in the following specifications:
the Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiS "<xref target="RFC8180" format="title"/>" <xref target="RFC
CH) Configuration <xref target="RFC8180" format="default"/>, 8180" format="default"/>,
the 6TiSCH Operation Sublayer Protocol (6P) <xref target="R "<xref target="RFC8480" format="title"/>" <xref target="RFC
FC8480" format="default"/>, and 8480" format="default"/>, and
the Constrained Join Protocol (CoJP) for 6TiSCH <xref targe "<xref target="RFC9031" format="title"/>" <xref target="RFC
t="I-D.ietf-6tisch-minimal-security" format="default"/>. 9031" format="default"/>.
Confidentiality and authentication of MSF control and data traffic are provided by these specifications whose security considerations continue to apply to MSF. Confidentiality and authentication of MSF control and data traffic are provided by these specifications whose security considerations continue to apply to MSF.
In particular, MSF does not define a new protocol or packet format. In particular, MSF does not define a new protocol or packet format.
</t> </t>
<t> <t>
MSF uses autonomous cells for initial bootstrap and the tra nsport of join traffic. MSF uses autonomous cells for initial bootstrap and the tra nsport of join traffic.
Autonomous cells are computed as a hash of nodes’ EUI64 add Autonomous cells are computed as a hash of nodes' EUI-64 ad
resses. dresses.
This makes the coordinates of autonomous cell an easy targe This makes the coordinates of autonomous cell an easy targe
t for an attacker, as EUI64 addresses are visible on the wire and are not e t for an attacker, as EUI-64 addresses are visible on the wire and are not
ncrypted by the link-layer security mechanism. encrypted by the link-layer security mechanism.
With the coordinates of autonomous cells available, the att With the coordinates of autonomous cells available, the att
acker can launch a selective jamming attack against any nodes’ AutoRxCell. acker can launch a selective jamming attack against any node's AutoRxCell.
If the attacker targets a node acting as a JP, it can preve nt pledges from using that JP to join the network. If the attacker targets a node acting as a JP, it can preve nt pledges from using that JP to join the network.
The pledge detects such a situation through the absence of a link-layer acknowledgment for its Join Request. The pledge detects such a situation through the absence of a link-layer acknowledgment for its Join Request.
As it is expected that each pledge will have more than one As it is expected that each pledge will have more than one
JP available to join the network, one available countermeasure for the pled JP available to join the network, one available countermeasure for the pled
ge is to pseudo-randomly select a new JP when the link to the previous JP a ge is to pseudorandomly select a new JP when the link to the previous JP ap
ppears bad. pears bad.
Such strategy alleviates the issue of the attacker randomly Such a strategy alleviates the issue of the attacker random
jamming to disturb the network but does not help in case the attacker is t ly jamming to disturb the network but does not help in the case the attacke
argeting a particular pledge. r is targeting a particular pledge.
In that case, the attacker can jam the AutoRxCell of the pl In that case, the attacker can jam the AutoRxCell of the pl
edge, in order to prevent it from receiving the join response. edge in order to prevent it from receiving the join response.
This situation should be detected through the absence of a particular node from the network and handled by the network administrator t hrough out-of-band means. This situation should be detected through the absence of a particular node from the network and handled by the network administrator t hrough out-of-band means.
</t> </t>
<t> <t>
MSF adapts to traffic containing packets from the IP layer. MSF adapts to traffic containing packets from the IP layer.
It is possible that the IP packet has a non-zero DSCP (Diff serv Code Point <xref target="RFC2474" format="default"/>) value in its IPv 6 header. It is possible that the IP packet has a nonzero DSCP (Diffe rentiated Services Code Point) <xref target="RFC2474" format="default"/> va lue in its IPv6 header.
The decision how to handle that packet belongs to the upper layer and is out of scope of MSF. The decision how to handle that packet belongs to the upper layer and is out of scope of MSF.
As long as the decision is made to hand over to MAC layer t o transmit, MSF will take that packet into account when adapting to traffic . As long as the decision is made to hand over to MAC layer t o transmit, MSF will take that packet into account when adapting to traffic .
</t> </t>
<t> <t>
Note that non-zero DSCP value may imply that the traffic is Note that nonzero DSCP values may imply that the traffic or
originated at unauthenticated pledges, referring to <xref target="I-D.ietf iginated at unauthenticated pledges (see <xref target="RFC9031" format="def
-6tisch-minimal-security" format="default"/>. ault"/>).
The implementation at IPv6 layer SHOULD rate-limit this joi The implementation at the IPv6 layer <bcp14>SHOULD</bcp14>
n traffic before it is passed to 6top sublayer where MSF can observe it. rate limit this join traffic before it is passed to the 6top sublayer where
In case there is no rate limit for join traffic, intermedia MSF can observe it.
te nodes in the 6TiSCH network may be prone to a resource exhaustion attack If there is no rate limit for join traffic, intermediate no
, with the attacker injecting unauthenticated traffic from the network edge des in the 6TiSCH network may be prone to a resource exhaustion attack, wit
. h the attacker injecting unauthenticated traffic from the network edge.
The assumption is that the rate limiting function is aware The assumption is that the rate-limiting function is aware
of the available bandwidth in the 6top L3 bundle(s) towards a next hop, not of the available bandwidth in the 6top Layer 3 bundle(s) towards a next hop
directly from MSF, but from an interaction with the 6top sublayer that man , not directly from MSF, but from an interaction with the 6top sublayer tha
ages ultimately the bundles under MSF's guidance. t ultimately manages the bundles under MSF's guidance.
How this rate-limit is implemented is out of scope of MSF. How this rate limit is implemented is out of scope of MSF.
</t> </t>
</section> </section>
<section anchor="sec_iana" numbered="true" toc="default"> <section anchor="sec_iana" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="sec_iana_sfid" numbered="true" toc="default"> <section anchor="sec_iana_sfid" numbered="true" toc="default">
<name>MSF Scheduling Function Identifiers</name> <name>MSF Scheduling Function Identifiers</name>
<t> <t>
This document adds the following number to the This document adds the following number to the
"6P Scheduling Function Identifiers" sub-registry, "6P Scheduling Function Identifiers" subregistry,
part of the "IPv6 over the TSCH mode of IEEE 802.15.4e part of the "IPv6 Over the TSCH Mode of IEEE 802.15.4e
(6TiSCH) parameters" registry, (6TiSCH)" registry,
as defined by <xref target="RFC8480" format="default"/> : as defined by <xref target="RFC8480" format="default"/> :
</t> </t>
<figure anchor="fig_iana_sfid">
<name>New SFID in 6P Scheduling Function Identifiers su <table anchor="fig_iana_sfid">
bregistry.</name> <name>New SFID in the "6P Scheduling Function Identifiers
<artwork name="" type="" align="left" alt=""><![CDATA[ " Subregistry</name>
+----------------------+-----------------------------+-------------+ <thead>
| SFID | Name | Reference | <tr>
+----------------------+-----------------------------+-------------+ <th>SFID</th>
| IANA_6TISCH_SFID_MSF | Minimal Scheduling Function | RFC_THIS | <th>Name</th>
| | (MSF) | | <th>Reference</th>
+----------------------+-----------------------------+-------------+ </tr>
]]></artwork> </thead>
</figure> <tbody>
<tr>
<td>0</td>
<td>Minimal Scheduling Function (MSF)</td>
<td>RFC 9033</td>
</tr>
</tbody>
</table>
<t> <t>
IANA_6TISCH_SFID_MSF is chosen from range 0-127, which is used for IETF Review or IESG Approval. The SFID was chosen from the range 0-127, which has the registration procedure of IETF Review or IESG Approval <xref target="RFC81 26"/>.
</t> </t>
</section> </section>
</section> </section>
<section anchor="sec_contributors" numbered="true" toc="default">
<name>Contributors</name>
<ul spacing="compact">
<li>Beshr Al Nahas (Chalmers University, beshr@chalmers.se)
</li>
<li>Olaf Landsiedel (Chalmers University, olafl@chalmers.se
)</li>
<li>Yasuyuki Tanaka (Inria-Paris, yasuyuki.tanaka@inria.fr)
</li>
</ul>
</section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-6tisch-dtsecurity-zerotouch-join" to="ZE
ROTOUCH-JOIN"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<!-- RFC 6TiSCH-->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc /bibxml/reference.RFC.8180.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc /bibxml/reference.RFC.8180.xml"/>
<!-- Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6Ti SCH) Configuration -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc /bibxml/reference.RFC.8480.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc /bibxml/reference.RFC.8480.xml"/>
<!-- 6TiSCH Operation Sublayer (6top) Protocol (6P) -->
<!-- RFC others -->
<!-- RPL: IPv6 Routing Protocol for Low-Power and Lossy Net
works -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc /bibxml/reference.RFC.6550.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc /bibxml/reference.RFC.6550.xml"/>
<!-- Key words for use in RFCs to Indicate Requirement Leve ls -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc /bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc /bibxml/reference.RFC.2119.xml"/>
<!--Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Wor ds --> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc /bibxml/reference.RFC.8126.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc /bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc /bibxml/reference.RFC.8174.xml"/>
<!-- Definition of the Differentiated Services Field (DS Fi eld) in the IPv4 and IPv6 Headers -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc /bibxml/reference.RFC.2474.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc /bibxml/reference.RFC.2474.xml"/>
<!-- Registration Extensions for IPv6 over Low-Power Wirele
ss Personal Area Network (6LoWPAN) Neighbor Discovery --> <!-- [I-D.ietf-6tisch-minimal-security] companion document RFC 9031 -->
<!-- I-D 6TiSCH --> <reference anchor="RFC9031" target="https://www.rfc-editor.org/info/rfc9031
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc ">
/bibxml3/reference.I-D.draft-ietf-6tisch-minimal-security-15.xml"/> <front>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc <title>Constrained Join Protocol (CoJP) for 6TiSCH</title>
/bibxml3/reference.I-D.draft-ietf-6tisch-enrollment-enhanced-beacon-14.xml"
/> <author initials="M" surname="Vucinic" fullname="Malisa Vucinic" role="edit
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc or">
/bibxml3/reference.I-D.draft-ietf-6tisch-architecture-28.xml"/> <organization/>
<!-- I-D others --> </author>
<!-- external -->
<reference anchor="IEEE802154" target='http://ieeexplore.ie <author initials="J" surname="Simon" fullname="Jonathan Simon">
ee.org/document/7460875/'> <organization/>
<front> </author>
<title>
IEEE Std 802.15.4 Standard for Low-Rate Wireles <author initials="K" surname="Pister" fullname="Kris Pister">
s Personal Area Networks (WPANs) <organization/>
</title> </author>
<author>
<organization>IEEE standard for Information Tec <author initials="M" surname="Richardson" fullname="Michael Richardson">
hnology</organization> <organization/>
</author> </author>
<date/>
</front> <date month="April" year="2021"/>
<seriesInfo name='DOI' value='10.1109/IEEE P802.15.4-RE
Vd/D01'/> </front>
</reference> <seriesInfo name="RFC" value="9031"/>
<seriesInfo name="DOI" value="10.17487/RFC9031"/>
</reference>
<!-- [I-D.ietf-6tisch-enrollment-enhanced-beacon] companion document RFC 90
32 -->
<reference anchor="RFC9032" target="https://www.rfc-editor.org/info/rfc9032
">
<front>
<title>IEEE 802.15.4 Information Element Encapsulation of 6TiSCH Join and E
nrollment Information</title>
<author initials="D" surname="Dujovne" fullname="Diego Dujovne">
<organization/>
</author>
<author initials="M" surname="Richardson" fullname="Michael Richardson">
<organization/>
</author>
<date month="April" year="2021"/>
</front>
<seriesInfo name="RFC" value="9032"/>
<seriesInfo name="DOI" value="10.17487/RFC9032"/>
</reference>
<!-- [I-D.ietf-6tisch-architecture] companion document RFC 9030 -->
<reference anchor="RFC9030" target="https://www.rfc-editor.org/info/rfc9030
">
<front>
<title>An Architecture for IPv6 over the TSCH Mode of IEEE 802.15.4</title>
<author initials="P" surname="Thubert" fullname="Pascal Thubert" role="edit
or">
<organization/>
</author>
<date month="April" year="2021"/>
</front>
<seriesInfo name="RFC" value="9030"/>
<seriesInfo name="DOI" value="10.17487/RFC9030"/>
</reference>
<reference anchor="IEEE802154" target="https://ieeexplore.ieee.org/do
cument/7460875">
<front>
<title>IEEE Standard for Low-Rate Wireless Networks</title>
<author>
<organization>IEEE</organization>
</author>
<date month="April" year="2016"/>
</front>
<seriesInfo name="IEEE Standard" value="802.15.4-2015"/>
<seriesInfo name="DOI" value=" 10.1109/IEEESTD.2016.7460875"/>
</reference>
<reference anchor="SAX-DASFAA"> <reference anchor="SAX-DASFAA">
<front> <front>
<title> Performance in Practice of String Hashing F unctions</title> <title> Performance in Practice of String Hashing F unctions</title>
<seriesInfo name="DASFAA" value=""/> <author initials="M.V." surname="Ramakrishna"/>
<author initials="M.V" surname="Ramakrishna"/>
<author initials="J" surname="Zobel"/> <author initials="J" surname="Zobel"/>
<date year="1997"/> <date year="1997"/>
</front> </front>
<seriesInfo name='DOI' value='10.1142/9789812819536_002 <refcontent>DASFAA</refcontent>
3'/> <seriesInfo name="DOI" value="10.1142/9789812819536_002
3"/>
</reference> </reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<!-- RFC 6TiSCH-->
<!-- Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSC
H) in the Internet of Things (IoT): Problem Statement -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc /bibxml/reference.RFC.7554.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc /bibxml/reference.RFC.7554.xml"/>
<!-- 6tisch Zero-Touch Secure Join protocol -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc <!-- [I-D.ietf-6tisch-dtsecurity-zerotouch-join] IESG state Expired -->
/bibxml3/reference.I-D.draft-ietf-6tisch-dtsecurity-zerotouch-join-04.xml"/ <xi:include href="https://datatracker.ietf.org/doc/bibxml3/
> reference.I-D.ietf-6tisch-dtsecurity-zerotouch-join.xml"/>
<!-- RFC others -->
<!-- The Trickle Algorithm -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc /bibxml/reference.RFC.6206.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc /bibxml/reference.RFC.6206.xml"/>
<!-- 6LoWPAN Neighbor Discovery -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc /bibxml/reference.RFC.8505.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc /bibxml/reference.RFC.8505.xml"/>
<!-- I-D 6TiSCH -->
<!-- I-D others -->
<!-- external -->
</references> </references>
</references> </references>
<section anchor="sec_hash_function" numbered="true" toc="default"> <section anchor="sec_hash_function" numbered="true" toc="default">
<name>Example of Implementation of SAX hash function</name> <name>Example Implementation of the SAX Hash Function</name>
<t> <t>
Considering the interoperability, this section provides an example of implemention SAX hash function <xref target="SAX-DASFAA" format= "default"/>. To support interoperability, this section provides an examp le implementation of the SAX hash function <xref target="SAX-DASFAA" forma t="default"/>.
The input parameters of the function are: The input parameters of the function are:
</t> </t>
<ul spacing="compact"> <ul spacing="normal">
<li>T, which is the hashing table length</li> <li>T, which is the hashing table length.</li>
<li>c, which is the characters of string s, to be hashed</l <li>c, which is the characters of string s, to be hashed.</
i> li>
</ul> </ul>
<t> <t>
In MSF, the T is replaced by the length of slotframe 1. In MSF, the T is replaced by the length of slotframe 1.
String s is replaced by the mote EUI64 address. The charact ers of the string c0, c1, ..., c7 are the 8 bytes of EUI64 address. String s is replaced by the node EUI-64 address. The charac ters of the string, c0 through c7, are the eight bytes of the EUI-64 addres s.
</t> </t>
<t> <t>
The SAX hash function requires shift operation which is def ined as follow: The SAX hash function requires shift operation, which is de fined as follow:
</t> </t>
<ul spacing="compact"> <ul spacing="normal">
<li>L_shift(v,b), which refers to left shift variable v by <li>L_shift(v,b), which refers to the left shift of variabl
b bits</li> e v by b bits</li>
<li>R_shift(v,b), which refers to right shift variable v by <li>R_shift(v,b), which refers to the right shift of variab
b bits</li> le v by b bits</li>
</ul> </ul>
<t> <t>
The steps to calculate the hash value of SAX hash function are: The steps to calculate the hash value of SAX hash function are:
</t> </t>
<ol spacing="compact" type="1"> <ol spacing="normal">
<li>initialize variable h to h0 and variable i to 0, where <li anchor="sax_step1">Initialize variable h, which is the
h is the intermediate hash value and i is the index of the bytes of EUI64 a intermediate hash value, to h0 and variable i, which is the index of the by
ddress</li> tes of the EUI-64 address, to 0.</li>
<li>sum the value of L_shift(h,l_bit), R_shift(h,r_bit) and <li anchor="sax_step2">Sum the value of L_shift(h,l_bit), R
ci</li> _shift(h,r_bit), and ci.</li>
<li>calculate the result of exclusive or between the sum va <li anchor="sax_step3">Calculate the result of the exclusiv
lue in Step 2 and h</li> e OR between the sum value in <xref target="sax_step2" format="none">Step 2
<li>modulo the result of Step 3 by T</li> </xref> and h.</li>
<li>assign the result of Step 4 to h</li> <li anchor="sax_step4">Modulo the result of <xref target="s
<li>increase i by 1</li> ax_step3" format="none">Step 3</xref> by T.</li>
<li>repeat Step2 to Step 6 until i reaches to 8 </li> <li anchor="sax_step5">Assign the result of <xref target="s
ax_step4" format="none">Step 4</xref> to h.</li>
<li anchor="sax_step6">Increase i by 1.</li>
<li anchor="sax_step7">Repeat <xref target="sax_step2" form
at="none">Step 2</xref> to <xref target="sax_step6" format="none">Step 6</x
ref> until i reaches to 8. </li>
</ol> </ol>
<t> <t>
The value of variable h is the hash value of SAX hash funct ion. The value of variable h is the hash value of the SAX hash f unction.
</t> </t>
<t> <t>
The values of h0, l_bit and r_bit in Step 1 and 2 are confi gured as: The values of h0, l_bit, and r_bit in <xref target="sax_ste p1" format="none">Step 1</xref> and <xref target="sax_step2" format="none"> Step 2</xref> are configured as:
</t> </t>
<ul spacing="compact"> <t indent="6">h0 = 0</t>
<li>h0 = 0</li> <t indent="6">l_bit = 0</t>
<li>l_bit = 0</li> <t indent="6">r_bit = 1</t>
<li>r_bit = 1</li>
</ul>
<t> <t>
The appropriate values of l_bit and r_bit could vary depend ing on the the set of motes' EUI64 address. The appropriate values of l_bit and r_bit could vary depend ing on the set of nodes' EUI-64 address.
How to find those values is out of the scope of this specif ication. How to find those values is out of the scope of this specif ication.
</t> </t>
</section>
<section anchor="sec_contributors" numbered="false">
<name>Contributors</name>
<contact fullname="Beshr Al Nahas">
<organization>Chalmers University</organization>
<address>
<email>beshr@chalmers.se</email>
</address>
</contact>
<contact fullname="Olaf Landsiedel">
<organization>Chalmers University</organization>
<address>
<email>olafl@chalmers.se</email>
</address>
</contact>
<contact fullname="Yasuyuki Tanaka">
<organization>Toshiba</organization>
<address>
<email>yatch1.tanaka@toshiba.co.jp</email>
</address>
</contact>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 149 change blocks. 
568 lines changed or deleted 795 lines changed or added

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