idnits 2.17.1 draft-ietf-rohc-rfc4995bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document obsoletes RFC3095, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 13, 2010) is 5179 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: 'RFC-ed' is mentioned on line 1615, but not defined == Missing Reference: '0-9a-fA-F' is mentioned on line 1810, but not defined -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4995 (Obsoleted by RFC 5795) -- Obsolete informational reference (is this intentional?): RFC 4996 (Obsoleted by RFC 6846) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Sandlund 3 Internet-Draft G. Pelletier 4 Obsoletes: 4995 (if approved) Ericsson 5 Intended status: Standards Track L-E. Jonsson 6 Expires: July 17, 2010 January 13, 2010 8 The RObust Header Compression (ROHC) Framework 9 draft-ietf-rohc-rfc4995bis-03 11 Abstract 13 The Robust Header Compression (ROHC) protocol provides an efficient, 14 flexible, and future-proof header compression concept. It is 15 designed to operate efficiently and robustly over various link 16 technologies with different characteristics. 18 The ROHC framework, along with a set of compression profiles, was 19 initially defined in RFC 3095. To improve and simplify the ROHC 20 specifications, this document explicitly defines the ROHC framework 21 and the profile for uncompressed separately. More specifically, the 22 definition of the framework does not modify or update the definition 23 of the framework specified by RFC 3095. 25 This specification obsoletes RFC 4995. It fixes one interoperability 26 issue that was erroneously introduced in RFC 4995, and adds some 27 minor clarifications. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on July 17, 2010. 52 Copyright Notice 54 Copyright (c) 2010 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the BSD License. 67 This document may contain material from IETF Documents or IETF 68 Contributions published or made publicly available before November 69 10, 2008. The person(s) controlling the copyright in some of this 70 material may not have granted the IETF Trust the right to allow 71 modifications of such material outside the IETF Standards Process. 72 Without obtaining an adequate license from the person(s) controlling 73 the copyright in such materials, this document may not be modified 74 outside the IETF Standards Process, and derivative works of it may 75 not be created outside the IETF Standards Process, except to format 76 it for publication as an RFC or to translate it into languages other 77 than English. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 83 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5 84 2.2. ROHC Terminology . . . . . . . . . . . . . . . . . . . . . 5 85 3. Background (Informative) . . . . . . . . . . . . . . . . . . . 8 86 3.1. Header Compression Fundamentals . . . . . . . . . . . . . 8 87 3.2. A Short History of Header Compression . . . . . . . . . . 9 88 4. Overview of Robust Header Compression (ROHC) (Informative) . . 10 89 4.1. General Principles . . . . . . . . . . . . . . . . . . . . 10 90 4.2. Compression Efficiency, Robustness, and Transparency . . . 11 91 4.3. Developing the ROHC Protocol . . . . . . . . . . . . . . . 12 92 4.4. Operational Characteristics of the ROHC Channel . . . . . 13 93 4.5. Compression and Master Sequence Number (MSN) . . . . . . . 14 94 4.6. Static and Dynamic Parts of a Context . . . . . . . . . . 15 95 5. The ROHC Framework (Normative) . . . . . . . . . . . . . . . . 15 96 5.1. The ROHC Channel . . . . . . . . . . . . . . . . . . . . . 16 97 5.1.1. Contexts and Context Identifiers . . . . . . . . . . . 16 98 5.1.2. Per-Channel Parameters . . . . . . . . . . . . . . . . 16 99 5.1.3. Persistence of Decompressor Contexts . . . . . . . . . 17 100 5.2. ROHC Packets and Packet Types . . . . . . . . . . . . . . 17 101 5.2.1. General Format of ROHC Packets . . . . . . . . . . . . 18 102 5.2.1.1. Format of the Padding Octet . . . . . . . . . . . 19 103 5.2.1.2. Format of the Add-CID Octet . . . . . . . . . . . 19 104 5.2.1.3. General Format of Header . . . . . . . . . . . . . 19 105 5.2.2. Initialization and Refresh (IR) Packet Types . . . . . 20 106 5.2.2.1. ROHC IR Header Format . . . . . . . . . . . . . . 20 107 5.2.2.2. ROHC IR-DYN Header Format . . . . . . . . . . . . 21 108 5.2.3. ROHC Initial Decompressor Processing . . . . . . . . . 22 109 5.2.4. ROHC Feedback . . . . . . . . . . . . . . . . . . . . 23 110 5.2.4.1. ROHC Feedback Format . . . . . . . . . . . . . . . 24 111 5.2.5. ROHC Segmentation . . . . . . . . . . . . . . . . . . 26 112 5.2.5.1. Segmentation Usage Considerations . . . . . . . . 26 113 5.2.5.2. Segmentation Protocol . . . . . . . . . . . . . . 27 114 5.3. General Encoding Methods . . . . . . . . . . . . . . . . . 28 115 5.3.1. Header Compression CRCs, Coverage and Polynomials . . 28 116 5.3.1.1. 8-bit CRCs in IR and IR-DYN Headers . . . . . . . 28 117 5.3.1.2. 3-bit CRC in Compressed Headers . . . . . . . . . 28 118 5.3.1.3. 7-bit CRC in Compressed Headers . . . . . . . . . 29 119 5.3.1.4. 32-bit Segmentation CRC . . . . . . . . . . . . . 29 120 5.3.2. Self-Describing Variable-Length Values . . . . . . . . 30 121 5.4. ROHC UNCOMPRESSED -- No Compression (Profile 0x0000) . . 30 122 5.4.1. IR Packet . . . . . . . . . . . . . . . . . . . . . . 31 123 5.4.2. Normal Packet . . . . . . . . . . . . . . . . . . . . 31 124 5.4.3. Context Initialization . . . . . . . . . . . . . . . . 32 125 5.4.4. Decompressor Operation . . . . . . . . . . . . . . . . 32 126 5.4.5. Feedback . . . . . . . . . . . . . . . . . . . . . . . 33 128 6. Overview of a ROHC Profile (Informative) . . . . . . . . . . . 33 129 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 130 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 131 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 132 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 133 10.1. Normative References . . . . . . . . . . . . . . . . . . . 37 134 10.2. Informative References . . . . . . . . . . . . . . . . . . 37 135 Appendix A. CRC Algorithm . . . . . . . . . . . . . . . . . . . . 38 136 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 138 1. Introduction 140 For many types of networks, reducing the deployment and operational 141 costs by improving the usage of the bandwidth resources is of vital 142 importance. Header compression over a link is possible because some 143 of the information carried within the header of a packet becomes 144 compressible between packets belonging to the same flow. 146 For links where the overhead of the IP header(s) is problematic, the 147 total size of the header may be significant. Applications carrying 148 data carried within RTP [RFC3550] will then, in addition to link- 149 layer framing, have an IPv4 [RFC0791] header (20 octets), a UDP 150 [RFC0768] header (8 octets), and an RTP header (12 octets), for a 151 total of 40 octets. With IPv6 [RFC2460], the IPv6 header is 40 152 octets for a total of 60 octets. Applications transferring data 153 using TCP [RFC0793] will have 20 octets for the transport header, for 154 a total size of 40 octets for IPv4 and 60 octets for IPv6. 156 The relative gain for specific flows (or applications) depends on the 157 size of the payload used in each packet. For applications such as 158 Voice-over-IP, where the size of the payload containing coded speech 159 can be as small as 15-20 octets, this gain will be quite significant. 160 Similarly, relative gains for TCP flows carrying large payloads (such 161 as file transfers) will be less than for flows carrying smaller 162 payloads (such as application signaling, e.g., session initiation). 164 As more and more wireless link technologies are being deployed to 165 carry IP traffic, care must be taken to address the specific 166 characteristics of these technologies within the header compression 167 algorithms. Legacy header compression schemes, such as those defined 168 in [RFC2507] and [RFC2508], have been shown to perform inadequately 169 over links where both the lossy behavior and the round-trip times are 170 non- negligible, such as those observed for example in wireless links 171 and IP tunnels. 173 In addition, a header compression scheme should handle the often non- 174 trivial residual errors, i.e., where the lower layer may pass a 175 packet that contains undetected bit errors to the decompressor. It 176 should also handle loss and reordering before the compression point, 177 as well as on the link between the compression and decompression 178 points [RFC4224]. 180 The Robust Header Compression (ROHC) protocol provides an efficient, 181 flexible, and future-proof header compression concept. It is 182 designed to operate efficiently and robustly over various link 183 technologies with different characteristics. 185 RFC 3095 [RFC3095] defines the ROHC framework along with an initial 186 set of compression profiles. To improve and simplify the 187 specification, the framework and the profiles' parts have been split 188 into separate documents. This document explicitly defines the ROHC 189 framework, but it does not modify or update the definition of the 190 framework specified by RFC 3095; both documents can be used 191 independently of each other. This also implies that implementations 192 based on either definition will be compatible and interoperable with 193 each other. However, it is the intent to let this specification 194 replace RFC 3095 as the base specification for all profiles defined 195 in the future. 197 This document fixes one interoperability issue that was erroneously 198 introduced in RFC 4995. The fix for this issue is located in 199 Section 5.2.4.1 and clarifies the interpretation of the Size field in 200 ROHC feedback. 202 2. Terminology 204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 205 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 206 document are to be interpreted as described in [RFC2119]. 208 2.1. Acronyms 210 This section lists most acronyms used for reference. 212 ACK Acknowledgment. 213 CID Context Identifier. 214 CO Compressed Packet Format. 215 CRC Cyclic Redundancy Check. 216 IR Initialization and Refresh. 217 IR-DYN Initialization and Refresh, Dynamic part. 218 LSB Least Significant Bit(s). 219 MRRU Maximum Reconstructed Reception Unit. 220 MSB Most Significant Bit(s). 221 MSN Master Sequence Number. 222 NACK Negative Acknowledgment. 223 ROHC RObust Header Compression. 225 2.2. ROHC Terminology 227 Context 229 The context of the compressor is the state it uses to compress a 230 header. The context of the decompressor is the state it uses to 231 decompress a header. Either of these or the two in combination 232 are usually referred to as "context", when it is clear which is 233 intended. The context contains relevant information from previous 234 headers in the packet flow, such as static fields and possible 235 reference values for compression and decompression. Moreover, 236 additional information describing the packet flow is also part of 237 the context, for example, information about the change behavior of 238 fields (e.g., the IP Identifier behavior, or the typical inter- 239 packet increase in sequence numbers and timestamps). 241 Context damage 243 When the context of the decompressor is not consistent with the 244 context of the compressor, decompression may fail to reproduce the 245 original header. This situation can occur when the context of the 246 decompressor has not been initialized properly or when packets 247 have been lost or damaged between the compressor and decompressor. 249 Packets which cannot be decompressed due to inconsistent contexts 250 are said to be lost due to context damage. Packets that are 251 decompressed but contain errors due to inconsistent contexts are 252 said to be damaged due to context damage. 254 Context repair mechanism 256 Context repair mechanisms are used to resynchronize the contexts, 257 an important task since context damage causes loss propagation. 258 Examples of such mechanisms are NACK-based mechanisms, and the 259 periodic refreshes of important context information, usually done 260 in unidirectional operation. There are also mechanisms that can 261 reduce the context inconsistency probability, for example, 262 repetition of the same type of information in multiple packets and 263 CRCs that protect context-updating information. 265 CRC-8 validation 267 The CRC-8 validation refers to the validation of the integrity 268 against bit error(s) in a received IR and IR-DYN header using the 269 8-bit CRC included in the IR/IR-DYN header. 271 CRC verification 273 The CRC verification refers to the verification of the result of a 274 decompression attempt using the 3-bit CRC or 7-bit CRC included in 275 the header of a compressed packet format. 277 Damage propagation 278 Delivery of incorrect decompressed headers due to context damage, 279 that is, due to errors in (i.e., loss of or damage to) previous 280 header(s) or feedback. 282 Error detection 284 Detection of errors by lower layers. If error detection is not 285 perfect, there will be residual errors. 287 Error propagation 289 Damage propagation or loss propagation. 291 ROHC profile 293 A ROHC profile is a compression protocol, which specifies how to 294 compress specific header combinations. A ROHC profile may be 295 tailored to handle a specific set of link characteristics, e.g., 296 loss characteristics, reordering between compression points, etc. 297 ROHC profiles provide the details of the header compression 298 framework defined in this document, and each compression profile 299 is associated with a unique ROHC profile identifier [ROHC-ids]. 300 When setting up a ROHC channel, the set of profiles supported by 301 both endpoints of the channel is negotiated, and when initializing 302 new contexts, a profile identifier from this negotiated set is 303 used to associate each compression context with one specific 304 profile. 306 Link 308 A physical transmission path that constitutes a single IP hop. 310 Loss propagation 312 Loss of headers, due to errors in (i.e., loss of or damage to) 313 previous header(s) or feedback. 315 Packet flow 317 A sequence of packets where the field values and change patterns 318 of field values are such that the headers can be compressed using 319 the same context. 321 Residual error 322 Errors introduced during transmission and not detected by lower- 323 layer error detection schemes. 325 ROHC channel 327 A logical unidirectional point-to-point channel carrying ROHC 328 packets from one compressor to one decompressor, optionally 329 carrying ROHC feedback information on the behalf of another 330 compressor-decompressor pair operating on a separate ROHC channel 331 in the opposite direction. See also [RFC3759]. 333 This document also makes use of the conceptual terminology defined by 334 "ROHC Terminology and Channel Mapping Examples", RFC 3759 [RFC3759]. 336 3. Background (Informative) 338 This section provides a background to the subject of header 339 compression. The fundamental ideas are described together with a 340 discussion about the history of header compression schemes. The 341 motivations driving the development of the various schemes are 342 discussed and their drawbacks identified, thereby providing the 343 foundations for the design of the ROHC framework and profiles 344 [RFC3095]. 346 3.1. Header Compression Fundamentals 348 Header compression is possible because there is significant 349 redundancy between header fields; within the headers of a single 350 packet, but in particular between consecutive packets belonging to 351 the same flow. On the path end-to-end, the entire header information 352 is necessary for all packets in the flow, but over a single link, 353 some of this information becomes redundant and can be reduced, as 354 long as it is transparently recovered at the receiving end of the 355 link. The header size can be reduced by first sending field 356 information that is expected to remain static for (at least most of) 357 the lifetime of the packet flow. Further compression is achieved for 358 the fields carrying information that changes more dynamically by 359 using compression methods tailored to their respective assumed change 360 behavior. 362 To achieve compression and decompression, some necessary information 363 from past packets is maintained in a context. The compressor and the 364 decompressor update their respective contexts upon certain, not 365 necessarily synchronized, events. Impairment events may lead to 366 inconsistencies in the decompressor context (i.e., context damage), 367 which in turn may cause incorrect decompression. A Robust Header 368 Compression scheme needs mechanisms to minimize the possibility of 369 context damage, in combination with mechanisms for context repair. 371 3.2. A Short History of Header Compression 373 The first header compression scheme, compressed TCP (CTCP) [RFC1144], 374 was introduced by Van Jacobson. CTCP, also often referred to as VJ 375 compression, compresses the 40 octets of the TCP/IP header down to 4 376 octets. CTCP uses delta encoding for sequentially changing fields. 377 The CTCP compressor detects transport-level retransmissions and sends 378 a header that updates the entire context when they occur. This 379 repair mechanism does not require any explicit signaling between the 380 compressor and decompressor. 382 A general IP header compression scheme, IP header compression 383 [RFC2507], improves somewhat on CTCP. IP Header Compression (IPHC) 384 can compress arbitrary IP, TCP, and UDP headers. When compressing 385 non-TCP headers, IPHC does not use delta encoding and is robust. The 386 repair mechanism of CTCP is augmented with negative acknowledgments, 387 called CONTEXT_STATE messages, which speeds up the repair. This 388 context repair mechanism is thus limited by the round-trip time of 389 the link. IPHC does not compress RTP headers. 391 CRTP [RFC2508] is an RTP extension to IPHC. CRTP compresses the 40 392 octets of IPv4/UDP/RTP headers to a minimum of 2 octets when the UDP 393 Checksum is not enabled. If the UDP Checksum is enabled, the minimum 394 CRTP header is 4 octets. 396 On lossy links with long round-trip times, CRTP does not perform well 397 [CRTP-eval]. Each packet lost over the link causes decompression of 398 several subsequent packets to fail, because the context becomes 399 invalidated during at least one link round-trip time from the lost 400 packet. Unfortunately, the large headers that CRTP sends when 401 updating the context waste additional bandwidth. 403 CRTP uses a local repair mechanism known as TWICE, which was 404 introduced by IPHC. TWICE derives its name from the observation that 405 when the flow of compressed packets is regular, the correct guess 406 when one packet is lost between the compression points is to apply 407 the update in the current packet twice. While TWICE improves CRTP 408 performance significantly, [CRTP-eval] also found that even with 409 TWICE, CRTP doubled the number of lost packets. 411 An enhanced variant of CRTP, called eCRTP [RFC3545], means to improve 412 the robustness of CRTP in the presence of reordering and packet 413 losses, while keeping the protocol almost unchanged from CRTP. As a 414 result, eCRTP does provide better means to implement some degree of 415 robustness, albeit at the expense of additional overhead, leading to 416 a reduction in compression efficiency in comparison to CRTP. 418 4. Overview of Robust Header Compression (ROHC) (Informative) 420 4.1. General Principles 422 As mentioned earlier, header compression is possible per-link due to 423 the fact that there is much redundancy between header field values 424 within packets, and especially between consecutive packets belonging 425 to the same flow. To utilize these properties for header 426 compression, there are a few essential steps to consider. 428 The first step consists of identifying and grouping packets together 429 into different "flows", so that packet-to-packet redundancy is 430 maximized in order to improve the compression ratio. Grouping 431 packets into flows is usually based on source and destination host 432 (IP) addresses, transport protocol type (e.g., UDP or TCP), process 433 (port) numbers, and potentially additional unique application 434 identifiers, such as the synchronization source (SSRC) in RTP 435 [RFC3550]. The compressor and decompressor each establish a context 436 for the packet flow and identify the context with a Context 437 Identifier (CID) included in each compressed header. 439 The second step is to understand the change patterns of the various 440 header fields. On a high level, header fields fall into one of the 441 following classes: 443 INFERRED These fields contain values that can be inferred from 444 other fields or external sources, for example, the size 445 of the frame carrying the packet can often be derived 446 from the link layer protocol, and thus does not have to 447 be transmitted by the compression scheme. 449 STATIC Fields classified as STATIC are assumed to be constant 450 throughout the lifetime of the packet flow. The value 451 of each field is thus only communicated initially. 453 STATIC-DEF Fields classified as STATIC-DEF are used to define a 454 packet flow as discussed above. Packets for which 455 respective values of these fields differ are treated as 456 belonging to different flows. These fields are in 457 general compressed as STATIC fields. 459 STATIC-KNOWN Fields classified as STATIC-KNOWN are expected to have 460 well-known values, and therefore their values do not 461 need to be communicated. 463 CHANGING These fields are expected to vary randomly, either 464 within a limited value set or range, or in some other 465 manner. CHANGING fields are usually handled in more 466 sophisticated ways based on a more detailed 467 classification of their expected change patterns. 469 Finally, the last step is to choose the encoding method(s) that will 470 be applied onto different fields based on classification. The 471 encoding methods, in combination with the identified field behavior, 472 provide the input to the design of the compressed header formats. 473 The analysis of the probability distribution of the identified change 474 patterns then provides the means to optimize the packet formats, 475 where the most frequently occurring change patterns for a field 476 should be encoded within the most efficient format(s). 478 However, compression efficiency has to be traded against two other 479 properties: the robustness of the encoding to losses and errors 480 between the compressor and the decompressor, and the ability to 481 detect and cope with errors in the decompression process. 483 4.2. Compression Efficiency, Robustness, and Transparency 485 The performance of a header compression protocol can be described 486 with three parameters: its compression efficiency, its robustness, 487 and its compression transparency. 489 Compression efficiency 490 The compression efficiency is determined by how much the average 491 header size is reduced by applying the compression protocol. 493 Robustness 495 A robust protocol tolerates packet losses, residual bit errors, 496 and out-of-order delivery on the link over which header 497 compression takes place, without losing additional packets or 498 introducing additional errors in decompressed headers. 500 Compression transparency 502 The compression transparency is a measure of the extent to which 503 the scheme maintains the semantics of the original headers. If 504 all decompressed headers are bitwise identical to the 505 corresponding original headers, the scheme is transparent. 507 4.3. Developing the ROHC Protocol 509 The challenge in developing a header compression protocol is to 510 conciliate compression efficiency and robustness while maintaining 511 transparency, as increasing robustness will always come at the 512 expense of a lower compression efficiency, and vice-versa. The 513 scheme should also be flexible enough in its design to minimize the 514 impacts from the varying round-trip times and loss patterns of links 515 where header compression will be used. 517 To achieve this, the header compression scheme must provide 518 facilities for the decompressor to verify decompression and detect 519 potential context damage, as well as context recovery mechanisms such 520 as feedback. Header compression schemes prior to the ones developed 521 by the Robust Header Compression (ROHC) WG were not designed with the 522 above high-level objectives in mind. 524 The ROHC WG has developed header compression solutions to meet the 525 needs of present and future link technologies. While special 526 attention has been put towards meeting the more stringent 527 requirements stemming from the characteristics of wireless links, the 528 results are equally applicable to many other link technologies. 530 RFC 3095 [RFC3095], "RObust Header Compression (ROHC): Framework and 531 four profiles: RTP, UDP, ESP, and uncompressed", was published in 532 2001, as the first output of the ROHC WG. ROHC is a general and 533 extendable framework for header compression, on top of which profiles 534 can be defined for compression of different protocols headers. RFC 535 3095 introduced a number of new compression techniques, and was 536 successful at living up to the requirements placed on it, as 537 described in [RFC3096]. 539 Interoperability testing of RFC 3095 confirms the capabilities of 540 ROHC to meet its purposes, but feedback from implementers has also 541 indicated that the protocol specification is complex and sometimes 542 obscure. Most importantly, a clear distinction between framework and 543 profiles is not obvious in [RFC3095], which also makes development of 544 additional profiles troublesome. This document therefore aims at 545 explicitly specifying the ROHC framework, while a companion document 546 [RFC5225] specifies revised versions of the compression profiles of 547 RFC 3095. 549 4.4. Operational Characteristics of the ROHC Channel 551 Robust header compression can be used over many type of link 552 technologies. The ROHC framework provides flexibility for profiles 553 to address a wide range of applications, and this section lists some 554 of the operational characteristics of the ROHC channel (see also 555 [RFC3759]). 557 Multiplexing over a single logical channel 559 The ROHC channel provides a mechanism to identify a context within 560 the general ROHC packet format. The CID makes it possible for a 561 logical channel that supports ROHC to transport multiple header- 562 compressed flows, while still making it possible for a channel to 563 be dedicated to one single packet flow without any CID overhead. 564 More specifically, ROHC uses a distinct context identifier space 565 per logical channel, and the context identifier can be omitted for 566 one of the flows over the ROHC channel when configured to use a 567 small CID space. 569 Establishment of channel parameters 571 A link layer defining support for the ROHC channel must provide 572 the means to establish header compression channel parameters (see 573 Section 5.1). This can be achieved through a negotiation 574 mechanism, static provisioning, or some out-of-band signaling. 576 Packet type identification 578 The ROHC channel defines a packet type identifier space, and puts 579 restrictions with respect to the use of a number of identifiers 580 that are common for all ROHC profiles. Identifiers that have no 581 restrictions, i.e., identifiers that are not defined by this 582 document, are available to each profile. The identifier is part 583 of each compressed header, and this makes it possible for the link 584 that supports the ROHC channel to allocate one single link layer 585 payload type for ROHC. 587 Out-of-order delivery between compression endpoints 589 Each profile defines its own level of robustness, including 590 tolerance to reordering of packets before but especially between 591 compression endpoints, if any. 593 For profiles specified in [RFC3095], the channel between the 594 compressor and decompressor is required to maintain in-order 595 delivery of the packets, i.e., the definition of these profiles 596 assumes that the decompressor always receives packets in the same 597 order as the compressor sent them. The impacts of reordering on 598 the performance of these profiles is described in [RFC4224]. 599 However, reordering before the compression point is handled, i.e., 600 these profiles make no assumption that the compressor will receive 601 packets in-order. 603 For the ROHCv2 profiles specified in [RFC5225], their definitions 604 assume that the decompressor can receive packets out-of-order, 605 i.e., not in the same order that the compressor sent them. 606 Reordering before the compression point is also dealt with. 608 Duplication of packets 610 The link supporting the ROHC channel is required to not duplicate 611 packets (however, duplication of packets can occur before they 612 reach the compressor, i.e., there is no assumption that the 613 compressor will receive only one copy of each packet). 615 Framing 617 The link layer must provide framing that makes it possible to 618 distinguish frame boundaries and individual frames. 620 Error detection/protection 622 ROHC profiles should be designed to cope with residual errors in 623 the headers delivered to the decompressor. CRCs are used to 624 detect decompression failures and to prevent or reduce damage 625 propagation. However, it is recommended that lower layers deploy 626 error detection for ROHC headers and that ROHC headers with high 627 residual error rates not be delivered. 629 4.5. Compression and Master Sequence Number (MSN) 631 Compression of header fields is based on the establishment of a 632 function to a sequence number, called the master sequence number 633 (MSN). This function describes the change pattern of the field with 634 respect to a change in the MSN. 636 Change patterns include, for example, fields that increase 637 monotonically or by a small value, fields that seldom change,and 638 fields that remain unchanging for the entire lifetime of the packet 639 flow, in which case the function to the MSN is equivalent to a 640 constant value. 642 The compressor first establishes functions for each of the header 643 fields, and then reliably communicates the MSN. When the change 644 pattern of the field does not match the established function, i.e., 645 the existing function gives a result that is different from the field 646 in the header being compressed, additional information can be sent to 647 update the parameters of that function. 649 The MSN is defined per profile. It can be either derived directly 650 from one of the fields of the protocol being compressed (e.g., the 651 RTP SN [RFC5225]), or it can be created and maintained by the 652 compressor (e.g., the MSN for compression of UDP in profile 0x0102 653 [RFC5225] or the MSN in ROHC-TCP [RFC4996]). 655 4.6. Static and Dynamic Parts of a Context 657 A compression context can be conceptually divided into two different 658 parts, the static context and the dynamic context, each based on the 659 properties of the fields that are being compressed. 661 The static part includes the information necessary to compress and 662 decompress the fields whose change behavior is classified as STATIC, 663 STATIC-KNOWN, or STATIC-DEF (as described in Section 4.1 above). 665 The dynamic part includes the state maintained for all the other 666 fields, i.e., those that are classified as CHANGING. 668 5. The ROHC Framework (Normative) 670 This section normatively defines the parts common to all ROHC 671 profiles, i.e., the framework. The framework specifies the 672 requirements and functionality of the ROHC channel, including how to 673 handle multiple compressed packet flows over the same channel. 675 Finally, this section specifies encoding methods used in the packet 676 formats that are common to all profiles. These encoding methods may 677 be reused within profile specifications for encoding fields in 678 profile-specific parts of a packet format, without requiring their 679 redefinition. 681 5.1. The ROHC Channel 683 5.1.1. Contexts and Context Identifiers 685 Associated with each compressed flow is a context. The context is 686 the state that the compressor and the decompressor maintain in order 687 to correctly compress or decompress the headers of the packet in the 688 flow. Each context is identified using a CID. 690 A context is considered to be a new context when the CID is 691 associated with a profile for the first time since the creation of 692 the ROHC channel, or when the CID gets associated from the reception 693 of an IR (this does not apply to the IR-DYN) with a different profile 694 than the profile in the context. 696 Context information is conceptually kept in a table. The context 697 table is indexed using the CID, which is sent along with compressed 698 headers and feedback information. 700 The CID space can be either small, which means that CIDs can take the 701 values 0 through 15, or large, which means that CIDs take values 702 between 0 and 2^14 - 1 = 16383. Whether the CID space is large or 703 small MUST be established, possibly by negotiation, before any 704 compressed packet may be sent over the ROHC channel. 706 The CID space is distinct for each channel, i.e., CID 3 over channel 707 A and CID 3 over channel B do not refer to the same context, even if 708 the endpoints of A and B are the same nodes. In particular, CIDs for 709 any pair of ROHC channels are not related (two associated ROHC 710 channels serving as feedback channels for one another do not even 711 need to have CID spaces of the same size). 713 5.1.2. Per-Channel Parameters 715 The ROHC channel is based on a number of parameters that form part of 716 the established channel state and the per-context state. The state 717 of the ROHC channel MUST be established before the first ROHC packet 718 may be sent, which may be achieved using negotiation protocols 719 provided by the link layer (see also [RFC3241], which describes an 720 option for negotiation of ROHC parameters for PPP). This section 721 describes some of this channel state information in an abstract way: 723 LARGE_CIDS: Boolean; if false, the small CID representation (0 octets 724 or 1 prefix octet, covering CID 0 to 15) is used; if true, the large 725 CID representation (1 or 2 embedded CID octets covering CID 0 to 726 16383) is used. See also Section 5.1.1 and Section 5.2.1.3. 728 MAX_CID: Non-negative integer; highest CID number to be used by the 729 compressor (note that this parameter is not coupled to, but in effect 730 further constrained by, LARGE_CIDS). This value represents an 731 agreement by the decompressor that it can provide sufficient memory 732 resources to host at least MAX_CID+1 contexts; the decompressor MUST 733 maintain established contexts within this space until either the CID 734 gets re-used by the establishment of a new context, or until the 735 channel is taken down. 737 PROFILES: Set of non-negative integers, where each integer indicates 738 a profile supported by both the compressor and the decompressor. A 739 profile is identified by a 16-bit value, where the 8 LSB bits 740 indicate the actual profile, and the 8 MSB bits indicate the variant 741 of that profile. The ROHC compressed header format identifies the 742 profile used with only the 8 LSB bits; this means that if multiple 743 variants of the same profile are available for a ROHC channel, the 744 PROFILES set after negotiation MUST NOT include more than one variant 745 of the same profile. The compressor MUST NOT compress using a 746 profile that is not in PROFILES. 748 FEEDBACK_FOR: Optional reference to a ROHC channel in the opposite 749 direction between the same compression endpoints. If provided, this 750 parameter indicates to which other ROHC channel any feedback sent on 751 this ROHC channel refers (see [RFC3759]). 753 MRRU: Non-negative integer. Maximum Reconstructed Reception Unit. 754 This is the size of the largest reconstructed unit in octets that the 755 decompressor is expected to reassemble from segments (see 756 Section 5.2.5). This size includes the segmentation CRC. If MRRU is 757 negotiated to be 0, segmentation MUST NOT be used on the channel, and 758 received segments MUST be discarded by the decompressor. 760 5.1.3. Persistence of Decompressor Contexts 762 As part of the negotiated channel parameters, the compressor and 763 decompressor have through the MAX_CID parameter agreed on the highest 764 context identification (CID) number to be used. By agreeing on the 765 MAX_CID, the decompressor also agrees to provide memory resources to 766 host at least MAX_CID+1 contexts, and an established context with a 767 CID within this negotiated space SHOULD be kept by the decompressor 768 until either the CID gets re-used, or the channel is taken down or 769 re-negotiated. 771 5.2. ROHC Packets and Packet Types 773 This section uses the following convention in the diagrams when 774 representing various ROHC packet types, formats, and fields: 776 - colons ":" indicate that the part is optional 777 - slashes "/" indicate variable length 779 The ROHC packet type indication scheme has been designed to provide 780 optional padding, a feedback packet type, an optional Add-CID octet 781 (which includes 4 bits of CID), and a simple segmentation and 782 reassembly mechanism. 784 The following packet types are reserved at the ROHC framework level: 786 11100000 : Padding 787 1110nnnn : Add-CID octet (nnnn=CID with values 0x1 through 0xF) 788 11110 : Feedback 789 11111000 : IR-DYN packet 790 1111110 : IR packet 791 1111111 : Segment 793 Other packet types can be defined and used by individual profiles: 795 0 : available (not reserved by ROHC framework) 796 10 : available (not reserved by ROHC framework) 797 110 : available (not reserved by ROHC framework) 798 1111101 : available (not reserved by ROHC framework) 799 11111001 : available (not reserved by ROHC framework) 801 5.2.1. General Format of ROHC Packets 803 A ROHC packet has the following general format: 805 --- --- --- --- --- --- --- --- 806 : Padding : 807 --- --- --- --- --- --- --- --- 808 : Feedback : 809 --- --- --- --- --- --- --- --- 810 : Header : 811 --- --- --- --- --- --- --- --- 812 : Payload : 813 --- --- --- --- --- --- --- --- 815 Padding: Any number (zero or more) of padding octets, where the 816 format of a padding octet is as defined in Section 5.2.1.1. 818 Feedback: Any number (zero or more) of feedback elements, where the 819 format of a feedback element is as defined in Section 5.2.4.1. 821 Header: Either a profile-specific CO header (see Section 5.2.1.3), an 822 IR or IR-DYN header (see Section 5.2.2), or a ROHC Segment (see 823 Section 5.2.5). There can be at most one Header in a ROHC packet, 824 but it may also be omitted (if the packet contains Feedback only). 826 Payload: Corresponds to zero or more octets of payload from the 827 uncompressed packet, starting with the first octet in the 828 uncompressed packet after the last header compressible by the current 829 profile. 831 At least one of Feedback or Header MUST be present. 833 5.2.1.1. Format of the Padding Octet 835 Padding octet: 837 0 1 2 3 4 5 6 7 838 +---+---+---+---+---+---+---+---+ 839 | 1 1 1 0 0 0 0 0 | 840 +---+---+---+---+---+---+---+---+ 842 Note: The Padding octet MUST NOT be interpreted as an Add-CID octet 843 for CID 0. 845 5.2.1.2. Format of the Add-CID Octet 847 Add-CID octet: 849 0 1 2 3 4 5 6 7 850 +---+---+---+---+---+---+---+---+ 851 | 1 1 1 0 | CID | 852 +---+---+---+---+---+---+---+---+ 854 CID: 0x1 through 0xF indicates CIDs 1 through 15. 856 Note: The Padding octet looks like an Add-CID octet for CID 0. 858 5.2.1.3. General Format of Header 860 All ROHC packet types have the following general Header format: 862 0 x-1 x 7 863 --- --- --- --- --- --- --- --- 864 : Add-CID octet : if CID 1-15 and small CIDs 865 +--- --- --- --- ---+--- --- ---+ 866 | type indication | body | 1 octet (8-x bits of body) 867 +--- --- --- --- ---+--- --- ---+ 868 : : 869 / 0, 1, or 2 octets of CID / 1 or 2 octets if large CIDs 870 : : 871 +---+---+---+---+---+---+---+---+ 872 / body / variable length 873 +---+---+---+---+---+---+---+---+ 875 type indication: ROHC packet type. 877 body: Interpreted according to the packet type indication and CID 878 information, as defined by individual profiles. 880 Thus, the header either starts with a packet type indication or has a 881 packet type indication immediately following an Add-CID octet. 883 When the ROHC channel is configured with a small CID space: 885 o If an Add-CID immediately precedes the packet type indication, 886 the packet has the CID of the Add-CID; otherwise, it has CID 0. 888 o A small CID with the value 0 is represented using zero bits; 889 therefore, a flow associated with CID 0 has no CID overhead in 890 the compressed header. In such case, Header starts with a packet 891 type indication. 893 o A small CID with a value from 1 to 15 is represented using the 894 Add-CID octet as described above. The Header starts with the 895 Add-CID octet, followed by a packet type indication. 897 o There is no large CID in the Header. 899 When the ROHC channel is configured with a large CID space: 901 o The large CID is always present and is represented using the 902 encoding scheme of Section 5.3.2, limited to two octets. In this 903 case, the Header starts with a packet type indication. 905 5.2.2. Initialization and Refresh (IR) Packet Types 907 IR packet types contain a profile identifier, which determines how 908 the rest of the header is to be interpreted. They also associate a 909 profile with a context. The stored profile parameter further 910 determines the syntax and semantics of the packet type identifiers 911 and packet types used with a specific context. 913 The IR and IR-DYN packets always update the context for all context- 914 updating fields carried in the header. They never clear the context, 915 except when initializing a new context (see Section 5.1.1), or unless 916 the profile indicated in the Profile field specifies otherwise. 918 5.2.2.1. ROHC IR Header Format 920 The IR header associates a CID with a profile, and typically also 921 initializes the context. It can typically also refresh all (or parts 922 of) the context. For IR, Header has the following general format: 924 0 1 2 3 4 5 6 7 925 --- --- --- --- --- --- --- --- 926 : Add-CID octet : if CID 1-15 and small CID 927 +---+---+---+---+---+---+---+---+ 928 | 1 1 1 1 1 1 0 | x | IR type octet 929 +---+---+---+---+---+---+---+---+ 930 : : 931 / 0-2 octets of CID / 1 or 2 octets if large CIDs 932 : : 933 +---+---+---+---+---+---+---+---+ 934 | Profile | 1 octet 935 +---+---+---+---+---+---+---+---+ 936 | CRC | 1 octet 937 +---+---+---+---+---+---+---+---+ 938 | | 939 / profile specific information / variable length 940 | | 941 +---+---+---+---+---+---+---+---+ 943 x: Profile specific information. Interpreted according to the 944 profile indicated in the Profile field of the IR header. 946 Profile: The profile associated with the CID. In the IR header, the 947 profile identifier is abbreviated to the 8 least significant bits 948 (see Section 5.1.2). 950 CRC: 8-bit CRC (see Section 5.3.1.1). 952 Profile specific information: The content of this part of the IR 953 header is defined by the individual profiles. It is interpreted 954 according to the profile indicated in the Profile field. 956 5.2.2.2. ROHC IR-DYN Header Format 958 In contrast to the IR header, the IR-DYN header can never initialize 959 a non-initialized context. However, it can redefine what profile is 960 associated with a context, if the profile indicated in the IR-DYN 961 header allows this. Thus, this packet type is also reserved at the 962 framework level. The IR-DYN header typically also initializes or 963 refreshes parts of a context. For IR-DYN, Header has the following 964 general format: 966 0 1 2 3 4 5 6 7 967 --- --- --- --- --- --- --- --- 968 : Add-CID octet : if CID 1-15 and small CID 969 +---+---+---+---+---+---+---+---+ 970 | 1 1 1 1 1 0 0 0 | IR-DYN type octet 971 +---+---+---+---+---+---+---+---+ 972 : : 973 / 0-2 octets of CID / 1 or 2 octets if large CIDs 974 : : 975 +---+---+---+---+---+---+---+---+ 976 | Profile | 1 octet 977 +---+---+---+---+---+---+---+---+ 978 | CRC | 1 octet 979 +---+---+---+---+---+---+---+---+ 980 | | 981 / profile specific information / variable length 982 | | 983 +---+---+---+---+---+---+---+---+ 985 Profile: The profile associated with the CID. This is abbreviated in 986 the same way as in IR packets. 988 CRC: 8-bit CRC (see Section 5.3.1.1). 990 Profile specific information: The content of this part of the IR-DYN 991 header is defined by the individual profiles. It is interpreted 992 according to the profile indicated in the Profile field. 994 5.2.3. ROHC Initial Decompressor Processing 996 Initially, all contexts are in no context state. Thus, all packets 997 referencing a non-initialized context, except packets that have 998 enough information on the static fields, cannot be decompressed by 999 the decompressor. 1001 When the decompressor receives a packet of type IR, the profile 1002 indicated in the IR packet determines how it is to be processed. 1004 o If the 8-bit CRC fails to verify the integrity of the Header, the 1005 packet MUST NOT be decompressed and delivered to upper layers. If 1006 a profile is indicated in the context, the logic of that profile 1007 determines what, if any, feedback is to be sent. If no profile is 1008 noted in the context, the logic used to determine what, if any, 1009 feedback to send is up to the implementation. However, it may be 1010 suitable to take no further actions, as any part of the IR header 1011 covered by the CRC may have caused the failure. 1013 When the decompressor receives a packet of type IR-DYN, the profile 1014 indicated in the IR-DYN packet determines how it is to be processed. 1016 o If the 8-bit CRC fails to verify the integrity of the header, the 1017 packet MUST NOT be decompressed and delivered to upper layers. If 1018 a profile is indicated in the context, the logic of that profile 1019 determines what, if any, feedback is to be sent. If no profile is 1020 noted in the context, the logic used to determine what, if any, 1021 feedback to send is up to the implementation. However, it may be 1022 suitable to take no further actions, as any part of the IR-DYN 1023 header covered by the CRC may have caused the failure. 1025 o If the context has not already been initialized, the packet MUST 1026 NOT be decompressed and delivered to upper layers. The logic of 1027 the profile indicated in the IR-DYN header (if verified by the 1028 8-bit CRC), determines what, if any, feedback is to be sent. 1030 If a parsing error occurs for any packet type, the decompressor MUST 1031 discard the packet without further processing. For example, a CID 1032 field is present in the compressed header when the large CID space is 1033 used for the ROHC channel, and the field is coded using the self- 1034 describing variable-length encoding of Section 5.3.2; if the field 1035 starts with 110 or 111, this would generate a parsing error for the 1036 decompressor because this field must not be encoded with a size 1037 larger than 2 octets. 1039 It is RECOMMENDED that profiles disallow the decompressor to make a 1040 decompression attempt for packets carrying only a 3-bit CRC after it 1041 has invalidated some or all of the entire dynamic context, until a 1042 packet that contains sufficient information on the dynamic fields is 1043 received, decompressed, and successfully verified by a 7- or 8-bit 1044 CRC. 1046 5.2.4. ROHC Feedback 1048 Feedback carries information from the decompressor to the compressor. 1049 Feedback can be sent over a ROHC channel that operates in the same 1050 direction as the feedback. 1052 The general ROHC packet format allows transport of feedback using 1053 interspersion or piggybacking (see [RFC3759]), or a combination of 1054 both, over a ROHC channel. This is facilitated by the following 1055 properties: 1057 Reserved packet type: 1059 A feedback packet type is reserved at the framework level. The 1060 packet type can carry variable-length feedback information. 1062 CID information: 1064 The feedback information sent on a particular channel is passed 1065 to, and interpreted by, the compressor associated with feedback on 1066 that channel. Thus, each feedback element contains CID 1067 information from the channel for which the feedback is sent. The 1068 ROHC feedback scheme thus requires that a channel carries feedback 1069 to at most one compressor. How a compressor is associated with 1070 the feedback for a particular channel is outside the scope of this 1071 specification. See also [RFC3759]. 1073 Length information: 1075 The length of a feedback element can be determined by examining 1076 the first few octets of the feedback. This enables piggybacking 1077 of feedback, and also the concatenation of more than one feedback 1078 element in a packet. The length information thus decouples the 1079 decompressor from the associated same-side compressor, as the 1080 decompressor can extract the feedback information from the 1081 compressed header without parsing its content and hand over the 1082 extracted information. 1084 The association between compressor-decompressor pairs operating in 1085 opposite directions, for the purpose of exchanging piggyback and/or 1086 interspersed feedback, SHOULD be maintained for the lifetime of the 1087 ROHC channel. Otherwise, it is RECOMMENDED that the compressor be 1088 notified if the feedback channel is no longer available: the 1089 compressor SHOULD then restart compression by creating a new context 1090 for each packet flow, and SHOULD use a CID value that was not 1091 previously associated with the profile used to compress the flow. 1093 5.2.4.1. ROHC Feedback Format 1095 ROHC defines three different categories of feedback messages: 1096 acknowledgment (ACK), negative ACK (NACK), and NACK for the entire 1097 context (STATIC-NACK). Other types of information may be defined in 1098 profile-specific feedback information. 1100 ACK: Acknowledges successful decompression of a packet. Indicates 1101 that the decompressor considers its context to be valid. 1103 NACK: Indicates that the decompressor considers some or all of the 1104 dynamic part of its context invalid. 1106 STATIC-NACK : Indicates that the decompressor considers its entire 1107 static context invalid, or that it has not been established. 1109 Feedback sent on a ROHC channel consists of one or more concatenated 1110 feedback elements, where each feedback element has the following 1111 format: 1113 0 1 2 3 4 5 6 7 1114 +---+---+---+---+---+---+---+---+ 1115 | 1 1 1 1 0 | Code | feedback type 1116 +---+---+---+---+---+---+---+---+ 1117 : Size : if Code = 0 1118 +---+---+---+---+---+---+---+---+ 1119 : Add-CID octet : if for small CIDs and (CID != 0) 1120 +---+---+---+---+---+---+---+---+ 1121 : : 1122 / large CID / 1-2 octets if for large CIDs 1123 : : 1124 +---+---+---+---+---+---+---+---+ 1125 / FEEDBACK data / variable length 1126 +---+---+---+---+---+---+---+---+ 1128 Code: 1130 0 indicates that a Size octet is present. 1132 1-7 indicates the total size of the FEEDBACK data field and the 1133 CID field (if any), in octets. 1135 Size: Indicates the total size of the FEEDBACK data field and the CID 1136 field (if any), in octets. 1138 FEEDBACK data: FEEDBACK-1 or FEEDBACK-2 (see below). 1140 CID information in a feedback element indicates the context for which 1141 feedback is sent. The LARGE_CIDS parameter that controls whether a 1142 large CID is present is taken from the channel state of the receiving 1143 compressor's channel, not from the state of the channel carrying the 1144 feedback. 1146 The large CID field, if present, is encoded according to 1147 Section 5.3.2, and it MUST NOT be encoded using more than 2 octets. 1149 The FEEDBACK data field can have either of the following two formats: 1151 FEEDBACK-1: 1153 0 1 2 3 4 5 6 7 1154 +---+---+---+---+---+---+---+---+ 1155 | profile specific information | 1 octet 1156 +---+---+---+---+---+---+---+---+ 1158 FEEDBACK-2: 1160 0 1 2 3 4 5 6 7 1161 +---+---+---+---+---+---+---+---+ 1162 |Acktype| | 1163 +---+---+ profile specific / at least 2 octets 1164 / information | 1165 +---+---+---+---+---+---+---+---+ 1167 Acktype: 0 = ACK 1168 1 = NACK 1169 2 = STATIC-NACK 1170 3 is reserved (MUST NOT be used. Otherwise unparseable.) 1172 5.2.5. ROHC Segmentation 1174 ROHC defines a simple segmentation protocol. The compressor may 1175 perform segmentation, e.g., to accommodate packets that are larger 1176 than a specific size configured for the channel. 1178 5.2.5.1. Segmentation Usage Considerations 1180 The ROHC segmentation protocol is not particularly efficient. It is 1181 not intended to replace link layer segmentation functions; these 1182 SHOULD be used whenever available and efficient for the task at hand. 1184 The ROHC segmentation protocol has been designed with an assumption 1185 of in-order delivery of packets between the compressor and the 1186 decompressor, using only a CRC for error detection, and no sequence 1187 numbers. If in-order delivery cannot be guaranteed, ROHC 1188 segmentation MUST NOT be used. 1190 The segmentation protocol also assumes that all segments of a ROHC 1191 packet corresponding to one context are received without interference 1192 from other ROHC packets over the channel, including any ROHC packet 1193 corresponding to a different context. Based on this assumption, 1194 segments do not carry CID information, and therefore cannot be 1195 associated with a specific context until all segments have been 1196 received and the whole unit has been reconstructed. 1198 5.2.5.2. Segmentation Protocol 1200 ROHC segmentation is applied to the combination of the Header and the 1201 Payload fields of the ROHC packet, as defined in Section 5.2.1. 1203 Segment format: 1205 0 1 2 3 4 5 6 7 1206 +---+---+---+---+---+---+---+---+ 1207 | 1 1 1 1 1 1 1 | F | segment type 1208 +---+---+---+---+---+---+---+---+ 1209 / Segment / variable length 1210 +---+---+---+---+---+---+---+---+ 1212 F: Final bit. If set, it indicates that this is the last segment of 1213 a reconstructed unit. 1215 Padding and/or Feedback may precede the segment type octet. There is 1216 no per-segment CID, but CID information is of course part of the 1217 reconstructed unit. The reconstructed unit MUST NOT contain padding, 1218 segments, or feedback. 1220 When a final segment is received, the decompressor reassembles the 1221 segment carried in this packet and any non-final segments that 1222 immediately preceded it into a single reconstructed unit, in the 1223 order they were received. All segments for one reconstructed unit 1224 have to be received consecutively and in the correct order by the 1225 decompressor. If a non-segment ROHC packet directly follows a non- 1226 final segment, the reassembly of the current reconstructed unit is 1227 aborted and the decompressor MUST discard the non-final segments so 1228 far received on this channel. 1230 Reconstructed unit: 1232 0 1 2 3 4 5 6 7 1233 +---+---+---+---+---+---+---+---+ 1234 / Header / 1235 +---+---+---+---+---+---+---+---+ 1236 : Payload : 1237 +---+---+---+---+---+---+---+---+ 1238 / CRC / 4 octets 1239 +---+---+---+---+---+---+---+---+ 1241 Header: See Section 5.2.1 1243 Payload: See Section 5.2.1 1245 CRC: 32-bit CRC computed using the polynomial of Section 5.3.1.4 1246 If the reconstructed unit is 4 octets or less, or if the CRC fails, 1247 or if it is larger than the channel parameter MRRU (see Section 5.1.2 1248 ), the reconstructed unit MUST be discarded by the decompressor. If 1249 the CRC succeeds, the reconstructed unit can be further processed. 1251 5.3. General Encoding Methods 1253 5.3.1. Header Compression CRCs, Coverage and Polynomials 1255 This section describes how to calculate the CRCs used by ROHC. For 1256 all CRCs, the algorithm used to calculate the CRC is the same as the 1257 one used in [RFC1662], defined in Appendix A of this document, with 1258 the polynomials specified in subsequent sections. 1260 5.3.1.1. 8-bit CRCs in IR and IR-DYN Headers 1262 The coverage for the 8-bit CRC in the IR and IR-DYN headers is 1263 profile-dependent, but it MUST cover at least the initial part of the 1264 header ending with the Profile field, including the CID or an Add-CID 1265 octet. Feedback and padding are not part of Header (Section 5.2.1) 1266 and are thus not included in the CRC calculation. As a rule of thumb 1267 for profile specifications, any other information that initializes 1268 the decompressor context SHOULD also be covered by a CRC. 1270 More specifically, the 8-bit CRC does not cover only and entirely the 1271 original uncompressed header; therefore, it does not provide the 1272 means for the decompressor to verify a decompression attempt, or the 1273 means to verify the correctness of the entire decompressor context. 1274 However, when successful, it does provide enough robustness for the 1275 decompressor to update its context with the information carried 1276 within the IR or the IR-DYN header. 1278 The CRC polynomial for the 8-bit CRC is: 1280 C(x) = 1 + x + x^2 + x^8 1282 When computing the CRC, the CRC field in the header is set to zero, 1283 and the initial content of the CRC register is set to all 1's. 1285 5.3.1.2. 3-bit CRC in Compressed Headers 1287 The 3-bit CRC in compressed headers is calculated over all octets of 1288 the entire original header, before compression, in the following 1289 manner. 1291 The initial content of the CRC register is set to all 1's. 1293 The polynomial for the 3-bit CRC is: 1295 C(x) = 1 + x + x^3 1297 The purpose of the 3-bit CRC is to provide the means for the 1298 decompressor to verify the outcome of a decompression attempt for 1299 small compressed headers, and to detect context damage based on 1300 aggregated probability over a number of decompression attempts. It 1301 is however too weak to provide enough success guarantees from the 1302 decompression of one single header. Therefore, compressed headers 1303 carrying a 3-bit CRC are normally not suitable to perform context 1304 repairs at the decompressor; hence, profiles should refrain from 1305 allowing decompression of such a header when some or the entire 1306 decompressor context is assumed invalid. 1308 5.3.1.3. 7-bit CRC in Compressed Headers 1310 The 7-bit CRC in compressed headers is calculated over all octets of 1311 the entire original header, before compression, in the following 1312 manner. 1314 The initial content of the CRC register is set to all 1's. 1316 The polynomial for the 7-bit CRC is: 1318 C(x) = 1 + x + x^2 + x^3 + x^6 + x^7 1320 The purpose of the 7-bit CRC is to provide the means for the 1321 decompressor to verify the outcome of a decompression attempt for a 1322 larger compressed header, and to provide enough protection to 1323 validate a context repair at the decompressor. The 7-bit CRC is 1324 strong enough to assume a repair to be successful from the 1325 decompression of one single header; hence, profiles may allow 1326 decompression of a header carrying a 7-bit CRC when some of the 1327 decompressor context is assumed invalid. 1329 5.3.1.4. 32-bit Segmentation CRC 1331 The 32-bit CRC is used by the segmentation scheme to verify the 1332 reconstructed unit, and it is thus calculated over the segmented 1333 unit, i.e., over the Header and the Payload fields of the ROHC 1334 packet. 1336 The initial content of the CRC register is set to all 1's. 1338 The polynomial for the 32-bit CRC is: 1340 C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 + 1341 x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32. 1343 The purpose of the 32-bit CRC is to verify the reconstructed unit. 1345 5.3.2. Self-Describing Variable-Length Values 1347 The values of many fields and compression parameters can vary widely. 1348 To optimize the transfer of such values, a variable number of octets 1349 are used to encode them. The first few bits of the first octet 1350 determine the number of octets used: 1352 First bit is 0: 1 octet. 1353 7 bits transferred. 1354 Up to 127 decimal. 1355 Encoded octets in hexadecimal: 00 to 7F 1357 First bits are 10: 2 octets. 1358 14 bits transferred. 1359 Up to 16 383 decimal. 1360 Encoded octets in hexadecimal: 80 00 to BF FF 1362 First bits are 110: 3 octets. 1363 21 bits transferred. 1364 Up to 2 097 151 decimal. 1365 Encoded octets in hexadecimal: C0 00 00 to DF FF FF 1367 First bits are 111: 4 octets. 1368 29 bits transferred. 1369 Up to 536 870 911 decimal. 1370 Encoded octets in hexadecimal: E0 00 00 00 to FF FF FF FF 1372 5.4. ROHC UNCOMPRESSED -- No Compression (Profile 0x0000) 1374 This section describes the uncompressed ROHC profile. The profile 1375 identifier for this profile is 0x0000. 1377 Profile 0x0000 provides a way to send IP packets without compressing 1378 them. This can be used for any packet for which a compression 1379 profile is not available in the set of profiles supported by the ROHC 1380 channel, or for which compression is not desirable for some reason. 1382 After initialization, the only overhead for sending packets using 1383 Profile 0x0000 is the size of the CID. When uncompressed packets are 1384 frequent, Profile 0x0000 should be associated with a CID the size of 1385 zero or one octet. Profile 0x0000 SHOULD be associated with at most 1386 one CID. 1388 5.4.1. IR Packet 1390 The initialization and refresh packet (IR packet) for Profile 0x0000 1391 has the following Header format: 1393 0 1 2 3 4 5 6 7 1394 --- --- --- --- --- --- --- --- 1395 : Add-CID octet : if for small CIDs and (CID != 0) 1396 +---+---+---+---+---+---+---+---+ 1397 | 1 1 1 1 1 1 0 |res| 1398 +---+---+---+---+---+---+---+---+ 1399 : : 1400 / 0-2 octets of CID info / 1-2 octets if for large CIDs 1401 : : 1402 +---+---+---+---+---+---+---+---+ 1403 | Profile = 0x00 | 1 octet 1404 +---+---+---+---+---+---+---+---+ 1405 | CRC | 1 octet 1406 +---+---+---+---+---+---+---+---+ 1408 res: MUST be set to zero; otherwise, the decompressor MUST discard 1409 the packet. 1411 Profile: 0x00 1413 CRC: 8-bit CRC, computed using the polynomial of Section 5.3.1.1. 1414 The CRC covers the first octet of the IR Header through the Profile 1415 octet of the IR Header, i.e., it does not cover the CRC itself. 1416 Neither does it cover any preceding Padding or Feedback, nor the 1417 Payload. 1419 For the IR packet, Payload has the following format: 1421 --- --- --- --- --- --- --- --- 1422 : : (optional) 1423 / IP packet / variable length 1424 : : 1425 --- --- --- --- --- --- --- --- 1427 IP packet: An uncompressed IP packet may be included in the IR 1428 packet. The decompressor determines if the IP packet is present by 1429 considering the length of the IR packet. 1431 5.4.2. Normal Packet 1433 A Normal packet is a normal IP packet plus CID information. For the 1434 Normal Packet, the following format corresponds to the Header and 1435 Payload (as defined in Section 5.2.1): 1437 0 1 2 3 4 5 6 7 1438 --- --- --- --- --- --- --- --- 1439 : Add-CID octet : if for small CIDs and (CID != 0) 1440 +---+---+---+---+---+---+---+---+ 1441 | first octet of IP packet | 1442 +---+---+---+---+---+---+---+---+ 1443 : : 1444 / 0-2 octets of CID info / 1-2 octets if for large CIDs 1445 : : 1446 +---+---+---+---+---+---+---+---+ 1447 | | 1448 / rest of IP packet / variable length 1449 | | 1450 +---+---+---+---+---+---+---+---+ 1452 Note that the first octet of the IP packet starts with the bit 1453 pattern 0100 (IPv4) or 0110 (IPv6). This does not conflict with any 1454 reserved packet types. 1456 When the channel uses small CIDs, and profile 0x0000 is associated 1457 with a CID > 0, an Add-CID octet precedes the IP packet. When the 1458 channel uses large CIDs, the CID is placed so that it starts at the 1459 second octet of the combined Header/Payload format above. 1461 A Normal Packet may carry Padding and/or Feedback as any other ROHC 1462 packet, preceding the combined Header/Payload. 1464 5.4.3. Context Initialization 1466 The compressor initializes the static context associated with the 1467 UNCOMPRESSED profile by sending IR packets (see Section 5.4.1). 1468 During context initialization, it is RECOMMENDED that the compressor 1469 sends IR packets until it is reasonably confident that the 1470 decompressor has successfully received at least one IR packet. This 1471 confidence can for example be based on feedback from the 1472 decompressor, or from knowledge of the characteristics of the link. 1474 The compressor SHOULD periodically transmit IR packets for a context 1475 associated with the UNCOMPRESSED profile, at least until it receives 1476 feedback from the decompressor for that context. The compressor MAY 1477 stop the periodic sending of IR packets once it has received 1478 feedback. 1480 5.4.4. Decompressor Operation 1482 When an IR packet is received, the decompressor first validates its 1483 header using the 8-bit CRC. 1485 o If the header fails validation, the decompressor MUST NOT deliver 1486 the IP packet to upper layers. 1488 o If the header is successfully validated, the decompressor 1490 1. initializes the context if it has no valid context for the 1491 given CID already associated to the specified profile, 1493 2. delivers the IP packet to upper layers if present, 1495 3. MAY send an ACK. 1497 When any other packet is received while the decompressor has no 1498 context, it is discarded without further action. 1500 When a Normal packet is received and the decompressor has a valid 1501 context, the IP packet is extracted and delivered to upper layers. 1503 5.4.5. Feedback 1505 The only kind of feedback defined by Profile 0x0000 is ACK, using the 1506 FEEDBACK-1 format of Section 5.2.4.1, where the value of the profile- 1507 specific octet in the FEEDBACK-1 is 0 (zero). The FEEDBACK-2 format 1508 is thus not defined for Profile 0x0000. 1510 6. Overview of a ROHC Profile (Informative) 1512 The ROHC protocol consists of a framework part and a profile part. 1513 The framework defines the mechanisms common to all profiles, while 1514 the profile defines the compression algorithm and profile specific 1515 packet formats. 1517 Section 5 specifies the details of the ROHC framework. This section 1518 provides an informative overview of the elements that make a profile 1519 specification. The normative specification of individual profiles is 1520 outside the scope of this document. 1522 A ROHC profile defines the elements that build up the compression 1523 protocol. A ROHC profile consists of: 1525 Packet formats: 1527 o Bits-on-the-wire 1528 The profile defines the layout of the bits for profile-specific 1529 packet types that it defines, and for the profile-specific 1530 parts of packet types common to all profiles (e.g., IR and IR- 1531 DYN). 1533 o Field encodings 1535 Bits and groups of bits from the packet format layout, referred 1536 to as Compressed fields, represent the result of an encoding 1537 method specific for that compressed field within a specific 1538 packet format. The profile defines these encoding methods. 1540 o Updating properties 1542 The profile-specific packet formats may update the state of the 1543 decompressor, and may do so in different ways. The profile 1544 defines how individual profile-specific fields, or entire 1545 profile-specific packet types, update the decompressor context. 1547 o Verification 1549 Packets that update the state of the decompressor are verified 1550 to prevent incorrect updates to the decompressor context. The 1551 profile defines the mechanisms used to verify the decompression 1552 of a packet. 1554 Context management: 1556 o Robustness logic 1558 Packets may be lost or reordered between the compressor and the 1559 decompressor. The profile defines mechanism to minimize the 1560 impacts of such events and prevent damage propagation. 1562 o Repair mechanism 1564 Despite the robustness logic, impairment events may still lead 1565 to decompression failure(s), and even to context damage at the 1566 decompressor. The profile defines context repair mechanisms, 1567 including feedback logic if used. 1569 7. Acknowledgments 1571 The authors would like to acknowledge all who have contributed to 1572 previous ROHC work, and especially to the authors of RFC 3095 1573 [RFC3095], which is the technical basis for this document. Thanks 1574 also to the various individuals who contributed to the RFC 3095 1575 corrections and clarifications document [RFC4815], from which 1576 technical contents, when applicable, have been incorporated into this 1577 document. Committed WG document reviewers were Carl Knutsson, Biplab 1578 Sarkar and Robert Stangarone, who reviewed the document during 1579 working group last-calls. Additional thanks to Bert Wijnen and Brian 1580 Carpenter for comments during IETF last-call. Also thanks to Jani 1581 Juvan for discovering the error in the feedback structure in 1582 [RFC4995] which made this document necessary. 1584 8. IANA Considerations 1586 An IANA registry for "RObust Header Compression (ROHC) Profile 1587 Identifiers" [ROHC-ids] was created by RFC 3095 [RFC3095]. The 1588 assignment policy, as outlined by RFC 3095, is the following: 1590 The ROHC profile identifier is a non-negative integer. In many 1591 negotiation protocols, it will be represented as a 16-bit value. Due 1592 to the way the profile identifier is abbreviated in ROHC packets, the 1593 8 least significant bits of the profile identifier have a special 1594 significance: Two profile identifiers with identical 8 LSBs should be 1595 assigned only if the higher-numbered one is intended to supersede the 1596 lower-numbered one. To highlight this relationship, profile 1597 identifiers should be given in hexadecimal (as in 0x1234, which would 1598 for example supersede 0x0A34). 1600 Following the policies outlined in [RFC5226], the IANA policy for 1601 assigning new values for the profile identifier shall be 1602 Specification Required: values and their meanings must be documented 1603 in an RFC or in some other permanent and readily available reference, 1604 in sufficient detail that interoperability between independent 1605 implementations is possible. In the 8 LSBs, the range 0 to 127 is 1606 reserved for IETF standard-track specifications; the range 128 to 254 1607 is available for other specifications that meet this requirement 1608 (such as Informational RFCs). The LSB value 255 is reserved for 1609 future extensibility of the present specification. 1611 The following profile identifiers have so far been allocated: 1613 Profile Identifier Usage Reference 1614 ------------------ ---------------------- --------- 1615 0x0000 ROHC uncompressed RFC XXXX [RFC-ed] 1616 0x0001 ROHC RTP RFC 3095 1617 0x0002 ROHC UDP RFC 3095 1618 0x0003 ROHC ESP RFC 3095 1619 0x0004 ROHC IP RFC 3843 1620 0x0005 ROHC LLA RFC 3242 1621 0x0105 ROHC LLA with R-mode RFC 3408 1622 0x0006 ROHC TCP RFC 4996 1623 0x0007 ROHC RTP/UDP-Lite RFC 4019 1624 0x0008 ROHC UDP-Lite RFC 4019 1625 0x0101 ROHCv2 RTP RFC 5225 1626 0x0102 ROHCv2 UDP RFC 5225 1627 0x0103 ROHCv2 ESP RFC 5225 1628 0x0104 ROHCv2 IP RFC 5225 1629 0x0107 ROHCv2 RTP/UDP-Lite RFC 5225 1630 0x0108 ROHCv2 UDP-Lite RFC 5225 1632 New profiles will need new identifiers to be assigned by the IANA, 1633 but this document does not require any additional IANA action. 1635 9. Security Considerations 1637 Because encryption eliminates the redundancy that header compression 1638 schemes try to exploit, there is some inducement to forego encryption 1639 of headers in order to enable operation over low-bandwidth links. 1641 A malfunctioning or malicious header compressor could cause the 1642 header decompressor to reconstitute packets that do not match the 1643 original packets but still have valid headers and possibly also valid 1644 transport checksums. Such corruption may be detected with end-to-end 1645 authentication and integrity mechanisms, which will not be affected 1646 by the compression. Moreover, the ROHC header compression scheme 1647 uses an internal checksum for verification of reconstructed headers, 1648 which reduces the probability of producing decompressed headers not 1649 matching the original ones without this being noticed. 1651 Denial-of-service attacks are possible if an intruder can introduce, 1652 for example, bogus IR, IR-DYN, or FEEDBACK packets onto the link and 1653 thereby cause compression efficiency to be reduced. However, an 1654 intruder having the ability to inject arbitrary packets at the link 1655 layer in this manner raises additional security issues that dwarf 1656 those related to the use of header compression. 1658 10. References 1659 10.1. Normative References 1661 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1662 Requirement Levels", BCP 14, RFC 2119, March 1997. 1664 10.2. Informative References 1666 [CRTP-eval] 1667 Degermark, M., Hannu, H., Jonsson, L., and K. Svanbro, 1668 ""Evaluation of CRTP Performance over Cellular Radio 1669 Networks", IEEE Personal Communication Magazine, Volume 7, 1670 number 4, pp. 20-25, August 2000.", 2000. 1672 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1673 August 1980. 1675 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1676 September 1981. 1678 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1679 RFC 793, September 1981. 1681 [RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed 1682 serial links", RFC 1144, February 1990. 1684 [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, 1685 July 1994. 1687 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1688 (IPv6) Specification", RFC 2460, December 1998. 1690 [RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header 1691 Compression", RFC 2507, February 1999. 1693 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 1694 Headers for Low-Speed Serial Links", RFC 2508, 1695 February 1999. 1697 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 1698 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 1699 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 1700 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 1701 Compression (ROHC): Framework and four profiles: RTP, UDP, 1702 ESP, and uncompressed", RFC 3095, July 2001. 1704 [RFC3096] Degermark, M., "Requirements for robust IP/UDP/RTP header 1705 compression", RFC 3096, July 2001. 1707 [RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP", 1708 RFC 3241, April 2002. 1710 [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and 1711 P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with 1712 High Delay, Packet Loss and Reordering", RFC 3545, 1713 July 2003. 1715 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1716 Jacobson, "RTP: A Transport Protocol for Real-Time 1717 Applications", STD 64, RFC 3550, July 2003. 1719 [RFC3759] Jonsson, L-E., "RObust Header Compression (ROHC): 1720 Terminology and Channel Mapping Examples", RFC 3759, 1721 April 2004. 1723 [RFC4224] Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust 1724 Header Compression (ROHC): ROHC over Channels That Can 1725 Reorder Packets", RFC 4224, January 2006. 1727 [RFC4815] Jonsson, L-E., Sandlund, K., Pelletier, G., and P. Kremer, 1728 "RObust Header Compression (ROHC): Corrections and 1729 Clarifications to RFC 3095", RFC 4815, February 2007. 1731 [RFC4995] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust 1732 Header Compression (ROHC) Framework", RFC 4995, July 2007. 1734 [RFC4996] Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West, 1735 "RObust Header Compression (ROHC): A Profile for TCP/IP 1736 (ROHC-TCP)", RFC 4996, July 2007. 1738 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression 1739 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and 1740 UDP-Lite", RFC 5225, April 2008. 1742 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1743 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1744 May 2008. 1746 [ROHC-ids] 1747 IANA Registry, "RObust Header Compression (ROHC) Profile 1748 Identifiers", 2001, 1749 . 1751 Appendix A. CRC Algorithm 1753 #!/usr/bin/perl -w 1755 use strict; 1756 #================================= 1757 # 1758 # ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02 1759 # 1760 # This little demo shows the four types of CRC in use in RFC 3095, 1761 # the specification for robust header compression. Type your data in 1762 # hexadecimal form and then press Control+D. 1763 # 1764 #--------------------------------- 1765 # 1766 # utility 1767 # 1768 sub dump_bytes($) { 1769 my $x = shift; 1770 my $i; 1771 for ($i = 0; $i < length($x); ) { 1772 printf("%02x ", ord(substr($x, $i, 1))); 1773 printf("\n") if (++$i % 16 == 0); 1774 } 1775 printf("\n") if ($i % 16 != 0); 1776 } 1778 #--------------------------------- 1779 # 1780 # The CRC calculation algorithm. 1781 # 1782 sub do_crc($$$) { 1783 my $nbits = shift; 1784 my $poly = shift; 1785 my $string = shift; 1787 my $crc = ($nbits == 32 ? 0xffffffff : (1 << $nbits) - 1); 1788 for (my $i = 0; $i < length($string); ++$i) { 1789 my $byte = ord(substr($string, $i, 1)); 1790 for( my $b = 0; $b < 8; $b++ ) { 1791 if (($crc & 1) ^ ($byte & 1)) { 1792 $crc >>= 1; 1793 $crc ^= $poly; 1794 } else { 1795 $crc >>= 1; 1796 } 1797 $byte >>= 1; 1798 } 1799 } 1800 printf "%2d bits, ", $nbits; 1801 printf "CRC: %02x\n", $crc; 1802 } 1803 #--------------------------------- 1804 # 1805 # Test harness 1806 # 1807 $/ = undef; 1808 $_ = <>; # read until EOF 1809 my $string = ""; # extract all that looks hex: 1810 s/([0-9a-fA-F][0-9a-fA-F])/$string .= chr(hex($1)), ""/eg; 1811 dump_bytes($string); 1813 #--------------------------------- 1814 # 1815 # 32-bit segmentation CRC 1816 # Note that the text implies this is complemented like for PPP 1817 # (this differs from 8, 7, and 3-bit CRC) 1818 # 1819 # C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 + 1820 # x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32 1821 # 1822 do_crc(32, 0xedb88320, $string); 1824 #--------------------------------- 1825 # 1826 # 8-bit IR/IR-DYN CRC 1827 # 1828 # C(x) = x^0 + x^1 + x^2 + x^8 1829 # 1830 do_crc(8, 0xe0, $string); 1832 #--------------------------------- 1833 # 1834 # 7-bit FO/SO CRC 1835 # 1836 # C(x) = x^0 + x^1 + x^2 + x^3 + x^6 + x^7 1837 # 1838 do_crc(7, 0x79, $string); 1840 #--------------------------------- 1841 # 1842 # 3-bit FO/SO CRC 1843 # 1844 # C(x) = x^0 + x^1 + x^3 1845 # 1846 do_crc(3, 0x6, $string); 1848 Authors' Addresses 1850 Kristofer Sandlund 1851 Ericsson 1852 Box 920 1853 Lulea SE-971 28 1854 Sweden 1856 Phone: +46 (0) 8 404 41 58 1857 Email: kristofer.sandlund@ericsson.com 1859 Ghyslain Pelletier 1860 Ericsson 1861 Box 920 1862 Lulea SE-971 28 1863 Sweden 1865 Phone: +46 (0) 8 404 29 43 1866 Email: ghyslain.pelletier@ericsson.com 1868 Lars-Erik Jonsson 1869 Optand 737 1870 Ostersund SE-831 92 1871 Sweden 1873 Phone: +46 76 830 03 12 1874 Email: lars-erik@lejonsson.com