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 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 0x04, indicates Remove Hard Cell Request operation.

The ScheduleIE should specify all the cells that need to be removed.

2.6. Time Sequence

6tus neighbors exchange 6tus-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. 6tus does not specify the criteria to choose time source neighbors from the Enhanced BEACONs.
• 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 6tus 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 6tus.

When receiving a Create soft cell command, Node A's 6tus layer 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 14 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 6tus 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 6tus.

When receiving a Delete soft cell command, Node A's 6tus layer 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 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 6tus (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, 6tus 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 6tus to create one or more hard cells by calling the Create hard cell command.

When receiving a Create hard cell command, Node A's 6tus layer 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 6tus to delete one or more hard cells by calling the Delete hard cell command.

When receiving a Delete hard cell command, Node A's 6tus layer 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.

2.7. Statistics

The 6tus 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

6tus 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.
• DeviceStatisticsEn.

6tus statistics function is enabled/disabled and configured by the commands defined in Section 2.4.4

2.8. Monitoring

Monitoring Fuction (MF) in 6tus 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.

6tus 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.

3. Using 6tus

This part describes how 6tus gives support to specific upper layers.

3.1. RPL on 6tus

6tus 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 6tus layer.

In order to optimize the combination of RPL and TSCH, 6tus 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 6tus layer 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. 6tus updates that table upon sending or reception of a packet from/to a neighbor. RPL can query at any time the neighbor table to retrieve information about a particular neighbor. This information can be used to compute the routing objective function as for example the 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.

6tus 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 6tus command to setup the desired policy. The policy is selected by RPL and enforced by 6tus layer.

The rule for 6tus to select and maintain time sources is as follows.

• Time source of one node should be one member of the node's neighbor set.
• Time sources should be the neighbors which have relatively lower Join Priority in the neighbor set. Lower Join Priority means closer to TSCH Pan coordinator.
• The link from a node to its time sources should be in a good link quality.

3.1.2. Support to Rank Computation

RPL objective function is computed by a set of metrics. The specific metrics and how the objective function is calculated are out of the scope of the present document, however, 6tus 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.

6tus provides Statistics for Rank computation as described in sections(Section 2.4.4 and Section 2.7). The function to compute the Rank based on those statistics is out of scope of 6tus, however the provided metrics are aligned to the behavior of the TSCH MAC layer.

3.1.3. Support to Control Messages Broadcast

In RPL, some control messages, e.g. DIO, and DAO in sorting mode, need to be broadcasted to the neighbors. The broadcast channel requirement has to be addressed by 6tus by configuring TSCH to provide such a channel.

In order to decouple the upper (RPL) layer to TSCH, instead of carrying DIO message in the Enhance Beacon, 6tus 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]). 6tus 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, 6tus 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 6tus, 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 waiting to the MAC layer to read it and sent it in a particular slot according to is destination and priority (Section 2.3). 6tus 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.

6tus 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. 6tus 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. 6tus is responsible for feeding these packets to TSCH at Transmit cells or Shared Cells.

6tus 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, 6tus 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.

3.2. GMPLS on 6tus

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, 6tus provides specific support to GMPLS in the following aspects:

• Cell Reservation Support
• QoS

3.2.1. Cell Reservation Support for GMPLS on 6tus

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. 6tus 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 6tus supports different types of reservations: soft cell and hard cell. How the reservation requirements are expressed is out of scope of this document, but 6tus 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. 6tus 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 6tus 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.

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.
[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.thubert-roll-forwarding-frags]	Thubert, P. and J. Hui, "LLN Fragment Forwarding and Recovery", Internet-Draft draft-thubert-roll-forwarding-frags-00, March 2012.
[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", Internet-Draft draft-tsao-roll-security-framework-02, March 2010.
[I-D.thubert-roll-asymlink]	Thubert, P., "RPL adaptation for asymmetrical links", Internet-Draft draft-thubert-roll-asymlink-02, December 2011.
[I-D.ietf-roll-terminology]	Vasseur, J., "Terminology in Low power And Lossy Networks", Internet-Draft draft-ietf-roll-terminology-11, February 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", Internet-Draft draft-ietf-roll-p2p-rpl-16, February 2013.
[I-D.ietf-roll-trickle-mcast]	Hui, J. and R. Kelsey, "Multicast Protocol for Low power and Lossy Networks (MPL)", Internet-Draft draft-ietf-roll-trickle-mcast-03, January 2013.
[I-D.thubert-6lowpan-backbone-router]	Thubert, P., "6LoWPAN Backbone Router", Internet-Draft draft-thubert-6lowpan-backbone-router-02, June 2010.
[I-D.sarikaya-core-sbootstrapping]	Sarikaya, B., Ohba, Y., Moskowitz, R., Cao, Z. and R. Cragie, "Security Bootstrapping Solution for Resource-Constrained Devices", Internet-Draft draft-sarikaya-core-sbootstrapping-04, 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", Internet-Draft draft-gilger-smart-object-security-workshop-00, October 2012.
[I-D.phinney-roll-rpl-industrial-applicability]	Phinney, T., Thubert, P. and R. Assimiti, "RPL applicability in industrial networks", Internet-Draft draft-phinney-roll-rpl-industrial-applicability-01, October 2012.
[I-D.ietf-core-coap]	Shelby, Z., Hartke, K., Bormann, C. and B. Frank, "Constrained Application Protocol (CoAP)", Internet-Draft draft-ietf-core-coap-13, December 2012.
[I-D.watteyne-6tsch-tsch-lln-context]	Watteyne, T., "Using IEEE802.15.4e TSCH in an LLN context: Overview, Problem Statement and Goals", Internet-Draft draft-watteyne-6tsch-tsch-lln-context-01, February 2013.
[I-D.draft-palattella-6tsch-terminology]	Palattella, MR., 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.draft-thubert-6tsch-architecture]	Thubert, P., Assimiti, R. and T. Watteyne, "An Architecture for IPv6 over Time Synchronized Channel Hopping. draft-thubert-6tsch-architecture-00 (work in progress) ", March 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", .

Authors' Addresses