One document matched: draft-ietf-lwig-terminology-05.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<rfc ipr="trust200902" docName="draft-ietf-lwig-terminology-05" category="info">

<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

  <front>
    <title abbrev="CNN terminology">Terminology for Constrained Node Networks</title>

    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
      <organization>Universitaet Bremen TZI</organization>
      <address>
        <postal>
          <street>Postfach 330440</street>
          <city>D-28359 Bremen</city>
          
          
          <country>Germany</country>
        </postal>
        <phone>+49-421-218-63921</phone>
        
        <email>cabo@tzi.org</email>
        
      </address>
    </author>
    <author initials="M." surname="Ersue" fullname="Mehmet Ersue">
      <organization>Nokia Siemens Networks</organization>
      <address>
        <postal>
          <street>St.-Martinstrasse 76</street>
          <city>81541 Munich</city>
          
          
          <country>Germany</country>
        </postal>
        <phone>+49 172 8432301</phone>
        
        <email>mehmet.ersue@nsn.com</email>
        
      </address>
    </author>
    <author initials="A." surname="Keranen" fullname="Ari Keranen">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>Hirsalantie 11</street>
          <city>02420 Jorvas</city>
          
          
          <country>Finland</country>
        </postal>
        
        
        <email>ari.keranen@ericsson.com</email>
        
      </address>
    </author>

    <date year="2013" month="July" day="09"/>

    <area>Internet</area>
    <workgroup>LWIG Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <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>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>Small devices with limited CPU, memory, and power resources, so called
constrained devices (also known as sensor, smart object, or smart device) can
constitute a network, becoming “constrained nodes” in that network.
Such a network may itself exhibit constraints, e.g. with unreliable or
lossy channels, limited and unpredictable bandwidth, and a highly
dynamic topology.</t>

<t>Constrained devices might be in charge of gathering information in
diverse settings including natural ecosystems, buildings, and
factories and sending the information to one or more server stations.
Constrained devices may work under severe resource constraints such
as limited battery and computing power, little memory, as well as
insufficient wireless bandwidth and ability to communicate.
Other entities on the network, e.g., a base station or controlling
server, might have more computational and communication resources and
could support the interaction between the constrained devices and
applications in more traditional networks.</t>

<t>Today diverse sizes of constrained devices with different resources
and capabilities are becoming connected.  Mobile personal gadgets,
building-automation devices, cellular phones, Machine-to-machine (M2M)
devices, etc. benefit from interacting with other “things” nearby
or somewhere in the Internet.  With this, the Internet of Things (IoT)
becomes a reality, built up out of uniquely identifiable and
addressable objects (things).  And over the next decade, this could
grow to large numbers <xref target="fifty-billion"/> of Internet-connected constrained
devices, greatly increasing the Internet’s size and scope.</t>

<t>The present document provides a number of basic terms that have turned
out to be useful in the standardization work for constrained
environments.  The intention is not to exhaustively cover the field,
but to make sure a few core terms are used consistently between
different groups cooperating in this space.</t>

<t>In this document, the term “byte” is used in its now customary sense
as a synonym for “octet”.  Where sizes of semiconductor memory are
given, the prefix “kibi” (1024) is combined with “byte” to “kibibyte”,
abbreviated “KiB”, for 1024 bytes <xref target="ISQ-13"/>.</t>

</section>
<section anchor="terminology" title="Terminology">

<t>The main focus of this field of work appears to be <spanx style='emph'>scaling</spanx>:</t>

<t><list style='symbols'>
  <t>Scaling up Internet technologies to a large number <xref target="fifty-billion"/> of
inexpensive nodes, while</t>
  <t>scaling down the characteristics of each of these nodes and of the
networks being built out of them, to make this scaling up economically
and physically viable.</t>
</list></t>

<t>The need for scaling down the characteristics of nodes leads to
<spanx style='emph'>constrained nodes</spanx>.</t>

<section anchor="constrained-nodes" title="Constrained Nodes">

<t>The term “constrained node” is best defined by contrasting the
characteristics of a constrained node with certain widely held
expectations on more familiar Internet nodes:</t>

<t><list style='hanging'>
  <t hangText='Constrained Node:'>
  A node where some of the characteristics that are otherwise pretty
much taken for granted for Internet nodes in 2013 are not
attainable, often due to cost constraints and/or physical
constraints on characteristics such as size, weight, and available
power and energy.</t>
</list></t>

<t>While this is less than satisfying as a rigorous definition, it is
grounded in the state of the art and clearly sets apart constrained
nodes from server systems, desktop or laptop computers, powerful
mobile devices such as smartphones etc.  There may be many design
considerations that lead to these constraints, including cost, size,
weight, and other scaling factors.</t>

