draft-ietf-lwig-energy-efficient-00.txt		draft-ietf-lwig-energy-efficient-01.txt
	Internet Engineering Task Force Z. Cao		Internet Engineering Task Force Z. Cao
	Internet-Draft China Mobile		Internet-Draft Leibniz University of Hannover
	Intended status: Informational C. Gomez		Intended status: Informational C. Gomez
	Expires: September 22, 2014 Universitat Politecnica de Catalunya/i2CAT		Expires: April 30, 2015 Universitat Politecnica de
			Catalunya/i2CAT
	M. Kovatsch		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
	March 21, 2014		Corporation
			October 27, 2014
	Energy Efficient Implementation of IETF Constrained Protocol Suite		Energy Efficient Implementation of IETF Constrained Protocol Suite
	draft-ietf-lwig-energy-efficient-00		draft-ietf-lwig-energy-efficient-01
	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.
	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 September 22, 2014.		This Internet-Draft will expire on April 30, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. MAC and Radio Duty Cycling . . . . . . . . . . . . . . . . . 5		3. MAC and Radio Duty Cycling . . . . . . . . . . . . . . . . . . 6
	3.1. Power Save Services Provided by IEEE 802.11v . . . . . . 6		3.1. Radio Duty Cycling techniques . . . . . . . . . . . . . . 6
	3.2. Power Save Services Provided by Bluetooth Low Energy . . 6		3.2. Latency and buffering . . . . . . . . . . . . . . . . . . 7
	3.3. Power Save Services in IEEE 802.15.4 . . . . . . . . . . 7		3.3. Power save services available in example low-power
	4. IP Adaptation and Transport Layer . . . . . . . . . . . . . . 9		radios . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Routing Protocols . . . . . . . . . . . . . . . . . . . . . . 10		3.3.1. Power Save Services Provided by IEEE 802.11v . . . . . 8
	6. Application Layer . . . . . . . . . . . . . . . . . . . . . . 10		3.3.2. Power Save Services Provided by Bluetooth Low
	7. Cross Layer Optimization . . . . . . . . . . . . . . . . . . 11		Energy . . . . . . . . . . . . . . . . . . . . . . . . 9
	8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		3.3.3. Power Save Services in IEEE 802.15.4 . . . . . . . . . 10
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12		4. IP Adaptation and Transport Layer . . . . . . . . . . . . . . 12
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		5. Routing Protocols . . . . . . . . . . . . . . . . . . . . . . 13
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 12		6. Application Layer . . . . . . . . . . . . . . . . . . . . . . 14
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		7. Cross Layer Optimization . . . . . . . . . . . . . . . . . . . 15
	12.1. Normative References . . . . . . . . . . . . . . . . . . 12		8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	12.2. Informative References . . . . . . . . . . . . . . . . . 14		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
			11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
			12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
			12.1. Normative References . . . . . . . . . . . . . . . . . . . 20
			12.2. Informative References . . . . . . . . . . . . . . . . . . 21
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	In many scenarios, the network systems comprises many battery-powered		In many scenarios, the network systems comprises 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
	the data center, there are no always-on and handy sustained power		the data center, there are no always-on and handy sustained power
	supplies for the large number of small devices. In such deployment		supplies for the large number of small devices. In such deployment
	environments, it is necessary to optimize the energy consumption of		environments, it is necessary to optimize the energy consumption of
	the entire system, including computing, application layer behavior,		the entire system, including computing, application layer behavior,
	skipping to change at page 3, line 21		skipping to change at page 3, line 37
	to summarize the design considerations of making the IETF protocol		to summarize the design considerations of making the IETF protocol
	suite as energy-efficient as possible. While this document does not		suite as energy-efficient as possible. While this document does not
	provide detailed and systematic solutions to the energy efficiency		provide detailed and systematic solutions to the energy efficiency
	problem, it summarizes the design efforts and analyzes the design		problem, it summarizes the design efforts and analyzes the design
	space of this problem.		space of this problem.
	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 network and application layers is also important to		design at the network and application layers is also important to
	make the device battery-friendly.		make the device energy-efficient.
	1.1. Conventions used in this document		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		The terminologies used in this document can be referred to [RFC7228].
	[I-D.ietf-lwig-terminology].
	2. Overview		2. Overview
	The IETF has developed multiple protocols to enable end-to-end IP		The IETF has developed multiple 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 show in		protocol stack to a light-weight Internet protocol stack. As show in
	Figure 1 below, the IETF has developed CoAP as the application layer		Figure 1 below, the IETF has developed CoAP as the application layer
	and 6LoWPAN as the adaption layer to run IPv6 over IEEE 802.15.4 and		and 6LoWPAN as the adaption layer to run IPv6 over IEEE 802.15.4 and
	Bluetooth Low-Energy, with the support of routing by RPL and		Bluetooth Low-Energy, with the support of routing by RPL and
	efficient neighbor discovery by 6LoWPAN-ND.		efficient neighbor discovery by 6LoWPAN-ND. 6LoWPAN is currently
			being adapted by the 6lo working group to support IPv6 over various
			other technologies, such as ITU-T G.9959, DECT ULE and MS/TP-BACnet.
	+-----+ +-----+ +-----+ +------+		+-----+ +-----+ +-----+ +------+
	|http | | ftp | |SNMP | | COAP |		|http | | ftp | |SNMP | | COAP |
	+-----+ +-----+ +-----+ +------+		+-----+ +-----+ +-----+ +------+
	\ / / / \		\ / / / \
	+-----+ +-----+ +-----+ +-----+		+-----+ +-----+ +-----+ +-----+
	| tcp | | udp | | tcp | | udp |		| tcp | | udp | | tcp | | udp |
	+-----+ +-----+ ===> +-----+ +-----+		+-----+ +-----+ ===> +-----+ +-----+
	\ / \ /		\ / \ /
	+-----+ +------+ +-------+ +------+ +-----+		+-----+ +------+ +-------+ +------+ +-----+
	skipping to change at page 4, line 27		skipping to change at page 4, line 40
	+-------+ +-------+ +----------+		+-------+ +-------+ +----------+
	|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 comprehensive measurements of wireless communication		There are numerous published studies reporting comprehensive
	[Powertrace]. Below we list the energy consumption profile of the		measurements of wireless communication platforms[Powertrace]. Below
	most common atom operations on a prevalent sensor node platform. The		we list the energy consumption profile of the most common atom
	measurement was based on the Tmote Sky with ContikiMAC as the radio		operations on a prevalent sensor node platform. The measurement was
	duty cycling algorithm. From the measurement, we can see that		based on the Tmote Sky with ContikiMAC as the radio duty cycling
	optimized transmissions and reception consume almost the same amount		algorithm. From the measurement, we can see that optimized
	of energy. For IEEE 802.15.4 and UWB radios, transmitting is		transmissions and reception consume almost the same amount of energy.
	actually even cheaper than receiving. Only for broadcast and non-		For IEEE 802.15.4 and UWB radios, transmitting may actually be even
	synchronized communication transmissions become costly in terms of		cheaper than receiving. Only for broadcast and non-synchronized
	energy because they need to flood the medium for a long time.		communication transmissions become costly in terms of energy because
			they need to flood 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 29		skipping to change at page 6, line 10
	+---------------------------------------+---------------+		+---------------------------------------+---------------+
	Figure 2: Power consumption of atom operations on the Tmote Sky with		Figure 2: Power consumption of atom operations on the Tmote Sky with
	ContikiMAC		ContikiMAC
	3. MAC and Radio Duty Cycling		3. MAC and Radio Duty Cycling
	In low-power wireless networks, communication and power consumption		In low-power wireless networks, communication and power consumption
	are intertwined. The communication device is typically the most		are intertwined. The communication device is typically the most
	power-consuming component, but merely refraining from transmissions		power-consuming component, but merely refraining from transmissions
	is not enough to attain a low power consumption: the radio consumes		is not enough to attain a low power consumption: the radio may
	as much power in listen mode as when actively transmitting, as show		consume as much power in listen mode as when actively transmitting.
	in Figure 2 . To reduce power consumption, the radio must be switched		This augments the key problem known as idle listening, whereby the
	completely off -- duty-cycled -- as much as possible. ContikiMAC is		radio of a device may be in receive mode (ready to receive any
	a very typical Radio Duty Cycling (RDC) protocol [ContikiMAC].		message), even if no message is being transmitted to that device.
			Idle listening consumes a huge amount of energy unnecessarily. To
			reduce power consumption, the radio must be switched completely off
			-- duty-cycled -- as much as possible. By applying duty-cycling, the
			lifetime of a device operating on a common button battery may be in
			the order of years, whereas otherwise the battery may be exhausted in
			a few days or even hours. Duty-cycling is a technique generally
			exploited by devices that use the P1 strategy [RFC7228], which need
			to be able to communicate on a relatively frequent basis. Note that
			a more aggressive approach to save energy relies on the P0, Normally-
			off strategy, whereby devices sleep for very long periods and
			communicate infrequently, even though they spend energy in network
			reattachment procedures. ContikiMAC is an example of a very typical
			Radio Duty Cycling (RDC) protocol [ContikiMAC].
	From the perspective of MAC&RDC, all upper layer protocols, such as		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 TX/RX		energy-efficiency of the wireless medium, it synchronizes the TX/RX
	request from the higher layer.		request from the higher layer.
	The MAC&RDC are not in the scope of the IETF, yet lower layer		The MAC&RDC are not in the scope of the IETF, yet lower layer
	designers and chipset manufactures take great care of the problem.		designers and chipset manufactures take great care of the problem.
	For the IETF protocol designers, however, it is good to know the		For the IETF protocol designers, however, it is good to know the
	behaviors of lower layers so that the designed protocols can work		behaviors of lower layers so that the designed protocols can work
	perfectly with them.		perfectly with them.
	Once again, the IETF protocols we are going to talk about in the		Once again, the IETF protocols we are going to talk about in the
	following sections are the customers of the lower layer. If they		following sections are the customers of the lower layer. If they
	want to get better service in a cooperative way, they should be		want to get better service in a cooperative way, they should be
	considerate and understand each other.		considerate and understand each other.
	3.1. Power Save Services Provided by IEEE 802.11v		3.1. Radio Duty Cycling techniques
			This subsection describes the main three RDC techniques. Note that
			more than one of the presented techniques may be available or can
			even be combined in a specific radio technology:
			a) Channel sampling. In this solution, the radio interface of a
			device periodically monitors the channel for very short time
			intervals (i.e. with a low duty cycle) with the aim of detecting
			incoming transmissions. In order to make sure that a receiver can
			correctly receive a transmitted data unit, the sender may prepend a
			preamble of a duration at least the sampling period to the data unit
			to be sent. Another option for the sender is to repeatedly transmit
			the data unit, instead of sending a preamble before the data unit.
			Once a transmission is detected by a receiver, the receiver may stay
			awake until the complete reception of the data unit. Examples of
			radio technologies that use preamble sampling include ContikiMAC, the
			Coordinated Sampled Listening (CSL) mode of IEEE 802.15.4e, and the
			Frequently Listening (FL) mode of ITU-T G.9959.
			b) Scheduled transmissions. This approach allows a device to know
			the instants in which it should be awake (during some time interval)
			in order to receive data units. Otherwise, the device may remain in
			sleep mode. The decision on the instants that will be used for
			communication is reached by means of some form of negotation between
			the involved devices. Such negotiation may be performed per
			transmission or per session/connection. Bluetooth Low Energy is an
			example of a radio technology based on this mechanism.
			c) Listen after send. This technique allows a node to remain in
			sleep mode by default, wake up and poll a sender (which must be ready
			to receive a poll message) for pending transmissions. After sending
			the poll message, the node remains in receive mode, ready for a
			potential incoming transmission. After a certain time interval, the
			node may go back to sleep. The Receiver Initated Transmission (RIT)
			mode of 802.15.4e, and the transmission of data between a coordinator
			and a device in IEEE 802.15.4-2003 use this technique.
			3.2. Latency and buffering
			The latency of a data unit transmission to a duty-cycled device is
			equal to or greater than the latency of transmitting to an always-on
			device. Therefore, duty-cycling leads to a trade-off between energy
			consumption and latency. Note that in addition to a latency
			increase, RDC may introduce latency variance, since the latency
			increase is a random variable (which is uniformly distributed if
			duty-cycling follows a periodical behavior).
			On the other hand, due to the latency increase of duty-cycling, a
			sender waiting for a transmission opportunity may need to store
			subsequent outgoing packets in a buffer, increasing memory
			requirements and potentially incurring queuing waiting time that
			contributes to the packet overall delay and increases the probability
			of buffer overflow, leading to losses.
			The parameters controlling the radio duty cycle have to be carefully
			tuned to achieve the intended application and/or network
			requirements. On the other hand, upper layers should take into
			account the expected latency behavior due to RDC.
			3.3. Power save services available in example low-power radios
			This subsection presents power save services and techniques used in a
			few relevant examples of wireless low-power radios: IEEE 802.11v,
			Bluetooth Low Energy and IEEE 802.15.4. For a more detailed overview
			of each technology, the reader may refer to the literature or to the
			corresponding specifications.
			3.3.1. Power Save Services Provided by IEEE 802.11v
	IEEE 802.11v [IEEE80211v] defines mechanisms and services for power		IEEE 802.11v [IEEE80211v] defines mechanisms and services for power
	save of stations/nodes that include flexible multicast service (FMS),		save of stations/nodes that include flexible multicast service (FMS),
	proxy ARP advertisement, extended sleep modes, traffic filtering. It		proxy ARP advertisement, extended sleep modes, traffic filtering. It
	would be useful if upper layer protocols knows such capabilities		would be useful if upper layer protocols knows such capabilities
	provided by the lower layer, so that they can coordinate with each		provided by the lower layer, so that they can coordinate with each
	other.		other.
	These services include:		These services include:
	skipping to change at page 6, line 45		skipping to change at page 9, line 9
	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.2. Power Save Services Provided by Bluetooth Low Energy		3.3.2. Power Save Services Provided by Bluetooth Low Energy
	Bluetooth Low Energy (BT-LE) is a wireless low-power communications		Bluetooth Low Energy (Bluetooth LE) is a wireless low-power
	technology that is the hallmark component of the Bluetooth 4.0		communications technology that is the hallmark component of the
	specification. BT-LE has been designed for the goal of ultra-low-		Bluetooth 4.0 and Bluetooth 4.1 specifications [Bluetooth41]"/>.
	power consumption. Currently, it is possible to run IPv6 over BT-LE		BT-LE has been designed for the goal of ultra-low-power consumption.
	networks by using a 6LoWPAN variant adapted to BT-LE		Currently, it is possible to run IPv6 over BT-LE networks by using a
	[I-D.ietf-6lowpan-btle].		6LoWPAN variant adapted to BT-LE [I-D.ietf-6lowpan-btle].
	BT-LE networks comprise a master and one or more slaves which are		Bluetooth LE networks comprise a master and one or more slaves which
	connected to the master. The BT-LE master is assumed to be a		are connected to the master. The Bluetooth LE master is assumed to
	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 BT-LE is based on a TDMA scheme which is coordinated		Medium access in Bluetooth LE is based on a TDMA scheme which is
	by the master. This device determines the start of connection		coordinated by the master. This device determines the start of
	events, in which communication between the master and a slave takes		connection events, in which communication between the master and a
	place. At the beginning of a connection event, the master sends a		slave takes place. At the beginning of a connection event, the
	poll message, which may encapsulate data, to the slave. The latter		master sends a poll message, which may encapsulate data, to the
	must send a response, which may also contain data. The master and		slave. The latter must send a response, which may also contain data.
	the slave may continue exchanging data until the end of the		The master and the slave may continue exchanging data until the end
	connection event. The next opportunity for communication between the		of the connection event. The next opportunity for communication
	master and the slave will be in the next connection event scheduled		between the master and the slave will be in the next connection event
	for the slave.		scheduled for the slave.
	The time between consecutive connection events is defined by the		The time between consecutive connection events is defined by the
	connInterval parameter, which may range between 7.5 ms and 4 s. The		connInterval parameter, which may range between 7.5 ms and 4 s. The
	slave may remain in sleep mode since the end of its last connection		slave may remain in sleep mode since the end of its last connection
	event until the beginning of its next connection event. Therefore,		event until the beginning of its next connection event. Therefore,
	BT-LE is duty-cycled by nature. Furthermore, after having replied to		Bluetooth LE is duty-cycled by nature. Furthermore, after having
	the master, a slave is not required to listen to the master (and thus		replied to the master, a slave is not required to listen to the
	may keep the radio in sleep mode) for connSlaveLatency consecutive		master (and thus may keep the radio in sleep mode) for
	connection events. connSlaveLatency is an integer parameter between 0		connSlaveLatency consecutive connection events. connSlaveLatency is
	and 499 which should not cause link inactivity for more than		an integer parameter between 0 and 499 which should not cause link
	connSupervisionTimeout time. The connSupervisionTimeout parameter is		inactivity for more than connSupervisionTimeout time. The
	in the range between 100 ms and 32 s.		connSupervisionTimeout parameter is in the range between 100 ms and
			32 s.
	Upper layer protocols should take into account the medium access and		Upper layer protocols should take into account the medium access and
	duty-cycling behavior of BT-LE. In particular, connInterval,		duty-cycling behavior of Bluetooth LE. In particular, connInterval,
	connSlaveLatency and connSupervisionTimeout determine the time		connSlaveLatency and connSupervisionTimeout determine the time
	between two consecutive connection events for a given slave. The		between two consecutive connection events for a given slave. The
	upper layer packet generation pattern and rate should be consistent		upper layer packet generation pattern and rate should be consistent
	with the settings of the aforementioned parameters (and vice versa).		with the settings of the aforementioned parameters (and vice versa).
	3.3. Power Save Services in IEEE 802.15.4		3.3.3. Power Save Services in IEEE 802.15.4
	IEEE 802.15.4 is a family of standard radio interfaces for low-rate,		IEEE 802.15.4 is a family of standard radio interfaces for low-rate,
	low-power wireless networking. Since the publication of its first		low-power wireless networking [fifteendotfour]. Since the
	version in 2003, IEEE 802.15.4 has become the de-facto choice for a		publication of its first version in 2003, IEEE 802.15.4 has become
	wide range of constrained node network application domains and has		the de-facto choice for a wide range of constrained node network
	been a primary target technology of various IETF working groups such		application domains and has been a primary target technology of
	as 6LoWPAN [RFC6282],[RFC6775],[RFC4944] and 6TiSCH		various IETF working groups such as 6LoWPAN
			[RFC6282],[RFC6775],[RFC4944] and 6TiSCH
	[I-D.ietf-6tisch-architecture]. IEEE 802.15.4 specifies PHY and MAC		[I-D.ietf-6tisch-architecture]. IEEE 802.15.4 specifies PHY and MAC
	layer functionality.		layer functionality.
	IEEE 802.15.4 defines three roles called device, coordinator and PAN		IEEE 802.15.4 defines three roles called device, coordinator and PAN
	coordinator. The device role is adequate for nodes that do not		coordinator. The device role is adequate for nodes that do not
	implement the complete IEEE 802.15.4 functionality, and is mainly		implement the complete IEEE 802.15.4 functionality, and is mainly
	targeted for constrained nodes with a limited energy source. The		targeted for constrained nodes with a limited energy source. The
	coordinator role includes synchronization capabilities and is		coordinator role includes synchronization capabilities and is
	suitable for nodes that do not suffer severe constraints (e.g. a		suitable for nodes that do not suffer severe constraints (e.g. a
	mains-powered node). The PAN coordinator is a special type of		mains-powered node). The PAN coordinator is a special type of
	coordinator that acts as a principal controller in an IEEE 802.15.4		coordinator that acts as a principal controller in an IEEE 802.15.4
	network.		network.
	IEEE 802.15.4 has mainly defined two types of networks depending on		IEEE 802.15.4 has mainly defined two types of networks depending on
	their configuration: beacon-enabled and nonbeacon-enabled networks.		their configuration: beacon-enabled and nonbeacon-enabled networks.
	In the first network type, coordinators periodically transmit		In the first network type, coordinators periodically transmit
	beacons. The time between beacons is divided in three main parts:		beacons. The time between beacons is divided in three main parts:
	the Contention Access Period (CAP), the Contention Free Period (CFP)		the Contention Access Period (CAP), the Contention Free Period (CFP)
	and an inactive period. In the first period, nodes use slotted CSMA/		and an inactive period. In the first period, nodes use slotted
	CA for data communication. In the second one, a TDMA scheme controls		CSMA/CA for data communication. In the second one, a TDMA scheme
	medium access. During the idle period, communication does not take		controls medium access. During the idle period, communication does
	place, thus the inactive period is a good opportunity for nodes to		not take place, thus the inactive period is a good opportunity for
	turn the radio off and save energy. The coordinator announces in		nodes to turn the radio off and save energy. The coordinator
	each beacon the list of nodes for which data will be sent in the		announces in each beacon the list of nodes for which data will be
	subsequent period. Therefore, devices may remain in sleep mode by		sent in the subsequent period. Therefore, devices may remain in
	default and wake up periodically to listen to the beacons sent by		sleep mode by default and wake up periodically to listen to the
	their coordinator. If a device wants to transmit data, or learns		beacons sent by their coordinator. If a device wants to transmit
	from a beacon that it is an intended destination, then it will		data, or learns from a beacon that it is an intended destination,
	exchange messages with the coordinator and will thus consume energy.		then it will exchange messages with the coordinator and will thus
	An underlying assumption is that when a message is sent to a		consume energy. An underlying assumption is that when a message is
	coordinator, the radio of the latter will be ready to receive the		sent to a coordinator, the radio of the latter will be ready to
	message.		receive the message.
	The beacon interval and the duration of the beacon interval active		The beacon interval and the duration of the beacon interval active
	portion (i.e. the CAP and the CFP), and thus the duty cycle, can be		portion (i.e. the CAP and the CFP), and thus the duty cycle, can be
	configured. The parameters that control these times are called		configured. The parameters that control these times are called
	macBeaconOrder and macSuperframeOrder, respectively. As an example,		macBeaconOrder and macSuperframeOrder, respectively. As an example,
	when IEEE 802.15.4 operates in the 2.4 GHz PHY, both times can be		when IEEE 802.15.4 operates in the 2.4 GHz PHY, both times can be
	(independently) set to values in the range between 15.36 ms and 251.6		(independently) set to values in the range between 15.36 ms and 251.6
	s.		s.
	In the beaconless mode, nodes use unslotted CSMA/CA for data		In the beaconless mode, nodes use unslotted CSMA/CA for data
	skipping to change at page 9, line 24		skipping to change at page 11, line 38
	the 6TiSCH working group has been recently created. TSCH is based on		the 6TiSCH working group has been recently created. TSCH is based on
	a TDMA schedule whereby a set of time slots are used for frame		a TDMA schedule whereby a set of time slots are used for frame
	transmission and reception, and other time slots are unscheduled.		transmission and reception, and other time slots are unscheduled.
	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
			the previously mentioned CSL and RIT.
	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
	skipping to change at page 10, line 36		skipping to change at page 13, line 23
	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 and data
	traffic stays relatively constant. The study also reflects that the		traffic stays relatively constant. The study also reflects that the
	routing protocol should keep the control traffic as low as possible		routing protocol should keep the control traffic as low as possible
	to make it energy-friendly. The amount of RPL control traffic can be		to make it energy-friendly. The amount of RPL control traffic can be
	tuned by setting the Trickle algorithm parameters (i.e. Imin, Imax		tuned by setting the Trickle algorithm parameters (i.e. Imin, Imax
	and k) to adequate values. However, there exists a trade-off between		and k) to adequate values. However, there exists a trade-off between
	energy consumption and other performance parameters such as network		energy consumption and other performance parameters such as network
	convergence time and robustness.		convergence time and robustness.
	Todo: more discussion of energy efficient routing.		RFC 6551 [RFC6551] defines routing metrics and constraints to be used
			by RPL in route computation. Among others, RFC 6551 specifies a Node
			Energy object that allows to provide information related to node
			energy, such as the energy source type or the estimated percentage of
			remaining energy. Appropriate use of energy-based routing metrics
			may help to balance energy consumption of network nodes, minimize
			network partitioning and increase network lifetime.
	6. Application Layer		6. Application Layer
	CoAP [I-D.ietf-core-coap]was designed as a RESTful application		CoAP [RFC7252] was designed as a RESTful application protocol,
	protocol, connecting the services of smart devices to the World Wide		connecting the services of smart devices to the World Wide Web. CoAP
	Web. CoAP is not a chatty protocol, it provides basic communication		is not a chatty protocol, it provides basic communication services
	services such as service discovery and GET/POST/PUT/DELETE methods		such as service discovery and GET/POST/PUT/DELETE methods with a
	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. To reduce regular and frequent queries of the		protocol design. CoAP uses a fixed-length binary header of only four
	resources, CoAP provides an observe mode, in which the requester		bytes that may be followed by binary options. To reduce regular and
	registers its interest of a certain resource and the responder will		frequent queries of the resources, CoAP provides an observe mode, in
	report the value whenever it was updated. This reduces the request		which the requester registers its interest of a certain resource and
	response roundtrip while keeping information exchange a ubiquitous		the responder will report the value whenever it was updated. This
	service.		reduces the request response roundtrip while keeping information
			exchange a ubiquitous service and, most importantly, it allows an
			energy-constrained server to remain in sleep mode during the period
			between observe notification transmissions.
			Furthermore, [RFC7252] defines CoAP proxies which can cache resource
			representations previously provided by sleepy CoAP servers. The
			proxies themselves may respond to client requests if the
			corresponding server is sleeping and the resource representation is
			recent enough. Otherwise, a proxy may attempt to obtain the resource
			from the sleepy server.
			Beyond these features of CoAP, there have been a number of proposals
			to further support sleepy nodes at the application layer by
			leveraging CoAP mechanisms. A good summary of such proposals can be
			found in [I-D.rahman-core-sleepy-nodes-do-we-need]. The different
			approaches include exploiting the use of proxies, leveraging the
			Resource Directory [I-D.ietf-core-resource-directory] or signaling
			when a node is awake to the interested nodes. As of the writing,
			none of these proposals has been adopted by the CoRE working group.
	CoAP offers mechanisms for reliable communication between two CoAP		CoAP offers mechanisms for reliable communication between two CoAP
	endpoints. A CoAP message may be signaled as a confirmable (CON)		endpoints. A CoAP message may be signaled as a confirmable (CON)
	message, and an acknowledgment (ACK) is issued by the receiver if the		message, and an acknowledgment (ACK) is issued by the receiver if the
	CON message is correctly received. The sender starts a		CON message is correctly received. The sender starts a
	Retransmission TimeOut (RTO) for every CON message sent. The initial		Retransmission TimeOut (RTO) for every CON message sent. The initial
	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. Cross Layer Optimization		7. Cross Layer Optimization
	The cross layer optimization is a technique used in many		The cross layer optimization is a technique used in many
	skipping to change at page 12, line 44		skipping to change at page 20, line 11
	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.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[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.
	[Cross-layer-Optimization]		[Cross-layer-Optimization]
	Le, and Hossain, "Cross-Layer Optimization Frameworks for		Le and Hossain, "Cross-Layer Optimization Frameworks for
	Multihop Wireless Networks Using Cooperative Diversity",		Multihop Wireless Networks Using Cooperative Diversity",
	July 2008.		July 2008.
	[Cross-layer-design]		[Cross-layer-design]
	Chen, , Low, , and Doyle, "Cross-layer design in multihop		Chen, Low, and Doyle, "Cross-layer design in multihop
	wireless networks", 2011.		wireless networks", 2011.
	[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",
	nud-07 (work in progress), October 2013.		draft-ietf-6man-impatient-nud-07 (work in progress),
			October 2013.
	[I-D.ietf-6tisch-architecture]		[I-D.ietf-6tisch-architecture]
	Thubert, P., Watteyne, T., and R. Assimiti, "An		Thubert, P., Watteyne, T., and R. Assimiti, "An
	Architecture for IPv6 over the TSCH mode of IEEE		Architecture for IPv6 over the TSCH mode of IEEE
	802.15.4e", draft-ietf-6tisch-architecture-01 (work in		802.15.4e", draft-ietf-6tisch-architecture-03 (work in
	progress), February 2014.		progress), July 2014.
	[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-00 (work in		Configuration", draft-ietf-6tisch-minimal-02 (work in
	progress), November 2013.		progress), July 2014.
	[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]
			Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource
			Directory", draft-ietf-core-resource-directory-01 (work in
			progress), December 2013.
	[I-D.ietf-lwig-terminology]		[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.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]
			Rahman, A., "Sleepy Devices: Do we need to Support them in
			CORE?", draft-rahman-core-sleepy-nodes-do-we-need-01 (work
			in progress), February 2014.
	[IEEE80211v]		[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.
	[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.
	12.2. Informative References		12.2. Informative References
	[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, March 1997.
	[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, September 2007.
	[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6		[RFC6282] Hui, J. 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.		September 2011.
	[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,		[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
	Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.		Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
	Alexander, "RPL: IPv6 Routing Protocol for Low-Power and		Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
	Lossy Networks", RFC 6550, March 2012.		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,		[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
	"Neighbor Discovery Optimization for IPv6 over Low-Power		"Neighbor Discovery Optimization for IPv6 over Low-Power
	Wireless Personal Area Networks (6LoWPANs)", RFC 6775,		Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
	November 2012.		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.)
	China Mobile		Leibniz University of Hannover
	Xuanwumenxi Ave. No.32
	Beijing 100871
	P.R.China		P.R.China
	Email: zehn.cao@gmail.com, caozhen@chinamobile.com		Phone:
			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
			Phone:
			Fax:
	Email: carlesgo@entel.upc.edu		Email: carlesgo@entel.upc.edu
			URI:
	Matthias Kovatsch		Matthias Kovatsch
	ETH Zurich		ETH Zurich
	Universitaetstrasse 6		Universitaetstrasse 6
	Zurich, CH-8092		Zurich, CH-8092
	Switzerland		Switzerland
			Phone:
			Fax:
	Email: kovatsch@inf.ethz.ch		Email: kovatsch@inf.ethz.ch
			URI:
	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
			Phone:
			Fax:
	Email: tianhui@mail.ritt.com.cn		Email: tianhui@mail.ritt.com.cn
			URI:
	Xuan He		Xuan He
	Hitachi China R&D Corporation		Hitachi China R&D Corporation
	301, Tower C North, Raycom, 2 Kexuyuan Nanlu, Haidian District		301, Tower C North, Raycom, 2 Kexuyuan Nanlu, Haidian District
	Beijing 100190		Beijing, 100190
	P.R.China		P.R.China
			Phone:
			Fax:
	Email: xhe@hitachi.cn		Email: xhe@hitachi.cn
			URI:
End of changes. 55 change blocks.
	128 lines changed or deleted		290 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/