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

Last change on this file was 25, checked in by caozhen@…, 6 years ago

update with 802.11v power save mode, contributed by Hui Tian
-zhen

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