source: draft-hex-lwig-energy-efficient.xml @ 23

Last change on this file since 23 was 23, checked in by kovatsch@…, 7 years ago

Added reference to new draft-kovatsch-lwig-coap.

File size: 40.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-hex-lwig-energy-efficient-01" category="info">
8
9<?rfc toc="yes"?>
10<?rfc tocdepth="3"?>
11<?rfc sortrefs="yes"?>
12<?rfc symrefs="yes"?>
13
14  <front>
15    <title abbrev="LWIG Energy-efficient">Energy-efficient Implementation of IETF Protocols on Constrained Devices</title>
16
17    <author initials="Z." surname="Cao" fullname="Zhen Cao" role="editor">
18      <organization>China Mobile</organization>
19      <address>
20        <postal>
21          <street>32 Xuanwumenxi Ave.</street>
22          <city>Beijing, 100871</city>
23         
24         
25          <country>P.R.China</country>
26        </postal>
27       
28       
29        <email>zehn.cao@gmail.com, caozhen@chinamobile.com</email>
30       
31      </address>
32    </author>
33    <author initials="X." surname="He" fullname="Xuan He">
34      <organization>Hitachi (China) R&amp;D Corp.</organization>
35      <address>
36        <postal>
37          <street>301, Tower C North, Raycom, 2 Kexuyuan Nanlu</street>
38          <city>Beijing, 100190</city>
39         
40         
41          <country>P.R.China</country>
42        </postal>
43       
44       
45        <email>xhe@hitachi.cn</email>
46       
47      </address>
48    </author>
49    <author initials="M." surname="Kovatsch" fullname="Matthias Kovatsch">
50      <organization>ETH Zurich</organization>
51      <address>
52        <postal>
53          <street>Universitätstrasse 6</street>
54          <city>CH-8092 Zurich</city>
55         
56         
57          <country>Switzerland</country>
58        </postal>
59       
60       
61        <email>kovatsch@inf.ethz.ch</email>
62       
63      </address>
64    </author>
65
66    <date year="2013" month="July" day="01"/>
67
68    <area>Internet</area>
69    <workgroup>LWIG Working Group</workgroup>
70    <keyword>Internet-Draft</keyword>
71
72    <abstract>
73
74
75<t>For IP-based Internet of Things devices to be battery-operated, protocols
76within IETF scope also need to behave energy friendly. This document summarizes
77the problems and current practices of energy-efficient protocol implementation
78on constrained devices.</t>
79
80
81
82    </abstract>
83
84
85  </front>
86
87  <middle>
88
89
90<section anchor="introduction" title="Introduction">
91
92<t>In many scenarios of embedded systems, the networked system is
93composed of many battery-powered devices.  For example, in an
94environmental monitoring system or a temperature and humidity
95monitoring system in the data center, there are no always-on and
96handy sustained power supplies for the large number of small devices.
97In such deployment environments, it is necessary to optimize the
98energy consumption of the entire system, including computing,
99application layer behavior, and lower layer communication.</t>
100
101<t>Various research efforts have been spent on this “energy efficiency”
102problem.  Most of this research has focused on how to optimize the
103system’s power consumption regarding a certain deployment scenario or
104how could an exisiting network function such as routing or security
105be more energy-efficient.  Only few efforts were spent on energy-
106efficient designs for IETF protocols and standardized network stacks
107for such constrained devices <xref target="I-D.kovatsch-lwig-coap"/>.</t>
108
109<t>The IETF has developed a suite of Internet protocols suitable for
110such small devices, including 6LoWPAN <xref target="RFC6282"/>, 6LoWPAN-ND
111<xref target="RFC6775"/>, RPL <xref target="RFC6550"/>, and CoAP <xref target="I-D.ietf-core-coap"/>.  This
112document tries to summarize the design considerations of making the IETF
113protocol suite as energy-efficient as possible.  While this document
114does not provide detailed and systematic solutions to the energy
115efficiency problem, it summarizes the design efforts and analyzes the
116design space of this problem.</t>
117
118<t>After reviewing the energy-efficient design of each layer, an overall
119conclusion is summarized.  Though the lower layer communication
120optimization is the key part of energy efficient design, the protocol
121design at the network and application layers is also important to
122make the device battery-friendly.</t>
123
124</section>
125<section anchor="terminology" title="Terminology">
126
127<t>The terminology used in this document can be referred to in
128<xref target="I-D.ietf-lwig-terminology"/>.</t>
129
130</section>
131<section anchor="overview" title="Overview">
132
133<t>The IETF has developed multiple protocols to enable end-to-end IP
134communication between constrained nodes and fully capable nodes.
135This work has witnessed the evolution of the traditional Internet
136protocol stack to a light-weight Internet protocol stack.  As show in
137Figure 1 below, the IETF has developed CoAP as the application layer
138and 6LoWPAN as the adaption layer to run IPv6 over IEEE 802.15.4 and
139Bluetooth Low-Energy, with the support of routing by RPL and
140efficient neighbor discovery by 6LoWPAN-ND.</t>
141
142<figure title="Traditional and Lighweight Internet Protocol Stack" anchor="stack"><artwork><![CDATA[
143  +------+   +-----+     +------+              +------+
144  | HTTP |   | ftp |     | SNMP |              | COAP |
145  +------+   +-----+     +------+              +------+
146        \     /           /                   /        \
147        +-----+     +-----+              +-----+      +-----+
148        | TCP |     | UDP |              | TCP |      | UDP |
149        +-----+     +-----+              +-----+      +-----+
150               \   /               ==>        \        /
151    +-----+  +------+  +-------+               +------+   +-----+
152    | RTG |--| IPv6 |--|ICMP/ND|               | IPv6 |---| RPL |
153    +-----+  +------+  +-------+               +------+   +-----+
154                 |                                 |
155             +-------+                         +-------+  +----------+
156             |MAC/PHY|                         |6LoWPAN|--|6LoWPAN-ND|
157             +-------+                         +-------+  +----------+
158                                                   |
159                                               +-------+
160                                               |MAC/PHY|
161                                               +-------+
162]]></artwork></figure>
163
164<t>There are comprehensive measurements of wireless communication
165<xref target="powertrace"/>.  Below we list the energy consumption profile of the
166most common atom operations on a prevalent sensor node platform.  The
167measurement was based on the Tmote Sky with ContikiMAC as the radio
168duty cycling algorithm.  From the measurement, we can see that
169optimized transmissions and reception consume almost the same amount
170of energy.  For IEEE 802.15.4 and UWB radios, transmitting is
171actually even cheaper than receiving.  Only for broadcast and non-
172synchronized communication transmissions become costly in terms of
173energy because they need to flood the medium for a long time.</t>
174
175</section>
176<section anchor="mac-and-radio-duty-cycling" title="MAC and Radio Duty Cycling">
177
178<texttable title="Power consumption of atom operations on the Tmote Sky with ContikiMAC" anchor="powertbl">
179      <ttcol align='left'>&#160;</ttcol>
180      <ttcol align='left'>Activity</ttcol>
181      <ttcol align='left'>Energy (uJ)</ttcol>
182      <c>&#160;</c>
183      <c>Broadcast reception</c>
184      <c>178</c>
185      <c>&#160;</c>
186      <c>Unicast reception</c>
187      <c>222</c>
188      <c>&#160;</c>
189      <c>Broadcast transmission</c>
190      <c>1790</c>
191      <c>&#160;</c>
192      <c>Non-synchronized unicast transmission</c>
193      <c>1090</c>
194      <c>&#160;</c>
195      <c>Synchronized unicast transmission</c>
196      <c>120</c>
197      <c>&#160;</c>
198      <c>Unicast TX to awake receiver</c>
199      <c>96</c>
200</texttable>
201
202<t>In low-power wireless networks, communication and power consumption
203are intertwined.  The communication device is typically the most
204power-consuming component, but merely refraining from transmissions
205is not enough to attain a low power consumption: the radio consumes
206as much power in listen mode as when actively transmitting, as show
207in <xref target="powertbl"/>.  To reduce power consumption, the radio must be
208switched completely off – duty-cycled – as much as possible.
209However, radio duty cycling (RDC) performs periodic channel checks to
210realize a virtual always-on link. This is the main difference to so
211called sleepy nodes, which perform duty-cycling at the application layer.</t>
212
213<t>RDC can be achieved through a separate, independent layer between PHY
214and MAC.  The upper layers can remain more or less untouched and only
215experience a higher latency. (Note that this might require tweaking the
216timeout parameters.)  State-of-the-art RDC layers can achieve an idle
217duty cycling way below 1% while checking the channel several times per
218second.  ContikiMAC <xref target="contikimac"/> for instance achieves a 0.3% cycle
219with a channel check rate of 4 Hz, which results in a worst-case delay
220of 250ms per hop.  While saving energy, ContikiMAC’s link-layer
221transmissions are also more robust due to its retransmission policy.
222Please refer to <xref target="contikimac"/> for details.</t>
223
224<t>In general, RDC can be divided into two approaches: sender initiated
225(e.g., ContikiMAC) and receiver initiated (e.g., A-MAC <xref target="amac"/>).  In
226the first approach, the sender of a message enables the radio first
227and continuously announces its attendance to send (note that for IEEE
228802.15.4 transceivers, transmitting consumes less energy than
229receiving).  Receivers periodically turn on only periodically to
230check for these announcements.  If they sense a busy channel, the
231radio is turned on for a longer period to receive a potential
232message.  In the other approach, the receiver periodically announces
233that it will keep on its radio for a while.  When a node wants to
234send, it turns on its radio to listen for these announcements and
235does so when it hears the recipient (following the scheme of the
236above MAC layer of course).  Which approach is optimal mainly depends
237on the communication pattern of the application.</t>
238
239<t>The MAC&amp;RDC are not in the scope of the IETF, yet lower layer
240designers and chipset manufactures take great care of the problem.
241For the IETF protocol designers, however, it is good to know the
242behaviors of lower layers so that the designed protocols can work
243perfectly with them. The IETF protocols we are going to talk about in
244the following sections are the customers of the lower layer.  If they
245want to get better service in a cooperative way, they should be
246considerative and understand each other.</t>
247
248</section>
249<section anchor="ip-adaption-and-transport-layer" title="IP Adaption and Transport Layer">
250
251<t>6LoWPAN is the adaption layer to run IPv6 over IEEE 802.15.4 MAC&amp;PHY.
252It was born to fill the gap that the IPv6 layer does not support
253fragmentation and assembly of &lt;1280-byte packets while IEEE 802.15.4
254only supports a MTU of 127 bytes.</t>
255
256<t>IPv6 is the basis for the higher layer protocols, including both TCP/UDP
257transport and applications.  So they are quite ignorant of the
258transmission and reception behaviors, and are almost neutral to the
259energy-efficiency problem.</t>
260
261<t>What the network stack can optimize is to save the computing power.
262For example the Contiki implementation has multiple cross layer
263optimizations for buffers and energy management, e.g., the computing
264and validation of UDP/TCP checksums without the need of reading IP
265headers from a different layer.  These optimizations are software
266implementation techniques, and out of the scope of IETF and the LWIG
267working group.</t>
268
269<t>The 6LoWPAN contributes to the energy-efficiency problem in two ways.
270First of all, it swaps computing with communication. 6LoWPAN applies
271compression of the IPv6 header.  This means less amount of data will
272be handled by the lower layer, but both the sender and receiver
273should spend more computing power on the compression and
274decompression of the packets over the air.  Secondly, the 6LoWPAN
275working group developed the energy-efficient Neigbor Discovery called
2766LoWPAN-ND, which is an energy efficient replacement of the IPv6 ND
277in constrained environments.  IPv6 Neighbor Discovery was not
278designed for non-transitive wireless links, as its heavy use of
279multicast makes it inefficient and sometimes impractical in a low-power
280and lossy network. 6LoWPAN-ND describes simple optimizations to
281IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate
282address detection for Low-power Wireless Personal Area Networks and
283similar networks.</t>
284
285</section>
286<section anchor="routing-protocols" title="Routing Protocols">
287
288<t>The routing protocol designed by the IETF for constrained
289environments is called RPL <xref target="RFC6550"/>.  As a routing protocol, RPL has
290to exchange messages periodically and keep routing states for each
291destination.  RPL is optimized for the many-to-one commununication
292pattern, where network nodes primarily send data towards the border
293router, but has provisions for any-to-any routing as well.</t>
294
295<t>The authors of the Powertrace tool studied the power profile of RPL.
296It devides the routing protocol into control and data traffic.  The
297control channel uses ICMP messages to establish and maintain the
298routing states.  The data channel is any application that uses RPL
299for routing packets.  The study has shown that the power consumption
300of the control traffic goes down over time and data traffic stays
301relatively constant.  The study also reflects that the routing
302protocol should keep the control traffic as low as possible to make
303it energy-friendly.</t>
304
305</section>
306<section anchor="application-layer" title="Application Layer">
307
308<t>CoAP <xref target="I-D.ietf-core-coap"/> was designed as a RESTful application
309protocol, connecting the services of smart devices to the World Wide
310Web. CoAP is not a chatty protocol, it provides basic communication
311services such as service discovery and GET/POST/PUT/DELETE methods
312with a binary header.</t>
313
314<section anchor="general-properties" title="General Properties">
315
316<t>The energy-efficient design is implicitly included in the CoAP
317protocol design.  To reduce regular and frequent queries of the
318resources, CoAP provides an observe mode, in which the requester
319registers its interest of a certain resource and the responder will
320report the value whenever it was updated.  This reduces the request
321reponse roundtrip while keeping information exchange a ubiquitous
322service.</t>
323
324</section>
325<section anchor="sleepy-nodes" title="Sleepy Nodes">
326
327<t>A direct way to conserve energy at the application layer are so called
328sleepy nodes. In contrast to the periodic channel checks of RDC, they
329put the radio into hibernation for a long period during which the node is
330fully disconnected from the network.
331Going to sleep for a longer time it not transparent for the
332application layer, as nodes need to re-synchronize and maybe re-
333associate with the network.  Several drafts in the IETF CoRE working
334group cover this strategy for low-power wireless networking such as
335<xref target="I-D.vial-core-mirror-proxy"/>, <xref target="I-D.fossati-core-publish-option"/>, and
336<xref target="I-D.fossati-core-monitor-option"/>.  Such features will have to be
337integrated into the application layer implementation of the nodes as well
338as the back-end systems.  In addition, alternatives to standard diagnosis
339tools such as ICMP ping will have to be provided, e.g., heartbeats by the
340application.</t>
341
342<t>This strategy is particular useful for communications other than
343IEEE 802.15.4.  Low-power Wi-Fi for instance is mainly based on long
344sleeping periods with short wake-up cycles.  Although the data rate
345would be high enough for HTTP over TCP, low-power Wi-FI can greatly
346benefit from CoAP and its shorter roundtrip times.  For further
347information about sleepy nodes based on low-power Wi-Fi see <xref target="lpwifi"/>.
348Another interesting example are SIM card based devices that use the
349Short Message Service (SMS). It comes with its own reliable and
350delay-tolerant delivery. Hence, no additional back-end systems such as
351mirror proxies are required.</t>
352
353</section>
354</section>
355<section anchor="cross-layer-optimization" title="Cross Layer Optimization">
356
357<t>The cross layer optimization is a technique used in many
358scenarios.There are some technologies for power efficient
359optimization via PHY to Routing cross layer design
360<xref target="crosslayeropt"/>.  In this research, cross-layer
361optimization frameworks have been developed to minimize the total
362power consumption or to maximize the utility-power tradeoff using
363cooperative diversity.</t>
364
365<t>Also a cross-layer design in multihop wireless networks is proposed
366for congestion control, routing and scheduling–in transport, network
367and link layers into a coherent framework <xref target="crosslayerdesign"/>.  This
368method and thinking could be applied to the implementation of energy
369effective cross layer design.</t>
370
371<t>Therefore, from the APP layer to the PHY layer, it should be considering
372the energy distribution of the entire protocol stack to achieve optimal
373energy efficiency.</t>
374
375<figure title="Affected layers" anchor="crosslayer"><artwork><![CDATA[
376                  +------+
377                  |  APP |          -------+
378                  +------+                 |
379                 /        \                |
380             +-----+      +-----+          |
381             | tcp |      | udp |          |
382             +-----+      +-----+          |
383                \        /                 |
384                 +------+   +-----------+  +--------------+
385                 | ipv6 |---| rpl/other |  | cross layer  |
386                 +------+   +-----------+  | optimization |
387                     |                     +--------------+
388                 +-------+  +----------+   |
389                 |6lowpan|--|6lowpan-nd|   |
390                 +-------+  +----------+   |
391                          |                |
392                      +-------+            |
393                      |MAC/PHY|    --------+
394                      +-------+
395]]></artwork></figure>
396
397</section>
398
399
400  </middle>
401
402  <back>
403
404    <references title='Normative References'>
405
406
407
408
409
410<reference anchor='RFC2616'>
411
412<front>
413<title abbrev='HTTP/1.1'>Hypertext Transfer Protocol -- HTTP/1.1</title>
414<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
415<organization abbrev='UC Irvine'>Department of Information and Computer Science</organization>
416<address>
417<postal>
418<street>University of California, Irvine</street>
419<city>Irvine</city>
420<region>CA</region>
421<code>92697-3425</code></postal>
422<facsimile>+1(949)824-1715</facsimile>
423<email>fielding@ics.uci.edu</email></address></author>
424<author initials='J.' surname='Gettys' fullname='James Gettys'>
425<organization abbrev='Compaq/W3C'>World Wide Web Consortium</organization>
426<address>
427<postal>
428<street>MIT Laboratory for Computer Science, NE43-356</street>
429<street>545 Technology Square</street>
430<city>Cambridge</city>
431<region>MA</region>
432<code>02139</code></postal>
433<facsimile>+1(617)258-8682</facsimile>
434<email>jg@w3.org</email></address></author>
435<author initials='J.' surname='Mogul' fullname='Jeffrey C. Mogul'>
436<organization abbrev='Compaq'>Compaq Computer Corporation</organization>
437<address>
438<postal>
439<street>Western Research Laboratory</street>
440<street>250 University Avenue</street>
441<city>Palo Alto</city>
442<region>CA</region>
443<code>94305</code></postal>
444<email>mogul@wrl.dec.com</email></address></author>
445<author initials='H.' surname='Frystyk' fullname='Henrik Frystyk Nielsen'>
446<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
447<address>
448<postal>
449<street>MIT Laboratory for Computer Science, NE43-356</street>
450<street>545 Technology Square</street>
451<city>Cambridge</city>
452<region>MA</region>
453<code>02139</code></postal>
454<facsimile>+1(617)258-8682</facsimile>
455<email>frystyk@w3.org</email></address></author>
456<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
457<organization abbrev='Xerox'>Xerox Corporation</organization>
458<address>
459<postal>
460<street>MIT Laboratory for Computer Science, NE43-356</street>
461<street>3333 Coyote Hill Road</street>
462<city>Palo Alto</city>
463<region>CA</region>
464<code>94034</code></postal>
465<email>masinter@parc.xerox.com</email></address></author>
466<author initials='P.' surname='Leach' fullname='Paul J. Leach'>
467<organization abbrev='Microsoft'>Microsoft Corporation</organization>
468<address>
469<postal>
470<street>1 Microsoft Way</street>
471<city>Redmond</city>
472<region>WA</region>
473<code>98052</code></postal>
474<email>paulle@microsoft.com</email></address></author>
475<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
476<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
477<address>
478<postal>
479<street>MIT Laboratory for Computer Science, NE43-356</street>
480<street>545 Technology Square</street>
481<city>Cambridge</city>
482<region>MA</region>
483<code>02139</code></postal>
484<facsimile>+1(617)258-8682</facsimile>
485<email>timbl@w3.org</email></address></author>
486<date year='1999' month='June' />
487<abstract>
488<t>
489   The Hypertext Transfer Protocol (HTTP) is an application-level
490   protocol for distributed, collaborative, hypermedia information
491   systems. It is a generic, stateless, protocol which can be used for
492   many tasks beyond its use for hypertext, such as name servers and
493   distributed object management systems, through extension of its
494   request methods, error codes and headers . A feature of HTTP is
495   the typing and negotiation of data representation, allowing systems
496   to be built independently of the data being transferred.
497</t>
498<t>
499   HTTP has been in use by the World-Wide Web global information
500   initiative since 1990. This specification defines the protocol
501   referred to as "HTTP/1.1", and is an update to RFC 2068 .
502</t></abstract></front>
503
504<seriesInfo name='RFC' value='2616' />
505<format type='TXT' octets='422317' target='http://www.rfc-editor.org/rfc/rfc2616.txt' />
506<format type='PS' octets='5529857' target='http://www.rfc-editor.org/rfc/rfc2616.ps' />
507<format type='PDF' octets='550558' target='http://www.rfc-editor.org/rfc/rfc2616.pdf' />
508<format type='HTML' octets='637302' target='http://xml.resource.org/public/rfc/html/rfc2616.html' />
509<format type='XML' octets='493420' target='http://xml.resource.org/public/rfc/xml/rfc2616.xml' />
510</reference>
511
512
513
514<reference anchor='RFC6570'>
515
516<front>
517<title>URI Template</title>
518<author initials='J.' surname='Gregorio' fullname='J. Gregorio'>
519<organization /></author>
520<author initials='R.' surname='Fielding' fullname='R. Fielding'>
521<organization /></author>
522<author initials='M.' surname='Hadley' fullname='M. Hadley'>
523<organization /></author>
524<author initials='M.' surname='Nottingham' fullname='M. Nottingham'>
525<organization /></author>
526<author initials='D.' surname='Orchard' fullname='D. Orchard'>
527<organization /></author>
528<date year='2012' month='March' />
529<abstract>
530<t>A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion.  This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet. [STANDARDS-TRACK]</t></abstract></front>
531
532<seriesInfo name='RFC' value='6570' />
533<format type='TXT' octets='79813' target='http://www.rfc-editor.org/rfc/rfc6570.txt' />
534</reference>
535
536
537
538<reference anchor='RFC6282'>
539
540<front>
541<title>Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks</title>
542<author initials='J.' surname='Hui' fullname='J. Hui'>
543<organization /></author>
544<author initials='P.' surname='Thubert' fullname='P. Thubert'>
545<organization /></author>
546<date year='2011' month='September' />
547<abstract>
548<t>This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks".  This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs).  The compression format relies on shared context to allow compression of arbitrary prefixes.  How the information is maintained in that shared context is out of scope.  This document specifies compression of multicast addresses and a framework for compressing next headers.  UDP header compression is specified within this framework. [STANDARDS-TRACK]</t></abstract></front>
549
550<seriesInfo name='RFC' value='6282' />
551<format type='TXT' octets='52588' target='http://www.rfc-editor.org/rfc/rfc6282.txt' />
552</reference>
553
554
555
556<reference anchor='RFC6775'>
557
558<front>
559<title>Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)</title>
560<author initials='Z.' surname='Shelby' fullname='Z. Shelby'>
561<organization /></author>
562<author initials='S.' surname='Chakrabarti' fullname='S. Chakrabarti'>
563<organization /></author>
564<author initials='E.' surname='Nordmark' fullname='E. Nordmark'>
565<organization /></author>
566<author initials='C.' surname='Bormann' fullname='C. Bormann'>
567<organization /></author>
568<date year='2012' month='November' />
569<abstract>
570<t>The IETF work in IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4.  This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation.  In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links.  IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network.  This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks.  The document thus updates RFC 4944 to specify the use of the optimizations defined here. [STANDARDS-TRACK]</t></abstract></front>
571
572<seriesInfo name='RFC' value='6775' />
573<format type='TXT' octets='130616' target='http://www.rfc-editor.org/rfc/rfc6775.txt' />
574</reference>
575
576
577
578<reference anchor='RFC6550'>
579
580<front>
581<title>RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks</title>
582<author initials='T.' surname='Winter' fullname='T. Winter'>
583<organization /></author>
584<author initials='P.' surname='Thubert' fullname='P. Thubert'>
585<organization /></author>
586<author initials='A.' surname='Brandt' fullname='A. Brandt'>
587<organization /></author>
588<author initials='J.' surname='Hui' fullname='J. Hui'>
589<organization /></author>
590<author initials='R.' surname='Kelsey' fullname='R. Kelsey'>
591<organization /></author>
592<author initials='P.' surname='Levis' fullname='P. Levis'>
593<organization /></author>
594<author initials='K.' surname='Pister' fullname='K. Pister'>
595<organization /></author>
596<author initials='R.' surname='Struik' fullname='R. Struik'>
597<organization /></author>
598<author initials='JP.' surname='Vasseur' fullname='JP. Vasseur'>
599<organization /></author>
600<author initials='R.' surname='Alexander' fullname='R. Alexander'>
601<organization /></author>
602<date year='2012' month='March' />
603<abstract>
604<t>Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained.  LLN routers typically operate with constraints on processing power, memory, and energy (battery power).  Their interconnects are characterized by high loss rates, low data rates, and instability.  LLNs are comprised of anything from a few dozen to thousands of routers.  Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point).  This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported.  Support for point-to-point traffic is also available. [STANDARDS-TRACK]</t></abstract></front>
605
606<seriesInfo name='RFC' value='6550' />
607<format type='TXT' octets='360651' target='http://www.rfc-editor.org/rfc/rfc6550.txt' />
608</reference>
609
610
611
612<reference anchor='I-D.ietf-core-coap'>
613<front>
614<title>Constrained Application Protocol (CoAP)</title>
615
616<author initials='Z' surname='Shelby' fullname='Zach Shelby'>
617    <organization />
618</author>
619
620<author initials='K' surname='Hartke' fullname='Klaus Hartke'>
621    <organization />
622</author>
623
624<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
625    <organization />
626</author>
627
628<date month='June' day='28' year='2013' />
629
630<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>
631
632</front>
633
634<seriesInfo name='Internet-Draft' value='draft-ietf-core-coap-18' />
635<format type='TXT'
636        target='http://www.ietf.org/internet-drafts/draft-ietf-core-coap-18.txt' />
637</reference>
638
639
640
641
642    </references>
643
644    <references title='Informative References'>
645
646
647
648
649
650<reference anchor='I-D.ietf-lwig-terminology'>
651<front>
652<title>Terminology for Constrained Node Networks</title>
653
654<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
655    <organization />
656</author>
657
658<author initials='M' surname='Ersue' fullname='Mehmet Ersue'>
659    <organization />
660</author>
661
662<author initials='A' surname='Keranen' fullname='Ari Keranen'>
663    <organization />
664</author>
665
666<date month='April' day='22' year='2013' />
667
668<abstract><t>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.</t></abstract>
669
670</front>
671
672<seriesInfo name='Internet-Draft' value='draft-ietf-lwig-terminology-04' />
673<format type='TXT'
674        target='http://www.ietf.org/internet-drafts/draft-ietf-lwig-terminology-04.txt' />
675</reference>
676
677
678
679<reference anchor='I-D.kovatsch-lwig-coap'>
680<front>
681<title>CoAP Implementation Guidance</title>
682
683<author initials='M' surname='Kovatsch' fullname='Matthias Kovatsch'>
684    <organization />
685</author>
686
687<author initials='O' surname='Bergmann' fullname='Olaf Bergmann'>
688    <organization />
689</author>
690
691<author initials='A' surname='Castellani' fullname='Angelo Castellani'>
692    <organization />
693</author>
694
695<author initials='E' surname='Dijk' fullname='Esko Dijk'>
696    <organization />
697</author>
698
699<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
700    <organization />
701</author>
702
703<date month='July' day='1' year='2013' />
704
705<abstract><t>The Constrained Application Protocol (CoAP) is designed for resource- constrained nodes and networks, e.g., sensor nodes in low-power lossy networks (LLNs).  Still, to implement this Internet protocol on Class 1 devices, i.e., ~ 10 KiB of RAM and ~ 100 KiB of ROM, lightweight implementation techniques are necessary.  This document provides lessons learned from implementing CoAP for tiny, battery-operated networked embedded systems.  The guidelines for transmission state management and developer APIs can also help with the implementation of CoAP for less constrained nodes.</t></abstract>
706
707</front>
708
709<seriesInfo name='Internet-Draft' value='draft-kovatsch-lwig-coap-00' />
710<format type='TXT'
711        target='http://www.ietf.org/internet-drafts/draft-kovatsch-lwig-coap-00.txt' />
712</reference>
713
714
715
716<reference anchor='I-D.arkko-core-sleepy-sensors'>
717<front>
718<title>Implementing Tiny COAP Sensors</title>
719
720<author initials='J' surname='Arkko' fullname='Jari Arkko'>
721    <organization />
722</author>
723
724<author initials='H' surname='Rissanen' fullname='Heidi-Maria Rissanen'>
725    <organization />
726</author>
727
728<author initials='S' surname='Loreto' fullname='Salvatore Loreto'>
729    <organization />
730</author>
731
732<author initials='Z' surname='Turanyi' fullname='Zoltan Turanyi'>
733    <organization />
734</author>
735
736<author initials='O' surname='Novo' fullname='Oscar Novo'>
737    <organization />
738</author>
739
740<date month='July' day='5' year='2011' />
741
742<abstract><t>The authors are developing COAP and IPv6-based sensor networks for environments where lightweight implementations, long battery lifetimes, and minimal management burden are important.  The memo shows how different communication models supported by COAP affect implementation complexity and energy consumption, far more so than mere changes in message syntax.  Our prototype implements a multicast-based IPv6, UDP, COAP, and XML protocol stack in less than 50 assembler instructions.  While this extremely minimal implementation is suitable only for limited applications and makes a number of assumptions, the general conclusions point to need for further work in developing the COAP multicast and observation frameworks.</t></abstract>
743
744</front>
745
746<seriesInfo name='Internet-Draft' value='draft-arkko-core-sleepy-sensors-01' />
747<format type='TXT'
748        target='http://www.ietf.org/internet-drafts/draft-arkko-core-sleepy-sensors-01.txt' />
749</reference>
750
751
752
753<reference anchor='I-D.vial-core-mirror-proxy'>
754<front>
755<title>CoRE Mirror Server</title>
756
757<author initials='M' surname='Vial' fullname='Matthieu Vial'>
758    <organization />
759</author>
760
761<date month='July' day='13' year='2012' />
762
763<abstract><t>The Constrained RESTful Environments (CoRE) working group aims at realizing the REpresentational State Transfer (REST) architecture in a suitable form for the most constrained nodes.  Thanks to the Constrained Application Protocol (CoAP), REST is now applicable to constrained networks.  However the most energy-constrained devices may enter sleep mode and disconnect their network link during several minutes to save energy, hence preventing them from acting as traditional web servers.  This document describes how a sleeping device can store resource representations in an entity called Mirror Server and participate in a constrained RESTful environment.</t></abstract>
764
765</front>
766
767<seriesInfo name='Internet-Draft' value='draft-vial-core-mirror-proxy-01' />
768<format type='TXT'
769        target='http://www.ietf.org/internet-drafts/draft-vial-core-mirror-proxy-01.txt' />
770</reference>
771
772
773
774<reference anchor='I-D.fossati-core-publish-option'>
775<front>
776<title>Publish Option for CoAP</title>
777
778<author initials='T' surname='Fossati' fullname='Thomas Fossati'>
779    <organization />
780</author>
781
782<author initials='P' surname='Giacomin' fullname='Pierpaolo Giacomin'>
783    <organization />
784</author>
785
786<author initials='S' surname='Loreto' fullname='Salvatore Loreto'>
787    <organization />
788</author>
789
790<date month='July' day='9' year='2012' />
791
792<abstract><t>This memo defines the Publish Option for the Constrained Application Protocol (CoAP).  The Publish Option is used by a sleepy node to temporarily delegate the authority of one of its resources to another, always on, node which is typically a proxy but doesn't need to be necessarily.  The sleepy node is given a simple RESTful messaging protocol that enables the setup, renew and removal of the authority transfer.  The whole process is driven by the (sleepy) origin, which may actually never need to listen or to keep any state.</t></abstract>
793
794</front>
795
796<seriesInfo name='Internet-Draft' value='draft-fossati-core-publish-option-00' />
797<format type='TXT'
798        target='http://www.ietf.org/internet-drafts/draft-fossati-core-publish-option-00.txt' />
799</reference>
800
801
802
803<reference anchor='I-D.fossati-core-monitor-option'>
804<front>
805<title>Monitor Option for CoAP</title>
806
807<author initials='T' surname='Fossati' fullname='Thomas Fossati'>
808    <organization />
809</author>
810
811<author initials='P' surname='Giacomin' fullname='Pierpaolo Giacomin'>
812    <organization />
813</author>
814
815<author initials='S' surname='Loreto' fullname='Salvatore Loreto'>
816    <organization />
817</author>
818
819<date month='July' day='9' year='2012' />
820
821<abstract><t>This memo defines Monitor, an additional Option for the Constrained Application Protocol (CoAP) especially targeted at sleepy sensors.  The Monitor Option complements the typical Observe pattern, enabling the tracking of a resource hosted by a node sleeping most of the time, by taking care of establishing and maintaining an Observe relationship with the (sleepy) origin on behalf of the (sleepy) client.</t></abstract>
822
823</front>
824
825<seriesInfo name='Internet-Draft' value='draft-fossati-core-monitor-option-00' />
826<format type='TXT'
827        target='http://www.ietf.org/internet-drafts/draft-fossati-core-monitor-option-00.txt' />
828</reference>
829
830
831<reference anchor="powertrace" >
832  <front>
833    <title>Powertrace: Network-level Power Profiling for Low-power Wireless Networks</title>
834    <author initials="A." surname="Dunkels" fullname="Adam Dunkels">
835      <organization></organization>
836    </author>
837    <author initials="J." surname="Eriksson" fullname="Joakim Eriksson">
838      <organization></organization>
839    </author>
840    <author initials="N." surname="Finne" fullname="Joakim Tsiftes">
841      <organization></organization>
842    </author>
843    <author initials="N." surname="Tsiftes" fullname="Joakim Tsiftes">
844      <organization></organization>
845    </author>
846    <date year="2011" month="March"/>
847  </front>
848  <seriesInfo name="SICS Technical Report T2011:05" value=""/>
849</reference>
850<reference anchor="contikimac" >
851  <front>
852    <title>The ContikiMAC Radio Duty Cycling Protocol</title>
853    <author initials="A." surname="Dunkels" fullname="Adam Dunkels">
854      <organization></organization>
855    </author>
856    <date year="2011" month="December"/>
857  </front>
858  <seriesInfo name="SICS Technical Report T2011:13" value=""/>
859</reference>
860<reference anchor="crosslayeropt" >
861  <front>
862    <title>Cross-Layer Optimization Frameworks for Multihop Wireless Networks Using Cooperative Diversity</title>
863    <author initials="L." surname="Le" fullname="Long Le">
864      <organization></organization>
865    </author>
866    <author initials="E." surname="Hossain" fullname="Ekram Hossain">
867      <organization></organization>
868    </author>
869    <date year="2008" month="July"/>
870  </front>
871  <seriesInfo name="IEEE Transactions on Wireless Communications" value=""/>
872</reference>
873<reference anchor="crosslayerdesign" >
874  <front>
875    <title>Cross-Layer Design in Multihop Wireless Networks</title>
876    <author initials="." surname="Lijun Chen" fullname="Lijun Chen">
877      <organization></organization>
878    </author>
879    <author initials="S.H." surname="Low" fullname="Steven H. Low">
880      <organization></organization>
881    </author>
882    <author initials="J.C." surname="Doyle" fullname="John C. Doyle">
883      <organization></organization>
884    </author>
885    <date year="2011"/>
886  </front>
887  <seriesInfo name="Computer Networks" value=""/>
888</reference>
889<reference anchor="lpwifi" >
890  <front>
891    <title>Connecting Things to the Web using Programmable Low-power WiFi Modules</title>
892    <author initials="B." surname="Ostermaier" fullname="Benedikt Ostermaier">
893      <organization></organization>
894    </author>
895    <author initials="M." surname="Kovatsch" fullname="Matthias Kovatsch">
896      <organization></organization>
897    </author>
898    <author initials="S." surname="Santini" fullname="Silvia Santini">
899      <organization></organization>
900    </author>
901    <date year="2011" month="June"/>
902  </front>
903  <seriesInfo name="Proceedings of the 2nd International Workshop on the Web of Things (WoT 2011). San Francisco, CA, USA" value=""/>
904</reference>
905<reference anchor="amac" >
906  <front>
907    <title>Designand Evaluation of a Versatile and Efficient Receiver-Initiated Link Layer for Low-Power Wireless</title>
908    <author initials="P." surname="Dutta" fullname="Prabal Dutta">
909      <organization></organization>
910    </author>
911    <author initials="S." surname="Dawson-Haggerty" fullname="Stephen Dawson-Haggerty">
912      <organization></organization>
913    </author>
914    <author initials="Y." surname="Chen" fullname="Yin Chen">
915      <organization></organization>
916    </author>
917    <author initials="C.-J.M." surname="Liang" fullname="Chieh-Jan Mike Liang">
918      <organization></organization>
919    </author>
920    <author initials="A." surname="Terzis" fullname="Andreas Terzis">
921      <organization></organization>
922    </author>
923    <date year="2010" month="November"/>
924  </front>
925  <seriesInfo name="Proceedings of the International Conference on Embedded Networked Sensor Systems (SenSys 2010). Zurich, Switzerland" value=""/>
926</reference>
927
928
929    </references>
930
931
932
933  </back>
934</rfc>
935
Note: See TracBrowser for help on using the repository browser.