<t>(An alternative name, when the properties as a network node are not in
focus, is “constrained device”.)</t>

<t>There are multiple facets to the constraints on nodes, often applying
in combination, e.g.:</t>

<t><list style='symbols'>
  <t>constraints on the maximum code complexity (ROM/Flash);</t>
  <t>constraints on the size of state and buffers (RAM);</t>
  <t>constraints on the available power.</t>
</list></t>

<t><xref target="devclass"/> defines a small number of interesting classes (“class-N”
for N=0,1,2) of constrained nodes focusing on relevant combinations of
the first two constraints.
With respect to available power, <xref target="RFC6606"/> distinguishes
“power-affluent” nodes (mains-powered or regularly recharged) from
“power-constrained nodes” that draw their power from primary batteries
or by using energy harvesting; more detailed power terminology is
given in <xref target="power"/>.</t>

<t>The use of constrained nodes in networks often also leads to
constraints on the networks themselves.  However, there may also be
constraints on networks that are largely independent from those of the
nodes.  We therefore distinguish <spanx style='emph'>constrained networks</spanx> and
<spanx style='emph'>constrained node networks</spanx>.</t>

<!--
[Editorial question: do you want to use capitalization for Constrained Node and Constrained Network and other terms you are defining?]
-->

</section>
<section anchor="constrained-networks" title="Constrained Networks">

<t>We define “constrained network” in a similar way:</t>

<t><list style='hanging'>
  <t hangText='Constrained Network:'>
  A network where some of the characteristics pretty much taken for
granted with link layers in common use in the Internet by 2013, are
not attainable.</t>
</list></t>

<t>Again, there may be several reasons for this:</t>

<t><list style='symbols'>
  <t>cost constraints on the network,</t>
  <t>constraints of the nodes (for constrained node networks),</t>
  <t>physical constraints (e.g., power constraints, environmental
constraints, media constraints
such as underwater operation, limited spectrum for very high
density, electromagnetic compatibility),</t>
  <t>regulatory constraints, such as very limited spectrum availability
(including limits on effective radiated power and duty cycle), or
explosion safety,</t>
  <t>technology constraints, such as older and lower speed technologies that
are still operational and may need to stay in use for some more time.</t>
</list></t>

<t>Constraints may include:</t>

<t><list style='symbols'>
  <t>low achievable bit rate (including limits on duty cycle),</t>
  <t>high packet loss, packet loss (delivery rate) variability,</t>
  <t>severe penalties for using larger packets (e.g., high packet loss
due to link layer fragmentation),</t>
  <t>lack of (or severe constraints on) advanced services such as IP multicast.</t>
</list></t>

<section anchor="challenged-networks" title="Challenged Networks">

<t>A constrained network is not necessarily a <spanx style='emph'>challenged</spanx> network <xref target="FALL"/>:</t>

<t><list style='hanging'>
  <t hangText='Challenged Network:'>
  A network that has serious trouble maintaining what an application
would today expect of the end-to-end IP model, e.g., by:</t>
</list></t>

<t><list style='symbols'>
  <t>not being able to offer end-to-end IP connectivity at all;</t>
  <t>exhibiting serious interruptions in end-to-end IP connectivity;</t>
  <t>exhibiting delay well beyond the Maximum Segment Lifetime (MSL)
defined by TCP <xref target="RFC0793"/>.</t>
</list></t>

<t>All challenged networks are constrained networks in some sense, but
not all constrained networks are challenged networks.  There is no
well-defined boundary between the two, though.  Delay-Tolerant
Networking (DTN) has been designed to cope with challenged networks
<xref target="RFC4838"/>.</t>

</section>
</section>
<section anchor="constrained-node-networks" title="Constrained Node Networks">

<t><list style='hanging'>
  <t hangText='Constrained Node Network:'>
  A network whose characteristics are influenced by being composed of
a significant portion of constrained nodes.</t>
</list></t>

<t>A constrained node network always is a constrained network because of
the network constraints stemming from the node constraints, but may
also have other constraints that already make it a constrained network.</t>

<section anchor="lln-low-power-lossy-network" title="LLN (“low-power lossy network”)">

<t>A related term that has been used recently is “low-power lossy
network” (LLN).  In its terminology document,
the ROLL working group is saying <xref target="I-D.ietf-roll-terminology"/>:</t>

<t><list style='empty'>
  <t>LLN: Low power and Lossy networks (LLNs) are typically composed of
   many embedded devices with limited power, memory, and processing
   resources interconnected by a variety of links, such as IEEE 802.15.4
   or Low Power WiFi.  There is a wide scope of application areas for
   LLNs, including industrial monitoring, building automation (HVAC,
   lighting, access control, fire), connected home, healthcare,
   environmental monitoring, urban sensor networks, energy management,
   assets tracking and refrigeration.. [sic]</t>
