summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7228.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7228.txt')
-rw-r--r--doc/rfc/rfc7228.txt955
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc7228.txt b/doc/rfc/rfc7228.txt
new file mode 100644
index 0000000..819068d
--- /dev/null
+++ b/doc/rfc/rfc7228.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+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
+
+Abstract
+
+ The 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bormann, et al. Informational [Page 1]
+
+RFC 7228 CNN Terminology May 2014
+
+
+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.
+
+Table of Contents
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bormann, et al. Informational [Page 2]
+
+RFC 7228 CNN Terminology May 2014
+
+
+1. Introduction
+
+ Small devices with limited CPU, memory, and power resources, so-
+ called "constrained devices" (often used as sensors/actuators, smart
+ objects, or smart devices) can form a network, becoming "constrained
+ nodes" in that network. Such a network may itself exhibit
+ constraints, e.g., with unreliable or lossy channels, limited and
+ unpredictable bandwidth, and a highly dynamic topology.
+
+ Constrained devices might be in charge of gathering information in
+ diverse settings, including natural ecosystems, buildings, and
+ factories, and sending the information to one or more server
+ stations. They might also act on information, by performing some
+ physical action, including displaying it. Constrained devices may
+ work under severe resource constraints such as limited battery and
+ computing power, little memory, and insufficient wireless bandwidth
+ and ability to communicate; these constraints often exacerbate each
+ other. Other entities on the network, e.g., a base station or
+ controlling server, might have more computational and communication
+ resources and could support the interaction between the constrained
+ devices and applications in more traditional networks.
+
+ Today, diverse sizes of constrained devices with different resources
+ and capabilities are becoming connected. Mobile personal gadgets,
+ building-automation devices, cellular phones, machine-to-machine
+ (M2M) devices, and other devices benefit from interacting with other
+ "things" nearby or somewhere in the Internet. With this, the
+ Internet of Things (IoT) becomes a reality, built up out of uniquely
+ identifiable and addressable objects (things). Over the next decade,
+ this could grow to large numbers [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].
+
+
+
+
+
+
+
+
+Bormann, et al. Informational [Page 3]
+
+RFC 7228 CNN Terminology May 2014
+
+
+ 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.
+
+2. Core Terminology
+
+ There are two important aspects to _scaling_ within the Internet of
+ Things:
+
+ o scaling up Internet technologies to a large number [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".
+
+2.1. Constrained Nodes
+
+ The term "constrained node" is best defined by contrasting the
+ characteristics of a constrained node with certain widely held
+ expectations on more familiar Internet nodes:
+
+ Constrained Node: A node where some of the characteristics that are
+ otherwise pretty much taken for granted for Internet nodes at the
+ time of writing are not attainable, often due to cost constraints
+ and/or physical constraints on characteristics such as size,
+ weight, and available power and energy. The tight limits on
+ power, memory, and processing resources lead to hard upper bounds
+ on state, code space, and processing cycles, making optimization
+ of energy and network bandwidth usage a dominating consideration
+ in all design requirements. Also, some layer-2 services such as
+ full connectivity and broadcast/multicast may be lacking.
+
+ While this is not a rigorous definition, it is grounded in the state
+ of the art and clearly sets apart constrained nodes from server
+ systems, desktop or laptop computers, powerful mobile devices such as
+ smartphones, etc. There may be many design considerations that lead
+ to these constraints, including cost, size, weight, and other scaling
+ factors.
+
+
+
+
+
+
+
+Bormann, et al. Informational [Page 4]
+
+RFC 7228 CNN Terminology May 2014
+
+
+ (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".
+
+2.2. Constrained Networks
+
+ We define "constrained network" in a similar way:
+
+ Constrained Network: A network where some of the characteristics
+ pretty much taken for granted with link layers in common use in
+ the Internet at the time of writing are not attainable.
+
+ Constraints may include:
+
+ o low achievable bitrate/throughput (including limits on duty
+ cycle),
+
+ o high packet loss and high variability of packet loss (delivery
+ rate),
+
+
+
+
+Bormann, et al. Informational [Page 5]
+
+RFC 7228 CNN Terminology May 2014
+
+
+ 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.
+
+2.2.1. Challenged Networks
+
+ A constrained network is not necessarily a "challenged network"
+ [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
+
+
+
+Bormann, et al. Informational [Page 6]
+
+RFC 7228 CNN Terminology May 2014
+
+
+ * 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].
+
+2.3. Constrained-Node Networks
+
+ Constrained-Node Network: A network whose characteristics are
+ influenced by being composed of a significant portion of
+ constrained nodes.
+
+ A constrained-node network always is a constrained network because of
+ the network constraints stemming from the node constraints, but it
+ may also have other constraints that already make it a constrained
+ network.
+
+ The rest of this subsection introduces two additional terms that are
+ in active use in the area of constrained-node networks, without an
+ intent to define them: LLN and (6)LoWPAN.
+
+2.3.1. LLN
+
+ A related term that has been used to describe the focus of the IETF
+ ROLL working group is "Low-Power and Lossy Network (LLN)". The ROLL
+ (Routing Over Low-Power and Lossy) terminology document [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].
+
+
+
+Bormann, et al. Informational [Page 7]
+
+RFC 7228 CNN Terminology May 2014
+
+
+ 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.
+
+2.3.2. LoWPAN, 6LoWPAN
+
+ One interesting class of a constrained network often used as a
+ constrained-node network is "LoWPAN" [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].
+
+3. Classes of Constrained Devices
+
+ Despite the overwhelming variety of Internet-connected devices that
+ can be envisioned, it may be worthwhile to have some succinct
+ terminology for different classes of constrained devices. In this
+ document, the class designations in 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
+
+
+
+Bormann, et al. Informational [Page 8]
+
+RFC 7228 CNN Terminology May 2014
+
+
+ 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.
+
+
+
+Bormann, et al. Informational [Page 9]
+
+RFC 7228 CNN Terminology May 2014
+
+
+ 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.
+
+4. Power Terminology
+
+ Devices not only differ in their computing capabilities but also in
+ available power and/or energy. While it is harder to find
+ recognizable clusters in this space, it is still useful to introduce
+ some common terminology.
+
+4.1. Scaling Properties
+
+ The power and/or energy available to a device may vastly differ, from
+ kilowatts to microwatts, from essentially unlimited to hundreds of
+ microjoules.
+
+ Instead of defining classes or clusters, we simply state, using the
+ International System of Units (SI units), an approximate value for
+ one or both of the quantities listed in 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
+
+
+
+
+
+Bormann, et al. Informational [Page 10]
+
+RFC 7228 CNN Terminology May 2014
+
+
+ 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.
+
+4.2. Classes of Energy Limitation
+
+ As discussed above, some devices are limited in available energy as
+ opposed to (or in addition to) being limited in available power.
+ Where no relevant limitations exist with respect to energy, the
+ device is classified as E9. The energy limitation may be in total
+ energy available in the usable lifetime of the device (e.g., a device
+ that is discarded when its non-replaceable primary battery is
+ exhausted), classified as E2. Where the relevant limitation is for a
+ specific period, the device is classified as E1, e.g., a solar-
+ powered device with a limited amount of energy available for the
+ night, a device that is manually connected to a charger and has a
+ period of time between recharges, or a device with a periodic
+ (primary) battery replacement interval. Finally, there may be a
+ limited amount of energy available for a specific event, e.g., for a
+ button press in an energy-harvesting light switch; such devices are
+ classified as E0. Note that, in a sense, many E1 devices are also
+ E2, as the rechargeable battery has a limited number of useful
+ recharging cycles.
+
+ Table 3 provides a summary of the classifications described above.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bormann, et al. Informational [Page 11]
+
+RFC 7228 CNN Terminology May 2014
+
+
+ +------+------------------------------+-----------------------------+
+ | 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
+
+4.3. Strategies for Using Power for Communication
+
+ Especially when wireless transmission is used, the radio often
+ consumes a big portion of the total energy consumed by the device.
+ Design parameters, such as the available spectrum, the desired range,
+ and the bitrate aimed for, influence the power consumed during
+ transmission and reception; the duration of transmission and
+ reception (including potential reception) influence the total energy
+ consumption.
+
+ Different strategies for power usage and network attachment may be
+ used, based on the type of the energy source (e.g., battery or mains-
+ powered) and the frequency with which a device needs to communicate.
+
+ The general strategies for power usage can be described as follows:
+
+ Always-on: This strategy is most applicable if there is no reason
+ for extreme measures for power saving. The device can stay on in
+ the usual manner all the time. It may be useful to employ power-
+ friendly hardware or limit the number of wireless transmissions,
+ CPU speeds, and other aspects for general power-saving and cooling
+ needs, but the device can be connected to the network all the
+ time.
+
+ Normally-off: Under this strategy, the device sleeps such long
+ periods at a time that once it wakes up, it makes sense for it to
+ not pretend that it has been connected to the network during
+
+
+
+
+
+Bormann, et al. Informational [Page 12]
+
+RFC 7228 CNN Terminology May 2014
+
+
+ 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").
+
+
+
+
+
+
+Bormann, et al. Informational [Page 13]
+
+RFC 7228 CNN Terminology May 2014
+
+
+ [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.
+
+5. Security Considerations
+
+ This document introduces common terminology that does not raise any
+ new security issues. Security considerations arising from the
+ constraints discussed in this document need to be discussed in the
+ context of specific protocols. For instance, 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].
+
+6. Acknowledgements
+
+ Dominique Barthel and Peter van der Stok provided useful comments;
+ Charles Palmer provided a full editorial review.
+
+ Peter van der Stok insisted that we should include power terminology,
+ hence 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.
+
+7. Informative References
+
+ [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.
+
+
+
+
+
+
+
+
+Bormann, et al. Informational [Page 14]
+
+RFC 7228 CNN Terminology May 2014
+
+
+ [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.
+
+
+
+
+Bormann, et al. Informational [Page 15]
+
+RFC 7228 CNN Terminology May 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bormann, et al. Informational [Page 16]
+
+RFC 7228 CNN Terminology May 2014
+
+
+Authors' Addresses
+
+ Carsten Bormann
+ Universitaet Bremen TZI
+ Postfach 330440
+ D-28359 Bremen
+ Germany
+
+ Phone: +49-421-218-63921
+ EMail: cabo@tzi.org
+
+
+ Mehmet Ersue
+ Nokia Solutions and Networks
+ St.-Martinstrasse 76
+ 81541 Munich
+ Germany
+
+ Phone: +49 172 8432301
+ EMail: mehmet.ersue@nsn.com
+
+
+ Ari Keranen
+ Ericsson
+ Hirsalantie 11
+ 02420 Jorvas
+ Finland
+
+ EMail: ari.keranen@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bormann, et al. Informational [Page 17]
+