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/