</list></t>

<t>In common usage, LLN often stands for
“the network characteristics that RPL has been designed for”.
Beyond what is said in the ROLL terminology document,
LLNs do appear to have significant loss at the physical layer, with
significant variability of the delivery rate, and some short-term
unreliability, coupled with some medium term stability that makes it
worthwhile to construct medium-term stable directed acyclic graphs for
routing and do measurements on the edges such as ETX <xref target="RFC6551"/>.
Actual “low power” does not seem to be required for an LLN
<xref target="I-D.hui-vasseur-roll-rpl-deployment"/>, and the positions on
scaling of LLNs appear to vary widely <xref target="I-D.clausen-lln-rpl-experiences"/>.</t>

<t>The ROLL terminology document states that LLNs typically are composed
of constrained nodes; this is also supported by the design of
operation modes such as RPL’s “non-storing mode”.  So, in the
terminology of the present document, an LLN seems to be a constrained
node network with certain network characteristics, which include
constraints on the network as well.</t>

</section>
<section anchor="lowpan-6lowpan" title="LoWPAN, 6LoWPAN">

<t>One interesting class of a constrained network often used as a
constrained node network is the “LoWPAN” <xref target="RFC4919"/>, a term inspired
from the name of the IEEE 802.15.4 working group (low-rate wireless
personal area networks (LR-WPANs)).  The expansion of that acronym,
“Low-Power Wireless Personal Area Network” contains a hard to justify
“Personal” that is due to the history of task group naming in IEEE 802
more than due to an
orientation of LoWPANs around a single person.  Actually, LoWPANs have
been suggested for urban monitoring, control of large buildings, and
industrial control applications, so the “Personal” can only be
considered a vestige.  Maybe the term is best read as “Low-Power
Wireless Area Networks” (LoWPANs) <xref target="WEI"/>.  Originally focused on IEEE
802.15.4, “LoWPAN” (or when used for IPv6, “6LoWPAN”) is now also
being used for networks built from similarly constrained link layer
technologies <xref target="I-D.ietf-6lowpan-btle"/> <xref target="I-D.mariager-6lowpan-v6over-dect-ule"/> <xref target="I-D.brandt-6man-lowpanz"/>.</t>

<t><vspace blankLines='999' /></t>

</section>
</section>
</section>
<section anchor="devclass" title="Classes of Constrained Devices">

<t>Despite the overwhelming variety of Internet-connected devices that
can be envisioned, it may be worthwhile to have some succinct
terminology for different classes of constrained devices.  In this
document, the class designations in <xref target="devclasstbl"/> may be used as rough
indications of device capabilities:</t>

<texttable title="Classes of Constrained Devices (KiB = 1024 bytes)" anchor="devclasstbl">
      <ttcol align='left'>Name</ttcol>
      <ttcol align='left'>data size (e.g., RAM)</ttcol>
      <ttcol align='left'>code size (e.g., Flash)</ttcol>
      <c>Class 0, C0</c>
      <c>« 10 KiB</c>
      <c>« 100 KiB</c>
      <c>Class 1, C1</c>
      <c>~ 10 KiB</c>
      <c>~ 100 KiB</c>
      <c>Class 2, C2</c>
      <c>~ 50 KiB</c>
      <c>~ 250 KiB</c>
</texttable>

<t>As of the writing of this document, these characteristics correspond
to distinguishable clusters of commercially available chips and design
cores for constrained devices.  While it is expected that the
boundaries of these classes will move over time, Moore’s law tends to
be less effective in the embedded space than in personal computing
devices: Gains made available by increases in transistor count and
density are more likely to be invested in reductions of cost and power
requirements than into continual increases in computing power.</t>

<t>Class 0 devices are very constrained sensor-like motes.  Most likely
they will not be able to communicate directly with the Internet in a
secure manner.  Class 0 devices will participate in Internet
communications with the help of larger devices acting as proxies,
gateways or servers.  Class 0 devices generally cannot be secured or managed
comprehensively in the traditional sense.  They will most likely be
preconfigured (and will be reconfigured rarely, if at all), with a very
small data set.  For management purposes, they could answer keepalive
signals and send on/off or basic health indications.</t>

<t>Class 1 devices cannot easily talk to other Internet nodes employing a
full protocol stack such as using HTTP, TLS and related security
protocols and XML-based data representations.  However, they have
enough power to use a protocol stack specifically designed for
constrained nodes (e.g., CoAP over UDP) and participate in meaningful
conversations without the help of a gateway node.  In particular, they
can provide support for the security functions required on a large
network.  Therefore, they can be integrated as fully developed peers
into an IP network, but they need to be parsimonious with state
memory, code space, and often power expenditure for protocol and
application usage.</t>

