One document matched: draft-thubert-6lo-rpl-nhc-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<rfc category="std" ipr="trust200902" updates="6282" docName="draft-thubert-6lo-rpl-nhc-01">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?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 fullname="Michael Richardson" initials="M.C." surname="Richardson">
<organization abbrev="Sandelman">
Sandelman Software Works
</organization>
<address>
<postal>
<street> </street>
<city>Ottawa</city>
<region>Ontario</region>
<code> </code>
<country>Canada</country>
</postal>
<email>mcr+ietf@sandelman.ca</email>
</address>
</author-->
<date/>
<area>Internet</area>
<workgroup>6lo</workgroup>
<abstract>
<t>
This document proposes a compression mechanism for the RPL option.
This operation saves up to 48 bits in each frame compared to RFC 6553.
</t>
</abstract>
</front>
<middle>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='introduction' title="Introduction">
<t>
The emergence of radio technology enabled a large variety of new types of devices
to be interconnected, at a very low marginal cost compared to wire, at any range from
Near Field to interplanetary distances, and in circumstances where wiring would be less
than practical, for instance rotating devices.
</t>
<t>
In particular, IEEE802.14.5 <xref target="IEEE802154"/> that is
chartered to specify PHY and MAC layers for radio Lowpower Lossy
Networks (LLNs), defined the <xref target="I-D.ietf-6tisch-tsch">
TimeSlotted Channel Hopping</xref> (TSCH) mode of operation as part of
the IEEE802.15.4e MAC specification in order to address Time Sensitive
applications.
</t>
<t>
The <xref target="I-D.ietf-6tisch-architecture">
6TiSCH architecture </xref> specifies the operation IPv6 over TSCH
wireless networks attached and synchronized by backbone routers.
</t>
<t>
With 6TiSCH, the route Computation may be achieved in a centralized
fashion by a Path Computation Element (PCE), in a distributed fashion
using the <xref target="RFC6550"> Routing Protocol for Low Power and
Lossy Networks </xref> (RPL), or in a mixed mode.
</t>
<t>
6TiSCH was created to simplify the adoption of IETF technology by other
Standard Defining Organizations (SDOs), in particular in the Industrial
Automation space, which already relies on variations of IEEE802.15.4e
TSCH for Wireless Sensor Networking.
</t>
<t>
<xref target="ISA100.11a">
ISA100.11a </xref> (now IEC62734) is an example of such industrial WSN
standard, using
IEEE802.15.4e over the classical IEEE802.14.5 PHY. In that case, after
security is applied, roughly 80 octets are available per frame for
IP and Payload. In order to 1) avoid fragmentation and 2) conserve
energy, the SDO will scrutinize any bit in the frame and reject any
waste.
</t>
<t>
The challenge to obtain the adoption of IPv6 in the original standard
was really to save any possible bit in the frames, including the UDP
checksum which was an interesting discussion on its own. This work was
actually one of the roots for the <xref target="RFC6282"> 6LoWPAN
Header Compression </xref> work, which goes down to the individual bits
to save space in the frames for actual data, and allowed ISA100.11a to
adopt IPv6.
</t>
<t> In order to get an SDO such as ISA100 to adopt RPL and 6TiSCH, it is
mandatory to maintain the same degree to requirement and maximize the
compression of all possible protocol information, and in particular the
overhead that RPL imposes on all packets.
</t>
</section>
<section anchor='waste' title="On Wasted Resources">
<t> The design of Lowpower Lossy Networks is generally focussed 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> <xref target="RFC6550">
The Routing Protocol for Low Power and Lossy Networks (RPL) </xref>
specification defines a generic Distance Vector protocol that is indeed
designed for very low energy consumption and adapted to a variety of LLNs.
RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) which root
often acts as the Border Router to connect the RPL domain to the Internet.
The root is responsible to select the RPL Instance that is used to forward
a packet coming from the Internet into the RPL domain and set the related
RPL information in the packets.
</t>
<t>A classical RPL implementation will use the <xref target="RFC6553"> RPL
Option for Carrying RPL Information in Data-Plane Datagrams </xref> to tag
a packet with the Instance ID and other information that RPL requires for
its operation within the RPL domain.
In particular, the Rank, which is the scalar metric computed by an specialized Objective Function
such as <xref target="RFC6552"/>, is modified at each hop and allows to validate that the packet
progresses in the expected direction each upwards or downwards in along the DODAG.
</t>
<figure title="Figure 1: IP-in-IP Encapsulation within the LLN ">
<artwork>
------+--------- ^
| Internet |
| | Native IPv6
+-----+ |
| | Border Router (RPL Root) ^ | ^
| | | | |
+-----+ | | | IPv6 +
| | | | HbH
o o o o | | | headers
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>With <xref target="RFC6553"/>, the RPL option is encoded as 6 Octets;
it must be placed in a Hop-by-Hop header that represents 2 additional
octets for a total of 8. In order to limit its range to the inside the RPL domain,
the Hop-by-Hop header must be added to (or removed from) packets
that cross the border of the RPL domain. For reasons such as the capability
to send ICMP errors back to the source, this operation involves an extra
IP-in-IP encapsulation inside the RPL domain for all the packets which path is
not contained within the RPL domain.
</t>
<t>
The 8-octets overhead is detrimental to the LLN operation, in particular
with regards to bandwidth and battery constraints. These octets may cause
a containing frame to grow above maximum frame size, leading to
Layer 2 or 6LoWPAN <xref target="RFC4944"/> fragmentation,
which in turn cause even more energy spending and issues discussed in the
<xref target="I-D.thubert-6lo-forwarding-fragments">LLN Fragment Forwarding
and Recovery</xref>.
</t>
<t> Considering that, in the classical IEEE802.14.5 PHY that is used
by 6TiSCH, roughly 80 octets are available per frame after security is
applied, and any additional transmitted bit weights in the energy
consumption and drains the batteries.
</t>
<t>
For timing reasons, <xref target="RFC6282"/> failed to provide an adapted
compression for the RPL option so the cost in current implementations can
not be alleviated in any fashion. This document provides thus the
much-needed efficient compression of the RPL option as a logical extension
to <xref target="RFC6282"/>.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section 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"></xref>
and <xref target="RFC6550"/>.</t>
</section>
<section title="Updating RFC 6282">
<t>
This specification proposes a new 6LoWPAN Next Header Compression (NHC)
for the RPL option <xref target="RFC6553"/>, called RPL_NHC, to be placed in
an <xref target="RFC6282"/>-compressed packet.
</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, RPL_NHC or LOWPAN_NHC.
</t><t>
Additionally, the necessary property of encoding headers using RPL_NHC is
that the immediately preceding header must be encoded using either
LOWPAN_IPHC or LOWPAN_NHC.
</t>
</section>
<section anchor="rplnhcenc" title="New RPL Next Header Compression">
<t>
<xref target="RFC6550"/> section 11.2 specifies the RPL information as a set
of fields that are to be placed into the packets for the purpose of Instance
Identification, as well as Loop Avoidance and Detection.
Those fields include an 'O', an 'R' and an 'F' bits, a 8-bit RPLInstanceID,
which is in fact an encoded structure, and a 16-bit SenderRank.
</t><t>
The SenderRank is the result of the DAGRank operation on the rank of the
sender, here the DAGRank operation is defined in section 3.5.1 as:
<list><t>DAGRank(rank) = floor(rank/MinHopRankIncrease)</t></list>
</t><t>
If MinHopRankIncrease is set to a multiple of 256, it appears that
the least significant 8 bits of the SenderRank will be all zeroes and
can be elided, in which case the SenderRank can be compressed into one octet.
This idea is leveraged in <xref target="RFC6552"/> that uses a
MinHopRankIncrease of 256 by default.
</t>
<t><xref target="RFC6553"/> defines an encoding for the RPL information
as a RPL option located in a Hop-by-hop header. The RPL_NHC provides a
compressed form for that the RPL information and is constructed as follows:
</t>
<figure anchor="rplnhc" title="The RPL_NHC">
<artwork>
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 0 | I | K | O | R | F |NH |
+---+---+---+---+---+---+---+---+
</artwork>
</figure>
<t> The RPL_NHC is immediately followed by the RPLInstanceID, unless it is
elided, and then the SenderRank, which is either compressed into one octet
or fully inlined as the whole 2 octets. Bits in the RPL_NHC indicate
whether the RPLInstanceID is elided and/or the SenderRank is compressed:
<list hangIndent="6" style="hanging">
<t hangText="O, R, and F bits">
The O, R, and F bits are defined in <xref target="RFC6550"/>
section 11.2. </t>
<t hangText="NH:"> 1-bit. 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. If it is set, the Instance ID is elided
and the RPLInstanceID is the Global RPLInstanceID 0.
If it is not set, the octet immediately following the RPL_NHC
contains the RPLInstanceID as specified in <xref target="RFC6550"/>
section 5.1. </t>
<t hangText="K:"> 1-bit. If it is set, the SenderRank is be
compressed into one octet, and the lowest significant octet is
elided.
If it is not set, the SenderRank, is fully inlined as 2 octets.</t>
</list>
</t>
<t>In the following case, the RPLInstanceID is the Global RPLInstanceID 0,
and the MinHopRankIncrease is a multiple of 256 so the least significant
octet is all zeroes and can be elided:
</t>
<figure anchor="rplnhc1" title="The most compressed RPL_NHC">
<artwork>
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|1|1|O|R|F|N| SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>In the following case, the RPLInstanceID is the Global RPLInstanceID 0,
but both octets of the SenderRank are significant so it can not be
compressed:
</t>
<figure anchor="rplnhc2" title="Eliding the RPLInstanceID">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|1|0|O|R|F|N| SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>In the following case, the RPLInstanceID is not the Global RPLInstanceID
0, and the MinHopRankIncrease is a multiple of 256:
</t>
<figure anchor="rplnhc4" title="Compressing SenderRank">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|1|O|R|F|N| RPLInstanceID | SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>In the following case, the RPLInstanceID is not the Global RPLInstanceID
0, and both octets of the SenderRank are significant:
</t>
<figure anchor="rplnhc3" title="Least compressed form of RPL_NHC">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|0|O|R|F|N| RPLInstanceID | SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>Depending on the RPLInstanceID and the MinHopRankIncrease, the proposed
format thus squeezes the RPL information in 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>
</section>
<section title="Security Considerations">
<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 title="IANA Considerations">
<t>This document updates IANA registry for the LOWPAN_NHC defined in
<xref target="RFC6282"/> and assigns the previously unassigned:
<list><t>
10IOKRFN: RPL Information [this]
</t></list>
Capital letters in bit positions represent class-specific bit
assignments. IOKRF 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>
</section>
<section title="Acknowledgements">
<t>The author wishes to thank Laurent Toutain and Carsten Bormann for suggesting
this work .</t>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2460"?>
<?rfc include="reference.RFC.6282"?>
<?rfc include="reference.RFC.6550"?>
<?rfc include="reference.RFC.6552"?>
<?rfc include="reference.RFC.6553"?>
<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 month="June" year="2011"/>
</front>
</reference>
<reference anchor="ISA100.11a" target="http://www.isa.org/Community/SP100WirelessSystemsforAutomation">
<front>
<title>Wireless Systems for Industrial Automation: Process Control and Related Applications - ISA100.11a-2011 - IEC 62734</title>
<author>
<organization>ISA/ANSI</organization>
</author>
<date year="2011" />
</front>
</reference>
</references>
<references title='Informative References'>
<?rfc include="reference.RFC.4944"?>
<?rfc include="reference.RFC.7102"?>
<?rfc include='reference.I-D.ietf-6tisch-tsch'?>
<?rfc include='reference.I-D.thubert-6lo-forwarding-fragments'?>
<?rfc include='reference.I-D.ietf-6tisch-architecture'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 05:18:11 |