draft-ietf-lwig-terminology-04.txt   draft-ietf-lwig-terminology-05.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 25, 2013 Nokia Siemens Networks Expires: January 10, 2014 Nokia Siemens Networks
A. Keranen A. Keranen
Ericsson Ericsson
April 23, 2013 July 09, 2013
Terminology for Constrained Node Networks Terminology for Constrained Node Networks
draft-ietf-lwig-terminology-04 draft-ietf-lwig-terminology-05
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 25, 2013. This Internet-Draft will expire on January 10, 2014.
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
described in the Simplified BSD License. described in the Simplified BSD License.
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") . . . . . . . . . . . 6
2.3.2. LoWPAN, 6LoWPAN . . . . . . . . . . . . . . . . . . . 6 2.3.2. LoWPAN, 6LoWPAN . . . . . . . . . . . . . . . . . . . 6
3. Classes of Constrained Devices . . . . . . . . . . . . . . . 7 3. Classes of Constrained Devices . . . . . . . . . . . . . . . 8
4. Power Terminology . . . . . . . . . . . . . . . . . . . . . . 9 4. Power Terminology . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Scaling Properties . . . . . . . . . . . . . . . . . . . 9 4.1. Scaling Properties . . . . . . . . . . . . . . . . . . . 10
4.2. Classes of Energy Limitation . . . . . . . . . . . . . . 9 4.2. Classes of Energy Limitation . . . . . . . . . . . . . . 10
4.3. Strategies of Using Power for Communication . . . . . . . 10 4.3. Strategies of Using Power for Communication . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
8. Informative References . . . . . . . . . . . . . . . . . . . 12 8. Informative References . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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.
Constrained devices might be in charge of gathering information in Constrained devices might be in charge of gathering information in
diverse settings including natural ecosystems, buildings, and diverse settings including natural ecosystems, buildings, and
factories and sending the information to one or more server stations. factories and sending the information to one or more server stations.
Constrained devices may work under severe resource constraints such Constrained devices may work under severe resource constraints such
as limited battery and computing power, little memory and as limited battery and computing power, little memory, as well as
insufficient wireless bandwidth, and communication capabilities. insufficient wireless bandwidth and ability to communicate. Other
Other entities on the network, e.g., a base station or controlling entities on the network, e.g., a base station or controlling server,
server, might have more computational and communication resources and might have more computational and communication resources and could
could support the interaction between the constrained devices and support the interaction between the constrained devices and
applications in more traditional networks. applications in more traditional networks.
Today diverse sizes of constrained devices with different resources Today diverse sizes of constrained devices with different resources
and capabilities are becoming connected. Mobile personal gadgets, and capabilities are becoming connected. Mobile personal gadgets,
building-automation devices, cellular phones, Machine-to-machine building-automation devices, cellular phones, Machine-to-machine
(M2M) devices, etc. benefit from interacting with other "things" (M2M) devices, etc. benefit from interacting with other "things"
nearby or somewhere in the Internet. With this, the Internet of nearby or somewhere in the Internet. With this, the Internet of
Things (IoT) becomes a reality, built up out of uniquely identifiable Things (IoT) becomes a reality, built up out of uniquely identifiable
and addressable objects (things). And over the next decade, this and addressable objects (things). And over the next decade, this
could grow to large numbers [fifty-billion] of Internet-connected could grow to large numbers [fifty-billion] of Internet-connected
constrained devices, greatly increasing the Internet's size and constrained devices, greatly increasing the Internet's size and
scope. scope.
The present document provides a number of basic terms that have The present document provides a number of basic terms that have
turned out to be useful in the standardization work for constrained turned out to be useful in the standardization work for constrained
environments. The intention is not to exhaustively cover the field, environments. The intention is not to exhaustively cover the field,
but to make sure a few core terms are used consistently between but to make sure a few core terms are used consistently between
different groups cooperating in this space. different groups cooperating in this space.
In this document, the term "byte" is used in its now customary sense
as a synonym for "octet". Where sizes of semiconductor memory are
given, the prefix "kibi" (1024) is combined with "byte" to
"kibibyte", abbreviated "KiB", for 1024 bytes [ISQ-13].
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
economically and physically viable. economically and physically viable.
skipping to change at page 4, line 32 skipping to change at page 4, line 38
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 2013 are pretty much taken for granted with link layers in common use in
not attainable. the Internet by 2013, are 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, environmental
such as underwater operation, limited spectrum for very high constraints, media constraints such as underwater operation,
density, electromagnetic compatibility), limited spectrum for very high density, electromagnetic
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
that are still operational and may need to stay in use for some
more time.
Constraints may include: Constraints may include:
o low achievable bit rate (including limits on duty cycle), o low achievable bit rate (including limits on duty cycle),
o high packet loss, packet loss (delivery rate) variability, o high packet loss, packet loss (delivery rate) variability,
o severe penalties for using larger packets (e.g., high packet loss o severe penalties for using larger packets (e.g., high packet loss
due to link layer fragmentation), due to link layer fragmentation),
o 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
skipping to change at page 6, line 40 skipping to change at page 6, line 51
node network with certain network characteristics, which include node network with certain network characteristics, which include
constraints on the network as well. 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 the history of task group naming in IEEE
orientation of LoWPANs around a single person. Actually, LoWPANs 802 more than due to an orientation of LoWPANs around a single
have been suggested for urban monitoring, control of large buildings, person. Actually, LoWPANs have been suggested for urban monitoring,
and industrial control applications, so the "Personal" can only be control of large buildings, and industrial control applications, so
considered a vestige. Maybe the term is best read as "Low-Power the "Personal" can only be considered a vestige. Maybe the term is
Wireless Area Networks" (LoWPANs) [WEI]. Originally focused on IEEE best read as "Low-Power Wireless Area Networks" (LoWPANs) [WEI].
802.15.4, "LoWPAN" (or when used for IPv6, "6LoWPAN") is now also Originally focused on IEEE 802.15.4, "LoWPAN" (or when used for IPv6,
being used for networks built from similarly constrained link layer "6LoWPAN") is now also being used for networks built from similarly
technologies [I-D.ietf-6lowpan-btle] constrained link layer technologies [I-D.ietf-6lowpan-btle]
[I-D.mariager-6lowpan-v6over-dect-ule] [I-D.brandt-6man-lowpanz]. [I-D.mariager-6lowpan-v6over-dect-ule] [I-D.brandt-6man-lowpanz].
3. Classes of Constrained Devices 3. Classes of Constrained Devices
Despite the overwhelming variety of Internet-connected devices that Despite the overwhelming variety of Internet-connected devices that
can be envisioned, it may be worthwhile to have some succinct can be envisioned, it may be worthwhile to have some succinct
terminology for different classes of constrained devices. In this terminology for different classes of constrained devices. In this
document, the class designations in Table 1 may be used as rough document, the class designations in Table 1 may be used as rough
indications of device capabilities: indications of device capabilities:
skipping to change at page 12, line 5 skipping to change at page 12, line 42
+------+------------+----------------------------------------------+ +------+------------+----------------------------------------------+
| S0 | Always-off | Re-attach when required | | S0 | Always-off | Re-attach when required |
| | | | | | | |
| S1 | Low-power | Appears connected, perhaps with high latency | | S1 | Low-power | Appears connected, perhaps with high latency |
| | | | | | | |
| S2 | Always-on | Always connected | | S2 | Always-on | Always connected |
+------+------------+----------------------------------------------+ +------+------------+----------------------------------------------+
Table 4: Strategies of Using Power for Communication Table 4: Strategies of Using Power for Communication
Note that the discussion above is at the device level; similar
considerations can apply at the communications interface level. This
document does not define terminology for the latter.
5. Security Considerations 5. Security Considerations
This draft introduces common terminology that does not raise any new This document introduces common terminology that does not raise any
security issue. new security issue. Security considerations arising from the
constraints discussed in this document need to be discussed in the
context of specific protocols. For instance, [I-D.ietf-core-coap]
section 11.6, "Constrained node considerations", discusses
implications of specific constraints on the security mechanisms
employed.
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 12, line 35 skipping to change at page 13, line 40
[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] [I-D.arkko-lwig-cellular]
Arkko, J., Eriksson, A., and A. Keraenen, "Building Power- Arkko, J., Eriksson, A., and A. Keraenen, "Building Power-
Efficient CoAP Devices for Cellular Networks", draft- Efficient CoAP Devices for Cellular Networks", draft-
arkko-lwig-cellular-00 (work in progress), February 2013. arkko-lwig-cellular-00 (work in progress), February 2013.
[I-D.brandt-6man-lowpanz] [I-D.brandt-6man-lowpanz]
Brandt, A. and J. Buron, "Transmission of IPv6 packets Brandt, A. and J. Buron, "Transmission of IPv6 packets
over ITU-T G.9959 Networks", draft-brandt-6man-lowpanz-00 over ITU-T G.9959 Networks", draft-brandt-6man-lowpanz-02
(work in progress), February 2013. (work in progress), June 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-06 (work in progress), February 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-core-coap]
Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-18
(work in progress), June 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-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.
[ISQ-13] International Electrotechnical Commission, "International
Standard -- Quantities and units -- Part 13: Information
science and technology", IEC 80000-13, March 2008.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981. 793, September 1981.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, April 2007. Networking Architecture", RFC 4838, April 2007.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs): over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals", RFC Overview, Assumptions, Problem Statement, and Goals", RFC
 End of changes. 18 change blocks. 
39 lines changed or deleted 68 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/