draft-ietf-lwig-terminology-01.txt   draft-ietf-lwig-terminology-02.txt 
LWIG Working Group C. Bormann LWIG Working Group C. Bormann
Internet-Draft Universitaet Bremen TZI Internet-Draft Universitaet Bremen TZI
Intended status: Informational M. Ersue Intended status: Informational M. Ersue
Expires: August 29, 2013 Nokia Siemens Networks Expires: September 29, 2013 Nokia Siemens Networks
February 25, 2013 March 28, 2013
Terminology for Constrained Node Networks Terminology for Constrained Node Networks
draft-ietf-lwig-terminology-01 draft-ietf-lwig-terminology-02
Abstract Abstract
The Internet Protocol Suite is increasingly used on small devices The Internet Protocol Suite is increasingly used on small devices
with severe constraints, creating constrained node networks. This with severe constraints, creating constrained node networks. This
document provides a number of basic terms that have turned out to be document provides a number of basic terms that have turned out to be
useful in the standardization work for constrained environments. useful in the standardization work for constrained environments.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 29, 2013. This Internet-Draft will expire on September 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Constrained Nodes . . . . . . . . . . . . . . . . . . . . 3 2.1. Constrained Nodes . . . . . . . . . . . . . . . . . . . . 3
2.2. Constrained Networks . . . . . . . . . . . . . . . . . . 4 2.2. Constrained Networks . . . . . . . . . . . . . . . . . . 4
2.2.1. Challenged Networks . . . . . . . . . . . . . . . . . 5 2.2.1. Challenged Networks . . . . . . . . . . . . . . . . . 5
2.3. Constrained Node Networks . . . . . . . . . . . . . . . . 5 2.3. Constrained Node Networks . . . . . . . . . . . . . . . . 5
2.3.1. LLN ("low-power lossy network") . . . . . . . . . . . 5 2.3.1. LLN ("low-power lossy network") . . . . . . . . . . . 5
2.3.2. LoWPAN, 6LoWPAN . . . . . . . . . . . . . . . . . . . 6 2.3.2. LoWPAN, 6LoWPAN . . . . . . . . . . . . . . . . . . . 6
3. Classes of Constrained Devices . . . . . . . . . . . . . . . 6 3. Classes of Constrained Devices . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Power Terminology . . . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4.1. Scaling Properties . . . . . . . . . . . . . . . . . . . 9
6. Informative References . . . . . . . . . . . . . . . . . . . 8 4.2. Energy Limitation Classes . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Power Usage Strategies . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. Informative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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 (aka. sensor, smart object, or smart called constrained devices (aka. sensor, smart object, or smart
device) can constitute a network, becoming "constrained nodes" in device) can constitute a network, becoming "constrained nodes" in
that network. Such a network may itself exhibit constraints, e.g. that network. Such a network may itself exhibit constraints, e.g.
with unreliable or lossy channels, limited and unpredictable with unreliable or lossy channels, limited and unpredictable
bandwidth, and a highly dynamic topology. bandwidth, and a highly dynamic topology.
skipping to change at page 3, line 31 skipping to change at page 3, line 35
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 on not meeting certain The term "constrained node" is best defined on not meeting certain
widely held expectations: widely held expectations:
Constrained Node: A node where some of the characteristics that are Constrained Node: A node where some of the characteristics that are
otherwise pretty much taken for granted for Internet nodes in 2012 otherwise pretty much taken for granted for Internet nodes in 2013
are not attainable, often due to cost constraints and/or physical are not attainable, often due to cost constraints and/or physical
constraints on characteristics such as size, weight, and available constraints on characteristics such as size, weight, and available
power. power.
While this is less than satisfying as a rigorous definition, it is While this is less than satisfying as a rigorous definition, it is
grounded in the state of the art and clearly sets apart constrained grounded in the state of the art and clearly sets apart constrained
nodes from server systems, desktop or laptop computers, powerful nodes from server systems, desktop or laptop computers, powerful
mobile devices such as smartphones etc. mobile devices such as smartphones etc.
(An alternative name, when the properties as a network node are not (An alternative name, when the properties as a network node are not
skipping to change at page 4, line 23 skipping to change at page 4, line 26
constraints on the networks themselves. However, there may also be constraints on the networks themselves. However, there may also be
constraints on networks that are largely independent from those of constraints on networks that are largely independent from those of
the nodes. We therefore distinguish _constrained networks_ and the nodes. We therefore distinguish _constrained networks_ and
_constrained node networks_. _constrained node networks_.
2.2. Constrained Networks 2.2. Constrained Networks
We define "constrained network" in a similar way: We define "constrained network" in a similar way:
Constrained Network: A network where some of the characteristics Constrained Network: A network where some of the characteristics
pretty much taken for granted for Internet link layers in 2012 are pretty much taken for granted for Internet link layers in 2013 are
not attainable. not attainable.
Again, there may be several reasons for this: Again, there may be several reasons for this:
o cost constraints on the network o cost constraints on the network
o constraints of the nodes (for constrained node networks) o constraints of the nodes (for constrained node networks)
o physical constraints (e.g., power constraints, media constraints o physical constraints (e.g., power constraints, media constraints
such as underwater operation, limited spectrum for very high such as underwater operation, limited spectrum for very high
skipping to change at page 5, line 11 skipping to change at page 5, line 11
o lack of (or severe constraints on) advanced services such as IP o lack of (or severe constraints on) advanced services such as IP
multicast multicast
2.2.1. Challenged Networks 2.2.1. Challenged Networks
A constrained network is not necessarily a _challenged_ network A constrained network is not necessarily a _challenged_ network
[FALL]: [FALL]:
Challenged Network: A network that has serious trouble maintaining Challenged Network: A network that has serious trouble maintaining
what an applicaton 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; o not being able to offer end-to-end IP connectivity at all;
o exhibiting serious interruptions in end-to-end IP connectivity; o exhibiting serious interruptions in end-to-end IP connectivity;
o exhibiting delay well beyond the MSL defined by TCP. o exhibiting delay well beyond the MSL defined by TCP.
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
skipping to change at page 6, line 11 skipping to change at page 6, line 11
automation (HVAC, lighting, access control, fire), connected home, automation (HVAC, lighting, access control, fire), connected home,
healthcare, environmental monitoring, urban sensor networks, healthcare, environmental monitoring, urban sensor networks,
energy management, assets tracking and refrigeration.. [sic] energy management, assets tracking and refrigeration.. [sic]
It is not clear that "LLN" is much more specific than "interesting" It is not clear that "LLN" is much more specific than "interesting"
or "the network characteristics that RPL has been designed for". or "the network characteristics that RPL has been designed for".
LLNs do appear to have significant loss at the physical layer, with LLNs do appear to have significant loss at the physical layer, with
significant variability of the delivery rate, and some short-term significant variability of the delivery rate, and some short-term
unreliability, coupled with some medium term stability that makes it unreliability, coupled with some medium term stability that makes it
worthwhile to construct medium-term stable directed acyclic graphs worthwhile to construct medium-term stable directed acyclic graphs
for routing and do measurements on the edges such as ETX. Actual for routing and do measurements on the edges such as ETX [RFC6551].
"low power" does not seem to be required for an LLN Actual "low power" does not seem to be required for an LLN
[I-D.hui-vasseur-roll-rpl-deployment], and the positions on scaling [I-D.hui-vasseur-roll-rpl-deployment], and the positions on scaling
of LLNs appear to vary widely [I-D.clausen-lln-rpl-experiences]. of LLNs appear to vary widely [I-D.clausen-lln-rpl-experiences].
Also, LLNs seem to be composed of constrained nodes; otherwise Also, LLNs seem to be composed of constrained nodes; otherwise
operation modes such as RPL's "non-storing mode" would not be operation modes such as RPL's "non-storing mode" would not be
sensible. So an LLN seems to be a constrained node network with sensible. So an LLN seems to be a constrained node network with
certain constraints on the network as well. certain constraints on the network as well.
2.3.2. LoWPAN, 6LoWPAN 2.3.2. LoWPAN, 6LoWPAN
skipping to change at page 6, line 47 skipping to change at page 7, line 13
[I-D.mariager-6lowpan-v6over-dect-ule]. [I-D.mariager-6lowpan-v6over-dect-ule].
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 following class designations may be used as rough document, the following class designations may be used as rough
indications of device capabilities: indications of device capabilities:
+---------+-----------------------+-------------------------+ +-------------+-----------------------+-------------------------+
| Name | data size (e.g., RAM) | code size (e.g., Flash) | | Name | data size (e.g., RAM) | code size (e.g., Flash) |
+---------+-----------------------+-------------------------+ +-------------+-----------------------+-------------------------+
| Class 0 | << 10 KiB | << 100 KiB | | Class 0, C0 | << 10 KiB | << 100 KiB |
| | | | | | | |
| Class 1 | ~ 10 KiB | ~ 100 KiB | | Class 1, C1 | ~ 10 KiB | ~ 100 KiB |
| | | | | | | |
| Class 2 | ~ 50 KiB | ~ 250 KiB | | Class 2, C2 | ~ 50 KiB | ~ 250 KiB |
+---------+-----------------------+-------------------------+ +-------------+-----------------------+-------------------------+
Table 1: Classes of Constrained Devices Table 1: Classes of Constrained Devices
As of the writing of this document, these characteristics correspond As of the writing of this document, these characteristics correspond
to distinguishable sets of commercially available chips and design to distinguishable sets of commercially available chips and design
cores for constrained devices. While it is expected that the 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
skipping to change at page 8, line 27 skipping to change at page 9, line 5
choose to support different functions. Even though Class 2 devices choose to support different functions. Even though Class 2 devices
have some more functionality available and may be able to provide a have some more functionality available and may be able to provide a
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. Security Considerations 4. Power Terminology
TBD Devices not only differ in their computing capabilities, but also in
available electrical power and/or energy. While it is harder to find
recognizable clusters in this space, it is still useful to introduce
some common terminology.
5. IANA Considerations 4.1. Scaling Properties
The power and/or energy available to a device may vastly differ, from
kilowatts to microwatts, from essentially unlimited to hundreds of
microjoules.
Instead of defining classes or clusters, we propose simply stating
one or both of the following quantities in SI units:
o Ps: Sustainable average power available for the device over the
time it is functioning (in W).
o Et: Total electrical energy available before the energy source is
exhausted (in J).
The value of Et may need to be interpreted in conjunction with an
indication over which period of time the value is given; see the next
subsection.
4.2. Energy Limitation Classes
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 E3. The energy limitation may be in total
energy available in the usable lifetime of the device (e.g. a device
with a non-replaceable primary battery, which is discarded when this
battery is exhausted), classified as E2. Where the relevant
limitation is for a specific period, this is classified as E1, e.g.
a limited amount of energy available for the night with a solar-
powered device, or for the period between recharges with a device
that is manually connected to a charger. Finally, there may be a
limited amount of energy available for a specific event, e.g. for a
button press in an energy harvesting light switch; this is classified
as E0. Note that many E1 devices in a sense also are E2, as the
rechargeable battery has a limited number of useful recharging
cycles.
In summary, we distinguish:
o E0: Event energy-limited
o E1: Period energy-limited
o E2: Lifetime energy-limited
o E3: No direct quantitative limitations to available energy
4.3. Power Usage Strategies
Especially when wireless transmission media is used, the radio often
consumes a big portion of the total energy consumed by the device.
Design parameters such as desired range and the spectrum available
and bitrate aimed for influence the power consumed during
transmission and reception; the duration of transmission and
reception (including potential reception) influence the total energy
consumption.
Based on the type of the energy source (e.g., battery or mains power)
and how often device needs to communicate, it may use different kinds
of strategies for power usage and network attachment.
The general strategies for power usage can be described as follows:
Always-on: This strategy is most applicable if there is no reason
for extreme measures for power saving. The device can stay on in
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.
Always-off: Under this strategy, the device sleeps such long periods
at a time that once it wakes up, it makes sense for it to not
pretend that it has been connected to the network during sleep:
The device re-attaches to the network as it is woken up. The main
optimization goal is to minimize the effort during such re-
attachment process and any resulting application communications.
If the device sleeps for long periods of time, for infrequent
communication the relative increase in energy expenditure during
reattachment may be acceptable.
Low-power: This strategy is most applicable to devices that need to
operate on a very small amount of power, but still need to be able
to communicate on a relatively frequent basis. This implies that
extremely low power solutions needs to be used for the hardware,
chosen link layer mechanisms, and so on. Typically, given the
small amount of time between transmissions, despite their sleep
state these devices retain some form of network attachment to the
network. Techniques used for minimizing power usage for the
network communications include minimizing any work from re-
establishing communications after waking up, tuning the frequency
of communications, and other parameters appropriately.
In summary, we distinguish the power usage strategies:
o S0: Always-off
o S1: Low-power
o S2: Always-on
5. Security Considerations
This draft introduces common terminology that does not raise any new
security issue.
6. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
6. Informative References 7. Acknowledgements
Ari Keranen, Dominique Barthel, and Peter van der Stok provided
useful comments.
Peter van der Stok insisted that we should have power terminology,
hence Section 4. The text for Section 4.3 is mostly lifted from
[I-D.arkko-lwig-cellular] and has been adapted for this document.
8. Informative References
[FALL] Fall, K., "A Delay-Tolerant Network Architecture for [FALL] Fall, K., "A Delay-Tolerant Network Architecture for
Challenged Internets", SIGCOMM 2003, 2003. Challenged Internets", SIGCOMM 2003, 2003.
[I-D.arkko-lwig-cellular]
Arkko, J., Eriksson, A., and A. Keraenen, "Building Power-
Efficient CoAP Devices for Cellular Networks", draft-
arkko-lwig-cellular-00 (work in progress), February 2013.
[I-D.clausen-lln-rpl-experiences] [I-D.clausen-lln-rpl-experiences]
Clausen, T., Verdiere, A., Yi, J., Herberg, U., and Y. Clausen, T., Verdiere, A., Yi, J., Herberg, U., and Y.
Igarashi, "Observations of RPL: IPv6 Routing Protocol for Igarashi, "Observations of RPL: IPv6 Routing Protocol for
Low power and Lossy Networks", draft-clausen-lln-rpl- Low power and Lossy Networks", draft-clausen-lln-rpl-
experiences-05 (work in progress), January 2013. experiences-06 (work in progress), February 2013.
[I-D.hui-vasseur-roll-rpl-deployment] [I-D.hui-vasseur-roll-rpl-deployment]
Vasseur, J., Hui, J., Dasgupta, S., and G. Yoon, "RPL Vasseur, J., Hui, J., Dasgupta, S., and G. Yoon, "RPL
deployment experience in large scale networks", draft-hui- deployment experience in large scale networks", draft-hui-
vasseur-roll-rpl-deployment-01 (work in progress), July vasseur-roll-rpl-deployment-01 (work in progress), July
2012. 2012.
[I-D.ietf-6lowpan-btle] [I-D.ietf-6lowpan-btle]
Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets
over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-12 over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-12
(work in progress), February 2013. (work in progress), February 2013.
[I-D.ietf-roll-terminology] [I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-11 (work in Networks", draft-ietf-roll-terminology-12 (work in
progress), February 2013. progress), March 2013.
[I-D.mariager-6lowpan-v6over-dect-ule] [I-D.mariager-6lowpan-v6over-dect-ule]
Mariager, P. and J. Petersen, "Transmission of IPv6 Mariager, P. and J. Petersen, "Transmission of IPv6
Packets over DECT Ultra Low Energy", draft-mariager- Packets over DECT Ultra Low Energy", draft-mariager-
6lowpan-v6over-dect-ule-02 (work in progress), May 2012. 6lowpan-v6over-dect-ule-02 (work in progress), May 2012.
[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.
[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D.
Barthel, "Routing Metrics Used for Path Calculation in
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.
[WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded [WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded
Internet", ISBN 9780470747995, 2009. Internet", ISBN 9780470747995, 2009.
[fifty-billion] [fifty-billion]
, "More Than 50 Billion Connected Devices", Ericsson White Ericsson, -., "More Than 50 Billion Connected Devices",
Paper 284 23-3149 Uen, February 2011, <http:// Ericsson White Paper 284 23-3149 Uen, February 2011,
www.ericsson.com/res/docs/whitepapers/wp-50-billions.pdf>. <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
Bremen D-28359 Bremen D-28359
Germany Germany
Phone: +49-421-218-63921 Phone: +49-421-218-63921
 End of changes. 18 change blocks. 
33 lines changed or deleted 167 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/