Internet DRAFT - draft-bormann-lwig-terms
draft-bormann-lwig-terms
LWIG Working Group C. Bormann
Internet-Draft Universitaet Bremen TZI
Intended status: Informational M. Ersue
Expires: May 12, 2013 Nokia Siemens Networks
November 08, 2012
Terminology for Constrained Node Networks
draft-bormann-lwig-terms-00
Abstract
The Internet Protocol Suite is increasingly used on small devices
with severe constraints, creating constrained node networks. This
document provides a number of basic terms that have turned out to be
useful in the standardization work for constrained environments.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 12, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Bormann & Ersue Expires May 12, 2013 [Page 1]
Internet-Draft CNN terminology November 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Constrained Nodes . . . . . . . . . . . . . . . . . . . . 4
2.2. Constrained Networks . . . . . . . . . . . . . . . . . . . 5
2.2.1. Challenged Networks . . . . . . . . . . . . . . . . . 5
2.3. Constrained Node Networks . . . . . . . . . . . . . . . . 6
2.3.1. LLN ("low-power lossy network") . . . . . . . . . . . 6
2.3.2. LoWPAN, 6LoWPAN . . . . . . . . . . . . . . . . . . . 7
3. Classes of Constrained Devices . . . . . . . . . . . . . . . . 8
4. Informative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Bormann & Ersue Expires May 12, 2013 [Page 2]
Internet-Draft CNN terminology November 2012
1. Introduction
Small devices with limited CPU, memory, and power resources, so
called constrained devices (aka. sensor, smart object, or smart
device) can constitute 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 send the information to one or more server stations.
Constrained devices may work under severe resource constraints such
as limited battery and computing power, little memory and
insufficient wireless bandwidth, and communication capabilities.
Other entities on the network, e.g., a base station or controlling
server, might have more computational and communication resources and
can 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, etc. benefit from interacting with other "things" in
the near or somewhere in the Internet. With this, the Internet of
Things (IoT) becomes a reality, built up out of uniquely identifiable
and addressable objects (things). And over the next decade, this
could grow to large numbers [50billion] of Internet-connected
constrained devices, greatly increasing the Internet's size and
scope.
The present document provides a number of basic terms that have
turned out to be useful in the standardization work for constrained
environments. The intention is not to exhaustingly cover the field,
but to make sure a few core terms are used consistently between
different groups cooperating in this space.
Bormann & Ersue Expires May 12, 2013 [Page 3]
Internet-Draft CNN terminology November 2012
2. Terminology
The main focus of this field of work appears to be _scaling_:
o Scaling up Internet technologies to a large number [50billion] of
inexpensive nodes, while
o scaling down the characteristics of each of these nodes and of the
networks being built out of them, to make this scaling up
econmically and physically viable.
The need for scaling down the characteristics of nodes leads to
_constrained nodes_.
2.1. Constrained Nodes
The term "constrained node" is best defined on not meeting certain
widely held expectations:
Constrained Node: A node where some of the characteristics that are
otherwise pretty much taken for granted for Internet nodes in 2012
are not attainable, often due to cost constraints and/or physical
constraints on characteristics such as size, weight, and available
power.
While this is less than satisfying as 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.
(An alternative name, when the properties as a network node are not
in focus, is "constrained device".)
There are multiple facets to the constraints on nodes, often applying
in combination, e.g.:
o constraints on the maximum code complexity (ROM/Flash);
o constraints on the size of state and buffers (RAM);
o constraints on the available power.
Section 3 defines a small number of interesting classes ("class-N"
for N=1,2) of constrained nodes focusing on relevant combinations of
the first two constraints. With respect to available power,
[RFC6606] distinguishes "power-affluent" nodes (mains-powered or
regularly recharged) from "power-constrained nodes" that draw their
power from primary batteries or using energy harvesting.
Bormann & Ersue Expires May 12, 2013 [Page 4]
Internet-Draft CNN terminology November 2012
The use of constrained nodes in networks often also leads to
constraints on the networks themselves. However, there may also be
constraints on networks that are largely independent from those of
the nodes. We therefore distinguish _constrained networks_ and
_constrained node networks_.
2.2. Constrained Networks
We define "constrained network" in a similar way:
Constrained Network: A network where some of the characteristics
pretty much taken for granted for Internet link layers in 2012 are
not attainable.
Again, there may be several reasons for this:
o cost constraints on the network
o constraints of the nodes (for constrained node networks)
o physical constraints (e.g., power constraints, media constraints
such as underwater operation, limited spectrum for very high
density).
Constraints may include:
o low achievable bit rate
o high packet loss, packet loss (delivery rate) variability
o severe penalties for using larger packets (e.g., high packet loss
due to link layer fragmentation)
o lack of (or severe constraints on) advanced services such as IP
multicast
2.2.1. Challenged Networks
A constrained network is not necessarily a _challenged_ network
[FALL]:
Challenged Network: A network that has serious trouble maintaining
what an applicaton would today expect of the end-to-end IP model,
e.g., by:
o not being able to offer end-to-end IP connectivity at all;
Bormann & Ersue Expires May 12, 2013 [Page 5]
Internet-Draft CNN terminology November 2012
o exhibiting serious interruptions in end-to-end IP connectivity;
o exhibiting delay well beyond the 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
[RFC4838].
2.3. Constrained Node Networks
Constrained Node Network: A network whose characteristics are
influenced by being composed of a significant portion of
constrained nodes.
A constrained node network always is a constrained network because of
the network constraints stemming from the node constraints, but may
also have other constraints that already make it a constrained
network.
2.3.1. LLN ("low-power lossy network")
A related term that has been used recently is "low-power lossy
network" (LLN). The ROLL working group currently is struggling with
its definition [I-D.ietf-roll-terminology]:
LLN: Low power and Lossy networks (LLNs) are typically composed of
many embedded devices with limited power, memory, and processing
resources interconnected by a variety of links, such as IEEE
802.15.4 or Low Power WiFi. There is a wide scope of application
areas for LLNs, including industrial monitoring, building
automation (HVAC, lighting, access control, fire), connected home,
healthcare, environmental monitoring, urban sensor networks,
energy management, assets tracking and refrigeration.. [sic]
It is not clear that "LLN" is much more specific than "interesting"
or "the network characteristics that RPL has been designed for".
LLNs do appear to have significant loss at the physical layer, with
significant variability of the delivery rate, and some short-term
unreliability, coupled with some medium term stability that makes it
worthwhile to construct medium-term stable directed acyclic graphs
for routing and do measurements on the edges such as ETX. Actual
"low power" does not seem to be required for an LLN
[I-D.hui-vasseur-roll-rpl-deployment], and the positions on scaling
of LLNs appear to vary widely [I-D.clausen-lln-rpl-experiences].
Also, LLNs seem to be composed of constrained nodes; otherwise
Bormann & Ersue Expires May 12, 2013 [Page 6]
Internet-Draft CNN terminology November 2012
operation modes such as RPL's "non-storing mode" would not be
sensible. So an LLN seems to be a constrained node network with
certain constraints on the network as well.
2.3.2. LoWPAN, 6LoWPAN
One interesting class of a constrained network often used as a
constrained node network is the "LoWPAN" [RFC4919], a term inspired
from the name of the IEEE 802.15.4 working group (low-rate wireless
personal area networks (LR-WPANs)). The expansion of that acronym,
"Low-Power Wireless Personal Area Network" contains a hard to justify
"Personal" that is due to IEEE politics 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. Maybe the term is best read as "Low-Power
Wireless Area Networks" (LoWPANs) [WEI]. Originally focused on IEEE
802.15.4, "LoWPAN" (or when used for IPv6, "6LoWPAN") is now also
being used for networks built from similarly constrained link layer
technologies [I-D.ietf-6lowpan-btle]
[I-D.mariager-6lowpan-v6over-dect-ule].
Bormann & Ersue Expires May 12, 2013 [Page 7]
Internet-Draft CNN terminology November 2012
3. Classes of Constrained Devices
Despite the overwhelming variety of Internet-connected devices that
can be envisioned, it may be worthwhile to have some succinct
terminology for different classes of constrained devices. In this
document, the following class designations may be used as rough
indications of device capabilities:
+---------+-----------------------+-------------------------+
| Name | data size (e.g., RAM) | code size (e.g., Flash) |
+---------+-----------------------+-------------------------+
| Class 0 | << 10 KiB | << 100 KiB |
| | | |
| Class 1 | ~ 10 KiB | ~ 100 KiB |
| | | |
| Class 2 | ~ 50 KiB | ~ 250 KiB |
+---------+-----------------------+-------------------------+
Table 1: Classes of Constrained Devices
As of the writing of this document, these characteristics correspond
to distinguishable sets of commercially available chips and design
cores for constrained devices. While it is expected that the
boundaries of these classes will move over time, Moore's law tends to
be less effective in the embedded space than in personal computing
devices: Gains made available by increases in transistor count and
density are more likely to be invested in reductions of cost and
power requirements than into continual increases in computing power.
Class 0 devices are very constrained sensor-like motes. Most likely
they will not be able to communicate directly with the Internet in a
secure manner. Class 0 devices will participate in Internet
communications with the help of larger devices acting as proxies or
gateways. Class 0 devices generally cannot be secured or managed
comprehensively in the traditional sense. They will be most likely
preconfigured and if ever will be reconfigured rarely with a very
small data set. For management purposes, they could answer keepalive
signals and send on/off or basic health indications.
Class 1 devices cannot easily talk to other Internet nodes employing
a full protocol stack such as using HTTP, TLS and related security
protocols and XML-based data representations. However, they have
enough power to use a protocol stack specifically designed for
constrained nodes (e.g., 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
Bormann & Ersue Expires May 12, 2013 [Page 8]
Internet-Draft CNN terminology November 2012
memory, code space, and often power expenditure for protocol and
application usage.
Class 2 can already support mostly the same protocol stacks as used
on notebooks or servers. However, even these devices can benefit
from lightweight and energy-efficient protocols and from consuming
less bandwidth. Furthermore, using fewer resources for networking
leaves more resources available to applications. Thus, using the
protocol stacks defined for very constrained devices also on Class 2
devices might reduce development costs and increase the
interoperability.
Constrained devices with capabilities significantly beyond Class 2
devices exist. They are less demanding from a standards development
point of view as they can largely use existing protocols unchanged.
The present document therefore does not make any attempt to define
classes beyond Class 2. These devices can still be constrained by a
limited energy supply.
With respect to examining the capabilities of constrained nodes,
particularly for Class 1 devices, it is important to understand what
type of applications they are able to run and which protocol
mechanisms would be most suitable. Because of memory and other
limitations, each specific Class 1 device might be able to support
only a few selected functions needed for its intended operation. In
other words, the set of functions that can actually be supported is
not static per device type: devices with similar constraints might
choose to support different functions. Even though Class 2 devices
have some more functionality available and may be able to provide a
more complete set of functions, they still need to be assessed for
the type of applications they will be running and the protocol
functions they would need. To be able to derive any requirements,
the use cases and the involvement of the devices in the application
and the operational scenario need to be analyzed. Use cases may
combine constrained devices of multiple classes as well as more
traditional Internet nodes.
Bormann & Ersue Expires May 12, 2013 [Page 9]
Internet-Draft CNN terminology November 2012
4. Informative References
[50billion]
"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>.
[FALL] Fall, K., "A Delay-Tolerant Network Architecture for
Challenged Internets", SIGCOMM 2003.
[I-D.clausen-lln-rpl-experiences]
Clausen, T., Verdiere, A., Yi, J., Herberg, U., and Y.
Igarashi, "Observations of RPL: IPv6 Routing Protocol for
Low power and Lossy Networks",
draft-clausen-lln-rpl-experiences-04 (work in progress),
July 2012.
[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]
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-11
(work in progress), October 2012.
[I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-06 (work in
progress), September 2011.
[I-D.mariager-6lowpan-v6over-dect-ule]
Mariager, P. and J. Petersen, "Transmission of IPv6
Packets over DECT Ultra Low Energy",
draft-mariager-6lowpan-v6over-dect-ule-02 (work in
progress), May 2012.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, April 2007.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, August 2007.
Bormann & Ersue Expires May 12, 2013 [Page 10]
Internet-Draft CNN terminology November 2012
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing",
RFC 6606, May 2012.
[WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded
Internet", ISBN 9780470747995, 2009.
Bormann & Ersue Expires May 12, 2013 [Page 11]
Internet-Draft CNN terminology November 2012
Authors' Addresses
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
Mehmet Ersue
Nokia Siemens Networks
Email: mehmet.ersue@nsn.com
Bormann & Ersue Expires May 12, 2013 [Page 12]
