--- 1/draft-ietf-lwig-energy-efficient-00.txt 2014-10-27 02:14:49.630436867 -0700 +++ 2/draft-ietf-lwig-energy-efficient-01.txt 2014-10-27 02:14:49.670437868 -0700 @@ -1,89 +1,97 @@ Internet Engineering Task Force Z. Cao -Internet-Draft China Mobile +Internet-Draft Leibniz University of Hannover Intended status: Informational C. Gomez -Expires: September 22, 2014 Universitat Politecnica de Catalunya/i2CAT +Expires: April 30, 2015 Universitat Politecnica de + Catalunya/i2CAT M. Kovatsch ETH Zurich H. Tian - China Academy of Telecommunication Research + China Academy of + Telecommunication Research X. He - Hitachi China R&D Corporation - March 21, 2014 + Hitachi China R&D + Corporation + October 27, 2014 Energy Efficient Implementation of IETF Constrained Protocol Suite - draft-ietf-lwig-energy-efficient-00 + draft-ietf-lwig-energy-efficient-01 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. -Status of This Memo +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 September 22, 2014. + This Internet-Draft will expire on April 30, 2015. Copyright Notice Copyright (c) 2014 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. MAC and Radio Duty Cycling . . . . . . . . . . . . . . . . . 5 - 3.1. Power Save Services Provided by IEEE 802.11v . . . . . . 6 - 3.2. Power Save Services Provided by Bluetooth Low Energy . . 6 - 3.3. Power Save Services in IEEE 802.15.4 . . . . . . . . . . 7 - 4. IP Adaptation and Transport Layer . . . . . . . . . . . . . . 9 - 5. Routing Protocols . . . . . . . . . . . . . . . . . . . . . . 10 - 6. Application Layer . . . . . . . . . . . . . . . . . . . . . . 10 - 7. Cross Layer Optimization . . . . . . . . . . . . . . . . . . 11 - 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 - 12.2. Informative References . . . . . . . . . . . . . . . . . 14 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. MAC and Radio Duty Cycling . . . . . . . . . . . . . . . . . . 6 + 3.1. Radio Duty Cycling techniques . . . . . . . . . . . . . . 6 + 3.2. Latency and buffering . . . . . . . . . . . . . . . . . . 7 + 3.3. Power save services available in example low-power + radios . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.3.1. Power Save Services Provided by IEEE 802.11v . . . . . 8 + 3.3.2. Power Save Services Provided by Bluetooth Low + Energy . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.3.3. Power Save Services in IEEE 802.15.4 . . . . . . . . . 10 + 4. IP Adaptation and Transport Layer . . . . . . . . . . . . . . 12 + 5. Routing Protocols . . . . . . . . . . . . . . . . . . . . . . 13 + 6. Application Layer . . . . . . . . . . . . . . . . . . . . . . 14 + 7. Cross Layer Optimization . . . . . . . . . . . . . . . . . . . 15 + 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction In many scenarios, the network systems comprises many battery-powered or energy-harvesting devices. For example, in an environmental monitoring system or a temperature and humidity monitoring system in the data center, there are no always-on and handy sustained power supplies for the large number of small devices. In such deployment environments, it is necessary to optimize the energy consumption of the entire system, including computing, application layer behavior, @@ -103,43 +111,44 @@ 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. 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 network and application layers is also important to - make the device battery-friendly. + 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 - [I-D.ietf-lwig-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 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 show 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. + 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 and MS/TP-BACnet. +-----+ +-----+ +-----+ +------+ |http | | ftp | |SNMP | | COAP | +-----+ +-----+ +-----+ +------+ \ / / / \ +-----+ +-----+ +-----+ +-----+ | tcp | | udp | | tcp | | udp | +-----+ +-----+ ===> +-----+ +-----+ \ / \ / +-----+ +------+ +-------+ +------+ +-----+ @@ -149,30 +158,31 @@ +-------+ +-------+ +----------+ |MAC/PHY| |6lowpan|--|6lowpan-nd| +-------+ +-------+ +----------+ | +-------+ |MAC/PHY| +-------+ Figure 1: Traditional and Light-weight Internet Protocol Stack - There are comprehensive measurements of wireless communication - [Powertrace]. 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 as the radio - duty cycling algorithm. From the measurement, we can see that - optimized transmissions and reception consume almost the same amount - of energy. For IEEE 802.15.4 and UWB radios, transmitting is - actually 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. + There are numerous published studies reporting comprehensive + measurements of wireless communication platforms[Powertrace]. 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 as the radio duty cycling + algorithm. From the measurement, we can see that optimized + transmissions and reception consume almost the same amount of energy. + 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. +---------------------------------------+---------------+ | Activity | Energy (uJ) | +---------------------------------------+---------------+ | Broadcast reception | 178 | +---------------------------------------+---------------+ | Unicast reception | 222 | +---------------------------------------+---------------+ | Broadcast transmission | 1790 | +---------------------------------------+---------------+ @@ -184,44 +194,125 @@ +---------------------------------------+---------------+ Figure 2: Power consumption of atom operations 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 consumes - as much power in listen mode as when actively transmitting, as show - in Figure 2 . To reduce power consumption, the radio must be switched - completely off -- duty-cycled -- as much as possible. ContikiMAC is - a very typical Radio Duty Cycling (RDC) protocol [ContikiMAC]. + 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 + 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- + off strategy, whereby devices sleep for very long periods and + communicate infrequently, even though they spend energy in network + reattachment procedures. ContikiMAC is an example of a very typical + Radio Duty Cycling (RDC) protocol [ContikiMAC]. 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 TX/RX request from the higher layer. The MAC&RDC are not in the scope of the IETF, yet lower layer designers and chipset manufactures take great care of the problem. For the IETF protocol designers, however, it is good to know the behaviors of lower layers so that the designed protocols can work perfectly with them. Once again, the IETF protocols we are going to talk about in the following sections are the customers of the lower layer. If they want to get better service in a cooperative way, they should be considerate and understand each other. -3.1. Power Save Services Provided by IEEE 802.11v +3.1. Radio Duty Cycling techniques + + This subsection describes the main three RDC techniques. Note that + more than one of the presented techniques may be available or can + even be combined in a specific radio technology: + + a) Channel sampling. In this solution, the radio interface of a + device periodically monitors the channel for very short time + intervals (i.e. with a low duty cycle) with the aim of detecting + incoming transmissions. In order to make sure that a receiver can + correctly receive a transmitted data unit, the sender may prepend a + preamble of a duration at least the sampling period to the data unit + to be sent. Another option for the sender is to repeatedly transmit + the data unit, instead of sending a preamble before the data unit. + Once a transmission is detected by a receiver, the receiver may stay + awake until the complete reception of the data unit. Examples of + 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. + + 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. 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. + +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 + increase, RDC may introduce latency variance, since the latency + increase is a random variable (which is uniformly distributed if + duty-cycling follows a periodical behavior). + + On the other hand, due to the latency increase of duty-cycling, a + sender waiting for a transmission opportunity may need to store + subsequent outgoing packets in a buffer, increasing memory + requirements and potentially incurring queuing waiting time that + contributes to the packet overall delay and increases the probability + of buffer overflow, leading to losses. + + The parameters controlling the radio duty cycle have to be carefully + tuned to achieve the intended application and/or network + requirements. On the other hand, upper layers should take into + account the expected latency behavior due to RDC. + +3.3. 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 + corresponding specifications. + +3.3.1. Power Save Services Provided by IEEE 802.11v IEEE 802.11v [IEEE80211v] defines mechanisms and services for power save of stations/nodes that include flexible multicast service (FMS), proxy ARP advertisement, extended sleep modes, traffic filtering. It would be useful if upper layer protocols knows such capabilities provided by the lower layer, so that they can coordinate with each other. These services include: @@ -247,104 +338,106 @@ 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.2. Power Save Services Provided by Bluetooth Low Energy +3.3.2. Power Save Services Provided by Bluetooth Low Energy - Bluetooth Low Energy (BT-LE) is a wireless low-power communications - technology that is the hallmark component of the Bluetooth 4.0 - specification. BT-LE has been designed for the goal of ultra-low- - power consumption. Currently, it is possible to run IPv6 over BT-LE - networks by using a 6LoWPAN variant adapted to BT-LE - [I-D.ietf-6lowpan-btle]. + 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 BT-LE networks by using a + 6LoWPAN variant adapted to BT-LE [I-D.ietf-6lowpan-btle]. - BT-LE networks comprise a master and one or more slaves which are - connected to the master. The BT-LE master is assumed to be a - relatively powerful device, whereas a slave is typically a + 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 BT-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 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, - BT-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 inactivity for more than - connSupervisionTimeout time. The connSupervisionTimeout parameter is - in the range between 100 ms and 32 s. + 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 + inactivity for more than connSupervisionTimeout time. The + connSupervisionTimeout parameter is in the range between 100 ms and + 32 s. Upper layer protocols should take into account the medium access and - duty-cycling behavior of BT-LE. In particular, connInterval, + duty-cycling behavior of Bluetooth LE. In particular, connInterval, connSlaveLatency and connSupervisionTimeout determine the time between two consecutive connection events for a given slave. The upper layer packet generation pattern and rate should be consistent with the settings of the aforementioned parameters (and vice versa). -3.3. Power Save Services in IEEE 802.15.4 +3.3.3. Power Save Services in IEEE 802.15.4 IEEE 802.15.4 is a family of standard radio interfaces for low-rate, - low-power wireless networking. 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 + 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 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 - coordinator, the radio of the latter will be ready to receive the - message. + 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 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. In the beaconless mode, nodes use unslotted CSMA/CA for data @@ -372,20 +465,23 @@ 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. + Other 802.15.4e modes, which are in fact designed for low energy, are + the previously mentioned CSL and RIT. + 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 @@ -437,37 +533,62 @@ 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 convergence time and robustness. - Todo: more discussion of energy efficient routing. + 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. 6. Application Layer - CoAP [I-D.ietf-core-coap]was 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. + CoAP [RFC7252] was 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. 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 exchange a ubiquitous - service. + 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 + 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. + + 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 + Resource Directory [I-D.ietf-core-resource-directory] or signaling + when a node is awake to the interested nodes. As of the writing, + none of these proposals has been adopted by the CoRE working group. CoAP offers mechanisms for reliable communication between two CoAP endpoints. A CoAP message may be signaled as a confirmable (CON) message, and an acknowledgment (ACK) is issued by the receiver if the CON message is correctly received. The sender starts a Retransmission TimeOut (RTO) for every CON message sent. The initial 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 @@ -534,135 +655,177 @@ 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. 12. References 12.1. Normative References [Announcementlayer] Dunkels, A., "The Announcement Layer: Beacon Coordination - for the Sensornet Stack. In Proceedings of EWSN 2011", . + for the Sensornet Stack. In Proceedings of EWSN 2011". + + [Bluetooth41] + "Bluetooth Core Specification Version 4.1", 2013. [ContikiMAC] Dunkels, A., "The ContikiMAC Radio Duty Cycling Protocol, SICS Technical Report T2011:13", December 2011. [Cross-layer-Optimization] - Le, and Hossain, "Cross-Layer Optimization Frameworks for + Le and Hossain, "Cross-Layer Optimization Frameworks for Multihop Wireless Networks Using Cooperative Diversity", July 2008. [Cross-layer-design] - Chen, , Low, , and Doyle, "Cross-layer design in multihop + Chen, Low, and Doyle, "Cross-layer design in multihop wireless networks", 2011. [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. + Detection is too impatient", + draft-ietf-6man-impatient-nud-07 (work in progress), + October 2013. [I-D.ietf-6tisch-architecture] Thubert, P., Watteyne, T., and R. Assimiti, "An Architecture for IPv6 over the TSCH mode of IEEE - 802.15.4e", draft-ietf-6tisch-architecture-01 (work in - progress), February 2014. + 802.15.4e", draft-ietf-6tisch-architecture-03 (work in + progress), July 2014. [I-D.ietf-6tisch-minimal] Vilajosana, X. and K. Pister, "Minimal 6TiSCH - Configuration", draft-ietf-6tisch-minimal-00 (work in - progress), November 2013. + Configuration", draft-ietf-6tisch-minimal-02 (work in + progress), July 2014. [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., Bormann, C., and S. Krco, "CoRE Resource + Directory", draft-ietf-core-resource-directory-01 (work in + progress), December 2013. + [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.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) + 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: + Dunkels, Eriksson, Finne, and Tsiftes, "Powertrace: Network-level Power Profiling for Low-power Wireless Networks", March 2011. + [fifteendotfour] + "802.15.4-2011", 2011. + 12.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.) - China Mobile - Xuanwumenxi Ave. No.32 - Beijing 100871 + Leibniz University of Hannover P.R.China - Email: zehn.cao@gmail.com, caozhen@chinamobile.com + Phone: + Email: zhencao.ietf@gmail.com + Carles Gomez Universitat Politecnica de Catalunya/i2CAT C/Esteve Terradas, 7 - Castelldefels 08860 + Castelldefels, 08860 Spain + Phone: + Fax: Email: carlesgo@entel.upc.edu + URI: Matthias Kovatsch ETH Zurich Universitaetstrasse 6 Zurich, CH-8092 Switzerland + Phone: + Fax: Email: kovatsch@inf.ethz.ch + URI: Hui Tian China Academy of Telecommunication Research Huayuanbeilu No.52 Beijing, Haidian District 100191 China + Phone: + Fax: Email: tianhui@mail.ritt.com.cn + URI: Xuan He Hitachi China R&D Corporation 301, Tower C North, Raycom, 2 Kexuyuan Nanlu, Haidian District - Beijing 100190 + Beijing, 100190 P.R.China + Phone: + Fax: Email: xhe@hitachi.cn + URI: