Internet Engineering Task Force M. Goyal, Ed.
Internet-Draft University of Wisconsin
Intended status: Standards Track Milwaukee
Expires: November 18, 2011 E. Baccelli
M. Philipp
INRIA
A. Brandt
Sigma Designs
J. Martocci
Johnson Controls
May 17, 2011
A Compression Format for RPL Control Messages Over a 6lowpan
draft-goyal-6lowpan-rpl-compression-00
Abstract
This document specifies a compression format for ICMPv6 RPL control
messages over a 6lowpan. The specified format is in accordance with
IPv6 header compression framework defined for a 6lowpan.
Status of this Memo
This Internet-Draft is submitted to IETF 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 November 18, 2011.
Copyright Notice
Copyright (c) 2011 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
Goyal, et al. Expires November 18, 2011 [Page 1]
Internet-Draft draft-goyal-6lowpan-rpl-compression-00 May 2011
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. ICMPv6 Message Compression . . . . . . . . . . . . . . . . . . 3
3. Compressing the Base Object . . . . . . . . . . . . . . . . . 4
3.1. Compressing the DODAG Information Object . . . . . . . . . 4
4. Compressing the RPL Options . . . . . . . . . . . . . . . . . 6
4.1. DODAG Configuration Option . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Authors and Contributors . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Goyal, et al. Expires November 18, 2011 [Page 2]
Internet-Draft draft-goyal-6lowpan-rpl-compression-00 May 2011
1. Introduction
RPL [I-D.ietf-roll-rpl] is an IPv6 routing protocol for low power and
lossy networks. It defines a number of ICMPv6 control messages for
its operation. These messages are susceptible to fragmentation when
RPL is deployed on a 6lowpan with a small MAC layer payload (e.g.
IEEE 802.15.4, where the MAC payload can be as small as 81 bytes).
This document specifies a compression format for ICMPv6 RPL control
messages to minimize such fragmentation. The specified format is in
accordance with 6lowpan IPv6 header compression format defined in
[I-D.ietf-6lowpan-hc]. This document currently defines the
compression format for RPL's DODAG Information Object (DIO) and some
of the options that are carried inside a DIO. Later versions of this
document may include the compression formats for other RPL messages
as well as non-RPL ICMPv6 messages used in a 6lowpan.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
Additionally, this document uses terminology from
[I-D.ietf-6lowpan-hc], [I-D.ietf-roll-rpl] and
[I-D.ietf-roll-p2p-rpl].
2. ICMPv6 Message Compression
0 1 2 3 4 5 6 7 8
+---+---+---+---+---+---+---+---+
| 1 | 1 | 0 | ID |
+---+---+---+---+---+---+---+---+
Figure 1: LOWPAN_NHC Encoding for an ICMPv6 Message
This document defines the single octet LOWPAN_NHC encoding for an
ICMPv6 message as shown in Figure 1. The ID field in the octet
identifies the particular ICMPv6 message being compressed. The ID
field values are as follows:
o 0: RPL DODAG Information Object (DIO)
o 1-31: Unassigned
Various fields of the ICMPv6 messages are treated in the following
manner:
Goyal, et al. Expires November 18, 2011 [Page 3]
Internet-Draft draft-goyal-6lowpan-rpl-compression-00 May 2011
o Type, Code: Always elided. The Type and Code of the ICMPv6
message being compressed are evident from the LOWPAN_NHC encoding
of the message.
o Checksum: The 16-bit Checksum is carried inline immediately
following the LOWPAN_NHC octet for the message.
o Base: The Base object carried in the message is compressed in the
manner described in Section 3.
o Option(s): Any options carried in the ICMPv6 message are
compressed as described in Section 4. The LOWPAN_NHC encoding for
the Base object identifies if any options are present in the
message.
3. Compressing the Base Object
This section defines the LOWPAN_NHC compression format for various
Base objects that can be carried inside an ICMPv6 message.
3.1. Compressing the DODAG Information Object
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - -
|I|L|V|R|G|T|F|O| Ra | Compr | Inline Fields
+---+---+---+---+---+---+---+---+- - - - - - - - - - - - - -
Figure 2: The Compression Format for DODAG Information Object
The format of a compressed DODAG Information Object (DIO) base object
is shown in Figure 2 and consists of the following fields:
o I: This flag indicates whether the RPLInstanceID field is elided
or not. This flag is set to 1 if the RPLInstanceID field is
present inline in the compressed DIO. This flag is set to 0 if
the RPLInstanceID field is elided. In this case, the implicit
value of the RPLInstanceID depends on the value of the L flag as
discussed next.
o L: This flag indicates whether the elided RPLInstanceID field is
global or local. The flag is set to 1 if the RPLInstanceID field
is local. In this case, the implicit value of the RPLInstanceID
field is 128. The flag is set to 0 if the RPLInstanceID field is
global. In this case, the implicit value of the RPLInstanceID
field is 0. The L flag is meaningful only if the I flag is set to
0. If the I flag is set to 1, the L flag MUST be set to 0 on
Goyal, et al. Expires November 18, 2011 [Page 4]
Internet-Draft draft-goyal-6lowpan-rpl-compression-00 May 2011
transmission and ignored on reception.
o V: This flag indicates whether the Version Number field of the DIO
is elided or not. This flag is set to 1 if the Version Number is
carried inline. The flag is set to 0 if the Version Number is
elided. In this case, the implicit value of the Version Number is
assumed to be zero.
o R: This flag indicates whether the Rank field in the DIO is
shortened or not. This flag is set to 1 if the full 16-bit Rank
is present inline in the compressed DIO. The flag is set to 0 if
the 4-bit long Ra field contains the rank value.
o G: This flag indicates whether the byte containing the Grounded,
Mode of Operation and DODAG Preference fields is elided or not.
This flag is set to 1 if the above-mentioned byte is carried
inline. The flag is set to 0, if this byte is elided. In this
case, the implicit values of Grounded, Mode of Operation and
DODAGPreference fields are as follows:
* The Grounded flag has implicit value 0, i.e., the DODAG is not
grounded.
* The Mode of Operation field has implicit value 0, i.e., the
DODAG does not maintain any downward routes.
* The DODAG Preference field has implicit value 0, i.e., least
preferred.
o T: This flag indicates whether the DTSN field is elided or not.
This flag is set to 1 if the DTSN field is carried inline. The
flag is set to 0, if the DTSN field is elided. In this case, the
implicit value of the DTSN field is assumed to be zero.
o F: This flag indicates whether the Flags and Reserved fields in
the DIO are elided or not. This flag is set to 1 if these fields
are carried inline. The flag is set to 0, if these fields are
elided. In this case, both fields are assumed to be zero.
o O: The O flag is set if the first RPL option following the
compressed DIO base object has been compressed in the manner
described in this document. If the O flag is set, the first
(compressed) RPL option follows the inline fields of the DIO. The
O flag is set to 0 if the RPL control message does not contain any
option or if the first RPL option is not compressed in the manner
described in this document.
Goyal, et al. Expires November 18, 2011 [Page 5]
Internet-Draft draft-goyal-6lowpan-rpl-compression-00 May 2011
o Ra: This field contains the 4-bit rank value if the R flag is set
to 0.
o Compr: This field contains the number of prefix octets that are
elided from the DODAGID field. For example, the Compr value will
be zero if full 16-octet DODAGID field is carried inline in the
compressed DIO.
o Inline Fields: Any inline fields in the compressed DIO appear in
the same order as in the uncompressed format defined in
[I-D.ietf-roll-rpl].
4. Compressing the RPL Options
This section defines the compression format for some of the RPL
options that may be carried inside an RPL control message. These RPL
options SHOULD be compressed when carried inside an RPL control
message compressed in the manner described in this document. The
other RPL options, for which a compression format is not specified in
this document, MUST follow the format in which they are defined when
carried inside an RPL control message compressed as described in this
document.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------
| Option Type | Option Length | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------
Figure 3: Format of a Compressed RPL Option
The compression format of an RPL option is shown in Figure 3. It
consists of:
o Option Type: The Option Type value for a compressed RPL option is
same as that of the uncompressed option with the most significant
bit (MSB) set to 1.
o Option Length: The Option Length is 8 bits long as in case of an
uncompressed RPL option.
Goyal, et al. Expires November 18, 2011 [Page 6]
Internet-Draft draft-goyal-6lowpan-rpl-compression-00 May 2011
4.1. DODAG Configuration Option
0 1 2 3 4 5 6 7 8
+---+---+---+---+---+---+---+---+- - - - - - - -
| F | T1| T2| I1| I2| O | R | L | Inline Fields
+---+---+---+---+---+---+---+---+- - - - - - - -
Figure 4: Format of a Compressed DODAG Configuration Option
The format of the compressed DODAG Configuration Option is shown in
Figure 4. The compressed DODAG Configuration option begins with an
octet consisting of flags that specify whether the individual fields
in the option are elided or not:
o F: This flag indicates whether the byte in the uncompressed DODAG
Configuration option, consisting of the Flags, A and PCS fields,
is elided or not. This flag is set to 1 if this byte is carried
inline. The flag is set to 0, if this byte is elided. In this
case, the implicit values of the A and PCS fields are zero and
DEFAULT_PATH_CONTROL_SIZE (as defined in [I-D.ietf-roll-rpl])
respectively.
o T1: This flag indicates whether the DIOIntervalDoublings and
DIOIntervalMin fields are elided or not. This flag is set to 1 if
these fields are carried inline. The flag is set to 0, if these
fields are elided. In this case, these fields assume their
default values as defined in [I-D.ietf-roll-rpl].
o T2: This flag indicates whether the DIORedundancyConstant field is
elided or not. This flag is set to 1 if DIORedundancyConstant is
carried inline. The flag is set to 0, if this field is elided.
In this case, the field assumes its default value as defined in
[I-D.ietf-roll-rpl].
o I1: This flag indicates whether the MaxRankIncrease field is
elided or not. This flag is set to 1 if this field is carried
inline. The flag is set to 0 if this field is elided. In this
case, the MaxRankIncrease field assumes its default value (as
defined in [I-D.ietf-roll-rpl]).
o I2: This flag indicates whether the MinHopRankInc field is elided
or not. This flag is set to 1 if this field is carried inline.
The flag is set to 0 if this field is elided. In this case, the
MinHopRankInc field assumes its default value (as defined in
[I-D.ietf-roll-rpl]).
o O: This flag indicates whether the OCP field is elided or not.
This flag is set to 1 if this field is carried inline. The flag
Goyal, et al. Expires November 18, 2011 [Page 7]
Internet-Draft draft-goyal-6lowpan-rpl-compression-00 May 2011
is set to 0 if this field is elided. In this case, RPL Objective
Function 0 [I-D.ietf-roll-of0] is the OCP in effect.
o R: This flag indicates whether the byte marked as Reserved in the
uncompressed format is elided or not. This flag is set to 1 if
this byte is carried inline. The flag is set to 0 if this byte is
elided. In this case, the Reserved byte is assumed to have value
0.
o L: This flag indicates whether the Default Lifetime and Lifetime
Unit fields in the uncompressed format are elided or not. This
flag is set to 1 if these fields are carried inline. The flag is
set to 0 if these fields are elided. In this case, the life time
of the routes associates with this DODAG is infinity.
o Inline fields: Any inline fields in the compressed DODAG
Configuration option appear in the same order as in the
uncompressed format.
5. Security Considerations
TBA
6. IANA Considerations
TBA
7. Authors and Contributors
In addition to the editors, the authors of this document include the
following individuals (listed in alphabetical order).
Anders Brandt, Sigma Designs, Emdrupvej 26A, 1., Copenhagen, Dk-2100,
Denmark. Phone: +45 29609501; Email: abr@sdesigns.dk
Jerald Martocci, Johnson Controls, Milwaukee, WI 53202, USA. Phone:
+1 414 524 4010; Email:jerald.p.martocci@jci.com
Authors gratefully acknowledge the contributions of in the
development of this document.
8. References
Goyal, et al. Expires November 18, 2011 [Page 8]
Internet-Draft draft-goyal-6lowpan-rpl-compression-00 May 2011
8.1. Normative References
[I-D.ietf-6lowpan-hc]
Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams in Low Power and Lossy Networks (6LoWPAN)",
draft-ietf-6lowpan-hc-15 (work in progress),
February 2011.
[I-D.ietf-roll-p2p-rpl]
Goyal, M., Baccelli, E., Brandt, A., Cragie, R., Martocci,
J., and C. Perkins, "Reactive Discovery of Point-to-Point
Routes in Low Power and Lossy Networks",
draft-ietf-roll-p2p-rpl-02 (work in progress),
February 2011.
[I-D.ietf-roll-rpl]
Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
Vasseur, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-19 (work in
progress), March 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.ietf-roll-of0]
Thubert, P., "RPL Objective Function 0",
draft-ietf-roll-of0-10 (work in progress), April 2011.
[I-D.ietf-roll-routing-metrics]
Vasseur, J., Kim, M., Pister, K., Dejean, N., and D.
Barthel, "Routing Metrics used for Path Calculation in Low
Power and Lossy Networks",
draft-ietf-roll-routing-metrics-19 (work in progress),
March 2011.
[I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-05 (work in
progress), March 2011.
[]
Thubert, P., "Reverse Routing Header",
draft-thubert-6man-reverse-routing-header-01 (work in
progress), December 2010.
Goyal, et al. Expires November 18, 2011 [Page 9]
Internet-Draft draft-goyal-6lowpan-rpl-compression-00 May 2011
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks",
RFC 5826, April 2010.
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
"Building Automation Routing Requirements in Low-Power and
Lossy Networks", RFC 5867, June 2010.
Authors' Addresses
Mukul Goyal (editor)
University of Wisconsin Milwaukee
3200 N Cramer St
Milwaukee, WI 53211
USA
Phone: +1 414 2295001
Email: mukul@uwm.edu
Emmanuel Baccelli
INRIA
Phone: +33-169-335-511
Email: Emmanuel.Baccelli@inria.fr
URI: http://www.emmanuelbaccelli.org/
Matthias Philipp
INRIA
Email: matthias.philipp@inria.fr
Anders Brandt
Sigma Designs
Phone: +45-29609501
Email: abr@sdesigns.dk
Jerald Martocci
Johnson Controls
Phone: +1-414-524-4010
Email: jerald.p.martocci@jci.com
Goyal, et al. Expires November 18, 2011 [Page 10]