--- 1/draft-ietf-lwig-energy-efficient-02.txt 2015-05-19 10:17:06.407756971 -0700 +++ 2/draft-ietf-lwig-energy-efficient-03.txt 2015-05-19 10:17:06.451758042 -0700 @@ -1,25 +1,25 @@ Internet Engineering Task Force Z. Cao Internet-Draft Leibniz University of Hannover Intended status: Informational C. Gomez -Expires: September 8, 2015 Universitat Politecnica de Catalunya/i2CAT +Expires: November 20, 2015 Universitat Politecnica de Catalunya/i2CAT M. Kovatsch ETH Zurich H. Tian China Academy of Telecommunication Research X. He Hitachi China R&D Corporation - March 7, 2015 + May 19, 2015 Energy Efficient Implementation of IETF Constrained Protocol Suite - draft-ietf-lwig-energy-efficient-02 + draft-ietf-lwig-energy-efficient-03 Abstract This document summarizes the problems and current practices of energy efficient protocol implementation on constrained devices, mostly about how to make the protocols within IETF scope behave energy friendly. This document also summarizes the impact of link layer protocol power saving behaviors to the upper layer protocols, so that they can coordinately make the system energy efficient. @@ -31,21 +31,21 @@ 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 September 8, 2015. + This Internet-Draft will expire on November 20, 2015. Copyright Notice Copyright (c) 2015 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 @@ -61,36 +61,38 @@ 1.1. Conventions used in this document . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 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.1. Power Save Services Provided by IEEE 802.11 . . . . . 8 - 3.5.2. Power Save Services Provided by Bluetooth Low Energy 9 + 3.5.2. Power Save Services Provided by Bluetooth LE . . . . 9 3.5.3. Power Save Services in IEEE 802.15.4 . . . . . . . . 10 - 4. IP Adaptation and Transport Layer . . . . . . . . . . . . . . 11 - 5. Routing Protocols . . . . . . . . . . . . . . . . . . . . . . 12 - 6. Application Layer . . . . . . . . . . . . . . . . . . . . . . 13 - 6.1. Energy efficient features in CoAP . . . . . . . . . . . . 13 - 6.2. Sleepy node support . . . . . . . . . . . . . . . . . . . 14 - 6.3. CoAP timers . . . . . . . . . . . . . . . . . . . . . . . 14 - 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 - 11.2. Informative References . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 + 3.5.4. Power Save Services in DECT ULE . . . . . . . . . . . 11 + 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 . . . . . . . . . . . . . . . . . . . . . . . . 17 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 + 12.2. Informative References . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction In many scenarios, the network systems comprise many battery-powered or energy-harvesting devices. For example, in an environmental monitoring system or a temperature and humidity monitoring system in a data center, there are no always-on and handy sustained power supplies for the potentially large number of constrained devices. In such deployment environments, it is necessary to optimize the energy consumption of the entire system, including computing, application @@ -141,33 +143,33 @@ 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 and efficient neighbor discovery by 6LoWPAN-ND. 6LoWPAN is currently being adapted by the 6lo working group to support IPv6 over various other technologies, such as ITU-T G.9959, DECT ULE, MS/TP-BACnet and NFC. +-----+ +-----+ +-----+ +------+ - |http | | ftp | |SNMP | | COAP | + |HTTP | | FTP | |SNMP | | CoAP | +-----+ +-----+ +-----+ +------+ \ / / / \ +-----+ +-----+ +-----+ +-----+ - | tcp | | udp | | tcp | | udp | + | TCP | | UDP | | TCP | | UDP | +-----+ +-----+ ===> +-----+ +-----+ \ / \ / +-----+ +------+ +-------+ +------+ +-----+ - | RTG |--| ipv6 |--|ICMP/ND| | ipv6 |---| rpl | + | RTG |--| IPv6 |--|ICMP/ND| | IPv6 |---| RPL | +-----+ +------+ +-------+ +------+ +-----+ | | +-------+ +-------+ +----------+ - |MAC/PHY| |6lowpan|--|6lowpan-nd| + |MAC/PHY| |6LoWPAN|--|6LoWPAN-ND| +-------+ +-------+ +----------+ | +-------+ |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 @@ -260,22 +262,23 @@ radio technologies that use preamble sampling include ContikiMAC, the Coordinated Sampled Listening (CSL) mode of IEEE 802.15.4e, and the Frequently Listening (FL) mode of ITU-T G.9959. b) Scheduled transmissions. This approach allows a device to know the instants in which it should be awake (during some time interval) in order to receive data units. Otherwise, the device may remain in sleep mode. The decision on the instants that will be used for communication is reached by means of some form of negotation between the involved devices. Such negotiation may be performed per - transmission or per session/connection. Bluetooth Low Energy is an - example of a radio technology based on this mechanism. + 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 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. @@ -316,23 +319,23 @@ tuned to achieve the intended application and/or network requirements. On the other hand, upper layers should take into account the expected latency and/or throughput behavior due to RDC. The next subsection provides details on key parameters controlling RDC mechanisms, and thus fundamental trade-offs, for various examples of relevant low-power radio technologies. 3.5. Power save services available in example low-power radios This subsection presents power save services and techniques used in a - few relevant examples of wireless low-power radios: IEEE 802.11v, - Bluetooth Low Energy and IEEE 802.15.4. For a more detailed overview - of each technology, the reader may refer to the literature or to the + few relevant examples of wireless low-power radios: IEEE 802.11, + Bluetooth LE and IEEE 802.15.4. For a more detailed overview of each + technology, the reader may refer to the literature or to the corresponding specifications. 3.5.1. Power Save Services Provided by IEEE 802.11 IEEE 802.11 defines the Power Save Mode (PSM) whereby a station may indicate to an Access Point (AP) that it will enter a sleep mode state. While the station is sleeping, the AP buffers any frames that should be sent to the sleeping station. The station wakes up every Listen Interval (which can be a multiple of the Beacon Interval) in order to receive beacons. The AP signals in the beacon whether there @@ -372,28 +375,28 @@ traffic filters specified by the non-AP STA. Using the above services provided by the lower layer, the constrained nodes can achieve either client initiated power save (via TFS) or network assisted power save (Proxy-ARP, BSS Max Idel Period and FMS). Upper layer protocols would better synchronize with the parameters 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 Low Energy +3.5.2. Power Save Services Provided by Bluetooth LE - Bluetooth Low Energy (Bluetooth LE) is a wireless low-power - communications technology that is the hallmark component of the - Bluetooth 4.0 and Bluetooth 4.1 specifications [Bluetooth41]"/>. 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]. + 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]. 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 @@ -502,41 +505,116 @@ 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 + typically operates on special power optimized silicon, but can + connect to a DECT Gateway supporting traditional DECT / CAT-iq for + cordless telephony and data as well as the DECT ULE extensions. It + is possible to run IPv6 over DECT ULE by using a 6LoWPAN variant + adapted for DECT ULE [I-D.ietf-6lo-dect-ule]. + + DECT terminology operates with two major role definitions: The + Portable Part (PP) is the power constrained device, while the Fixed + Part (FP) is the Gateway or base station in a star topology. DECT is + operating in license free and reserved frequency bands based on TDMA/ + FDMA and TDD using dynamic channel allocation for interference + avoidance. It provides good indoor (~50 m) and outdoor (~300 m) + coverage. It is using a frame length of 10 ms, which is divided into + 24 timeslots and it is supporting connection oriented, packet data + and connection less services. + + The FP usually transmits a so-called dummy bearer (beacon) that is + used to broadcast synchronization, system and paging information. + The slot/carrier position of this dummy bearer can automatically be + reallocated in order to avoid mutual interference with other DECT + signals. + + At MAC level DECT ULE communications between FP and PP are initiated + by the PP. A FP can initiate communication indirectly by sending + paging signal to a PP. The PP determines the timeslot and frequency + on which the communication between FP and PP takes place. The PP + verifies the radio timeslot/frequency position is unoccupied before + it initiates its transmitter. An access-request message, which + usually carries data, is sent to the FP. The FP sends a confirm + message, which also may carry data. More data can be sent in + subsequent frames. A MAC level automatic retransmission scheme + improves data transfer reliability significant. A segmentation and + reassembly scheme supports transfer of larger higher layer SDUs and + provides data integrity check. The DECT ULE packet data service + ensures data integrity, proper sequencing, duplicate protection, but + does not guaranteed delivery. Higher layers protocols have to take + this into considerations. + + The FP may send paging information to PPs to trigger connection setup + and indicate required service type. The interval between paging + information to a specific PP can be defined in range 10 ms to 327 + seconds. The PP may enter sleep mode to save power. The listening + interval is defined by the PP application. For short sleep intervals + (below ~10 seconds) the PP may be able to retain synchronization to + the FP dummy bearer and only turn on the receiver during the expected + timeslot. For longer sleep intervals the PP can't keep + synchronization and has to search for and resynchronize to the FP + dummybearer. Hence, longer sleep interval reduces the average energy + consumption, but adds a energy consumption penalty for acquiring + synchronization to the FP dummy bearer. The PP can obtain all + information to determine paging and acquire synchronization + information in a single reception of one full timeslot. + + Packet data latency is normally 30 ms for short packets (below or + equal to 32 octets), however if retry and back-off scenarios occur, + the latency is increased. The latency can actually be reduced to + about 10 ms by doing energy consuming RSSI scanning in advance. In + the direction from FP to PP the latency is usually increased by the + used paging interval and the sleep interval. The MAC layer can + piggyback commands to improve efficiency (reduce latency) of higher + layer protocols. Such commands can instruct the PP to initiate a new + packet transfer in N frames without the need for resynchronization + and listening to paging or instruct the PP to stay in a higher duty + cycle paging detection mode. + + The DECT ULE technology allows per PP configuration of paging + interval, MTU size, reassembly window size and higher layer service + negotiation and protocol. + 4. IP Adaptation and Transport Layer 6LoWPAN is the adaption layer to run IPv6 over IEEE 802.15.4 MAC&PHY. It was born to fill the gap that the IPv6 layer does not support fragmentation and assembly of <1280-byte packets while IEEE 802.15.4 only supports a MTU of 127 bytes. IPv6 is the basis for the higher layer protocols, including both TCP/ UDP transport and applications. So they are quite ignorant of the lower layers, and are almost neutral to the energy-efficiency problem. What the network stack can optimize is to save the computing power. For example the Contiki implementation has multiple cross layer optimizations for buffers and energy management, e.g., the computing and validation of UDP/TCP checksums without the need of reading IP headers from a different layer. These optimizations are software implementation techniques, and out of the scope of IETF and the LWIG working group. - The 6LoWPAN contributes to the energy-efficiency problem in two ways. + 6LoWPAN contributes to the energy-efficiency problem in two ways. First of all, it swaps computing with communication. 6LoWPAN applies compression of the IPv6 header. This means less amount of data will be handled by the lower layer, but both the sender and receiver should spend more computing power on the compression and decompression of the packets over the air. Secondly, the 6LoWPAN working group developed the energy-efficient Neighbor Discovery called 6LoWPAN-ND, which is an energy efficient replacement of the IPv6 ND in constrained environments. IPv6 Neighbor Discovery was not designed for non-transitive wireless links, as its heavy use of multicast makes it inefficient and sometimes impractical in a low- @@ -558,27 +636,27 @@ to exchange messages periodically and keep routing states for each destination. RPL is optimized for the many-to-one communication pattern, where network nodes primarily send data towards the border router, but has provisions for any-to-any routing as well. The authors of the Powertrace tool [Powertrace] studied the power profile of RPL. It divides the routing protocol into control and data traffic. The control channel uses ICMP messages to establish and maintain the routing states. The data channel is any application that uses RPL for routing packets. The study has shown that the - power consumption of the control traffic goes down over time and data - traffic stays relatively constant. The study also reflects that the - routing protocol should keep the control traffic as low as possible - to make it energy-friendly. The amount of RPL control traffic can be - tuned by setting the Trickle algorithm parameters (i.e. Imin, Imax - and k) to adequate values. However, there exists a trade-off between - energy consumption and other performance parameters such as network + power consumption of the control traffic goes down over time in a + relatively stable network. The study also reflects that the routing + protocol should keep the control traffic as low as possible to make + it energy-friendly. The amount of RPL control traffic can be tuned + by setting the Trickle algorithm parameters (i.e. Imin, Imax and k) + to adequate values. However, there exists a trade-off between energy + consumption and other performance parameters such as network convergence time and robustness. RFC 6551 [RFC6551] defines routing metrics and constraints to be used by RPL in route computation. Among others, RFC 6551 specifies a Node Energy object that allows to provide information related to node energy, such as the energy source type or the estimated percentage of remaining energy. Appropriate use of energy-based routing metrics may help to balance energy consumption of network nodes, minimize network partitioning and increase network lifetime. @@ -591,21 +669,21 @@ is not a chatty protocol, it provides basic communication services such as service discovery and GET/POST/PUT/DELETE methods with a binary header. The energy-efficient design is implicitly included in the CoAP protocol design. CoAP uses a fixed-length binary header of only four bytes that may be followed by binary options. To reduce regular and frequent queries of the resources, CoAP provides an observe mode, in which the requester registers its interest of a certain resource and the responder will report the value whenever it was updated. This - reduces the request response roundtrip while keeping information + reduces the request response round trips while keeping information exchange a ubiquitous service and, most importantly, it allows an energy-constrained server to remain in sleep mode during the period between observe notification transmissions. Furthermore, [RFC7252] defines CoAP proxies which can cache resource representations previously provided by sleepy CoAP servers. The 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. @@ -668,163 +746,180 @@ be fine-tuned to exploit the collaboration with the lower layer protocols. Layers should offer interfaces that can be exploited by other layers in order to optimize global protocol stack performance. c. The power trace analysis of different protocol operations showed that for radio-duty-cycled networks broadcasts should be avoided. Saving unnecessary states maintenance is also an effective method to be energy-friendly. -8. Acknowledgments +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. Authors would like to thank the review and feedback from a number of experts in this area: Carsten Bormann, Ari Keranen, Hannes - Tschofenig. + 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. -9. IANA Considerations +10. IANA Considerations This document has no IANA requests. -10. Security Considerations +11. Security Considerations This document discusses the energy efficient protocol design, and does not incur any changes or challenges on security issues besides what the protocol specifications have analyzed. -11. References +12. References -11.1. Normative References +12.1. Normative References + + [Bluetooth42] + "Bluetooth Core Specification Version 4.2", 2014. + + [EN300] ""Digital Enhanced Cordless Telecommunications (DECT); + Common Interface (CI);"", 2013. + + [IEEE80211v] + IEEE, , "Part 11: Wireless LAN Medium Access Control (MAC) + and Physical Layer (PHY) specifications, Amendment 8: IEEE + 802.11 Wireless Network Management.", February 2012. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, + "Transmission of IPv6 Packets over IEEE 802.15.4 + Networks", RFC 4944, September 2007. + + [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. + + [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. + Barthel, "Routing Metrics Used for Path Calculation in + Low-Power and Lossy Networks", RFC 6551, March 2012. + + [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link + Format", RFC 6690, August 2012. + + [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, + "Neighbor Discovery Optimization for IPv6 over Low-Power + Wireless Personal Area Networks (6LoWPANs)", RFC 6775, + November 2012. + + [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for + Constrained-Node Networks", RFC 7228, May 2014. + + [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained + Application Protocol (CoAP)", RFC 7252, June 2014. + + [TS102] ""Digital Enhanced Cordless Telecommunications (DECT); + Ultra Low Energy (ULE); Machine to Machine Communications; + Part 1: Home Automation Network (phase 1)"", 2013. + + [fifteendotfour] + "802.15.4-2011", 2011. + +12.2. Informative References [AN053] Selvig, B., "Measuring power consumption with CC2430 and - Z-Stack", . + Z-Stack". [Announcementlayer] Dunkels, A., "The Announcement Layer: Beacon Coordination - for the Sensornet Stack. In Proceedings of EWSN 2011", . - - [Bluetooth41] - "Bluetooth Core Specification Version 4.1", 2013. + 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.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-01 (work in progress), + January 2015. + [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. [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., Watteyne, T., Struik, R., and M. Richardson, - "An Architecture for IPv6 over the TSCH mode of IEEE - 802.15.4e", draft-ietf-6tisch-architecture-05 (work in - progress), January 2015. + Thubert, P., "An Architecture for IPv6 over the TSCH mode + of IEEE 802.15.4", draft-ietf-6tisch-architecture-08 (work + in progress), May 2015. [I-D.ietf-6tisch-minimal] Vilajosana, X. and K. Pister, "Minimal 6TiSCH - Configuration", draft-ietf-6tisch-minimal-05 (work in - progress), January 2015. + Configuration", draft-ietf-6tisch-minimal-06 (work in + progress), March 2015. [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-resource-directory] Shelby, Z. and C. Bormann, "CoRE Resource Directory", draft-ietf-core-resource-directory-02 (work in progress), November 2014. [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. [I-D.koster-core-coap-pubsub] Koster, M., Keranen, A., and J. Jimenez, "Publish- - Subscribe in the Constrained Application Protocol (CoAP)", - draft-koster-core-coap-pubsub-00 (work in progress), - October 2014. + Subscribe Broker for the Constrained Application Protocol + (CoAP)", draft-koster-core-coap-pubsub-01 (work in + progress), March 2015. [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. - [IEEE80211v] - IEEE, , "Part 11: Wireless LAN Medium Access Control (MAC) - and Physical Layer (PHY) specifications, Amendment 8: IEEE - 802.11 Wireless Network Management.", February 2012. - [Powertrace] Dunkels, , Eriksson, , Finne, , and Tsiftes, "Powertrace: Network-level Power Profiling for Low-power Wireless Networks", March 2011. - [fifteendotfour] - "802.15.4-2011", 2011. - -11.2. Informative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, - "Transmission of IPv6 Packets over IEEE 802.15.4 - Networks", RFC 4944, September 2007. - - [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. - - [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. - Barthel, "Routing Metrics Used for Path Calculation in - Low-Power and Lossy Networks", RFC 6551, March 2012. - - [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link - Format", RFC 6690, August 2012. - - [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, - "Neighbor Discovery Optimization for IPv6 over Low-Power - Wireless Personal Area Networks (6LoWPANs)", RFC 6775, - November 2012. - - [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for - Constrained-Node Networks", RFC 7228, May 2014. - - [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained - Application Protocol (CoAP)", RFC 7252, June 2014. - Authors' Addresses Zhen Cao (Ed.) Leibniz University of Hannover P.R.China Email: zhencao.ietf@gmail.com Carles Gomez Universitat Politecnica de Catalunya/i2CAT