draft-ietf-lwig-energy-efficient-02.txt   draft-ietf-lwig-energy-efficient-03.txt 
Internet Engineering Task Force Z. Cao Internet Engineering Task Force Z. Cao
Internet-Draft Leibniz University of Hannover Internet-Draft Leibniz University of Hannover
Intended status: Informational C. Gomez Intended status: Informational C. Gomez
Expires: September 8, 2015 Universitat Politecnica de Catalunya/i2CAT Expires: November 20, 2015 Universitat Politecnica de Catalunya/i2CAT
M. Kovatsch M. Kovatsch
ETH Zurich ETH Zurich
H. Tian H. Tian
China Academy of Telecommunication Research China Academy of Telecommunication Research
X. He X. He
Hitachi China R&D Corporation Hitachi China R&D Corporation
March 7, 2015 May 19, 2015
Energy Efficient Implementation of IETF Constrained Protocol Suite Energy Efficient Implementation of IETF Constrained Protocol Suite
draft-ietf-lwig-energy-efficient-02 draft-ietf-lwig-energy-efficient-03
Abstract Abstract
This document summarizes the problems and current practices of energy This document summarizes the problems and current practices of energy
efficient protocol implementation on constrained devices, mostly efficient protocol implementation on constrained devices, mostly
about how to make the protocols within IETF scope behave energy about how to make the protocols within IETF scope behave energy
friendly. This document also summarizes the impact of link layer friendly. This document also summarizes the impact of link layer
protocol power saving behaviors to the upper layer protocols, so that protocol power saving behaviors to the upper layer protocols, so that
they can coordinately make the system energy efficient. they can coordinately make the system energy efficient.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 September 8, 2015. This Internet-Draft will expire on November 20, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
1.1. Conventions used in this document . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. MAC and Radio Duty Cycling . . . . . . . . . . . . . . . . . 5 3. MAC and Radio Duty Cycling . . . . . . . . . . . . . . . . . 5
3.1. Radio Duty Cycling techniques . . . . . . . . . . . . . . 6 3.1. Radio Duty Cycling techniques . . . . . . . . . . . . . . 6
3.2. Latency and buffering . . . . . . . . . . . . . . . . . . 7 3.2. Latency and buffering . . . . . . . . . . . . . . . . . . 7
3.3. Throughput . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Throughput . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Radio interface tuning . . . . . . . . . . . . . . . . . 7 3.4. Radio interface tuning . . . . . . . . . . . . . . . . . 7
3.5. Power save services available in example low-power radios 7 3.5. Power save services available in example low-power radios 7
3.5.1. Power Save Services Provided by IEEE 802.11 . . . . . 8 3.5.1. Power Save Services Provided by IEEE 802.11 . . . . . 8
3.5.2. Power Save Services Provided by Bluetooth Low Energy 9 3.5.2. Power Save Services Provided by Bluetooth LE . . . . 9
3.5.3. Power Save Services in IEEE 802.15.4 . . . . . . . . 10 3.5.3. Power Save Services in IEEE 802.15.4 . . . . . . . . 10
4. IP Adaptation and Transport Layer . . . . . . . . . . . . . . 11 3.5.4. Power Save Services in DECT ULE . . . . . . . . . . . 11
5. Routing Protocols . . . . . . . . . . . . . . . . . . . . . . 12 4. IP Adaptation and Transport Layer . . . . . . . . . . . . . . 13
6. Application Layer . . . . . . . . . . . . . . . . . . . . . . 13 5. Routing Protocols . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Energy efficient features in CoAP . . . . . . . . . . . . 13 6. Application Layer . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Sleepy node support . . . . . . . . . . . . . . . . . . . 14 6.1. Energy efficient features in CoAP . . . . . . . . . . . . 15
6.3. CoAP timers . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Sleepy node support . . . . . . . . . . . . . . . . . . . 15
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.3. CoAP timers . . . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 16 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
In many scenarios, the network systems comprise many battery-powered In many scenarios, the network systems comprise many battery-powered
or energy-harvesting devices. For example, in an environmental or energy-harvesting devices. For example, in an environmental
monitoring system or a temperature and humidity monitoring system in monitoring system or a temperature and humidity monitoring system in
a data center, there are no always-on and handy sustained power a data center, there are no always-on and handy 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 environments, it is necessary to optimize the energy
consumption of the entire system, including computing, application consumption of the entire system, including computing, application
skipping to change at page 4, line 11 skipping to change at page 4, line 13
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.
+-----+ +-----+ +-----+ +------+ +-----+ +-----+ +-----+ +------+
|http | | ftp | |SNMP | | COAP | |HTTP | | FTP | |SNMP | | CoAP |
+-----+ +-----+ +-----+ +------+ +-----+ +-----+ +-----+ +------+
\ / / / \ \ / / / \
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| tcp | | udp | | tcp | | udp | | TCP | | UDP | | TCP | | UDP |
+-----+ +-----+ ===> +-----+ +-----+ +-----+ +-----+ ===> +-----+ +-----+
\ / \ / \ / \ /
+-----+ +------+ +-------+ +------+ +-----+ +-----+ +------+ +-------+ +------+ +-----+
| RTG |--| ipv6 |--|ICMP/ND| | ipv6 |---| rpl | | RTG |--| IPv6 |--|ICMP/ND| | IPv6 |---| RPL |
+-----+ +------+ +-------+ +------+ +-----+ +-----+ +------+ +-------+ +------+ +-----+
| | | |
+-------+ +-------+ +----------+ +-------+ +-------+ +----------+
|MAC/PHY| |6lowpan|--|6lowpan-nd| |MAC/PHY| |6LoWPAN|--|6LoWPAN-ND|
+-------+ +-------+ +----------+ +-------+ +-------+ +----------+
| |
+-------+ +-------+
|MAC/PHY| |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
skipping to change at page 6, line 42 skipping to change at page 6, line 42
radio technologies that use preamble sampling include ContikiMAC, the radio technologies that use preamble sampling include ContikiMAC, the
Coordinated Sampled Listening (CSL) mode of IEEE 802.15.4e, and the Coordinated Sampled Listening (CSL) mode of IEEE 802.15.4e, and the
Frequently Listening (FL) mode of ITU-T G.9959. Frequently Listening (FL) mode of ITU-T G.9959.
b) Scheduled transmissions. This approach allows a device to know b) Scheduled transmissions. This approach allows a device to know
the instants in which it should be awake (during some time interval) the instants in which it should be awake (during some time interval)
in order to receive data units. Otherwise, the device may remain in in order to receive data units. Otherwise, the device may remain in
sleep mode. The decision on the instants that will be used for sleep mode. The decision on the instants that will be used for
communication is reached by means of some form of negotation between communication is reached by means of some form of negotation between
the involved devices. Such negotiation may be performed per the involved devices. Such negotiation may be performed per
transmission or per session/connection. Bluetooth Low Energy is an transmission or per session/connection. Bluetooth Low Energy
example of a radio technology based on this mechanism. (Bluetooth LE) is an example of a radio technology based on this
mechanism.
c) Listen after send. This technique allows a node to remain in 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 sleep mode by default, wake up and poll a sender (which must be ready
to receive a poll message) for pending transmissions. After sending to receive a poll message) for pending transmissions. After sending
the poll message, the node remains in receive mode, ready for a the poll message, the node remains in receive mode, ready for a
potential incoming transmission. After a certain time interval, the potential incoming transmission. After a certain time interval, the
node may go back to sleep. For example, the Receiver Initated node may go back to sleep. For example, the Receiver Initated
Transmission (RIT) mode of 802.15.4e, and the transmission of data 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 between a coordinator and a device in IEEE 802.15.4-2003 use this
technique. technique.
skipping to change at page 7, line 50 skipping to change at page 7, line 50
tuned to achieve the intended application and/or network tuned to achieve the intended application and/or network
requirements. On the other hand, upper layers should take into requirements. On the other hand, upper layers should take into
account the expected latency and/or throughput behavior due to RDC. account the expected latency and/or throughput behavior due to RDC.
The next subsection provides details on key parameters controlling The next subsection provides details on key parameters controlling
RDC mechanisms, and thus fundamental trade-offs, for various examples RDC mechanisms, and thus fundamental trade-offs, for various examples
of relevant low-power radio technologies. of relevant low-power radio technologies.
3.5. Power save services available in example low-power radios 3.5. Power save services available in example low-power radios
This subsection presents power save services and techniques used in a This subsection presents power save services and techniques used in a
few relevant examples of wireless low-power radios: IEEE 802.11v, few relevant examples of wireless low-power radios: IEEE 802.11,
Bluetooth Low Energy and IEEE 802.15.4. For a more detailed overview Bluetooth LE and IEEE 802.15.4. For a more detailed overview of each
of each technology, the reader may refer to the literature or to the technology, the reader may refer to the literature or to the
corresponding specifications. corresponding specifications.
3.5.1. Power Save Services Provided by IEEE 802.11 3.5.1. Power Save Services Provided by IEEE 802.11
IEEE 802.11 defines the Power Save Mode (PSM) whereby a station may IEEE 802.11 defines the Power Save Mode (PSM) whereby a station may
indicate to an Access Point (AP) that it will enter a sleep mode indicate to an Access Point (AP) that it will enter a sleep mode
state. While the station is sleeping, the AP buffers any frames that state. While the station is sleeping, the AP buffers any frames that
should be sent to the sleeping station. The station wakes up every should be sent to the sleeping station. The station wakes up every
Listen Interval (which can be a multiple of the Beacon Interval) in Listen Interval (which can be a multiple of the Beacon Interval) in
order to receive beacons. The AP signals in the beacon whether there order to receive beacons. The AP signals in the beacon whether there
skipping to change at page 9, line 13 skipping to change at page 9, line 13
traffic filters specified by the non-AP STA. traffic filters specified by the non-AP STA.
Using the above services provided by the lower layer, the constrained Using the above services provided by the lower layer, the constrained
nodes can achieve either client initiated power save (via TFS) or nodes can achieve either client initiated power save (via TFS) or
network assisted power save (Proxy-ARP, BSS Max Idel Period and FMS). network assisted power save (Proxy-ARP, BSS Max Idel Period and FMS).
Upper layer protocols would better synchronize with the parameters Upper layer protocols would better synchronize with the parameters
such as FMS interval and BSS MAX Idle Period, so that the wireless such as FMS interval and BSS MAX Idle Period, so that the wireless
transmissions are not triggered periodically. transmissions are not triggered periodically.
3.5.2. Power Save Services Provided by Bluetooth Low Energy 3.5.2. Power Save Services Provided by Bluetooth LE
Bluetooth Low Energy (Bluetooth LE) is a wireless low-power Bluetooth LE is a wireless low-power communications technology that
communications technology that is the hallmark component of the is the hallmark component of the Bluetooth 4.0, 4.1 and 4.2
Bluetooth 4.0 and Bluetooth 4.1 specifications [Bluetooth41]"/>. BT- specifications [Bluetooth42]. BT-LE has been designed for the goal
LE has been designed for the goal of ultra-low-power consumption. of ultra-low-power consumption. Currently, it is possible to run
Currently, it is possible to run IPv6 over Bluetooth LE networks by IPv6 over Bluetooth LE networks by using a 6LoWPAN variant adapted to
using a 6LoWPAN variant adapted to BT-LE [I-D.ietf-6lowpan-btle]. BT-LE [I-D.ietf-6lowpan-btle].
Bluetooth LE networks comprise a master and one or more slaves which Bluetooth LE networks comprise a master and one or more slaves which
are connected to the master. The Bluetooth LE master is assumed to are connected to the master. The Bluetooth LE master is assumed to
be a relatively powerful device, whereas a slave is typically a be a relatively powerful device, whereas a slave is typically a
constrained device (e.g. a class 1 device). constrained device (e.g. a class 1 device).
Medium access in Bluetooth LE is based on a TDMA scheme which is Medium access in Bluetooth LE is based on a TDMA scheme which is
coordinated by the master. This device determines the start of coordinated by the master. This device determines the start of
connection events, in which communication between the master and a connection events, in which communication between the master and a
slave takes place. At the beginning of a connection event, the slave takes place. At the beginning of a connection event, the
skipping to change at page 11, line 48 skipping to change at page 11, line 48
The latter time slots may be used by a dynamic scheduling mechanism, The latter time slots may be used by a dynamic scheduling mechanism,
otherwise nodes may keep the radio off during the unscheduled time otherwise nodes may keep the radio off during the unscheduled time
slots, thus saving energy. The minimal schedule configuration slots, thus saving energy. The minimal schedule configuration
specified in [I-D.ietf-6tisch-minimal] comprises 101 time slots, specified in [I-D.ietf-6tisch-minimal] comprises 101 time slots,
whereby 95 of these time slots are unscheduled and the time slot whereby 95 of these time slots are unscheduled and the time slot
duration is 15 ms. duration is 15 ms.
Other 802.15.4e modes, which are in fact designed for low energy, are Other 802.15.4e modes, which are in fact designed for low energy, are
the previously mentioned CSL and RIT. the previously mentioned CSL and RIT.
3.5.4. Power Save Services in DECT ULE
DECT Ultra Low Energy (DECT ULE) is a wireless technology building on
the key fundamentals of traditional DECT / CAT-iq [EN300] but with
specific changes to significantly reduce the power consumption on the
expense of data throughput as specified in [TS102]. DECT ULE devices
typically operates on special power optimized silicon, but can
connect to a DECT Gateway supporting traditional DECT / CAT-iq for
cordless telephony and data as well as the DECT ULE extensions. It
is possible to run IPv6 over DECT ULE by using a 6LoWPAN variant
adapted for DECT ULE [I-D.ietf-6lo-dect-ule].
DECT terminology operates with two major role definitions: The
Portable Part (PP) is the power constrained device, while the Fixed
Part (FP) is the Gateway or base station in a star topology. DECT is
operating in license free and reserved frequency bands based on TDMA/
FDMA and TDD using dynamic channel allocation for interference
avoidance. It provides good indoor (~50 m) and outdoor (~300 m)
coverage. It is using a frame length of 10 ms, which is divided into
24 timeslots and it is supporting connection oriented, packet data
and connection less services.
The FP usually transmits a so-called dummy bearer (beacon) that is
used to broadcast synchronization, system and paging information.
The slot/carrier position of this dummy bearer can automatically be
reallocated in order to avoid mutual interference with other DECT
signals.
At MAC level DECT ULE communications between FP and PP are initiated
by the PP. A FP can initiate communication indirectly by sending
paging signal to a PP. The PP determines the timeslot and frequency
on which the communication between FP and PP takes place. The PP
verifies the radio timeslot/frequency position is unoccupied before
it initiates its transmitter. An access-request message, which
usually carries data, is sent to the FP. The FP sends a confirm
message, which also may carry data. More data can be sent in
subsequent frames. A MAC level automatic retransmission scheme
improves data transfer reliability significant. A segmentation and
reassembly scheme supports transfer of larger higher layer SDUs and
provides data integrity check. The DECT ULE packet data service
ensures data integrity, proper sequencing, duplicate protection, but
does not guaranteed delivery. Higher layers protocols have to take
this into considerations.
The FP may send paging information to PPs to trigger connection setup
and indicate required service type. The interval between paging
information to a specific PP can be defined in range 10 ms to 327
seconds. The PP may enter sleep mode to save power. The listening
interval is defined by the PP application. For short sleep intervals
(below ~10 seconds) the PP may be able to retain synchronization to
the FP dummy bearer and only turn on the receiver during the expected
timeslot. For longer sleep intervals the PP can't keep
synchronization and has to search for and resynchronize to the FP
dummybearer. Hence, longer sleep interval reduces the average energy
consumption, but adds a energy consumption penalty for acquiring
synchronization to the FP dummy bearer. The PP can obtain all
information to determine paging and acquire synchronization
information in a single reception of one full timeslot.
Packet data latency is normally 30 ms for short packets (below or
equal to 32 octets), however if retry and back-off scenarios occur,
the latency is increased. The latency can actually be reduced to
about 10 ms by doing energy consuming RSSI scanning in advance. In
the direction from FP to PP the latency is usually increased by the
used paging interval and the sleep interval. The MAC layer can
piggyback commands to improve efficiency (reduce latency) of higher
layer protocols. Such commands can instruct the PP to initiate a new
packet transfer in N frames without the need for resynchronization
and listening to paging or instruct the PP to stay in a higher duty
cycle paging detection mode.
The DECT ULE technology allows per PP configuration of paging
interval, MTU size, reassembly window size and higher layer service
negotiation and protocol.
4. IP Adaptation and Transport Layer 4. IP Adaptation and Transport Layer
6LoWPAN is the adaption layer to run IPv6 over IEEE 802.15.4 MAC&PHY. 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 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 fragmentation and assembly of <1280-byte packets while IEEE 802.15.4
only supports a MTU of 127 bytes. only supports a MTU of 127 bytes.
IPv6 is the basis for the higher layer protocols, including both TCP/ IPv6 is the basis for the higher layer protocols, including both TCP/
UDP transport and applications. So they are quite ignorant of the UDP transport and applications. So they are quite ignorant of the
lower layers, and are almost neutral to the energy-efficiency lower layers, and are almost neutral to the energy-efficiency
problem. problem.
What the network stack can optimize is to save the computing power. What the network stack can optimize is to save the computing power.
For example the Contiki implementation has multiple cross layer For example the Contiki implementation has multiple cross layer
optimizations for buffers and energy management, e.g., the computing optimizations for buffers and energy management, e.g., the computing
and validation of UDP/TCP checksums without the need of reading IP and validation of UDP/TCP checksums without the need of reading IP
headers from a different layer. These optimizations are software headers from a different layer. These optimizations are software
implementation techniques, and out of the scope of IETF and the LWIG implementation techniques, and out of the scope of IETF and the LWIG
working group. working group.
The 6LoWPAN contributes to the energy-efficiency problem in two ways. 6LoWPAN contributes to the energy-efficiency problem in two ways.
First of all, it swaps computing with communication. 6LoWPAN applies First of all, it swaps computing with communication. 6LoWPAN applies
compression of the IPv6 header. This means less amount of data will compression of the IPv6 header. This means less amount of data will
be handled by the lower layer, but both the sender and receiver be handled by the lower layer, but both the sender and receiver
should spend more computing power on the compression and should spend more computing power on the compression and
decompression of the packets over the air. Secondly, the 6LoWPAN decompression of the packets over the air. Secondly, the 6LoWPAN
working group developed the energy-efficient Neighbor Discovery working group developed the energy-efficient Neighbor Discovery
called 6LoWPAN-ND, which is an energy efficient replacement of the called 6LoWPAN-ND, which is an energy efficient replacement of the
IPv6 ND in constrained environments. IPv6 Neighbor Discovery was not IPv6 ND in constrained environments. IPv6 Neighbor Discovery was not
designed for non-transitive wireless links, as its heavy use of designed for non-transitive wireless links, as its heavy use of
multicast makes it inefficient and sometimes impractical in a low- multicast makes it inefficient and sometimes impractical in a low-
skipping to change at page 13, line 10 skipping to change at page 14, line 34
to exchange messages periodically and keep routing states for each to exchange messages periodically and keep routing states for each
destination. RPL is optimized for the many-to-one communication destination. RPL is optimized for the many-to-one communication
pattern, where network nodes primarily send data towards the border pattern, where network nodes primarily send data towards the border
router, but has provisions for any-to-any routing as well. router, but has provisions for any-to-any routing as well.
The authors of the Powertrace tool [Powertrace] studied the power The authors of the Powertrace tool [Powertrace] studied the power
profile of RPL. It divides the routing protocol into control and profile of RPL. It divides the routing protocol into control and
data traffic. The control channel uses ICMP messages to establish data traffic. The control channel uses ICMP messages to establish
and maintain the routing states. The data channel is any application and maintain the routing states. The data channel is any application
that uses RPL for routing packets. The study has shown that the that uses RPL for routing packets. The study has shown that the
power consumption of the control traffic goes down over time and data power consumption of the control traffic goes down over time in a
traffic stays relatively constant. The study also reflects that the relatively stable network. The study also reflects that the routing
routing protocol should keep the control traffic as low as possible protocol should keep the control traffic as low as possible to make
to make it energy-friendly. The amount of RPL control traffic can be it energy-friendly. The amount of RPL control traffic can be tuned
tuned by setting the Trickle algorithm parameters (i.e. Imin, Imax by setting the Trickle algorithm parameters (i.e. Imin, Imax and k)
and k) to adequate values. However, there exists a trade-off between to adequate values. However, there exists a trade-off between energy
energy consumption and other performance parameters such as network consumption and other performance parameters such as network
convergence time and robustness. convergence time and robustness.
RFC 6551 [RFC6551] defines routing metrics and constraints to be used RFC 6551 [RFC6551] defines routing metrics and constraints to be used
by RPL in route computation. Among others, RFC 6551 specifies a Node by RPL in route computation. Among others, RFC 6551 specifies a Node
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.
skipping to change at page 13, line 43 skipping to change at page 15, line 21
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
the responder will report the value whenever it was updated. This the responder will report the value whenever it was updated. This
reduces the request response roundtrip while keeping information reduces the request response round trips while keeping information
exchange a ubiquitous service and, most importantly, it allows an exchange a ubiquitous service and, most importantly, it allows an
energy-constrained server to remain in sleep mode during the period energy-constrained server to remain in sleep mode during the period
between observe notification transmissions. between observe notification transmissions.
Furthermore, [RFC7252] defines CoAP proxies which can cache resource Furthermore, [RFC7252] defines CoAP proxies which can cache resource
representations previously provided by sleepy CoAP servers. The representations previously provided by sleepy CoAP servers. The
proxies themselves may respond to client requests if the proxies themselves may respond to client requests if the
corresponding server is sleeping and the resource representation is corresponding server is sleeping and the resource representation is
recent enough. Otherwise, a proxy may attempt to obtain the resource recent enough. Otherwise, a proxy may attempt to obtain the resource
from the sleepy server. from the sleepy server.
6.2. Sleepy node support 6.2. Sleepy node support
Beyond these features of CoAP, there have been a number of proposals Beyond these features of CoAP, there have been a number of proposals
to further support sleepy nodes at the application layer by to further support sleepy nodes at the application layer by
leveraging CoAP mechanisms. A good summary of such proposals can be leveraging CoAP mechanisms. A good summary of such proposals can be
found in [I-D.rahman-core-sleepy-nodes-do-we-need]. The different found in [I-D.rahman-core-sleepy-nodes-do-we-need]. The different
approaches include exploiting the use of proxies, leveraging the approaches include exploiting the use of proxies, leveraging the
Resource Directory [I-D.ietf-core-resource-directory] or signaling Resource Directory [I-D.ietf-core-resource-directory] or signaling
when a node is awake to the interested nodes. A more recent work when a node is awake to the interested nodes. A more recent work
defines publish- subscribe and message queuing extensions to CoAP and defines publish-subscribe and message queuing extensions to CoAP and
the Resource Directory in order to support devices that spend most of the Resource Directory in order to support devices that spend most of
their time in a sleeping state [I-D.koster-core-coap-pubsub]. As of their time in a sleeping state [I-D.koster-core-coap-pubsub]. As of
the writing, none of these proposals has been adopted by the CoRE the writing, none of these proposals has been adopted by the CoRE
working group. working group.
In addition to the work within the scope of CoAP to support sleepy In addition to the work within the scope of CoAP to support sleepy
nodes, other specifications define application layer functionality nodes, other specifications define application layer functionality
for the same purpose. The Lightweight Machine-to-Machine (LWM2M) for the same purpose. The Lightweight Machine-to-Machine (LWM2M)
specification from the Open Mobile Alliance (OMA) defines a Queue specification from the Open Mobile Alliance (OMA) defines a Queue
Mode whereby an LWM2M Server queues requests to an LWM2M Client until Mode whereby an LWM2M Server queues requests to an LWM2M Client until
skipping to change at page 15, line 29 skipping to change at page 17, line 5
be fine-tuned to exploit the collaboration with the lower layer be fine-tuned to exploit the collaboration with the lower layer
protocols. Layers should offer interfaces that can be exploited protocols. Layers should offer interfaces that can be exploited
by other layers in order to optimize global protocol stack by other layers in order to optimize global protocol stack
performance. performance.
c. The power trace analysis of different protocol operations showed c. The power trace analysis of different protocol operations showed
that for radio-duty-cycled networks broadcasts should be avoided. that for radio-duty-cycled networks broadcasts should be avoided.
Saving unnecessary states maintenance is also an effective method Saving unnecessary states maintenance is also an effective method
to be energy-friendly. to be energy-friendly.
8. Acknowledgments 8. Contributors
Jens T. Petersen, RTX, contributed the section on power save
services in DECT ULE.
9. Acknowledgments
Carles Gomez has been supported by Ministerio de Economia y Carles Gomez has been supported by Ministerio de Economia y
Competitividad and FEDER through project TEC2012-32531. Competitividad and FEDER through project TEC2012-32531.
Authors would like to thank the review and feedback from a number of Authors would like to thank the review and feedback from a number of
experts in this area: Carsten Bormann, Ari Keranen, Hannes experts in this area: Carsten Bormann, Ari Keranen, Hannes
Tschofenig. Tschofenig, Dominique Barthel.
The text of this document was improved based on IESG Document Editing The text of this document was improved based on IESG Document Editing
session during IETF87. Thank Ted Lemon, Joel Jaeggli, and efforts to session during IETF87. Thank Ted Lemon, Joel Jaeggli, and efforts to
initiate this facilities. initiate this facilities.
9. IANA Considerations 10. IANA Considerations
This document has no IANA requests. This document has no IANA requests.
10. Security Considerations 11. Security Considerations
This document discusses the energy efficient protocol design, and This document discusses the energy efficient protocol design, and
does not incur any changes or challenges on security issues besides does not incur any changes or challenges on security issues besides
what the protocol specifications have analyzed. what the protocol specifications have analyzed.
11. References 12. References
11.1. Normative References 12.1. Normative References
[Bluetooth42]
"Bluetooth Core Specification Version 4.2", 2014.
[EN300] ""Digital Enhanced Cordless Telecommunications (DECT);
Common Interface (CI);"", 2013.
[IEEE80211v]
IEEE, , "Part 11: Wireless LAN Medium Access Control (MAC)
and Physical Layer (PHY) specifications, Amendment 8: IEEE
802.11 Wireless Network Management.", February 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
September 2011.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012.
[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D.
Barthel, "Routing Metrics Used for Path Calculation in
Low-Power and Lossy Networks", RFC 6551, March 2012.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, August 2012.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
"Neighbor Discovery Optimization for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
November 2012.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, May 2014.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, June 2014.
[TS102] ""Digital Enhanced Cordless Telecommunications (DECT);
Ultra Low Energy (ULE); Machine to Machine Communications;
Part 1: Home Automation Network (phase 1)"", 2013.
[fifteendotfour]
"802.15.4-2011", 2011.
12.2. Informative References
[AN053] Selvig, B., "Measuring power consumption with CC2430 and [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".
[Bluetooth41]
"Bluetooth Core Specification Version 4.1", 2013.
[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]
Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D.
Barthel, "Transmission of IPv6 Packets over DECT Ultra Low
Energy", draft-ietf-6lo-dect-ule-01 (work in progress),
January 2015.
[I-D.ietf-6lowpan-btle] [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., Watteyne, T., Struik, R., and M. Richardson, Thubert, P., "An Architecture for IPv6 over the TSCH mode
"An Architecture for IPv6 over the TSCH mode of IEEE of IEEE 802.15.4", draft-ietf-6tisch-architecture-08 (work
802.15.4e", draft-ietf-6tisch-architecture-05 (work in in progress), May 2015.
progress), January 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-05 (work in Configuration", draft-ietf-6tisch-minimal-06 (work in
progress), January 2015. progress), March 2015.
[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. and C. Bormann, "CoRE Resource Directory",
draft-ietf-core-resource-directory-02 (work in progress), draft-ietf-core-resource-directory-02 (work in progress),
November 2014. November 2014.
[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 in the Constrained Application Protocol (CoAP)", Subscribe Broker for the Constrained Application Protocol
draft-koster-core-coap-pubsub-00 (work in progress), (CoAP)", draft-koster-core-coap-pubsub-01 (work in
October 2014. progress), March 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.
[IEEE80211v]
IEEE, , "Part 11: Wireless LAN Medium Access Control (MAC)
and Physical Layer (PHY) specifications, Amendment 8: IEEE
802.11 Wireless Network Management.", February 2012.
[Powertrace] [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.
[fifteendotfour]
"802.15.4-2011", 2011.
11.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
September 2011.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012.
[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D.
Barthel, "Routing Metrics Used for Path Calculation in
Low-Power and Lossy Networks", RFC 6551, March 2012.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, August 2012.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
"Neighbor Discovery Optimization for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
November 2012.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, May 2014.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, June 2014.
Authors' Addresses Authors' Addresses
Zhen Cao (Ed.) Zhen Cao (Ed.)
Leibniz University of Hannover Leibniz University of Hannover
P.R.China P.R.China
Email: zhencao.ietf@gmail.com Email: zhencao.ietf@gmail.com
Carles Gomez Carles Gomez
Universitat Politecnica de Catalunya/i2CAT Universitat Politecnica de Catalunya/i2CAT
 End of changes. 33 change blocks. 
109 lines changed or deleted 204 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/