<?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-thubert-6lo-rpl-nhc-02" category="std" updates="6282">

<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc compact="no"?>

  <front>
    <title>A compression mechanism for the RPL option</title>

    <author initials="P." surname="Thubert" fullname="Pascal Thubert" role="editor">
      <organization abbrev="Cisco">Cisco Systems</organization>
      <address>
        <postal>
          <street>Village d'Entreprises Green Side</street> <street>400, Avenue de Roumanille</street> <street>Batiment T3</street>
          <city>Biot - Sophia Antipolis</city>
          <code>06410</code>
          <country>FRANCE</country>
        </postal>
        <phone>+33 4 97 23 26 34</phone>
        <email>pthubert@cisco.com</email>
      </address>
    </author>
    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
      <organization abbrev="TZI">Universitaet Bremen TZI</organization>
      <address>
        <postal>
          <street>Postfach 330440</street>
          <city>Bremen</city>
          <code>D-28359</code>
          <country>Germany</country>
        </postal>
        <phone>+49-421-218-63921</phone>
        <email>cabo@tzi.org</email>
      </address>
    </author>

    <date year="2014" month="October" day="24"/>

    <area>Internet</area>
    <workgroup>6lo</workgroup>
    

    <abstract>


<t>This specification defines the RPL Packet Information (RPI) NHC compression,
a method to compress RPL Option (RFC6553) information within 6LoWPAN-style
(“6lo”) adaptation layers.
This extends 6LoWPAN Header Compression (RFC6282), saving up to 48 bits
in each frame compared to the uncompressed form in RFC 6553.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>The design of Low Power and Lossy Networks (LLNs) is generally
focused on saving
energy, which is the most constrained resource of all. The other
constraints, such as the memory capacity and the duty cycling of the LLN
devices, derive from that primary concern. Energy is typically available
from batteries that are expected to last for years, or scavenged from the
environment in very limited quantities. Any protocol that is intended for
use in LLNs must be designed with the primary concern of saving energy as
a strict requirement.</t>

<t>Controlling the amount of data transmission is one possible venue to save
energy. In a number of LLN standards, the frame size is limited to much
smaller values than the IPv6 maximum transmission unit (MTU) of 1280 bytes.
In particular, an LLN that relies on the classical Physical Layer (PHY)
of IEEE 802.14.5 <xref target="IEEE802154"/> is limited to 127 bytes
per frame. The need to compress IPv6 packets over IEEE 802.14.5 led to
the <xref target="RFC6282">6LoWPAN Header Compression</xref> work (6LoWPAN-HC).</t>

<t><xref target="RFC6550">The Routing Protocol for Low Power and Lossy Networks</xref> (RPL)
is
designed to optimize the routing operations in constrained LLNs.
As part of this optimization, RPL requires the addition of RPL Packet Information
(RPI) in every packet, as defined in Section 11.2 of <xref target="RFC6550"/>.</t>

<figure title="IP-in-IP Encapsulation within the LLN" anchor="encaps"><artwork><![CDATA[
           ------+---------                            ^
                 |          Internet                   |
                 |                                     | Native IPv6
              +-----+                                  |
              |     | Border Router (RPL Root)    ^    |    ^
              |     |                             |    |    |
              +-----+                             |    |    | IPv6 in
                 |                                |    |    | IPv6 + RPI
           o    o   o    o                        |    |    |
       o o   o  o   o  o  o o   o                 |    |    |
      o  o o  o o    o   o   o  o  o              |    |    |
      o   o    o  o     o  o    o  o  o           |    |    |
     o  o   o  o   o         o   o o              v    v    v
     o          o             o     o
                       LLN
]]></artwork></figure>

<t>The RPI is used to tag the packet with the RPL
Instance ID and other information that RPL requires for its operation
within the RPL domain. In particular, the SenderRank, which is the scalar
metric computed by an specialized Objective Function such as <xref target="RFC6552"/>, indicates the Rank of the sender and is modified
at each hop. The SenderRank allows to validate that the packet progresses
in the expected direction, either upwards or downwards, along the DODAG.</t>

<t>RPL defines the
<xref target="RFC6553">RPL Option for Carrying RPL Information in Data-Plane Datagrams</xref>
to transport the RPI, which is carried in an <xref target="RFC2460">IPv6 Hop-by-Hop Options Header</xref>,
typically consuming eight bytes per packet.</t>

