idnits 2.17.1 draft-bormann-6lowpan-ghc-01.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 23, 2010) is 4934 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) == Missing Reference: 'RFCthis' is mentioned on line 428, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-6lowpan-hc-13 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 3 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 23, 2010 5 Expires: April 26, 2011 7 6LoWPAN Generic Compression of Headers and Header-like Payloads 8 draft-bormann-6lowpan-ghc-01 10 Abstract 12 This short I-D provides a complete design for a simple addition to 13 6LoWPAN Header Compression that enables the compression of generic 14 headers 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 26, 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. Integrating 6LoWPAN-GHC into 6LoWPAN-HC . . . . . . . . . . . 11 55 4.1. Compressing extension headers . . . . . . . . . . . . . . 11 56 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 57 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 60 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 61 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 64 1. The Header Compression Coupling Problem 66 [I-D.ietf-6lowpan-hc] defines a scheme for header compression in 67 6LoWPAN [RFC4944] packets. As with most header compression schemes, 68 a new specification is needed for every new kind of header that needs 69 to be compressed. In addition, [I-D.ietf-6lowpan-hc] does not define 70 an extensibility scheme like the ROHC profiles defined in ROHC 71 [RFC3095] [RFC5795]. This leads to the difficult situation that 72 [I-D.ietf-6lowpan-hc] tends to be reopened and reexamined each time a 73 new header receives consideration (or an old header is changed and 74 reconsidered) in the 6lowpan/roll/core cluster of IETF working 75 groups. At this rate, [I-D.ietf-6lowpan-hc] will never get completed 76 (fortunately, by now it has passed WGLC, but the underlying problem 77 remains unsolved). 79 The purpose of the present contribution is to plug into 80 [I-D.ietf-6lowpan-hc] as is, using its NHC (next header compression) 81 concept. We add a slightly less efficient, but vastly more general 82 form of compression for headers of any kind and even for header-like 83 payloads such as those exhibited by routing protocols, DHCP, etc. 84 The objective is to arrive at something that can be defined on a 85 single page and implemented in a couple of lines of code, as opposed 86 to a general data compression scheme such as that defined in 87 [RFC1951]. 89 1.1. Terminology 91 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 92 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 93 and "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119] 94 and indicate requirement levels for compliant CoAP implementations. 96 The term "byte" is used in its now customary sense as a synonym for 97 "octet". 99 2. 6LoWPAN-GHC 101 The format of a compressed header or payload is a simple bytecode. A 102 compressed header consists of a sequence of pieces, each of which 103 begins with a code byte, which may be followed by zero or more bytes 104 as its argument. Some code bytes cause bytes to be laid out in the 105 destination buffer, some simply modify some decompression variables. 107 At the start of decompressing a header or payload within a L2 packet 108 (= fragment), variables "sa" and "na" are initialized as zero. 110 The code bytes are defined as follows: 112 +----------+---------------------------------------------+----------+ 113 | code | Action | Argument | 114 | byte | | | 115 +----------+---------------------------------------------+----------+ 116 | 0kkkkkkk | Append k = 0b0kkkkkkk bytes of data in the | The k | 117 | | bytecode argument (k < 96) | bytes of | 118 | | | data | 119 | | | | 120 | 0110iiii | Append all bytes (possibly filling an | | 121 | | incomplete byte with zero bits) from | | 122 | | Context i | | 123 | | | | 124 | 0111iiii | Append 8 bytes from Context i; i.e., the | | 125 | | context value truncated/extended to 8 | | 126 | | bytes, and then append 0000 00FF FE00 | | 127 | | (i.e., 14 bytes total) | | 128 | | | | 129 | 1000nnnn | Append 0b0000nnnn+2 bytes of zeroes | | 130 | | | | 131 | 1001nnnn | reserved | | 132 | | | | 133 | 101nssss | sa += 0b0ssss000, na += 0b0000n000 | | 134 | | | | 135 | 11nnnkkk | n = na+0b00000nnn+2; s = 0b00000kkk+sa+n; | | 136 | | append n bytes from previously output | | 137 | | bytes, starting s bytes to the left of the | | 138 | | current output pointer; set sa = 0, na = 0 | | 139 +----------+---------------------------------------------+----------+ 141 For the purposes of the backreferences, the expansion buffer is 142 initialized with the pseudo-header as defined in [RFC2460], at the 143 end of which the target buffer begins. These pseudo-header bytes are 144 therefore available for backreferencing, but not copied into the 145 final result. 147 3. Examples 149 This section demonstrates some relatively realistic examples derived 150 from actual PCAP dumps taken at previous interops. Unfortunately, 151 for these dumps, no context information was available, so the 152 relatively powerful effect of context-based compression is not shown. 153 (TBD: Add a couple DHCP examples.) 155 Figure 1 shows a quite short RPL control message that obviously 156 cannot be improved much. 158 IP header: 159 60 00 00 00 00 08 3a ff fe 80 00 00 00 00 00 00 160 02 1c da ff fe 00 20 24 ff 02 00 00 00 00 00 00 161 00 00 00 00 00 00 00 1a 162 Payload: 163 9b 00 6b de 00 00 00 00 164 Pseudoheader: 165 fe 80 00 00 00 00 00 00 02 1c da ff fe 00 20 24 166 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 1a 167 00 00 00 08 00 00 00 3a 168 copy: 04 9b 00 6b de 169 4 nulls: 82 170 Compressed: 171 04 9b 00 6b de 82 172 Was 8 bytes; compressed to 6 bytes, compression factor 1.33 174 Figure 1: A simple RPL example 176 Figure 2 shows a longer RPL control message that is improved a bit 177 more (but would likely benefit additionally from a context 178 reference). Note that the compressed output exposes an inefficiency 179 in the simple-minded compressor used to generate it; this does not 180 devalue the example since constrained nodes are quite likely to make 181 use of simple-minded compressors. 183 IP header: 184 60 00 00 00 00 5c 3a ff fe 80 00 00 00 00 00 00 185 02 1c da ff fe 00 30 23 ff 02 00 00 00 00 00 00 186 00 00 00 00 00 00 00 1a 187 Payload: 188 9b 01 7a 5f 00 f0 01 00 88 00 00 00 20 02 0d b8 189 00 00 00 00 00 00 00 ff fe 00 fa ce 04 0e 00 14 190 09 ff 00 00 01 00 00 00 00 00 00 00 08 1e 80 20 191 ff ff ff ff ff ff ff ff 00 00 00 00 20 02 0d b8 192 00 00 00 00 00 00 00 ff fe 00 fa ce 03 0e 40 00 193 ff ff ff ff 20 02 0d b8 00 00 00 00 194 Pseudoheader: 195 fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 196 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 1a 197 00 00 00 5c 00 00 00 3a 198 copy: 09 9b 01 7a 5f 00 f0 01 00 88 199 3 nulls: 81 200 copy: 04 20 02 0d b8 201 7 nulls: 85 202 ref(52): ff fe 00 -> ref 101nssss 0 6/11nnnkkk 1 1: a6 c9 203 copy: 08 fa ce 04 0e 00 14 09 ff 204 2 nulls: 80 205 copy: 01 01 206 7 nulls: 85 207 copy: 06 08 1e 80 20 ff ff 208 ref(2): ff ff -> ref 11nnnkkk 0 0: c0 209 ref(4): ff ff ff ff -> ref 11nnnkkk 2 0: d0 210 4 nulls: 82 211 ref(48): 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 fa ce 212 -> ref 101nssss 1 4/11nnnkkk 6 0: b4 f0 213 copy: 03 03 0e 40 214 ref(9): 00 ff -> ref 11nnnkkk 0 7: c7 215 ref(28): ff ff ff -> ref 101nssss 0 3/11nnnkkk 1 1: a3 c9 216 ref(24): 20 02 0d b8 00 00 00 00 217 -> ref 101nssss 0 2/11nnnkkk 6 0: a2 f0 218 Compressed: 219 09 9b 01 7a 5f 00 f0 01 00 88 81 04 20 02 0d b8 220 85 a6 c9 08 fa ce 04 0e 00 14 09 ff 80 01 01 85 221 06 08 1e 80 20 ff ff c0 d0 82 b4 f0 03 03 0e 40 222 c7 a3 c9 a2 f0 223 Was 92 bytes; compressed to 53 bytes, compression factor 1.74 225 Figure 2: A longer RPL example 227 Figure 3 shows an the effect of compressing a simple ND neighbor 228 solicitation (again, no context-based compression). 230 IP header: 231 60 00 00 00 00 30 3a ff 20 02 0d b8 00 00 00 00 232 00 00 00 ff fe 00 3b d3 fe 80 00 00 00 00 00 00 233 02 1c da ff fe 00 30 23 234 Payload: 235 87 00 a7 68 00 00 00 00 fe 80 00 00 00 00 00 00 236 02 1c da ff fe 00 30 23 01 01 3b d3 00 00 00 00 237 1f 02 00 00 00 00 00 06 00 1c da ff fe 00 20 24 238 Pseudoheader: 239 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 3b d3 240 fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 241 00 00 00 30 00 00 00 3a 242 copy: 04 87 00 a7 68 243 4 nulls: 82 244 ref(32): fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 245 -> ref 101nssss 1 2/11nnnkkk 6 0: b2 f0 246 copy: 04 01 01 3b d3 247 4 nulls: 82 248 copy: 02 1f 02 249 5 nulls: 83 250 copy: 02 06 00 251 ref(24): 1c da ff fe 00 -> ref 101nssss 0 2/11nnnkkk 3 3: a2 db 252 copy: 02 20 24 253 Compressed: 254 04 87 00 a7 68 82 b2 f0 04 01 01 3b d3 82 02 1f 255 02 83 02 06 00 a2 db 02 20 24 256 Was 48 bytes; compressed to 26 bytes, compression factor 1.85 258 Figure 3: An ND neighbor solicitation 260 Figure 4 shows the compression of an ND neighbor advertisement. 262 IP header: 263 60 00 00 00 00 30 3a fe fe 80 00 00 00 00 00 00 264 02 1c da ff fe 00 30 23 20 02 0d b8 00 00 00 00 265 00 00 00 ff fe 00 3b d3 266 Payload: 267 88 00 26 6c c0 00 00 00 fe 80 00 00 00 00 00 00 268 02 1c da ff fe 00 30 23 02 01 fa ce 00 00 00 00 269 1f 02 00 00 00 00 00 06 00 1c da ff fe 00 20 24 270 Pseudoheader: 271 fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 272 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 3b d3 273 00 00 00 30 00 00 00 3a 274 copy: 05 88 00 26 6c c0 275 3 nulls: 81 276 ref(48): fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 277 -> ref 101nssss 1 4/11nnnkkk 6 0: b4 f0 278 copy: 04 02 01 fa ce 279 4 nulls: 82 280 copy: 02 1f 02 281 5 nulls: 83 282 copy: 02 06 00 283 ref(24): 1c da ff fe 00 -> ref 101nssss 0 2/11nnnkkk 3 3: a2 db 284 copy: 02 20 24 285 Compressed: 286 05 88 00 26 6c c0 81 b4 f0 04 02 01 fa ce 82 02 287 1f 02 83 02 06 00 a2 db 02 20 24 288 Was 48 bytes; compressed to 27 bytes, compression factor 1.78 290 Figure 4: An ND neighbor advertisement 292 Figure 5 shows the compression of an ND router solicitation. Note 293 that the relatively good compression is not caused by the many zero 294 bytes in the link-layer address of this particular capture (which are 295 unlikely to occur in practice): 7 of these 8 bytes are copied from 296 the pseudo header (the 8th byte cannot be copied as the universal/ 297 local bit needs to be inverted). 299 IP header: 300 60 00 00 00 00 18 3a ff fe 80 00 00 00 00 00 00 301 ae de 48 00 00 00 00 01 ff 02 00 00 00 00 00 00 302 00 00 00 00 00 00 00 02 303 Payload: 304 85 00 90 65 00 00 00 00 01 02 ac de 48 00 00 00 305 00 01 00 00 00 00 00 00 306 Pseudoheader: 307 fe 80 00 00 00 00 00 00 ae de 48 00 00 00 00 01 308 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 02 309 00 00 00 18 00 00 00 3a 310 copy: 04 85 00 90 65 311 ref(33): 00 00 00 00 01 -> ref 101nssss 0 3/11nnnkkk 3 4: a3 dc 312 copy: 02 02 ac 313 ref(42): de 48 00 00 00 00 01 314 -> ref 101nssss 0 4/11nnnkkk 5 3: a4 eb 315 6 nulls: 84 316 Compressed: 317 04 85 00 90 65 a3 dc 02 02 ac a4 eb 84 318 Was 24 bytes; compressed to 13 bytes, compression factor 1.85 320 Figure 5 322 Figure 6 shows the compression of an ND router advertisement. The 323 indefinite lifetime is compressed to four bytes by backreferencing; 324 this could be improved (at the cost of minor additional decompressor 325 complexity) by including some simple runlength mechanism. 327 IP header: 328 60 00 00 00 00 60 3a ff fe 80 00 00 00 00 00 00 329 10 34 00 ff fe 00 11 22 fe 80 00 00 00 00 00 00 330 ae de 48 00 00 00 00 01 331 Payload: 332 86 00 55 c9 40 00 0f a0 1c 5a 38 17 00 00 07 d0 333 01 01 11 22 00 00 00 00 03 04 40 40 ff ff ff ff 334 ff ff ff ff 00 00 00 00 20 02 0d b8 00 00 00 00 335 00 00 00 00 00 00 00 00 20 02 40 10 00 00 03 e8 336 20 02 0d b8 00 00 00 00 21 03 00 01 00 00 00 00 337 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 11 22 338 Pseudoheader: 339 fe 80 00 00 00 00 00 00 10 34 00 ff fe 00 11 22 340 fe 80 00 00 00 00 00 00 ae de 48 00 00 00 00 01 341 00 00 00 60 00 00 00 3a 342 copy: 0c 86 00 55 c9 40 00 0f a0 1c 5a 38 17 343 2 nulls: 80 344 copy: 06 07 d0 01 01 11 22 345 4 nulls: 82 346 copy: 06 03 04 40 40 ff ff 347 ref(2): ff ff -> ref 11nnnkkk 0 0: c0 348 ref(4): ff ff ff ff -> ref 11nnnkkk 2 0: d0 349 4 nulls: 82 350 copy: 04 20 02 0d b8 351 12 nulls: 8a 352 copy: 04 20 02 40 10 353 ref(38): 00 00 03 -> ref 101nssss 0 4/11nnnkkk 1 3: a4 cb 354 copy: 01 e8 355 ref(24): 20 02 0d b8 00 00 00 00 356 -> ref 101nssss 0 2/11nnnkkk 6 0: a2 f0 357 copy: 02 21 03 358 ref(84): 00 01 00 00 00 -> ref 101nssss 0 9/11nnnkkk 3 7: a9 df 359 ref(40): 00 20 02 0d b8 00 00 00 00 00 00 00 360 -> ref 101nssss 1 3/11nnnkkk 2 4: b3 d4 361 ref(120): ff fe 00 11 22 362 -> ref 101nssss 0 14/11nnnkkk 3 3: ae db 363 Compressed: 364 0c 86 00 55 c9 40 00 0f a0 1c 5a 38 17 80 06 07 365 d0 01 01 11 22 82 06 03 04 40 40 ff ff c0 d0 82 366 04 20 02 0d b8 8a 04 20 02 40 10 a4 cb 01 e8 a2 367 f0 02 21 03 a9 df b3 d4 ae db 368 Was 96 bytes; compressed to 58 bytes, compression factor 1.66 370 Figure 6: An ND router advertisement 372 4. Integrating 6LoWPAN-GHC into 6LoWPAN-HC 374 6LoWPAN-GHC is intended to plug in as an NHC format for 6LoWPAN-HC 375 [I-D.ietf-6lowpan-hc]. This section shows how this can be done 376 (without supplying the detailed normative text yet, although it could 377 be implemented from this page). 379 GHC is by definition generic and can be applied to different kinds of 380 packets. All the examples given above are for ICMPv6 packets; it is 381 trivial to define an NHC format for ICMPv6 based on GHC. 383 In addition it may be useful to include an NHC format for UDP, as 384 many headerlike payloads (e.g., DHCPv6) are carried in UDP. 385 [I-D.ietf-6lowpan-hc] already defines an NHC format for UDP 386 (11110CPP). What remains to be done is to define an analogous NHC 387 byte formatted, e.g. as shown in Figure 7, and simply reference the 388 existing specification, indicating that for 0b11010cpp NHC bytes, the 389 UDP payload is not supplied literally but compressed by 6LoWPAN-GHC. 391 0 1 2 3 4 5 6 7 392 +---+---+---+---+---+---+---+---+ 393 | 1 | 1 | 0 | 1 | 0 | C | P | 394 +---+---+---+---+---+---+---+---+ 396 Figure 7: A possible NHC byte for UDP GHC 398 To stay in the same general numbering space, we propose 0b11011111 as 399 the NHC byte for IPCMPv6 GHC. 401 4.1. Compressing extension headers 403 If the compression of specific extension headers is considered 404 desirable, this can be added in a similar way, e.g. as in Figure 8 405 (however, probably only EID 0 to 3 need to be assigned). As there is 406 no easy way to extract the length field from the GHC-encoded header 407 before decoding, this would make detecting the end of the extension 408 header somewhat complex. The easiest (and most efficient) approach 409 is to completely elide the length field (in the same way NHC already 410 elides the next header field in certain cases) and reconstruct it 411 only on decompression. Instead, the reserved bytecode 0b10010000 412 would be assigned as a stop marker. 414 0 1 2 3 4 5 6 7 415 +---+---+---+---+---+---+---+---+ 416 | 1 | 0 | 1 | 1 | EID |NH | 417 +---+---+---+---+---+---+---+---+ 419 Figure 8: A possible NHC byte for extension header GHC 421 5. IANA considerations 423 In the IANA registry for the LOWPAN_NHC header type, IANA would need 424 to add the assigments in Figure 9. 426 10110IIN: Extension header GHC*) [RFCthis] 427 11010CPP: UDP GHC [RFCthis] 428 11011111: ICMPv6 GHC [RFCthis] 430 Figure 9: IANA assignments for the NHC byte 432 *) if the functionality of Section 4.1 is made part of this document. 434 6. Acknowledgements 436 Colin O'Flynn has repeatedly insisted that some form of compression 437 for ICMPv6 and ND packets might be beneficial. He actually has his 438 own draft, [I-D.oflynn-6lowpan-icmphc], which compresses better, but 439 addresses basic ICMPv6/ND only and needs a much longer spec (around 440 17 pages of detailed spec, as compared to the single page here). 441 This motivated the author to try something simple, yet general. 443 The examples given are based on pcap files that Colin O'Flynn and 444 Owen Kirby provided. 446 7. Security Considerations 448 (To be worked out. Probably mostly about the need to avoid buffer 449 overflows and out-of-area references during decompression.) 451 8. References 453 8.1. Normative References 455 [I-D.ietf-6lowpan-hc] 456 Hui, J. and P. Thubert, "Compression Format for IPv6 457 Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-13 458 (work in progress), September 2010. 460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 461 Requirement Levels", BCP 14, RFC 2119, March 1997. 463 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 464 (IPv6) Specification", RFC 2460, December 1998. 466 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 467 "Transmission of IPv6 Packets over IEEE 802.15.4 468 Networks", RFC 4944, September 2007. 470 8.2. Informative References 472 [I-D.oflynn-6lowpan-icmphc] 473 O'Flynn, C., "ICMPv6/ND Compression for 6LoWPAN Networks", 474 draft-oflynn-6lowpan-icmphc-00 (work in progress), 475 July 2010. 477 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 478 version 1.3", RFC 1951, May 1996. 480 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 481 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 482 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 483 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 484 Compression (ROHC): Framework and four profiles: RTP, UDP, 485 ESP, and uncompressed", RFC 3095, July 2001. 487 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 488 Header Compression (ROHC) Framework", RFC 5795, 489 March 2010. 491 Author's Address 493 Carsten Bormann 494 Universitaet Bremen TZI 495 Postfach 330440 496 Bremen D-28359 497 Germany 499 Phone: +49-421-218-63921 500 Fax: +49-421-218-7000 501 Email: cabo@tzi.org