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/