6lo working group C. Bormann
Internet-Draft Universitaet Bremen TZI
Intended status: Standards Track August 14, 2014
Expires: February 15, 2015
6lo RPL Information Header
draft-bormann-6lo-rpl-mesh-01
Abstract
This short draft provides a straw man for the RPL Information Header,
a method to compress RPL Option [RFC6553] information within 6lowpan-
style ("6lo") adaptation layers.
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 February 15, 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Bormann Expires February 15, 2015 [Page 1]
Internet-Draft 6lo RPL Information Header August 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
2. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security considerations . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
[I-D.thubert-6man-flow-label-for-rpl] defines a way to compress
information from the [RFC6553] RPL Option, for inclusion in an IPv6
flow label. The present draft shows how to carry the same
information in a RPL Information Header, in a potentially slightly
more efficient way.
The RPL Information Header is added to the 6lo adaptation layer
framework ([RFC4944], [RFC6282]) as a small number of additional
dispatch codes.
(More background information in Section 5.)
1.1. 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 RFC 2119 [RFC2119].
2. Encoding
(Insert definitions from [I-D.thubert-6man-flow-label-for-rpl] here.)
Where [I-D.thubert-6man-flow-label-for-rpl] would carry the [RFC6553]
information in a flow label:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |O|R|F| SenderRank | RPLInstanceID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bormann Expires February 15, 2015 [Page 2]
Internet-Draft 6lo RPL Information Header August 2014
the RPL Information header carries it in a RFC 4944 header.
Depending on whether Rank and Inst both fit into 4 bits (S=0) or not
(S=1), this header is structured as shown in Figure 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 0 0 1|0|U| Rank | Inst | (continuation)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 0 0 1|1|U| Rank | Inst | (continuation)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RPL Mesh Header: Short and Long Version
The U bit controls whether an [RFC6282] IPHC dispatch follows (U=0,
Figure 2) or an [RFC4944] FRAG1 fragment header (U=1, Figure 3). In
both cases, the first three bits of the dispatch are replaced by the
O, R, and F bits from [I-D.thubert-6man-flow-label-for-rpl].
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| O | R | F | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 2: continuation for U=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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O R F 0 0| datagram_size | datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: continuation for U=1
Note that, for U=1, continuation bytes of the form XXXnnXXX, where nn
is not 00, are available for future updates of this header (they do
not necessarily imply a Frag1 header).
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
Bormann Expires February 15, 2015 [Page 3]
Internet-Draft 6lo RPL Information Header August 2014
Options header [RFC2460] with a single RPL Option [RFC6553] in it,
performs the following checks:
1. Does the compression scheme in
[I-D.thubert-6man-flow-label-for-rpl] apply? I.e.:
A. is no sub-tlv present in the RPL Option?
B. is SenderRank < 256?
2. Does the additional compression for S=0 apply? I.e.:
A. is SenderRank < 16?
B. is RPLInstanceID < 16?
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, generates
an RPL Information Header with S=0 or S=1 from the payload
information in the RPL Option. 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 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.
4. Discussion
(This section to be removed by the RFC editor.)
Compared to [I-D.thubert-6man-flow-label-for-rpl], the 6lo-based
approach used here has the following advantages:
o more efficient (in size) encoding possible
o avoids any entanglement with flow label from RFC 6437
o avoids any issues with undetected changes to flow label field,
which might be:
* because the IPv6 header is not covered by a checksum
* because nodes that happen to become on-path use the flow label
for something else
Bormann Expires February 15, 2015 [Page 4]
Internet-Draft 6lo RPL Information Header August 2014
o nodes outside 6lo that do not need the compression do not have to
deal with an alternate representations of the RFC 6553 information
Compared to [I-D.toutain-6lo-local-extensions], RPL Information
Header proposal is entirely focused on RFC 6553 (with some extension
bits left to possibly eventually cover RFC 6554). So it may be
possible to complete this focused draft much faster than a general
approach. Also, the result is likely to be more efficient. Finally,
this draft can be ignored by implementations not implementing RPL.
5. Background
Some more historical background about compression and RPL: (This
section to be removed by the RFC editor.)
The ROLL WG has a routing protocol, RPL [RFC6550], that requires some
data to be shipped around together with IP packets. [RFC6553] and
[RFC6554] define ways to do this that are consistent with the IP
architecture: The RPL Option defined in [RFC6553] is a hop-by-hop
option that provides RPL rank and instance-id, as well as a few
flags; the Routing Header defined in [RFC6554] provides the source
routing needed for downward-routed packets in RPL's dominant non-
storing mode.
Unfortunately, the overhead (signal-to-fluff ratio) for both
representations is relatively high, and in a constrained environment,
that matters.
An obvious next step would have been looking at ways to do header
compression. Compressing RPL was extensively discussed, but mostly
with a view to compressing the (control plane) ROLL messages carried
in ICMPv6, not so much about the RPL information carried with the
(data plane) IP packets themselves. GHC [I-D.ietf-6lo-ghc] is trying
to be a reasonably useful, but also reasonably general way to
compress the control plane messages.
For the data packets, the flow label (and its now predominant non-
use) provides an attractive place in the IPv6 packets to ship around
the [RFC6553] information, but not the potentially more substantial
[RFC6554] information. In 6lo networks, normally [RFC6282]
compresses away empty flow labels, but it is cheap to put them in, so
a flow label really only costs 3 bytes (instead of the 8 bytes a RPL
Option [RFC6553] costs). The most useful information from [RFC6553]
can be stuffed into 19 bits, as demonstrated by
[I-D.thubert-6man-flow-label-for-rpl].
[RFC6282] has extension points (GHC uses one of them), but not really
useful ones for the ROLL data plane. So it appears it never occurred
Bormann Expires February 15, 2015 [Page 5]
Internet-Draft 6lo RPL Information Header August 2014
to us that the best way to handle these 19 bits is to actually
sidestep [RFC6282], and use the existing extension points of
[RFC4944]. Until Laurent Toutain showed one way of doing this
[I-D.toutain-6lo-local-extensions]. The present draft just went from
there and used Laurent's idea for compressing the [RFC6553] option,
in a way that is as efficient as (or, in most cases, actually more
efficient than) using the flow label opportunity.
This means the present draft intends to replace the flow label bit
allocation of [I-D.thubert-6man-flow-label-for-rpl]. It does not
cover the "license-to-drop" the flow label that
[I-D.thubert-6man-flow-label-for-rpl] implies (and that is denied by
[RFC6437]). It also does not cover the compression of [RFC6554]
source routing information, but does provide an extension point for
adding that later.
6. IANA considerations
This draft requests IANA to assign the following four dispatch types
in the "IPv6 Low Power Personal Area Network Parameters" registry:
01 0001SU
7. Security considerations
The security considerations of [RFC4944], [RFC6282], and [RFC6553]
apply.
8. Acknowledgments
This document is based on the ideas in the specification
[I-D.thubert-6man-flow-label-for-rpl]. Its use of the RFC 4944
framework was inspired by [I-D.toutain-6lo-local-extensions]. Ralph
Droms supplied a number of helpful comments on the -00 draft. The
discussion in the 6man and roll working groups also was helpful.
9. References
9.1. Normative References
[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.
Bormann Expires February 15, 2015 [Page 6]
Internet-Draft 6lo RPL Information Header August 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.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
September 2011.
[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.
9.2. Informative References
[I-D.ietf-6lo-ghc]
Bormann, C., "6LoWPAN Generic Compression of Headers and
Header-like Payloads", draft-ietf-6lo-ghc-03 (work in
progress), July 2014.
[I-D.thubert-6man-flow-label-for-rpl]
Thubert, P., "The IPv6 Flow Label within a RPL domain",
draft-thubert-6man-flow-label-for-rpl-04 (work in
progress), August 2014.
[I-D.toutain-6lo-local-extensions]
Toutain, L., "6LoWPAN Local Extensions", draft-toutain-
6lo-local-extensions-00 (work in progress), June 2014.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437, November 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.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554, March
2012.
Author's Address
Bormann Expires February 15, 2015 [Page 7]
Internet-Draft 6lo RPL Information Header August 2014
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
Bormann Expires February 15, 2015 [Page 8]