idnits 2.17.1 draft-ietf-rohc-rtp-rocco-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 == The page length should not exceed 58 lines per page, but there was 66 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 67 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 448 has weird spacing: '...ntially the u...' -- 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 15, 2000) is 8716 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: 'CJHC' is mentioned on line 2301, but not defined == Unused Reference: 'HDLC' is defined on line 2343, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 1889 (ref. 'RTP') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 2509 (ref. 'PPPHC') (Obsoleted by RFC 3544) -- Possible downref: Non-RFC (?) normative reference: ref. 'CRTPC' -- Possible downref: Non-RFC (?) normative reference: ref. 'CELL' -- Possible downref: Non-RFC (?) normative reference: ref. 'ROVID' -- Possible downref: Non-RFC (?) normative reference: ref. 'PERF' -- Possible downref: Non-RFC (?) normative reference: ref. 'LLG' -- Possible downref: Non-RFC (?) normative reference: ref. 'WCDMA' Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Lars-Erik Jonsson, Ericsson 3 INTERNET-DRAFT Mikael Degermark, Lulea University 4 Expires: December 2000 Hans Hannu, Ericsson 5 Krister Svanbro, Ericsson 6 Sweden 7 June 15, 2000 9 RObust Checksum-based header COmpression (ROCCO) 10 12 ROCCO Version: 06 14 Status of this memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/lid-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This document is a submission of the IETF ROHC WG. Comments should be 35 directed to its mailing list, rohc@cdt.luth.se. 37 Abstract 39 Existing header compression schemes do not work well when used over 40 links with significant error rates, especially when the round-trip 41 time of the link is long. For many bandwidth limited links where 42 header compression is essential, such characteristics are common. 44 A header compression framework and a highly robust and efficient 45 header compression scheme is introduced in this document, adaptable 46 to the characteristics of the link over which it is used and also to 47 the properties of the packet streams it compresses. 49 Table of contents 51 1. Introduction..................................................5 52 2. Terminology...................................................7 53 3. Background...................................................10 54 3.1. Header compression fundamentals.......................10 55 3.2. Existing header compression schemes...................10 56 3.3. Requirements on a new header compression scheme.......12 57 3.4. Classification of header fields.......................12 58 4. Header compression framework.................................13 59 4.1. General ROCCO principles..............................14 60 4.2. Data structures.......................................14 61 4.3. Header compression profiles...........................15 62 4.4. Profile negotiation...................................16 63 4.5. Link layer requirements...............................16 64 5. Header compression profiles optimized for voice traffic......17 65 5.1. Usage scenarios, environment and requirements.........17 66 5.2. Profile definitions...................................17 67 5.2.1. List of defined profiles.....................17 68 5.2.2. Additional common profile characteristics....20 69 5.3. Encoding methods used.................................21 70 5.3.1. Least Significant Bits (LSB) encoding........21 71 5.3.2. Least Significant Part (LSP) encoding........21 72 5.3.3. LSB or LSB encoding with extended range......22 73 5.4. Packet formats........................................23 74 5.4.1. Static information packets, initialization...24 75 5.4.2. Dynamic information packets..................25 76 5.4.3. Compressed packets...........................28 77 5.4.4. Extensions to compressed headers.............30 78 5.4.5. Feedback packets.............................35 79 5.5. Encoding of field values..............................37 80 5.5.1. LSP encoding of field values.................37 81 5.5.2. LSB encoding of field values.................37 82 5.5.3. Timer-based timestamp decompression..........38 83 5.6. Header compression CRCs, coverage and polynomials.....39 84 5.6.1. STATIC packet CRC............................39 85 5.6.2. DYNAMIC packet CRC...........................39 86 5.6.3. COMPRESSED packet CRCs.......................39 87 6. Implementation issues........................................40 88 6.1. Compressor and decompressor logic, use of feedback.....40 89 6.2. ROCCO over simplex links..............................40 90 6.2.1. Compression slow-start.......................41 91 6.2.2. Periodic refresh.............................41 92 6.2.3. Refresh recommendations......................42 93 6.2.4. Cost and robustness of refreshes.............42 94 6.2.5. Simplex link improvements....................43 95 6.3. Reverse decompression.................................43 96 6.4. Pre-verification of CRCs..............................44 97 6.5. Using "guesses" with LSB and LSP encoding.............45 99 7. Further work.................................................46 100 7.1. Compression of IPv6 extension headers.................46 101 7.2. Efficient compression of CSRC lists...................46 102 7.3. General, media independent profiles...................46 103 8. Implementation status........................................47 104 9 . Discussion and conclusions...................................47 105 10. Security considerations......................................48 106 11. Acknowledgements.............................................49 107 12. Intellectual property considerations.........................49 108 13. References...................................................50 109 14. Authors' addresses...........................................51 111 Appendix A. Detailed classification of header fields............52 112 A.1. General classification................................52 113 A.1.1. IPv6 header fields...........................53 114 A.1.2. IPv4 header fields...........................55 115 A.1.3. UDP header fields............................57 116 A.1.4. RTP header fields............................58 117 A.1.5. Summary for IP/UDP/RTP.......................59 118 A.2. Analysis of change patterns of header fields..........60 119 A.2.1. IPv4 Identification..........................62 120 A.2.2. IP Traffic-Class / Type-Of-Service...........63 121 A.2.3. IP Hop-Limit / Time-To-Live..................63 122 A.2.4. UDP Checksum.................................63 123 A.2.5. RTP CSRC Counter.............................63 124 A.2.6. RTP Marker...................................64 125 A.2.7. RTP Payload Type.............................64 126 A.2.8. RTP Sequence Number..........................64 127 A.2.9. RTP Timestamp................................64 128 A.2.10. RTP Contributing Sources (CSRC)..............64 129 A.3. Header compression strategies.........................65 130 A.3.1. Do not send at all...........................65 131 A.3.2. Transmit only initially......................65 132 A.3.3. Transmit initially, update occasionally......65 133 A.3.4. Be prepared to update or send as-is..........66 134 A.3.5. Guarantee continuous robustness..............66 135 A.3.6. Transmit as-is in all packets................66 136 A.3.7. Establish and be prepared to update delta....66 138 Document history 140 The original name of this internet draft was draft-jonsson-robust-hc. 141 Since it now has been submitted as a ROHC WG draft, the name has 142 changed and then also the numbering. However, the old draft version 143 numbering is kept as a version reference for the protocol and this 144 one should be referred to as ROCCO 06. 146 00 1999-06-22 First release. 148 01 1999-09-01 Only small corrections and modifications. Cut-and- 149 paste errors from the 00 draft removed. 151 02 1999-10-22 Generalized concept with a number of different 152 profiles. New chapters added describing profile 153 negotiation, implementation status and security. 155 03 2000-01-18 LSP encoding and one-octet profiles introduced. 156 Modified and simplified extension formats and 157 small changes in the CONTEXT_REQUEST packets. 159 04 2000-03-10 The CONTEXT_UPDATE packet has changed its name to 160 DYNAMIC while also being slightly modified. Both 161 the STATIC and the DYNAMIC packet now include a 162 header compression CRC of 8 bits to ensure 163 reliability of the scheme. Some profiles have been 164 modified, some renumbered, some removed and some 165 added. The CONTEXT_REQUEST packet has been replaced 166 by a more general FEEDBACK packet type with several 167 sub-types including three that leaves much room for 168 implementation features. The profile definitions 169 have been improved in many ways with more details 170 and clarifications. New chapters have been added 171 discussing implementation issues and possible 172 further work. 174 05 2000-05-24 New, additional compressed header formats have been 175 added, both for timer-based timestamp decompression 176 and for the cases without that functionality. The 177 extension formats have also been updated. Initial 178 chapters have been reorganized to get a better 179 structure. CID-field has been moved to the beginning 180 of each header. Minor changes have been applied to 181 various parts of the specification. 183 06 2000-06-15 Errors in the previous version have been corrected. 184 Since the ROHC group is now creating a final robust 185 header compression scheme, ROCCO has served its 186 purposes and will be terminated. This is therefore 187 the final ROCCO version. 189 1. Introduction 191 During the last five years, two communication technologies in 192 particular have become commonly used by the general public: cellular 193 telephony and the Internet. Cellular telephony has provided its users 194 with the revolutionary possibility of always being reachable with 195 reasonable service quality no matter where they are. However, until 196 now the main service provided has been speech. With the Internet, the 197 conditions have been almost the opposite. While flexibility for all 198 kinds of usage has been its strength, its focus has been on fixed 199 connections and large terminals, and the experienced quality of some 200 services (such as Internet telephony) has generally been low. 202 Today, IP telephony is gaining momentum thanks to improved technical 203 solutions. It seems reasonable to believe that in the years to come, 204 IP will become a commonly used way to carry telephony. Some future 205 cellular telephony links might also be based on IP and IP telephony. 206 Cellular phones may have IP stacks supporting not only audio and 207 video, but also web browsing, email, gaming, etc. 209 The scenario we are envisioning might then be the one in Figure 1.1, 210 where two mobile terminals are communicating with each other. Both 211 are connected to base stations over cellular links, and the base 212 stations are connected to each other through a wired (or possibly 213 wireless) network. Instead of two mobile terminals, there could of 214 course be one mobile and one wired terminal, but the case with two 215 cellular links is technically more demanding. 217 Mobile Base Base Mobile 218 Terminal Station Station Terminal 220 | ~ ~ ~ \ / \ / ~ ~ ~ ~ | 221 | | | | 222 +--+ | | +--+ 223 | | | | | | 224 | | | | | | 225 +--+ | | +--+ 226 | | 227 |=========================| 229 Cellular Wired Cellular 230 Link Network Link 232 Figure 1.1 : Scenario for IP telephony over cellular links 234 It is obvious that the wired network can be IP-based. With the 235 cellular links, the situation is less clear. IP could be terminated 236 in the fixed network, and special solutions implemented for each 237 supported service over the cellular link. However, this would limit 238 the flexibility of the services supported. If technically and 239 economically feasible, a solution with pure IP all the way from 240 terminal to terminal would have certain advantages. However, to make 241 IP-all-the-way a viable alternative, a number of problems have to be 242 addressed, especially regarding bandwidth efficiency. 244 For cellular phone systems, it is of vital importance to use the 245 scarce radio resources in an efficient way. A sufficient number of 246 users per cell is crucial, otherwise deployment costs will be 247 prohibitive [CELL]. The quality of the voice service should also be 248 as good as in today's cellular systems. It is likely that even with 249 support for new services, lower quality of the voice service is 250 acceptable only if costs are significantly reduced. 252 A problem with IP over cellular links when used for interactive voice 253 conversations is the large header overhead. Speech data for IP 254 telephony will most likely be carried by RTP [RTP]. A packet will 255 then, in addition to link layer framing, have an IP [IPv4] header (20 256 octets), a UDP [UDP] header (8 octets), and an RTP header (12 octets) 257 for a total of 40 octets. With IPv6 [IPv6], the IP header is 40 258 octets for a total of 60 octets. The size of the payload depends on 259 the speech coding and frame sizes used and may be as low as 15-20 260 octets. 262 From these numbers, the need for reducing header sizes for efficiency 263 reasons is obvious. However, cellular links have characteristics that 264 make header compression as defined in [IPHC,CRTP,PPPHC] perform less 265 than well. The most important characteristic is the lossy behavior of 266 cellular links, where a bit error rate (BER) as high as 1e-3 must be 267 accepted to keep the radio resources efficiently utilized [CELL]. In 268 severe operating situations, the BER can be as high as 1e-2. The 269 other problematic characteristic is the long round-trip time (RTT) of 270 the cellular link, which can be as high as 100-200 milliseconds 271 [CELL]. A viable header compression scheme for cellular links must be 272 able to handle loss on the link between the compression and 273 decompression point as well as loss before the compression point. 275 Bandwidth is the most costly resource in cellular links. Processing 276 power is very cheap in comparison. Implementation or computational 277 simplicity of a header compression scheme is therefore of less 278 importance than its compression ratio and robustness. 280 2. Terminology 282 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 283 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 284 document are to be interpreted as described in RFC 2119. 286 BER 288 Bit Error Rate. Cellular radio links have a rather high BER. In 289 this document BER is usually given as a frequency, but one also 290 needs to consider the error distribution as bit errors are not 291 independent. In our simulations we use a channel with a certain 292 BER, and the error distribution is according to a realistic channel 293 [WCDMA]. 295 Cellular links 297 Wireless links between mobile terminals and base stations. The BER 298 and the RTT are rather high in order to achieve an efficient system 299 overall. 301 Compression efficiency 303 The performance of a header compression scheme can be described 304 with three parameters, compression efficiency, robustness and 305 compression reliability. The compression efficiency is determined 306 by how much the header sizes are reduced by the compression scheme. 308 Compression reliability 310 The performance of a header compression scheme can be described 311 with three parameters, compression efficiency, robustness and 312 compression reliability. The compression reliability is a measure 313 for how well the scheme ensures that the decompressed headers are 314 not erroneous and the possibility to avoid error propagation from 315 the decompressor. 317 Context 319 The context is the state which the compressor uses to compress a 320 header and which the decompressor uses to decompress a header. The 321 context is basically the uncompressed version of the last header 322 sent (compressor) or received (decompressor) over the link, except 323 for fields in the header that are included "as-is" in compressed 324 headers or can be inferred from, e.g., the size of the link-level 325 frame. The context can also contain additional information 326 describing the packet stream, for example the typical inter-packet 327 increase in sequence numbers or timestamps. 329 Context damage 331 When the context of the decompressor is not consistent with the 332 context of the compressor, header decompression will fail. This 333 situation can occur when the context of the decompressor has not 334 been initialized properly or when packets have been lost or damaged 335 between compressor and decompressor. Packets which cannot be 336 decompressed due to inconsistent contexts are said to be lost due 337 to context damage. 339 Context repair mechanism 341 To avoid excessive context damage, a context repair mechanism is 342 needed. Context repair mechanisms can be based on explicit requests 343 for context updates, periodic updates sent by the compressor, or 344 methods for local repair at the decompressor side. 346 FER 348 Frame Error Rate. The FER considered in this document includes the 349 frames lost on the channel between compressor and decompressor and 350 frames lost due to context damage. FER is here defined to be 351 identical to packet loss rate. 353 Header compression profile 355 A header compression profile is a specification of how to compress 356 the headers of a certain kind of packet stream over a certain kind 357 of link. Compression profiles provide the details of the header 358 compression framework introduced in this document. The profile 359 concept makes use of profile identifiers to separate different 360 profiles which are used when setting up the compression scheme. All 361 variations and parameters of the header compression scheme are 362 handled by different profile identifiers, which makes the number of 363 profiles rather large. This can act as a deterrent when first 364 studying the concept, but is a real strength for several reasons. 365 One advantage of this merging of parameters into one is that new 366 parameters can be added by the endpoints without affecting the 367 negotiation requirements on the link in between. Another benefit of 368 the concept is that different combinations of functionality might 369 be implemented with different methods, meaning that the scheme can 370 be optimized regardless of what functionality is enabled. Finally, 371 it should be noted that even if there are a large number of 372 profiles, only a small number of them can/will be implemented over 373 a specific link (IPv4 and IPv6 profiles will for example probably 374 not coexist). Most profiles usable in a certain environment will 375 probably also be almost identical from an implementation point of 376 view. 378 Header compression CRC 380 A CRC (Cyclic Redundancy Checksum) computed by the compressor and 381 included in each compressed header. Its main purpose is to provide 382 a way for the decompressor to reliably verify the correctness of 383 reconstructed headers. What values the CRC is computed over depends 384 on the packet type it is included in; typically it covers most of 385 the original header fields. 387 Pre-HC links 389 Pre-HC links are all links before the header compression point. If 390 we consider a path with cellular links as first and last hops, the 391 Pre-HC links for the compressor at the last link are the first 392 cellular link plus the wired links in between. 394 Robustness 396 The performance of a header compression scheme can be described 397 with three parameters, compression efficiency, robustness and 398 compression reliability. A robust scheme tolerates errors on the 399 link over which header compression takes place without losing 400 additional packets, introducing additional errors, or using more 401 bandwidth. 403 RTT 405 Round Trip Time - The time it takes to send a packet back and forth 406 over the link. 408 Simplex link 410 A simplex (or unidirectional) link is a point to point link without 411 a return channel. Over simplex links, header compression must rely 412 on periodic refreshes since feedback from the decompressor can not 413 be sent to the compressor. For simplex links, a header compression 414 CRC is mandatory to guarantee correct decompression. 416 Spectrum efficiency 418 Radio resources are limited and expensive. Therefore they must be 419 used efficiently to make the system economically feasible. In 420 cellular systems this is achieved by maximizing the number of users 421 served within each cell, while the quality of the provided services 422 is kept at an acceptable level. A consequence of efficient spectrum 423 use is a high BER, even after channel coding with error correction. 425 Timestamp delta 427 The timestamp delta is the increase in the timestamp value between 428 two consecutive packets. 430 3. Background 432 This chapter provides a background to the subject of header 433 compression. The fundamental ideas are described together with 434 descriptions of existing header compression schemes, their drawbacks 435 and requirements and motivation for new header compression solutions. 437 3.1. Header compression fundamentals 439 The main reason why header compression can be done at all is the fact 440 that there are lots of redundancy between header fields, both within 441 the same packet header but especially between consecutive packets 442 belonging to the same packet stream. By sending static field 443 information only initially and utilize dependencies and 444 predictability's for other fields, the header size can be 445 significantly reduced for most packets. 447 In general, header compression methods maintain a context, which is 448 essentially the uncompressed version of the last header sent over 449 the link, at both compressor and decompressor. Compression and 450 decompression are done relative to the context. When compressed 451 headers carry differences from the previous header, each compressed 452 header will update the context of the decompressor. When a packet is 453 lost between compressor and decompressor, the context of the 454 decompressor will be brought out of sync since it is not updated 455 correctly. A header compression method must have a way to repair the 456 context, i.e. bring it into sync, after such events. 458 3.2. Existing header compression schemes 460 The original header compression scheme, CTCP [VJHC], was invented by 461 Van Jacobson. CTCP compressed the 40 octet IP+TCP header to 4 octets. 463 The CTCP compressor detects transport-level retransmissions and sends 464 a header that updates the context completely when they occur. This 465 repair mechanism does not require any explicit signaling between 466 compressor and decompressor. 468 CRTP [CRTP, IPHC] by Casner and Jacobson is a header compression 469 scheme that compresses 40 octets of IPv4/UDP/RTP headers to a minimum 470 of 2 octets when no UDP checksum is present. If the UDP checksum is 471 present, the minimum CRTP header is 4 octets. CRTP cannot use the 472 same repair mechanism as CTCP since UDP/RTP does not retransmit. 473 Instead, CRTP uses explicit signaling messages from decompressor to 474 compressor, called CONTEXT_STATE messages, to indicate that the 475 context is out of sync. The link roundtrip time will thus limit the 476 speed of this context repair mechanism. 478 On lossy links with long roundtrip times, such as most cellular 479 links, CRTP does not perform well. Each lost packet over the link 480 causes several subsequent packets to be lost since the context is out 481 of sync during at least one link roundtrip time. This behavior is 482 documented in [CRTPC]. For voice conversations such long loss events 483 will degrade the voice quality. Moreover, bandwidth is wasted by the 484 large headers sent by CRTP when updating the context. [CRTPC] found 485 that CRTP performed much worse than ideally for a lossy cellular 486 link. It is clear that CRTP alone is not a viable header compression 487 scheme for cellular links. 489 To avoid losing headers due to the context being out of sync, CRTP 490 decompressors can attempt to repair the context locally by using a 491 mechanism known as TWICE. Each CRTP packet contains a counter which 492 is incremented by one for each packet sent out by the CRTP 493 compressor. If the counter increases by more than one, at least one 494 packet was lost over the link. The decompressor then attempts to 495 repair the context by guessing how the lost packet(s) would have 496 updated it. The guess is then verified by decompressing the packet 497 and checking the UDP checksum - if it succeeds, the repair is deemed 498 successful and the packet can be forwarded or delivered. TWICE has 499 got its name from the observation that when the compressed packet 500 stream is regular, the correct guess is to apply the update in the 501 current packet twice. [CRTPC] found that even with TWICE, CRTP 502 doubled the number of lost packets. TWICE improves CRTP performance 503 significantly. However, there are several problems with using TWICE: 505 1) It becomes mandatory to use the UDP checksum: 507 - the minimal compressed header size increases by 100% to 4 508 octets. 510 - most speech codecs developed for cellular links tolerate errors 511 in the encoded data. Such codecs will not want to enable the UDP 512 checksum, since they want damaged packets to be delivered. 514 - errors in the payload will make the UDP checksum fail when the 515 guess is correct (and might make it succeed when it is wrong). 517 2) Loss in an RTP stream that occurs before the compression point 518 will make updates in CRTP headers less regular. Simple-minded 519 versions of TWICE will then perform badly. More sophisticated 520 versions would need more repair attempts to succeed. 522 3.3. Requirements on a new header compression scheme 524 The major problem with CRTP is that it is not sufficiently robust 525 against packets being damaged between compressor and decompressor. A 526 viable header compression scheme must be less fragile. This increased 527 robustness must be obtained without increasing the compressed header 528 size; a larger header would make IP telephony over cellular links 529 economically unattractive. 531 A major cause of the bad performance of CRTP over cellular links is 532 the long link roundtrip time, during which many packets are lost when 533 the context is out of sync. This problem can be attacked directly by 534 finding ways to reduce the link roundtrip time. Future generations of 535 cellular technologies may indeed achieve lower link roundtrip times. 536 However, these will probably always be rather high [CELL]. The 537 benefits in terms of lower loss and smaller bandwidth demands if the 538 context can be repaired locally will be present even if the link 539 roundtrip time is decreased. A reliable way to detect a successful 540 context repair is then needed. 542 One might argue that a better way to solve the problem is to improve 543 the cellular link so that packet loss is less likely to occur. It 544 would of course be nice if the links were almost error free, but such 545 a system would not be able to support a sufficiently large number of 546 users per cell and would thus be economically unfeasible [CELL]. 548 One might also argue that the speech codecs should be able to deal 549 with the kind of packet loss induced by CRTP, in particular since the 550 speech codecs probably must be able to deal with packet loss anyway 551 if the RTP stream crosses the Internet. While the latter is true, the 552 kind of loss induced by CRTP is difficult to deal with. It is usually 553 not possible to hide a loss event where well over 100 ms worth of 554 sound is completely lost. If such loss occurs frequently at both ends 555 of the path, the speech quality will suffer. 557 3.4. Classification of header fields 559 As mentioned earlier, header compression is possible due to the fact 560 that there are much redundancy between header field values within 561 packets, but especially between consecutive packets. To utilize these 562 properties for header compression, it is important to understand the 563 behavior of the various header fields. To do this, all header fields 564 have been classified in detail in appendix A. The fields are first 565 classified on a high level and then some of them are studied more in 566 detail. Finally, the appendix concludes with recommendations about 567 how the various fields should be handled by header compression 568 algorithms. The main conclusion that can be drawn is that most of the 569 header fields can easily be compressed away since they are never or 570 seldom changing. Only 5 fields with a total size of about 10 octets 571 are rather difficult to compress and must be handled in a 572 sophisticated way by the compression scheme. Those fields are: 574 - IPv4 Identification (16 bits) 575 - UDP Checksum (16 bits) 576 - RTP Marker (1 bit) 577 - RTP Sequence Number (16 bits) 578 - RTP Timestamp (32 bits) 580 It is rather obvious that these field then will have a large impact 581 on how a header compression scheme is designed. However, all details 582 about this should be found in Appendix A. 584 4. Header compression framework 586 A solution is proposed for efficient, robust and reliable header 587 compression, ROCCO. The scheme is heavily geared towards local repair 588 of the context in combination with robust encoding of header fields. 589 What is needed is a reliable way to detect when a repair attempt has 590 succeeded, plus possibly hints to the decompressor about how the 591 header fields have changed. 593 The key element of the proposed header compression scheme is that 594 compressed headers should carry a CRC computed over the header before 595 compression. This provides a reliable way to detect whether 596 decompression and context repair have succeeded. In addition to the 597 CRC, the header could contain codes and additional information as 598 needed for decompression. 600 A completely general solution cannot achieve compression rates high 601 enough to make IP telephony over cellular economically feasible. On 602 the other hand, the solution needs to be extendable so that other 603 kinds of packet streams can also be compressed well. Therefore, we 604 envision a scheme where the basic framework is supplemented with a 605 set of compression profiles, where each compression profile provides 606 the exact details on how a packet stream is to be compressed and 607 decompressed. The use of compression profiles allows the basic 608 framework to be adapted to the properties of packet streams as well 609 as various link properties. 611 The ROCCO header compression framework does not state any exact 612 details about how the compression is to be performed, what formats 613 the headers should have, etc. This is left to the compression 614 profiles to define. The framework instead describes general 615 principles for how to do header compression "the ROCCO way". The 616 header compression profile concept is presented describing what a 617 profile is, what to consider when designing a profile and what every 618 profile must or should define. The concept also exactly states the 619 rules regarding negotiation of compression profiles. 621 4.1. General ROCCO principles 623 ROCCO header compression is based on the principle of decompressor 624 context repair attempts relying on a header compression CRC included 625 in compressed headers. Profiles will define various packet types and 626 all of them do not have to carry a header compression CRC. In 627 general, if the CRC is present it is RECOMMENDED to calculate it over 628 the uncompressed header, but profiles MAY define the coverage 629 differently for some packet types. 631 Distinguishing packet streams and packet types is necessary, but some 632 of that information may be available from the underlying technology. 633 To avoid wasting precious header bits, it is left to the compression 634 profile to decide how to distinguish packet types and packet streams. 635 This allows efficient use of header bits overall. 637 If each packet stream has its own logical channel, it is not 638 necessary to have any additional information for distinguishing 639 between streams. Otherwise there MUST be slightly different profiles 640 defined with support for various numbers of concurrent packet 641 streams. 643 The link layer could carry explicit information about packet types, 644 but that would not lead to an efficient use of bits, since different 645 profiles could use different number of packet types. If the packet 646 type distinguishing mechanism is included in the header compression 647 profile instead, the profile could optimize the bit usage of that 648 mechanism to its own packet types. However, it is up to the profile 649 designer to choose if this mechanism is included in the profile or 650 required from the link layer. 652 A compression profile MAY define headers which do not have a 653 corresponding original packet. Such packets would be internal header 654 compression packets, and would not be delivered further from the 655 decompressor. An example would be to initially send non-changing 656 fields of a packet stream as a separate packet. Another example would 657 be to send packets to update the RTP timestamp field even when no RTP 658 packets arrive, in order to decrease the increment in the RTP 659 timestamp field when a packet does arrive. 661 The profiles defined in this document SHOULD be considered as 662 examples for how profiles are supposed to be defined and described. 664 4.2. Data structures 666 The compression scheme needs to maintain a context for compression 667 and decompression of a packet stream. The context must be kept 668 updated at both compressor and decompressor. The context is 669 essentially the header of the last packet transmitted, and includes 670 all static header fields plus some fields that change more or less 671 frequently. If the compression profile used is designed to handle a 672 certain amount of packet loss on the link, both compressor and 673 decompressor will typically keep information about earlier packets; 674 packets that arrived before the current packet. Finally, there may be 675 packet stream related information such as field deltas (e.g. RTP 676 timestamp) or a list of which CSRC items have occurred in the packet 677 stream. 679 4.3. Header compression profiles 681 The details on how a packet stream is to be compressed and 682 decompressed are determined by a compression profile. Over a link a 683 number of profiles can be active, either within the same or within 684 different logical channels. How to determine what profile to use for 685 a certain packet stream is not defined in this document, but the 686 usage MUST be negotiated between compressor and decompressor as 687 described in the subsequent chapter. 689 One way to select a suitable profile is to have a common channel over 690 which a general-purpose header compression profile is used. When the 691 packet stream characteristics are identified, it is switched to 692 another channel where a suitable compression profile is used. 694 Profiles can be defined to compress one packet stream only, in which 695 case the link layer must be able to separate packet streams. Profiles 696 can also be defined for compression of more than one packet stream, 697 in which case the profile must provide a way to distinguish between 698 the packet streams. 700 Important parameters to consider when designing a profile are: 702 - what kind of packet streams to compress (IPv6, IPv4, UDP, 703 UDP/RTP, TCP) and if UDP, whether the UDP checksum is supported. 705 - the rate and pattern of loss of the channel. 707 - the pattern of change of the changing fields. 709 - the expected rate and pattern of loss and reordering before the 710 compression point. 712 - if included in the profile, the number of concurrent packet 713 streams supported through context identifiers. 715 - what support there is from the link layer, such as the number of 716 packet streams supported, and if it can indicate packet types. 718 When these things have been considered, the specifics of the profile 719 can be determined. The profile MUST specify: 721 - the exact semantics of the various packet types and how the 722 desired functionality is supported. 724 - the size of, polynomials for, and what the Header Compression 725 CRC covers for all packet types. 727 - the information needed in the contexts for compression and 728 decompression, including history information and properties of 729 the packet stream. 731 - procedures for compression and decompression. 733 - how compression is initiated (which packets are used and how). 735 - description of context repair mechanisms. 737 Chapter 5 defines compression profiles optimized for conversational 738 voice traffic over cellular radio links. 740 4.4. Profile negotiation 742 To initiate ROCCO header compression, compressor and decompressor 743 must be able to negotiate which header compression profile to use. A 744 header compression profile is identified by a 16 bit profile 745 identifier, and underlying link layers MUST provide a way to 746 negotiate this. 748 4.5. Link layer requirements 750 This chapter lists general ROCCO requirements on an underlying link 751 layer. Profiles could also state additional requirements, but these 752 MUST be provided for ALL ROCCO profiles. See also [LLG]. 754 Framing 756 Framing, which makes it possible to separate different packets, is 757 the most important link layer functionality. 759 Length 761 Most link layers can indicate the length of the packet, and this 762 information has therefore been removed from the packet headers. 763 This means that it now MUST be given by the link layer. 765 Profile negotiation 767 In addition to the packet handling mechanisms above, the link 768 layer MUST also provide a way to carry on the negotiation of 769 header compression profiles, described in chapter 5.4. 771 5. Header compression profiles optimized for voice traffic 773 This section exemplifies how the framework outlined in chapter 4 774 could be instantiated by defining profiles optimized for header 775 compression of packet streams carrying voice data. A number of 776 profiles are defined providing support for both IPv6 and IPv4 in 777 combination with various functionality. 779 5.1. Usage scenarios, environment and requirements 781 These profiles are optimized for voice traffic over error prone 782 links. The profiles are designed to successfully handle loss of 783 several consecutive packets over the link, without introducing any 784 additional loss. Packet type identification is included in all 785 profiles, which means that such functionality SHOULD NOT be provided 786 by the link layer used. Regarding packet stream separation, various 787 profiles are defined supporting different numbers of concurrent 788 streams. 789 As an error prone link with similar characteristics is expected at 790 the other end of the connection (see Figure 1.1), the profiles are 791 also designed to handle some consecutive lost packet before the 792 compression point without increasing the size of the compressed 793 header. The profiles are also in general designed to handle 794 reordering of single packets before the compression point without 795 increasing the size of compressed headers. 797 5.2. Profile definitions 799 This document defines a number of different header compression 800 profiles. The definitions are built up of the requirements on and 801 capabilities of each profile in combination with information about 802 which mechanisms are used to implement the desired behavior. 804 5.2.1. List of defined profiles 806 All defined profiles are listed in Table 5.1 together with their 807 characteristics, capabilities and pointers to implementation details 808 that may differ from profile to profile. For more information about 809 the profile concept see chapter 4.3 and "Header compression profile" 810 in the Terminology chapter. 812 The first seven columns state requirements on and capabilities of the 813 profiles. The meaning of the columns are: 815 Nr This is the identification number for each profile. These 816 numbers are used when negotiating profiles in the header 817 compression setup phase. The numbers are preliminary and will 818 perhaps change in future versions of this profile 819 specification. 821 IPv This is the IP version for which the profile is designed. 822 Possible values for this column are 6 and 4. 824 CID This column gives the number of concurrent packet streams 825 that are supported by the header compression profile through 826 context identifiers (CIDs). 828 Chk This column indicates whether the profile supports packet 829 streams with the UDP checksum (E)nabled or D(isabled). 831 ID For profiles supporting IPv4, this column indicates which 832 behavior of the IPv4 Identification field the profile is 833 optimized for. Possible values in this column are: 835 (S)EQUENTIAL These profiles can handle all kind of 836 Identification assignment methods but 837 will be less efficient than RANDOM 838 profiles if the assignment truly is 839 random. If the value is sequentially 840 assigned, no extra overhead is added 841 for Identification. 843 (R)ANDOM These profiles are recommended if it is 844 known that random assignment is used. 845 The Identification field will be 846 included "as-is" which means that the 847 header size will increase by two 848 octets. 850 TbT Timer-based Timestamp decompression. Requires a timer at the 851 decompressor side to estimate timestamp jumps. Compressor 852 never sends more than a few bits of timestamp LSB with these 853 profiles. Can be (E)nabled or (D)isabled (see chapter 5.5.3). 855 S S gives the minimal header Size for the profile. 857 The next five columns indicate how each profile is implemented. This 858 includes header formats for STATIC (STA, see chapter 5.4.1), DYNAMIC 859 (DYN, see chapter 5.4.2) and COMPRESSED (COM, see chapter 5.4.3) 860 packets, and also what EXTENSION (EXT, see chapter 5.4.4) formats are 861 used with the COMPRESSED packets. The CRC column tells the coverage 862 of the header compression CRC: uncompressed (H)eader or the same 863 coverage as for the UDP (C)hecksum (see chapter 5.6). 865 +-----+---+-----+---+---+---+ +---+ +---+---+-------+---+---+ 866 | N | I | C | C | I | T | | S | | S | D | C | E | C | 867 | r | P | I | h | D | b | | | | T | Y | O | X | R | 868 | | v | D | k | | T | | | | A | N | M | T | C | 869 +=====+===+=====+===+===+===+ +===+ +===+===+=======+===+===+ 870 | 1 | 6 | 1 | E | - | E | | 2 | | 1 | 1 | 1 | A | C | 871 +-----+---+-----+---+---+---+ +---+ +---+---+-------+---+---+ 872 | 2 | 6 | 1 | E | - | D | | 2 | | 1 | 1 | 1 | A | C | 873 +-----+---+-----+---+---+---+ +---+ +---+---+-------+---+---+ 874 | 3 | 6 | 256 | E | - | E | | 3 | | 2 | 2 | 2 | A | C | 875 +-----+---+-----+---+---+---+ +---+ +---+---+-------+---+---+ 876 | 4 | 6 | 256 | E | - | D | | 3 | | 2 | 2 | 2 | A | C | 877 +-----+---+-----+---+---+---+ +---+ +---+---+-------+---+---+ 878 | 5 | 4 | 1 | D | S | E | | 1 | | 3 | 3 | 5, 9 | D | H | 879 +-----+---+-----+---+---+---+ +---+ +---+---+-------+---+---+ 880 | 6 | 4 | 1 | D | S | E | | 2 | | 3 | 3 | 1 | D | H | 881 +-----+---+-----+---+---+---+ +---+ +---+---+-------+---+---+ 882 | 7 | 4 | 1 | D | S | D | | 1 | | 3 | 3 | 5, 13 | B | H | 883 +-----+---+-----+---+---+---+ +---+ +---+---+-------+---+---+ 884 | 8 | 4 | 1 | D | S | D | | 2 | | 3 | 3 | 1 | B | H | 885 +-----+---+-----+---+---+---+ +---+ +---+---+-------+---+---+ 886 | 9 | 4 | 1 | D | R | E | | 3 | | 3 | 3 | 7, 11 | C | H | 887 +-----+---+-----+---+---+---+ +---+ +---+---+-------+---+---+ 888 | 10 | 4 | 1 | D | R | E | | 4 | | 3 | 3 | 3 | C | H | 889 +-----+---+-----+---+---+---+ +---+ +---+---+-------+---+---+ 890 | 11 | 4 | 1 | D | R | D | | 3 | | 3 | 3 | 7, 15 | A | H | 891 +-----+---+-----+---+---+---+ +---+ +---+---+-------+---+---+ 892 | 12 | 4 | 1 | D | R | D | | 4 | | 3 | 3 | 3 | A | H | 893 +-----+---+-----+---+---+---+ +---+ +---+---+-------+---+---+ 894 | 13 | 4 | 1 | E | S | E | | 2 | | 3 | 5 | 1 | D | C | 895 +-----+---+-----+---+---+---+ +---+ +---+---+-------+---+---+ 896 | 14 | 4 | 1 | E | S | D | | 2 | | 3 | 5 | 1 | B | C | 897 +-----+---+-----+---+---+---+ +---+ +---+---+-------+---+---+ 898 | 15 | 4 | 1 | E | R | E | | 4 | | 3 | 5 | 3 | C | C | 899 +-----+---+-----+---+---+---+ +---+ +---+---+-------+---+---+ 900 | 16 | 4 | 1 | E | R | D | | 4 | | 3 | 5 | 3 | A | C | 901 +-----+---+-----+---+---+---+ +---+ +---+---+-------+---+---+ 902 | 17 | 4 | 256 | D | S | E | | 2 | | 4 | 4 | 6, 10 | D | H | 903 +-----+---+-----+---+---+---+ +---+ +---+---+-------+---+---+ 904 | 18 | 4 | 256 | D | S | E | | 3 | | 4 | 4 | 2 | D | H | 905 +-----+---+-----+---+---+---+ +---+ +---+---+-------+---+---+ 906 | 19 | 4 | 256 | D | S | D | | 2 | | 4 | 4 | 6, 14 | B | H | 907 +-----+---+-----+---+---+---+ +---+ +---+---+-------+---+---+ 908 | 20 | 4 | 256 | D | S | D | | 3 | | 4 | 4 | 2 | B | H | 909 +-----+---+-----+---+---+---+ +---+ +---+---+-------+---+---+ 910 | 21 | 4 | 256 | D | R | E | | 4 | | 4 | 4 | 8, 12 | C | H | 911 +-----+---+-----+---+---+---+ +---+ +---+---+-------+---+---+ 912 | 22 | 4 | 256 | D | R | E | | 5 | | 4 | 4 | 4 | C | H | 913 +-----+---+-----+---+---+---+ +---+ +---+---+-------+---+---+ 914 | 23 | 4 | 256 | D | R | D | | 4 | | 4 | 4 | 8, 16 | A | H | 915 +-----+---+-----+---+---+---+ +---+ +---+---+-------+---+---+ 916 +-----+---+-----+---+---+---+ +---+ +---+---+---+---+---+ 917 | N | I | C | C | I | T | | S | | S | D | C | E | C | 918 | r | P | I | h | D | b | | | | T | Y | O | X | R | 919 | | v | D | k | | T | | | | A | N | M | T | C | 920 +=====+===+=====+===+===+===+ +===+ +===+===+===+===+===+ 921 | 24 | 4 | 256 | D | R | D | | 5 | | 4 | 4 | 4 | A | H | 922 +-----+---+-----+---+---+---+ +---+ +---+---+---+---+---+ 923 | 25 | 4 | 256 | E | S | E | | 3 | | 4 | 6 | 2 | D | C | 924 +-----+---+-----+---+---+---+ +---+ +---+---+---+---+---+ 925 | 26 | 4 | 256 | E | S | D | | 3 | | 4 | 6 | 2 | B | C | 926 +-----+---+-----+---+---+---+ +---+ +---+---+---+---+---+ 927 | 27 | 4 | 256 | E | R | E | | 5 | | 4 | 6 | 4 | C | C | 928 +-----+---+-----+---+---+---+ +---+ +---+---+---+---+---+ 929 | 28 | 4 | 256 | E | R | D | | 5 | | 4 | 6 | 4 | A | C | 930 +-----+---+-----+---+---+---+ +---+ +---+---+---+---+---+ 932 Table 5.1 : List of defined profiles 934 5.2.2. Additional common profile characteristics 936 In addition to what was stated in the left part of Table 5.1, the 937 following applies to all the profiles defined in this document: 939 Packet stream characteristics 941 These profiles are designed for packet streams carrying 942 conversational voice data. 944 Link layer requirements 946 Except for the general link layer requirements (framing, length & 947 profile negotiation) stated in chapter 4.5, these profiles also 948 require a reliable link layer CRC covering at least the header part 949 of the packet. The CRC SHOULD ensure that packets with errors in 950 the header part are never delivered. 952 Pre link characteristics 954 With these profiles, several consecutive packet losses before the 955 header compression point are handled without introducing additional 956 header overhead. Packet reordering on pre links is expected to be 957 uncommon but is handled, very efficiently when limited. 959 Link Characteristics 961 The link over which header compression is performed is expected to 962 have a loss characteristic that very seldom leads to loss of many 963 consecutive packets. These profiles can without extra 964 reconstruction attempts handle loss of up to 25 consecutive packets 965 over the link without losing context, and even if loss on pre links 966 decreases this robustness, it should be more than sufficient for 967 all realistic scenarios. The round-trip time of the link is 968 expected to be between 100 and 200 milliseconds. 970 5.3. Encoding methods used 972 The analysis of header field changes in appendix A excluded changes 973 due to loss and/or reordering before the header compression point. 974 Such changes will have an impact on the regularity of the RTP 975 sequence number, the RTP timestamp value and, for IPv4, the IP ID 976 value. However, as described in A.2, both the RTP timestamp and the 977 IP ID value (if sequentially assigned) are expected to follow the RTP 978 sequence number for most packets. The most important task is then to 979 communicate RTP sequence number information in an efficient way. The 980 profiles defined in this document make use of two different methods 981 of handling the sequence number field and also other fields, LSB 982 encoding and LSP encoding. The methods are interpreted in different 983 ways for different fields, and this chapter therefore describes these 984 methods in a general way. How these two methods are applied to fields 985 in different compressed headers is described in chapter 5.6. 987 5.3.1. Least Significant Bits (LSB) encoding 989 A commonly used method for updating fields whose values are always 990 subject to small changes (usually positive) is Least Significant Bits 991 (LSB) encoding. For example, an increase of up to 16 could be handled 992 with only 4 bits with LSB encoding (if decreases are not expected). 993 This method is used for many different fields by the ROCCO profiles 994 defined in this document, especially when information such as 995 timestamps is sent in EXTENDED COMPRESSED headers. If a field is 996 labeled " LSB", it means that the field contains only the 997 least significant bits of the corresponding original field. 999 5.3.2. Least Significant Part (LSP) encoding 1001 One restriction with LSB encoding is that whole bits are needed, 1002 meaning that only 2, 4, 8, 16, 32, ... code-points could be used. In 1003 some cases, especially when several mechanisms are integrated for 1004 efficiency reasons, it would be desirable to have a method that could 1005 make use of any number of available code-points. To signal one 1006 special event one could either use one single bit or, if the event is 1007 not to be signaled in parallel with other information, as one bit 1008 pattern for several bits. That would leave more bit patterns for 1009 other usage. 1011 Assume that we have 4 special events to signal and 5 bits available. 1012 Taking 2 bits for these events, then there would be 3 bits (8 code- 1013 points) left for other usage. If we instead reserved 4 of the code- 1014 points represented by all 5 bits, there would instead be 32-4=28 1015 code-points left for other usage. The only disadvantage would be that 1016 the bits cannot be used for both purposes at the same time. 1018 What would be desirable is to do LSB encoding of code-points instead 1019 of whole bits. Therefore the method called Least Significant Part 1020 (LSP) encoding has been introduced. LSP encoding of size (number of 1021 code-points) M for a value N is defined as: 1023 LSP:M(N) = N modulo M 1025 An example showing the LSP encoding and decoding of a counter S(n) 1026 with M code-points is used below to illustrate the LSP principle. 1027 S'(n) is the decoded value corresponding to the original S(n) value. 1028 With S'(n-1), we denote the last correctly decompressed value. 1030 Input sequence: S(n) 1031 Encoded sequence: LSP:M(S(n)) = S(n) modulo M 1032 Decoded sequence: S'(n) = S'(n-1) - LSP:M(S'(n-1)) + LSP:M(S(n)) = 1033 S'(n-1) - S(n-1) modulo M + S(n) modulo M 1035 To handle modulo wrap-around, an additional verification is inserted. 1036 If the decoded value S'(n) is smaller than S'(n-1)-R, S'(n) is 1037 increased with M (reordering of order R is then handled with this 1038 encoding). 1040 When applying LSP encoding, there are thus two parameters that must 1041 be set: 1043 M - The number of code-points to use (modulo value) 1044 R - The reordering order to handle 1046 A similar mechanism as for modulo wrap-around should also be used to 1047 handle full-field wrap-around. 1049 5.3.3. LSB or LSP encoding with extended range 1051 If needed, it could be good to extend the range covered by the LSB or 1052 LSP encoding. For the LSB case, it is simple to send only the next 1053 more significant bits. For the LSP, what must be done is to rewrite 1054 the definition of LSP so that it defines an additional parameter. 1056 The LSP definition from previous chapter can instead be expressed as: 1058 LSP:M(N) = N - INT:M(N)*M [ INT:M(N) = (N - LSP:M(N)) / M) ] 1060 And in that case, INT:M(N) is the integer part left after division. 1061 If additional bits can be transmitted to increase the range covered, 1062 this can be done by sending the least significant bits (LSB) of this 1063 integer part, INT:M(N). The example from previous chapter will then 1064 change into: 1066 Input sequence: S(n) 1067 Encoded sequence: LSP:M(S(n)) = S(n) modulo M 1068 INT:M(S(n)) = (S(n)-LSP:M(S(n))) / M 1069 Decoded sequence: S'(n) = S'(n-1) - LSP:M(S'(n-1)) * M 1070 + LSP:M(S(n)) * M 1071 - LSB(INT:M(S'(n-1))) * M 1072 + LSB(INT:M(S(n))) * M 1074 5.4. Packet formats 1076 The profiles defined in this document make use of four different 1077 packet types: STATIC, DYNAMIC, COMPRESSED and FEEDBACK. 1079 To identify packet types, 4 bit patterns for the initial 5 bits of 1080 the first octet (not including a potential CID field) in all packets 1081 are reserved. These patterns are: 1083 STATIC 11111 1084 DYNAMIC 1110* (both 11100 and 11101 are reserved for this) 1085 FEEDBACK 11110 1087 The other 28 (32-4) bit patterns indicate a COMPRESSED packet format 1088 and the usage of these patterns are explained further on. 1090 This section defines the header formats of the four ordinary packet 1091 types STATIC, DYNAMIC, COMPRESSED and FEEDBACK together with 1092 descriptions of when and how to use them. A subsections is also 1093 dedicated to the EXTENSION formats of COMPRESSED headers. 1095 5.4.1. Static information packets, initialization 1097 The STATIC packet type is a packet containing no payload but only the 1098 header fields that are expected to be constant throughout the 1099 lifetime of the packet stream (classified as STATIC in appendix A). A 1100 packet of this kind MUST be sent once as the first packet from 1101 compressor to decompressor and also when requested by the 1102 decompressor (see chapter 5.4.5). The packet formats are shown below 1103 for IPv6 and IPv4, respectively. Note that some fields are only 1104 present in some of the STATIC packet types. 1106 IPv6 (45-46 octets): STATIC1, STATIC2: 1108 0 1 2 3 4 5 6 7 1109 +...+...+...+...+...+...+...+...+ 1110 : Context Identifier (CID) : only present in STATIC2 1111 +---+---+---+---+---+---+---+---+ 1112 | 1 1 1 1 1 | - | - | - | 1113 +---+---+---+---+---+---+---+---+ 1114 | | 1115 + Flow Label + 1116 | | 1117 + +---+---+---+---+ 1118 | | - | - | P | E | 1119 +---+---+---+---+---+---+---+---+ 1120 | | 1121 / Source Address / 16 octets 1122 | | 1123 +---+---+---+---+---+---+---+---+ 1124 | | 1125 / Destination Address / 16 octets 1126 | | 1127 +---+---+---+---+---+---+---+---+ 1128 | | 1129 + Source Port + 1130 | | 1131 +---+---+---+---+---+---+---+---+ 1132 | | 1133 + Destination Port + 1134 | | 1135 +---+---+---+---+---+---+---+---+ 1136 | | 1137 / SSRC / 4 octets 1138 | | 1139 +---+---+---+---+---+---+---+---+ 1140 | Header Compression CRC | see chapter 5.6.1. 1141 +---+---+---+---+---+---+---+---+ 1143 IPv4 (18-19 octets): STATIC3, STATIC4: 1145 0 1 2 3 4 5 6 7 1146 +...+...+...+...+...+...+...+...+ 1147 : Context Identifier (CID) : only present in STATIC4 1148 +---+---+---+---+---+---+---+---+ 1149 | 1 1 1 1 1 | F | P | E | 1150 +---+---+---+---+---+---+---+---+ 1151 | | 1152 / Source Address / 4 octets 1153 | | 1154 +---+---+---+---+---+---+---+---+ 1155 | | 1156 / Destination Address / 4 octets 1157 | | 1158 +---+---+---+---+---+---+---+---+ 1159 | | 1160 + Source Port + 1161 | | 1162 +---+---+---+---+---+---+---+---+ 1163 | | 1164 + Destination Port + 1165 | | 1166 +---+---+---+---+---+---+---+---+ 1167 | | 1168 / SSRC / 4 octets 1169 | | 1170 +---+---+---+---+---+---+---+---+ 1171 | Header Compression CRC | see chapter 5.6.1. 1172 +---+---+---+---+---+---+---+---+ 1174 All fields except for the initial five bits, the padding (-) and the 1175 Header Compression CRC are the ordinary IP, UDP and RTP fields 1176 (F=IPv4 May Fragment, P=RTP Padding, E=RTP Extension). 1178 The number of STATIC packets sent on each occasion should be limited. 1179 If the decompressor receives DYNAMIC or COMPRESSED headers without 1180 having received a STATIC packet, the decompressor MUST send a 1181 STATIC_FAILURE_FEEDBACK packet. 1183 5.4.2. Dynamic information packets 1185 The DYNAMIC packet type has a header containing all changing header 1186 fields in their original, uncompressed form, and carries a payload 1187 just like ordinary COMPRESSED packets. This packet type is used after 1188 the initial STATIC packet to set up the decompressor context for the 1189 first time, and also whenever the header field information cannot be 1190 encoded in EXTENDED_COMPRESSED packets. DYNAMIC packets could be used 1191 due to significant field changes or upon INVALID_CONTEXT_FEEBACK. 1193 All fields except for the initial four bits, the Timestamp Delta, and 1194 the Header Compression CRC are ordinary IP, UDP and RTP fields. The 1195 Timestamp Delta is the current delta between RTP timestamps in 1196 consecutive RTP packets. Initially this value SHOULD be set to 160. 1198 The packet formats are shown below for IPv6 and IPv4, respectively. 1199 Note that some fields are only present in some of the DYNAMIC packet 1200 types. 1202 IPv6 (13-16 octets + CSRC List of 0-60 octets): DYNAMIC1, DYNAMIC2: 1204 0 1 2 3 4 5 6 7 1205 +...+...+...+...+...+...+...+...+ 1206 : Context Identifier (CID) : only in DYNAMIC2 1207 +---+---+---+---+---+---+---+---+ 1208 | 1 1 1 0 | CSRC Counter | 1209 +---+---+---+---+---+---+---+---+ 1210 | Traffic Class | 1211 +---+---+---+---+---+---+---+---+ 1212 | Hop Limit | 1213 +---+---+---+---+---+---+---+---+ 1214 | | 1215 + UDP Checksum + 1216 | | 1217 +---+---+---+---+---+---+---+---+ 1218 | M | Payload Type | 1219 +---+---+---+---+---+---+---+---+ 1220 | | 1221 + Sequence Number + 1222 | | 1223 +---+---+---+---+---+---+---+---+ 1224 | | 1225 / Timestamp / 4 octets 1226 | | 1227 +---+---+---+---+---+---+---+---+ 1228 : : 1229 : CSRC List : 0-15 x 4 octets 1230 : : 1231 +---+---+---+---+---+---+---+---+ 1232 | | 1233 + Timestamp Delta + 1234 | | 1235 +---+---+---+---+---+---+---+---+ 1236 | Header Compression CRC | see chapter 5.6.2. 1237 +---+---+---+---+---+---+---+---+ 1238 / Payload / 1239 +---+---+---+---+---+---+---+---+ 1241 IPv4 (15-18 octets + CSRC List of 0-60 octets): DYNAMIC3, DYNAMIC4, 1242 DYNAMIC5, DYNAMIC6: 1244 0 1 2 3 4 5 6 7 1245 +...+...+...+...+...+...+...+...+ 1246 : Context Identifier (CID) : only in DYNAMIC4 and DYNAMIC6 1247 +---+---+---+---+---+---+---+---+ 1248 | 1 1 1 0 | CSRC Counter | 1249 +---+---+---+---+---+---+---+---+ 1250 | Type Of Service | 1251 +---+---+---+---+---+---+---+---+ 1252 | | 1253 + Identification + 1254 | | 1255 +---+---+---+---+---+---+---+---+ 1256 | Time To Live | 1257 +---+---+---+---+---+---+---+---+ 1258 : : 1259 + UDP Checksum + only in DYNAMIC5 and DYNAMIC6 1260 : : 1261 +---+---+---+---+---+---+---+---+ 1262 | M | Payload Type | 1263 +---+---+---+---+---+---+---+---+ 1264 | | 1265 + Sequence Number + 1266 | | 1267 +---+---+---+---+---+---+---+---+ 1268 | | 1269 / Timestamp / 4 octets 1270 | | 1271 +---+---+---+---+---+---+---+---+ 1272 : : 1273 : CSRC List : 0-15 x 4 octets 1274 : : 1275 +---+---+---+---+---+---+---+---+ 1276 | | 1277 + TS Delta + 1278 | | 1279 +---+---+---+---+---+---+---+---+ 1280 | Header Compression CRC | see chapter 5.6.2. 1281 +---+---+---+---+---+---+---+---+ 1282 / Payload / 1283 +---+---+---+---+---+---+---+---+ 1285 Each time a DYNAMIC packet is sent, several subsequent packets SHOULD 1286 also be DYNAMIC packets to ensure a successful update even when 1287 packets are lost. Context updates both with DYNAMIC and COMPRESSED 1288 packets could also be acknowledged with CONTEXT_UPDATED_FEEDBACK. 1290 5.4.3. Compressed packets 1292 The COMPRESSED packet type is the most commonly used packet and is 1293 designed to handle ordinary changes as efficiently as possible. 1295 When changes are regular, all information is carried in the base 1296 header. When desired, it is possible to send additional information 1297 in extensions to the COMPRESSED base-header. 1299 The COMPRESSED base-header formats are shown below. Note that some 1300 fields are only present in some of the COMPRESSED packet types. 1302 Defines packet types: COMPRESSED1..COMPRESSED4: 1304 0 1 2 3 4 5 6 7 1305 +...+...+...+...+...+...+...+...+ 1306 : Context Identifier (CID) : only in COMPRESSED type 2 and 4 1307 +---+---+---+---+---+---+---+---+ 1308 | Sequence LSP# | | # see chapter 5.5.2 1309 +---+---+---+---+---+ +---+ 1310 | Header Compression CRC* | X | * see chapter 5.6.3 1311 +---+---+---+---+---+---+---+---+ 1312 : : 1313 + Identification + only in COMPRESSED type 3 and 4 1314 : : 1315 +...+...+...+...+...+...+...+...+ 1316 : : 1317 / Extension / only present if X=1 1318 : : 1319 +---+---+---+---+---+---+---+---+ 1320 / Payload / 1321 +---+---+---+---+---+---+---+---+ 1323 Defines packet types: COMPRESSED5..COMPRESSED8: 1325 0 1 2 3 4 5 6 7 1326 +...+...+...+...+...+...+...+...+ 1327 : Context Identifier (CID) : only in COMPRESSED 6 and 8 1328 +---+---+---+---+---+---+---+---+ 1329 | 0 | Sequence LSB# | CRC* | # see chapter 5.5.1 1330 +---+---+---+---+---+---+---+---+ * see chapter 5.6.3 1331 : : 1332 + Identification + only in COMPRESSED 7 and 8 1333 : : 1334 +---+---+---+---+---+---+---+---+ 1335 / Payload / 1336 +---+---+---+---+---+---+---+---+ 1338 Defines packet types: COMPRESSED9..COMPRESSED12: 1340 0 1 2 3 4 5 6 7 1341 +...+...+...+...+...+...+...+...+ 1342 : Context Identifier (CID) : only in COMPRESSED 10 and 12 1343 +---+---+---+---+---+---+---+---+ 1344 | 1 0 | CRC* | * see chapter 5.6.3 1345 +---+---+---+---+---+---+---+---+ 1346 | Sequence LSB# | STS LSB# | X | # see chapter 5.5.1 1347 +---+---+---+---+---+---+---+---+ 1348 : : 1349 + Identification + only in COMPRESSED 11 and 12 1350 : : 1351 +...+...+...+...+...+...+...+...+ 1352 : : 1353 / Extension / only present if X=1 1354 : : 1355 +---+---+---+---+---+---+---+---+ 1356 / Payload / 1357 +---+---+---+---+---+---+---+---+ 1359 Defines packet types: COMPRESSED13..COMPRESSED16: 1361 0 1 2 3 4 5 6 7 1362 +...+...+...+...+...+...+...+...+ 1363 : Context Identifier (CID) : only in COMPRESSED 14 and 16 1364 +---+---+---+---+---+---+---+---+ 1365 | 1 0 | M | STS LSB# | # see chapter 5.5.1 1366 +---+---+---+---+---+---+---+---+ 1367 | Sequence LSB# | CRC* | X | * see chapter 5.6.3 1368 +---+---+---+---+---+---+---+---+ 1369 : : 1370 + Identification + only in COMPRESSED 15 and 16 1371 : : 1372 +...+...+...+...+...+...+...+...+ 1373 : : 1374 / Extension / only present if X=1 1375 : : 1376 +---+---+---+---+---+---+---+---+ 1377 / Payload / 1378 +---+---+---+---+---+---+---+---+ 1380 The coverage of the Header Compression CRC is described in chapter 1381 5.6.3. In that chapter, the CRC polynomials to use are also defined. 1383 The interpretations of the Sequence and STS (Scaled TimeStamp) fields 1384 for different profiles are given in section 5.5. 1386 5.4.4. Extensions to compressed headers 1388 Less regular changes in the header fields or updates of decompressor 1389 contexts require an extension in addition to the base header. When 1390 there is an extension present in the COMPRESSED packet, this is 1391 indicated by the extension bit (X) being set. Extensions are of 1392 variable size depending on the information needed to be transmitted. 1393 However, the first three extension bits are used as an extension Type 1394 field for all extension formats. The extension can carry an M-bit, a 1395 t-bit, a SEQ EXT LSB field (called SEQ*), a (S)TS (EXT) LSB field 1396 (called TS*), an ID LSB field and a bit mask for additional fields. 1397 The M-bit is the RTP marker bit and the (S)TS (EXT) LSB is timestamp 1398 information sent with the least significant bits (the most 1399 significant bits are then expected to be unchanged compared to 1400 context). The timestamp information could either be the LSB of the 1401 (S)caled (T)ime(S)tamp value (if indicated with the t-bit unset) or 1402 the LSB of the absolute timestamp value. For profiles with a 1403 timestamp field in the compressed base header, the timestamp 1404 information is sent as an extended range to that field. The SEQ EXT 1405 LSB is extended range for the RTP sequence number. How extended range 1406 works is described in chapter 5.5.1 and 5.5.2. The t-bit is sent when 1407 timestamp is not scaled, otherwise it is always scaled with the 1408 timestamp delta. The ID LSB is the LSB of the IP Identification 1409 value. Various bit mask patterns are possible and can consist of 1410 S,H,C,D,T and I. The interpretations of these bits are given at the 1411 end of this chapter. 1413 The guiding principle for choosing the extension type is to find the 1414 smallest header type that can communicate the information needed. 1416 For the profiles defined in this document, four different extension 1417 sets are used, called A, B, C and D. Set A and C are for IPv6 and do 1418 not handle the IPv4 identification field, which set B and D do. Set A 1419 and B handle timestamp information which set C and D do not. All 1420 possible extensions are shown below with indications of which sets 1421 and types the extensions correspond to. For instance, B3 means that 1422 in extension set B, the extension is used with type value 3 1423 (indicated in the type field). 1425 The defined extension types are shown below: 1427 0 7 1428 - - +-+-+-+-+-+-+-+-+ 1429 A0, B0, |0 0 0| SEQ* | 1430 C0, D0 - - +-+-+-+-+-+-+-+-+ 1432 0 7 1433 - - +-+-+-+-+-+-+-+-+ 1434 A1, B1 |0 0 1|M| TS* | 1435 - - +-+-+-+-+-+-+-+-+ 1436 1 1437 0 7 8 5 1438 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 A2 |0 1 0|M| TS* | 1440 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1442 1 1 2 1443 0 7 8 5 6 3 1444 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1445 A3 |0 1 1|M|t| TS* | 1446 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 0 7 1449 - - +-+-+-+-+-+-+-+-+ - - 1450 A4 |1 0 0|M|H|D|T|t| 1451 - - +-+-+-+-+-+-+-+-+ - - 1453 1 1454 0 7 8 5 1455 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 1456 A5 |1 0 1|M|C|H|S|D| TS* | 1457 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 1459 1 1 2 1460 0 7 8 5 6 3 1461 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 1462 A6 |1 1 0|M|C|H|S|D|t| TS* | 1463 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 1465 1 1466 0 7 8 5 1467 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 1468 A7 |1 1 1|M|C|H|S|D|T|t| SEQ* | 1469 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 1471 1 1472 0 7 8 5 1473 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 B2 |0 1 0|M| TS* | SEQ* | 1475 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 1 1478 0 7 8 5 1479 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1480 B3 |0 1 1|M| TS* | ID LSB | 1481 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1482 0 7 1483 - - +-+-+-+-+-+-+-+-+ 1484 B4, D4 |1 0 0|M| ID LSB| 1485 - - +-+-+-+-+-+-+-+-+ 1487 0 7 1488 - - +-+-+-+-+-+-+-+-+ - - 1489 B5 |1 0 1|M|H|D|T|I| 1490 - - +-+-+-+-+-+-+-+-+ - - 1492 1 2 1493 0 7 8 5 3 1494 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 B6 |1 1 0|M|t| TS* | ID LSB | 1496 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 1 1499 0 7 8 5 1500 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 1501 B7 |1 1 1|M|C|H|S|D|T|I|t| SEQ* | 1502 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 1504 1 1505 0 7 8 5 1506 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 C1, D1 |0 0 1|M| SEQ* | 1508 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1510 1 1511 0 7 8 5 1512 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 1513 C2, D2 |0 1 0|M|C|H|S| SEQ* | 1514 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 1516 0 7 1517 - - +-+-+-+-+-+-+-+-+ - - 1518 C3, D3 |0 1 1|M|C|H|S|-| 1519 - - +-+-+-+-+-+-+-+-+ - - 1521 0 7 8 5 1522 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 D5 |1 0 1|M| ID LSB | 1524 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 1 1 2 1526 0 7 8 5 6 3 1527 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 1528 D6 |1 1 0|M|C|H|S|-| ID | 1529 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 1531 Bit masks indicating additional fields have the following meaning: 1533 C - Traffic (C)lass / Type Of Service 1534 H - (H)op Limit / Time To Live 1535 S - Contributing (S)ources - CSRC 1536 D - Timestamp (D)elta 1537 T - (T)imestamp LSB 1538 I - (I)dentification LSB 1540 If any of these fields are included, they will appear in the order as 1541 listed above and the format of the fields will be as described below. 1543 C - Traffic Class / Type Of Service 1545 The field contains the value of the original IP header field. 1547 8 bits 1548 - - +-+-+-+-+-+-+-+-+ - - 1549 | TC / TOS | 1550 - - +-+-+-+-+-+-+-+-+ - - 1552 H - Hop Limit / Time To Live 1554 The field contains the value of the original IP header field. 1556 8 bits 1557 - - +-+-+-+-+-+-+-+-+ - - 1558 | HL / TTL | 1559 - - +-+-+-+-+-+-+-+-+ - - 1561 S - Contributing Sources 1563 The CSRC field is built up of: 1565 - a counter of the number of CSRC items present (4 bits) 1566 - an unused field (4 bits) 1567 - the CSRC items, 1 to 15 (4-60 octets) 1569 1 octet + 4 to 60 octets 1570 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+~~~+-+-+-+-+-+ - - 1571 | Count | Unused| CSRC Items | 1572 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+~~~+-+-+-+-+-+ - - 1574 D - Timestamp Delta 1576 The Timestamp Delta field is a one-octet field. We want to 1577 communicate Timestamp Delta values corresponding to 80 ms. 1578 Therefore, the Timestamp Delta value communicated is not the 1579 actual number of samples, but the number of samples divided by 1580 8. Thus, only Timestamp Delta values evenly divisible by 8 can 1581 be communicated in the Timestamp Delta field of an extension. On 1582 the other hand, the maximum value is 255*8 = 2040 (255 ms at 1583 8000 Hz). Delta values larger than 2040 or delta values not 1584 evenly divisible by 8 must be communicated in a DYNAMIC packet. 1586 8 bits 1587 - - +-+-+-+-+-+-+-+-+ - - 1588 |Timestamp Delta| 1589 - - +-+-+-+-+-+-+-+-+ - - 1591 Note that when the Timestamp Delta is changed, Timestamp LSB 1592 field MUST also be included not downscaled with the delta. 1594 T - Timestamp LSB 1596 The field contains the 16 least significant bits of the RTP 1597 timestamp, scaled if t-bit not set. May be sent as extended 1598 range for some profiles. 1600 16 bits 1601 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 1602 | TS* | 1603 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 1605 I - Identification 1607 The field contains the IP Identification. 1609 16 bits 1610 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 | ID | 1612 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 When information of any kind is sent in an extension, the 1615 corresponding information SHOULD also be sent in some subsequent 1616 packets (either as Extensions or in DYNAMIC packets). 1618 5.4.5. Feedback packets 1620 Feedback packets are used by the decompressor to provide various 1621 types of feedback to the compressor. That could include active 1622 feedback to assure error free performance or passive feedback (in 1623 case of invalidated context) to request a context update from the 1624 compressor. The feedback mechanisms defined here leave a lot to the 1625 implementation regarding how to use feedback. The general feedback 1626 packet format is shown below: 1628 0 1 2 3 4 5 6 7 1629 +...+...+...+...+...+...+...+...+ 1630 FEEDBACK (GENERAL) : Context Identifier (CID) : 1631 +---+---+---+---+---+---+---+---+ 1632 | 1 1 1 1 0 | Type | 1633 +---+---+---+---+---+---+---+---+ 1635 Note that The CID field is present only for profiles using STATIC 1636 packet format 2 or 4, which are profiles supporting multiple packet 1637 streams. The Type field tells what kind of feedback the packet 1638 corresponds to and the feedback types defined are the following: 1640 0 1 2 3 4 5 6 7 1641 +...+...+...+...+...+...+...+...+ 1642 STATIC_FAILURE_FEEDBACK : Context Identifier (CID) : 1643 +---+---+---+---+---+---+---+---+ 1644 | 1 1 1 1 0 | 0 0 0 | 1645 +---+---+---+---+---+---+---+---+ 1647 The STATIC_FAILURE_FEEDBACK packet tells the compressor that the 1648 static part of the decompressor context is invalid, and that an 1649 update of that part is required. Reasons for sending such feedback 1650 could be that no STATIC packet has been received at all, or that 1651 decompression has failed even when DYNAMIC packets are decompressed. 1653 0 1 2 3 4 5 6 7 1654 +...+...+...+...+...+...+...+...+ 1655 INVALID_CONTEXT_FEEDBACK : Context Identifier (CID) : 1656 +---+---+---+---+---+---+---+---+ 1657 | 1 1 1 1 0 | 0 0 1 | 1658 +---+---+---+---+---+---+---+---+ 1659 | Last Sequence Number LSB | 1660 +---+---+---+---+---+---+---+---+ 1662 The INVALID_CONTEXT_FEEDBACK packet SHOULD be sent to signal an 1663 invalid decompressor context, indicated by failing decompression of 1664 COMPRESSED packets. 1666 0 1 2 3 4 5 6 7 1667 +...+...+...+...+...+...+...+...+ 1668 NO_PACKETS_FEEDBACK : Context Identifier (CID) : 1669 +---+---+---+---+---+---+---+---+ 1670 | 1 1 1 1 0 | 0 1 0 | 1671 +---+---+---+---+---+---+---+---+ 1672 | Last Sequence Number LSB | 1673 +---+---+---+---+---+---+---+---+ 1675 The NO_PACKET_FEEDBACK packet can be used by the decompressor to 1676 signal that packets have not been received for some time. It is not 1677 always possible for the decompressor to notice such events, and it is 1678 therefore up to the implementers to decide whether and when to use 1679 this feedback packet. 1681 0 1 2 3 4 5 6 7 1682 +...+...+...+...+...+...+...+...+ 1683 LONGEST_LOSS_FEEDBACK : Context Identifier (CID) : 1684 +---+---+---+---+---+---+---+---+ 1685 | 1 1 1 1 0 | 0 1 1 | 1686 +---+---+---+---+---+---+---+---+ 1687 | Last Sequence Number LSB | 1688 +---+---+---+---+---+---+---+---+ 1689 | Length of longest loss | 1690 +---+---+---+---+---+---+---+---+ 1692 The LONGEST_LOSS_FEEDBACK packet can be used by the decompressor to 1693 inform the compressor about the length of the longest loss event that 1694 has occurred on the link between compressor and decompressor. It is 1695 not always possible for the decompressor to provide this information, 1696 and it is therefore up to the implementers to decide whether and when 1697 to use this feedback packet. 1699 0 1 2 3 4 5 6 7 1700 +...+...+...+...+...+...+...+...+ 1701 CONTEXT_UPDATED_FEEDBACK : Context Identifier (CID) : 1702 +---+---+---+---+---+---+---+---+ 1703 | 1 1 1 1 0 | 1 0 0 | 1704 +---+---+---+---+---+---+---+---+ 1705 | Last Sequence Number LSB | 1706 +---+---+---+---+---+---+---+---+ 1708 The CONTEXT_UPDATED_FEEDBACK packet can be used to signal that an 1709 update of some header fields has been correctly received, either in a 1710 DYNAMIC packet or in an EXTENDED_COMPRESSED packet. It is optional to 1711 use this active feedback mechanism and the compressor MUST NOT expect 1712 such packets initially. First after reception of one such packet, the 1713 compressor can expect to get this feedback from the decompressor. 1715 5.5. Encoding of field values 1717 The source increases the RTP sequence number by one for each packet 1718 sent. However, due to losses and reordering before the compression 1719 point, the changes seen by the compressor may vary. This would 1720 especially be the case if we consider the scenario in Figure 1.1 1721 where there are cellular links at both ends of the path. That is one 1722 reason why sequence number changes need special treatment, but 1723 another reason is that both timestamps and IP identification for most 1724 packets can be recreated with a combination of history and sequence 1725 number knowledge. The profiles defined in this document handle the 1726 sequence number, timestamp and identification values with LSB 1727 encoding, except for some profiles that use LSP encoding for the 1728 sequence number. For timestamp, some profiles also use the principle 1729 with timer-based decompression. This chapter describes how the 1730 different encoding methods are applied to the various field values. 1732 5.5.1. LSB encoding of field values 1734 LSB encoding is used for sequence number, timestamp and 1735 identification encoding as described in chapter 5.3.1. The sequence 1736 numbers, included in all compressed headers, can be sent with 1737 extended range in extension headers. This is also the case with the 1738 timestamp value for profiles not using timer-based TS reconstruction 1739 (see 5.2.1 and 5.5.3). With timer-based timestamp decompression, the 1740 amount of timestamp LSB that is sent is always limited to the size of 1741 the field in the compressed header. Note that in most headers, the 1742 timestamp value is sent as STS LSB (scaled timestamp LSB), which 1743 means that it is the least significant bits of the timestamp, scaled 1744 down with the timestamp delta (STS LSB = LSB of [TS / TS Delta]). 1746 5.5.2. LSP encoding of field values 1748 LSP, as described in chapter 5.3.2, is used for sequence numbers in 1749 the "Sequence LSP" field of COMPRESSED1..COMPRESSED4 headers. For 1750 those headers, there are 28 code-points left for sequence information 1751 because 4 are reserved for packet type identification. An LSP of size 1752 28 is therefore used with the following encoding: 1754 CODE(n) = LSP:28(n) 1756 The sequence range can be extended with extra bits in extension 1757 headers, as described in chapter 5.3.3. The "SEQ EXT LSB" field must 1758 for the case of extended LSP consist of the LSB of the integer 1759 quotient. 1761 The reordering parameter for LSP MUST be set to 2 meaning that first 1762 and second order reordering can be handled by the encoding. 1764 5.5.3. Timer-based timestamp decompression 1766 The RTP timestamp field is one of the header fields that may change 1767 dynamically on a per packet basis. For audio services, the timestamp 1768 value can be inferred from the encoded RTP sequence number value 1769 during talk spurts. When the encoded sequence number is incremented 1770 by N, the timestamp value is incremented by N * Timestamp-Delta- 1771 value. However, when a talk spurt has faded into silence and a new 1772 talk spurt starts, the timestamp value will take a leap compared to 1773 the sequence number. To communicate this leap in the timestamp value, 1774 some additional action has to be taken. In chapter 5.4.4, extension 1775 headers are defined that can transfer this leap in the timestamp 1776 value. That increases, however, the average header size. This chapter 1777 describes an optional method used by some profiles (see the TbT 1778 column of table 5.1) to reconstruct the timestamp value, requiring 1779 only a fixed number of added bits for timestamp leaps. The method 1780 makes use of timers or a local wall clock at the decompressor. 1782 To initialize the header compression and the timer-based timestamp 1783 reconstruction, the absolute value of the timestamp together with the 1784 sequence number must be transferred from compressor to decompressor 1785 at the beginning of the compression session. A default timestamp 1786 delta is also transferred. This is done through the transmission of a 1787 DYNAMIC header. For speech codecs with 8 kHz sampling frequency and 1788 20 ms frame sizes, for example, the timestamp delta will be 8000*0.02 1789 = 160. The decompressor then knows that the timestamp will increase 1790 by 160 for each packet containing 20 ms of speech. Hence, by using a 1791 local clock and by measuring packet arrival times, the decompressor 1792 can estimate the timestamp change compared to the previous packet. 1793 If, for example, a speech period has been succeeded by a silence 1794 period at the time T0 and a new speech period starts at the time 1795 T0+dT, it can be assumed that the timestamp has changed by: 1797 round(dT/(time for one speech frame)) * (timestamp delta) 1799 The packet time interval (or codec frame size in time) may be 1800 determined through the a priori knowledge that most speech codecs 1801 have constant frame sizes of 10, 20 or 30 ms, or through measurements 1802 on packet arrival times. 1804 The decompressor can then get an estimate of the timestamp change, 1805 add this change to the previous value and replace the least 1806 significant bits with those received in the compressed header. This 1807 should give the correct timestamp value. 1809 It is very important to verify the correctness of a timer-based 1810 timestamp decompression. However, this is automatically done in ROCCO 1811 with the header compression CRC verification. 1813 5.6. Header compression CRCs, coverage and polynomials 1815 This chapter contains a description of how to calculate the different 1816 CRCs used by the ROCCO profiles defined in this document. 1818 5.6.1. STATIC packet CRC 1820 The CRC in the STATIC header is calculated over the whole STATIC 1821 packet except for the header compression CRC itself. Therefore, the 1822 header compression CRC field MUST be set to 0 before the CRC 1823 calculation. 1825 The CRC polynomial to be used in STATIC packets is: 1827 C(x) = 1 + x + x^2 + x^8 1829 5.6.2. DYNAMIC packet CRC 1831 The CRC in the DYNAMIC packet is calculated over the original 1832 IP/UDP/RTP header. Before the calculation of the CRC, the IPv4 header 1833 checksum and the UDP checksum have to be set to 0. This makes it 1834 possible to recalculate the checksums after the decompression. 1835 Calculation over the full IP/UDP/RTP headers ensures that the 1836 decompressed IP/UDP/RTP header is a correct header. 1838 The CRC polynomial to be used in DYNAMIC packets is: 1840 C(x) = 1 + x + x^2 + x^8 1842 5.6.3. COMPRESSED packet CRCs 1844 COMPRESSED1..COMPRESSED4 1846 The header compression CRC in COMPRESSED header types 1 to 4 is 1847 calculated over the same headers as the CRC in the DYNAMIC packet, 1848 except for profiles which use replacement of the UDP checksum, I.e. 1849 except for profiles 1-4 and 13-16. In profiles 1-4 and 13-16, the 1850 header compression CRC also covers the payload covered by the UDP 1851 checksum. 1853 The polynomial to be used is: 1855 C(x) = 1 + x + x^4 + x^5 + x^9 + x^10 1857 COMPRESSED5..COMPRESSED8 and COMPRESSED14..COMPRESSED16 1859 In COMPRESSED header types 5 to 8 and 14 to 16 the header compression 1860 CRC is calculated over the same headers as the CRC in the DYNAMIC 1861 packet, but with a different polynomial: 1863 C(x) = 1 + x + x^3 1865 COMPRESSED10..COMPRESSED12 1867 In COMPRESSED header types 10 to 12 the header compression CRC is 1868 calculated over the same headers as the CRC in the DYNAMIC packet, 1869 but with a different polynomial: 1871 C(x) = 1 + x + x^3 + x^4 + x^6 1873 6. Implementation issues 1875 The profiles defined in this document specifies mechanisms for the 1876 protocol, while much of the usage of these mechanisms is left to the 1877 implementers to decide upon. This chapter is aimed to give 1878 guidelines, ideas and suggestions for implementing the scheme. 1880 6.1. Compressor and decompressor logic, use of feedback 1882 How to send and respond to the various kinds of FEEDBACK packets is 1883 not defined in this document, but left to the implementers to decide. 1884 However, it is recommended to reduce both the number of requests and 1885 the number of corresponding updating packets to a suitable level. 1886 Also it is recommended to use COMPRESSED packets with EXTENSIONS 1887 instead of DYNAMIC packets to update an invalid context, when 1888 possible. 1890 More guidelines on this issue will be included here at a later date. 1892 6.2. ROCCO over simplex links 1894 This chapter contains a discussion about how ROCCO can be used over 1895 simplex links. 1897 Previous chapters assumed that the decompressor has the possibility 1898 of sending requests to the compressor. This is true for many systems 1899 but there are several important scenarios where it is not possible to 1900 send information from the decompressor back to the compressor. The 1901 most important case may be when the packet are broadcasted in some 1902 way. It can also, for example, be the communication from a satellite. 1903 Over a simplex link the decompressor does not have the possibility of 1904 sending information back to the compressor. The compressor does not 1905 know when the decompressor needs a STATIC or DYNAMIC packet. If 1906 STATIC and DYNAMIC packets are sent at regular intervals it is 1907 possible for the decompressor to recover a lost context. A slow-start 1908 mechanism and a periodic refresh guarantee that the decompressor can 1909 recover a lost synchronization fast. 1911 The ROCCO scheme is especially suited for simplex links, since it is 1912 possible for the decompressor to continue with new reconstruction 1913 attempts, verified with the header checksum, until the next 1914 STATIC/DYNAMIC packet arrives. It is then possible for the 1915 decompressor to recover the context before the next STATIC/DYNAMIC 1916 packet arrives. 1918 When ROCCO is used over simplex links it is RECOMMENDED that only one 1919 DYNAMIC packet be sent at a time and not several as stated in 1920 previous chapters. 1922 6.2.1. Compression slow-start 1924 When a field in the STATIC or DYNAMIC packet has changed or if we are 1925 at the beginning of a ROCCO session, it is necessary to send the 1926 STATIC/DYNAMIC packet to the decompressor. To ensure that the new 1927 information reaches the decompressor as fast as possible even if 1928 packets are lost over the link, a slow-start mechanism is used. After 1929 the first two packets (STATIC and DYNAMIC), STATIC and DYNAMIC 1930 packets (read refresh) are sent with an exponentially increasing 1931 period until a new change occurs. The following figure shows how the 1932 slow-start works: 1934 |.|..|....|........|................|............................ 1935 ^ 1936 Change in STATIC and/or DYNAMIC packet 1938 Sent packets: 1939 . Packet with compressed header 1940 | STATIC packet followed by a DYNAMIC packet 1942 6.2.2. Periodic refresh 1944 To prevent the period between two refreshes from increasing too much, 1945 an upper limit on the interval between refreshes is set (MAX_PERIOD). 1946 This is used to avoid losing too many packets if the decompressor has 1947 lost its context. If the MAX_PERIOD between two refreshes is reached 1948 a new refresh (STATIC/DYNAMIC) has to be sent. 1950 To avoid long time periods between two refreshes an upper limit on 1951 the time between two packets is used (MAX_TIME). This ensures that 1952 the time between two refreshes does not exceed the MAX_TIME even if 1953 no MAX_PERIOD packets are sent. If the MAX_TIME between two refreshes 1954 is reached, a new refresh (STATIC/DYNAMIC) has to be sent. 1956 6.2.3. Refresh recommendations 1958 It is recommended that the MAX_PERIOD not exceed 256 packets and that 1959 the maximum time between two refreshes (MAX_TIME) not exceed 5 1960 seconds. 1962 6.2.4. Cost and robustness of refreshes 1964 If we assume that STATIC/DYNAMIC packets are sent every f'th packet, 1965 the average header size is: 1967 (S+U-C) 1968 ----- + C 1969 f 1971 S = STATIC header size 1972 U = DYNAMIC header size 1973 C = COMPRESSED header size 1975 The increase in average header size compared with the COMPRESSED 1976 header size is: 1978 (S+U-C) 1979 ----- 1980 f 1982 If we assume that we use ROCCO profile number 8 and that a refresh is 1983 sent every 256th packet, the increase in average header size is 1984 (18+15-2)/256=0.12 octets. The average header size for ROCCO profile 1985 number 4 over duplex links is, with realistic BER, 2.15 octets 1986 [PERF]. This results in an average header size of 2.15+0.12=2.27 1987 octets. 1989 The difference in robustness of ROCCO between simplex links and 1990 duplex links is very small. The reason for this is that the ROCCO 1991 decompressor very seldom loses its context. This results in that 1992 FEEDBACK packets are almost never needed, as proven in simulations. 1993 For example: In profile number 8 it is possible to lose up to 24 1994 consecutive packets without losing the context in the decompressor. 1995 The probability that 25 consecutive packets are lost is very small 1996 even if channels with high bit error rates are used. This indicates 1997 that a ROCCO scheme implemented over simplex links is almost as 1998 robust as the duplex ROCCO scheme. 2000 6.2.5. Simplex link improvements 2002 DYNAMIC information can be sent in two different ways: either as an 2003 ordinary DYNAMIC packet or as extensions to COMPRESSED headers. If 2004 the information is sent in extensions to COMPRESSED headers, it is 2005 possible to reduce the average header size, since a COMPRESSED header 2006 with extension is smaller than a DYNAMIC header. If COMPRESSED 2007 headers are used for transmission of DYNAMIC information the 2008 following is important: 2010 - All fields in the DYNAMIC packet that have changed since the last 2011 3-4 refreshes have to be transmitted in the extension. 2012 - DYNAMIC and STATIC packets still have to be sent at regular 2013 intervals to ensure that it is possible to recover a lost context 2014 even if COMPRESSED extension refreshes have failed. 2016 6.3. Reverse decompression 2018 This chapter describes an optional decompressor operation to reduce 2019 discarded packets due to an invalid context. 2021 Once a context becomes invalid (e.g., in the case when more 2022 consecutive packet losses than expected has occurred), subsequent 2023 compressed packets cannot be decompressed correctly with normal 2024 decompression operation. This decompression operation aims at 2025 decompressing these packets with a later recovered context. The 2026 decompressor stores them until the context is validated. After the 2027 context is updated, the decompressor tries to recover the stored 2028 packets in the reverse order from the packet updating the context. 2029 Each time the stored packet is decompressed, its correctness is 2030 verified using the header compression CRC, which is transmitted in 2031 each compressed header. Correctly decompressed packets are 2032 transferred to upper layers in the original order. 2034 Note that this reverse decompression introduces buffering while 2035 waiting for the context to be validated and thereby introduces 2036 additional delay. Thus, it should be used only when some amount of 2037 delay could be accepted. For example, for video packets belonging to 2038 the same video frame, the delay of packet arrival time does not cause 2039 presentation time delay. Delay-insensitive streaming applications can 2040 also be tolerant to such delay. 2042 The following illustrates the decompression procedure in some detail: 2044 1. The decompressor stores compressed packets that cannot be 2045 decompressed correctly due to an invalid context. 2047 2. When the decompressor has received a context updating packet and 2048 the context has been validated, it starts to recover the stored 2049 packets in reverse order. Decompression is carried out followed 2050 by the last decompressed packet to its previous packet as if the 2051 two packets were reordered. After that, decompressor checks the 2052 correctness of the reconstructed header using the header 2053 compression CRC. 2055 3. If the header compression CRC indicates a successful 2056 decompression, the decompressor stores the complete packet and 2057 tries to decompress its previous packet. In this way, the stored 2058 packets are recovered from correctly decompressed packets until 2059 no compressed packets are left. For each packet, the decompressor 2060 checks the correctness of the decompressed headers using header 2061 compression CRC. 2063 4. If the header compression CRC indicates an incorrectly 2064 decompressed packet, the reverse decompression attempt must be 2065 terminated and all remaining packets must be discarded. 2067 5. Finally, the decompressor forwards all the correctly decompressed 2068 packets to upper layers in the original order. 2070 6.4. Pre-verification of CRCs 2072 For reasons of compression efficiency, it is desirable to keep the 2073 size of the header compression CRC as small as possible. However, if 2074 the size of the CRC is decreased, the reliability is also decreased 2075 and erroneous headers could be generated and passed on from the 2076 decompressor. It would then be desirable to find a method of 2077 increasing the strength of the CRC without making it larger. 2079 There is one property of the ROCCO CRC and its usage that can be used 2080 to achieve this goal. The CRCs that will occur at the decompressor 2081 will in most cases follow a pattern well known also to the 2082 compressor. There are two factors that will affect which CRCs are 2083 generated and in which order they will occur. If the decompressor 2084 makes several reconstruction attempts, the first factor affecting the 2085 CRCs will be the order and properties of the assumptions made for 2086 each reconstruction attempt. The attempts are in general: 2088 1:st attempt: No loss is assumed 2089 2:nd attempt: Loss of the preceding packet is assumed 2090 3:rd attempt: Loss of the two preceding packets is assumed 2091 4:th attempt: Loss of the three preceding packets is assumed 2092 etc. 2094 The other factor that will affect the CRCs generated is what has 2095 really happened to preceding packets, that is, if no loss has 2096 occurred or if one or several preceding packets have been lost 2097 between compressor and decompressor. 2099 Since the compressor knows how the decompressor performs the 2100 reconstruction attempts, the compressor can PRE-CALCULATE and VERIFY 2101 the most probable CRC situations. If a CRC is found not to detect an 2102 erroneous header, then a different packet type with a larger CRC 2103 (such as the "normal" COMPRESSED packet) should be used instead or 2104 additional information could be sent (by using EXTENDED_COMPRESSED or 2105 DYNAMIC packets). To ensure reliability, the important thing is that 2106 the CRC must fail if the header is not correctly reconstructed. 2107 Combining the two factors described above gives a list of the most 2108 probable CRCs that MUST fail. 2110 - If ONE packet WAS lost, attempt one (no loss) MUST fail 2111 - If TWO packets WERE lost, attempt one (no loss) MUST fail 2112 - If TWO packets WERE lost, attempt two (one lost) MUST fail 2113 - If THREE packets WERE lost, attempt one (no loss) MUST fail 2114 - If THREE packets WERE lost, attempt two (one lost) MUST fail 2115 - If THREE packets WERE lost, attempt three (two lost) MUST fail 2116 - etc. 2118 By doing PRE-CALCULATIONS of the six CRCs that would be the result of 2119 the events listed above, the CRC can be kept strong enough, even with 2120 a reduced size, because CRCs likely to fail will be avoided. 2122 6.5. Using "guesses" with LSB and LSP encoding 2124 ROCCO profiles using LSP encoding can handle 25 consecutive packet 2125 losses without invalidating the context. LSB or LSP encoding is also 2126 used for other fields and the range handled is then much larger. 2127 However, for all LSP or LSB decoding, the range can be extended with 2128 multiples by making reconstruction attempts (also called "guesses"). 2129 The limiting factors are implementation complexity and time. The 2130 following example shows how this can be done: 2132 In chapter 5.3.2, LSP encoding is described. When an LSP encoded 2133 value for M code-points is decoded to a value S'(n), the original 2134 header can be reconstructed. If the CRC verification fails, a new 2135 reconstruction attempt could be made with S'(n)+M as the sequence 2136 number. If M was a multiple of 2 (LSB encoding), this would be the 2137 same as changing the value of the lowest MSB bit (i.e. the lowest bit 2138 NOT transmitted in LSB). More attempts could then be made increasing 2139 the sequence number by M for each attempt. 2141 7. Further work 2143 The ROCCO scheme, including the compression profiles optimized for 2144 conversational voice defined in this document, has been iterated and 2145 optimized for almost a year, and most of the desired functionality is 2146 today supported. However, much work remains before all details are 2147 settled. In addition to the tuning efforts, there are still new 2148 issues that should be investigated and implemented. This chapter 2149 elaborates on some ideas that might be sensible to apply to the 2150 scheme. 2152 7.1. Compression of IPv6 extension headers 2154 The ROCCO compression profiles defined in this document currently do 2155 not support compression of IPv6 extension headers, which is an 2156 undesirable limitation. Therefore, it is necessary to investigate 2157 what is really needed from the compression scheme regarding 2158 compression of extensions, and also to further develop the current 2159 and future compression profiles including the desired extension 2160 support. 2162 7.2. Efficient compression of CSRC lists 2164 The compression profiles defined in this document do support 2165 transmission of CSRC items, but this could probably be done in a much 2166 more efficient manner. Improved solutions for the CSRC compression 2167 would be preferable because if CSRC lists occur, the headers will be 2168 significantly expanded due to the size of the CSRC items. 2170 7.3. General, media independent profiles 2172 This document defines header compression profiles optimized for 2173 packet streams carrying conversational voice. Independently of packet 2174 stream characteristics, these profiles will successfully compress and 2175 decompress the headers of all IP/UDP/RTP packets. However, the 2176 compression may not be done in an optimal way. Therefore, general 2177 profiles should be designed that is optimized to handle 2178 uncharacterized or intermixed RTP packet streams as efficient as 2179 possible. 2181 8. Implementation status 2183 The ROCCO algorithm, as defined in previous versions of this Internet 2184 draft, has been implemented in a testbed environment for realtime IP 2185 traffic over wireless channels. In the testbed it is possible to 2186 listen to the effects of header compression in conjunction with 2187 packet losses. The currently implemented profiles are optimized for 2188 voice traffic only. A first rough estimate of the CPU utilization 2189 showed that ROCCO used only slightly more computational power than 2190 CRTP. On the other hand, with ROCCO the audio quality is 2191 significantly better. Figure 8.1 shows a block diagram of the testbed 2192 environment. 2194 +---------+ +---------------+ +----------+ +------------+ 2195 | Speech |-->| RTP/UDP/IP |-->| Wired IP |-->| Header |--> 2196 | Encoder | | Encapsulation | | Network | | Compressor | 2197 +---------+ +---------------+ +----------+ +------------+ 2199 +----------+ +--------------+ +---------+ 2200 ~~>| Cellular |~~>| Header De- |-->| Speech | 2201 | Link | | compressor | | Decoder | 2202 +----------+ +--------------+ +---------+ 2204 Figure 8.1 : Block diagram of testbed environment 2206 The implementation has made some impact on the ROCCO protocol, 2207 realized in this document. Continuously updated information about 2208 implementation status can be obtained from the ROCCO homepage: 2209 http://www.ludd.luth.se/users/larsman/rocco/ 2210 See also [PERF] for simulated performance results. 2212 9. Discussion and conclusions 2214 This document has presented ROCCO, a robust header compression 2215 protocol framework adaptable to various usage and requirements. In 2216 addition to the general framework, realizations of the scheme 2217 optimized for conversational voice packet streams have been presented 2218 together with performance results for these realizations. 2220 ROCCO uses CRCs to make local decompressor repairs of the context 2221 possible. Together with robust encoding methods for header fields, 2222 the usage of CRCs has made the scheme very robust and capable of 2223 coping with many consecutive packet losses (up to 25). One other 2224 important advantage with the CRC approach is that it makes the scheme 2225 reliable, meaning that it has a very low probability of incorrect 2226 header reconstruction and error propagation from the decompressor. 2228 ROCCO defines a concept with header compression profiles, which is an 2229 abstraction that merges all scheme parameters into one. There are two 2230 fundamental advantages with the profile concept. First of all, only 2231 one scheme parameter must be negotiated by the link layer between the 2232 compression and the decompression points and this requirement does 2233 not change even if new internal header compression parameters are 2234 later added with new realizations of the scheme. The second advantage 2235 is the possibility of optimizing the scheme completely for all 2236 situations and functionality requirements by using different 2237 profiles. 2239 Thanks to the profile concept, it has been possible to compress the 2240 headers down to a minimal size of 1 octet, the average header size 2241 being only 1.25 octets. As shown in [PERF], this is achieved without 2242 introducing any loss of packets due to invalid header compression 2243 context even over links with bit error rates as high as 1e-2. The 2244 probability of packet loss due to invalid header compression context 2245 is practically eliminated thanks to the robustness of ROCCO, even at 2246 the high BERs (1e-3 to 1e-2) a cellular system may produce. 2248 With the profiles defined today in this document and in a separate 2249 document for conversational video [ROVID], ROCCO can efficiently 2250 compress IP/UDP/RTP packet streams for both conversational voice and 2251 video. There are profiles defined for both IPv4 and IPv6, support for 2252 various numbers of concurrent packet streams, enabled or disabled UDP 2253 checksum, etc. Optimizations have been done to efficiently take care 2254 of the IPv4 Identification field and make it more compressible if 2255 knowledge about the sender's assignment policy can be obtained. 2256 Finally, it is also possible to tune the compression scheme to the 2257 characteristics of the channel it is used over. 2259 ROCCO has been evolved and improved during one year. Experiences from 2260 implementations have been taken into account in the process of 2261 improving the scheme. However, even if many suggestions for efficient 2262 implementations are included, there is still room for implementers to 2263 find even more efficient realizations. 2265 Hence, ROCCO provides at the present date a powerful toolbox for 2266 achieving efficient and robust header compression in various types of 2267 scenarios and over various types of links. ROCCO has also been proven 2268 to be suitable for cellular environments. 2270 10. Security considerations 2272 Because encryption eliminates the redundancy that header compression 2273 schemes try to exploit, there is some inducement to forego encryption 2274 in order to achieve operation over low-bandwidth links. However, for 2275 those cases where encryption of data (and not headers) is sufficient, 2276 RTP does specify an alternative encryption method in which only the 2277 RTP payload is encrypted and the headers are left in the clear. That 2278 would still allow header compression to be applied. 2280 A malfunctioning or malicious header compressor could cause the 2281 header decompressor to reconstitute packets that do not match the 2282 original packets but still have valid IP, UDP and RTP headers and 2283 possibly even valid UDP checksums. Such corruption may be detected 2284 with end-to-end authentication and integrity mechanisms which will 2285 not be affected by the compression. Further, this header compression 2286 scheme provides an internal checksum for verification of re- 2287 constructed headers. This reduces the probability of producing 2288 decompressed headers not matching the original ones without this 2289 being noticed. 2291 Denial-of-service attacks are possible if an intruder can introduce 2292 (for example) bogus STATIC, DYNAMIC or FEEDBACK packets onto the link 2293 and thereby cause compression efficiency to be reduced. However, an 2294 intruder having the ability to inject arbitrary packets at the link 2295 layer in this manner raises additional security issues that dwarf 2296 those related to the use of header compression. 2298 11. Acknowledgements 2300 When designing this protocol, earlier header compression ideas 2301 described in [CJHC], [IPHC] and [CRTP] have been important sources of 2302 knowledge. 2304 Thanks to Takeshi Yoshimura at NTT DoCoMo for providing the reverse 2305 decompression chapter (chapter 6.3). Thanks also to Anton Martensson 2306 for many valuable draft contributions and to Andreas Jonsson (Lulea 2307 University), who made a great job supporting this work in his study 2308 of header field change patterns. Thanks also to all others who have 2309 given comments. 2311 12. Intellectual property considerations 2313 This proposal in is conformity with RFC 2026. 2315 Telefonaktiebolaget LM Ericsson and its subsidiaries, in accordance 2316 with corporate policy, will for submissions rightfully made by its 2317 employees which are adopted or recommended as a standard by the IETF 2318 offer patent licensing as follows: 2320 If part(s) of a submission by Ericsson employees is (are) included in 2321 a standard and Ericsson has patents and/or patent application(s) that 2322 are essential to implementation of such included part(s) in said 2323 standard, Ericsson is prepared to grant - on the basis of reciprocity 2324 (grant-back) - a license on such included part(s) on reasonable, non- 2325 discriminatory terms and conditions. 2327 For the avoidance of doubt this general patent licensing undertaking 2328 applies to this proposal. 2330 13. References 2332 [UDP] Jon Postel, "User Datagram Protocol", RFC 768, August 1980. 2334 [IPv4] Jon Postel, "Internet Protocol", RFC 791, September 1981. 2336 [IPv6] Steven Deering, Robert Hinden, "Internet Protocol, Version 6 2337 (IPv6) Specification", RFC 2460, December 1998. 2339 [RTP] Henning Schulzrinne, Stephen Casner, Ron Frederick, Van 2340 Jacobson, "RTP: A Transport Protocol for Real-Time 2341 Applications", RFC 1889, January 1996. 2343 [HDLC] William Simpson, "PPP in HDLC-like framing", RFC 1662, 1994. 2345 [VJHC] Van Jacobson, "Compressing TCP/IP Headers for Low-Speed 2346 Serial Links", RFC 1144, February 1990. 2348 [IPHC] Mikael Degermark, Bjorn Nordgren, Stephen Pink, "IP Header 2349 Compression", RFC 2507, February 1999. 2351 [CRTP] Steven Casner, Van Jacobson, "Compressing IP/UDP/RTP Headers 2352 for Low-Speed Serial Links", RFC 2508, February 1999. 2354 [PPPHC] Mathias Engan, Steven Casner, Carsten Bormann, "IP Header 2355 Compression over PPP", RFC 2509, February 1999. 2357 [CRTPC] Mikael Degermark, Hans Hannu, Lars-Erik Jonsson, Krister 2358 Svanbro, "CRTP over cellular radio links", Internet Draft 2359 (work in progress), December 1999. 2360 2362 [CELL] Lars Westberg, Morgan Lindqvist, "Realtime traffic over 2363 cellular access networks", Internet Draft 2364 (work in progress), May 2000. 2365 2367 [ROVID] Anton Martensson, Torbjorn Einarsson, Lars-Erik Jonsson, 2368 "ROCCO Conversational Video Profiles", Internet Draft 2369 (work in progress), May 2000. 2370 2372 [PERF] Hans Hannu, Krister Svanbro, Lars-Erik Jonsson, "ROCCO 2373 Performance Evaluation", Internet Draft (work in progress), 2374 May 2000. 2375 2377 [LLG] Krister Svanbro, "Lower Layer Guidelines for Robust Header 2378 Compression", Internet Draft (work in progress), May 2000. 2379 2381 [WCDMA] "Universal Mobile Telecommunications System (UMTS); 2382 Selection procedures for the choice of radio transmission 2383 technologies of the UMTS (UMTS 30.03 version 3.1.0)". 2384 ETSI TR 101 112 V3.0.1, November 1997. 2386 14. Authors' addresses 2388 Lars-Erik Jonsson Tel: +46 920 20 21 07 2389 Ericsson Erisoft AB Fax: +46 920 20 20 99 2390 Box 920 Mobile: +46 70 554 82 71 2391 SE-971 28 Lulea, Sweden EMail: lars-erik.jonsson@ericsson.com 2393 Mikael Degermark Tel: +46 920 911 88 2394 Dept of CS & EE Fax: +46 920 728 01 2395 Lulea University of Technology Moblie: +46 70 833 89 33 2396 SE-971 87 Lulea EMail: micke@sm.luth.se 2398 Hans Hannu Tel: +46 920 20 21 84 2399 Ericsson Erisoft AB Fax: +46 920 20 20 99 2400 Box 920 Mobile: +46 70 559 90 15 2401 SE-971 28 Lulea, Sweden EMail: hans.hannu@ericsson.com 2403 Krister Svanbro Tel: +46 920 20 20 77 2404 Ericsson Erisoft AB Fax: +46 920 20 20 99 2405 Box 920 Mobile: +46 70 531 25 08 2406 SE-971 28 Lulea, Sweden EMail: krister.svanbro@ericsson.com 2408 Appendix A. Detailed classification of header fields 2410 Header compression is possible due to the fact that most header 2411 fields do not vary randomly from packet to packet. Many of the fields 2412 exhibit static behavior or changes in a more or less predictable way. 2413 When designing a header compression scheme, it is of fundamental 2414 importance to understand the behavior of the fields in detail. 2416 In this appendix, all IP, UDP and RTP header fields are classified 2417 and analyzed in two steps. First, we have a general classification in 2418 A.1 where the fields are classified based on stable knowledge and 2419 assumptions. The general classification does not take into account 2420 the change characteristics of changing fields because those will vary 2421 more or less depending on the implementation and on the application 2422 used. A less stable but more detailed analysis considering the change 2423 characteristics is then done in A.2. Finally, A.3 summarizes this 2424 appendix with conclusions about how the various header fields should 2425 be handled by the header compression scheme to optimize compression 2426 and functionality. 2428 A.1. General classification 2430 On a general level, the header fields are separated into 5 classes: 2432 INFERRED These fields contain values that can be inferred from 2433 other values, for example the size of the frame 2434 carrying the packet, and thus does not have to be 2435 handled at all by the compression scheme. 2437 STATIC These fields are expected to be constant throughout 2438 the lifetime of the packet stream. Static information 2439 must in some way be communicated once. 2441 STATIC-DEF STATIC fields whose values define a packet stream. 2442 They are in general handled as STATIC. 2444 STATIC-KNOWN These STATIC fields are expected to have well-known 2445 values and therefore do not need to be communicated 2446 at all. 2448 CHANGING These fields are expected to vary in some way, either 2449 randomly, within a limited value set or range, or in 2450 some other manner. 2452 In this section, each of the IP, UDP and RTP header fields is 2453 assigned to one of these classes. For all fields except those 2454 classified as CHANGING, the motives for the classification are also 2455 stated. CHANGING fields are in A.2 further examined and classified 2456 based on their expected change behavior. 2458 A.1.1. IPv6 header fields 2460 +---------------------+-------------+----------------+ 2461 | Field | Size (bits) | Class | 2462 +---------------------+-------------+----------------+ 2463 | Version | 4 | STATIC-KNOWN | 2464 | Traffic Class | 8 | CHANGING | 2465 | Flow Label | 20 | STATIC-DEF | 2466 | Payload Length | 16 | INFERRED | 2467 | Next Header | 8 | STATIC-KNOWN | 2468 | Hop Limit | 8 | CHANGING | 2469 | Source Address | 128 | STATIC-DEF | 2470 | Destination Address | 128 | STATIC-DEF | 2471 +---------------------+-------------+----------------+ 2473 Version 2475 The version field states which IP version the packet is based on. 2476 Packets with different values in this field must be handled by 2477 different IP stacks. For header compression, different compression 2478 profiles must also be used. When compressor and decompressor have 2479 negotiated which profile to use, the IP version is also known to 2480 both parties. The field is therefore classified as STATIC-KNOWN. 2482 Flow Label 2484 This field may be used to identify packets belonging to a specific 2485 packet stream. If not used, the value should be set to zero. 2486 Otherwise, all packets belonging to the same stream must have the 2487 same value in this field, it being one of the fields defining the 2488 stream. The field is therefore classified as STATIC-DEF. 2490 Payload Length 2492 Information about the packet length (and then also payload length) 2493 is expected to be provided by the link layer. The field is 2494 therefore classified as INFERRED. 2496 Next Header 2498 This field is expected to have the same value in all packets of a 2499 packet stream. As for the version number, a certain compression 2500 profile can only handle a specific next header which means that 2501 this value is known when profile has been negotiated. The field is 2502 therefore classified as STATIC-KNOWN. 2504 Source and Destination addresses 2506 These fields are part of the definition of a stream and must thus 2507 be constant for all packets in the stream. The fields are therefore 2508 classified as STATIC-DEF. 2510 Summarizing the bits corresponding to the classes gives: 2512 +--------------+--------------+ 2513 | Class | Size (octets)| 2514 +--------------+--------------+ 2515 | INFERRED | 2 | 2516 | STATIC-DEF | 34.5 | 2517 | STATIC-KNOWN | 1.5 | 2518 | CHANGING | 2 | 2519 +--------------+--------------+ 2521 A.1.2. IPv4 header fields 2523 +---------------------+-------------+----------------+ 2524 | Field | Size (bits) | Class | 2525 +---------------------+-------------+----------------+ 2526 | Version | 4 | STATIC-KNOWN | 2527 | Header Length | 4 | STATIC-KNOWN | 2528 | Type Of Service | 8 | CHANGING | 2529 | Packet Length | 16 | INFERRED | 2530 | Identification | 16 | CHANGING | 2531 | Reserved flag | 1 | STATIC-KNOWN | 2532 | May Fragment flag | 1 | STATIC | 2533 | Last Fragment flag | 1 | STATIC-KNOWN | 2534 | Fragment Offset | 13 | STATIC-KNOWN | 2535 | Time To Live | 8 | CHANGING | 2536 | Protocol | 8 | STATIC-KNOWN | 2537 | Header Checksum | 16 | INFERRED | 2538 | Source Address | 32 | STATIC-DEF | 2539 | Destination Address | 32 | STATIC-DEF | 2540 +---------------------+-------------+----------------+ 2542 Version 2544 The version field states which IP version the packet is based on 2545 and packets with different values in this field must be handled by 2546 different IP stacks. For header compression, different compression 2547 profiles must also be used. When compressor and decompressor has 2548 negotiated which profile to use, the IP version is also well known 2549 to both parties. The field is therefore classified as STATIC-KNOWN. 2551 Header Length 2553 As long as there are no options present in the IP header, the 2554 header length is constant and well known. If there are options, the 2555 fields would be STATIC, but we assume no options. The field is 2556 therefore classified as STATIC-KNOWN. 2558 Packet Length 2560 Information about the packet length is expected to be provided by 2561 the link layer. The field is therefore classified as INFERRED. 2563 Flags 2565 The Reserved flag must be set to zero and is therefore classified 2566 as STATIC-KNOWN. The May Fragment flag will be constant for all 2567 packets in a stream and is therefore classified as STATIC. Finally, 2568 the Last Fragment bit is expected to be zero because fragmentation 2569 is NOT expected, due to the small packet size expected. The Last 2570 Fragment bit is therefore classified as STATIC-KNOWN. 2572 Fragment Offset 2574 With the assumption that no fragmentation occurs, the fragment 2575 offset is always zero. The field is therefore classified as STATIC- 2576 KNOWN. 2578 Protocol 2580 This field is expected to have the same value in all packets of a 2581 packet stream. As for the version number, a certain compression 2582 profile can only handle a specific next header which means that 2583 this value is well known when profile has been negotiated. The 2584 field is therefore classified as STATIC-KNOWN. 2586 Header Checksum 2588 The header checksum protects individual hops from processing a 2589 corrupted header. When almost all IP header information is 2590 compressed away, there is no need to have this additional checksum; 2591 instead it can be regenerate at the decompressor side. The field is 2592 therefore classified as INFERRED. 2594 Source and Destination addresses 2596 These fields are part of the definition of a stream and must thus 2597 be constant for all packets in the stream. The fields are therefore 2598 classified as STATIC-DEF. 2600 Summarizing the bits corresponding to the classes gives: 2602 +--------------+--------------+ 2603 | Class | Size (octets)| 2604 +--------------+--------------+ 2605 | INFERRED | 4 | 2606 | STATIC | 1 bit | 2607 | STATIC-DEF | 8 | 2608 | STATIC-KNOWN | 3 +7 bits | 2609 | CHANGING | 4 | 2610 +--------------+--------------+ 2612 A.1.3. UDP header fields 2614 +------------------+-------------+-------------+ 2615 | Field | Size (bits) | Class | 2616 +------------------+-------------+-------------+ 2617 | Source Port | 16 | STATIC-DEF | 2618 | Destination Port | 16 | STATIC-DEF | 2619 | Length | 16 | INFERRED | 2620 | Checksum | 16 | CHANGING | 2621 +------------------+-------------+-------------+ 2623 Source and Destination ports 2625 These fields are part of the definition of a stream and must thus 2626 be constant for all packets in the stream. The fields are therefore 2627 classified as STATIC-DEF. 2629 Length 2631 This field is redundant and is therefore classified as INFERRED. 2633 Summarizing the bits corresponding to the classes gives: 2635 +------------+--------------+ 2636 | Class | Size (octets)| 2637 +------------+--------------+ 2638 | INFERRED | 2 | 2639 | STATIC-DEF | 4 | 2640 | CHANGING | 2 | 2641 +------------+--------------+ 2643 A.1.4. RTP header fields 2645 +-----------------+-------------+----------------+ 2646 | Field | Size (bits) | Class | 2647 +-----------------+-------------+----------------+ 2648 | Version | 2 | STATIC-KNOWN | 2649 | Padding | 1 | STATIC | 2650 | Extension | 1 | STATIC | 2651 | CSRC Counter | 4 | CHANGING | 2652 | Marker | 1 | CHANGING | 2653 | Payload Type | 7 | CHANGING | 2654 | Sequence Number | 16 | CHANGING | 2655 | Timestamp | 32 | CHANGING | 2656 | SSRC | 32 | STATIC-DEF | 2657 | CSRC | 0(-480) | CHANGING | 2658 +-----------------+-------------+----------------+ 2660 Version 2662 There exists only one working RTP version and that is version 2. 2663 The field is therefore classified as STATIC-KNOWN. 2665 Padding 2667 The use of this field depends on the application, but when payload 2668 padding is used it is likely to be present in all packets. The 2669 field is therefore classified as STATIC. 2671 Extension 2673 If RTP extensions is used by the application, it is likely to be an 2674 extension present in all packets (but use of extensions is very 2675 uncommon). However, for safety's sake this field is classified as 2676 STATIC and not STATIC-KNOWN. 2678 SSRC 2680 This field is part of the definition of a stream and must thus be 2681 constant for all packets in the stream. The field is therefore 2682 classified as STATIC-DEF. 2684 Summarizing the bits corresponding to the classes gives: 2686 +--------------+--------------+ 2687 | Class | Size (octets)| 2688 +--------------+--------------+ 2689 | STATIC | 2 bits | 2690 | STATIC-DEF | 4 | 2691 | STATIC-KNOWN | 2 bits | 2692 | CHANGING | 7.5(-67.5) | 2693 +--------------+--------------+ 2695 A.1.5. Summary for IP/UDP/RTP 2697 If we summarize this for IP/UDP/RTP we get: 2699 +----------------+--------------+--------------+ 2700 | Class \ IP ver | IPv6 (octets)| IPv4 (octets)| 2701 +----------------+--------------+--------------+ 2702 | INFERRED | 4 | 6 | 2703 | STATIC | 2 bits | 3 bits | 2704 | STATIC-DEF | 42.5 | 16 | 2705 | STATIC-KNOWN | 1 +6 bits | 4 +1 bit | 2706 | CHANGING | 11.5(-71.5) | 13.5(-73.5) | 2707 +----------------+--------------+--------------+ 2708 | Total | 60(-120) | 40(-100) | 2709 +----------------+--------------+--------------+ 2711 A.2. Analysis of change patterns of header fields 2713 To design suitable mechanisms for efficient compression of all header 2714 fields, their change patterns must be analyzed. For this reason, an 2715 extended classification is done based on the general classification 2716 in A.1, considering the fields which were labeled CHANGING in that 2717 classification. Different applications will use the fields in 2718 different ways, which may affect their behavior. When this is the 2719 case, typical behavior for conversational audio and video will be 2720 discussed. 2722 The CHANGING fields are separated into five different subclasses: 2724 STATIC These are fields that were classified as 2725 CHANGING on a general basis, but are classified 2726 as STATIC here due to certain additional 2727 assumptions. 2729 SEMISTATIC These fields are STATIC most of the time. 2730 However, occasionally the value changes but 2731 reverts to its original value after a known 2732 number of packets. 2734 RARELY-CHANGING (RC) These are fields that change their values 2735 occasionally and then keep their new values. 2737 ALTERNATING These fields alternate between a small number 2738 of different values. 2740 IRREGULAR These, finally, are the fields for which no 2741 useful change pattern can be identified. 2743 To further expand the classification possibilities without increasing 2744 complexity, the classification can be done either according to the 2745 values of the field and/or according to the values of the deltas for 2746 the field. 2748 When the classification is done, other details are also stated 2749 regarding possible additional knowledge about the field values and/or 2750 field deltas, according to the classification. For fields classified 2751 as STATIC or SEMISTATIC, the case could be that the value of the 2752 field is not only STATIC but also well KNOWN a priori (two states for 2753 SEMISTATIC fields). For fields with non-irregular change behavior, it 2754 could be known that changes usually are within a LIMITED range 2755 compared to the maximal change for the field. For other fields, the 2756 values are completely UNKNOWN. 2758 Table A.1 classifies all the CHANGING fields based on their expected 2759 change patterns, especially for conversational audio and video. 2761 +------------------------+-------------+-------------+-------------+ 2762 | Field | Value/Delta | Class | Knowledge | 2763 +========================+=============+=============+=============+ 2764 | Sequential | Delta | STATIC | KNOWN | 2765 | -----------+-------------+-------------+-------------+ 2766 | IPv4 Id: Seq. jump | Delta | RC | LIMITED | 2767 | -----------+-------------+-------------+-------------+ 2768 | Random | Value | IRREGULAR | UNKNOWN | 2769 +------------------------+-------------+-------------+-------------+ 2770 | IP TOS / Tr. Class | Value | RC | UNKNOWN | 2771 +------------------------+-------------+-------------+-------------+ 2772 | IP TTL / Hop Limit | Value | ALTERNATING | LIMITED | 2773 +------------------------+-------------+-------------+-------------+ 2774 | Disabled | Value | STATIC | KNOWN | 2775 | UDP Checksum: ---------+-------------+-------------+-------------+ 2776 | Enabled | Value | IRREGULAR | UNKNOWN | 2777 +------------------------+-------------+-------------+-------------+ 2778 | No mix | Value | STATIC | KNOWN | 2779 | RTP CSRC Count: -------+-------------+-------------+-------------+ 2780 | Mixed | Value | RC | LIMITED | 2781 +------------------------+-------------+-------------+-------------+ 2782 | RTP Marker | Value | SEMISTATIC | KNOWN/KNOWN | 2783 +------------------------+-------------+-------------+-------------+ 2784 | RTP Payload Type | Value | RC | UNKNOWN | 2785 +------------------------+-------------+-------------+-------------+ 2786 | RTP Sequence Number | Delta | STATIC | KNOWN | 2787 +------------------------+-------------+-------------+-------------+ 2788 | RTP Timestamp | Delta | RC | LIMITED | 2789 +------------------------+-------------+-------------+-------------+ 2790 | No mix | - | - | - | 2791 | RTP CSRC List: -------+-------------+-------------+-------------+ 2792 | Mixed | Value | RC | UNKNOWN | 2793 +------------------------+-------------+-------------+-------------+ 2795 Table A.1 : Classification of CHANGING header fields 2797 The following subsections discuss the various header fields in 2798 detail. Note that table A.1 and the discussions below do not consider 2799 changes caused by loss or reordering before the compression point. 2801 A.2.1. IPv4 Identification 2803 The Identification field (IP ID) of the IPv4 header is there to 2804 identify which fragments constitute a datagram when reassembling 2805 fragmented datagrams. The IPv4 specification does not specify exactly 2806 how this field is to be assigned values, only that each packet should 2807 get an IP ID that is unique for the source-destination pair and 2808 protocol for the time the datagram (or any of its fragments) could be 2809 alive in the network. This means that assignment of IP ID values can 2810 be done in various ways, which we have separated into three classes. 2812 Sequential 2814 This assignment policy keeps a separate counter for each outgoing 2815 packet stream and thus the IP ID value will increment by one for 2816 each packet in the stream. Therefore, the delta value of the 2817 field is constant and well known a priori. When RTP is used on 2818 top of UDP and IP, the IP ID value follows the RTP sequence 2819 number. This assignment policy is the most desirable for header 2820 compression purposes but its usage is not as common as it should 2821 be. The reason is that it can be realized only if UDP and IP are 2822 implemented together so that UDP, which separates packet streams 2823 by the port identification, can make IP use separate ID counters 2824 for each packet stream. 2826 Sequential jump 2828 This is the most common assignment policy in today's IP stacks. 2829 The difference from the sequential method is that only one 2830 counter is used for all connections. When the sender is running 2831 more than one packet stream simultaneously, the IP ID can 2832 increase by more than one. The IP ID values will be much more 2833 predictable and require less bits to transfer than random values, 2834 and the packet-to-packet increment (determined by the number of 2835 active outgoing packet streams and sending frequencies) will 2836 usually be limited. 2838 Random 2840 Some IP stacks assign IP ID values using a pseudo-random number 2841 generator. There is thus no correlation between the ID values of 2842 subsequent datagrams. Therefore there is no way to predict the IP 2843 ID value for the next datagram. For header compression purposes, 2844 this means that the IP ID field needs to be sent uncompressed 2845 with each datagram, resulting in two extra octets of header. IP 2846 stacks in cellular terminals SHOULD NOT use this IP ID assignment 2847 policy. 2849 It should be noted that the ID is an IPv4 mechanism and is therefore 2850 not needed at all in IPv6 profiles. For IPv4 the ID could be handled 2851 in three different ways. Firstly, we have the inefficient but 2852 reliable solution where the ID field is sent as-is in all packets, 2853 increasing the compressed headers with two octets. This is the best 2854 way to handle the ID field if the sender uses random assignment of 2855 the ID field. Secondly, there can be solutions with more flexible 2856 mechanisms requiring less bits for the ID handling as long as 2857 sequential jump assignment is used. Such solutions will probably 2858 require even more bits if random assignment is used by the sender. 2859 Knowledge about the sender's assignment policy could therefore be 2860 useful when choosing between the two solutions above. Finally, even 2861 for IPv4, header compression could be designed without any additional 2862 information for the ID field included in compressed headers. To use 2863 such schemes, it must be known that the sender makes use of the pure 2864 sequential assignment policy for the ID field. That might not be 2865 possible to know, which implies that the applicability of such 2866 solutions is very uncertain. However, designers of IPv4 stacks for 2867 cellular terminals SHOULD use the sequential policy. 2869 A.2.2. IP Traffic-Class / Type-Of-Service 2871 The Traffic-Class (IPv6) or Type-Of-Service (IPv4) field is expected 2872 to be constant during the lifetime of a packet stream or to change 2873 relatively seldom. 2875 A.2.3. IP Hop-Limit / Time-To-Live 2877 The Hop-Limit (IPv6) or Time-To-Live (IPv4) field is expected to be 2878 constant during the lifetime of a packet stream or to alternate 2879 between a limited number of values due to route changes. 2881 A.2.4. UDP Checksum 2883 The UDP checksum is optional. If disabled, its value is constantly 2884 zero and could be compressed away. If enabled, its value depends on 2885 the payload, which for compression purposes is equivalent to it 2886 changing randomly with every packet. 2888 A.2.5. RTP CSRC Counter 2890 This is a counter indicating the number of CSRC items present in the 2891 CSRC list. This number is expected to be almost constant on a packet- 2892 to-packet basis and change by small amount. As long as no RTP mixer 2893 is used, the value of this field is zero. 2895 A.2.6. RTP Marker 2897 For audio the marker bit should be set only in the first packet of a 2898 talkspurt while for video it should be set in the last packet of 2899 every picture. This means that in both cases the RTP marker is 2900 classified as SEMISTATIC with well-known values for both states. 2902 A.2.7. RTP Payload Type 2904 Changes of the RTP payload type within a packet stream are expected 2905 to be rare. Applications could adapt to congestion by changing 2906 payload type and/or frame sizes, but that is not expected to happen 2907 frequently. 2909 A.2.8. RTP Sequence Number 2911 The RTP sequence number will be incremented by one for each packet 2912 sent. 2914 A.2.9. RTP Timestamp 2916 In the audio case: 2918 As long as there are no pauses in the audio stream, the RTP 2919 timestamp will be incremented by a constant delta, corresponding 2920 to the number of samples in the speech frame. It will thus mostly 2921 follow the RTP sequence number. When there has been a silent 2922 period and a new talkspurt begins, the timestamp will jump in 2923 proportion to the length of the silent period. However, the 2924 increment will probably be within a relatively limited range. 2926 In the video case: 2928 The timestamp change between two consecutive packets will either 2929 be zero or increase by a multiple of a fixed value corresponding 2930 to the picture clock frequency. The timestamp can also decrease 2931 by a multiple of the fixed value if B-pictures are used. The 2932 delta interval, expressed as a multiple of the picture clock 2933 frequency, is in most cases very limited. 2935 A.2.10. RTP Contributing Sources (CSRC) 2937 The participants in a session, which are identified by the CSRC 2938 fields, are expected to be almost the same on a packet-to-packet 2939 basis with relatively few additions or removals. As long as RTP 2940 mixers are not used, no CSRC fields are present at all. 2942 A.3. Header compression strategies 2944 This section elaborates on what has been done in previous sections. 2945 Based in the classifications, recommendations are given on how to 2946 handle the various fields in the header compression process. Seven 2947 different actions are possible and these are listed together with the 2948 fields to which each action applies. 2950 A.3.1. Do not send at all 2952 The fields that have well known values a priori do not have to be 2953 sent at all. These are: 2955 - IP Version 2956 - IPv6 Payload Length 2957 - IPv6 Next Header 2958 - IPv4 Header Length 2959 - IPv4 Reserved Flag 2960 - IPv4 Last Fragment Flag 2961 - IPv4 Fragment Offset 2962 - IPv4 Protocol 2963 - UDP Checksum (if disabled) 2964 - RTP Version 2966 A.3.2. Transmit only initially 2968 The fields that are constant throughout the lifetime of the packet 2969 stream have to be transmitted and correctly delivered to the 2970 decompressor only once. These are: 2972 - IP Source Address 2973 - IP Destination Address 2974 - IPv6 Flow Label 2975 - IPv4 May Fragment Flag 2976 - UDP Source Port 2977 - UDP Destination Port 2978 - RTP Padding Flag 2979 - RTP Extension Flag 2980 - RTP SSRC 2982 A.3.3. Transmit initially, but be prepared to update occasionally 2984 The fields that are changing only occasionally must be transmitted 2985 initially but there must also be a way to update these fields with 2986 new values if they change. These fields are: 2988 - IPv6 Traffic Class 2989 - IPv6 Hop Limit 2990 - IPv4 Type Of Service (TOS) 2991 - IPv4 Time To Live (TTL) 2992 - RTP CSRC Counter 2993 - RTP Payload Type 2994 - RTP CSRC List 2996 A.3.4. Be prepared to update or send as-is frequently 2998 For fields that normally are either constant or whose values can be 2999 deduced from some other field but frequently diverge from that 3000 behavior, there must be an efficient way to update the field value or 3001 send it as-is in some packets. Those fields are: 3003 - IPv4 Identification (if not sequentially assigned) 3004 - RTP Marker 3005 - RTP Timestamp 3007 A.3.5. Guarantee continuous robustness 3009 Fields that behave like a counter with a fixed delta for ALL packets, 3010 the only requirement on the transmission encoding is that packet 3011 losses between compressor and decompressor must be tolerable. If more 3012 than one such field exists, all these can be communicated together. 3013 Such fields can also be used to interpret the values for fields 3014 listed in the previous section. Fields that have this counter 3015 behavior are: 3017 - IPv4 Identification (if sequentially assigned) 3018 - RTP Sequence Number 3020 A.3.6. Transmit as-is in all packets 3022 Fields that have completely random values for each packet must be 3023 included as-is in all compressed headers. Those fields are: 3025 - IPv4 Identification (if randomly assigned) 3026 - UDP Checksum (if enabled) 3028 A.3.7. Establish and be prepared to update delta 3030 Finally, there is a field that is usually increasing by a fixed delta 3031 and is correlated to another field. For this field it would make 3032 sense to make that delta part of the context state. The delta must 3033 then be possible to initiate and update in the same way as the fields 3034 listed in A.3.3. The field to which this applies is: 3036 - RTP Timestamp 3037 This Internet-Draft expires December 15, 2000.