--- 1/draft-ietf-lwig-energy-efficient-05.txt 2017-02-08 15:13:09.187547074 -0800 +++ 2/draft-ietf-lwig-energy-efficient-06.txt 2017-02-08 15:13:09.235548197 -0800 @@ -1,91 +1,92 @@ Internet Engineering Task Force C. Gomez Internet-Draft Universitat Politecnica de Catalunya/i2CAT Intended status: Informational M. Kovatsch -Expires: April 16, 2017 ETH Zurich +Expires: August 12, 2017 ETH Zurich H. Tian China Academy of Telecommunication Research Z. Cao, Ed. Huawei Technologies - October 13, 2016 + February 8, 2017 Energy-Efficient Features of Internet of Things Protocols - draft-ietf-lwig-energy-efficient-05 + draft-ietf-lwig-energy-efficient-06 Abstract - This document describes the problems and current practices of energy - efficient protocol operation on constrained devices. It summarizes - the main link layer techniques for energy efficient networking, and - it highlights the impact of such techniques on the upper layer - protocols, so that they can coordinately achieve an energy efficient - behavior. The document also provides an overview of energy efficient - mechanisms available at each layer of the constrained node network - IETF protocol suite. + This document describes the challenges for energy-efficient protocol + operation on constrained devices and the current practices used to + overcome those challenges. It summarizes the main link-layer + techniques used for energy-efficient networking, and it highlights + the impact of such techniques on the upper layer protocols so that + they can together achieve an energy efficient behavior. The document + also provides an overview of energy-efficient mechanisms available at + each layer of the IETF protocol suite specified for constrained node + networks. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 16, 2017. + This Internet-Draft will expire on August 12, 2017. Copyright Notice - Copyright (c) 2016 IETF Trust and the persons identified as the + Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions used in this document . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. MAC and Radio Duty Cycling . . . . . . . . . . . . . . . . . 5 3.1. Radio Duty Cycling techniques . . . . . . . . . . . . . . 6 3.2. Latency and buffering . . . . . . . . . . . . . . . . . . 7 3.3. Throughput . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Radio interface tuning . . . . . . . . . . . . . . . . . 7 - 3.5. Power save services available in example low-power radios 7 + 3.5. Power save services available in example low-power radios 8 3.5.1. Power Save Services Provided by IEEE 802.11 . . . . . 8 3.5.2. Power Save Services Provided by Bluetooth LE . . . . 9 3.5.3. Power Save Services in IEEE 802.15.4 . . . . . . . . 10 - 3.5.4. Power Save Services in DECT ULE . . . . . . . . . . . 11 + 3.5.4. Power Save Services in DECT ULE . . . . . . . . . . . 12 4. IP Adaptation and Transport Layer . . . . . . . . . . . . . . 13 5. Routing Protocols . . . . . . . . . . . . . . . . . . . . . . 14 6. Application Layer . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Energy efficient features in CoAP . . . . . . . . . . . . 15 6.2. Sleepy node support . . . . . . . . . . . . . . . . . . . 15 6.3. CoAP timers . . . . . . . . . . . . . . . . . . . . . . . 16 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 + 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 12.2. Informative References . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction @@ -100,46 +101,49 @@ A large body of research efforts have been put on this "energy efficiency" problem. Most of this research has focused on how to optimize the system's power consumption regarding a certain deployment scenario or how could an existing network function such as routing or security be more energy-efficient. Only few efforts focused on energy-efficient designs for IETF protocols and standardized network stacks for such constrained devices [I-D.kovatsch-lwig-class1-coap]. The IETF has developed a suite of Internet protocols suitable for - such constrained devices, including 6LoWPAN ( - [RFC6282],[RFC6775],[RFC4944] ), RPL[RFC6550], and - CoAP[I-D.ietf-core-coap]. This document tries to summarize the - design considerations of making the IETF contrained protocol suite as - energy-efficient as possible. While this document does not provide - detailed and systematic solutions to the energy efficiency problem, - it summarizes the design efforts and analyzes the design space of - this problem. In particular, it provides a comprehensive overview of - the techniques used by the lower layers to save energy and how these - may impact on the upper layers. + such constrained devices, including IPv6 over Low-Power Wireless + Personal Area Networks (6LoWPAN) [RFC6282],[RFC6775],[RFC4944], the + IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) + [RFC6550], and the Constrained Application Protocol (CoAP) [RFC7252]. + This document tries to summarize the design considerations for making + the IETF constrained protocol suite as energy-efficient as possible. + While this document does not provide detailed and systematic + solutions to the energy efficiency problem, it summarizes the design + efforts and analyzes the design space of this problem. In + particular, it provides an overview of the techniques used by the + lower layers to save energy and how these may impact on the upper + layers. After reviewing the energy-efficient design of each layer, an overall conclusion is summarized. Though the lower layer communication optimization is the key part of energy efficient design, the protocol design at the upper layers is also important to make the device energy-efficient. 1.1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 1.2. Terminology - The terminologies used in this document can be referred to [RFC7228]. + The terminologies used in this document can be referred to [RFC7228] + [I-D.bormann-lwig-7228bis]. 2. Overview The IETF has developed protocols to enable end-to-end IP communication between constrained nodes and fully capable nodes. This work has witnessed the evolution of the traditional Internet protocol stack to a light-weight Internet protocol stack. As shown in Figure 1 below, the IETF has developed CoAP as the application layer and 6LoWPAN as the adaption layer to run IPv6 over IEEE 802.15.4 and Bluetooth Low-Energy, with the support of routing by RPL @@ -166,48 +170,49 @@ | +-------+ |MAC/PHY| +-------+ Figure 1: Traditional and Light-weight Internet Protocol Stack There are numerous published studies reporting comprehensive measurements of wireless communication platforms [Powertrace]. As an example, below we list the energy consumption profile of the most - common atom operations on a prevalent sensor node platform. The - measurement was based on the Tmote Sky with ContikiMAC [ContikiMAC] - as the radio duty cycling algorithm. From this and many other - measurement reports (e.g. [AN053]), we can see that the energy - consumption of optimized transmission and reception are in the same - order. For IEEE 802.15.4 and UWB links, transmitting may actually be - even cheaper than receiving. It also shows that broadcast and non- - synchronized communication transmissions are energy costly because - they need to acquire the medium for a long time. + common operations involved in communication on a prevalent sensor + node platform. The measurement was based on the Tmote Sky with + ContikiMAC [ContikiMAC] as the radio duty cycling algorithm. From + this and many other measurement reports (e.g. [AN053]), we can see + that the energy consumption of optimized transmission and reception + are in the same order. For IEEE 802.15.4 and Ultra WideBand (UWB) + links, transmitting may actually be even cheaper than receiving. It + also shows that broadcast and non-synchronized communication + transmissions are energy costly because they need to acquire the + medium for a long time. +---------------------------------------+---------------+ | Activity | Energy (uJ) | +---------------------------------------+---------------+ | Broadcast reception | 178 | +---------------------------------------+---------------+ | Unicast reception | 222 | +---------------------------------------+---------------+ | Broadcast transmission | 1790 | +---------------------------------------+---------------+ | Non-synchronized unicast transmission | 1090 | +---------------------------------------+---------------+ | Synchronized unicast transmission | 120 | +---------------------------------------+---------------+ | Unicast TX to awake receiver | 96 | +---------------------------------------+---------------+ - Figure 2: Power consumption of atom operations on the Tmote Sky with - ContikiMAC + Figure 2: Power consumption of common operations involved in + communication on the Tmote Sky with ContikiMAC 3. MAC and Radio Duty Cycling In low-power wireless networks, communication and power consumption are intertwined. The communication device is typically the most power-consuming component, but merely refraining from transmissions is not enough to attain a low power consumption: the radio may consume as much power in listen mode as when actively transmitting. This augments the key problem known as idle listening, whereby the radio of a device may be in receive mode (ready to receive any @@ -270,21 +275,21 @@ the involved devices. Such negotiation may be performed per transmission or per session/connection. Bluetooth Low Energy (Bluetooth LE) is an example of a radio technology based on this mechanism. c) Listen after send. This technique allows a node to remain in sleep mode by default, wake up and poll a sender (which must be ready to receive a poll message) for pending transmissions. After sending the poll message, the node remains in receive mode, ready for a potential incoming transmission. After a certain time interval, the - node may go back to sleep. For example, the Receiver Initated + node may go back to sleep. For example, the Receiver Initiated Transmission (RIT) mode of 802.15.4e, and the transmission of data between a coordinator and a device in IEEE 802.15.4-2003 use this technique. 3.2. Latency and buffering The latency of a data unit transmission to a duty-cycled device is equal to or greater than the latency of transmitting to an always-on device. Therefore, duty-cycling leads to a trade-off between energy consumption and latency. Note that in addition to a latency @@ -381,37 +386,37 @@ such as FMS interval and BSS MAX Idle Period, so that the wireless transmissions are not triggered periodically. 3.5.2. Power Save Services Provided by Bluetooth LE Bluetooth LE is a wireless low-power communications technology that is the hallmark component of the Bluetooth 4.0, 4.1 and 4.2 specifications [Bluetooth42]. BT-LE has been designed for the goal of ultra-low-power consumption. Currently, it is possible to run IPv6 over Bluetooth LE networks by using a 6LoWPAN variant adapted to - BT-LE [I-D.ietf-6lowpan-btle]. + BT-LE [RFC7668]. Bluetooth LE networks comprise a master and one or more slaves which are connected to the master. The Bluetooth LE master is assumed to be a relatively powerful device, whereas a slave is typically a constrained device (e.g. a class 1 device). - Medium access in Bluetooth LE is based on a TDMA scheme which is - coordinated by the master. This device determines the start of - connection events, in which communication between the master and a - slave takes place. At the beginning of a connection event, the - master sends a poll message, which may encapsulate data, to the - slave. The latter must send a response, which may also contain data. - The master and the slave may continue exchanging data until the end - of the connection event. The next opportunity for communication - between the master and the slave will be in the next connection event - scheduled for the slave. + Medium access in Bluetooth LE is based on a Time Division Multiple + Access (TDMA) scheme which is coordinated by the master. This device + determines the start of connection events, in which communication + between the master and a slave takes place. At the beginning of a + connection event, the master sends a poll message, which may + encapsulate data, to the slave. The latter must send a response, + which may also contain data. The master and the slave may continue + exchanging data until the end of the connection event. The next + opportunity for communication between the master and the slave will + be in the next connection event scheduled for the slave. The time between consecutive connection events is defined by the connInterval parameter, which may range between 7.5 ms and 4 s. The slave may remain in sleep mode since the end of its last connection event until the beginning of its next connection event. Therefore, Bluetooth LE is duty-cycled by nature. Furthermore, after having replied to the master, a slave is not required to listen to the master (and thus may keep the radio in sleep mode) for connSlaveLatency consecutive connection events. connSlaveLatency is an integer parameter between 0 and 499 which should not cause link @@ -431,47 +436,48 @@ IEEE 802.15.4 is a family of standard radio interfaces for low-rate, low-power wireless networking [fifteendotfour]. Since the publication of its first version in 2003, IEEE 802.15.4 has become the de-facto choice for a wide range of constrained node network application domains and has been a primary target technology of various IETF working groups such as 6LoWPAN [RFC6282],[RFC6775],[RFC4944] and 6TiSCH [I-D.ietf-6tisch-architecture]. IEEE 802.15.4 specifies PHY and MAC layer functionality. - IEEE 802.15.4 defines three roles called device, coordinator and PAN - coordinator. The device role is adequate for nodes that do not - implement the complete IEEE 802.15.4 functionality, and is mainly - targeted for constrained nodes with a limited energy source. The - coordinator role includes synchronization capabilities and is - suitable for nodes that do not suffer severe constraints (e.g. a - mains-powered node). The PAN coordinator is a special type of - coordinator that acts as a principal controller in an IEEE 802.15.4 - network. + IEEE 802.15.4 defines three roles called device, coordinator and + Personal Area Network (PAN) coordinator. The device role is adequate + for nodes that do not implement the complete IEEE 802.15.4 + functionality, and is mainly targeted for constrained nodes with a + limited energy source. The coordinator role includes synchronization + capabilities and is suitable for nodes that do not suffer severe + constraints (e.g. a mains-powered node). The PAN coordinator is a + special type of coordinator that acts as a principal controller in an + IEEE 802.15.4 network. IEEE 802.15.4 has mainly defined two types of networks depending on their configuration: beacon-enabled and nonbeacon-enabled networks. In the first network type, coordinators periodically transmit beacons. The time between beacons is divided in three main parts: the Contention Access Period (CAP), the Contention Free Period (CFP) - and an inactive period. In the first period, nodes use slotted CSMA/ - CA for data communication. In the second one, a TDMA scheme controls - medium access. During the idle period, communication does not take - place, thus the inactive period is a good opportunity for nodes to - turn the radio off and save energy. The coordinator announces in - each beacon the list of nodes for which data will be sent in the - subsequent period. Therefore, devices may remain in sleep mode by - default and wake up periodically to listen to the beacons sent by - their coordinator. If a device wants to transmit data, or learns - from a beacon that it is an intended destination, then it will - exchange messages with the coordinator and will thus consume energy. - An underlying assumption is that when a message is sent to a + and an inactive period. In the first period, nodes use slotted + Carrier Sense Multiple Access / Collision Avoidance (CSMA/CA) for + data communication. In the second one, a TDMA scheme controls medium + access. During the idle period, communication does not take place, + thus the inactive period is a good opportunity for nodes to turn the + radio off and save energy. The coordinator announces in each beacon + the list of nodes for which data will be sent in the subsequent + period. Therefore, devices may remain in sleep mode by default and + wake up periodically to listen to the beacons sent by their + coordinator. If a device wants to transmit data, or learns from a + beacon that it is an intended destination, then it will exchange + messages with the coordinator and will thus consume energy. An + underlying assumption is that when a message is sent to a coordinator, the radio of the latter will be ready to receive the message. The beacon interval and the duration of the beacon interval active portion (i.e. the CAP and the CFP), and thus the duty cycle, can be configured. The parameters that control these times are called macBeaconOrder and macSuperframeOrder, respectively. As an example, when IEEE 802.15.4 operates in the 2.4 GHz PHY, both times can be (independently) set to values in the range between 15.36 ms and 251.6 s. @@ -491,29 +497,28 @@ nodes may lead to a quick battery depletion), or apply synchronization techniques. The latter are out of the scope of IEEE 802.15.4. The main MAC layer IEEE 802.15.4 amendment to date is IEEE 802.15.4e. This amendment includes various new MAC layer modes, some of which include mechanisms for low energy consumption. Among these, the Time-Slotted Channel Hopping (TSCH) is an outstanding mode which offers robust features for industrial environments, among others. In order to provide the functionality needed to enable IPv6 over TSCH, - the 6TiSCH working group has been recently created. TSCH is based on - a TDMA schedule whereby a set of time slots are used for frame - transmission and reception, and other time slots are unscheduled. - The latter time slots may be used by a dynamic scheduling mechanism, - otherwise nodes may keep the radio off during the unscheduled time - slots, thus saving energy. The minimal schedule configuration - specified in [I-D.ietf-6tisch-minimal] comprises 101 time slots, - whereby 95 of these time slots are unscheduled and the time slot - duration is 15 ms. + the 6TiSCH working group was created. TSCH is based on a TDMA + schedule whereby a set of time slots are used for frame transmission + and reception, and other time slots are unscheduled. The latter time + slots may be used by a dynamic scheduling mechanism, otherwise nodes + may keep the radio off during the unscheduled time slots, thus saving + energy. The minimal schedule configuration specified in + [I-D.ietf-6tisch-minimal] comprises 101 time slots, whereby 95 of + these time slots are unscheduled and the time slot duration is 15 ms. Other 802.15.4e modes, which are in fact designed for low energy, are the previously mentioned CSL and RIT. 3.5.4. Power Save Services in DECT ULE DECT Ultra Low Energy (DECT ULE) is a wireless technology building on the key fundamentals of traditional DECT / CAT-iq [EN300] but with specific changes to significantly reduce the power consumption on the expense of data throughput as specified in [TS102]. DECT ULE devices @@ -685,29 +690,31 @@ proxies themselves may respond to client requests if the corresponding server is sleeping and the resource representation is recent enough. Otherwise, a proxy may attempt to obtain the resource from the sleepy server. 6.2. Sleepy node support Beyond these features of CoAP, there have been a number of proposals to further support sleepy nodes at the application layer by leveraging CoAP mechanisms. A good summary of such proposals can be - found in [I-D.rahman-core-sleepy-nodes-do-we-need]. The different - approaches include exploiting the use of proxies, leveraging the + found in [I-D.rahman-core-sleepy-nodes-do-we-need], while an example + application (in the context of illustrating several security + mechanisms) in a scenario with sleepy devices has been described + [I-D.ietf-lwig-crypto-sensors]. The different approaches to support + sleepy nodes include exploiting the use of proxies, leveraging the Resource Directory [I-D.ietf-core-resource-directory] or signaling when a node is awake to the interested nodes. A more recent work defines publish-subscribe and message queuing extensions to CoAP and the Resource Directory in order to support devices that spend most of - their time in a sleeping state [I-D.koster-core-coap-pubsub]. As of - the writing, none of these proposals has been adopted by the CoRE - working group. + their time in a sleeping state [I-D.ietf-core-coap-pubsub]. Notably, + this work has been adopted by the CoRE Working Group. In addition to the work within the scope of CoAP to support sleepy nodes, other specifications define application layer functionality for the same purpose. The Lightweight Machine-to-Machine (LWM2M) specification from the Open Mobile Alliance (OMA) defines a Queue Mode whereby an LWM2M Server queues requests to an LWM2M Client until the latter (which may often stay in sleep mode) is online. LWM2M functionality operates on top of CoAP. On the other hand, oneM2M defines a CoAP binding with an application @@ -727,45 +734,46 @@ RTO value), CoAP RTO parameters should be tuned accordingly in order to avoid spurious RTOs which would unnecessarily waste node energy and other resources. 7. Summary We summarize the key takeaways in this document: a. Internet protocols designed by IETF can be considered as the customer of the lower layers (PHY, MAC, and Duty-cycling). To - save power consumption, it is recommended to synergize with the - lower layer other than treating the lower layer as a black box. + save power consumption, it is recommended to operate based on the + lower layer behavior rather than treating the lower layer as a + black box. - b. It is always useful to compresss the protocol headers in order to + b. It is always useful to compress the protocol headers in order to reduce the transmission/reception power. This design principles have been employed by many protocols in 6Lo and CoRE working group. - c. Broadcast and non-synchronzed transmissions consume more than + c. Broadcast and non-synchronized transmissions consume more than other TX/RX operations. If protocols must use these ways to collect information, reduction of their usage by aggregating similar messages together will be helpful in saving power. d. Saving power by sleeping occasionally is used widely. Reduction of states is also an effective method to be energy efficient. 8. Contributors Jens T. Petersen, RTX, contributed the section on power save services in DECT ULE. 9. Acknowledgments - Carles Gomez has been supported by Ministerio de Economia y - Competitividad and FEDER through project TEC2012-32531. + Carles Gomez has been supported by the Spanish Government, FEDER and + the ERDF through projects TEC2012-32531 and TEC2016-79988-P. Authors would like to thank the review and feedback from a number of experts in this area: Carsten Bormann, Ari Keranen, Hannes Tschofenig, Dominique Barthel. The text of this document was improved based on IESG Document Editing session during IETF87. Thank Ted Lemon, Joel Jaeggli, and efforts to initiate this facilities. 10. IANA Considerations @@ -837,84 +845,84 @@ [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . + [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., + Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low + Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, + . + [TS102] ""Digital Enhanced Cordless Telecommunications (DECT); Ultra Low Energy (ULE); Machine to Machine Communications; Part 1: Home Automation Network (phase 1)"", 2013. 12.2. Informative References [AN053] Selvig, B., "Measuring power consumption with CC2430 and Z-Stack". [Announcementlayer] Dunkels, A., "The Announcement Layer: Beacon Coordination for the Sensornet Stack. In Proceedings of EWSN 2011". [ContikiMAC] Dunkels, A., "The ContikiMAC Radio Duty Cycling Protocol, SICS Technical Report T2011:13", December 2011. + [I-D.bormann-lwig-7228bis] + Bormann, C. and C. Gomez, "Terminology for Constrained- + Node Networks", draft-bormann-lwig-7228bis-00 (work in + progress), October 2016. + [I-D.ietf-6lo-dect-ule] Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D. Barthel, "Transmission of IPv6 Packets over DECT Ultra Low - Energy", draft-ietf-6lo-dect-ule-06 (work in progress), - October 2016. - - [I-D.ietf-6lowpan-btle] - Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., - Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets - over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-12 - (work in progress), February 2013. + Energy", draft-ietf-6lo-dect-ule-09 (work in progress), + December 2016. [I-D.ietf-6man-impatient-nud] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability Detection is too impatient", draft-ietf-6man-impatient- nud-07 (work in progress), October 2013. [I-D.ietf-6tisch-architecture] Thubert, P., "An Architecture for IPv6 over the TSCH mode - of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work - in progress), June 2016. + of IEEE 802.15.4", draft-ietf-6tisch-architecture-11 (work + in progress), January 2017. [I-D.ietf-6tisch-minimal] - Vilajosana, X. and K. Pister, "Minimal 6TiSCH - Configuration", draft-ietf-6tisch-minimal-16 (work in - progress), June 2016. + Vilajosana, X., Pister, K., and T. Watteyne, "Minimal + 6TiSCH Configuration", draft-ietf-6tisch-minimal-19 (work + in progress), January 2017. - [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. + [I-D.ietf-core-coap-pubsub] + Koster, M., Keranen, A., and J. Jimenez, "Publish- + Subscribe Broker for the Constrained Application Protocol + (CoAP)", draft-ietf-core-coap-pubsub-00 (work in + progress), October 2016. [I-D.ietf-core-resource-directory] Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE - Resource Directory", draft-ietf-core-resource-directory-08 - (work in progress), July 2016. - - [I-D.ietf-lwig-terminology] - Bormann, C., Ersue, M., and A. Keranen, "Terminology for - Constrained Node Networks", draft-ietf-lwig-terminology-07 - (work in progress), February 2014. + Resource Directory", draft-ietf-core-resource-directory-09 + (work in progress), October 2016. - [I-D.koster-core-coap-pubsub] - Koster, M., Keranen, A., and J. Jimenez, "Publish- - Subscribe Broker for the Constrained Application Protocol - (CoAP)", draft-koster-core-coap-pubsub-05 (work in - progress), July 2016. + [I-D.ietf-lwig-crypto-sensors] + Sethi, M., Arkko, J., Keranen, A., and H. Back, "Practical + Considerations and Implementation Experiences in Securing + Smart Object Networks", draft-ietf-lwig-crypto-sensors-01 + (work in progress), October 2016. [I-D.kovatsch-lwig-class1-coap] Kovatsch, M., "Implementing CoAP for Class 1 Devices", draft-kovatsch-lwig-class1-coap-00 (work in progress), October 2012. [I-D.rahman-core-sleepy-nodes-do-we-need] Rahman, A., "Sleepy Devices: Do we need to Support them in CORE?", draft-rahman-core-sleepy-nodes-do-we-need-01 (work in progress), February 2014.