--- 1/draft-ietf-lwig-energy-efficient-03.txt 2016-02-25 02:15:27.457027772 -0800 +++ 2/draft-ietf-lwig-energy-efficient-04.txt 2016-02-25 02:15:27.505028968 -0800 @@ -1,55 +1,55 @@ -Internet Engineering Task Force Z. Cao -Internet-Draft Leibniz University of Hannover -Intended status: Informational C. Gomez -Expires: November 20, 2015 Universitat Politecnica de Catalunya/i2CAT - M. Kovatsch - ETH Zurich +Internet Engineering Task Force C. Gomez +Internet-Draft Universitat Politecnica de Catalunya/i2CAT +Intended status: Informational M. Kovatsch +Expires: August 28, 2016 ETH Zurich H. Tian China Academy of Telecommunication Research - X. He - Hitachi China R&D Corporation - May 19, 2015 + Z. Cao, Ed. + Huawei Technologies + February 25, 2016 - Energy Efficient Implementation of IETF Constrained Protocol Suite - draft-ietf-lwig-energy-efficient-03 + Energy-Efficient Features of Internet of Things Protocols + draft-ietf-lwig-energy-efficient-04 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. + 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. 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 November 20, 2015. + This Internet-Draft will expire on August 28, 2016. Copyright Notice - Copyright (c) 2015 IETF Trust and the persons identified as the + Copyright (c) 2016 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 @@ -71,80 +71,79 @@ 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 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 + 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 - 12.2. Informative References . . . . . . . . . . . . . . . . . 18 + 12.2. Informative References . . . . . . . . . . . . . . . . . 19 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 + Network systems for physical world monitoring contain many battery- + powered or energy-harvesting devices. For example, in an + environmental monitoring system, or a temperature and humidity + monitoring system, there are no always-on and 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 - layer behavior, and lower layer communication. + such deployment scenarios, it is necessary to optimize the energy + consumption of the constrained devices. - Significant research efforts have been spent on this "energy + 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 were - spent on energy-efficient designs for IETF protocols and standardized - network stacks for such constrained devices + 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 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. + 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. 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]. 2. Overview - The IETF has developed multiple protocols to enable end-to-end IP + 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 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. @@ -155,41 +154,41 @@ \ / / / \ +-----+ +-----+ +-----+ +-----+ | TCP | | UDP | | TCP | | UDP | +-----+ +-----+ ===> +-----+ +-----+ \ / \ / +-----+ +------+ +-------+ +------+ +-----+ | RTG |--| IPv6 |--|ICMP/ND| | IPv6 |---| RPL | +-----+ +------+ +-------+ +------+ +-----+ | | +-------+ +-------+ +----------+ - |MAC/PHY| |6LoWPAN|--|6LoWPAN-ND| + |MAC/PHY| | 6Lo |--|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 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 may be in the - same order. For IEEE 802.15.4 and UWB radios, transmitting may - actually be even cheaper than receiving. Only for broadcast and non- - synchronized communication transmissions become costly in terms of - energy because they need to flood the medium for a long time. + 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. +---------------------------------------+---------------+ | Activity | Energy (uJ) | +---------------------------------------+---------------+ | Broadcast reception | 178 | +---------------------------------------+---------------+ | Unicast reception | 222 | +---------------------------------------+---------------+ | Broadcast transmission | 1790 | +---------------------------------------+---------------+ @@ -212,23 +211,23 @@ 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 message), even if no message is being transmitted to that device. Idle listening consumes a huge amount of energy unnecessarily. To reduce power consumption, the radio must be switched completely off -- duty-cycled -- as much as possible. By applying duty-cycling, the lifetime of a device operating on a common button battery may be in the order of years, whereas otherwise the battery may be exhausted in a few days or even hours. Duty-cycling is a technique generally - exploited by devices that use the P1 strategy [RFC7228], which need - to be able to communicate on a relatively frequent basis. Note that - a more aggressive approach to save energy relies on the P0, Normally- + employed by devices that use the P1 strategy [RFC7228], which need to + be able to communicate on a relatively frequent basis. Note that a + more aggressive approach to save energy relies on the P0, Normally- off strategy, whereby devices sleep for very long periods and communicate infrequently, even though they spend energy in network reattachment procedures. From the perspective of MAC&RDC, all upper layer protocols, such as routing, RESTful communication, adaptation, and management flows, are all applications. Since the duty cycling algorithm is the key to energy-efficiency of the wireless medium, it synchronizes the transmission and/or reception request from the higher layer. @@ -657,21 +656,21 @@ 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. 6. Application Layer 6.1. Energy efficient features in CoAP - CoAP [RFC7252] was designed as a RESTful application protocol, + CoAP [RFC7252] is designed as a RESTful application protocol, connecting the services of smart devices to the World Wide Web. CoAP 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 @@ -724,41 +723,39 @@ RTO value is chosen randomly between 2 and 3 s. If an RTO expires, the new RTO value is doubled (unless a limit on the number of retransmissions has been reached). Since duty-cycling at the link layer may lead to long latency (i.e. even greater than the initial 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 find a summary section necessary although most IETF documents do - not contain it. The points we would like to summarize are as - follows. + We summarize the key takeaways in this document: - a. All Internet protocols, which are in the scope of the IETF, are - customers of the lower layers (PHY, MAC, and Duty-cycling). In - order to get a better service, the designers of higher layers - should know them better. + 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. - b. The IETF has developed multiple protocols for constrained - networked devices. A lot of implicit energy efficient design - principles have been used in these protocols. The latter should - 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. + b. It is always useful to compresss 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. 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. + c. Broadcast and non-synchronzed 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. @@ -784,170 +781,176 @@ 12. References 12.1. Normative References [Bluetooth42] "Bluetooth Core Specification Version 4.2", 2014. [EN300] ""Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI);"", 2013. + [fifteendotfour] + "802.15.4-2011", 2011. + [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. + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, 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. + Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, + . - [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 + [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, - September 2011. + DOI 10.17487/RFC6282, 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. + [RFC6550] Winter, T., Ed., Thubert, P., Ed., 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, + DOI 10.17487/RFC6550, 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. + [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., + and D. Barthel, "Routing Metrics Used for Path Calculation + in Low-Power and Lossy Networks", RFC 6551, + DOI 10.17487/RFC6551, March 2012, + . [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link - Format", RFC 6690, August 2012. + Format", RFC 6690, DOI 10.17487/RFC6690, 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. + [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. + Bormann, "Neighbor Discovery Optimization for IPv6 over + Low-Power Wireless Personal Area Networks (6LoWPANs)", + RFC 6775, DOI 10.17487/RFC6775, November 2012, + . [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for - Constrained-Node Networks", RFC 7228, May 2014. + 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, June 2014. + Application Protocol (CoAP)", RFC 7252, + DOI 10.17487/RFC7252, 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". [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.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. + Energy", draft-ietf-6lo-dect-ule-03 (work in progress), + September 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., "An Architecture for IPv6 over the TSCH mode - of IEEE 802.15.4", draft-ietf-6tisch-architecture-08 (work - in progress), May 2015. + of IEEE 802.15.4", draft-ietf-6tisch-architecture-09 (work + in progress), November 2015. [I-D.ietf-6tisch-minimal] Vilajosana, X. and K. Pister, "Minimal 6TiSCH - Configuration", draft-ietf-6tisch-minimal-06 (work in - progress), March 2015. + Configuration", draft-ietf-6tisch-minimal-14 (work in + progress), January 2016. [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. + Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE + Resource Directory", draft-ietf-core-resource-directory-05 + (work in progress), October 2015. [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 Broker for the Constrained Application Protocol - (CoAP)", draft-koster-core-coap-pubsub-01 (work in - progress), March 2015. + (CoAP)", draft-koster-core-coap-pubsub-04 (work in + progress), November 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. [Powertrace] Dunkels, , Eriksson, , Finne, , and Tsiftes, "Powertrace: Network-level Power Profiling for Low-power Wireless Networks", March 2011. Authors' Addresses - Zhen Cao (Ed.) - Leibniz University of Hannover - P.R.China - - Email: zhencao.ietf@gmail.com - Carles Gomez Universitat Politecnica de Catalunya/i2CAT C/Esteve Terradas, 7 Castelldefels 08860 Spain Email: carlesgo@entel.upc.edu - Matthias Kovatsch ETH Zurich Universitaetstrasse 6 Zurich, CH-8092 Switzerland Email: kovatsch@inf.ethz.ch + Hui Tian China Academy of Telecommunication Research Huayuanbeilu No.52 Beijing, Haidian District 100191 China Email: tianhui@mail.ritt.com.cn - Xuan He - Hitachi China R&D Corporation - 301, Tower C North, Raycom, 2 Kexuyuan Nanlu, Haidian District - Beijing 100190 - P.R.China + Zhen Cao (editor) + Huawei Technologies + China - Email: xhe@hitachi.cn + Email: zhencao.ietf@gmail.com