Changeset 25


Ignore:
Timestamp:
Jul 4, 2013, 9:49:52 PM (6 years ago)
Author:
caozhen@…
Message:

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

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-hex-lwig-energy-efficient.xml

    r23 r25  
    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"?>
     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"?>
    1313
    1414  <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">
     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">
    1819      <organization>China Mobile</organization>
     20
    1921      <address>
    2022        <postal>
    2123          <street>32 Xuanwumenxi Ave.</street>
     24
    2225          <city>Beijing, 100871</city>
    23          
    24          
     26
    2527          <country>P.R.China</country>
    2628        </postal>
    27        
    28        
     29
    2930        <email>zehn.cao@gmail.com, caozhen@chinamobile.com</email>
    30        
    3131      </address>
    3232    </author>
    33     <author initials="X." surname="He" fullname="Xuan He">
     33
     34    <author fullname="Xuan He" initials="X." surname="He">
    3435      <organization>Hitachi (China) R&amp;D Corp.</organization>
     36
    3537      <address>
    3638        <postal>
    3739          <street>301, Tower C North, Raycom, 2 Kexuyuan Nanlu</street>
     40
    3841          <city>Beijing, 100190</city>
    39          
    40          
     42
    4143          <country>P.R.China</country>
    4244        </postal>
    43        
    44        
     45
    4546        <email>xhe@hitachi.cn</email>
    46        
    4747      </address>
    4848    </author>
    49     <author initials="M." surname="Kovatsch" fullname="Matthias Kovatsch">
     49
     50    <author fullname="Matthias Kovatsch" initials="M." surname="Kovatsch">
    5051      <organization>ETH Zurich</organization>
     52
    5153      <address>
    5254        <postal>
    53           <street>Universitätstrasse 6</street>
     55          <street>Universit&auml;tstrasse 6</street>
     56
    5457          <city>CH-8092 Zurich</city>
    55          
    56          
     58
    5759          <country>Switzerland</country>
    5860        </postal>
    59        
    60        
     61
    6162        <email>kovatsch@inf.ethz.ch</email>
    62        
    6363      </address>
    6464    </author>
    6565
    66     <date year="2013" month="July" day="01"/>
     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"/>
    6793
    6894    <area>Internet</area>
     95
    6996    <workgroup>LWIG Working Group</workgroup>
     97
    7098    <keyword>Internet-Draft</keyword>
    7199
    72100    <abstract>
    73 
    74 
    75 <t>For IP-based Internet of Things devices to be battery-operated, protocols
    76 within IETF scope also need to behave energy friendly. This document summarizes
    77 the problems and current practices of energy-efficient protocol implementation
    78 on constrained devices.</t>
    79 
    80 
    81 
     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>
    82105    </abstract>
    83 
    84 
    85106  </front>
    86107
    87108  <middle>
    88 
    89 
    90 <section anchor="introduction" title="Introduction">
    91 
    92 <t>In many scenarios of embedded systems, the networked system is
    93 composed of many battery-powered devices.  For example, in an
    94 environmental monitoring system or a temperature and humidity
    95 monitoring system in the data center, there are no always-on and
    96 handy sustained power supplies for the large number of small devices.
    97 In such deployment environments, it is necessary to optimize the
    98 energy consumption of the entire system, including computing,
    99 application layer behavior, and lower layer communication.</t>
    100 
    101 <t>Various research efforts have been spent on this “energy efficiency”
    102 problem.  Most of this research has focused on how to optimize the
    103 system’s power consumption regarding a certain deployment scenario or
    104 how could an exisiting network function such as routing or security
    105 be more energy-efficient.  Only few efforts were spent on energy-
    106 efficient designs for IETF protocols and standardized network stacks
    107 for 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
    110 such 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
    112 document tries to summarize the design considerations of making the IETF
    113 protocol suite as energy-efficient as possible.  While this document
    114 does not provide detailed and systematic solutions to the energy
    115 efficiency problem, it summarizes the design efforts and analyzes the
    116 design space of this problem.</t>
    117 
    118 <t>After reviewing the energy-efficient design of each layer, an overall
    119 conclusion is summarized.  Though the lower layer communication
    120 optimization is the key part of energy efficient design, the protocol
    121 design at the network and application layers is also important to
    122 make 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
    134 communication between constrained nodes and fully capable nodes.
    135 This work has witnessed the evolution of the traditional Internet
    136 protocol stack to a light-weight Internet protocol stack.  As show in
    137 Figure 1 below, the IETF has developed CoAP as the application layer
    138 and 6LoWPAN as the adaption layer to run IPv6 over IEEE 802.15.4 and
    139 Bluetooth Low-Energy, with the support of routing by RPL and
    140 efficient neighbor discovery by 6LoWPAN-ND.</t>
    141 
    142 <figure title="Traditional and Lighweight Internet Protocol Stack" anchor="stack"><artwork><![CDATA[
     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[
    143163  +------+   +-----+     +------+              +------+
    144164  | HTTP |   | ftp |     | SNMP |              | COAP |
     
    160180                                               |MAC/PHY|
    161181                                               +-------+
    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
    166 most common atom operations on a prevalent sensor node platform.  The
    167 measurement was based on the Tmote Sky with ContikiMAC as the radio
    168 duty cycling algorithm.  From the measurement, we can see that
    169 optimized transmissions and reception consume almost the same amount
    170 of energy.  For IEEE 802.15.4 and UWB radios, transmitting is
    171 actually even cheaper than receiving.  Only for broadcast and non-
    172 synchronized communication transmissions become costly in terms of
    173 energy 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
    203 are intertwined.  The communication device is typically the most
    204 power-consuming component, but merely refraining from transmissions
    205 is not enough to attain a low power consumption: the radio consumes
    206 as much power in listen mode as when actively transmitting, as show
    207 in <xref target="powertbl"/>.  To reduce power consumption, the radio must be
    208 switched completely off – duty-cycled – as much as possible.
    209 However, radio duty cycling (RDC) performs periodic channel checks to
    210 realize a virtual always-on link. This is the main difference to so
    211 called 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
    214 and MAC.  The upper layers can remain more or less untouched and only
    215 experience a higher latency. (Note that this might require tweaking the
    216 timeout parameters.)  State-of-the-art RDC layers can achieve an idle
    217 duty cycling way below 1% while checking the channel several times per
    218 second.  ContikiMAC <xref target="contikimac"/> for instance achieves a 0.3% cycle
    219 with a channel check rate of 4 Hz, which results in a worst-case delay
    220 of 250ms per hop.  While saving energy, ContikiMAC’s link-layer
    221 transmissions are also more robust due to its retransmission policy.
    222 Please 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
    226 the first approach, the sender of a message enables the radio first
    227 and continuously announces its attendance to send (note that for IEEE
    228 802.15.4 transceivers, transmitting consumes less energy than
    229 receiving).  Receivers periodically turn on only periodically to
    230 check for these announcements.  If they sense a busy channel, the
    231 radio is turned on for a longer period to receive a potential
    232 message.  In the other approach, the receiver periodically announces
    233 that it will keep on its radio for a while.  When a node wants to
    234 send, it turns on its radio to listen for these announcements and
    235 does so when it hears the recipient (following the scheme of the
    236 above MAC layer of course).  Which approach is optimal mainly depends
    237 on 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
    240 designers and chipset manufactures take great care of the problem.
    241 For the IETF protocol designers, however, it is good to know the
    242 behaviors of lower layers so that the designed protocols can work
    243 perfectly with them. The IETF protocols we are going to talk about in
    244 the following sections are the customers of the lower layer.  If they
    245 want to get better service in a cooperative way, they should be
    246 considerative 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.
    252 It was born to fill the gap that the IPv6 layer does not support
    253 fragmentation and assembly of &lt;1280-byte packets while IEEE 802.15.4
    254 only supports a MTU of 127 bytes.</t>
    255 
    256 <t>IPv6 is the basis for the higher layer protocols, including both TCP/UDP
    257 transport and applications.  So they are quite ignorant of the
    258 transmission and reception behaviors, and are almost neutral to the
    259 energy-efficiency problem.</t>
    260 
    261 <t>What the network stack can optimize is to save the computing power.
    262 For example the Contiki implementation has multiple cross layer
    263 optimizations for buffers and energy management, e.g., the computing
    264 and validation of UDP/TCP checksums without the need of reading IP
    265 headers from a different layer.  These optimizations are software
    266 implementation techniques, and out of the scope of IETF and the LWIG
    267 working group.</t>
    268 
    269 <t>The 6LoWPAN contributes to the energy-efficiency problem in two ways.
    270 First of all, it swaps computing with communication. 6LoWPAN applies
    271 compression of the IPv6 header.  This means less amount of data will
    272 be handled by the lower layer, but both the sender and receiver
    273 should spend more computing power on the compression and
    274 decompression of the packets over the air.  Secondly, the 6LoWPAN
    275 working group developed the energy-efficient Neigbor Discovery called
    276 6LoWPAN-ND, which is an energy efficient replacement of the IPv6 ND
    277 in constrained environments.  IPv6 Neighbor Discovery was not
    278 designed for non-transitive wireless links, as its heavy use of
    279 multicast makes it inefficient and sometimes impractical in a low-power
    280 and lossy network. 6LoWPAN-ND describes simple optimizations to
    281 IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate
    282 address detection for Low-power Wireless Personal Area Networks and
    283 similar 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
    289 environments is called RPL <xref target="RFC6550"/>.  As a routing protocol, RPL has
    290 to exchange messages periodically and keep routing states for each
    291 destination.  RPL is optimized for the many-to-one commununication
    292 pattern, where network nodes primarily send data towards the border
    293 router, 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.
    296 It devides the routing protocol into control and data traffic.  The
    297 control channel uses ICMP messages to establish and maintain the
    298 routing states.  The data channel is any application that uses RPL
    299 for routing packets.  The study has shown that the power consumption
    300 of the control traffic goes down over time and data traffic stays
    301 relatively constant.  The study also reflects that the routing
    302 protocol should keep the control traffic as low as possible to make
    303 it 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
    309 protocol, connecting the services of smart devices to the World Wide
    310 Web. CoAP is not a chatty protocol, it provides basic communication
    311 services such as service discovery and GET/POST/PUT/DELETE methods
    312 with 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
    317 protocol design.  To reduce regular and frequent queries of the
    318 resources, CoAP provides an observe mode, in which the requester
    319 registers its interest of a certain resource and the responder will
    320 report the value whenever it was updated.  This reduces the request
    321 reponse roundtrip while keeping information exchange a ubiquitous
    322 service.</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
    328 sleepy nodes. In contrast to the periodic channel checks of RDC, they
    329 put the radio into hibernation for a long period during which the node is
    330 fully disconnected from the network.
    331 Going to sleep for a longer time it not transparent for the
    332 application layer, as nodes need to re-synchronize and maybe re-
    333 associate with the network.  Several drafts in the IETF CoRE working
    334 group 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
    337 integrated into the application layer implementation of the nodes as well
    338 as the back-end systems.  In addition, alternatives to standard diagnosis
    339 tools such as ICMP ping will have to be provided, e.g., heartbeats by the
    340 application.</t>
    341 
    342 <t>This strategy is particular useful for communications other than
    343 IEEE 802.15.4.  Low-power Wi-Fi for instance is mainly based on long
    344 sleeping periods with short wake-up cycles.  Although the data rate
    345 would be high enough for HTTP over TCP, low-power Wi-FI can greatly
    346 benefit from CoAP and its shorter roundtrip times.  For further
    347 information about sleepy nodes based on low-power Wi-Fi see <xref target="lpwifi"/>.
    348 Another interesting example are SIM card based devices that use the
    349 Short Message Service (SMS). It comes with its own reliable and
    350 delay-tolerant delivery. Hence, no additional back-end systems such as
    351 mirror 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
    358 scenarios.There are some technologies for power efficient
    359 optimization via PHY to Routing cross layer design
    360 <xref target="crosslayeropt"/>.  In this research, cross-layer
    361 optimization frameworks have been developed to minimize the total
    362 power consumption or to maximize the utility-power tradeoff using
    363 cooperative diversity.</t>
    364 
    365 <t>Also a cross-layer design in multihop wireless networks is proposed
    366 for congestion control, routing and scheduling–in transport, network
    367 and link layers into a coherent framework <xref target="crosslayerdesign"/>.  This
    368 method and thinking could be applied to the implementation of energy
    369 effective cross layer design.</t>
    370 
    371 <t>Therefore, from the APP layer to the PHY layer, it should be considering
    372 the energy distribution of the entire protocol stack to achieve optimal
    373 energy efficiency.</t>
    374 
    375 <figure title="Affected layers" anchor="crosslayer"><artwork><![CDATA[
     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[
    376455                  +------+
    377456                  |  APP |          -------+
     
    393472                      |MAC/PHY|    --------+
    394473                      +-------+
    395 ]]></artwork></figure>
    396 
    397 </section>
    398 
    399 
     474]]></artwork>
     475      </figure>
     476    </section>
    400477  </middle>
    401478
    402479  <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 
     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>
    642919    </references>
    643920
    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 
     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>
    9291302    </references>
    930 
    931 
    932 
    9331303  </back>
    9341304</rfc>
    935 
Note: See TracChangeset for help on using the changeset viewer.