Terminology for Constrained-Node Networks
Universitaet Bremen TZI
Postfach 330440
Bremen
D-28359
Germany
+49-421-218-63921
cabo@tzi.org
mersue@gmail.com
Ericsson
Hirsalantie 11
Jorvas
02420
Finland
ari.keranen@ericsson.com
UPC/i2CAT
Escola d'Enginyeria de Telecomunicacio i Aeroespacial de Castelldefels C/Esteve Terradas, 7
Castelldefels
08860
Spain
+34-93-413-7206
carlesgo@entel.upc.edu
Internet
LWIG Working Group
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
been useful in the standardization work for constrained-node networks.
Introduction
Small devices with limited CPU, memory, and power resources, so-called
"constrained devices" (often used as sensors/actuators, smart objects,
or smart devices) can
form a network, becoming "constrained nodes" in that network.
Such a network may itself exhibit constraints, e.g., with unreliable or
lossy channels, limited and unpredictable bandwidth, and a highly
dynamic topology.
Constrained devices might be in charge of gathering information in
diverse settings, including natural ecosystems, buildings, and
factories, and sending the information to one or more server stations.
They might also act on information, by performing some
physical action, including displaying it.
Constrained devices may work under severe resource constraints such
as limited battery and computing power, little memory, and
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, might have more computational and communication resources and
could support the interaction between the constrained devices and
applications in more traditional networks.
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, and other devices 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). Over the next decade, this could
grow to large numbers of Internet-connected constrained
devices ( predicts that by, 2025, more than
2500 devices will be connected to the Internet per second), greatly
increasing the Internet's size and scope.
The present document provides a number of basic terms that have
been 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.
The present document is a revision of .
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 .
Powers of 10 are given as 10100 where 100 is the exponent.
In computing, the term "power" is often used for the concept of
"computing power" or "processing power", as in CPU performance.
In this document, the term stands
for electrical power unless explicitly stated otherwise. "Mains-powered"
is used as a shorthand for
being permanently connected to a stable electrical power grid.
Core Terminology
There are two important aspects to scaling within the Internet of Things:
scaling up Internet technologies to a large number of
inexpensive nodes, while
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".
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 term, 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, for example:
constraints on the maximum code complexity (ROM/Flash),
constraints on the size of state and buffers (RAM),
constraints on the amount of computation feasible in a period of
time ("processing power"),
constraints on the available power, and
constraints on user interface and accessibility in deployment
(ability to set keys, update software, etc.).
defines a number of interesting classes ("class-N") of
constrained nodes focusing on relevant combinations of
the first two constraints.
With respect to available power, 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 .
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" from
"constrained-node networks".
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.
Constraints may include:
low achievable bitrate/throughput (including limits on duty cycle),
high packet loss and high variability of packet loss (delivery rate),
highly asymmetric link characteristics,
severe penalties for using larger packets (e.g., high packet loss
due to link-layer fragmentation),
limits on reachability over time (a substantial number of devices
may power off at any point in time but periodically "wake up" and
can communicate for brief periods of time), and
lack of (or severe constraints on) advanced services such as IP multicast.
More generally, we speak of constrained networks whenever at least
some of the nodes involved in the network exhibit these
characteristics.
Again, there may be several reasons for this:
cost constraints on the network,
constraints posed by the nodes (for constrained-node networks),
physical constraints (e.g., power constraints, environmental
constraints, media constraints
such as underwater operation, limited spectrum for very high
density, electromagnetic compatibility),
regulatory constraints, such as very limited spectrum availability
(including limits on effective radiated power and duty cycle) or
explosion safety, and
technology constraints, such as older and lower-speed technologies that
are still operational and may need to stay in use for some more time.
Challenged Networks
A constrained network is not necessarily a "challenged network" :
-
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:
not being able to offer end-to-end IP connectivity at all,
exhibiting serious interruptions in end-to-end IP connectivity, or
exhibiting delay well beyond the Maximum Segment Lifetime (MSL)
defined by TCP .
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 .
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 it 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.
LLN
A related term that has been used to describe the focus of the IETF
ROLL working group is
"Low-Power and Lossy Network (LLN)". The ROLL (Routing Over Low-Power and
Lossy) terminology document defines LLNs as follows:
-
LLN: Low-Power and Lossy Network. 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 Wi-Fi. There is a wide scope of application
areas for LLNs, including industrial monitoring, building
automation (heating,
ventilation, and air conditioning (HVAC), lighting, access control, fire),
connected home,
health care, environmental monitoring, urban sensor networks,
energy management, assets tracking, and refrigeration.
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 both construct directed acyclic graphs
that are medium-term stable for routing and do measurements on the edges
such as Expected Transmission Count (ETX) . Not all LLNs comprise low-power nodes .
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 ). 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.
LoWPAN, 6LoWPAN
One interesting class of a constrained network often used as a
constrained-node network is "LoWPAN" , a term inspired
from the name of an IEEE 802.15.4 working group (low-rate wireless
personal area networks (LR-WPANs)). The expansion of the LoWPAN 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" . 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 .
LPWAN
An overview over Low-Power Wide Area Network (LPWAN) technologies is
provided by .
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.
Before we get to that, let's first distinguish two big rough groups of
devices based on their CPU capabilities:
Microcontroller-class devices (sometimes called "M-class").
These often (but not always) include RAM and code storage on chip
and would struggle to support more powerful general-purpose operating systems, e.g.,
they do not have an MMU (memory management unit). They use most of
their pins for interfaces to application hardware such as digital
in/out (the latter often Pulse Width Modulation (PWM)-controllable),
ADC/DACs (analog-to-digital and digital-to-analog converters), etc.
Where this hardware is specialized for an application, we may talk
about "Systems on a Chip" (SOC). These devices often implement
elaborate sleep modes to achieve microwatt- or at least
milliwatt-level sustained power usage (Ps, see below).
General-purpose-class devices (sometimes called "A-class"). These usually
have RAM and Flash storage on separate chips (not always separate
packages), and offer support for general-purpose operating systems
such as Linux, e.g. an MMU. Many of the pins on the CPU chip are
dedicated to interfacing with RAM and other memory. Some
general-purpose-class devices integrate some application hardware
such as video controllers, these are often also called "Systems on a
Chip" (SOC). While these chips also include sleep modes, they are
usually more on the watt side of sustained power usage (Ps).
If the distinction between these groups needs to be made in this
document, we distinguish group "M" (microcontroller) from group "J"
(general purpose).
In this document, the class designations in may be
used as rough indications of device capabilities. Note that the
classes from 10 upwards are not really constrained devices in the
sense of the previous section; they may still be useful to discuss
constraints in larger devices:
Group
Name
data size (e.g., RAM)
code size (e.g., Flash)
Examples
M
Class 0, C0
<< 10 KiB
<< 100 KiB
ATtiny
M
Class 1, C1
~ 10 KiB
~ 100 KiB
STM32F103CB
M
Class 2, C2
~ 50 KiB
~ 250 KiB
STM32F103RC
M
Class 3, C3
~ 100 KiB
~ 500..1000 KiB
STM32F103RG
M
Class 4, C4
~ 300..1000 KiB
~ 1000..2000 KiB
"Luxury"
J
Class 10, C10
4-8 MiB
(?)
OpenWRT routers
J
Class 15, C15
0.5..1 GiB
(lots)
Raspberry PI
J
Class 16, C16
1..4 GiB
(lots)
Smartphones
J
Class 17, C17
4..32 GiB
(lots)
Laptops
J
Class 19, C19
(lots)
(lots)
Servers
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. They are so
severely constrained in memory and processing capabilities that most
likely they will not have the resources required to communicate
directly with the Internet in a secure manner (rare heroic, narrowly
targeted implementation efforts
notwithstanding). 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 are quite constrained in code space and processing
capabilities, such that they
cannot easily talk to other Internet nodes employing a
full protocol stack such as using HTTP, Transport Layer Security (TLS), and
related security
protocols and XML-based data representations.
However, they are capable enough to
use a protocol stack specifically designed for
constrained nodes (such as the Constrained Application Protocol (CoAP) over
UDP ) 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 to be parsimonious with state
memory, code space, and often power expenditure for protocol and
application usage.
Class 2 devices are less constrained and fundamentally capable of
supporting most of 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 more constrained devices 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 previous version of the present document therefore did not make
any attempt to define constrained classes beyond Class 2. These
devices, and to a certain extent even J-group devices, can still be
constrained by a limited energy supply. Class 3 and 4 devices are
less clearly defined than the lower classes; they are even less
constrained. In particular Class 4 devices are powerful enough to
quite comfortably run, e.g., JavaScript interpreters, together with
elaborate network stacks. Additional classes
may need to be defined based on protection capabilities, e.g., an MPU
(memory protection unit; true MMUs are typically only found in J-group
devices).
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.
Firmware/Software upgradeability
Platforms may differ in their firmware or software upgradeability.
The below is a first attempt at classifying this.
Name
Firmware/Software upgradeability
F0
no (discard for upgrade)
F1
replaceable, out of service during replacement, reboot
F2
patchable during operation, reboot required
F3
patchable during operation, restart not visible externally
F9
app-level upgradeability, no reboot required ("hitless")
Isolation functionality
TBD. This section could discuss the ability of the platform to
isolate different components. The categories below are not mutually
exclusive; we need to build relevant clusters.
Name
Isolation functionality
Is0
no isolation
Is2
MPU (memory protection unit), at least boundary registers
Is5
MMU with Linux-style kernel/user
Is7
Virtualization-style isolation
Is8
Secure enclave isolation
Shielded secrets
[Need to identify clusters]
Some platforms can keep shielded secrets (usually in conjunction with
secure enclave functionality).
Name
Secret shielding functionality
Sh0
no secret shielding
Sh1
some secret shielding
Sh9
perfect secret shielding
Power Terminology
Devices not only differ in their computing capabilities but also in
available power and/or energy. While it is harder to find
recognizable clusters in this space, it is still useful to introduce
some common terminology.
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, using
the International System of Units (SI units), an approximate value for one
or both of the quantities
listed in :
Name
Definition
SI Unit
Ps
Sustainable average power available for the device over the time it is functioning
W (Watt)
Et
Total electrical energy available before the energy source is exhausted
J (Joule)
The value of Et may need to be interpreted in conjunction with an
indication over which period of time the value is given; see .
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.
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 that is discarded when its
non-replaceable primary battery is exhausted),
classified as E2.
Where the relevant limitation is for a specific period, the device is
classified as E1, e.g.,
a solar-powered device with a limited amount of
energy available for the night, a device that is manually connected to a
charger and has a period of time between recharges, or a device with 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;
such devices are classified as E0.
Note that, in a sense, many E1 devices are also E2, as the rechargeable
battery has a limited number of useful recharging cycles.
provides a summary of the classifications
described above.
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 limitations to available energy
Mains-powered
Strategies for 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.
Different
strategies for power usage and network attachment may be used, based on the
type of the energy source (e.g., battery or mains-powered)
and the frequency with which a device needs to communicate.
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 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 reattaches
to the network as it is woken up. The main optimization goal is to
minimize the effort during the reattachment 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 need 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 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 and tuning the frequency of communications (including "duty cycling",
where components are switched on and off in a regular cycle) and other parameters
appropriately.
provides a summary of the strategies
described above.
Name
Strategy
Ability to communicate
P0
Normally-off
Reattach when required
P1
Low-power
Appears connected, perhaps with high latency
P9
Always-on
Always connected
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").
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.
Strategies of Keeping Time over Power Events
[This subsection is very drafty.]
Many applications for a device require it to keep some concept of time.
Time-keeping can be relative to a previous event (last packet received),
absolute on a device-specific scale (e.g., last reboot), or absolute
on a world-wide scale ("wall-clock time").
Some devices lose the concept of time when going to sleep: after
wakeup, they don't know how long they slept. Some others do keep some
concept of time during sleep, but not precise enough to use as a basis
for keeping absolute time. Some devices have a continuously running
source of a reasonably accurate time (often a 32,768 Hz watch crystal).
Finally, some devices can keep their concept of time even during a
battery change, e.g., by using a backup battery or a supercapacitor to
power the real-time clock (RTC).
The actual accuracy of time may vary, with errors ranging from tens of
percent from on-chip RC oscillators (not useful for keeping absolute
time, but still useful for, e.g., timing out some state) to
approximately 10-4 to 10-5 ("watch crystal") of error. More precise
timing is available with temperature compensated crystal oscillators
(TCXO). Further improvement requires significantly higher power
usage, bulk, fragility, and device cost, e.g. oven-controlled crystal
oscillators (OCXO) can reach 10-8 accuracy, and Rubidium frequency sources can
reach 10-11 over the short term and 10-9 over the long term.
A device may need to fire up a more accurate frequency source during
wireless communication, this may also allow it to keep more precise
time during the period.
The various time sources available on the device can be assisted by
external time input, e.g. via the network using the NTP protocol
. Information from measuring the deviation between external
input and local time source can be used to increase the accuracy of
maintaining time even during periods of no network use.
Errors of the frequency source can be compensated if known (calibrated
against a known better source, or even predicted, e.g., in a software
TCXO). Even with errors partially compensated, an uncertainty
remains, which is the more fundamental characteristic to discuss.
Battery solutions may allow the device to keep a wall-clock time
during its entire life, or the wall-clock time may need to be reset
after a battery change. Even devices that have a battery lasting for
their lifetime may not be set to wall-clock time at manufacture time,
possibly because the battery is only activated at installation time
where time sources may be questionable or because setting the clock
during manufacture is deemed too much effort.
Devices that keep a good approximation of wall-clock time during their
life may be in a better position to securely validate external time
inputs than devices that need to be reset episodically, which can
possibly be tricked by their environment into accepting a long-past
time, for instance with the intent of exploiting expired security
assertions such as certificates.
From a practical point of view, devices can be divided at least on the
two dimensions proposed in and
. Corrections to the local time of a device
performed over the network can be used to improve the uncertainty
exhibited by these basic device classes.
Name
Type
Uncertainty (roughly)
T0
no concept of time
infinite
T1
relative time while awake
(usually high)
T2
relative time
(usually high during sleep)
T3
relative time
10-4 or better
T5
absolute time (e.g., since boot)
10-4 or better
T7
wall-clock time
10-4 or better
T8
wall-clock time
10-5 or better
T9
wall-clock time
10-6 or better (TCXO)
T10
wall-clock time
10-7 or better (OCXO or Rb)
Name
Permanency (from type T5 upwards):
Uncertainty
TP0
time needs to be reset on certain occasions
TP1
time needs to be set during installation
(possibly reduced...
TP9
reliable time is maintained during lifetime
...by using external input)
Classes of Networks
Classes of link layer MTU size
Link layer technologies used by constrained devices can be categorized
on the basis of link layer MTU size. Depending on this parameter, the
fragmentation techniques needed (if any) to support the IPv6 MTU
requirement may vary.
We define the following classes of link layer MTU size:
Name
L2 MTU size (bytes)
6LoWPAN Fragmentation applicable*?
S0
3 - 12
need new kind of fragmentation
S1
13 - 127
yes
S2
128 - 1279
yes
S3
>= 1280
no fragmentation needed
* if no link layer fragmentation is available
(note: 'Sx' stands for 'Size x')
S0 technologies require fragmentation to support the IPv6 MTU requirement.
If no link layer fragmentation is available, fragmentation is needed at
the adaptation layer below IPv6. However, 6LoWPAN fragmentation
cannot be used for these technologies, given the extremely reduced link
layer MTU. In this case, lightweight fragmentation formats must be used
(e.g. ).
S1 and S2 technologies require fragmentation at the subnetwork level to
support the IPv6 MTU requirement.
If link layer fragmentation is unavailable or insufficient,
fragmentation is needed at the adaptation layer below IPv6.
6LoWPAN fragmentation can be used to carry 1280-byte IPv6
packets over these technologies.
S3 technologies do not require fragmentation to support the IPv6 MTU
requirement.
Class of Internet Integration
The term "Internet of Things" is sometimes confusingly used for
connected devices that are not actually employing Internet technology.
Some devices do use Internet technology, but only use it to exchange
packets with a fixed communication partner ("device-to-cloud"
scenarios, ). More general devices are prepared to
communicate with other nodes in the Internet as well.
We define the following classes of Internet technology level:
Name
Internet technology
I0
none (local interconnect only)
I1
device-to-cloud only
I9
full Internet connectivity supported
Classes of physical layer bit rate
[This section is a trial balloon. We could also talk about
burst rate, sustained rate; bits/s, messages/s, ...]
Physical layer technologies used by constrained devices can be
categorized on the basis of physical layer (PHY) bit rate. The PHY bit
rate class of a technology has important implications with regard to
compatibility with existing protocols and mechanisms on the Internet,
responsiveness to frame transmissions and need for header compression
techniques.
We define the following classes of PHY bit rate:
Name
PHY bit rate (bit/s)
Comment
B0
< 10
Transmission time of 150-byte frame > MSL
B1
10 -- 10^3
Unresponsiveness if human expects reaction to sent frame (frame size > 62.5 byte)
B2
10^3 -- 10^6
Responsiveness if human expects reaction to sent frame, but header compression still needed
B3
> 10^6
Header compression yields relatively low performance benefits
(note: 'Bx' stands for 'Bit rate x')
B0 technologies lead to very high transmission times, which may be close
to or even greater than the Maximum Segment Lifetime (MSL) assumed on
the Internet . Many Internet protocols and mechanisms will fail
when transmit times are greater than the MSL. B0 technologies lead to a
frame transmission time greater than the MSL for a frame size greater
than 150 bytes.
B1 technologies offer transmission times which are lower than the MSL
(for a frame size greater than 150 bytes). However, transmission times
for B1 technologies are still significant if a human expects a reaction
to the transmission of a frame. With B1 technologies, the transmission
time of a frame greater than 62.5 bytes exceeds 0.5 seconds, i.e. a
threshold time beyond which any response or reaction to a frame
transmission will appear not to be immediate .
B2 technologies do not incur responsiveness problems, but still benefit
from using header compression techniques (e.g. ) to achieve
performance improvements.
Over B3 technologies, the relative performance benefits of header
compression are low. For example, in a duty-cycled technology offering
B3 PHY bit rates, energy consumption decrease due to header compression
may be comparable with the energy consumed while in a sleep interval. On
the other hand, for B3 PHY bit rates, a human user will not be able to
perceive whether header compression has been used or not in a frame
transmission.
IANA Considerations
This document makes no requests to IANA.
Security Considerations
This document introduces common terminology that does not raise any
new security issues. Security considerations arising from the
constraints discussed in this document need to be discussed in the
context of specific protocols. For instance, ,
"Constrained node considerations", discusses implications of specific
constraints on the security mechanisms employed. provides a security
threat analysis for the RPL routing protocol.
Implementation considerations for security protocols on constrained
nodes are discussed in and .
A wider view of security in constrained-node networks is provided in .
Terminology for Constrained-Node Networks
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 been useful in the standardization work for constrained-node networks.
Network Time Protocol Version 4: Protocol and Algorithms Specification
The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK]
Transmission of IPv6 Packets over IEEE 802.15.4 Networks
This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK]
Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks
This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework. [STANDARDS-TRACK]
SCHC: Generic Framework for Static Context Header Compression and Fragmentation
This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind.SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers.This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size.The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope.
Architectural Considerations in Smart Object Networking
The term "Internet of Things" (IoT) denotes a trend where a large number of embedded devices employ communication services offered by Internet protocols. Many of these devices, often called "smart objects", are not directly operated by humans but exist as components in buildings or vehicles, or are spread out in the environment. Following the theme "Everything that can be connected will be connected", engineers and researchers designing smart object networks need to decide how to achieve this in practice.This document offers guidance to engineers designing Internet- connected smart objects.
Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing
IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) are formed by devices that are compatible with the IEEE 802.15.4 standard. However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format specification defines how mesh topologies could be obtained and maintained. Thus, it should be considered how 6LoWPAN formation and multi-hop routing could be supported.This document provides the problem statement and design space for 6LoWPAN routing. It defines the routing requirements for 6LoWPANs, considering the low-power and other particular characteristics of the devices and links. The purpose of this document is not to recommend specific solutions but to provide general, layer-agnostic guidelines about the design of 6LoWPAN routing that can lead to further analysis and protocol design. This document is intended as input to groups working on routing protocols relevant to 6LoWPANs, such as the IETF ROLL WG. This document is not an Internet Standards Track specification; it is published for informational purposes.
Transmission Control Protocol
Delay-Tolerant Networking Architecture
This document describes an architecture for delay-tolerant and disruption-tolerant networks, and is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration. This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical. We define a message- oriented overlay that exists above the transport (or other) layers of the networks it interconnects. The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues. This document represents the consensus of the IRTF DTN research group and has been widely reviewed by that group. This memo provides information for the Internet community.
Terms Used in Routing for Low-Power and Lossy Networks
This document provides a glossary of terminology used in routing requirements and solutions for networks referred to as Low-Power and Lossy Networks (LLNs). An LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g., heating, ventilation, air conditioning, lighting, access control, fire), connected home, health care, environmental monitoring, urban sensor networks, energy management, assets tracking, and refrigeration.
Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks
Low-Power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad hoc networks that require the specification of new routing metrics and constraints. By contrast, with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing Protocol for Low-Power and Lossy Networks (RPL). [STANDARDS-TRACK]
RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available. [STANDARDS-TRACK]
IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals
This document describes the assumptions, problem statement, and goals for transmitting IP over IEEE 802.15.4 networks. The set of goals enumerated in this document form an initial set only. This memo provides information for the Internet community.
The Constrained Application Protocol (CoAP)
The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.
IPv6 over BLUETOOTH(R) Low Energy
Bluetooth Smart is the brand name for the Bluetooth low energy feature in the Bluetooth specification defined by the Bluetooth Special Interest Group. The standard Bluetooth radio has been widely implemented and available in mobile phones, notebook computers, audio headsets, and many other devices. The low-power version of Bluetooth is a specification that enables the use of this air interface with devices such as sensors, smart meters, appliances, etc. The low-power variant of Bluetooth has been standardized since revision 4.0 of the Bluetooth specifications, although version 4.1 or newer is required for IPv6. This document describes how IPv6 is transported over Bluetooth low energy using IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) techniques.
Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE)
Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) is a low-power air interface technology that is proposed by the DECT Forum and is defined and specified by ETSI.The DECT air interface technology has been used worldwide in communication devices for more than 20 years. It has primarily been used to carry voice for cordless telephony but has also been deployed for data-centric services.DECT ULE is a recent addition to the DECT interface primarily intended for low-bandwidth, low-power applications such as sensor devices, smart meters, home automation, etc. As the DECT ULE interface inherits many of the capabilities from DECT, it benefits from operation that is long-range and interference-free, worldwide- reserved frequency band, low silicon prices, and maturity. There is an added value in the ability to communicate with IPv6 over DECT ULE, such as for Internet of Things applications.This document describes how IPv6 is transported over DECT ULE using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques.
Transmission of IPv6 Packets over ITU-T G.9959 Networks
This document describes the frame format for transmission of IPv6 packets as well as a method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks.
Driving the Digital Agenda Requires Strategic Architecture
IDC
Slide 11
6LoWPAN: the Wireless Embedded Internet
A Delay-Tolerant Network Architecture for Challenged Internets
International Standard -- Quantities and units -- Part 13: Information science and technology
International Electrotechnical Commission
RPL deployment experience in large scale networks
Low power and Lossy Networks (LLNs) exhibit characteristics unlike
other more traditional IP links. LLNs are a class of network in
which both routers and their interconnect are resource constrained.
LLN routers are typically resource constrained in processing power,
memory, and energy (i.e. battery power). LLN links are typically
exhibit high loss rates, low data rates, are are strongly affected by
environmental conditions that change over time. LLNs may be composed
of a few dozen to thousands of routers. A new protocol called the
IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) has been
specified for routing in LLNs supporting multipoint-to-point, point-
to-multipoint traffic, and point-to-point traffic. Since RPL's
publication as an RFC, several large scale networks have been
succesfully deployed. The aim of this document is to provide
deployment experience on real-life deployed RPL-based networks.
A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs)
This document presents a security threat analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks. A systematic approach is used in defining and evaluating the security threats. Applicable countermeasures are application specific and are addressed in relevant applicability statements.
Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation
This document describes a minimal initiator version of the Internet Key Exchange version 2 (IKEv2) protocol for constrained nodes. IKEv2 is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). IKEv2 includes several optional features, which are not needed in minimal implementations. This document describes what is required from the minimal implementation and also describes various optimizations that can be done. The protocol described here is interoperable with a full IKEv2 implementation using shared secret authentication (IKEv2 does not require the use of certificate authentication). This minimal initiator implementation can only talk to a full IKEv2 implementation acting as the responder; thus, two minimal initiator implementations cannot talk to each other.This document does not update or modify RFC 7296 but provides a more compact description of the minimal version of the protocol. If this document and RFC 7296 conflict, then RFC 7296 is the authoritative description.
A Hitchhiker's Guide to the (Datagram) Transport Layer Security Protocol for Smart Objects and Constrained Node Networks
Transport Layer Security (TLS) is a widely used security protocol
that offers communication security services at the transport layer.
The initial design of TLS was focused on the protection of
applications running on top of the Transmission Control Protocol
(TCP), and was a good match for securing the Hypertext Transfer
Protocol (HTTP). Subsequent standardization efforts lead to the
publication of the Datagram Transport Layer Security (DTLS) protocol,
which allows the re-use of the TLS security functionality and the
payloads to be exchanged on top of the User Datagram Protocol (UDP).
With the work on the Constrained Application Protocol (CoAP), as a
specialized web transfer protocol for use with constrained nodes and
constrained networks, DTLS is a preferred communication security
protocol.
Smart objects are constrained in various ways (e.g., CPU, memory,
power consumption) and these limitations may impose restrictions on
the protocol stack such a device runs. This document only looks at
the security part of that protocol stacks and the ability to
customize TLS/DTLS. To offer input for implementers and system
architects this document illustrates the costs and benefits of
various TLS/DTLS features for use with smart objects and constraint
node networks.
Internet of Things (IoT) Security: State of the Art and Challenges
The Internet of Things (IoT) concept refers to the usage of standard Internet protocols to allow for human-to-thing and thing-to-thing communication. The security needs for IoT systems are well recognized, and many standardization steps to provide security have been taken -- for example, the specification of the Constrained Application Protocol (CoAP) secured with Datagram Transport Layer Security (DTLS). However, security challenges still exist, not only because there are some use cases that lack a suitable solution, but also because many IoT devices and systems have been designed and deployed with very limited security capabilities. In this document, we first discuss the various stages in the lifecycle of a thing. Next, we document the security threats to a thing and the challenges that one might face to protect against these threats. Lastly, we discuss the next steps needed to facilitate the deployment of secure IoT systems. This document can be used by implementers and authors of IoT specifications as a reference for details about security considerations while documenting their specific security challenges, threat models, and mitigations.This document is a product of the IRTF Thing-to-Thing Research Group (T2TRG).
Home Automation Routing Requirements in Low-Power and Lossy Networks
This document presents requirements specific to home control and automation applications for Routing Over Low power and Lossy (ROLL) networks. In the near future, many homes will contain high numbers of wireless devices for a wide set of purposes. Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure), and advanced controllers (radio-frequency-based AV remote control, central server for light and heat control). Because such devices only cover a limited radio range, routing is often required. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home-control and automation environment. This document is not an Internet Standards Track specification; it is published for informational purposes.
Low-Power Wide Area Network (LPWAN) Overview
Low-Power Wide Area Networks (LPWANs) are wireless technologies with characteristics such as large coverage areas, low bandwidth, possibly very small packet and application-layer data sizes, and long battery life operation. This memo is an informational overview of the set of LPWAN technologies being considered in the IETF and of the gaps that exist between the needs of those technologies and the goal of running IP in LPWANs.