idnits 2.17.1 draft-bormann-6lowpan-ghc-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2010) is 4939 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) == Outdated reference: A later version (-15) exists of draft-ietf-6lowpan-hc-13 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6LoWPAN Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track October 18, 2010 5 Expires: April 21, 2011 7 6LoWPAN Generic Compression of Headers and Header-like Payloads 8 draft-bormann-6lowpan-ghc-00 10 Abstract 12 This short I-D provides a basic design for a an addition to 6lowpan 13 Header Compression that enables the compression of generic headers 14 and header-like payloads. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 21, 2011. 33 Copyright Notice 35 Copyright (c) 2010 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. The Header Compression Coupling Problem . . . . . . . . . . . 3 51 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. 6lowpan-ghc . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 56 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 57 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 58 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 61 1. The Header Compression Coupling Problem 63 [I-D.ietf-6lowpan-hc] defines a scheme for header compression in 64 6LoWPAN [RFC4944] packets. As with most header compression schemes, 65 a new specification is needed for every new kind of header that needs 66 to be compressed. In addition, [I-D.ietf-6lowpan-hc] does not define 67 an extensibility scheme like the ROHC profiles defined in ROHC 68 [RFC3095] [RFC5795]. This leads to the difficult situation that 69 [I-D.ietf-6lowpan-hc] tends to be reopened and reexamined each time a 70 new header receives consideration (or an old header is changed and 71 reconsidered) in the 6lowpan/roll/core cluster of IETF working 72 groups. At this rate, [I-D.ietf-6lowpan-hc] will never get completed 73 (fortunately, by now it has passed WGLC, but the underlying problem 74 remains unsolved). 76 The purpose of the present contribution is to plug into 77 [I-D.ietf-6lowpan-hc] as is, using its NHC (next header compression) 78 concept. We add a slightly less efficient, but vastly more general 79 form of compression for headers of any kind and even for header-like 80 payloads such as those exhibited by routing protocols, DHCP, etc. 81 The objective is to arrive at something that can be defined on a 82 single page and implemented in a couple of lines of code, as opposed 83 to a general data compression scheme such as that defined in 84 [RFC1951]. 86 1.1. Terminology 88 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 89 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 90 and "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119] 91 and indicate requirement levels for compliant CoAP implementations. 93 The term "byte" is used in its now customary sense as a synonym for 94 "octet". 96 2. 6lowpan-ghc 98 The format of a compressed header or payload is a simple bytecode. A 99 compressed header consists of a sequence of pieces, each of which 100 begins with a code byte, which may be followed by zero or more bytes 101 as its argument. Some code bytes cause bytes to be laid out in the 102 destination buffer, some simply modify some decompression variables. 104 At the start of decompressing an L2 packet (= fragment), variable s 105 is initialized as zero. 107 The code bytes are defined as follows: 109 +----------+--------------------------------------------+-----------+ 110 | code | Action | Argument | 111 | byte | | | 112 +----------+--------------------------------------------+-----------+ 113 | 0kkkkkkk | Copy k+1 bytes of actual data (k < 96) | The k+1 | 114 | | | bytes of | 115 | | | data | 116 | | | | 117 | 011sssss | s = (sssss * 8) | | 118 | | | | 119 | 10000nnn | reserved | | 120 | | | | 121 | 10001kkk | Insert 8 bytes copied from previous bytes, | | 122 | | at k + s bytes distance; s += 8 | | 123 | | | | 124 | 1001nnnn | Insert n+2 bytes of zeroes | | 125 | | | | 126 | 1010iiii | Insert all bytes (possibly filling an | | 127 | | incomplete byte with zero bits) from | | 128 | | Context i | | 129 | | | | 130 | 1011iiii | Insert 8 bytes from Context i; i.e., the | | 131 | | context value truncated/extended to 8 | | 132 | | bytes, and then insert 0000 00FF FE00 | | 133 | | | | 134 | 11nnnkkk | Insert n+2 bytes from previous bytes, k + | | 135 | | s bytes distance; s = 0 | | 136 +----------+--------------------------------------------+-----------+ 138 For the purposes of the backreferences, the expansion buffer is 139 initialized with the pseudo-header as defined in [RFC2460], at the 140 end of which the target buffer begins. These pseudo-header bytes are 141 therefore available for backreferencing, but not copied into the 142 final result. 144 3. Examples 146 This section demonstrates a couple of realistic examples derived from 147 actual PCAP dumps taken at previous interops. Unfortunately, for 148 these dumps, no context information was available, so the relatively 149 powerful effect of context-based compression is not shown. (TBD: Add 150 a couple more general ICMP, ND, DHCP and RPL examples that show how 151 nifty all this is.) 153 Figure 1 shows a quite short RPL control message that obviously 154 cannot be improved much. 156 IP header: 157 60 00 00 00 00 08 3a ff fe 80 00 00 00 00 00 00 158 02 1c da ff fe 00 20 24 ff 02 00 00 00 00 00 00 159 00 00 00 00 00 00 00 1a 160 Payload: 161 9b 00 6b de 00 00 00 00 162 Pseudoheader: 163 fe 80 00 00 00 00 00 00 02 1c da ff fe 00 20 24 164 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 1a 165 00 00 00 08 00 00 00 3a 166 copy: 04 9b 00 6b de 167 4 nulls: 92 168 Compressed: 169 04 9b 00 6b de 92 170 Was 8 bytes; compressed to 6 bytes, 75 % 172 Figure 1: A simple RPL example 174 Figure 2 shows a longer RPL control message that is improved a bit 175 more (but would likely benefit additionally from a context 176 reference). Note that the compressed output exposes an inefficiency 177 in the simple-minded compressor used to generate it; this does not 178 devalue the example since constrained nodes are quite likely to make 179 use of simple-minded compressors. 181 IP header: 182 60 00 00 00 00 5c 3a ff fe 80 00 00 00 00 00 00 183 02 1c da ff fe 00 30 23 ff 02 00 00 00 00 00 00 184 00 00 00 00 00 00 00 1a 185 Payload: 186 9b 01 7a 5f 00 f0 01 00 88 00 00 00 20 02 0d b8 187 00 00 00 00 00 00 00 ff fe 00 fa ce 04 0e 00 14 188 09 ff 00 00 01 00 00 00 00 00 00 00 08 1e 80 20 189 ff ff ff ff ff ff ff ff 00 00 00 00 20 02 0d b8 190 00 00 00 00 00 00 00 ff fe 00 fa ce 03 0e 40 00 191 ff ff ff ff 20 02 0d b8 00 00 00 00 0a 192 Pseudoheader: 193 fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 194 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 1a 195 00 00 00 5d 00 00 00 3a 196 copy: 09 9b 01 7a 5f 00 f0 01 00 88 197 3 nulls: 91 198 copy: 04 20 02 0d b8 199 7 nulls: 95 200 ref(52): ff fe 00 -> ref 011sssss 6/11nnnkkk 1 4: 66 cc 201 copy: 08 fa ce 04 0e 00 14 09 ff 202 2 nulls: 90 203 copy: 01 01 204 7 nulls: 95 205 copy: 06 08 1e 80 20 ff ff 206 ref(2): ff ff -> ref 11nnnkkk 0 2: c2 207 ref(4): ff ff ff ff -> ref 11nnnkkk 2 4: d4 208 4 nulls: 92 209 ref(48): 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 fa ce 210 -> ref 011sssss 6/10001kkk 0/11nnnkkk 6 0: 66 88 f0 211 copy: 03 03 0e 40 212 ref(9): 00 ff -> ref 011sssss 1/11nnnkkk 0 1: 61 c1 213 ref(28): ff ff ff -> ref 011sssss 3/11nnnkkk 1 4: 63 cc 214 ref(24): 20 02 0d b8 00 00 00 00 215 -> ref 011sssss 3/11nnnkkk 6 0: 63 f0 216 copy: 01 0a 217 Compressed: 218 09 9b 01 7a 5f 00 f0 01 00 88 91 04 20 02 0d b8 219 95 66 cc 08 fa ce 04 0e 00 14 09 ff 90 01 01 95 220 06 08 1e 80 20 ff ff c2 d4 92 66 88 f0 03 03 0e 221 40 61 c1 63 cc 63 f0 01 0a 222 Was 93 bytes; compressed to 57 bytes, 61 % 224 Figure 2: A longer RPL example 226 Figure 3 shows an the effect of compressing a simple ND neighbor 227 solicitation (again, no context-based compression). 229 IP header: 230 60 00 00 00 00 30 3a ff 20 02 0d b8 00 00 00 00 231 00 00 00 ff fe 00 3b d3 fe 80 00 00 00 00 00 00 232 02 1c da ff fe 00 30 23 233 Payload: 234 87 00 a7 68 00 00 00 00 fe 80 00 00 00 00 00 00 235 02 1c da ff fe 00 30 23 01 01 3b d3 00 00 00 00 236 1f 02 00 00 00 00 00 06 00 1c da ff fe 00 20 24 237 Pseudoheader: 238 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 3b d3 239 fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 240 00 00 00 30 00 00 00 3a 241 copy: 04 87 00 a7 68 242 4 nulls: 92 243 ref(32): fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 244 -> ref 011sssss 4/10001kkk 0/11nnnkkk 6 0: 64 88 f0 245 copy: 04 01 01 3b d3 246 4 nulls: 92 247 copy: 02 1f 02 248 5 nulls: 93 249 copy: 02 06 00 250 ref(24): 1c da ff fe 00 -> ref 011sssss 3/11nnnkkk 3 0: 63 d8 251 copy: 02 20 24 252 Compressed: 253 04 87 00 a7 68 92 64 88 f0 04 01 01 3b d3 92 02 254 1f 02 93 02 06 00 63 d8 02 20 24 255 Was 48 bytes; compressed to 27 bytes, 56 % 257 Figure 3: An ND neighbor solicitation 259 Figure 4 shows the compression of an ND neighbor advertisement. No 260 RS or RA examples were available at this time; note that particularly 261 RA messages might improve (even if they often will not be able to 262 make use of context-based compression). 264 IP header: 265 60 00 00 00 00 30 3a fe fe 80 00 00 00 00 00 00 266 02 1c da ff fe 00 30 23 20 02 0d b8 00 00 00 00 267 00 00 00 ff fe 00 3b d3 268 Payload: 269 88 00 26 6c c0 00 00 00 fe 80 00 00 00 00 00 00 270 02 1c da ff fe 00 30 23 02 01 fa ce 00 00 00 00 271 1f 02 00 00 00 00 00 06 00 1c da ff fe 00 20 24 272 Pseudoheader: 273 fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 274 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 3b d3 275 00 00 00 30 00 00 00 3a 276 copy: 05 88 00 26 6c c0 277 3 nulls: 91 278 ref(48): fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 279 -> ref 011sssss 6/10001kkk 0/11nnnkkk 6 0: 66 88 f0 280 copy: 04 02 01 fa ce 281 4 nulls: 92 282 copy: 02 1f 02 283 5 nulls: 93 284 copy: 02 06 00 285 ref(24): 1c da ff fe 00 286 -> ref 011sssss 3/11nnnkkk 3 0: 63 d8 287 copy: 02 20 24 288 Compressed: 289 05 88 00 26 6c c0 91 66 88 f0 04 02 01 fa ce 92 290 02 1f 02 93 02 06 00 63 d8 02 20 24 291 Was 48 bytes; compressed to 28 bytes, 58 % 293 Figure 4: An ND neighbor advertisement 295 4. Acknowledgements 297 Colin O'Flynn has repeatedly insisted that some form of compression 298 for ICMPv6 and ND packets might be beneficial. He actually has his 299 own draft, [I-D.oflynn-6lowpan-icmphc], which compresses better, but 300 addresses basic ICMPv6/ND only and needs a much longer spec (around 301 17 pages of detailed spec, as compared to the single page here). 302 This motivated the author to try something simple, yet general. 304 5. Security Considerations 306 (To be worked out.) 308 6. References 310 6.1. Normative References 312 [I-D.ietf-6lowpan-hc] 313 Hui, J. and P. Thubert, "Compression Format for IPv6 314 Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-13 315 (work in progress), September 2010. 317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", BCP 14, RFC 2119, March 1997. 320 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 321 (IPv6) Specification", RFC 2460, December 1998. 323 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 324 "Transmission of IPv6 Packets over IEEE 802.15.4 325 Networks", RFC 4944, September 2007. 327 6.2. Informative References 329 [I-D.oflynn-6lowpan-icmphc] 330 O'Flynn, C., "ICMPv6/ND Compression for 6LoWPAN Networks", 331 draft-oflynn-6lowpan-icmphc-00 (work in progress), 332 July 2010. 334 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 335 version 1.3", RFC 1951, May 1996. 337 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 338 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 339 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 340 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 341 Compression (ROHC): Framework and four profiles: RTP, UDP, 342 ESP, and uncompressed", RFC 3095, July 2001. 344 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 345 Header Compression (ROHC) Framework", RFC 5795, 346 March 2010. 348 Author's Address 350 Carsten Bormann 351 Universitaet Bremen TZI 352 Postfach 330440 353 Bremen D-28359 354 Germany 356 Phone: +49-421-218-63921 357 Fax: +49-421-218-7000 358 Email: cabo@tzi.org