Internet DRAFT - draft-thubert-6lo-rpl-nhc
draft-thubert-6lo-rpl-nhc
6lo P. Thubert, Ed.
Internet-Draft Cisco
Updates: 6282 (if approved) C. Bormann
Intended status: Standards Track TZI
Expires: April 27, 2015 October 24, 2014
A compression mechanism for the RPL option
draft-thubert-6lo-rpl-nhc-02
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 27, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Thubert & Bormann Expires April 27, 2015 [Page 1]
Internet-Draft A compression mechanism for the RPL option October 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Updating RFC 6282 . . . . . . . . . . . . . . . . . . . . . . 4
4. The RPL Packet Information NHC . . . . . . . . . . . . . . . 4
4.1. Compressing the RPLInstanceId . . . . . . . . . . . . . . 5
4.2. Compressing the SenderRank . . . . . . . . . . . . . . . 5
4.3. The RPI_NHC encoding . . . . . . . . . . . . . . . . . . 5
4.3.1. The Greedy Approach . . . . . . . . . . . . . . . . . 7
4.3.2. The Conservative Approach . . . . . . . . . . . . . . 7
4.3.3. The Efficient Approach . . . . . . . . . . . . . . . 8
4.3.3.1. The NHC escape mechanism . . . . . . . . . . . . 8
4.3.3.2. RPI_NHC Encoding . . . . . . . . . . . . . . . . 9
4.3.3.3. Operation . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
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.
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 [IEEE802154] is limited to 127
bytes per frame. The need to compress IPv6 packets over IEEE
802.14.5 led to the 6LoWPAN Header Compression [RFC6282] work
(6LoWPAN-HC).
The Routing Protocol for Low Power and Lossy Networks [RFC6550] (RPL)
is designed to optimize the routing operations in constrained LLNs.
Thubert & Bormann Expires April 27, 2015 [Page 2]
Internet-Draft A compression mechanism for the RPL option October 2014
As part of this optimization, RPL requires the addition of RPL Packet
Information (RPI) in every packet, as defined in Section 11.2 of
[RFC6550].
------+--------- ^
| 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
Figure 1: IP-in-IP Encapsulation within the LLN
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 [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.
RPL defines the RPL Option for Carrying RPL Information in Data-Plane
Datagrams [RFC6553] to transport the RPI, which is carried in an IPv6
Hop-by-Hop Options Header [RFC2460], typically consuming eight bytes
per packet.
6TiSCH [I-D.ietf-6tisch-architecture] specifies the operation of IPv6
over the TimeSlotted Channel Hopping [I-D.ietf-6tisch-tsch] (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.
This specification extends the 6lo adaptation layer framework
([RFC4944], [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.
Thubert & Bormann Expires April 27, 2015 [Page 3]
Internet-Draft A compression mechanism for the RPL option October 2014
2. Terminology
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 [RFC2119].
The Terminology used in this document is consistent with and
incorporates that described in `Terminology in Low power And Lossy
Networks' [RFC7102] and [RFC6550].
The term "byte" is used in its now customary sense as a synonym for
"octet".
3. Updating RFC 6282
This specification proposes a new 6LoWPAN Next Header Compression
(NHC) for the RPL option [RFC6553], called RPI_NHC, to be placed in a
packet that is compressed per [RFC6282].
It updates [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".
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.
(Discuss: Is this really an update of RFC 6282 or a straightforward
addition to it?)
4. The RPL Packet Information NHC
[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.
[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.
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.
Thubert & Bormann Expires April 27, 2015 [Page 4]
Internet-Draft A compression mechanism for the RPL option October 2014
This section defines the format of the RPL Packet Information NHC
(RPI_NHC) that is used to compress the RPI in 6LoWPAN networks.
4.1. Compressing the RPLInstanceId
RPL Instances are discussed in [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:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0| ID | Global RPLInstanceID in 0..127
+-+-+-+-+-+-+-+-+
Figure 2: RPLInstanceID Field Format for Global Instances
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.
4.2. Compressing the SenderRank
The SenderRank is the result of the DAGRank operation on the rank of
the sender; here the DAGRank operation is defined in [RFC6550],
Section 3.5.1, as:
DAGRank(rank) = floor(rank/MinHopRankIncrease)
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 [RFC6550] by defining DEFAULT_MIN_HOP_RANK_INCREASE
as 256 and in [RFC6552] that defaults MinHopRankIncrease to
DEFAULT_MIN_HOP_RANK_INCREASE.
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.
4.3. The RPI_NHC encoding
[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:
Thubert & Bormann Expires April 27, 2015 [Page 5]
Internet-Draft A compression mechanism for the RPL option October 2014
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:
O, R, and F bits: The O, R, and F bits as defined in [RFC6550],
Section 11.2.
NH: 1-bit flag. The Next Header (NH) bit is defined in [RFC6282],
Section 4.2, and it is set to indicate that the next header is
encoded using LOWPAN_NHC
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 [RFC6550], Section 5.1.
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.
In Figure 3, 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:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NHC: I=1, K=1 | SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The most compressed RPI_NHC
In Figure 4, the RPLInstanceID is the Global RPLInstanceID 0, but
both bytes of the SenderRank are significant so it can not be
compressed:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Eliding the RPLInstanceID
In Figure 5, the RPLInstanceID is not the Global RPLInstanceID 0, and
the MinHopRankIncrease is a multiple of 256:
Thubert & Bormann Expires April 27, 2015 [Page 6]
Internet-Draft A compression mechanism for the RPL option October 2014
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Compressing SenderRank
In Figure 6, the RPLInstanceID is not the Global RPLInstanceID 0, and
both bytes of the SenderRank are significant:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Least compressed form of RPI_NHC
The next sections provide alternatives for format of the RPI_NHC.
4.3.1. The Greedy Approach
The RPI_NHC is constructed as follows:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 0 | I | K | O | R | F |NH |
+---+---+---+---+---+---+---+---+
Figure 7: The RPI_NHC, Greedy Version
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 [RFC6553].
(This is called the "greedy" approach as it consumes 1/4 of the NHC
space just for the RPI compression.)
4.3.2. The Conservative Approach
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.
Thubert & Bormann Expires April 27, 2015 [Page 7]
Internet-Draft A compression mechanism for the RPL option October 2014
The NH type is indicated in an extension to existing LOWPAN_NHC
encodings. Section 4.2 of [RFC6553] defines LOWPAN_NHC encodings for
IPv6 Extension Headers as in Figure 8:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 1 | 1 | 0 | EID |NH |
+---+---+---+---+---+---+---+---+
Figure 8: IPv6 Extension Header Encoding
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 Figure 9:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| I | K | O | R | F | reserved |
+---+---+---+---+---+---+---+---+
Figure 9: The RPI_NHC, Conservative Version
The bits 5 to 7 of the RPI_NHC are reserved for future use and MUST
be sent as zero.
(This is called the "conservative" approach as it consumes only 1/256
of the NHC space.)
4.3.3. The Efficient Approach
4.3.3.1. The NHC escape mechanism
The NHC space of [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:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 0 | 1 | 0 | 0 | 0 | 1 | X | Y |
+---+---+---+---+---+---+---+---+
Figure 10: NHC Escape Codes
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.
Thubert & Bormann Expires April 27, 2015 [Page 8]
Internet-Draft A compression mechanism for the RPL option October 2014
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.
4.3.3.2. RPI_NHC Encoding
The RPI_NHC provides a compressed form for the RPI and is constructed
as follows:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 0 | 0 | 0 | O | I | K |NH |
+---+---+---+---+---+---+---+---+
Figure 11: RPI NHC, efficient version
The R and F bits, as defined in [RFC6550], Section 11.2, are
represented as follows:
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.)
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 [RFC6553].
(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.)
4.3.3.3. Operation
A 6lo compressor that is about to create either an RFC 6282 IPHC
header [RFC6282] or a Frag1 header [RFC4944] and finds a Hop-by-Hop
Options header [RFC2460] with an RPL Option [RFC6553] in it, performs
the following checks:
1. Does the compression scheme apply? I.e.:
A. is no sub-tlv present in the RPL Option?
B. is the RPL Option the only option in the Hop-by-Hop Options
header?
Thubert & Bormann Expires April 27, 2015 [Page 9]
Internet-Draft A compression mechanism for the RPL option October 2014
2. Does the additional compression for I=1 apply? I.e.: is
RPLInstanceID == 0?
3. Does the additional compression for K=1 apply? I.e.: is
SenderRank < 256?
4. Is both R=0 and F=0, or do we need an escape code?
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 Section 4.3.3.2.
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.
5. Security Considerations
The security considerations of [RFC4944], [RFC6282], and [RFC6553]
apply.
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 [RFC6553].
6. IANA Considerations
(greedy variant:)
This document updates IANA registry for the LOWPAN_NHC defined in
[RFC6282] and assigns the previously unassigned:
10IKORFN: RPL Information [RFCthis]
Capital letters in bit positions represent class-specific bit
assignments. IKORF represents variables specific to RPL Information
compression defined in Section 4. N indicates whether or not
additional LOWPAN_NHC encodings follow, as defined in Section 4.2 of
[RFC6553].
(efficient variant:)
Thubert & Bormann Expires April 27, 2015 [Page 10]
Internet-Draft A compression mechanism for the RPL option October 2014
This draft requests IANA to assign the following LOWPAN_NHC types in
the "IPv6 Low Power Personal Area Network Parameters" registry:
010001XY: Escape X=0/Y=0 to X=1/Y=1 [RFCthis]
1000IOKN: RPL Information [RFCthis]
7. Acknowledgements
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
[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.
8. References
8.1. Normative References
[IEEE802154]
IEEE standard for Information Technology, "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", June 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
September 2011.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012.
[RFC6552] Thubert, P., "Objective Function Zero for the Routing
Protocol for Low-Power and Lossy Networks (RPL)", RFC
6552, March 2012.
Thubert & Bormann Expires April 27, 2015 [Page 11]
Internet-Draft A compression mechanism for the RPL option October 2014
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
Power and Lossy Networks (RPL) Option for Carrying RPL
Information in Data-Plane Datagrams", RFC 6553, March
2012.
8.2. Informative References
[I-D.bormann-6lo-rpl-mesh]
Bormann, C., "NHC compression for RPL Packet Information",
draft-bormann-6lo-rpl-mesh-02 (work in progress), October
2014.
[I-D.ietf-6tisch-architecture]
Thubert, P., Watteyne, T., and R. Assimiti, "An
Architecture for IPv6 over the TSCH mode of IEEE
802.15.4e", draft-ietf-6tisch-architecture-03 (work in
progress), July 2014.
[I-D.ietf-6tisch-tsch]
Watteyne, T., Palattella, M., and L. Grieco, "Using
IEEE802.15.4e TSCH in an IoT context: Overview, Problem
Statement and Goals", draft-ietf-6tisch-tsch-02 (work in
progress), October 2014.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, January 2014.
Authors' Addresses
Pascal Thubert (editor)
Cisco Systems
Village d'Entreprises Green Side
400, Avenue de Roumanille
Batiment T3
Biot - Sophia Antipolis 06410
FRANCE
Phone: +33 4 97 23 26 34
Email: pthubert@cisco.com
Thubert & Bormann Expires April 27, 2015 [Page 12]
Internet-Draft A compression mechanism for the RPL option October 2014
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
Thubert & Bormann Expires April 27, 2015 [Page 13]
