6TiSCH Q. Wang, Ed.
Internet-Draft Univ. of Sci. and Tech. Beijing
Intended status: Informational X. Vilajosana
Expires: August 4, 2014 Universitat Oberta de Catalunya
T. Watteyne
Linear Technology
January 31, 2014
6TiSCH Operation Sublayer (6top) Interface
draft-wang-6tisch-6top-interface-00
Abstract
The recently published [IEEE802154e] standard formalizes the concept
of link-layer resources in LLNs. Nodes are synchronized and follow a
schedule. A cell in that schedule corresponds to an atomic link-
layer resource, and can be allocated to any pair of neighbors in the
network. This allows the schedule to be built to tightly match each
node's bandwidth, latency and energy constraints. The [IEEE802154e]
standard does not, however, present a mechanism to do so, as building
and managing the schedule is out of scope of the standard. This
document describes the 6TiSCH Operation Sublayer (6top) and the
commands it provides to upper network layers such as RPL or GMPLS.
The set of functionalities includes feedback metrics from cell states
so network layers can take routing decisions, TSCH configuration and
control procedures, and the support for decentralized and centralized
scheduling. In addition, 6top can be configured to enable packet
switching at layer 2.5, analogous to GMPLS.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 4, 2014.
Wang, et al. Expires August 4, 2014 [Page 1]
Internet-Draft 6tisch-6top-interface January 2014
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. 6TiSCH Operation Sublayer (6top) Overview . . . . . . . . . . 4
3. 6top Commands . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Cell Model . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. hard cells . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. soft cells . . . . . . . . . . . . . . . . . . . . . 7
3.2. Data Transfer Model . . . . . . . . . . . . . . . . . . . 7
3.3. Commands . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1. Cell Commands . . . . . . . . . . . . . . . . . . . . 11
3.3.2. Slotframe Commands . . . . . . . . . . . . . . . . . 17
3.3.3. Monitoring Commands . . . . . . . . . . . . . . . . . 20
3.3.4. Statistics Commands . . . . . . . . . . . . . . . . . 21
3.3.5. Network Formation Commands . . . . . . . . . . . . . 22
3.3.6. Time Source Neighbor Commands . . . . . . . . . . . . 24
3.3.7. Neighbor Commands . . . . . . . . . . . . . . . . . . 24
3.3.8. Queueing Commands . . . . . . . . . . . . . . . . . . 26
3.3.9. Data Commands . . . . . . . . . . . . . . . . . . . . 28
3.3.10. Label Switching Commands . . . . . . . . . . . . . . 29
3.3.11. Chunk Command . . . . . . . . . . . . . . . . . . . . 30
3.3.12. Chunk Cell Command . . . . . . . . . . . . . . . . . 30
4. Generic Data Model . . . . . . . . . . . . . . . . . . . . . 32
4.1. YANG model of 6top MIB . . . . . . . . . . . . . . . . . 32
4.2. YANG model of IEEE802.15.4 PIB . . . . . . . . . . . . . 47
4.3. YANG model of IEEE802.15.4e PIB . . . . . . . . . . . . . 47
5. Using 6top . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1. RPL on 6top . . . . . . . . . . . . . . . . . . . . . . . 47
5.1.1. Support to Neighbor Discovery and Parent Selection . 47
5.1.2. Support of Rank Computation . . . . . . . . . . . . . 48
5.1.3. Support of Control Messages Broadcast . . . . . . . . 49
5.1.4. Support for QoS . . . . . . . . . . . . . . . . . . . 50
5.2. GMPLS on 6top . . . . . . . . . . . . . . . . . . . . . . 51
Wang, et al. Expires August 4, 2014 [Page 2]
Internet-Draft 6tisch-6top-interface January 2014
5.2.1. Cell Reservation Support for GMPLS on 6top . . . . . 51
5.2.2. Supporting QoS . . . . . . . . . . . . . . . . . . . 52
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.1. Normative References . . . . . . . . . . . . . . . . . . 52
6.2. Informative References . . . . . . . . . . . . . . . . . 52
6.3. External Informative References . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
1. Introduction
As presented in [I-D.watteyne-6tsch-tsch-lln-context], the
[IEEE802154e] standard defines the mechanisms for a TSCH node to
communicate, given a schedule. It does not, however, define the
mechanism to build and maintain the TSCH schedule, match that
schedule to the multi-hop paths maintained by a network layer such as
RPL or a 2.5 layer such as GMPLS, adapt the resources allocated
between neighbor nodes to the data traffic flows, enforce a
differentiated treatment for data generated at the application layer
and signalling messages needed by 6LoWPAN and RPL to discover
neighbors, react to topology changes, self-configure IP addresses, or
manage keying material.
In a TSCH network, the MAC layer is not in charge of setting up the
schedule that controls the connectivity graph of the network and the
resources allocated to each cell in that topology. This
responsibility is left to an upper layer, defined in this document
and called "6top".
This document describes the 6TiSCH Operation Sublayer (6top) and the
main commands provided to upper network layers such as RPL or GMPLS.
The set of functionalities include feedback metrics from cell state
so the network layer can take routing decisions, TSCH configuration
and control procedures, and support for the different scheduling
mechanisms defined in [I-D.thubert-6tisch-architecture]. 6top
addresses the set of functionalities described in
[I-D.watteyne-6tsch-tsch-lln-context].
For example, network formation in a TSCH network is handled by the
use of Enhanced Beacons (EB). EBs include information for joining
nodes to be able to synchronize and set up an initial network
topology. However, [IEEE802154e] does not specify how the period of
EBs is configured, nor the rules for a node to select a particular
node to join. 6top offers a set of commands so control mechanisms can
be introduced on top of TSCH to configure nodes to join a specific
node and obtain a unique 16-bit identifier from the network. Once a
network is formed, 6top maintains the network's health, allowing for
nodes to stay synchronized. It supplies mechanisms to manage each
node's time source neighbor and configure the EB interval. Network
Wang, et al. Expires August 4, 2014 [Page 3]
Internet-Draft 6tisch-6top-interface January 2014
layers running on top of 6top take advantage of the TSCH MAC layer
information so routing metrics, topological information, energy
consumption and latency requirements can be adjusted to TSCH, and
adapted to application requirements.
TSCH requires a mechanism to manage its schedule; 6top provides a set
of commands for upper layers to set up specific schedules, either
explicitly by detailing specific cell information, or by allowing
6top to establish a schedule given a bandwidth or latency
requirement. 6top is designed to enable decentralized, centralized or
hybrid scheduling solutions. 6top enables internal TSCH queuing
configuration, size of buffers, packet priorities, transmission
failure behavior, and defines mechanisms to encrypt and authenticate
MAC slotframes.
As described in [label-switching-154e], due to the slotted nature of
a TSCH 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 is not needed at each packet; the input cell (or bundle) and
the output cell (or bundle) uniquely identify the data flow. The
6top sublayer provides operations to manage the cell mappings.
2. 6TiSCH Operation Sublayer (6top) Overview
6top is a sublayer which is the next-higher layer for TSCH
(Figure 1), as detailed in [I-D.thubert-6tisch-architecture]. 6top
offers both management and data interfaces to an upper layer. It
includes monitoring and statistics collection, both of which are
configurable through the management interface.
Wang, et al. Expires August 4, 2014 [Page 4]
Internet-Draft 6tisch-6top-interface January 2014
Protocol Stack
+-----------------------------------+
| PCEP | CoAP | | 6LoWPAN | |
| PCC | DTLS | PANA | ND |RPL |
+------------------------------------------+
| TCP | UDP | ICMP | RSVP |
+------------------------------------------+
| IPv6 |
+------------------------------------------+
| 6LoWPAN HC |
+------------------------------------------+
| 6top |
+------------------------------------------+
| IEEE802.15.4e TSCH |
+------------------------------------------+
| IEEE802.15.4 |
+------------------------------------------+
Figure 1
6top distinguishes between hard cells and soft cells. It therefore
requires an extra flag to all cells in the TSCH schedule, as detailed
in Section 3.1.
When a higher layer gives 6top a 6LoWPAN packet for transmission,
6top maps it to the appropriate outgoing priority-based queue, as
detailed in Section 3.2.
All commands of the management and data interfaces are detailed in
Section 3.3. This set of commands is designed to support
decentralized, centralized and hybrid scheduling solutions.
YANG is used to express 6top data model, detailed in Section 4.
3. 6top Commands
3.1. Cell Model
[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
Timekeeping cell. These options are not exclusive, as a cell can be
qualified with more than one of them. The MLME-SET-LINK.request
command defined in [IEEE802154e] uses a linkOptions bitmap to specify
the options of a cell. Acceptable values are:
b0 = Transmit
Wang, et al. Expires August 4, 2014 [Page 5]
Internet-Draft 6tisch-6top-interface January 2014
b1 = Receive
b2 = Shared
b3 = Timekeeping
b4-b7 = Reserved
Only Transmit cells can also be marked as Shared cells. When the
shared bit is set, a back-off procedure is applied to handle
collisions. Shared behavior does not apply to Receive cells.
6top allows an upper layer to schedule a cell at a specific
slotOffset and channelOffset, in a specific slotframe.
In addition, 6top allows an upper layer to schedule a certain amount
of bandwidth to a neighbor, without having to specify the exact
slotOffset(s) and channelOffset(s). Once bandwidth is reserved, 6top
is in charge of ensuring that this requirement is continuously
satisfied. 6top dynamically reallocates cells if needed, and over-
provisions if required.
6top allows an upper layer to associate a cell with a specific track
by using a TrackID. A TrackID is a tuple
(TrackOwnerAddr,InstanceID), where TrackOwnerAddr is the address of
the node which initializes the process of creating the track, i.e.,
the owner of the track; and InstanceID is an instance identifier
given by the owner of the track. InstanceID comes from upper layer;
InstanceID could for example be the local instance ID defined in RPL.
If the TrackID is set to (0,0), the cell can be used by the best-
effort QoS configuration or as a Shared cell. If the TrackID is not
set to (0,0), i.e., the cell belongs to a specific track, the cell
MUST not be set as Shared cell.
6top allows an upper layer ask a node manage a a portion of a
slotframe, which is named as chunk. Chunks can be delegated
explicitly by the PCE to a node, or claimed automatically by any node
that participates to the distributed cell scheduling process. The
resource in a chunk can be appropriated by the node, i.e. the owner
of the chunk.
Given this mechanism, 6top defines hard cells (which have been
requested specifically) and soft cells (which can be reallocated
dynamically). The hard/soft flag is introduced by the 6top sublayer
named as CellType, 0: soft cell, 1: hard cell. This option is
mandatory; all cells are either hard or soft.
Wang, et al. Expires August 4, 2014 [Page 6]
Internet-Draft 6tisch-6top-interface January 2014
3.1.1. hard cells
A hard cell is a cell that cannot be dynamically reallocated by 6top.
A hard cell is uniquely identified by the following tuple:
slotframe ID: ID of the slotframe this cell is part of.
slotOffset: the slotOffset for the cell.
channelOffset: the channelOffset for the cell.
LinkOption bitmap: bitmap as defined in [IEEE802154].
CellType: MUST be set to 1.
3.1.2. soft cells
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
a specific bandwidth requirement. Soft cells are installed through
the soft cell negotiation procedure described in "draft-wang-6tisch-
6top-sublayer".
3.2. Data Transfer Model
Once a TSCH schedule is established, 6top is responsible for feeding
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
it to TSCH. Since 6top is a sublayer between TSCH and 6LoWPAN, the
properties associated with a packet/fragment from the upper layer
includes the next hop neighbor (DestAddr) and expected sending
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 schedule.
Wang, et al. Expires August 4, 2014 [Page 7]
Internet-Draft 6tisch-6top-interface January 2014
6top Data Transfer Model
|
| (DestAddr, Priority, Fragment)
|
+---------------------------------------+
| I-MUX |
+---------------------------------------+
| | | | .... |
| | | | |
+---+ +---+ +---+ +---+ +---+
| | | | | | | | | |
|Q1 | |Q2 | |Q3 | |Q4 | |Qn |
| | | | | | | | | |
+---+ +---+ +---+ +---+ +---+
| | | | |
| | | | |
+---------------------------------------+
| MUX |
+---------------------------------------+
|
|
+---+
|PDU|
+---+
|
| TSCH MAC-payload
|
Figure 2
In Figure 2, Qi represents a queue, which is either broadcast or
unicast, and is assigned a priority. The number of queues is
configurable. The relationship between queues and tracks is
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
tracks can be used.
When 6top receives a packet to transmit through a Send.data command
(Section 3.3.9), the I-MUX module selects a queue in which to insert
it. If the packet's destination address is a unicast (resp.
broadcast) address, it will be inserted into a unicast (resp.
broadcast) queue.
The MUX module is invoked at each scheduled transmit cell by TSCH.
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
Wang, et al. Expires August 4, 2014 [Page 8]
Internet-Draft 6tisch-6top-interface January 2014
to TSCH for transmission. If the next active cell is a broadcast
cell, it selects a fragment only from broadcast queues.
How the MUX module selects the best frame is configurable. The
following rules are a typical example:
The frame's layer 2 destination address MUST match the neighbor
address associated with the transmit cell.
If the transmit cell is associated with a specific track, the
frames in the queue corresponding to the TrackID have the
highest priority.
If the transmit cell is not associated with a specific track,
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.
Further rules can be configured to satisfy specific QoS requirements.
3.3. Commands
6top provides a set of commands as the interface with the higher
layer. Most of these commands are related to the management of
slotframes, cells and scheduling information. 6top also provides an
interface allowing an upper layer to retrieve status information and
statistics. This section describes the following commands provided
by 6top.
CREATE.hardcell: Section 3.3.1.1
CREATE.softcell: Section 3.3.1.2
READ.cell: Section 3.3.1.3
UPDATE.cell: Section 3.3.1.4
DELETE.hardcell: Section 3.3.1.5
DELETE.softcell: Section 3.3.1.6
REALLOCATE.softcell: Section 3.3.1.7
CREATE.slotframe: Section 3.3.2.1
READ.slotframe: Section 3.3.2.2
UPDATE.slotframe: Section 3.3.2.3
Wang, et al. Expires August 4, 2014 [Page 9]
Internet-Draft 6tisch-6top-interface January 2014
DELETE.slotframe: Section 3.3.2.4
CONFIGURE.monitoring: Section 3.3.3.1
READ.monitoring: Section 3.3.3.2
CONFIGURE.statistics: Section 3.3.4.1
READ.statistics: Section 3.3.4.2
RESET.statistics: Section 3.3.4.3
CONFIGURE.eb: Section 3.3.5.1
READ.eb: Section 3.3.5.2
CONFIGURE.timesource: Section 3.3.6.1
READ.timesource: Section 3.3.6.2
CREATE.neighbor: Section 3.3.7.1
READ.all.neighbor: Section 3.3.7.2
READ.neighbor: Section 3.3.7.3
UPDATE.neighbor: Section 3.3.7.4
DELETE.neighbor: Section 3.3.7.5
CREATE.queue: Section 3.3.8.1
READ.queue: Section 3.3.8.2
READ.queue.stats: Section 3.3.8.3
UPDATE.queue: Section 3.3.8.4
DELETE.queue: Section 3.3.8.5
Send.data: Section 3.3.9.1
Receive.data: Section 3.3.9.2
LabelSwitching.map: Section 3.3.10.1
LabelSwitching.unmap: Section 3.3.10.2
Wang, et al. Expires August 4, 2014 [Page 10]
Internet-Draft 6tisch-6top-interface January 2014
CREATE.chunk: Section 3.3.11.1
DELETE.chunk: Section 3.3.11.2
CREATE.hardcell.fromchunk: Section 3.3.12.1
DELETE.hardcell.fromchunk: Section 3.3.12.2
3.3.1. Cell Commands
6top provides the following commands to manage TSCH cells.
3.3.1.1. CREATE.hardcell
Creates one or more hard cells in the schedule. Fails if the cell
already exists. A cell is uniquely identified by the tuple
(slotframe ID, slotOffset, channelOffset).
To create a hard cell, the upper layer specifies:
slotframe ID: ID of the slotframe this timeslot will be
scheduled in.
slotOffset: the slotOffset for the cell.
channelOffset: channelOffset for the cell.
LinkOption bitmap: bitmap as defined in [IEEE802154e]
LinkType : as defined in section 6.2.19.3 of [IEEE802154e].
CellType: as defined in Section 3.1
target node address: the address of that node to communicate
with over this cell. In case of broadcast cells this is the
broadcast address.
TrackID: ID of the track the cell will belong to.
6top schedules the cell and marks it as a hard cell, indicating that
it cannot reschedule this cell. The return value is CellID and the
created cell is also filled in CellList (Section 4.1).
The interaction between 6top and MAC layer caused by CREATE.hardcell
is as follows.
Wang, et al. Expires August 4, 2014 [Page 11]
Internet-Draft 6tisch-6top-interface January 2014
Firstly, 6top calls the premitive MLME-SET-LINK.request defind in
section 6.2.19.3 of [IEEE802154e]. The premitive parameters are set
as follows.
+---------------------------------+---------------------------------+
| MLME-SET-LINK.request parameter | set by 6top |
+---------------------------------+---------------------------------+
| operation | ADD-LINK |
+---------------------------------+---------------------------------+
| LinkHandle | CellID |
+---------------------------------+---------------------------------+
| slotframeHandle | slotframe ID |
+---------------------------------+---------------------------------+
| timeslot | slotOffset |
+---------------------------------+---------------------------------+
| channelOffset | channelOffset |
+---------------------------------+---------------------------------+
| LinkOptions | LinkOption bitmap |
+---------------------------------+---------------------------------+
| LinkType | LinkType |
+---------------------------------+---------------------------------+
| nodeAddr | target node address |
+---------------------------------+---------------------------------+
Secondly, if the status from MLME-SET-LINK.confirm defined in section
6.2.19.4 of [IEEE802154e] is SUCCESS, then add the LinkHandle to the
BundleList specified by TrackID, and confirm to upper layer with
status = SUCCESS; otherwise, confirm to upper layer with status =
FAIL.
3.3.1.2. CREATE.softcell
To create soft cell(s), the upper layer specifies:
slotframe ID: ID of the slotframe the cell(s) will be scheduled
in
number of cells: the required number of soft cells.
LinkOption bitmap: bitmap as defined in [IEEE802154e]
CellType: as defined in Section 3.1
target node address: the address of the node to communicate
with over the cell(s). In case of broadcast cells this is the
broadcast address.
TrackID: ID of the track the cell(s) will belong to.
Wang, et al. Expires August 4, 2014 [Page 12]
Internet-Draft 6tisch-6top-interface January 2014
QoS level: the cell redundancy policy. The policy can be for
example STRICT, BEST_EFFORT, etc.
6top is responsible for picking the exact slotOffset and
channelOffset in the schedule, and ensure that the target node choose
the same cell and TrackID. 6top marks these cells as soft cell,
indicating that it will continuously monitor their performance and
reschedule if needed. The return value is CellID, and the created
cell is also filled in CellList (Section 4.1).
6top deals with the allocation process by negotiation with the target
node. The command returns the list of created cells defined by
(slotframe ID, slotOffset, channelOffset). It fails if the required
number of cells is higher than the available number of cells in the
schedule. It fails if the negotiation with the target node fails.
It fails if the LinkOption bitmap indicates that the cell(s) MUST be
Hard.
The interaction between 6top and TSCH happens on both sides described
as follows.
For example, after neigotiation, node A and node B find a specifical
cell, slotOffset=10, channelOffset=12, as a Tx cell and Rx cell,
respectively, then the 6top in node A and node B will call the
premitive MLME-SET-LINK.request defind in section 6.2.19.3 of
[IEEE802154e], respectively. The premitive parameters are set in
node A and node B as follows.
+---------------------------------+---------------------------------+
| MLME-SET-LINK.request parameter | set by A's 6top | set by B's top|
+---------------------------------+---------------------------------+
| operation | ADD-LINK | ADD-LINK |
+---------------------------------+---------------------------------+
| LinkHandle | CellID | CellID |
+---------------------------------+---------------------------------+
| slotframeHandle | slotframe ID | slotframe ID |
+---------------------------------+---------------------------------+
| timeslot | 10 | 10 |
+---------------------------------+---------------------------------+
| channelOffset | 12 | 12 |
+---------------------------------+---------------------------------+
| LinkOptions | Tx | Rx |
+---------------------------------+---------------------------------+
| LinkType | NORMAL | NORMAL |
+---------------------------------+---------------------------------+
| nodeAddr | Node A | Node B |
+---------------------------------+---------------------------------+
Wang, et al. Expires August 4, 2014 [Page 13]
Internet-Draft 6tisch-6top-interface January 2014
If the Status from MLME-SET-LINK.confirm defined in section 6.2.19.4
of [IEEE802154e], 6top will notify upper layer failure.
3.3.1.3. READ.cell
Given a (slotframe ID, slotOffset, channelOffset), retrieves the cell
information. Fails if the cell does not exist. The returned
information contains:
slotframe ID: ID of the slotframe where this cell is installed.
slotOffset: the slotOffset for the cell.
channelOffset: the selected channelOffset for the cell.
LinkOption bitmap: bitmap as defined in [IEEE802154e]
CellType: as defined in Section 3.1
target node address: the target address of that cell. In case
of broadcast cells this is the broadcast address.
TrackID: ID of the track the cell will belong to.
NumOfStatistics: Number of elements in the following list of
tuple (StatisticsMetriceID and StatisticsValue)
list of (StatisticsMetriceID, StatisticsValue):
StatisticsMetriceID is the index to Statistics Metric defined
in Section 3.3.4, StatisticsValue is the value corresponding to
the metric indexd by StatisticsMetriceID
A read command can be issued for any cell, hard or soft. 6top gets
cell information from CellList (Section 4.1).
3.3.1.4. UPDATE.cell
Update a hard cell, i.e., re-allocate it to a different slotOffset
and/or channelOffset. Fails if the cell does not exist. Requires
both old (slotframe ID, slotOffset, channelOffset) and new (slotframe
ID, slotOffset, channelOffset) as parameters. And, the type of cell,
target node address and TrackID are the fields that cannot be
updated. Soft cells MUST NOT be updated by the UPDATE.cell command.
REALLOCATE.softcell (Section 3.3.1.7) MUST be used instead.
It causes a old cell being removed and a new cell being created.
Wang, et al. Expires August 4, 2014 [Page 14]
Internet-Draft 6tisch-6top-interface January 2014
3.3.1.5. DELETE.hardcell
To remove a hard cell, the upper layer specifies:
slotframe ID: the ID of the slotframe where this cell is
installed.
slotOffset: the slotOffset for the cell.
channelOffset: the selected channelOffset for the cell.
LinkOption bitmap: bitmap as defined in [IEEE802154e]
LinkType : as defined in in section 6.2.19.3 of [IEEE802154e].
CellType: as defined in Section 3.1
target node address: the target address of that cell. In case
of broadcast cells this is the broadcast address.
TrackID: ID of the track the cell will belong to.
This removes the hard cell from the node's schedule, from CellList
(Section 4.1)as well.
The interaction between 6top and MAC layer caused by DELETE.hardcell
is as follows.
Firstly, 6top calls the premitive MLME-SET-LINK.request defind in
section 6.2.19.3 of [IEEE802154e]. The premitive parameters are set
as follows.
Wang, et al. Expires August 4, 2014 [Page 15]
Internet-Draft 6tisch-6top-interface January 2014
+---------------------------------+---------------------------------+
| MLME-SET-LINK.request parameter | set by 6top |
+---------------------------------+---------------------------------+
| operation | DELETE-LINK |
+---------------------------------+---------------------------------+
| LinkHandle | CellID |
+---------------------------------+---------------------------------+
| slotframeHandle | slotframe ID |
+---------------------------------+---------------------------------+
| timeslot | slotOffset |
+---------------------------------+---------------------------------+
| channelOffset | channelOffset |
+---------------------------------+---------------------------------+
| LinkOptions | LinkOption bitmap |
+---------------------------------+---------------------------------+
| LinkType | LinkType |
+---------------------------------+---------------------------------+
| nodeAddr | target node address |
+---------------------------------+---------------------------------+
Secondly, if the status from MLME-SET-LINK.confirm defined in section
6.2.19.4 of [IEEE802154e] is SUCCESS, then remove the LinkHandle from
its BundleList specified by TrackID, and confirm to upper layer with
status = SUCCESS; otherwise, confirm to upper layer with status =
FAIL.
3.3.1.6. DELETE.softcell
To remove a (number of) soft cell(s), the upper layer specifies:
slotframe ID: ID of the slotframe where this cell is installed.
number of cells: the number of cells to be removed
LinkOption bitmap: bitmap as defined in [IEEE802154e]
CellType: as defined in Section 3.1
target node address: the target address of that cell. In case
of broadcast cells this is the broadcast address.
TrackID: ID of the track the cell will belong to.
In the case a soft cell wants to be re-allocated from the allocated
cell so a hard cell can be installed instead, the REALLOCATE.softcell
(Section 3.3.1.7) MUST be used.
Wang, et al. Expires August 4, 2014 [Page 16]
Internet-Draft 6tisch-6top-interface January 2014
After the pair of nodes figure out the specific cell(s) to be
removed, the interaction between 6top and TSCH on both sides will be
similar to that caused by DELETE.hardcell, except LinkType should be
set to NORMAL.
3.3.1.7. REALLOCATE.softcell
To force a re-allocation of a soft cell, the upper layer specifies:
slotframe ID: ID of the slotframe where the cell is allocated.
slotOffset: the slotOffset for that cell.
channelOffset: the channelOffset for that cell.
The reallocated cell will be installed in a different slotOffset,
channelOffset but slotframe and TrackID remain the same. Hard cells
MUST NOT be reallocated.
The interaction between 6top and TSCH caused by this command includes
that described in Section 3.3.1.6 and Section 3.3.1.2.
3.3.2. Slotframe Commands
6top provides the following commands to manage TSCH slotframes.
3.3.2.1. CREATE.slotframe
Creates a new slotframe. The command requires:
slotframe ID: unique identifier of the slotframe, corresponding
to its priority.
number of timeslots: the required number of timeslots in the
slotframe.
Fails if the number of required timeslots is less than zero.
The interaction between 6top and MAC layer caused by CREATE.slotframe
is as follows.
Firstly, 6top calls the premitive MLME-SET-SLOTFRAME.request defind
in section 6.2.19.1 of [IEEE802154e]. The premitive parameters are
set as follows.
Wang, et al. Expires August 4, 2014 [Page 17]
Internet-Draft 6tisch-6top-interface January 2014
+---------------------------------+---------------------------------+
| MLME-SET-SLOTFRAME.request | |
| parameter | set by 6top |
+---------------------------------+---------------------------------+
| slotframeHandle | slotframe ID |
+---------------------------------+---------------------------------+
| operation | ADD |
+---------------------------------+---------------------------------+
| size | number of timeslot |
+---------------------------------+---------------------------------+
Secondly, if the status from MLME-SET-SLOTFRAME.confirm defined in
section 6.2.19.2 of [IEEE802154e] is SUCCESS, then confirms to upper
layer with status = SUCCESS; otherwise, confirm to upper layer with
status = FAIL.
3.3.2.2. READ.slotframe
Returns the information of a slotframe given its slotframe ID. The
command returns:
slotframe ID: ID of the slotframe. (SlotFrameHandle)
number of timeslots: the number of timeslots in the slotframe.
Fails if the slotframe ID does not exist.
TODO: access a specific slotframe with PIBAttribute of MLME-
GET.request
3.3.2.3. UPDATE.slotframe
Change the number of timeslots in a slotframe. The command requires:
slotframe ID: ID of the slotframe.
number of timeslots: the number of timeslots to be updated.
Fails if the number of required timeslots is less than zero. Fails
if the slotframe ID does not exist.
The interaction between 6top and MAC layer caused by UPDATE.slotframe
is as follows.
Firstly, 6top calls the premitive MLME-SET-SLOTFRAME.request defind
in section 6.2.19.1 of [IEEE802154e]. The premitive parameters are
set as follows.
Wang, et al. Expires August 4, 2014 [Page 18]
Internet-Draft 6tisch-6top-interface January 2014
+---------------------------------+---------------------------------+
| MLME-SET-SLOTFRAME.request | |
| parameter | set by 6top |
+---------------------------------+---------------------------------+
| slotframeHandle | slotframe ID |
+---------------------------------+---------------------------------+
| operation | MODIFY |
+---------------------------------+---------------------------------+
| size | number of timeslot |
+---------------------------------+---------------------------------+
Secondly, if the status from MLME-SET-SLOTFRAME.confirm defined in
section 6.2.19.2 of [IEEE802154e] is SUCCESS, then confirms to upper
layer with status = SUCCESS; otherwise, confirm to upper layer with
status = FAIL.
3.3.2.4. DELETE.slotframe
Deletes a slotframe. The command requires:
slotframe ID: ID of the slotframe.
number of timeslot: the number of timeslots in the slotframe.
Fails if the slotframe ID does not exist.
The interaction between 6top and MAC layer caused by DELETE.slotframe
is as follows.
Firstly, 6top calls the premitive MLME-SET-SLOTFRAME.request defind
in section 6.2.19.1 of [IEEE802154e]. The premitive parameters are
set as follows.
+---------------------------------+---------------------------------+
| MLME-SET-SLOTFRAME.request | |
| parameter | set by 6top |
+---------------------------------+---------------------------------+
| slotframeHandle | slotframe ID |
+---------------------------------+---------------------------------+
| operation | DELETE |
+---------------------------------+---------------------------------+
| size | number of timeslot |
+---------------------------------+---------------------------------+
Secondly, if the status from MLME-SET-SLOTFRAME.confirm defined in
section 6.2.19.2 of [IEEE802154e] is SUCCESS, then confirms to upper
layer with status = SUCCESS; otherwise, confirm to upper layer with
status = FAIL.
Wang, et al. Expires August 4, 2014 [Page 19]
Internet-Draft 6tisch-6top-interface January 2014
3.3.3. Monitoring Commands
Monitoring commands provide the means for upper layers to configure
whether 6top must ensure the required bandwidth. This procedure is
achieved through overprovisioning according to cell status feedback.
Monitoring is also in charge of reallocating soft cells that are
under the required QoS.
3.3.3.1. CONFIGURE.monitoring
Configures the level of QoS the Monitoring process MUST enforce. The
command requires:
slotframe ID: ID of the slotframe.
target node address: the target neighbor address.
enforce policy: The policy used to enforce the QoS
requirements. Can be for example DISABLE, BEST_EFFORT, STRICT,
OVER-PROVISION, etc.
Fails if the slotframe ID does not exist.
3.3.3.2. READ.monitoring.status
Reads the current Monitoring status. Requires the following
parameters.
slotframe ID: the ID of the slotframe.
target node address: the target neighbor address.
Returns the QoS levels for that Target node on that slotframe.
allocated_hard: Number of hard cells allocated.
allocated_soft: Number of soft cells allocated.
provisioned: the extra provisioned cells. 0 if CONFIGURE.qos
enforce is DISABLE.
QoS: the current QoS. Including overprovisioned cells, i.e
what bandwidth is being obtained including the overprovisioned
cells.
RQoS: the real QoS without provisioned cells. What is the
actual bandwidth without taking into account the
overprovisioned cells.
Wang, et al. Expires August 4, 2014 [Page 20]
Internet-Draft 6tisch-6top-interface January 2014
Fails if the slotframe ID does not exist.
3.3.4. Statistics Commands
6top keeps track of TSCH statistics for upper layers to adapt
correctly to medium changes. The exact metrics for statistics are
out of scope but the present commands SHOULD be used to configure and
read monitored information regardless of the specific metric.
3.3.4.1. CONFIGURE.statistics
Configures Statistics process. The command requires:
slotframe ID: ID of the slotframe. If empty monitors all
slotframe IDs
slotOffset: specific slotOffset to be monitored. If empty all
timeslots are monitored
channelOffset: specific channelOffset to be monitored. If
empty all channels are monitored.
target node address: the target neighbor address. If empty,
all neighbor nodes are monitored.
metric: metric to be monitored. This MAY be PDR, ETX, queuing
statistics, energy-related metrics, etc.)
window: time window to be considered for the calculations. If
0 all historical data is considered.
enable: Enables statistics or disables them.
Fails if the slotframe ID does not exist. The statistics service can
be configured to retrieve statistics at different levels. For
example to aggregate information by slotframe ID, or to retrieve
statistics for a particular timeslot, etc. The CONFIGURE.statistics
enables flexible configuration and supports empty parameters that
will force 6top to conduct statistics on all members of that
dimension. For example, if ChannelOffset is empty and metric is set
as PDR, then, 6top will conduct the statistics of PDR on all of
channels.
3.3.4.2. READ.statistics
Reads a metric for the specified dimension. Information is
aggregated according to the parameters. The command requires:
Wang, et al. Expires August 4, 2014 [Page 21]
Internet-Draft 6tisch-6top-interface January 2014
slotframe ID: ID of the slotframe. If empty aggregates
information of all slotframe IDs
slotOffset: the specific slotOffset for which the information
is required. If empty all timeslots are aggregated
channelOffset: the specific channelOffset for which the
information is required. If empty all channels are aggregated.
target node address: the target neighbor address. If empty all
neighbor addresses are aggregated.
metric: metric to be read.
Returns the value for the requested metric.
Fails if empty metric or metric does not exits.
3.3.4.3. RESET.statistics
Resets the gathered statistics. The command requires:
slotframe ID: ID of the slotframe. If empty resets the
information of all slotframe IDs
slotOffset: the specific slotOffset for which the information
wants to be reset. If empty statistics from all timeslots are
reset
channelOffset: the specific channelOffset for which the
information wants to be reset. If empty all statistics for all
channels are reset.
target node address: the target neighbor address. If empty all
neighbor addresses are aggregated.
metric: metric to be reset.
Fails if empty metric or metric does not exits.
3.3.5. Network Formation Commands
EBs need to be configured, including their transmission period, the
slotOffset and channelOffset that they SHOULD be sent on, and the
join priority they contain. The parameters for that command are
optional and enable flexible configuration of EBs. If slotframe ID
is specified, the EBs will be configured to use that specific
slotframe; if not, they will use the first slotframe where the
Wang, et al. Expires August 4, 2014 [Page 22]
Internet-Draft 6tisch-6top-interface January 2014
configured slotOffset is allocated. The slotOffset enforces the EB
to a specific timeslot. In case slotOffset parameter is not present,
the EB is sent in the first available transmit timeslot. In case
channelOffset parameter is not set, the EB is configured to use the
first available channel.
3.3.5.1. CONFIGURE.eb
Configures EBs. The command requires:
slotframe ID: ID of the slotframe where the EBs MUST be sent.
Zero if any slotframe can be used.
slotOffset: the slotOffset where the EBs MUST be sent. Zero if
any timeslot can be used.
channelOffset: the channelOffset where the EBs MUST be sent.
Zero if any channelOffset can be used.
period: the EBs period, in seconds.
Expiration: when the EBs periodicity will stop. If Zero the
period never stops.
priority: the joining priority model that will be used for
advertisement. Joining priority MAY be for example
SAME_AS_PARENT, RANDOM, BEST_PARENT+1 or DAGRANK(rank) as
decribed in in [I-D.vilajosana-6tisch-minimal].
Fails if the tuple (slotframe ID, slotOffset, channelOffset) is
already scheduled.
3.3.5.2. READ.eb
Reads the EBs configuration. No parameters are required.
Returns the current EBs configuration for that slotframe, which
contains:
slotframe ID: the slotframe where the EB is being sent.
slotOffset: the slotOffset where the EBs is being sent.
channelOffset: the channelOffset the EBs is being sent on.
period: the EBs period.
Wang, et al. Expires August 4, 2014 [Page 23]
Internet-Draft 6tisch-6top-interface January 2014
Expiration: when the EBs periodicity stops. If 0 the period
never stops.
priority: the joining priority that this node advertises.
Fails if the slotframe ID does not exist.
3.3.6. Time Source Neighbor Commands
Commands to select time source neighbors.
3.3.6.1. CONFIGURE.timesource
Configures the Time Source Neighbor selection process. More than one
time source neighbor can be selected. The command requires:
selection policy: The policy used to select the time source
neighbor. The policy MAY be for example ALL_PARENTS,
BEST_CONNECTED, LOWEST_JOIN_PRIORITY, etc.
Fails if any of the time source neighbors do not exist or it is not
reachable.
3.3.6.2. READ.timesource
Retrieves information about the time source neighbors of that node.
The command does not require any parameter.
Returns the following information for each of the time sources:
target node: address of the time source neighbor.
statistics: includes for example minimum, maximum, average time
correction for that time source neighbor
policy: the used policy
Fails if the slotframe ID or no time source neighbors exist.
3.3.7. Neighbor Commands
Commands to manage neighbor table. The commands SHOULD be used by
the upper layer to query the neighbor related information and by the
lower layer to keep track of neighbors information.
Wang, et al. Expires August 4, 2014 [Page 24]
Internet-Draft 6tisch-6top-interface January 2014
3.3.7.1. CREATE.neighbor
Creates an entry for a neighbor in the neighbor table.
neighbor address: The address of the neighbor.
neighbor stats: for example, RSSI of the last received packet
from that neighbor, ASN when that neighbor has been added, etc.
Returns whether the neighbor is created or not.
3.3.7.2. READ.all.neighbor
Returns the list of neighbors of that node. Fails if empty. For
each neighbor in the list it returns:
neighbor address: The address of the neighbor.
neighbor stats: for example, RSSI of the last received packet
from that neighbor, ASN when that neighbor has been added,
packets received from that neighbor, packets sent to it, etc.
3.3.7.3. READ.neighbor
Returns the information of a specific neighbor of that node specified
by its neighbor address. Fails if it does not exists. For that
neighbor it returns:
neighbor address: The address of the neighbor.
neighbor stats: for example, RSSI of the last received packet
from that neighbor, ASN when that neighbor has been added,
packets received from that neighbor, packets sent to it, etc.
3.3.7.4. UPDATE.neighbor
Updates an entry for a neighbor in the neighbor table. Fails if the
neighbor does not exist. Updates stats parameters. Requires:
neighbor address: The address of the neighbor.
neighbor stats: for example, RSSI of the last received packet
from that neighbor, ASN when that neighbor has been added, etc.
Returns whether the neighbor is updated or not.
Wang, et al. Expires August 4, 2014 [Page 25]
Internet-Draft 6tisch-6top-interface January 2014
3.3.7.5. DELETE.neighbor
Deletes a neighbor given its address. Fails if the neighbor does not
exists.
3.3.8. Queueing Commands
Queues need to be configured. This includes queue length,
retransmission policy, discarding of packets, etc.
3.3.8.1. CREATE.queue
Creates and Configures Queues. The command SHOULD be applied for
each required queue. The command requires:
txqlength: the desired transmission queue length.
rxqlength: the desired reception queue length.
numrtx: number of allowed retransmissions.
age: discard packet according to its age on the queue. 0 if no
discards are allowed.
rtxbackoff: retransmission backoff in number of slotframes. 0
if next available timeslot wants to be used.
statswindow: window of time used to compute stats.
queue priority: the priority of this queue.
TrackIDs: a set of TrackIDs. While it is empty, no specific
track is associated with the queue
Returns the queue ID.
3.3.8.2. READ.queue
Reads the queue configuration. Requires the queue ID.
The command returns:
txqlength: the transmission queue length.
rxqlength: the reception queue length.
numrtx: number of allowed retransmissions.
Wang, et al. Expires August 4, 2014 [Page 26]
Internet-Draft 6tisch-6top-interface January 2014
age: maximum age of a packet before being discarded. 0 if no
discards are allowed.
rtxbackoff: retransmission backoff in number of slotframes. 0
if next available timeslot is used.
3.3.8.3. READ.queue.stats
Reads the queue stats. Requires queue ID.
The command returns:
txqlengthstats: average, maximum, minimum length of the
transmission queue.
rxqlengthstats: average, maximum, minimum length of the
reception queue.
numrtxstats: average, maximum, minimum number of
retransmissions.
agestats: average, maximum, minimum age of a packet in the
queue.
rtxbackoffstats: average, maximum, minimum retransmission
backoff.
queue priority: the priority of this queue.
TrackIDs: a set of TrackIDs.
3.3.8.4. UPDATE.queue
Update a Queue. The command requires:
queueid: the queue ID.
txqlength: the desired transmission queue length.
rxqlength: the desired reception queue length.
numrtx: number of allowed retransmissions.
age: discard packet according to its age on the queue. 0 if no
discards are allowed.
rtxbackoff: retransmission backoff in number of slotframes. 0
if next available timeslot wants to be used.
Wang, et al. Expires August 4, 2014 [Page 27]
Internet-Draft 6tisch-6top-interface January 2014
statswindow: window of time used to compute stats.
queue priority: the desired priority of this queue.
TrackIDs: the desired set of TrackIDs.
3.3.8.5. DELETE.queue
Deletes a Queue. The command requires the queue ID. All packets in
the queue are discarded and the queue is deleted.
3.3.9. Data Commands
3.3.9.1. Send.data
The command used by upper layers to queue a packet so underlying TSCH
sends it. According to the specific priority, the packet is pushed
into a Queue with the equivalent priority or following a criteria out
of scope. Once a packet is inserted into a queue it waits to be
transmitted by TSCH according to the model defined in Section 3.2.
If the queue is full or destination address is not a L2 neighbor of
the node, failure to enqueue will be indicated to the caller.
The required parameters are:
src address: L2 address
dest address: L2 unicast or broadcast address
priority: packet priority, usually is consistent with queue
priority
message length: the length of the message
message: control message or data message
securityLevel:As defined by [IEEE802154e].
3.3.9.2. Receive.data
The command is invoked whenever a packet is received and inserted
into a reception queue. The method acts as a callback function to
notify to the upper layers the received message. Upper layers MUST
terminate this indication.
The function has the following parameters:
src address: L2 source address
Wang, et al. Expires August 4, 2014 [Page 28]
Internet-Draft 6tisch-6top-interface January 2014
dest address: L2 unicast or broadcast destination address
priority: packet priority, usually is consistent with queue
priority
message length: the length of the message.
message: control message or data message
3.3.10. Label Switching Commands
3.3.10.1. LabelSwitching.map
The command used by an upper layer to map an input cell or a bundle
of input cells to an output cell or a bundle of output cells. 6top
stores this mapping and makes sure that the packets are forwarded at
the specific output cell/bundle. Label Switching is enabled by the
specified bundle as soon as the mapping is installed.
The required parameters are:
input cells: list of input cells (one or more cells in a
bundle). Each input cells is described by an unique tuple
(slotOffset, channelOffset, destination address).
output cells: list of output cells (one or more cells in a
bundle). Each output cells is described by an unique tuple
(slotOffset, channelOffset, destination address).
load balancing policy: A policy for load balance cell usage.
The policy is out of scope, however an example can be use ROUND
ROBIN policy within the cells of the same bundle.
3.3.10.2. LabelSwitching.unmap
The command used by upper layers to unmap one input cell or a bundle
of input cells to an output cell or a bundle of output cells. The
mapping is removed from the state kept by 6top.
The required parameters are:
input cells: list of input cells (one or more cells in a
bundle). Each input cells is described by an unique tuple
(slotOffset, channelOffset, destination address).
output cells: list of output cells (one or more cells in a
bundle). Each output cells is described by an unique tuple
(slotOffset, channelOffset, destination address).
Wang, et al. Expires August 4, 2014 [Page 29]
Internet-Draft 6tisch-6top-interface January 2014
3.3.11. Chunk Command
3.3.11.1. Create.chunk
Create a chunk which consists of one or more unappropriated cells.
To create a chunk, upper layer specifies:
slotframe ID: ID of the slotframe which this chunk belongs to.
NumOfCells: number of the cells which the chunk includes.
list of (slotOffset, channelOffset):
slotOffset: the slotOffset for the cell.
channelOffset: channelOffset for the cell.
ChunkID is the return value of the command (Section 4.1).
3.3.11.2. Delete.chunk
To delete a chunk, upper layer specifies ChunkID.
It removes the chunk from ChunkList (Section 4.1). It also causes
all of the appropriated cells in the chunk are deleted from CellList
(Section 4.1) and TSCH schedule as well.
3.3.12. Chunk Cell Command
3.3.12.1. CREATE.hardcell.fromchunk
Creates one or more hard cells from a chunk. Fails if the cell
already exists. A cell is uniquely identified by the tuple
(slotframe ID, slotOffset, channelOffset).
To create a hard cell from a chunk which is corresponding to a
specific slotframe ID, the upper layer specifies:
chunkID: ID of the chunk which this cell belongs to.
slotOffset: the slotOffset for the cell.
channelOffset: channelOffset for the cell.
LinkOption bitmap: bitmap as defined in [IEEE802154e]
LinkType : as defined in section 6.2.19.3 of [IEEE802154e].
Wang, et al. Expires August 4, 2014 [Page 30]
Internet-Draft 6tisch-6top-interface January 2014
CellType: as defined in Section 3.1
target node address: the address of that node to communicate
with over this cell. In case of broadcast cells this is the
broadcast address.
TrackID: ID of the track the cell will belong to.
6top schedules the cell and marks it as a hard cell, indicating that
it cannot reschedule this cell. In addition, 6top will change the
attributes corresponding to the cell in the ChunkList, i.e. its
CellID is changed to the same CellID in the CellList, and its Status
is changed to APPROPRIATED (Section 4.1).
The interaction between 6top and MAC layer caused by
CREATE.hardcell.fromchunk is same as that caused by CREATE.hardcell
(Section 3.3.1.1).
3.3.12.2. DELETE.hardcell.fromchunk
To remove a hard cell which comes from a chunk, the upper layer
specifies:
slotframe ID: the ID of the slotframe where this cell is
installed.
slotOffset: the slotOffset for the cell.
channelOffset: the selected channelOffset for the cell.
LinkOption bitmap: bitmap as defined in [IEEE802154e]
LinkType : as defined in in section 6.2.19.3 of [IEEE802154e].
CellType: as defined in Section 3.1
target node address: the target address of that cell. In case
of broadcast cells this is the broadcast address.
TrackID: ID of the track the cell will belong to.
This removes the hard cell from the node's schedule and CellList
(Section 4.1). In addition, it changes the attributes corresponding
to the cell in the ChunkList, i.e. its CellID is changed back to
FFFF, and its Status is changed to UNAPPROPRIATED (Section 4.1).
The interaction between 6top and MAC layer caused by DELETE.hardcell
is same as that caused by DELETE.hardcell (Section 3.3.1.5).
Wang, et al. Expires August 4, 2014 [Page 31]
Internet-Draft 6tisch-6top-interface January 2014
4. Generic Data Model
YANG model is used to express the generic data model as follows. The
data model includes that corresponding to 6top MIB, part of
[IEEE802154] PIB and part of [IEEE802154e] PIB.
4.1. YANG model of 6top MIB
list CellList {
key "CellID";
description
"List of of scheduled cells of a node with all of its neighbors,
in all of its slotframes.";
leaf CellID {
type uint16;
description
"equal to Linkhandle in the linkTable of TSCH";
reference
"IEEE802154e";
}
leaf SlotframeID {
type uint8;
description
"equal to SlotframeHandle defined in TSCH";
reference
"IEEE802154e";
}
leaf SlotOffset {
type uint16;
description
"Defined in IEEE802154e.";
reference
"IEEE802154e";
}
leaf ChannelOffset {
type uint8;
description
"Defined in IEEE802154e. Value range is 0..15";
reference
"IEEE802154e";
}
leaf LinkOption {
type bits {
bit Transmit {
position 0;
}
Wang, et al. Expires August 4, 2014 [Page 32]
Internet-Draft 6tisch-6top-interface January 2014
bit Receive {
position 1;
}
bit Share {
position 2;
}
bit Timekeeping {
position 3;
}
bit Reserved1 {
position 4;
}
bit Reserved2 {
position 5;
}
bit Reserved3 {
position 6;
}
bit Reserved4 {
position 7;
}
}
description
"Defined in IEEE802154e.";
reference
"IEEE802154e";
}
leaf LinkType {
type enumeration {
enum NORMAL;
enum ADVERTISING;
}
description
"defined in IEEE802154";
reference
"IEEE802154";
}
leaf CellType {
type enumeration {
enum SOFT;
enum HARD;
}
description
"defined in 6top";
}
leaf TargetNodeAddress {
type uint64;
description
Wang, et al. Expires August 4, 2014 [Page 33]
Internet-Draft 6tisch-6top-interface January 2014
"defined by 6top, but being constrained by TSCH macNodeAddress
size, 2-octets. If using TSCH as MAC, higher 6-octets should
be filled with "0", and lowest 2-octets is neighbor address";
}
leaf TrackID {
type uint16;
description
"A TrackID is a tuple (TrackOwnerAddr,InstanceID), where
TrackOwnerAddr is the address of the node which initializes
the process of creating the track, i.e., the owner of the
track; and InstanceID is an instance identifier given by the
owner of the track.";
}
container Statistic {
leaf NumOfStatistic {
type uint8;
description
"number of statistics conducted on the cell";
}
list MeasureList {
key "StatisticsMetricsID";
leaf StatisticsMetricsID{
type uint16;
}
leaf StatisticsValue{
type uint16;
}
}
}
}
list SlotframeList {
key "SlotframeID";
leaf SlotframeID {
type uint8;
}
leaf NumOfSlots {
type uint16;
}
}
list MonitoringStatusList {
key "MonitoringStatusID";
leaf MonitoringStatusID {
type uint16;
}
leaf SlotframeID {
type uint8;
Wang, et al. Expires August 4, 2014 [Page 34]
Internet-Draft 6tisch-6top-interface January 2014
}
leaf TargetNodeAddress {
type uint64;
}
leaf EnforcePolicy {
type enumeration {
enum DISABLE;
enum BESTEFFORT;
enum STRICT;
enum OVERPROVISION;
}
description
"current enforced QoS policy";
}
leaf AllocatedHard {
type uint16;
description
"Number of hard cells allocated";
}
leaf AllocatedSoft {
type uint16;
description
"Number of soft cells allocated";
}
leaf OverProvision {
type uint16;
description
"Overprovisioned cells. 0 if CONFIGURE.qos enforce is DISABLE";
}
leaf QoS {
type uint16;
description
"Current QoS including overprovisioned cells, i.e. the
bandwidth obtained including the overprovisioned cells.";
}
leaf NQoS {
type uint16;
description
"real QoS without provisioned cells, i.e. the actual bandwidth
without taking into account the overprovisioned cells.";
}
}
list StatisticsMetricsList {
key "StatisticsMetricsID";
leaf StatisticsMetricsID {
type uint16;
}
Wang, et al. Expires August 4, 2014 [Page 35]
Internet-Draft 6tisch-6top-interface January 2014
leaf SlotframeID {
type uint16;
description
"ID of the slotframe. If empty monitors all slotframe IDs";
reference
"IEEE802154e";
}
leaf SlotOffset {
type uint16;
description
"Specific slotOffset to be monitored. If empty all timeslots are
monitored";
reference
"IEEE802154e";
}
leaf ChannelOffset {
type uint8;
description
"Specific channelOffset to be monitored. If empty all channels
are monitored";
reference
"IEEE802154e";
}
leaf TargetNodeAddress {
type uint64;
description
"If empty, all neighbor nodes are monitored.";
}
leaf Metrics {
type enumeration {
enum PDR;
enum ETX;
enum RSSI;
enum LQI;
}
description
"The metric to be monitored.";
}
leaf Window {
type uint16;
description
"measurement period, in Number of the slotframe size";
}
leaf Enable {
type enumeration {
enum DISABLE;
enum ENABLE;
}
Wang, et al. Expires August 4, 2014 [Page 36]
Internet-Draft 6tisch-6top-interface January 2014
}
}
list EBList {
key "EbID";
leaf EbID {
type uint8;
}
leaf CellID {
type uint16;
description
"equal to LinkHandle in IEEE802154e";
}
leaf Peroid {
type uint16;
description
"the EBs period, in seconds";
}
leaf Expiration {
type enumeration {
enum NEVERSTOP;
enum EXPIRATION;
}
description
"with Period to indicate when the EBs periodicity will stop.
If Zero the period never stops.";
}
leaf Priority {
type uint8;
description
"the joining priority model that will be used for advertisement.
Joining priority MAY be for example SAME_AS_PARENT, RANDOM,
BEST_PARENT+1 or DAGRANK(rank).";
}
}
Wang, et al. Expires August 4, 2014 [Page 37]
Internet-Draft 6tisch-6top-interface January 2014
container TimeSource {
leaf policy {
type enumeration {
enum ALLPARENT;
enum BESTCONNECTED;
enum LOWESTJOINPRIORITY;
}
}
leaf TargetNodeAddress {
type uint64;
description
"address of the time source neighbor";
}
leaf MinTimeCorrection {
type uint16;
description
"in microsecond";
}
leaf MaxTimeCorrection {
type uint16;
description
"in microsecond";
}
leaf AveTimeCorrection {
type uint16;
description
"in microsecond";
}
}
Wang, et al. Expires August 4, 2014 [Page 38]
Internet-Draft 6tisch-6top-interface January 2014
typedef asntype {
description
"the type to store ASN. String of 5 bytes";
type string {
length "0..5";
}
}
list NeighborList {
key "TargetNodeAddress";
leaf TargetNodeAddress {
type uint64;
description
"address of the time source neighbor";
}
leaf RSSI {
type uint8;
description
"the received signal strength";
}
leaf LinkQuality {
type uint8;
description
"the LQI metric";
}
leaf ASN {
type asntype;
description
"the 5 ASN bytes";
}
}
list QueueList {
key "QueueId";
leaf QueueId {
type uint8;
description
"address of the time source neighbor";
}
leaf TxqLength {
type uint8;
description
"the tx queue length in number of packets";
Wang, et al. Expires August 4, 2014 [Page 39]
Internet-Draft 6tisch-6top-interface January 2014
}
leaf RxqLength {
type uint8;
description
"the rxqueue length in number of packets";
}
leaf NumrTx {
type uint8;
description
"number of allowed retransmissions.";
}
leaf Age {
type uint16;
description
"In seconds. Discard packet according to its age
on the queue. 0 if no discards are allowed.";
}
leaf RTXbackoff {
type uint8;
description
"retransmission backoff in number of slotframes.
0 if next available timeslot wants to be used.";
}
leaf StatsWindow {
type uint16;
description
"In second, window of time used to compute stats.";
}
leaf QueuePriority {
type uint8;
description
"the priority for this queue.";
}
list TrackIds {
key "TrackID";
unique "TrackID";
leaf TrackID{
type uint16;
description
"the TrackID.";
}
}
Wang, et al. Expires August 4, 2014 [Page 40]
Internet-Draft 6tisch-6top-interface January 2014
leaf MinLenTXQueue {
type uint8;
description
"Statistics, lowest TX queue len registered in the window.";
}
leaf MaxLenTXQueue {
type uint8;
description
"Statistics, largest TX queue len registered in the window.";
}
leaf AvgLenTXQueue {
type uint8;
description
"Statistics, avg TX queue len registered in the window.";
}
leaf MinLenRXQueue {
type uint8;
description
"Statistics, lowest RX queue len registered in the window.";
}
leaf MaxLenRXQueue {
type uint8;
description
"Statistics, largest RX queue len registered in the window.";
}
leaf AvgLenRXQueue {
type uint8;
description
"Statistics, avg RX queue len
registered in the window.";
}
leaf MinRetransmissions {
type uint8;
description
"Statistics, lowest number of
retransmissions registered in the window.";
}
leaf MaxRetransmissions {
type uint8;
description
"Statistics, largest number of retransmissions registered
Wang, et al. Expires August 4, 2014 [Page 41]
Internet-Draft 6tisch-6top-interface January 2014
in the window.";
}
leaf AvgRetransmissions {
type uint8;
description
"Statistics, average number of retransmissions registered
in the window.";
}
leaf MinPacketAge {
type uint16;
description
"Statistics, in seconds, minimum time a packet stayed in
the queue during the observed window.";
}
leaf MaxPacketAge {
type uint16;
description
"Statistics, in seconds, maximum time a packet stayed
in the queue during the observed window.";
}
leaf AvgPacketAge {
type uint16;
description
"Statistics, in seconds, average time a packet stayed in
the queue during the observed window.";
}
leaf MinBackoff {
type uint8;
description
"Statistics, in number of slotframes, minimum Backoff
for a packet in the queue during the observed window.";
}
leaf MaxBackoff {
type uint8;
description
"Statistics, in number of slotframes, maximum Backoff
for a packet in the queue during the observed window.";
}
leaf AvgBackoff {
type uint8;
Wang, et al. Expires August 4, 2014 [Page 42]
Internet-Draft 6tisch-6top-interface January 2014
description
"Statistics, in number of slotframes, average Backoff
for a packet in the queue during the observed window.";
}
}
list LabelSwitchList {
key "LabelSwitchID";
leaf LabelSwitchID {
type uint16;
}
list InputCellIds {
key "CellID";
leaf CellID{
type uint16;
description
"the CellID.";
}
}
list OutputCellIds {
key "CellID";
leaf CellID{
type uint16;
description
"the CellID.";
}
}
leaf LoadBalancingPolicy {
type enumeration {
enum ROUNDROBIN;
enum OTHER;
}
description
"The Load Balancing policy.";
}
}
list BundleList {
key "BundleID";
leaf BundleID {
type uint8;
}
Wang, et al. Expires August 4, 2014 [Page 43]
Internet-Draft 6tisch-6top-interface January 2014
leaf TargetNodeAddress {
type uint64;
description
"The destination address for this bundle.";
}
leaf TrackID{
type uint16;
description
"the track which the bundle is associted";
}
list CellIds {
key "CellID";
leaf CellID{
type uint16;
description
"the CellID.";
}
}
leaf NumOfStatistics {
type uint8;
description
"The number of statistics being monitored in the bundle.";
}
list Statistics {
key "StatisticsMatriceId";
leaf StatisticsMatriceId{
type uint16;
description
"the Statistics List ID.";
}
leaf StatisticsValue{
type uint16;
description
"Their meaning depends on the value of Metrics
indexed by StatisticsMatriceId.";
}
}
}
Wang, et al. Expires August 4, 2014 [Page 44]
Internet-Draft 6tisch-6top-interface January 2014
list TrackList {
key "TrackId";
leaf TrackId {
type uint16;
}
leaf TrackOwnerAddr {
type uint64;
description
"the address of the node which initializes the process of creating
the track, i.e., the owner of the track;";
}
leaf InstanceID {
type uint16;
description
"InstanceID is an instance identifier given by the owner of the
track. InstanceID comes from upper layer; InstanceID could for
example be the local instance ID defined in RPL.";
}
}
}
Wang, et al. Expires August 4, 2014 [Page 45]
Internet-Draft 6tisch-6top-interface January 2014
list ChunkList {
key "ChunkId";
leaf ChunkId{
type uint16;
description
"the id of a Chunk";
}
leaf SlotframeId{
type uint8;
description
"the id of the slotframe that is mapped to this chunk";
}
list ChunkCells {
key "SlotOffset ChannelOffset";
leaf SlotOffset{
type uint16;
description
"the slotoffset.";
}
leaf ChannelOffset{
type uint16;
description
"the channeloffset.";
}
leaf CellID{
type uint16;
description
"initial value of CellID is FFFF. When the cell is
appropriated, the value of CellID is same as that in
CellList";
}
leaf ChunkCellStatus {
type enumeration {
enum UNAPPROPRIATED;
enum APPROPRIATED;
}
}
}
}
Wang, et al. Expires August 4, 2014 [Page 46]
Internet-Draft 6tisch-6top-interface January 2014
4.2. YANG model of IEEE802.15.4 PIB
This section describes the YANG model of the part of [IEEE802154] PIB
used in 6top, such as security related attributes. This part of data
will be accessed by using primitives like MLME-GET and MLME-SET
([IEEE802154]).
TODO
4.3. YANG model of IEEE802.15.4e PIB
This section describes the YANG model of the part of [IEEE802154e]
PIB used in 6top, such as TSCH related attributes. This part of data
will be accessed by using primitives like MLME-GET and MLME-SET
([IEEE802154]).
TODO
5. Using 6top
This part describes how 6top gives support to specific upper layers.
5.1. RPL on 6top
6top provides a set of functionalities so higher layers can obtain
information about the status of the network and take advantage of the
slotted structure to improve metric calculation and objective
function optimization. The following sections describe how RPL can
make use of 6top sublayer.
In order to optimize the combination of RPL and TSCH, 6top provides
specific support to RPL in the following aspects:
RPL Neighbor Discovery and Parent Selection
RPL Rank Computation
RPL Control Messages Broadcast
QoS
5.1.1. Support to Neighbor Discovery and Parent Selection
The Section 3.3.7 defines a set of commands so the neighbor table can
be managed and queried by RPL. An entry to the neighbor table is
inserted whenever an EBs is received at L2. The EB causes the 6top
sublayer to create an entry to the neighbors table. A neighbor table
entry contains a set of statistics with respect to that specific
Wang, et al. Expires August 4, 2014 [Page 47]
Internet-Draft 6tisch-6top-interface January 2014
neighbor such as the ASN when the last packet has been received from
that neighbor, a set of cell quality metrics (RSSI, LQI), number of
packets sent to it or number of packets received from it amongst
others. 6top updates that table upon sending or reception of a packet
from/to a neighbor. RPL can query at any time the neighbor table to
retrieve information about a particular neighbor. This information
can be used to compute the routing objective function as for example
the Zero Objective function as described in
[I-D.vilajosana-6tisch-minimal]. Parent selection can also be driven
by the information contained on the neighbor table as well as
complemented with the cells statistics defined in Section 3.3.4.
6top enables RPL to configure EB periodicity. By controlling the EBs
periodicity, RPL can configure how network dynamism and support to
mobility are addressed, as more frequent beacons the more prone to
cope with mobility. Section 3.3.5 enables to configure how the
network is formed and EBs periodicity.
RPL MAY want to select the policy to determine the time source
neighbor, this can be interesting when time source neighbors can be
aligned to the routing topology, i.e., the selected time source
neighbor can be the node's favorite parent in a specific DODAG.
Section 3.3.6 describes the 6top command to set up the desired
policy. The policy is selected by RPL and enforced by the 6top
sublayer.
The rule for 6top to select and maintain time source neighbors is as
follows:
The time source neighbor of a node SHOULD be a member of the
node's neighbor set.
Time source neighbors SHOULD be the neighbors which have a
relatively lower join priority in the neighbor set. A lower
join priority indicates that the neighbor is closer to the TSCH
PAN coordinator.
The link between a node and one of its time source neighbors
SHOULD be a good link quality.
5.1.2. Support of Rank Computation
The RPL objective function is computed using a set of metrics. The
[I-D.vilajosana-6tisch-minimal] defines how Zero Objective Function
is used to configure the rank and metrics used from 6top statistics.
The specific metrics, and how the objective function is calculated
are out of scope. However, 6top builds a set of functionalities to
provide more accurate statistics of the underlying layer so the
Wang, et al. Expires August 4, 2014 [Page 48]
Internet-Draft 6tisch-6top-interface January 2014
objective function can be accommodated to the nature of a TSCH MAC
layer.
6top provides statistics for rank computation as described in
Section 3.3.4. The function used to compute the rank based on those
statistics is out of scope. However, the provided metrics are
aligned to the behavior of the TSCH MAC layer.
5.1.3. Support of Control Messages Broadcast
In RPL, some control messages, e.g., DIO in storing mode, need to be
broadcast to all neighbor nodes. The broadcast channel requirement
has to be addressed by 6top by configuring TSCH to provide such a
channel.
In order to decouple the upper (RPL) layer from TSCH, instead of
carrying DIO messages in Enhance Beacons, 6top introduces a mechanism
to establish broadcast cells.
In TSCH schedule, every cell has the LinkType attribute. If
LinkType=ADVERTISING, indicates that the cell MAY be used to send an
Enhanced Beacon. When a node forms its Enhanced Beacon, the cell,
with LinkType=ADVERTISING, SHOULD be included in the FrameAndLinkIE,
and its LinkOption field SHOULD be set to the combination of
"Receive" and "Timekeeping". The receiver of the Enhanced Beacon MAY
be listening at the cell to get the Enhanced Beacon ([IEEE802154e]).
6top takes this way to establish broadcast channel, which not only
allows TSCH broadcast Enhanced Beacon, but also allows an upper layer
like RPL broadcast.
To support DIO and DAO broadcasts, 6top uses the payload of a Data
Packet to carry the DIO or DAO. The message is inserted into the
queue associated with the cells which LinkType is set to ADVERTISING.
Then, taking advantage of the broadcast cell feature established with
FrameAndLinkIE as described above, the data packet with DIO or DAO in
the payload can be received by neighbors, which enforces to the
maintenance of DODAG.
A LinkOption combining "Receive" and "Timekeeping" bits indicates to
the receivers of the Enhanced Beacon that the cell MUST be used as a
broadcast cell. The frequency of sending Enhance Beacon or other
broadcast messages by upper layer is determined by the timers
associated with the messages. For example, the transmission of
Enhance Beacons is triggered by a timer in 6top; transmission of a
DIO message is triggered by the trickle timer of RPL.
Wang, et al. Expires August 4, 2014 [Page 49]
Internet-Draft 6tisch-6top-interface January 2014
5.1.4. Support for QoS
The TSCH MAC layer is decoupled from the upper layer, and the
interaction between the upper layer ad TSCH is asynchronous. This
means that the MAC layer executes a schedule and checks at each
timeslot according to the type of cell whether there is something to
send or receive. If that is the case the packet is transmitted and
the MAC layer continues its operation. When an upper layer sends a
packet, this packet is pushed into a queue waiting to the MAC layer
to read it and send it in a particular timeslot according to is
destination and priority (Section 3.2). 6top provides a set of queue
management operations which enable upper layers to create different
queues and determine their priorities. This allows different classes
of traffic to be handled by the routing layer, i.e. inserting a
packet to a specific queue according to its priority.
A 6top implement MUST provide at least a Broadcast Queue, a Transmit
Queue, and a Receive Queue. RPL can configure the queues with
Internal Queueing Command (Section 3.3.8.1). The Broadcast Queue is
associated with cells with LinkType=ADVERTISING in sender's schedule,
and LinkOption="Receive" and "Timekeeping" in all neighbors'
schedule. This indicates that the cells can be used as broadcast
cells from the sender to its neighbors. A Transmit Queue is
associated with the dedicated Transmit cells or Shared Cells. RPL
can benefit from having different priority queues to improve latency
or provide integrated services with different priorities, i.e.
different traffic classes.
Data Communication Commands (Section 3.3.9) can be used to send
control messages and data messages. The operation is used to insert
a message to an specific queue.
For example a suitable configuration can include two Broadcast Queues
with priority High and Low, respectively; three Transmit Queues, with
priority High, Mid, and Low, respectively; and one Receive Queue.
When DestAddr is a broadcast address, its related MAC layer packets
will be pushed into the Broadcast Queue with the corresponding
priority. 6top is responsible for feeding these packets to TSCH at
broadcast cells.
When DestAddr is unicast address, its related MAC layer packets will
be push into the Transmit Queue with corresponding priority. 6top is
responsible for feeding these packets to TSCH at Transmit cells or
Shared Cells.
6top conducts a QoS policy, which is out of scope. Here is an
example. Packets in higher priority queue MUST be sent out before
Wang, et al. Expires August 4, 2014 [Page 50]
Internet-Draft 6tisch-6top-interface January 2014
the packets in lower priority queue. Then, when there is an
available broadcast/unicast cell, 6top checks the broadcast/unicast
queue with higher priority first, if there is a packet, then feeds it
to TSCH at the cell, otherwise it checks broadcast/unicast queue with
lower priority further. 6top repeats the process, until it finds a
broadcast/unicast packet to feed to TSCH or finds that all of
broadcast/unicast queues are empty.
5.2. GMPLS on 6top
GMPLS is a 2.5 layer service that is used to forward packets based on
the concept of generalized labels. Labels are determined by a
reservation protocol during the formation of a multi-hop path. As
defined by [RFC3471], [RFC3473] and [RFC4606] a generalized label
identifies a flow of data through a set of nodes that conform to a
multi-hop path. Instead of being written implicitly into a field in
each packet, as is the case in MPLS [RFC3031], the generalized label
is kept at each node in the form of a table. The table can be used
to map input cells to output cells so routing decisions can be taken
at that layer.
In order to optimize the combination of GMPLS and TSCH, 6top provides
specific support to GMPLS in the following aspects:
Cell Reservation Support
QoS
5.2.1. Cell Reservation Support for GMPLS on 6top
The GMPLS control plane is used to send path reservation requests and
reservation confirmations. When reservation confirmations are
received, GMPLS needs to configure the underlying MAC layer to
provide the required bandwidth. 6top provides a set of commands to
deal with bandwidth allocation, i.e., cell allocation. Section 3.3.1
describes the operations that GMPLS layer MAY use for cell
configuration. Note that 6top supports different types of
reservations: soft cell and hard cell. How the reservation
requirements are expressed is out of scope, but 6top is able to
handle a reservation done as a specific bandwidth requirement, done
through specifying exact cells.
The [I-D.vilajosana-6tisch-minimal] defines a pre-configured schedule
that can be used to bootstrap the network. Those cells can be seen
as a GMPLS control plane where RPL routes can be formed and Track
reservations issued.
Wang, et al. Expires August 4, 2014 [Page 51]
Internet-Draft 6tisch-6top-interface January 2014
GMPLS can also give different priorities to its control plane and
data plane. It can for example be interesting to have a higher
priority for control messages so the network adapts to new bandwidth
requirements quickly. In contrast, data plane messages can be given
a higher priority when they need to meet higher throughput or lower
latency. 6top provides commands (Section 3.3.8) to manage MAC layer
queues and assign different priorities to them.
5.2.2. Supporting QoS
GMPLS can use 6top statistics to determine whether some QoS
requirement is met. Operations defined in Section 3.3.4 can be used
by GMPLS to trigger new bandwidth allocation, or to map different
input bundles to output bundles.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
Wang, et al. Expires August 4, 2014 [Page 52]
Internet-Draft 6tisch-6top-interface January 2014
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, July 2004.
[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-
Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals", RFC
4919, August 2007.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
"Routing Requirements for Urban Low-Power and Lossy
Networks", RFC 5548, May 2009.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks", RFC
5826, April 2010.
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
"Building Automation Routing Requirements in Low-Power and
Lossy Networks", RFC 5867, June 2010.
[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney,
"Industrial Routing Requirements in Low-Power and Lossy
Networks", RFC 5673, October 2009.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
September 2011.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012.
[RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and
Application Spaces for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs)", RFC 6568, April 2012.
Wang, et al. Expires August 4, 2014 [Page 53]
Internet-Draft 6tisch-6top-interface January 2014
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing", RFC
6606, May 2012.
[RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
for OAuth", RFC 6755, October 2012.
[I-D.watteyne-6tsch-tsch-lln-context]
Watteyne, T., Palattella, M., and L. Grieco, "Using
IEEE802.15.4e TSCH in an LLN context: Overview, Problem
Statement and Goals", draft-watteyne-6tsch-tsch-lln-
context-02 (work in progress), May 2013.
[I-D.thubert-6tisch-architecture]
Thubert, P., Watteyne, T., and R. Assimiti, "An
Architecture for IPv6 over the TSCH mode of IEEE
802.15.4e", draft-thubert-6tisch-architecture-01 (work in
progress), October 2013.
[I-D.palattella-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terminology in IPv6 over the TSCH mode of IEEE
802.15.4e", draft-palattella-6tisch-terminology-00 (work
in progress), October 2013.
[I-D.vilajosana-6tisch-minimal]
Vilajosana, X. and K. Pister, "Minimal 6TiSCH
Configuration", draft-vilajosana-6tisch-minimal-00 (work
in progress), October 2013.
[I-D.ohba-6tsch-security]
Chasko, S., Das, S., Lopez, R., Ohba, Y., Thubert, P., and
A. Yegin, "Security Framework and Key Management Protocol
Requirements for 6TSCH", draft-ohba-6tsch-security-01
(work in progress), July 2013.
[I-D.thubert-roll-forwarding-frags]
Thubert, P. and J. Hui, "LLN Fragment Forwarding and
Recovery", draft-thubert-roll-forwarding-frags-02 (work in
progress), September 2013.
[I-D.tsao-roll-security-framework]
Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A
Security Framework for Routing over Low Power and Lossy
Networks", draft-tsao-roll-security-framework-02 (work in
progress), March 2010.
Wang, et al. Expires August 4, 2014 [Page 54]
Internet-Draft 6tisch-6top-interface January 2014
[I-D.thubert-roll-asymlink]
Thubert, P., "RPL adaptation for asymmetrical links",
draft-thubert-roll-asymlink-02 (work in progress),
December 2011.
[I-D.ietf-roll-terminology]
Vasseur, J., "Terms used in Routing for Low power And
Lossy Networks", draft-ietf-roll-terminology-13 (work in
progress), October 2013.
[I-D.ietf-roll-p2p-rpl]
Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J.
Martocci, "Reactive Discovery of Point-to-Point Routes in
Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-17
(work in progress), March 2013.
[I-D.ietf-roll-trickle-mcast]
Hui, J. and R. Kelsey, "Multicast Protocol for Low power
and Lossy Networks (MPL)", draft-ietf-roll-trickle-
mcast-05 (work in progress), August 2013.
[I-D.thubert-6lowpan-backbone-router]
Thubert, P., "6LoWPAN Backbone Router", draft-thubert-
6lowpan-backbone-router-03 (work in progress), February
2013.
[I-D.sarikaya-core-sbootstrapping]
Sarikaya, B., Ohba, Y., Moskowitz, R., Cao, Z., and R.
Cragie, "Security Bootstrapping Solution for Resource-
Constrained Devices", draft-sarikaya-core-
sbootstrapping-04 (work in progress), April 2012.
[I-D.gilger-smart-object-security-workshop]
Gilger, J. and H. Tschofenig, "Report from the 'Smart
Object Security Workshop', 23rd March 2012, Paris,
France", draft-gilger-smart-object-security-workshop-00
(work in progress), October 2012.
[I-D.phinney-roll-rpl-industrial-applicability]
Phinney, T., Thubert, P., and R. Assimiti, "RPL
applicability in industrial networks", draft-phinney-roll-
rpl-industrial-applicability-02 (work in progress),
February 2013.
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-18
(work in progress), June 2013.
Wang, et al. Expires August 4, 2014 [Page 55]
Internet-Draft 6tisch-6top-interface January 2014
6.3. External Informative References
[IEEE802154e]
IEEE standard for Information Technology, "IEEE std.
802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area
Networks (LR-WPANs) Amendment 1: MAC sublayer", April
2012.
[IEEE802154]
IEEE standard for Information Technology, "IEEE std.
802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
and Physical Layer (PHY) Specifications for Low-Rate
Wireless Personal Area Networks", June 2011.
[OpenWSN] "Berkeley's OpenWSN Project Homepage",
<http://www.openwsn.org/>.
[label-switching-154e]
Morell, A., Vilajosana, X., Lopez-Vicario, J., and T.
Watteyne, "Label Switching over IEEE802.15.4e Networks.
Transactions on Emerging Telecommunications Technologies",
June 2013.
Authors' Addresses
Qin Wang (editor)
Univ. of Sci. and Tech. Beijing
30 Xueyuan Road
Beijing, Hebei 100083
China
Phone: +86 (10) 6233 4781
Email: wangqin@ies.ustb.edu.cn
Xavier Vilajosana
Universitat Oberta de Catalunya
156 Rambla Poblenou
Barcelona, Catalonia 08018
Spain
Phone: +34 (646) 633 681
Email: xvilajosana@uoc.edu
Wang, et al. Expires August 4, 2014 [Page 56]
Internet-Draft 6tisch-6top-interface January 2014
Thomas Watteyne
Linear Technology
30695 Huntwood Avenue
Hayward, CA 94544
USA
Phone: +1 (510) 400-2978
Email: twatteyne@linear.com
Wang, et al. Expires August 4, 2014 [Page 57]