6TSCH Q. Wang, Ed. Internet-Draft Univ. of Sci. and Tech. Beijing Intended status: Informational X. Vilajosana Expires: January 14, 2014 Universitat Oberta de Catalunya T. Watteyne Linear Technology July 13, 2013 6TSCH Operation Sublayer (6top) draft-wang-6tsch-6top-00 Abstract The recently published [IEEE802154e] standard formalizes the concept of link-layer resources in LLNs. Nodes are synchronized and follow a schedule. A time slot 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, while ensuring collision-free communication. The [IEEE802154e] standard does not, however, present a mechanism to do so, as building and managing the schedule is out of the standard's scope. Routing layers such as the IETF IPv6 Routing Protocol for LLNs (RPL) provide a mechanism to route multipoint-to-point traffic (from devices inside the LLN towards a central control point) and point-to-multipoint traffic (from the central control point to the devices inside the LLN). Network layer overlays cannot be optimized and adapted to take advantage of the cell-based topology created by the underlying TSCH MAC layer as a missing set of functionalities need to be defined. This document describes the 6TSCH Operation Sublayer (6top) and the main 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 centralized and decentralized scheduling policies. In addition, 6top can be configured to enable packet switching at layer 2.5, analogous to GMPLS. Once a multi-hop track is defined, input cells can be mapped to output cells and packets can be relayed without the need of higher layer routing. 6top defines the operations so input cells and output cells can be mapped and the configuration maintained. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Wang, et al. Expires January 14, 2014 [Page 1] Internet-Draft 6tsch-6top July 2013 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 January 14, 2014. Copyright Notice Copyright (c) 2013 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. 6TSCH Operation Sublayer (6top) . . . . . . . . . . . . . . . 4 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Cell Model . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. hard cells . . . . . . . . . . . . . . . . . . . . . 7 2.2.2. soft cells . . . . . . . . . . . . . . . . . . . . . 7 2.3. Data Convey Model . . . . . . . . . . . . . . . . . . . . 7 2.4. Commands . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4.1. Cell Commands . . . . . . . . . . . . . . . . . . . . 9 2.4.2. Slotframe Commands . . . . . . . . . . . . . . . . . 14 2.4.3. Monitoring Commands . . . . . . . . . . . . . . . . . 15 2.4.4. Statistics Commands . . . . . . . . . . . . . . . . . 17 2.4.5. Network Formation Commands . . . . . . . . . . . . . 19 2.4.6. Time Source Neighbor Commands . . . . . . . . . . . . 21 2.4.7. Neighbor Commands . . . . . . . . . . . . . . . . . . 22 2.4.8. Queueing Commands . . . . . . . . . . . . . . . . . . 24 2.4.9. Security Commands . . . . . . . . . . . . . . . . . . 27 2.4.10. Data Commands . . . . . . . . . . . . . . . . . . . . 29 2.4.11. Label Switching Commands . . . . . . . . . . . . . . 30 Wang, et al. Expires January 14, 2014 [Page 2] Internet-Draft 6tsch-6top July 2013 2.5. Message Formats . . . . . . . . . . . . . . . . . . . . . 31 2.5.1. Information Elements . . . . . . . . . . . . . . . . 32 2.5.2. Packet Formats . . . . . . . . . . . . . . . . . . . 40 2.6. Time Sequence . . . . . . . . . . . . . . . . . . . . . . 45 2.6.1. Network Formation . . . . . . . . . . . . . . . . . . 45 2.6.2. Creating soft cells . . . . . . . . . . . . . . . . . 46 2.6.3. Deleting soft cells . . . . . . . . . . . . . . . . . 47 2.6.4. Maintaining soft cells . . . . . . . . . . . . . . . 48 2.6.5. Creating hard cells . . . . . . . . . . . . . . . . . 48 2.6.6. Deleting hard cells . . . . . . . . . . . . . . . . . 48 2.7. Statistics . . . . . . . . . . . . . . . . . . . . . . . 49 2.7.1. Statistics Metrics . . . . . . . . . . . . . . . . . 49 2.7.2. Statistics Configuration . . . . . . . . . . . . . . 49 2.8. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 50 2.8.1. Monitor Configuration . . . . . . . . . . . . . . . . 50 2.8.2. Actuation . . . . . . . . . . . . . . . . . . . . . . 50 2.9. Label Switching . . . . . . . . . . . . . . . . . . . . . 51 3. Using 6top . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.1. RPL on 6top . . . . . . . . . . . . . . . . . . . . . . . 51 3.1.1. Support to Neighbor Discovery and Parent Selection . 51 3.1.2. Support of Rank Computation . . . . . . . . . . . . . 52 3.1.3. Support of Control Messages Broadcast . . . . . . . . 53 3.1.4. Support to QoS . . . . . . . . . . . . . . . . . . . 53 3.2. GMPLS on 6top . . . . . . . . . . . . . . . . . . . . . . 55 3.2.1. Cell Reservation Support for GMPLS on 6top . . . . . 55 3.2.2. Supporting QoS . . . . . . . . . . . . . . . . . . . 55 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.1. Normative References . . . . . . . . . . . . . . . . . . 56 4.2. Informative References . . . . . . . . . . . . . . . . . 56 4.3. External Informative References . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 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 policies 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 signaling 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 Wang, et al. Expires January 14, 2014 [Page 3] Internet-Draft 6tsch-6top July 2013 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 6TSCH 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 centralized and decentralized scheduling policies. 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 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 centralized, decentralized or hybrid scheduling entities. 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 TSCH networks, 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. 6TSCH Operation Sublayer (6top) Wang, et al. Expires January 14, 2014 [Page 4] Internet-Draft 6tsch-6top July 2013 2.1. Overview 6top is a sublayer which is the next-higher layer for TSCH, as detailed in [I-D.thubert-6tsch-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. 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 2.2. 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 2.3. All commands of the management and data interfaces are detailed in Section 2.4. This set of commands is designed to support centralized, decentralized and hybrid scheduling entities. 6top defines TSCH Information Elements (IEs) for neighbors nodes to negociate scheduling cells in the TSCH schedule. The format of those is given in Section 2.5. Example data exchanges between neighbor nodes are illustrated in Section 2.6. Section 2.7 defines how 6top gathers statistics (e.g. link quality, energy level, queue usage), and what commands an upper layer can use to configure and retrieve statistics. 6top can be configured to monitor some cells it has scheduled in order to detect cells with poor performance. It can then automatically move those cells inside the TSCH schedule. This behavior is described in Section 2.8 2.2. Cell Model IEEE802.15.4e 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 IEEE802.15.4e MLME-SET- LINK.request command uses a linkOptions bitmap to specify the options of a cell. Acceptable values are: b0 = Transmit b1 = Receive Wang, et al. Expires January 14, 2014 [Page 5] Internet-Draft 6tsch-6top July 2013 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 timeslot and channel offset, in a specific slotframe. 6top follows the hard cell reservation process described in Section 2.6.5. In addition, 6top allows an upper layer to schedule a certain amount of bandwidth to a neighbor, without having to specify the exact timeslot(s) and channel offset(s). 6top follows the soft cell reservation process described in Section 2.6.2. Once bandwidth is reserved, 6top is in charge of ensuring that this requirement is continuously satisfied, as described in Section 2.8. 6top dynamically reallocates slots if needed, and overprovisions if required. 6top allows an upper layer to associate a hard/soft 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 initalizes 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. Given this mechanism, 6top defines hard cells (which have been requested specifically) and soft cells (which that can be reallocated dynamically). The hard/soft flag is introduced by the 6top sublayer as an extension of the IEEE802.15.4e LinkOption flags. This option is mandatory; all cells are either hard or soft. With the addition of the Hard/Soft flag, the resulting flags are: b0 = Transmit b1 = Receive b2 = Shared Wang, et al. Expires January 14, 2014 [Page 6] Internet-Draft 6tsch-6top July 2013 b3 = Timekeeping b4 = Hard (1)/Soft (0) b5-b7 = Reserved 2.2.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. timeslot: the slot within the slotframe. channel offset. LinkOption bitmap: bitmap as defined in Section 2.2, including the hard/soft bit which must be set to 1. 2.2.2. soft cells A soft cell is a cell that can be reallocated by 6top dynamically. The hard/soft bit 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 Section 2.6. 2.3. Data Convey Model Once a TSCH schedule is established, 6top is responsible for feeding the data flow 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. 6top Data Convey Model Wang, et al. Expires January 14, 2014 [Page 7] Internet-Draft 6tsch-6top July 2013 | | (DestAddr, Priority, Fragment) | +---------------------------------------+ | I-MUX | +---------------------------------------+ | | | | .... | | | | | | +---+ +---+ +---+ +---+ +---+ | | | | | | | | | | |Q1 | |Q2 | |Q3 | |Q4 | |Qn | | | | | | | | | | | +---+ +---+ +---+ +---+ +---+ | | | | | | | | | | +---------------------------------------+ | MUX | +---------------------------------------+ | | +---+ |PDU| +---+ | | TSCH MAC-payload | Figure 1 In Figure 1, 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, or all of the tracks can be used, or a subset of tracks can be used. When 6top receives a packet to transmit through a Send.data command (Section 2.4.10), 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 frame to send. If it finds a frame, it hands it over to TSCH for transmission. If the next active cell is a broadcast cell, it selects a fragment only from broadcast queues. Wang, et al. Expires January 14, 2014 [Page 8] Internet-Draft 6tsch-6top July 2013 How the MUX module selects the best frame is configurable. Typically, the following rules are used: 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. 2.4. Commands 6top provides a set of commands a higher layer can call, including management commands and data commands. Most of these commands are related to the management of slotframes, time slots and scheduling information. 6top also provides an interface allowing an upper layer to retrieve status information and statistics. This section lists the commands offered by 6top. 2.4.1. Cell Commands The following methods allow an upper layer to manage the network schedule: 2.4.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, timeslot, channel offset). To create a hard cell, the upper layer specifies: slotframe id: id of the slotframe this slot will be scheduled in. time slot: the specific time slot number. channel offset: the frequency offset. LinkOption bitmap: bitmap as defined in Section 2.2 Wang, et al. Expires January 14, 2014 [Page 9] Internet-Draft 6tsch-6top July 2013 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. 2.4.1.2. CREATE.softcell To create a soft cell, the upper layer specifies: slotframe id: id of the slotframe this slot will be scheduled in number of cells: the required number of soft cells. LinkOption bitmap: bitmap as defined in Section 2.2 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. QoS level: the cell redundancy policy. The policy can be for example STRICT, BEST_EFFORT, etc. 6top is responsible for picking the exact timeslot and channel offset 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. 6top deals with the allocation process by negotiation with the target node. The negotiation process is described in Section 2.6.2. The command returns the list of created cells defined by (slotframe id, time slot number, channel offset). 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 cell Option bitmap indicates that the cell MUST be Hard. 2.4.1.3. READ.cell Given a (slotframe id, time slot number, channel offset), retrieves the cell information. Fails if the cell does not exist. The returned information contains: Wang, et al. Expires January 14, 2014 [Page 10] Internet-Draft 6tsch-6top July 2013 slotframe id: the id of the slotframe where this cell is installed. time slot: the time slot where the cell is set. channel offset: the selected channel offset for the cell. LinkOption bitmap: bitmap as defined in Section 2.2 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. A read command can be issued for any cell, hard or soft. 2.4.1.4. UPDATE.cell Update a hard cell, i.e. move it to a different timeslot and/or channel offset. Fails if the cell does not exist. Requires a (slotframe id, time slot, channel offset), type of cell, target node and TrackID are the fields that can be updated. soft cells cannot be updated by the UPDATE.cell command. REALLOCATE.softcell (Section 2.4.1.7) MUST be used instead. 2.4.1.5. DELETE.hardcell To removes a hard cell, the upper layer specifies: slotframe id: the id of the slotframe where this cell is installed. time slot: the time slot where the cell is set. channel offset: the selected channel offset for the cell. This removes the hard cell from the node's schedule. 2.4.1.6. DELETE.softcell To remove a (number of) soft cell(s), the upper layer specifies: slotframe id: the 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 Section 2.2 Wang, et al. Expires January 14, 2014 [Page 11] Internet-Draft 6tsch-6top July 2013 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 moved from the allocated slot so a hard cell can be installed instead, the REALLOCATE.softcell (Section 2.4.1.7) MUST be used. 2.4.1.7. REALLOCATE.softcell To force a move of a soft cell, the upper layer specifies: slotframe id: the id of the slotframe where the cell is allocated. time slot: the slot number where that cell is installed. channel offset: the channel offset for that cell. The reallocated cell will be installed in a different slot, channel offset but slotframe and TrackID remain the same. Hard cells cannot be reallocated. 2.4.1.8. Hardcell Command Behavior The following table describe the behavior of 6top upon reception of the hard cell management commands. hard cell Operations behavior Wang, et al. Expires January 14, 2014 [Page 12] Internet-Draft 6tsch-6top July 2013 +---------------------------------+---------------------------------+ | 6top commands | 6top behavior | +---------------------------------+---------------------------------+ | Create.hardcell | 6top_ReserveHardCellReq() -ACK | | (NeigAddr, TrackID, SlotframeID,| | | SlotOffset, | If NeigAddr ==Broadcast Address| | ChannelOffset, LinkOption) | Then LinkType=ADVERTISING | | | Add cell to EB's FrameAndCellIE | +---------------------------------+---------------------------------+ | Read.cell | MLME-GET.request | |(NeigAddr, TrackID | | | SlotframeID,SlotOffset, | | | ChannelOffset, LinkOption) | | +---------------------------------+---------------------------------+ | Delete.hardcell | 6top_RemoveHardCellReq() --ACK | | (NeigAddr, TrackID, | | | SlotOffset, | | | ChannelOffset, LinkOption) | If LinkType=ADVERTISING, it is a| | | broadcast cell, Then Remove cell| | | from EB's FrameAndCellIE | +---------------------------------+---------------------------------+ | Update.cell | 6top_RemoveHardCellReq() --ACK | | (OldFrameID, OldSlotOffset, | 6top_ReserveHardCellReq() --ACK | | OldChannelOffset, NewFrameID, | (with same NeigAddr, TrackID, | | NewSlotOffset,NewChannelOffset)| LinkOption) | | | If old cell is in EB | | | Then modify EB | +---------------------------------+---------------------------------+ 2.4.1.9. Softcell Command Behavior The following table describe the behavior of 6top upon reception of the Softcell management commands. soft cell Operations behavior Wang, et al. Expires January 14, 2014 [Page 13] Internet-Draft 6tsch-6top July 2013 +--------------------------------+----------------------------------+ | 6top commands | 6top behavior | +--------------------------------+----------------------------------+ | Create.softcell | 6top_ReserveSoftCellReq() -ACK | |(NeigAddr, TrackID, | | | NumCell,LinkOption, | ACK ---6top_ReserveSoftCellResp()| | SlotframeID, QoSLevel) | | +--------------------------------+----------------------------------+ | Read.cell | MLME-GET.request | |(NeigAddr, TrackID, | | | SlotframeID, | | | SlotOffset,ChannelOffset) | | +--------------------------------+----------------------------------+ | Delete.softcell | 6top_RemoveSoftCellReq() -- ACK | | (NeigAddr, TrackID ,NumCell, | If LinkType =ADVERTISING | | LinkOption, SlotframeID) | i.e. a broadcast cell Then Remove| | | cell from EB's FrameAndCellIE | +--------------------------------+----------------------------------+ | Reallocate.softcell | 6top_RemoveSoftCellReq() -- ACK | |(NeigAddr, TrackID | 6top_ReserveSoftCellReq() -- ACK | | SlotframeID, | ACK ---6top_ReserveSoftCellResp()| | SlotOffset,ChannelOffset) | | +--------------------------------+----------------------------------+ 2.4.2. Slotframe Commands 6top provides the following commands to manage TSCH slotframes. 2.4.2.1. CREATE.slotframe Creates a new slotframe. Returns the slotframe id that corresponds to its priority (SlotFrameHandle). The command requires: number of slots: the required number of slots. Fails if the number of required slots is less than zero. 2.4.2.2. READ.slotframe Returns the information of a slotframe given its slotframe id. The command returns: slotframe id: the id of the slotframe. (SlotFrameHandle) number of slots: the number of slots. Fails if the slotframe id does not exist. Wang, et al. Expires January 14, 2014 [Page 14] Internet-Draft 6tsch-6top July 2013 2.4.2.3. UPDATE.slotframe Change the number of slots in a slotframe. The command requires: slotframe id: the id of the slotframe. number of slots: the number of slots to be updated. Fails if the number of required slots is less than zero. Fails if the slotframe id does not exist. 2.4.2.4. DELETE.slotframe Deletes a slotframe. The command requires: slotframe id: the id of the slotframe. Fails if the slotframe id does not exist. 2.4.2.5. Slotframe Command Behavior The following table describes the behavior of 6top upon reception of the Slotframe management commands. Slotframe Management Operations behavior +--------------------------------+----------------------------------+ | 6top commands | 6top behavior | +--------------------------------+----------------------------------+ | Create.slotframe(NumSlot) | MLME-SET-SLOTFRAME.request | | |(operation=ADD) | +--------------------------------+----------------------------------+ | Read.slotframe(SlotframeID) | MLME-GET.request | +--------------------------------+----------------------------------+ | Delete.slotframe(SlotframeID) | MLME-SET-SLOTFRAME.request | | |(operation=DELETE) | +--------------------------------|----------------------------------+ | Update.slotframe(SlotframeID | MLME-SET-SLOTFRAME.request | | ,NumSlot) |(operation=MODIFY) | +--------------------------------+----------------------------------+ 2.4.3. Monitoring Commands Wang, et al. Expires January 14, 2014 [Page 15] Internet-Draft 6tsch-6top July 2013 Monitoring commands provide the means for upper layers to configure whether 6top must ensure the required bandwidth. This procedure is achieved through over-provisioning according to cell status feedback. Monitoring is also in charge of reallocating soft cells that are under the required QoS. The mechanism is described in Section 2.8. 2.4.3.1. CONFIGURE.monitoring Configures the level of QoS the Monitoring process must enforce. The command requires: slotframe id: the id of the slotframe. target node: the destination node. 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. 2.4.3.2. READ.monitoring.status Reads the current Monitoring status. Requires the following parameters. slotframe id: the id of the slotframe. target node: the destination node. 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. Fails if the slotframe id does not exist. Wang, et al. Expires January 14, 2014 [Page 16] Internet-Draft 6tsch-6top July 2013 2.4.3.3. Monitoring Command Behavior The following table describes the behavior of 6top upon reception of the Monitoring management commands. Monitoring Management Operations behavior +------------------------------------+------------------------------+ | 6top commands | 6top behavior | +------------------------------------+------------------------------+ | Configure.monitoring(NeigAdd, | Create/Update Monitoring MIB | | SlotframeID,Enforce) | Starts monitoring service | +------------------------------------+------------------------------+ | Read.monitoring.status(SlotframeID)| Reads 6top Monitoring MIB | +------------------------------------+------------------------------+ Figure 2 2.4.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 the scope of this document but the present commands should be used to configure and read monitored information regardless of the specific metric. 2.4.4.1. CONFIGURE.statistics Configures Statistics process. The command requires: slotframe id: the id of the slotframe. If empty monitors all slotframe ids time slot: slot number to be monitored. If empty all slots are monitored channel offset: specific channel offset to be monitored. If empty all channels are monitored. target node: the destination node. If empty, all target 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. Wang, et al. Expires January 14, 2014 [Page 17] Internet-Draft 6tsch-6top July 2013 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 slot, etc. the CONFIGURE.statistics enables flexible configuration by supporting empty parameters that will force the monitoring of the statistics by all members of that dimension. 2.4.4.2. READ.statistics Reads a metric for the specified dimension. Information is aggregated according to the parameters. The command requires: slotframe id: the id of the slotframe. If empty aggregates information of all slotframe ids time slot: the slot number for which the information is required. If empty all slots are aggregated channel offset: the specific channel offset for which the information is required. If empty all channels are aggregated. target node: the destination node. If empty all target nodes are aggregated. metric: metric to be read. Returns the value for the requested metric. Fails if empty metric or metric does not exits. 2.4.4.3. RESET.statistics Resets the gathered statistics. The command requires: slotframe id: the id of the slotframe. If empty resets the information of all slotframe ids time slot: the slot number for which the information wants to be reset. If empty statistics from all slots are reset channel offset: the specific channel offset for which the information wants to be reset. If empty all statistics for all channels are reset. Wang, et al. Expires January 14, 2014 [Page 18] Internet-Draft 6tsch-6top July 2013 target node: the destination node. If empty all statistics for the target node are reset. metric: metric to be reset. Fails if empty metric or metric does not exits. 2.4.4.4. Statistics Command Behavior The following table describes the behavior of 6top upon reception of the Statistics management commands. Statistics Management Operations behavior +--------------------------------+----------------------------------+ | 6top commands | 6top behavior | +--------------------------------+----------------------------------+ | Configure.statistics | | | (SlotFrameID,TSlot, ChannelOff,| Configures Statistics MIB. | | NeigAdd,Metric,Window,En) | Enables statistics service | +--------------------------------+----------------------------------+ | Read.statistics(SlotFrameID) | Returns the statistic MIB for the| | Ch.Off,NeigAdd,Metric) | requested parameters | +--------------------------------+----------------------------------+ | Reset.statistics(SlotFrameID) | Resets the required statistic MIB| | Ch.Off,NeigAdd,Metric) | | +--------------------------------+----------------------------------+ 2.4.5. Network Formation Commands EBs need to be configured, including their transmission period, the slot number and channel offset that they should be sent on, and the priority announced. The parameters for that command are optional and enable a very 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 configured time slot is allocated. Time slot enforces the EB to a specific time slot. In case time slot parameter is not present, the EB is sent in the first available transmit time slot. In case channel offset parameter is not set, the EB is configured to use the first available channel. Wang, et al. Expires January 14, 2014 [Page 19] Internet-Draft 6tsch-6top July 2013 2.4.5.1. CONFIGURE.eb Configures EBs. The command requires: slotframe id: the id of the slotframe where the EBs MUST be sent. Zero if any slotframe can be used. time slot: the slot number where the EBs MUST be sent. Zero if any timeslot can be used. channel offset: the channel offset where the EBs MUST be sent. Zero if any channel offset can be used. period: the EBs period, in seconds. expires: 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. Fails if the tuple (slotframe id, timeslot, channel offset) is already scheduled. 2.4.5.2. READ.eb Reads the EBs configuration. No parameters are required. Returns the current EBs configuraton for that slotframe, which contains: slotframe id: the slotframe where the EB is being sent. time slot: the slot number where the EBs is being sent. channel offset: the channel offset the EBs is being sent on. period: the EBs period. expires: 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. Wang, et al. Expires January 14, 2014 [Page 20] Internet-Draft 6tsch-6top July 2013 2.4.5.3. Network Formation Command Behavior The following table describes the behavior of 6top upon reception of the Network Configuration management commands. Network Configuration Management Operations behavior +----------------------------------+--------------------------------+ | 6top commands | 6top behavior | +----------------------------------+--------------------------------+ | Configure.EB(SlotFrameID,TSlot, | Configures the 6top MIB | | Ch.Off,Period,Expires,Prio,Con_p)| regarding EB configuration | +----------------------------------+--------------------------------+ | Read.EB() | Reads 6top EB MIB | | | | +----------------------------------+--------------------------------+ 2.4.6. Time Source Neighbor Commands Commands to select time source neighbors. 2.4.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 parent. 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. 2.4.6.2. READ.timesource Retrieves information about the time parents 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 parent. statistics: includes for example minimum, maximum, average time correction for that time parent policy: the used policy Wang, et al. Expires January 14, 2014 [Page 21] Internet-Draft 6tsch-6top July 2013 Fails if the slotframe id or no time source neighbors exist. 2.4.6.3. Time Source Neighbor Command Behavior The following table describes the behavior of 6top upon reception of the Time Source Neighbor Configuration management commands. Time Source Neighbors Configuration Management Operations behavior +---------------------------------+---------------------------------+ | 6top commands | 6top behavior | +---------------------------------+---------------------------------+ | Configure.timesource(Policy) | Configures the 6top MIB | | | regarding timesource parents | +---------------------------------+---------------------------------+ | Read.timesource() | Read 6top timesource MIB | | | | +---------------------------------+---------------------------------+ Figure 3 2.4.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. 2.4.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. 2.4.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. . Wang, et al. Expires January 14, 2014 [Page 22] Internet-Draft 6tsch-6top July 2013 2.4.7.3. READ.neighbor Returns the information of a specific neighbors 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. 2.4.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. 2.4.7.5. DELETE.neighbor Deletes a neighbor given its address. Fails if the neighbor does not exists. 2.4.7.6. Neighbors Command Behavior The following table describes the behavior of 6top upon reception of the Neighbors Configuration management commands. Neighbors Management Operations behavior Wang, et al. Expires January 14, 2014 [Page 23] Internet-Draft 6tsch-6top July 2013 +---------------------------------+---------------------------------+ | 6top commands | 6top behavior | +---------------------------------+---------------------------------+ | Create.neighbor(address,stats) | Adds a neighbor to the neighbor | | | table in the 6top MIB. | +---------------------------------+---------------------------------+ | Read.all.neighbor() | lists all neighbors from the | | | neighbor table. | +---------------------------------+---------------------------------+ | Read.neighbor(address) | Reads neighbor information from | | | neighbor table in the 6top MIB | +---------------------------------+---------------------------------+ | Update.neighbor(address,stats) | Updates an entry for a neighbor | | | in the 6top MIB | +---------------------------------+---------------------------------+ | Delete.neighbor(address) | Removes the neighbor from the | | | 6top MIB | +---------------------------------+---------------------------------+ 2.4.8. Queueing Commands TSCH MAC layer queues need to be configured. This includes queue length, retransmission policy, discarding of packets, etc. 2.4.8.1. CREATE.queue Creates and Configures TSCH 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 back off in number of slotframes. 0 if next available slot 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 Wang, et al. Expires January 14, 2014 [Page 24] Internet-Draft 6tsch-6top July 2013 Returns the queue id. 2.4.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. age: maximum age of a packet befoer being discarded. 0 if no discards are allowed. rtxbackoff: retransmission backoff in number of slotframes. 0 if next available slot is used. 2.4.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. 2.4.8.4. UPDATE.queue Update a TSCH Queue. The command requires: queueid: the queue id. Wang, et al. Expires January 14, 2014 [Page 25] Internet-Draft 6tsch-6top July 2013 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 slot wants to be used. statswindow: window of time used to compute stats. queue priority: the desired priority of this queue. TrackIDs: the desired set of TrackIDs. 2.4.8.5. DELETE.queue Deletes a TSCH Queue. The command requires the queue id. All packets in the queue are discarded and the queue is deleted. 2.4.8.6. Queueing Command Behavior The following table describes the behavior of 6top upon reception of the Queue management commands. Queue Management Operations behavior Wang, et al. Expires January 14, 2014 [Page 26] Internet-Draft 6tsch-6top July 2013 +---------------------------------+---------------------------------+ | 6top commands | 6top behavior | +---------------------------------+---------------------------------+ | Create.queue(tqlen,trlen,numrtx,| Creates a queue with specified | | age,rtxbackoff,prio,TrackIDs) | parameters. Updates 6top MIB. | +---------------------------------+---------------------------------+ | Read.queue(id) | Reads the queue configuration | | | from 6top MIB. | +---------------------------------+---------------------------------+ | Update.queue(id,tqlen,trlen, | Updates the queue configuration | | numrtx,age,rtxbackoff, | from 6top MIB. Readjustes actual| | prio, TrackIDs) | queue size if required. | +---------------------------------+---------------------------------+ | Delete.queue(id) | Deletes the queue from MIB. | | | | +---------------------------------+---------------------------------+ | Read.queue.stats() | Reads the queue | | | stats from 6top MIB. | +---------------------------------+---------------------------------+ 2.4.9. Security Commands The following commands are used to manage underlying layer security. In that case 6top acts as delegating interface to IEEE802.15.4 security configuration commands. 2.4.9.1. CONFIGURE.security Enables/Disables Security and configures the MAC PIB. The command requires: enable: enables underlying layer security. macAutoRequestSecurityLevel: the security level used for automatic data requests as described by IEEE 802.15.4 table 61. macAutoRequestKeyIdMode: the key identifier mode used for automatic data requests as described by IEEE 802.15.4 table 61. macAutoRequestKeySource: the originator of the key for automatic data requests as described by IEEE 802.15.4 table 61. macAutoRequestKeyIndex: the index of the key used for automatic data requests as described by IEEE 802.15.4 table 61. macDefaultKeySource: the originator of the default key used for key identifier mode 0x01 as described by IEEE 802.15.4 table 61. Wang, et al. Expires January 14, 2014 [Page 27] Internet-Draft 6tsch-6top July 2013 macPANCordinatorExtendedAddress: Address of the PAN coordinator as described by IEEE 802.15.4 table 61. macPANCordinatorShortAddress: Short address of the PAN coordinator as described by IEEE 802.15.4 table 61. 2.4.9.2. CONFIGURE.security.macKeyTable Configures Security Keys. The command requires: KeyIdLookupList: list of keyIdLookupDescriptor Entries as defined by IEEE 802.15.4 table 61. DeviceDescriptorHandleList: Implementation specific list of devices that are using this key. As defined by IEEE 802.15.4 table 61. KeyUsageList: List of slotframe types on which this key is being used as specified by IEEE 802.15.4 section 7.4.1.2 Key: 16 octets key. As specified by IEEE 802.15.4 table 61. 2.4.9.3. CONFIGURE.security.macSecurityLevelTable Configures the set of security levels. The command requires: FrameType: Slotframe type as defined by IEEE802.15.4e std. Command Identifier: The command identifier as defined by IEEE802.15.4e std. Security Minimum: The minimum required security level as specified by IEEE 802.15.4e Device Override Security Minimum: whether the minimum security level can be overridden as specified by IEEE 802.15.4 Table 64 Allowed Security Levels: the key identifier field that identifies the key that is being used as specified by IEEE 802.15.4 section 7.4.3 2.4.9.4. Security Command Behavior 6top offers the interface to upper layers so underlying MAC layer can be configured. In that sense, 6top acts as a "none-layer" by only delegating the functionalities to the MAC security services. For more details Section 7 on IEEE802.15.4-2011 and its amendments on IEEE802.15.4e-2012 should be referred. Wang, et al. Expires January 14, 2014 [Page 28] Internet-Draft 6tsch-6top July 2013 2.4.10. Data Commands 2.4.10.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 the scope of this document. Once a packet is inserted into a queue it waits to be transmitted by TSCH according to the model defined in Section 2.3. The required parameters are: src address: L2 source address 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 securityLevel:As defined by IEEE802.15.4e std. 2.4.10.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 provide an implementation for that method. The function has the following parameters: src address: L2 source address 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 2.4.10.3. Data Command Behavior Wang, et al. Expires January 14, 2014 [Page 29] Internet-Draft 6tsch-6top July 2013 The following table describes the behavior of 6top upon reception of the Data Communication Configuration management commands. Data Communication Management Operations behavior +---------------------------------+---------------------------------+ | 6top commands | 6top behavior | +---------------------------------+---------------------------------+ | Send.data(src,dest,prio, | The message is inserted in the | | len,msg,seclevel) | the queue corresponding to the | | | required priority. Fails if the | | | queue is full. Fails if the | | | destination address is not a | | | L2 neighbor of the node. | +---------------------------------+---------------------------------+ | Receive.data(src,dest,prio,len, | The method is invoked whenever a| | msg) | message is inserted in the queue| | | after successful reception. | +---------------------------------+---------------------------------+ Figure 4 2.4.11. Label Switching Commands 2.4.11.1. LabelSwitching.map The command used by upper layers to map one 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 (time slot, frequency offset, destination address). output cells: list of output cells (one or more cells in a bundle). Each output cells is described by an unique tuple (time slot, frequency offset, destination address). load balancing policy: A policy for load balance cell usage. The policy is out of the scope of this document, however an example can be use ROUND ROBIN policy within the cells of the same bundle. 2.4.11.2. LabelSwitching.unmap Wang, et al. Expires January 14, 2014 [Page 30] Internet-Draft 6tsch-6top July 2013 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 (time slot, frequency offset, destination address). output cells: list of output cells (one or more cells in a bundle). Each output cells is described by an unique tuple (time slot, frequency offset, destination address). 2.4.11.3. Label Switching Command Behavior The following table describes the behavior of 6top sublayer upon reception of the Label Switching Commands. Data Communication Management Operations behavior +---------------------------------+---------------------------------+ | 6top commands | 6top behavior | +---------------------------------+---------------------------------+ | LabelSwitching.map(src,dest, | The 6top sublayer label mapping | | policy) | table is configured with the | | | input and output cells bindings.| | | According to the policy a | | | monitoring mechanism is started | | | so load balancing can be | | | enforced. | +---------------------------------+---------------------------------+ | LabelSwitching.unmap(src,dest) | The src and dst cells are | | | removed from the mapping table | | | and any load balancing policy | | | is disabled. | +---------------------------------+---------------------------------+ Figure 5 2.5. Message Formats 6top has to negotiate the scheduling of soft cells with neighbor nodes. This negotiation happens through 6top-specific TSCH Information Elements, the format of which is defined in this section. This section also details the formats of the IEs defined in [IEEE802154e] and reused without modification. Wang, et al. Expires January 14, 2014 [Page 31] Internet-Draft 6tsch-6top July 2013 6top messages can contain one or more IEs. Section 2.5.1 defines the different IEs used by 6top, both the ones used without modification from [IEEE802154e], and the new ones defined by 6top. Section 2.5.2 shows how those IEs are assembled to form the different packets used by 6top. 2.5.1. Information Elements IEEE802.15.4e defines Information elements (IEs) which are formatted data objects consisting of an ID, a length, and a data payload used to pass data between layers or devices. IEEE802.15.4e defines Header IEs and Payload IEs; 6top only uses Payload IEs. A Payload IE includes one or more IEs, and ends with a termination IE (ID = 0xf, see [IEEE802154e]). 6top uses the following Information Elements, some defined in IEEE802.15.4e, others introduced in this document. Defined in [IEEE802154e] and used by 6top without modification: TSCH Synchronization IE (Section 2.5.1.1) TSCH Slotframe and Cell IE (Section 2.5.1.2) TSCH Timeslot Template IE (Section 2.5.1.3) TSCH Channel Hopping IE (Section 2.5.1.4) Defined by 6top: 6top Opcode IE (Section 2.5.1.5) 6top Bandwidth IE (Section 2.5.1.6) 6top TrackID IE (Section 2.5.1.7) 6top Generic Schedule IE (Section 2.5.1.8) 2.5.1.1. TSCH Synchronization IE A Synchronization IE (SyncIE) contains Information allowing a node to synchronize to a TSCH network, including the current ASN and a join priority. Synchronization IE must be included in all TSCH Enhanced Beacons. Wang, et al. Expires January 14, 2014 [Page 32] Internet-Draft 6tsch-6top July 2013 6top re-uses this IE as defined in [IEEE802154e]. Format of a TSCH Synchronization IE (SyncIE). 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | SubID |T| ASN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASN | Join Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 Length=6 SubID=0x1a T=0, i.e. short type ASN (5 octets) contains the Absolute Slot Number corresponding to the timeslot in which the TSCH Enhanced Beacon is sent. The Join Priority can be used by a joining device to select among beaconing devices when multiple beacons are heard. The PAN coordinator's join priority is zero. A lower value of join priority indicates that the device is the preferred one to connect to. The beaconing device's join priority is the lowest join priority heard when it joined the network plus one. 2.5.1.2. TSCH Slotframe and Cell IE The Slotframe and Cell IE (FrameAndCellIE) contains one or more slotframes and their respective cells that a beaconing device advertises to allow other devices to join the network. 6top re-uses this IE as defined in [IEEE802154e]. Wang, et al. Expires January 14, 2014 [Page 33] Internet-Draft 6tsch-6top July 2013 Format of a TSCH Slotframe and Cell IE (FrameAndCellIE). 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | SubID |T| NumFrame | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | // Slotframe and cell information // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 Length=variable SubID=0x1b T=0, i.e. short type NumFrame is set to the total number of slotframe descriptors contained in the TSCH Enhanced Beacon. Format of a slotframe descriptor. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FrameID | FrameLen | NumCell | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Cell information for each cell (5x NumCell) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8 The FrameID field shall be set to the slotframeHandle that uniquely identifies the slotframe. The FrameLen field shall be set to the size of the slotframe in number of timeslots. The NumCell field shall be set to the number of cells that belong to the specific slotframe identified by the slotframeHandle. Format of a Cell information. Wang, et al. Expires January 14, 2014 [Page 34] Internet-Draft 6tsch-6top July 2013 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SlotOffset | ChannelOffset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LinkOption | +-+-+-+-+-+-+-+-+ Figure 9 SlotOffset shall be set to the timeslot of this cell. ChannelOffset shall be set to the logic channel of this cell. LinkOption indicates whether this cell is a TX cell, an RX cell, or a SHARED TX cell, whether the device to which it is being linked is to be used for clock synchronization, and whether this cell is hard cell. 2.5.1.3. TSCH Timeslot Template IE Timeslot Template IE (SlotTemplateIE) defines Timeslot template being used by the TSCH device. 6top re-uses this IE as defined in [IEEE802154e]. Format of a TSCH Timeslot Template IE (SlotTemplateIE). 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | SubID |T| TemplateID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10 Length=1 SubID=0x1c T=0, i.e. short type TemplateID shall be set to a Timeslot template handle. The full time-slot template, which contains the macTimeslotTemplate of TSCH (total 25 octets), may be included.(see IEEE802.15.4e). 2.5.1.4. TSCH Channel Hopping IE Channel Hopping IE (ChHoppingIE) defines the Hopping Sequence being used by the TSCH device. Wang, et al. Expires January 14, 2014 [Page 35] Internet-Draft 6tsch-6top July 2013 6top re-uses this IE as defined in [IEEE802154e]. Format of a TSCH Channel Hopping IE (ChHoppingIE). 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | SubID |T| HopSequenceID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11 Length=1 SubID=0x09 T=1, i.e. long type HopSequenceID shall be set to a Hopping Sequence handle. The full Hopping Sequence information may be included. (see IEEE802.15.4e). 2.5.1.5. 6top Opcode IE 6top Opcode IE (OpcodeIE) defines operation codes of packets in 6top sublayer. This IE is not present in [IEEE802154e] and is defined by 6top. Format of a 6top Opcode IE (OpcodeIE). 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | SubID |T| OpcodeID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12 Length=1 SubID=0x41 T=0, i.e. short type OpcodeID field shall be set to one of the following codes. 0x00: Reserve Soft Cell Request 0x01: Reserve Soft Cell Response Wang, et al. Expires January 14, 2014 [Page 36] Internet-Draft 6tsch-6top July 2013 0x02: Remove Soft Cell Request 0x03: Reserve Hard Cell Request 0x04: Remove Hard Cell Request 2.5.1.6. 6top Bandwidth IE Bandwidth IE (BwIE) defines the number of cells to be reserved or actually be reserved. This IE is not present in [IEEE802154e] and is defined by 6top. Format of a 6top Bandwidth IE (BwIE). 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | SubID |T| FrameID | NumCell | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13 Length=2 SubID=0x42 T=0, i.e. short type FrameID may be set to the SlotFrameHandle to identify the slotframe from which cells are reserved. FrameID field may be set to NOP, which means no specific slotframe is associated. NumCell shall be set to the number of cells. When BwIE is combined with the OpecodeID of Reserve Soft Cell Request, NumCell presents how many cells are required to reserve; and when BwIE is combined with the OpecodeID of Reserve Soft Cell Response, NumCell presents how many cells are reserved successfully. 2.5.1.7. 6top TrackID IE TrackID IE (TrackIdIE) describes the track which the reserved/removed cell(s) are associated with. This IE is not present in [IEEE802154e] and is defined by 6top. Format of a 6top TrackID IE (TrackIdIE). Wang, et al. Expires January 14, 2014 [Page 37] Internet-Draft 6tsch-6top July 2013 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | SubID |T|OwnerInstID|rev| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | // // | TrackOwnerAddr | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14 Length=3 or 7. When length=3, TrackOwnerAddr is 2 bytes short address, and when length=7, TrackOwnerAddr is 6 bytes long address. SubID=0x43 T=0, i.e. short type The combination of TrackOwnerAddr and OwnerInstId represents a specific TrackID. 2.5.1.8. 6top Generic Schedule IE Generic Schedule IE (ScheduleIE) describes cell sets. In different packets, ScheduleIE represents different information. See Section 2.5.2 for more detail. This IE is not present in [IEEE802154e] and is defined by 6top. Format of a 6top Generic Schedule IE (ScheduleIE). 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | SubID |T| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | // Schedule Body // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15 Length=variable SubID=0x44 T=0, i.e. short type Wang, et al. Expires January 14, 2014 [Page 38] Internet-Draft 6tsch-6top July 2013 Schedule Body carries one or more schedule object. An object may carry a TLV, which may itself comprise other TLVs. TLV format is as follows. Type: 1 byte, Length: 1 byte, Value: variable The following are some examples of schedule object TLV. Example 1. Cell Set TLV 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=1 | Length | FrameID | NumCell |F| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // CellObjects // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16 FrameID shall be set to the slotframeHandle that uniquely identifies the slotframe. NumCell shall be set to the number of cells that belong to the specific slotframe identified by the slotframeHandle. F=1 means the specified cells equals to what are listed in CellObjects, and F=0 means the specified cells equals to what are not listed in CellObjects. CellObjects carries the information for one or more cells, including SlotOffset, ChannelOffset, LinkOption (Figure 9). Example 2. Schedule Matrix TLV 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=2 | Length | FrameID |StartSlotOffset| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |StartSLotOffset| NumSlot | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | // SlotBitMap (2x NumSlot) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 17 Wang, et al. Expires January 14, 2014 [Page 39] Internet-Draft 6tsch-6top July 2013 FrameID field shall be set to the slotframeHandle that uniquely identifies the slotframe. StartSlotOffset field (2 octets) shall be set to the slotoffset in the specific slotframe identified by the slotframeHandle. NumSlot field shall be set to the number of slots from StartSlotOffset in the specific slotframe identified by the slotframeHandle. SlotBitMap (per slot) indicates for the given slot which channels are specified. For the 16 channels in 2.4GHz band, 2-octets are used to indicate which channel is specified. For example, given a slot and a SlotBitmap with value (10001000,00010000); the bitmap represents that ChannelOffset-0, ChannelOffset-4, ChannelOffset-11 are specified. 2.5.2. Packet Formats This section describes the packets used in 6top to form a network, reserve/maintain bandwidth using soft cells, and reserve/remove hard cells in both Tx side and Rx side. Each of these packets use one or more IEs defined in Section 2.5.1. 2.5.2.1. TSCH Enhanced Beacon The TSCH Enhanced Beacon is used to announce the presence of the network and allows new nodes to join. It is an IEEE802.15.4e Enhanced Beacon packet with the following Payload IEs: TSCH Synchronization IE (Section 2.5.1.1) TSCH Timeslot Template IE (Section 2.5.1.3) TSCH Channel Hopping IE (Section 2.5.1.4) TSCH Slotframe and Cell IE (Section 2.5.1.2) Payload IE of TSCH Enhanced Beacon Packet Wang, et al. Expires January 14, 2014 [Page 40] Internet-Draft 6tsch-6top July 2013 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length |GroupID|T| SyncIE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SyncIE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SyncIE | SlotTemplateIE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |SlotTemplateIE | ChHoppingIE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // FrameAndCellIE // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 18 Length=variable GroupID=0x1, i.e. MLME IE T=1, i.e. payload IE See Section 2.5.1.1, Section 2.5.1.3, Section 2.5.1.4,Section 2.5.1.2 for SyncIE, SlotTemplateIE, ChHoppingIE and FrameAndCellIE. 2.5.2.2. Soft Cell Reservation Request A Soft Cell Reservation Request packet is an IEEE802.15.4e data packet with the following payload IE. Payload IE of Soft Cell Reservation Request 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length |GroupID|T| OpcodeIE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OpcodeIE | BwIE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BwIE | | +-+-+-+-+-+-+-+-+ | // ScheduleIE // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 19 Length=variable Wang, et al. Expires January 14, 2014 [Page 41] Internet-Draft 6tsch-6top July 2013 GroupID=0x1, i.e. MLME IE T=1, i.e. payload IE The OpcodeID field in the 3-octet OpcodeIE should be set to 0x00, indicates Reserve Soft Cell Request operation. The NumCell field in 4-octet BwIE should be set to the number of cells needed to be reserved. The ScheduleIE specifies a candidate cell set, from which the cells should be reserved. ScheduleIE may be empty, means there is no constrain on which cells should not be reserved. In addition, TrackIdIE can be added in the packet to associate the reserved soft cells to a specific TrackID. 2.5.2.3. Soft Cell Reservation Response Soft Cell Reservation Response is an IEEE802.15.4e data packet with the following payload IE. Payload IE of Soft Cell Reservation Response 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length |GroupID|T| OpcodeIE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OpcodeIE | BwIE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BwIE | | +-+-+-+-+-+-+-+-+ | // ScheduleIE // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 20 Length=variable GroupID=0x1, i.e. MLME IE T=1, i.e. payload IE The OpcodeID field in the 3-octet OpcodeIE should be set to 0x01, indicates Reserve Soft Cell Response operation. Wang, et al. Expires January 14, 2014 [Page 42] Internet-Draft 6tsch-6top July 2013 The NumCell field in 4-octet BwIE should be set to the number of cells which have been reserved successfully. The ScheduleIE should specify all of the cells which have been reserved successfully. In addition, TrackIdIE can be added in the packet to associate the reserved soft cells to a specific TrackID. 2.5.2.4. Soft Cell Remove Request Soft Cell Remove Request is an IEEE802.15.4e data packet with the following payload IE. Payload IE of Soft Cell Remove Request 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length |GroupID|T| OpcodeIE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OpcodeIE | | +-+-+-+-+-+-+-+-+ | // ScheduleIE // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 21 Length=variable GroupID=0x1, i.e. MLME IE T=1, i.e. payload IE The OpcodeID field in the 3-octet OpcodeIE should be set to 0x02, indicates Remove Soft Cell Request operation. The ScheduleIE should specify all the cells that need to be removed. 2.5.2.5. Hard Cell Reservation Request Hard Cell Reservation Request packet is an IEEE802.15.4e data packet with the following payload IE. Payload IE of Hard Cell Reservation Request Wang, et al. Expires January 14, 2014 [Page 43] Internet-Draft 6tsch-6top July 2013 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length |GroupID|T| OpcodeIE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OpcodeIE | | +-+-+-+-+-+-+-+-+ | // ScheduleIE // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 22 Length=variable GroupID=0x1, i.e. MLME IE T=1, i.e. payload IE The OpcodeID field in the 3-octet OpcodeIE should be set to 0x03, indicates Reserve Hard Cell Request operation. The ScheduleIE should specify all the cell that need to be reserved. In addition, TrackIdIE can be added in the packet to associate the reserved hard cells to a specific TrackID. 2.5.2.6. Hard Cell Remove Request Hard Cell Remove Request is an IEEE802.15.4e data packet with the following payload IE. Payload IE of Hard Cell Remove Request 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length |GroupID|T| OpcodeIE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OpcodeIE | | +-+-+-+-+-+-+-+-+ | // ScheduleIE // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 23 Length=variable GroupID=0x1, i.e. MLME IE Wang, et al. Expires January 14, 2014 [Page 44] Internet-Draft 6tsch-6top July 2013 T=1, i.e. payload IE The OpcodeID field in the 3-octet OpcodeIE should be set to 0x04, indicates Remove Hard Cell Request operation. The ScheduleIE should specify all the cells that need to be removed. 2.6. Time Sequence 6top neighbors exchange 6top-specific packets in the following cases, each detailed in a subsection. Network formation is detailed in Section 2.6.1. Creating soft cells is detailed in Section 2.6.2. Deleting soft cells is detailed in Section 2.6.3. Maintaining soft cells is detailed in Section 2.6.4. Creating hard cells is detailed in Section 2.6.5. Deleting hard cells is detailed in Section 2.6.6. 2.6.1. Network Formation Network formation consists of two processes: joining and maintenance. 2.6.1.1. Joining A node already in the network sends out TSCH Enhanced Beacons periodically. When a node is joining an existing network, it listens for TSCH Enhanced Beacons. After collecting one or more TSCH Enhanced BEACONs (the format of which is detailed in Section 2.5.2.1), the joining node must do the following. Initialize a neighbor table. Establish a neighbor table and record all of the information described in the TSCH Enhanced BEACONs as its initial schedule with those neighbors. Select a time source neighbor. According to the Joining Priority described by SyncIEs, the joining node chooses one or more of the advertisers as its time source neighbors. 6top does not specify the criteria to choose time source neighbors from the Enhanced BEACONs. Wang, et al. Expires January 14, 2014 [Page 45] Internet-Draft 6tsch-6top July 2013 Select cells for Enhanced Beacons. The joining node selects one or more cells to broadcast its own Enhanced Beacons, which may be same as the cells used by its neighbors for Enhanced Beacon broadcast, and record those cell(s) into the TSCH schedule with LinkType=ADVERTISING. From its Enhanced Beacons, including the cell(s) for its Enhanced Beacon, which LinkOption should be set to "Receive" and "Timekeeping", telling its neighbors that the cell is used for broadcast. Start broadcasting Enhanced Beacon and communicate with neighbors. 2.6.1.2. Maintenance Nodes may broadcast Enhance Beacons on the cells marked with LinkType=ADVERTISING, and listen for Enhanced Beacons from neighbors on the cells with LinkOption = "Receive" and "Timekeeping". If a cell with both LinkType=ADVERTISING has both the "Receive" and "Timekeeping" LinkOption, it is shared by neighbors and itself to broadcast, then broadcast Enhanced Beacon has higher priority. Whenever a node receives an Enhanced Beacon, it must update its schedule if there is a difference. 2.6.2. Creating soft cells The upper layer instructs 6top to schedule one or more soft cells by calling the Create soft cell command. This command can also be called by the monitoring process internal to 6top. Wang, et al. Expires January 14, 2014 [Page 46] Internet-Draft 6tsch-6top July 2013 When receiving a Create soft cell command, Node A's 6top sublayer forms a Soft Cell Reservation Request packet which includes BwIE and ScheduleIE. The BwIE includes the number of cells needed to be reserved (N1), and ScheduleIE includes a candidate cell set from which the new cells should be selected. If the ScheduleIE is empty, Node A indicates there is no constraint on cell selection. The Soft Cell Reservation Request is then sent to the neighbor (Node B) with whom new cells need to be added. After receiving the Soft Cell Reservation Request, Node B selects the cells from the candidate cell set defined by the ScheludeIE in the Soft Cell Reservation Request, and forms a Soft Cell Reservation Response packet, in which BwIE indicates the number of cells actually being reserved (N2), and ScheduleIE indicates those reserved cells. If N2 is smaller than N1, node B indicates to node A that there are not enough qualified cells to be reserved. Node B must record the reserved cells into its local schedule while sending out Soft Cell Reservation Response. After receiving the Soft Cell Reservation Response, Node A must record the reserved cells into its local schedule. The policy to build a candidate cell set and the policy to select cells from the candidate cell set to reserve is flexiable. For example, the candidate cell set can be all of the cells not used by Node A, and Node B can randomly choose N1 cells, which are not used by Node B, from the candidate cell set. The expression of Schedule Body is flexible. For example, Node A can use Cell Set TLV defined in Figure 16 with field 'F' set to '0', and the CellObjects includes all of the cells being used by Node A. In another word, the cell candidate set is all of the cells not being included in the list defined by CellObjects. The policy to deal with the failure or not fully satisfaction in a soft cell Reservation process is flexible. For example, Node A may initiate another soft cell reservation procedure, or simply report to upper layer. 2.6.3. Deleting soft cells The upper layer instructs 6top to delete one or more soft cells by calling the Delete soft cell command. This command can also be called by the monitoring process internal to 6top. When receiving a Delete soft cell command, Node A's 6top sublayer selects cells to be removed from its local schedule, and creates a Soft Cell Remove Request, including a ScheduleIE. The ScheduleIE indicates which specific cells to remove with a neighbor (Node B). The cells specified in the ScheduleIE should be removed from local schedule of Node A while the Soft Cell Remove Request is sent to Node Wang, et al. Expires January 14, 2014 [Page 47] Internet-Draft 6tsch-6top July 2013 B. When receiving the Soft Cell Remove Request, the cells specified in the ScheduleIE should be removed from the local schedule of Node B. The policy to select cells corresponding to a Delete soft cell command is out of scope. 2.6.4. Maintaining soft cells The monitoring process internal to 6top (Section 2.8) is responsible for monitoring and re-scheduling soft cells to meet some QoS requirements. The monitoring process may issue a soft cell Maintenance command, which indicate a set of cells to be moved in the TSCH schedule. When a receiving a soft cell Maintenance command, 6top initializes a Soft Cell Remove Request (Section 2.6.3) with the neighbor in question, followed by a Soft Cell Reservation Request (Section 2.6.2). 2.6.5. Creating hard cells The upper layer instructs 6top to create one or more hard cells by calling the Create hard cell command. When receiving a Create hard cell command, Node A's 6top sublayer creates a Hard Cell Reservation Request, including a ScheduleIE. The ScheduleIE indicates which specific cells with a neighbor (Node B) to be added. The cells specified in the ScheduleIE should be added in local schedule of Node A while the Hard Cell Reserve Request is sent to Node B. When receiving the Hard Cell Reserve Request, the cells specified in the ScheduleIE should be added in the local schedule of Node B. 2.6.6. Deleting hard cells The upper layer instructs 6top to delete one or more hard cells by calling the Delete hard cell command. When receiving a Delete hard cell command, Node A's 6top sublayer creates a Hard Cell Remove Request, including a ScheduleIE. The ScheduleIE indicates which specific cells with a neighbor (Node B) to be removed. The cells specified in the ScheduleIE should be removed from local schedule of Node A while the Hard Cell Remove Request is sent to Node B. When receiving the Hard Cell Remove Request, the cells specified in the ScheduleIE should be removed from the local schedule of Node B. Wang, et al. Expires January 14, 2014 [Page 48] Internet-Draft 6tsch-6top July 2013 2.7. Statistics The 6top Statistics Fuction (SF) is responsible for collecting statistics, which it can provide to an upper layer and the Monitoring Function (Section 2.8). 2.7.1. Statistics Metrics 6top is in charge of keeping statistics from a set of metrics gathered from the behavior of the TSCH layer. The statistics data related to node states and cell metrics should be provided to upper layer for management, e.g. for RPL to calculate Rank or to GMPLS to determine whether the link in a multi-hop path is meeting the required bandwidth. The specific algorithm to generate the statistics is implementation dependent and hence out of the scope of this document. However, the statistics component should include the following metrics: 1. LinkThroughput: associated with a link, Node A->Node B. For example, LinkThroughput can be calculated with: SUM(NumOfCell(i)*NumOfBytePerPacket)/(FrameLen(i)*SlotDuration) where NumOfCell(i) is the total number of cells from Node A to Node B in Slotframe-i, FrameLen(i) is the length of Slotframe-i. 2. Latency: associated with a link, Node A->Node B. For example, latency can be expressed as Minimum and Maximum Latency. Minimum Latency = Min(MinNumOfSlot(i),i=1..) * SlotDuration and Maximum Latency = Max(MaxNumOfSlot(i),i=1..) * SlotDuration where, MinNumOfSlot(i) and MaxNumOfSlot(i) are the minimum or maximum number of slots between two dedicated cells from Node A to Node B in Slotframe-i, respectively. 3. LinkQuality. For example, average LQI, ETX; 4. TafficLoad. For example, Queue Full Rate, Queue Empty Rate; 5. NodeEnergy. For example, E_E=E_bat / [E_0 (T-t)/T]. 2.7.2. Statistics Configuration Statistics Function should be configurable. The configuration parameters should include: LinkQualityStatisticsEn. TafficLoadStatisticsEn. Wang, et al. Expires January 14, 2014 [Page 49] Internet-Draft 6tsch-6top July 2013 DeviceStatisticsEn. 6top statistics function is enabled/disabled and configured by the commands defined in Section 2.4.4 2.8. Monitoring The 6top Monitoring Fuction (MF) is responsible for monitoring cell quality, traffic load, and issuing soft cell Maintenance command, or Create/Delete soft cell command. The data provided by Statistics Function may be used as a input of MF in making monitoring decision. 2.8.1. Monitor Configuration Monitoring Function should be configurable. The configuration parameters should include: MaintainCellEn. CreateDeleteCellEn. QosLevel. QosLevel should associate with specific neighbor address. QosLevel may reflect the latency constraint, cell quality constraint, and so on. The value of QosLevel works as the bandwidth redundancy coefficient. 6top monitoring function is enabled/disabled and configured by the commands defined in Section 2.4.3 2.8.2. Actuation The cell quality statistics may be used to generate soft cell Maintenance command, which leads to a soft cell Maintenance procedure (see Section 2.6.4). The traffic load statistics may be used to generate internal Create/Delete soft cell commands, which leads to a soft cell Reservation process or a soft cell Remove process, respectively. (see Section 2.6.2 and Section 2.6.3) The policy to generate the soft cell Maintenance command and the policy to generate Create/Delete soft cell commands is out of the scope. The policy to generate Create/Delete soft cell commands may take QosLevel into account. For example, there are two slotframes existing, Slotframe-1 consists of 32 slots, Slotframe-2 consists of 96 slots; Slot duration is 10ms; QosLevel=1.5. If, from the traffic load statistics, MF figures out 2 packet/second should be added, then it leads to a Create soft cell command, where FrameID=2, NumCell=3. Wang, et al. Expires January 14, 2014 [Page 50] Internet-Draft 6tsch-6top July 2013 2.9. Label Switching Label Switching Fuction (LS) in 6top is responsible for maintaining the mapping of input cells and output cells in the same track in a particular node. By keeping that mapping, layer 3 routing can be avoided as packets are forwarded by the 6top sublayer according to the input cells they were received on. The selected output cell is one of the cells that forward the packet to the subsequent hop in the track. As cells can be grouped in bundles, 6top can maintain mappings from input bundles to output bundles and provide a policy to select the output cell according to the input cell. 3. Using 6top This part describes how 6top gives support to specific upper layers. 3.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 3.1.1. Support to Neighbor Discovery and Parent Selection The Section 2.4.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 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 Wang, et al. Expires January 14, 2014 [Page 51] Internet-Draft 6tsch-6top July 2013 can be used to compute the routing objective function as for example the inverse of the Probability Delivery Ratio (PDR). 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 2.4.4 and Section 2.7. 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 2.4.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 2.4.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. 3.1.2. Support of Rank Computation The RPL objective function is computed using a set of metrics. The specific metrics and how the objective function is calculated are out of the scope of the present document, however, 6top builds a set of functionalities to provide more accurate statistics of the underlying layer so the objective function can be accommodated to the nature of a TSCH MAC layer. 6top provides statistics for rank computation as described in sections Section 2.4.4 and Section 2.7. The function used to compute the rank based on those statistics is out of scope of 6top, however the provided metrics are aligned to the behavior of the TSCH MAC layer. Wang, et al. Expires January 14, 2014 [Page 52] Internet-Draft 6tsch-6top July 2013 3.1.3. Support of Control Messages Broadcast In RPL, some control messages, e.g. DIO and DAO 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 FrameAndCellIE, and its LinkOption field should be set to the combination of "Receive" and "Timekeeping". The receiver of the Enhanced Beacon may listen to 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 broadcast, 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 FrameAndCellIE as described above, the data packet with DIO or DAO in payload can be received by neighbors, which leads to the maintenance of DODAG. The LinkOption of combining "Receive" and "Timekeeping" let the receivers of the Enhanced Beacon understand that the cell is used as broadcast cell. But the frequency of sending Enhance Beacon or other broadcast messages by upper layer is determined by the timers associated with the messages, e.g. Enhance Beacon is triggered by the timer in 6top, and the DIO message is triggered by the trickle timer of RPL. Therefore, for energy efficiency, receivers can have some policy to wake up at the broadcast cell, but it is implementation dependent. 3.1.4. Support to QoS TSCH MAC layer is decoupled from the upper layers and its interaction with them is asynchronous. This means that the MAC layer executes a schedule and checks at each slot according to the type of cell whether there is something to send or receive. If that is the case the packet is sent and the MAC layer continues its operation. When an upper layer sends a packet, this packet is pushed into a queue Wang, et al. Expires January 14, 2014 [Page 53] Internet-Draft 6tsch-6top July 2013 waiting to the MAC layer to read it and sent it in a particular slot according to is destination and priority (Section 2.3). 6top provides a set of queue management operations which enable upper layers to create different queues and determine their priorities. In that sense different classes of traffic can be handled by the routing layer, i.e inserting a packet to a specific queue according to its priority. 6top provides at least a Broadcast Queue, a Transmit Queue, and a Receive Queue. RPL can configure the queues with Internal Queueing Command (Section 2.4.8.1). Broadcast Queue are associated with cells with LinkType=ADVERTISING in sender's schedule, and LinkOption="Receive" and "Timekeeping" in all neighbors' schedule. That indicates the cells can be used for broadcast from the sender to its neighbors. Transmit Queues are associated with the dedicated Transmit cells or Shared Cells. RPL can benefit from having different priority queues in order to improve latency or provide integrated services with different priorities, i.e different traffic classes. Data Communication Command (Section 2.4.10) 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 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 feed it to TSCH at the cell, otherwise checks broadcast/unicast queue with lower priority further. Repeat the process, until find a broadcast/ unicast packet to feed to TSCH or find all of broadcast/unicast queues are empty. Wang, et al. Expires January 14, 2014 [Page 54] Internet-Draft 6tsch-6top July 2013 3.2. GMPLS on 6top GMPLS is a 2.5 layer service that is used to forward packets based on the concept of generalized label. 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 appended to each packet as is the case in MPLS [RFC3031], the generalized label it 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 3.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 2.4.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 of this document, but 6top is able to handle a reservation done as a specific bandwidth requirement, done through specifying exact cells. 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 2.4.8) to manage MAC layer queues and assign different priorities to them. 3.2.2. Supporting QoS GMPLS can use 6top statistics to determine whether some QoS requirement is met. Metrics defined in Section 2.7 and operations defined in Section 2.4.4.4 can be used by GMPLS to trigger new bandwidth allocation, or to map different input bundles to output bundles. Wang, et al. Expires January 14, 2014 [Page 55] Internet-Draft 6tsch-6top July 2013 4. References 4.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 4.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. [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. Wang, et al. Expires January 14, 2014 [Page 56] Internet-Draft 6tsch-6top July 2013 [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. [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-6tsch-architecture] Thubert, P., Assimiti, R., and T. Watteyne, "An Architecture for IPv6 over Time Slotted Channel Hopping", draft-thubert-6tsch-architecture-01 (work in progress), April 2013. Wang, et al. Expires January 14, 2014 [Page 57] Internet-Draft 6tsch-6top July 2013 [I-D.palattella-6tsch-terminology] Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, "Terminology in IPv6 over Time Slotted Channel Hopping", draft-palattella-6tsch-terminology-00 (work in progress), March 2013. [I-D.vilajosana-6tsch-basic] Vilajosana, X., "Minimal 6TSCH Configuration", draft- vilajosana-6tsch-basic-00 (work in progress), June 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-01 (work in progress), February 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. [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., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-12 (work in progress), March 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-04 (work in progress), February 2013. Wang, et al. Expires January 14, 2014 [Page 58] Internet-Draft 6tsch-6top July 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. 4.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) Amendament 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. Wang, et al. Expires January 14, 2014 [Page 59] Internet-Draft 6tsch-6top July 2013 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 Thomas Watteyne Linear Technology 30695 Huntwood Avenue Hayward, CA 94544 USA Phone: +1 (510) 400-2978 Email: twatteyne@linear.com Wang, et al. Expires January 14, 2014 [Page 60]