draft-ietf-lwig-terminology-05.txt		draft-ietf-lwig-terminology-06.txt
	LWIG Working Group C. Bormann		LWIG Working Group C. Bormann
	Internet-Draft Universitaet Bremen TZI		Internet-Draft Universitaet Bremen TZI
	Intended status: Informational M. Ersue		Intended status: Informational M. Ersue
	Expires: January 10, 2014 Nokia Siemens Networks		Expires: June 21, 2014 Nokia Siemens Networks
	A. Keranen		A. Keranen
	Ericsson		Ericsson
	July 09, 2013		December 18, 2013
	Terminology for Constrained Node Networks		Terminology for Constrained Node Networks
	draft-ietf-lwig-terminology-05		draft-ietf-lwig-terminology-06
	Abstract		Abstract
	The Internet Protocol Suite is increasingly used on small devices		The Internet Protocol Suite is increasingly used on small devices
	with severe constraints, creating constrained node networks. This		with severe constraints on power, memory and processing resources,
	document provides a number of basic terms that have turned out to be		creating constrained node networks. This document provides a number
	useful in the standardization work for constrained environments.		of basic terms that have turned out to be useful in the
			standardization work for constrained node networks.
	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 January 10, 2014.		This Internet-Draft will expire on June 21, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Core Terminology . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Constrained Nodes . . . . . . . . . . . . . . . . . . . . 3		2.1. Constrained Nodes . . . . . . . . . . . . . . . . . . . . 4
	2.2. Constrained Networks . . . . . . . . . . . . . . . . . . 4		2.2. Constrained Networks . . . . . . . . . . . . . . . . . . 5
	2.2.1. Challenged Networks . . . . . . . . . . . . . . . . . 5		2.2.1. Challenged Networks . . . . . . . . . . . . . . . . . 6
	2.3. Constrained Node Networks . . . . . . . . . . . . . . . . 5		2.3. Constrained Node Networks . . . . . . . . . . . . . . . . 6
	2.3.1. LLN ("low-power lossy network") . . . . . . . . . . . 6		2.3.1. LLN ("low-power lossy network") . . . . . . . . . . . 7
	2.3.2. LoWPAN, 6LoWPAN . . . . . . . . . . . . . . . . . . . 6		2.3.2. LoWPAN, 6LoWPAN . . . . . . . . . . . . . . . . . . . 7
	3. Classes of Constrained Devices . . . . . . . . . . . . . . . 8		3. Classes of Constrained Devices . . . . . . . . . . . . . . . 8
	4. Power Terminology . . . . . . . . . . . . . . . . . . . . . . 10		4. Power Terminology . . . . . . . . . . . . . . . . . . . . . . 10
	4.1. Scaling Properties . . . . . . . . . . . . . . . . . . . 10		4.1. Scaling Properties . . . . . . . . . . . . . . . . . . . 10
	4.2. Classes of Energy Limitation . . . . . . . . . . . . . . 10		4.2. Classes of Energy Limitation . . . . . . . . . . . . . . 10
	4.3. Strategies of Using Power for Communication . . . . . . . 11		4.3. Strategies of Using Power for Communication . . . . . . . 11
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 13		5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	8. Informative References . . . . . . . . . . . . . . . . . . . 13		8. Informative References . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	Small devices with limited CPU, memory, and power resources, so		Small devices with limited CPU, memory, and power resources, so
	called constrained devices (also known as sensor, smart object, or		called constrained devices (often used as a sensor/actuator, a smart
	smart device) can constitute a network, becoming "constrained nodes"		object, or a smart device) can form a network, becoming "constrained
	in that network. Such a network may itself exhibit constraints, e.g.		nodes" in that network. Such a network may itself exhibit
	with unreliable or lossy channels, limited and unpredictable		constraints, e.g. with unreliable or lossy channels, limited and
	bandwidth, and a highly dynamic topology.		unpredictable bandwidth, and a highly dynamic topology.
	Constrained devices might be in charge of gathering information in		Constrained devices might be in charge of gathering information in
	diverse settings including natural ecosystems, buildings, and		diverse settings including natural ecosystems, buildings, and
	factories and sending the information to one or more server stations.		factories and sending the information to one or more server stations.
	Constrained devices may work under severe resource constraints such		They also act on information, by performing some physical action,
	as limited battery and computing power, little memory, as well as		including displaying it. Constrained devices may work under severe
	insufficient wireless bandwidth and ability to communicate. Other		resource constraints such as limited battery and computing power,
			little memory, as well as insufficient wireless bandwidth and ability
			to communicate; these constraints often exacerbate each other. Other
	entities on the network, e.g., a base station or controlling server,		entities on the network, e.g., a base station or controlling server,
	might have more computational and communication resources and could		might have more computational and communication resources and could
	support the interaction between the constrained devices and		support the interaction between the constrained devices and
	applications in more traditional networks.		applications in more traditional networks.
	Today diverse sizes of constrained devices with different resources		Today diverse sizes of constrained devices with different resources
	and capabilities are becoming connected. Mobile personal gadgets,		and capabilities are becoming connected. Mobile personal gadgets,
	building-automation devices, cellular phones, Machine-to-machine		building-automation devices, cellular phones, Machine-to-machine
	(M2M) devices, etc. benefit from interacting with other "things"		(M2M) devices, etc. benefit from interacting with other "things"
	nearby or somewhere in the Internet. With this, the Internet of		nearby or somewhere in the Internet. With this, the Internet of
	Things (IoT) becomes a reality, built up out of uniquely identifiable		Things (IoT) becomes a reality, built up out of uniquely identifiable
	and addressable objects (things). And over the next decade, this		and addressable objects (things). And over the next decade, this
	could grow to large numbers [fifty-billion] of Internet-connected		could grow to large numbers [fifty-billion] of Internet-connected
	constrained devices, greatly increasing the Internet's size and		constrained devices, greatly increasing the Internet's size and
	scope.		scope.
	The present document provides a number of basic terms that have		The present document provides a number of basic terms that have
	turned out to be useful in the standardization work for constrained		turned out to be useful in the standardization work for constrained
	environments. The intention is not to exhaustively cover the field,		environments. The intention is not to exhaustively cover the field,
	but to make sure a few core terms are used consistently between		but to make sure a few core terms are used consistently between
	different groups cooperating in this space.		different groups cooperating in this space.
	In this document, the term "byte" is used in its now customary sense		In this document, the term "byte" is used in its now customary sense
	as a synonym for "octet". Where sizes of semiconductor memory are		as a synonym for "octet". Where sizes of semiconductor memory are
	given, the prefix "kibi" (1024) is combined with "byte" to		given, the prefix "kibi" (1024) is combined with "byte" to
	"kibibyte", abbreviated "KiB", for 1024 bytes [ISQ-13].		"kibibyte", abbreviated "KiB", for 1024 bytes [ISQ-13].
	2. Terminology		In computing, the term "power" is often used for the concept of
			"computing power" or "processing power", as in CPU performance.
			Unless explicitly stated otherwise, in this document the term stands
			for electrical power. "Mains-powered" is used as a short-hand for
			being permanently connected to a stable electrical power grid.
	The main focus of this field of work appears to be _scaling_:		2. Core Terminology
			There are two important aspects to _scaling_ within the Internet of
			Things:
	o Scaling up Internet technologies to a large number [fifty-billion]		o Scaling up Internet technologies to a large number [fifty-billion]
	of inexpensive nodes, while		of inexpensive nodes, while
	o scaling down the characteristics of each of these nodes and of the		o scaling down the characteristics of each of these nodes and of the
	networks being built out of them, to make this scaling up		networks being built out of them, to make this scaling up
	economically and physically viable.		economically and physically viable.
	The need for scaling down the characteristics of nodes leads to		The need for scaling down the characteristics of nodes leads to
	_constrained nodes_.		_constrained nodes_.
	2.1. Constrained Nodes		2.1. Constrained Nodes
	The term "constrained node" is best defined by contrasting the		The term "constrained node" is best defined by contrasting the
	characteristics of a constrained node with certain widely held		characteristics of a constrained node with certain widely held
	expectations on more familiar Internet nodes:		expectations on more familiar Internet nodes:
	Constrained Node: A node where some of the characteristics that are		Constrained Node: A node where some of the characteristics that are
	otherwise pretty much taken for granted for Internet nodes in 2013		otherwise pretty much taken for granted for Internet nodes at the
	are not attainable, often due to cost constraints and/or physical		time of writing are not attainable, often due to cost constraints
	constraints on characteristics such as size, weight, and available		and/or physical constraints on characteristics such as size,
	power and energy.		weight, and available power and energy. The tight limits on
			power, memory and processing resources lead to hard upper bounds
			on state, code space and processing cycles, making optimization of
			energy and network bandwidth usage a dominating consideration in
			all design requirements. Also, some layer 2 services such as full
			connectivity and broadcast/multicast may be lacking.
	While this is less than satisfying as a rigorous definition, it is		While this is not a rigorous definition, it is grounded in the state
	grounded in the state of the art and clearly sets apart constrained		of the art and clearly sets apart constrained nodes from server
	nodes from server systems, desktop or laptop computers, powerful		systems, desktop or laptop computers, powerful mobile devices such as
	mobile devices such as smartphones etc. There may be many design		smartphones etc. There may be many design considerations that lead
	considerations that lead to these constraints, including cost, size,		to these constraints, including cost, size, weight, and other scaling
	weight, and other scaling factors.		factors.
	(An alternative name, when the properties as a network node are not		(An alternative name, when the properties as a network node are not
	in focus, is "constrained device".)		in focus, is "constrained device".)
	There are multiple facets to the constraints on nodes, often applying		There are multiple facets to the constraints on nodes, often applying
	in combination, e.g.:		in combination, e.g.:
	o constraints on the maximum code complexity (ROM/Flash);		o constraints on the maximum code complexity (ROM/Flash);
	o constraints on the size of state and buffers (RAM);		o constraints on the size of state and buffers (RAM);
	o constraints on the available power.		o constraints on the amount of computation feasible in a period of
			time ("processing power");
			o constraints on the available (electrical) power;
			o constraints on user interface and accessibility in deployment
			(ability to set keys, update software, etc.).
	Section 3 defines a small number of interesting classes ("class-N"		Section 3 defines a small number of interesting classes ("class-N"
	for N=0,1,2) of constrained nodes focusing on relevant combinations		for N=0,1,2) of constrained nodes focusing on relevant combinations
	of the first two constraints. With respect to available power,		of the first two constraints. With respect to available (electrical)
	[RFC6606] distinguishes "power-affluent" nodes (mains-powered or		power, [RFC6606] distinguishes "power-affluent" nodes (mains-powered
	regularly recharged) from "power-constrained nodes" that draw their		or regularly recharged) from "power-constrained nodes" that draw
	power from primary batteries or by using energy harvesting; more		their power from primary batteries or by using energy harvesting;
	detailed power terminology is given in Section 4.		more detailed power terminology is given in Section 4.
	The use of constrained nodes in networks often also leads to		The use of constrained nodes in networks often also leads to
	constraints on the networks themselves. However, there may also be		constraints on the networks themselves. However, there may also be
	constraints on networks that are largely independent from those of		constraints on networks that are largely independent from those of
	the nodes. We therefore distinguish _constrained networks_ and		the nodes. We therefore distinguish _constrained networks_ and
	_constrained node networks_.		_constrained node networks_.
	2.2. Constrained Networks		2.2. Constrained Networks
	We define "constrained network" in a similar way:		We define "constrained network" in a similar way:
	Constrained Network: A network where some of the characteristics		Constrained Network: A network where some of the characteristics
	pretty much taken for granted with link layers in common use in		pretty much taken for granted with link layers in common use in
	the Internet by 2013, are not attainable.		the Internet at the time of writing, are not attainable.
	Again, there may be several reasons for this:		Again, there may be several reasons for this:
	o cost constraints on the network,		o cost constraints on the network,
	o constraints of the nodes (for constrained node networks),		o constraints of the nodes (for constrained node networks),
	o physical constraints (e.g., power constraints, environmental		o physical constraints (e.g., power constraints, environmental
	constraints, media constraints such as underwater operation,		constraints, media constraints such as underwater operation,
	limited spectrum for very high density, electromagnetic		limited spectrum for very high density, electromagnetic
	skipping to change at page 5, line 19		skipping to change at page 5, line 52
	o technology constraints, such as older and lower speed technologies		o technology constraints, such as older and lower speed technologies
	that are still operational and may need to stay in use for some		that are still operational and may need to stay in use for some
	more time.		more time.
	Constraints may include:		Constraints may include:
	o low achievable bit rate (including limits on duty cycle),		o low achievable bit rate (including limits on duty cycle),
	o high packet loss, packet loss (delivery rate) variability,		o high packet loss, packet loss (delivery rate) variability,
			o highly asymmetric link characteristics,
	o severe penalties for using larger packets (e.g., high packet loss		o severe penalties for using larger packets (e.g., high packet loss
	due to link layer fragmentation),		due to link layer fragmentation),
	o lack of (or severe constraints on) advanced services such as IP		o lack of (or severe constraints on) advanced services such as IP
	multicast.		multicast.
	2.2.1. Challenged Networks		2.2.1. Challenged Networks
	A constrained network is not necessarily a _challenged_ network		A constrained network is not necessarily a _challenged_ network
	[FALL]:		[FALL]:
	skipping to change at page 6, line 10		skipping to change at page 6, line 43
	Constrained Node Network: A network whose characteristics are		Constrained Node Network: A network whose characteristics are
	influenced by being composed of a significant portion of		influenced by being composed of a significant portion of
	constrained nodes.		constrained nodes.
	A constrained node network always is a constrained network because of		A constrained node network always is a constrained network because of
	the network constraints stemming from the node constraints, but may		the network constraints stemming from the node constraints, but may
	also have other constraints that already make it a constrained		also have other constraints that already make it a constrained
	network.		network.
			The rest of this subsection introduces two additional terms that are
			in active use in the area of constrained node networks, without an
			intent to define them: LLN and (6)LoWPAN.
	2.3.1. LLN ("low-power lossy network")		2.3.1. LLN ("low-power lossy network")
	A related term that has been used recently is "low-power lossy		A related term that has been used to describe the focus of the IETF
	network" (LLN). In its terminology document, the ROLL working group		working group on Routing Over Low power and Lossy networks (ROLL) is
	is saying [I-D.ietf-roll-terminology]:		"low-power lossy network" (LLN). The ROLL terminology document
			[I-D.ietf-roll-terminology] defines LLNs as follows:
	LLN: Low power and Lossy networks (LLNs) are typically composed of		LLN: Low power and Lossy networks (LLNs) are typically composed of
	many embedded devices with limited power, memory, and processing		many embedded devices with limited power, memory, and processing
	resources interconnected by a variety of links, such as IEEE		resources interconnected by a variety of links, such as IEEE
	802.15.4 or Low Power WiFi. There is a wide scope of application		802.15.4 or Low Power WiFi. There is a wide scope of application
	areas for LLNs, including industrial monitoring, building		areas for LLNs, including industrial monitoring, building
	automation (HVAC, lighting, access control, fire), connected home,		automation (HVAC, lighting, access control, fire), connected home,
	healthcare, environmental monitoring, urban sensor networks,		healthcare, environmental monitoring, urban sensor networks,
	energy management, assets tracking and refrigeration.. [sic]		energy management, assets tracking and refrigeration.. [sic]
	In common usage, LLN often stands for "the network characteristics		Beyond that, LLNs often exhibit considerable loss at the physical
	that RPL has been designed for". Beyond what is said in the ROLL		layer, with significant variability of the delivery rate, and some
	terminology document, LLNs do appear to have significant loss at the		short-term unreliability, coupled with some medium term stability
	physical layer, with significant variability of the delivery rate,		that makes it worthwhile to construct medium-term stable directed
	and some short-term unreliability, coupled with some medium term		acyclic graphs for routing and do measurements on the edges such as
	stability that makes it worthwhile to construct medium-term stable		ETX [RFC6551]. Actual "low power" does not seem to be a defining
	directed acyclic graphs for routing and do measurements on the edges		characteristic for an LLN [I-D.hui-vasseur-roll-rpl-deployment].
	such as ETX [RFC6551]. Actual "low power" does not seem to be
	required for an LLN [I-D.hui-vasseur-roll-rpl-deployment], and the
	positions on scaling of LLNs appear to vary widely
	[I-D.clausen-lln-rpl-experiences].
	The ROLL terminology document states that LLNs typically are composed		LLNs typically are composed of constrained nodes; this leads to the
	of constrained nodes; this is also supported by the design of		design of operation modes such as the "non-storing mode" defined by
	operation modes such as RPL's "non-storing mode". So, in the		RPL (the IPv6 Routing Protocol for Low-Power and Lossy Networks
	terminology of the present document, an LLN seems to be a constrained		[RFC6650]). So, in the terminology of the present document, an LLN
	node network with certain network characteristics, which include		is a constrained node network with certain network characteristics,
	constraints on the network as well.		which include constraints on the network as well.
	2.3.2. LoWPAN, 6LoWPAN		2.3.2. LoWPAN, 6LoWPAN
	One interesting class of a constrained network often used as a		One interesting class of a constrained network often used as a
	constrained node network is the "LoWPAN" [RFC4919], a term inspired		constrained node network is the "LoWPAN" [RFC4919], a term inspired
	from the name of the IEEE 802.15.4 working group (low-rate wireless		from the name of the IEEE 802.15.4 working group (low-rate wireless
	personal area networks (LR-WPANs)). The expansion of that acronym,		personal area networks (LR-WPANs)). The expansion of that acronym,
	"Low-Power Wireless Personal Area Network" contains a hard to justify		"Low-Power Wireless Personal Area Network" contains a hard to justify
	"Personal" that is due to the history of task group naming in IEEE		"Personal" that is due to the history of task group naming in IEEE
	802 more than due to an orientation of LoWPANs around a single		802 more than due to an orientation of LoWPANs around a single
	person. Actually, LoWPANs have been suggested for urban monitoring,		person. Actually, LoWPANs have been suggested for urban monitoring,
	control of large buildings, and industrial control applications, so		control of large buildings, and industrial control applications, so
	the "Personal" can only be considered a vestige. Maybe the term is		the "Personal" can only be considered a vestige. Occasionally the
	best read as "Low-Power Wireless Area Networks" (LoWPANs) [WEI].		term is read as "Low-Power Wireless Area Networks" (LoWPANs) [WEI].
	Originally focused on IEEE 802.15.4, "LoWPAN" (or when used for IPv6,		Originally focused on IEEE 802.15.4, "LoWPAN" (or when used for IPv6,
	"6LoWPAN") is now also being used for networks built from similarly		"6LoWPAN") also refers to networks built from similarly constrained
	constrained link layer technologies [I-D.ietf-6lowpan-btle]		link layer technologies [I-D.ietf-6lowpan-btle]
	[I-D.mariager-6lowpan-v6over-dect-ule] [I-D.brandt-6man-lowpanz].		[I-D.mariager-6lowpan-v6over-dect-ule] [I-D.brandt-6man-lowpanz].
	3. Classes of Constrained Devices		3. Classes of Constrained Devices
	Despite the overwhelming variety of Internet-connected devices that		Despite the overwhelming variety of Internet-connected devices that
	can be envisioned, it may be worthwhile to have some succinct		can be envisioned, it may be worthwhile to have some succinct
	terminology for different classes of constrained devices. In this		terminology for different classes of constrained devices. In this
	document, the class designations in Table 1 may be used as rough		document, the class designations in Table 1 may be used as rough
	indications of device capabilities:		indications of device capabilities:
	skipping to change at page 8, line 48		skipping to change at page 8, line 48
	gateways or servers. Class 0 devices generally cannot be secured or		gateways or servers. Class 0 devices generally cannot be secured or
	managed comprehensively in the traditional sense. They will most		managed comprehensively in the traditional sense. They will most
	likely be preconfigured (and will be reconfigured rarely, if at all),		likely be preconfigured (and will be reconfigured rarely, if at all),
	with a very small data set. For management purposes, they could		with a very small data set. For management purposes, they could
	answer keepalive signals and send on/off or basic health indications.		answer keepalive signals and send on/off or basic health indications.
	Class 1 devices cannot easily talk to other Internet nodes employing		Class 1 devices cannot easily talk to other Internet nodes employing
	a full protocol stack such as using HTTP, TLS and related security		a full protocol stack such as using HTTP, TLS and related security
	protocols and XML-based data representations. However, they have		protocols and XML-based data representations. However, they have
	enough power to use a protocol stack specifically designed for		enough power to use a protocol stack specifically designed for
	constrained nodes (e.g., CoAP over UDP) and participate in meaningful		constrained nodes (such as CoAP over UDP [I-D.ietf-core-coap]) and
	conversations without the help of a gateway node. In particular,		participate in meaningful conversations without the help of a gateway
	they can provide support for the security functions required on a		node. In particular, they can provide support for the security
	large network. Therefore, they can be integrated as fully developed		functions required on a large network. Therefore, they can be
	peers into an IP network, but they need to be parsimonious with state		integrated as fully developed peers into an IP network, but they need
	memory, code space, and often power expenditure for protocol and		to be parsimonious with state memory, code space, and often power
	application usage.		expenditure for protocol and application usage.
	Class 2 can already support mostly the same protocol stacks as used		Class 2 can already support mostly the same protocol stacks as used
	on notebooks or servers. However, even these devices can benefit		on notebooks or servers. However, even these devices can benefit
	from lightweight and energy-efficient protocols and from consuming		from lightweight and energy-efficient protocols and from consuming
	less bandwidth. Furthermore, using fewer resources for networking		less bandwidth. Furthermore, using fewer resources for networking
	leaves more resources available to applications. Thus, using the		leaves more resources available to applications. Thus, using the
	protocol stacks defined for very constrained devices also on Class 2		protocol stacks defined for very constrained devices also on Class 2
	devices might reduce development costs and increase the		devices might reduce development costs and increase the
	interoperability.		interoperability.
	skipping to change at page 10, line 18		skipping to change at page 10, line 18
	available electrical power and/or energy. While it is harder to find		available electrical power and/or energy. While it is harder to find
	recognizable clusters in this space, it is still useful to introduce		recognizable clusters in this space, it is still useful to introduce
	some common terminology.		some common terminology.
	4.1. Scaling Properties		4.1. Scaling Properties
	The power and/or energy available to a device may vastly differ, from		The power and/or energy available to a device may vastly differ, from
	kilowatts to microwatts, from essentially unlimited to hundreds of		kilowatts to microwatts, from essentially unlimited to hundreds of
	microjoules.		microjoules.
	Instead of defining classes or clusters, we propose simply stating,		Instead of defining classes or clusters, we simply state, in SI
	in SI units, an approximate value for one or both of the quantities		units, an approximate value for one or both of the quantities listed
	listed in Table 2:		in Table 2:
	+--------+---------------------------------------------+------------+		+--------+---------------------------------------------+------------+
	| Name | Definition | SI Unit |		| Name | Definition | SI Unit |
	+--------+---------------------------------------------+------------+		+--------+---------------------------------------------+------------+
	| Ps | Sustainable average power available for the | W (Watt) |		| Ps | Sustainable average power available for the | W (Watt) |
	| | device over the time it is functioning | |		| | device over the time it is functioning | |
	| | | |		| | | |
	| Et | Total electrical energy available before | J (Joule) |		| Et | Total electrical energy available before | J (Joule) |
	| | the energy source is exhausted | |		| | the energy source is exhausted | |
	+--------+---------------------------------------------+------------+		+--------+---------------------------------------------+------------+
	Table 2: Quantities Relevant to Power and Energy		Table 2: Quantities Relevant to Power and Energy
	The value of Et may need to be interpreted in conjunction with an		The value of Et may need to be interpreted in conjunction with an
	indication over which period of time the value is given; see the next		indication over which period of time the value is given; see the next
	subsection.		subsection.
			Some devices enter a "low-power" mode before the energy available in
			a period is exhausted, or even have multiple such steps on the way to
			exhaustion. For these devices, Ps would need to be given for each of
			the modes/steps.
	4.2. Classes of Energy Limitation		4.2. Classes of Energy Limitation
	As discussed above, some devices are limited in available energy as		As discussed above, some devices are limited in available energy as
	opposed to (or in addition to) being limited in available power.		opposed to (or in addition to) being limited in available power.
	Where no relevant limitations exist with respect to energy, the		Where no relevant limitations exist with respect to energy, the
	device is classified as E3. The energy limitation may be in total		device is classified as E9. The energy limitation may be in total
	energy available in the usable lifetime of the device (e.g. a device		energy available in the usable lifetime of the device (e.g. a device
	with a non-replaceable primary battery, which is discarded when this		with a non-replaceable primary battery, which is discarded when this
	battery is exhausted), classified as E2. Where the relevant		battery is exhausted), classified as E2. Where the relevant
	limitation is for a specific period, this is classified as E1, e.g.		limitation is for a specific period, this is classified as E1, e.g. a
	a limited amount of energy available for the night with a solar-		limited amount of energy available for the night with a solar-powered
	powered device, or for the period between recharges with a device		device, or for the period between recharges with a device that is
	that is manually connected to a charger, or by a periodic (primary)		manually connected to a charger, or by a periodic (primary) battery
	battery replacement interval. Finally, there may be a limited amount		replacement interval. Finally, there may be a limited amount of
	of energy available for a specific event, e.g. for a button press in		energy available for a specific event, e.g. for a button press in an
	an energy harvesting light switch; this is classified as E0. Note		energy harvesting light switch; this is classified as E0. Note that
	that many E1 devices in a sense also are E2, as the rechargeable		many E1 devices in a sense also are E2, as the rechargeable battery
	battery has a limited number of useful recharging cycles.		has a limited number of useful recharging cycles.
	In summary, we distinguish (Table 3):		In summary, we distinguish (Table 3):
	+------+------------------------------+-----------------------------+		+------+------------------------------+-----------------------------+
	| Name | Type of energy limitation | Example Power Source |		| Name | Type of energy limitation | Example Power Source |
	+------+------------------------------+-----------------------------+		+------+------------------------------+-----------------------------+
	| E0 | Event energy-limited | Event-based harvesting |		| E0 | Event energy-limited | Event-based harvesting |
	| | | |		| | | |
	| E1 | Period energy-limited | Battery that is |		| E1 | Period energy-limited | Battery that is |
	| | | periodically recharged or |		| | | periodically recharged or |
	| | | replaced |		| | | replaced |
	| | | |		| | | |
	| E2 | Lifetime energy-limited | Non-replaceable primary |		| E2 | Lifetime energy-limited | Non-replaceable primary |
	| | | battery |		| | | battery |
	| | | |		| | | |
	| E3 | No direct quantitative | Mains powered |		| E9 | No direct quantitative | Mains powered |
	| | limitations to available | |		| | limitations to available | |
	| | energy | |		| | energy | |
	+------+------------------------------+-----------------------------+		+------+------------------------------+-----------------------------+
	Table 3: Classes of Energy Limitation		Table 3: Classes of Energy Limitation
	4.3. Strategies of Using Power for Communication		4.3. Strategies of Using Power for Communication
	Especially when wireless transmission is used, the radio often		Especially when wireless transmission is used, the radio often
	consumes a big portion of the total energy consumed by the device.		consumes a big portion of the total energy consumed by the device.
	skipping to change at page 12, line 5		skipping to change at page 12, line 10
	The general strategies for power usage can be described as follows:		The general strategies for power usage can be described as follows:
	Always-on: This strategy is most applicable if there is no reason		Always-on: This strategy is most applicable if there is no reason
	for extreme measures for power saving. The device can stay on in		for extreme measures for power saving. The device can stay on in
	the usual manner all the time. It may be useful to employ power-		the usual manner all the time. It may be useful to employ power-
	friendly hardware or limit the number of wireless transmissions,		friendly hardware or limit the number of wireless transmissions,
	CPU speeds, and other aspects for general power saving and cooling		CPU speeds, and other aspects for general power saving and cooling
	needs, but the device can be connected to the network all the		needs, but the device can be connected to the network all the
	time.		time.
	Always-off: Under this strategy, the device sleeps such long periods		Normally-off: Under this strategy, the device sleeps such long
	at a time that once it wakes up, it makes sense for it to not		periods at a time that once it wakes up, it makes sense for it to
	pretend that it has been connected to the network during sleep:		not pretend that it has been connected to the network during
	The device re-attaches to the network as it is woken up. The main		sleep: The device re-attaches to the network as it is woken up.
	optimization goal is to minimize the effort during such re-		The main optimization goal is to minimize the effort during such
	attachment process and any resulting application communications.		re-attachment process and any resulting application
			communications.
	If the device sleeps for long periods of time, and needs to		If the device sleeps for long periods of time, and needs to
	communicate infrequently, the relative increase in energy		communicate infrequently, the relative increase in energy
	expenditure during reattachment may be acceptable.		expenditure during reattachment may be acceptable.
	Low-power: This strategy is most applicable to devices that need to		Low-power: This strategy is most applicable to devices that need to
	operate on a very small amount of power, but still need to be able		operate on a very small amount of power, but still need to be able
	to communicate on a relatively frequent basis. This implies that		to communicate on a relatively frequent basis. This implies that
	extremely low power solutions needs to be used for the hardware,		extremely low power solutions needs to be used for the hardware,
	chosen link layer mechanisms, and so on. Typically, given the		chosen link layer mechanisms, and so on. Typically, given the
	small amount of time between transmissions, despite their sleep		small amount of time between transmissions, despite their sleep
	state these devices retain some form of network attachment to the		state these devices retain some form of network attachment to the
	network. Techniques used for minimizing power usage for the		network. Techniques used for minimizing power usage for the
	network communications include minimizing any work from re-		network communications include minimizing any work from re-
	establishing communications after waking up, tuning the frequency		establishing communications after waking up, tuning the frequency
	of communications, and other parameters appropriately.		of communications (including "duty cycling", where components are
			switched on and off in a regular cycle), and other parameters
			appropriately.
	In summary, we distinguish (Table 4):		In summary, we distinguish (Table 4):
	+------+------------+----------------------------------------------+		+--------+--------------------+-------------------------------------+
	| Name | Strategy | Ability to communicate |		| Name | Strategy | Ability to communicate |
	+------+------------+----------------------------------------------+		+--------+--------------------+-------------------------------------+
	| S0 | Always-off | Re-attach when required |		| P0 | Normally-off | Re-attach when required |
	| | | |		| | | |
	| S1 | Low-power | Appears connected, perhaps with high latency |		| P1 | Low-power | Appears connected, perhaps with |
	| | | |		| | | high latency |
	| S2 | Always-on | Always connected |		| | | |
	+------+------------+----------------------------------------------+		| P9 | Always-on | Always connected |
			+--------+--------------------+-------------------------------------+
	Table 4: Strategies of Using Power for Communication		Table 4: Strategies of Using Power for Communication
	Note that the discussion above is at the device level; similar		Note that the discussion above is at the device level; similar
	considerations can apply at the communications interface level. This		considerations can apply at the communications interface level. This
	document does not define terminology for the latter.		document does not define terminology for the latter.
			A term often used to describe power-saving approaches is "duty-
			cycling". This describes all forms of periodically switching off
			some function, leaving it on only for a certain percentage of time
			(the "duty cycle").
			[I-D.ietf-roll-terminology] only distinguishes two levels, defining a
			Non-sleepy Node as a node that always remains in a fully powered on
			state (always awake) where it has the capability to perform
			communication (P9), and a Sleepy Node as a node that may sometimes go
			into a sleep mode (a low power state to conserve power) and
			temporarily suspend protocol communication (P0); there is no explicit
			mention of P1.
	5. Security Considerations		5. Security Considerations
	This document introduces common terminology that does not raise any		This document introduces common terminology that does not raise any
	new security issue. Security considerations arising from the		new security issue. Security considerations arising from the
	constraints discussed in this document need to be discussed in the		constraints discussed in this document need to be discussed in the
	context of specific protocols. For instance, [I-D.ietf-core-coap]		context of specific protocols. For instance, [I-D.ietf-core-coap]
	section 11.6, "Constrained node considerations", discusses		section 11.6, "Constrained node considerations", discusses
	implications of specific constraints on the security mechanisms		implications of specific constraints on the security mechanisms
	employed.		employed. A wider view at security in constrained node networks is
			provided in [I-D.garcia-core-security].
	6. IANA Considerations		6. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	7. Acknowledgements		7. Acknowledgements
	Dominique Barthel and Peter van der Stok provided useful comments;		Dominique Barthel and Peter van der Stok provided useful comments;
	Charles Palmer provided a full editorial review.		Charles Palmer provided a full editorial review.
	Peter van der Stok insisted that we should have power terminology,		Peter van der Stok insisted that we should have power terminology,
	hence Section 4. The text for Section 4.3 is mostly lifted from		hence Section 4. The text for Section 4.3 is mostly lifted from a
	[I-D.arkko-lwig-cellular] and has been adapted for this document.		previous version of [I-D.ietf-lwig-cellular] and has been adapted for
			this document.
	8. Informative References		8. Informative References
	[FALL] Fall, K., "A Delay-Tolerant Network Architecture for		[FALL] Fall, K., "A Delay-Tolerant Network Architecture for
	Challenged Internets", SIGCOMM 2003, 2003.		Challenged Internets", SIGCOMM 2003, 2003.
	[I-D.arkko-lwig-cellular]
	Arkko, J., Eriksson, A., and A. Keraenen, "Building Power-
	Efficient CoAP Devices for Cellular Networks", draft-
	arkko-lwig-cellular-00 (work in progress), February 2013.
	[I-D.brandt-6man-lowpanz]		[I-D.brandt-6man-lowpanz]
	Brandt, A. and J. Buron, "Transmission of IPv6 packets		Brandt, A. and J. Buron, "Transmission of IPv6 packets
	over ITU-T G.9959 Networks", draft-brandt-6man-lowpanz-02		over ITU-T G.9959 Networks", draft-brandt-6man-lowpanz-02
	(work in progress), June 2013.		(work in progress), June 2013.
	[I-D.clausen-lln-rpl-experiences]		[I-D.garcia-core-security]
	Clausen, T., Verdiere, A., Yi, J., Herberg, U., and Y.		Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and
	Igarashi, "Observations of RPL: IPv6 Routing Protocol for		R. Struik, "Security Considerations in the IP-based
	Low power and Lossy Networks", draft-clausen-lln-rpl-		Internet of Things", draft-garcia-core-security-06 (work
	experiences-06 (work in progress), February 2013.		in progress), September 2013.
	[I-D.hui-vasseur-roll-rpl-deployment]		[I-D.hui-vasseur-roll-rpl-deployment]
	Vasseur, J., Hui, J., Dasgupta, S., and G. Yoon, "RPL		Vasseur, J., Hui, J., Dasgupta, S., and G. Yoon, "RPL
	deployment experience in large scale networks", draft-hui-		deployment experience in large scale networks", draft-hui-
	vasseur-roll-rpl-deployment-01 (work in progress), July		vasseur-roll-rpl-deployment-01 (work in progress), July
	2012.		2012.
	[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-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-lwig-cellular]
			Arkko, J., Eriksson, A., and A. Keranen, "Building Power-
			Efficient CoAP Devices for Cellular Networks", draft-ietf-
			lwig-cellular-00 (work in progress), August 2013.
	[I-D.ietf-roll-terminology]		[I-D.ietf-roll-terminology]
	Vasseur, J., "Terminology in Low power And Lossy		Vasseur, J., "Terms used in Routing for Low power And
	Networks", draft-ietf-roll-terminology-12 (work in		Lossy Networks", draft-ietf-roll-terminology-13 (work in
	progress), March 2013.		progress), October 2013.
	[I-D.mariager-6lowpan-v6over-dect-ule]		[I-D.mariager-6lowpan-v6over-dect-ule]
	Mariager, P. and J. Petersen, "Transmission of IPv6		Mariager, P., Petersen, J., and Z. Shelby, "Transmission
	Packets over DECT Ultra Low Energy", draft-mariager-		of IPv6 Packets over DECT Ultra Low Energy", draft-
	6lowpan-v6over-dect-ule-02 (work in progress), May 2012.		mariager-6lowpan-v6over-dect-ule-03 (work in progress),
			July 2013.
	[ISQ-13] International Electrotechnical Commission, "International		[ISQ-13] International Electrotechnical Commission, "International
	Standard -- Quantities and units -- Part 13: Information		Standard -- Quantities and units -- Part 13: Information
	science and technology", IEC 80000-13, March 2008.		science and technology", IEC 80000-13, March 2008.
	[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC		[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
	793, September 1981.		793, September 1981.
	[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,		[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
	R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant		R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
	skipping to change at page 15, line 7		skipping to change at page 16, line 7
	[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D.		[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D.
	Barthel, "Routing Metrics Used for Path Calculation in		Barthel, "Routing Metrics Used for Path Calculation in
	Low-Power and Lossy Networks", RFC 6551, March 2012.		Low-Power and Lossy Networks", RFC 6551, March 2012.
	[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem		[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
	Statement and Requirements for IPv6 over Low-Power		Statement and Requirements for IPv6 over Low-Power
	Wireless Personal Area Network (6LoWPAN) Routing", RFC		Wireless Personal Area Network (6LoWPAN) Routing", RFC
	6606, May 2012.		6606, May 2012.
			[RFC6650] Falk, J. and M. Kucherawy, "Creation and Use of Email
			Feedback Reports: An Applicability Statement for the Abuse
			Reporting Format (ARF)", RFC 6650, June 2012.
	[WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded		[WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded
	Internet", ISBN 9780470747995, 2009.		Internet", ISBN 9780470747995, 2009.
	[fifty-billion]		[fifty-billion]
	Ericsson, "More Than 50 Billion Connected Devices",		Ericsson, "More Than 50 Billion Connected Devices",
	Ericsson White Paper 284 23-3149 Uen, February 2011,		Ericsson White Paper 284 23-3149 Uen, February 2011,
	<http://www.ericsson.com/res/docs/whitepapers/		<http://www.ericsson.com/res/docs/whitepapers/
	wp-50-billions.pdf>.		wp-50-billions.pdf>.
	Authors' Addresses		Authors' Addresses
End of changes. 42 change blocks.
	128 lines changed or deleted		180 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/