--- 1/draft-ietf-lwig-terminology-03.txt 2013-05-02 09:10:30.237452172 +0100 +++ 2/draft-ietf-lwig-terminology-04.txt 2013-05-02 09:10:30.901468666 +0100 @@ -1,21 +1,21 @@ LWIG Working Group C. Bormann Internet-Draft Universitaet Bremen TZI Intended status: Informational M. Ersue -Expires: October 02, 2013 Nokia Siemens Networks +Expires: October 25, 2013 Nokia Siemens Networks A. Keranen Ericsson - March 31, 2013 + April 23, 2013 Terminology for Constrained Node Networks - draft-ietf-lwig-terminology-03 + draft-ietf-lwig-terminology-04 Abstract The Internet Protocol Suite is increasingly used on small devices with severe constraints, creating constrained node networks. This document provides a number of basic terms that have turned out to be useful in the standardization work for constrained environments. Status of This Memo @@ -25,21 +25,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 02, 2013. + This Internet-Draft will expire on October 25, 2013. Copyright Notice Copyright (c) 2013 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 @@ -61,21 +61,21 @@ 2.3.2. LoWPAN, 6LoWPAN . . . . . . . . . . . . . . . . . . . 6 3. Classes of Constrained Devices . . . . . . . . . . . . . . . 7 4. Power Terminology . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Scaling Properties . . . . . . . . . . . . . . . . . . . 9 4.2. Classes of Energy Limitation . . . . . . . . . . . . . . 9 4.3. Strategies of Using Power for Communication . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 8. Informative References . . . . . . . . . . . . . . . . . . . 12 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction Small devices with limited CPU, memory, and power resources, so called constrained devices (also known as sensor, smart object, or smart device) can constitute 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. @@ -109,36 +109,36 @@ 2. Terminology The main focus of this field of work appears to be _scaling_: 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 - econmically and physically viable. + 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 in 2013 are not attainable, often due to cost constraints and/or physical constraints on characteristics such as size, weight, and available - power. + power and energy. While this is less than satisfying as a rigorous definition, it is 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. (An alternative name, when the properties as a network node are not in focus, is "constrained device".) @@ -149,21 +149,22 @@ o constraints on the size of state and buffers (RAM); o constraints on the available power. 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. + 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_ and _constrained node networks_. 2.2. Constrained Networks We define "constrained network" in a similar way: @@ -203,21 +204,22 @@ [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: o not being able to offer end-to-end IP connectivity at all; o exhibiting serious interruptions in end-to-end IP connectivity; - o exhibiting delay well beyond the MSL defined by TCP. + o exhibiting delay well beyond the Maximum Segment Lifetime (MSL) + defined by TCP [RFC0793]. All challenged networks are constrained networks in some sense, but 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 @@ -225,47 +227,50 @@ constrained nodes. A constrained node network always is a constrained network because of the network constraints stemming from the node constraints, but may also have other constraints that already make it a constrained network. 2.3.1. LLN ("low-power lossy network") A related term that has been used recently is "low-power lossy - network" (LLN). The ROLL working group currently is struggling with - its definition [I-D.ietf-roll-terminology]: + network" (LLN). In its terminology document, the ROLL working group + is saying [I-D.ietf-roll-terminology]: LLN: Low power and Lossy networks (LLNs) are 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 WiFi. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (HVAC, lighting, access control, fire), connected home, healthcare, environmental monitoring, urban sensor networks, energy management, assets tracking and refrigeration.. [sic] - It is not clear that "LLN" is much more specific than "interesting" - or "the network characteristics that RPL has been designed for". - LLNs do appear to have significant 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 construct medium-term stable directed acyclic graphs - for routing and do measurements on the edges such as ETX [RFC6551]. - Actual "low power" does not seem to be required for an LLN - [I-D.hui-vasseur-roll-rpl-deployment], and the positions on scaling - of LLNs appear to vary widely [I-D.clausen-lln-rpl-experiences]. + In common usage, LLN often stands for "the network characteristics + that RPL has been designed for". Beyond what is said in the ROLL + terminology document, LLNs do appear to have significant 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 construct medium-term stable + directed acyclic graphs for routing and do measurements on the edges + such as ETX [RFC6551]. Actual "low power" does not seem to be + required for an LLN [I-D.hui-vasseur-roll-rpl-deployment], and the + positions on scaling of LLNs appear to vary widely + [I-D.clausen-lln-rpl-experiences]. - Also, LLNs seem to be composed of constrained nodes; otherwise - operation modes such as RPL's "non-storing mode" would not be - sensible. So an LLN seems to be a constrained node network with - certain constraints on the network as well. + The ROLL terminology document states that LLNs typically are composed + of constrained nodes; this is also supported by the design of + operation modes such as RPL's "non-storing mode". So, in the + terminology of the present document, an LLN seems to be a constrained + node network with certain network characteristics, which include + constraints on the network as well. 2.3.2. LoWPAN, 6LoWPAN One interesting class of a constrained network often used as a constrained node network is the "LoWPAN" [RFC4919], a term inspired from the name of the IEEE 802.15.4 working group (low-rate wireless personal area networks (LR-WPANs)). The expansion of that acronym, "Low-Power Wireless Personal Area Network" contains a hard to justify "Personal" that is due to IEEE politics more than due to an orientation of LoWPANs around a single person. Actually, LoWPANs @@ -289,21 +294,21 @@ +-------------+-----------------------+-------------------------+ | 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 + 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. @@ -551,20 +556,23 @@ [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-12 (work in progress), March 2013. [I-D.mariager-6lowpan-v6over-dect-ule] Mariager, P. and J. Petersen, "Transmission of IPv6 Packets over DECT Ultra Low Energy", draft-mariager- 6lowpan-v6over-dect-ule-02 (work in progress), May 2012. + [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 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. [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D.