draft-ietf-lwig-terminology-07.txt   rfc7228.txt 
LWIG Working Group C. Bormann Internet Engineering Task Force (IETF) C. Bormann
Internet-Draft Universitaet Bremen TZI Request for Comments: 7228 Universitaet Bremen TZI
Intended status: Informational M. Ersue Category: Informational M. Ersue
Expires: August 14, 2014 Nokia Siemens Networks ISSN: 2070-1721 Nokia Solutions and Networks
A. Keranen A. Keranen
Ericsson Ericsson
February 10, 2014 May 2014
Terminology for Constrained Node Networks Terminology for Constrained-Node Networks
draft-ietf-lwig-terminology-07
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 on power, memory and processing resources, with severe constraints on power, memory, and processing resources,
creating constrained node networks. This document provides a number creating constrained-node networks. This document provides a number
of basic terms that have turned out to be useful in the of basic terms that have been useful in the standardization work for
standardization work for constrained node networks. constrained-node networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on August 14, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7228.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction ....................................................3
2. Core Terminology . . . . . . . . . . . . . . . . . . . . . . 3 2. Core Terminology ................................................4
2.1. Constrained Nodes . . . . . . . . . . . . . . . . . . . . 4 2.1. Constrained Nodes ..........................................4
2.2. Constrained Networks . . . . . . . . . . . . . . . . . . 5 2.2. Constrained Networks .......................................5
2.2.1. Challenged Networks . . . . . . . . . . . . . . . . . 6 2.2.1. Challenged Networks .................................6
2.3. Constrained Node Networks . . . . . . . . . . . . . . . . 6 2.3. Constrained-Node Networks ..................................7
2.3.1. LLN ("low-power lossy network") . . . . . . . . . . . 7 2.3.1. LLN .................................................7
2.3.2. LoWPAN, 6LoWPAN . . . . . . . . . . . . . . . . . . . 7 2.3.2. LoWPAN, 6LoWPAN .....................................8
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 ..............................11
4.3. Strategies of Using Power for Communication . . . . . . . 11 4.3. Strategies for Using Power for Communication ..............12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations ........................................14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgements ...............................................14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 7. Informative References .........................................14
8. Informative References . . . . . . . . . . . . . . . . . . . 14
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 (often used as a sensor/actuator, a smart called "constrained devices" (often used as sensors/actuators, smart
object, or a smart device) can form a network, becoming "constrained objects, or smart devices) can form a network, becoming "constrained
nodes" in that network. Such a network may itself exhibit nodes" in that network. Such a network may itself exhibit
constraints, e.g. with unreliable or lossy channels, limited and constraints, e.g., with unreliable or lossy channels, limited and
unpredictable 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
They also act on information, by performing some physical action, stations. They might also act on information, by performing some
including displaying it. Constrained devices may work under severe physical action, including displaying it. Constrained devices may
resource constraints such as limited battery and computing power, work under severe resource constraints such as limited battery and
little memory, as well as insufficient wireless bandwidth and ability computing power, little memory, and insufficient wireless bandwidth
to communicate; these constraints often exacerbate each other. Other and ability to communicate; these constraints often exacerbate each
entities on the network, e.g., a base station or controlling server, other. Other entities on the network, e.g., a base station or
might have more computational and communication resources and could controlling server, might have more computational and communication
support the interaction between the constrained devices and resources and could support the interaction between the constrained
applications in more traditional networks. devices and 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, and other devices benefit from interacting with other
nearby or somewhere in the Internet. With this, the Internet of "things" nearby or somewhere in the Internet. With this, the
Things (IoT) becomes a reality, built up out of uniquely identifiable Internet of Things (IoT) becomes a reality, built up out of uniquely
and addressable objects (things). And over the next decade, this identifiable and addressable objects (things). Over the next decade,
could grow to large numbers [fifty-billion] of Internet-connected this could grow to large numbers [FIFTY-BILLION] of Internet-
constrained devices, greatly increasing the Internet's size and connected constrained devices, greatly increasing the Internet's size
scope. and scope.
The present document provides a number of basic terms that have The present document provides a number of basic terms that have been
turned out to be useful in the standardization work for constrained useful in the standardization work for constrained environments. The
environments. The intention is not to exhaustively cover the field, intention is not to exhaustively cover the field but to make sure a
but to make sure a few core terms are used consistently between few core terms are used consistently between different groups
different groups cooperating in this space. 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].
In computing, the term "power" is often used for the concept of In computing, the term "power" is often used for the concept of
"computing power" or "processing power", as in CPU performance. "computing power" or "processing power", as in CPU performance. In
Unless explicitly stated otherwise, in this document the term stands this document, the term stands for electrical power unless explicitly
for electrical power. "Mains-powered" is used as a short-hand for stated otherwise. "Mains-powered" is used as a shorthand for being
being permanently connected to a stable electrical power grid. permanently connected to a stable electrical power grid.
2. Core Terminology 2. Core Terminology
There are two important aspects to _scaling_ within the Internet of There are two important aspects to _scaling_ within the Internet of
Things: 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 at the otherwise pretty much taken for granted for Internet nodes at the
time of writing are not attainable, often due to cost constraints time of writing are not attainable, often due to cost constraints
and/or physical constraints on characteristics such as size, and/or physical constraints on characteristics such as size,
weight, and available power and energy. The tight limits on weight, and available power and energy. The tight limits on
power, memory and processing resources lead to hard upper bounds power, memory, and processing resources lead to hard upper bounds
on state, code space and processing cycles, making optimization of on state, code space, and processing cycles, making optimization
energy and network bandwidth usage a dominating consideration in of energy and network bandwidth usage a dominating consideration
all design requirements. Also, some layer 2 services such as full in all design requirements. Also, some layer-2 services such as
connectivity and broadcast/multicast may be lacking. full connectivity and broadcast/multicast may be lacking.
While this is not a rigorous definition, it is grounded in the state While this is not a rigorous definition, it is grounded in the state
of the art and clearly sets apart constrained nodes from server of the art and clearly sets apart constrained nodes from server
systems, desktop or laptop computers, powerful mobile devices such as systems, desktop or laptop computers, powerful mobile devices such as
smartphones etc. There may be many design considerations that lead smartphones, etc. There may be many design considerations that lead
to these constraints, including cost, size, weight, and other scaling to these constraints, including cost, size, weight, and other scaling
factors. factors.
(An alternative name, when the properties as a network node are not (An alternative term, 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, for example:
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 amount of computation feasible in a period of o constraints on the amount of computation feasible in a period of
time ("processing power"); time ("processing power"),
o constraints on the available (electrical) power; o constraints on the available power, and
o constraints on user interface and accessibility in deployment o constraints on user interface and accessibility in deployment
(ability to set keys, update software, etc.). (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
of the first two constraints. With respect to available (electrical) combinations of the first two constraints. With respect to available
power, [RFC6606] distinguishes "power-affluent" nodes (mains-powered power, [RFC6606] distinguishes "power-affluent" nodes (mains-powered
or regularly recharged) from "power-constrained nodes" that draw or regularly recharged) from "power-constrained nodes" that draw
their power from primary batteries or by using energy harvesting; their power from primary batteries or by using energy harvesting;
more 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" from
_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 at the time of writing, are not attainable. the Internet at the time of writing are not attainable.
Constraints may include: Constraints may include:
o low achievable bit rate/throughput (including limits on duty o low achievable bitrate/throughput (including limits on duty
cycle), cycle),
o high packet loss, high packet loss (delivery rate) variability, o high packet loss and high variability of packet loss (delivery
rate),
o highly asymmetric link characteristics, 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 limits on reachability over time (a substantial number of devices o limits on reachability over time (a substantial number of devices
may power off at any point in time but periodically "wake up" and may power off at any point in time but periodically "wake up" and
can communicate for brief periods of time) can communicate for brief periods of time), and
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.
More generally, we speak of constrained networks whenever at least More generally, we speak of constrained networks whenever at least
some of the nodes involved in the network exhibit these some of the nodes involved in the network exhibit these
characteristics. characteristics.
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 posed by 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
compatibility), compatibility),
o regulatory constraints, such as very limited spectrum availability o regulatory constraints, such as very limited spectrum availability
(including limits on effective radiated power and duty cycle), or (including limits on effective radiated power and duty cycle) or
explosion safety, explosion safety, and
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.
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]:
Challenged Network: A network that has serious trouble maintaining Challenged Network: A network that has serious trouble maintaining
what an application would today expect of the end-to-end IP model, what an application would today expect of the end-to-end IP model,
e.g., by: e.g., by:
o not being able to offer end-to-end IP connectivity at all; * not being able to offer end-to-end IP connectivity at all,
o exhibiting serious interruptions in end-to-end IP connectivity; * exhibiting serious interruptions in end-to-end IP connectivity,
or
o exhibiting delay well beyond the Maximum Segment Lifetime (MSL) * exhibiting delay well beyond the Maximum Segment Lifetime (MSL)
defined by TCP [RFC0793]. defined by TCP [RFC0793].
All challenged networks are constrained networks in some sense, but All challenged networks are constrained networks in some sense, but
not all constrained networks are challenged networks. There is no not all constrained networks are challenged networks. There is no
well-defined boundary between the two, though. Delay-Tolerant well-defined boundary between the two, though. Delay-Tolerant
Networking (DTN) has been designed to cope with challenged networks Networking (DTN) has been designed to cope with challenged networks
[RFC4838]. [RFC4838].
2.3. Constrained Node Networks 2.3. Constrained-Node Networks
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 it
also have other constraints that already make it a constrained may also have other constraints that already make it a constrained
network. network.
The rest of this subsection introduces two additional terms that are The rest of this subsection introduces two additional terms that are
in active use in the area of constrained node networks, without an in active use in the area of constrained-node networks, without an
intent to define them: LLN and (6)LoWPAN. intent to define them: LLN and (6)LoWPAN.
2.3.1. LLN ("low-power lossy network") 2.3.1. LLN
A related term that has been used to describe the focus of the IETF 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 ROLL working group is "Low-Power and Lossy Network (LLN)". The ROLL
"low-power lossy network" (LLN). The ROLL terminology document (Routing Over Low-Power and Lossy) terminology document [RFC7102]
[RFC7102] defines LLNs as follows: defines LLNs as follows:
LLN: Low power and Lossy networks (LLNs) are typically composed of LLN: Low-Power and Lossy Network. Typically composed of many
many embedded devices with limited power, memory, and processing 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 Wi-Fi. 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 (heating, ventilation, and air conditioning (HVAC),
healthcare, environmental monitoring, urban sensor networks, lighting, access control, fire), connected home, health care,
energy management, assets tracking and refrigeration.. [sic] environmental monitoring, urban sensor networks, energy
management, assets tracking, and refrigeration.
Beyond that, LLNs often exhibit considerable loss at the physical Beyond that, LLNs often exhibit considerable loss at the physical
layer, with significant variability of the delivery rate, and some layer, with significant variability of the delivery rate, and some
short-term unreliability, coupled with some medium term stability short-term unreliability, coupled with some medium-term stability
that makes it worthwhile to construct medium-term stable directed that makes it worthwhile to both construct directed acyclic graphs
acyclic graphs for routing and do measurements on the edges such as that are medium-term stable for routing and do measurements on the
ETX [RFC6551]. Not all LLNs comprise low power nodes edges such as Expected Transmission Count (ETX) [RFC6551]. Not all
[I-D.hui-vasseur-roll-rpl-deployment]. LLNs comprise low-power nodes [RPL-DEPLOYMENT].
LLNs typically are composed of constrained nodes; this leads to the LLNs typically are composed of constrained nodes; this leads to the
design of operation modes such as the "non-storing mode" defined by design of operation modes such as the "non-storing mode" defined by
RPL (the IPv6 Routing Protocol for Low-Power and Lossy Networks RPL (the IPv6 Routing Protocol for Low-Power and Lossy Networks
[RFC6650]). So, in the terminology of the present document, an LLN [RFC6550]). So, in the terminology of the present document, an LLN
is a constrained node network with certain network characteristics, is a constrained-node network with certain network characteristics,
which include 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 "LoWPAN" [RFC4919], a term inspired from
from the name of the IEEE 802.15.4 working group (low-rate wireless the name of an 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 the LoWPAN
"Low-Power Wireless Personal Area Network" contains a hard to justify acronym, "Low-Power Wireless Personal Area Network", contains a hard-
"Personal" that is due to the history of task group naming in IEEE to-justify "Personal" that is due to the history of task group naming
802 more than due to an orientation of LoWPANs around a single in IEEE 802 more than due to an orientation of LoWPANs around a
person. Actually, LoWPANs have been suggested for urban monitoring, single person. Actually, LoWPANs have been suggested for urban
control of large buildings, and industrial control applications, so monitoring, control of large buildings, and industrial control
the "Personal" can only be considered a vestige. Occasionally the applications, so the "Personal" can only be considered a vestige.
term is read as "Low-Power Wireless Area Networks" (LoWPANs) [WEI]. Occasionally, the term is read as "Low-Power Wireless Area Networks"
[WEI]. Originally focused on IEEE 802.15.4, "LoWPAN" (or when used
Originally focused on IEEE 802.15.4, "LoWPAN" (or when used for IPv6, for IPv6, "6LoWPAN") also refers to networks built from similarly
"6LoWPAN") also refers to networks built from similarly constrained constrained link-layer technologies [V6-BTLE] [V6-DECT-ULE]
link layer technologies [I-D.ietf-6lowpan-btle] [V6-G9959].
[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 35 skipping to change at page 9, line 6
| Class 2, C2 | ~ 50 KiB | ~ 250 KiB | | Class 2, C2 | ~ 50 KiB | ~ 250 KiB |
+-------------+-----------------------+-------------------------+ +-------------+-----------------------+-------------------------+
Table 1: Classes of Constrained Devices (KiB = 1024 bytes) Table 1: Classes of Constrained Devices (KiB = 1024 bytes)
As of the writing of this document, these characteristics correspond As of the writing of this document, these characteristics correspond
to distinguishable clusters of commercially available chips and to distinguishable clusters of commercially available chips and
design cores for constrained devices. While it is expected that the design cores for constrained devices. While it is expected that the
boundaries of these classes will move over time, Moore's law tends to boundaries of these classes will move over time, Moore's law tends to
be less effective in the embedded space than in personal computing be less effective in the embedded space than in personal computing
devices: Gains made available by increases in transistor count and devices: gains made available by increases in transistor count and
density are more likely to be invested in reductions of cost and density are more likely to be invested in reductions of cost and
power requirements than into continual increases in computing power. power requirements than into continual increases in computing power.
Class 0 devices are very constrained sensor-like motes. They are so Class 0 devices are very constrained sensor-like motes. They are so
severely constrained in memory and processing capabilities that most severely constrained in memory and processing capabilities that most
likely they will not have the resources required to communicate likely they will not have the resources required to communicate
directly with the Internet in a secure manner (rare heroic, narrowly directly with the Internet in a secure manner (rare heroic, narrowly
targeted implementation efforts notwithstanding). Class 0 devices targeted implementation efforts notwithstanding). Class 0 devices
will participate in Internet communications with the help of larger will participate in Internet communications with the help of larger
devices acting as proxies, gateways or servers. Class 0 devices devices acting as proxies, gateways, or servers. Class 0 devices
generally cannot be secured or managed comprehensively in the generally cannot be secured or managed comprehensively in the
traditional sense. They will most likely be preconfigured (and will traditional sense. They will most likely be preconfigured (and will
be reconfigured rarely, if at all), with a very small data set. For be reconfigured rarely, if at all) with a very small data set. For
management purposes, they could answer keepalive signals and send on/ management purposes, they could answer keepalive signals and send on/
off or basic health indications. off or basic health indications.
Class 1 devices are quite constrained in code space and processing Class 1 devices are quite constrained in code space and processing
capabilities, such that they cannot easily talk to other Internet capabilities, such that they cannot easily talk to other Internet
nodes employing a full protocol stack such as using HTTP, TLS and nodes employing a full protocol stack such as using HTTP, Transport
related security protocols and XML-based data representations. Layer Security (TLS), and related security protocols and XML-based
However, they have enough power to use a protocol stack specifically data representations. However, they are capable enough to use a
designed for constrained nodes (such as CoAP over UDP protocol stack specifically designed for constrained nodes (such as
[I-D.ietf-core-coap]) and participate in meaningful conversations the Constrained Application Protocol (CoAP) over UDP [COAP]) and
without the help of a gateway node. In particular, they can provide participate in meaningful conversations without the help of a gateway
support for the security functions required on a large network. node. In particular, they can provide support for the security
Therefore, they can be integrated as fully developed peers into an IP functions required on a large network. Therefore, they can be
network, but they need to be parsimonious with state memory, code integrated as fully developed peers into an IP network, but they need
space, and often power expenditure for protocol and application to be parsimonious with state memory, code space, and often power
usage. expenditure for protocol and application usage.
Class 2 devides are less constrained and fundamentally capable of Class 2 devices are less constrained and fundamentally capable of
supporting most of the same protocol stacks as used on notebooks or supporting most of the same protocol stacks as used on notebooks or
servers. However, even these devices can benefit from lightweight servers. However, even these devices can benefit from lightweight
and energy-efficient protocols and from consuming less bandwidth. and energy-efficient protocols and from consuming less bandwidth.
Furthermore, using fewer resources for networking leaves more Furthermore, using fewer resources for networking leaves more
resources available to applications. Thus, using the protocol stacks resources available to applications. Thus, using the protocol stacks
defined for more constrained devices also on Class 2 devices might defined for more constrained devices on Class 2 devices might reduce
reduce development costs and increase the interoperability. development costs and increase the interoperability.
Constrained devices with capabilities significantly beyond Class 2 Constrained devices with capabilities significantly beyond Class 2
devices exist. They are less demanding from a standards development devices exist. They are less demanding from a standards development
point of view as they can largely use existing protocols unchanged. point of view as they can largely use existing protocols unchanged.
The present document therefore does not make any attempt to define The present document therefore does not make any attempt to define
classes beyond Class 2. These devices can still be constrained by a classes beyond Class 2. These devices can still be constrained by a
limited energy supply. limited energy supply.
With respect to examining the capabilities of constrained nodes, With respect to examining the capabilities of constrained nodes,
particularly for Class 1 devices, it is important to understand what particularly for Class 1 devices, it is important to understand what
skipping to change at page 10, line 7 skipping to change at page 10, line 25
more complete set of functions, they still need to be assessed for more complete set of functions, they still need to be assessed for
the type of applications they will be running and the protocol the type of applications they will be running and the protocol
functions they would need. To be able to derive any requirements, functions they would need. To be able to derive any requirements,
the use cases and the involvement of the devices in the application the use cases and the involvement of the devices in the application
and the operational scenario need to be analyzed. Use cases may and the operational scenario need to be analyzed. Use cases may
combine constrained devices of multiple classes as well as more combine constrained devices of multiple classes as well as more
traditional Internet nodes. traditional Internet nodes.
4. Power Terminology 4. Power Terminology
Devices not only differ in their computing capabilities, but also in Devices not only differ in their computing capabilities but also in
available electrical power and/or energy. While it is harder to find available 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 simply state, in SI Instead of defining classes or clusters, we simply state, using the
units, an approximate value for one or both of the quantities listed International System of Units (SI units), an approximate value for
in Table 2: one or both of the quantities listed 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 |
| | device over the time it is functioning | | | | device over the time it is functioning | (Watt) |
| | | | | | | |
| Et | Total electrical energy available before | J (Joule) | | Et | Total electrical energy available before the | J |
| | the energy source is exhausted | | | | energy source is exhausted | (Joule) |
+--------+---------------------------------------------+------------+ +------+--------------------------------------------------+---------+
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
subsection. Section 4.2.
Some devices enter a "low-power" mode before the energy available in 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 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 exhaustion. For these devices, Ps would need to be given for each of
the modes/steps. 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 E9. 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 that is discarded when its non-replaceable primary battery is
battery is exhausted), classified as E2. Where the relevant exhausted), classified as E2. Where the relevant limitation is for a
limitation is for a specific period, this is classified as E1, e.g. a specific period, the device is classified as E1, e.g., a solar-
limited amount of energy available for the night with a solar-powered powered device with a limited amount of energy available for the
device, or for the period between recharges with a device that is night, a device that is manually connected to a charger and has a
manually connected to a charger, or by a periodic (primary) battery period of time between recharges, or a device with a periodic
replacement interval. Finally, there may be a limited amount of (primary) battery replacement interval. Finally, there may be a
energy available for a specific event, e.g. for a button press in an limited amount of energy available for a specific event, e.g., for a
energy harvesting light switch; this is classified as E0. Note that button press in an energy-harvesting light switch; such devices are
many E1 devices in a sense also are E2, as the rechargeable battery classified as E0. Note that, in a sense, many E1 devices are also
has a limited number of useful recharging cycles. E2, as the rechargeable battery has a limited number of useful
recharging cycles.
In summary, we distinguish (Table 3): Table 3 provides a summary of the classifications described above.
+------+------------------------------+-----------------------------+ +------+------------------------------+-----------------------------+
| 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 |
| | | | | | | |
| E9 | 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 for 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.
Design parameters such as the available spectrum, the desired range, Design parameters, such as the available spectrum, the desired range,
and the bitrate aimed for, influence the power consumed during and the bitrate aimed for, influence the power consumed during
transmission and reception; the duration of transmission and transmission and reception; the duration of transmission and
reception (including potential reception) influence the total energy reception (including potential reception) influence the total energy
consumption. consumption.
Based on the type of the energy source (e.g., battery or mains power) Different strategies for power usage and network attachment may be
and how often device needs to communicate, it may use different kinds used, based on the type of the energy source (e.g., battery or mains-
of strategies for power usage and network attachment. powered) and the frequency with which a device needs to communicate.
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.
Normally-off: Under this strategy, the device sleeps such long 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 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 not pretend that it has been connected to the network during
sleep: The device re-attaches to the network as it is woken up. sleep: the device reattaches to the network as it is woken up.
The main optimization goal is to minimize the effort during such The main optimization goal is to minimize the effort during the
re-attachment process and any resulting application reattachment process and any resulting application communications.
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 need 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 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 and tuning the
of communications (including "duty cycling", where components are frequency of communications (including "duty cycling", where
switched on and off in a regular cycle), and other parameters components are switched on and off in a regular cycle) and other
appropriately. parameters appropriately.
In summary, we distinguish (Table 4): Table 4 provides a summary of the strategies described above.
+--------+--------------------+-------------------------------------+ +------+--------------+---------------------------------------------+
| Name | Strategy | Ability to communicate | | Name | Strategy | Ability to communicate |
+--------+--------------------+-------------------------------------+ +------+--------------+---------------------------------------------+
| P0 | Normally-off | Re-attach when required | | P0 | Normally-off | Reattach when required |
| | | | | | | |
| P1 | Low-power | Appears connected, perhaps with | | P1 | Low-power | Appears connected, perhaps with high |
| | | high latency | | | | latency |
| | | | | | | |
| P9 | 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- A term often used to describe power-saving approaches is "duty-
cycling". This describes all forms of periodically switching off cycling". This describes all forms of periodically switching off
some function, leaving it on only for a certain percentage of time some function, leaving it on only for a certain percentage of time
(the "duty cycle"). (the "duty cycle").
[RFC7102] only distinguishes two levels, defining a Non-sleepy Node [RFC7102] only distinguishes two levels, defining a Non-Sleepy Node
as a node that always remains in a fully powered on state (always as a node that always remains in a fully powered-on state (always
awake) where it has the capability to perform communication (P9), and 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 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 low-power state to conserve power) and temporarily suspend protocol
communication (P0); there is no explicit mention of P1. 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 issues. 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, Section 11.6 of [COAP],
section 11.6, "Constrained node considerations", discusses "Constrained node considerations", discusses implications of specific
implications of specific constraints on the security mechanisms constraints on the security mechanisms employed. [ROLL-SEC-THREATS]
employed. [I-D.ietf-roll-security-threats] provides a security provides a security threat analysis for the RPL routing protocol.
threat analysis for the RPL routing protocol. Implementation Implementation considerations for security protocols on constrained
considerations for security protocols on constrained nodes are nodes are discussed in [IKEV2-MINIMAL] and [TLS-MINIMAL]. A wider
discussed in [I-D.ietf-lwig-ikev2-minimal] and view of security in constrained-node networks is provided in
[I-D.ietf-lwig-tls-minimal]. A wider view at security in constrained [IOT-SECURITY].
node networks is provided in [I-D.garcia-core-security].
6. IANA Considerations
This document has no actions for IANA.
7. Acknowledgements 6. 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 include power terminology,
hence Section 4. The text for Section 4.3 is mostly lifted from a hence Section 4. The text for Section 4.3 is mostly lifted from a
previous version of [I-D.ietf-lwig-cellular] and has been adapted for previous version of [COAP-CELLULAR] and has been adapted for this
this document. document.
8. Informative References
[FALL] Fall, K., "A Delay-Tolerant Network Architecture for
Challenged Internets", SIGCOMM 2003, 2003.
[I-D.brandt-6man-lowpanz]
Brandt, A. and J. Buron, "Transmission of IPv6 packets
over ITU-T G.9959 Networks", draft-brandt-6man-lowpanz-02
(work in progress), June 2013.
[I-D.garcia-core-security]
Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and
R. Struik, "Security Considerations in the IP-based
Internet of Things", draft-garcia-core-security-06 (work
in progress), September 2013.
[I-D.hui-vasseur-roll-rpl-deployment]
Vasseur, J., Hui, J., Dasgupta, S., and G. Yoon, "RPL
deployment experience in large scale networks", draft-hui-
vasseur-roll-rpl-deployment-01 (work in progress), July
2012.
[I-D.ietf-6lowpan-btle] 7. Informative References
Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets
over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-12
(work in progress), February 2013.
[I-D.ietf-core-coap] [COAP] Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Shelby, Z., Hartke, K., and C. Bormann, "Constrained Application Protocol (CoAP)", Work in Progress, June 2013.
Application Protocol (CoAP)", draft-ietf-core-coap-18
(work in progress), June 2013.
[I-D.ietf-lwig-cellular] [COAP-CELLULAR]
Arkko, J., Eriksson, A., and A. Keranen, "Building Power- Arkko, J., Eriksson, A., and A. Keranen, "Building Power-
Efficient CoAP Devices for Cellular Networks", draft-ietf- Efficient CoAP Devices for Cellular Networks", Work in
lwig-cellular-00 (work in progress), August 2013. Progress, February 2014.
[I-D.ietf-lwig-ikev2-minimal] [FALL] Fall, K., "A Delay-Tolerant Network Architecture for
Kivinen, T., "Minimal IKEv2", draft-ietf-lwig- Challenged Internets", SIGCOMM 2003, 2003.
ikev2-minimal-01 (work in progress), October 2013.
[I-D.ietf-lwig-tls-minimal] [FIFTY-BILLION]
Kumar, S., Keoh, S., and H. Tschofenig, "A Hitchhiker's Ericsson, "More Than 50 Billion Connected Devices",
Guide to the (Datagram) Transport Layer Security Protocol Ericsson White Paper 284 23-3149 Uen, February 2011,
for Smart Objects and Constrained Node Networks", draft- <http://www.ericsson.com/res/docs/whitepapers/
ietf-lwig-tls-minimal-00 (work in progress), September wp-50-billions.pdf>.
2013.
[I-D.ietf-roll-security-threats] [IKEV2-MINIMAL]
Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., Kivinen, T., "Minimal IKEv2", Work in Progress, October
and M. Richardson, "A Security Threat Analysis for Routing
Protocol for Low-power and lossy networks (RPL)", draft-
ietf-roll-security-threats-06 (work in progress), December
2013. 2013.
[I-D.mariager-6lowpan-v6over-dect-ule] [IOT-SECURITY]
Mariager, P., Petersen, J., and Z. Shelby, "Transmission Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and
of IPv6 Packets over DECT Ultra Low Energy", draft- R. Struik, "Security Considerations in the IP-based
mariager-6lowpan-v6over-dect-ule-03 (work in progress), Internet of Things", Work in Progress, September 2013.
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
Networking Architecture", RFC 4838, April 2007. Networking Architecture", RFC 4838, April 2007.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs): over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals", RFC Overview, Assumptions, Problem Statement, and Goals", RFC
4919, August 2007. 4919, August 2007.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012.
[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.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, January 2014. Lossy Networks", RFC 7102, January 2014.
[ROLL-SEC-THREATS]
Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
and M. Richardson, "A Security Threat Analysis for Routing
Protocol for Low-power and lossy networks (RPL)", Work in
Progress, December 2013.
[RPL-DEPLOYMENT]
Vasseur, J., Ed., Hui, J., Ed., Dasgupta, S., and G. Yoon,
"RPL deployment experience in large scale networks", Work
in Progress, July 2012.
[TLS-MINIMAL]
Kumar, S., Keoh, S., and H. Tschofenig, "A Hitchhiker's
Guide to the (Datagram) Transport Layer Security Protocol
for Smart Objects and Constrained Node Networks", Work in
Progress, March 2014.
[V6-BTLE] Nieminen, J., Ed., Savolainen, T., Ed., Isomaki, M.,
Patil, B., Shelby, Z., and C. Gomez, "Transmission of IPv6
Packets over BLUETOOTH Low Energy", Work in Progress, May
2014.
[V6-DECT-ULE]
Mariager, P., Ed., Petersen, J., and Z. Shelby,
"Transmission of IPv6 Packets over DECT Ultra Low Energy",
Work in Progress, July 2013.
[V6-G9959] Brandt, A. and J. Buron, "Transmission of IPv6 packets
over ITU-T G.9959 Networks", Work in Progress, May 2014.
[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]
Ericsson, "More Than 50 Billion Connected Devices",
Ericsson White Paper 284 23-3149 Uen, February 2011,
<http://www.ericsson.com/res/docs/whitepapers/
wp-50-billions.pdf>.
Authors' Addresses Authors' Addresses
Carsten Bormann Carsten Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
D-28359 Bremen D-28359 Bremen
Germany Germany
Phone: +49-421-218-63921 Phone: +49-421-218-63921
Email: cabo@tzi.org EMail: cabo@tzi.org
Mehmet Ersue Mehmet Ersue
Nokia Siemens Networks Nokia Solutions and Networks
St.-Martinstrasse 76 St.-Martinstrasse 76
81541 Munich 81541 Munich
Germany Germany
Phone: +49 172 8432301 Phone: +49 172 8432301
Email: mehmet.ersue@nsn.com EMail: mehmet.ersue@nsn.com
Ari Keranen Ari Keranen
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
02420 Jorvas 02420 Jorvas
Finland Finland
Email: ari.keranen@ericsson.com EMail: ari.keranen@ericsson.com
 End of changes. 101 change blocks. 
311 lines changed or deleted 296 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/