<t>Class 2 can already support mostly the same protocol stacks as used on
notebooks or servers.  However, even these devices can benefit from
lightweight and energy-efficient protocols and from consuming less
bandwidth.  Furthermore, using fewer resources for networking leaves
more resources available to applications.  Thus, using the protocol
stacks defined for very constrained devices also on Class 2 devices
might reduce development costs and increase the interoperability.</t>

<t>Constrained devices with capabilities significantly beyond Class 2
devices exist.  They are less demanding from a standards development
point of view as they can largely use existing protocols unchanged.
The present document therefore does not make any attempt to define
classes beyond Class 2.  These devices can still be constrained by a
limited energy supply.</t>

<t>With respect to examining the capabilities of constrained nodes,
particularly for Class 1 devices, it is important to understand what
type of applications they are able to run and which protocol
mechanisms would be most suitable.  Because of memory and other
limitations, each specific Class 1 device might be able to support
only a few selected functions needed for its intended operation.  In
other words, the set of functions that can actually be supported is
not static per device type: devices with similar constraints might
choose to support different functions.  Even though Class 2 devices
have some more functionality available and may be able to provide a
more complete set of functions, they still need to be assessed for the
type of applications they will be running and the protocol functions
they would need.  To be able to derive any requirements, the use
cases and the involvement of the devices in the application and the
operational scenario need to be analyzed.  Use cases may combine
constrained devices of multiple classes as well as more traditional
Internet nodes.
<!-- The use cases where Class 1
or Class 2 devices build a cluster or are part of a hierarchy as well
as the assumed degree of automation might be essentially important.
 --></t>

<t><vspace blankLines='999' /></t>

</section>
<section anchor="power" title="Power Terminology">

<t>Devices not only differ in their computing capabilities, but also in
available electrical power and/or energy.  While it is harder to find
recognizable clusters in this space, it is still useful to introduce
some common terminology.</t>

<section anchor="scaling-properties" title="Scaling Properties">

<t>The power and/or energy available to a device may vastly differ, from
kilowatts to microwatts, from essentially unlimited to hundreds of
microjoules.</t>

<t>Instead of defining classes or clusters, we propose simply stating, in
SI units, an approximate value for one or both of the quantities
listed in <xref target="scaletbl"/>:</t>

<texttable title="Quantities Relevant to Power and Energy" anchor="scaletbl">
      <ttcol align='left'>Name</ttcol>
      <ttcol align='left'>Definition</ttcol>
      <ttcol align='left'>SI Unit</ttcol>
      <c>Ps</c>
      <c>Sustainable average power available for the device over the time it is functioning</c>
      <c>W (Watt)</c>
      <c>Et</c>
      <c>Total electrical energy available before the energy source is exhausted</c>
      <c>J (Joule)</c>
</texttable>

<t>The value of Et may need to be interpreted in conjunction with an
indication over which period of time the value is given; see the next
subsection.</t>

</section>
<section anchor="classes-of-energy-limitation" title="Classes of Energy Limitation">

<t>As discussed above, some devices are limited in available energy as
opposed to (or in addition to) being limited in available power.
Where no relevant limitations exist with respect to energy, the device
is classified as E3.
The energy limitation may be in total energy available in the usable
lifetime of the device (e.g. a device with a non-replaceable primary
battery, which is discarded when this battery is exhausted),
classified as E2.
Where the relevant limitation is for a specific period, this is
classified as E1, e.g. a limited amount of energy available for the
night with a solar-powered device, or for the period between recharges
with a device that is manually connected to a charger, or by a
periodic (primary) battery replacement interval.
Finally, there may be a limited amount of energy available for a specific
event, e.g. for a button press in an energy harvesting light switch;
this is classified as E0.
Note that many E1 devices in a sense also are E2, as the rechargeable
battery has a limited number of useful recharging cycles.</t>

<t>In summary, we distinguish (<xref target="enclasstbl"/>):</t>

<texttable title="Classes of Energy Limitation" anchor="enclasstbl">
      <ttcol align='left'>Name</ttcol>
      <ttcol align='left'>Type of energy limitation</ttcol>
      <ttcol align='left'>Example Power Source</ttcol>
      <c>E0</c>
      <c>Event energy-limited</c>
      <c>Event-based harvesting</c>
      <c>E1</c>
      <c>Period energy-limited</c>
      <c>Battery that is periodically recharged or replaced</c>
      <c>E2</c>
      <c>Lifetime energy-limited</c>
      <c>Non-replaceable primary battery</c>
      <c>E3</c>
      <c>No direct quantitative limitations to available energy</c>
      <c>Mains powered</c>
</texttable>

</section>
<section anchor="poweruse" title="Strategies of Using Power for Communication">

