idnits 2.17.1 draft-jonsson-robust-hc-04.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. ** The abstract seems to contain references ([CRTP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (March 10, 2000) is 8784 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 2468, but not defined == Unused Reference: 'HDLC' is defined on line 2510, 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. 'WCDMA' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Lars-Erik Jonsson, Ericsson 2 INTERNET-DRAFT Mikael Degermark, Lulea University 3 Expires: September 2000 Hans Hannu, Ericsson 4 Krister Svanbro, Ericsson 5 Sweden 6 March 10, 2000 8 RObust Checksum-based header COmpression (ROCCO) 9 11 Status of this memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/lid-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This document is an individual submission to the IETF. Comments 32 should be directed to the authors. 34 Abstract 36 IP/UDP/RTP header compression [CRTP] can generate a large number of 37 lost packets when used over links with significant error rates, 38 especially when the round-trip time of the link is long. 40 This document describes a more robust header compression scheme. The 41 scheme is adaptable to the characteristics of the link over which it 42 is used and also to the properties of the packet streams it 43 compresses. Robustness against link loss is achieved without 44 decreasing compression efficiency. 46 Table of contents 48 1. Introduction..................................................5 49 2. Terminology...................................................6 50 3. Existing header compression schemes...........................9 51 4. Desired improvements.........................................11 52 5. Proposed solution............................................11 53 5.1. Header compression framework..........................12 54 5.2. General ROCCO principles..............................12 55 5.3. Data structures.......................................13 56 5.4. Header compression profiles...........................13 57 5.5. Profile negotiation...................................14 58 5.6. Link layer requirements...............................15 59 6. Classification of header fields..............................15 60 7. Header compression profiles for IP telephony packet streams..16 61 7.1. Usage scenarios, environment and requirements.........16 62 7.2. Analysis of change patterns of header fields..........17 63 7.2.1. IPv4 Identification..........................19 64 7.2.2. IP Traffic-Class / Type-Of-Service...........20 65 7.2.3. IP Hop-Limit / Time-To-Live..................20 66 7.2.4. UDP Checksum.................................20 67 7.2.5. RTP CSRC Counter.............................20 68 7.2.6. RTP Marker...................................21 69 7.2.7. RTP Payload Type.............................21 70 7.2.8. RTP Sequence Number..........................21 71 7.2.9. RTP Timestamp................................21 72 7.2.10. RTP Contributing Sources (CSRC)..............21 73 7.3. Profile definitions...................................21 74 7.3.1. List of defined profiles.....................21 75 7.3.2. Additional common profile characteristics....24 76 7.4. Encoding methods used.................................24 77 7.4.1. Least Significant Bits (LSB) encoding........25 78 7.4.2. Least Significant Part (LSP) encoding........25 79 7.5. Packet formats........................................26 80 7.5.1. Static information packets, initialization...27 81 7.5.2. Dynamic information packets..................28 82 7.5.3. Compressed packets...........................31 83 7.5.4. Minimal compressed headers...................31 84 7.5.5. Extensions to compressed headers.............32 85 7.5.6. Feedback packets.............................37 86 7.6. Interpretations of the code field.....................39 87 7.7. Encoding of field values..............................40 88 7.7.1. LSP encoding of field values.................40 89 7.7.2. LSB encoding of field values.................40 90 7.7.3. Sequence encoding with no information........41 91 7.8. Header compression CRCs, coverage and polynomials.....41 92 7.8.1. STATIC packet CRC............................41 93 7.8.2. DYNAMIC packet CRC...........................41 94 7.8.3. COMPRESSED packet CRCs.......................42 96 8. Implementation issues........................................42 97 8.1. Feedback and context update procedures................42 98 8.2. ROCCO over simplex links..............................42 99 8.2.1. Compression slow-start.......................43 100 8.2.2. Periodic refresh.............................43 101 8.2.3. Refresh recommendations......................44 102 8.2.4. Cost and robustness of refreshes.............44 103 8.2.5. Simplex link improvements....................45 104 8.3. Pre-verification of CRCs..............................45 105 8.4. Using "guesses" with LSB and LSP encoding.............46 106 9. Further work.................................................47 107 9.1. Timer-based timestamp reconstruction..................47 108 9.2. Compression of IPv6 extension headers.................48 109 9.3. Replacement of the UDP checksum.......................49 110 9.4. Efficient compression of CSRC lists...................49 111 9.5. General, media independent profiles...................49 112 10. Implementation status........................................50 113 11. Discussion and conclusions...................................50 114 12. Security considerations......................................51 115 13. Acknowledgements.............................................52 116 14. Intellectual property considerations.........................52 117 15. References...................................................53 118 16. Authors' addresses...........................................54 120 Appendix A. Detailed classification of header fields............55 121 A.1. IPv6 header fields....................................55 122 A.2. IPv4 header fields....................................56 123 A.3. UDP header fields.....................................58 124 A.4. RTP header fields.....................................59 125 A.5. Summary...............................................60 127 Appendix B. Simulated performance results.......................61 128 B.1. Simulated scenario....................................61 129 B.2. Input data............................................61 130 B.3. Influence of pre-HC links.............................61 131 B.4. Used link layers......................................62 132 B.5. The cellular link.....................................62 133 B.6. Compression performance...............................62 134 B.7. Robustness results....................................64 135 B.8. CRC strength considerations...........................66 137 Document history 139 00 1999-06-22 First release. 141 01 1999-09-01 Only small corrections and modifications. Cut-and- 142 paste errors from the 00 draft removed. 144 02 1999-10-22 Generalized concept with a number of different 145 profiles. New chapters added describing profile 146 negotiation, implementation status and security. 148 03 2000-01-18 LSP encoding and one-octet profiles introduced. 149 Modified and simplified extension formats and 150 small changes in the CONTEXT_REQUEST packets. 152 04 2000-03-10 The CONTEXT_UPDATE packet has changed its name to 153 DYNAMIC while also being slightly modified. Both 154 the STATIC and the DYNAMIC packet now include a 155 header compression CRC of 8 bits to ensure 156 reliability of the scheme. Some profiles have been 157 modified, some renumbered, some removed and some 158 added. The CONTEXT_REQUEST packet has been replaced 159 by a more general FEEDBACK packet type with several 160 sub-types including three that leaves much room for 161 implementation features. The profile definitions 162 have been improved in many ways with more details 163 and clarifications. New chapters have been added 164 discussing implementation issues and possible 165 further work. New simulation results are included in 166 an appendix. 168 1. Introduction 170 During the last five years, two communication technologies in 171 particular have become commonly used by the general public: cellular 172 telephony and the Internet. Cellular telephony has provided its users 173 with the revolutionary possibility of always being reachable with 174 reasonable service quality no matter where they are. However, until 175 now the main service provided has been speech. With the Internet, the 176 conditions have been almost the opposite. While flexibility for all 177 kinds of usage has been its strength, its focus has been on fixed 178 connections and large terminals, and the experienced quality of some 179 services (such as Internet telephony) has generally been low. 181 Today, IP telephony is gaining momentum thanks to improved technical 182 solutions. It seems reasonable to believe that in the years to come, 183 IP will become a commonly used way to carry telephony. Some future 184 cellular telephony links might also be based on IP and IP telephony. 185 Cellular phones may have IP stacks supporting not only audio and 186 video, but also web browsing, email, gaming, etc. 188 The scenario we are envisioning might then be the one in Figure 1.1, 189 where two mobile terminals are communicating with each other. Both 190 are connected to base stations over cellular links, and the base 191 stations are connected to each other through a wired (or possibly 192 wireless) network. Instead of two mobile terminals, there could of 193 course be one mobile and one wired terminal, but the case with two 194 cellular links is technically more demanding. 196 Mobile Base Base Mobile 197 Terminal Station Station Terminal 199 | ~ ~ ~ \ / \ / ~ ~ ~ ~ | 200 | | | | 201 +--+ | | +--+ 202 | | | | | | 203 | | | | | | 204 +--+ | | +--+ 205 | | 206 |=========================| 208 Cellular Wired Cellular 209 Link Network Link 211 Figure 1.1 : Scenario for IP telephony over cellular links 213 It is obvious that the wired network can be IP-based. With the 214 cellular links, the situation is less clear. IP could be terminated 215 in the fixed network, and special solutions implemented for each 216 supported service over the cellular link. However, this would limit 217 the flexibility of the services supported. If technically and 218 economically feasible, a solution with pure IP all the way from 219 terminal to terminal would have certain advantages. However, to make 220 IP-all-the-way a viable alternative, a number of problems have to be 221 addressed, especially regarding bandwidth efficiency. 223 For cellular phone systems, it is of vital importance to use the 224 scarce radio resources in an efficient way. A sufficient number of 225 users per cell is crucial, otherwise deployment costs will be 226 prohibitive [CELL]. The quality of the voice service should also be 227 as good as in today's cellular systems. It is likely that even with 228 support for new services, lower quality of the voice service is 229 acceptable only if costs are significantly reduced. 231 A problem with IP over cellular links when used for interactive voice 232 conversations is the large header overhead. Speech data for IP 233 telephony will most likely be carried by RTP [RTP]. A packet will 234 then, in addition to link layer framing, have an IP [IPv4] header (20 235 octets), a UDP [UDP] header (8 octets), and an RTP header (12 octets) 236 for a total of 40 octets. With IPv6 [IPv6], the IP header is 40 237 octets for a total of 60 octets. The size of the payload depends on 238 the speech coding and frame sizes used and may be as low as 15-20 239 octets. 241 From these numbers, the need for reducing header sizes for efficiency 242 reasons is obvious. However, cellular links have characteristics that 243 make header compression as defined in [IPHC,CRTP,PPPHC] perform less 244 than well. The most important characteristic is the lossy behavior of 245 cellular links, where a bit error rate (BER) as high as 1e-3 must be 246 accepted to keep the radio resources efficiently utilized [CELL]. In 247 severe operating situations, the BER can be as high as 1e-2. The 248 other problematic characteristic is the long round-trip time (RTT) of 249 the cellular link, which can be as high as 100-200 milliseconds 250 [CELL]. A viable header compression scheme for cellular links must be 251 able to handle loss on the link between the compression and 252 decompression point as well as loss before the compression point. 254 Bandwidth is the most costly resource in cellular links. Processing 255 power is very cheap in comparison. Implementation or computational 256 simplicity of a header compression scheme is therefore of less 257 importance than its compression ratio and robustness. 259 2. Terminology 261 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 262 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 263 document are to be interpreted as described in RFC 2119. 265 BER 267 Bit Error Rate. Cellular radio links have a rather high BER. In 268 this document BER is usually given as a frequency, but one also 269 needs to consider the error distribution as bit errors are not 270 independent. In our simulations we use a channel with a certain 271 BER, and the error distribution is according to a realistic channel 272 [WCDMA]. 274 Cellular links 276 Wireless links between mobile terminals and base stations. The BER 277 and the RTT are rather high in order to achieve an efficient system 278 overall. 280 Compression efficiency 282 The performance of a header compression scheme can be described 283 with two parameters, compression efficiency and robustness. The 284 compression efficiency is determined by how much header sizes are 285 reduced by the compression scheme. 287 Context 289 The context is the state which the compressor uses to compress a 290 header and which the decompressor uses to decompress a header. The 291 context is basically the uncompressed version of the last header 292 sent (compressor) or received (decompressor) over the link, except 293 for fields in the header that are included "as-is" in compressed 294 headers or can be inferred from, e.g., the size of the link-level 295 frame. The context can also contain additional information 296 describing the packet stream, for example the typical inter-packet 297 increase in sequence numbers or timestamps. 299 Context damage 301 When the context of the decompressor is not consistent with the 302 context of the compressor, header decompression will fail. This 303 situation can occur when the context of the decompressor has not 304 been initialized properly or when packets have been lost or damaged 305 between compressor and decompressor. Packets which cannot be 306 decompressed due to inconsistent contexts are said to be lost due 307 to context damage. 309 Context repair mechanism 311 To avoid excessive context damage, a context repair mechanism is 312 needed. Context repair mechanisms can be based on explicit requests 313 for context updates, periodic updates sent by the compressor, or 314 methods for local repair at the decompressor side. 316 FER 318 Frame Error Rate. The FER considered in this document includes the 319 frames lost on the channel between compressor and decompressor and 320 frames lost due to context damage. FER is here defined to be 321 identical to packet loss rate. 323 Header compression profile 325 A header compression profile is a specification of how to compress 326 the headers of a certain kind of packet stream over a certain kind 327 of link. Compression profiles provide the details of the header 328 compression framework introduced in this document. The profile 329 concept makes use of profile identifiers to separate different 330 profiles which, are used when setting up the compression scheme. 331 All variations and parameters of the header compression scheme are 332 handled by different profile identifiers, which makes the number of 333 profiles rather large. This can act as a deterrent when first 334 studying the concept, but is a real strength for several reasons. 335 One advantage of this merging of parameters into one is that new 336 parameters can be added by the endpoints without affecting the 337 negotiation requirements on the link in between. Another benefit of 338 the concept is that different combinations of functionality might 339 be implemented with different methods, meaning that the scheme can 340 be optimized regardless of what functionality is enabled. Finally, 341 it should be noted that even if there are a large number of 342 profiles, only a small number of them can/will be implemented over 343 a specific link (IPv4 and IPv6 profiles will for example probably 344 not coexist). Most profiles usable in a certain environment will 345 probably also be almost identical from an implementation point of 346 view. 348 Header compression CRC 350 A CRC computed by the compressor and included in each compressed 351 header. Its main purpose is to provide a way for the decompressor 352 to reliably verify the correctness of reconstructed headers. What 353 values the CRC is computed over depends on the packet type it is 354 included in; typically it covers most of the original header 355 fields. 357 Pre-HC links 359 Pre-HC links are all links before the header compression point. If 360 we consider a path with cellular links as first and last hops, the 361 Pre-HC links for the compressor at the last link are the first 362 cellular link plus the wired links in between. 364 Robustness 366 The performance of a header compression scheme can be described 367 with two parameters, compression efficiency and robustness. A 368 robust scheme tolerates errors on the link over which header 369 compression takes place without losing additional packets, 370 introducing additional errors, or using more bandwidth. 372 Spectrum efficiency 374 Radio resources are limited and expensive. Therefore they must be 375 used efficiently to make the system economically feasible. In 376 cellular systems this is achieved by maximizing the number of users 377 served within each cell, while the quality of the provided services 378 is kept at an acceptable level. A consequence of efficient spectrum 379 use is a high BER, even after channel coding with error correction. 381 Timestamp delta 383 The timestamp delta is the increase in the timestamp value between 384 two consecutive packets. 386 3. Existing header compression schemes 388 The original header compression scheme, CTCP [VJHC], was invented by 389 Van Jacobson. CTCP compressed the 40 octet IP+TCP header to 4 octets. 391 Header compression methods maintain a context, which is essentially 392 the uncompressed version of the last header sent over the link, at 393 both compressor and decompressor. Compression and decompression are 394 done relative to the context. When compressed headers carry 395 differences from the previous header, each compressed header will 396 update the context of the decompressor. When a packet is lost between 397 compressor and decompressor, the context of the decompressor will be 398 brought out of sync since it is not updated correctly. A header 399 compression method must have a way to repair the context, i.e. bring 400 it into sync, after such events. 402 The CTCP compressor detects transport-level retransmissions and sends 403 a header that updates the context completely when they occur. This 404 repair mechanism does not require any explicit signaling between 405 compressor and decompressor. 407 CRTP [CRTP, IPHC] by Casner and Jacobson is a header compression 408 scheme that compresses 40 octets of IPv4/UDP/RTP headers to a minimum 409 of 2 octets when no UDP checksum is present. If the UDP checksum is 410 present, the minimum CRTP header is 4 octets. CRTP cannot use the 411 same repair mechanism as CTCP since UDP/RTP does not retransmit. 412 Instead, CRTP uses explicit signaling messages from decompressor to 413 compressor, called CONTEXT_STATE messages, to indicate that the 414 context is out of sync. The link roundtrip time will thus limit the 415 speed of this context repair mechanism. 417 On lossy links with long roundtrip times, such as most cellular 418 links, CRTP does not perform well. Each lost packet over the link 419 causes several subsequent packets to be lost since the context is out 420 of sync during at least one link roundtrip time. This behavior is 421 documented in [CRTPC]. For voice conversations such long loss events 422 will degrade the voice quality. Moreover, bandwidth is wasted by the 423 large headers sent by CRTP when updating the context. [CRTPC] found 424 that CRTP performed much worse than ideally for a lossy cellular 425 link. It is clear that CRTP alone is not a viable header compression 426 scheme for cellular links. 428 To avoid losing headers due to the context being out of sync, CRTP 429 decompressors can attempt to repair the context locally by using a 430 mechanism known as TWICE. Each CRTP packet contains a counter which 431 is incremented by one for each packet sent out by the CRTP 432 compressor. If the counter increases by more than one, at least one 433 packet was lost over the link. The decompressor then attempts to 434 repair the context by guessing how the lost packet(s) would have 435 updated it. The guess is then verified by decompressing the packet 436 and checking the UDP checksum - if it succeeds, the repair is deemed 437 successful and the packet can be forwarded or delivered. TWICE has 438 got its name from the observation that when the compressed packet 439 stream is regular, the correct guess is to apply the update in the 440 current packet twice. [CRTPC] found that even with TWICE, CRTP 441 doubled the number of lost packets. TWICE improves CRTP performance 442 significantly. However, there are several problems with using TWICE: 444 1) It becomes mandatory to use the UDP checksum: 446 - the minimal compressed header size increases by 100% to 4 447 octets. 449 - most speech codecs developed for cellular links tolerate errors 450 in the encoded data. Such codecs will not want to enable the UDP 451 checksum, since they want damaged packets to be delivered. 453 - errors in the payload will make the UDP checksum fail when the 454 guess is correct (and might make it succeed when it is wrong). 456 2) Loss in an RTP stream that occurs before the compression point 457 will make updates in CRTP headers less regular. Simple-minded 458 versions of TWICE will then perform badly. More sophisticated 459 versions would need more repair attempts to succeed. 461 4. Desired improvements 463 The major problem with CRTP is that it is not sufficiently robust 464 against packets being damaged between compressor and decompressor. A 465 viable header compression scheme must be less fragile. This increased 466 robustness must be obtained without increasing the compressed header 467 size; a larger header would make IP telephony over cellular links 468 economically unattractive. 470 A major cause of the bad performance of CRTP over cellular links is 471 the long link roundtrip time, during which many packets are lost when 472 the context is out of sync. This problem can be attacked directly by 473 finding ways to reduce the link roundtrip time. Future generations of 474 cellular technologies may indeed achieve lower link roundtrip times. 475 However, these will probably always be rather high [CELL]. The 476 benefits in terms of lower loss and smaller bandwidth demands if the 477 context can be repaired locally will be present even if the link 478 roundtrip time is decreased. A reliable way to detect a successful 479 context repair is then needed. 481 One might argue that a better way to solve the problem is to improve 482 the cellular link so that packet loss is less likely to occur. It 483 would of course be nice if the links were almost error free, but such 484 a system would not be able to support a sufficiently large number of 485 users per cell and would thus be economically unfeasible [CELL]. 487 One might also argue that the speech codecs should be able to deal 488 with the kind of packet loss induced by CRTP, in particular since the 489 speech codecs probably must be able to deal with packet loss anyway 490 if the RTP stream crosses the Internet. While the latter is true, the 491 kind of loss induced by CRTP is difficult to deal with. It is usually 492 not possible to hide a loss event where well over 100 ms worth of 493 sound is completely lost. If such loss occurs frequently at both ends 494 of the path, the speech quality will suffer. 496 5. Proposed solution 498 We propose a solution which is heavily geared towards local repair of 499 the context. What is needed is a reliable way to detect when a repair 500 attempt has succeeded, plus possibly hints to the decompressor about 501 how the header fields have changed. 503 The key element of our header compression scheme is that compressed 504 headers should carry a CRC computed over the header before 505 compression. This provides a reliable way to detect whether 506 decompression and context repair have succeeded. In addition to the 507 CRC, the header could contain codes and additional information as 508 needed for decompression. 510 A completely general solution cannot achieve compression rates high 511 enough to make IP telephony over cellular economically feasible. On 512 the other hand, the solution needs to be extendable so that other 513 kinds of packet streams can also be compressed well. Therefore, we 514 envision a scheme where the basic framework is supplemented with a 515 set of compression profiles, where each compression profile provides 516 the exact details on how a packet stream is to be compressed and 517 decompressed. The use of compression profiles allows the basic 518 framework to be adapted to the properties of packet streams as well 519 as various link properties. 521 5.1. Header compression framework 523 The ROCCO header compression framework does not state any exact 524 details about how the compression is to be performed, what formats 525 the headers should have, etc. This is left to the compression 526 profiles to define. The framework instead describes general 527 principles for how to do header compression "the ROCCO way". The 528 header compression profile concept is presented describing what a 529 profile is, what to consider when designing a profile and what every 530 profile must or should define. The concept also exactly states the 531 rules regarding negotiation of compression profiles. 533 5.2. General ROCCO principles 535 ROCCO header compression is based on the principle of decompressor 536 context repair attempts relying on a header compression CRC included 537 in compressed headers. Profiles will define various packet types and 538 all of them do not have to carry a header compression CRC. In 539 general, if the CRC is present it is RECOMMENDED to calculate it over 540 the uncompressed header, but profiles MAY define the coverage 541 differently for some packet types. 543 Distinguishing packet streams and packet types is necessary, but some 544 of that information may be available from the underlying technology. 545 To avoid wasting precious header bits, it is left to the compression 546 profile to decide how to distinguish packet types and packet streams. 547 This allows efficient use of header bits overall. 549 If each packet stream has its own logical channel, it is not 550 necessary to have any additional information for distinguishing 551 between streams. Otherwise there MUST be slightly different profiles 552 defined with support for various numbers of concurrent packet 553 streams. 555 The link layer could carry explicit information about packet types, 556 but that would not lead to an efficient use of bits, since different 557 profiles could use different number of packet types. If the packet 558 type distinguishing mechanism is included in the header compression 559 profile instead, the profile could optimize the bit usage of that 560 mechanism to its own packet types. However, it is up to the profile 561 designer to choose if this mechanism is included in the profile or 562 required from the link layer. 564 A compression profile MAY define headers which do not have a 565 corresponding original packet. Such packets would be internal header 566 compression packets, and would not be delivered further from the 567 decompressor. An example would be to initially send non-changing 568 fields of a packet stream as a separate packet. Another example would 569 be to send packets to update the RTP timestamp field even when no RTP 570 packets arrive, in order to decrease the increment in the RTP 571 timestamp field when a packet does arrive. 573 The profiles defined in this document SHOULD be considered as 574 examples for how profiles are supposed to be defined and described. 576 5.3. Data structures 578 The compression scheme needs to maintain a context for compression 579 and decompression of a packet stream. The context must be kept 580 updated at both compressor and decompressor. The context is 581 essentially the header of the last packet transmitted, and includes 582 all static header fields plus some fields that change more or less 583 frequently. If the compression profile used is designed to handle a 584 certain amount of packet loss on the link, both compressor and 585 decompressor will typically keep information about earlier packets; 586 packets that arrived before the current packet. Finally, there may be 587 packet stream related information such as field deltas (e.g. RTP 588 timestamp) or a list of which CSRC items have occurred in the packet 589 stream. 591 5.4. Header compression profiles 593 The details on how a packet stream is to be compressed and 594 decompressed are determined by a compression profile. Over a link a 595 number of profiles can be active, but for each logical channel 596 exactly one profile is active. How to determine what profile to use 597 for a certain packet stream is not defined in this document, but the 598 usage MUST be negotiated between compressor and decompressor as 599 described in the subsequent chapter. 601 One way to select a suitable profile is to have a common channel over 602 which a general-purpose header compression profile is used. When the 603 packet stream characteristics are identified, it is switched to 604 another channel where a suitable compression profile is used. 606 Profiles can be defined to compress one packet stream only, in which 607 case the link layer must be able to separate packet streams. Profiles 608 can also be defined for compression of more than one packet stream, 609 in which case the profile must provide a way to distinguish between 610 the packet streams. 612 Important parameters to consider when designing a compression profile 613 are: 615 - what kind of packet streams to compress (IPv6, IPv4, UDP, 616 UDP/RTP, TCP) and if UDP, whether the UDP checksum is supported. 618 - the rate and pattern of loss of the channel. 620 - the pattern of change of the changing fields. 622 - the expected rate and pattern of loss and reordering before the 623 compression point. 625 - if included in the profile, the number of streams supported. 627 - what support there is from the link layer, such as the number of 628 packet streams supported, and if it can indicate packet types. 630 When these things have been considered, the specifics of the profile 631 can be determined. The profile MUST specify: 633 - the exact semantics of the various packet types and how the 634 desired functionality is supported. 636 - the size of, polynomials for, and what the Header Compression 637 CRC covers for all packet types. 639 - the information needed in the contexts for compression and 640 decompression, including history information and properties of 641 the packet stream. 643 - procedures for compression and decompression. 645 - how compression is initiated (which packets are used and how). 647 - description of context repair mechanisms. 649 Chapter 7 defines compression profiles for IP telephony to use over 650 cellular radio links. 652 5.5. Profile negotiation 654 To initiate ROCCO header compression, compressor and decompressor 655 must be able to negotiate which header compression profile to use. A 656 header compression profile is identified by a 16 bit profile 657 identifier, and underlying link layers MUST provide a way to 658 negotiate this. 660 5.6. Link layer requirements 662 This chapter lists general ROCCO requirements on an underlying link 663 layer. Profiles could also state additional requirements on the link 664 layer, but these MUST be provided for ALL ROCCO profiles. 666 Framing 668 Framing, which makes it possible to separate different packets, is 669 the most important link layer functionality. 671 Length 673 Most link layers can indicate the length of the packet, and this 674 information has therefore been removed from the packet headers. 675 This means that it now MUST be given by the link layer. 677 Profile negotiation 679 In addition to the packet handling mechanisms above, the link 680 layer MUST also provide a way to carry on the negotiation of 681 header compression profiles, described in chapter 5.4. 683 6. Classification of header fields 685 The IP/UDP/RTP header fields can be classified according to the way 686 they are expected to change. On a general level, we classify them as: 688 INFERRED These fields contain values that can be inferred from 689 other values, for example the size of the frame 690 carrying the packet, and thus must not be handled at 691 all by the compression scheme. 693 STATIC These fields are expected to be constant during the 694 lifetime of the packet stream. Static information 695 must in some way be communicated once. 697 STATIC-DEF STATIC fields whose values define a packet stream. 698 They are in general handled as STATIC. 700 STATIC-KNOWN These STATIC fields are expected to have well known 701 values and therefore do not need to be communicated 702 at all. 704 CHANGING These fields are expected to vary in some way, either 705 randomly, within a limited value set or range, or in 706 some other manner. 708 All unchanging fields of the IP/UDP/RTP headers are classified in 709 Appendix A. Table 6.1 summarizes this for IP/UDP/RTP. The interval 710 for the CHANGING fields in Table 6.1 reflects the varying size of the 711 CSRC list of the RTP header. 713 +----------------+--------------+--------------+ 714 | Class \ IP ver | IPv6 (octets)| IPv4 (octets)| 715 +----------------+--------------+--------------+ 716 | INFERRED | 4 | 6 | 717 | STATIC | 2 bits | 3 bits | 718 | STATIC-DEF | 42.5 | 16 | 719 | STATIC-KNOWN | 1 +6 bits | 4 +1 bit | 720 | CHANGING | 11.5(-71.5) | 13.5(-73.5) | 721 +----------------+--------------+--------------+ 722 | Total | 60(-120) | 40(-100) | 723 +----------------+--------------+--------------+ 725 Table 6.1 : Sizes of field classes 727 The information carried by the STATIC and STATIC-DEF fields has to be 728 transferred once, and every header compression profile MUST specify a 729 way of doing this. The information in INFERRED and STATIC-KNOWN 730 fields SHOULD NOT be transmitted at all. The values of INFERRED 731 fields can be computed from other information known to the 732 decompressor. The values of STATIC-KNOWN fields are implicitly 733 defined by the compression profiles. Profiles MUST also handle the 734 CHANGING fields, and that should be done efficiently based on the 735 expected change patterns for the kind of packet streams the profile 736 compresses. A detailed analysis of the change patterns of these 737 fields SHOULD therefore also be done for each profile. 739 7. Header compression profiles for IP telephony packet streams 741 This section exemplifies how the framework outlined in chapter 5 742 could be instantiated by defining profiles for header compression of 743 IP telephony packet streams. A number of profiles are defined 744 providing support for both IPv6 and IPv4 in combination with various 745 functionality. 747 7.1. Usage scenarios, environment and requirements 749 These profiles are intended for IP telephony over cellular links with 750 high error rates. The profiles are designed to successfully handle 751 loss of several consecutive packets over the link, without 752 introducing any additional loss. Packet type identification is 753 included in all profiles, which means that such functionality SHOULD 754 NOT be provided by the link layer used. Regarding packet stream 755 separation, various profiles are defined supporting different numbers 756 of concurrent streams. 758 As a cellular link with similar characteristics is expected at the 759 other end of the connection (see Figure 1.1), the profiles are also 760 designed to handle some consecutive lost packet before the 761 compression point without increasing the size of the compressed 762 header. The profiles are also in general designed to handle 763 reordering of single packets before the compression point without 764 increasing the size of compressed headers. 766 7.2. Analysis of change patterns of header fields 768 To design suitable mechanisms for efficient compression of all header 769 fields, their change patterns need to be analyzed. For this reason, 770 an extended classification tailored for IP-telephony packet streams 771 is made, which applies to all profiles defined in this document. This 772 classification is based on the general classification in chapter 6 773 and Appendix A, and considers the fields which were labeled CHANGING 774 in that classification. These fields are further separated into five 775 different subclasses: 777 STATIC These are fields that were classified as 778 CHANGING on a general basis, but are classified 779 as STATIC for IP telephony packet streams. 781 SEMISTATIC These fields are STATIC most of the time. 782 However, occasionally the value changes but 783 returns to its original value after a known 784 number of packets. 786 RARELY-CHANGING (RC) These are fields that change their values 787 occasionally and then keep their new values. 789 ALTERNATING These fields alternate between a few different 790 values. 792 IRREGULAR These, finally, are the fields for which no 793 useful change pattern can be identified. 795 To further expand the classification possibilities without increasing 796 complexity, the classification can be done either on the values of 797 the field and/or on the values of the deltas for the field. 799 When the classification is done, other details could also be stated 800 regarding possible additional knowledge about the field values and/or 801 field deltas, according to the classification. For fields classified 802 as STATIC or SEMISTATIC, the case could be that the value of the 803 field is not only STATIC but also well KNOWN a priori (two states for 804 SEMISTATIC fields). For fields with non-irregular change behavior, it 805 could be known that changes usually are within a LIMITED range 806 compared to the maximal change for the field. For other fileds, the 807 values are completely UNKNOWN. 809 Table 7.1 classifies all the CHANGING fields based on their expected 810 change patterns for IP telephony streams. 812 +------------------------+-------------+-------------+-------------+ 813 | Field | Value/Delta | Class | Knowledge | 814 +========================+=============+=============+=============+ 815 | Sequential | Delta | STATIC | KNOWN | 816 | -----------+-------------+-------------+-------------+ 817 | IPv4 Id: Seq. jump | Delta | RC | LIMITED | 818 | -----------+-------------+-------------+-------------+ 819 | Random | Value | IRREGULAR | UNKNOWN | 820 +------------------------+-------------+-------------+-------------+ 821 | IP TOS / Tr. Class | Value | RC | UNKNOWN | 822 +------------------------+-------------+-------------+-------------+ 823 | IP TTL / Hop Limit | Value | ALTERNATING | LIMITED | 824 +------------------------+-------------+-------------+-------------+ 825 | Disabled | Value | STATIC | KNOWN | 826 | UDP Checksum: ---------+-------------+-------------+-------------+ 827 | Enabled | Value | IRREGULAR | UNKNOWN | 828 +------------------------+-------------+-------------+-------------+ 829 | No mix | Value | STATIC | KNOWN | 830 | RTP CSRC Count: -------+-------------+-------------+-------------+ 831 | Mixed | Value | RC | LIMITED | 832 +------------------------+-------------+-------------+-------------+ 833 | RTP Marker | Value | SEMISTATIC | KNOWN/KNOWN | 834 +------------------------+-------------+-------------+-------------+ 835 | RTP Payload Type | Value | RC | UNKNOWN | 836 +------------------------+-------------+-------------+-------------+ 837 | RTP Sequence Number | Delta | STATIC | KNOWN | 838 +------------------------+-------------+-------------+-------------+ 839 | RTP Timestamp | Delta | RC | LIMITED | 840 +------------------------+-------------+-------------+-------------+ 841 | No mix | - | - | - | 842 | RTP CSRC List: -------+-------------+-------------+-------------+ 843 | Mixed | Value | RC | UNKNOWN | 844 +------------------------+-------------+-------------+-------------+ 846 Table 7.1 : Classification of CHANGING header fields 848 The following subsections discuss the various header fields in 849 detail. Note that table 7.1 and the discussions below do not consider 850 changes caused by loss or reordering before the compression point. 852 7.2.1. IPv4 Identification 854 The Identification field (IP ID) of the IPv4 header is there to 855 identify which fragments constitute a datagram when reassembling 856 fragmented datagrams. The IPv4 specification does not specify exactly 857 how this field is to be assigned values, only that each packet should 858 get an IP ID that is unique for the source-destination pair and 859 protocol for the time the datagram (or any of its fragments) could be 860 alive in the network. This means that assignment of IP ID values can 861 be done in various ways, which we have separated into three classes. 863 Sequential 865 This assignment policy keeps a separate counter for each outgoing 866 packet stream and thus the IP ID value will increment by one for 867 each packet in the stream. Therefore, the delta value of the 868 field is constant and well known a priori. When RTP is used on 869 top of UDP and IP, the IP ID value follows the RTP sequence 870 number. This assignment policy is the most desirable for header 871 compression purposes but its usage is not as common as it should 872 be. The reason is that it can be realized only if UDP and IP are 873 implemented together so that UDP, which separates packet streams 874 by the port identification, can make IP use separate ID counters 875 for each packet stream. 877 Sequential jump 879 This is the most common assignment policy in today's IP stacks. 880 The difference from the sequential method is that only one 881 counter is used for all connections. When the sender is running 882 more than one packet stream simultaneously, the IP ID can 883 increase by more than one. The IP ID values will be much more 884 predictable and require less bits to transfer than random values, 885 and the packet-to-packet increment (determined by the number of 886 active outgoing packet streams) will usually be limited. 888 Random 890 Some IP stacks assign IP ID values using a pseudo-random number 891 generator. There is thus no correlation between the ID values of 892 subsequent datagrams. Therefore there is no way to predict the IP 893 ID value for the next datagram. For header compression purposes, 894 this means that the IP ID field needs to be sent uncompressed 895 with each datagram, resulting in two extra octets of header. IP 896 stacks in cellular terminals SHOULD NOT use this IP ID assignment 897 policy. 899 In this document, various profiles are defined with different IP ID 900 capabilities. First of all, it should be noted that the ID is an IPv4 901 mechanism and is therefore not needed at all in IPv6 profiles. For 902 IPv4, all profiles could be designed in three variants depending on 903 the ID handling. Firstly, we have the inefficient but reliable 904 solution where the ID field is sent as-is in all packets, increasing 905 the compressed headers with two octets. This is the best way to 906 handle the ID field if the sender uses random assignment of the ID 907 field. Secondly, there can be profiles with more flexible mechanisms 908 requiring less bits for the ID handling as long as sequential jump 909 assignment is used. Such profiles will probably require even more 910 bits if random assignment is used by the sender. Knowledge about the 911 sender's assignment policy could therefore be useful when choosing 912 between the two solutions above. Finally, even for IPv4, profiles 913 could be designed without any additional information for the ID field 914 included in compressed headers. To use such profiles, it must be 915 known that the sender makes use of the pure sequential assignment 916 policy for the ID field. That might not be possible to know, which 917 implies that the applicability of such profiles is very uncertain. 918 However, designers of IPv4 stacks for cellular terminals SHOULD use 919 the sequential policy. 921 7.2.2. IP Traffic-Class / Type-Of-Service 923 The Traffic-Class (IPv6) or Type-Of-Service (IPv4) field is expected 924 to be constant during the lifetime of a packet stream or to change 925 relatively seldom. 927 7.2.3. IP Hop-Limit / Time-To-Live 929 The Hop-Limit (IPv6) or Time-To-Live (IPv4) field is expected to be 930 constant during the lifetime of a packet stream or to alternate 931 between a limited number of values due to route changes. 933 7.2.4. UDP Checksum 935 The UDP checksum is optional. If disabled, its value is constantly 936 zero. If enabled, its value depends on the payload, which for 937 compression purposes is equivalent to it changing randomly with every 938 packet. 940 In this document, there are profiles defined for packet streams both 941 with and without support for the UDP checksum. Profiles with this 942 support will of course require more bits to be sent in compressed 943 headers. 945 7.2.5. RTP CSRC Counter 947 This is a counter indicating the number of CSRC items present in the 948 CSRC list. This number is expected to be almost constant on a packet- 949 to-packet basis and change by small amount. As long as no RTP mixer 950 is used, the value of this field is zero. 952 7.2.6. RTP Marker 954 The marker bit should be set only in the first packet of a talkspurt, 955 which means that it has a semistatic characteristic with well-known 956 values for both states. 958 7.2.7. RTP Payload Type 960 Changes of the RTP payload type within a packet stream are expected 961 to be rare. Applications could adapt to congestion by changing 962 payload type and/or frame sizes, but that is not expected to happen 963 frequently. 965 7.2.8. RTP Sequence Number 967 The RTP sequence number will be incremented by one for each packet 968 sent. 970 7.2.9. RTP Timestamp 972 As long as there are no pauses in the audio stream, the RTP timestamp 973 will be incremented by a constant delta, corresponding to the number 974 of samples in the speech frame. It will thus mostly follow the RTP 975 sequence number. When there has been a silent period and a new 976 talkspurt begins, the timestamp will jump in proportion to the length 977 of the silent period. However, the increment will probably be within 978 a relatively limited range. 980 7.2.10. RTP Contributing Sources (CSRC) 982 The participants in a session, which are identified by the CSRC 983 fields, are expected to be almost the same on a packet-to-packet 984 basis with relatively few additions or removals. As long as RTP 985 mixers are not used, no CSRC fields are present at all. 987 7.3. Profile definitions 989 This document defines a number of different header compression 990 profiles. The definitions are built up of the requirements on and 991 capabilities of each profile in combination with information about 992 which mechanisms are used to implement the desired behavior. 994 7.3.1. List of defined profiles 996 All defined profiles are listed in Table 7.2 together with their 997 characteristics, capabilities and pointers to implementation details 998 that may differ from profile to profile. For more information about 999 the profile concept see chapter 5.4 and "Header compression profile" 1000 in the Terminology chapter. 1002 The first six columns state requirements on and capabilities of the 1003 profiles. The meaning of the columns are: 1005 Nr This is the identification number for each profile. These 1006 numbers are used when negotiating profiles in the header 1007 compression setup phase. The numbers are preliminary and will 1008 perhaps change in future versions of this profile 1009 specification. 1011 IPv This is the IP version for which the profile is designed. 1012 Possible values for this column are 6 and 4. 1014 CPS This column gives the number of Concurrent Packet Streams 1015 that are supported by the header compression profile. 1017 Chk This column indicates whether the profile supports packet 1018 streams with the UDP checksum (E)nabled or D(isabled). For 1019 IPv6, which prohibits disabling of the checksum, a third kind 1020 of profiles should be defined (C)ompressing the checksum. 1022 Id For profiles supporting IPv4, this column indicates which 1023 behavior of the IPv4 Identification field the profile is 1024 optimized for. Possible values in this column are: 1026 (S)EQUENTIAL These profiles cannot handle streams 1027 with IP Identification values assigned 1028 using any other policy than sequential. 1030 (S)EQUENTIAL (J)UMP These profiles can handle all kinds of 1031 Identification assignment methods but 1032 will be less efficient than RANDOM 1033 profiles if the assignment truly is 1034 random. "+" suits frequent jumps. 1036 (R)ANDOM These profiles are recommended if it is 1037 known that random assignment is used. 1038 The Identification field will be 1039 included "as-is" which means that the 1040 header size will increase by two 1041 octets. 1043 S/R S gives the minimal header Size for the profile while R 1044 represents a Robustness value. R corresponds to the number of 1045 packet losses that can be handled without losing context. 1047 The next five columns indicate how each profile is implemented. This 1048 includes header formats for STATIC (STA, chapter 7.5.1), DYNAMIC 1049 (DYN, chapter 7.5.2) and COMPRESSED (COM, chapter 7.5.3) packets, and 1050 also what EXTENSION (EXT, chapter 7.5.5) formats are used with the 1051 COMPRESSED packets and the interpretation of the Code-field (CFI, 1052 chapter 7.6). 1054 Nr | IPv | CPS | Chk | Id | S/R || STA | DYN | COM | EXT | CFI 1055 =====+=====+=====+=====+=====+======++=====+=====+=====+=====+===== 1056 1 | 6 | 1 | E | - | 4/26 || 1 | 5 | 2 | A | S 1057 -----+-----+-----+-----+-----+------++-----+-----+-----+-----+----- 1058 2 | 6 | 28 | E | - | 4/5 || 2 | 6 | 4 | A | C 1059 -----+-----+-----+-----+-----+------++-----+-----+-----+-----+----- 1060 3 | 6 | 256 | E | - | 5/26 || 2 | 6 | 6 | A | S 1061 -----+-----+-----+-----+-----+------++-----+-----+-----+-----+----- 1062 4 | 4 | 1 | D | S | 2/26 || 3 | 3 | 1 | A | S 1063 -----+-----+-----+-----+-----+------++-----+-----+-----+-----+----- 1064 5 | 4 | 1 | E | S | 4/26 || 3 | 7 | 2 | A | S 1065 -----+-----+-----+-----+-----+------++-----+-----+-----+-----+----- 1066 6 | 4 | 28 | D | S | 2/5 || 4 | 4 | 3 | A | C 1067 -----+-----+-----+-----+-----+------++-----+-----+-----+-----+----- 1068 7 | 4 | 28 | E | S | 4/5 || 4 | 8 | 4 | A | C 1069 -----+-----+-----+-----+-----+------++-----+-----+-----+-----+----- 1070 8 | 4 | 256 | D | S | 3/26 || 4 | 4 | 5 | A | S 1071 -----+-----+-----+-----+-----+------++-----+-----+-----+-----+----- 1072 9 | 4 | 256 | E | S | 5/26 || 4 | 8 | 6 | A | S 1073 -----+-----+-----+-----+-----+------++-----+-----+-----+-----+----- 1074 10 | 4 | 1 | D | SJ+ | 2/5 || 3 | 3 | 7 | B | I/S 1075 -----+-----+-----+-----+-----+------++-----+-----+-----+-----+----- 1076 11 | 4 | 1 | E | SJ+ | 4/5 || 3 | 7 | 8 | B | I/S 1077 -----+-----+-----+-----+-----+------++-----+-----+-----+-----+----- 1078 12 | 4 | 256 | D | SJ+ | 3/5 || 4 | 4 | 9 | B | I/S 1079 -----+-----+-----+-----+-----+------++-----+-----+-----+-----+----- 1080 13 | 4 | 256 | E | SJ+ | 5/5 || 4 | 8 | 10 | B | I/S 1081 -----+-----+-----+-----+-----+------++-----+-----+-----+-----+----- 1082 14 | 4 | 1 | D | SJ | 2/26 || 3 | 3 | 7 | B | S/I 1083 -----+-----+-----+-----+-----+------++-----+-----+-----+-----+----- 1084 15 | 4 | 1 | E | SJ | 4/26 || 3 | 7 | 8 | B | S/I 1085 -----+-----+-----+-----+-----+------++-----+-----+-----+-----+----- 1086 16 | 4 | 256 | D | SJ | 3/26 || 4 | 4 | 9 | B | S/I 1087 -----+-----+-----+-----+-----+------++-----+-----+-----+-----+----- 1088 17 | 4 | 256 | E | SJ | 5/26 || 4 | 8 | 10 | B | S/I 1089 -----+-----+-----+-----+-----+------++-----+-----+-----+-----+----- 1090 18 | 4 | 1 | D | R | 4/26 || 3 | 3 | 11 | A | S 1091 -----+-----+-----+-----+-----+------++-----+-----+-----+-----+----- 1092 19 | 4 | 1 | E | R | 6/26 || 3 | 7 | 12 | A | S 1093 -----+-----+-----+-----+-----+------++-----+-----+-----+-----+----- 1094 20 | 4 | 28 | D | R | 4/5 || 4 | 4 | 13 | A | C 1095 -----+-----+-----+-----+-----+------++-----+-----+-----+-----+----- 1096 21 | 4 | 28 | E | R | 6/5 || 4 | 8 | 14 | A | C 1097 -----+-----+-----+-----+-----+------++-----+-----+-----+-----+----- 1098 22 | 4 | 256 | D | R | 5/26 || 4 | 4 | 15 | A | S 1099 -----+-----+-----+-----+-----+------++-----+-----+-----+-----+----- 1100 23 | 4 | 256 | E | R | 7/26 || 4 | 8 | 16 | A | S 1101 -----+-----+-----+-----+-----+------++-----+-----+-----+-----+----- 1102 24 | 4 | 1 | D | S | 1/16 || 3 | 3 | 1M | A | S 1104 Table 7.2 : List of defined profiles 1106 7.3.2. Additional common profile characteristics 1108 In addition to what was stated in the left part of Table 7.2, the 1109 following applies to all the profiles defined in this document: 1111 Packet stream characteristics 1113 These profiles are designed for packet streams carrying IP 1114 telephony data. 1116 Link layer requirements 1118 Except for the general link layer requirements (framing, length & 1119 profile negotiation) stated in chapter 5.6, these profiles also 1120 require a reliable link layer CRC covering at least the header part 1121 of the packet. The CRC SHOULD ensure that packets with errors in 1122 the header part are never delivered. 1124 Pre link characteristics 1126 With these profiles, several consecutive packet losses before the 1127 header compression point are handled without introducing additional 1128 header overhead. Packet reordering on pre links is expected to be 1129 uncommon but is handled, very efficiently when limited. 1131 Link Characteristics 1133 The link over which header compression is performed is expected to 1134 have a loss characteristic that very seldom leads to loss of many 1135 consecutive packets. These profiles can on a single "guess" handle 1136 loss of up to 26 consecutive packets over the link without losing 1137 context, and even if loss on pre links decreases this robustness it 1138 should be more than sufficient for all realistic scenarios. The 1139 round-trip time of the link is expected to be between 100 and 200 1140 milliseconds. 1142 7.4. Encoding methods used 1144 The analysis in section 7.2 excluded changes due to loss and/or 1145 reordering before the header compression point. Such changes will 1146 have an impact on the regularity of the RTP sequence number, the RTP 1147 timestamp value and, for IPv4, the IP ID value. However, as described 1148 in 7.2, both the RTP timestamp and the IP ID value (if sequentially 1149 assigned) are expected to follow the RTP sequence number for most 1150 packets. The most important task is then to communicate RTP sequence 1151 number information in an efficient way. The profiles defined in this 1152 document make use of three different methods of handling the sequence 1153 number field, LSB encoding, LSP encoding, and reconstruction attempts 1154 based on "normal case" knowledge. The first two are also used for 1155 encoding of a variety of other fields, and this chapter therefore 1156 describes these methods in a general way. How these two methods are 1157 applied for different profiles and how the method with "normal case" 1158 reconstruction attempts works is described in chapters 7.6 and 7.7. 1160 7.4.1. Least Significant Bits (LSB) encoding 1162 A commonly used method for updating fields whose values are always 1163 subject to small changes (usually positive) is Least Significant Bits 1164 (LSB) encoding. For example, an increase of up to 16 could be handled 1165 with only 4 bits with LSB encoding (if decreases are not expected). 1166 This method is used for many different fields by the ROCCO profiles 1167 defined in this document, especially when information such as 1168 timestamps is sent in EXTENDED COMPRESSED headers. If a field is 1169 labeled " LSB" it means that the field contains only the 1170 least significant bits of the corresponding original field. 1172 7.4.2. Least Significant Part (LSP) encoding 1174 One restriction with LSB encoding is that an exact number of whole 1175 bits are needed, meaning that only 2, 4, 8, 16, 32, ... code-points 1176 could be used. In some cases, especially when several mechanisms are 1177 integrated for efficiency reasons, it would be desirable to have a 1178 method that could make use of any number of available code-points. To 1179 signal one special event one could either use one single bit or, if 1180 the event is not to be signaled in parallel with other information, 1181 as one bit pattern for several bits. That would leave more bit 1182 patterns for other usage. 1184 Assume that we have 4 special events to signal and 5 bits available. 1185 Taking 2 bits for these events, then there would be 3 bits (8 code- 1186 points) left for other usage. If we instead reserved 4 of the code- 1187 points represented by all 5 bits, there would instead be 32-4=28 1188 code-points left for other usage. The only disadvantage would be that 1189 the bits cannot be used for both purposes at the same time. 1191 What would be desirable is to do LSB encoding of code-points instead 1192 of whole bits. Therefore the method called Least Significant Part 1193 (LSP) encoding has been introduced. LSP encoding of size (number of 1194 code-points) M for a value N is defined as: 1196 LSP:M(N) = N modulo M 1198 An example showing the LSP encoding and decoding of a counter S(n) 1199 with M code-points is used below to illustrate the LSP principle. 1200 S'(n) is the decoded value corresponding to the original S(n) value. 1201 With S'(n-1), we denote the last correctly decompressed value. 1203 Input sequence: S(n) 1204 Encoded sequence: LSP:M(S(n)) = S(n) modulo M 1205 Decoded sequence: S'(n) = S(n-1) - LSP:M(S'(n-1)) + LSP:M(S(n)) = 1206 S(n-1) - S(n-1) modulo M + S(n) modulo M 1208 To handle modulo wrap-around, an additional verification is inserted. 1209 If the decoded value S'(n) is smaller than S'(n-1)-R, S'(n) is 1210 increased with M (reordering of order R is then handled with this 1211 encoding). 1213 When applying LSP encoding, there are thus two parameters that must 1214 be set: 1216 M - The number of code-points to use (modulo value) 1217 R - The reordering order to handle 1219 A similar mechanism as for modulo wrap-around should also be used to 1220 handle full-field wrap-around. 1222 7.5. Packet formats 1224 The profiles defined in this document make use of four different 1225 packet types: STATIC, DYNAMIC, COMPRESSED and FEEDBACK. 1227 To identify packet types, 4 bit patterns for the initial 5 bits of 1228 the first octet in all packets are reserved. These patterns are: 1230 STATIC 00000 1231 DYNAMIC 0001* 1232 FEEDBACK 00001 1234 The other 28 (32-4) bit patterns indicate a COMPRESSED packet format 1235 and the usage of these patterns are explained in chapter 7.6 and 1236 chapter 7.7. These five bits are hereafter referred to as the Code- 1237 field in COMPRESSED headers. 1239 Note that for profiles using the MINIMAL_COMPRESSED header sub-type 1240 described in chapter 7.6.4, all bit patterns starting with a "1" are 1241 ALSO reserved for identification of this header type. 1243 MINIMAL_COMPRESSED 1**** 1245 That leaves 12 (16-4) bit patterns in the Code-field for other usage 1246 in the "normal" COMPRESSED header for such profiles. 1248 This section defines the header formats of the four ordinary packet 1249 types STATIC, DYNAMIC, COMPRESSED and FEEDBACK together with 1250 descriptions of when and how to use them. Subsections are also 1251 dedicated to the MINIMAL and EXTENSION formats of COMPRESSED headers. 1253 7.5.1. Static information packets, initialization 1255 The STATIC packet type is a packet containing no payload but only the 1256 header fields that are expected to be constant throughout the 1257 lifetime of the packet stream (classified as STATIC in chapter 6). A 1258 packet of this kind MUST be sent once as the first packet from 1259 compressor to decompressor and also when requested by the 1260 decompressor (see 7.6.7 and 7.7). The packet formats are shown below 1261 for IPv6 and IPv4, respectively. Note that some fields are only 1262 present in some of the STATIC packet types. 1264 IPv6 (45-46 octets): STATIC1, STATIC2: 1266 0 1 2 3 4 5 6 7 1267 +---+---+---+---+---+---+---+---+ 1268 0 | 0 | 0 | 0 | 0 | 0 | - | - | - | 1269 +---+---+---+---+---+---+---+---+ 1270 1 | | 1271 + Flow Label + 1272 2 | | 1273 + +---+---+---+---+ 1274 3 | | - | - | P | E | 1275 +---+---+---+---+---+---+---+---+ 1276 4 | | 1277 / Source Address / 16 octets 1278 19 | | 1279 +---+---+---+---+---+---+---+---+ 1280 20 | | 1281 / Destination Address / 16 octets 1282 35 | | 1283 +---+---+---+---+---+---+---+---+ 1284 36 | | 1285 + Source Port + 1286 37 | | 1287 +---+---+---+---+---+---+---+---+ 1288 38 | | 1289 + Destination Port + 1290 39 | | 1291 +---+---+---+---+---+---+---+---+ 1292 40 | | 1293 / SSRC / 4 octets 1294 43 | | 1295 +---+---+---+---+---+---+---+---+ 1296 44 | Header Compression CRC | see chapter 7.8.1. 1297 +---+---+---+---+---+---+---+---+ 1298 : Context Identifier : only present in STATIC2 1299 +...............................+ 1301 IPv4 (18-19 octets): STATIC3, STATIC4: 1303 0 1 2 3 4 5 6 7 1304 +---+---+---+---+---+---+---+---+ 1305 0 | 0 | 0 | 0 | 0 | 0 | F | P | E | 1306 +---+---+---+---+---+---+---+---+ 1307 1 | | 1308 / Source Address / 4 octets 1309 4 | | 1310 +---+---+---+---+---+---+---+---+ 1311 5 | | 1312 / Destination Address / 4 octets 1313 8 | | 1314 +---+---+---+---+---+---+---+---+ 1315 9 | | 1316 + Source Port + 1317 10 | | 1318 +---+---+---+---+---+---+---+---+ 1319 11 | | 1320 + Destination Port + 1321 12 | | 1322 +---+---+---+---+---+---+---+---+ 1323 13 | | 1324 / SSRC / 4 octets 1325 16 | | 1326 +---+---+---+---+---+---+---+---+ 1327 17 | Header Compression CRC | see chapter 7.8.1. 1328 +---+---+---+---+---+---+---+---+ 1329 : Context Identifier : only present in STATIC4 1330 +...............................+ 1332 All fields except for the initial five bits, the padding (-) and the 1333 Header Compression CRC are the ordinary IP, UDP and RTP fields 1334 (F=IPv4 May Fragment, P=RTP Padding, E=RTP Extension). 1336 The number of STATIC packets sent on each occasion should be limited. 1337 If the decompressor receives DYNAMIC or COMPRESSED headers without 1338 having received a STATIC packet, the decompressor MUST send a 1339 STATIC_FAILURE_FEEDBACK packet. 1341 7.5.2. Dynamic information packets 1343 The DYNAMIC packet type has a header containing all changing header 1344 fields in their original, uncompressed form, and carries a payload 1345 just like ordinary COMPRESSED packets. This packet type is used after 1346 the initial STATIC packet to set up the decompressor context for the 1347 first time, and also whenever the header field information cannot be 1348 encoded in EXTENDED_COMPRESSED packets. DYNAMIC packets could be used 1349 due to significant field changes or upon INVALID_CONTEXT_FEEBACK. 1351 All fields except for the initial four bits, the Timestamp Delta, and 1352 the Header Compression CRC are ordinary IP, UDP and RTP fields. The 1353 Timestamp Delta is the current delta between RTP timestamps in 1354 consecutive RTP packets. Initially this value SHOULD be set to 160. 1356 The packet formats are shown below for IPv6 and IPv4, respectively. 1357 Note that some fields are only present in some of the DYNAMIC packet 1358 types. 1360 IPv6 (13-16 octets + CSRC List of 0-60 octets): DYNAMIC1, DYNAMIC2, 1361 DYNAMIC5, DYNAMIC6: 1363 0 1 2 3 4 5 6 7 1364 +---+---+---+---+---+---+---+---+ 1365 0 | 0 | 0 | 0 | 1 | CSRC Counter | 1366 +---+---+---+---+---+---+---+---+ 1367 1 | | 1368 + Timestamp Delta + 1369 2 | | 1370 +---+---+---+---+---+---+---+---+ 1371 3 | Traffic Class | 1372 +---+---+---+---+---+---+---+---+ 1373 4 | Hop Limit | 1374 +---+---+---+---+---+---+---+---+ 1375 5 | M | Payload Type | 1376 +---+---+---+---+---+---+---+---+ 1377 6 | | 1378 + Sequence Number + 1379 7 | | 1380 +---+---+---+---+---+---+---+---+ 1381 8 | | 1382 / Timestamp / 4 octets 1383 11 | | 1384 +---+---+---+---+---+---+---+---+ 1385 12 | Header Compression CRC | see chapter 7.8.2. 1386 +---+---+---+---+---+---+---+---+ 1387 : : 1388 : CSRC List : 0-15 x 4 octets 1389 : : 1390 +...............................+ 1391 : : 1392 : UDP Checksum : only in DYNAMIC5 and DYNAMIC6 1393 : : 1394 +...............................+ 1395 : Context Identifier : only in DYNAMIC2 and DYNAMIC6 1396 +---+---+---+---+---+---+---+---+ 1397 | | 1398 / Payload / 1399 | | 1400 +---+---+---+---+---+---+---+---+ 1402 IPv4 (15-18 octets + CSRC List of 0-60 octets): DYNAMIC3, DYNAMIC4, 1403 DYNAMIC7, DYNAMIC8: 1405 0 1 2 3 4 5 6 7 1406 +---+---+---+---+---+---+---+---+ 1407 0 | 0 | 0 | 0 | 1 | CSRC Counter | 1408 +---+---+---+---+---+---+---+---+ 1409 1 | | 1410 + TS Delta + 1411 2 | | 1412 +---+---+---+---+---+---+---+---+ 1413 3 | Type Of Service | 1414 +---+---+---+---+---+---+---+---+ 1415 4 | | 1416 + Identification + 1417 5 | | 1418 +---+---+---+---+---+---+---+---+ 1419 6 | Time To Live | 1420 +---+---+---+---+---+---+---+---+ 1421 7 | M | Payload Type | 1422 +---+---+---+---+---+---+---+---+ 1423 8 | | 1424 + Sequence Number + 1425 9 | | 1426 +---+---+---+---+---+---+---+---+ 1427 10 | | 1428 / Timestamp / 4 octets 1429 13 | | 1430 +---+---+---+---+---+---+---+---+ 1431 14 | Header Compression CRC | see chapter 7.8.2. 1432 +---+---+---+---+---+---+---+---+ 1433 : : 1434 : CSRC List : 0-15 x 4 octets 1435 : : 1436 +...............................+ 1437 : : 1438 + UDP Checksum + only in DYNAMIC7 and DYNAMIC8 1439 : : 1440 +...............................+ 1441 : Context Identifier : only in DYNAMIC4 and DYNAMIC8 1442 +---+---+---+---+---+---+---+---+ 1443 | | 1444 / Payload / 1445 | | 1446 +---+---+---+---+---+---+---+---+ 1448 Each time a DYNAMIC packet is sent, several subsequent packets SHOULD 1449 also be DYNAMIC packets to ensure a successful update even when 1450 packets are lost. Context updates both with DYNAMIC and COMPRESSED 1451 packets could also be acknowledged with CONTEXT_UPDATED_FEEDBACK. 1453 7.5.3. Compressed packets 1455 The COMPRESSED packet type is the most commonly used packet and is 1456 designed to handle ordinary changes as efficiently as possible. When 1457 changes are regular, all information is carried in the base header, 1458 with only the Header Compression CRC of 10 bits, the Code-field and 1459 one bit indicating if header extensions are present. When desired, it 1460 is possible to send additional information in extensions to the 1461 COMPRESSED base-header. The COMPRESSED base-header formats are shown 1462 below. Note that some fields are only present in some of the 1463 COMPRESSED packet types. 1465 Defines packet types: COMPRESSED1..COMPRESSED16: 1467 0 1 2 3 4 5 6 7 1468 +---+---+---+---+---+---+---+---+ 1469 0 | Code-field | | 1470 +---+---+---+---+---+ +---+ 1471 1 | Header Compression CRC | X | 1472 +---+---+---+---+---+---+---+---+ 1473 : : 1474 + UDP Checksum + only in type 2,4,6,8,10,12,14,16 1475 : : 1476 +...+...+...+...+...+...+...+...+ 1477 : Context Identifier (CID) : only in type 5,6,9,10,15,16 1478 +...+...+...+...+...+...+...+...+ 1479 : : 1480 + Identification + only in type 11,12,13,14,15,16 1481 : : 1482 +...+...+...+...+...+...+...+...+ 1483 : : 1484 / Extension / only present if X=1 1485 : : 1486 +...+...+...+...+...+...+...+...+ 1488 The Header Compression CRC is computed over the original packet 1489 header as described in chapter 7.8.3. In that chapter, the CRC 1490 polynomials to use are also defined. 1492 The interpretations of the Code-field for different profiles are 1493 given in section 7.6 and section 7.7. 1495 7.5.4. Minimal compressed headers 1497 Profiles using COMPRESSED packet types marked with an "M" also 1498 support a special MINIMAL_COMPRESSED header type in addition to the 1499 ordinary one. This header type is indicated for such profiles by 1500 setting the first bit to 1, while 0 means that the normal compressed 1501 header type is used. MINIMAL_COMPRESSED headers SHOULD only be used 1502 when header field changes are regular before the compression point, 1503 otherwise the normal compressed format SHOULD be used. 1505 MINIMAL_COMPRESSED packet type (used with COMPRESSED*M): 1507 0 1 2 3 4 5 6 7 1508 +---+---+---+---+---+---+---+---+ 1509 0 | 1 | Seq LSB | CRC | 1510 +---+---+---+---+---+---+---+---+ 1512 Sequence LSB is included as described in chapter 7.7.2. The CRC is a 1513 reduced form of the Header Compression CRC used in ordinary 1514 compressed headers. The CRC polynomial to be used is defined in 1515 appendix B. The small CRC does not provide a very high reliability. 1516 Therefore, when using the MINIMAL_COMPRESSED packet type, it is 1517 recommended to implement the CRC pre-verification mechanism described 1518 in chapter 8.3 to reduce this weakness to an insignificant level. 1520 Note that because of the need to identify the minimal compressed 1521 header type, the Code-field interpretation is different than for 1522 profiles without this header type, as described in 7.7.1. 1524 7.5.5. Extensions to compressed headers 1526 Less regular changes in the header fields or updates of decompressor 1527 contexts require an extension in addition to the base header. When 1528 there is an extension present in the COMPRESSED packet, this is 1529 indicated by the extension bit (X) being set. Extensions are of 1530 variable size depending on the information needed to be transmitted. 1531 However, the first three extension bits are used as an extension Type 1532 field for all extension formats. The extension can carry an M bit, a 1533 TS LSB field, a SEQ LSB field, an ID LSB field and a bit mask for 1534 additional fields. The M bit is the RTP marker bit and the TS LSB is 1535 the least significant bits of the timestamp value (the most 1536 significant bits are then expected to be unchanged since previous 1537 packets). The SEQ LSB (described in chapter 7.7.2) is the least 1538 significant bits for the RTP sequence number, and the ID LSB is the 1539 LSB of the IP Identification value. Various bit mask patterns are 1540 possible and can consist of S,H,C,D,T and I. The interpretations of 1541 these bits are given at the end of this chapter. 1543 The guiding principle for choosing the extension type is to find the 1544 smallest header type that can communicate the information needed. 1546 For the profiles defined in this document, two different extension 1547 sets are used, called A and B. Set A is the simpler one while set B 1548 handles much more functionality and is therefore more complex. All 1549 possible extensions are shown below with indications of which sets 1550 and types the extensions correspond to. For instance, B3 means that 1551 in extension set B, the extension is used with type value 3 1552 (indicated in the type field). 1554 The defined extension types are shown below: 1556 0 7 1557 - - +-+-+-+-+-+-+-+-+ 1558 A0, B0 |0 0 0| SEQ LSB | 1559 - - +-+-+-+-+-+-+-+-+ 1561 0 7 1562 - - +-+-+-+-+-+-+-+-+ 1563 A1, B1 |0 0 1|M| TS LSB| 1564 - - +-+-+-+-+-+-+-+-+ 1566 1 1567 0 7 8 5 1568 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1569 A2 |0 1 0|M| TS LSB | 1570 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 1 1 2 1573 0 7 8 5 6 3 1574 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 A3 |0 1 1|M| TS LSB | 1576 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 0 7 1579 - - +-+-+-+-+-+-+-+-+ - - 1580 A4 |1 0 0|M|H|S|T|D| 1581 - - +-+-+-+-+-+-+-+-+ - - 1583 1 1584 0 7 8 5 1585 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 1586 A5 |1 0 1|M|C|H|S|D| TS LSB | 1587 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 1589 1 1 2 1590 0 7 8 5 6 3 1591 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 1592 A6 |1 1 0|M|C|H|S|D| TS LSB | 1593 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 1595 1 1596 0 7 8 5 1597 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 1598 A7 |1 1 1|M|C|H|S|D|T| SEQ LSB | 1599 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 1600 1 1601 0 7 8 5 1602 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 B2 |0 1 0|M| TS LSB | SEQ LSB | 1604 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1606 1 1607 0 7 8 5 1608 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 B3 |0 1 1|M| TS LSB| ID LSB | 1610 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1612 0 7 1613 - - +-+-+-+-+-+-+-+-+ - - 1614 B4 |1 0 0|M|H|T|D|I| 1615 - - +-+-+-+-+-+-+-+-+ - - 1617 1 2 1618 0 7 8 5 3 1619 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 B5 |1 0 1|M| TS LSB | ID LSB | 1621 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1623 1 1 2 1624 0 7 8 5 6 3 1625 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1626 B6 |1 1 0|M| TS LSB | SEQ LSB | 1627 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 1 1630 0 7 8 5 1631 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 1632 B7 |1 1 1|M|C|H|S|D|T|I| SEQ LSB | 1633 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 1635 A bit mask indicating additional fields could include bits with the 1636 following meaning: 1638 C - Traffic (C)lass / Type Of Service 1639 H - (H)op Limit / Time To Live 1640 S - Contributing (S)ources - CSRC 1641 D - Timestamp (D)elta 1642 T - (T)imestamp LSB 1643 I - (I)dentification LSB 1645 If any of these fields are included, they will appear in the order as 1646 listed above and the format of the fields will be as described below. 1648 C - Traffic Class / Type Of Service 1650 The field contains the value of the original IP header field. 1652 8 bits 1653 - - +-+-+-+-+-+-+-+-+ - - 1654 | TC / TOS | 1655 - - +-+-+-+-+-+-+-+-+ - - 1657 H - Hop Limit / Time To Live 1659 The field contains the value of the original IP header field. 1661 8 bits 1662 - - +-+-+-+-+-+-+-+-+ - - 1663 | HL / TTL | 1664 - - +-+-+-+-+-+-+-+-+ - - 1666 S - Contributing Sources 1668 The CSRC field is built up of: 1670 - a counter of the number of CSRC items present (4 bits) 1671 - an unused field (4 bits) 1672 - the CSRC items, 1 to 15 (4-60 octets) 1674 1 octet + 4 to 60 octets 1675 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+~~~+-+-+-+-+-+ - - 1676 | Count | Unused| CSRC Items | 1677 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+~~~+-+-+-+-+-+ - - 1679 D - Timestamp Delta 1681 The Timestamp Delta field is a one-octet field. We want to 1682 communicate Timestamp Delta values corresponding to 80 ms. 1683 Therefore, the Timestamp Delta value communicated is not the 1684 actual number of samples, but the number of samples divided by 1685 8. Thus, only Timestamp Delta values evenly divisible by 8 can 1686 be communicated in the Timestamp Delta field of an extension. On 1687 the other hand, the maximum value is 255*8 = 2040 (255 ms at 1688 8000 Hz). Delta values larger than 2040 or delta values not 1689 evenly divisible by 8 must be communicated in a DYNAMIC packet. 1691 8 bits 1692 - - +-+-+-+-+-+-+-+-+ - - 1693 |Timestamp Delta| 1694 - - +-+-+-+-+-+-+-+-+ - - 1695 Note that when the Timestamp Delta is changed, the Timestamp LSB 1696 field MUST also be included. 1698 T - Timestamp LSB 1700 The field contains the 16 least significant bits of the RTP 1701 timestamp. 1703 16 bits 1704 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 1705 | TS LSB | 1706 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 1708 I - Identification 1710 The field contains the IP ID LSB. 1712 8 bits 1713 - - +-+-+-+-+-+-+-+-+ 1714 | ID LSB | 1715 - - +-+-+-+-+-+-+-+-+ 1717 An example where the HL/TTL and the Timestamp Delta fields are 1718 present in a type A4 extension is shown below. When the Timestamp 1719 Delta field is present the RTP Marker will probably also be set, 1720 which is the case in this example. 1722 Type M C H S D 1723 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 1724 |1 0 0|1|0 1 0 1| HL / TTL |Timestamp Delta| 1725 - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 1727 When information of any kind is sent in an extension, the 1728 corresponding information SHOULD also be sent in some subsequent 1729 packets (either as Extensions or in DYNAMIC packets). 1731 7.5.6. Feedback packets 1733 Feedback packets are used by the decompressor to provide various 1734 types of feedback to the compressor. That could include active 1735 feedback to assure error free performance or passive feedback (in 1736 case of invalidated context) to request a context update from the 1737 compressor. The feedback mechanisms defined here leave a lot to the 1738 implementation regarding how to use feedback. The general feedback 1739 packet format is shown below: 1741 0 1 2 3 4 5 6 7 1742 +---+---+---+---+---+---+---+---+ 1743 FEEDBACK (GENERAL) | 0 | 0 | 0 | 0 | 1 | Type | 1744 +---+---+---+---+---+---+---+---+ 1745 : Context Identifier (CID) : 1746 +...+...+...+...+...+...+...+...+ 1748 Note that The CID field is present only for profiles using STATIC 1749 packet format 2 or 4, which are profiles supporting multiple packet 1750 streams. The Type field tells what kind of feedback the packet 1751 corresponds to and the feedback types defined are the following: 1753 0 1 2 3 4 5 6 7 1754 +---+---+---+---+---+---+---+---+ 1755 STATIC FAILURE FEEDBACK | 0 0 0 1 1 | 0 0 0 | 1756 +---+---+---+---+---+---+---+---+ 1757 : Context Identifier (CID) : 1758 +...+...+...+...+...+...+...+...+ 1760 The STATIC_FAILURE_FEEDBACK packet tells the compressor that the 1761 static part of the decompressor context is invalid, and that an 1762 update of that part is required. Reasons for sending such feedback 1763 could be that no STATIC packet has been received at all, or that 1764 decompression has failed even when DYNAMIC packets are decompressed. 1766 0 1 2 3 4 5 6 7 1767 +---+---+---+---+---+---+---+---+ 1768 INVALID CONTEXT FEEDBACK | 0 0 0 1 1 | 0 0 1 | 1769 +---+---+---+---+---+---+---+---+ 1770 | Last Sequence Number LSB | 1771 +---+---+---+---+---+---+---+---+ 1772 : Context Identifier (CID) : 1773 +...+...+...+...+...+...+...+...+ 1775 The INVALID_CONTEXT_FEEDBACK packet SHOULD be sent to signal an 1776 invalid decompressor context, indicated by failing decompression of 1777 COMPRESSED packets. 1779 0 1 2 3 4 5 6 7 1780 +---+---+---+---+---+---+---+---+ 1781 NO PACKETS FEEDBACK | 0 0 0 1 1 | 0 1 0 | 1782 +---+---+---+---+---+---+---+---+ 1783 | Last Sequence Number LSB | 1784 +---+---+---+---+---+---+---+---+ 1785 : Context Identifier (CID) : 1786 +...+...+...+...+...+...+...+...+ 1788 The NO_PACKET_FEEDBACK packet can be used by the decompressor to 1789 signal that packets have not been received for some time. It is not 1790 always possible for the decompressor to notice such events, and it is 1791 therefore up to the implementers to decide whether and when to use 1792 this feedback packet. 1794 0 1 2 3 4 5 6 7 1795 +---+---+---+---+---+---+---+---+ 1796 LONGEST_LOSS FEEDBACK | 0 0 0 1 1 | 0 1 1 | 1797 +---+---+---+---+---+---+---+---+ 1798 | Last Sequence Number LSB | 1799 +---+---+---+---+---+---+---+---+ 1800 | Length of longest loss | 1801 +---+---+---+---+---+---+---+---+ 1802 : Context Identifier (CID) : 1803 +...+...+...+...+...+...+...+...+ 1805 The LONGEST_LOSS_FEEDBACK packet can be used by the decompressor to 1806 inform the compressor about the length of the longest loss event that 1807 has occurred on the link between compressor and decompressor. It is 1808 not always possible for the decompressor to provide this information, 1809 and it is therefore up to the implementers to decide whether and when 1810 to use this feedback packet. 1812 0 1 2 3 4 5 6 7 1813 +---+---+---+---+---+---+---+---+ 1814 CONTEXT_UPDATED_FEEDBACK | 0 0 0 1 1 | 1 0 0 | 1815 +---+---+---+---+---+---+---+---+ 1816 | Last Sequence Number LSB | 1817 +---+---+---+---+---+---+---+---+ 1818 : Context Identifier (CID) : 1819 +...+...+...+...+...+...+...+...+ 1821 The CONTEXT_UPDATED_FEEDBACK packet can be used to signal that an 1822 update of some header fields has been correctly received, either in a 1823 DYNAMIC packet or in an EXTENDED_COMPRESSED packet. It is optional to 1824 use this active feedback mechanism and the compressor MUST NOT expect 1825 such packets initially. First after reception of one such packet, the 1826 compressor can expect to get this feedback from the decompressor. 1828 7.6. Interpretations of the Code-field 1830 The usage of the Code-field in COMPRESSED headers (the 28 or 12 code- 1831 points left after packet type identification) differs from profile to 1832 profile. The field is used in four different ways for the profiles 1833 defined in this document, as shown in table 7.2.: 1835 S - Sequence encoding 1837 The remaining 28 or 12 code-points are used for sequence 1838 number LSP encoding as described in chapter 7.7.1. 1840 C - Context Identification (CID) 1842 The code-points are used to separate up to 28 different packet 1843 streams. When used in this way, the sequence encoding MUST be 1844 done in extension headers. The encoding is performed using the 1845 same principles as for S above, but with LSB instead of LSP 1846 and using the SEQ LSB field of an extension. However, as long 1847 as the sequence value is increasing by one and also has been 1848 in at least the three preceding packets, the sequence 1849 information MAY be completely omitted. If the decompressor 1850 receives a packet without sequence information it uses 1851 reconstruction attempts to find the correct value, as 1852 described in chapter 7.7.3. 1854 I/S - IP Identification LSP OR Sequence encoding 1856 For profiles using this Code-field interpretation, the field 1857 could be used both for sequence and IP Identification 1858 encoding. There are two rules for where to sent what: 1860 # Normally, the IP Identification LSP is encoded in the 1861 Code-field as described in chapter 7.7.1. The sequence 1862 number is then either sent as the LSB in an extension header 1863 or not sent at all as described in chapter 7.7.3. 1865 # If the IP identification offset has changed too much to be 1866 encoded in the Code-field, it MUST be sent in an extension 1867 instead as described in chapter 7.7.2, and for these cases 1868 the sequence number MUST be encoded in the Code-field as 1869 described in 7.7.1. 1871 S/I - Sequence encoding OR IP Identification LSP 1873 This is almost the same interpretation as in I/S above but 1874 with the difference that as long as the IP Identification 1875 follows the sequence number, sequence LSP is encoded in the 1876 Code-field. IP Identification LSP is sent in the Code-field 1877 only if the sequence number LSB is sent in an extension 1878 (provided that the number of code-points are sufficient). 1880 7.7. Encoding of field values 1882 The source increases the RTP sequence number by one for each packet 1883 sent. However, due to losses and reordering before the compression 1884 point, the changes seen by the compressor may vary. This would 1885 especially be the case if we consider the scenario in Figure 1.1 1886 where there are cellular links at both ends of the path. That is one 1887 reason why sequence number changes need special treatment, but 1888 another reason is that both timestamps and IP identification for most 1889 packets can be recreated with a combination of history and sequence 1890 number knowledge. The profiles defined in this document handle the 1891 sequence numbers with three different methods: LSP encoding, LSB 1892 encoding and, in some common cases, header reconstruction attempts 1893 without requiring any information in the compressed header. LSP and 1894 LSB encoding are also used for the IP Identification field in some of 1895 the profiles defined here. This chapter describes how the encoding 1896 methods in chapter 7.4 are applied to the various field values. 1898 7.7.1. LSP encoding of field values 1900 LSP, as described in chapter 7.4.2, is used in the Code-field of the 1901 "normal" COMPRESSED header (chapter 7.5.3). For profiles not using 1902 the MINIMAL_COMPRESSED header format, there are 28 code-points in the 1903 Code-field left for sequence encoding. An LSP of size 28 is therefore 1904 used with the following encoding (+4 because 0-3 are reserved): 1906 CODE(n) = LSP:28(n) + 4 1908 For profiles using the MINIMAL_COMPRESSED header format, 12 code- 1909 points in the "normal" COMPRESSED header are left for other usage, 1910 meaning that an LSP of size 12 must be used instead. However, the 1911 encoding is the same: 1913 CODE(n) = LSP:12(n) + 4 1915 The reordering parameter for LSP MUST be set to 1 meaning that first 1916 order reordering can be handled by encoding in the Code-field. 1918 7.7.2. LSB encoding of field values 1920 In MINIMAL_COMPRESSED headers (chapter 7.5.4), LSB encoding with 4 1921 bits is used for sequence numbers. LSB encoding with various sizes is 1922 also used when transmitting sequence number, timestamp and IP 1923 Identification information in extended compressed headers. 1925 7.7.3. Sequence encoding with no information 1927 Some profiles make use of headers without any sequence number 1928 information at all provided. Such headers MUST NOT be used by the 1929 compressor if the sequence number has changed irregularly (by other 1930 values than +1) for the current or any of the 3 previous packets 1931 transmitted. In such cases, extended compressed headers MUST be used. 1932 If the decompressor receives a packet without explicit sequence 1933 information, it should instead use reconstruction attempts to find 1934 the correct value. The attempts are based on the knowledge that the 1935 received and previous sent (maybe lost) packets all had a sequence 1936 number increase of 1. The attempts SHOULD be: 1938 1 - No loss: S(n) = S(n-1) + 1 1940 2 - One lost: S(n) = S(n-1) + 2 1942 3 - Two lost: S(n) = S(n-1) + 3 1944 4 - Three lost: S(n) = S(n-1) + 4 1946 If possible, more attempts could be performed. 1948 7.8. Header compression CRCs, coverage and polynomials 1950 This chapter contains a description of how to calculate the different 1951 CRCs used by the ROCCO profiles defined in this document. 1953 7.8.1. STATIC packet CRC 1955 The CRC in the STATIC header is calculated over the whole STATIC 1956 packet except for the header compression CRC itself. Therefore, the 1957 header compression CRC field MUST be set to 0 before the CRC 1958 calculation. 1960 The CRC polynomial to be used in STATIC packets is: 1962 C(x) = 1 + x + x^2 + x^8 1964 7.8.2. DYNAMIC packet CRC 1966 The CRC in the DYNAMIC packet is calculated over the original 1967 IP/UDP/RTP header. Before the calculation of the CRC, the IPv4 header 1968 checksum and the UDP checksum have to be set to 0. This makes it 1969 possible to recalculate the checksums after the decompression. 1970 Calculation over the full IP/UDP/RTP headers ensures that the 1971 decompressed IP/UDP/RTP header is a correct header. 1973 The CRC polynomial to be used in DYNAMIC packets is: 1975 C(x) = 1 + x + x^2 + x^8 1977 7.8.3. COMPRESSED packet CRCs 1979 The header compression CRC in the COMPRESSED header is calculated 1980 over the same headers as the CRC in the DYNAMIC packet. The only 1981 difference is that the polynomial to be used is: 1983 C(x) = 1 + x + x^4 + x^5 + x^9 + x^10 1985 In the MINIMAL_COMPRESSED header, the coverage is the same but with a 1986 different polynomial: 1988 C(x) = 1 + x + x^3 1990 8. Implementation issues 1992 The profiles defined in this document specifies mechanisms for the 1993 protocol, while much of the usage of these mechanisms is left to the 1994 implementers to decide upon. This chapter is aimed to give 1995 guidelines, ideas and suggestions for implementing the scheme. 1997 8.1. Feedback and context update procedures 1999 How to send and respond to the various kinds of FEEDBACK packets is 2000 not defined in this document, but left to the implementers to decide. 2001 However, it is recommended to reduce both the number of requests and 2002 the number of corresponding updating packets to a suitable level. 2003 Also it is recommended to use COMPRESSED packets with EXTENSIONS 2004 instead of DYNAMIC packets to update an invalid context, when 2005 possible. 2007 More guidelines on this issue will be included here when the 2008 implementation experience grows. 2010 8.2. ROCCO over simplex links 2012 This chapter contains a discussion about how ROCCO can be used over 2013 simplex links. 2015 Previous chapters assumed that the decompressor has the possibility 2016 of sending requests to the compressor. This is true for many systems 2017 but there are several important transport systems that cannot 2018 possibly send information back to the compressor. The most important 2019 case may be when the packet are broadcast in some way. It can, for 2020 example, be the communication from a satellite. Over a simplex link 2021 the decompressor does not have the possibility of sending information 2022 back to the compressor. The compressor does not know when the 2023 decompressor needs a STATIC or DYNAMIC packet. If STATIC and DYNAMIC 2024 packets are sent at regular intervals it is possible for the 2025 decompressor to recover a lost context. A slow-start mechanism and a 2026 periodic refresh guarantee that the decompressor can recover a lost 2027 synchronization fast. 2029 The ROCCO scheme is especially suited for simplex links, since it is 2030 possible for the decompressor to continue with guesses until the next 2031 STATIC/DYNAMIC packet arrives. It is then possible for the 2032 decompressor to recover the context before the next STATIC/DYNAMIC 2033 packet arrives. 2035 When ROCCO is used over simplex links it is RECOMMENDED that only one 2036 DYNAMIC packet be sent at a time and not several as stated in 2037 previous chapters. 2039 8.2.1. Compression slow-start 2041 When a field in the STATIC or DYNAMIC packet has changed or if we are 2042 at the beginning of a ROCCO session, it is necessary to send the 2043 STATIC/DYNAMIC packet to the decompressor. To ensure that the new 2044 information reaches the decompressor as fast as possible even if 2045 packets are lost over the link, a slow-start mechanism is used. After 2046 the first two packets (STATIC and DYNAMIC), STATIC and DYNAMIC 2047 packets (read refresh) are sent with an exponentially increasing 2048 period until a new change occurs. The following figure shows how the 2049 slow-start works: 2051 |.|..|....|........|................|............................ 2052 ^ 2053 Change in STATIC and/or DYNAMIC packet 2055 Sent packets: 2056 . Packet with compressed header 2057 | STATIC packet followed by a DYNAMIC packet 2059 8.2.2. Periodic refresh 2061 To prevent the period between two refreshes from increasing too much, 2062 an upper limit on the interval between refreshes is set (MAX_PERIOD). 2063 This is used to avoid losing too many packets if the decompressor has 2064 lost its context. If the MAX_PERIOD between two refreshes is reached 2065 a new refresh (STATIC/DYNAMIC) has to be sent. 2067 To avoid long time periods between two refreshes an upper limit on 2068 the time between two packets is used (MAX_TIME). This ensures that 2069 the time between two refreshes does not exceed the MAX_TIME even if 2070 no MAX_PERIOD packets are sent. If the MAX_TIME between two refreshes 2071 is reached, a new refresh (STATIC/DYNAMIC) has to be sent. 2073 8.2.3. Refresh recommendations 2075 It is recommended that the MAX_PERIOD not exceed 256 packets and that 2076 the maximum time between two refreshes (MAX_TIME) not exceed 5 2077 seconds. 2079 8.2.4. Cost and robustness of refreshes 2081 If we assume that STATIC/DYNAMIC packets are sent every f'th packet, 2082 the average header size is: 2084 (S+U-C) 2085 ----- + C 2086 f 2088 S = STATIC header size 2089 U = DYNAMIC header size 2090 C = COMPRESSED header size 2092 The increase in average header size compared with the COMPRESSED 2093 header size is: 2095 (S+U-C) 2096 ----- 2097 f 2099 If we assume that we use ROCCO profile number 4 and that a refresh is 2100 sent every 256th packet, the increase in average header size is 2101 (18+15-2)/256=0.12 octets. The average header size for ROCCO profile 2102 number 4 over duplex links is with realistic BER 2.15 octets 2103 (appendix B.6). This results in an average header size of 2104 2.15+0.12=2.27 octets. 2106 The difference in robustness of ROCCO between simplex links and 2107 duplex links is very small. The reason for this is that the ROCCO 2108 decompressor very seldom loses its context. This results in that 2109 FEEDBACK packets are almost never needed, as proven in simulations. 2110 For example: In profile number 4 it is possible to lose up to 26 2111 consecutive packets without losing the context in the decompressor. 2112 The probability that 27 consecutive packets are lost is very small 2113 even if channels with high bit error rates are used. This indicates 2114 that a ROCCO scheme implemented over simplex links is almost as 2115 robust as the duplex ROCCO scheme. 2117 8.2.5. Simplex link improvements 2119 DYNAMIC information can be sent in two different ways: either as an 2120 ordinary DYNAMIC packet or as extensions to COMPRESSED headers. If 2121 the information is sent in extensions to COMPRESSED headers, it is 2122 possible to reduce the average header size, since a COMPRESSED header 2123 with extension is smaller than a DYNAMIC header. If COMPRESSED 2124 headers are used for transmission of DYNAMIC information the 2125 following is important: 2127 - All fields in the DYNAMIC packet that have changed since the last 2128 3-4 refreshes have to be transmitted in the extension. 2129 - DYNAMIC and STATIC packets still have to be sent at regular 2130 intervals to ensure that it is possible to recover a lost context 2131 even if COMPRESSED extension refreshes have failed. 2133 8.3. Pre-verification of CRCs 2135 For reasons of compression efficiency, it is desirable to keep the 2136 size of the header compression CRC as small as possible. However, if 2137 the size of the CRC is decreased, the reliability is also decreased 2138 and erroneous headers could be generated and passed on from the 2139 decompressor. It would then be desirable to find a method of 2140 increasing the strength of the CRC without making it larger. 2142 There is one property of the ROCCO CRC and its usage that can be used 2143 to achieve this goal. The CRCs that will occur at the decompressor 2144 will in most cases follow a pattern well known also to the 2145 compressor. There are two factors that will affect which CRCs are 2146 generated and in which order they will occur. If the decompressor 2147 makes several reconstruction attempts, the first factor affecting the 2148 CRCs will be the order and properties of the assumptions made for 2149 each reconstruction attempt. The attempts are in general: 2151 1:st attempt: No loss is assumed 2152 2:nd attempt: Loss of the preceding packet is assumed 2153 3:rd attempt: Loss of the two preceding packets is assumed 2154 4:th attempt: Loss of the three preceding packets is assumed 2155 etc. 2157 The other factor that will affect the CRCs generated is what has 2158 really happened to preceding packets, that is, if no loss has 2159 occurred or if one or several preceding packets have been lost 2160 between compressor and decompressor. 2162 Since the compressor knows how the decompressor performs the 2163 reconstruction attempts, the compressor can PRE-CALCULATE and VERIFY 2164 the most probable CRC situations. If a CRC is found not to detect an 2165 erroneous header, then a different packet type with a larger CRC 2166 (such as the "normal" COMPRESSED packet) should be used instead or 2167 additional information could be sent (by using EXTENDED_COMPRESSED or 2168 DYNAMIC packets). To ensure reliability, the important thing is that 2169 the CRC must fail if the header is not correctly reconstructed. 2170 Combining the two factors described above gives a list of the most 2171 probable CRCs that MUST fail. 2173 - If ONE packet WAS lost, attempt one (no loss) MUST fail 2174 - If TWO packets WERE lost, attempt one (no loss) MUST fail 2175 - If TWO packets WERE lost, attempt two (one lost) MUST fail 2176 - If THREE packets WERE lost, attempt one (no loss) MUST fail 2177 - If THREE packets WERE lost, attempt two (one lost) MUST fail 2178 - If THREE packets WERE lost, attempt three (two lost) MUST fail 2179 - etc. 2181 By doing PRE-CALCULATIONS of the six CRCs that would be the result of 2182 the events listed above, the CRC can be kept strong enough, even with 2183 a reduced size, because CRCs likely to fail will be avoided. 2185 8.4. Using "guesses" with LSB and LSP encoding 2187 ROCCO profiles using LSP encoding can handle 26 or 10 consecutive 2188 packet losses without invalidating the context. LSB or LSP encoding 2189 is also used for other fields and the range handled is then much 2190 larger. However, for all LSP or LSB decoding, the range can be 2191 extended with multiples by making reconstruction attempts (also 2192 called "guesses"). The limiting factors are implementation complexity 2193 and time. The following example shows how this can be done: 2195 In chapter 7.4.2, LSP encoding is described. When an LSP encoded 2196 value for M code-points is decoded to a value S'(n), the original 2197 header can be reconstructed. If the CRC verification fails, a new 2198 reconstruction attempt could be made with S'(n)+M as the sequence 2199 number. If M was a multiple of 2 (LSB encoding), this would be the 2200 same as changing the value of the lowest MSB bit (i.e. the lowest bit 2201 NOT transmitted in LSB). More attempts could then be made increasing 2202 the sequence number by M for each attempt. 2204 9. Further work 2206 The ROCCO scheme, including the compression profiles for IP telephony 2207 defined in this document, has been iterated and optimized for almost 2208 a year, and most of the desired functionality is today supported. 2209 However, much work remains before all details are settled. In 2210 addition to the tuning efforts, there are still new issues that 2211 should be investigated and implemented. This chapter elaborates on 2212 some ideas that might be sensible to apply to the scheme. 2214 9.1. Timer-based timestamp reconstruction 2216 The RTP timestamp field is one of the header fields that may change 2217 dynamically on a per packet basis. In chapter 7.7 it is stated that 2218 the timestamp value can be inferred from the encoded RTP sequence 2219 number value for audio services during talk spurts. When the encoded 2220 sequence number is incremented by N, the timestamp value is 2221 incremented by N * Timestamp-Delta-value. However, when a talk spurt 2222 has faded into silence and a new talk spurt starts, the timestamp 2223 value will take a leap compared to the sequence number. To 2224 communicate this leap in the timestamp value, some additional action 2225 has to be taken. In chapter 7.5.5 extension headers are used to 2226 transfer this leap in the timestamp value. That increases, however, 2227 the average header size. This subchapter presents a possible non- 2228 mandatory mechanism for solving this problem, without adding any 2229 additional header bits, through the use of timers or a local wall 2230 clock at the decompressor. 2232 To initialize the header compression and the timer based timestamp 2233 reconstruction the absolute value of the timestamp together with the 2234 sequence number must be transferred from compressor to decompressor 2235 at the beginning of the compression session. A default timestamp 2236 delta is also transferred. For speech codecs with 8 kHz sampling 2237 frequency and 20 ms frame sizes, for example, the timestamp delta 2238 will be 8000*0.02 = 160. The decompressor then knows that the 2239 timestamp will increase by 160 for each packet containing 20 ms of 2240 speech. Hence, by using a local clock and by measuring packet arrival 2241 times, the decompressor can estimate the timestamp change compared to 2242 the previous packet. If, for example, a speech period has been 2243 succeeded by a silence period at the time T0 and a new speech period 2244 starts at the time T0+dT, it can be assumed that the timestamp has 2245 changed by: 2246 round(dT/(time for one speech frame)) * (timestamp delta) 2248 In a numeric example with dT = 103 ms, this translates into: 2249 timestamp change = round(103/20) * 160 = 5*160 = 800 2250 Hence, the local clock at the decompressor indicates that the 2251 timestamp has changed by 5 packet time intervals and the timestamp 2252 should thus be incremented by 5*160 = 800. 2254 This timestamp change value is finally added to the previous 2255 timestamp value (as received at time T0) to give a reconstructed 2256 value of the timestamp. 2258 The packet time interval (or codec frame size in time) may be 2259 determined through the a priori knowledge that most speech codecs 2260 have constant frame sizes of 10, 20 or 30 ms, or through measurements 2261 on packet arrival times. 2263 The correctness of a timestamp estimation based on timers MUST always 2264 be verified to ensure the correctness of the decompressed full 2265 header. This verification is preferably done using the header 2266 compression CRC or possibly some small number of least significant 2267 timestamp bits included in the compressed header. 2269 This mechanism makes it possible for the decompressor to reconstruct 2270 the timestamp value at the beginning of speech periods (when the 2271 timestamp has taken a leap compared to the sequence number) without 2272 imposing the need for extra timestamp bits in the compressed header 2273 at this event. Hence, it removes the need for sending extensions to 2274 compressed headers when the timestamp value cannot be inferred from 2275 the sequence number and therefore decreases the average header size. 2277 The usefulness of timer based timestamp reconstruction may be smaller 2278 for video services since the timestamp for video services will have a 2279 less regular timestamp increment compared to the sequence number 2280 increment. If, for example, MPEG4 is used, the timestamp may in fact 2281 have a negative difference compared to the previous packet. MPEG4 can 2282 use I, P and B-frames. B-frames are encoded using two consecutive P- 2283 frames and the B-frame contains the video contents between these two 2284 P-frames. The B-frame is however sent (with RTP) after the two P- 2285 frames, and the timestamp difference may thus be negative compared to 2286 the sequence number change. Hence, a timer-based timestamp 2287 reconstruction may thus have a higher failure rate for video 2288 services. 2290 The usage of timer-based timestamp reconstruction MUST NOT be 2291 mandatory in a scheme, since a decompressor should not be dependent 2292 on the availability of a wall clock or timer. 2294 9.2. Compression of IPv6 extension headers 2296 The ROCCO compression profiles defined in this document currently do 2297 not support compression of IPv6 extension headers, which is an 2298 undesirable limitation. Therefore, it is necessary to investigate 2299 what is really needed from the compression scheme regarding 2300 compression of extensions, and also to further develop the current 2301 and future compression profiles including the desired extension 2302 support. 2304 9.3. Replacement of the UDP checksum 2306 When the UDP checksum is enabled (which is always the case with 2307 IPv6), it must be included in all compressed headers, meaning that 2308 the minimal header size is increased by 2 octets. This is undesirable 2309 from a compression point of view but for most header compression 2310 schemes there has been no other solution. 2312 However, there is one other possible solution which is applicable 2313 especially to ROCCO. The idea is to replace the UDP checksum by a 2314 stronger checksum over the link where header compression is carried 2315 out. A CRC would provide a stronger error detection than the UDP 2316 checksum, even with fewer bits, and if the CRC coverage is chosen in 2317 a suitable way it could at the same time serve as the header 2318 compression checksum. By combining the UDP checksum and the header 2319 compression CRC into one stronger CRC, header compression profiles 2320 could be designed with a smallest header size of 3 or maybe only 2 2321 octets, even with support for the UDP checksum. 2323 This idea would be even more applicable in a scenario where UDP Lite 2324 is used with a checksum coverage limited to the headers only, because 2325 the checksum coverage would then be exactly the same as for the 2326 header compression CRC in ROCCO. 2328 9.4. Efficient compression of CSRC lists 2330 The compression profiles defined in this document do support 2331 transmission of CSRC items, but this could probably be done in a much 2332 more efficient manner. Improved solutions for the CSRC compression 2333 would be preferable because if CSRC lists occur, the headers will be 2334 significantly expanded due to the size of the CSRC items. 2336 9.5. General, media independent profiles 2338 This document defines header compression profiles optimized for IP 2339 telephony packet streams. Independently of packet stream 2340 characteristics, these profiles will successfully compress and 2341 decompress the headers of all IP/UDP/RTP packets. However, the 2342 compression will not be done in an optimal way. Therefore, general 2343 profiles should be designed that is optimized to handle 2344 uncharacterized or intermixed RTP packet streams as efficient as 2345 possible. 2347 10. Implementation status 2349 The ROCCO algorithm, as defined in previous versions of this Internet 2350 draft, has been implemented in a testbed environment for realtime IP 2351 traffic over wireless channels. Currently, profile #7 and #23 of 2352 ROCCO version 03 (renumbered #4 and #24 in ROCCO version 04) are 2353 implemented. In the testbed it is possible to listen to the effects 2354 of header compression in conjunction with packet losses. The 2355 currently implemented profiles are optimized for voice traffic only. 2356 A first rough estimate of the CPU utilization showed that ROCCO used 2357 slightly more computational power than CRTP. On the other hand, with 2358 ROCCO the audio quality is significantly better. Figure 10.1 shows a 2359 block diagram of the testbed environment. 2361 +---------+ +---------------+ +----------+ +------------+ 2362 | Speech |-->| RTP/UDP/IP |-->| Wired IP |-->| Header |--> 2363 | Encoder | | Encapsulation | | Network | | Compressor | 2364 +---------+ +---------------+ +----------+ +------------+ 2366 +----------+ +--------------+ +---------+ 2367 ~~>| Cellular |~~>| Header De- |-->| Speech | 2368 | Link | | compressor | | Decoder | 2369 +----------+ +--------------+ +---------+ 2371 Figure 10.1 : Block diagram of testbed environment 2373 The implementation has made some impact on the ROCCO protocol, 2374 realized in this document. Continuously updated information about 2375 implementation status can be obtained from the ROCCO homepage: 2376 http://www.ludd.luth.se/users/larsman/rocco/ 2378 11. Discussion and conclusions 2380 This document has presented ROCCO, a robust header compression 2381 protocol framework adaptable to various usage and requirements. In 2382 addition to the general framework, realizations of the scheme 2383 optimized for IP telephony packet streams have been presented 2384 together with performance results for these realizations. 2386 ROCCO uses CRCs to make local decompressor repairs of the context 2387 possible. Together with robust encoding methods for header fields, 2388 the usage of CRCs has made the scheme very robust and capable of 2389 coping with many consecutive packet losses (up to 26). One other 2390 important advantage with the CRC approach is that it makes the scheme 2391 reliable, meaning that it has a very low probability of incorrect 2392 header reconstruction and forwarding of erroneous headers. 2394 ROCCO defines a concept with header compression profiles, which is an 2395 abstraction that merges all scheme parameters into one. There are two 2396 fundamental advantages with the profile concept. First of all, only 2397 one scheme parameter must be negotiated by the link layer between the 2398 compression and the decompression points and this requirement does 2399 not change even if new internal header compression parameters are 2400 later added with new realizations of the scheme. The second advantage 2401 is the possibility of optimizing the scheme completely for all 2402 situations and functionality requirements by using different 2403 profiles. 2405 Thanks to the profile concept, it has been possible to compress the 2406 headers down to a minimal size of 1 octet, the average header size 2407 being only 1.25 octets. As shown in Appendix B, this is achieved 2408 without introducing any loss of packets due to invalid header 2409 compression context even over links with bit error rates as high as 2410 1e-2. The probability of packet loss due to invalid header 2411 compression context is practically eliminated thanks to the 2412 robustness of ROCCO, even at the high BERs (1e-3 to 1e-2) a cellular 2413 system may produce. 2415 With the profiles defined today in this document and in a separate 2416 document for conversational video [ROVID], ROCCO can efficiently 2417 compress IP/UDP/RTP packet streams for both conversational voice and 2418 video. There are profiles defined for both IPv4 and IPv6, support for 2419 various numbers of concurrent packet streams, enabled or disabled UDP 2420 checksum, etc. Optimizations have been done to efficiently take care 2421 of the IPv4 Identification field and make it more compressible if 2422 knowledge about the sender's assignment policy can be obtained. 2423 Finally, it is also possible to tune the compression scheme to the 2424 characteristics of the channel it is used over. 2426 ROCCO has been evolved and improved during one year. Experiences from 2427 implementations have been taken into account in the process of 2428 improving the scheme. However, even if many suggestions for efficient 2429 implementations are included, there is still room for implementers to 2430 find even more efficient realizations. 2432 Hence, ROCCO provides at the present date a powerful toolbox for 2433 achieving efficient and robust header compression in various types of 2434 scenarios and over various types of links. ROCCO has also been proven 2435 to be suitable for cellular environments. 2437 12. Security considerations 2439 Because encryption eliminates the redundancy that header compression 2440 schemes try to exploit, there is some inducement to forego encryption 2441 in order to achieve operation over low-bandwidth links. However, for 2442 those cases where encryption of data (and not headers) is sufficient, 2443 RTP does specify an alternative encryption method in which only the 2444 RTP payload is encrypted and the headers are left in the clear. That 2445 would still allow header compression to be applied. 2447 A malfunctioning or malicious header compressor could cause the 2448 header decompressor to reconstitute packets that do not match the 2449 original packets but still have valid IP, UDP and RTP headers and 2450 possibly even valid UDP checksums. Such corruption may be detected 2451 with end-to-end authentication and integrity mechanisms which will 2452 not be affected by the compression. Further, this header compression 2453 scheme provides an internal checksum for verification of re- 2454 constructed headers. This reduces the probability of producing 2455 decompressed headers not matching the original ones without this 2456 being noticed. 2458 Denial-of-service attacks are possible if an intruder can introduce 2459 (for example) bogus STATIC, DYNAMIC or FEEDBACK packets onto the link 2460 and thereby cause compression efficiency to be reduced. However, an 2461 intruder having the ability to inject arbitrary packets at the link 2462 layer in this manner raises additional security issues that dwarf 2463 those related to the use of header compression. 2465 13. Acknowledgements 2467 When designing this protocol, earlier header compression ideas 2468 described in [CJHC], [IPHC] and [CRTP] have been important sources of 2469 knowledge. 2471 Thanks to Anton Martensson for many valuable draft contributions. 2473 Andreas Jonsson (Lulea University) made a great job supporting this 2474 work in his study of header field change patterns. Our collaboration 2475 on consistent field classification methods was also very fruitful and 2476 resulted in great improvements to those parts of this document. 2478 14. Intellectual property considerations 2480 This proposal in is conformity with RFC 2002. 2482 Telefonaktiebolaget LM Ericsson and its subsidiaries, in accordance 2483 with corporate policy, will for submissions rightfully made by its 2484 employees which are adopted or recommended as a standard by the IETF 2485 offer patent licensing as follows: 2487 If part(s) of a submission by Ericsson employees is (are) included in 2488 a standard and Ericsson has patents and/or patent application(s) that 2489 are essential to implementation of such included part(s) in said 2490 standard, Ericsson is prepared to grant - on the basis of reciprocity 2491 (grant-back) - a license on such included part(s) on reasonable, non- 2492 discriminatory terms and conditions. 2494 For the avoidance of doubt this general patent licensing undertaking 2495 applies to this proposal. 2497 15. References 2499 [UDP] Jon Postel, "User Datagram Protocol", RFC 768, August 1980. 2501 [IPv4] Jon Postel, "Internet Protocol", RFC 791, September 1981. 2503 [IPv6] Steven Deering, Robert Hinden, "Internet Protocol, Version 6 2504 (IPv6) Specification", RFC 2460, December 1998. 2506 [RTP] Henning Schulzrinne, Stephen Casner, Ron Frederick, Van 2507 Jacobson, "RTP: A Transport Protocol for Real-Time 2508 Applications", RFC 1889, January 1996. 2510 [HDLC] William Simpson, "PPP in HDLC-like framing", RFC 1662, July 2511 1994. 2513 [VJHC] Van Jacobson, "Compressing TCP/IP Headers for Low-Speed 2514 Serial Links", RFC 1144, February 1990. 2516 [IPHC] Mikael Degermark, Bjorn Nordgren, Stephen Pink, "IP Header 2517 Compression", RFC 2507, February 1999. 2519 [CRTP] Steven Casner, Van Jacobson, "Compressing IP/UDP/RTP Headers 2520 for Low-Speed Serial Links", RFC 2508, February 1999. 2522 [PPPHC] Mathias Engan, Steven Casner, Carsten Bormann, "IP Header 2523 Compression over PPP", RFC 2509, February 1999. 2525 [CRTPC] Mikael Degermark, Hans Hannu, Lars-Erik Jonsson, Krister 2526 Svanbro, "CRTP over cellular radio links", Internet Draft 2527 (work in progress), December 1999. 2528 2530 [CELL] Lars Westberg, Morgan Lindqvist, "Realtime traffic over 2531 cellular access networks", Internet Draft 2532 (work in progress), October 1999. 2533 2535 [ROVID] Anton Martensson, Torbjorn Einarsson, Lars-Erik Jonsson, 2536 "ROCCO Conversational Video Profiles", Internet Draft 2537 (work in progress), March 2000. 2538 2540 [WCDMA] "Universal Mobile Telecommunications System (UMTS); 2541 Selection procedures for the choice of radio transmission 2542 technologies of the UMTS (UMTS 30.03 version 3.1.0)". 2543 ETSI TR 101 112 V3.0.1, November 1997. 2544 http://www.etsi.org 2546 16. Authors' addresses 2548 Lars-Erik Jonsson Tel: +46 920 20 21 07 2549 Ericsson Erisoft AB Fax: +46 920 20 20 99 2550 Box 920 Mobile: +46 70 554 82 71 2551 SE-971 28 Lulea, Sweden EMail: lars-erik.jonsson@ericsson.com 2553 Mikael Degermark Tel: +46 920 911 88 2554 Dept of CS & EE Fax: +46 920 728 01 2555 Lulea University of Technology Moblie: +46 70 833 89 33 2556 SE-971 87 Lulea EMail: micke@sm.luth.se 2558 Hans Hannu Tel: +46 920 20 21 84 2559 Ericsson Erisoft AB Fax: +46 920 20 20 99 2560 Box 920 Mobile: +46 70 559 90 15 2561 SE-971 28 Lulea, Sweden EMail: hans.hannu@ericsson.com 2563 Krister Svanbro Tel: +46 920 20 20 77 2564 Ericsson Erisoft AB Fax: +46 920 20 20 99 2565 Box 920 Mobile: +46 70 531 25 08 2566 SE-971 28 Lulea, Sweden EMail: krister.svanbro@ericsson.com 2568 Appendix A. Detailed classification of header fields 2569 (According to chapter 6) 2571 In this appendix, all IP, UDP and RTP header fields are classified as 2572 STATIC, STATIC-DEF, STATIC-KNOWN, INFERRED or CHANGING. For all 2573 fields except for those classified as CHANGING, the classifications 2574 are also motivated. CHANGING fields should be further classified 2575 based on their expected change behavior for various kinds of packet 2576 streams. 2578 A.1. IPv6 header fields 2580 +---------------------+-------------+----------------+ 2581 | Field | Size (bits) | Class | 2582 +---------------------+-------------+----------------+ 2583 | Version | 4 | STATIC-KNOWN | 2584 | Traffic Class | 8 | CHANGING | 2585 | Flow Label | 20 | STATIC-DEF | 2586 | Payload Length | 16 | INFERRED | 2587 | Next Header | 8 | STATIC-KNOWN | 2588 | Hop Limit | 8 | CHANGING | 2589 | Source Address | 128 | STATIC-DEF | 2590 | Destination Address | 128 | STATIC-DEF | 2591 +---------------------+-------------+----------------+ 2593 Version 2595 The version field states which IP version the packet is based on. 2596 Packets with different values in this field must be handled by 2597 different IP stacks. For header compression, different compression 2598 profiles must also be used. When compressor and decompressor have 2599 negotiated which profile to use, the IP version is also known to 2600 both parties. The field is therefore classified as STATIC-KNOWN. 2602 Flow Label 2604 This field may be used to identify packets belonging to a specific 2605 packet stream. If not used, the value should be set to zero. 2606 Otherwise, all packets belonging to the same stream must have the 2607 same value in this field, it being one of the fields defining the 2608 stream. The field is therefore classified as STATIC-DEF. 2610 Payload Length 2612 Information about the packet length (and then also payload length) 2613 is expected to be provided by the link layer. The field is 2614 therefore classified as INFERRED. 2616 Next Header 2618 This field is expected to have the same value in all packets of a 2619 packet stream. As for the version number, a certain compression 2620 profile can only handle a specific next header which means that 2621 this value is known when profile has been negotiated. The field is 2622 therefore classified as STATIC-KNOWN. 2624 Source and Destination addresses 2626 These fields are part of the definition of a stream and must thus 2627 be constant for all packets in the stream. The fields are therefore 2628 classified as STATIC-DEF. 2630 Summarizing the bits corresponding to the classes gives: 2632 +--------------+--------------+ 2633 | Class | Size (octets)| 2634 +--------------+--------------+ 2635 | INFERRED | 2 | 2636 | STATIC-DEF | 34.5 | 2637 | STATIC-KNOWN | 1.5 | 2638 | CHANGING | 2 | 2639 +--------------+--------------+ 2641 A.2. IPv4 header fields 2643 +---------------------+-------------+----------------+ 2644 | Field | Size (bits) | Class | 2645 +---------------------+-------------+----------------+ 2646 | Version | 4 | STATIC-KNOWN | 2647 | Header Length | 4 | STATIC-KNOWN | 2648 | Type Of Service | 8 | CHANGING | 2649 | Packet Length | 16 | INFERRED | 2650 | Identification | 16 | CHANGING | 2651 | Reserved flag | 1 | STATIC-KNOWN | 2652 | May Fragment flag | 1 | STATIC | 2653 | Last Fragment flag | 1 | STATIC-KNOWN | 2654 | Fragment Offset | 13 | STATIC-KNOWN | 2655 | Time To Live | 8 | CHANGING | 2656 | Protocol | 8 | STATIC-KNOWN | 2657 | Header Checksum | 16 | INFERRED | 2658 | Source Address | 32 | STATIC-DEF | 2659 | Destination Address | 32 | STATIC-DEF | 2660 +---------------------+-------------+----------------+ 2662 Version 2664 The version field states which IP version the packet is based on 2665 and packets with different values in this field must be handled by 2666 different IP stacks. For header compression, different compression 2667 profiles must also be used. When compressor and decompressor has 2668 negotiated which profile to use, the IP version is also well known 2669 to both parties. The field is therefore classified as STATIC-KNOWN. 2671 Header Length 2673 As long as there are no options present in the IP header, the 2674 header length is constant and well known. If there are options, the 2675 fields would be STATIC, but we assume no options. The field is 2676 therefore classified as STATIC-KNOWN. 2678 Packet Length 2680 Information about the packet length is expected to be provided by 2681 the link layer. The field is therefore classified as INFERRED. 2683 Flags 2685 The Reserved flag must be set to zero and is therefore classified 2686 as STATIC-KNOWN. The May Fragment flag will be constant for all 2687 packets in a stream and is therefore classified as STATIC. Finally, 2688 the Last Fragment bit is expected to be zero because fragmentation 2689 is NOT expected, due to the small packet size expected. The Last 2690 Fragment bit is therefore classified as STATIC-KNOWN. 2692 Fragment Offset 2694 With the assumption that no fragmentation occurs, the fragment 2695 offset is always zero. The field is therefore classified as STATIC- 2696 KNOWN. 2698 Protocol 2700 This field is expected to have the same value in all packets of a 2701 packet stream. As for the version number, a certain compression 2702 profile can only handle a specific next header which means that 2703 this value is well known when profile has been negotiated. The 2704 field is therefore classified as STATIC-KNOWN. 2706 Header Checksum 2708 The header checksum protects individual hops from processing a 2709 corrupted header. When almost all IP header information is 2710 compressed away, there is no need to have this additional checksum; 2711 instead it can be regenerate at the decompressor side. The field is 2712 therefore classified as INFERRED. 2714 Source and Destination addresses 2716 These fields are part of the definition of a stream and must thus 2717 be constant for all packets in the stream. The fields are therefore 2718 classified as STATIC-DEF. 2720 Summarizing the bits corresponding to the classes gives: 2722 +--------------+--------------+ 2723 | Class | Size (octets)| 2724 +--------------+--------------+ 2725 | INFERRED | 4 | 2726 | STATIC | 1 bit | 2727 | STATIC-DEF | 8 | 2728 | STATIC-KNOWN | 3 +7 bits | 2729 | CHANGING | 4 | 2730 +--------------+--------------+ 2732 A.3. UDP header fields 2734 +------------------+-------------+-------------+ 2735 | Field | Size (bits) | Class | 2736 +------------------+-------------+-------------+ 2737 | Source Port | 16 | STATIC-DEF | 2738 | Destination Port | 16 | STATIC-DEF | 2739 | Length | 16 | INFERRED | 2740 | Checksum | 16 | CHANGING | 2741 +------------------+-------------+-------------+ 2743 Source and Destination ports 2745 These fields are part of the definition of a stream and must thus 2746 be constant for all packets in the stream. The fields are therefore 2747 classified as STATIC-DEF. 2749 Length 2751 This field is redundant and is therefore classified as INFERRED. 2753 Summarizing the bits corresponding to the classes gives: 2755 +------------+--------------+ 2756 | Class | Size (octets)| 2757 +------------+--------------+ 2758 | INFERRED | 2 | 2759 | STATIC-DEF | 4 | 2760 | CHANGING | 2 | 2761 +------------+--------------+ 2763 A.4. RTP header fields 2765 +-----------------+-------------+----------------+ 2766 | Field | Size (bits) | Class | 2767 +-----------------+-------------+----------------+ 2768 | Version | 2 | STATIC-KNOWN | 2769 | Padding | 1 | STATIC | 2770 | Extension | 1 | STATIC | 2771 | CSRC Counter | 4 | CHANGING | 2772 | Marker | 1 | CHANGING | 2773 | Payload Type | 7 | CHANGING | 2774 | Sequence Number | 16 | CHANGING | 2775 | Timestamp | 32 | CHANGING | 2776 | SSRC | 32 | STATIC-DEF | 2777 | CSRC | 0(-480) | CHANGING | 2778 +-----------------+-------------+----------------+ 2780 Version 2782 There exists only one working RTP version and that is version 2. 2783 The field is therefore classified as STATIC-KNOWN. 2785 Padding 2787 The use of this field depends on the application, but when payload 2788 padding is used it is likely to be present in all packets. The 2789 field is therefore classified as STATIC. 2791 Extension 2793 If RTP extensions is used by the application, it is likely to be an 2794 extension present in all packets (but use of extensions is very 2795 uncommon). However, for safety's sake this field is classified as 2796 STATIC and not STATIC-KNOWN. 2798 SSRC 2800 This field is part of the definition of a stream and must thus be 2801 constant for all packets in the stream. The field is therefore 2802 classified as STATIC-DEF. 2804 Summarizing the bits corresponding to the classes gives: 2806 +--------------+--------------+ 2807 | Class | Size (octets)| 2808 +--------------+--------------+ 2809 | STATIC | 2 bits | 2810 | STATIC-DEF | 4 | 2811 | STATIC-KNOWN | 2 bits | 2812 | CHANGING | 7.5(-67.5) | 2813 +--------------+--------------+ 2815 A.5. Summary 2817 If we summarize this for IP/UDP/RTP we get: 2819 +----------------+--------------+--------------+ 2820 | Class \ IP ver | IPv6 (octets)| IPv4 (octets)| 2821 +----------------+--------------+--------------+ 2822 | INFERRED | 4 | 6 | 2823 | STATIC | 2 bits | 3 bits | 2824 | STATIC-DEF | 42.5 | 16 | 2825 | STATIC-KNOWN | 1 +6 bits | 4 +1 bit | 2826 | CHANGING | 11.5(-71.5) | 13.5(-73.5) | 2827 +----------------+--------------+--------------+ 2828 | Total | 60(-120) | 40(-100) | 2829 +----------------+--------------+--------------+ 2831 Appendix B. Simulated performance results 2833 To evaluate the performance of ROCCO and the IP telephony profile, 2834 two header compression schemes have been simulated; CRTP [CRTP] and 2835 ROCCO, both the 2 octet solution (profile number 4) and the 1 octet 2836 solution (profile number 24). Sections B.1 to B.5 provide the 2837 parameters used in the simulations. Sections B.6 and B.7 show the 2838 results. 2840 B.1. Simulated scenario 2842 A source generates RTP packets, which are sent over a wired network 2843 to an end-system where the last link is a cellular link. The RTP 2844 stream is compressed over the last cellular link using one of the two 2845 header compression schemes. The simulated scenario is shown in Figure 2846 B.1. 2848 Source Compression End-system 2849 point _____________ +-------+ 2850 / back channel\ | | 2851 +----+ +---+/ \+----+ | 2852 | |--------->---------| HC|-------->--------|HD | | 2853 +----+ Internet path +---+ Cellular link +----+ | 2854 (loss) | | 2855 +-------+ 2856 Figure B.1 : Simulated scenario. 2858 B.2. Input data 2860 The speech source generates packets with a fixed size, 244 bits, 2861 every 20 ms (12.2 kbps), corresponding to the GSM enhanced full-rate 2862 speech codec. On top of these bits, there is a 12 bit application 2863 CRC, making up a total of 256 bits (32 octets). 2865 The length of the talk spurts and the silent intervals between them 2866 are both exponentially distributed with an expected length of 1 2867 second. Silence suppression is used, meaning that no data is 2868 transmitted during silent periods. 2870 B.3. Influence of pre-HC links 2872 The packet stream suffers from a 0.5% uniformly distributed packet 2873 loss, i.e. in a prior IP network. There is no reordering of packets. 2874 The purpose of using high error probabilities is to test the 2875 capabilities of the schemes also under rough conditions. 2877 B.4. Used link layers 2879 CRTP needs to have the packet type identification provided by the 2880 link layer, whereas ROCCO has the packet type identification 2881 integrated. Hence one octet extra of link layer overhead is added for 2882 the CRTP case. This octet is not included in the presented result. A 2883 16 bit CRC covers only the header and not the payload. This fits in 2884 well with speech coders, which can conceal some damage. This will 2885 also increase the headers seen by the decompressor and hence improve 2886 header compression performance. 2888 A packet is considered as lost if it is not passed up to the 2889 application (speech codec). There are three possible reasons for 2890 packet loss in these simulations: 2891 1. A bit error has occurred in the compressed header. 2892 2. A bit error has occurred in the link layer packet type 2893 identification (for the CRTP case only) or in the link layer 2894 checksum. 2895 3. The header compression scheme has a faulty context and cannot 2896 decompress any received compressed header (context damage). Note 2897 that this can happen even if the compressed header is error free. 2899 B.5. The cellular link 2901 The cellular link is a WCDMA channel simulated with the fading model 2902 in [WCDMA]. The reported bit error rates, BER, are the BERs seen by 2903 the link layer and thus the BERs after channel coding. The back 2904 channel used in our simulations never damages the FEEDBACK messages. 2905 The RTT is set to 120 ms. 2907 B.6. Compression performance 2909 Figure B.2 shows the average header size plotted against BERs for the 2910 two header compression schemes. For BERs around 1e-4 CRTP and ROCCO 2911 profile 4 gives an average header size of just above 2 octets (2.15 2912 for both). ROCCO profile 24 has an average header size just above 1 2913 octet, 1.20, at the same BER. The average header size for CRTP starts 2914 to increase when BER becomes slightly larger than 1e-4; at BER 1e-3 2915 it is 2.35. At higher BERs than 1e-3 the average header size for CRTP 2916 increases faster, and at 1e-2 it is almost 4 octets. For the two 2917 ROCCO profiles (4,24) the average header size remains constant at 2918 2.15 octets and 1.20 octets respectively. 2920 The difference between CRTP and ROCCO is mainly that the latter 2921 tolerates losing several consecutive packets before it needs a 2922 context update packet, while CRTP needs a context update for each 2923 loss. ROCCO therefore requires less updates than CRTP introducing 2924 less header overhead and losing a significantly lower number of 2925 packets. 2927 Figure B.2 : Average header sizes 2929 Figure B.3 shows the variation in header sizes for the schemes. The 2930 variations are due to silences, and thus the RTP timestamp changes 2931 with more than 1 timestamp delta. Most packets are however the 2932 smallest available, around 85-95% for both schemes. As ROCCO can 2933 handle several consecutive packet losses it never has to make any 2934 context requests, but CRTP does have to make them and hence it more 2935 often sends larger packets. 2937 Figure B.3 : Header size variations 2939 B.7. Robustness results 2941 A packet is considered as lost if it is not passed up to the 2942 application (speech codec), meaning that a packet with errors in the 2943 payload is not regarded as lost as long as it is deemed ok by the 2944 header compression scheme. 2946 In figure B.4 the FER is shown for the two header compression 2947 schemes. At BER 2e-4 the FER for CRTP is 1.10%; for both ROCCO 2948 profiles the FER is 0.12%. When the FER increases to 1e-3, CRTP gives 2949 4.06% FER, ROCCO profile 4 gives 0.81% and ROCCO profile 24 gives 2950 0.69%. The difference in robustness is clearly visible for the two 2951 header compression schemes. For CRTP a packet loss between compressor 2952 and decompressor triggers a burst of additional losses due to its 2953 round-trip based error recovery. In figure B.5 this is clearly 2954 visible. 2956 Figure B.4 : Packet loss rate versus BER 2958 Figure B.5 shows the loss pattern for CRTP and ROCCO at BER 4e-3. It 2959 is evident from this figure that the majority of the losses are such 2960 that 7 consecutive packets are lost. This comes from CRTPs round-trip 2961 dependent context repair mechanism. For ROCCO all loss events include 2962 1 or 2 consecutive lost packets, which means that it does not suffer 2963 from context damage. 2965 Figure B.5 : Packet loss patterns for CRTP and ROCCO 2967 B.8. CRC strength considerations 2969 The 10 bits of CRC are used to verify guesses when reconstructing the 2970 header. The only header fields with bits changing between guesses are 2971 the IP identification, RTP sequence number and RTP timestamp. More 2972 than 300,000 different combinations of these fields, according to 2973 what ROCCO should manage, have gone through a CRC calculation without 2974 letting any erroneous packets through. This therefore indicates that 2975 10 bits of CRC is enough to verify the correctness of the guessed 2976 header. 2978 This Internet-Draft expires September 10, 2000.