source: draft-ietf-lwig-terminology.mkd

Last change on this file was 41, checked in by cabo@…, 6 years ago

Always do the spell-check *after* submission :-)

File size: 27.1 KB
2title: Terminology for Constrained Node Networks
3abbrev: CNN terminology
4docname: draft-ietf-lwig-terminology-07
5date: 2014-02-10
7stand_alone: true
9ipr: trust200902
10area: Internet
11wg: LWIG Working Group
12kw: Internet-Draft
13cat: info
16  toc: yes
17  tocdepth: 4
18  sortrefs: yes
19  symrefs: yes
22      -
23        ins: C. Bormann
24        name: Carsten Bormann
25        org: Universitaet Bremen TZI
26        street: Postfach 330440
27        city: D-28359 Bremen
28        country: Germany
29        phone: +49-421-218-63921
30        email:
31      -
32        ins: M. Ersue
33        name: Mehmet Ersue
34        email:
35        org: Nokia Siemens Networks
36        street: St.-Martinstrasse 76
37        city: 81541 Munich
38        country: Germany
39        phone: +49 172 8432301
40      -
41        ins: A. Keranen
42        name: Ari Keranen
43        org: Ericsson
44        street: Hirsalantie 11
45        city: 02420 Jorvas
46        country: Finland
47        email:
49# normative:
50#  RFC2119:
52  I-D.ietf-core-coap: coap
53  I-D.ietf-6lowpan-btle: btle
54  I-D.mariager-6lowpan-v6over-dect-ule: dect-ule
55  I-D.brandt-6man-lowpanz: lowpanz
56  fifty-billion:
57    title: More Than 50 Billion Connected Devices
58    target:
59    date: 2011-02
60    author:
61      -
62        org: Ericsson
63    seriesinfo:
64      "Ericsson White Paper": "284 23-3149 Uen"
65  WEI:
66    title: "6LoWPAN: the Wireless Embedded Internet"
67    author:
68      -
69        ins: Z. Shelby
70        name: Zach Shelby
71      -
72        ins: C. Bormann
73        name: Carsten Bormann
74    date: 2009
75    seriesinfo:
76      ISBN: 9780470747995
77  FALL:
78    author:
79      ins: K. Fall
80      name: Kevin Fall
81    title: A Delay-Tolerant Network Architecture for Challenged Internets
82    date: 2003
83    seriesinfo:
84      SIGCOMM: 2003
85  ISQ-13:
86    author:
87      org: International Electrotechnical Commission
88    title: >-
89      International Standard --
90      Quantities and units -- Part 13: Information science and technology
91    date: 2008-03
92    seriesinfo:
93      IEC: 80000-13
95--- abstract
98The Internet Protocol Suite is increasingly used on small devices with
99severe constraints on power, memory and processing resources, creating constrained node networks.
100This document provides a number of basic terms that have turned out to
101be useful in the standardization work for constrained node networks.
103--- middle
108Small devices with limited CPU, memory, and power resources, so called
109constrained devices (often used as a sensor/actuator, a smart object,
110or a smart device) can
111form a network, becoming "constrained nodes" in that network.
112Such a network may itself exhibit constraints, e.g. with unreliable or
113lossy channels, limited and unpredictable bandwidth, and a highly
114dynamic topology.
116Constrained devices might be in charge of gathering information in
117diverse settings including natural ecosystems, buildings, and
118factories and sending the information to one or more server stations.
119They also act on information, by performing some
120physical action, including displaying it.
121Constrained devices may work under severe resource constraints such
122as limited battery and computing power, little memory, as well as
123insufficient wireless bandwidth and ability to communicate; these
124constraints often exacerbate each other.
125Other entities on the network, e.g., a base station or controlling
126server, might have more computational and communication resources and
127could support the interaction between the constrained devices and
128applications in more traditional networks.
130Today diverse sizes of constrained devices with different resources
131and capabilities are becoming connected.  Mobile personal gadgets,
132building-automation devices, cellular phones, Machine-to-machine (M2M)
133devices, etc. benefit from interacting with other "things" nearby
134or somewhere in the Internet.  With this, the Internet of Things (IoT)
135becomes a reality, built up out of uniquely identifiable and
136addressable objects (things).  And over the next decade, this could
137grow to large numbers {{fifty-billion}} of Internet-connected constrained
138devices, greatly increasing the Internet's size and scope.
140The present document provides a number of basic terms that have turned
141out to be useful in the standardization work for constrained
142environments.  The intention is not to exhaustively cover the field,
143but to make sure a few core terms are used consistently between
144different groups cooperating in this space.
146In this document, the term "byte" is used in its now customary sense
147as a synonym for "octet".  Where sizes of semiconductor memory are
148given, the prefix "kibi" (1024) is combined with "byte" to "kibibyte",
149abbreviated "KiB", for 1024 bytes {{ISQ-13}}.
151In computing, the term "power" is often used for the concept of
152"computing power" or "processing power", as in CPU performance.
153Unless explicitly stated otherwise, in this document the term stands
154for electrical power.  "Mains-powered" is used as a short-hand for
155being permanently connected to a stable electrical power grid.
157Core Terminology
160There are two important aspects to *scaling* within the Internet of Things:
162* Scaling up Internet technologies to a large number {{fifty-billion}} of
163  inexpensive nodes, while
164* scaling down the characteristics of each of these nodes and of the
165  networks being built out of them, to make this scaling up economically
166  and physically viable.
168The need for scaling down the characteristics of nodes leads to
169*constrained nodes*.
171Constrained Nodes
174The term "constrained node" is best defined by contrasting the
175characteristics of a constrained node with certain widely held
176expectations on more familiar Internet nodes:
178Constrained Node:
179: A node where some of the characteristics that are otherwise pretty
180  much taken for granted for Internet nodes at the time of writing are not
181  attainable, often due to cost constraints and/or physical
182  constraints on characteristics such as size, weight, and available
183  power and energy.
184  The tight limits on power, memory and processing resources lead to
185  hard upper bounds on state, code space and processing cycles, making
186  optimization of energy and network bandwidth usage a dominating
187  consideration in all design
188  requirements.  Also, some layer 2 services such as full connectivity
189  and broadcast/multicast may be lacking.
191While this is not a rigorous definition, it is
192grounded in the state of the art and clearly sets apart constrained
193nodes from server systems, desktop or laptop computers, powerful
194mobile devices such as smartphones etc.  There may be many design
195considerations that lead to these constraints, including cost, size,
196weight, and other scaling factors.
198(An alternative name, when the properties as a network node are not in
199focus, is "constrained device".)
201There are multiple facets to the constraints on nodes, often applying
202in combination, e.g.:
204* constraints on the maximum code complexity (ROM/Flash);
205* constraints on the size of state and buffers (RAM);
206* constraints on the amount of computation feasible in a period of
207  time ("processing power");
208* constraints on the available (electrical) power;
209* constraints on user interface and accessibility in deployment
210  (ability to set keys, update software, etc.).
212{{devclass}} defines a small number of interesting classes ("class-N"
213for N=0,1,2) of constrained nodes focusing on relevant combinations of
214the first two constraints.
215With respect to available (electrical) power, {{?RFC6606}} distinguishes
216"power-affluent" nodes (mains-powered or regularly recharged) from
217"power-constrained nodes" that draw their power from primary batteries
218or by using energy harvesting; more detailed power terminology is
219given in {{power}}.
221The use of constrained nodes in networks often also leads to
222constraints on the networks themselves.  However, there may also be
223constraints on networks that are largely independent from those of the
224nodes.  We therefore distinguish *constrained networks* and
225*constrained node networks*.
228[Editorial question: do you want to use capitalization for Constrained Node and Constrained Network and other terms you are defining?]
231Constrained Networks
234We define "constrained network" in a similar way:
236Constrained Network:
237: A network where some of the characteristics pretty much taken for
238  granted with link layers in common use in the Internet at the time
239  of writing, are
240  not attainable.
242Constraints may include:
244* low achievable bit rate/throughput (including limits on duty cycle),
245* high packet loss, high packet loss (delivery rate) variability,
246* highly asymmetric link characteristics,
247* severe penalties for using larger packets (e.g., high packet loss
248  due to link layer fragmentation),
249* limits on reachability over time (a substantial number of devices
250  may power off at any point in time but periodically "wake up" and
251  can communicate for brief periods of time)
252* lack of (or severe constraints on) advanced services such as IP multicast.
254More generally, we speak of constrained networks whenever at least
255some of the nodes involved in the network exhibit these
258Again, there may be several reasons for this:
260* cost constraints on the network,
261* constraints of the nodes (for constrained node networks),
262* physical constraints (e.g., power constraints, environmental
263  constraints, media constraints
264  such as underwater operation, limited spectrum for very high
265  density, electromagnetic compatibility),
266* regulatory constraints, such as very limited spectrum availability
267  (including limits on effective radiated power and duty cycle), or
268  explosion safety,
269* technology constraints, such as older and lower speed technologies that
270  are still operational and may need to stay in use for some more time.
272### Challenged Networks
274A constrained network is not necessarily a *challenged* network {{FALL}}:
276Challenged Network:
277: A network that has serious trouble maintaining what an application
278  would today expect of the end-to-end IP model, e.g., by:
280* not being able to offer end-to-end IP connectivity at all;
281* exhibiting serious interruptions in end-to-end IP connectivity;
282* exhibiting delay well beyond the Maximum Segment Lifetime (MSL)
283  defined by TCP {{?RFC0793}}.
285All challenged networks are constrained networks in some sense, but
286not all constrained networks are challenged networks.  There is no
287well-defined boundary between the two, though.  Delay-Tolerant
288Networking (DTN) has been designed to cope with challenged networks
291Constrained Node Networks
294Constrained Node Network:
295: A network whose characteristics are influenced by being composed of
296  a significant portion of constrained nodes.
298A constrained node network always is a constrained network because of
299the network constraints stemming from the node constraints, but may
300also have other constraints that already make it a constrained network.
302The rest of this subsection introduces two additional terms that are
303in active use in the area of constrained node networks, without an
304intent to define them: LLN and (6)LoWPAN.
306### LLN ("low-power lossy network")
308A related term that has been used to describe the focus of the IETF
309working group on Routing Over Low power and Lossy networks (ROLL) is
310"low-power lossy network" (LLN).  The ROLL terminology document
311{{?RFC7102}} defines LLNs as follows:
313>    LLN: Low power and Lossy networks (LLNs) are typically composed of
314>    many embedded devices with limited power, memory, and processing
315>    resources interconnected by a variety of links, such as IEEE 802.15.4
316>    or Low Power WiFi.  There is a wide scope of application areas for
317>    LLNs, including industrial monitoring, building automation (HVAC,
318>    lighting, access control, fire), connected home, healthcare,
319>    environmental monitoring, urban sensor networks, energy management,
320>    assets tracking and refrigeration.. \[sic\]
322Beyond that, LLNs often exhibit considerable loss at the
323physical layer, with significant variability of the delivery rate,
324and some short-term unreliability, coupled with some medium term
325stability that makes it worthwhile to construct medium-term stable
326directed acyclic graphs for routing and do measurements on the edges
327such as ETX {{?RFC6551}}.  Not all LLNs comprise low power nodes
330LLNs typically are composed
331of constrained nodes; this leads to the design of
332operation modes such as the "non-storing mode" defined by RPL (the
333IPv6 Routing Protocol for Low-Power and Lossy Networks {{?RFC6650}}).  So, in the
334terminology of the present document, an LLN is a constrained
335node network with certain network characteristics, which include
336constraints on the network as well.
338### LoWPAN, 6LoWPAN
340One interesting class of a constrained network often used as a
341constrained node network is the "LoWPAN" {{?RFC4919}}, a term inspired
342from the name of the IEEE 802.15.4 working group (low-rate wireless
343personal area networks (LR-WPANs)).  The expansion of that acronym,
344"Low-Power Wireless Personal Area Network" contains a hard to justify
345"Personal" that is due to the history of task group naming in IEEE 802
346more than due to an
347orientation of LoWPANs around a single person.  Actually, LoWPANs have
348been suggested for urban monitoring, control of large buildings, and
349industrial control applications, so the "Personal" can only be
350considered a vestige.  Occasionally the term is read as "Low-Power
351Wireless Area Networks" (LoWPANs) {{WEI}}.  Originally focused on IEEE
352802.15.4, "LoWPAN" (or when used for IPv6, "6LoWPAN") also refers to
353networks built from similarly constrained link layer
354technologies {{-btle}} {{-dect-ule}} {{-lowpanz}}.
357Classes of Constrained Devices {#devclass}
360Despite the overwhelming variety of Internet-connected devices that
361can be envisioned, it may be worthwhile to have some succinct
362terminology for different classes of constrained devices.  In this
363document, the class designations in {{devclasstbl}} may be used as rough
364indications of device capabilities:
366| Name        | data size (e.g., RAM) | code size (e.g., Flash) |
368| Class 0, C0 | << 10 KiB             | << 100 KiB              |
369| Class 1, C1 | ~ 10 KiB              | ~ 100 KiB               |
370| Class 2, C2 | ~ 50 KiB              | ~ 250 KiB               |
371{: #devclasstbl title="Classes of Constrained Devices (KiB = 1024 bytes)"}
374As of the writing of this document, these characteristics correspond
375to distinguishable clusters of commercially available chips and design
376cores for constrained devices.  While it is expected that the
377boundaries of these classes will move over time, Moore's law tends to
378be less effective in the embedded space than in personal computing
379devices: Gains made available by increases in transistor count and
380density are more likely to be invested in reductions of cost and power
381requirements than into continual increases in computing power.
383Class 0 devices are very constrained sensor-like motes.  They are so
384severely constrained in memory and processing capabilities that most
385likely they will not have the resources required to communicate
386directly with the Internet in a secure manner (rare heroic, narrowly
387targeted implementation efforts
388notwithstanding).  Class 0 devices will participate in Internet
389communications with the help of larger devices acting as proxies,
390gateways or servers.  Class 0 devices generally cannot be secured or managed
391comprehensively in the traditional sense.  They will most likely be
392preconfigured (and will be reconfigured rarely, if at all), with a very
393small data set.  For management purposes, they could answer keepalive
394signals and send on/off or basic health indications.
396Class 1 devices are quite constrained in code space and processing
397capabilities, such that they
398cannot easily talk to other Internet nodes employing a
399full protocol stack such as using HTTP, TLS and related security
400protocols and XML-based data representations.  However, they have
401enough power to use a protocol stack specifically designed for
402constrained nodes (such as CoAP over UDP {{-coap}}) and participate in meaningful
403conversations without the help of a gateway node.  In particular, they
404can provide support for the security functions required on a large
405network.  Therefore, they can be integrated as fully developed peers
406into an IP network, but they need to be parsimonious with state
407memory, code space, and often power expenditure for protocol and
408application usage.
410Class 2 devices are less constrained and fundamentally capable of
411supporting most of the same protocol stacks as used on
412notebooks or servers.  However, even these devices can benefit from
413lightweight and energy-efficient protocols and from consuming less
414bandwidth.  Furthermore, using fewer resources for networking leaves
415more resources available to applications.  Thus, using the protocol
416stacks defined for more constrained devices also on Class 2 devices
417might reduce development costs and increase the interoperability.
419Constrained devices with capabilities significantly beyond Class 2
420devices exist.  They are less demanding from a standards development
421point of view as they can largely use existing protocols unchanged.
422The present document therefore does not make any attempt to define
423classes beyond Class 2.  These devices can still be constrained by a
424limited energy supply.
426With respect to examining the capabilities of constrained nodes,
427particularly for Class 1 devices, it is important to understand what
428type of applications they are able to run and which protocol
429mechanisms would be most suitable.  Because of memory and other
430limitations, each specific Class 1 device might be able to support
431only a few selected functions needed for its intended operation.  In
432other words, the set of functions that can actually be supported is
433not static per device type: devices with similar constraints might
434choose to support different functions.  Even though Class 2 devices
435have some more functionality available and may be able to provide a
436more complete set of functions, they still need to be assessed for the
437type of applications they will be running and the protocol functions
438they would need.  To be able to derive any requirements, the use
439cases and the involvement of the devices in the application and the
440operational scenario need to be analyzed.  Use cases may combine
441constrained devices of multiple classes as well as more traditional
442Internet nodes.
443<!-- The use cases where Class 1
444or Class 2 devices build a cluster or are part of a hierarchy as well
445as the assumed degree of automation might be essentially important.
446 -->
450Power Terminology {#power}
453Devices not only differ in their computing capabilities, but also in
454available electrical power and/or energy.  While it is harder to find
455recognizable clusters in this space, it is still useful to introduce
456some common terminology.
458Scaling Properties
461The power and/or energy available to a device may vastly differ, from
462kilowatts to microwatts, from essentially unlimited to hundreds of
465Instead of defining classes or clusters, we simply state, in
466SI units, an approximate value for one or both of the quantities
467listed in {{scaletbl}}:
469| Name | Definition                                                                         | SI Unit   |
470| Ps   | Sustainable average power available for the device over the time it is functioning | W (Watt)  |
471| Et   | Total electrical energy available before the energy source is exhausted            | J (Joule) |
472{: #scaletbl title="Quantities Relevant to Power and Energy"}
474The value of Et may need to be interpreted in conjunction with an
475indication over which period of time the value is given; see the next
478Some devices enter a "low-power" mode before the energy available in a
479period is exhausted, or even have multiple such steps on the way to
480exhaustion.  For these devices, Ps would need to be given for each of
481the modes/steps.
483Classes of Energy Limitation
486As discussed above, some devices are limited in available energy as
487opposed to (or in addition to) being limited in available power.
488Where no relevant limitations exist with respect to energy, the device
489is classified as E9.
490The energy limitation may be in total energy available in the usable
491lifetime of the device (e.g. a device with a non-replaceable primary
492battery, which is discarded when this battery is exhausted),
493classified as E2.
494Where the relevant limitation is for a specific period, this is
495classified as E1, e.g. a limited amount of energy available for the
496night with a solar-powered device, or for the period between recharges
497with a device that is manually connected to a charger, or by a
498periodic (primary) battery replacement interval.
499Finally, there may be a limited amount of energy available for a specific
500event, e.g. for a button press in an energy harvesting light switch;
501this is classified as E0.
502Note that many E1 devices in a sense also are E2, as the rechargeable
503battery has a limited number of useful recharging cycles.
505In summary, we distinguish ({{enclasstbl}}):
507| Name | Type of energy limitation                              | Example Power Source                               |
509| E0   | Event energy-limited                                   | Event-based harvesting                             |
510| E1   | Period energy-limited                                  | Battery that is periodically recharged or replaced |
511| E2   | Lifetime energy-limited                                | Non-replaceable primary battery                    |
512| E9   | No direct quantitative limitations to available energy | Mains powered                                                    |
513{: #enclasstbl title="Classes of Energy Limitation"}
515Strategies of Using Power for Communication {#poweruse}
518Especially when wireless transmission is used, the radio often
519consumes a big portion of the total energy consumed by the device.
520Design parameters such as the available spectrum, the desired range,
521and the bitrate aimed for,
522influence the power consumed during transmission and reception; the
523duration of transmission and reception (including potential reception)
524influence the total energy consumption.
526Based on the type of the energy source (e.g., battery or mains power)
527and how often device needs to communicate, it may use different kinds
528of strategies for power usage and network attachment.
530The general strategies for power usage can be described as follows:
533: This strategy is most applicable if there is no reason for extreme
534measures for power saving.  The device can stay on in the usual manner
535all the time.  It may be useful to employ power-friendly hardware or
536limit the number of wireless transmissions, CPU speeds, and other
537aspects for general power saving and cooling needs, but the device can
538be connected to the network all the time.
541: Under this strategy, the device sleeps such long periods at a time
542that once it wakes up, it makes sense for it to not pretend that it
543has been connected to the network during sleep: The device re-attaches
544to the network as it is woken up.  The main optimization goal is to
545minimize the effort during such re-attachment process and any
546resulting application communications.
547: If the device sleeps for long periods of time, and needs to
548communicate infrequently, the relative increase in energy expenditure
549during reattachment may be acceptable.
552: This strategy is most applicable to devices that need to operate on
553a very small amount of power, but still need to be able to communicate
554on a relatively frequent basis. This implies that extremely low power
555solutions needs to be used for the hardware, chosen link layer
556mechanisms, and so on.  Typically, given the small amount of time
557between transmissions, despite their sleep state these devices retain
558some form of network attachment to the network.  Techniques used for
559minimizing power usage for the network communications include
560minimizing any work from re-establishing communications after waking
561up, tuning the frequency of communications (including "duty cycling",
562where components are switched on and off in a regular cycle), and other parameters
565In summary, we distinguish ({{powclasstbl}}):
567| Name | Strategy     | Ability to communicate                       |
569| P0   | Normally-off | Re-attach when required                      |
570| P1   | Low-power    | Appears connected, perhaps with high latency |
571| P9   | Always-on    | Always connected                             |
572{: #powclasstbl title="Strategies of Using Power for Communication"}
574Note that the discussion above is at the device level; similar
575considerations can apply at the communications interface level.
576This document does not define terminology for the latter.
578A term often used to describe power-saving approaches is
579"duty-cycling".  This describes all forms of periodically switching
580off some function, leaving it on only for a certain percentage of
581time (the "duty cycle").
583{{?RFC7102}} only distinguishes two levels, defining
584a Non-sleepy Node as a node that always remains in a fully powered on
585state (always awake) where it has the capability to perform
586communication (P9), and a Sleepy Node as a node that may sometimes go
587into a sleep mode (a low power state to conserve power) and
588temporarily suspend protocol communication (P0); there is no explicit
589mention of P1.
592Security Considerations
595This document introduces common terminology that does not raise any
596new security issue.  Security considerations arising from the
597constraints discussed in this document need to be discussed in the
598context of specific protocols.  For instance, {{-coap}} section 11.6,
599"Constrained node considerations", discusses implications of specific
600constraints on the security mechanisms employed.
601{{?I-D.ietf-roll-security-threats}} provides a security
602threat analysis for the RPL routing protocol.
603Implementation considerations for security protocols on constrained
604nodes are discussed in {{?I-D.ietf-lwig-ikev2-minimal}} and
606A wider view at security in constrained node networks is provided in
609IANA Considerations
612This document has no actions for IANA.
617Dominique Barthel and Peter van der Stok provided useful comments;
618Charles Palmer provided a full editorial review.
620Peter van der Stok insisted that we should have power terminology,
621hence {{power}}.
622The text for {{poweruse}} is mostly lifted from a previous version of
623{{?I-D.ietf-lwig-cellular}} and has been adapted for this document.
627<!--  LocalWords:  interoperability microwatts microjoules bitrate IP
628 -->
629<!--  LocalWords:  IANA Acknowledgements Ericsson LoWPAN Bormann MSL
630 -->
631<!--  LocalWords:  lossy Internet's multicast smartphones TCP DTN LLN
632 -->
633<!--  LocalWords:  IETF LLNs WiFi HVAC healthcare acyclic ETX RPL IPv
634 -->
635<!--  LocalWords:  IEEE WPANs LoWPANs Moore's preconfigured keepalive
636 -->
637<!--  LocalWords:  TLS CoAP UDP reachability
638 -->
Note: See TracBrowser for help on using the repository browser.