<t>Especially when wireless transmission is used, the radio often
consumes a big portion of the total energy consumed by the device.
Design parameters such as the available spectrum, the desired range,
and the bitrate aimed for,
influence the power consumed during transmission and reception; the
duration of transmission and reception (including potential reception)
influence the total energy consumption.</t>

<t>Based on the type of the energy source (e.g., battery or mains power)
and how often device needs to communicate, it may use different kinds
of strategies for power usage and network attachment.</t>

<t>The general strategies for power usage can be described as follows:</t>

<t><list style='hanging'>
  <t hangText='Always-on:'>
  This strategy is most applicable if there is no reason for extreme
measures for power saving.  The device can stay on in the usual manner
all the time.  It may be useful to employ power-friendly hardware or
limit the number of wireless transmissions, CPU speeds, and other
aspects for general power saving and cooling needs, but the device can
be connected to the network all the time.</t>
  <t hangText='Always-off:'>
  Under this strategy, the device sleeps such long periods at a time
that once it wakes up, it makes sense for it to not pretend that it
has been connected to the network during sleep: The device re-attaches
to the network as it is woken up.  The main optimization goal is to
minimize the effort during such re-attachment process and any
resulting application communications.</t>
  <t>If the device sleeps for long periods of time, and needs to
communicate infrequently, the relative increase in energy expenditure
during reattachment may be acceptable.</t>
  <t hangText='Low-power:'>
  This strategy is most applicable to devices that need to operate on
a very small amount of power, but still need to be able to communicate
on a relatively frequent basis. This implies that extremely low power
solutions needs to be used for the hardware, chosen link layer
mechanisms, and so on.  Typically, given the small amount of time
between transmissions, despite their sleep state these devices retain
some form of network attachment to the network.  Techniques used for
minimizing power usage for the network communications include
minimizing any work from re-establishing communications after waking
up, tuning the frequency of communications, and other parameters
appropriately.</t>
</list></t>

<t>In summary, we distinguish (<xref target="powclasstbl"/>):</t>

<texttable title="Strategies of Using Power for Communication" anchor="powclasstbl">
      <ttcol align='left'>Name</ttcol>
      <ttcol align='left'>Strategy</ttcol>
      <ttcol align='left'>Ability to communicate</ttcol>
      <c>S0</c>
      <c>Always-off</c>
      <c>Re-attach when required</c>
      <c>S1</c>
      <c>Low-power</c>
      <c>Appears connected, perhaps with high latency</c>
      <c>S2</c>
      <c>Always-on</c>
      <c>Always connected</c>
</texttable>

<t>Note that the discussion above is at the device level; similar
considerations can apply at the communications interface level.
This document does not define terminology for the latter.</t>

<t><vspace blankLines='999' /></t>

</section>
</section>
<section anchor="security-considerations" title="Security Considerations">

<t>This document introduces common terminology that does not raise any
new security issue.  Security considerations arising from the
constraints discussed in this document need to be discussed in the
context of specific protocols.  For instance, <xref target="I-D.ietf-core-coap"/> section 11.6,
“Constrained node considerations”, discusses implications of specific
constraints on the security mechanisms employed.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>This document has no actions for IANA.</t>

</section>
<section anchor="acknowledgements" title="Acknowledgements">

<t>Dominique Barthel and Peter van der Stok provided useful comments;
Charles Palmer provided a full editorial review.</t>

<t>Peter van der Stok insisted that we should have power terminology,
hence <xref target="power"/>.
The text for <xref target="poweruse"/> is mostly lifted from
<xref target="I-D.arkko-lwig-cellular"/> and has been adapted for this document.</t>

<!--  LocalWords:  interoperability microwatts microjoules bitrate
 -->
<!--  LocalWords:  IANA Acknowledgements
 -->

</section>


  </middle>

  <back>


    <references title='Informative References'>





<reference anchor='I-D.ietf-core-coap'>
<front>
<title>Constrained Application Protocol (CoAP)</title>

<author initials='Z' surname='Shelby' fullname='Zach Shelby'>
    <organization />
</author>

<author initials='K' surname='Hartke' fullname='Klaus Hartke'>
    <organization />
</author>

<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
    <organization />
</author>

<date month='June' day='28' year='2013' />

<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>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-core-coap-18' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-core-coap-18.txt' />
</reference>



<reference anchor='I-D.ietf-6lowpan-btle'>
<front>
<title>Transmission of IPv6 Packets over BLUETOOTH Low Energy</title>

<author initials='J' surname='Nieminen' fullname='Johanna Nieminen'>
    <organization />
</author>

<author initials='T' surname='Savolainen' fullname='Teemu Savolainen'>
    <organization />
</author>

<author initials='M' surname='Isomaki' fullname='Markus Isomaki'>
    <organization />
