draft-ietf-6tisch-6top-interface-01.txt   draft-ietf-6tisch-6top-interface-02.txt 
6TiSCH Q. Wang, Ed. 6TiSCH Q. Wang, Ed.
Internet-Draft Univ. of Sci. and Tech. Beijing Internet-Draft Univ. of Sci. and Tech. Beijing
Intended status: Informational X. Vilajosana Intended status: Informational X. Vilajosana
Expires: January 5, 2015 Universitat Oberta de Catalunya Expires: April 30, 2015 Universitat Oberta de Catalunya
T. Watteyne T. Watteyne
Linear Technology Linear Technology
July 4, 2014 October 27, 2014
6TiSCH Operation Sublayer (6top) Interface 6TiSCH Operation Sublayer (6top) Interface
draft-ietf-6tisch-6top-interface-01 draft-ietf-6tisch-6top-interface-02
Abstract Abstract
This document defines a generic data model for the 6TiSCH Operation This document defines a generic data model for the 6TiSCH Operation
Sublayer (6top), using the YANG data modeling language. This data Sublayer (6top), using the YANG data modeling language. This data
model can be used for future network management solutions defined by model can be used for future network management solutions defined by
the 6TiSCH working group. This document also defines a list commands the 6TiSCH working group. This document also defines a list of
internal to the 6top sublayer. commands for the internal use of the 6top sublayer and or to be used
by implementers as an API guideline or basic specification.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2015. This Internet-Draft will expire on April 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. 6TiSCH Operation Sublayer (6top) Overview . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
2.1. Cell Model . . . . . . . . . . . . . . . . . . . . . . . 4 3. 6TiSCH Operation Sublayer (6top) Overview . . . . . . . . . . 3
2.1.1. hard cells . . . . . . . . . . . . . . . . . . . . . 6 3.1. Cell Model . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2. soft cells . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. hard cells . . . . . . . . . . . . . . . . . . . . . 6
2.2. Data Transfer Model . . . . . . . . . . . . . . . . . . . 6 3.1.2. soft cells . . . . . . . . . . . . . . . . . . . . . 6
3. Generic Data Model . . . . . . . . . . . . . . . . . . . . . 8 3.2. Data Transfer Model . . . . . . . . . . . . . . . . . . . 6
3.1. YANG model of the 6top MIB . . . . . . . . . . . . . . . 8 4. Generic Data Model . . . . . . . . . . . . . . . . . . . . . 8
3.2. YANG model of the IEEE802.15.4 PIB . . . . . . . . . . . 24 4.1. YANG model of the 6top MIB . . . . . . . . . . . . . . . 8
4. Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.2. YANG model of the IEEE802.15.4 PIB . . . . . . . . . . . 24
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 5. Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1. Normative References . . . . . . . . . . . . . . . . . . 33 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2. Informative References . . . . . . . . . . . . . . . . . 33 6.1. Normative References . . . . . . . . . . . . . . . . . . 33
5.3. External Informative References . . . . . . . . . . . . . 34 6.2. Informative References . . . . . . . . . . . . . . . . . 33
6.3. External Informative References . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
This document defines a generic data model for the 6TiSCH Operation This document defines a generic data model for the 6TiSCH Operation
Sublayer (6top), using the YANG data modeling language defined in Sublayer (6top), using the YANG data modeling language defined in
[RFC6020]. This data model can be used for future network management [RFC6020]. This data model can be used for future network management
solutions defined by the 6TiSCH working group. This document also solutions defined by the 6TiSCH working group. This document also
defines a list commands internal to the 6top sublayer. This data defines a list commands internal to the 6top sublayer. This data
model gives access to metrics (e.g. cell state), TSCH configuration model gives access to metrics (e.g. cell state), TSCH configuration
skipping to change at page 3, line 35 skipping to change at page 3, line 26
failure behavior, and defines mechanisms to encrypt and authenticate failure behavior, and defines mechanisms to encrypt and authenticate
MAC slotframes. MAC slotframes.
As described in [morell04label], due to the slotted nature of a TSCH As described in [morell04label], due to the slotted nature of a TSCH
network, it is possible to use a label switched architecture on top network, it is possible to use a label switched architecture on top
of TSCH cells. As a cell belongs to a specific track, a label header of TSCH cells. As a cell belongs to a specific track, a label header
is not needed at each packet; the input cell (or bundle) and the is not needed at each packet; the input cell (or bundle) and the
output cell (or bundle) uniquely identify the data flow. The 6top output cell (or bundle) uniquely identify the data flow. The 6top
sublayer provides operations to manage the cell mappings. sublayer provides operations to manage the cell mappings.
2. 6TiSCH Operation Sublayer (6top) Overview 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. 6TiSCH Operation Sublayer (6top) Overview
6top is a sublayer which is the next-higher layer for TSCH 6top is a sublayer which is the next-higher layer for TSCH
(Figure 1), as detailed in [I-D.ietf-6tisch-architecture]. 6top (Figure 1), as detailed in [I-D.ietf-6tisch-architecture]. 6top
offers both management and data interfaces to an upper layer, and offers both management and data interfaces to an upper layer, and
includes monitoring and statistics collection, both of which are includes monitoring and statistics collection, both of which are
configurable through its management interface. The detail of 6top- configurable through its management interface. The detail of 6top-
sublayer is described in [I-D.wang-6tisch-6top-sublayer] sublayer is described in [I-D.wang-6tisch-6top-sublayer]
Protocol Stack Protocol Stack
+-----------------------------------+ +-----------------------------------+
skipping to change at page 4, line 27 skipping to change at page 4, line 27
+------------------------------------------+ +------------------------------------------+
| IEEE802.15.4e TSCH | | IEEE802.15.4e TSCH |
+------------------------------------------+ +------------------------------------------+
| IEEE802.15.4 | | IEEE802.15.4 |
+------------------------------------------+ +------------------------------------------+
Figure 1 Figure 1
6top distinguishes between hard cells and soft cells. It therefore 6top distinguishes between hard cells and soft cells. It therefore
requires an extra flag to all cells in the TSCH schedule, as detailed requires an extra flag to all cells in the TSCH schedule, as detailed
in Section 2.1. in Section 3.1.
When a higher layer gives 6top a 6LoWPAN packet for transmission, When a higher layer gives 6top a 6LoWPAN packet for transmission,
6top maps it to the appropriate outgoing priority-based queue, as 6top maps it to the appropriate outgoing priority-based queue, as
detailed in Section 2.2. detailed in Section 3.2.
Section 3 contains a generic data model for the 6top sublayer, Section 4 contains a generic data model for the 6top sublayer,
described in the YANG data modeling language. described in the YANG data modeling language.
The commands of the management and data interfaces are listed in The commands of the management and data interfaces are listed in
Section 4. This set of commands is designed to support Section 5. This set of commands is designed to support
decentralized, centralized and hybrid scheduling solutions. decentralized, centralized and hybrid scheduling solutions.
2.1. Cell Model 3.1. Cell Model
[IEEE802154e] defines a set of options attached to each cell. A cell [IEEE802154e] defines a set of options attached to each cell. A cell
can be a Transmit cell, a Receive cell, a Shared cell or a can be a Transmit cell, a Receive cell, a Shared cell or a
Timekeeping cell. These options are not exclusive, as a cell can be Timekeeping cell. These options are not exclusive, as a cell can be
qualified with more than one of them. The MLME-SET-LINK.request qualified with more than one of them. The MLME-SET-LINK.request
command defined in [IEEE802154e] uses a linkOptions bitmap to specify command defined in [IEEE802154e] uses a linkOptions bitmap to specify
the options of a cell. Acceptable values are: the options of a cell. Acceptable values are:
b0 = Transmit b0 = Transmit
skipping to change at page 6, line 5 skipping to change at page 6, line 5
that participates to the distributed cell scheduling process. The that participates to the distributed cell scheduling process. The
resource in a chunk can be appropriated by the node, i.e. the owner resource in a chunk can be appropriated by the node, i.e. the owner
of the chunk. of the chunk.
Given this mechanism, 6top defines hard cells (which have been Given this mechanism, 6top defines hard cells (which have been
requested specifically) and soft cells (which can be reallocated requested specifically) and soft cells (which can be reallocated
dynamically). The hard/soft flag is introduced by the 6top sublayer dynamically). The hard/soft flag is introduced by the 6top sublayer
named as CellType, 0: soft cell, 1: hard cell. This option is named as CellType, 0: soft cell, 1: hard cell. This option is
mandatory; all cells are either hard or soft. mandatory; all cells are either hard or soft.
2.1.1. hard cells 3.1.1. hard cells
A hard cell is a cell that cannot be dynamically reallocated by 6top. A hard cell is a cell that cannot be dynamically reallocated by 6top.
The CellType MUST be set to 1. The cell is installed by 6top given The CellType MUST be set to 1. The cell is installed by 6top given
specific slotframe ID, slotOffset, and channelOffset. specific slotframe ID, slotOffset, and channelOffset.
2.1.2. soft cells 3.1.2. soft cells
A soft cell is a cell that can be reallocated by 6top dynamically. A soft cell is a cell that can be reallocated by 6top dynamically.
The CellType MUST be set to 0. This cell is installed by 6top given The CellType MUST be set to 0. This cell is installed by 6top given
a specific bandwidth requirement. Soft cells are installed through a specific bandwidth requirement. Soft cells are installed through
the soft cell negotiation procedure described in the soft cell negotiation procedure described in
[I-D.wang-6tisch-6top-sublayer]. [I-D.wang-6tisch-6top-sublayer].
2.2. Data Transfer Model 3.2. Data Transfer Model
Once a TSCH schedule is established, 6top is responsible for feeding Once a TSCH schedule is established, 6top is responsible for feeding
the data from the upper layer into TSCH. This section describes how the data from the upper layer into TSCH. This section describes how
6top shapes data from the upper layer (e.g., RPL, 6LoWPAN), and feeds 6top shapes data from the upper layer (e.g., RPL, 6LoWPAN), and feeds
it to TSCH. Since 6top is a sublayer between TSCH and 6LoWPAN, the it to TSCH. Since 6top is a sublayer between TSCH and 6LoWPAN, the
properties associated with a packet/fragment from the upper layer properties associated with a packet/fragment from the upper layer
includes the next hop neighbor (DestAddr) and expected sending includes the next hop neighbor (DestAddr) and expected sending
priority of the packet (Priority), and/or TrackID(s). The output to priority of the packet (Priority), and/or TrackID(s). The output to
TSCH is the fragment corresponding to the next active cell in the TSCH is the fragment corresponding to the next active cell in the
TSCH schedule. TSCH schedule.
skipping to change at page 7, line 44 skipping to change at page 7, line 44
Figure 2 Figure 2
In Figure 2, Qi represents a queue, which is either broadcast or In Figure 2, Qi represents a queue, which is either broadcast or
unicast, and has an assigned priority. The number of queues is unicast, and has an assigned priority. The number of queues is
configurable. The relationship between queues and tracks is configurable. The relationship between queues and tracks is
configurable. For example, for a given queue, only one specific configurable. For example, for a given queue, only one specific
track can be used, all of the tracks can be used, or a subset of the track can be used, all of the tracks can be used, or a subset of the
tracks can be used. tracks can be used.
When 6top receives a packet to transmit through a Send.data command When 6top receives a packet to transmit through a Send.data command
(Section 4), the I-MUX module selects a queue in which to insert it. (Section 5), the I-MUX module selects a queue in which to insert it.
If the packet's destination address is a unicast (resp. broadcast) If the packet's destination address is a unicast (resp. broadcast)
address, it will be inserted into a unicast (resp. broadcast) queue. address, it will be inserted into a unicast (resp. broadcast) queue.
The MUX module is invoked at each scheduled transmit cell by TSCH. The MUX module is invoked at each scheduled transmit cell by TSCH.
When invoked, the MUX module goes through the queues, looking for the When invoked, the MUX module goes through the queues, looking for the
best matching frame to send. If it finds a frame, it hands it over best matching frame to send. If it finds a frame, it hands it over
to TSCH for transmission. If the next active cell is a broadcast to TSCH for transmission. If the next active cell is a broadcast
cell, it selects a fragment only from broadcast queues. cell, it selects a fragment only from broadcast queues.
How the MUX module selects the best frame is configurable. The How the MUX module selects the best frame is configurable. The
skipping to change at page 8, line 21 skipping to change at page 8, line 21
If the transmit cell is associated with a specific track, the If the transmit cell is associated with a specific track, the
frames in the queue corresponding to the TrackID have the frames in the queue corresponding to the TrackID have the
highest priority. highest priority.
If the transmit cell is not associated with a specific track, If the transmit cell is not associated with a specific track,
i.e., TrackID=(0,0), frames from a queue with a higher priority i.e., TrackID=(0,0), frames from a queue with a higher priority
MUST be sent before frames from a queue with a lower priority. MUST be sent before frames from a queue with a lower priority.
Further rules can be configured to satisfy specific QoS requirements. Further rules can be configured to satisfy specific QoS requirements.
3. Generic Data Model 4. Generic Data Model
This section presents the generic data model of the 6top sublayer, This section presents the generic data model of the 6top sublayer,
using the YANG data modeling langage. This data model can be used using the YANG data modeling langage. This data model can be used
for future network management solutions defined by the 6TiSCH working for future network management solutions defined by the 6TiSCH working
group. The data model consists of the MIB (management information group. The data model consists of the MIB (management information
base) defined in 6top, and part of the PIB (personal area network base) defined in 6top, and part of the PIB (personal area network
information base) defined in [IEEE802154e] and [IEEE802154]. information base) defined in [IEEE802154e] and [IEEE802154].
3.1. YANG model of the 6top MIB 4.1. YANG model of the 6top MIB
list CellList { list CellList {
key "CellID"; key "CellID";
description description
"List of scheduled cells of a node with all of its neighbors, "List of scheduled cells of a node with all of its neighbors,
in all of its slotframes."; in all of its slotframes.";
leaf CellID { leaf CellID {
type uint16; type uint16;
description description
skipping to change at page 9, line 12 skipping to change at page 9, line 12
"IEEE802154e"; "IEEE802154e";
} }
leaf SlotOffset { leaf SlotOffset {
type uint16; type uint16;
description description
"Defined in IEEE802154e."; "Defined in IEEE802154e.";
reference reference
"IEEE802154e"; "IEEE802154e";
} }
leaf ChannelOffset { leaf ChannelOffset {
type uint8; type uint16;
description description
"Defined in IEEE802154e. Value range is 0..15"; "Defined in IEEE802154e.";
reference reference
"IEEE802154e"; "IEEE802154e";
} }
leaf LinkOption { leaf LinkOption {
type bits { type bits {
bit Transmit { bit Transmit {
position 0; position 0;
} }
bit Receive { bit Receive {
position 1; position 1;
skipping to change at page 10, line 50 skipping to change at page 10, line 50
type uint8; type uint8;
description description
"Number of statistics collected on the cell"; "Number of statistics collected on the cell";
} }
list MeasureList { list MeasureList {
key "StatisticsMetricsID"; key "StatisticsMetricsID";
leaf StatisticsMetricsID{ leaf StatisticsMetricsID{
type uint16; type uint16;
description description
"An index of StatisticsMetricList, which defines how "An index of StatisticsMetricList, which defines how
to collect data and get the statistice value"; to collect data and get the statistics value";
} }
leaf StatisticsValue{ leaf StatisticsValue{
type uint16; type uint16;
config false; config false;
description description
"updated by 6top according to the statistics methed "updated by 6top according to the statistics method
specified by StatisticsMetricsID"; specified by StatisticsMetricsID";
} }
} }
} }
} }
list SlotframeList { list SlotframeList {
key "SlotframeID"; key "SlotframeID";
description description
"List of all of the slotframes used by the node."; "List of all of the slotframes used by the node.";
skipping to change at page 13, line 16 skipping to change at page 13, line 16
leaf NQoS { leaf NQoS {
type uint16; type uint16;
config false; config false;
description description
"Real QoS without over provisioned cells, i.e. the actual "Real QoS without over provisioned cells, i.e. the actual
bandwidth without taking into account the overprovisioned bandwidth without taking into account the overprovisioned
cells."; cells.";
} }
} }
list StatisticsMetricsList { list StatisticsMetricsList {
key "StatisticsMetricsID"; key "StatisticsMetricsID";
description description
"List of Statistics Metrics used in the node."; "List of Statistics Metrics used in the node. Statistics can be set and queried.";
leaf StatisticsMetricsID { leaf StatisticsMetricsID {
type uint16; type uint16;
} }
leaf SlotframeID { leaf SlotframeID {
type uint16; type uint16;
description description
"SlotframeID, one in SlotframeList, specifies the slotframe to "SlotframeID, one in SlotframeList, specifies the slotframe to
which the statistics metrics applies to. If empty, applies to which the statistics metrics applies to. If empty, applies to
all slotframes"; all slotframes";
reference reference
"IEEE802154e"; "IEEE802154e";
} }
leaf SlotOffset { leaf SlotOffset {
type uint16; type uint16;
description description
"Specific slotOffset to which the statistics metrics applies "Specific slotOffset to which the statistics metrics applies
to. If empty, applies to all timeslots"; to. If empty, applies to all timeslots";
reference reference
"IEEE802154e"; "IEEE802154e";
} }
leaf ChannelOffset { leaf ChannelOffset {
type uint8; type uint8;
description description
"Specific channelOffset to which the statistics metrics applies "Specific channelOffset to which the statistics metrics applies
to. If empty, applies to all channels"; to. If empty, applies to all channels";
reference reference
"IEEE802154e"; "IEEE802154e";
} }
leaf TargetNodeAddress { leaf TargetNodeAddress {
type uint64; type uint64;
description description
"Specific neighbor nodes to which the statistics metrics "Specific neighbor nodes to which the statistics metrics
applies to. If empty, applies to all neighbor nodes."; applies to. If empty, applies to all neighbor nodes.";
} }
leaf Metrics { leaf Metrics {
type enumeration { type enumeration {
enum PDR; enum macCounterOctets
enum ETX; enum macRetryCount
enum RSSI; enum macMultipleRetryCount
enum LQI; enum macTXFailCount
} enum macTXSuccessCount
description enum macFCSErrorCount
"The metric to be monitored."; enum macSecurityFailure
} enum macDuplicateFrameCount
leaf Window { enum macRXSuccessCount
type uint16; enum macNACKcount
description enum PDR;
"measurement period, in Number of the slotframe size"; enum ETX;
enum RSSI;
enum LQI;
} }
leaf Enable { description
type enumeration { "The metric to be monitored. Include those provided by underlying IEEE 802.15.4e TSCH -- see table 4i (2012). PDR,ETX,RSSI,LQI are maintained by 6top. ";
enum DISABLE; }
enum ENABLE; leaf Window {
} type uint16;
description description
"indicates the StatisticsMetric is active or not"; "measurement period, in Number of the slotframes. If not specified the metrics are updated continuously in time. If a period is specified the metric values are given for the specified time-window";
}
leaf Enable {
type enumeration {
enum DISABLE;
enum ENABLE;
} }
description
"indicates the StatisticsMetric is active or not";
} }
}
list EBList { list EBList {
key "EbID"; key "EbID";
description description
"List of information related with the EBs used by the node"; "List of information related with the EBs used by the node";
leaf EbID { leaf EbID {
type uint8; type uint8;
} }
leaf CellID { leaf CellID {
type uint16; type uint16;
description description
"CellID, one in CellList, indicates the cell used to send "CellID, one in CellList, indicates the cell used to send
EB"; EB";
} }
leaf Peroid { leaf SlotframeId{
type uint8;
description
"SlotframeID, one in SlotframeList, indicates the
slotframe to which the EB is send";
}
leaf Period {
type uint16; type uint16;
description description
"The EBs period, in seconds, indicates the interval between "The EBs period, in seconds, indicates the interval between
two EB sendings"; two EB sends";
} }
leaf Expiration { leaf Expiration {
type enumeration { type enumeration {
enum NEVERSTOP; enum NEVERSTOP;
enum EXPIRATION; enum EXPIRATION;
} }
description description
"NEVERSTOP- the period of the EB never stops; EXPIRATION- "NEVERSTOP- the period of the EB never stops; EXPIRATION-
when the Period arrives, the EB will stop."; when the Period arrives, the EB will stop.";
} }
skipping to change at page 24, line 40 skipping to change at page 24, line 40
CellList"; CellList";
} }
leaf ChunkCellStatus { leaf ChunkCellStatus {
type enumeration { type enumeration {
enum UNSCHEDULED; enum UNSCHEDULED;
enum SCHEDULED; enum SCHEDULED;
} }
} }
} }
3.2. YANG model of the IEEE802.15.4 PIB 4.2. YANG model of the IEEE802.15.4 PIB
This section describes the YANG model of the part of PIB This section describes the YANG model of the part of PIB
([IEEE802154] and [IEEE802154e]) used by 6top, such as security ([IEEE802154] and [IEEE802154e]) used by 6top, such as security
related attributes, TSCH related attributes. This part of data will related attributes, TSCH related attributes. This part of data will
be accessed through the MLME-GET and MLME-SET primitive [IEEE802154] be accessed through the MLME-GET and MLME-SET primitive [IEEE802154]
directly, instead of using 6top comannds. directly, instead of using 6top comannds.
TODO the security related attributes will be added after 6TiSCH WG TODO the security related attributes will be added after 6TiSCH WG
has consensus on the security scheme of 6top has consensus on the security scheme of 6top
skipping to change at page 29, line 25 skipping to change at page 29, line 25
} }
leaf macCurrentHop { leaf macCurrentHop {
type uint16; type uint16;
config false; config false;
description description
"Index of the current position in the hopping sequence "Index of the current position in the hopping sequence
list."; list.";
} }
} }
4. Commands 5. Commands
6top provides a set of commands as the interface with the higher 6top provides a set of commands as the interface with the higher
layer. Most of these commands are related to the management of layer. Most of these commands are related to the management of
slotframes, cells and scheduling information. 6top also provides an slotframes, cells and scheduling information. 6top also provides an
interface allowing an upper layer to retrieve status information and interface allowing an upper layer to retrieve status information and
statistics. The command set aims to facilitate 6top implementation statistics. The command set aims to facilitate 6top implementation
by describing the main operations that higher layers may use to by describing the main operations that higher layers may use to
interact with 6top. The listed commands aim at providing semantics interact with 6top. The listed commands aim at providing semantics
to manipulate 6top MIB, IEEE802.15.4 PIB and IEEE802.15.4e PIB to manipulate 6top MIB, IEEE802.15.4 PIB and IEEE802.15.4e PIB
programmatically. programmatically.
CREATE.hardcell: Creates one or more hard cells in the schedule. CREATE.hardcell: Creates one or more hard cells in the schedule.
Fails if the cell already exists. A cell is uniquely identified Fails if the cell already exists. A cell is uniquely identified
by the tuple (slotframe ID, slotOffset, channelOffset). 6top by the tuple (slotframe ID, slotOffset, channelOffset). 6top
schedules the cell and marks it as a hard cell, indicating that it schedules the cell and marks it as a hard cell, indicating that it
cannot reschedule this cell. The return value is CellID and the cannot reschedule this cell. The return value is CellID and the
created cell is also filled in CellList(Section 3.1). created cell is also filled in CellList(Section 4.1).
CREATE.softcell: To create soft cell(s). 6top is responsible for CREATE.softcell: To create soft cell(s). 6top is responsible for
picking the exact slotOffset and channelOffset in the schedule, picking the exact slotOffset and channelOffset in the schedule,
and ensure that the target node chooses the same cell and TrackID. and ensure that the target node chooses the same cell and TrackID.
6top marks these cells as soft cell, indicating that it will 6top marks these cells as soft cell, indicating that it will
continuously monitor their performance and reschedule if needed. continuously monitor their performance and reschedule if needed.
The return value is CellID, and the created cell is also filled in The return value is CellID, and the created cell is also filled in
CellList (Section 3.1). CellList (Section 4.1).
READ.cell: Given a (slotframe ID, slotOffset, channelOffset), READ.cell: Given a (slotframe ID, slotOffset, channelOffset),
retrieves the cell information. A read command can be issued for retrieves the cell information. A read command can be issued for
any cell, hard or soft. 6top gets cell information from CellList any cell, hard or soft. 6top gets cell information from CellList
(Section 3.1). (Section 4.1).
UPDATE.cell: Update a hard cell, i.e., re-allocate it to a UPDATE.cell: Update a hard cell, i.e., re-allocate it to a
different slotOffset and/or channelOffset. Fails if the cell does different slotOffset and/or channelOffset. Fails if the cell does
not exist. CellList (Section 3.1) will be modified. not exist. CellList (Section 4.1) will be modified.
DELETE.hardcell: To remove a hard cell. This removes the hard DELETE.hardcell: To remove a hard cell. This removes the hard
cell from the node's schedule, from CellList (Section 3.1). cell from the node's schedule, from CellList (Section 4.1).
DELETE.softcell: To remove a (number of) soft cell(s). This DELETE.softcell: To remove a (number of) soft cell(s). This
command leads the pair of nodes figure out the specific cell(s) to command leads the pair of nodes figure out the specific cell(s) to
be removed. After that, the cell(s) will be removed from the be removed. After that, the cell(s) will be removed from the
CellLists (Section 3.1) on both sides. CellLists (Section 4.1) on both sides.
REALLOCATE.softcell: To force a re-allocation of a soft cell. The REALLOCATE.softcell: To force a re-allocation of a soft cell. The
reallocated cell will be installed in a different slotOffset, reallocated cell will be installed in a different slotOffset,
channelOffset but slotframe and TrackID remain the same. Hard channelOffset but slotframe and TrackID remain the same. Hard
cells MUST NOT be reallocated. This command will result in the cells MUST NOT be reallocated. This command will result in the
modificaition of CellLists (Section 3.1) on both sides. modificaition of CellLists (Section 4.1) on both sides.
CREATE.slotframe: Creates a new slotframe. Adds a entry to the CREATE.slotframe: Creates a new slotframe. Adds a entry to the
SlotframeList (Section 3.1). SlotframeList (Section 4.1).
READ.slotframe: Returns the information of a slotframe given its READ.slotframe: Returns the information of a slotframe given its
slotframeID from SlotframeList (Section 3.1). slotframeID from SlotframeList (Section 4.1).
UPDATE.slotframe: Change the number of timeslots in a slotframe UPDATE.slotframe: Change the number of timeslots in a slotframe
given its slotframeID in SlotframeList (Section 3.1). given its slotframeID in SlotframeList (Section 4.1).
DELETE.slotframe: Deletes a slotframe, remove it from DELETE.slotframe: Deletes a slotframe, remove it from
SlotframeList (Section 3.1). SlotframeList (Section 4.1).
CONFIGURE.monitoring: Configures the level of QoS the Monitoring CONFIGURE.monitoring: Configures the level of QoS the Monitoring
process MUST enforce, i.e. config MonitoringStatusList process MUST enforce, i.e. config MonitoringStatusList
(Section 3.1). (Section 4.1).
READ.monitoring: Reads the current Monitoring status from READ.monitoring: Reads the current Monitoring status from
MonitoringStatusList (Section 3.1). MonitoringStatusList (Section 4.1).
CONFIGURE.statistics: Configures the statistics process in CONFIGURE.statistics: Configures the statistics process in
StatisticsMetricsList(Section 3.1). The CONFIGURE.statistics StatisticsMetricsList(Section 4.1). The CONFIGURE.statistics
enables flexible configuration and supports empty parameters that enables flexible configuration and supports empty parameters that
will force 6top to conduct statistics on all members of that will force 6top to conduct statistics on all members of that
dimension. For example, if ChannelOffset is empty and metric is dimension. For example, if ChannelOffset is empty and metric is
set as PDR, then, 6top will conduct the statistics of PDR on all set as PDR, then, 6top will conduct the statistics of PDR on all
of channels. of channels.
READ.statistics: Reads a metric for the specified dimension. READ.statistics: Reads a metric for the specified dimension.
Information is aggregated according to the parameters from Information is aggregated according to the parameters from
CellList (Section 3.1). CellList (Section 4.1).
RESET.statistics: Resets the gathered statistics in CellList RESET.statistics: Resets the gathered statistics in CellList
(Section 3.1). (Section 4.1).
CONFIGURE.eb: Configures EBs, i.e. configures EBlist CONFIGURE.eb: Configures EBs, i.e. configures EBlist
(Section 3.1). (Section 4.1).
READ.eb: Reads the EBs configuration from EBList (Section 3.1). READ.eb: Reads the EBs configuration from EBList (Section 4.1).
CONFIGURE.timesource: Configures the Time Source Neighbor CONFIGURE.timesource: Configures the Time Source Neighbor
selection process, i.e. configure TimeSource (Section 3.1). selection process, i.e. configure TimeSource (Section 4.1).
READ.timesource: Retrieves information about the time source READ.timesource: Retrieves information about the time source
neighbors of that node from TimeSource (Section 3.1). neighbors of that node from TimeSource (Section 4.1).
CREATE.neighbor: Creates an entry for a neighbor in the neighbor CREATE.neighbor: Creates an entry for a neighbor in the neighbor
table, i.e. NeighborList (Section 3.1). table, i.e. NeighborList (Section 4.1).
READ.all.neighbor: Returns the list of neighbors of that node READ.all.neighbor: Returns the list of neighbors of that node
according to NeighborList (Section 3.1). according to NeighborList (Section 4.1).
READ.neighbor: Returns the information of a specific neighbor of READ.neighbor: Returns the information of a specific neighbor of
that node specified by its neighbor address according to that node specified by its neighbor address according to
NeighborList (Section 3.1). NeighborList (Section 4.1).
UPDATE.neighbor: Updates the last status for a given UPDATE.neighbor: Updates the last status for a given
TargetNodeAddress in the NeighborList (Section 3.1). TargetNodeAddress in the NeighborList (Section 4.1).
DELETE.neighbor: Deletes a neighbor given its address from DELETE.neighbor: Deletes a neighbor given its address from
NeighborList (Section 3.1). NeighborList (Section 4.1).
CREATE.queue: Creates and Configures a queue in QueueList CREATE.queue: Creates and Configures a queue in QueueList
(Section 3.1). (Section 4.1).
READ.queue: Reads the queue configuration for given QueueId from READ.queue: Reads the queue configuration for given QueueId from
QueueList (Section 3.1). QueueList (Section 4.1).
READ.queue.stats: For a given QueueId, reads the queue statistics READ.queue.stats: For a given QueueId, reads the queue statistics
information from the QueueList (Section 3.1). information from the QueueList (Section 4.1).
UPDATE.queue: For a given QueueId, update its configuration in the UPDATE.queue: For a given QueueId, update its configuration in the
QueueList (Section 3.1). QueueList (Section 4.1).
DELETE.queue: Deletes a Queue for a given QueueId from the DELETE.queue: Deletes a Queue for a given QueueId from the
QueueList (Section 3.1). QueueList (Section 4.1).
LabelSwitching.map: Maps an input cell or a bundle of input cells LabelSwitching.map: Maps an input cell or a bundle of input cells
to an output cell or a bundle of output cells, i.e. adds a entry to an output cell or a bundle of output cells, i.e. adds a entry
to the LabelSwitchList (Section 3.1). to the LabelSwitchList (Section 4.1).
LabelSwitching.unmap: Unmap one input cell or a bundle of input LabelSwitching.unmap: Unmap one input cell or a bundle of input
cells to an output cell or a bundle of output cells, i.e. modifies cells to an output cell or a bundle of output cells, i.e. modifies
the LabelSwitchList (Section 3.1). the LabelSwitchList (Section 4.1).
CREATE.chunk: Creates a chunk which consists of one or more CREATE.chunk: Creates a chunk which consists of one or more
unscheduled cells, i.e. add an entry to the ChunkList unscheduled cells, i.e. add an entry to the ChunkList
(Section 3.1). (Section 4.1).
READ.chunk: Returns the information of a chunk given its ChunkID READ.chunk: Returns the information of a chunk given its ChunkID
from ChunkList (Section 3.1). from ChunkList (Section 4.1).
DELETE.chunk: For given ChunkId, removes a chunk from the DELETE.chunk: For given ChunkId, removes a chunk from the
ChunkList (Section 3.1), which also causes all of the scheduled ChunkList (Section 4.1), which also causes all of the scheduled
cells in the chunk to be deleted from the TSCH schedule and cells in the chunk to be deleted from the TSCH schedule and
CellList (Section 3.1). CellList (Section 4.1).
CREATE.hardcell.fromchunk: Creates one or more hard cells from a CREATE.hardcell.fromchunk: Creates one or more hard cells from a
chunk. 6top schedules the cell and marks it as a hard cell, chunk. 6top schedules the cell and marks it as a hard cell,
indicating that it cannot reschedule this cell. The cell will be indicating that it cannot reschedule this cell. The cell will be
added into the CellList (Section 3.1). In addition, 6top will added into the CellList (Section 4.1). In addition, 6top will
change the attributes corresponding to the cell in the change the attributes corresponding to the cell in the
ChunkCellList (Section 3.1), i.e. its CellID is changed to the ChunkCellList (Section 4.1), i.e. its CellID is changed to the
same CellID in the CellList, and its Status is changed to same CellID in the CellList, and its Status is changed to
SCHEDULED. SCHEDULED.
READ.chunkcell: Returns the information of all cells in a chunk READ.chunkcell: Returns the information of all cells in a chunk
given its ChunkID from ChunkCellList (Section 3.1). given its ChunkID from ChunkCellList (Section 4.1).
DELETE.hardcell.fromchunk: To remove a hard cell which comes from DELETE.hardcell.fromchunk: To remove a hard cell which comes from
a chunk. This removes the hard cell from the node's schedule and a chunk. This removes the hard cell from the node's schedule and
CellList (Section 3.1). In addition, it changes the attributes CellList (Section 4.1). In addition, it changes the attributes
corresponding to the cell in the ChunkCellList (Section 3.1), i.e. corresponding to the cell in the ChunkCellList (Section 4.1), i.e.
its CellID is changed back to 0xFFFF, and its Status is changed to its CellID is changed back to 0xFFFF, and its Status is changed to
UNSCHEDULED. UNSCHEDULED.
5. References 6. References
5.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
5.2. Informative References 6.2. Informative References
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020, Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010. October 2010.
[I-D.ietf-6tisch-tsch] [I-D.ietf-6tisch-tsch]
Watteyne, T., Palattella, M., and L. Grieco, "Using Watteyne, T., Palattella, M., and L. Grieco, "Using
IEEE802.15.4e TSCH in an LLN context: Overview, Problem IEEE802.15.4e TSCH in an IoT context: Overview, Problem
Statement and Goals", draft-ietf-6tisch-tsch-00 (work in Statement and Goals", draft-ietf-6tisch-tsch-02 (work in
progress), November 2013. progress), October 2014.
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., Watteyne, T., and R. Assimiti, "An Thubert, P., Watteyne, T., and R. Assimiti, "An
Architecture for IPv6 over the TSCH mode of IEEE Architecture for IPv6 over the TSCH mode of IEEE
802.15.4e", draft-ietf-6tisch-architecture-02 (work in 802.15.4e", draft-ietf-6tisch-architecture-03 (work in
progress), June 2014. progress), July 2014.
[I-D.ietf-6tisch-terminology] [I-D.ietf-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terminology in IPv6 over the TSCH mode of IEEE "Terminology in IPv6 over the TSCH mode of IEEE
802.15.4e", draft-ietf-6tisch-terminology-01 (work in 802.15.4e", draft-ietf-6tisch-terminology-02 (work in
progress), February 2014. progress), July 2014.
[I-D.ietf-6tisch-minimal] [I-D.ietf-6tisch-minimal]
Vilajosana, X. and K. Pister, "Minimal 6TiSCH Vilajosana, X. and K. Pister, "Minimal 6TiSCH
Configuration", draft-ietf-6tisch-minimal-01 (work in Configuration", draft-ietf-6tisch-minimal-03 (work in
progress), June 2014. progress), October 2014.
[I-D.ietf-6tisch-6top-interface]
Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH
Operation Sublayer (6top) Interface", draft-ietf-6tisch-
6top-interface-00 (work in progress), March 2014.
[I-D.wang-6tisch-6top-sublayer] [I-D.wang-6tisch-6top-sublayer]
Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH
Operation Sublayer (6top)", draft-wang-6tisch-6top- Operation Sublayer (6top)", draft-wang-6tisch-6top-
sublayer-00 (work in progress), February 2014. sublayer-01 (work in progress), July 2014.
[I-D.ietf-6tisch-coap] [I-D.ietf-6tisch-coap]
Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and
Interaction using CoAP", draft-ietf-6tisch-coap-00 (work Interaction using CoAP", draft-ietf-6tisch-coap-01 (work
in progress), May 2014. in progress), July 2014.
5.3. External Informative References 6.3. External Informative References
[IEEE802154e] [IEEE802154e]
IEEE standard for Information Technology, "IEEE std. IEEE standard for Information Technology, "IEEE std.
802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area
Networks (LR-WPANs) Amendment 1: MAC sublayer", April Networks (LR-WPANs) Amendment 1: MAC sublayer", April
2012. 2012.
[IEEE802154] [IEEE802154]
IEEE standard for Information Technology, "IEEE std. IEEE standard for Information Technology, "IEEE std.
802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
 End of changes. 81 change blocks. 
167 lines changed or deleted 180 lines changed or added

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