<t><xref target="I-D.ietf-6tisch-architecture">6TiSCH</xref> specifies the
operation of IPv6 over the
<xref target="I-D.ietf-6tisch-tsch">TimeSlotted Channel Hopping</xref> (TSCH) mode of
operation of IEEE 802.14.5. The architecture requires the use of both 6LoWPAN HC and RPL
over IEEE 802.14.5. Because it inherits the constraints on the frame size
from the MAC layer, 6TiSCH cannot afford to spend 8 bytes per packet
on the RPI.
Hence the requirement for a 6LoWPAN header compression of the RPI.</t>

<t>This specification extends the 6lo adaptation layer framework
(<xref target="RFC4944"/>, <xref target="RFC6282"/>) to carry the same information in a 6LoWPAN RPL
Packet Information (RPI) NHC Next-header compression (NHC) header,
usually eliminating the Hop-by-Hop Options Header saving up to six bytes per packet.</t>

</section>
<section anchor="terminology" title="Terminology">

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”,
“SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”,
and “OPTIONAL” in this document are to be interpreted as
described in <xref target="RFC2119"/>.</t>

<t>The Terminology used in this document is consistent with and
incorporates that described in `Terminology in Low power And Lossy
Networks’ <xref target="RFC7102"/> and <xref target="RFC6550"/>.</t>

<t>The term “byte” is used in its now customary sense as a synonym for
“octet”.</t>

</section>
<section anchor="updating-rfc-6282" title="Updating RFC 6282">

<t>This specification proposes a new 6LoWPAN Next Header Compression (NHC)
for the RPL option <xref target="RFC6553"/>, called RPI_NHC, to be placed in
a packet that is compressed per <xref target="RFC6282"/>.</t>

<t>It updates <xref target="RFC6282"/> in that the “necessary property of
encoding headers using LOWPAN_NHC” becomes that “the immediately preceding
header must be encoded using either LOWPAN_IPHC, RPI_NHC or LOWPAN_NHC”.</t>

<t>Additionally, the necessary property of encoding headers using RPI_NHC is
that the immediately preceding header must be encoded using either
LOWPAN_IPHC or LOWPAN_NHC.</t>

<t>(Discuss: Is this really an update of RFC 6282 or a straightforward
addition to it?)</t>

</section>
<section anchor="rplnhcenc" title="The RPL Packet Information NHC">

<t><xref target="RFC6550"/>, Section 11.2, specifies the RPL Packet Information (RPI) as
a set of fields that are to be added to the IP packets for the purpose
of Instance Identification, as well as Loop Avoidance and Detection.</t>

<t><xref target="RFC6553"/> defines an encoding for the RPI as a
RPL option located in the IPv6 Hop-by-hop Option Header.
The present NHC compression mechanism compresses IPv6 Hop-by-hop
Headers that contain only that RPL option.</t>

<t>The fields in the RPI include an ‘O’, an ‘R’, and an ‘F’ bit, an 8-bit
RPLInstanceID (with some internal structure), and a 16-bit SenderRank.</t>

<t>This section defines the format of the RPL Packet Information NHC
(RPI_NHC) that is used to compress the RPI in 6LoWPAN networks.</t>

<section anchor="intsnhc" title="Compressing the RPLInstanceId">

<t>RPL Instances are discussed in <xref target="RFC6550"/>, Section 5.
A number of simple use cases will not require more than one instance, and in
such a case, the instance is expected to be the global Instance 0.
A global RPLInstanceID is encoded in a RPLInstanceID field as follows:</t>

<figure title="RPLInstanceID Field Format for Global Instances" anchor="rplgid"><artwork><![CDATA[
    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |0|     ID      |  Global RPLInstanceID in 0..127
   +-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t>For the particular case of the global Instance 0, the
RPLInstanceID field is all zeroes.
This specification allows to elide a RPLInstanceID field that is all
zeroes, and defines a ‘I’ flag that, when set, signals that the field is elided.</t>

</section>
<section anchor="ranknhc" title="Compressing the SenderRank">

<t>The SenderRank is the result of the DAGRank operation on the rank of the
sender; here the DAGRank operation is defined in <xref target="RFC6550"/>, Section 3.5.1, as:</t>

<t><list style='empty'>
  <t>DAGRank(rank) = floor(rank/MinHopRankIncrease)</t>
</list></t>

<t>If MinHopRankIncrease is set to a multiple of 256,
the least significant 8 bits of the SenderRank will be all zeroes; by
eliding those, the SenderRank can be compressed into a single byte.
This idea is used in <xref target="RFC6550"/> by defining
DEFAULT_MIN_HOP_RANK_INCREASE as 256 and in <xref target="RFC6552"/> that defaults
MinHopRankIncrease to DEFAULT_MIN_HOP_RANK_INCREASE.</t>

<t>This specification allows to encode the SenderRank as either one or
two bytes, and defines a ‘K’ flag that, when set, signals that a
single byte is used.</t>

</section>
<section anchor="the-rpinhc-encoding" title="The RPI_NHC encoding">

<t><xref target="RFC6553"/> defines an encoding for the RPL information as a RPL
Option located in an IPv6 Hop-by-Hop Option Header.  The RPI_NHC
provides a compressed form for that information and is constructed as
follows:</t>

<t>The RPI_NHC is immediately followed by the RPLInstanceID, unless that
is elided (I=1), and then the SenderRank, which is either compressed
into one byte (K=1) or fully inlined as the whole 2 bytes (K=0). Bits
in the RPI_NHC indicate whether the RPLInstanceID is elided and/or the
SenderRank is compressed:</t>

<t><list style="hanging" hangIndent="6">
  <t hangText='O, R, and F bits:'>
  The O, R, and F bits as defined in <xref target="RFC6550"/>, Section 11.2.</t>
  <t hangText='NH:'>
  1-bit flag. The Next Header (NH) bit is defined in <xref target="RFC6282"/>,
Section 4.2, and it is set to indicate that the next header is
encoded using LOWPAN_NHC</t>
  <t hangText='I:'>
  1-bit flag. If it is set, the Instance ID is elided and the
RPLInstanceID is the Global RPLInstanceID 0.  If it is not set, the
byte immediately following the RPI_NHC contains the RPLInstanceID as
specified in <xref target="RFC6550"/>, Section 5.1.</t>
  <t hangText='K:'>
  1-bit flag. If it is set, the SenderRank is compressed into one
byte, and the least significant byte is elided.  If it is not set,
the SenderRank is fully inlined as 2 bytes.</t>
</list></t>

<t>In <xref target="rplnhc1"/>, the RPLInstanceID is the Global RPLInstanceID 0,
and the MinHopRankIncrease is a multiple of 256 so the least significant
byte is all zeroes and can be elided:</t>

<figure title="The most compressed RPI_NHC" anchor="rplnhc1"><artwork><![CDATA[
    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | NHC: I=1, K=1 |  SenderRank   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t>In <xref target="rplnhc2"/>, the RPLInstanceID is the Global RPLInstanceID 0,
but both bytes of the SenderRank are significant so it can not be
compressed:</t>

<figure title="Eliding the RPLInstanceID" anchor="rplnhc2"><artwork><![CDATA[
    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | NHC: I=1, K=0 |      SenderRank               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t>In <xref target="rplnhc4"/>, the RPLInstanceID is not the Global RPLInstanceID
0, and the MinHopRankIncrease is a multiple of 256:</t>

<figure title="Compressing SenderRank" anchor="rplnhc4"><artwork><![CDATA[
    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | NHC: I=0, K=1 | RPLInstanceID |  SenderRank   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t>In <xref target="rplnhc3"/>, the RPLInstanceID is not the Global RPLInstanceID
0, and both bytes of the SenderRank are significant:</t>

<figure title="Least compressed form of RPI_NHC" anchor="rplnhc3"><artwork><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | NHC: I=0, K=0 | RPLInstanceID |      SenderRank               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t>The next sections provide alternatives for format of the RPI_NHC.</t>

<section anchor="the-greedy-approach" title="The Greedy Approach">

<t>The RPI_NHC is constructed as follows:</t>

<figure title="The RPI_NHC, Greedy Version" anchor="rplnhc"><artwork><![CDATA[
     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1 | 0 | I | K | O | R | F |NH |
   +---+---+---+---+---+---+---+---+
]]></artwork></figure>

<t>Depending on the RPLInstanceID and the MinHopRankIncrease, the proposed
format thus squeezes the RPL information into 16 to 32 bits, which compares to
64 bits when using a Hop-by-hop option with the RPL option as specified
in <xref target="RFC6553"/>.</t>

<t>(This is called the “greedy” approach as it consumes 1/4 of the NHC
space just for the RPI compression.)</t>

</section>
<section anchor="the-conservative-approach" title="The Conservative Approach">

<t>In this approach, the encoding of the RPL Packet Information takes
two bytes: one byte to indicate the NH type, and then one byte to signal
the compressed information.</t>

<t>The NH type is indicated in an extension to existing LOWPAN_NHC encodings.
Section 4.2 of <xref target="RFC6553"/> defines LOWPAN_NHC encodings for
IPv6 Extension Headers as in <xref target="sixnh"/>:</t>

<figure title="IPv6 Extension Header Encoding" anchor="sixnh"><artwork><![CDATA[
     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1 | 1 | 1 | 0 |    EID    |NH |
   +---+---+---+---+---+---+---+---+
]]></artwork></figure>

<t>Values 5 and 6 of the IPv6 Extension Header ID (EID) are still reserved.
This specification uses EID of 5 to indicate that the next byte is a
RPI_NHC. The RPI_NHC is constructed as shown in <xref target="rpinhc"/>:</t>

<figure title="The RPI_NHC, Conservative Version" anchor="rpinhc"><artwork><![CDATA[
     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | I | K | O | R | F | reserved  |
   +---+---+---+---+---+---+---+---+
]]></artwork></figure>

<t>The bits 5 to 7 of the RPI_NHC are reserved for future use and MUST be
sent as zero.</t>

<t>(This is called the “conservative” approach as it consumes only 1/256
of the NHC space.)</t>

</section>
<section anchor="the-efficient-approach" title="The Efficient Approach">

<section anchor="the-nhc-escape-mechanism" title="The NHC escape mechanism">

<t>The NHC space of <xref target="RFC6282"/> is limited to 256 code points.
For the case some infrequent bit combinations do not fit into the 256
code points, this specification assigns four code points:</t>

<figure title="NHC Escape Codes" anchor="esccode"><artwork><![CDATA[
        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      | 0 | 1 | 0 | 0 | 0 | 1 | X | Y |
      +---+---+---+---+---+---+---+---+
]]></artwork></figure>

<t>Each NHC escape code is followed by a further NHC code point.
The latter MUST be a code point for which special semantics for a
preceding escape code are defined, i.e., an escape code MUST NOT be
used in front of an NHC code point that does not define special
semantics for this escape code.</t>

<t>An escape code followed by another escape code supplies additional
semantics; again, a sequence of such escape codes MUST NOT be used
unless the final NHC code following this sequence defines the
semantics for the specific sequence.</t>

</section>
<section anchor="encoding" title="RPI_NHC Encoding">

<t>The RPI_NHC provides a
compressed form for the RPI and is constructed as follows:</t>

<figure title="RPI NHC, efficient version" anchor="rpinhce"><artwork><![CDATA[
        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      | 1 | 0 | 0 | 0 | O | I | K |NH |
      +---+---+---+---+---+---+---+---+
]]></artwork></figure>

<t>The R and F bits, as defined in <xref target="RFC6550"/>, Section 11.2, are
represented as follows:</t>

<t>If R=0 and F=0, the NHC code is used as defined above.
  If either is non-zero, a single escape code with X=R and Y=F is prepended
  in front of the NHC code.  (An escape code with X=0 and Y=0 MUST NOT
  be used with RPI_NHC.  A sequence of two or more escape codes MUST
  NOT be used with RPI_NHC.)</t>

<t>Depending on the RPLInstanceID and the MinHopRankIncrease, the
proposed format thus squeezes the RPI into 16 to 40 bits,
which compares to 64 bits when using a Hop-by-hop option with the RPL
option as specified in <xref target="RFC6553"/>.</t>

<t>(This is called the “efficient” approach as it consumes only 1/16 of
the NHC space, but, depending on the frequency of set R or set F
flags, is almost as efficient as the greedy approach.)</t>

</section>
<section anchor="operation" title="Operation">

<t>A 6lo compressor that is about to create either an RFC 6282 IPHC
header <xref target="RFC6282"/> or a Frag1 header <xref target="RFC4944"/> and finds a
Hop-by-Hop Options header <xref target="RFC2460"/> with an RPL Option
<xref target="RFC6553"/> in it, performs the following checks:</t>

<t><list style="numbers">
  <t>Does the compression scheme apply?  I.e.:
  <list style="letters">
      <t>is no sub-tlv present in the RPL Option?</t>
      <t>is the RPL Option the only option in the Hop-by-Hop Options header?</t>
    </list></t>
  <t>Does the additional compression for I=1 apply?  I.e.:
is RPLInstanceID == 0?</t>
  <t>Does the additional compression for K=1 apply?  I.e.:
is SenderRank &lt; 256?</t>
  <t>Is both R=0 and F=0, or do we need an escape code?</t>
</list></t>

<t>If check 1 succeeds, the compressor removes the Hop-by-Hop Options
header (replacing the zero-valued next header field in the IPv6 header
with the value of the next header field of the Hop-by-Hop Options
header), and, depending on the outcome of check 2 and 3, generates an
RPI_NHC Header with I and K set from the payload information in the
RPL Option.  If one or both of R and F are non-zero (check 4), it
precedes the first byte in the RPI_NHC header with an escape code
with X=R and Y=F.
It then continues generating the RFC 6282 IPHC or RFC
4944 Frag1 header, filling in the continuation of the RPL Information
header as defined in <xref target="encoding"/>.</t>

<t>A 6lo decompressor that encounters a RPL Information header reverses
this process, creating a Hop-by-Hop Options header with a single RPL
Option carrying the information in the RPL Information header.</t>

</section>
</section>
</section>
</section>
<section anchor="security-considerations" title="Security Considerations">

<t>The security considerations of <xref target="RFC4944"/>, <xref target="RFC6282"/>, and
<xref target="RFC6553"/> apply.</t>

<t>Using a compressed format as opposed to the full inline RPL option is
logically equivalent and does not create an opening for a new threat when
compared to <xref target="RFC6553"/>.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>(greedy variant:)</t>

<t>This document updates IANA registry for the LOWPAN_NHC defined in <xref target="RFC6282"/> and assigns the previously unassigned:</t>

<t><list style='empty'>
  <t>10IKORFN: RPL Information                          [RFCthis]</t>
</list></t>

<t>Capital letters in bit positions represent class-specific bit
assignments.  IKORF represents
variables specific to RPL Information compression defined in <xref target="rplnhcenc"/>.
N indicates whether or not additional LOWPAN_NHC
encodings follow, as defined in Section 4.2 of <xref target="RFC6553"/>.</t>

<t>(efficient variant:)</t>

<t>This draft requests IANA to assign the following LOWPAN_NHC types in
the “IPv6 Low Power Personal Area Network Parameters” registry:</t>

<t><list style='empty'>
  <t>010001XY: Escape X=0/Y=0 to X=1/Y=1   [RFCthis]</t>
</list></t>

<t><list style='empty'>
  <t>1000IOKN: RPL Information             [RFCthis]</t>
</list></t>

</section>
<section anchor="acknowledgements" title="Acknowledgements">

<t>The author wishes to thank Laurent Toutain for suggesting
this work and and Martin Turon for his constructive contributions.
Ralph Droms supplied a number of helpful comments on the -00 draft of
<xref target="I-D.bormann-6lo-rpl-mesh"/>, which was superseded by the present
document, turning into the “efficient approach”.
The discussion in the 6man and roll working groups also was helpful.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference anchor='RFC2119'>

<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  This document defines these words as they should be
   interpreted in IETF documents.  Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:

<list>
<t>
      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119.
</t></list></t>
<t>
   Note that the force of these words is modified by the requirement
   level of the document in which they are used.
</t></abstract></front>

<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17970' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>



<reference anchor='RFC2460'>

<front>
<title abbrev='IPv6 Specification'>Internet Protocol, Version 6 (IPv6) Specification</title>
<author initials='S.E.' surname='Deering' fullname='Stephen E. Deering'>
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<street>San Jose</street>
<region>CA</region>
<code>95134-1706</code>
<country>USA</country></postal>
<phone>+1 408 527 8213</phone>
<facsimile>+1 408 527 8254</facsimile>
<email>deering@cisco.com</email></address></author>
<author initials='R.M.' surname='Hinden' fullname='Robert M. Hinden'>
<organization>Nokia</organization>
<address>
<postal>
<street>232 Java Drive</street>
<street>Sunnyvale</street>
<region>CA</region>
<code>94089</code>
<country>USA</country></postal>
<phone>+1 408 990 2004</phone>
<facsimile>+1 408 743 5677</facsimile>
<email>hinden@iprg.nokia.com</email></address></author>
<date year='1998' month='December' />
<area>Internet</area>
<keyword>internet protocol version 6</keyword>
<keyword>IPv6</keyword>
<abstract>
<t>
   This document specifies version 6 of the Internet Protocol (IPv6),
   also sometimes referred to as IP Next Generation or IPng.
</t></abstract></front>

<seriesInfo name='RFC' value='2460' />
<format type='TXT' octets='85490' target='http://www.rfc-editor.org/rfc/rfc2460.txt' />
<format type='HTML' octets='107357' target='http://xml.resource.org/public/rfc/html/rfc2460.html' />
<format type='XML' octets='94163' target='http://xml.resource.org/public/rfc/xml/rfc2460.xml' />
</reference>



<reference anchor='RFC6282'>

<front>
<title>Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks</title>
<author initials='J.' surname='Hui' fullname='J. Hui'>
<organization /></author>
<author initials='P.' surname='Thubert' fullname='P. Thubert'>
<organization /></author>
<date year='2011' month='September' />
<abstract>
<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>

<seriesInfo name='RFC' value='6282' />
<format type='TXT' octets='52588' target='http://www.rfc-editor.org/rfc/rfc6282.txt' />
</reference>



<reference anchor='RFC6550'>

<front>
<title>RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks</title>
<author initials='T.' surname='Winter' fullname='T. Winter'>
<organization /></author>
<author initials='P.' surname='Thubert' fullname='P. Thubert'>
<organization /></author>
<author initials='A.' surname='Brandt' fullname='A. Brandt'>
<organization /></author>
<author initials='J.' surname='Hui' fullname='J. Hui'>
<organization /></author>
<author initials='R.' surname='Kelsey' fullname='R. Kelsey'>
<organization /></author>
<author initials='P.' surname='Levis' fullname='P. Levis'>
<organization /></author>
<author initials='K.' surname='Pister' fullname='K. Pister'>
<organization /></author>
<author initials='R.' surname='Struik' fullname='R. Struik'>
<organization /></author>
<author initials='JP.' surname='Vasseur' fullname='JP. Vasseur'>
<organization /></author>
<author initials='R.' surname='Alexander' fullname='R. Alexander'>
<organization /></author>
<date year='2012' month='March' />
<abstract>
<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>

<seriesInfo name='RFC' value='6550' />
<format type='TXT' octets='360651' target='http://www.rfc-editor.org/rfc/rfc6550.txt' />
</reference>



<reference anchor='RFC6552'>

<front>
<title>Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)</title>
<author initials='P.' surname='Thubert' fullname='P. Thubert'>
<organization /></author>
<date year='2012' month='March' />
<abstract>
<t>The Routing Protocol for Low-Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of network types by the application of specific Objective Functions (OFs). An OF states the outcome of the process used by a RPL node to select and optimize routes within a RPL Instance based on the Information Objects available; an OF is not an algorithm.&lt;/t>&lt;t> This document specifies a basic Objective Function that relies only on the objects that are defined in the RPL and does not use any protocol extensions. [STANDARDS-TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='6552' />
<format type='TXT' octets='30419' target='http://www.rfc-editor.org/rfc/rfc6552.txt' />
</reference>



<reference anchor='RFC6553'>

<front>
<title>The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams</title>
<author initials='J.' surname='Hui' fullname='J. Hui'>
<organization /></author>
<author initials='JP.' surname='Vasseur' fullname='JP. Vasseur'>
<organization /></author>
<date year='2012' month='March' />
<abstract>
<t>The Routing Protocol for Low-Power and Lossy Networks (RPL) includes routing information in data-plane datagrams to quickly identify inconsistencies in the routing topology.  This document describes the RPL Option for use among RPL routers to include such routing information. [STANDARDS-TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='6553' />
<format type='TXT' octets='19093' target='http://www.rfc-editor.org/rfc/rfc6553.txt' />
</reference>


<reference anchor="IEEE802154" >
  <front>
    <title>IEEE std. 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks</title>
    <author >
      <organization>IEEE standard for Information Technology</organization>
    </author>
    <date year="2011" month="June"/>
  </front>
</reference>


    </references>

    <references title='Informative References'>





<reference anchor='RFC4944'>

<front>
<title>Transmission of IPv6 Packets over IEEE 802.15.4 Networks</title>
<author initials='G.' surname='Montenegro' fullname='G. Montenegro'>
<organization /></author>
<author initials='N.' surname='Kushalnagar' fullname='N. Kushalnagar'>
<organization /></author>
<author initials='J.' surname='Hui' fullname='J. Hui'>
<organization /></author>
<author initials='D.' surname='Culler' fullname='D. Culler'>
<organization /></author>
<date year='2007' month='September' />
<abstract>
<t>This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks.  Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='4944' />
<format type='TXT' octets='67232' target='http://www.rfc-editor.org/rfc/rfc4944.txt' />
</reference>



<reference anchor='RFC7102'>

<front>
<title>Terms Used in Routing for Low-Power and Lossy Networks</title>
<author initials='JP.' surname='Vasseur' fullname='JP. Vasseur'>
<organization /></author>
<date year='2014' month='January' />
<abstract>
<t>This document provides a glossary of terminology used in routing requirements and solutions for networks referred to as Low-Power and Lossy Networks (LLNs).  An LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links.  There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g., heating, ventilation, air conditioning, lighting, access control, fire), connected home, health care, environmental monitoring, urban sensor networks, energy management, assets tracking, and refrigeration.</t></abstract></front>

<seriesInfo name='RFC' value='7102' />
<format type='TXT' octets='16444' target='http://www.rfc-editor.org/rfc/rfc7102.txt' />
</reference>



<reference anchor='I-D.ietf-6tisch-tsch'>
<front>
<title>Using IEEE802.15.4e TSCH in an IoT context: Overview, Problem Statement and Goals</title>

<author initials='T' surname='Watteyne' fullname='Thomas Watteyne'>
    <organization />
</author>

<author initials='M' surname='Palattella' fullname='Maria Palattella'>
    <organization />
</author>

<author initials='L' surname='Grieco' fullname='Luigi Grieco'>
    <organization />
</author>

<date month='October' day='17' year='2014' />

<abstract><t>This document describes the environment, problem statement, and goals for using the IEEE802.15.4e TSCH MAC protocol in the context of LLNs. The set of goals enumerated in this document form an initial set only.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-6tisch-tsch-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-6tisch-tsch-02.txt' />
</reference>



<reference anchor='I-D.ietf-6tisch-architecture'>
<front>
<title>An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4e</title>

<author initials='P' surname='Thubert' fullname='Pascal Thubert'>
    <organization />
</author>

<author initials='T' surname='Watteyne' fullname='Thomas Watteyne'>
    <organization />
</author>

<author initials='R' surname='Assimiti' fullname='Robert Assimiti'>
    <organization />
</author>

<date month='July' day='4' year='2014' />

<abstract><t>This document presents an architecture for an IPv6 Multi-Link subnet that is composed of a high speed powered backbone and a number of IEEE802.15.4e TSCH wireless networks attached and synchronized by Backbone Routers.  The TSCH schedule can be static or dynamic. 6TiSCH defines mechanisms to establish and maintain the routing and scheduling operations in a centralized, distributed, or mixed fashion.  Backbone Routers perform proxy Neighbor Discovery operations over the backbone on behalf of the wireless devices, so they can share a same subnet and appear to be connected to the same backbone as classical devices</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-6tisch-architecture-03' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-6tisch-architecture-03.txt' />
</reference>



<reference anchor='I-D.bormann-6lo-rpl-mesh'>
<front>
<title>NHC compression for RPL Packet Information</title>

<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
    <organization />
</author>

<date month='October' day='12' year='2014' />

<abstract><t>This short draft provides a straw man for the RPL Packet Information (RPI) NHC compression, a method to compress RPL Option [RFC6553] information within 6lowpan-style ("6lo") adaptation layers.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-bormann-6lo-rpl-mesh-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-bormann-6lo-rpl-mesh-02.txt' />
</reference>




    </references>


<!--  LocalWords:  IANA LOWPAN NHC RPL RPI LoWPAN SenderRank
 -->



  </back>
</rfc>

