A compression mechanism for the RPL option
Cisco Systems
Village d'Entreprises Green Side400, Avenue de RoumanilleBatiment T3Biot - Sophia Antipolis06410FRANCE+33 4 97 23 26 34pthubert@cisco.com
Internet
6lo
This document proposes a compression mechanism for the RPL option.
This operation saves up to 48 bits in each frame compared to RFC 6553.
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.
In particular, IEEE802.14.5 that is
chartered to specify PHY and MAC layers for radio Lowpower Lossy
Networks (LLNs), defined the
TimeSlotted Channel Hopping (TSCH) mode of operation as part of
the IEEE802.15.4e MAC specification in order to address Time Sensitive
applications.
The
6TiSCH architecture specifies the operation IPv6 over TSCH
wireless networks attached and synchronized by backbone routers.
With 6TiSCH, the route Computation may be achieved in a centralized
fashion by a Path Computation Element (PCE), in a distributed fashion
using the Routing Protocol for Low Power and
Lossy Networks (RPL), or in a mixed mode.
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.
ISA100.11a (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.
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 6LoWPAN
Header Compression work, which goes down to the individual bits
to save space in the frames for actual data, and allowed ISA100.11a to
adopt IPv6.
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.
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.
The Routing Protocol for Low Power and Lossy Networks (RPL)
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.
A classical RPL implementation will use the RPL
Option for Carrying RPL Information in Data-Plane Datagrams 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 , 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.
With , 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.
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 fragmentation,
which in turn cause even more energy spending and issues discussed in the
LLN Fragment Forwarding
and Recovery.
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.
For timing reasons, 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 .
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 .The Terminology used in this document is consistent with and
incorporates that described in `Terminology in Low power And Lossy
Networks'
and .
This specification proposes a new 6LoWPAN Next Header Compression (NHC)
for the RPL option , called RPL_NHC, to be placed in
an -compressed packet.
It updates 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.
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.
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.
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:
DAGRank(rank) = floor(rank/MinHopRankIncrease)
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 that uses a
MinHopRankIncrease of 256 by default.
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:
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:
The O, R, and F bits are defined in
section 11.2. 1-bit. The Next Header (NH) bit is defined in
section 4.2, and it is set to indicate that
the next header is encoded using LOWPAN_NHC 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
section 5.1. 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.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:
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:
In the following case, the RPLInstanceID is not the Global RPLInstanceID
0, and the MinHopRankIncrease is a multiple of 256:
In the following case, the RPLInstanceID is not the Global RPLInstanceID
0, and both octets of the SenderRank are significant:
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 .
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 .
This document updates IANA registry for the LOWPAN_NHC defined in
and assigns the previously unassigned:
10IOKRFN: RPL Information [this]
Capital letters in bit positions represent class-specific bit
assignments. IOKRF represents
variables specific to RPL Information compression defined in
.
N indicates whether or not additional LOWPAN_NHC
encodings follow, as defined in Section 4.2 of
.
The author wishes to thank Laurent Toutain and Carsten Bormann for suggesting
this work .IEEE std. 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area NetworksIEEE standard for Information TechnologyWireless Systems for Industrial Automation: Process Control and Related Applications - ISA100.11a-2011 - IEC 62734ISA/ANSI