idnits 2.17.1 draft-ietf-rohc-udp-lite-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 961. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 939. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 945. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 9, 2004) is 7254 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: '4' is defined on line 721, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 734, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '6') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 1889 (ref. '8') (Obsoleted by RFC 3550) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Ghyslain Pelletier 3 INTERNET-DRAFT Ericsson AB 4 Expires: December 2004 5 June 9, 2004 7 RObust Header Compression (ROHC): 8 Profiles for UDP-Lite 9 11 Status of this memo 13 By submitting this Internet-Draft, I (we) certify that any applicable 14 patent or other IPR claims of which I am (we are) aware have been 15 disclosed, and any of which I (we) become aware will be disclosed, in 16 accordance with RFC 3668 (BCP 79). 18 By submitting this Internet-Draft, I (we) accept the provisions of 19 Section #3 of RFC 3667 (BCP 78). 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/lid-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This document is a submission of the IETF ROHC WG. Comments should be 37 directed to the ROHC WG mailing list, rohc@ietf.org. 39 Abstract 41 This document defines ROHC (Robust Header Compression) profiles for 42 compression of RTP/UDP-Lite/IP packets (Real-Time Transport Protocol, 43 User Datagram Protocol Lite, Internet Protocol) and UDP-Lite/IP. 44 These profiles are defined based on their differences with the 45 profiles for UDP specified in RFC 3095. 47 Table of Contents 49 1. Introduction.....................................................3 50 2. Terminology......................................................4 51 3. Background.......................................................4 52 3.1. Overview of the UDP-Lite Protocol...........................4 53 3.2. Expected Behaviours of UDP-Lite Flows.......................5 54 3.2.1. Per-packet behavior....................................5 55 3.2.2. Inter-packet behavior..................................5 56 3.2.3. Per-flow behavior......................................6 57 3.3. Header Field Classification.................................6 58 4. Rationale behind the Design of ROHC Profiles for UDP-Lite........7 59 4.1. Design Motivations..........................................7 60 4.2. ROHC Considerations.........................................7 61 5. ROHC Profiles for UDP-Lite.......................................7 62 5.1. Context Parameters..........................................8 63 5.2. Initialization..............................................9 64 5.2.1. Initialization of the UDP-Lite Header [1]..............9 65 5.2.2. Compressor and Decompressor Logic......................9 66 5.3. Packet Formats.............................................10 67 5.3.1. General Packet Format.................................10 68 5.3.2. Packet Type CCE: CCE(), CCE(ON) and CCE(OFF)..........11 69 5.3.2.1. Properties of CCE():.............................12 70 5.3.2.2. Properties of CCE(ON):...........................12 71 5.3.2.3. Properties of CCE(OFF):..........................12 72 5.4. Compressor Logic...........................................13 73 5.5. Decompressor Logic.........................................13 74 5.6. Additional Mode Transition Logic...........................13 75 5.7. The CONTEXT_MEMORY Feedback Option.........................13 76 5.8. Constant IP-ID.............................................14 77 6. Security Considerations.........................................15 78 7. IANA Considerations.............................................15 79 8. Acknowledgments.................................................15 80 9. Author's Address................................................15 81 10. References.....................................................16 82 10.1. Normative References......................................16 83 10.2. Informative References....................................16 84 Appendix A - Detailed Classification of Header Fields..............17 85 Appendix B - Detailed Format of the CCE Packet Type................20 87 1. Introduction 89 The ROHC WG has developed a header compression framework on top of 90 which various profiles can be defined for different protocol sets, or 91 for different compression strategies. Due to the demands of the 92 cellular industry for an efficient way of transporting voice over IP 93 over wireless, ROHC [2] has mainly focused on compression of 94 IP/UDP/RTP headers, which are generous in size, especially compared 95 to the payloads often carried by packets with these headers. 97 ROHC RTP has become a very efficient, robust and capable compression 98 scheme, able to compress the headers down to a total size of one 99 octet only. Also, transparency is guaranteed to an extremely high 100 extent, even when residual bit errors are present in compressed 101 headers delivered to the decompressor. 103 UDP-Lite [1] is a transport protocol similar to the UDP protocol [7]. 104 UDP-Lite is useful for applications that are designed with the 105 capability to tolerate errors in the payload and for which receiving 106 damaged data is better than dealing with the loss of entire packets. 107 This may be particularly suitable when packets are transported over 108 link technologies where data can be partially damaged, such as 109 wireless links. 111 Although both transport protocols are very similar, ROHC profiles 112 must be defined separately for robust compression of UDP-Lite headers 113 because UDP-Lite does not share the same protocol identifier with 114 UDP. Also, the UDP-Lite Checksum Coverage field does not share the 115 semantics of the corresponding UDP Length field and as a consequence 116 it cannot always be inferred anymore. 118 This document defines two ROHC profiles for efficient compression of 119 UDP-Lite headers. The objective of this document is to provide simple 120 modifications to the corresponding ROHC profiles for UDP specified in 121 RFC 3095 [2]. In addition, the ROHC profiles for UDP-Lite support 122 some of the mechanisms defined in the profile for compression of IP 123 headers [3] (ROHC IP-Only). This specification includes support for 124 compression of multiple IP headers and for compressing IP-ID fields 125 with constant behavior, as well as improved mode transition logic and 126 a feedback option for decompressors with limited memory resources. 128 2. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD, "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119 [1]. 134 ROHC RTP : RTP/UDP/IP profile 0x0001 defined in RFC 3095 [2]. 135 ROHC UDP : UDP/IP profile 0x0002 defined in RFC 3095 [2]. 136 ROHC UDP-Lite : UDP-Lite/IP profile defined in this document. 137 ROHC RTP/UDP-Lite: RTP/UDP-Lite/IP profile defined in this document. 139 3. Background 141 3.1. Overview of the UDP-Lite Protocol 143 UDP-Lite is a transport protocol defined as an independent variant of 144 the UDP transport protocol. UDP-Lite is very similar to UDP, and it 145 allows applications that can tolerate errors in the payload to use a 146 checksum with an optional partial coverage. This is particularly 147 useful with IPv6 [6], where the use of the transport-layer checksum 148 is mandatory. 150 UDP-Lite replaces the Length field of the UDP header with a Checksum 151 Coverage field. This field indicates the number of octets covered by 152 the 16-bit checksum, which is applied on a per-packet basis. The 153 coverage area always include the UDP-Lite header and may cover the 154 entire packet, in which case UDP-Lite becomes semantically identical 155 to UDP. UDP-Lite and UDP do not share the same protocol identifier. 157 The UDP-Lite header format: 159 0 15 16 31 160 +--------+--------+--------+--------+ 161 | Source | Destination | 162 | Port | Port | 163 +--------+--------+--------+--------+ 164 | Checksum | | 165 | Coverage | Checksum | 166 +--------+--------+--------+--------+ 167 | | 168 : Payload : 169 | | 170 +-----------------------------------+ 172 The UDP-Lite checksum, like the UDP checksum, is an end-to-end 173 mechanism against erroneous delivery of error sensitive data. 174 This checksum is mandatory with IPv6 [5] for both protocols. 175 However, as opposed to UDP, the UDP-Lite checksum may not be 176 transmitted as all zeroes and cannot be disabled for IPv4 [5]. 178 For UDP, in the case where the checksum is disabled (IPv4 only), the 179 Checksum field maintains a constant value and is normally not sent by 180 the header compression scheme. In the case where the UDP checksum is 181 enabled (mandatory for IPv6), such an unpredictable field cannot be 182 compressed and is sent uncompressed. The UDP Length field, however, 183 is always redundant and can be provided by the IP module. Header 184 compression schemes do not normally transmit any bits of information 185 for this field, as its value can be inferred from the link layer. 187 For UDP-Lite, the checksum also has unpredictable values and this 188 field must always be included as-is in the compressed header, for 189 both IPv4 and IPv6. Furthermore, as the UDP Length field is redefined 190 as the Checksum Coverage field by UDP-Lite, this leads to different 191 properties for this field from a header compression perspective. 193 The following summarizes the relationship between UDP and UDP-Lite: 195 - UDP-Lite and UDP have different protocol identifiers; 196 - The UDP-Lite checksum cannot be disabled for IPv4; 197 - UDP-Lite redefines the UDP Length field as the Checksum 198 Coverage field, with different semantics; 199 - UDP-Lite is semantically equivalent to UDP when the Checksum 200 Coverage field indicates the total length of the packet. 202 The next section provides a more detailed discussion of the behavior 203 of the Checksum Coverage field of UDP-Lite in relation to header 204 compression. 206 3.2. Expected Behaviours of UDP-Lite Flows 208 3.2.1. Per-packet behavior 210 As mentioned in the previous section, the checksum coverage value 211 is applied independently of other packets that may belong to the 212 same flow. Specifically, the value of the checksum coverage may 213 indicate that the UDP-Lite packet is either entirely covered by the 214 checksum, or covered up to some boundary less than the packet size 215 but including the UDP-Lite header. 217 3.2.2. Inter-packet behavior 219 In relation to each other, UDP-Lite packets may exhibit either one 220 of three possible change patterns, where within a sequence of 221 packets the value of the Checksum Coverage field is: 223 1. changing, while covering the entire packet; 224 2. unchanging, covering up to a fixed boundary within the packet; 225 3. changing, but does not follow any specific pattern. 227 The first pattern above corresponds to the semantics of UDP, when 228 the UDP checksum is enabled. For this case, the checksum coverage 229 field varies according to the packet length and may be inferred 230 from the IP header similarly as for the UDP Length field. 232 The second pattern corresponds to the case where the coverage is 233 the same from one packet to another within a particular sequence. 234 For this case, the Checksum Coverage field may be a static value 235 defined in the context and it does not need to be sent in the 236 compressed header. 238 For the third case, no useful change pattern can be identified from 239 packet to packet for the value of the checksum coverage field, and 240 it must be included in the compressed header. 242 3.2.3. Per-flow behavior 244 It can be expected that any one of the above change patterns for 245 sequences of packets may be predominant at any time during the 246 lifetime of the UDP-Lite flow. A flow that predominantly follows 247 the first two change patterns described above may provide 248 opportunities for compressing the Checksum Coverage field for most 249 of the packets. 251 3.3. Header Field Classification 253 In relation to the header field classification of RFC 3095 [2], the 254 first two patterns represent the case where the value of the 255 Checksum Coverage field behavior is fixed and may be either 256 INFERRED (pattern 1) or STATIC (pattern 2); pattern 3 is for the 257 case where the value varies unpredictably, the field is CHANGING 258 and the value must be sent along with every packet. 260 Additional information regarding the analysis of the behavior of 261 the UDP-Lite fields may be found in Appendix A. 263 4. Rationale behind the Design of ROHC Profiles for UDP-Lite 265 4.1. Design Motivations 267 Simplicity is a strong motivation for the design of the UDP-Lite 268 header compression profiles. The profiles defined for UDP-Lite should 269 entail only a few simple modifications to the corresponding profiles 270 defined for UDP in RFC 3095 [2]. In addition, it is desirable to 271 include some of the improvements found in the ROHC IP-Only profile 272 [3]. Finally, whenever UDP-Lite is used in a manner that is 273 semantically identical to UDP, the compression efficiency should be 274 similar. 276 4.2. ROHC Considerations 278 The simplest approach to the definition of ROHC profiles for UDP-Lite 279 is to treat the Checksum Coverage field as an irregular value, and to 280 send it uncompressed for every packet. This may be achieved simply by 281 adding the field to the definition of the general packet format [2]. 282 However, the compression efficiency would then always be less than 283 for UDP. 285 Some care should be given to achieve similar compression efficiency 286 for UDP-Lite as for UDP when the Checksum Coverage field behaves like 287 the UDP Length field. This requires the possibility to infer the 288 Checksum Coverage field when it is equal to the length of the packet. 289 This would otherwise put the UDP-Lite protocol at a disadvantage over 290 links where header compression is used, when its behavior is made 291 similar to the semantics of UDP. 293 A mechanism to detect the presence of the Checksum Coverage field in 294 compressed headers is thus needed. This is achieved by defining a new 295 packet type with the identifiers left unused in RFC 3095 [2]. 297 5. ROHC Profiles for UDP-Lite 299 This section defines two ROHC profiles: 301 - RTP/UDP-Lite/IP compression (profile 0x0007) 302 - UDP-Lite/IP compression (profile 0x0008) 304 These profiles build on the specifications found in RFC 3095 [2] with 305 as little modifications as possible. Unless explicitly stated 306 otherwise, the profiles defined herein follow the specifications of 307 ROHC UDP and ROHC RTP, respectively. 309 Note also that this document reuses the notation found in [2]. 311 5.1. Context Parameters 313 As described in [2], information about previous packets is maintained 314 in a context. This includes information describing the packet stream, 315 and compression parameters. While the UDP and UDP-Lite protocols 316 share many commonalities, the differences in semantics as described 317 earlier renders the following parameter inapplicable: 319 The parameter context(UDP Checksum) 321 The UDP-Lite checksum cannot be disabled, as opposed to UDP. The 322 parameter context(UDP Checksum) defined in [2] (section 5.7) is 323 therefore not used for compression of UDP-Lite. 325 In addition, the UDP-Lite checksum is always sent as-is in every 326 compressed packet. However, the Checksum Coverage field may not 327 always be sent in each compressed packet, and the following context 328 parameter is used to indicate whether or not the field is sent: 330 The parameter context(UDP-Lite Coverage Field Present) 332 Whether the UDP-Lite Checksum Coverage field is present or not in 333 the general packet format (see section 5.3.1) is controlled by the 334 value of the Coverage Field Present (CFP) flag in the context. 336 If context(CFP) is nonzero, the Checksum Coverage field is not 337 compressed and it is present within compressed packets. If 338 context(CFP) is zero, the Checksum Coverage field is compressed and 339 it is not sent. This is the case when the value of the Checksum 340 Coverage field follows a stable inter-packet change pattern; the 341 field has either a constant value or it has a value equal to the 342 packet length for most packets in a sequence (see section 3.2). 344 Finally, the following context parameter is needed to indicate 345 whether the field should be inferred or taken from a value previously 346 saved in the context: 348 The parameter context(UDP-Lite Coverage Field Inferred) 350 When the UDP-Lite Checksum Coverage field is not present in the 351 compressed header (CFP=0), whether it is inferred or not is 352 controlled by the value of the Coverage Field Inferred (CFI) flag 353 in the context. 355 If context(CFI) is nonzero, the Checksum Coverage field is inferred 356 from the packet length, similarly as for the UDP Length field in 357 ROHC RTP. If context(CFI) is zero, the Checksum Coverage field is 358 decompressed using context(UDP-Lite Checksum Coverage). Therefore, 359 when context(CFI) is updated to a nonzero value, the value of the 360 Checksum Coverage field stored in the context must also be updated. 362 5.2. Initialization 364 Unless stated otherwise, the mechanisms of ROHC RTP and ROHC UDP 365 found in [2] are used also for the ROHC RTP/UDP-Lite and the ROHC 366 UDP-Lite profiles, respectively. 368 In particular, the considerations of ROHC UDP regarding the UDP SN 369 taking the role of the RTP Sequence Number apply to ROHC UDP-Lite. 370 Also, the static context for ROHC UDP-Lite may be initialized by 371 reusing an existing context belonging to a stream compressed using 372 ROHC RTP/UDP-Lite (profile 0x0007), similarly as for ROHC UDP. 374 5.2.1. Initialization of the UDP-Lite Header [1] 376 The structure of the IR and IR-DYN packets and the initialization 377 procedures are the same as for the ROHC profiles for UDP [2], with 378 the exception of the dynamic part as specified for UDP. A 2-octet 379 field containing the checksum coverage is added before the Checksum 380 field. This affects the format of dynamic chains in both IR and IR- 381 DYN packets. 383 Dynamic part: 385 +---+---+---+---+---+---+---+---+ 386 / Checksum Coverage / 2 octets 387 +---+---+---+---+---+---+---+---+ 388 / Checksum / 2 octets 389 +---+---+---+---+---+---+---+---+ 391 CRC-DYNAMIC: Checksum Coverage field, Checksum field (octets 5-8). 393 CRC-STATIC: All other fields (octets 1-4). 395 5.2.2. Compressor and Decompressor Logic 397 The following logic must be used by both the compressor and the 398 decompressor for assigning values to the parameters context(CFP) and 399 context(CFI) during initialization: 401 Context(CFP) 403 During context initialization, the value of context(CFP) MUST be 404 set to a nonzero value if the Checksum Coverage field differs from 405 the length of the UDP-Lite packet, for any one IR or IR-DYN packet 406 sent (compressor) or received (decompressor); otherwise the value 407 MUST be set to zero. 409 Context(CFI) 411 During context initialization, the value of context(CFI) MUST be 412 set to a nonzero value if the Checksum Coverage field is equal to 413 the length of the UDP-Lite packet within an IR or an IR-DYN packet 414 sent (compressor) or received (decompressor); otherwise the value 415 MUST be set to zero. 417 5.3. Packet Formats 419 The general packet format as defined in RFC 3095 [2] is modified to 420 include an additional field for the UDP-Lite checksum coverage. A 421 packet type is also defined to handle the specific semantics and 422 characteristics of this field. 424 5.3.1. General Packet Format 426 The general packet format of a compressed ROHC UDP-Lite header is 427 similar to the compressed ROHC RTP header ([2], section 5.7), with 428 modifications to the Checksum field, as well as additional fields for 429 handling multiple IP headers and for the UDP-Lite checksum coverage: 431 --- --- --- --- --- --- --- --- 432 : List of : variable, given by static chain 433 / dynamic chains / (does not include SN) 434 : for additional IP headers : see also [3], section 3.2. 435 --- --- --- --- --- --- --- --- 436 : : 2 octets, 437 + UDP-Lite Checksum Coverage + if context(CFP) = 1 or 438 : : if packet type = CCE (see 5.3.2) 439 --- --- --- --- --- --- --- --- 440 : : 441 + UDP-Lite Checksum + 2 octets 442 : : 443 --- --- --- --- --- --- --- --- 445 The list of dynamic header chains carries the dynamic header part for 446 each IP header in excess of the initial two, if any (as indicated by 447 the presence of corresponding header parts in the static chain). Note 448 that there is no sequence number at the end of the chain, as SN is 449 present within compressed base headers. 451 The order of the fields following the optional extension of the 452 general ROHC packet format is the same as the order between the 453 fields in the uncompressed header. 455 When calculating the CRC, the Checksum Coverage field is CRC-DYNAMIC. 457 5.3.2. Packet Type CCE: CCE(), CCE(ON) and CCE(OFF) 459 The ROHC profiles for UDP-Lite defines a packet type to handle the 460 various possible change patterns of the checksum coverage. This 461 packet type may be used to manipulate the context values that control 462 the presence of the Checksum Coverage field within the general packet 463 format, i.e. context(CFP), and how the field is decompressed, i.e. 464 context(CFI). The 2-octet Checksum Coverage field is always present 465 within the format of this packet (see section 5.3.1). 467 This type of packet is named Checksum Coverage Extension, or CCE, and 468 its updating properties depend on the final two bits of the packet 469 type octet (see format below). A naming scheme of the form 470 CCE() is used to uniquely identify the properties of a 471 particular CCE packet. 473 Although this packet type defines its own format, it may be 474 considered as an extension mechanism for packets of type 2, 1 or 0 475 [2]. This is achieved by substitution of the packet type identifier 476 of the first octet of the base header (the "outer" identifier) with 477 one of the unused packet types from RFC 3095 [2]. The substituted 478 identifier is then moved to the first octet of the remainder of the 479 base header (the "inner" identifier). 481 The format of the ROHC UDP-Lite CCE packet type: 483 0 1 2 3 4 5 6 7 484 +---+---+---+---+---+---+---+---+ 485 | 1 1 1 1 1 0 F | K | Outer packet type identifier 486 +===+===+===+===+===+===+===+===+ 487 : : (with inner type identifier) 488 / Inner Base header / variable number of bits, given by 489 : : the inner packet type identifier 490 +---+---+---+---+---+---+---+---+ 492 F,K: F,K = 00 is reserved at framework level (IR-DYN); 493 F,K = 01 indicates CCE(); 494 F,K = 10 indicates CCE(ON); 495 F,K = 11 indicates CCE(OFF). 497 Updating properties: The updating properties of the inner packet 498 type carried within any of the CCE packets are always 499 maintained. CCE(ON) and CCE(OFF) MUST NOT be used to extend 500 R-0 and R-1* headers. In addition, CCE(ON) always update 501 context(CFP); CCE(OFF) always update context(CFP), 502 context(CFI) and context(UDP-Lite Checksum Coverage). 504 Appendix B provides an expanded view of the resulting format of the 505 CCE packet type. 507 5.3.2.1. Properties of CCE(): 509 Aside from the updating properties of the inner packet type carried 510 within CCE(), this packet does not update any other context values. 511 CCE() thus is mode-agnostic, e.g. it can extend any of packet types 512 2, 1 and 0, regardless of the current mode of operation [2]. 514 CCE() may be used when the checksum coverage deviates from the 515 change pattern assumed by the compressor, where the field could 516 previously be compressed. This packet is useful if the occurrence 517 of such deviations is rare. 519 5.3.2.2. Properties of CCE(ON): 521 In addition to the updating properties of the inner packet type, 522 CCE(ON) updates context(CFP) to a nonzero value, i.e. it 523 effectively turns on the presence of the Checksum Coverage field 524 within the general packet format. This is useful when the 525 predominant change pattern of the checksum coverage preclude its 526 compression. 528 CCE(ON) can extend any of the context updating packets of type 2, 1 529 and 0, that is packets with a compressed header containing a CRC 530 [2]. Specifically, R-0 and R-1* headers MUST NOT be extended using 531 CCE(ON). 533 5.3.2.3. Properties of CCE(OFF): 535 In addition to the updating properties of the inner packet type, 536 CCE(OFF) updates context(CFP) to a value of zero, i.e. it 537 effectively turns off the presence of the Checksum Coverage field 538 within the general packet format. This is useful when the change 539 pattern of the checksum coverage seldom deviates from the pattern 540 assumed by the compressor. 542 CCE(OFF) also updates context(CFI) to a nonzero value, if 543 field(UDP-Lite Checksum Coverage) is equal to the packet length; 544 otherwise it must be set to zero. Note that when updating 545 context(CFI) using packet type CCE(OFF), a match of field(Checksum 546 Coverage) with the packet length always has precedence over a match 547 with context(Checksum Coverage). Finally, context(UDP-Lite Checksum 548 Coverage) is also updated by CCE(OFF). 550 Similarly to CCE(ON), CCE(OFF) can extend any of the context 551 updating packets of type 2, 1 and 0 [2]. 553 5.4. Compressor Logic 555 Should hdr(UDP-Lite Checksum Coverage) be different from context(UDP- 556 Lite Checksum Coverage) and different from the packet length when 557 context(CFP) is zero, the Checksum Coverage field cannot be 558 compressed. In addition, should hdr(UDP-Lite Checksum Coverage) be 559 different from the packet length when context(CFP) is zero and 560 context(CFI) is nonzero, the Checksum Coverage field cannot be 561 compressed either. For both cases, the field must be sent 562 uncompressed using a CCE packet or the context must be reinitialized 563 using an IR packet. 565 5.5. Decompressor Logic 567 For packet types other than IR, IR-DYN and CCE that are received when 568 the value of context(CFP) is zero, the Checksum Coverage field must 569 be decompressed using the value stored in the context if the value of 570 context(CFI) is zero; otherwise the field is inferred from the length 571 of the UDP-Lite packet derived from the IP module. 573 5.6. Additional Mode Transition Logic 575 The profiles defined in this document allow the compressor to decline 576 a mode transition requested by the decompressor. This is achieved by 577 redefining the Mode parameter for the value mode = 0 (in packet types 578 UOR-2, IR and IR-DYN) as follow (see also [3], section 3.4): 580 Mode: Compression mode. 0 = (C)ancel Mode Transition 582 Upon receiving the Mode parameter set to '0', the decompressor MUST 583 stay in its current mode of operation and SHOULD refrain from sending 584 further mode transition requests for the declined mode for a certain 585 amount of time. 587 5.7. The CONTEXT_MEMORY Feedback Option 589 This feedback option informs the compressor that the decompressor 590 does not have sufficient memory resources to handle the context of 591 the packet stream required by the current compressed structure. 593 0 1 2 3 4 5 6 7 594 +---+---+---+---+---+---+---+---+ 595 | Opt Type = 9 | Opt Len = 0 | 596 +---+---+---+---+---+---+---+---+ 598 When receiving a CONTEXT_MEMORY option, the compressor SHOULD take 599 actions to compress the packet stream in a way that requires less 600 decompressor memory resources, or stop compressing the packet stream. 602 5.8. Constant IP-ID 604 The profiles for UDP-Lite support compression of the IP-ID field with 605 constant behavior with the addition of the Static IP Identifier (SID) 606 flag within the dynamic part of the chain used to initialize the IPv4 607 header, as follow (see also [3], section 3.3): 609 Dynamic part: 611 +---+---+---+---+---+---+---+---+ 612 | Type of Service | 613 +---+---+---+---+---+---+---+---+ 614 | Time to Live | 615 +---+---+---+---+---+---+---+---+ 616 / Identification / 2 octets 617 +---+---+---+---+---+---+---+---+ 618 | DF|RND|NBO|SID| 0 | 619 +---+---+---+---+---+---+---+---+ 620 / Generic extension header list / variable length 621 +---+---+---+---+---+---+---+---+ 623 SID: Static IP Identifier. 625 For IR and IR-DYN packets: 627 For IR and IR-DYN packets, the logic is the same as for the 628 respective ROHC profiles for UDP, with the addition that 629 field(SID) must be kept in the context. 631 For compressed headers other than IR and IR-DYN: 633 If value(RND) = 0 and context(SID) = 0, hdr(IP-ID) is 634 compressed using Offset IP-ID encoding (see [2], section 635 4.5.5) using p = 0 and default-slope(IP-ID offset) = 0. 637 If value(RND) = 0 and context(SID) = 1, hdr(IP-ID) is constant 638 and compressed away; hdr(IP-ID) is the value of context(IP-ID). 640 If value(RND) = 1, IP-ID is the uncompressed hdr(IP-ID). IP-ID 641 is then passed as additional octets at the end of the 642 compressed header, after any extensions. 644 Note: Only IR and IR-DYN packets can update context(SID). 646 Note: All other fields are the same as for the respective ROHC 647 profiles for UDP [2]. 649 6. Security Considerations 651 The security considerations of RFC 3095 [2] apply integrally to this 652 document without modifications. 654 7. IANA Considerations 656 ROHC profile identifiers 0x0007 (ROHC RTP/UDP-Lite) and 0x0008 (ROHC 657 UDP-Lite) have been reserved by the IANA for the profiles defined in 658 this document. 660 { NOTE TO IANA - TO BE REMOVED BEFORE PUBLICATION } 662 Two ROHC profile identifiers must be reserved by the IANA for the 663 profiles defined in this document. Since profile number 0x0006 is 664 being saved for the TCP/IP (ROHC-TCP) profile, profile numbers 665 0x0007 and 0x0008 are the most suitable unused identifiers 666 available, and should thus be used. As for previous ROHC profiles, 667 profile numbers 0xnn07 and 0xnn08 must also be reserved for future 668 variants of these profiles. The registration suggested for the 669 "RObust Header Compression (ROHC) Profile Identifiers" name space: 671 OLD: 0x0006-0xnn7F To be Assigned by IANA 673 NEW: 0xnn06 To be Assigned by IANA 674 0x0007 ROHC RTP/UDP-Lite [RFCXXXX (this)] 675 0xnn07 Reserved 676 0x0008 ROHC UDP-Lite [RFCXXXX (this)] 677 0xnn08 Reserved 678 0x0009-0xnn7F To be Assigned by IANA 680 { END OF NOTE } 682 8. Acknowledgments 684 The author would like to thank Lars-Erik Jonsson, Kristofer Sandlund, 685 Mark West, Richard Price, Gorry Fairhurst, Fredrik Linstroem and Mats 686 Nordberg for useful reviews and discussions around this document. 688 9. Author's Address 690 Ghyslain Pelletier 691 Ericsson AB 692 Box 920 693 SE-971 28 Lulea, Sweden 694 Phone: +46 920 20 24 32 695 Fax : +46 920 20 20 99 696 Email: ghyslain.pelletier@ericsson.com 698 10. References 700 10.1. Normative References 702 [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement 703 Levels", RFC 2119, March 1997. 705 [2] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 706 Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K., Liu, 707 Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., 708 Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): 709 Framework and four profiles: RTP, UDP, ESP, and uncompressed", 710 RFC 3095, July 2001. 712 <# Editor's Note: RFC number to be updated before publication #> 713 <# for #> 715 [3] Jonsson, L. and G. Pelletier, "RObust Header Compression (ROHC): 716 A compression profile for IP", RFCZZZZ, %Month% 2004. 718 <# Editor's Note: RFC number to be updated before publication #> 719 <# for #> 721 [4] Larzon, L., Degermark, M., Pink, S., Jonsson, L. and G. 722 Fairhurst, "The UDP-Lite Protocol", RFCUUUU, %Month% 2004. 724 10.2. Informative References 726 [5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 728 [6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 729 Specification", RFC 2460, December 1998. 731 [7] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 732 1980. 734 [8] Schulzrinne, H., Casner S., Frederick, R. and V. Jacobson, "RTP: 735 A Transport Protocol for Real-Time Applications", RFC 1889, 736 January 1996. 738 Appendix A - Detailed Classification of Header Fields 740 This section summarizes the difference from the classification found 741 in the corresponding appendix in RFC 3095 [2], and similarly provides 742 conclusions about how the various header fields should be handled by 743 the header compression scheme to optimize compression and 744 functionality. These conclusions are separated based on the behavior 745 of the UDP-Lite Checksum Coverage field and uses the expected change 746 patterns described in section 3.2 of this document. 748 A.1. UDP-Lite Header Fields 750 The following table summarizes a possible classification for the UDP- 751 Lite header fields in comparison with the classification for UDP, 752 using the same classes as in RFC 3095 [2]. 754 Header fields of UDP-Lite and UDP: 756 +-------------------+-------------+ 757 | UDP-Lite | UDP | 758 +-------------------+--------+-------------------+-------------+ 759 | Header | Size | Class | Class | 760 | Field | (bits) | | | 761 +-------------------+--------+-------------------+-------------+ 762 | Source Port | 16 | STATIC-DEF | STATIC-DEF | 763 | Destination Port | 16 | STATIC-DEF | STATIC-DEF | 764 | Checksum Coverage | 16 | INFERRED | | 765 | | | STATIC | | 766 | | | CHANGING | | 767 | Length | 16 | | INFERRED | 768 | Checksum | 16 | CHANGING | CHANGING | 769 +-------------------+--------+-------------------+-------------+ 771 Source and Destination Port 773 Same as for UDP. Specifically, these fields are part of the 774 definition of a stream and must thus be constant for all packets in 775 the stream. The fields are therefore classified as STATIC-DEF. 777 Checksum Coverage 779 This field specifies which part of the UDP-Lite datagram is covered 780 by the checksum. It may have a value of zero or equal to the 781 datagram length if the checksum covers the entire datagram, or it 782 may have any value between eight octets and the length of the 783 datagram to specify the number of octets protected by the checksum, 784 calculated from the first octet of the UDP-Lite header. The value 785 of this field may vary for each packet, and this makes the value 786 unpredictable from a header compression perspective. 788 Checksum 790 The information used for the calculation of the UDP-Lite checksum 791 is governed by the value of the checksum coverage, and minimally 792 includes the UDP-Lite header. The checksum is a changing field that 793 must always be sent as-is. 795 The total size of the fields in each class, for each expected change 796 patterns (see section 3.2), is summarized in the tables below: 798 Pattern 1: 799 +------------+---------------+ 800 | Class | Size (octets) | 801 +------------+---------------+ 802 | INFERRED | 2 | Checksum Coverage 803 | STATIC-DEF | 4 | Source Port / Destination Port 804 | CHANGING | 2 | Checksum 805 +------------+---------------+ 807 Pattern 2: 808 +------------+---------------+ 809 | Class | Size (octets) | 810 +------------+---------------+ 811 | STATIC-DEF | 4 | Source Port / Destination Port 812 | STATIC | 2 | Checksum Coverage 813 | CHANGING | 2 | Checksum 814 +------------+---------------+ 816 Pattern 3: 817 +------------+---------------+ 818 | Class | Size (octets) | 819 +------------+---------------+ 820 | STATIC-DEF | 4 | Source Port / Destination Port 821 | CHANGING | 4 | Checksum Coverage / Checksum 822 +------------+---------------+ 824 A.2. Header Compression Strategies for UDP-Lite 826 The following table revisits the corresponding table (table A.1) for 827 UDP from [2] (section A.2), and classifies the changing fields based 828 on the change patterns previously identified in section 3.2. 830 Header compression strategies for UDP-Lite: 831 +----------+---------+-------------+-----------+-----------+ 832 | Field | Pattern | Value/Delta | Class | Knowledge | 833 +==========+=========+=============+===========+===========+ 834 | | #1 | Value | CHANGING | INFERRED | 835 | Checksum |---------+-------------+-----------+-----------+ 836 | Coverage | #2 | Value | RC | UNKNOWN | 837 | |---------+-------------+-----------+-----------+ 838 | | #3 | Value | IRREGULAR | UNKNOWN | 839 +----------+---------+-------------+-----------+-----------+ 840 | Checksum | All | Value | IRREGULAR | UNKNOWN | 841 +----------+---------+-------------+-----------+-----------+ 843 A.2.1. Transmit initially, but be prepared to update 845 UDP-Lite Checksum Coverage (Patterns #1 and #2) 847 A.2.2. Transmit as-is in all packets 849 UDP-Lite Checksum 850 UDP-Lite Checksum Coverage (Pattern #3) 852 Appendix B - Detailed Format of the CCE Packet Type 854 This section provides an expanded view of the format of the CCE 855 packet, based on the general ROHC RTP compressed header [2] and the 856 general format of a compressed header of the ROHC IP-Only profile 857 [3]. The modifications necessary to carry the base header of a packet 858 of type 2, 1 or 0 [2] within the CCE packet format along with the 859 additional fields to properly handle compression of multiple IP 860 headers results in the following structure for the CCE packet type: 862 0 1 2 3 4 5 6 7 863 --- --- --- --- --- --- --- --- 864 : Add-CID octet : if for small CIDs and CID 1-15 865 +---+---+---+---+---+---+---+---+ 866 | 1 1 1 1 1 0 F | K | Outer packet type identifier 867 +---+---+---+---+---+---+---+---+ 868 : : 869 / 0, 1, or 2 octets of CID / 1-2 octets if large CIDs 870 : : 871 +---+---+---+---+---+---+---+---+ 872 | First octet of base header | (with "inner" type indication) 873 +---+---+---+---+---+---+---+---+ 874 / Remainder of base header / variable number of bits 875 +---+---+---+---+---+---+---+---+ 876 : : 877 / Extension / See RFC 3095 [2], section 5.7. 878 : : 879 --- --- --- --- --- --- --- --- 880 : : 881 + IP-ID of outer IPv4 header + See RFC 3095 [2], section 5.7. 882 : : 883 --- --- --- --- --- --- --- --- 884 / AH data for outer list / See RFC 3095 [2], section 5.7. 885 --- --- --- --- --- --- --- --- 886 : : 887 + GRE checksum + See RFC 3095 [2], section 5.7. 888 : : 889 --- --- --- --- --- --- --- --- 890 : : 891 + IP-ID of inner IPv4 header + See RFC 3095 [2], section 5.7. 892 : : 893 --- --- --- --- --- --- --- --- 894 / AH data for inner list / See RFC 3095 [2], section 5.7. 895 --- --- --- --- --- --- --- --- 896 : : 897 + GRE checksum + See RFC 3095 [2], section 5.7. 898 : : 899 --- --- --- --- --- --- --- --- 900 : List of : Variable, given by static chain 901 / dynamic chains / (includes no SN) 902 : for additional IP headers : See [3], section 3.2. 904 --- --- --- --- --- --- --- --- 905 : : 906 + UDP-Lite Checksum Coverage + 2 octets 907 : : 908 +---+---+---+---+---+---+---+---+ 909 : : 910 + UDP-Lite Checksum + 2 octets 911 : : 912 +---+---+---+---+---+---+---+---+ 914 F,K: F,K = 00 is reserved at framework level (IR-DYN); 915 F,K = 01 indicates CCE(); 916 F,K = 10 indicates CCE(ON); 917 F,K = 11 indicates CCE(OFF). 919 Note that this document does not define (F,K) = 00, as this would 920 collide with the IR-DYN packet type already reserved at the ROHC 921 framework level. 923 Intellectual Property Statement 925 The IETF takes no position regarding the validity or scope of any 926 Intellectual Property Rights or other rights that might be claimed to 927 pertain to the implementation or use of the technology described in 928 this document or the extent to which any license under such rights 929 might or might not be available; nor does it represent that it has 930 made any independent effort to identify any such rights. Information 931 on the IETF's procedures with respect to rights in IETF Documents can 932 be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79). 934 Copies of IPR disclosures made to the IETF Secretariat and any 935 assurances of licenses to be made available, or the result of an 936 attempt made to obtain a general license or permission for the use of 937 such proprietary rights by implementers or users of this 938 specification can be obtained from the IETF on-line IPR repository at 939 http://www.ietf.org/ipr. 941 The IETF invites any interested party to bring to its attention any 942 copyrights, patents or patent applications, or other proprietary 943 rights that may cover technology that may be required to implement 944 this standard. Please address the information to the IETF at ietf- 945 ipr@ietf.org. 947 Copyright Statement 949 Copyright (C) The Internet Society (2004). This document is subject 950 to the rights, licenses and restrictions contained in BCP 78, and 951 except as set forth therein, the authors retain all their rights. 953 Disclaimer of Validity 955 This document and the information contained herein are provided on an 956 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 957 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 958 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 959 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 960 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 961 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 963 This Internet-Draft expires December 9, 2004.