draft-ietf-lwig-terminology-06.txt   draft-ietf-lwig-terminology-07.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: June 21, 2014 Nokia Siemens Networks Expires: August 14, 2014 Nokia Siemens Networks
A. Keranen A. Keranen
Ericsson Ericsson
December 18, 2013 February 10, 2014
Terminology for Constrained Node Networks Terminology for Constrained Node Networks
draft-ietf-lwig-terminology-06 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 turned out to be useful in the
standardization work for constrained node networks. standardization work for constrained node networks.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 June 21, 2014. This Internet-Draft will expire on August 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
skipping to change at page 2, line 23 skipping to change at page 2, line 23
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 . . . . . . . . . . . . . . . . 6
2.3.1. LLN ("low-power lossy network") . . . . . . . . . . . 7 2.3.1. LLN ("low-power lossy network") . . . . . . . . . . . 7
2.3.2. LoWPAN, 6LoWPAN . . . . . . . . . . . . . . . . . . . 7 2.3.2. LoWPAN, 6LoWPAN . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . 10
4.3. Strategies of Using Power for Communication . . . . . . . 11 4.3. Strategies of Using Power for Communication . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
8. Informative References . . . . . . . . . . . . . . . . . . . 14 8. Informative References . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 a sensor/actuator, a smart
object, or a smart device) can form a network, becoming "constrained object, or a smart device) 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
skipping to change at page 5, line 27 skipping to change at page 5, line 27
_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:
o low achievable bit rate/throughput (including limits on duty
cycle),
o high packet loss, high packet loss (delivery rate) variability,
o highly asymmetric link characteristics,
o severe penalties for using larger packets (e.g., high packet loss
due to link layer fragmentation),
o limits on reachability over time (a substantial number of devices
may power off at any point in time but periodically "wake up" and
can communicate for brief periods of time)
o lack of (or severe constraints on) advanced services such as IP
multicast.
More generally, we speak of constrained networks whenever at least
some of the nodes involved in the network exhibit these
characteristics.
Again, there may be several reasons for this: 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, 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,
skipping to change at page 5, line 46 skipping to change at page 6, line 19
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,
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.
Constraints may include:
o low achievable bit rate (including limits on duty cycle),
o high packet loss, packet loss (delivery rate) variability,
o highly asymmetric link characteristics,
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 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; o not being able to offer end-to-end IP connectivity at all;
skipping to change at page 7, line 10 skipping to change at page 7, line 14
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 ("low-power lossy network")
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 working group on Routing Over Low power and Lossy networks (ROLL) is
"low-power lossy network" (LLN). The ROLL terminology document "low-power lossy network" (LLN). The ROLL terminology document
[I-D.ietf-roll-terminology] defines LLNs as follows: [RFC7102] defines LLNs as follows:
LLN: Low power and Lossy networks (LLNs) are typically composed of LLN: Low power and Lossy networks (LLNs) are typically composed of
many embedded devices with limited power, memory, and processing many 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 WiFi. 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 (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]
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 construct medium-term stable directed
acyclic graphs for routing and do measurements on the edges such as acyclic graphs for routing and do measurements on the edges such as
ETX [RFC6551]. Actual "low power" does not seem to be a defining ETX [RFC6551]. Not all LLNs comprise low power nodes
characteristic for an LLN [I-D.hui-vasseur-roll-rpl-deployment]. [I-D.hui-vasseur-roll-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 [RFC6650]). 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
skipping to change at page 8, line 34 skipping to change at page 8, line 39
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. Most likely Class 0 devices are very constrained sensor-like motes. They are so
they will not be able to communicate directly with the Internet in a severely constrained in memory and processing capabilities that most
secure manner. Class 0 devices will participate in Internet likely they will not have the resources required to communicate
communications with the help of larger devices acting as proxies, directly with the Internet in a secure manner (rare heroic, narrowly
gateways or servers. Class 0 devices generally cannot be secured or targeted implementation efforts notwithstanding). Class 0 devices
managed comprehensively in the traditional sense. They will most will participate in Internet communications with the help of larger
likely be preconfigured (and will be reconfigured rarely, if at all), devices acting as proxies, gateways or servers. Class 0 devices
with a very small data set. For management purposes, they could generally cannot be secured or managed comprehensively in the
answer keepalive signals and send on/off or basic health indications. traditional sense. They will most likely be preconfigured (and will
be reconfigured rarely, if at all), with a very small data set. For
management purposes, they could answer keepalive signals and send on/
off or basic health indications.
Class 1 devices cannot easily talk to other Internet nodes employing Class 1 devices are quite constrained in code space and processing
a full protocol stack such as using HTTP, TLS and related security capabilities, such that they cannot easily talk to other Internet
protocols and XML-based data representations. However, they have nodes employing a full protocol stack such as using HTTP, TLS and
enough power to use a protocol stack specifically designed for related security protocols and XML-based data representations.
constrained nodes (such as CoAP over UDP [I-D.ietf-core-coap]) and However, they have enough power to use a protocol stack specifically
participate in meaningful conversations without the help of a gateway designed for constrained nodes (such as CoAP over UDP
node. In particular, they can provide support for the security [I-D.ietf-core-coap]) and participate in meaningful conversations
functions required on a large network. Therefore, they can be without the help of a gateway node. In particular, they can provide
integrated as fully developed peers into an IP network, but they need support for the security functions required on a large network.
to be parsimonious with state memory, code space, and often power Therefore, they can be integrated as fully developed peers into an IP
expenditure for protocol and application usage. network, but they need to be parsimonious with state memory, code
space, and often power expenditure for protocol and application
usage.
Class 2 can already support mostly the same protocol stacks as used Class 2 devides are less constrained and fundamentally capable of
on notebooks or servers. However, even these devices can benefit supporting most of the same protocol stacks as used on notebooks or
from lightweight and energy-efficient protocols and from consuming servers. However, even these devices can benefit from lightweight
less bandwidth. Furthermore, using fewer resources for networking and energy-efficient protocols and from consuming less bandwidth.
leaves more resources available to applications. Thus, using the Furthermore, using fewer resources for networking leaves more
protocol stacks defined for very constrained devices also on Class 2 resources available to applications. Thus, using the protocol stacks
devices might reduce development costs and increase the defined for more constrained devices also on Class 2 devices might
interoperability. reduce 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 13, line 14 skipping to change at page 13, line 14
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").
[I-D.ietf-roll-terminology] only distinguishes two levels, defining a [RFC7102] only distinguishes two levels, defining a Non-sleepy Node
Non-sleepy Node as a node that always remains in a fully powered on as a node that always remains in a fully powered on state (always
state (always awake) where it has the capability to perform awake) where it has the capability to perform communication (P9), and
communication (P9), and a Sleepy Node as a node that may sometimes go a Sleepy Node as a node that may sometimes go into a sleep mode (a
into a sleep mode (a low power state to conserve power) and low power state to conserve power) and temporarily suspend protocol
temporarily suspend protocol communication (P0); there is no explicit communication (P0); there is no explicit mention of P1.
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 issue. 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, [I-D.ietf-core-coap]
section 11.6, "Constrained node considerations", discusses section 11.6, "Constrained node considerations", discusses
implications of specific constraints on the security mechanisms implications of specific constraints on the security mechanisms
employed. A wider view at security in constrained node networks is employed. [I-D.ietf-roll-security-threats] provides a security
provided in [I-D.garcia-core-security]. threat analysis for the RPL routing protocol. Implementation
considerations for security protocols on constrained nodes are
discussed in [I-D.ietf-lwig-ikev2-minimal] and
[I-D.ietf-lwig-tls-minimal]. A wider view at security in constrained
node networks is provided in [I-D.garcia-core-security].
6. IANA Considerations 6. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
7. Acknowledgements 7. 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.
skipping to change at page 15, line 19 skipping to change at page 14, line 43
[I-D.ietf-core-coap] [I-D.ietf-core-coap]
Shelby, Z., Hartke, K., and C. Bormann, "Constrained Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-18 Application Protocol (CoAP)", draft-ietf-core-coap-18
(work in progress), June 2013. (work in progress), June 2013.
[I-D.ietf-lwig-cellular] [I-D.ietf-lwig-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", draft-ietf-
lwig-cellular-00 (work in progress), August 2013. lwig-cellular-00 (work in progress), August 2013.
[I-D.ietf-roll-terminology] [I-D.ietf-lwig-ikev2-minimal]
Vasseur, J., "Terms used in Routing for Low power And Kivinen, T., "Minimal IKEv2", draft-ietf-lwig-
Lossy Networks", draft-ietf-roll-terminology-13 (work in ikev2-minimal-01 (work in progress), October 2013.
progress), October 2013.
[I-D.ietf-lwig-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", draft-
ietf-lwig-tls-minimal-00 (work in progress), September
2013.
[I-D.ietf-roll-security-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)", draft-
ietf-roll-security-threats-06 (work in progress), December
2013.
[I-D.mariager-6lowpan-v6over-dect-ule] [I-D.mariager-6lowpan-v6over-dect-ule]
Mariager, P., Petersen, J., and Z. Shelby, "Transmission Mariager, P., Petersen, J., and Z. Shelby, "Transmission
of IPv6 Packets over DECT Ultra Low Energy", draft- of IPv6 Packets over DECT Ultra Low Energy", draft-
mariager-6lowpan-v6over-dect-ule-03 (work in progress), mariager-6lowpan-v6over-dect-ule-03 (work in progress),
July 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.
skipping to change at page 16, line 11 skipping to change at page 15, line 47
[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 [RFC6650] Falk, J. and M. Kucherawy, "Creation and Use of Email
Feedback Reports: An Applicability Statement for the Abuse Feedback Reports: An Applicability Statement for the Abuse
Reporting Format (ARF)", RFC 6650, June 2012. Reporting Format (ARF)", RFC 6650, June 2012.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, January 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] [fifty-billion]
Ericsson, "More Than 50 Billion Connected Devices", Ericsson, "More Than 50 Billion Connected Devices",
Ericsson White Paper 284 23-3149 Uen, February 2011, Ericsson White Paper 284 23-3149 Uen, February 2011,
<http://www.ericsson.com/res/docs/whitepapers/ <http://www.ericsson.com/res/docs/whitepapers/
wp-50-billions.pdf>. wp-50-billions.pdf>.
Authors' Addresses Authors' Addresses
 End of changes. 18 change blocks. 
66 lines changed or deleted 99 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/