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. [I-D.thubert-6man-reverse-routing-header] 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]