</author>

<author initials='B' surname='Patil' fullname='Basavaraj Patil'>
    <organization />
</author>

<author initials='Z' surname='Shelby' fullname='Zach Shelby'>
    <organization />
</author>

<author initials='C' surname='Gomez' fullname='Carles Gomez'>
    <organization />
</author>

<date month='February' day='12' year='2013' />

<abstract><t>BLUETOOTH Low Energy is a low power air interface technology defined by the BLUETOOTH Special Interest Group (BT-SIG).  The standard BLUETOOTH radio has been widely implemented and available in mobile phones, notebook computers, audio headsets and many other devices. The low power version of BLUETOOTH is a new specification that enables the use of this air interface with devices such as sensors, smart meters, appliances, etc.  The low power variant of BLUETOOTH is currently specified in the revision 4.0 of the BLUETOOTH specifications (BLUETOOTH 4.0).  This document describes how IPv6 is transported over BLUETOOTH Low Energy using 6LoWPAN techniques.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-6lowpan-btle-12' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-btle-12.txt' />
</reference>



<reference anchor='I-D.mariager-6lowpan-v6over-dect-ule'>
<front>
<title>Transmission of IPv6 Packets over DECT Ultra Low Energy</title>

<author initials='P' surname='Mariager' fullname='Peter Mariager'>
    <organization />
</author>

<author initials='J' surname='Petersen' fullname='Jens Petersen'>
    <organization />
</author>

<date month='May' day='2' year='2012' />

<abstract><t>DECT Ultra Low Energy is a low power air interface technology that is defined by the DECT Forum and specified by ETSI.  The DECT air interface technology has been used world-wide in communication devices for more than 15 years, primarily carrying voice for cordless telephony but has also been deployed for data centric services.  The DECT Ultra Low Energy is a recent addition to the DECT interface primarily intended for low-bandwidth, low-power applications such as sensor devices, smart meters, home automation etc.  As the DECT Ultra Low Energy interface inherits many of the capabilities from DECT, it benefits from long range, interference free operation, world wide reserved frequency band, low silicon prices and maturity.  There is an added value in the ability to communicate with IPv6 over DECT ULE.  This document describes how IPv6 is transported over DECT ULE using 6LoWPAN techniques.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-mariager-6lowpan-v6over-dect-ule-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-mariager-6lowpan-v6over-dect-ule-02.txt' />
</reference>



<reference anchor='I-D.brandt-6man-lowpanz'>
<front>
<title>Transmission of IPv6 packets over ITU-T G.9959 Networks</title>

<author initials='A' surname='Brandt' fullname='Anders Brandt'>
    <organization />
</author>

<author initials='J' surname='Buron' fullname='Jakob Buron'>
    <organization />
</author>

<date month='June' day='18' year='2013' />

<abstract><t>This document describes the frame format for transmission of IPv6 packets and a method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-brandt-6man-lowpanz-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-brandt-6man-lowpanz-02.txt' />
<format type='PDF'
        target='http://www.ietf.org/internet-drafts/draft-brandt-6man-lowpanz-02.pdf' />
</reference>


<reference anchor="fifty-billion" target="http://www.ericsson.com/res/docs/whitepapers/wp-50-billions.pdf">
  <front>
    <title>More Than 50 Billion Connected Devices</title>
    <author >
      <organization>Ericsson</organization>
    </author>
    <date year="2011" month="February"/>
  </front>
  <seriesInfo name="Ericsson White Paper" value="284 23-3149 Uen"/>
</reference>
<reference anchor="WEI" >
  <front>
    <title>6LoWPAN: the Wireless Embedded Internet</title>
    <author initials="Z." surname="Shelby" fullname="Zach Shelby">
      <organization></organization>
    </author>
    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
      <organization></organization>
    </author>
    <date year="2009"/>
  </front>
  <seriesInfo name="ISBN" value="9780470747995"/>
</reference>
<reference anchor="FALL" >
  <front>
    <title>A Delay-Tolerant Network Architecture for Challenged Internets</title>
    <author initials="K." surname="Fall" fullname="Kevin Fall">
      <organization></organization>
    </author>
    <date year="2003"/>
  </front>
  <seriesInfo name="SIGCOMM" value="2003"/>
</reference>
<reference anchor="ISQ-13" >
  <front>
    <title>International Standard -- Quantities and units -- Part 13: Information science and technology</title>
    <author >
      <organization>International Electrotechnical Commission</organization>
    </author>
    <date year="2008" month="March"/>
  </front>
  <seriesInfo name="IEC" value="80000-13"/>
</reference>




<reference anchor='RFC6606'>

