draft-ietf-lwig-terminology-03.txt   draft-ietf-lwig-terminology-04.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: October 02, 2013 Nokia Siemens Networks Expires: October 25, 2013 Nokia Siemens Networks
A. Keranen A. Keranen
Ericsson Ericsson
March 31, 2013 April 23, 2013
Terminology for Constrained Node Networks Terminology for Constrained Node Networks
draft-ietf-lwig-terminology-03 draft-ietf-lwig-terminology-04
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 36 skipping to change at page 1, line 36
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 October 02, 2013. This Internet-Draft will expire on October 25, 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 26 skipping to change at page 2, line 26
2.3.2. LoWPAN, 6LoWPAN . . . . . . . . . . . . . . . . . . . 6 2.3.2. LoWPAN, 6LoWPAN . . . . . . . . . . . . . . . . . . . 6
3. Classes of Constrained Devices . . . . . . . . . . . . . . . 7 3. Classes of Constrained Devices . . . . . . . . . . . . . . . 7
4. Power Terminology . . . . . . . . . . . . . . . . . . . . . . 9 4. Power Terminology . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Scaling Properties . . . . . . . . . . . . . . . . . . . 9 4.1. Scaling Properties . . . . . . . . . . . . . . . . . . . 9
4.2. Classes of Energy Limitation . . . . . . . . . . . . . . 9 4.2. Classes of Energy Limitation . . . . . . . . . . . . . . 9
4.3. Strategies of Using Power for Communication . . . . . . . 10 4.3. Strategies of Using Power for Communication . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. Informative References . . . . . . . . . . . . . . . . . . . 12 8. Informative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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 (also known as sensor, smart object, or called constrained devices (also known as sensor, smart object, or
smart device) can constitute a network, becoming "constrained nodes" smart device) can constitute a network, becoming "constrained nodes"
in that network. Such a network may itself exhibit constraints, e.g. in 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 26 skipping to change at page 3, line 26
2. Terminology 2. Terminology
The main focus of this field of work appears to be _scaling_: The main focus of this field of work appears to be _scaling_:
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
econmically 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 in 2013 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 and energy.
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. There may be many design mobile devices such as smartphones etc. There may be many design
considerations that lead to these constraints, including cost, size, considerations that lead to these constraints, including cost, size,
weight, and other scaling factors. weight, and other scaling factors.
(An alternative name, when the properties as a network node are not (An alternative name, when the properties as a network node are not
in focus, is "constrained device".) in focus, is "constrained device".)
skipping to change at page 4, line 18 skipping to change at page 4, line 18
o constraints on the size of state and buffers (RAM); o constraints on the size of state and buffers (RAM);
o constraints on the available power. o constraints on the available power.
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 combinations
of the first two constraints. With respect to available power, of the first two constraints. With respect to available power,
[RFC6606] distinguishes "power-affluent" nodes (mains-powered or [RFC6606] distinguishes "power-affluent" nodes (mains-powered or
regularly recharged) from "power-constrained nodes" that draw their regularly recharged) from "power-constrained nodes" that draw their
power from primary batteries or by using energy harvesting. power from primary batteries or by using energy harvesting; 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_ 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:
skipping to change at page 5, line 25 skipping to change at page 5, line 25
[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;
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 Maximum Segment Lifetime (MSL)
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
skipping to change at page 5, line 47 skipping to change at page 5, line 48
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 may
also have other constraints that already make it a constrained also have other constraints that already make it a constrained
network. network.
2.3.1. LLN ("low-power lossy network") 2.3.1. LLN ("low-power lossy network")
A related term that has been used recently is "low-power lossy A related term that has been used recently is "low-power lossy
network" (LLN). The ROLL working group currently is struggling with network" (LLN). In its terminology document, the ROLL working group
its definition [I-D.ietf-roll-terminology]: is saying [I-D.ietf-roll-terminology]:
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]
It is not clear that "LLN" is much more specific than "interesting" In common usage, LLN often stands for "the network characteristics
or "the network characteristics that RPL has been designed for". that RPL has been designed for". Beyond what is said in the ROLL
LLNs do appear to have significant loss at the physical layer, with terminology document, LLNs do appear to have significant loss at the
significant variability of the delivery rate, and some short-term physical layer, with significant variability of the delivery rate,
unreliability, coupled with some medium term stability that makes it and some short-term unreliability, coupled with some medium term
worthwhile to construct medium-term stable directed acyclic graphs stability that makes it worthwhile to construct medium-term stable
for routing and do measurements on the edges such as ETX [RFC6551]. directed acyclic graphs for routing and do measurements on the edges
Actual "low power" does not seem to be required for an LLN such as ETX [RFC6551]. Actual "low power" does not seem to be
[I-D.hui-vasseur-roll-rpl-deployment], and the positions on scaling required for an LLN [I-D.hui-vasseur-roll-rpl-deployment], and the
of LLNs appear to vary widely [I-D.clausen-lln-rpl-experiences]. 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 The ROLL terminology document states that LLNs typically are composed
operation modes such as RPL's "non-storing mode" would not be of constrained nodes; this is also supported by the design of
sensible. So an LLN seems to be a constrained node network with operation modes such as RPL's "non-storing mode". So, in the
certain constraints on the network as well. terminology of the present document, an LLN seems to be a constrained
node network with certain network characteristics, 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 the "LoWPAN" [RFC4919], a term inspired
from the name of the IEEE 802.15.4 working group (low-rate wireless from the name of the 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 that acronym,
"Low-Power Wireless Personal Area Network" contains a hard to justify "Low-Power Wireless Personal Area Network" contains a hard to justify
"Personal" that is due to IEEE politics more than due to an "Personal" that is due to IEEE politics more than due to an
orientation of LoWPANs around a single person. Actually, LoWPANs orientation of LoWPANs around a single person. Actually, LoWPANs
skipping to change at page 7, line 23 skipping to change at page 7, line 23
+-------------+-----------------------+-------------------------+ +-------------+-----------------------+-------------------------+
| Name | data size (e.g., RAM) | code size (e.g., Flash) | | Name | data size (e.g., RAM) | code size (e.g., Flash) |
+-------------+-----------------------+-------------------------+ +-------------+-----------------------+-------------------------+
| Class 0, C0 | << 10 KiB | << 100 KiB | | Class 0, C0 | << 10 KiB | << 100 KiB |
| | | | | | | |
| Class 1, C1 | ~ 10 KiB | ~ 100 KiB | | Class 1, C1 | ~ 10 KiB | ~ 100 KiB |
| | | | | | | |
| Class 2, C2 | ~ 50 KiB | ~ 250 KiB | | Class 2, C2 | ~ 50 KiB | ~ 250 KiB |
+-------------+-----------------------+-------------------------+ +-------------+-----------------------+-------------------------+
Table 1: Classes of Constrained Devices 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.
skipping to change at page 13, line 17 skipping to change at page 13, line 17
[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-12 (work in Networks", draft-ietf-roll-terminology-12 (work in
progress), March 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.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
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.
[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D.
 End of changes. 14 change blocks. 
26 lines changed or deleted 34 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/