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", . [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]