<front>
<title>Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing</title>
<author initials='E.' surname='Kim' fullname='E. Kim'>
<organization /></author>
<author initials='D.' surname='Kaspar' fullname='D. Kaspar'>
<organization /></author>
<author initials='C.' surname='Gomez' fullname='C. Gomez'>
<organization /></author>
<author initials='C.' surname='Bormann' fullname='C. Bormann'>
<organization /></author>
<date year='2012' month='May' />
<abstract>
<t>IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) are formed by devices that are compatible with the IEEE 802.15.4 standard. However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format specification defines how mesh topologies could be obtained and maintained. Thus, it should be considered how 6LoWPAN formation and multi-hop routing could be supported.</t><t> This document provides the problem statement and design space for 6LoWPAN routing. It defines the routing requirements for 6LoWPANs, considering the low-power and other particular characteristics of the devices and links. The purpose of this document is not to recommend specific solutions but to provide general, layer-agnostic guidelines about the design of 6LoWPAN routing that can lead to further analysis and protocol design. This document is intended as input to groups working on routing protocols relevant to 6LoWPANs, such as the IETF ROLL WG. This document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract></front>

<seriesInfo name='RFC' value='6606' />
<format type='TXT' octets='75436' target='http://www.rfc-editor.org/rfc/rfc6606.txt' />
</reference>



<reference anchor='RFC0793'>

<front>
<title abbrev='Transmission Control Protocol'>Transmission Control Protocol</title>
<author initials='J.' surname='Postel' fullname='Jon Postel'>
<organization>University of Southern California (USC)/Information Sciences Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country></postal></address></author>
<date year='1981' day='1' month='September' /></front>

<seriesInfo name='STD' value='7' />
<seriesInfo name='RFC' value='793' />
<format type='TXT' octets='172710' target='http://www.rfc-editor.org/rfc/rfc793.txt' />
</reference>



<reference anchor='RFC4838'>

<front>
<title>Delay-Tolerant Networking Architecture</title>
<author initials='V.' surname='Cerf' fullname='V. Cerf'>
<organization /></author>
<author initials='S.' surname='Burleigh' fullname='S. Burleigh'>
<organization /></author>
<author initials='A.' surname='Hooke' fullname='A. Hooke'>
<organization /></author>
<author initials='L.' surname='Torgerson' fullname='L. Torgerson'>
<organization /></author>
<author initials='R.' surname='Durst' fullname='R. Durst'>
<organization /></author>
<author initials='K.' surname='Scott' fullname='K. Scott'>
<organization /></author>
<author initials='K.' surname='Fall' fullname='K. Fall'>
<organization /></author>
<author initials='H.' surname='Weiss' fullname='H. Weiss'>
<organization /></author>
<date year='2007' month='April' />
<abstract>
<t>This document describes an architecture for delay-tolerant and disruption-tolerant networks, and is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration.  This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical.  We define a message- oriented overlay that exists above the transport (or other) layers of the networks it interconnects.  The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues.  This document represents the consensus of the IRTF DTN research group and has been widely reviewed by that group.  This memo provides information for the Internet community.</t></abstract></front>

<seriesInfo name='RFC' value='4838' />
<format type='TXT' octets='89265' target='http://www.rfc-editor.org/rfc/rfc4838.txt' />
</reference>



<reference anchor='I-D.ietf-roll-terminology'>
<front>
<title>Terminology in Low power And Lossy Networks</title>

<author initials='J' surname='Vasseur' fullname='JP Vasseur'>
    <organization />
</author>

<date month='March' day='12' year='2013' />

<abstract><t>The documents defines a terminology for discussing routing requirements and solutions for networks referred to as Low power and Lossy Networks (LLN).  An LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links.  There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g.  Heating, Ventilating, Air Conditioning, lighting, access control, fire), connected home, healthcare, environmental monitoring, urban sensor networks, energy management, assets tracking, refrigeration.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-roll-terminology-12' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-roll-terminology-12.txt' />
</reference>



<reference anchor='RFC6551'>

