idnits 2.17.1 draft-goyal-6lowpan-rpl-compression-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 17, 2011) is 4728 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-roll-routing-metrics' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-terminology' is defined on line 383, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-6man-reverse-routing-header' is defined on line 388, but no explicit reference was found in the text == Unused Reference: 'RFC5826' is defined on line 393, but no explicit reference was found in the text == Unused Reference: 'RFC5867' is defined on line 397, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-roll-p2p-rpl-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-roll-p2p-rpl (ref. 'I-D.ietf-roll-p2p-rpl') == Outdated reference: A later version (-20) exists of draft-ietf-roll-of0-10 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-05 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Goyal, Ed. 3 Internet-Draft University of Wisconsin 4 Intended status: Standards Track Milwaukee 5 Expires: November 18, 2011 E. Baccelli 6 M. Philipp 7 INRIA 8 A. Brandt 9 Sigma Designs 10 J. Martocci 11 Johnson Controls 12 May 17, 2011 14 A Compression Format for RPL Control Messages Over a 6lowpan 15 draft-goyal-6lowpan-rpl-compression-00 17 Abstract 19 This document specifies a compression format for ICMPv6 RPL control 20 messages over a 6lowpan. The specified format is in accordance with 21 IPv6 header compression framework defined for a 6lowpan. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 18, 2011. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. ICMPv6 Message Compression . . . . . . . . . . . . . . . . . . 3 60 3. Compressing the Base Object . . . . . . . . . . . . . . . . . 4 61 3.1. Compressing the DODAG Information Object . . . . . . . . . 4 62 4. Compressing the RPL Options . . . . . . . . . . . . . . . . . 6 63 4.1. DODAG Configuration Option . . . . . . . . . . . . . . . . 7 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 7. Authors and Contributors . . . . . . . . . . . . . . . . . . . 8 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 RPL [I-D.ietf-roll-rpl] is an IPv6 routing protocol for low power and 75 lossy networks. It defines a number of ICMPv6 control messages for 76 its operation. These messages are susceptible to fragmentation when 77 RPL is deployed on a 6lowpan with a small MAC layer payload (e.g. 78 IEEE 802.15.4, where the MAC payload can be as small as 81 bytes). 79 This document specifies a compression format for ICMPv6 RPL control 80 messages to minimize such fragmentation. The specified format is in 81 accordance with 6lowpan IPv6 header compression format defined in 82 [I-D.ietf-6lowpan-hc]. This document currently defines the 83 compression format for RPL's DODAG Information Object (DIO) and some 84 of the options that are carried inside a DIO. Later versions of this 85 document may include the compression formats for other RPL messages 86 as well as non-RPL ICMPv6 messages used in a 6lowpan. 88 1.1. Terminology 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 92 "OPTIONAL" in this document are to be interpreted as described in 93 [RFC2119]. 95 Additionally, this document uses terminology from 96 [I-D.ietf-6lowpan-hc], [I-D.ietf-roll-rpl] and 97 [I-D.ietf-roll-p2p-rpl]. 99 2. ICMPv6 Message Compression 101 0 1 2 3 4 5 6 7 8 102 +---+---+---+---+---+---+---+---+ 103 | 1 | 1 | 0 | ID | 104 +---+---+---+---+---+---+---+---+ 106 Figure 1: LOWPAN_NHC Encoding for an ICMPv6 Message 108 This document defines the single octet LOWPAN_NHC encoding for an 109 ICMPv6 message as shown in Figure 1. The ID field in the octet 110 identifies the particular ICMPv6 message being compressed. The ID 111 field values are as follows: 113 o 0: RPL DODAG Information Object (DIO) 115 o 1-31: Unassigned 117 Various fields of the ICMPv6 messages are treated in the following 118 manner: 120 o Type, Code: Always elided. The Type and Code of the ICMPv6 121 message being compressed are evident from the LOWPAN_NHC encoding 122 of the message. 124 o Checksum: The 16-bit Checksum is carried inline immediately 125 following the LOWPAN_NHC octet for the message. 127 o Base: The Base object carried in the message is compressed in the 128 manner described in Section 3. 130 o Option(s): Any options carried in the ICMPv6 message are 131 compressed as described in Section 4. The LOWPAN_NHC encoding for 132 the Base object identifies if any options are present in the 133 message. 135 3. Compressing the Base Object 137 This section defines the LOWPAN_NHC compression format for various 138 Base objects that can be carried inside an ICMPv6 message. 140 3.1. Compressing the DODAG Information Object 142 0 1 143 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - 145 |I|L|V|R|G|T|F|O| Ra | Compr | Inline Fields 146 +---+---+---+---+---+---+---+---+- - - - - - - - - - - - - - 148 Figure 2: The Compression Format for DODAG Information Object 150 The format of a compressed DODAG Information Object (DIO) base object 151 is shown in Figure 2 and consists of the following fields: 153 o I: This flag indicates whether the RPLInstanceID field is elided 154 or not. This flag is set to 1 if the RPLInstanceID field is 155 present inline in the compressed DIO. This flag is set to 0 if 156 the RPLInstanceID field is elided. In this case, the implicit 157 value of the RPLInstanceID depends on the value of the L flag as 158 discussed next. 160 o L: This flag indicates whether the elided RPLInstanceID field is 161 global or local. The flag is set to 1 if the RPLInstanceID field 162 is local. In this case, the implicit value of the RPLInstanceID 163 field is 128. The flag is set to 0 if the RPLInstanceID field is 164 global. In this case, the implicit value of the RPLInstanceID 165 field is 0. The L flag is meaningful only if the I flag is set to 166 0. If the I flag is set to 1, the L flag MUST be set to 0 on 167 transmission and ignored on reception. 169 o V: This flag indicates whether the Version Number field of the DIO 170 is elided or not. This flag is set to 1 if the Version Number is 171 carried inline. The flag is set to 0 if the Version Number is 172 elided. In this case, the implicit value of the Version Number is 173 assumed to be zero. 175 o R: This flag indicates whether the Rank field in the DIO is 176 shortened or not. This flag is set to 1 if the full 16-bit Rank 177 is present inline in the compressed DIO. The flag is set to 0 if 178 the 4-bit long Ra field contains the rank value. 180 o G: This flag indicates whether the byte containing the Grounded, 181 Mode of Operation and DODAG Preference fields is elided or not. 182 This flag is set to 1 if the above-mentioned byte is carried 183 inline. The flag is set to 0, if this byte is elided. In this 184 case, the implicit values of Grounded, Mode of Operation and 185 DODAGPreference fields are as follows: 187 * The Grounded flag has implicit value 0, i.e., the DODAG is not 188 grounded. 190 * The Mode of Operation field has implicit value 0, i.e., the 191 DODAG does not maintain any downward routes. 193 * The DODAG Preference field has implicit value 0, i.e., least 194 preferred. 196 o T: This flag indicates whether the DTSN field is elided or not. 197 This flag is set to 1 if the DTSN field is carried inline. The 198 flag is set to 0, if the DTSN field is elided. In this case, the 199 implicit value of the DTSN field is assumed to be zero. 201 o F: This flag indicates whether the Flags and Reserved fields in 202 the DIO are elided or not. This flag is set to 1 if these fields 203 are carried inline. The flag is set to 0, if these fields are 204 elided. In this case, both fields are assumed to be zero. 206 o O: The O flag is set if the first RPL option following the 207 compressed DIO base object has been compressed in the manner 208 described in this document. If the O flag is set, the first 209 (compressed) RPL option follows the inline fields of the DIO. The 210 O flag is set to 0 if the RPL control message does not contain any 211 option or if the first RPL option is not compressed in the manner 212 described in this document. 214 o Ra: This field contains the 4-bit rank value if the R flag is set 215 to 0. 217 o Compr: This field contains the number of prefix octets that are 218 elided from the DODAGID field. For example, the Compr value will 219 be zero if full 16-octet DODAGID field is carried inline in the 220 compressed DIO. 222 o Inline Fields: Any inline fields in the compressed DIO appear in 223 the same order as in the uncompressed format defined in 224 [I-D.ietf-roll-rpl]. 226 4. Compressing the RPL Options 228 This section defines the compression format for some of the RPL 229 options that may be carried inside an RPL control message. These RPL 230 options SHOULD be compressed when carried inside an RPL control 231 message compressed in the manner described in this document. The 232 other RPL options, for which a compression format is not specified in 233 this document, MUST follow the format in which they are defined when 234 carried inside an RPL control message compressed as described in this 235 document. 237 0 1 2 238 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------- 240 | Option Type | Option Length | Option Data 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------- 243 Figure 3: Format of a Compressed RPL Option 245 The compression format of an RPL option is shown in Figure 3. It 246 consists of: 248 o Option Type: The Option Type value for a compressed RPL option is 249 same as that of the uncompressed option with the most significant 250 bit (MSB) set to 1. 252 o Option Length: The Option Length is 8 bits long as in case of an 253 uncompressed RPL option. 255 4.1. DODAG Configuration Option 257 0 1 2 3 4 5 6 7 8 258 +---+---+---+---+---+---+---+---+- - - - - - - - 259 | F | T1| T2| I1| I2| O | R | L | Inline Fields 260 +---+---+---+---+---+---+---+---+- - - - - - - - 262 Figure 4: Format of a Compressed DODAG Configuration Option 264 The format of the compressed DODAG Configuration Option is shown in 265 Figure 4. The compressed DODAG Configuration option begins with an 266 octet consisting of flags that specify whether the individual fields 267 in the option are elided or not: 269 o F: This flag indicates whether the byte in the uncompressed DODAG 270 Configuration option, consisting of the Flags, A and PCS fields, 271 is elided or not. This flag is set to 1 if this byte is carried 272 inline. The flag is set to 0, if this byte is elided. In this 273 case, the implicit values of the A and PCS fields are zero and 274 DEFAULT_PATH_CONTROL_SIZE (as defined in [I-D.ietf-roll-rpl]) 275 respectively. 277 o T1: This flag indicates whether the DIOIntervalDoublings and 278 DIOIntervalMin fields are elided or not. This flag is set to 1 if 279 these fields are carried inline. The flag is set to 0, if these 280 fields are elided. In this case, these fields assume their 281 default values as defined in [I-D.ietf-roll-rpl]. 283 o T2: This flag indicates whether the DIORedundancyConstant field is 284 elided or not. This flag is set to 1 if DIORedundancyConstant is 285 carried inline. The flag is set to 0, if this field is elided. 286 In this case, the field assumes its default value as defined in 287 [I-D.ietf-roll-rpl]. 289 o I1: This flag indicates whether the MaxRankIncrease field is 290 elided or not. This flag is set to 1 if this field is carried 291 inline. The flag is set to 0 if this field is elided. In this 292 case, the MaxRankIncrease field assumes its default value (as 293 defined in [I-D.ietf-roll-rpl]). 295 o I2: This flag indicates whether the MinHopRankInc field is elided 296 or not. This flag is set to 1 if this field is carried inline. 297 The flag is set to 0 if this field is elided. In this case, the 298 MinHopRankInc field assumes its default value (as defined in 299 [I-D.ietf-roll-rpl]). 301 o O: This flag indicates whether the OCP field is elided or not. 302 This flag is set to 1 if this field is carried inline. The flag 303 is set to 0 if this field is elided. In this case, RPL Objective 304 Function 0 [I-D.ietf-roll-of0] is the OCP in effect. 306 o R: This flag indicates whether the byte marked as Reserved in the 307 uncompressed format is elided or not. This flag is set to 1 if 308 this byte is carried inline. The flag is set to 0 if this byte is 309 elided. In this case, the Reserved byte is assumed to have value 310 0. 312 o L: This flag indicates whether the Default Lifetime and Lifetime 313 Unit fields in the uncompressed format are elided or not. This 314 flag is set to 1 if these fields are carried inline. The flag is 315 set to 0 if these fields are elided. In this case, the life time 316 of the routes associates with this DODAG is infinity. 318 o Inline fields: Any inline fields in the compressed DODAG 319 Configuration option appear in the same order as in the 320 uncompressed format. 322 5. Security Considerations 324 TBA 326 6. IANA Considerations 328 TBA 330 7. Authors and Contributors 332 In addition to the editors, the authors of this document include the 333 following individuals (listed in alphabetical order). 335 Anders Brandt, Sigma Designs, Emdrupvej 26A, 1., Copenhagen, Dk-2100, 336 Denmark. Phone: +45 29609501; Email: abr@sdesigns.dk 338 Jerald Martocci, Johnson Controls, Milwaukee, WI 53202, USA. Phone: 339 +1 414 524 4010; Email:jerald.p.martocci@jci.com 341 Authors gratefully acknowledge the contributions of in the 342 development of this document. 344 8. References 345 8.1. Normative References 347 [I-D.ietf-6lowpan-hc] 348 Hui, J. and P. Thubert, "Compression Format for IPv6 349 Datagrams in Low Power and Lossy Networks (6LoWPAN)", 350 draft-ietf-6lowpan-hc-15 (work in progress), 351 February 2011. 353 [I-D.ietf-roll-p2p-rpl] 354 Goyal, M., Baccelli, E., Brandt, A., Cragie, R., Martocci, 355 J., and C. Perkins, "Reactive Discovery of Point-to-Point 356 Routes in Low Power and Lossy Networks", 357 draft-ietf-roll-p2p-rpl-02 (work in progress), 358 February 2011. 360 [I-D.ietf-roll-rpl] 361 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 362 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 363 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 364 Lossy Networks", draft-ietf-roll-rpl-19 (work in 365 progress), March 2011. 367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 368 Requirement Levels", BCP 14, RFC 2119, March 1997. 370 8.2. Informative References 372 [I-D.ietf-roll-of0] 373 Thubert, P., "RPL Objective Function 0", 374 draft-ietf-roll-of0-10 (work in progress), April 2011. 376 [I-D.ietf-roll-routing-metrics] 377 Vasseur, J., Kim, M., Pister, K., Dejean, N., and D. 378 Barthel, "Routing Metrics used for Path Calculation in Low 379 Power and Lossy Networks", 380 draft-ietf-roll-routing-metrics-19 (work in progress), 381 March 2011. 383 [I-D.ietf-roll-terminology] 384 Vasseur, J., "Terminology in Low power And Lossy 385 Networks", draft-ietf-roll-terminology-05 (work in 386 progress), March 2011. 388 [I-D.thubert-6man-reverse-routing-header] 389 Thubert, P., "Reverse Routing Header", 390 draft-thubert-6man-reverse-routing-header-01 (work in 391 progress), December 2010. 393 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 394 Routing Requirements in Low-Power and Lossy Networks", 395 RFC 5826, April 2010. 397 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 398 "Building Automation Routing Requirements in Low-Power and 399 Lossy Networks", RFC 5867, June 2010. 401 Authors' Addresses 403 Mukul Goyal (editor) 404 University of Wisconsin Milwaukee 405 3200 N Cramer St 406 Milwaukee, WI 53211 407 USA 409 Phone: +1 414 2295001 410 Email: mukul@uwm.edu 412 Emmanuel Baccelli 413 INRIA 415 Phone: +33-169-335-511 416 Email: Emmanuel.Baccelli@inria.fr 417 URI: http://www.emmanuelbaccelli.org/ 419 Matthias Philipp 420 INRIA 422 Email: matthias.philipp@inria.fr 424 Anders Brandt 425 Sigma Designs 427 Phone: +45-29609501 428 Email: abr@sdesigns.dk 430 Jerald Martocci 431 Johnson Controls 433 Phone: +1-414-524-4010 434 Email: jerald.p.martocci@jci.com