source: draft-ietf-lwig-terminology.xml

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

Submit lwig-terminology -07

File size: 54.5 KB
Line 
1<?xml version="1.0" encoding="UTF-8"?>
2  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
3
4<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
5]>
6
7<rfc ipr="trust200902" docName="draft-ietf-lwig-terminology-07" category="info">
8
9<?rfc toc="yes"?>
10<?rfc tocdepth="4"?>
11<?rfc sortrefs="yes"?>
12<?rfc symrefs="yes"?>
13
14  <front>
15    <title abbrev="CNN terminology">Terminology for Constrained Node Networks</title>
16
17    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
18      <organization>Universitaet Bremen TZI</organization>
19      <address>
20        <postal>
21          <street>Postfach 330440</street>
22          <city>D-28359 Bremen</city>
23         
24         
25          <country>Germany</country>
26        </postal>
27        <phone>+49-421-218-63921</phone>
28       
29        <email>cabo@tzi.org</email>
30       
31      </address>
32    </author>
33    <author initials="M." surname="Ersue" fullname="Mehmet Ersue">
34      <organization>Nokia Siemens Networks</organization>
35      <address>
36        <postal>
37          <street>St.-Martinstrasse 76</street>
38          <city>81541 Munich</city>
39         
40         
41          <country>Germany</country>
42        </postal>
43        <phone>+49 172 8432301</phone>
44       
45        <email>mehmet.ersue@nsn.com</email>
46       
47      </address>
48    </author>
49    <author initials="A." surname="Keranen" fullname="Ari Keranen">
50      <organization>Ericsson</organization>
51      <address>
52        <postal>
53          <street>Hirsalantie 11</street>
54          <city>02420 Jorvas</city>
55         
56         
57          <country>Finland</country>
58        </postal>
59       
60       
61        <email>ari.keranen@ericsson.com</email>
62       
63      </address>
64    </author>
65
66    <date year="2014" month="February" day="10"/>
67
68    <area>Internet</area>
69    <workgroup>LWIG Working Group</workgroup>
70    <keyword>Internet-Draft</keyword>
71
72    <abstract>
73
74
75<t>The Internet Protocol Suite is increasingly used on small devices with
76severe constraints on power, memory and processing resources, creating constrained node networks.
77This document provides a number of basic terms that have turned out to
78be useful in the standardization work for constrained node networks.</t>
79
80
81
82    </abstract>
83
84
85  </front>
86
87  <middle>
88
89
90<section anchor="introduction" title="Introduction">
91
92<t>Small devices with limited CPU, memory, and power resources, so called
93constrained devices (often used as a sensor/actuator, a smart object,
94or a smart device) can
95form a network, becoming “constrained nodes” in that network.
96Such a network may itself exhibit constraints, e.g. with unreliable or
97lossy channels, limited and unpredictable bandwidth, and a highly
98dynamic topology.</t>
99
100<t>Constrained devices might be in charge of gathering information in
101diverse settings including natural ecosystems, buildings, and
102factories and sending the information to one or more server stations.
103They also act on information, by performing some
104physical action, including displaying it.
105Constrained devices may work under severe resource constraints such
106as limited battery and computing power, little memory, as well as
107insufficient wireless bandwidth and ability to communicate; these
108constraints often exacerbate each other.
109Other entities on the network, e.g., a base station or controlling
110server, might have more computational and communication resources and
111could support the interaction between the constrained devices and
112applications in more traditional networks.</t>
113
114<t>Today diverse sizes of constrained devices with different resources
115and capabilities are becoming connected.  Mobile personal gadgets,
116building-automation devices, cellular phones, Machine-to-machine (M2M)
117devices, etc. benefit from interacting with other “things” nearby
118or somewhere in the Internet.  With this, the Internet of Things (IoT)
119becomes a reality, built up out of uniquely identifiable and
120addressable objects (things).  And over the next decade, this could
121grow to large numbers <xref target="fifty-billion"/> of Internet-connected constrained
122devices, greatly increasing the Internet’s size and scope.</t>
123
124<t>The present document provides a number of basic terms that have turned
125out to be useful in the standardization work for constrained
126environments.  The intention is not to exhaustively cover the field,
127but to make sure a few core terms are used consistently between
128different groups cooperating in this space.</t>
129
130<t>In this document, the term “byte” is used in its now customary sense
131as a synonym for “octet”.  Where sizes of semiconductor memory are
132given, the prefix “kibi” (1024) is combined with “byte” to “kibibyte”,
133abbreviated “KiB”, for 1024 bytes <xref target="ISQ-13"/>.</t>
134
135<t>In computing, the term “power” is often used for the concept of
136“computing power” or “processing power”, as in CPU performance.
137Unless explicitly stated otherwise, in this document the term stands
138for electrical power.  “Mains-powered” is used as a short-hand for
139being permanently connected to a stable electrical power grid.</t>
140
141</section>
142<section anchor="core-terminology" title="Core Terminology">
143
144<t>There are two important aspects to <spanx style="emph">scaling</spanx> within the Internet of Things:</t>
145
146<t><list style="symbols">
147  <t>Scaling up Internet technologies to a large number <xref target="fifty-billion"/> of
148inexpensive nodes, while</t>
149  <t>scaling down the characteristics of each of these nodes and of the
150networks being built out of them, to make this scaling up economically
151and physically viable.</t>
152</list></t>
153
154<t>The need for scaling down the characteristics of nodes leads to
155<spanx style="emph">constrained nodes</spanx>.</t>
156
157<section anchor="constrained-nodes" title="Constrained Nodes">
158
159<t>The term “constrained node” is best defined by contrasting the
160characteristics of a constrained node with certain widely held
161expectations on more familiar Internet nodes:</t>
162
163<t><list style="hanging">
164  <t hangText='Constrained Node:'>
165  A node where some of the characteristics that are otherwise pretty
166much taken for granted for Internet nodes at the time of writing are not
167attainable, often due to cost constraints and/or physical
168constraints on characteristics such as size, weight, and available
169power and energy.
170The tight limits on power, memory and processing resources lead to
171hard upper bounds on state, code space and processing cycles, making
172optimization of energy and network bandwidth usage a dominating
173consideration in all design
174requirements.  Also, some layer 2 services such as full connectivity
175and broadcast/multicast may be lacking.</t>
176</list></t>
177
178<t>While this is not a rigorous definition, it is
179grounded in the state of the art and clearly sets apart constrained
180nodes from server systems, desktop or laptop computers, powerful
181mobile devices such as smartphones etc.  There may be many design
182considerations that lead to these constraints, including cost, size,
183weight, and other scaling factors.</t>
184
185<t>(An alternative name, when the properties as a network node are not in
186focus, is “constrained device”.)</t>
187
188<t>There are multiple facets to the constraints on nodes, often applying
189in combination, e.g.:</t>
190
191<t><list style="symbols">
192  <t>constraints on the maximum code complexity (ROM/Flash);</t>
193  <t>constraints on the size of state and buffers (RAM);</t>
194  <t>constraints on the amount of computation feasible in a period of
195time (“processing power”);</t>
196  <t>constraints on the available (electrical) power;</t>
197  <t>constraints on user interface and accessibility in deployment
198(ability to set keys, update software, etc.).</t>
199</list></t>
200
201<t><xref target="devclass"/> defines a small number of interesting classes (“class-N”
202for N=0,1,2) of constrained nodes focusing on relevant combinations of
203the first two constraints.
204With respect to available (electrical) power, <xref target="RFC6606"/> distinguishes
205“power-affluent” nodes (mains-powered or regularly recharged) from
206“power-constrained nodes” that draw their power from primary batteries
207or by using energy harvesting; more detailed power terminology is
208given in <xref target="power"/>.</t>
209
210<t>The use of constrained nodes in networks often also leads to
211constraints on the networks themselves.  However, there may also be
212constraints on networks that are largely independent from those of the
213nodes.  We therefore distinguish <spanx style="emph">constrained networks</spanx> and
214<spanx style="emph">constrained node networks</spanx>.</t>
215
216<!--
217[Editorial question: do you want to use capitalization for Constrained Node and Constrained Network and other terms you are defining?]
218-->
219
220</section>
221<section anchor="constrained-networks" title="Constrained Networks">
222
223<t>We define “constrained network” in a similar way:</t>
224
225<t><list style="hanging">
226  <t hangText='Constrained Network:'>
227  A network where some of the characteristics pretty much taken for
228granted with link layers in common use in the Internet at the time
229of writing, are
230not attainable.</t>
231</list></t>
232
233<t>Constraints may include:</t>
234
235<t><list style="symbols">
236  <t>low achievable bit rate/throughput (including limits on duty cycle),</t>
237  <t>high packet loss, high packet loss (delivery rate) variability,</t>
238  <t>highly asymmetric link characteristics,</t>
239  <t>severe penalties for using larger packets (e.g., high packet loss
240due to link layer fragmentation),</t>
241  <t>limits on reachability over time (a substantial number of devices
242may power off at any point in time but periodically “wake up” and
243can communicate for brief periods of time)</t>
244  <t>lack of (or severe constraints on) advanced services such as IP multicast.</t>
245</list></t>
246
247<t>More generally, we speak of constrained networks whenever at least
248some of the nodes involved in the network exhibit these
249characteristics.</t>
250
251<t>Again, there may be several reasons for this:</t>
252
253<t><list style="symbols">
254  <t>cost constraints on the network,</t>
255  <t>constraints of the nodes (for constrained node networks),</t>
256  <t>physical constraints (e.g., power constraints, environmental
257constraints, media constraints
258such as underwater operation, limited spectrum for very high
259density, electromagnetic compatibility),</t>
260  <t>regulatory constraints, such as very limited spectrum availability
261(including limits on effective radiated power and duty cycle), or
262explosion safety,</t>
263  <t>technology constraints, such as older and lower speed technologies that
264are still operational and may need to stay in use for some more time.</t>
265</list></t>
266
267<section anchor="challenged-networks" title="Challenged Networks">
268
269<t>A constrained network is not necessarily a <spanx style="emph">challenged</spanx> network <xref target="FALL"/>:</t>
270
271<t><list style="hanging">
272  <t hangText='Challenged Network:'>
273  A network that has serious trouble maintaining what an application
274would today expect of the end-to-end IP model, e.g., by:</t>
275</list></t>
276
277<t><list style="symbols">
278  <t>not being able to offer end-to-end IP connectivity at all;</t>
279  <t>exhibiting serious interruptions in end-to-end IP connectivity;</t>
280  <t>exhibiting delay well beyond the Maximum Segment Lifetime (MSL)
281defined by TCP <xref target="RFC0793"/>.</t>
282</list></t>
283
284<t>All challenged networks are constrained networks in some sense, but
285not all constrained networks are challenged networks.  There is no
286well-defined boundary between the two, though.  Delay-Tolerant
287Networking (DTN) has been designed to cope with challenged networks
288<xref target="RFC4838"/>.</t>
289
290</section>
291</section>
292<section anchor="constrained-node-networks" title="Constrained Node Networks">
293
294<t><list style="hanging">
295  <t hangText='Constrained Node Network:'>
296  A network whose characteristics are influenced by being composed of
297a significant portion of constrained nodes.</t>
298</list></t>
299
300<t>A constrained node network always is a constrained network because of
301the network constraints stemming from the node constraints, but may
302also have other constraints that already make it a constrained network.</t>
303
304<t>The rest of this subsection introduces two additional terms that are
305in active use in the area of constrained node networks, without an
306intent to define them: LLN and (6)LoWPAN.</t>
307
308<section anchor="lln-low-power-lossy-network" title="LLN (“low-power lossy network”)">
309
310<t>A related term that has been used to describe the focus of the IETF
311working group on Routing Over Low power and Lossy networks (ROLL) is
312“low-power lossy network” (LLN).  The ROLL terminology document
313<xref target="RFC7102"/> defines LLNs as follows:</t>
314
315<t><list style='empty'>
316  <t>LLN: Low power and Lossy networks (LLNs) are typically composed of
317   many embedded devices with limited power, memory, and processing
318   resources interconnected by a variety of links, such as IEEE 802.15.4
319   or Low Power WiFi.  There is a wide scope of application areas for
320   LLNs, including industrial monitoring, building automation (HVAC,
321   lighting, access control, fire), connected home, healthcare,
322   environmental monitoring, urban sensor networks, energy management,
323   assets tracking and refrigeration.. [sic]</t>
324</list></t>
325
326<t>Beyond that, LLNs often exhibit considerable loss at the
327physical layer, with significant variability of the delivery rate,
328and some short-term unreliability, coupled with some medium term
329stability that makes it worthwhile to construct medium-term stable
330directed acyclic graphs for routing and do measurements on the edges
331such as ETX <xref target="RFC6551"/>.  Not all LLNs comprise low power nodes
332<xref target="I-D.hui-vasseur-roll-rpl-deployment"/>.</t>
333
334<t>LLNs typically are composed
335of constrained nodes; this leads to the design of
336operation modes such as the “non-storing mode” defined by RPL (the
337IPv6 Routing Protocol for Low-Power and Lossy Networks <xref target="RFC6650"/>).  So, in the
338terminology of the present document, an LLN is a constrained
339node network with certain network characteristics, which include
340constraints on the network as well.</t>
341
342</section>
343<section anchor="lowpan-6lowpan" title="LoWPAN, 6LoWPAN">
344
345<t>One interesting class of a constrained network often used as a
346constrained node network is the “LoWPAN” <xref target="RFC4919"/>, a term inspired
347from the name of the IEEE 802.15.4 working group (low-rate wireless
348personal area networks (LR-WPANs)).  The expansion of that acronym,
349“Low-Power Wireless Personal Area Network” contains a hard to justify
350“Personal” that is due to the history of task group naming in IEEE 802
351more than due to an
352orientation of LoWPANs around a single person.  Actually, LoWPANs have
353been suggested for urban monitoring, control of large buildings, and
354industrial control applications, so the “Personal” can only be
355considered a vestige.  Occasionally the term is read as “Low-Power
356Wireless Area Networks” (LoWPANs) <xref target="WEI"/>.  Originally focused on IEEE
357802.15.4, “LoWPAN” (or when used for IPv6, “6LoWPAN”) also refers to
358networks built from similarly constrained link layer
359technologies <xref target="I-D.ietf-6lowpan-btle"/> <xref target="I-D.mariager-6lowpan-v6over-dect-ule"/> <xref target="I-D.brandt-6man-lowpanz"/>.</t>
360
361</section>
362</section>
363</section>
364<section anchor="devclass" title="Classes of Constrained Devices">
365
366<t>Despite the overwhelming variety of Internet-connected devices that
367can be envisioned, it may be worthwhile to have some succinct
368terminology for different classes of constrained devices.  In this
369document, the class designations in <xref target="devclasstbl"/> may be used as rough
370indications of device capabilities:</t>
371
372<texttable title="Classes of Constrained Devices (KiB = 1024 bytes)" anchor="devclasstbl">
373      <ttcol align='left'>Name</ttcol>
374      <ttcol align='left'>data size (e.g., RAM)</ttcol>
375      <ttcol align='left'>code size (e.g., Flash)</ttcol>
376      <c>Class 0, C0</c>
377      <c>« 10 KiB</c>
378      <c>« 100 KiB</c>
379      <c>Class 1, C1</c>
380      <c>~ 10 KiB</c>
381      <c>~ 100 KiB</c>
382      <c>Class 2, C2</c>
383      <c>~ 50 KiB</c>
384      <c>~ 250 KiB</c>
385</texttable>
386
387<t>As of the writing of this document, these characteristics correspond
388to distinguishable clusters of commercially available chips and design
389cores for constrained devices.  While it is expected that the
390boundaries of these classes will move over time, Moore’s law tends to
391be less effective in the embedded space than in personal computing
392devices: Gains made available by increases in transistor count and
393density are more likely to be invested in reductions of cost and power
394requirements than into continual increases in computing power.</t>
395
396<t>Class 0 devices are very constrained sensor-like motes.  They are so
397severely constrained in memory and processing capabilities that most
398likely they will not have the resources required to communicate
399directly with the Internet in a secure manner (rare heroic, narrowly
400targeted implementation efforts
401notwithstanding).  Class 0 devices will participate in Internet
402communications with the help of larger devices acting as proxies,
403gateways or servers.  Class 0 devices generally cannot be secured or managed
404comprehensively in the traditional sense.  They will most likely be
405preconfigured (and will be reconfigured rarely, if at all), with a very
406small data set.  For management purposes, they could answer keepalive
407signals and send on/off or basic health indications.</t>
408
409<t>Class 1 devices are quite constrained in code space and processing
410capabilities, such that they
411cannot easily talk to other Internet nodes employing a
412full protocol stack such as using HTTP, TLS and related security
413protocols and XML-based data representations.  However, they have
414enough power to use a protocol stack specifically designed for
415constrained nodes (such as CoAP over UDP <xref target="I-D.ietf-core-coap"/>) and participate in meaningful
416conversations without the help of a gateway node.  In particular, they
417can provide support for the security functions required on a large
418network.  Therefore, they can be integrated as fully developed peers
419into an IP network, but they need to be parsimonious with state
420memory, code space, and often power expenditure for protocol and
421application usage.</t>
422
423<t>Class 2 devides are less constrained and fundamentally capable of
424supporting most of the same protocol stacks as used on
425notebooks or servers.  However, even these devices can benefit from
426lightweight and energy-efficient protocols and from consuming less
427bandwidth.  Furthermore, using fewer resources for networking leaves
428more resources available to applications.  Thus, using the protocol
429stacks defined for more constrained devices also on Class 2 devices
430might reduce development costs and increase the interoperability.</t>
431
432<t>Constrained devices with capabilities significantly beyond Class 2
433devices exist.  They are less demanding from a standards development
434point of view as they can largely use existing protocols unchanged.
435The present document therefore does not make any attempt to define
436classes beyond Class 2.  These devices can still be constrained by a
437limited energy supply.</t>
438
439<t>With respect to examining the capabilities of constrained nodes,
440particularly for Class 1 devices, it is important to understand what
441type of applications they are able to run and which protocol
442mechanisms would be most suitable.  Because of memory and other
443limitations, each specific Class 1 device might be able to support
444only a few selected functions needed for its intended operation.  In
445other words, the set of functions that can actually be supported is
446not static per device type: devices with similar constraints might
447choose to support different functions.  Even though Class 2 devices
448have some more functionality available and may be able to provide a
449more complete set of functions, they still need to be assessed for the
450type of applications they will be running and the protocol functions
451they would need.  To be able to derive any requirements, the use
452cases and the involvement of the devices in the application and the
453operational scenario need to be analyzed.  Use cases may combine
454constrained devices of multiple classes as well as more traditional
455Internet nodes.
456<!-- The use cases where Class 1
457or Class 2 devices build a cluster or are part of a hierarchy as well
458as the assumed degree of automation might be essentially important.
459 --></t>
460
461<t><vspace blankLines='999' /></t>
462
463</section>
464<section anchor="power" title="Power Terminology">
465
466<t>Devices not only differ in their computing capabilities, but also in
467available electrical power and/or energy.  While it is harder to find
468recognizable clusters in this space, it is still useful to introduce
469some common terminology.</t>
470
471<section anchor="scaling-properties" title="Scaling Properties">
472
473<t>The power and/or energy available to a device may vastly differ, from
474kilowatts to microwatts, from essentially unlimited to hundreds of
475microjoules.</t>
476
477<t>Instead of defining classes or clusters, we simply state, in
478SI units, an approximate value for one or both of the quantities
479listed in <xref target="scaletbl"/>:</t>
480
481<texttable title="Quantities Relevant to Power and Energy" anchor="scaletbl">
482      <ttcol align='left'>Name</ttcol>
483      <ttcol align='left'>Definition</ttcol>
484      <ttcol align='left'>SI Unit</ttcol>
485      <c>Ps</c>
486      <c>Sustainable average power available for the device over the time it is functioning</c>
487      <c>W (Watt)</c>
488      <c>Et</c>
489      <c>Total electrical energy available before the energy source is exhausted</c>
490      <c>J (Joule)</c>
491</texttable>
492
493<t>The value of Et may need to be interpreted in conjunction with an
494indication over which period of time the value is given; see the next
495subsection.</t>
496
497<t>Some devices enter a “low-power” mode before the energy available in a
498period is exhausted, or even have multiple such steps on the way to
499exhaustion.  For these devices, Ps would need to be given for each of
500the modes/steps.</t>
501
502</section>
503<section anchor="classes-of-energy-limitation" title="Classes of Energy Limitation">
504
505<t>As discussed above, some devices are limited in available energy as
506opposed to (or in addition to) being limited in available power.
507Where no relevant limitations exist with respect to energy, the device
508is classified as E9.
509The energy limitation may be in total energy available in the usable
510lifetime of the device (e.g. a device with a non-replaceable primary
511battery, which is discarded when this battery is exhausted),
512classified as E2.
513Where the relevant limitation is for a specific period, this is
514classified as E1, e.g. a limited amount of energy available for the
515night with a solar-powered device, or for the period between recharges
516with a device that is manually connected to a charger, or by a
517periodic (primary) battery replacement interval.
518Finally, there may be a limited amount of energy available for a specific
519event, e.g. for a button press in an energy harvesting light switch;
520this is classified as E0.
521Note that many E1 devices in a sense also are E2, as the rechargeable
522battery has a limited number of useful recharging cycles.</t>
523
524<t>In summary, we distinguish (<xref target="enclasstbl"/>):</t>
525
526<texttable title="Classes of Energy Limitation" anchor="enclasstbl">
527      <ttcol align='left'>Name</ttcol>
528      <ttcol align='left'>Type of energy limitation</ttcol>
529      <ttcol align='left'>Example Power Source</ttcol>
530      <c>E0</c>
531      <c>Event energy-limited</c>
532      <c>Event-based harvesting</c>
533      <c>E1</c>
534      <c>Period energy-limited</c>
535      <c>Battery that is periodically recharged or replaced</c>
536      <c>E2</c>
537      <c>Lifetime energy-limited</c>
538      <c>Non-replaceable primary battery</c>
539      <c>E9</c>
540      <c>No direct quantitative limitations to available energy</c>
541      <c>Mains powered</c>
542</texttable>
543
544</section>
545<section anchor="poweruse" title="Strategies of Using Power for Communication">
546
547<t>Especially when wireless transmission is used, the radio often
548consumes a big portion of the total energy consumed by the device.
549Design parameters such as the available spectrum, the desired range,
550and the bitrate aimed for,
551influence the power consumed during transmission and reception; the
552duration of transmission and reception (including potential reception)
553influence the total energy consumption.</t>
554
555<t>Based on the type of the energy source (e.g., battery or mains power)
556and how often device needs to communicate, it may use different kinds
557of strategies for power usage and network attachment.</t>
558
559<t>The general strategies for power usage can be described as follows:</t>
560
561<t><list style="hanging">
562  <t hangText='Always-on:'>
563  This strategy is most applicable if there is no reason for extreme
564measures for power saving.  The device can stay on in the usual manner
565all the time.  It may be useful to employ power-friendly hardware or
566limit the number of wireless transmissions, CPU speeds, and other
567aspects for general power saving and cooling needs, but the device can
568be connected to the network all the time.</t>
569  <t hangText='Normally-off:'>
570  Under this strategy, the device sleeps such long periods at a time
571that once it wakes up, it makes sense for it to not pretend that it
572has been connected to the network during sleep: The device re-attaches
573to the network as it is woken up.  The main optimization goal is to
574minimize the effort during such re-attachment process and any
575resulting application communications.</t>
576  <t>If the device sleeps for long periods of time, and needs to
577communicate infrequently, the relative increase in energy expenditure
578during reattachment may be acceptable.</t>
579  <t hangText='Low-power:'>
580  This strategy is most applicable to devices that need to operate on
581a very small amount of power, but still need to be able to communicate
582on a relatively frequent basis. This implies that extremely low power
583solutions needs to be used for the hardware, chosen link layer
584mechanisms, and so on.  Typically, given the small amount of time
585between transmissions, despite their sleep state these devices retain
586some form of network attachment to the network.  Techniques used for
587minimizing power usage for the network communications include
588minimizing any work from re-establishing communications after waking
589up, tuning the frequency of communications (including “duty cycling”,
590where components are switched on and off in a regular cycle), and other parameters
591appropriately.</t>
592</list></t>
593
594<t>In summary, we distinguish (<xref target="powclasstbl"/>):</t>
595
596<texttable title="Strategies of Using Power for Communication" anchor="powclasstbl">
597      <ttcol align='left'>Name</ttcol>
598      <ttcol align='left'>Strategy</ttcol>
599      <ttcol align='left'>Ability to communicate</ttcol>
600      <c>P0</c>
601      <c>Normally-off</c>
602      <c>Re-attach when required</c>
603      <c>P1</c>
604      <c>Low-power</c>
605      <c>Appears connected, perhaps with high latency</c>
606      <c>P9</c>
607      <c>Always-on</c>
608      <c>Always connected</c>
609</texttable>
610
611<t>Note that the discussion above is at the device level; similar
612considerations can apply at the communications interface level.
613This document does not define terminology for the latter.</t>
614
615<t>A term often used to describe power-saving approaches is
616“duty-cycling”.  This describes all forms of periodically switching
617off some function, leaving it on only for a certain percentage of
618time (the “duty cycle”).</t>
619
620<t><xref target="RFC7102"/> only distinguishes two levels, defining
621a Non-sleepy Node as a node that always remains in a fully powered on
622state (always awake) where it has the capability to perform
623communication (P9), and a Sleepy Node as a node that may sometimes go
624into a sleep mode (a low power state to conserve power) and
625temporarily suspend protocol communication (P0); there is no explicit
626mention of P1.</t>
627
628</section>
629</section>
630<section anchor="security-considerations" title="Security Considerations">
631
632<t>This document introduces common terminology that does not raise any
633new security issue.  Security considerations arising from the
634constraints discussed in this document need to be discussed in the
635context of specific protocols.  For instance, <xref target="I-D.ietf-core-coap"/> section 11.6,
636“Constrained node considerations”, discusses implications of specific
637constraints on the security mechanisms employed.
638<xref target="I-D.ietf-roll-security-threats"/> provides a security
639threat analysis for the RPL routing protocol.
640Implementation considerations for security protocols on constrained
641nodes are discussed in <xref target="I-D.ietf-lwig-ikev2-minimal"/> and
642<xref target="I-D.ietf-lwig-tls-minimal"/>.
643A wider view at security in constrained node networks is provided in
644<xref target="I-D.garcia-core-security"/>.</t>
645
646</section>
647<section anchor="iana-considerations" title="IANA Considerations">
648
649<t>This document has no actions for IANA.</t>
650
651</section>
652<section anchor="acknowledgements" title="Acknowledgements">
653
654<t>Dominique Barthel and Peter van der Stok provided useful comments;
655Charles Palmer provided a full editorial review.</t>
656
657<t>Peter van der Stok insisted that we should have power terminology,
658hence <xref target="power"/>.
659The text for <xref target="poweruse"/> is mostly lifted from a previous version of
660<xref target="I-D.ietf-lwig-cellular"/> and has been adapted for this document.</t>
661
662<t><vspace blankLines='999' /></t>
663
664<!--  LocalWords:  interoperability microwatts microjoules bitrate IP
665 -->
666<!--  LocalWords:  IANA Acknowledgements Ericsson LoWPAN Bormann MSL
667 -->
668<!--  LocalWords:  lossy Internet's multicast smartphones TCP DTN LLN
669 -->
670<!--  LocalWords:  IETF LLNs WiFi HVAC healthcare acyclic ETX RPL IPv
671 -->
672<!--  LocalWords:  IEEE WPANs LoWPANs Moore's preconfigured keepalive
673 -->
674<!--  LocalWords:  TLS CoAP UDP
675 -->
676
677</section>
678
679
680  </middle>
681
682  <back>
683
684
685    <references title='Informative References'>
686
687
688
689
690
691<reference anchor='I-D.ietf-core-coap'>
692<front>
693<title>Constrained Application Protocol (CoAP)</title>
694
695<author initials='Z' surname='Shelby' fullname='Zach Shelby'>
696    <organization />
697</author>
698
699<author initials='K' surname='Hartke' fullname='Klaus Hartke'>
700    <organization />
701</author>
702
703<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
704    <organization />
705</author>
706
707<date month='June' day='28' year='2013' />
708
709<abstract><t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks.  The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as 6LoWPAN often have high packet error rates and a typical throughput of 10s of kbit/s.  The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation.  CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types.  CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead and simplicity for constrained environments.</t></abstract>
710
711</front>
712
713<seriesInfo name='Internet-Draft' value='draft-ietf-core-coap-18' />
714<format type='TXT'
715        target='http://www.ietf.org/internet-drafts/draft-ietf-core-coap-18.txt' />
716</reference>
717
718
719
720<reference anchor='I-D.ietf-6lowpan-btle'>
721<front>
722<title>Transmission of IPv6 Packets over BLUETOOTH Low Energy</title>
723
724<author initials='J' surname='Nieminen' fullname='Johanna Nieminen'>
725    <organization />
726</author>
727
728<author initials='T' surname='Savolainen' fullname='Teemu Savolainen'>
729    <organization />
730</author>
731
732<author initials='M' surname='Isomaki' fullname='Markus Isomaki'>
733    <organization />
734</author>
735
736<author initials='B' surname='Patil' fullname='Basavaraj Patil'>
737    <organization />
738</author>
739
740<author initials='Z' surname='Shelby' fullname='Zach Shelby'>
741    <organization />
742</author>
743
744<author initials='C' surname='Gomez' fullname='Carles Gomez'>
745    <organization />
746</author>
747
748<date month='February' day='12' year='2013' />
749
750<abstract><t>BLUETOOTH Low Energy is a low power air interface technology defined by the BLUETOOTH Special Interest Group (BT-SIG).  The standard BLUETOOTH radio has been widely implemented and available in mobile phones, notebook computers, audio headsets and many other devices. The low power version of BLUETOOTH is a new specification that enables the use of this air interface with devices such as sensors, smart meters, appliances, etc.  The low power variant of BLUETOOTH is currently specified in the revision 4.0 of the BLUETOOTH specifications (BLUETOOTH 4.0).  This document describes how IPv6 is transported over BLUETOOTH Low Energy using 6LoWPAN techniques.</t></abstract>
751
752</front>
753
754<seriesInfo name='Internet-Draft' value='draft-ietf-6lowpan-btle-12' />
755<format type='TXT'
756        target='http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-btle-12.txt' />
757</reference>
758
759
760
761<reference anchor='I-D.mariager-6lowpan-v6over-dect-ule'>
762<front>
763<title>Transmission of IPv6 Packets over DECT Ultra Low Energy</title>
764
765<author initials='P' surname='Mariager' fullname='Peter Mariager'>
766    <organization />
767</author>
768
769<author initials='J' surname='Petersen' fullname='Jens Petersen'>
770    <organization />
771</author>
772
773<author initials='Z' surname='Shelby' fullname='Zach Shelby'>
774    <organization />
775</author>
776
777<date month='July' day='15' year='2013' />
778
779<abstract><t>DECT Ultra Low Energy is a low power air interface technology that is defined by the DECT Forum and specified by ETSI.  The DECT air interface technology has been used world-wide in communication devices for more than 15 years, primarily carrying voice for cordless telephony but has also been deployed for data centric services.  The DECT Ultra Low Energy is a recent addition to the DECT interface primarily intended for low-bandwidth, low-power applications such as sensor devices, smart meters, home automation etc.  As the DECT Ultra Low Energy interface inherits many of the capabilities from DECT, it benefits from long range, interference free operation, world wide reserved frequency band, low silicon prices and maturity.  There is an added value in the ability to communicate with IPv6 over DECT ULE such as for Internet of Things applications.  This document describes how IPv6 is transported over DECT ULE using 6LoWPAN techniques.</t></abstract>
780
781</front>
782
783<seriesInfo name='Internet-Draft' value='draft-mariager-6lowpan-v6over-dect-ule-03' />
784<format type='TXT'
785        target='http://www.ietf.org/internet-drafts/draft-mariager-6lowpan-v6over-dect-ule-03.txt' />
786<format type='PDF'
787        target='http://www.ietf.org/internet-drafts/draft-mariager-6lowpan-v6over-dect-ule-03.pdf' />
788</reference>
789
790
791
792<reference anchor='I-D.brandt-6man-lowpanz'>
793<front>
794<title>Transmission of IPv6 packets over ITU-T G.9959 Networks</title>
795
796<author initials='A' surname='Brandt' fullname='Anders Brandt'>
797    <organization />
798</author>
799
800<author initials='J' surname='Buron' fullname='Jakob Buron'>
801    <organization />
802</author>
803
804<date month='June' day='18' year='2013' />
805
806<abstract><t>This document describes the frame format for transmission of IPv6 packets and a method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks.</t></abstract>
807
808</front>
809
810<seriesInfo name='Internet-Draft' value='draft-brandt-6man-lowpanz-02' />
811<format type='TXT'
812        target='http://www.ietf.org/internet-drafts/draft-brandt-6man-lowpanz-02.txt' />
813<format type='PDF'
814        target='http://www.ietf.org/internet-drafts/draft-brandt-6man-lowpanz-02.pdf' />
815</reference>
816
817
818<reference anchor="fifty-billion" target="http://www.ericsson.com/res/docs/whitepapers/wp-50-billions.pdf">
819  <front>
820    <title>More Than 50 Billion Connected Devices</title>
821    <author >
822      <organization>Ericsson</organization>
823    </author>
824    <date year="2011" month="February"/>
825  </front>
826  <seriesInfo name="Ericsson White Paper" value="284 23-3149 Uen"/>
827</reference>
828<reference anchor="WEI" >
829  <front>
830    <title>6LoWPAN: the Wireless Embedded Internet</title>
831    <author initials="Z." surname="Shelby" fullname="Zach Shelby">
832      <organization></organization>
833    </author>
834    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
835      <organization></organization>
836    </author>
837    <date year="2009"/>
838  </front>
839  <seriesInfo name="ISBN" value="9780470747995"/>
840</reference>
841<reference anchor="FALL" >
842  <front>
843    <title>A Delay-Tolerant Network Architecture for Challenged Internets</title>
844    <author initials="K." surname="Fall" fullname="Kevin Fall">
845      <organization></organization>
846    </author>
847    <date year="2003"/>
848  </front>
849  <seriesInfo name="SIGCOMM" value="2003"/>
850</reference>
851<reference anchor="ISQ-13" >
852  <front>
853    <title>International Standard -- Quantities and units -- Part 13: Information science and technology</title>
854    <author >
855      <organization>International Electrotechnical Commission</organization>
856    </author>
857    <date year="2008" month="March"/>
858  </front>
859  <seriesInfo name="IEC" value="80000-13"/>
860</reference>
861
862
863
864
865<reference anchor='RFC6606'>
866
867<front>
868<title>Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing</title>
869<author initials='E.' surname='Kim' fullname='E. Kim'>
870<organization /></author>
871<author initials='D.' surname='Kaspar' fullname='D. Kaspar'>
872<organization /></author>
873<author initials='C.' surname='Gomez' fullname='C. Gomez'>
874<organization /></author>
875<author initials='C.' surname='Bormann' fullname='C. Bormann'>
876<organization /></author>
877<date year='2012' month='May' />
878<abstract>
879<t>IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) are formed by devices that are compatible with the IEEE 802.15.4 standard. However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format specification defines how mesh topologies could be obtained and maintained. Thus, it should be considered how 6LoWPAN formation and multi-hop routing could be supported.&lt;/t>&lt;t> This document provides the problem statement and design space for 6LoWPAN routing. It defines the routing requirements for 6LoWPANs, considering the low-power and other particular characteristics of the devices and links. The purpose of this document is not to recommend specific solutions but to provide general, layer-agnostic guidelines about the design of 6LoWPAN routing that can lead to further analysis and protocol design. This document is intended as input to groups working on routing protocols relevant to 6LoWPANs, such as the IETF ROLL WG. This document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract></front>
880
881<seriesInfo name='RFC' value='6606' />
882<format type='TXT' octets='75436' target='http://www.rfc-editor.org/rfc/rfc6606.txt' />
883</reference>
884
885
886
887<reference anchor='RFC0793'>
888
889<front>
890<title abbrev='Transmission Control Protocol'>Transmission Control Protocol</title>
891<author initials='J.' surname='Postel' fullname='Jon Postel'>
892<organization>University of Southern California (USC)/Information Sciences Institute</organization>
893<address>
894<postal>
895<street>4676 Admiralty Way</street>
896<city>Marina del Rey</city>
897<region>CA</region>
898<code>90291</code>
899<country>US</country></postal></address></author>
900<date year='1981' day='1' month='September' /></front>
901
902<seriesInfo name='STD' value='7' />
903<seriesInfo name='RFC' value='793' />
904<format type='TXT' octets='172710' target='http://www.rfc-editor.org/rfc/rfc793.txt' />
905</reference>
906
907
908
909<reference anchor='RFC4838'>
910
911<front>
912<title>Delay-Tolerant Networking Architecture</title>
913<author initials='V.' surname='Cerf' fullname='V. Cerf'>
914<organization /></author>
915<author initials='S.' surname='Burleigh' fullname='S. Burleigh'>
916<organization /></author>
917<author initials='A.' surname='Hooke' fullname='A. Hooke'>
918<organization /></author>
919<author initials='L.' surname='Torgerson' fullname='L. Torgerson'>
920<organization /></author>
921<author initials='R.' surname='Durst' fullname='R. Durst'>
922<organization /></author>
923<author initials='K.' surname='Scott' fullname='K. Scott'>
924<organization /></author>
925<author initials='K.' surname='Fall' fullname='K. Fall'>
926<organization /></author>
927<author initials='H.' surname='Weiss' fullname='H. Weiss'>
928<organization /></author>
929<date year='2007' month='April' />
930<abstract>
931<t>This document describes an architecture for delay-tolerant and disruption-tolerant networks, and is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration.  This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical.  We define a message- oriented overlay that exists above the transport (or other) layers of the networks it interconnects.  The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues.  This document represents the consensus of the IRTF DTN research group and has been widely reviewed by that group.  This memo provides information for the Internet community.</t></abstract></front>
932
933<seriesInfo name='RFC' value='4838' />
934<format type='TXT' octets='89265' target='http://www.rfc-editor.org/rfc/rfc4838.txt' />
935</reference>
936
937
938
939<reference anchor='RFC7102'>
940
941<front>
942<title>Terms Used in Routing for Low-Power and Lossy Networks</title>
943<author initials='JP.' surname='Vasseur' fullname='JP. Vasseur'>
944<organization /></author>
945<date year='2014' month='January' />
946<abstract>
947<t>This document provides a glossary of terminology used in routing requirements and solutions for networks referred to as Low-Power and Lossy Networks (LLNs).  An LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links.  There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g., heating, ventilation, air conditioning, lighting, access control, fire), connected home, health care, environmental monitoring, urban sensor networks, energy management, assets tracking, and refrigeration.</t></abstract></front>
948
949<seriesInfo name='RFC' value='7102' />
950<format type='TXT' octets='16444' target='http://www.rfc-editor.org/rfc/rfc7102.txt' />
951</reference>
952
953
954
955<reference anchor='RFC6551'>
956
957<front>
958<title>Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks</title>
959<author initials='JP.' surname='Vasseur' fullname='JP. Vasseur'>
960<organization /></author>
961<author initials='M.' surname='Kim' fullname='M. Kim'>
962<organization /></author>
963<author initials='K.' surname='Pister' fullname='K. Pister'>
964<organization /></author>
965<author initials='N.' surname='Dejean' fullname='N. Dejean'>
966<organization /></author>
967<author initials='D.' surname='Barthel' fullname='D. Barthel'>
968<organization /></author>
969<date year='2012' month='March' />
970<abstract>
971<t>Low-Power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad hoc networks that require the specification of new routing metrics and constraints.  By contrast, with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing Protocol for Low-Power and Lossy Networks (RPL). [STANDARDS-TRACK]</t></abstract></front>
972
973<seriesInfo name='RFC' value='6551' />
974<format type='TXT' octets='67707' target='http://www.rfc-editor.org/rfc/rfc6551.txt' />
975</reference>
976
977
978
979<reference anchor='I-D.hui-vasseur-roll-rpl-deployment'>
980<front>
981<title>RPL deployment experience in large scale networks</title>
982
983<author initials='J' surname='Vasseur' fullname='JP Vasseur'>
984    <organization />
985</author>
986
987<author initials='J' surname='Hui' fullname='Jonathan Hui'>
988    <organization />
989</author>
990
991<author initials='S' surname='Dasgupta' fullname='Sukrit Dasgupta'>
992    <organization />
993</author>
994
995<author initials='G' surname='Yoon' fullname='Giyoung Yoon'>
996    <organization />
997</author>
998
999<date month='July' day='5' year='2012' />
1000
1001<abstract><t>Low power and Lossy Networks (LLNs) exhibit characteristics unlike other more traditional IP links.  LLNs are a class of network in which both routers and their interconnect are resource constrained. LLN routers are typically resource constrained in processing power, memory, and energy (i.e. battery power).  LLN links are typically exhibit high loss rates, low data rates, are are strongly affected by environmental conditions that change over time.  LLNs may be composed of a few dozen to thousands of routers.  A new protocol called the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) has been specified for routing in LLNs supporting multipoint-to-point, point- to-multipoint traffic, and point-to-point traffic.  Since RPL's publication as an RFC, several large scale networks have been succesfully deployed.  The aim of this document is to provide deployment experience on real-life deployed RPL-based networks.</t></abstract>
1002
1003</front>
1004
1005<seriesInfo name='Internet-Draft' value='draft-hui-vasseur-roll-rpl-deployment-01' />
1006<format type='TXT'
1007        target='http://www.ietf.org/internet-drafts/draft-hui-vasseur-roll-rpl-deployment-01.txt' />
1008<format type='PDF'
1009        target='http://www.ietf.org/internet-drafts/draft-hui-vasseur-roll-rpl-deployment-01.pdf' />
1010</reference>
1011
1012
1013
1014<reference anchor='RFC6650'>
1015
1016<front>
1017<title>Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)</title>
1018<author initials='J.' surname='Falk' fullname='J. Falk'>
1019<organization /></author>
1020<author initials='M.' surname='Kucherawy' fullname='M. Kucherawy'>
1021<organization /></author>
1022<date year='2012' month='June' />
1023<abstract>
1024<t>RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties.  This applicability statement describes common methods for utilizing this format for reporting both abuse and authentication failure events.  Mailbox Providers of any size, mail-sending entities, and end users can use these methods as a basis to create procedures that best suit them.  Some related optional mechanisms are also discussed. [STANDARDS-TRACK]</t></abstract></front>
1025
1026<seriesInfo name='RFC' value='6650' />
1027<format type='TXT' octets='35273' target='http://www.rfc-editor.org/rfc/rfc6650.txt' />
1028</reference>
1029
1030
1031
1032<reference anchor='RFC4919'>
1033
1034<front>
1035<title>IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals</title>
1036<author initials='N.' surname='Kushalnagar' fullname='N. Kushalnagar'>
1037<organization /></author>
1038<author initials='G.' surname='Montenegro' fullname='G. Montenegro'>
1039<organization /></author>
1040<author initials='C.' surname='Schumacher' fullname='C. Schumacher'>
1041<organization /></author>
1042<date year='2007' month='August' />
1043<abstract>
1044<t>This document describes the assumptions, problem statement, and goals for transmitting IP over IEEE 802.15.4 networks.  The set of goals enumerated in this document form an initial set only.  This memo provides information for the Internet community.</t></abstract></front>
1045
1046<seriesInfo name='RFC' value='4919' />
1047<format type='TXT' octets='27650' target='http://www.rfc-editor.org/rfc/rfc4919.txt' />
1048</reference>
1049
1050
1051
1052<reference anchor='I-D.ietf-roll-security-threats'>
1053<front>
1054<title>A Security Threat Analysis for Routing Protocol for Low-power and lossy networks (RPL)</title>
1055
1056<author initials='T' surname='Tsao' fullname='Tzeta Tsao'>
1057    <organization />
1058</author>
1059
1060<author initials='R' surname='Alexander' fullname='Roger Alexander'>
1061    <organization />
1062</author>
1063
1064<author initials='M' surname='Dohler' fullname='Mischa Dohler'>
1065    <organization />
1066</author>
1067
1068<author initials='V' surname='Daza' fullname='Vanesa Daza'>
1069    <organization />
1070</author>
1071
1072<author initials='A' surname='Lozano' fullname='Angel Lozano'>
1073    <organization />
1074</author>
1075
1076<author initials='M' surname='Richardson' fullname='Michael Richardson'>
1077    <organization />
1078</author>
1079
1080<date month='December' day='15' year='2013' />
1081
1082<abstract><t>This document presents a security threat analysis for the Routing Protocol for Low-power and lossy networks (RPL, ROLL).  The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks.  A systematic approach is used in defining and evaluating the security threats.  Applicable countermeasures are application specific and are addressed in relevant applicability statements.</t></abstract>
1083
1084</front>
1085
1086<seriesInfo name='Internet-Draft' value='draft-ietf-roll-security-threats-06' />
1087<format type='TXT'
1088        target='http://www.ietf.org/internet-drafts/draft-ietf-roll-security-threats-06.txt' />
1089</reference>
1090
1091
1092
1093<reference anchor='I-D.ietf-lwig-ikev2-minimal'>
1094<front>
1095<title>Minimal IKEv2</title>
1096
1097<author initials='T' surname='Kivinen' fullname='Tero Kivinen'>
1098    <organization />
1099</author>
1100
1101<date month='October' day='17' year='2013' />
1102
1103<abstract><t>This document describes minimal version of the Internet Key Exchange version 2 (IKEv2) protocol.  IKEv2 is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs).  IKEv2 includes several optional features, which are not needed in minimal implementations.  This document describes what is required from the minimal implementation, and also describes various optimizations which can be done.  The protocol described here is compliant with full IKEv2 with exception that this document describes mainly shared secret authentication (IKEv2 requires support for certificate authentication in addition to shared secret authentication).  This document does not update or modify RFC 5996, but provides more compact description of the minimal version of the protocol.  If this document and RFC 5996 conflicts then RFC 5996 is the authoritative description.</t></abstract>
1104
1105</front>
1106
1107<seriesInfo name='Internet-Draft' value='draft-ietf-lwig-ikev2-minimal-01' />
1108<format type='TXT'
1109        target='http://www.ietf.org/internet-drafts/draft-ietf-lwig-ikev2-minimal-01.txt' />
1110</reference>
1111
1112
1113
1114<reference anchor='I-D.ietf-lwig-tls-minimal'>
1115<front>
1116<title>A Hitchhiker's Guide to the (Datagram) Transport Layer Security Protocol for Smart Objects and Constrained Node Networks</title>
1117
1118<author initials='S' surname='Kumar' fullname='Sandeep Kumar'>
1119    <organization />
1120</author>
1121
1122<author initials='S' surname='Keoh' fullname='Sye Keoh'>
1123    <organization />
1124</author>
1125
1126<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
1127    <organization />
1128</author>
1129
1130<date month='September' day='4' year='2013' />
1131
1132<abstract><t>Transport Layer Security (TLS) is a widely used security protocol that offers communication security services at the transport layer. The initial design of TLS was focused on the protection of applications running on top of the Transmission Control Protocol (TCP), and was a good match for securing the Hypertext Transfer Protocol (HTTP).  Subsequent standardization efforts lead to the publication of the Datagram Transport Layer Security (DTLS) protocol, which allows the re-use of the TLS security functionality and the payloads to be exchanged on top of the User Datagram Protocol (UDP).  With the work on the Constrained Application Protocol (CoAP), as a specialized web transfer protocol for use with constrained nodes and constrained networks, DTLS is a preferred communication security protocol.  Smart objects are constrained in various ways (e.g., CPU, memory, power consumption) and these limitations may impose restrictions on the protocol stack such a device runs. This document only looks at the security part of that protocol stacks and the ability to customize TLS/DTLS. To offer input for implementers and system architects this document illustrates the costs and benefits of various TLS/DTLS features for use with smart objects and constraint node networks.</t></abstract>
1133
1134</front>
1135
1136<seriesInfo name='Internet-Draft' value='draft-ietf-lwig-tls-minimal-00' />
1137<format type='TXT'
1138        target='http://www.ietf.org/internet-drafts/draft-ietf-lwig-tls-minimal-00.txt' />
1139</reference>
1140
1141
1142
1143<reference anchor='I-D.garcia-core-security'>
1144<front>
1145<title>Security Considerations in the IP-based Internet of Things</title>
1146
1147<author initials='O' surname='Garcia-Morchon' fullname='Oscar Garcia-Morchon'>
1148    <organization />
1149</author>
1150
1151<author initials='S' surname='Kumar' fullname='Sandeep Kumar'>
1152    <organization />
1153</author>
1154
1155<author initials='S' surname='Keoh' fullname='Sye Keoh'>
1156    <organization />
1157</author>
1158
1159<author initials='R' surname='Hummen' fullname='Rene Hummen'>
1160    <organization />
1161</author>
1162
1163<author initials='R' surname='Struik' fullname='Rene Struik'>
1164    <organization />
1165</author>
1166
1167<date month='September' day='11' year='2013' />
1168
1169<abstract><t>A direct interpretation of the Internet of Things concept refers to the usage of standard Internet protocols to allow for human-to-thing or thing-to-thing communication.  Although the security needs are well-recognized, it is still not fully clear how existing IP-based security protocols can be applied to this new setting.  This Internet-Draft first provides an overview of security architecture, its deployment model and general security needs in the context of the lifecycle of a thing.  Then, it presents challenges and requirements for the successful roll-out of new applications and usage of standard IP-based security protocols when applied to get a functional Internet of Things.</t></abstract>
1170
1171</front>
1172
1173<seriesInfo name='Internet-Draft' value='draft-garcia-core-security-06' />
1174<format type='TXT'
1175        target='http://www.ietf.org/internet-drafts/draft-garcia-core-security-06.txt' />
1176</reference>
1177
1178
1179
1180<reference anchor='I-D.ietf-lwig-cellular'>
1181<front>
1182<title>Building Power-Efficient CoAP Devices for Cellular Networks</title>
1183
1184<author initials='J' surname='Arkko' fullname='Jari Arkko'>
1185    <organization />
1186</author>
1187
1188<author initials='A' surname='Eriksson' fullname='Anders Eriksson'>
1189    <organization />
1190</author>
1191
1192<author initials='A' surname='Keranen' fullname='Ari Keranen'>
1193    <organization />
1194</author>
1195
1196<date month='August' day='14' year='2013' />
1197
1198<abstract><t>This memo discusses the use of the Constrained Application Protocol (CoAP) protocol in building sensors and other devices that employ cellular networks as a communications medium.  Building communicating devices that employ these networks is obviously well known, but this memo focuses specifically on techniques necessary to minimize power consumption.</t></abstract>
1199
1200</front>
1201
1202<seriesInfo name='Internet-Draft' value='draft-ietf-lwig-cellular-00' />
1203<format type='TXT'
1204        target='http://www.ietf.org/internet-drafts/draft-ietf-lwig-cellular-00.txt' />
1205</reference>
1206
1207
1208
1209
1210    </references>
1211
1212
1213
1214  </back>
1215</rfc>
1216
Note: See TracBrowser for help on using the repository browser.