<front>
<title>Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks</title>
<author initials='JP.' surname='Vasseur' fullname='JP. Vasseur'>
<organization /></author>
<author initials='M.' surname='Kim' fullname='M. Kim'>
<organization /></author>
<author initials='K.' surname='Pister' fullname='K. Pister'>
<organization /></author>
<author initials='N.' surname='Dejean' fullname='N. Dejean'>
<organization /></author>
<author initials='D.' surname='Barthel' fullname='D. Barthel'>
<organization /></author>
<date year='2012' month='March' />
<abstract>
<t>Low-Power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad hoc networks that require the specification of new routing metrics and constraints.  By contrast, with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing Protocol for Low-Power and Lossy Networks (RPL). [STANDARDS-TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='6551' />
<format type='TXT' octets='67707' target='http://www.rfc-editor.org/rfc/rfc6551.txt' />
</reference>



<reference anchor='I-D.hui-vasseur-roll-rpl-deployment'>
<front>
<title>RPL deployment experience in large scale networks</title>

<author initials='J' surname='Vasseur' fullname='JP Vasseur'>
    <organization />
</author>

<author initials='J' surname='Hui' fullname='Jonathan Hui'>
    <organization />
</author>

<author initials='S' surname='Dasgupta' fullname='Sukrit Dasgupta'>
    <organization />
</author>

<author initials='G' surname='Yoon' fullname='Giyoung Yoon'>
    <organization />
</author>

<date month='July' day='5' year='2012' />

<abstract><t>Low power and Lossy Networks (LLNs) exhibit characteristics unlike other more traditional IP links.  LLNs are a class of network in which both routers and their interconnect are resource constrained. LLN routers are typically resource constrained in processing power, memory, and energy (i.e. battery power).  LLN links are typically exhibit high loss rates, low data rates, are are strongly affected by environmental conditions that change over time.  LLNs may be composed of a few dozen to thousands of routers.  A new protocol called the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) has been specified for routing in LLNs supporting multipoint-to-point, point- to-multipoint traffic, and point-to-point traffic.  Since RPL's publication as an RFC, several large scale networks have been succesfully deployed.  The aim of this document is to provide deployment experience on real-life deployed RPL-based networks.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-hui-vasseur-roll-rpl-deployment-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-hui-vasseur-roll-rpl-deployment-01.txt' />
<format type='PDF'
        target='http://www.ietf.org/internet-drafts/draft-hui-vasseur-roll-rpl-deployment-01.pdf' />
</reference>



<reference anchor='I-D.clausen-lln-rpl-experiences'>
<front>
<title>Observations of RPL: IPv6 Routing Protocol for Low power and Lossy Networks</title>

<author initials='T' surname='Clausen' fullname='Thomas Clausen'>
    <organization />
</author>

<author initials='A' surname='Verdiere' fullname='Axel Verdiere'>
    <organization />
</author>

<author initials='J' surname='Yi' fullname='Jiazi Yi'>
    <organization />
</author>

<author initials='U' surname='Herberg' fullname='Ulrich Herberg'>
    <organization />
</author>

<author initials='Y' surname='Igarashi' fullname='Yuichi Igarashi'>
    <organization />
</author>

<date month='February' day='25' year='2013' />

<abstract><t>With RPL - the "IPv6 Routing Protocol for Low-power Lossy Networks" - having been published as a Proposed Standard after a ~2-year development cycle, this document presents an evaluation of the resulting protocol, of its applicability, and of its limits.  The documents presents a selection of observations of the protocol characteristics, exposes experiences acquired when producing various prototype implementations of RPL, and presents results obtained from testing this protocol - by way of network simulations, in network testbeds and in deployments.  The document aims at providing a better understanding of possible limits of RPL, notably the possible directions that further protocol developments should explore, in order to address these.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-clausen-lln-rpl-experiences-06' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-clausen-lln-rpl-experiences-06.txt' />
</reference>



<reference anchor='RFC4919'>

<front>
<title>IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals</title>
<author initials='N.' surname='Kushalnagar' fullname='N. Kushalnagar'>
<organization /></author>
<author initials='G.' surname='Montenegro' fullname='G. Montenegro'>
<organization /></author>
<author initials='C.' surname='Schumacher' fullname='C. Schumacher'>
<organization /></author>
<date year='2007' month='August' />
<abstract>
<t>This document describes the assumptions, problem statement, and goals for transmitting IP over IEEE 802.15.4 networks.  The set of goals enumerated in this document form an initial set only.  This memo provides information for the Internet community.</t></abstract></front>

<seriesInfo name='RFC' value='4919' />
<format type='TXT' octets='27650' target='http://www.rfc-editor.org/rfc/rfc4919.txt' />
</reference>



<reference anchor='I-D.arkko-lwig-cellular'>
<front>
<title>Building Power-Efficient CoAP Devices for Cellular Networks</title>

<author initials='J' surname='Arkko' fullname='Jari Arkko'>
    <organization />
</author>

<author initials='A' surname='Eriksson' fullname='Anders Eriksson'>
    <organization />
</author>

<author initials='A' surname='Keränen' fullname='Ari Keränen'>
    <organization />
</author>

<date month='February' day='18' year='2013' />

<abstract><t>This memo discusses the use of the Constrained Application Protocol (CoAP) protocol in building sensors and other devices that employ cellular networks as a communications medium.  Building communicating devices that employ these networks is obviously well known, but this memo focuses specifically on techniques necessary to minimize power consumption.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-arkko-lwig-cellular-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-arkko-lwig-cellular-00.txt' />
</reference>




    </references>



  </back>
</rfc>