draft-ietf-lwig-energy-efficient-03.txt | draft-ietf-lwig-energy-efficient-04.txt | |||
---|---|---|---|---|
Internet Engineering Task Force Z. Cao | Internet Engineering Task Force C. Gomez | |||
Internet-Draft Leibniz University of Hannover | Internet-Draft Universitat Politecnica de Catalunya/i2CAT | |||
Intended status: Informational C. Gomez | Intended status: Informational M. Kovatsch | |||
Expires: November 20, 2015 Universitat Politecnica de Catalunya/i2CAT | Expires: August 28, 2016 ETH Zurich | |||
M. Kovatsch | ||||
ETH Zurich | ||||
H. Tian | H. Tian | |||
China Academy of Telecommunication Research | China Academy of Telecommunication Research | |||
X. He | Z. Cao, Ed. | |||
Hitachi China R&D Corporation | Huawei Technologies | |||
May 19, 2015 | February 25, 2016 | |||
Energy Efficient Implementation of IETF Constrained Protocol Suite | Energy-Efficient Features of Internet of Things Protocols | |||
draft-ietf-lwig-energy-efficient-03 | draft-ietf-lwig-energy-efficient-04 | |||
Abstract | Abstract | |||
This document summarizes the problems and current practices of energy | This document describes the problems and current practices of energy | |||
efficient protocol implementation on constrained devices, mostly | efficient protocol operation on constrained devices. It summarizes | |||
about how to make the protocols within IETF scope behave energy | the main link layer techniques for energy efficient networking, and | |||
friendly. This document also summarizes the impact of link layer | it highlights the impact of such techniques on the upper layer | |||
protocol power saving behaviors to the upper layer protocols, so that | protocols, so that they can coordinately achieve an energy efficient | |||
they can coordinately make the system 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 | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | 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 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. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
skipping to change at page 2, line 38 | skipping to change at page 2, line 38 | |||
3.5.2. Power Save Services Provided by Bluetooth LE . . . . 9 | 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.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 . . . . . . . . . . . 11 | |||
4. IP Adaptation and Transport Layer . . . . . . . . . . . . . . 13 | 4. IP Adaptation and Transport Layer . . . . . . . . . . . . . . 13 | |||
5. Routing Protocols . . . . . . . . . . . . . . . . . . . . . . 14 | 5. Routing Protocols . . . . . . . . . . . . . . . . . . . . . . 14 | |||
6. Application Layer . . . . . . . . . . . . . . . . . . . . . . 15 | 6. Application Layer . . . . . . . . . . . . . . . . . . . . . . 15 | |||
6.1. Energy efficient features in CoAP . . . . . . . . . . . . 15 | 6.1. Energy efficient features in CoAP . . . . . . . . . . . . 15 | |||
6.2. Sleepy node support . . . . . . . . . . . . . . . . . . . 15 | 6.2. Sleepy node support . . . . . . . . . . . . . . . . . . . 15 | |||
6.3. CoAP timers . . . . . . . . . . . . . . . . . . . . . . . 16 | 6.3. CoAP timers . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 | 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 | 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 | |||
11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . 17 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . 18 | 12.2. Informative References . . . . . . . . . . . . . . . . . 19 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
1. Introduction | 1. Introduction | |||
In many scenarios, the network systems comprise many battery-powered | Network systems for physical world monitoring contain many battery- | |||
or energy-harvesting devices. For example, in an environmental | powered or energy-harvesting devices. For example, in an | |||
monitoring system or a temperature and humidity monitoring system in | environmental monitoring system, or a temperature and humidity | |||
a data center, there are no always-on and handy sustained power | monitoring system, there are no always-on and sustained power | |||
supplies for the potentially large number of constrained devices. In | supplies for the potentially large number of constrained devices. In | |||
such deployment environments, it is necessary to optimize the energy | such deployment scenarios, it is necessary to optimize the energy | |||
consumption of the entire system, including computing, application | consumption of the constrained devices. | |||
layer behavior, and lower layer communication. | ||||
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 | efficiency" problem. Most of this research has focused on how to | |||
optimize the system's power consumption regarding a certain | optimize the system's power consumption regarding a certain | |||
deployment scenario or how could an existing network function such as | deployment scenario or how could an existing network function such as | |||
routing or security be more energy-efficient. Only few efforts were | routing or security be more energy-efficient. Only few efforts | |||
spent on energy-efficient designs for IETF protocols and standardized | focused on energy-efficient designs for IETF protocols and | |||
network stacks for such constrained devices | standardized network stacks for such constrained devices | |||
[I-D.kovatsch-lwig-class1-coap]. | [I-D.kovatsch-lwig-class1-coap]. | |||
The IETF has developed a suite of Internet protocols suitable for | The IETF has developed a suite of Internet protocols suitable for | |||
such constrained devices, including 6LoWPAN ( | such constrained devices, including 6LoWPAN ( | |||
[RFC6282],[RFC6775],[RFC4944] ), RPL[RFC6550], and | [RFC6282],[RFC6775],[RFC4944] ), RPL[RFC6550], and | |||
CoAP[I-D.ietf-core-coap]. This document tries to summarize the | CoAP[I-D.ietf-core-coap]. This document tries to summarize the | |||
design considerations of making the IETF protocol suite as energy- | design considerations of making the IETF contrained protocol suite as | |||
efficient as possible. While this document does not provide detailed | energy-efficient as possible. While this document does not provide | |||
and systematic solutions to the energy efficiency problem, it | detailed and systematic solutions to the energy efficiency problem, | |||
summarizes the design efforts and analyzes the design space of this | it summarizes the design efforts and analyzes the design space of | |||
problem. In particular, it provides a comprehensive overview of the | this problem. In particular, it provides a comprehensive overview of | |||
techniques used by the lower layers to save energy and how these may | the techniques used by the lower layers to save energy and how these | |||
impact on the upper layers. | may impact on the upper layers. | |||
After reviewing the energy-efficient design of each layer, an overall | After reviewing the energy-efficient design of each layer, an overall | |||
conclusion is summarized. Though the lower layer communication | conclusion is summarized. Though the lower layer communication | |||
optimization is the key part of energy efficient design, the protocol | optimization is the key part of energy efficient design, the protocol | |||
design at the upper layers is also important to make the device | design at the upper layers is also important to make the device | |||
energy-efficient. | energy-efficient. | |||
1.1. Conventions used in this document | 1.1. Conventions used in this document | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119] | document are to be interpreted as described in [RFC2119] | |||
1.2. Terminology | 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]. | |||
2. Overview | 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. | communication between constrained nodes and fully capable nodes. | |||
This work has witnessed the evolution of the traditional Internet | This work has witnessed the evolution of the traditional Internet | |||
protocol stack to a light-weight Internet protocol stack. As shown | protocol stack to a light-weight Internet protocol stack. As shown | |||
in Figure 1 below, the IETF has developed CoAP as the application | in Figure 1 below, the IETF has developed CoAP as the application | |||
layer and 6LoWPAN as the adaption layer to run IPv6 over IEEE | 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 | 802.15.4 and Bluetooth Low-Energy, with the support of routing by RPL | |||
and efficient neighbor discovery by 6LoWPAN-ND. 6LoWPAN is currently | and efficient neighbor discovery by 6LoWPAN-ND. 6LoWPAN is currently | |||
being adapted by the 6lo working group to support IPv6 over various | 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 | other technologies, such as ITU-T G.9959, DECT ULE, MS/TP-BACnet and | |||
NFC. | NFC. | |||
skipping to change at page 4, line 25 | skipping to change at page 4, line 24 | |||
\ / / / \ | \ / / / \ | |||
+-----+ +-----+ +-----+ +-----+ | +-----+ +-----+ +-----+ +-----+ | |||
| 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| | 6Lo |--|6LoWPAN-ND| | |||
+-------+ +-------+ +----------+ | +-------+ +-------+ +----------+ | |||
| | | | |||
+-------+ | +-------+ | |||
|MAC/PHY| | |MAC/PHY| | |||
+-------+ | +-------+ | |||
Figure 1: Traditional and Light-weight Internet Protocol Stack | Figure 1: Traditional and Light-weight Internet Protocol Stack | |||
There are numerous published studies reporting comprehensive | There are numerous published studies reporting comprehensive | |||
measurements of wireless communication platforms [Powertrace]. As an | measurements of wireless communication platforms [Powertrace]. As an | |||
example, below we list the energy consumption profile of the most | example, below we list the energy consumption profile of the most | |||
common atom operations on a prevalent sensor node platform. The | common atom operations on a prevalent sensor node platform. The | |||
measurement was based on the Tmote Sky with ContikiMAC [ContikiMAC] | measurement was based on the Tmote Sky with ContikiMAC [ContikiMAC] | |||
as the radio duty cycling algorithm. From this and many other | as the radio duty cycling algorithm. From this and many other | |||
measurement reports (e.g. [AN053]), we can see that the energy | measurement reports (e.g. [AN053]), we can see that the energy | |||
consumption of optimized transmission and reception may be in the | consumption of optimized transmission and reception are in the same | |||
same order. For IEEE 802.15.4 and UWB radios, transmitting may | order. For IEEE 802.15.4 and UWB links, transmitting may actually be | |||
actually be even cheaper than receiving. Only for broadcast and non- | even cheaper than receiving. It also shows that broadcast and non- | |||
synchronized communication transmissions become costly in terms of | synchronized communication transmissions are energy costly because | |||
energy because they need to flood the medium for a long time. | they need to acquire the medium for a long time. | |||
+---------------------------------------+---------------+ | +---------------------------------------+---------------+ | |||
| Activity | Energy (uJ) | | | Activity | Energy (uJ) | | |||
+---------------------------------------+---------------+ | +---------------------------------------+---------------+ | |||
| Broadcast reception | 178 | | | Broadcast reception | 178 | | |||
+---------------------------------------+---------------+ | +---------------------------------------+---------------+ | |||
| Unicast reception | 222 | | | Unicast reception | 222 | | |||
+---------------------------------------+---------------+ | +---------------------------------------+---------------+ | |||
| Broadcast transmission | 1790 | | | Broadcast transmission | 1790 | | |||
+---------------------------------------+---------------+ | +---------------------------------------+---------------+ | |||
skipping to change at page 5, line 40 | skipping to change at page 5, line 40 | |||
consume as much power in listen mode as when actively transmitting. | consume as much power in listen mode as when actively transmitting. | |||
This augments the key problem known as idle listening, whereby the | This augments the key problem known as idle listening, whereby the | |||
radio of a device may be in receive mode (ready to receive any | radio of a device may be in receive mode (ready to receive any | |||
message), even if no message is being transmitted to that device. | message), even if no message is being transmitted to that device. | |||
Idle listening consumes a huge amount of energy unnecessarily. To | Idle listening consumes a huge amount of energy unnecessarily. To | |||
reduce power consumption, the radio must be switched completely off | reduce power consumption, the radio must be switched completely off | |||
-- duty-cycled -- as much as possible. By applying duty-cycling, the | -- duty-cycled -- as much as possible. By applying duty-cycling, the | |||
lifetime of a device operating on a common button battery may be in | 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 | the order of years, whereas otherwise the battery may be exhausted in | |||
a few days or even hours. Duty-cycling is a technique generally | a few days or even hours. Duty-cycling is a technique generally | |||
exploited by devices that use the P1 strategy [RFC7228], which need | employed by devices that use the P1 strategy [RFC7228], which need to | |||
to be able to communicate on a relatively frequent basis. Note that | be able to communicate on a relatively frequent basis. Note that a | |||
a more aggressive approach to save energy relies on the P0, Normally- | more aggressive approach to save energy relies on the P0, Normally- | |||
off strategy, whereby devices sleep for very long periods and | off strategy, whereby devices sleep for very long periods and | |||
communicate infrequently, even though they spend energy in network | communicate infrequently, even though they spend energy in network | |||
reattachment procedures. | reattachment procedures. | |||
From the perspective of MAC&RDC, all upper layer protocols, such as | From the perspective of MAC&RDC, all upper layer protocols, such as | |||
routing, RESTful communication, adaptation, and management flows, are | routing, RESTful communication, adaptation, and management flows, are | |||
all applications. Since the duty cycling algorithm is the key to | all applications. Since the duty cycling algorithm is the key to | |||
energy-efficiency of the wireless medium, it synchronizes the | energy-efficiency of the wireless medium, it synchronizes the | |||
transmission and/or reception request from the higher layer. | transmission and/or reception request from the higher layer. | |||
skipping to change at page 15, line 9 | skipping to change at page 15, line 9 | |||
Energy object that allows to provide information related to node | Energy object that allows to provide information related to node | |||
energy, such as the energy source type or the estimated percentage of | energy, such as the energy source type or the estimated percentage of | |||
remaining energy. Appropriate use of energy-based routing metrics | remaining energy. Appropriate use of energy-based routing metrics | |||
may help to balance energy consumption of network nodes, minimize | may help to balance energy consumption of network nodes, minimize | |||
network partitioning and increase network lifetime. | network partitioning and increase network lifetime. | |||
6. Application Layer | 6. Application Layer | |||
6.1. Energy efficient features in CoAP | 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 | connecting the services of smart devices to the World Wide Web. CoAP | |||
is not a chatty protocol, it provides basic communication services | is not a chatty protocol, it provides basic communication services | |||
such as service discovery and GET/POST/PUT/DELETE methods with a | such as service discovery and GET/POST/PUT/DELETE methods with a | |||
binary header. | binary header. | |||
The energy-efficient design is implicitly included in the CoAP | The energy-efficient design is implicitly included in the CoAP | |||
protocol design. CoAP uses a fixed-length binary header of only four | protocol design. CoAP uses a fixed-length binary header of only four | |||
bytes that may be followed by binary options. To reduce regular and | bytes that may be followed by binary options. To reduce regular and | |||
frequent queries of the resources, CoAP provides an observe mode, in | frequent queries of the resources, CoAP provides an observe mode, in | |||
which the requester registers its interest of a certain resource and | which the requester registers its interest of a certain resource and | |||
skipping to change at page 16, line 27 | skipping to change at page 16, line 27 | |||
RTO value is chosen randomly between 2 and 3 s. If an RTO expires, | 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 | the new RTO value is doubled (unless a limit on the number of | |||
retransmissions has been reached). Since duty-cycling at the link | retransmissions has been reached). Since duty-cycling at the link | |||
layer may lead to long latency (i.e. even greater than the initial | layer may lead to long latency (i.e. even greater than the initial | |||
RTO value), CoAP RTO parameters should be tuned accordingly in order | RTO value), CoAP RTO parameters should be tuned accordingly in order | |||
to avoid spurious RTOs which would unnecessarily waste node energy | to avoid spurious RTOs which would unnecessarily waste node energy | |||
and other resources. | and other resources. | |||
7. Summary | 7. Summary | |||
We find a summary section necessary although most IETF documents do | We summarize the key takeaways in this document: | |||
not contain it. The points we would like to summarize are as | ||||
follows. | ||||
a. All Internet protocols, which are in the scope of the IETF, are | a. Internet protocols designed by IETF can be considered as the | |||
customers of the lower layers (PHY, MAC, and Duty-cycling). In | customer of the lower layers (PHY, MAC, and Duty-cycling). To | |||
order to get a better service, the designers of higher layers | save power consumption, it is recommended to synergize with the | |||
should know them better. | lower layer other than treating the lower layer as a black box. | |||
b. The IETF has developed multiple protocols for constrained | b. It is always useful to compresss the protocol headers in order to | |||
networked devices. A lot of implicit energy efficient design | reduce the transmission/reception power. This design principles | |||
principles have been used in these protocols. The latter should | have been employed by many protocols in 6Lo and CoRE working | |||
be fine-tuned to exploit the collaboration with the lower layer | group. | |||
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 | c. Broadcast and non-synchronzed transmissions consume more than | |||
that for radio-duty-cycled networks broadcasts should be avoided. | other TX/RX operations. If protocols must use these ways to | |||
Saving unnecessary states maintenance is also an effective method | collect information, reduction of their usage by aggregating | |||
to be energy-friendly. | 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 | 8. Contributors | |||
Jens T. Petersen, RTX, contributed the section on power save | Jens T. Petersen, RTX, contributed the section on power save | |||
services in DECT ULE. | services in DECT ULE. | |||
9. Acknowledgments | 9. Acknowledgments | |||
Carles Gomez has been supported by Ministerio de Economia y | Carles Gomez has been supported by Ministerio de Economia y | |||
Competitividad and FEDER through project TEC2012-32531. | Competitividad and FEDER through project TEC2012-32531. | |||
skipping to change at page 17, line 43 | skipping to change at page 17, line 38 | |||
12. References | 12. References | |||
12.1. Normative References | 12.1. Normative References | |||
[Bluetooth42] | [Bluetooth42] | |||
"Bluetooth Core Specification Version 4.2", 2014. | "Bluetooth Core Specification Version 4.2", 2014. | |||
[EN300] ""Digital Enhanced Cordless Telecommunications (DECT); | [EN300] ""Digital Enhanced Cordless Telecommunications (DECT); | |||
Common Interface (CI);"", 2013. | Common Interface (CI);"", 2013. | |||
[fifteendotfour] | ||||
"802.15.4-2011", 2011. | ||||
[IEEE80211v] | [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 | and Physical Layer (PHY) specifications, Amendment 8: IEEE | |||
802.11 Wireless Network Management.", February 2012. | 802.11 Wireless Network Management.", February 2012. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [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, | ||||
<http://www.rfc-editor.org/info/rfc2119>. | ||||
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, | [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, | |||
"Transmission of IPv6 Packets over IEEE 802.15.4 | "Transmission of IPv6 Packets over IEEE 802.15.4 | |||
Networks", RFC 4944, September 2007. | Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, | |||
<http://www.rfc-editor.org/info/rfc4944>. | ||||
[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, | Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, | |||
September 2011. | DOI 10.17487/RFC6282, September 2011, | |||
<http://www.rfc-editor.org/info/rfc6282>. | ||||
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., | [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., | |||
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. | Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, | |||
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and | JP., and R. Alexander, "RPL: IPv6 Routing Protocol for | |||
Lossy Networks", RFC 6550, March 2012. | Low-Power and Lossy Networks", RFC 6550, | |||
DOI 10.17487/RFC6550, March 2012, | ||||
<http://www.rfc-editor.org/info/rfc6550>. | ||||
[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. | [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., | |||
Barthel, "Routing Metrics Used for Path Calculation in | and D. Barthel, "Routing Metrics Used for Path Calculation | |||
Low-Power and Lossy Networks", RFC 6551, March 2012. | in Low-Power and Lossy Networks", RFC 6551, | |||
DOI 10.17487/RFC6551, March 2012, | ||||
<http://www.rfc-editor.org/info/rfc6551>. | ||||
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link | [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link | |||
Format", RFC 6690, August 2012. | Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, | |||
<http://www.rfc-editor.org/info/rfc6690>. | ||||
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, | [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. | |||
"Neighbor Discovery Optimization for IPv6 over Low-Power | Bormann, "Neighbor Discovery Optimization for IPv6 over | |||
Wireless Personal Area Networks (6LoWPANs)", RFC 6775, | Low-Power Wireless Personal Area Networks (6LoWPANs)", | |||
November 2012. | RFC 6775, DOI 10.17487/RFC6775, November 2012, | |||
<http://www.rfc-editor.org/info/rfc6775>. | ||||
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for | [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, | ||||
<http://www.rfc-editor.org/info/rfc7228>. | ||||
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained | [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, | ||||
<http://www.rfc-editor.org/info/rfc7252>. | ||||
[TS102] ""Digital Enhanced Cordless Telecommunications (DECT); | [TS102] ""Digital Enhanced Cordless Telecommunications (DECT); | |||
Ultra Low Energy (ULE); Machine to Machine Communications; | Ultra Low Energy (ULE); Machine to Machine Communications; | |||
Part 1: Home Automation Network (phase 1)"", 2013. | Part 1: Home Automation Network (phase 1)"", 2013. | |||
[fifteendotfour] | ||||
"802.15.4-2011", 2011. | ||||
12.2. Informative References | 12.2. Informative References | |||
[AN053] Selvig, B., "Measuring power consumption with CC2430 and | [AN053] Selvig, B., "Measuring power consumption with CC2430 and | |||
Z-Stack". | Z-Stack". | |||
[Announcementlayer] | [Announcementlayer] | |||
Dunkels, A., "The Announcement Layer: Beacon Coordination | 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". | |||
[ContikiMAC] | [ContikiMAC] | |||
Dunkels, A., "The ContikiMAC Radio Duty Cycling Protocol, | Dunkels, A., "The ContikiMAC Radio Duty Cycling Protocol, | |||
SICS Technical Report T2011:13", December 2011. | SICS Technical Report T2011:13", December 2011. | |||
[I-D.ietf-6lo-dect-ule] | [I-D.ietf-6lo-dect-ule] | |||
Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D. | Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D. | |||
Barthel, "Transmission of IPv6 Packets over DECT Ultra Low | Barthel, "Transmission of IPv6 Packets over DECT Ultra Low | |||
Energy", draft-ietf-6lo-dect-ule-01 (work in progress), | Energy", draft-ietf-6lo-dect-ule-03 (work in progress), | |||
January 2015. | September 2015. | |||
[I-D.ietf-6lowpan-btle] | [I-D.ietf-6lowpan-btle] | |||
Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., | Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., | |||
Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets | Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets | |||
over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-12 | over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-12 | |||
(work in progress), February 2013. | (work in progress), February 2013. | |||
[I-D.ietf-6man-impatient-nud] | [I-D.ietf-6man-impatient-nud] | |||
Nordmark, E. and I. Gashinsky, "Neighbor Unreachability | Nordmark, E. and I. Gashinsky, "Neighbor Unreachability | |||
Detection is too impatient", draft-ietf-6man-impatient- | Detection is too impatient", draft-ietf-6man-impatient- | |||
nud-07 (work in progress), October 2013. | nud-07 (work in progress), October 2013. | |||
[I-D.ietf-6tisch-architecture] | [I-D.ietf-6tisch-architecture] | |||
Thubert, P., "An Architecture for IPv6 over the TSCH mode | Thubert, P., "An Architecture for IPv6 over the TSCH mode | |||
of IEEE 802.15.4", draft-ietf-6tisch-architecture-08 (work | of IEEE 802.15.4", draft-ietf-6tisch-architecture-09 (work | |||
in progress), May 2015. | in progress), November 2015. | |||
[I-D.ietf-6tisch-minimal] | [I-D.ietf-6tisch-minimal] | |||
Vilajosana, X. and K. Pister, "Minimal 6TiSCH | Vilajosana, X. and K. Pister, "Minimal 6TiSCH | |||
Configuration", draft-ietf-6tisch-minimal-06 (work in | Configuration", draft-ietf-6tisch-minimal-14 (work in | |||
progress), March 2015. | progress), January 2016. | |||
[I-D.ietf-core-coap] | [I-D.ietf-core-coap] | |||
Shelby, Z., Hartke, K., and C. Bormann, "Constrained | Shelby, Z., Hartke, K., and C. Bormann, "Constrained | |||
Application Protocol (CoAP)", draft-ietf-core-coap-18 | Application Protocol (CoAP)", draft-ietf-core-coap-18 | |||
(work in progress), June 2013. | (work in progress), June 2013. | |||
[I-D.ietf-core-resource-directory] | [I-D.ietf-core-resource-directory] | |||
Shelby, Z. and C. Bormann, "CoRE Resource Directory", | Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE | |||
draft-ietf-core-resource-directory-02 (work in progress), | Resource Directory", draft-ietf-core-resource-directory-05 | |||
November 2014. | (work in progress), October 2015. | |||
[I-D.ietf-lwig-terminology] | [I-D.ietf-lwig-terminology] | |||
Bormann, C., Ersue, M., and A. Keranen, "Terminology for | Bormann, C., Ersue, M., and A. Keranen, "Terminology for | |||
Constrained Node Networks", draft-ietf-lwig-terminology-07 | Constrained Node Networks", draft-ietf-lwig-terminology-07 | |||
(work in progress), February 2014. | (work in progress), February 2014. | |||
[I-D.koster-core-coap-pubsub] | [I-D.koster-core-coap-pubsub] | |||
Koster, M., Keranen, A., and J. Jimenez, "Publish- | Koster, M., Keranen, A., and J. Jimenez, "Publish- | |||
Subscribe Broker for the Constrained Application Protocol | Subscribe Broker for the Constrained Application Protocol | |||
(CoAP)", draft-koster-core-coap-pubsub-01 (work in | (CoAP)", draft-koster-core-coap-pubsub-04 (work in | |||
progress), March 2015. | progress), November 2015. | |||
[I-D.kovatsch-lwig-class1-coap] | [I-D.kovatsch-lwig-class1-coap] | |||
Kovatsch, M., "Implementing CoAP for Class 1 Devices", | Kovatsch, M., "Implementing CoAP for Class 1 Devices", | |||
draft-kovatsch-lwig-class1-coap-00 (work in progress), | draft-kovatsch-lwig-class1-coap-00 (work in progress), | |||
October 2012. | October 2012. | |||
[I-D.rahman-core-sleepy-nodes-do-we-need] | [I-D.rahman-core-sleepy-nodes-do-we-need] | |||
Rahman, A., "Sleepy Devices: Do we need to Support them in | Rahman, A., "Sleepy Devices: Do we need to Support them in | |||
CORE?", draft-rahman-core-sleepy-nodes-do-we-need-01 (work | CORE?", draft-rahman-core-sleepy-nodes-do-we-need-01 (work | |||
in progress), February 2014. | in progress), February 2014. | |||
[Powertrace] | [Powertrace] | |||
Dunkels, , Eriksson, , Finne, , and Tsiftes, "Powertrace: | Dunkels, , Eriksson, , Finne, , and Tsiftes, "Powertrace: | |||
Network-level Power Profiling for Low-power Wireless | Network-level Power Profiling for Low-power Wireless | |||
Networks", March 2011. | Networks", March 2011. | |||
Authors' Addresses | Authors' Addresses | |||
Zhen Cao (Ed.) | ||||
Leibniz University of Hannover | ||||
P.R.China | ||||
Email: zhencao.ietf@gmail.com | ||||
Carles Gomez | Carles Gomez | |||
Universitat Politecnica de Catalunya/i2CAT | Universitat Politecnica de Catalunya/i2CAT | |||
C/Esteve Terradas, 7 | C/Esteve Terradas, 7 | |||
Castelldefels 08860 | Castelldefels 08860 | |||
Spain | Spain | |||
Email: carlesgo@entel.upc.edu | Email: carlesgo@entel.upc.edu | |||
Matthias Kovatsch | Matthias Kovatsch | |||
ETH Zurich | ETH Zurich | |||
Universitaetstrasse 6 | Universitaetstrasse 6 | |||
Zurich, CH-8092 | Zurich, CH-8092 | |||
Switzerland | Switzerland | |||
Email: kovatsch@inf.ethz.ch | Email: kovatsch@inf.ethz.ch | |||
Hui Tian | Hui Tian | |||
China Academy of Telecommunication Research | China Academy of Telecommunication Research | |||
Huayuanbeilu No.52 | Huayuanbeilu No.52 | |||
Beijing, Haidian District 100191 | Beijing, Haidian District 100191 | |||
China | China | |||
Email: tianhui@mail.ritt.com.cn | Email: tianhui@mail.ritt.com.cn | |||
Xuan He | Zhen Cao (editor) | |||
Hitachi China R&D Corporation | Huawei Technologies | |||
301, Tower C North, Raycom, 2 Kexuyuan Nanlu, Haidian District | China | |||
Beijing 100190 | ||||
P.R.China | ||||
Email: xhe@hitachi.cn | Email: zhencao.ietf@gmail.com | |||
End of changes. 44 change blocks. | ||||
112 lines changed or deleted | 115 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |