LWIG Working Group C. Bormann
Internet-Draft Universitaet Bremen TZI
Intended status: Informational M. Ersue
Expires: June 21, 2014 Nokia Siemens Networks
A. Keranen
Ericsson
December 18, 2013
Terminology for Constrained Node Networksdraft-ietf-lwig-terminology-06
Abstract
The Internet Protocol Suite is increasingly used on small devices
with severe constraints on power, memory and processing resources,
creating constrained node networks. This document provides a number
of basic terms that have turned out to be useful in the
standardization work for constrained node networks.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 21, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Bormann, et al. Expires June 21, 2014 [Page 1]

Internet-Draft CNN terminology December 2013
Today diverse sizes of constrained devices with different resources
and capabilities are becoming connected. Mobile personal gadgets,
building-automation devices, cellular phones, Machine-to-machine
(M2M) devices, etc. benefit from interacting with other "things"
nearby or somewhere in the Internet. With this, the Internet of
Things (IoT) becomes a reality, built up out of uniquely identifiable
and addressable objects (things). And over the next decade, this
could grow to large numbers [fifty-billion] of Internet-connected
constrained devices, greatly increasing the Internet's size and
scope.
The present document provides a number of basic terms that have
turned out to be useful in the standardization work for constrained
environments. The intention is not to exhaustively cover the field,
but to make sure a few core terms are used consistently between
different groups cooperating in this space.
In this document, the term "byte" is used in its now customary sense
as a synonym for "octet". Where sizes of semiconductor memory are
given, the prefix "kibi" (1024) is combined with "byte" to
"kibibyte", abbreviated "KiB", for 1024 bytes [ISQ-13].
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.
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]
of inexpensive nodes, while
o scaling down the characteristics of each of these nodes and of the
networks being built out of them, to make this scaling up
economically and physically viable.
The need for scaling down the characteristics of nodes leads to
_constrained nodes_.
Bormann, et al. Expires June 21, 2014 [Page 3]

Internet-Draft CNN terminology December 20132.1. Constrained Nodes
The term "constrained node" is best defined by contrasting the
characteristics of a constrained node with certain widely held
expectations on more familiar Internet nodes:
Constrained Node: A node where some of the characteristics that are
otherwise pretty much taken for granted for Internet nodes at the
time of writing are not attainable, often due to cost constraints
and/or physical constraints on characteristics such as size,
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 not a rigorous definition, it is grounded in the state
of the art and clearly sets apart constrained nodes from server
systems, desktop or laptop computers, powerful mobile devices such as
smartphones etc. There may be many design considerations that lead
to these constraints, including cost, size, weight, and other scaling
factors.
(An alternative name, when the properties as a network node are not
in focus, is "constrained device".)
There are multiple facets to the constraints on nodes, often applying
in combination, e.g.:
o constraints on the maximum code complexity (ROM/Flash);
o constraints on the size of state and buffers (RAM);
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.).
Bormann, et al. Expires June 21, 2014 [Page 4]

Internet-Draft CNN terminology December 2013Section 3 defines a small number of interesting classes ("class-N"
for N=0,1,2) of constrained nodes focusing on relevant combinations
of the first two constraints. With respect to available (electrical)
power, [RFC6606] distinguishes "power-affluent" nodes (mains-powered
or regularly recharged) from "power-constrained nodes" that draw
their power from primary batteries or by using energy harvesting;
more detailed power terminology is given in Section 4.
The use of constrained nodes in networks often also leads to
constraints on the networks themselves. However, there may also be
constraints on networks that are largely independent from those of
the nodes. We therefore distinguish _constrained networks_ and
_constrained node networks_.
2.2. Constrained Networks
We define "constrained network" in a similar way:
Constrained Network: A network where some of the characteristics
pretty much taken for granted with link layers in common use in
the Internet at the time of writing, are not attainable.
Again, there may be several reasons for this:
o cost constraints on the network,
o constraints of the nodes (for constrained node networks),
o physical constraints (e.g., power constraints, environmental
constraints, media constraints such as underwater operation,
limited spectrum for very high density, electromagnetic
compatibility),
o regulatory constraints, such as very limited spectrum availability
(including limits on effective radiated power and duty cycle), or
explosion safety,
o technology constraints, such as older and lower speed technologies
that are still operational and may need to stay in use for some
more time.
Constraints may include:
o low achievable bit rate (including limits on duty cycle),
o high packet loss, packet loss (delivery rate) variability,
o highly asymmetric link characteristics,
Bormann, et al. Expires June 21, 2014 [Page 5]

Internet-Draft CNN terminology December 2013
o severe penalties for using larger packets (e.g., high packet loss
due to link layer fragmentation),
o lack of (or severe constraints on) advanced services such as IP
multicast.
2.2.1. Challenged Networks
A constrained network is not necessarily a _challenged_ network
[FALL]:
Challenged Network: A network that has serious trouble maintaining
what an application would today expect of the end-to-end IP model,
e.g., by:
o not being able to offer end-to-end IP connectivity at all;
o exhibiting serious interruptions in end-to-end IP connectivity;
o exhibiting delay well beyond the Maximum Segment Lifetime (MSL)
defined by TCP [RFC0793].
All challenged networks are constrained networks in some sense, but
not all constrained networks are challenged networks. There is no
well-defined boundary between the two, though. Delay-Tolerant
Networking (DTN) has been designed to cope with challenged networks
[RFC4838].
2.3. Constrained Node Networks
Constrained Node Network: A network whose characteristics are
influenced by being composed of a significant portion of
constrained nodes.
A constrained node network always is a constrained network because of
the network constraints stemming from the node constraints, but may
also have other constraints that already make it a constrained
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.
Bormann, et al. Expires June 21, 2014 [Page 6]

Internet-Draft CNN terminology December 20132.3.1. LLN ("low-power lossy network")
A related term that has been used to describe the focus of the IETF
working group on Routing Over Low power and Lossy networks (ROLL) is
"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
many embedded devices with limited power, memory, and processing
resources interconnected by a variety of links, such as IEEE
802.15.4 or Low Power WiFi. There is a wide scope of application
areas for LLNs, including industrial monitoring, building
automation (HVAC, lighting, access control, fire), connected home,
healthcare, environmental monitoring, urban sensor networks,
energy management, assets tracking and refrigeration.. [sic]
Beyond that, LLNs often exhibit considerable loss at the physical
layer, with significant variability of the delivery rate, and some
short-term unreliability, coupled with some medium term stability
that makes it worthwhile to construct medium-term stable directed
acyclic graphs for routing and do measurements on the edges such as
ETX [RFC6551]. Actual "low power" does not seem to be a defining
characteristic for an LLN [I-D.hui-vasseur-roll-rpl-deployment].
LLNs typically are composed of constrained nodes; this leads to the
design of operation modes such as the "non-storing mode" defined by
RPL (the IPv6 Routing Protocol for Low-Power and Lossy Networks
[RFC6650]). So, in the terminology of the present document, an LLN
is a constrained node network with certain network characteristics,
which include constraints on the network as well.
2.3.2. LoWPAN, 6LoWPAN
One interesting class of a constrained network often used as a
constrained node network is the "LoWPAN" [RFC4919], a term inspired
from the name of the IEEE 802.15.4 working group (low-rate wireless
personal area networks (LR-WPANs)). The expansion of that acronym,
"Low-Power Wireless Personal Area Network" contains a hard to justify
"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
person. Actually, LoWPANs have been suggested for urban monitoring,
control of large buildings, and industrial control applications, so
the "Personal" can only be considered a vestige. Occasionally the
term is read as "Low-Power Wireless Area Networks" (LoWPANs) [WEI].
Originally focused on IEEE 802.15.4, "LoWPAN" (or when used for IPv6,
"6LoWPAN") also refers to networks built from similarly constrained
link layer technologies [I-D.ietf-6lowpan-btle]
[I-D.mariager-6lowpan-v6over-dect-ule] [I-D.brandt-6man-lowpanz].
Bormann, et al. Expires June 21, 2014 [Page 7]

Internet-Draft CNN terminology December 20133. Classes of Constrained Devices
Despite the overwhelming variety of Internet-connected devices that
can be envisioned, it may be worthwhile to have some succinct
terminology for different classes of constrained devices. In this
document, the class designations in Table 1 may be used as rough
indications of device capabilities:
+-------------+-----------------------+-------------------------+
| Name | data size (e.g., RAM) | code size (e.g., Flash) |
+-------------+-----------------------+-------------------------+
| Class 0, C0 | << 10 KiB | << 100 KiB |
| | | |
| Class 1, C1 | ~ 10 KiB | ~ 100 KiB |
| | | |
| Class 2, C2 | ~ 50 KiB | ~ 250 KiB |
+-------------+-----------------------+-------------------------+
Table 1: Classes of Constrained Devices (KiB = 1024 bytes)
As of the writing of this document, these characteristics correspond
to distinguishable clusters of commercially available chips and
design cores for constrained devices. While it is expected that the
boundaries of these classes will move over time, Moore's law tends to
be less effective in the embedded space than in personal computing
devices: Gains made available by increases in transistor count and
density are more likely to be invested in reductions of cost and
power requirements than into continual increases in computing power.
Class 0 devices are very constrained sensor-like motes. Most likely
they will not be able to communicate directly with the Internet in a
secure manner. Class 0 devices will participate in Internet
communications with the help of larger devices acting as proxies,
gateways or servers. Class 0 devices generally cannot be secured or
managed comprehensively in the traditional sense. They will most
likely be preconfigured (and will be reconfigured rarely, if at all),
with a very small data set. For management purposes, they could
answer keepalive signals and send on/off or basic health indications.
Class 1 devices cannot easily talk to other Internet nodes employing
a full protocol stack such as using HTTP, TLS and related security
protocols and XML-based data representations. However, they have
enough power to use a protocol stack specifically designed for
constrained nodes (such as CoAP over UDP [I-D.ietf-core-coap]) and
participate in meaningful conversations without the help of a gateway
node. In particular, they can provide support for the security
functions required on a large network. Therefore, they can be
integrated as fully developed peers into an IP network, but they need
Bormann, et al. Expires June 21, 2014 [Page 8]

Internet-Draft CNN terminology December 2013
to be parsimonious with state memory, code space, and often power
expenditure for protocol and application usage.
Class 2 can already support mostly the same protocol stacks as used
on notebooks or servers. However, even these devices can benefit
from lightweight and energy-efficient protocols and from consuming
less bandwidth. Furthermore, using fewer resources for networking
leaves more resources available to applications. Thus, using the
protocol stacks defined for very constrained devices also on Class 2
devices might reduce development costs and increase the
interoperability.
Constrained devices with capabilities significantly beyond Class 2
devices exist. They are less demanding from a standards development
point of view as they can largely use existing protocols unchanged.
The present document therefore does not make any attempt to define
classes beyond Class 2. These devices can still be constrained by a
limited energy supply.
With respect to examining the capabilities of constrained nodes,
particularly for Class 1 devices, it is important to understand what
type of applications they are able to run and which protocol
mechanisms would be most suitable. Because of memory and other
limitations, each specific Class 1 device might be able to support
only a few selected functions needed for its intended operation. In
other words, the set of functions that can actually be supported is
not static per device type: devices with similar constraints might
choose to support different functions. Even though Class 2 devices
have some more functionality available and may be able to provide a
more complete set of functions, they still need to be assessed for
the type of applications they will be running and the protocol
functions they would need. To be able to derive any requirements,
the use cases and the involvement of the devices in the application
and the operational scenario need to be analyzed. Use cases may
combine constrained devices of multiple classes as well as more
traditional Internet nodes.
Bormann, et al. Expires June 21, 2014 [Page 9]

Internet-Draft CNN terminology December 20134. Power Terminology
Devices not only differ in their computing capabilities, but also in
available electrical power and/or energy. While it is harder to find
recognizable clusters in this space, it is still useful to introduce
some common terminology.
4.1. Scaling Properties
The power and/or energy available to a device may vastly differ, from
kilowatts to microwatts, from essentially unlimited to hundreds of
microjoules.
Instead of defining classes or clusters, we simply state, in SI
units, an approximate value for one or both of the quantities listed
in Table 2:
+--------+---------------------------------------------+------------+
| Name | Definition | SI Unit |
+--------+---------------------------------------------+------------+
| Ps | Sustainable average power available for the | W (Watt) |
| | device over the time it is functioning | |
| | | |
| Et | Total electrical energy available before | J (Joule) |
| | the energy source is exhausted | |
+--------+---------------------------------------------+------------+
Table 2: Quantities Relevant to Power and Energy
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
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
As discussed above, some devices are limited in available energy as
opposed to (or in addition to) being limited in available power.
Where no relevant limitations exist with respect to energy, the
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
with a non-replaceable primary battery, which is discarded when this
battery is exhausted), classified as E2. Where the relevant
limitation is for a specific period, this is classified as E1, e.g. a
Bormann, et al. Expires June 21, 2014 [Page 10]

Internet-Draft CNN terminology December 2013
limited amount of energy available for the night with a solar-powered
device, or for the period between recharges with a device that is
manually connected to a charger, or by a periodic (primary) battery
replacement interval. Finally, there may be a limited amount of
energy available for a specific event, e.g. for a button press in an
energy harvesting light switch; this is classified as E0. Note that
many E1 devices in a sense also are E2, as the rechargeable battery
has a limited number of useful recharging cycles.
In summary, we distinguish (Table 3):
+------+------------------------------+-----------------------------+
| Name | Type of energy limitation | Example Power Source |
+------+------------------------------+-----------------------------+
| E0 | Event energy-limited | Event-based harvesting |
| | | |
| E1 | Period energy-limited | Battery that is |
| | | periodically recharged or |
| | | replaced |
| | | |
| E2 | Lifetime energy-limited | Non-replaceable primary |
| | | battery |
| | | |
| E9 | No direct quantitative | Mains powered |
| | limitations to available | |
| | energy | |
+------+------------------------------+-----------------------------+
Table 3: Classes of Energy Limitation
4.3. Strategies of Using Power for Communication
Especially when wireless transmission is used, the radio often
consumes a big portion of the total energy consumed by the device.
Design parameters such as the available spectrum, the desired range,
and the bitrate aimed for, influence the power consumed during
transmission and reception; the duration of transmission and
reception (including potential reception) influence the total energy
consumption.
Based on the type of the energy source (e.g., battery or mains power)
and how often device needs to communicate, it may use different kinds
of strategies for power usage and network attachment.
The general strategies for power usage can be described as follows:
Always-on: This strategy is most applicable if there is no reason
for extreme measures for power saving. The device can stay on in
Bormann, et al. Expires June 21, 2014 [Page 11]

Internet-Draft CNN terminology December 2013
the usual manner all the time. It may be useful to employ power-
friendly hardware or limit the number of wireless transmissions,
CPU speeds, and other aspects for general power saving and cooling
needs, but the device can be connected to the network all the
time.
Normally-off: Under this strategy, the device sleeps such long
periods at a time that once it wakes up, it makes sense for it to
not pretend that it has been connected to the network during
sleep: The device re-attaches to the network as it is woken up.
The main optimization goal is to minimize the effort during such
re-attachment process and any resulting application
communications.
If the device sleeps for long periods of time, and needs to
communicate infrequently, the relative increase in energy
expenditure during reattachment may be acceptable.
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
to communicate on a relatively frequent basis. This implies that
extremely low power solutions needs to be used for the hardware,
chosen link layer mechanisms, and so on. Typically, given the
small amount of time between transmissions, despite their sleep
state these devices retain some form of network attachment to the
network. Techniques used for minimizing power usage for the
network communications include minimizing any work from re-
establishing communications after waking up, tuning the frequency
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):
+--------+--------------------+-------------------------------------+
| Name | Strategy | Ability to communicate |
+--------+--------------------+-------------------------------------+
| P0 | Normally-off | Re-attach when required |
| | | |
| P1 | Low-power | Appears connected, perhaps with |
| | | high latency |
| | | |
| P9 | Always-on | Always connected |
+--------+--------------------+-------------------------------------+
Table 4: Strategies of Using Power for Communication
Bormann, et al. Expires June 21, 2014 [Page 12]

Internet-Draft CNN terminology December 2013
Note that the discussion above is at the device level; similar
considerations can apply at the communications interface level. This
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.
Bormann, et al. Expires June 21, 2014 [Page 13]