Internet Engineering Task Force (IETF) C. Bormann Request for Comments: 7228 Universitaet Bremen TZI Category: Informational M. Ersue ISSN: 2070-1721 Nokia Solutions and Networks A. Keranen Ericsson May 2014 Terminology for Constrained-Node Networks
AbstractThe Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7228.
Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction ....................................................3 2. Core Terminology ................................................4 2.1. Constrained Nodes ..........................................4 2.2. Constrained Networks .......................................5 2.2.1. Challenged Networks .................................6 2.3. Constrained-Node Networks ..................................7 2.3.1. LLN .................................................7 2.3.2. LoWPAN, 6LoWPAN .....................................8 3. Classes of Constrained Devices ..................................8 4. Power Terminology ..............................................10 4.1. Scaling Properties ........................................10 4.2. Classes of Energy Limitation ..............................11 4.3. Strategies for Using Power for Communication ..............12 5. Security Considerations ........................................14 6. Acknowledgements ...............................................14 7. Informative References .........................................14
FIFTY-BILLION] of Internet- connected constrained devices, greatly increasing the Internet's size and scope. The present document provides a number of basic terms that have been useful in the standardization work for constrained environments. The intention is not to exhaustively cover the field but to make sure a few core terms are used consistently between 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].
In computing, the term "power" is often used for the concept of "computing power" or "processing power", as in CPU performance. In this document, the term stands for electrical power unless explicitly stated otherwise. "Mains-powered" is used as a shorthand for being permanently connected to a stable electrical power grid. FIFTY-BILLION] of inexpensive nodes, while o scaling down the characteristics of each of these nodes and of the networks being built out of them, to make this scaling up economically and physically viable. The need for scaling down the characteristics of nodes leads to "constrained nodes".
(An alternative term, when the properties as a network node are not in focus, is "constrained device".) There are multiple facets to the constraints on nodes, often applying in combination, for example: o constraints on the maximum code complexity (ROM/Flash), o constraints on the size of state and buffers (RAM), o constraints on the amount of computation feasible in a period of time ("processing power"), o constraints on the available power, and o constraints on user interface and accessibility in deployment (ability to set keys, update software, etc.). Section 3 defines a small number of interesting classes ("class-N" for N = 0, 1, 2) of constrained nodes focusing on relevant combinations of the first two constraints. With respect to available power, [RFC6606] distinguishes "power-affluent" nodes (mains-powered or regularly recharged) from "power-constrained nodes" that draw their 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 constraints on the networks themselves. However, there may also be constraints on networks that are largely independent from those of the nodes. We therefore distinguish "constrained networks" from "constrained-node networks".
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), and 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: o cost constraints on the network, o constraints posed by the nodes (for constrained-node networks), o physical constraints (e.g., power constraints, environmental constraints, media constraints such as underwater operation, limited spectrum for very high density, electromagnetic compatibility), o regulatory constraints, such as very limited spectrum availability (including limits on effective radiated power and duty cycle) or explosion safety, and 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. FALL]: Challenged Network: A network that has serious trouble maintaining what an application would today expect of the end-to-end IP model, e.g., by: * not being able to offer end-to-end IP connectivity at all, * exhibiting serious interruptions in end-to-end IP connectivity, or
* exhibiting delay well beyond the Maximum Segment Lifetime (MSL) defined by TCP [RFC0793]. All challenged networks are constrained networks in some sense, but not all constrained networks are challenged networks. There is no well-defined boundary between the two, though. Delay-Tolerant Networking (DTN) has been designed to cope with challenged networks [RFC4838]. RFC7102] defines LLNs as follows: LLN: Low-Power and Lossy Network. Typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links, such as IEEE 802.15.4 or low-power Wi-Fi. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (heating, ventilation, and air conditioning (HVAC), lighting, access control, fire), connected home, health care, environmental monitoring, urban sensor networks, energy management, assets tracking, and refrigeration. Beyond that, LLNs often exhibit considerable loss at the physical layer, with significant variability of the delivery rate, and some short-term unreliability, coupled with some medium-term stability that makes it worthwhile to both construct directed acyclic graphs that are medium-term stable for routing and do measurements on the edges such as Expected Transmission Count (ETX) [RFC6551]. Not all LLNs comprise low-power nodes [RPL-DEPLOYMENT].
LLNs typically are composed of constrained nodes; this leads to the design of operation modes such as the "non-storing mode" defined by RPL (the IPv6 Routing Protocol for Low-Power and Lossy Networks [RFC6550]). So, in the terminology of the present document, an LLN is a constrained-node network with certain network characteristics, which include constraints on the network as well. RFC4919], a term inspired from the name of an IEEE 802.15.4 working group (low-rate wireless personal area networks (LR-WPANs)). The expansion of the LoWPAN acronym, "Low-Power Wireless Personal Area Network", contains a hard- to-justify "Personal" that is due to the history of task group naming in IEEE 802 more than due to an orientation of LoWPANs around a single person. Actually, LoWPANs have been suggested for urban monitoring, control of large buildings, and industrial control applications, so the "Personal" can only be considered a vestige. Occasionally, the term is read as "Low-Power Wireless Area Networks" [WEI]. Originally focused on IEEE 802.15.4, "LoWPAN" (or when used for IPv6, "6LoWPAN") also refers to networks built from similarly constrained link-layer technologies [V6-BTLE] [V6-DECT-ULE] [V6-G9959]. Table 1 may be used as rough indications of device capabilities: +-------------+-----------------------+-------------------------+ | Name | data size (e.g., RAM) | code size (e.g., Flash) | +-------------+-----------------------+-------------------------+ | Class 0, C0 | << 10 KiB | << 100 KiB | | | | | | Class 1, C1 | ~ 10 KiB | ~ 100 KiB | | | | | | Class 2, C2 | ~ 50 KiB | ~ 250 KiB | +-------------+-----------------------+-------------------------+ Table 1: Classes of Constrained Devices (KiB = 1024 bytes) As of the writing of this document, these characteristics correspond to distinguishable clusters of commercially available chips and design cores for constrained devices. While it is expected that the
boundaries of these classes will move over time, Moore's law tends to be less effective in the embedded space than in personal computing devices: gains made available by increases in transistor count and density are more likely to be invested in reductions of cost and power requirements than into continual increases in computing power. Class 0 devices are very constrained sensor-like motes. They are so severely constrained in memory and processing capabilities that most likely they will not have the resources required to communicate directly with the Internet in a secure manner (rare heroic, narrowly targeted implementation efforts notwithstanding). Class 0 devices will participate in Internet communications with the help of larger devices acting as proxies, gateways, or servers. Class 0 devices generally cannot be secured or managed comprehensively in the 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 are quite constrained in code space and processing capabilities, such that they cannot easily talk to other Internet nodes employing a full protocol stack such as using HTTP, Transport Layer Security (TLS), and related security protocols and XML-based data representations. However, they are capable enough to use a protocol stack specifically designed for constrained nodes (such as the Constrained Application Protocol (CoAP) over UDP [COAP]) and participate in meaningful conversations without the help of a gateway node. In particular, they can provide support for the security functions required on a large network. Therefore, they can be integrated as fully developed peers into an IP network, but they need to be parsimonious with state memory, code space, and often power expenditure for protocol and application usage. Class 2 devices are less constrained and fundamentally capable of supporting most of the same protocol stacks as used on notebooks or servers. However, even these devices can benefit from lightweight and energy-efficient protocols and from consuming less bandwidth. Furthermore, using fewer resources for networking leaves more resources available to applications. Thus, using the protocol stacks defined for more constrained devices on Class 2 devices might reduce development costs and increase the interoperability. Constrained devices with capabilities significantly beyond Class 2 devices exist. They are less demanding from a standards development point of view as they can largely use existing protocols unchanged. The present document therefore does not make any attempt to define classes beyond Class 2. These devices can still be constrained by a limited energy supply.
With respect to examining the capabilities of constrained nodes, particularly for Class 1 devices, it is important to understand what type of applications they are able to run and which protocol mechanisms would be most suitable. Because of memory and other limitations, each specific Class 1 device might be able to support only a few selected functions needed for its intended operation. In other words, the set of functions that can actually be supported is not static per device type: devices with similar constraints might choose to support different functions. Even though Class 2 devices have some more functionality available and may be able to provide a more complete set of functions, they still need to be assessed for the type of applications they will be running and the protocol functions they would need. To be able to derive any requirements, the use cases and the involvement of the devices in the application and the operational scenario need to be analyzed. Use cases may combine constrained devices of multiple classes as well as more traditional Internet nodes. Table 2: +------+--------------------------------------------------+---------+ | Name | Definition | SI Unit | +------+--------------------------------------------------+---------+ | Ps | Sustainable average power available for the | W | | | device over the time it is functioning | (Watt) | | | | | | Et | Total electrical energy available before the | J | | | energy source is exhausted | (Joule) | +------+--------------------------------------------------+---------+ Table 2: Quantities Relevant to Power and Energy
The value of Et may need to be interpreted in conjunction with an indication over which period of time the value is given; see Section 4.2. Some devices enter a "low-power" mode before the energy available in a period is exhausted or even have multiple such steps on the way to exhaustion. For these devices, Ps would need to be given for each of the modes/steps. Table 3 provides a summary of the classifications described above.
+------+------------------------------+-----------------------------+ | Name | Type of energy limitation | Example Power Source | +------+------------------------------+-----------------------------+ | E0 | Event energy-limited | Event-based harvesting | | | | | | E1 | Period energy-limited | Battery that is | | | | periodically recharged or | | | | replaced | | | | | | E2 | Lifetime energy-limited | Non-replaceable primary | | | | battery | | | | | | E9 | No direct quantitative | Mains-powered | | | limitations to available | | | | energy | | +------+------------------------------+-----------------------------+ Table 3: Classes of Energy Limitation
sleep: the device reattaches to the network as it is woken up. The main optimization goal is to minimize the effort during the reattachment process and any resulting application communications. If the device sleeps for long periods of time and needs to communicate infrequently, the relative increase in energy expenditure during reattachment may be acceptable. Low-power: This strategy is most applicable to devices that need to operate on a very small amount of power but still need to be able to communicate on a relatively frequent basis. This implies that extremely low-power solutions need to be used for the hardware, chosen link-layer mechanisms, and so on. Typically, given the small amount of time between transmissions, despite their sleep state, these devices retain some form of attachment to the network. Techniques used for minimizing power usage for the network communications include minimizing any work from re- establishing communications after waking up and tuning the frequency of communications (including "duty cycling", where components are switched on and off in a regular cycle) and other parameters appropriately. Table 4 provides a summary of the strategies described above. +------+--------------+---------------------------------------------+ | Name | Strategy | Ability to communicate | +------+--------------+---------------------------------------------+ | P0 | Normally-off | Reattach when required | | | | | | P1 | Low-power | Appears connected, perhaps with high | | | | latency | | | | | | P9 | Always-on | Always connected | +------+--------------+---------------------------------------------+ 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. A term often used to describe power-saving approaches is "duty- cycling". This describes all forms of periodically switching off some function, leaving it on only for a certain percentage of time (the "duty cycle").
[RFC7102] only distinguishes two levels, defining a Non-Sleepy Node as a node that always remains in a fully powered-on state (always awake) where it has the capability to perform communication (P9) and a Sleepy Node as a node that may sometimes go into a sleep mode (a low-power state to conserve power) and temporarily suspend protocol communication (P0); there is no explicit mention of P1. Section 11.6 of [COAP], "Constrained node considerations", discusses implications of specific constraints on the security mechanisms employed. [ROLL-SEC-THREATS] provides a security threat analysis for the RPL routing protocol. Implementation considerations for security protocols on constrained nodes are discussed in [IKEV2-MINIMAL] and [TLS-MINIMAL]. A wider view of security in constrained-node networks is provided in [IOT-SECURITY]. Section 4. The text for Section 4.3 is mostly lifted from a previous version of [COAP-CELLULAR] and has been adapted for this document. [COAP] Shelby, Z., Hartke, K., and C. Bormann, "Constrained Application Protocol (CoAP)", Work in Progress, June 2013. [COAP-CELLULAR] Arkko, J., Eriksson, A., and A. Keranen, "Building Power- Efficient CoAP Devices for Cellular Networks", Work in Progress, February 2014. [FALL] Fall, K., "A Delay-Tolerant Network Architecture for Challenged Internets", SIGCOMM 2003, 2003.
[FIFTY-BILLION] Ericsson, "More Than 50 Billion Connected Devices", Ericsson White Paper 284 23-3149 Uen, February 2011, <http://www.ericsson.com/res/docs/whitepapers/ wp-50-billions.pdf>. [IKEV2-MINIMAL] Kivinen, T., "Minimal IKEv2", Work in Progress, October 2013. [IOT-SECURITY] Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and R. Struik, "Security Considerations in the IP-based Internet of Things", Work in Progress, September 2013. [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 793, September 1981. [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, April 2007. [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, August 2007. [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012. [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", RFC 6551, March 2012. [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing", RFC 6606, May 2012. [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and Lossy Networks", RFC 7102, January 2014.
[ROLL-SEC-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)", Work in Progress, December 2013. [RPL-DEPLOYMENT] Vasseur, J., Ed., Hui, J., Ed., Dasgupta, S., and G. Yoon, "RPL deployment experience in large scale networks", Work in Progress, July 2012. [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", Work in Progress, March 2014. [V6-BTLE] Nieminen, J., Ed., Savolainen, T., Ed., Isomaki, M., Patil, B., Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets over BLUETOOTH Low Energy", Work in Progress, May 2014. [V6-DECT-ULE] Mariager, P., Ed., Petersen, J., and Z. Shelby, "Transmission of IPv6 Packets over DECT Ultra Low Energy", Work in Progress, July 2013. [V6-G9959] Brandt, A. and J. Buron, "Transmission of IPv6 packets over ITU-T G.9959 Networks", Work in Progress, May 2014. [WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded Internet", ISBN 9780470747995, 2009.