idnits 2.17.1 draft-ietf-rohc-rfc3095bis-rohcv2-profiles-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 5627. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5638. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5645. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5651. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 19, 2008) is 5882 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 4995 (Obsoleted by RFC 5795) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Robust Header Compression G. Pelletier 3 Internet-Draft K. Sandlund 4 Intended status: Standards Track Ericsson 5 Expires: September 20, 2008 March 19, 2008 7 RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, 8 ESP and UDP Lite 9 draft-ietf-rohc-rfc3095bis-rohcv2-profiles-06 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 20, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document specifies ROHC (Robust Header Compression) profiles 43 that efficiently compress RTP/UDP/IP (Real-Time Transport Protocol, 44 User Datagram Protocol, Internet Protocol), RTP/UDP-Lite/IP (User 45 Datagram Protocol Lite), UDP/IP, UDP-Lite/IP, IP and ESP/IP 46 (Encapsulating Security Payload) headers. 48 This specification defines a second version of the profiles found in 49 RFC 3095, RFC 3843 and RFC 4019; it supersedes their definition, but 50 does not obsolete them. 52 The ROHCv2 profiles introduce a number of simplifications to the 53 rules and algorithms that govern the behavior of the compression 54 endpoints. It also defines robustness mechanisms that may be used by 55 a compressor implementation to increase the probability of 56 decompression success when packets can be lost and/or reordered on 57 the ROHC channel. Finally, the ROHCv2 profiles define its own 58 specific set of header formats, using the ROHC formal notation. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4. Background (Informative) . . . . . . . . . . . . . . . . . . 7 66 4.1. Classification of Header Fields . . . . . . . . . . . . . 7 67 4.2. Improvements of ROHCv2 over RFC 3095 Profiles . . . . . . 8 68 4.3. Operational Characteristics of ROHCv2 Profiles . . . . . 10 69 5. Overview of the ROHCv2 Profiles (Informative) . . . . . . . . 10 70 5.1. Compressor Concepts . . . . . . . . . . . . . . . . . . . 11 71 5.1.1. Optimistic Approach . . . . . . . . . . . . . . . . . 11 72 5.1.2. Tradeoff between Robustness to Losses and to 73 Reordering . . . . . . . . . . . . . . . . . . . . . 11 74 5.1.3. Interactions with the Decompressor Context . . . . . 13 75 5.2. Decompressor Concepts . . . . . . . . . . . . . . . . . . 14 76 5.2.1. Decompressor State Machine . . . . . . . . . . . . . 14 77 5.2.2. Decompressor Context Management . . . . . . . . . . . 17 78 5.2.3. Feedback Logic . . . . . . . . . . . . . . . . . . . 19 79 6. ROHCv2 Profiles (Normative) . . . . . . . . . . . . . . . . . 19 80 6.1. Channel Parameters, Segmentation and Reordering . . . . . 19 81 6.2. Profile Operation, Per-context . . . . . . . . . . . . . 19 82 6.3. Control Fields . . . . . . . . . . . . . . . . . . . . . 20 83 6.3.1. Master Sequence Number (MSN) . . . . . . . . . . . . 21 84 6.3.2. Reordering Ratio . . . . . . . . . . . . . . . . . . 21 85 6.3.3. IP-ID Behavior . . . . . . . . . . . . . . . . . . . 22 86 6.3.4. UDP-Lite Coverage Behavior . . . . . . . . . . . . . 22 87 6.3.5. Timestamp Stride . . . . . . . . . . . . . . . . . . 22 88 6.3.6. Time Stride . . . . . . . . . . . . . . . . . . . . . 22 89 6.3.7. CRC-3 for Control Fields . . . . . . . . . . . . . . 22 90 6.4. Reconstruction and Verification . . . . . . . . . . . . . 23 91 6.5. Compressed Header Chains . . . . . . . . . . . . . . . . 23 92 6.6. Header Formats and Encoding Methods . . . . . . . . . . . 25 93 6.6.1. baseheader_extension_headers . . . . . . . . . . . . 25 94 6.6.2. baseheader_outer_headers . . . . . . . . . . . . . . 26 95 6.6.3. inferred_udp_length . . . . . . . . . . . . . . . . . 26 96 6.6.4. inferred_ip_v4_header_checksum . . . . . . . . . . . 26 97 6.6.5. inferred_mine_header_checksum . . . . . . . . . . . . 27 98 6.6.6. inferred_ip_v4_length . . . . . . . . . . . . . . . . 28 99 6.6.7. inferred_ip_v6_length . . . . . . . . . . . . . . . . 28 100 6.6.8. Scaled RTP Timestamp Compression . . . . . . . . . . 28 101 6.6.9. timer_based_lsb . . . . . . . . . . . . . . . . . . . 30 102 6.6.10. inferred_scaled_field . . . . . . . . . . . . . . . . 31 103 6.6.11. control_crc3_encoding . . . . . . . . . . . . . . . . 32 104 6.6.12. inferred_sequential_ip_id . . . . . . . . . . . . . . 33 105 6.6.13. list_csrc(cc_value) . . . . . . . . . . . . . . . . . 33 106 6.7. Encoding Methods With External Parameters as Arguments . 37 107 6.8. Header Formats . . . . . . . . . . . . . . . . . . . . . 39 108 6.8.1. Initialization and Refresh Header Format (IR) . . . . 39 109 6.8.2. Compressed Header Formats (CO) . . . . . . . . . . . 40 110 6.9. Feedback Formats and Options . . . . . . . . . . . . . . 99 111 6.9.1. Feedback Formats . . . . . . . . . . . . . . . . . . 99 112 6.9.2. Feedback Options . . . . . . . . . . . . . . . . . . 101 113 7. Security Considerations . . . . . . . . . . . . . . . . . . . 103 114 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 104 115 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 105 116 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 106 117 10.1. Normative References . . . . . . . . . . . . . . . . . . 106 118 10.2. Informative References . . . . . . . . . . . . . . . . . 107 119 Appendix A. Detailed Classification of Header Fields . . . . . 107 120 Appendix A.1. IPv4 Header Fields . . . . . . . . . . . . . . . . 108 121 Appendix A.2. IPv6 Header Fields . . . . . . . . . . . . . . . . 110 122 Appendix A.3. UDP Header Fields . . . . . . . . . . . . . . . . 112 123 Appendix A.4. UDP-Lite Header Fields . . . . . . . . . . . . . . 112 124 Appendix A.5. RTP Header Fields . . . . . . . . . . . . . . . . 113 125 Appendix A.6. ESP Header Fields . . . . . . . . . . . . . . . . 115 126 Appendix A.7. IPv6 Extension Header Fields . . . . . . . . . . . 115 127 Appendix A.8. GRE Header Fields . . . . . . . . . . . . . . . . 116 128 Appendix A.9. MINE Header Fields . . . . . . . . . . . . . . . . 117 129 Appendix A.10. AH Header Fields . . . . . . . . . . . . . . . . . 118 130 Appendix B. Compressor Implementation Guidelines . . . . . . . 118 131 Appendix B.1. Reference Management . . . . . . . . . . . . . . . 119 132 Appendix B.2. Window-based LSB Encoding (W-LSB) . . . . . . . . 119 133 Appendix B.3. W-LSB Encoding and Timer-based Compression . . . . 119 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 120 135 Intellectual Property and Copyright Statements . . . . . . . . . 122 137 1. Introduction 139 The ROHC WG has developed a header compression framework on top of 140 which various profiles can be defined for different protocol sets or 141 compression requirements. The ROHC framework was first documented in 142 [RFC3095], together with profiles for compression of RTP/UDP/IP 143 (Real-Time Transport Protocol, User Datagram Protocol, Internet 144 Protocol), UDP/IP, IP and ESP/IP (Encapsulating Security Payload) 145 headers. Additional profiles for compression of IP headers [RFC3843] 146 and UDP-Lite (User Datagram Protocol Lite) headers [RFC4019] were 147 later specified to complete the initial set of ROHC profiles. 149 This document defines an updated version for each of the above 150 mentioned profiles, and its definition is based on the specification 151 of the ROHC framework as found in [RFC4995]. 153 Specifically, this document defines header compression schemes for: 155 o RTP/UDP/IP : profile 0x0101 156 o UDP/IP : profile 0x0102 157 o ESP/IP : profile 0x0103 158 o IP : profile 0x0104 159 o RTP/UDP-Lite/IP : profile 0x0107 160 o UDP-Lite/IP : profile 0x0108 162 ROHCv2 compresses the following type of extension headers: 164 o AH [RFC4302] 165 o GRE [RFC2784][RFC2890] 166 o MINE [RFC2004] 167 o IPv6 Destination Options header[RFC2460] 168 o IPv6 Hop-by-hop Options header[RFC2460] 169 o IPv6 Routing header [RFC2460]. 171 2. Terminology 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in RFC 2119 [RFC2119]. 177 This document is consistent with the terminology found in the ROHC 178 framework [RFC4995] and in the formal notation for ROHC [RFC4997]. 179 In addition, this document uses or defines the following terms: 181 Acknowledgment Number 182 The Acknowledgment Number identifies what packet is being 183 acknowledged in the RoHCv2 feedback element (See Section 6.9). 184 The value of this field normally corresponds to the Master 185 Sequence Number (MSN) of the header that was last successfully 186 decompressed, for the compression context (CID) for which the 187 feedback information applies. 189 Chaining of Items 191 A chain of items groups fields based on similar characteristics. 192 ROHCv2 defines chain items for static, dynamic and irregular 193 fields. Chaining is achieved by appending an item to the chain 194 for each header in its order of appearance in the uncompressed 195 packet. Chaining is useful to construct compressed headers from 196 an arbitrary number of any of the protocol headers for which a 197 ROHCv2 profile defines a compressed format. 199 CRC-3 Control Fields Validation 201 The CRC-3 control fields validation refers to the validation of 202 the control fields. This validation is performed by the 203 decompressor when it receives a CO header that contains a 3-bit 204 CRC calculated over control fields. This 3-bit CRC covers 205 controls fields carried in the CO header as well as specific 206 control fields in the context. In the formal definition of the 207 header formats, this 3-bit CRC is labeled "control_crc3" and uses 208 the "control_crc3_encoding" (See also Section 6.6.11). 210 Delta 212 The delta refers to the difference in the absolute value of a 213 field between two consecutive packets being processed by the same 214 compression endpoint. 216 Reordering Depth 218 The number of packets by which a packet is received late within 219 its sequence due to reordering between the compressor and the 220 decompressor, i.e., reordering between packets associated with the 221 same context (CID). See the definition of sequentially late 222 packet below. 224 ROHCv2 Header Types 225 ROHCv2 profiles use two different header types: the Initialization 226 and Refresh (IR) header type, and the Compressed (CO) header type. 228 Sequentially Early Packet 230 A packet that reaches the decompressor before one or several 231 packets that were delayed over the channel, where all of the said 232 packets belong to the same header-compressed flow and are 233 associated to the same compression context (CID). At the time of 234 the arrival of a sequentially early packet, the packet(s) delayed 235 on the link cannot be differentiated from lost packet(s). 237 Sequentially Late Packet 239 A packet is late within its sequence if it reaches the 240 decompressor after one or several other packets belonging to the 241 same CID have been received, although the sequentially late packet 242 was sent from the compressor before the other packet(s). How the 243 decompressor detects a sequentially late packet is outside the 244 scope of this specification, but it can for example use the MSN 245 for this purpose. 247 Timestamp Stride (ts_stride) 249 The timestamp stride (ts_stride) is the expected increase in the 250 timestamp value between two RTP packets with consecutive sequence 251 numbers. For example, for a media encoding with a sample rate of 252 8 kHz producing one frame every 20ms, the RTP timestamp will 253 typically increase by n * 160 (= 8000 * 0.02), for some integer n. 255 Time Stride (time_stride) 257 The time stride (time_stride) is the time interval equivalent to 258 one ts_stride, e.g., 20 ms in the example for the RTP timestamp 259 increment above. 261 3. Acronyms 263 This section lists most acronyms used for reference, in addition to 264 those defined in [RFC4995]. 266 AH Authentication Header. 267 ESP Encapsulating Security Payload. 268 GRE Generic Routing Encapsulation. 269 FC Full Context state (decompressor). 270 IP Internet Protocol. 271 LSB Least Significant Bits. 272 MINE Minimal Encapsulation in IP. 273 MSB Most Significant Bits. 274 MSN Master Sequence Number. 275 NC No Context state (decompressor). 276 OA Optimistic Approach. 277 RC Repair Context state (decompressor). 278 ROHC Header compression framework (RFC 4995). 279 ROHCv2 Set of header compression profiles defined in this document. 280 RTP Real-time Transport Protocol. 281 SSRC Synchronization source. Field in RTP header. 282 CSRC Contributing source. The RTP header contains an optional list 283 of contributing sources. 284 TC Traffic Class. Field in the IPv6 header. See also TOS. 285 TOS Type Of Service. Field in the IPv4 header. See also TC. 286 TS RTP Timestamp. 287 TTL Time to Live. Field in the IPv4 header. 288 UDP User Datagram Protocol. 289 UDP-Lite User Datagram Protocol Lite. 291 4. Background (Informative) 293 This section provides background information on the compression 294 profiles defined in this document. The fundamentals of general 295 header compression and of the ROHC framework may be found in section 296 3 and 4 of [RFC4995], respectively. The fundamentals of the formal 297 notation for ROHC are defined in [RFC4997]. [RFC4224] describes the 298 impacts of out-of-order delivery on profiles based on [RFC3095]. 300 4.1. Classification of Header Fields 302 Section 3.1 of [RFC4995] explains that header compression is possible 303 due to the fact that there is much redundancy between field values 304 within the headers of a packet, especially between the headers of 305 consecutive packets. 307 Appendix A lists and classifies in detail all the header fields 308 relevant to this document. The appendix concludes with 309 recommendations on how the various fields should be handled by header 310 compression algorithms. 312 The main conclusion is that most of the header fields can easily be 313 compressed away since they never or seldom change. A small number of 314 fields however need more sophisticated mechanisms. 316 These fields are: 318 - IPv4 Identification (16 bits) - IP-ID 319 - ESP Sequence Number (32 bits) - ESP SN 320 - UDP Checksum (16 bits) - Checksum 321 - UDP-Lite Checksum (16 bits) - Checksum 322 - UDP-Lite Checksum Coverage (16 bits) - CCov 323 - RTP Marker ( 1 bit ) - M-bit 324 - RTP Sequence Number (16 bits) - RTP SN 325 - RTP Timestamp (32 bits) - TS 327 In particular, for RTP, the analysis in Appendix A reveals that the 328 values of the RTP Timestamp (TS) field usually have a strong 329 correlation to the RTP Sequence Number (SN), which increments by one 330 for each packet emitted by an RTP source. The RTP M-bit is expected 331 to have the same value most of the time, but it needs to be 332 communicated explicitly on occasion. 334 For UDP, the Checksum field cannot be inferred or recalculated at the 335 receiving end without violating its end-to-end properties, and is 336 thus sent as-is when enabled (mandatory with IPv6). The same applies 337 to the UDP-Lite Checksum (mandatory with both IPv4 and IPv6), while 338 the UDP-Lite Checksum Coverage may in some cases be compressible. 340 For IPv4, a similar correlation as the one of the RTP TS to the RTP 341 SN is often observed between the Identifier field (IP-ID) and the 342 master sequence number used for compression (e.g., the RTP SN when 343 compressing RTP headers). 345 4.2. Improvements of ROHCv2 over RFC 3095 Profiles 347 The ROHCv2 profiles can achieve compression efficiency and robustness 348 that are both at least equivalent to RFC 3095 profiles [RFC3095], 349 when used under the same operating conditions. In particular, the 350 size and bit layout of the smallest compressed header (i.e., PT-0 351 format U/O-0 in RFC 3095, and pt_0_crc3 in ROHCv2) are identical. 353 There are a number of differences and improvements between profiles 354 defined in this document and their earlier version defined in RFC 355 3095. This section provides an overview of some of the most 356 significant improvements: 358 Tolerance to reordering 359 Profiles defined in RFC 3095 require that the channel between 360 compressor and decompressor provide in-order delivery between 361 compression endpoints. ROHCv2 profiles, however, can handle 362 robustly and efficiently a limited amount of reordering after the 363 compression point as part of the compression algorithm itself. In 364 addition, this improved support for reordering makes it possible 365 for ROHCv2 profiles to handle prelink reordering more efficiently. 367 Operational logic 369 Profiles in RFC 3095 define multiple operational modes, each with 370 different updating logic and compressed header formats. ROHCv2 371 profiles operate in unidirectional operation until feedback is 372 first received for a context (CID), at which point bidirectional 373 operation is used; the formats are independent of what operational 374 logic is used. 376 IP extension header 378 Profiles in RFC 3095 compress IP Extension headers using list 379 compression. ROHCv2 profiles instead treat extension headers in 380 the same manner as other protocol headers, i.e., using the 381 chaining mechanism; it thus assumes that extension headers are not 382 added or removed during the lifetime of a context (CID), otherwise 383 compression has to be restarted for this flow. 385 IP encapsulation 387 Profiles in RFC 3095 can compress at most two levels of IP 388 headers. ROHCv2 profiles can compress an arbitrary number of IP 389 headers. 391 List compression 393 ROHCv2 profiles do not support reference-based list compression. 395 Robustness and repairs 397 ROHCv2 profiles do not define a format for the IR-DYN packet; 398 instead, each profile defines a compressed header that can be used 399 to perform a more robust context repair using a 7-bit CRC 400 verification. This also implies that only the IR header can 401 change the association between a CID and the profile it uses. 403 Feedback 404 ROHCv2 profiles mandate a CRC in the format of the FEEDBACK-2, 405 while this is optional in RFC 3095. A different set of feedback 406 options is also used in ROHCv2 compared to RFC 3095. 408 4.3. Operational Characteristics of ROHCv2 Profiles 410 Robust header compression can be used over different link 411 technologies. Section 4.4 of [RFC4995] lists the operational 412 characteristics of the ROHC channel. The ROHCv2 profiles address a 413 wide range of applications, and this section summarizes some of the 414 operational characteristics that are specific to these profiles. 416 Packet length 418 ROHCv2 profiles assume that the lower layer indicates the length 419 of a compressed packet. ROHCv2 compressed headers do not contain 420 length information for the payload. 422 Out-of-order delivery between compression endpoints 424 The definition of the ROHCv2 profiles places no strict requirement 425 on the delivery sequence between the compression endpoints, i.e., 426 packets may be received in a different order than the compressor 427 has sent them and still have a fair probability to be successfully 428 decompressed. 430 However, frequent out-of-order delivery and/or significant 431 reordering depth will negatively impact the compression 432 efficiency. More specifically, if the compressor can operate 433 using a proper estimate of the reordering characteristics of the 434 path between the compression endpoints, larger headers can be sent 435 more often to increase the robustness against decompression 436 failures due to out-of-order delivery. Otherwise, the compression 437 efficiency will be impaired from an increase in the frequency of 438 decompression failures and recovery attempts. 440 5. Overview of the ROHCv2 Profiles (Informative) 442 This section provides an overview of concepts that are important and 443 useful to the ROHCv2 profiles. These concepts may be used as 444 guidelines for implementations but they are not part of the normative 445 definition of the profiles, as these concepts relate to the 446 compression efficiency of the protocol without impacting the 447 interoperability characteristics of an implementation. 449 5.1. Compressor Concepts 451 Header compression can be conceptually characterized as the 452 interaction of a compressor with a decompressor state machine, one 453 per context. The responsibility of the compressor is to convey the 454 information needed to successfully decompress a packet, based on a 455 certain confidence regarding the state of the decompressor context. 457 This confidence is obtained from the frequency and the type of 458 information the compressor sends when updating the decompressor 459 context, from the optimistic approach (Section 5.1.1) and optionally 460 from feedback messages (See Section 6.9) received from the 461 decompressor. 463 5.1.1. Optimistic Approach 465 A compressor always uses the optimistic approach when it performs 466 context updates. The compressor normally repeats the same type of 467 update until it is fairly confident that the decompressor has 468 successfully received the information. If the decompressor 469 successfully receives any of the headers containing this update, 470 state will be available for the decompressor to process smaller 471 compressed headers. 473 If field X in the uncompressed header changes value, the compressor 474 uses a header type that contains an encoding of field X until it has 475 gained confidence that the decompressor has received at least one 476 packet containing the new value for X. The compressor normally 477 selects a compressed format with the smallest header that can convey 478 the changes needed to achieve confidence. 480 The number of repetitions that is needed to obtain this confidence is 481 normally related to the packet loss and out-of-order delivery 482 characteristics of the link where header compression is used; it is 483 thus not defined in this document and is left open to 484 implementations. 486 5.1.2. Tradeoff between Robustness to Losses and to Reordering 488 The ability of a header compression algorithm to handle sequentially 489 late packets is mainly limited by two factors: the interpretation 490 interval offset of the sliding window used for lsb encoded fields 491 [RFC4997], and the optimistic approach (See Section 5.1.1) for seldom 492 changing fields. 494 lsb encoded fields: 496 The interpretation interval offset specifies an upper limit for 497 the maximum reordering depth, by which is it possible for the 498 decompressor to recover the original value of a dynamically 499 changing (i.e., sequentially incrementing) field that is encoded 500 using a window-based lsb encoding. Its value is typically bound 501 to the number of lsb compressed bits in the compressed header 502 format, and thus grows with the number of bits transmitted. 503 However, the offset and the lsb encoding only provide robustness 504 for the field that it compresses, and (implicitly) for other 505 sequentially changing fields that are derived from that field. 507 This is shown in the figure below: 509 <--- interpretation interval (size is 2^k) ----> 510 |------------------+---------------------------| 511 v_ref-p v_ref v_ref + (2^k-1) - p 512 Lower Upper 513 Bound Bound 514 <--- reordering --> <--------- losses ---------> 516 where p is the maximum negative delta, corresponding to the 517 maximum reordering depth for which the lsb encoding can recover 518 the original value of the field; 520 where (2^k-1) - p is the maximum positive delta, corresponding 521 to the maximum number of consecutive losses for which the lsb 522 encoding can recover the original value of the field; 524 where v_ref is the reference value, as defined in the lsb 525 encoding method in [RFC4997]. 527 There is thus a tradeoff between the robustness against reordering 528 and the robustness against packet losses, with respect to the 529 number of MSN bits needed and the distribution of the 530 interpretation interval between negative and positive deltas in 531 the MSN. 533 Seldom changing fields 535 The optimistic approach (Section 5.1.1) provides the upper limit 536 for the maximum reordering depth for seldom changing fields. 538 There is thus a tradeoff between compression efficiency and 539 robustness. When only information on the MSN needs to be conveyed to 540 the decompressor, the tradeoff relates to the number of compressed 541 MSN bits in the compressed header format. Otherwise, the tradeoff 542 relates to the implementation of the optimistic approach. 544 In particular, compressor implementations should adjust their 545 optimistic approach strategy to match both packet loss and reordering 546 characteristics of the link over which header compression is applied. 547 For example, the number of repetitions for each update of a non-lsb 548 encoded field can be increased. The compressor can ensure that each 549 update is repeated until it is reasonably confident that at least one 550 packet containing the change has reached the decompressor before the 551 first packet sent after this sequence. 553 5.1.3. Interactions with the Decompressor Context 555 The compressor normally starts compression with the initial 556 assumption that the decompressor has no useful information to process 557 the new flow, and sends Initialization and Refresh (IR) packets. 559 Initially, when sending the first IR packet for a compressed flow, 560 the compressor does not expect to receive feedback for that flow, 561 until such feedback is first received. At this point, the compressor 562 may then assume that the decompressor will continue to send feedback 563 in order to repair its context when necessary. The former is 564 referred to as unidirectional operation, while the latter is called 565 bidirectional operation. 567 The compressor can then adjust the compression level (i.e., what 568 header format it selects) based on its confidence that the 569 decompressor has the necessary information to successfully process 570 the compressed headers that it selects. 572 In other words, the responsibilities of the compressor are to ensure 573 that the decompressor operates with state information that is 574 sufficient to successfully decompress the type of compressed 575 header(s) it receives, and to allow the decompressor to successfully 576 recover that state information as soon as possible otherwise. The 577 compressor therefore selects the type of compressed header based on 578 the following factors: 580 o the outcome of the encoding method applied to each field; 581 o the optimistic approach, with respect to the characteristics of 582 the channel; 583 o the type of operation (unidirectional or bidirectional), and if in 584 bidirectional operation, feedback received from the decompressor 585 (ACKs, NACKs, STATIC-NACK, and options). 587 Encoding methods normally use previous value(s) from a history of 588 packets whose headers it has previously compressed. The optimistic 589 approach is meant to ensure that at least one compressed header 590 containing the information to update the state for a field is 591 received. Finally, feedback indicates what actions the decompressor 592 has taken with respect to its assumptions regarding the validity of 593 its context (Section 5.2.2); it indicates what type of compressed 594 header the decompressor can or cannot decompress. 596 The decompressor has the means to detect decompression failures for 597 any compressed (CO) header format, using the CRC verification. 598 Depending on the frequency and/or on the type of the failure, it 599 might send a negative acknowledgement (NACK) or an explicit request 600 for a complete context update (STATIC-NACK). However, the 601 decompressor does not have the means to identify the cause of the 602 failure, and in particular decompression of what field(s) is 603 responsible for the failure. The compressor is thus always 604 responsible for determining what is the most suitable response to a 605 negative acknowledgement, using the confidence it has in the state of 606 the decompressor context, when selecting the type of compressed 607 header it will use when compressing a header. 609 5.2. Decompressor Concepts 611 The decompressor normally uses the last received and successfully 612 validated (IR packets) or verified (CO packets) header as the 613 reference for future decompression. 615 The decompressor is responsible for verifying the outcome of every 616 decompression attempt, to update its context when successful and 617 finally to request context repairs by making coherent usage of 618 feedback, once it has started using feedback. 620 Specifically, the outcome of every decompression attempt is verified 621 using the CRC present in the compressed header; the decompressor 622 updates the context information when this outcome is successfully 623 verified; finally if the decompressor uses feedback once for a 624 compressed flow then it will continue to do so for as long as the 625 corresponding context is associated with the same profile. 627 5.2.1. Decompressor State Machine 629 The decompressor operation may be represented as a state machine 630 defining three states: No Context (NC), Repair Context (RC) and Full 631 Context (FC). 633 The decompressor starts without a valid context, the NC state. Upon 634 receiving an IR packet, the decompressor validates the integrity of 635 its header using the CRC-8 validation. If the IR header is 636 successfully validated, the decompressor updates the context and uses 637 this header as the reference header, and moves to the FC state. The 638 decompressor state machine normally does not leave the FC state once 639 it has entered this state; only repeated decompression failures will 640 force the decompressor to transit downwards to a lower state. When 641 context damage is detected, the decompressor moves to the repair 642 context (RC) state, where it stays until it successfully verifies a 643 decompression attempt for a compressed header with a 7-bit CRC or 644 until it successfully validates an IR header. When static context 645 damage is detected, the decompressor moves back to the NC state. 647 Below is the state machine for the decompressor. Details of the 648 transitions between states and decompression logic are given in the 649 sub-sections following the figure. 651 CRC-8(IR) Validation 652 +----->----->----->----->----->----->----->----->----->----->----+ 653 | CRC-8(IR) | 654 | !CRC-8(IR) or CRC-7(CO) or or CRC-7(CO) | 655 | PT not allowed CRC-8(IR) or CRC-3(CO) | 656 | +--->---+ +--->----->----->----->---+ +--->---->---+ | 657 | | | | | | | | 658 | | v | v | v v 659 +-----------------+ +----------------------+ +--------------------+ 660 | No Context (NC) | | Repair Context (RC) | | Full Context (FC) | 661 +-----------------+ +----------------------+ +--------------------+ 662 ^ ^ Static Context | ^ !CRC-7(CO) or | ^ Context Damage | | 663 | | Damage Detected | | PT not allowed | | Detected | | 664 | +--<-----<-----<--+ +----<------<----+ +--<-----<-----<--+ | 665 | | 666 | Static Context Damage Detected | 667 +--<-----<-----<-----<-----<-----<-----<-----<-----<---------+ 669 where: 671 CRC-8(IR) : Successful CRC-8 validation for the IR header. 672 !CRC-8(IR) : Unsuccessful CRC-8 validation for the IR header. 673 CRC-7(CO) and/or 674 CRC-3(CO) : Successful CRC verification for the decompression 675 of a CO header, based on the number of CRC bits 676 carried in the CO header. 677 !CRC-7(CO) : Failure to CRC verify the decompression of a CO 678 header carrying a 7-bit CRC. 679 PT not allowed : The decompressor has received a packet type (PT) 680 for which the decompressor's current context does 681 not provide enough valid state information to 682 decompress the packet. 684 Static Context Damage Detected: See definition in Section 5.2.2. 685 Context Damage Detected: See definition in Section 5.2.2. 687 5.2.1.1. No Context (NC) State 689 Initially, while working in the No Context (NC) state, the 690 decompressor has not yet successfully validated an IR header. 692 Attempting decompression: 694 In the NC state, only packets carrying sufficient information on 695 the static fields (i.e., IR packets) can be decompressed. 697 Upward transition: 699 The decompressor can move to the Full Context (FC) state when the 700 CRC validation of an 8-bit CRC in an IR header is successful. 702 Feedback logic: 704 In the NC state, the decompressor should send a STATIC-NACK if a 705 packet of a type other than IR is received, or if an IR header has 706 failed the CRC-8 validation, subject to the feedback rate 707 limitation as described in Section 5.2.3. 709 5.2.1.2. Repair Context (RC) State 711 In the Repair Context (RC) state, the decompressor has successfully 712 decompressed packets for this context, but does not have confidence 713 that the entire context is valid. 715 Attempting decompression: 717 In the RC state, only headers covered by an 8-bit CRC (i.e. IR) 718 or CO headers carrying a 7-bit CRC can be decompressed. 720 Upward transition: 722 The decompressor can move to the Full Context (FC) state when the 723 CRC verification succeeds for a CO header carrying a 7-bit CRC or 724 validation of an 8-bit CRC in an IR header. 726 Downward transition: 728 The decompressor moves back to the NC state if it assumes static 729 context damage. 731 Feedback logic: 733 In the RC state, the decompressor should send a STATIC-NACK when 734 CRC-8 validation of an IR header fails, or when a CO header 735 carrying a 7-bit CRC fails and static context damage is assumed, 736 subject to the feedback rate limitation as described in 737 Section 5.2.3. If any other packet type is received, the 738 decompressor should treat it as a CRC verification failure to 739 determine if NACK is to be sent. 741 5.2.1.3. Full Context (FC) State 743 In the Full Context (FC) state, the decompressor assumes that its 744 entire context is valid. 746 Attempting decompression: 748 In the FC state, decompression can be attempted regardless of the 749 type of packet received. 751 Downward transition: 753 The decompressor moves back to the RC state if it assumes context 754 damage. If the decompressor assumes static context damage, it 755 moves directly to the NC state. 757 Feedback logic: 759 In the FC state, the decompressor should send a NACK when CRC-8 760 validation or CRC verification of any header type fails and if 761 context damage is assumed, or it should send a STATIC-NACK if 762 static context damage is assumed; this is subject to the feedback 763 rate limitation described in Section 5.2.3. 765 5.2.2. Decompressor Context Management 767 All header formats carry a CRC and are context updating. A packet 768 for which the CRC succeeds updates the reference values of all header 769 fields, either explicitly (from the information about a field carried 770 within the compressed header) or implicitly (fields inferred from 771 other fields). 773 The decompressor may assume that some or the entire context is 774 invalid, when it fails to validate or to verify one or more headers 775 using the CRC. Because the decompressor cannot know the exact 776 reason(s) for a CRC failure or what field caused it, the validity of 777 the context hence does not refer to what specific part(s) of the 778 context is deemed valid or not. 780 Validity of the context rather relates to the detection of a problem 781 with the context. The decompressor first assumes that the type of 782 information that most likely caused the failure(s) is the state that 783 normally changes for each packet, i.e., context damage of the dynamic 784 part of the context. Upon repeated decompression failures and 785 unsuccessful repairs, the decompressor then assumes that the entire 786 context, including the static part, needs to be repaired, i.e., 787 static context damage. Failure to validate the 3-bit CRC that 788 protects control fields should be treated as a decompression failure 789 when the decompressor asserts the validity of its context. 791 Context Damage Detection 793 The assumption of context damage means that the decompressor will 794 not attempt decompression of a CO header that carries only a 3-bit 795 CRC, and will only attempt decompression of IR headers, or CO 796 headers protected by a CRC-7. 798 Static Context Damage Detection 800 The assumption of static context damage means that the 801 decompressor refrains from attempting decompression of any type of 802 header other than the IR header. 804 How these assumptions are made, i.e., how context damage is detected, 805 is open to implementations. It can be based on the residual error 806 rate, where a low error rate makes the decompressor assume damage 807 more often than on a high rate link. 809 The decompressor implements these assumptions by selecting the type 810 of compressed header for which it will attempt decompression. In 811 other words, validity of the context refers to the ability of a 812 decompressor to attempt or not decompression of specific packet 813 types. 815 When ROHCv2 profiles are used over a channel that cannot guarantee 816 in-order delivery, the decompressor may refrain from updating its 817 context with the content of a sequentially late packet that is 818 successfully decompressed. This is to avoid updating the context 819 with information that is older than what the decompressor already has 820 in its context. 822 5.2.3. Feedback Logic 824 ROHCv2 profiles may be used in environments with or without feedback 825 capabilities from decompressor to compressor. ROHCv2 however assumes 826 that if a ROHC feedback channel is available and if this channel is 827 used at least once by the decompressor for a specific context, this 828 channel will be used during the entire compression operation for that 829 context (i.e., bidirectional operation). 831 The ROHC framework defines 3 types of feedback messages: ACKs, NACKs 832 and STATIC-NACKs. The semantics of each message if defined in 833 section 5.2.4.1. of [RFC4995]. What feedback to send is coupled to 834 the context management of the decompressor, i.e. to the 835 implementation of the context damage detection algorithms as 836 described in Section 5.2.2. 838 The decompressor should send a NACK when it assumes context damage, 839 and it should send a STATIC-NACK when it assumes static context 840 damage. The decompressor is not strictly expected to send ACK 841 feedback upon successful decompression, other than for the purpose of 842 improving compression efficiency. 844 When ROHCv2 profiles are used over a channel that cannot guarantee 845 in-order delivery, the decompressor may refrain from sending ACK 846 feedback for a sequentially late packet that is successfully 847 decompressed. 849 The decompressor should limit the rate at which it sends feedback, 850 for both ACKs and STATIC-NACK/NACKs, and should avoid sending 851 unnecessary duplicates of the same type of feedback message that may 852 be associated to the same event. 854 6. ROHCv2 Profiles (Normative) 856 6.1. Channel Parameters, Segmentation and Reordering 858 The compressor MUST NOT use ROHC segmentation (see [RFC4995] section 859 5.2.5), i.e., MRRU MUST be set to 0, if the configuration of the ROHC 860 channel contains at least one ROHCv2 profile in the list of supported 861 profiles (i.e., the PROFILES parameter) and if the channel cannot 862 guarantee in-order delivery of packets between compression endpoints. 864 6.2. Profile Operation, Per-context 866 ROHCv2 profiles operate differently, per context, depending on how 867 the decompressor makes use of the feedback channel, if any. Once the 868 decompressor uses the feedback channel for a context, it establishes 869 the feedback channel for that CID. 871 The compressor always starts with the assumption that the 872 decompressor will not send feedback when it initializes a new context 873 (see also the definition of a new context in section 5.1.1. of 874 [RFC4995]), i.e., there is no established feedback channel for the 875 new context. At this point, despite the use of the optimistic 876 approach, decompression failure is still possible because the 877 decompressor may not have received sufficient information to 878 correctly decompress the packets; therefore, until the decompressor 879 has established a feedback channel, the compressor SHOULD 880 periodically send IR packets. The periodicity can be based on 881 timeouts, on the number of compressed packets sent for the flow, or 882 any other strategy the implementer chooses. 884 The reception of either positive feedback (ACKs) or negative feedback 885 (NACKs or STATIC-NACKs) from the decompressor establishes the 886 feedback channel for the context (CID) for which the feedback was 887 received. Once there is an established feedback channel for a 888 specific context, the compressor can make use of this feedback to 889 estimate the current state of the decompressor. This helps to 890 increase the compression efficiency by providing the information 891 needed for the compressor to achieve the necessary confidence level. 892 When the feedback channel is established, it becomes superfluous for 893 the compressor to send periodic refreshes, and instead it can rely 894 entirely on the optimistic approach and feedback from the 895 decompressor. 897 The decompressor MAY send positive feedback (ACKs) to initially 898 establish the feedback channel for a particular flow. Either 899 positive feedback (ACKs) or negative feedback (NACKs) establishes 900 this channel. Once it has established a feedback channel for a CID, 901 the decompressor is REQUIRED to continue sending feedback for the 902 lifetime of the context (i.e., until it receives an IR packet that 903 associates the CID to a different profile), to send error recovery 904 requests and (optionally) acknowledgments of significant context 905 updates. 907 Compression without an established feedback channel will be less 908 efficient, because of the periodic refreshes and from the lack of 909 feedback to trigger error recovery; there will also be a slightly 910 higher probability of loss propagation compared to the case where the 911 decompressor uses feedback. 913 6.3. Control Fields 915 ROHCv2 defines a number of control fields that are used by the 916 decompressor in its interpretation of the header formats received 917 from the compressor. The control fields listed in the following 918 subsections are defined using the formal notation [RFC4997] in 919 Section 6.8.2.4. 921 6.3.1. Master Sequence Number (MSN) 923 The Master Sequence Number (MSN) field is either taken from a field 924 that already exists in one of the headers of the protocol that the 925 profile compresses (e.g., RTP SN), or alternatively it is created at 926 the compressor. There is one MSN space per context (CID). 928 The MSN field has the following two functions: 930 o Differentiating between reference headers when receiving feedback 931 data; 932 o Inferring the value of incrementing fields (e.g., IPv4 933 Identifier). 935 There is one MSN field in every ROHCv2 header, i.e., the MSN is 936 always present in each header type sent by the compressor. The MSN 937 is sent in full in IR headers, while it can be lsb encoded within CO 938 header formats. The decompressor always includes LSBs of the MSN in 939 the Acknowledgment Number field in feedback (see Section 6.9). The 940 compressor can later use this field to infer what packet the 941 decompressor is acknowledging. 943 For profiles for which the MSN is created by the compressor (i.e. 944 0x0102, 0x0104 and 0x0108), the following applies: 946 o The compressor only initializes the MSN for a context when that 947 context is first created or when the profile associated with a 948 context changes; 949 o When the MSN is initialized, it is initialized to a random value; 950 o The value of the MSN SHOULD be incremented by one for each packet 951 that the compressor sends for a specific CID. 953 6.3.2. Reordering Ratio 955 The control field reorder_ratio specifies how much reordering is 956 handled by the lsb encoding of the MSN. This is useful when header 957 compression is performed over links with varying reordering 958 characteristics. The reorder_ratio control field provides the means 959 for the compressor to adjust the robustness characteristics of the 960 lsb encoding method with respect to reordering and consecutive 961 losses, as described in Section 5.1.2. 963 6.3.3. IP-ID Behavior 965 The IP-ID field of the IPv4 header can have different change 966 patterns: sequential in network byte order, sequential byte-swapped, 967 random or constant (a constant value of zero, although not conformant 968 with [RFC0791], has been observed in practice). There is one IP-ID 969 behavior control field per IP header. The control field for the 970 IP-ID behavior of the innermost IP header determines which set of 971 header formats is used. The IP-ID behavior control field is also 972 used to determine the contents of the irregular chain item, for each 973 IP header. 975 ROHCv2 profiles MUST NOT assign a sequential behavior (network byte 976 order or byte-swapped) to any IP-ID but the one in the innermost IP 977 header, when compressing more than one level of IP headers. This is 978 because only the IP-ID of the innermost IP header is likely to have a 979 sufficiently close correlation with the MSN to compress it as a 980 sequentially changing field. Therefore, a compressor MUST assign 981 either the constant zero IP-ID or the random IP-ID behavior to 982 tunneling headers. 984 6.3.4. UDP-Lite Coverage Behavior 986 The control field coverage_behavior specifies how the checksum 987 coverage field of the UDP-Lite header is compressed with RoHCv2. It 988 can indicate one of the following encoding methods: irregular, static 989 or inferred encoding. 991 6.3.5. Timestamp Stride 993 The ts_stride control field is used in scaled RTP timestamp encoding 994 (see Section 6.6.8). It defines the expected increase in the RTP 995 timestamp between consecutive RTP sequence numbers. 997 6.3.6. Time Stride 999 The time_stride control field is used in timer-based compression 1000 encoding (see Section 6.6.9). When timer-based compression is used, 1001 time_stride should be set to the expected difference in arrival time 1002 between consecutive RTP packets. 1004 6.3.7. CRC-3 for Control Fields 1006 ROHCv2 profiles define a CRC-3 calculated over a number of control 1007 fields. This 3-bit CRC protecting the control fields is present in 1008 the header format for the co_common and co_repair header types. 1010 The decompressor MUST always validate the integrity of the control 1011 fields covered by this 3-bit CRC when processing a co_common or a 1012 co_repair compressed header. 1014 Failure to validate the control fields using this CRC should be 1015 considered as a decompression failure by the decompressor, in the 1016 algorithm that assesses the validity of the context. However, if the 1017 decompression attempt can be verified using either the CRC-3 or the 1018 CRC-7 calculated over the uncompressed header, the decompressor MAY 1019 still forward the decompressed header to upper layers. This is 1020 because the protected control fields are not always used to 1021 decompress the header (i.e., co_common or co_repair) that updates 1022 their respective value. 1024 The CRC polynomial and coverage of this CRC-3 is defined in 1025 Section 6.6.11. 1027 6.4. Reconstruction and Verification 1029 Validation of the IR header (8-bit CRC) 1031 The decompressor MUST always validate the integrity of the IR 1032 header using the 8-bit CRC carried within the IR header. When the 1033 header is validated, the decompressor updates the context with the 1034 information in the IR header. Otherwise, if the IR cannot be 1035 validated, the context MUST NOT be updated and the IR header MUST 1036 NOT be delivered to upper layers. 1038 Verification of CO headers (3-bit CRC or 7-bit CRC) 1040 The decompressor MUST always verify the decompression of a CO 1041 header using the CRC carried within the compressed header. When 1042 the decompression is verified and successful, the decompressor 1043 updates the context with the information received in the CO 1044 header; otherwise if the reconstructed header fails the CRC 1045 verification, these updates MUST NOT be performed. 1047 A packet for which the decompression attempt cannot be verified 1048 using the CRC MUST NOT be delivered to upper layers. 1050 Decompressor implementations may attempt corrective or repair 1051 measures on CO headers prior to performing the above actions, and 1052 the result of any decompression attempt MUST be verified using the 1053 CRC. 1055 6.5. Compressed Header Chains 1057 Some header types use one or more chains containing sub-header 1058 information. The function of a chain is to group fields based on 1059 similar characteristics, such as static, dynamic or irregular fields. 1061 Chaining is done by appending an item for each header to the chain in 1062 their order of appearance in the uncompressed packet, starting from 1063 the fields in the outermost header. 1065 In the text below, the term is used to identify 1066 formal notation names corresponding to different protocol headers. 1067 The mapping between these is defined in the following table: 1068 +----------------------------------+---------------+ 1069 | Protocol | protocol_name | 1070 +----------------------------------+---------------+ 1071 | IPv4 RFC 0791 | ipv4 | 1072 | IPv6 RFC 2460 | ipv6 | 1073 | UDP RFC 0768 | udp | 1074 | RTP RFC 3550 | rtp | 1075 | ESP RFC 4303 | esp | 1076 | UDP-Lite RFC 3828 | udp_lite | 1077 | AH RFC 4302 | ah | 1078 | GRE RFC 2784, RFC 2890 | gre | 1079 | MINE RFC 2004 | mine | 1080 | IPv6 Destination Option RFC 2460 | dest_opt | 1081 | IPv6 Hop-by-hop Options RFC 2460 | hop_opt | 1082 | IPv6 Routing Header RFC 2460 | rout_opt | 1083 +----------------------------------+---------------+ 1085 Static chain: 1087 The static chain consists of one item for each header of the chain 1088 of protocol headers that is compressed, starting from the 1089 outermost IP header. In the formal description of the header 1090 formats, this static chain item for each header type is labeled 1091 _static. The static chain is only used in the IR 1092 header format. 1094 Dynamic chain: 1096 The dynamic chain consists of one item for each header of the 1097 chain of protocol headers that is compressed, starting from the 1098 outermost IP header. In the formal description of the header 1099 formats, the dynamic chain item for each header type is labeled 1100 _dynamic. The dynamic chain is only used in the IR 1101 and co_repair header formats. 1103 Irregular chain: 1105 The structure of the irregular chain is analogous to the structure 1106 of the static chain. For each compressed header that uses the 1107 general format of Section 6.8, the irregular chain is appended at 1108 a specific location in the general format of the compressed 1109 headers. In the formal description of the header formats, the 1110 irregular chain item for each header type is a format whose name 1111 is suffixed by "_irregular". The irregular chain is used in all 1112 CO headers, except for the co_repair format. 1114 The format of the irregular chain for the innermost IP header 1115 differs from the format used for the outer IP headers, because 1116 this header is part of the compressed base header. In the 1117 definition of the header formats using the formal notation, the 1118 argument "is_innermost" passed to the corresponding encoding 1119 method (ipv4 or ipv6) determines what irregular chain items to 1120 use. The format of the irregular chain item for the outer IP 1121 headers is also determined using one flag for TTL/Hop Limit and 1122 TOS/TC. This flag is defined in the format of some of the 1123 compressed base headers. 1125 ROHCv2 profiles compress extension headers as other headers, and thus 1126 extension headers have a static chain, a dynamic chain and an 1127 irregular chain. 1129 ROHCv2 profiles define chains for all headers that can be compressed, 1130 i.e., RTP [RFC3550], UDP [RFC0768], ESP [RFC4303], UDP Lite 1131 [RFC3828], IPv4 [RFC0791], IPv6 [RFC2460], AH [RFC4302], GRE 1132 [RFC2784][RFC2890], MINE [RFC2004], IPv6 Destination Options header 1133 [RFC2460], IPv6 Hop-by-hop Options header [RFC2460] and IPv6 Routing 1134 header [RFC2460]. 1136 6.6. Header Formats and Encoding Methods 1138 The header formats are defined using the ROHC formal notation. Some 1139 of the encoding methods used in the header formats are defined in 1140 [RFC4997], while other methods are defined in this section. 1142 6.6.1. baseheader_extension_headers 1144 The baseheader_extension_headers encoding method skips over all 1145 fields of the extension headers of the innermost IP header, without 1146 encoding any of them. Fields in these extension headers are instead 1147 encoded in the irregular chain. 1149 This encoding is used in CO headers (see Section 6.8.2). The 1150 innermost IP header is combined with other header(s) (i.e., UDP, UDP 1151 Lite, RTP) to create the compressed base header. In this case, there 1152 may be a number of extension headers between the IP headers and the 1153 other headers. 1155 The base header defines a representation of the extension headers, to 1156 comply with the syntax of the formal notation; this encoding method 1157 provides this representation. 1159 6.6.2. baseheader_outer_headers 1161 The baseheader_outer_headers encoding method skips over all the 1162 fields of the extension header(s) that do not belong to the innermost 1163 IP header, without encoding any of them. Changing fields in outer 1164 headers are instead handled by the irregular chain. 1166 This encoding method, similarly to the baseheader_extension_headers 1167 encoding method above, is necessary to keep the definition of the 1168 header formats syntactically correct. It describes tunneling IP 1169 headers and their respective extension headers (i.e., all headers 1170 located before the innermost IP header) for CO headers (see 1171 Section 6.8.2). 1173 6.6.3. inferred_udp_length 1175 The decompressor infers the value of the UDP length field as being 1176 the sum of the UDP header length and the UDP payload length. The 1177 compressor must therefore ensure that the UDP length field is 1178 consistent with the length field(s) of preceding subheaders, i.e., 1179 there must not be any padding after the UDP payload that is covered 1180 by the IP Length. 1182 This encoding method is also used for the UDP-Lite Checksum Coverage 1183 field, when it behaves in the same manner as the UDP length field 1184 (i.e., when the checksum always covers the entire UDP-Lite payload). 1186 6.6.4. inferred_ip_v4_header_checksum 1188 This encoding method compresses the header checksum field of the IPv4 1189 header. This checksum is defined in RFC 791 [RFC0791] as follows: 1191 Header Checksum: 16 bits 1193 A checksum on the header only. Since some header fields change 1194 (e.g., time to live), this is recomputed and verified at each 1195 point that the internet header is processed. 1197 The checksum algorithm is: 1199 The checksum field is the 16 bit one's complement of the one's 1200 complement sum of all 16 bit words in the header. For purposes 1201 of computing the checksum, the value of the checksum field is 1202 zero. 1204 As described above, the header checksum protects individual hops from 1205 processing a corrupted header. There is no reason to transmit this 1206 checksum when almost all IP header information is compressed away, 1207 and when decompression is verified by a CRC computed over the 1208 original header for every compressed packet; instead, the checksum 1209 can be recomputed by the decompressor. 1211 The "inferred_ip_v4_header_checksum" encoding method thus compresses 1212 the header checksum field of the IPv4 header down to a size of zero 1213 bits, i.e., no bits are transmitted in compressed headers for this 1214 field. Using this encoding method, the decompressor infers the value 1215 of this field using the computation above. 1217 The compressor MAY use the header checksum to validate the 1218 correctness of the header before compressing it, to avoid processing 1219 a corrupted header. 1221 6.6.5. inferred_mine_header_checksum 1223 This encoding method compresses the minimal encapsulation header 1224 checksum. This checksum is defined in RFC 2004 [RFC2004] as follows: 1226 Header Checksum 1228 The 16-bit one's complement of the one's complement sum of all 1229 16-bit words in the minimal forwarding header. For purposes of 1230 computing the checksum, the value of the checksum field is 0. 1231 The IP header and IP payload (after the minimal forwarding 1232 header) are not included in this checksum computation. 1234 The "inferred_mine_header_checksum" encoding method compresses the 1235 minimal encapsulation header checksum down to a size of zero bits, 1236 i.e., no bits are transmitted in compressed headers for this field. 1237 Using this encoding method, the decompressor infers the value of this 1238 field using the above computation. 1240 The motivations for inferring this checksum are similar to the ones 1241 explained above in Section 6.6.4. 1243 The compressor MAY use the minimal encapsulation header checksum to 1244 validate the correctness of the header before compressing it, to 1245 avoid processing a corrupted header. 1247 6.6.6. inferred_ip_v4_length 1249 This encoding method compresses the total length field of the IPv4 1250 header. The total length field of the IPv4 header is defined in RFC 1251 791 [RFC0791] as follows: 1253 Total Length: 16 bits 1255 Total Length is the length of the datagram, measured in octets, 1256 including internet header and data. This field allows the 1257 length of a datagram to be up to 65,535 octets. 1259 The "inferred_ip_v4_length" encoding method compresses the IPv4 1260 header checksum down to a size of zero bits, i.e., no bits are 1261 transmitted in compressed headers for this field. Using this 1262 encoding method, the decompressor infers the value of this field by 1263 counting in octets the length of the entire packet after 1264 decompression. 1266 6.6.7. inferred_ip_v6_length 1268 This encoding method compresses the payload length field in the IPv6 1269 header. This length field is defined in RFC 2460 [RFC2460] as 1270 follows: 1272 Payload Length: 16-bit unsigned integer 1274 Length of the IPv6 payload, i.e., the rest of the packet 1275 following this IPv6 header, in octets. (Note that any 1276 extension headers present are considered part of the payload, 1277 i.e., included in the length count.) 1279 The "inferred_ip_v6_length" encoding method compresses the payload 1280 length field of the IPv6 header down to a size of zero bits, i.e., no 1281 bits are transmitted in compressed headers for this field. Using 1282 this encoding method, the decompressor infers the value of this field 1283 by counting in octets the length of the entire packet after 1284 decompression. 1286 6.6.8. Scaled RTP Timestamp Compression 1288 This section provides additional details on encodings used to scale 1289 the RTP timestamp, as defined in the formal notation in 1290 Section 6.8.2.4. 1292 The RTP timestamp (TS) usually increases by a multiple of the RTP 1293 Sequence Number's (SN) increase and is therefore a suitable candidate 1294 for scaled encoding. This scaling factor is labeled ts_stride in the 1295 definition of the profile in the formal notation. The compressor 1296 sets the scaling factor based on the change in TS with respect to the 1297 change in the RTP SN. 1299 The default value of the scaling factor ts_stride is 160, as defined 1300 in Section 6.8.2.4. To use a different value for ts_stride, the 1301 compressor explicitly updates the value of ts_stride to the 1302 decompressor using one of the header formats that can carry this 1303 information. 1305 When the compressor uses a scaling factor that is different than the 1306 default value of ts_stride, it can only use the new scaling factor 1307 once it has enough confidence that the decompressor has successfully 1308 calculated the residue (ts_offset) of the scaling function for the 1309 timestamp. The compressor achieves this by sending unscaled 1310 timestamp values, to allow the decompressor to establish the residue 1311 based on the current ts_stride. The compressor MAY send the unscaled 1312 timestamp in the same compressed header(s) used to establish the 1313 value of ts_stride. 1315 Once the compressor has gained enough confidence that both the value 1316 of the scaling factor and the value of the residue have been 1317 established in the decompressor, the compressor can start compressing 1318 packets using the new scaling factor. 1320 When the compressor detects that the residue (ts_offset) value has 1321 changed, it MUST NOT select a compressed header format that uses the 1322 scaled timestamp encoding before it has re-established the residue as 1323 described above. 1325 When the value of the timestamp field wraps around, the value of the 1326 residue of the scaling function is likely to change. When this 1327 occurs, the compressor re-establishes the new residue value as 1328 described above. 1330 If the decompressor receives a compressed header containing scaled 1331 timestamp bits while the ts_stride equals zero, it MUST NOT deliver 1332 the packet to upper layers and it SHOULD treat this as a CRC 1333 verification failure. 1335 Whether or not the scaling is applied to the RTP TS field is up to 1336 the compressor implementation (i.e., The use of scaling is OPTIONAL), 1337 and is indicated by the tsc_indicator control field. In case scaling 1338 is applied to the RTP TS field, the value of ts_stride used by the 1339 compressor is up to the implementation. A value of ts_stride that is 1340 set to the expected increase in RTP timestamp between consecutive 1341 unit increase of the RTP SN will provide the most gain for the scaled 1342 encoding. Other values may provide the same gain in some situations, 1343 but may reduce the gain in others. 1345 When scaled timestamp encoding is used for header formats that do not 1346 transmit any lsb-encoded timestamp bits at all, the 1347 inferred_scaled_field encoding of Section 6.6.10 is used for encoding 1348 the timestamp. 1350 6.6.9. timer_based_lsb 1352 The timer-based compression encoding method, "timer_based_lsb", 1353 compresses a field whose change pattern approximates a linear 1354 function of the time of day. 1356 This encoding uses the local clock to obtain an approximation of the 1357 value that it encodes. The approximated value is then used as a 1358 reference value together with the num_lsbs_param least-significant 1359 bits received as the encoded value, where num_lsbs_param represents a 1360 number of bits that is sufficient to uniquely represent the encoded 1361 value in the presence of jitter between compression endpoints. 1363 ts_scaled =:= timer_based_lsb(, 1364 , ) 1366 The parameters "num_lsbs_param" and "offset_param" are the parameters 1367 to use for the lsb encoding, i.e., the number of least significant 1368 bits and the interpretation interval offset, respectively. The 1369 parameter "time_stride_param" represents the context value of the 1370 control field time_stride. 1372 This encoding method always uses a scaled version of the field it 1373 compresses. 1375 The value of the field is decoded by calculating an approximation of 1376 the scaled value, using: 1377 tsc_ref_advanced = tsc_ref + (a_n - a_ref) / time_stride. 1379 where: 1380 - tsc_ref is a reference value of the scaled representation 1381 of the field. 1382 - a_n is the arrival time associated to the value to decode. 1383 - a_ref is the arrival time associated to the reference header. 1384 - tsc_ref_advanced is an approximation of the scaled value 1385 of the field. 1387 The lsb encoding is then applied using the num_lsbs_param bits 1388 received in the compressed header and tsc_ref_advanced as "ref_value" 1389 (as per Section 4.11.5 of [RFC4997]). 1391 Appendix B.3 provides an example on how the compressor can calculate 1392 jitter. 1394 The control field time_stride controls whether or not the 1395 timer_based_lsb method is used in the CO header. The decompressor 1396 SHOULD send the CLOCK_RESOLUTION option with a zero value, if: 1398 o it receives a non-zero time_stride value, and 1399 o it has not previously sent a CLOCK_RESOLUTION feedback with a non- 1400 zero value. 1402 This is to allow compression to recover from the case where a 1403 compressor erroneously activates timer-based compression. 1405 The support and usage of timer-based compression is OPTIONAL for both 1406 the compressor and the decompressor; the compressor is not required 1407 to set the time_stride control field to a non-zero value when it has 1408 received a non-zero value for the CLOCK_RESOLUTION option. 1410 6.6.10. inferred_scaled_field 1412 The "inferred_scaled_field" encoding method encodes a field that is 1413 defined as changing in relation to the MSN, and for which the 1414 increase with respect to the MSN can be scaled by some scaling 1415 factor. This encoding method is used in compressed header formats 1416 that do not contain any bits for the scaled field. In this case, the 1417 decompressor infers the unscaled value of the scaled field from the 1418 MSN field, which value is calculated according to the following 1419 formula: 1421 unscaled_value = delta_msn * stride + reference_unscaled_value 1423 Where "delta_msn" is the difference in MSN between the reference 1424 value of the MSN in the context and the value of the MSN decompressed 1425 from this packet, "reference_unscaled_value" is the value of the 1426 field being scaled in the context, and "stride" is the scaling value 1427 for this field. 1429 For example, when this encoding method is applied to the RTP 1430 timestamp in the RTP profile, the calculation above becomes: 1432 timestamp = delta_msn * ts_stride + reference_timestamp 1434 6.6.11. control_crc3_encoding 1436 The "control_crc3_encoding" method provides a CRC calculated over a 1437 number of control fields. The definition of this encoding method is 1438 the same as for the "crc" encoding method specified in section 4.11.6 1439 of [RFC4997], with the difference that the data that is covered by 1440 the CRC is given by a concatenated list of control fields. 1442 In other words, the definition of the control_crc3_encoding method is 1443 equivalent to the following definition: 1445 control_crc_encoding(ctrl_data_value, ctrl_data_length) 1446 { 1447 UNCOMPRESSED { 1448 } 1450 COMPRESSED { 1451 control_crc3 =:= 1452 crc(3, 0x06, 0x07, ctrl_data_value, ctrl_data_length) [ 3 ]; 1453 } 1454 } 1456 where the parameter "ctrl_data_value" binds to the concatenated 1457 values of the following control fields, in the order listed below: 1459 o reorder_ratio, 2 bits padded with 6 MSB of zeroes 1460 o ts_stride, 32 bits (only for profiles 0x0101 and 0x0107) 1461 o time_stride, 32 bits (only for profiles 0x0101 and 0x0107) 1462 o msn, 16 bits (not applicable for profiles 0x0101, 0x0103 and 1463 0x0107) 1464 o coverage_behavior, 2 bits padded with 6 MSB of zeroes (only to 1465 profiles 0x0107 and 0x0108) 1466 o ip_id_behavior, one octet for each IP header in the compressible 1467 header chain starting from the outermost header. Each octet 1468 consists of 2 bits padded with 6 MSBs of zeroes 1470 The "ctrl_data_length" binds to the sum of the length of the control 1471 field(s) that are applicable to the specific profile. 1473 The decompressor uses the resulting 3-bit CRC to validate the control 1474 fields that are updated by the co_common and co_repair header 1475 formats; this CRC cannot be used to verify the outcome of a 1476 decompression attempt. 1478 This CRC protects the update of control fields, as the updated values 1479 are not always used to decompress the header that carries them and 1480 thus are not protected by the CRC-7 verification. This prevents 1481 impairments that could occur in case the decompression of a co_common 1482 or of a co_repair succeeds and the decompressor would send positive 1483 feedback, while for some reason the control fields would be 1484 incorrectly updated. 1486 6.6.12. inferred_sequential_ip_id 1488 This encoding method is used with a sequential IP-ID behavior 1489 (sequential or sequential byte-swapped) and when there are no coded 1490 IP-ID bits in the compressed header. In this case, the IP-ID offset 1491 from the MSN is constant, and the IP-ID increases by the same amount 1492 as the MSN (similar to the inferred_scaled_field encoding method). 1494 The decompressor calculates the value for the IP-ID according to the 1495 following formula: 1497 IP-ID = delta_msn + reference_IP_ID_value 1498 where "delta_msn" is the difference between the reference value of 1499 the MSN in the context and the uncompressed value of the MSN 1500 associated to the compressed header, and where 1501 "reference_IP_ID_value" is the value of the IP-ID in the context. 1502 For swapped IP-ID behavior (i.e., when ip_id_behavior_innermost is 1503 set to IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED), "reference_IP_ID_value" 1504 and "IP-ID" are byte-swapped with regard to the corresponding fields 1505 in the context. 1507 If the IP-ID behavior is random or zero, this encoding method does 1508 not update any fields. 1510 6.6.13. list_csrc(cc_value) 1512 This encoding method compresses the list of RTP CSRC identifiers 1513 using list compression. This encoding establishes a content for the 1514 different CSRC identifiers (items) and a list describing the order in 1515 which they appear. 1517 The compressor passes an argument (cc_value) to this encoding method: 1518 this is the value of the CC field taken from the RTP header. The 1519 decompressor is required to bind the value of this argument to the 1520 number of items in the list, which will allow the decompressor to 1521 correctly reconstruct the CC field. 1523 6.6.13.1. List Compression 1525 The CSRC identifiers in the uncompressed packet can be represented as 1526 an ordered list, whose order and presence are usually constant 1527 between packets. The generic structure of such a list is as follows: 1529 +--------+--------+--...--+--------+ 1530 list: | item 1 | item 2 | | item n | 1531 +--------+--------+--...--+--------+ 1533 When performing list compression on a CSRC list, each item is the 1534 uncompressed value of one CSRC identifier. 1536 The basic principles of list-based compression are the following: 1538 When initializing the context: 1540 1) The complete representation of the list of CSRC identifiers is 1541 transmitted. 1543 Then, once the context has been initialized: 1545 2) When the list is unchanged, a compressed header that does not 1546 contain information about the list can be used. 1547 3) When the list changes, a compressed list is sent in the 1548 compressed header, including a representation of its structure and 1549 order. Previously unknown items are sent uncompressed in the 1550 list, while previously known items are only represented by an 1551 index pointing to the item stored in the context. 1553 6.6.13.2. Table-based Item Compression 1555 The table-based item compression compresses individual items sent in 1556 compressed lists. The compressor assigns a unique identifier, 1557 "Index", to each item "Item" of a list. 1559 Compressor Logic 1561 The compressor conceptually maintains an Item Table containing all 1562 items, indexed using "Index". The (Index, Item) pair is sent 1563 together in compressed lists until the compressor gains enough 1564 confidence that the decompressor has observed the mapping between 1565 items and their respective index. Confidence is obtained from the 1566 reception of an acknowledgment from the decompressor, or by 1567 sending (Index, Item) pairs using the optimistic approach. Once 1568 confidence is obtained, the index alone is sent in compressed 1569 lists to indicate the presence of the item corresponding to this 1570 index. 1572 The compressor MAY reset its item table upon receiving negative 1573 acknowledgement. 1575 The compressor MAY reassign an existing index to a new item, by 1576 re-establishing the mapping using the procedure described above. 1578 Decompressor Logic 1580 The decompressor conceptually maintains an Item Table that 1581 contains all (Index, Item) pairs received. The Item Table is 1582 updated whenever an (Index, Item) pair is received and 1583 decompression is successful (CRC verification, or CRC-8 1584 validation). The decompressor retrieves the item from the table 1585 whenever an Index is received without an accompanying Item. 1587 If an index is received without an accompanying Item and the 1588 decompressor does not have any context for this index, the 1589 decompressor MUST NOT deliver the packet to upper layers. 1591 6.6.13.3. Encoding of Compressed Lists 1593 Each item present in a compressed list is represented by: 1595 o an index into the table of items, and 1596 o a presence bit indicating if a compressed representation of the 1597 item is present in the list. 1598 o an item (if the presence bit is set) 1600 If the presence bit is not set, the item must already be known by the 1601 decompressor. 1603 A compressed list of items uses the following encoding: 1605 0 1 2 3 4 5 6 7 1606 +---+---+---+---+---+---+---+---+ 1607 | Reserved |PS | m | 1608 +---+---+---+---+---+---+---+---+ 1609 | XI_1, ..., XI_m | m octets, or m * 4 bits 1610 / --- --- --- ---/ 1611 | : Padding : if PS = 0 and m is odd 1612 +---+---+---+---+---+---+---+---+ 1613 | | 1614 / item_1, ..., item_n / variable 1615 | | 1616 +---+---+---+---+---+---+---+---+ 1617 Reserved: MUST be set to zero; otherwise, the decompressor MUST 1618 discard the packet. 1620 PS: Indicates size of XI fields: 1621 PS = 0 indicates 4-bit XI fields; 1622 PS = 1 indicates 8-bit XI fields. 1624 m: Number of XI item(s) in the compressed list. Also the value of 1625 the cc_value argument of the list_csrc encoding (Section 6.6.13). 1627 XI_1, ..., XI_m: m XI items. Each XI represents one item in the 1628 list of item of the uncompressed header, in the same order as they 1629 appear in the uncompressed header. 1631 The format of an XI item is as follows: 1633 0 1 2 3 1634 +---+---+---+---+ 1635 PS = 0: | X | Index | 1636 +---+---+---+---+ 1638 0 1 2 3 4 5 6 7 1639 +---+---+---+---+---+---+---+---+ 1640 PS = 1: | X | Reserved | Index | 1641 +---+---+---+---+---+---+---+---+ 1643 X: Indicates whether the item is present in the list: 1645 X = 1 indicates that the item corresponding to the Index is 1646 sent in the item_1, ..., item_n list; 1647 X = 0 indicates that the item corresponding to the Index is 1648 not sent. 1650 Reserved: MUST be set to zero; otherwise the decompressor MUST 1651 discard the packet. 1653 Index: An index into the item table. See Section 6.6.13.4 1655 When 4-bit XI items are used, the XI items are placed in octets 1656 in the following manner: 1658 0 1 2 3 4 5 6 7 1659 +---+---+---+---+---+---+---+---+ 1660 | XI_k | XI_k + 1 | 1661 +---+---+---+---+---+---+---+---+ 1663 Padding: A 4-bit padding field is present when PS = 0 and the 1664 number of XIs is odd. The Padding field MUST be set to zero; 1665 otherwise, the decompressor MUST discard the packet. 1667 Item 1, ..., item n: Each item corresponds to an XI with X = 1 in 1668 XI 1, ..., XI m. Each entry in the item list is the uncompressed 1669 representation of one CSRC identifier. 1671 6.6.13.4. Item Table Mappings 1673 The item table for list compression is limited to 16 different items, 1674 since the RTP header can only carry at most 15 simultaneous CSRC 1675 identifiers. The effect of having more than 16 items in the item 1676 table will only cause a slight overhead to the compressor when items 1677 are swapped in/out of the item table. 1679 6.6.13.5. Compressed Lists in Dynamic Chain 1681 A compressed list that is part of the dynamic chain must have all its 1682 list items present, i.e., all X-bits in the XI list MUST be set. All 1683 items previously established in the item table that are not present 1684 in the list decompressed from this packet MUST also be retained in 1685 the decompressor context. 1687 6.7. Encoding Methods With External Parameters as Arguments 1689 A number of encoding methods in Section 6.8.2.4 have one or more 1690 arguments for which the derivation of the parameter's value is 1691 outside the scope of the ROHC-FN specification of the header formats. 1693 List of encoding methods with external parameters as arguments, from 1694 Section 6.8.2.4: 1696 o udp(profile_value, reorder_ratio_value) 1697 o udp_lite(profile_value, reorder_ratio_value, 1698 coverage_behavior_value) 1699 o esp(profile_value, reorder_ratio_value) 1700 o rtp(profile_value, ts_stride_value, time_stride_value, 1701 reorder_ratio_value) 1702 o ipv4(profile_value, is_innermost, outer_ip_flag, 1703 ip_id_behavior_value, reorder_ratio_value)) 1704 o ipv6(profile_value, is_innermost, outer_ip_flag, 1705 reorder_ratio_value)) 1706 o iponly_baseheader(profile_value, outer_ip_flag, 1707 ip_id_behavior_value, reorder_ratio_value) 1708 o udp_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value, 1709 reorder_ratio_value) 1711 o udplite_baseheader(profile_value, outer_ip_flag, 1712 ip_id_behavior_value, reorder_ratio_value) 1713 o esp_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value, 1714 reorder_ratio_value) 1715 o rtp_baseheader(profile_value, ts_stride_value, time_stride_value, 1716 outer_ip_flag, ip_id_behavior_value, reorder_ratio_value) 1717 o udplite_rtp_baseheader(profile_value, ts_stride_value, 1718 time_stride_value, outer_ip_flag, ip_id_behavior_value, 1719 reorder_ratio_value, coverage_behavior_value) 1721 The following applies for all parameters listed below: At the 1722 compressor, the value of the parameter is set according to the 1723 recommendations for each parameter. At the decompressor, the value 1724 of the parameter is set to undefined and will get bound by encoding 1725 methods, except where otherwise noted. 1727 List of external arguments with their respective definition: 1729 o profile_value: 1731 Set to the 16-bit number that identifies the profile used to 1732 compress this packet. When processing the static chain at the 1733 decompressor, this parameter is set to the value of the profile 1734 field in the IR header (see Section 6.8.1). 1736 o reorder_ratio_value: 1738 Set to a 2-bit integer value, using one of the constants whose 1739 name begins with the prefix REORDERING_ and as defined in 1740 Section 6.8.2.4. 1742 o ip_id_behavior_value: 1744 Set to a 2-bit integer value, using one of the constants whose 1745 name begins with the prefix IP_ID_BEHAVIOR_ and as defined in 1746 Section 6.8.2.4. 1748 o coverage_behavior_value: 1750 Set to a 2-bit integer value, using one of the constants whose 1751 name begins with the prefix UDP_LITE_COVERAGE_ and as defined 1752 in Section 6.8.2.4. 1754 o outer_ip_flag: 1756 This parameter is set to 1 if at least one of the TOS/TC or 1757 TTL/Hop Limit fields in outer IP headers has changed compared 1758 to their reference values in the context, otherwise it is set 1759 to 0. This flag may only be set to 1 for the "co_common" 1760 header format in the different profiles. 1762 o is_innermost: 1764 This boolean flag is set to 1 when processing the innermost of 1765 the compressible IP headers; otherwise it is set to 0. 1767 o ts_stride_value 1769 The value of this parameter should be set to the expected 1770 increase in the RTP Timestamp between consecutive RTP sequence 1771 numbers. The value selected is implementation-specific. See 1772 also Section 6.6.8. 1774 o time_stride_value 1776 The value of this parameter should be set to the expected 1777 inter-arrival time between consecutive packets for the flow. 1778 The value selected is implementation-specific. This parameter 1779 MUST be set to zero, unless the compressor has received a 1780 feedback message with the CLOCK_RESOLUTION option set to a non- 1781 zero value. See also Section 6.6.9. 1783 6.8. Header Formats 1785 ROHCv2 profiles use two different header types: the Initialization 1786 and Refresh (IR) header type, and the Compressed header type (CO). 1788 The CO header type defines a number of header formats: there are two 1789 sets of base header formats, with a few additional formats that are 1790 common to both sets. 1792 6.8.1. Initialization and Refresh Header Format (IR) 1794 The IR header format uses the structure of the ROHC IR header as 1795 defined in [RFC4995], section 5.2.2.1. 1797 Header type: IR 1798 This header format communicates the static part and the dynamic 1799 part of the context. 1801 The ROHCv2 IR header has the following format: 1803 0 1 2 3 4 5 6 7 1804 --- --- --- --- --- --- --- --- 1805 : Add-CID octet : if for small CIDs and (CID != 0) 1806 +---+---+---+---+---+---+---+---+ 1807 | 1 1 1 1 1 1 0 1 | IR type octet 1808 +---+---+---+---+---+---+---+---+ 1809 : : 1810 / 0-2 octets of CID / 1-2 octets if for large CIDs 1811 : : 1812 +---+---+---+---+---+---+---+---+ 1813 | Profile | 1 octet 1814 +---+---+---+---+---+---+---+---+ 1815 | CRC | 1 octet 1816 +---+---+---+---+---+---+---+---+ 1817 | | 1818 / Static chain / variable length 1819 | | 1820 - - - - - - - - - - - - - - - - 1821 | | 1822 / Dynamic chain / variable length 1823 | | 1824 - - - - - - - - - - - - - - - - 1826 CRC: 8-bit CRC over the entire IR-header, including any CID fields 1827 and up until the end of the dynamic chain, using the polynomial 1828 defined in [RFC4995]. For purposes of computing the CRC, the CRC 1829 field is zero. 1830 Static chain: See Section 6.5. 1832 Dynamic chain: See Section 6.5. 1834 6.8.2. Compressed Header Formats (CO) 1836 6.8.2.1. Design Rationale for Compressed Base Headers 1838 The compressed header formats are defined as two separate sets for 1839 each profile: one set for the headers where the innermost IP header 1840 contains a sequential IP-ID (either network byte order or byte 1841 swapped), and one set for the headers without sequential IP-ID 1842 (either random, zero, or no IP-ID). There are also a number of 1843 common header formats shared between both sets. In the description 1844 below, the naming convention used for header formats that belong to 1845 the sequential set is to include "seq" in the name of the format, 1846 while similarly "rnd" is used for those that belong to the non- 1847 sequential set. 1849 The design of the header formats is derived from the field behavior 1850 analysis found in Appendix A. 1852 All of the compressed base headers transmit lsb-encoded MSN bits and 1853 a CRC. 1855 The following header formats exist for all profiles defined in this 1856 document, and are common to both the sequential and the random header 1857 format sets: 1859 o co_common: This format can be used to update the context when the 1860 established change pattern of a dynamic field changes, for any of 1861 the dynamic fields. However, not all dynamic fields are updated 1862 by conveying their uncompressed value; some fields can only be 1863 transmitted using a compressed representation. This format is 1864 especially useful when a rarely changing field needs to be 1865 updated. This format contains a set of flags to indicate what 1866 fields are present in the header, and its size can vary 1867 accordingly. This format is protected by a 7-bit CRC. It can 1868 update control fields, and it thus also carries a 3-bit CRC to 1869 protect those fields as well. This format is similar in purpose 1870 to the UOR-2-extension 3 format of [RFC3095]. 1872 o co_repair: This format can be used to update the context of all 1873 the dynamic fields by conveying their uncompressed value. This is 1874 especially useful when context damage is assumed (e.g. from the 1875 reception of a NACK) and a context repair is performed. This 1876 format is protected by a 7-bit CRC. It also carries a 3-bit CRC 1877 over the control fields, which control fields it can also update. 1878 This format is similar in purpose to the IR-DYN format of 1879 [RFC3095] when performing context repairs. 1881 o pt_0_crc3: This format conveys only the MSN; it can therefore only 1882 update the MSN and fields that are derived from the MSN, such as 1883 IP-ID and the RTP Timestamp (for applicable profiles). It is 1884 protected by a 3-bit CRC. This format is equivalent to the UO-0 1885 header format in [RFC3095]. 1887 o pt_0_crc7: This format has the same properties as pt_0_crc3, but 1888 is instead protected by a 7-bit CRC and contains a larger amount 1889 of lsb-encoded MSN bits. This format is useful in environments 1890 where a high amount of reordering or a high residual error rate 1891 can occur. 1893 The following header format descriptions apply to profiles 0x0101 and 1894 0x0107. 1896 o pt_1_rnd: This format can convey changes to the MSN, to the RTP 1897 Marker bit and it can update the RTP timestamp using scaled 1898 timestamp encoding. It is protected by a 3-bit CRC. It is 1899 similar in purpose to the UO-1 format in [RFC3095]. 1901 o pt_1_seq_id: This format can convey changes to the MSN and to the 1902 IP-ID. It is protected by a 3-bit CRC. It is similar in purpose 1903 to the UO-1-ID format in [RFC3095]. 1905 o pt_1_seq_ts: This format can convey changes to the MSN, to the RTP 1906 Marker bit and it can update the RTP Timestamp using scaled 1907 timestamp encoding. It is protected by a 3-bit CRC. It is 1908 similar in purpose to the UO-1-TS format in [RFC3095]. 1910 o pt_2_rnd: This format can convey changes to the MSN, to the RTP 1911 Marker bit and to the RTP Timestamp. It is protected by a 7-bit 1912 CRC. It is similar in purpose to the UOR-2 format in [RFC3095]. 1914 o pt_2_seq_id: This format can convey changes to the MSN and to the 1915 IP-ID. It is protected by a 7-bit CRC. It is similar in purpose 1916 to the UO-2-ID format in [RFC3095]. 1918 o pt_2_seq_ts: This format can convey changes to the MSN, to the RTP 1919 Marker bit and it can update the RTP Timestamp using scaled 1920 timestamp encoding. It is protected by a 7-bit CRC. It is 1921 similar in purpose to the UO-2-TS format in [RFC3095]. 1923 o pt_2_seq_both: This format can convey changes to both the RTP 1924 Timestamp and IP-ID, in addition to the MSN and to the Marker bit. 1925 It is protected by a 7-bit CRC. It is similar in purpose to the 1926 UOR-2-ID extension 1 format in [RFC3095]. 1928 The following header formats descriptions apply to profiles 0x0102, 1929 0x0103, 0x0104 and 0x0108. 1931 o pt_1_seq_id: This format can convey changes to the MSN and to the 1932 IP-ID. It is protected by a 7-bit CRC. It is similar in purpose 1933 to the UO-1-ID format in [RFC3095]. 1935 o pt_2_seq_id: This format can convey changes to the MSN and to the 1936 IP-ID. It is protected by a 7-bit CRC. It is similar in purpose 1937 to the UO-2-ID format in [RFC3095]. 1939 6.8.2.2. co_repair Header Format 1941 The ROHCv2 co_repair header has the following format: 1943 0 1 2 3 4 5 6 7 1944 --- --- --- --- --- --- --- --- 1945 : Add-CID octet : if for small CIDs and CID 1-15 1946 +---+---+---+---+---+---+---+---+ 1947 | 1 1 1 1 1 0 1 1 | discriminator 1948 +---+---+---+---+---+---+---+---+ 1949 : : 1950 / 0, 1, or 2 octets of CID / 1-2 octets if large CIDs 1951 : : 1952 +---+---+---+---+---+---+---+---+ 1953 |r1 | CRC-7 | 1954 +---+---+---+---+---+---+---+---+ 1955 | r2 | CRC-3 | 1956 +---+---+---+---+---+---+---+---+ 1957 | | 1958 / Dynamic chain / variable length 1959 | | 1960 - - - - - - - - - - - - - - - - 1962 r1: MUST be set to zero; otherwise, the decompressor MUST discard 1963 the packet. 1965 CRC-7: A 7-bit CRC over the entire uncompressed header, computed 1966 using the crc7(data_value, data_length) encoding method defined in 1967 Section 6.8.2.4, where data_value corresponds to the entire 1968 uncompressed header chain and where data_length corresponds to the 1969 length of this header chain. 1971 r2: MUST be set to zero; otherwise, the decompressor MUST discard 1972 the packet. 1974 CRC-3: Encoded using the control_crc3_encoding method defined in 1975 Section 6.6.11. 1977 Dynamic chain: See Section 6.5. 1979 6.8.2.3. General CO Header Format 1981 The CO header format communicates irregularities in the packet 1982 header. All CO formats carry a CRC and can update the context. All 1983 CO header formats use the general format defined in this section, 1984 with the exception of the co_repair format which is defined in 1985 Section 6.8.2.2 . 1987 The general format for a compressed header is as follows: 1989 0 1 2 3 4 5 6 7 1990 --- --- --- --- --- --- --- --- 1991 : Add-CID octet : if for small CIDs and CID 1-15 1992 +---+---+---+---+---+---+---+---+ 1993 | first octet of base header | (with type indication) 1994 +---+---+---+---+---+---+---+---+ 1995 : : 1996 / 0, 1, or 2 octets of CID / 1-2 octets if large CIDs 1997 : : 1998 +---+---+---+---+---+---+---+---+ 1999 / remainder of base header / variable length 2000 +---+---+---+---+---+---+---+---+ 2001 : : 2002 / Irregular Chain / variable length 2003 : : 2004 --- --- --- --- --- --- --- --- 2006 The base header in the figure above is the compressed representation 2007 of the innermost IP header and other header(s), if any, in the 2008 uncompressed packet. The base header formats are defined in 2009 Section 6.8.2.4. In the formal description of the header formats, 2010 the base header for each profile is labeled 2011 _baseheader, where is defined in the 2012 following table: 2014 +------------------+----------------+ 2015 | Profile number | profile_name | 2016 +------------------+----------------+ 2017 | 0x0101 | rtp | 2018 | 0x0102 | udp | 2019 | 0x0103 | esp | 2020 | 0x0104 | ip | 2021 | 0x0107 | udplite_rtp | 2022 | 0x0108 | udplite | 2023 +------------------+----------------+ 2025 6.8.2.4. Header Formats in ROHC-FN 2027 This section defines the complete set of base header formats for 2028 ROHCv2 profiles. The base header formats are defined using the ROHC 2029 Formal notation [RFC4997] . 2031 // NOTE The irregular, static and dynamic chains (see section 6.5) 2032 // are defined across multiple encoding methods and are embodied 2033 // in the correspondingly named formats within those encoding 2034 // methods. In particular note that the static and dynamic 2035 // chains ordinarily go together. The uncompressed fields are 2036 // defined across these two formats combined, rather than in one 2037 // or the other of them. The irregular chain items are likewise 2038 // combined with a baseheader format. 2040 //////////////////////////////////////////// 2041 // Constants 2042 //////////////////////////////////////////// 2044 // IP-ID behavior constants 2045 IP_ID_BEHAVIOR_SEQUENTIAL = 0; 2046 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED = 1; 2047 IP_ID_BEHAVIOR_RANDOM = 2; 2048 IP_ID_BEHAVIOR_ZERO = 3; 2050 // UDP-lite checksum coverage behavior constants 2051 UDP_LITE_COVERAGE_INFERRED = 0; 2052 UDP_LITE_COVERAGE_STATIC = 1; 2053 UDP_LITE_COVERAGE_IRREGULAR = 2; 2054 // The value 3 is reserved and cannot be used for coverage behavior 2056 // Variable reordering offset 2057 REORDERING_NONE = 0; 2058 REORDERING_QUARTER = 1; 2059 REORDERING_HALF = 2; 2060 REORDERING_THREEQUARTERS = 3; 2062 // Profile names and versions 2063 PROFILE_RTP_0101 = 0x0101; 2064 PROFILE_UDP_0102 = 0x0102; 2065 PROFILE_ESP_0103 = 0x0103; 2066 PROFILE_IP_0104 = 0x0104; 2067 PROFILE_RTP_0107 = 0x0107; // With UDP-LITE 2068 PROFILE_UDPLITE_0108 = 0x0108; // Without RTP 2070 // Default values for RTP timestamp encoding 2071 TS_STRIDE_DEFAULT = 160; 2072 TIME_STRIDE_DEFAULT = 0; 2074 //////////////////////////////////////////// 2075 // Global control fields 2076 //////////////////////////////////////////// 2078 CONTROL { 2079 profile [ 16 ]; 2080 msn [ 16 ]; 2081 reorder_ratio [ 2 ]; 2082 // ip_id fields are for innermost IP header only 2083 ip_id_offset [ 16 ]; 2084 ip_id_behavior_innermost [ 2 ]; 2085 // The following are only used in RTP-based profiles 2086 ts_stride [ 32 ]; 2087 time_stride [ 32 ]; 2088 ts_scaled [ 32 ]; 2089 ts_offset [ 32 ]; 2090 // UDP-lite-based profiles only 2091 coverage_behavior [ 2 ]; 2092 } 2094 /////////////////////////////////////////////// 2095 // Encoding methods not specified in FN syntax: 2096 /////////////////////////////////////////////// 2098 baseheader_extension_headers "defined in Section 6.6.1"; 2099 baseheader_outer_headers "defined in Section 6.6.2"; 2100 control_crc3_encoding "defined in Section 6.6.11"; 2101 inferred_ip_v4_header_checksum "defined in Section 6.6.4"; 2102 inferred_ip_v4_length "defined in Section 6.6.6"; 2103 inferred_ip_v6_length "defined in Section 6.6.7"; 2104 inferred_mine_header_checksum "defined in Section 6.6.5"; 2105 inferred_scaled_field "defined in Section 6.6.10"; 2106 inferred_sequential_ip_id "defined in Section 6.6.12"; 2107 inferred_udp_length "defined in Section 6.6.3"; 2108 list_csrc(cc_value) "defined in Section 6.6.13"; 2109 timer_based_lsb(time_stride, k, p) "defined in Section 6.6.9"; 2111 //////////////////////////////////////////// 2112 // General encoding methods 2113 //////////////////////////////////////////// 2115 static_or_irreg(flag, width) 2116 { 2117 UNCOMPRESSED { 2118 field [ width ]; 2119 } 2120 COMPRESSED irreg_enc { 2121 ENFORCE(flag == 1); 2122 field =:= irregular(width) [ width ]; 2123 } 2125 COMPRESSED static_enc { 2126 ENFORCE(flag == 0); 2127 field =:= static [ 0 ]; 2128 } 2129 } 2131 optional_32(flag) 2132 { 2133 UNCOMPRESSED { 2134 item [ 0, 32 ]; 2135 } 2137 COMPRESSED present { 2138 ENFORCE(flag == 1); 2139 item =:= irregular(32) [ 32 ]; 2140 } 2142 COMPRESSED not_present { 2143 ENFORCE(flag == 0); 2144 item =:= compressed_value(0, 0) [ 0 ]; 2145 } 2146 } 2148 // Send the entire value, or keep previous value 2149 sdvl_or_static(flag) 2150 { 2151 UNCOMPRESSED { 2152 field [ 32 ]; 2153 } 2155 COMPRESSED present_7bit { 2156 ENFORCE(flag == 1); 2157 ENFORCE(field.UVALUE < 2^7); 2158 ENFORCE(field.CVALUE == field.UVALUE); 2159 discriminator =:= '0' [ 1 ]; 2160 field [ 7 ]; 2161 } 2163 COMPRESSED present_14bit { 2164 ENFORCE(flag == 1); 2165 ENFORCE(field.UVALUE < 2^14); 2166 ENFORCE(field.CVALUE == field.UVALUE); 2167 discriminator =:= '10' [ 2 ]; 2168 field [ 14 ]; 2169 } 2171 COMPRESSED present_21bit { 2172 ENFORCE(flag == 1); 2173 ENFORCE(field.UVALUE < 2^21); 2174 ENFORCE(field.CVALUE == field.UVALUE); 2175 discriminator =:= '110' [ 3 ]; 2176 field [ 21 ]; 2177 } 2179 COMPRESSED present_28bit { 2180 ENFORCE(flag == 1); 2181 ENFORCE(field.UVALUE < 2^28); 2182 ENFORCE(field.CVALUE == field.UVALUE); 2183 discriminator =:= '1110' [ 4 ]; 2184 field [ 28 ]; 2185 } 2187 COMPRESSED present_32bit { 2188 ENFORCE(flag == 1); 2189 ENFORCE(field.CVALUE == field.UVALUE); 2190 discriminator =:= '11111111' [ 8 ]; 2191 field [ 32 ]; 2192 } 2194 COMPRESSED not_present { 2195 ENFORCE(flag == 0); 2196 field =:= static; 2197 } 2198 } 2200 // Send the entire value, or revert to default value 2201 sdvl_or_default(flag, default_value) 2202 { 2203 UNCOMPRESSED { 2204 field [ 32 ]; 2205 } 2207 COMPRESSED present_7bit { 2208 ENFORCE(flag == 1); 2209 ENFORCE(field.UVALUE < 2^7); 2210 ENFORCE(field.CVALUE == field.UVALUE); 2211 discriminator =:= '0' [ 1 ]; 2212 field [ 7 ]; 2213 } 2215 COMPRESSED present_14bit { 2216 ENFORCE(flag == 1); 2217 ENFORCE(field.UVALUE < 2^14); 2218 ENFORCE(field.CVALUE == field.UVALUE); 2219 discriminator =:= '10' [ 2 ]; 2220 field [ 14 ]; 2221 } 2223 COMPRESSED present_21bit { 2224 ENFORCE(flag == 1); 2225 ENFORCE(field.UVALUE < 2^21); 2226 ENFORCE(field.CVALUE == field.UVALUE); 2227 discriminator =:= '110' [ 3 ]; 2228 field [ 21 ]; 2229 } 2231 COMPRESSED present_28bit { 2232 ENFORCE(flag == 1); 2233 ENFORCE(field.UVALUE < 2^28); 2234 ENFORCE(field.CVALUE == field.UVALUE); 2235 discriminator =:= '1110' [ 4 ]; 2236 field [ 28 ]; 2237 } 2239 COMPRESSED present_32bit { 2240 ENFORCE(flag == 1); 2241 ENFORCE(field.CVALUE == field.UVALUE); 2242 discriminator =:= '11111111' [ 8 ]; 2243 field [ 32 ]; 2244 } 2246 COMPRESSED not_present { 2247 ENFORCE(flag == 0); 2248 field =:= uncompressed_value(32, default_value); 2249 } 2250 } 2252 lsb_7_or_31 2253 { 2254 UNCOMPRESSED { 2255 item [ 32 ]; 2256 } 2258 COMPRESSED lsb_7 { 2259 discriminator =:= '0' [ 1 ]; 2260 item =:= lsb(7, ((2^7) / 4) - 1) [ 7 ]; 2261 } 2263 COMPRESSED lsb_31 { 2264 discriminator =:= '1' [ 1 ]; 2265 item =:= lsb(31, ((2^31) / 4) - 1) [ 31 ]; 2266 } 2267 } 2269 crc3(data_value, data_length) 2270 { 2271 UNCOMPRESSED { 2272 } 2274 COMPRESSED { 2275 crc_value =:= crc(3, 0x06, 0x07, data_value, data_length) [ 3 ]; 2276 } 2277 } 2279 crc7(data_value, data_length) 2280 { 2281 UNCOMPRESSED { 2282 } 2284 COMPRESSED { 2285 crc_value =:= crc(7, 0x79, 0x7f, data_value, data_length) [ 7 ]; 2286 } 2287 } 2289 // Encoding method for updating a scaled field and its associated 2290 // control fields. Should be used both when the value is scaled 2291 // or unscaled in a compressed format. 2292 // Does not have an uncompressed side. 2293 field_scaling(stride_value, scaled_value, unscaled_value, residue_value) 2294 { 2295 UNCOMPRESSED { 2296 // Nothing 2297 } 2299 COMPRESSED no_scaling { 2300 ENFORCE(stride_value == 0); 2301 ENFORCE(residue_value == unscaled_value); 2302 ENFORCE(scaled_value == 0); 2303 } 2305 COMPRESSED scaling_used { 2306 ENFORCE(stride_value != 0); 2307 ENFORCE(residue_value == (unscaled_value % stride_value)); 2308 ENFORCE(unscaled_value == 2309 scaled_value * stride_value + residue_value); 2310 } 2311 } 2312 //////////////////////////////////////////// 2313 // IPv6 Destination options header 2314 //////////////////////////////////////////// 2316 ip_dest_opt 2317 { 2318 UNCOMPRESSED { 2319 next_header [ 8 ]; 2320 length [ 8 ]; 2321 value [ length.UVALUE * 64 + 48 ]; 2322 } 2324 DEFAULT { 2325 length =:= static; 2326 next_header =:= static; 2327 value =:= static; 2328 } 2330 COMPRESSED dest_opt_static { 2331 next_header =:= irregular(8) [ 8 ]; 2332 length =:= irregular(8) [ 8 ]; 2333 } 2335 COMPRESSED dest_opt_dynamic { 2336 value =:= 2337 irregular(length.UVALUE * 64 + 48) [ length.UVALUE * 64 + 48 ]; 2338 } 2340 COMPRESSED dest_opt_irregular { 2341 } 2343 } 2345 //////////////////////////////////////////// 2346 // IPv6 Hop-by-Hop options header 2347 //////////////////////////////////////////// 2349 ip_hop_opt 2350 { 2351 UNCOMPRESSED { 2352 next_header [ 8 ]; 2353 length [ 8 ]; 2354 value [ length.UVALUE * 64 + 48 ]; 2355 } 2357 DEFAULT { 2358 length =:= static; 2359 next_header =:= static; 2360 value =:= static; 2361 } 2363 COMPRESSED hop_opt_static { 2364 next_header =:= irregular(8) [ 8 ]; 2365 length =:= irregular(8) [ 8 ]; 2366 } 2368 COMPRESSED hop_opt_dynamic { 2369 value =:= 2370 irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; 2371 } 2373 COMPRESSED hop_opt_irregular { 2374 } 2376 } 2378 //////////////////////////////////////////// 2379 // IPv6 Routing header 2380 //////////////////////////////////////////// 2382 ip_rout_opt 2383 { 2384 UNCOMPRESSED { 2385 next_header [ 8 ]; 2386 length [ 8 ]; 2387 value [ length.UVALUE * 64 + 48 ]; 2388 } 2390 DEFAULT { 2391 length =:= static; 2392 next_header =:= static; 2393 value =:= static; 2394 } 2396 COMPRESSED rout_opt_static { 2397 next_header =:= irregular(8) [ 8 ]; 2398 length =:= irregular(8) [ 8 ]; 2399 value =:= 2400 irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; 2401 } 2403 COMPRESSED rout_opt_dynamic { 2404 } 2406 COMPRESSED rout_opt_irregular { 2407 } 2409 } 2411 //////////////////////////////////////////// 2412 // GRE Header 2413 //////////////////////////////////////////// 2415 optional_lsb_7_or_31(flag) 2416 { 2417 UNCOMPRESSED { 2418 item [ 0, 32 ]; 2419 } 2421 COMPRESSED present { 2422 ENFORCE(flag == 1); 2423 item =:= lsb_7_or_31 [ 8, 32 ]; 2424 } 2426 COMPRESSED not_present { 2427 ENFORCE(flag == 0); 2428 item =:= compressed_value(0, 0) [ 0 ]; 2429 } 2430 } 2432 optional_checksum(flag_value) 2433 { 2434 UNCOMPRESSED { 2435 value [ 0, 16 ]; 2436 reserved1 [ 0, 16 ]; 2437 } 2439 COMPRESSED cs_present { 2440 ENFORCE(flag_value == 1); 2441 value =:= irregular(16) [ 16 ]; 2442 reserved1 =:= uncompressed_value(16, 0) [ 0 ]; 2443 } 2445 COMPRESSED not_present { 2446 ENFORCE(flag_value == 0); 2447 value =:= compressed_value(0, 0) [ 0 ]; 2448 reserved1 =:= compressed_value(0, 0) [ 0 ]; 2449 } 2450 } 2452 gre_proto 2453 { 2454 UNCOMPRESSED { 2455 protocol [ 16 ]; 2456 } 2457 COMPRESSED ether_v4 { 2458 discriminator =:= '0' [ 1 ]; 2459 protocol =:= uncompressed_value(16, 0x0800) [ 0 ]; 2460 } 2462 COMPRESSED ether_v6 { 2463 discriminator =:= '1' [ 1 ]; 2464 protocol =:= uncompressed_value(16, 0x86DD) [ 0 ]; 2465 } 2466 } 2468 gre 2469 { 2470 UNCOMPRESSED { 2471 c_flag [ 1 ]; 2472 r_flag =:= uncompressed_value(1, 0) [ 1 ]; 2473 k_flag [ 1 ]; 2474 s_flag [ 1 ]; 2475 reserved0 =:= uncompressed_value(9, 0) [ 9 ]; 2476 version =:= uncompressed_value(3, 0) [ 3 ]; 2477 protocol [ 16 ]; 2478 checksum_and_res [ 0, 32 ]; 2479 key [ 0, 32 ]; 2480 sequence_number [ 0, 32 ]; 2481 } 2483 DEFAULT { 2484 c_flag =:= static; 2485 k_flag =:= static; 2486 s_flag =:= static; 2487 protocol =:= static; 2488 key =:= static; 2489 sequence_number =:= static; 2490 } 2492 COMPRESSED gre_static { 2493 ENFORCE((c_flag.UVALUE == 1 && checksum_and_res.ULENGTH == 32) 2494 || checksum_and_res.ULENGTH == 0); 2495 ENFORCE((s_flag.UVALUE == 1 && sequence_number.ULENGTH == 32) 2496 || sequence_number.ULENGTH == 0); 2497 protocol =:= gre_proto [ 1 ]; 2498 c_flag =:= irregular(1) [ 1 ]; 2499 k_flag =:= irregular(1) [ 1 ]; 2500 s_flag =:= irregular(1) [ 1 ]; 2501 padding =:= compressed_value(4, 0) [ 4 ]; 2502 key =:= optional_32(k_flag.UVALUE) [ 0, 32 ]; 2503 } 2504 COMPRESSED gre_dynamic { 2505 checksum_and_res =:= 2506 optional_checksum(c_flag.UVALUE) [ 0, 16 ]; 2507 sequence_number =:= optional_32(s_flag.UVALUE) [ 0, 32 ]; 2508 } 2510 COMPRESSED gre_irregular { 2511 checksum_and_res =:= optional_checksum(c_flag.UVALUE) [ 0, 16 ]; 2512 sequence_number =:= 2513 optional_lsb_7_or_31(s_flag.UVALUE) [ 0, 8, 32 ]; 2514 } 2516 } 2518 ///////////////////////////////////////////// 2519 // MINE header 2520 ///////////////////////////////////////////// 2522 mine 2523 { 2524 UNCOMPRESSED { 2525 next_header [ 8 ]; 2526 s_bit [ 1 ]; 2527 res_bits [ 7 ]; 2528 checksum [ 16 ]; 2529 orig_dest [ 32 ]; 2530 orig_src [ 0, 32 ]; 2531 } 2533 DEFAULT { 2534 next_header =:= static; 2535 s_bit =:= static; 2536 res_bits =:= static; 2537 checksum =:= inferred_mine_header_checksum; 2538 orig_dest =:= static; 2539 orig_src =:= static; 2540 } 2542 COMPRESSED mine_static { 2543 next_header =:= irregular(8) [ 8 ]; 2544 s_bit =:= irregular(1) [ 1 ]; 2545 // Reserved bits are included to achieve byte-alignment 2546 res_bits =:= irregular(7) [ 7 ]; 2547 orig_dest =:= irregular(32) [ 32 ]; 2548 orig_src =:= optional_32(s_bit.UVALUE) [ 0, 32 ]; 2549 } 2551 COMPRESSED mine_dynamic { 2552 } 2554 COMPRESSED mine_irregular { 2555 } 2556 } 2558 ///////////////////////////////////////////// 2559 // Authentication Header (AH) 2560 ///////////////////////////////////////////// 2562 ah 2563 { 2564 UNCOMPRESSED { 2565 next_header [ 8 ]; 2566 length [ 8 ]; 2567 res_bits =:= uncompressed_value(16, 0) [ 16 ]; 2568 spi [ 32 ]; 2569 sequence_number [ 32 ]; 2570 icv [ length.UVALUE*32-32 ]; 2571 } 2573 DEFAULT { 2574 next_header =:= static; 2575 length =:= static; 2576 spi =:= static; 2577 sequence_number =:= static; 2578 } 2580 COMPRESSED ah_static { 2581 next_header =:= irregular(8) [ 8 ]; 2582 length =:= irregular(8) [ 8 ]; 2583 spi =:= irregular(32) [ 32 ]; 2584 } 2586 COMPRESSED ah_dynamic { 2587 sequence_number =:= irregular(32) [ 32 ]; 2588 icv =:= 2589 irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ]; 2590 } 2592 COMPRESSED ah_irregular { 2593 sequence_number =:= lsb_7_or_31 [ 8, 32 ]; 2594 icv =:= 2595 irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ]; 2596 } 2598 } 2599 ///////////////////////////////////////////// 2600 // IPv6 Header 2601 ///////////////////////////////////////////// 2603 fl_enc 2604 { 2605 UNCOMPRESSED { 2606 flow_label [ 20 ]; 2607 } 2609 COMPRESSED fl_zero { 2610 discriminator =:= '0' [ 1 ]; 2611 flow_label =:= uncompressed_value(20, 0) [ 0 ]; 2612 reserved =:= '0000' [ 4 ]; 2613 } 2615 COMPRESSED fl_non_zero { 2616 discriminator =:= '1' [ 1 ]; 2617 flow_label =:= irregular(20) [ 20 ]; 2618 } 2619 } 2621 ipv6(profile_value, is_innermost, outer_ip_flag, reorder_ratio_value) 2622 { 2623 UNCOMPRESSED { 2624 version =:= uncompressed_value(4, 6) [ 4 ]; 2625 tos_tc [ 8 ]; 2626 flow_label [ 20 ]; 2627 payload_length [ 16 ]; 2628 next_header [ 8 ]; 2629 ttl_hopl [ 8 ]; 2630 src_addr [ 128 ]; 2631 dst_addr [ 128 ]; 2632 } 2634 CONTROL { 2635 ENFORCE(profile == profile_value); 2636 ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value); 2637 ENFORCE(innermost_ip.UVALUE == is_innermost); 2638 innermost_ip [ 1 ]; 2639 } 2641 DEFAULT { 2642 tos_tc =:= static; 2643 flow_label =:= static; 2644 payload_length =:= inferred_ip_v6_length; 2645 next_header =:= static; 2646 ttl_hopl =:= static; 2647 src_addr =:= static; 2648 dst_addr =:= static; 2649 } 2651 COMPRESSED ipv6_static { 2652 version_flag =:= '1' [ 1 ]; 2653 innermost_ip =:= irregular(1) [ 1 ]; 2654 reserved =:= '0' [ 1 ]; 2655 flow_label =:= fl_enc [ 5, 21 ]; 2656 next_header =:= irregular(8) [ 8 ]; 2657 src_addr =:= irregular(128) [ 128 ]; 2658 dst_addr =:= irregular(128) [ 128 ]; 2659 } 2661 COMPRESSED ipv6_endpoint_dynamic { 2662 ENFORCE((is_innermost == 1) && 2663 (profile_value == PROFILE_IP_0104)); 2664 tos_tc =:= irregular(8) [ 8 ]; 2665 ttl_hopl =:= irregular(8) [ 8 ]; 2666 reserved =:= compressed_value(6, 0) [ 6 ]; 2667 reorder_ratio =:= irregular(2) [ 2 ]; 2668 msn =:= irregular(16) [ 16 ]; 2669 } 2671 COMPRESSED ipv6_regular_dynamic { 2672 ENFORCE((is_innermost == 0) || 2673 (profile_value != PROFILE_IP_0104)); 2674 tos_tc =:= irregular(8) [ 8 ]; 2675 ttl_hopl =:= irregular(8) [ 8 ]; 2676 } 2678 COMPRESSED ipv6_outer_irregular { 2679 ENFORCE(is_innermost == 0); 2680 tos_tc =:= 2681 static_or_irreg(outer_ip_flag, 8) [ 0, 8 ]; 2682 ttl_hopl =:= 2683 static_or_irreg(outer_ip_flag, 8) [ 0, 8 ]; 2684 } 2686 COMPRESSED ipv6_innermost_irregular { 2687 ENFORCE(is_innermost == 1); 2688 } 2690 } 2692 ///////////////////////////////////////////// 2693 // IPv4 Header 2694 ///////////////////////////////////////////// 2695 ip_id_enc_dyn(behavior) 2696 { 2697 UNCOMPRESSED { 2698 ip_id [ 16 ]; 2699 } 2701 COMPRESSED ip_id_seq { 2702 ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) || 2703 (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 2704 ENFORCE(ip_id_offset.UVALUE == ip_id.UVALUE - msn.UVALUE); 2705 ip_id =:= irregular(16) [ 16 ]; 2706 } 2708 COMPRESSED ip_id_random { 2709 ENFORCE(behavior == IP_ID_BEHAVIOR_RANDOM); 2710 ip_id =:= irregular(16) [ 16 ]; 2711 } 2713 COMPRESSED ip_id_zero { 2714 ENFORCE(behavior == IP_ID_BEHAVIOR_ZERO); 2715 ip_id =:= uncompressed_value(16, 0) [ 0 ]; 2716 } 2717 } 2719 ip_id_enc_irreg(behavior) 2720 { 2721 UNCOMPRESSED { 2722 ip_id [ 16 ]; 2723 } 2725 COMPRESSED ip_id_seq { 2726 ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL); 2727 } 2729 COMPRESSED ip_id_seq_swapped { 2730 ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED); 2731 } 2733 COMPRESSED ip_id_rand { 2734 ENFORCE(behavior == IP_ID_BEHAVIOR_RANDOM); 2735 ip_id =:= irregular(16) [ 16 ]; 2736 } 2738 COMPRESSED ip_id_zero { 2739 ENFORCE(behavior == IP_ID_BEHAVIOR_ZERO); 2740 ip_id =:= uncompressed_value(16, 0) [ 0 ]; 2741 } 2742 } 2743 ipv4(profile_value, is_innermost, outer_ip_flag, ip_id_behavior_value, 2744 reorder_ratio_value) 2745 { 2746 UNCOMPRESSED { 2747 version =:= uncompressed_value(4, 4) [ 4 ]; 2748 hdr_length =:= uncompressed_value(4, 5) [ 4 ]; 2749 tos_tc [ 8 ]; 2750 length =:= inferred_ip_v4_length [ 16 ]; 2751 ip_id [ 16 ]; 2752 rf =:= uncompressed_value(1, 0) [ 1 ]; 2753 df [ 1 ]; 2754 mf =:= uncompressed_value(1, 0) [ 1 ]; 2755 frag_offset =:= uncompressed_value(13, 0) [ 13 ]; 2756 ttl_hopl [ 8 ]; 2757 protocol [ 8 ]; 2758 checksum =:= inferred_ip_v4_header_checksum [ 16 ]; 2759 src_addr [ 32 ]; 2760 dst_addr [ 32 ]; 2761 } 2763 CONTROL { 2764 ENFORCE(profile == profile_value); 2765 ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value); 2766 ENFORCE(innermost_ip.UVALUE == is_innermost); 2767 ip_id_behavior_outer [ 2 ]; 2768 innermost_ip [ 1 ]; 2769 } 2771 DEFAULT { 2772 tos_tc =:= static; 2773 df =:= static; 2774 ttl_hopl =:= static; 2775 protocol =:= static; 2776 src_addr =:= static; 2777 dst_addr =:= static; 2778 ip_id_behavior_outer =:= static; 2779 } 2781 COMPRESSED ipv4_static { 2782 version_flag =:= '0' [ 1 ]; 2783 innermost_ip =:= irregular(1) [ 1 ]; 2784 reserved =:= '000000' [ 6 ]; 2785 protocol =:= irregular(8) [ 8 ]; 2786 src_addr =:= irregular(32) [ 32 ]; 2787 dst_addr =:= irregular(32) [ 32 ]; 2788 } 2790 COMPRESSED ipv4_endpoint_innermost_dynamic { 2791 ENFORCE((is_innermost == 1) && (profile_value == PROFILE_IP_0104)); 2792 ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value); 2793 reserved =:= '000' [ 3 ]; 2794 reorder_ratio =:= irregular(2) [ 2 ]; 2795 df =:= irregular(1) [ 1 ]; 2796 ip_id_behavior_innermost =:= irregular(2) [ 2 ]; 2797 tos_tc =:= irregular(8) [ 8 ]; 2798 ttl_hopl =:= irregular(8) [ 8 ]; 2799 ip_id =:= ip_id_enc_dyn(ip_id_behavior_innermost.UVALUE) [ 0, 16 ]; 2800 msn =:= irregular(16) [ 16 ]; 2801 } 2803 COMPRESSED ipv4_regular_innermost_dynamic { 2804 ENFORCE((is_innermost == 1) && (profile_value != PROFILE_IP_0104)); 2805 ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value); 2806 reserved =:= '00000' [ 5 ]; 2807 df =:= irregular(1) [ 1 ]; 2808 ip_id_behavior_innermost =:= irregular(2) [ 2 ]; 2809 tos_tc =:= irregular(8) [ 8 ]; 2810 ttl_hopl =:= irregular(8) [ 8 ]; 2811 ip_id =:= ip_id_enc_dyn(ip_id_behavior_innermost.UVALUE) [ 0, 16 ]; 2812 } 2814 COMPRESSED ipv4_outer_dynamic { 2815 ENFORCE(is_innermost == 0); 2816 ENFORCE(ip_id_behavior_outer.UVALUE == ip_id_behavior_value); 2817 reserved =:= '00000' [ 5 ]; 2818 df =:= irregular(1) [ 1 ]; 2819 ip_id_behavior_outer =:= irregular(2) [ 2 ]; 2820 tos_tc =:= irregular(8) [ 8 ]; 2821 ttl_hopl =:= irregular(8) [ 8 ]; 2822 ip_id =:= ip_id_enc_dyn(ip_id_behavior_outer.UVALUE) [ 0, 16 ]; 2823 } 2825 COMPRESSED ipv4_outer_irregular { 2826 ENFORCE(is_innermost == 0); 2827 ip_id =:= 2828 ip_id_enc_irreg(ip_id_behavior_outer.UVALUE) [ 0, 16 ]; 2829 tos_tc =:= static_or_irreg(outer_ip_flag, 8) [ 0, 8 ]; 2830 ttl_hopl =:= static_or_irreg(outer_ip_flag, 8) [ 0, 8 ]; 2831 } 2833 COMPRESSED ipv4_innermost_irregular { 2834 ENFORCE(is_innermost == 1); 2835 ip_id =:= 2836 ip_id_enc_irreg(ip_id_behavior_innermost.UVALUE) [ 0, 16 ]; 2837 } 2839 } 2841 ///////////////////////////////////////////// 2842 // UDP Header 2843 ///////////////////////////////////////////// 2845 udp(profile_value, reorder_ratio_value) 2846 { 2847 UNCOMPRESSED { 2848 ENFORCE((profile_value == PROFILE_RTP_0101) || 2849 (profile_value == PROFILE_UDP_0102)); 2850 src_port [ 16 ]; 2851 dst_port [ 16 ]; 2852 udp_length =:= inferred_udp_length [ 16 ]; 2853 checksum [ 16 ]; 2854 } 2856 CONTROL { 2857 ENFORCE(profile == profile_value); 2858 ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value); 2859 checksum_used [ 1 ]; 2860 } 2862 DEFAULT { 2863 src_port =:= static; 2864 dst_port =:= static; 2865 checksum_used =:= static; 2866 } 2868 COMPRESSED udp_static { 2869 src_port =:= irregular(16) [ 16 ]; 2870 dst_port =:= irregular(16) [ 16 ]; 2871 } 2873 COMPRESSED udp_endpoint_dynamic { 2874 ENFORCE(profile_value == PROFILE_UDP_0102); 2875 ENFORCE(profile == PROFILE_UDP_0102); 2876 ENFORCE(checksum_used.UVALUE == (checksum.UVALUE != 0)); 2877 checksum =:= irregular(16) [ 16 ]; 2878 msn =:= irregular(16) [ 16 ]; 2879 reserved =:= compressed_value(6, 0) [ 6 ]; 2880 reorder_ratio =:= irregular(2) [ 2 ]; 2881 } 2883 COMPRESSED udp_regular_dynamic { 2884 ENFORCE(profile_value == PROFILE_RTP_0101); 2885 ENFORCE(checksum_used.UVALUE == (checksum.UVALUE != 0)); 2886 checksum =:= irregular(16) [ 16 ]; 2888 } 2890 COMPRESSED udp_zero_checksum_irregular { 2891 ENFORCE(checksum_used.UVALUE == 0); 2892 checksum =:= uncompressed_value(16, 0) [ 0 ]; 2893 } 2895 COMPRESSED udp_with_checksum_irregular { 2896 ENFORCE(checksum_used.UVALUE == 1); 2897 checksum =:= irregular(16) [ 16 ]; 2898 } 2900 } 2902 ///////////////////////////////////////////// 2903 // RTP Header 2904 ///////////////////////////////////////////// 2906 csrc_list_dynchain(presence, cc_value) 2907 { 2908 UNCOMPRESSED { 2909 csrc_list; 2910 } 2912 COMPRESSED no_list { 2913 ENFORCE(cc_value == 0); 2914 ENFORCE(presence == 0); 2915 csrc_list =:= uncompressed_value(0, 0) [ 0 ]; 2916 } 2918 COMPRESSED list_present { 2919 ENFORCE(presence == 1); 2920 csrc_list =:= list_csrc(cc_value) [ VARIABLE ]; 2921 } 2922 } 2924 rtp(profile_value, ts_stride_value, time_stride_value, 2925 reorder_ratio_value) 2926 { 2927 UNCOMPRESSED { 2928 ENFORCE((profile_value == PROFILE_RTP_0101) || 2929 (profile_value == PROFILE_RTP_0107)); 2930 rtp_version =:= uncompressed_value(2, 0) [ 2 ]; 2931 pad_bit [ 1 ]; 2932 extension [ 1 ]; 2933 cc [ 4 ]; 2934 marker [ 1 ]; 2935 payload_type [ 7 ]; 2936 sequence_number [ 16 ]; 2937 timestamp [ 32 ]; 2938 ssrc [ 32 ]; 2939 csrc_list [ cc.UVALUE * 32 ]; 2940 } 2942 CONTROL { 2943 ENFORCE(profile == profile_value); 2944 ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value); 2945 ENFORCE(time_stride_value == time_stride.UVALUE); 2946 ENFORCE(ts_stride_value == ts_stride.UVALUE); 2947 dummy_field =:= field_scaling(ts_stride.UVALUE, 2948 ts_scaled.UVALUE, timestamp.UVALUE, ts_offset.UVALUE) [ 0 ]; 2949 } 2951 INITIAL { 2952 ts_stride =:= uncompressed_value(32, TS_STRIDE_DEFAULT); 2953 time_stride =:= uncompressed_value(32, TIME_STRIDE_DEFAULT); 2954 } 2956 DEFAULT { 2957 ENFORCE(msn.UVALUE == sequence_number.UVALUE); 2958 pad_bit =:= static; 2959 extension =:= static; 2960 cc =:= static; 2961 marker =:= static; 2962 payload_type =:= static; 2963 sequence_number =:= static; 2964 timestamp =:= static; 2965 ssrc =:= static; 2966 csrc_list =:= static; 2967 ts_stride =:= static; 2968 time_stride =:= static; 2969 ts_scaled =:= static; 2970 ts_offset =:= static; 2971 } 2973 COMPRESSED rtp_static { 2974 ssrc =:= irregular(32) [ 32 ]; 2975 } 2977 COMPRESSED rtp_dynamic { 2978 reserved =:= compressed_value(1, 0) [ 1 ]; 2979 reorder_ratio =:= irregular(2) [ 2 ]; 2980 list_present =:= irregular(1) [ 1 ]; 2981 tss_indicator =:= irregular(1) [ 1 ]; 2982 tis_indicator =:= irregular(1) [ 1 ]; 2983 pad_bit =:= irregular(1) [ 1 ]; 2984 extension =:= irregular(1) [ 1 ]; 2985 marker =:= irregular(1) [ 1 ]; 2986 payload_type =:= irregular(7) [ 7 ]; 2987 sequence_number =:= irregular(16) [ 16 ]; 2988 timestamp =:= irregular(32) [ 32 ]; 2989 ts_stride =:= sdvl_or_default(tss_indicator.CVALUE, 2990 TS_STRIDE_DEFAULT) [ VARIABLE ]; 2991 time_stride =:= sdvl_or_default(tis_indicator.CVALUE, 2992 TIME_STRIDE_DEFAULT) [ VARIABLE ]; 2993 csrc_list =:= csrc_list_dynchain(list_present.CVALUE, 2994 cc.UVALUE) [ VARIABLE ]; 2995 } 2997 COMPRESSED rtp_irregular { 2998 } 2999 } 3001 ///////////////////////////////////////////// 3002 // UDP-Lite Header 3003 ///////////////////////////////////////////// 3005 checksum_coverage_dynchain(behavior) 3006 { 3007 UNCOMPRESSED { 3008 checksum_coverage [ 16 ]; 3009 } 3011 COMPRESSED inferred_coverage { 3012 ENFORCE(behavior == UDP_LITE_COVERAGE_INFERRED); 3013 checksum_coverage =:= inferred_udp_length [ 0 ]; 3014 } 3016 COMPRESSED static_coverage { 3017 ENFORCE(behavior == UDP_LITE_COVERAGE_STATIC); 3018 checksum_coverage =:= irregular(16) [ 16 ]; 3019 } 3021 COMPRESSED irregular_coverage { 3022 ENFORCE(behavior == UDP_LITE_COVERAGE_IRREGULAR); 3023 checksum_coverage =:= irregular(16) [ 16 ]; 3024 } 3025 } 3027 checksum_coverage_irregular(behavior) 3028 { 3029 UNCOMPRESSED { 3030 checksum_coverage [ 16 ]; 3031 } 3032 COMPRESSED inferred_coverage { 3033 ENFORCE(behavior == UDP_LITE_COVERAGE_INFERRED); 3034 checksum_coverage =:= inferred_udp_length [ 0 ]; 3035 } 3037 COMPRESSED static_coverage { 3038 ENFORCE(behavior == UDP_LITE_COVERAGE_STATIC); 3039 checksum_coverage =:= static [ 0 ]; 3040 } 3042 COMPRESSED irregular_coverage { 3043 ENFORCE(behavior == UDP_LITE_COVERAGE_IRREGULAR); 3044 checksum_coverage =:= irregular(16) [ 16 ]; 3045 } 3046 } 3048 udp_lite(profile_value, reorder_ratio_value, coverage_behavior_value) 3049 { 3050 UNCOMPRESSED { 3051 ENFORCE((profile_value == PROFILE_RTP_0107) || 3052 (profile_value == PROFILE_UDPLITE_0108)); 3053 src_port [ 16 ]; 3054 dst_port [ 16 ]; 3055 checksum_coverage [ 16 ]; 3056 checksum [ 16 ]; 3057 } 3059 CONTROL { 3060 ENFORCE(profile == profile_value); 3061 ENFORCE(coverage_behavior.UVALUE == coverage_behavior_value); 3062 ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value); 3063 } 3065 DEFAULT { 3066 src_port =:= static; 3067 dst_port =:= static; 3068 coverage_behavior =:= static; 3069 } 3071 COMPRESSED udp_lite_static { 3072 src_port =:= irregular(16) [ 16 ]; 3073 dst_port =:= irregular(16) [ 16 ]; 3074 } 3076 COMPRESSED udp_lite_endpoint_dynamic { 3077 ENFORCE(profile_value == PROFILE_UDPLITE_0108); 3078 reserved =:= compressed_value(4, 0) [ 4 ]; 3079 coverage_behavior =:= irregular(2) [ 2 ]; 3080 reorder_ratio =:= irregular(2) [ 2 ]; 3081 checksum_coverage =:= 3082 checksum_coverage_dynchain(coverage_behavior.UVALUE) [ 16 ]; 3083 checksum =:= irregular(16) [ 16 ]; 3084 msn =:= irregular(16) [ 16 ]; 3085 } 3087 COMPRESSED udp_lite_regular_dynamic { 3088 ENFORCE(profile_value == PROFILE_RTP_0107); 3089 coverage_behavior =:= irregular(2) [ 2 ]; 3090 reserved =:= compressed_value(6, 0) [ 6 ]; 3091 checksum_coverage =:= 3092 checksum_coverage_dynchain(coverage_behavior.UVALUE) [ 16 ]; 3093 checksum =:= irregular(16) [ 16 ]; 3094 } 3096 COMPRESSED udp_lite_irregular { 3097 checksum_coverage =:= 3098 checksum_coverage_irregular(coverage_behavior.UVALUE) [ 0, 16 ]; 3099 checksum =:= irregular(16) [ 16 ]; 3100 } 3101 } 3103 ///////////////////////////////////////////// 3104 // ESP Header 3105 ///////////////////////////////////////////// 3107 esp(profile_value, reorder_ratio_value) 3108 { 3109 UNCOMPRESSED { 3110 ENFORCE(profile_value == PROFILE_ESP_0103); 3111 ENFORCE(msn.UVALUE == sequence_number.UVALUE % 65536); 3112 spi [ 32 ]; 3113 sequence_number [ 32 ]; 3114 } 3116 CONTROL { 3117 ENFORCE(profile == profile_value); 3118 ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value); 3119 } 3121 DEFAULT { 3122 spi =:= static; 3123 sequence_number =:= static; 3124 } 3126 COMPRESSED esp_static { 3127 spi =:= irregular(32) [ 32 ]; 3129 } 3131 COMPRESSED esp_dynamic { 3132 sequence_number =:= irregular(32) [ 32 ]; 3133 reserved =:= compressed_value(6, 0) [ 6 ]; 3134 reorder_ratio =:= irregular(2) [ 2 ]; 3135 } 3137 COMPRESSED esp_irregular { 3138 } 3139 } 3141 /////////////////////////////////////////////////// 3142 // Encoding methods used in the profiles' CO headers 3143 /////////////////////////////////////////////////// 3145 // Variable reordering offset used for MSN 3146 msn_lsb(k) 3147 { 3148 UNCOMPRESSED { 3149 master [ VARIABLE ]; 3150 } 3152 COMPRESSED none { 3153 ENFORCE(reorder_ratio.UVALUE == REORDERING_NONE); 3154 master =:= lsb(k, 1); 3155 } 3157 COMPRESSED quarter { 3158 ENFORCE(reorder_ratio.UVALUE == REORDERING_QUARTER); 3159 master =:= lsb(k, ((2^k) / 4) - 1); 3160 } 3162 COMPRESSED half { 3163 ENFORCE(reorder_ratio.UVALUE == REORDERING_HALF); 3164 master =:= lsb(k, ((2^k) / 2) - 1); 3165 } 3167 COMPRESSED threequarters { 3168 ENFORCE(reorder_ratio.UVALUE == REORDERING_THREEQUARTERS); 3169 master =:= lsb(k, (((2^k) * 3) / 4) - 1); 3170 } 3171 } 3173 ip_id_lsb(behavior, k) 3174 { 3175 UNCOMPRESSED { 3176 ip_id [ 16 ]; 3178 } 3180 CONTROL { 3181 ip_id_nbo [ 16 ]; 3182 } 3184 COMPRESSED nbo { 3185 ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL); 3186 ENFORCE(ip_id_offset.UVALUE == ip_id.UVALUE - msn.UVALUE); 3187 ip_id_offset =:= lsb(k, ((2^k) / 4) - 1) [ k ]; 3188 } 3190 COMPRESSED non_nbo { 3191 ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED); 3192 ENFORCE(ip_id_nbo.UVALUE == 3193 (ip_id.UVALUE / 256) + (ip_id.UVALUE % 256) * 256); 3194 ENFORCE(ip_id_nbo.ULENGTH == 16); 3195 ENFORCE(ip_id_offset.UVALUE == ip_id_nbo.UVALUE - msn.UVALUE); 3196 ip_id_offset =:= lsb(k, ((2^k) / 4) - 1) [ k ]; 3197 } 3198 } 3200 ip_id_sequential_variable(behavior, indicator) 3201 { 3202 UNCOMPRESSED { 3203 ip_id [ 16 ]; 3204 } 3206 COMPRESSED short { 3207 ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) || 3208 (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3209 ENFORCE(indicator == 0); 3210 ip_id =:= ip_id_lsb(behavior, 8) [ 8 ]; 3211 } 3213 COMPRESSED long { 3214 ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) || 3215 (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3216 ENFORCE(indicator == 1); 3217 ENFORCE(ip_id_offset.UVALUE == ip_id.UVALUE - msn.UVALUE); 3218 ip_id =:= irregular(16) [ 16 ]; 3219 } 3221 COMPRESSED not_present { 3222 ENFORCE((behavior == IP_ID_BEHAVIOR_RANDOM) || 3223 (behavior == IP_ID_BEHAVIOR_ZERO)); 3224 } 3225 } 3226 dont_fragment(version) 3227 { 3228 UNCOMPRESSED { 3229 df [ 0, 1 ]; 3230 } 3232 COMPRESSED v4 { 3233 ENFORCE(version == 4); 3234 df =:= irregular(1) [ 1 ]; 3235 } 3237 COMPRESSED v6 { 3238 ENFORCE(version == 6); 3239 unused =:= compressed_value(1, 0) [ 1 ]; 3240 } 3241 } 3243 pt_irr_or_static(flag) 3244 { 3245 UNCOMPRESSED { 3246 payload_type [ 7 ]; 3247 } 3249 COMPRESSED not_present { 3250 ENFORCE(flag == 0); 3251 payload_type =:= static [ 0 ]; 3252 } 3254 COMPRESSED present { 3255 ENFORCE(flag == 1); 3256 reserved =:= compressed_value(1, 0) [ 1 ]; 3257 payload_type =:= irregular(7) [ 7 ]; 3258 } 3259 } 3261 csrc_list_presence(presence, cc_value) 3262 { 3263 UNCOMPRESSED { 3264 csrc_list; 3265 } 3267 COMPRESSED no_list { 3268 ENFORCE(presence == 0); 3269 csrc_list =:= static [ 0 ]; 3270 } 3272 COMPRESSED list_present { 3273 ENFORCE(presence == 1); 3274 csrc_list =:= list_csrc(cc_value) [ VARIABLE ]; 3275 } 3276 } 3278 scaled_ts_lsb(time_stride_value, k) 3279 { 3280 UNCOMPRESSED { 3281 timestamp [ 32 ]; 3282 } 3284 COMPRESSED timerbased { 3285 ENFORCE(time_stride_value != 0); 3286 timestamp =:= timer_based_lsb(time_stride_value, k, 3287 ((2^k) / 2) - 1); 3288 } 3290 COMPRESSED regular { 3291 ENFORCE(time_stride_value == 0); 3292 timestamp =:= lsb(k, ((2^k) / 4) - 1); 3293 } 3294 } 3296 // Self-describing variable length encoding with reordering offset 3297 sdvl_sn_lsb(field_width) 3298 { 3299 UNCOMPRESSED { 3300 field [ field_width ]; 3301 } 3303 COMPRESSED lsb7 { 3304 discriminator =:= '0' [ 1 ]; 3305 field =:= msn_lsb(7) [ 7 ]; 3306 } 3308 COMPRESSED lsb14 { 3309 discriminator =:= '10' [ 2 ]; 3310 field =:= msn_lsb(14) [ 14 ]; 3311 } 3313 COMPRESSED lsb21 { 3314 discriminator =:= '110' [ 3 ]; 3315 field =:= msn_lsb(21) [ 21 ]; 3316 } 3318 COMPRESSED lsb28 { 3319 discriminator =:= '1110' [ 4 ]; 3320 field =:= msn_lsb(28) [ 28 ]; 3321 } 3322 COMPRESSED lsb32 { 3323 discriminator =:= '11111111' [ 8 ]; 3324 field =:= irregular(field_width) [ field_width ]; 3325 } 3326 } 3328 // Self-describing variable length encoding 3329 sdvl_lsb(field_width) 3330 { 3331 UNCOMPRESSED { 3332 field [ field_width ]; 3333 } 3335 COMPRESSED lsb7 { 3336 discriminator =:= '0' [ 1 ]; 3337 field =:= lsb(7, ((2^7) / 4) - 1) [ 7 ]; 3338 } 3340 COMPRESSED lsb14 { 3341 discriminator =:= '10' [ 2 ]; 3342 field =:= lsb(14, ((2^14) / 4) - 1) [ 14 ]; 3343 } 3345 COMPRESSED lsb21 { 3346 discriminator =:= '110' [ 3 ]; 3347 field =:= lsb(21, ((2^21) / 4) - 1) [ 21 ]; 3348 } 3350 COMPRESSED lsb28 { 3351 discriminator =:= '1110' [ 4 ]; 3352 field =:= lsb(28, ((2^28) / 4) - 1) [ 28 ]; 3353 } 3355 COMPRESSED lsb32 { 3356 discriminator =:= '11111111' [ 8 ]; 3357 field =:= irregular(field_width) [ field_width ]; 3358 } 3359 } 3361 sdvl_scaled_ts_lsb(time_stride) 3362 { 3363 UNCOMPRESSED { 3364 field [ 32 ]; 3365 } 3367 COMPRESSED lsb7 { 3368 discriminator =:= '0' [ 1 ]; 3369 field =:= scaled_ts_lsb(time_stride, 7) [ 7 ]; 3371 } 3373 COMPRESSED lsb14 { 3374 discriminator =:= '10' [ 2 ]; 3375 field =:= scaled_ts_lsb(time_stride, 14) [ 14 ]; 3376 } 3378 COMPRESSED lsb21 { 3379 discriminator =:= '110' [ 3 ]; 3380 field =:= scaled_ts_lsb(time_stride, 21) [ 21 ]; 3381 } 3383 COMPRESSED lsb28 { 3384 discriminator =:= '1110' [ 4 ]; 3385 field =:= scaled_ts_lsb(time_stride, 28) [ 28 ]; 3386 } 3388 COMPRESSED lsb32 { 3389 discriminator =:= '11111111' [ 8 ]; 3390 field =:= irregular(32) [ 32 ]; 3391 } 3392 } 3394 variable_scaled_timestamp(tss_flag, tsc_flag, ts_stride, time_stride) 3395 { 3396 UNCOMPRESSED { 3397 scaled_value [ 32 ]; 3398 } 3400 COMPRESSED present { 3401 ENFORCE((tss_flag == 0) && (tsc_flag == 1)); 3402 ENFORCE(ts_stride != 0); 3403 scaled_value =:= sdvl_scaled_ts_lsb(time_stride) [ VARIABLE ]; 3404 } 3406 COMPRESSED not_present { 3407 ENFORCE(((tss_flag == 1) && (tsc_flag == 0)) || 3408 ((tss_flag == 0) && (tsc_flag == 0))); 3409 } 3410 } 3412 variable_unscaled_timestamp(tss_flag, tsc_flag) 3413 { 3414 UNCOMPRESSED { 3415 timestamp [ 32 ]; 3416 } 3418 COMPRESSED present { 3419 ENFORCE(((tss_flag == 1) && (tsc_flag == 0)) || 3420 ((tss_flag == 0) && (tsc_flag == 0))); 3421 timestamp =:= sdvl_lsb(32); 3422 } 3424 COMPRESSED not_present { 3425 ENFORCE((tss_flag == 0) && (tsc_flag == 1)); 3426 } 3427 } 3429 profile_1_7_flags1_enc(flag, ip_version) 3430 { 3431 UNCOMPRESSED { 3432 ip_outer_indicator [ 1 ]; 3433 ttl_hopl_indicator [ 1 ]; 3434 tos_tc_indicator [ 1 ]; 3435 df [ 0, 1 ]; 3436 ip_id_behavior [ 2 ]; 3437 reorder_ratio [ 2 ]; 3438 } 3440 COMPRESSED not_present { 3441 ENFORCE(flag == 0); 3442 ENFORCE(ip_outer_indicator.CVALUE == 0); 3443 ENFORCE(ttl_hopl_indicator.CVALUE == 0); 3444 ENFORCE(tos_tc_indicator.CVALUE == 0); 3445 df =:= static; 3446 ip_id_behavior =:= static; 3447 reorder_ratio =:= static; 3448 } 3450 COMPRESSED present { 3451 ENFORCE(flag == 1); 3452 ip_outer_indicator =:= irregular(1) [ 1 ]; 3453 ttl_hopl_indicator =:= irregular(1) [ 1 ]; 3454 tos_tc_indicator =:= irregular(1) [ 1 ]; 3455 df =:= dont_fragment(ip_version) [ 1 ]; 3456 ip_id_behavior =:= irregular(2) [ 2 ]; 3457 reorder_ratio =:= irregular(2) [ 2 ]; 3458 } 3459 } 3461 profile_1_flags2_enc(flag) 3462 { 3463 UNCOMPRESSED { 3464 list_indicator [ 1 ]; 3465 pt_indicator [ 1 ]; 3466 time_stride_indicator [ 1 ]; 3467 pad_bit [ 1 ]; 3468 extension [ 1 ]; 3469 } 3471 COMPRESSED not_present{ 3472 ENFORCE(flag == 0); 3473 ENFORCE(list_indicator.UVALUE == 0); 3474 ENFORCE(pt_indicator.UVALUE == 0); 3475 ENFORCE(time_stride_indicator.UVALUE == 0); 3476 pad_bit =:= static; 3477 extension =:= static; 3478 } 3480 COMPRESSED present { 3481 ENFORCE(flag == 1); 3482 list_indicator =:= irregular(1) [ 1 ]; 3483 pt_indicator =:= irregular(1) [ 1 ]; 3484 time_stride_indicator =:= irregular(1) [ 1 ]; 3485 pad_bit =:= irregular(1) [ 1 ]; 3486 extension =:= irregular(1) [ 1 ]; 3487 reserved =:= compressed_value(3, 0) [ 3 ]; 3488 } 3489 } 3491 profile_2_3_4_flags_enc(flag, ip_version) 3492 { 3493 UNCOMPRESSED { 3494 ip_outer_indicator [ 1 ]; 3495 df [ 0, 1 ]; 3496 ip_id_behavior [ 2 ]; 3497 } 3499 COMPRESSED not_present { 3500 ENFORCE(flag == 0); 3501 ENFORCE(ip_outer_indicator.CVALUE == 0); 3502 df =:= static; 3503 ip_id_behavior =:= static; 3504 } 3506 COMPRESSED present { 3507 ENFORCE(flag == 1); 3508 ip_outer_indicator =:= irregular(1) [ 1 ]; 3509 df =:= dont_fragment(ip_version) [ 1 ]; 3510 ip_id_behavior =:= irregular(2) [ 2 ]; 3511 reserved =:= compressed_value(4, 0) [ 4 ]; 3512 } 3513 } 3514 profile_8_flags_enc(flag, ip_version) 3515 { 3516 UNCOMPRESSED { 3517 ip_outer_indicator [ 1 ]; 3518 df [ 0, 1 ]; 3519 ip_id_behavior [ 2 ]; 3520 coverage_behavior [ 2 ]; 3521 } 3523 COMPRESSED not_present { 3524 ENFORCE(flag == 0); 3525 ENFORCE(ip_outer_indicator.CVALUE == 0); 3526 df =:= static; 3527 ip_id_behavior =:= static; 3528 coverage_behavior =:= static; 3529 } 3531 COMPRESSED present { 3532 ENFORCE(flag == 1); 3533 reserved =:= compressed_value(2, 0) [ 2 ]; 3534 ip_outer_indicator =:= irregular(1) [ 1 ]; 3535 df =:= dont_fragment(ip_version) [ 1 ]; 3536 ip_id_behavior =:= irregular(2) [ 2 ]; 3537 coverage_behavior =:= irregular(2) [ 2 ]; 3538 } 3539 } 3541 profile_7_flags2_enc(flag) 3542 { 3543 UNCOMPRESSED { 3544 list_indicator [ 1 ]; 3545 pt_indicator [ 1 ]; 3546 time_stride_indicator [ 1 ]; 3547 pad_bit [ 1 ]; 3548 extension [ 1 ]; 3549 coverage_behavior [ 2 ]; 3550 } 3552 COMPRESSED not_present{ 3553 ENFORCE(flag == 0); 3554 ENFORCE(list_indicator.CVALUE == 0); 3555 ENFORCE(pt_indicator.CVALUE == 0); 3556 ENFORCE(time_stride_indicator.CVALUE == 0); 3557 pad_bit =:= static; 3558 extension =:= static; 3559 coverage_behavior =:= static; 3560 } 3561 COMPRESSED present { 3562 ENFORCE(flag == 1); 3563 reserved =:= compressed_value(1, 0) [ 1 ]; 3564 list_indicator =:= irregular(1) [ 1 ]; 3565 pt_indicator =:= irregular(1) [ 1 ]; 3566 time_stride_indicator =:= irregular(1) [ 1 ]; 3567 pad_bit =:= irregular(1) [ 1 ]; 3568 extension =:= irregular(1) [ 1 ]; 3569 coverage_behavior =:= irregular(2) [ 2 ]; 3570 } 3571 } 3573 //////////////////////////////////////////// 3574 // RTP profile 3575 //////////////////////////////////////////// 3577 rtp_baseheader(profile_value, ts_stride_value, time_stride_value, 3578 outer_ip_flag, ip_id_behavior_value, 3579 reorder_ratio_value) 3580 { 3581 UNCOMPRESSED v4 { 3582 ENFORCE(msn.UVALUE == sequence_number.UVALUE); 3583 outer_headers =:= baseheader_outer_headers [ VARIABLE ]; 3584 ip_version =:= uncompressed_value(4, 4) [ 4 ]; 3585 header_length =:= uncompressed_value(4, 5) [ 4 ]; 3586 tos_tc [ 8 ]; 3587 length =:= inferred_ip_v4_length [ 16 ]; 3588 ip_id [ 16 ]; 3589 rf =:= uncompressed_value(1, 0) [ 1 ]; 3590 df [ 1 ]; 3591 mf =:= uncompressed_value(1, 0) [ 1 ]; 3592 frag_offset =:= uncompressed_value(13, 0) [ 13 ]; 3593 ttl_hopl [ 8 ]; 3594 next_header [ 8 ]; 3595 ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ]; 3596 src_addr [ 32 ]; 3597 dest_addr [ 32 ]; 3598 extension_headers =:= baseheader_extension_headers [ VARIABLE ]; 3599 src_port [ 16 ]; 3600 dst_port [ 16 ]; 3601 udp_length =:= inferred_udp_length [ 16 ]; 3602 udp_checksum [ 16 ]; 3603 rtp_version =:= uncompressed_value(2, 2) [ 2 ]; 3604 pad_bit [ 1 ]; 3605 extension [ 1 ]; 3606 cc [ 4 ]; 3607 marker [ 1 ]; 3608 payload_type [ 7 ]; 3609 sequence_number [ 16 ]; 3610 timestamp [ 32 ]; 3611 ssrc [ 32 ]; 3612 csrc_list [ VARIABLE ]; 3613 } 3615 UNCOMPRESSED v6 { 3616 ENFORCE(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_RANDOM); 3617 ENFORCE(msn.UVALUE == sequence_number.UVALUE); 3618 outer_headers =:= baseheader_outer_headers [ VARIABLE ]; 3619 ip_version =:= uncompressed_value(4, 6) [ 4 ]; 3620 tos_tc [ 8 ]; 3621 flow_label [ 20 ]; 3622 payload_length =:= inferred_ip_v6_length [ 16 ]; 3623 next_header [ 8 ]; 3624 ttl_hopl [ 8 ]; 3625 src_addr [ 128 ]; 3626 dest_addr [ 128 ]; 3627 extension_headers =:= baseheader_extension_headers [ VARIABLE ]; 3628 src_port [ 16 ]; 3629 dst_port [ 16 ]; 3630 udp_length =:= inferred_udp_length [ 16 ]; 3631 udp_checksum [ 16 ]; 3632 rtp_version =:= uncompressed_value(2, 2) [ 2 ]; 3633 pad_bit [ 1 ]; 3634 extension [ 1 ]; 3635 cc [ 4 ]; 3636 marker [ 1 ]; 3637 payload_type [ 7 ]; 3638 sequence_number [ 16 ]; 3639 timestamp [ 32 ]; 3640 ssrc [ 32 ]; 3641 csrc_list [ VARIABLE ]; 3642 df =:= uncompressed_value(0,0) [ 0 ]; 3643 ip_id =:= uncompressed_value(0,0) [ 0 ]; 3644 } 3646 CONTROL { 3647 ENFORCE(profile_value == PROFILE_RTP_0101); 3648 ENFORCE(profile == profile_value); 3649 ENFORCE(time_stride.UVALUE == time_stride_value); 3650 ENFORCE(ts_stride.UVALUE == ts_stride_value); 3651 ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value); 3652 ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value); 3653 dummy_field =:= field_scaling(ts_stride.UVALUE, 3654 ts_scaled.UVALUE, timestamp.UVALUE, ts_offset.UVALUE) [ 0 ]; 3655 } 3656 INITIAL { 3657 ts_stride =:= uncompressed_value(32, TS_STRIDE_DEFAULT); 3658 time_stride =:= uncompressed_value(32, TIME_STRIDE_DEFAULT); 3659 } 3661 DEFAULT { 3662 ENFORCE(outer_ip_flag == 0); 3663 tos_tc =:= static; 3664 dest_addr =:= static; 3665 ttl_hopl =:= static; 3666 src_addr =:= static; 3667 df =:= static; 3668 flow_label =:= static; 3669 next_header =:= static; 3670 src_port =:= static; 3671 dst_port =:= static; 3672 pad_bit =:= static; 3673 extension =:= static; 3674 cc =:= static; 3675 // When marker not present in packets, it is assumed 0 3676 marker =:= uncompressed_value(1, 0); 3677 payload_type =:= static; 3678 sequence_number =:= static; 3679 timestamp =:= static; 3680 ssrc =:= static; 3681 csrc_list =:= static; 3682 ts_stride =:= static; 3683 time_stride =:= static; 3684 ts_scaled =:= static; 3685 ts_offset =:= static; 3686 reorder_ratio =:= static; 3687 ip_id_behavior_innermost =:= static; 3688 } 3690 // Replacement for UOR-2-ext3 3691 COMPRESSED co_common { 3692 ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE); 3693 discriminator =:= '11111010' [ 8 ]; 3694 marker =:= irregular(1) [ 1 ]; 3695 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 3696 flags1_indicator =:= irregular(1) [ 1 ]; 3697 flags2_indicator =:= irregular(1) [ 1 ]; 3698 tsc_indicator =:= irregular(1) [ 1 ]; 3699 tss_indicator =:= irregular(1) [ 1 ]; 3700 ip_id_indicator =:= irregular(1) [ 1 ]; 3701 control_crc3 =:= control_crc3_encoding [ 3 ]; 3703 outer_ip_indicator : ttl_hopl_indicator : 3705 tos_tc_indicator : df : ip_id_behavior_innermost : reorder_ratio 3706 =:= profile_1_7_flags1_enc(flags1_indicator.CVALUE, 3707 ip_version.UVALUE) [ 0, 8 ]; 3708 list_indicator : pt_indicator : tis_indicator : pad_bit : 3709 extension =:= profile_1_flags2_enc( 3710 flags2_indicator.CVALUE) [ 0, 8 ]; 3711 tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ]; 3712 ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE, 3713 ttl_hopl.ULENGTH) [ 0, 8 ]; 3714 payload_type =:= pt_irr_or_static(pt_indicator) [ 0, 8 ]; 3715 sequence_number =:= 3716 sdvl_sn_lsb(sequence_number.ULENGTH) [ VARIABLE ]; 3717 ip_id =:= ip_id_sequential_variable( 3718 ip_id_behavior_innermost.UVALUE, 3719 ip_id_indicator.CVALUE) [ 0, 8, 16 ]; 3720 ts_scaled =:= variable_scaled_timestamp(tss_indicator.CVALUE, 3721 tsc_indicator.CVALUE, ts_stride.UVALUE, 3722 time_stride.UVALUE) [ VARIABLE ]; 3723 timestamp =:= variable_unscaled_timestamp(tss_indicator.CVALUE, 3724 tsc_indicator.CVALUE) [ VARIABLE ]; 3725 ts_stride =:= sdvl_or_static(tss_indicator.CVALUE) [ VARIABLE ]; 3726 time_stride =:= sdvl_or_static(tis_indicator.CVALUE) [ VARIABLE ]; 3727 csrc_list =:= csrc_list_presence(list_indicator.CVALUE, 3728 cc.UVALUE) [ VARIABLE ]; 3729 } 3731 // UO-0 3732 COMPRESSED pt_0_crc3 { 3733 discriminator =:= '0' [ 1 ]; 3734 msn =:= msn_lsb(4) [ 4 ]; 3735 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3736 timestamp =:= inferred_scaled_field [ 0 ]; 3737 ip_id =:= inferred_sequential_ip_id [ 0 ]; 3738 } 3740 // New format, Type 0 with strong CRC and more SN bits 3741 COMPRESSED pt_0_crc7 { 3742 discriminator =:= '1000' [ 4 ]; 3743 msn =:= msn_lsb(5) [ 5 ]; 3744 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 3745 timestamp =:= inferred_scaled_field [ 0 ]; 3746 ip_id =:= inferred_sequential_ip_id [ 0 ]; 3747 } 3749 // UO-1 replacement 3750 COMPRESSED pt_1_rnd { 3751 ENFORCE(ts_stride.UVALUE != 0); 3752 ENFORCE((ip_id_behavior_innermost.UVALUE == 3753 IP_ID_BEHAVIOR_RANDOM) || 3754 (ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO)); 3755 discriminator =:= '101' [ 3 ]; 3756 marker =:= irregular(1) [ 1 ]; 3757 msn =:= msn_lsb(4) [ 4 ]; 3758 ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 5) [ 5 ]; 3759 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3760 } 3762 // UO-1-ID replacement 3763 COMPRESSED pt_1_seq_id { 3764 ENFORCE((ip_id_behavior_innermost.UVALUE == 3765 IP_ID_BEHAVIOR_SEQUENTIAL) || 3766 (ip_id_behavior_innermost.UVALUE == 3767 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3768 discriminator =:= '1001' [ 4 ]; 3769 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4) [ 4 ]; 3770 msn =:= msn_lsb(5) [ 5 ]; 3771 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3772 timestamp =:= inferred_scaled_field [ 0 ]; 3773 } 3775 // UO-1-TS replacement 3776 COMPRESSED pt_1_seq_ts { 3777 ENFORCE(ts_stride.UVALUE != 0); 3778 ENFORCE((ip_id_behavior_innermost.UVALUE == 3779 IP_ID_BEHAVIOR_SEQUENTIAL) || 3780 (ip_id_behavior_innermost.UVALUE == 3781 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3782 discriminator =:= '101' [ 3 ]; 3783 marker =:= irregular(1) [ 1 ]; 3784 msn =:= msn_lsb(4) [ 4 ]; 3785 ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 5) [ 5 ]; 3786 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3787 ip_id =:= inferred_sequential_ip_id [ 0 ]; 3788 } 3790 // UOR-2 replacement 3791 COMPRESSED pt_2_rnd { 3792 ENFORCE(ts_stride.UVALUE != 0); 3793 ENFORCE((ip_id_behavior_innermost.UVALUE == 3794 IP_ID_BEHAVIOR_RANDOM) || 3795 (ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO)); 3796 discriminator =:= '110' [ 3 ]; 3797 msn =:= msn_lsb(7) [ 7 ]; 3798 ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 6) [ 6 ]; 3799 marker =:= irregular(1) [ 1 ]; 3800 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 3802 } 3804 // UOR-2-ID replacement 3805 COMPRESSED pt_2_seq_id { 3806 ENFORCE((ip_id_behavior_innermost.UVALUE == 3807 IP_ID_BEHAVIOR_SEQUENTIAL) || 3808 (ip_id_behavior_innermost.UVALUE == 3809 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3810 discriminator =:= '11000' [ 5 ]; 3811 msn =:= msn_lsb(7) [ 7 ]; 3812 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 5) [ 5 ]; 3813 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 3814 timestamp =:= inferred_scaled_field [ 0 ]; 3815 } 3817 // UOR-2-ID-ext1 replacement (both TS and IP-ID) 3818 COMPRESSED pt_2_seq_both { 3819 ENFORCE(ts_stride.UVALUE != 0); 3820 ENFORCE((ip_id_behavior_innermost.UVALUE == 3821 IP_ID_BEHAVIOR_SEQUENTIAL) || 3822 (ip_id_behavior_innermost.UVALUE == 3823 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3824 discriminator =:= '11001' [ 5 ]; 3825 msn =:= msn_lsb(7) [ 7 ]; 3826 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 5) [ 5 ]; 3827 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 3828 ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 7) [ 7 ]; 3829 marker =:= irregular(1) [ 1 ]; 3830 } 3832 // UOR-2-TS replacement 3833 COMPRESSED pt_2_seq_ts { 3834 ENFORCE(ts_stride.UVALUE != 0); 3835 ENFORCE((ip_id_behavior_innermost.UVALUE == 3836 IP_ID_BEHAVIOR_SEQUENTIAL) || 3837 (ip_id_behavior_innermost.UVALUE == 3838 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3839 discriminator =:= '1101' [ 4 ]; 3840 msn =:= msn_lsb(7) [ 7 ]; 3841 ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 5) [ 5 ]; 3842 marker =:= irregular(1) [ 1 ]; 3843 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 3844 ip_id =:= inferred_sequential_ip_id [ 0 ]; 3845 } 3846 } 3848 //////////////////////////////////////////// 3849 // UDP profile 3850 //////////////////////////////////////////// 3852 udp_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value, 3853 reorder_ratio_value) 3854 { 3855 UNCOMPRESSED v4 { 3856 outer_headers =:= baseheader_outer_headers [ VARIABLE ]; 3857 ip_version =:= uncompressed_value(4, 4) [ 4 ]; 3858 header_length =:= uncompressed_value(4, 5) [ 4 ]; 3859 tos_tc [ 8 ]; 3860 length =:= inferred_ip_v4_length [ 16 ]; 3861 ip_id [ 16 ]; 3862 rf =:= uncompressed_value(1, 0) [ 1 ]; 3863 df [ 1 ]; 3864 mf =:= uncompressed_value(1, 0) [ 1 ]; 3865 frag_offset =:= uncompressed_value(13, 0) [ 13 ]; 3866 ttl_hopl [ 8 ]; 3867 next_header [ 8 ]; 3868 ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ]; 3869 src_addr [ 32 ]; 3870 dest_addr [ 32 ]; 3871 extension_headers =:= baseheader_extension_headers [ VARIABLE ]; 3872 src_port [ 16 ]; 3873 dst_port [ 16 ]; 3874 udp_length =:= inferred_udp_length [ 16 ]; 3875 udp_checksum [ 16 ]; 3876 } 3878 UNCOMPRESSED v6 { 3879 ENFORCE(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM); 3880 outer_headers =:= baseheader_outer_headers [ VARIABLE ]; 3881 ip_version =:= uncompressed_value(4, 6) [ 4 ]; 3882 tos_tc [ 8 ]; 3883 flow_label [ 20 ]; 3884 payload_length =:= inferred_ip_v6_length [ 16 ]; 3885 next_header [ 8 ]; 3886 ttl_hopl [ 8 ]; 3887 src_addr [ 128 ]; 3888 dest_addr [ 128 ]; 3889 extension_headers =:= baseheader_extension_headers [ VARIABLE ]; 3890 src_port [ 16 ]; 3891 dst_port [ 16 ]; 3892 udp_length =:= inferred_udp_length [ 16 ]; 3893 udp_checksum [ 16 ]; 3894 df =:= uncompressed_value(0,0) [ 0 ]; 3895 ip_id =:= uncompressed_value(0,0) [ 0 ]; 3896 } 3897 CONTROL { 3898 ENFORCE(profile_value == PROFILE_UDP_0102); 3899 ENFORCE(profile == profile_value); 3900 ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value); 3901 ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value); 3902 } 3904 DEFAULT { 3905 ENFORCE(outer_ip_flag == 0); 3906 tos_tc =:= static; 3907 dest_addr =:= static; 3908 ip_version =:= static; 3909 ttl_hopl =:= static; 3910 src_addr =:= static; 3911 df =:= static; 3912 flow_label =:= static; 3913 next_header =:= static; 3914 src_port =:= static; 3915 dst_port =:= static; 3916 reorder_ratio =:= static; 3917 ip_id_behavior_innermost =:= static; 3918 } 3920 // Replacement for UOR-2-ext3 3921 COMPRESSED co_common { 3922 ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE); 3923 discriminator =:= '11111010' [ 8 ]; 3924 ip_id_indicator =:= irregular(1) [ 1 ]; 3925 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 3926 flags_indicator =:= irregular(1) [ 1 ]; 3927 ttl_hopl_indicator =:= irregular(1) [ 1 ]; 3928 tos_tc_indicator =:= irregular(1) [ 1 ]; 3929 reorder_ratio =:= irregular(2) [ 2 ]; 3930 control_crc3 =:= control_crc3_encoding [ 3 ]; 3931 outer_ip_indicator : df : ip_id_behavior_innermost =:= 3932 profile_2_3_4_flags_enc( 3933 flags_indicator.CVALUE, ip_version.UVALUE) [ 0, 8 ]; 3934 tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ]; 3935 ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE, 3936 ttl_hopl.ULENGTH) [ 0, 8 ]; 3937 msn =:= msn_lsb(8) [ 8 ]; 3938 ip_id =:= ip_id_sequential_variable(ip_id_behavior_innermost.UVALUE, 3939 ip_id_indicator.CVALUE) [ 0, 8, 16 ]; 3940 } 3942 // UO-0 3943 COMPRESSED pt_0_crc3 { 3944 discriminator =:= '0' [ 1 ]; 3945 msn =:= msn_lsb(4) [ 4 ]; 3946 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3947 ip_id =:= inferred_sequential_ip_id [ 0 ]; 3948 } 3950 // New format, Type 0 with strong CRC and more SN bits 3951 COMPRESSED pt_0_crc7 { 3952 discriminator =:= '100' [ 3 ]; 3953 msn =:= msn_lsb(6) [ 6 ]; 3954 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 3955 ip_id =:= inferred_sequential_ip_id [ 0 ]; 3956 } 3958 // UO-1-ID replacement (PT-1 only used for sequential) 3959 COMPRESSED pt_1_seq_id { 3960 ENFORCE((ip_id_behavior_innermost.UVALUE == 3961 IP_ID_BEHAVIOR_SEQUENTIAL) || 3962 (ip_id_behavior_innermost.UVALUE == 3963 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3964 discriminator =:= '101' [ 3 ]; 3965 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 3966 msn =:= msn_lsb(6) [ 6 ]; 3967 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4) [ 4 ]; 3968 } 3970 // UOR-2-ID replacement 3971 COMPRESSED pt_2_seq_id { 3972 ENFORCE((ip_id_behavior_innermost.UVALUE == 3973 IP_ID_BEHAVIOR_SEQUENTIAL) || 3974 (ip_id_behavior_innermost.UVALUE == 3975 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 3976 discriminator =:= '110' [ 3 ]; 3977 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 6) [ 6 ]; 3978 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 3979 msn =:= msn_lsb(8) [ 8 ]; 3980 } 3981 } 3983 //////////////////////////////////////////// 3984 // ESP profile 3985 //////////////////////////////////////////// 3987 esp_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value, 3988 reorder_ratio_value) 3989 { 3990 UNCOMPRESSED v4 { 3991 ENFORCE(msn.UVALUE == sequence_number.UVALUE % 65536); 3992 outer_headers =:= baseheader_outer_headers [ VARIABLE ]; 3993 ip_version =:= uncompressed_value(4, 4) [ 4 ]; 3994 header_length =:= uncompressed_value(4, 5) [ 4 ]; 3995 tos_tc [ 8 ]; 3996 length =:= inferred_ip_v4_length [ 16 ]; 3997 ip_id [ 16 ]; 3998 rf =:= uncompressed_value(1, 0) [ 1 ]; 3999 df [ 1 ]; 4000 mf =:= uncompressed_value(1, 0) [ 1 ]; 4001 frag_offset =:= uncompressed_value(13, 0) [ 13 ]; 4002 ttl_hopl [ 8 ]; 4003 next_header [ 8 ]; 4004 ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ]; 4005 src_addr [ 32 ]; 4006 dest_addr [ 32 ]; 4007 extension_headers =:= baseheader_extension_headers [ VARIABLE ]; 4008 spi [ 32 ]; 4009 sequence_number [ 32 ]; 4010 } 4012 UNCOMPRESSED v6 { 4013 ENFORCE(msn.UVALUE == (sequence_number.UVALUE % 65536)); 4014 ENFORCE(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_RANDOM); 4015 outer_headers =:= baseheader_outer_headers [ VARIABLE ]; 4016 ip_version =:= uncompressed_value(4, 6) [ 4 ]; 4017 tos_tc [ 8 ]; 4018 flow_label [ 20 ]; 4019 payload_length =:= inferred_ip_v6_length [ 16 ]; 4020 next_header [ 8 ]; 4021 ttl_hopl [ 8 ]; 4022 src_addr [ 128 ]; 4023 dest_addr [ 128 ]; 4024 extension_headers =:= baseheader_extension_headers [ VARIABLE ]; 4025 spi [ 32 ]; 4026 sequence_number [ 32 ]; 4027 df =:= uncompressed_value(0,0) [ 0 ]; 4028 ip_id =:= uncompressed_value(0,0) [ 0 ]; 4029 } 4031 CONTROL { 4032 ENFORCE(profile_value == PROFILE_ESP_0103); 4033 ENFORCE(profile == profile_value); 4034 ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value); 4035 ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value); 4036 } 4038 DEFAULT { 4039 ENFORCE(outer_ip_flag == 0); 4040 tos_tc =:= static; 4041 dest_addr =:= static; 4042 ttl_hopl =:= static; 4043 src_addr =:= static; 4044 df =:= static; 4045 flow_label =:= static; 4046 next_header =:= static; 4047 spi =:= static; 4048 sequence_number =:= static; 4049 reorder_ratio =:= static; 4050 ip_id_behavior_innermost =:= static; 4051 } 4053 // Replacement for UOR-2-ext3 4054 COMPRESSED co_common { 4055 ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE); 4056 discriminator =:= '11111010' [ 8 ]; 4057 ip_id_indicator =:= irregular(1) [ 1 ]; 4058 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 4059 flags_indicator =:= irregular(1) [ 1 ]; 4060 ttl_hopl_indicator =:= irregular(1) [ 1 ]; 4061 tos_tc_indicator =:= irregular(1) [ 1 ]; 4062 reorder_ratio =:= irregular(2) [ 2 ]; 4063 control_crc3 =:= control_crc3_encoding [ 3 ]; 4065 outer_ip_indicator : df : ip_id_behavior_innermost =:= 4066 profile_2_3_4_flags_enc( 4067 flags_indicator.CVALUE, ip_version.UVALUE) [ 0, 8 ]; 4068 tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ]; 4069 ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE, 4070 ttl_hopl.ULENGTH) [ 0, 8 ]; 4071 sequence_number =:= 4072 sdvl_sn_lsb(sequence_number.ULENGTH) [ VARIABLE ]; 4073 ip_id =:= ip_id_sequential_variable(ip_id_behavior_innermost.UVALUE, 4074 ip_id_indicator.CVALUE) [ 0, 8, 16 ]; 4075 } 4077 // Sequence number sent instead of MSN due to field length 4078 // UO-0 4079 COMPRESSED pt_0_crc3 { 4080 discriminator =:= '0' [ 1 ]; 4081 sequence_number =:= msn_lsb(4) [ 4 ]; 4082 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 4083 ip_id =:= inferred_sequential_ip_id [ 0 ]; 4084 } 4086 // New format, Type 0 with strong CRC and more SN bits 4087 COMPRESSED pt_0_crc7 { 4088 discriminator =:= '100' [ 3 ]; 4089 sequence_number =:= msn_lsb(6) [ 6 ]; 4090 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 4091 ip_id =:= inferred_sequential_ip_id [ 0 ]; 4092 } 4094 // UO-1-ID replacement (PT-1 only used for sequential) 4095 COMPRESSED pt_1_seq_id { 4096 ENFORCE((ip_id_behavior_innermost.UVALUE == 4097 IP_ID_BEHAVIOR_SEQUENTIAL) || 4098 (ip_id_behavior_innermost.UVALUE == 4099 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 4100 discriminator =:= '101' [ 3 ]; 4101 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 4102 sequence_number =:= msn_lsb(6) [ 6 ]; 4103 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4) [ 4 ]; 4104 } 4106 // UOR-2-ID replacement 4107 COMPRESSED pt_2_seq_id { 4108 ENFORCE((ip_id_behavior_innermost.UVALUE == 4109 IP_ID_BEHAVIOR_SEQUENTIAL) || 4110 (ip_id_behavior_innermost.UVALUE == 4111 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 4112 discriminator =:= '110' [ 3 ]; 4113 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 6) [ 6 ]; 4114 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 4115 sequence_number =:= msn_lsb(8) [ 8 ]; 4116 } 4117 } 4119 //////////////////////////////////////////// 4120 // IP-only profile 4121 //////////////////////////////////////////// 4123 iponly_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value, 4124 reorder_ratio_value) 4125 { 4126 UNCOMPRESSED v4 { 4127 outer_headers =:= baseheader_outer_headers [ VARIABLE ]; 4128 ip_version =:= uncompressed_value(4, 4) [ 4 ]; 4129 header_length =:= uncompressed_value(4, 5) [ 4 ]; 4130 tos_tc [ 8 ]; 4131 length =:= inferred_ip_v4_length [ 16 ]; 4132 ip_id [ 16 ]; 4133 rf =:= uncompressed_value(1, 0) [ 1 ]; 4134 df [ 1 ]; 4135 mf =:= uncompressed_value(1, 0) [ 1 ]; 4136 frag_offset =:= uncompressed_value(13, 0) [ 13 ]; 4137 ttl_hopl [ 8 ]; 4138 next_header [ 8 ]; 4139 ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ]; 4140 src_addr [ 32 ]; 4141 dest_addr [ 32 ]; 4142 extension_headers =:= baseheader_extension_headers [ VARIABLE ]; 4143 } 4145 UNCOMPRESSED v6 { 4146 ENFORCE(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_RANDOM); 4147 outer_headers =:= baseheader_outer_headers [ VARIABLE ]; 4148 ip_version =:= uncompressed_value(4, 6) [ 4 ]; 4149 tos_tc [ 8 ]; 4150 flow_label [ 20 ]; 4151 payload_length =:= inferred_ip_v6_length [ 16 ]; 4152 next_header [ 8 ]; 4153 ttl_hopl [ 8 ]; 4154 src_addr [ 128 ]; 4155 dest_addr [ 128 ]; 4156 extension_headers =:= baseheader_extension_headers [ VARIABLE ]; 4157 df =:= uncompressed_value(0,0) [ 0 ]; 4158 ip_id =:= uncompressed_value(0,0) [ 0 ]; 4159 } 4161 CONTROL { 4162 ENFORCE(profile_value == PROFILE_IP_0104); 4163 ENFORCE(profile == profile_value); 4164 ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value); 4165 ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value); 4166 } 4168 DEFAULT { 4169 ENFORCE(outer_ip_flag == 0); 4170 tos_tc =:= static; 4171 dest_addr =:= static; 4172 ttl_hopl =:= static; 4173 src_addr =:= static; 4174 df =:= static; 4175 flow_label =:= static; 4176 next_header =:= static; 4177 reorder_ratio =:= static; 4178 ip_id_behavior_innermost =:= static; 4179 } 4181 // Replacement for UOR-2-ext3 4182 COMPRESSED co_common { 4183 ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE); 4184 discriminator =:= '11111010' [ 8 ]; 4185 ip_id_indicator =:= irregular(1) [ 1 ]; 4186 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 4187 flags_indicator =:= irregular(1) [ 1 ]; 4188 ttl_hopl_indicator =:= irregular(1) [ 1 ]; 4189 tos_tc_indicator =:= irregular(1) [ 1 ]; 4190 reorder_ratio =:= irregular(2) [ 2 ]; 4191 control_crc3 =:= control_crc3_encoding [ 3 ]; 4192 outer_ip_indicator : df : ip_id_behavior_innermost =:= 4193 profile_2_3_4_flags_enc( 4194 flags_indicator.CVALUE, ip_version.UVALUE) [ 0, 8 ]; 4195 tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ]; 4196 ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE, 4197 ttl_hopl.ULENGTH) [ 0, 8 ]; 4198 msn =:= msn_lsb(8) [ 8 ]; 4199 ip_id =:= ip_id_sequential_variable(ip_id_behavior_innermost.UVALUE, 4200 ip_id_indicator.CVALUE) [ 0, 8, 16 ]; 4201 } 4203 // UO-0 4204 COMPRESSED pt_0_crc3 { 4205 discriminator =:= '0' [ 1 ]; 4206 msn =:= msn_lsb(4) [ 4 ]; 4207 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 4208 ip_id =:= inferred_sequential_ip_id [ 0 ]; 4209 } 4211 // New format, Type 0 with strong CRC and more SN bits 4212 COMPRESSED pt_0_crc7 { 4213 discriminator =:= '100' [ 3 ]; 4214 msn =:= msn_lsb(6) [ 6 ]; 4215 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 4216 ip_id =:= inferred_sequential_ip_id [ 0 ]; 4217 } 4219 // UO-1-ID replacement (PT-1 only used for sequential) 4220 COMPRESSED pt_1_seq_id { 4221 ENFORCE((ip_id_behavior_innermost.UVALUE == 4222 IP_ID_BEHAVIOR_SEQUENTIAL) || 4223 (ip_id_behavior_innermost.UVALUE == 4224 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 4225 discriminator =:= '101' [ 3 ]; 4226 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 4227 msn =:= msn_lsb(6) [ 6 ]; 4228 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4) [ 4 ]; 4229 } 4231 // UOR-2-ID replacement 4232 COMPRESSED pt_2_seq_id { 4233 ENFORCE((ip_id_behavior_innermost.UVALUE == 4234 IP_ID_BEHAVIOR_SEQUENTIAL) || 4235 (ip_id_behavior_innermost.UVALUE == 4236 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 4237 discriminator =:= '110' [ 3 ]; 4238 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 6) [ 6 ]; 4239 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 4240 msn =:= msn_lsb(8) [ 8 ]; 4241 } 4242 } 4244 //////////////////////////////////////////// 4245 // UDP-lite/RTP profile 4246 //////////////////////////////////////////// 4248 udplite_rtp_baseheader(profile_value, ts_stride_value, 4249 time_stride_value, outer_ip_flag, 4250 ip_id_behavior_value, reorder_ratio_value, 4251 coverage_behavior_value) 4252 { 4253 UNCOMPRESSED v4 { 4254 ENFORCE(msn.UVALUE == sequence_number.UVALUE); 4255 outer_headers =:= baseheader_outer_headers [ VARIABLE ]; 4256 ip_version =:= uncompressed_value(4, 4) [ 4 ]; 4257 header_length =:= uncompressed_value(4, 5) [ 4 ]; 4258 tos_tc [ 8 ]; 4259 length =:= inferred_ip_v4_length [ 16 ]; 4260 ip_id [ 16 ]; 4261 rf =:= uncompressed_value(1, 0) [ 1 ]; 4262 df [ 1 ]; 4263 mf =:= uncompressed_value(1, 0) [ 1 ]; 4264 frag_offset =:= uncompressed_value(13, 0) [ 13 ]; 4265 ttl_hopl [ 8 ]; 4266 next_header [ 8 ]; 4267 ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ]; 4268 src_addr [ 32 ]; 4269 dest_addr [ 32 ]; 4270 extension_headers =:= baseheader_extension_headers [ VARIABLE ]; 4271 src_port [ 16 ]; 4272 dst_port [ 16 ]; 4273 checksum_coverage [ 16 ]; 4274 udp_checksum [ 16 ]; 4275 rtp_version =:= uncompressed_value(2, 2) [ 2 ]; 4276 pad_bit [ 1 ]; 4277 extension [ 1 ]; 4278 cc [ 4 ]; 4279 marker [ 1 ]; 4280 payload_type [ 7 ]; 4281 sequence_number [ 16 ]; 4282 timestamp [ 32 ]; 4283 ssrc [ 32 ]; 4284 csrc_list [ VARIABLE ]; 4285 } 4287 UNCOMPRESSED v6 { 4288 ENFORCE(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_RANDOM); 4289 outer_headers =:= baseheader_outer_headers [ VARIABLE ]; 4290 ip_version =:= uncompressed_value(4, 6) [ 4 ]; 4291 tos_tc [ 8 ]; 4292 flow_label [ 20 ]; 4293 payload_length =:= inferred_ip_v6_length [ 16 ]; 4294 next_header [ 8 ]; 4295 ttl_hopl [ 8 ]; 4296 src_addr [ 128 ]; 4297 dest_addr [ 128 ]; 4298 extension_headers =:= baseheader_extension_headers [ VARIABLE ]; 4299 src_port [ 16 ]; 4300 dst_port [ 16 ]; 4301 checksum_coverage [ 16 ]; 4302 udp_checksum [ 16 ]; 4303 rtp_version =:= uncompressed_value(2, 2) [ 2 ]; 4304 pad_bit [ 1 ]; 4305 extension [ 1 ]; 4306 cc [ 4 ]; 4307 marker [ 1 ]; 4308 payload_type [ 7 ]; 4309 sequence_number [ 16 ]; 4310 timestamp [ 32 ]; 4311 ssrc [ 32 ]; 4312 csrc_list [ VARIABLE ]; 4313 df =:= uncompressed_value(0,0) [ 0 ]; 4314 ip_id =:= uncompressed_value(0,0) [ 0 ]; 4315 } 4317 CONTROL { 4318 ENFORCE(profile_value == PROFILE_RTP_0107); 4319 ENFORCE(profile == profile_value); 4320 ENFORCE(time_stride.UVALUE == time_stride_value); 4321 ENFORCE(ts_stride.UVALUE == ts_stride_value); 4322 ENFORCE(coverage_behavior.UVALUE == coverage_behavior_value); 4323 ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value); 4324 ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value); 4325 dummy_field =:= field_scaling(ts_stride.UVALUE, 4326 ts_scaled.UVALUE, timestamp.UVALUE, ts_offset.UVALUE) [ 0 ]; 4327 } 4328 INITIAL { 4329 ts_stride =:= uncompressed_value(32, TS_STRIDE_DEFAULT); 4330 time_stride =:= uncompressed_value(32, TIME_STRIDE_DEFAULT); 4331 } 4333 DEFAULT { 4334 ENFORCE(outer_ip_flag == 0); 4335 tos_tc =:= static; 4336 dest_addr =:= static; 4337 ttl_hopl =:= static; 4338 src_addr =:= static; 4339 df =:= static; 4340 flow_label =:= static; 4341 next_header =:= static; 4342 src_port =:= static; 4343 dst_port =:= static; 4344 pad_bit =:= static; 4345 extension =:= static; 4346 cc =:= static; 4347 // When marker not present in packets, it is assumed 0 4348 marker =:= uncompressed_value(1, 0); 4349 payload_type =:= static; 4350 sequence_number =:= static; 4351 timestamp =:= static; 4352 ssrc =:= static; 4353 csrc_list =:= static; 4354 ts_stride =:= static; 4355 time_stride =:= static; 4356 ts_scaled =:= static; 4357 ts_offset =:= static; 4358 reorder_ratio =:= static; 4359 ip_id_behavior_innermost =:= static; 4360 } 4362 // Replacement for UOR-2-ext3 4363 COMPRESSED co_common { 4364 ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE); 4365 discriminator =:= '11111010' [ 8 ]; 4366 marker =:= irregular(1) [ 1 ]; 4367 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 4368 flags1_indicator =:= irregular(1) [ 1 ]; 4369 flags2_indicator =:= irregular(1) [ 1 ]; 4370 tsc_indicator =:= irregular(1) [ 1 ]; 4371 tss_indicator =:= irregular(1) [ 1 ]; 4372 ip_id_indicator =:= irregular(1) [ 1 ]; 4373 control_crc3 =:= control_crc3_encoding [ 3 ]; 4375 outer_ip_indicator : ttl_hopl_indicator : 4377 tos_tc_indicator : df : ip_id_behavior_innermost : reorder_ratio 4378 =:= profile_1_7_flags1_enc(flags1_indicator.CVALUE, 4379 ip_version.UVALUE) [ 0, 8 ]; 4380 list_indicator : pt_indicator : tis_indicator : pad_bit : 4381 extension : coverage_behavior =:= 4382 profile_7_flags2_enc(flags2_indicator.CVALUE) [ 0, 8 ]; 4383 tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ]; 4384 ttl_hopl =:= 4385 static_or_irreg(ttl_hopl_indicator.CVALUE, 8) [ 0, 8 ]; 4386 payload_type =:= pt_irr_or_static(pt_indicator.CVALUE) [ 0, 8 ]; 4387 sequence_number =:= 4388 sdvl_sn_lsb(sequence_number.ULENGTH) [ VARIABLE ]; 4389 ip_id =:= ip_id_sequential_variable(ip_id_behavior_innermost.UVALUE, 4390 ip_id_indicator.CVALUE) [ 0, 8, 16 ]; 4391 ts_scaled =:= variable_scaled_timestamp(tss_indicator.CVALUE, 4392 tsc_indicator.CVALUE, ts_stride.UVALUE, 4393 time_stride.UVALUE) [ VARIABLE ]; 4394 timestamp =:= variable_unscaled_timestamp(tss_indicator.CVALUE, 4395 tsc_indicator.CVALUE) [ VARIABLE ]; 4396 ts_stride =:= sdvl_or_static(tss_indicator.CVALUE) [ VARIABLE ]; 4397 time_stride =:= sdvl_or_static(tis_indicator.CVALUE) [ VARIABLE ]; 4398 csrc_list =:= 4399 csrc_list_presence(list_indicator.CVALUE, 4400 cc.UVALUE) [ VARIABLE ]; 4401 } 4403 // UO-0 4404 COMPRESSED pt_0_crc3 { 4405 discriminator =:= '0' [ 1 ]; 4406 msn =:= msn_lsb(4) [ 4 ]; 4407 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 4408 timestamp =:= inferred_scaled_field [ 0 ]; 4409 ip_id =:= inferred_sequential_ip_id [ 0 ]; 4410 } 4412 // New format, Type 0 with strong CRC and more SN bits 4413 COMPRESSED pt_0_crc7 { 4414 discriminator =:= '1000' [ 4 ]; 4415 msn =:= msn_lsb(5) [ 5 ]; 4416 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 4417 timestamp =:= inferred_scaled_field [ 0 ]; 4418 ip_id =:= inferred_sequential_ip_id [ 0 ]; 4419 } 4421 // UO-1 replacement 4422 COMPRESSED pt_1_rnd { 4423 ENFORCE(ts_stride.UVALUE != 0); 4424 ENFORCE((ip_id_behavior_innermost.UVALUE == 4425 IP_ID_BEHAVIOR_RANDOM) || 4426 (ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO)); 4427 discriminator =:= '101' [ 3 ]; 4428 marker =:= irregular(1) [ 1 ]; 4429 msn =:= msn_lsb(4) [ 4 ]; 4430 ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 5) [ 5 ]; 4431 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 4432 } 4434 // UO-1-ID replacement 4435 COMPRESSED pt_1_seq_id { 4436 ENFORCE((ip_id_behavior_innermost.UVALUE == 4437 IP_ID_BEHAVIOR_SEQUENTIAL) || 4438 (ip_id_behavior_innermost.UVALUE == 4439 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 4440 discriminator =:= '1001' [ 4 ]; 4441 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4) [ 4 ]; 4442 msn =:= msn_lsb(5) [ 5 ]; 4443 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 4444 timestamp =:= inferred_scaled_field [ 0 ]; 4445 } 4447 // UO-1-TS replacement 4448 COMPRESSED pt_1_seq_ts { 4449 ENFORCE(ts_stride.UVALUE != 0); 4450 ENFORCE((ip_id_behavior_innermost.UVALUE == 4451 IP_ID_BEHAVIOR_SEQUENTIAL) || 4452 (ip_id_behavior_innermost.UVALUE == 4453 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 4454 discriminator =:= '101' [ 3 ]; 4455 marker =:= irregular(1) [ 1 ]; 4456 msn =:= msn_lsb(4) [ 4 ]; 4457 ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 5) [ 5 ]; 4458 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 4459 ip_id =:= inferred_sequential_ip_id [ 0 ]; 4460 } 4462 // UOR-2 replacement 4463 COMPRESSED pt_2_rnd { 4464 ENFORCE(ts_stride.UVALUE != 0); 4465 ENFORCE((ip_id_behavior_innermost.UVALUE == 4466 IP_ID_BEHAVIOR_RANDOM) || 4467 (ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_ZERO)); 4468 discriminator =:= '110' [ 3 ]; 4469 msn =:= msn_lsb(7) [ 7 ]; 4470 ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 6) [ 6 ]; 4471 marker =:= irregular(1) [ 1 ]; 4472 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 4474 } 4476 // UOR-2-ID replacement 4477 COMPRESSED pt_2_seq_id { 4478 ENFORCE((ip_id_behavior_innermost.UVALUE == 4479 IP_ID_BEHAVIOR_SEQUENTIAL) || 4480 (ip_id_behavior_innermost.UVALUE == 4481 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 4482 discriminator =:= '11000' [ 5 ]; 4483 msn =:= msn_lsb(7) [ 7 ]; 4484 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 5) [ 5 ]; 4485 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 4486 timestamp =:= inferred_scaled_field [ 0 ]; 4487 } 4489 // UOR-2-ID-ext1 replacement (both TS and IP-ID) 4490 COMPRESSED pt_2_seq_both { 4491 ENFORCE(ts_stride.UVALUE != 0); 4492 ENFORCE((ip_id_behavior_innermost.UVALUE == 4493 IP_ID_BEHAVIOR_SEQUENTIAL) || 4494 (ip_id_behavior_innermost.UVALUE == 4495 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 4496 discriminator =:= '11001' [ 5 ]; 4497 msn =:= msn_lsb(7) [ 7 ]; 4498 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 5) [ 5 ]; 4499 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 4500 ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 7) [ 7 ]; 4501 marker =:= irregular(1) [ 1 ]; 4502 } 4504 // UOR-2-TS replacement 4505 COMPRESSED pt_2_seq_ts { 4506 ENFORCE(ts_stride.UVALUE != 0); 4507 ENFORCE((ip_id_behavior_innermost.UVALUE == 4508 IP_ID_BEHAVIOR_SEQUENTIAL) || 4509 (ip_id_behavior_innermost.UVALUE == 4510 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 4511 discriminator =:= '1101' [ 4 ]; 4512 msn =:= msn_lsb(7) [ 7 ]; 4513 ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 5) [ 5 ]; 4514 marker =:= irregular(1) [ 1 ]; 4515 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 4516 ip_id =:= inferred_sequential_ip_id [ 0 ]; 4517 } 4518 } 4520 //////////////////////////////////////////// 4521 // UDP-lite profile 4522 //////////////////////////////////////////// 4524 udplite_baseheader(profile_value, outer_ip_flag, ip_id_behavior_value, 4525 reorder_ratio_value, coverage_behavior_value) 4526 { 4527 UNCOMPRESSED v4 { 4528 outer_headers =:= baseheader_outer_headers [ VARIABLE ]; 4529 ip_version =:= uncompressed_value(4, 4) [ 4 ]; 4530 header_length =:= uncompressed_value(4, 5) [ 4 ]; 4531 tos_tc [ 8 ]; 4532 length =:= inferred_ip_v4_length [ 16 ]; 4533 ip_id [ 16 ]; 4534 rf =:= uncompressed_value(1, 0) [ 1 ]; 4535 df [ 1 ]; 4536 mf =:= uncompressed_value(1, 0) [ 1 ]; 4537 frag_offset =:= uncompressed_value(13, 0) [ 13 ]; 4538 ttl_hopl [ 8 ]; 4539 next_header [ 8 ]; 4540 ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ]; 4541 src_addr [ 32 ]; 4542 dest_addr [ 32 ]; 4543 extension_headers =:= baseheader_extension_headers [ VARIABLE ]; 4544 src_port [ 16 ]; 4545 dst_port [ 16 ]; 4546 checksum_coverage [ 16 ]; 4547 udp_checksum [ 16 ]; 4548 } 4550 UNCOMPRESSED v6 { 4551 ENFORCE(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_RANDOM); 4552 outer_headers =:= baseheader_outer_headers [ VARIABLE ]; 4553 ip_version =:= uncompressed_value(4, 6) [ 4 ]; 4554 tos_tc [ 8 ]; 4555 flow_label [ 20 ]; 4556 payload_length =:= inferred_ip_v6_length [ 16 ]; 4557 next_header [ 8 ]; 4558 ttl_hopl [ 8 ]; 4559 src_addr [ 128 ]; 4560 dest_addr [ 128 ]; 4561 extension_headers =:= baseheader_extension_headers [ VARIABLE ]; 4562 src_port [ 16 ]; 4563 dst_port [ 16 ]; 4564 checksum_coverage [ 16 ]; 4565 udp_checksum [ 16 ]; 4566 df =:= uncompressed_value(0,0) [ 0 ]; 4567 ip_id =:= uncompressed_value(0,0) [ 0 ]; 4568 } 4569 CONTROL { 4570 ENFORCE(profile_value == PROFILE_UDPLITE_0108); 4571 ENFORCE(profile == profile_value); 4572 ENFORCE(coverage_behavior.UVALUE == coverage_behavior_value); 4573 ENFORCE(reorder_ratio.UVALUE == reorder_ratio_value); 4574 ENFORCE(ip_id_behavior_innermost.UVALUE == ip_id_behavior_value); 4575 } 4577 DEFAULT { 4578 ENFORCE(outer_ip_flag == 0); 4579 tos_tc =:= static; 4580 dest_addr =:= static; 4581 ttl_hopl =:= static; 4582 src_addr =:= static; 4583 df =:= static; 4584 flow_label =:= static; 4585 next_header =:= static; 4586 src_port =:= static; 4587 dst_port =:= static; 4588 reorder_ratio =:= static; 4589 ip_id_behavior_innermost =:= static; 4590 } 4592 // Replacement for UOR-2-ext3 4593 COMPRESSED co_common { 4594 ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE); 4595 discriminator =:= '11111010' [ 8 ]; 4596 ip_id_indicator =:= irregular(1) [ 1 ]; 4597 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 4598 flags_indicator =:= irregular(1) [ 1 ]; 4599 ttl_hopl_indicator =:= irregular(1) [ 1 ]; 4600 tos_tc_indicator =:= irregular(1) [ 1 ]; 4601 reorder_ratio =:= irregular(2) [ 2 ]; 4602 control_crc3 =:= control_crc3_encoding [ 3 ]; 4603 outer_ip_indicator : df : ip_id_behavior_innermost : 4604 coverage_behavior =:= 4605 profile_8_flags_enc(flags_indicator.CVALUE, 4606 ip_version.UVALUE) [ 0, 8 ]; 4607 tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ]; 4608 ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE, 4609 ttl_hopl.ULENGTH) [ 0, 8 ]; 4610 msn =:= msn_lsb(8) [ 8 ]; 4611 ip_id =:= ip_id_sequential_variable(ip_id_behavior_innermost.UVALUE, 4612 ip_id_indicator.CVALUE) [ 0, 8, 16 ]; 4613 } 4615 // UO-0 4616 COMPRESSED pt_0_crc3 { 4617 discriminator =:= '0' [ 1 ]; 4618 msn =:= msn_lsb(4) [ 4 ]; 4619 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 4620 ip_id =:= inferred_sequential_ip_id [ 0 ]; 4621 } 4623 // New format, Type 0 with strong CRC and more SN bits 4624 COMPRESSED pt_0_crc7 { 4625 discriminator =:= '100' [ 3 ]; 4626 msn =:= msn_lsb(6) [ 6 ]; 4627 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 4628 ip_id =:= inferred_sequential_ip_id [ 0 ]; 4629 } 4631 // UO-1-ID replacement (PT-1 only used for sequential) 4632 COMPRESSED pt_1_seq_id { 4633 ENFORCE((ip_id_behavior_innermost.UVALUE == 4634 IP_ID_BEHAVIOR_SEQUENTIAL) || 4635 (ip_id_behavior_innermost.UVALUE == 4636 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 4637 discriminator =:= '101' [ 3 ]; 4638 header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; 4639 msn =:= msn_lsb(6) [ 6 ]; 4640 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 4) [ 4 ]; 4641 } 4643 // UOR-2-ID replacement 4644 COMPRESSED pt_2_seq_id { 4645 ENFORCE((ip_id_behavior_innermost.UVALUE == 4646 IP_ID_BEHAVIOR_SEQUENTIAL) || 4647 (ip_id_behavior_innermost.UVALUE == 4648 IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); 4649 discriminator =:= '110' [ 3 ]; 4650 ip_id =:= ip_id_lsb(ip_id_behavior_innermost.UVALUE, 6) [ 6 ]; 4651 header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; 4652 msn =:= msn_lsb(8) [ 8 ]; 4653 } 4654 } 4656 6.9. Feedback Formats and Options 4658 6.9.1. Feedback Formats 4660 This section describes the feedback format for ROHCv2 profiles, using 4661 the formats described in section 5.2.3 of [RFC4995]. 4663 The Acknowledgment Number field of the feedback formats contains the 4664 least significant bits of the MSN (see Section 6.3.1) that 4665 corresponds to the reference header that is being acknowledged. A 4666 reference header is a header that has been successfully CRC-8 4667 validated or CRC verified. If there is no reference header 4668 available, the feedback MUST carry an ACKNUMBER-NOT-VALID option. 4670 FEEDBACK-1 4672 0 1 2 3 4 5 6 7 4673 +---+---+---+---+---+---+---+---+ 4674 | Acknowledgment Number | 4675 +---+---+---+---+---+---+---+---+ 4677 Acknowledgment Number: The eight least significant bits of the 4678 MSN. 4680 A FEEDBACK-1 is an ACK. In order to send a NACK or a STATIC-NACK, 4681 FEEDBACK-2 must be used. 4683 FEEDBACK-2 4685 0 1 2 3 4 5 6 7 4686 +---+---+---+---+---+---+---+---+ 4687 |Acktype| Acknowledgment Number | 4688 +---+---+---+---+---+---+---+---+ 4689 | Acknowledgment Number | 4690 +---+---+---+---+---+---+---+---+ 4691 | CRC | 4692 +---+---+---+---+---+---+---+---+ 4693 / Feedback options / 4694 +---+---+---+---+---+---+---+---+ 4696 Acktype: 4698 0 = ACK 4699 1 = NACK 4700 2 = STATIC-NACK 4701 3 is reserved (MUST NOT be used for parsability) 4703 Acknowledgment Number: The least significant bits of the MSN. 4705 CRC: 8-bit CRC computed over the entire feedback payload including 4706 any CID fields but excluding the feedback type, the 'Size' field 4707 and the 'Code' octet, using the polynomial defined in [RFC4995], 4708 Section 5.3.1.1. If the CID is given with an Add-CID octet, the 4709 Add-CID octet immediately precedes the FEEDBACK-1 or FEEDBACK-2 4710 format. For purposes of computing the CRC, the CRC field is zero. 4712 Feedback options: A variable number of feedback options, see 4713 Section 6.9.2. Options may appear in any order. 4715 A FEEDBACK-2 of type NACK or STATIC-NACK is always implicitly an 4716 acknowledgment for a successfully decompressed packet, which 4717 corresponds to a packet whose LSBs match the Acknowledgment Number of 4718 the feedback element, unless the ACKNUMBER-NOT-VALID option 4719 Section 6.9.2.2 appears in the feedback element. 4721 The FEEDBACK-2 format always carry a CRC and is thus more robust than 4722 the FEEDBACK-1 format. When receiving FEEDBACK-2, the compressor 4723 MUST verify the information by computing the CRC and comparing the 4724 result with the CRC carried in the feedback format. If the two are 4725 not identical, the feedback element MUST be discarded. 4727 6.9.2. Feedback Options 4729 A feedback option has variable length and the following general 4730 format: 4732 0 1 2 3 4 5 6 7 4733 +---+---+---+---+---+---+---+---+ 4734 | Opt Type | Opt Len | 4735 +---+---+---+---+---+---+---+---+ 4736 / Option Data / Opt Len (octets) 4737 +---+---+---+---+---+---+---+---+ 4739 Opt Type: Unsigned integer that represents the type of the 4740 feedback option. Sections Section 6.9.2.1 to Section 6.9.2.4 4741 describe the ROHCv2 feedback options. 4743 Opt Len: The lenght of the Option Data field, in octets. 4745 Option Data: Feedback type specific data. Present if the value of 4746 the Opt Len field is set to a non-zero value. 4748 6.9.2.1. The REJECT Option 4750 The REJECT option informs the compressor that the decompressor does 4751 not have sufficient resources to handle the flow. 4753 0 1 2 3 4 5 6 7 4754 +---+---+---+---+---+---+---+---+ 4755 | Opt Type = 2 | Opt Len = 0 | 4756 +---+---+---+---+---+---+---+---+ 4758 When receiving a REJECT option, the compressor MUST stop compressing 4759 the packet flow, and SHOULD refrain from attempting to increase the 4760 number of compressed packet flows for some time. The REJECT option 4761 MUST NOT appear more than once in the FEEDBACK-2 format, otherwise 4762 the compressor MUST discard the entire feedback element. 4764 6.9.2.2. The ACKNUMBER-NOT-VALID Option 4766 The ACKNUMBER-NOT-VALID option indicates that the Acknowledgment 4767 Number field of the feedback is not valid. 4769 0 1 2 3 4 5 6 7 4770 +---+---+---+---+---+---+---+---+ 4771 | Opt Type = 3 | Opt Len = 0 | 4772 +---+---+---+---+---+---+---+---+ 4774 A compressor MUST NOT use the Acknowledgment Number of the feedback 4775 to find the corresponding sent header when this option is present. 4776 When this option is used, the Acknowledgment Number field of the 4777 FEEDBACK-2 format is set to zero. Consequently, a NACK or a STATIC- 4778 NACK feedback type sent with the ACKNUMBER-NOT-VALID option is 4779 equivalent to a STATIC-NACK with respect to the type of context 4780 repair requested by the decompressor. 4782 The ACKNUMBER-NOT-VALID option MUST NOT appear more than once in the 4783 FEEDBACK-2 format, otherwise the compressor MUST discard the entire 4784 feedback element. 4786 6.9.2.3. The CONTEXT_MEMORY Option 4788 The CONTEXT_MEMORY option informs the compressor that the 4789 decompressor does not have sufficient memory resources to handle the 4790 context of the packet flow, as the flow is currently compressed. 4792 0 1 2 3 4 5 6 7 4793 +---+---+---+---+---+---+---+---+ 4794 | Opt Type = 9 | Opt Len = 0 | 4795 +---+---+---+---+---+---+---+---+ 4797 When receiving a CONTEXT_MEMORY option, the compressor SHOULD take 4798 actions to compress the packet flow in a way that requires less 4799 decompressor memory resources, or stop compressing the packet flow. 4800 The CONTEXT_MEMORY option MUST NOT appear more than once in the 4801 FEEDBACK-2 format, otherwise the compressor MUST discard the entire 4802 feedback element. 4804 6.9.2.4. The CLOCK_RESOLUTION Option 4806 The CLOCK_RESOLUTION option informs the compressor of the clock 4807 resolution of the decompressor. It also informs whether the 4808 decompressor supports timer-based compression of the RTP TS timestamp 4809 (see Section 6.6.9) or not. The CLOCK_RESOLUTION option is 4810 applicable per channel, i.e., it applies to any context associated 4811 with a profile for which the option is relevant between one 4812 compressor and decompressor pair. 4814 0 1 2 3 4 5 6 7 4815 +---+---+---+---+---+---+---+---+ 4816 | Opt Type = 10 | Opt Len = 1 | 4817 +---+---+---+---+---+---+---+---+ 4818 | Clock resolution (ms) | 4819 +---+---+---+---+---+---+---+---+ 4821 Clock resolution: Unsigned integer that represents the clock 4822 resolution of the decompressor expressed in milliseconds. 4824 The smallest clock resolution which can be indicated is 1 4825 millisecond. The value zero has a special meaning: it indicates that 4826 the decompressor cannot do timer-based compression of the RTP 4827 Timestamp. The CLOCK_RESOLUTION option MUST NOT appear more than 4828 once in the FEEDBACK-2 format, otherwise the compressor MUST discard 4829 the entire feedback element. 4831 6.9.2.5. Unknown Option Types 4833 If an option type other than those defined in this document is 4834 encountered, the compressor MUST discard the entire feedback element. 4836 7. Security Considerations 4838 A malfunctioning or malicious header compressor could cause the 4839 header decompressor to reconstitute packets that do not match the 4840 original packets but still have valid IP, UDP and RTP headers and 4841 possibly also valid UDP checksums. Such corruption may be detected 4842 with integrity mechanisms which will not be affected by the 4843 compression. Moreover, this header compression scheme uses an 4844 internal checksum for verification of reconstructed headers. This 4845 reduces the probability of producing decompressed headers not 4846 matching the original ones without this being noticed, which can be 4847 useful in the case of malfunctioning compressors. 4849 Denial-of-service attacks are possible if an intruder can introduce 4850 (for example) bogus IR or FEEDBACK packets onto the link and thereby 4851 cause compression efficiency to be reduced. However, an intruder 4852 having the ability to inject arbitrary packets at the link layer in 4853 this manner raises additional security issues that dwarf those 4854 related to the use of header compression. 4856 8. IANA Considerations 4858 The following ROHC profile identifiers have been reserved by the IANA 4859 for the profiles defined in this document: 4860 Identifier Profile 4861 ---------- ------- 4862 0x0101 ROHCv2 RTP 4863 0x0102 ROHCv2 UDP 4864 0x0103 ROHCv2 ESP 4865 0x0104 ROHCv2 IP 4866 0x0107 ROHCv2 RTP/UDP-Lite 4867 0x0108 ROHCv2 UDP-Lite 4869 <# Editor's Note: To be removed before publication #> 4871 ROHC profile identifiers must be reserved by the IANA for the updated 4872 profiles defined in this document. A suggested registration in the 4873 "RObust Header Compression (ROHC) Profile Identifiers" name space 4874 would then be: 4876 Profile Identifier Usage Reference 4877 ------------------ ---------------------- --------- 4878 0x0000 ROHC uncompressed RFC 3095 4879 0xnn00 Reserved 4880 0x0001 ROHC RTP RFC 3095 4881 0x0101 ROHCv2 RTP [RFCXXXX (this)] 4882 0xnn01 Reserved 4883 0x0002 ROHC UDP RFC 3095 4884 0x0102 ROHCv2 UDP [RFCXXXX (this)] 4885 0xnn02 Reserved 4886 0x0003 ROHC ESP RFC 3095 4887 0x0103 ROHCv2 ESP [RFCXXXX (this)] 4888 0xnn03 Reserved 4889 0x0004 ROHC IP RFC 3843 4890 0x0104 ROHCv2 IP [RFCXXXX (this)] 4891 0xnn04 Reserved 4892 0x0005 ROHC LLA RFC 4362 4893 0x0105 ROHC LLA with R-mode RFC 3408 4894 0xnn05 Reserved 4895 0x0006 ROHC TCP RFC 4996 4896 0xnn06 Reserved 4897 0x0007 ROHC RTP/UDP-Lite RFC 4019 4898 0x0107 ROHCv2 RTP/UDP-Lite [RFCXXXX (this)] 4899 0xnn07 Reserved 4900 0x0008 ROHC UDP-Lite RFC 4019 4901 0x0108 ROHCv2 UDP-Lite [RFCXXXX (this)] 4902 0xnn08 Reserved 4903 0x0009-0xnn7F To be Assigned by IANA 4904 0xnn80-0xnnFE To be Assigned by IANA 4905 0xnnFF Reserved 4907 9. Acknowledgements 4909 The authors would like to thank Mark West, Robert Finking, Haipeng 4910 Jin and Rohit Kapoor for serving as committed document reviewers, and 4911 also for constructive discussions during the development of this 4912 document. Thanks to Carl Knutsson for his extensive contribution to 4913 this specification, as well as to Jani Juvan and Anders Edqvist for 4914 useful comments and feedback. Thanks also to Elwyn Davies for his 4915 review as the General Area Review Team (Gen-ART) reviewer, and to 4916 Stephen Kent for his review on behalf of the IETF security 4917 directorate, during IETF last-call. Finally, thanks to the many 4918 people who have contributed to previous ROHC specifications and 4919 supported this effort. 4921 10. References 4922 10.1. Normative References 4924 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 4925 August 1980. 4927 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 4928 September 1981. 4930 [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 4931 October 1996. 4933 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4934 Requirement Levels", BCP 14, RFC 2119, March 1997. 4936 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 4937 (IPv6) Specification", RFC 2460, December 1998. 4939 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 4940 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 4941 March 2000. 4943 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 4944 RFC 2890, September 2000. 4946 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 4947 Jacobson, "RTP: A Transport Protocol for Real-Time 4948 Applications", STD 64, RFC 3550, July 2003. 4950 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 4951 G. Fairhurst, "The Lightweight User Datagram Protocol 4952 (UDP-Lite)", RFC 3828, July 2004. 4954 [RFC4019] Pelletier, G., "RObust Header Compression (ROHC): Profiles 4955 for User Datagram Protocol (UDP) Lite", RFC 4019, 4956 April 2005. 4958 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 4959 December 2005. 4961 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 4962 RFC 4303, December 2005. 4964 [RFC4995] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust 4965 Header Compression (ROHC) Framework", RFC 4995, July 2007. 4967 [RFC4997] Finking, R. and G. Pelletier, "Formal Notation for RObust 4968 Header Compression (ROHC-FN)", RFC 4997, July 2007. 4970 10.2. Informative References 4972 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 4973 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 4974 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 4975 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 4976 Compression (ROHC): Framework and four profiles: RTP, UDP, 4977 ESP, and uncompressed", RFC 3095, July 2001. 4979 [RFC3843] Jonsson, L-E. and G. Pelletier, "RObust Header Compression 4980 (ROHC): A Compression Profile for IP", RFC 3843, 4981 June 2004. 4983 [RFC4224] Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust 4984 Header Compression (ROHC): ROHC over Channels That Can 4985 Reorder Packets", RFC 4224, January 2006. 4987 Appendix A. Detailed Classification of Header Fields 4989 Header compression is possible due to the fact that most header 4990 fields do not vary randomly from packet to packet. Many of the 4991 fields exhibit static behavior or change in a more or less 4992 predictable way. When designing a header compression scheme, it is 4993 of fundamental importance to understand the behavior of the fields in 4994 detail. 4996 In this appendix, all fields in the headers compressible by these 4997 profiles are classified and analyzed. The analysis is based on 4998 behavior for the types of traffic that are expected to be the most 4999 frequently compressed (e.g., RTP field behavior is based on voice 5000 and/or video traffic behavior). 5002 Fields are classified as belonging to one of the following classes: 5004 INFERRED - These fields contain values that can be inferred from 5005 other values, for example the size of the frame carrying the packet, 5006 and thus do not have to be included in compressed packets. 5008 STATIC These fields are expected to be constant throughout the 5009 lifetime of the flow and any change to them only has to be possible 5010 to convey in IR packets. 5012 STATIC-DEF - These fields are expected to be constant throughout the 5013 lifetime of the flow and whose values can be used to define a flow. 5014 They are only sent in IR packets. 5016 STATIC-KNOWN - These fields are expected to have well-known values 5017 and therefore do not need to be communicated at all. 5019 SEMISTATIC These fields are unchanged most of the time. However, 5020 occasionally the value changes but will revert to its original value. 5021 For ROHCv2, the values of such fields do not need to be possible to 5022 change with the smallest compressed packet formats, but should be 5023 possible to change via slightly larger compressed packets. 5025 RARELY CHANGING (RACH) These are fields that change their values 5026 occasionally and then keep their new values. For ROHCv2, the values 5027 of such fields do not need to be possible to change with the smallest 5028 compressed packet formats, but should be possible to change via 5029 slightly larger compressed packets. 5031 IRREGULAR These are the fields for which no useful change pattern can 5032 be identified and should be transmitted uncompressed in all 5033 compressed packets. 5035 PATTERN These are fields that change between each packet, but change 5036 in a predictable pattern. 5038 Appendix A.1. IPv4 Header Fields 5040 +------------------------+----------------+ 5041 | Field | Class | 5042 +------------------------+----------------+ 5043 | Version | STATIC-KNOWN | 5044 | Header Length | STATIC-KNOWN | 5045 | Type Of Service | RACH | 5046 | Packet Length | INFERRED | 5047 | Identification | | 5048 | Sequential | PATTERN | 5049 | Seq. swap | PATTERN | 5050 | Random | IRREGULAR | 5051 | Zero | STATIC | 5052 | Reserved flag | STATIC-KNOWN | 5053 | Don't Fragment flag | RACH | 5054 | More Fragments flag | STATIC-KNOWN | 5055 | Fragment Offset | STATIC-KNOWN | 5056 | Time To Live | RACH | 5057 | Protocol | STATIC-DEF | 5058 | Header Checksum | INFERRED | 5059 | Source Address | STATIC-DEF | 5060 | Destination Address | STATIC-DEF | 5061 +------------------------+----------------+ 5063 Version 5064 The version field states which IP version is used, and is set to 5065 the value four. 5067 Header Length 5068 As long no options are present in the IP header, the header length 5069 is constant with the value five. If there are options, the field 5070 could be RACH or STATIC-DEF, but only option-less headers are 5071 compressed by ROHCv2 profiles. The field is therefore classified 5072 as STATIC-KNOWN. 5074 Type Of Service 5075 The Type Of Service field is expected to be constant during the 5076 lifetime of a flow or to change relatively seldom. 5078 Packet Length 5079 Information about packet length is expected to be provided by the 5080 link layer. The field is therefore classified as INFERRED. 5082 IPv4 Identification 5083 The Identification field (IP ID) is used to identify what 5084 fragments constitute a datagram when reassembling fragmented 5085 datagrams. The IPv4 specification does not specify exactly how 5086 this field is to be assigned values, only that each packet should 5087 get an IP ID that is unique for the source-destination pair and 5088 protocol for the time the datagram (or any of its fragments) could 5089 be alive in the network. This means that assignment of IP ID 5090 values can be done in various ways, but the expected behaviors 5091 have been separated into four classes. 5093 Sequential 5094 In this behavior, the IP-ID is expected to increment by one for 5095 most packets, but may increment by a value larger than one, 5096 depending on the behavior of the transmitting IPv4 stack. 5097 Sequential Swapped 5098 When using this behavior, the IP-ID behaves as in the 5099 Sequential behavior, but the two bytes of IP-ID are byte 5100 swapped. Therefore, the IP-ID can be swapped before 5101 compression to make it behave exactly as the Sequential 5102 behavior. 5103 Random 5104 Some IP stacks assign IP ID values using a pseudo-random number 5105 generator. There is thus no correlation between the ID values 5106 of subsequent datagrams, and therefore there is no way to 5107 predict the IP ID value for the next datagram. For header 5108 compression purposes, this means that the IP ID field needs to 5109 be sent uncompressed with each datagram, resulting in two extra 5110 octets of header. 5112 Zero 5113 This behavior, although not a legal implementation of IPv4 is 5114 sometimes seen in existing IPv4 stacks. When this behavior is 5115 used, all IP packets have the IP-ID value set to zero. 5117 Flags 5118 The Reserved flag must be set to zero and is therefore classified 5119 as STATIC-KNOWN. The Don't Fragment (DF) flag will changes rarely 5120 and is therefore classified as RACH. Finally, the More Fragments 5121 (MF) flag is expected to be zero because IP fragments will not be 5122 compressed by ROHC and is therefore classified as STATIC-KNOWN. 5124 Fragment Offset 5125 Under the assumption that no fragmentation occurs, the fragment 5126 offset is always zero and is therefore classified as STATIC-KNOWN. 5128 Time To Live 5129 Time To Live field is expected to be constant during the lifetime 5130 of a flow or to alternate between a limited number of values due 5131 to route changes. 5133 Protocol 5134 This field will have the same value in all packets of a flow and 5135 is therefore classified as STATIC-DEF. 5137 Header Checksum 5138 The header checksum protects individual hops from processing a 5139 corrupted header. When almost all IP header information is 5140 compressed away, there is no point in having this additional 5141 checksum; instead it can be regenerated at the decompressor side. 5142 The field is therefore classified as INFERRED. 5144 Source and Destination addresses 5145 These fields are part of the definition of a flow and must thus be 5146 constant for all packets in the flow. 5148 Appendix A.2. IPv6 Header Fields 5149 +----------------------+----------------+ 5150 | Field | Class | 5151 +----------------------+----------------+ 5152 | Version | STATIC-KNOWN | 5153 | Traffic Class | RACH | 5154 | Flow Label | STATIC-DEF | 5155 | Payload Length | INFERRED | 5156 | Next Header | STATIC-DEF | 5157 | Hop Limit | RACH | 5158 | Source Address | STATIC-DEF | 5159 | Destination Address | STATIC-DEF | 5160 +----------------------+----------------+ 5162 Version 5163 The version field states which IP version is used, and is set to 5164 the value six. 5166 Traffic Class 5167 The Traffic Class field is expected to be constant during the 5168 lifetime of a flow or to change relatively seldom. 5170 Flow Label 5171 This field may be used to identify packets belonging to a specific 5172 flow. If not used, the value should be set to zero. Otherwise, 5173 all packets belonging to the same flow must have the same value in 5174 this field. The field is therefore classified as STATIC-DEF. 5176 Payload Length 5177 Information about packet length (and, consequently, payload 5178 length) is expected to be provided by the link layer. The field 5179 is therefore classified as INFERRED. 5181 Next Header 5182 This field will have the same value in all packets of a flow and 5183 is therefore classified as STATIC-DEF. 5185 Hop Limit 5186 The Hop Limit field is expected to be constant during the lifetime 5187 of a flow or to alternate between a limited number of values due 5188 to route changes. 5190 Source and Destination addresses 5191 These fields are part of the definition of a flow and must thus be 5192 constant for all packets in the flow. The fields are therefore 5193 classified as STATIC-DEF. 5195 Appendix A.3. UDP Header Fields 5197 +------------------+-------------+ 5198 | Field | Class | 5199 +------------------+-------------+ 5200 | Source Port | STATIC-DEF | 5201 | Destination Port | STATIC-DEF | 5202 | Length | INFERRED | 5203 | Checksum | | 5204 | Disabled | STATIC | 5205 | Enabled | IRREGULAR | 5206 +------------------+-------------+ 5208 Source and Destination ports 5209 These fields are part of the definition of a flow and must thus be 5210 constant for all packets in the flow. 5212 Length 5213 Information about packet length is expected to be provided by the 5214 link layer. The field is therefore classified as INFERRED. 5216 Checksum 5217 The checksum can be optional. If disabled, its value is 5218 constantly zero and can be compressed away. If enabled, its value 5219 depends on the payload, which for compression purposes is 5220 equivalent to it changing randomly with every packet. 5222 Appendix A.4. UDP-Lite Header Fields 5224 +--------------------+-------------+ 5225 | Field | Class | 5226 +--------------------+-------------+ 5227 | Source Port | STATIC-DEF | 5228 | Destination Port | STATIC-DEF | 5229 | Checksum Coverage | | 5230 | Zero | STATIC-DEF | 5231 | Constant | INFERRED | 5232 | Variable | IRREGULAR | 5233 | Checksum | IRREGULAR | 5234 +--------------------+-------------+ 5236 Source and Destination Port 5237 These fields are part of the definition of a flow and must thus be 5238 constant for all packets in the flow. 5240 Checksum Coverage 5241 The Checksum Coverage field may behave in different ways: it may 5242 have a value of zero, it may be equal to the datagram length, or 5243 it may have any value between eight octets and the length of the 5244 datagram. From a compression perspective, this field is expected 5245 to either be entirely predictable (for the cases where it follows 5246 the same behavior as the UDP Length field or where it takes on a 5247 constant value) or either to change randomly for each packet 5248 (making the value unpredictable from a header-compression 5249 perspective). For all cases, the behavior itself is not expected 5250 to change for this field during the lifetime of a packet flow, or 5251 to change relatively seldom. 5253 Checksum 5254 The information used for the calculation of the UDP-Lite checksum 5255 is governed by the value of the checksum coverage and minimally 5256 includes the UDP-Lite header. The checksum is a changing field 5257 that must always be sent as-is. 5259 Appendix A.5. RTP Header Fields 5261 +----------------+----------------+ 5262 | Field | Class | 5263 +----------------+----------------+ 5264 | Version | STATIC-KNOWN | 5265 | Padding | RACH | 5266 | Extension | RACH | 5267 | CSRC Counter | RACH | 5268 | Marker | SEMISTATIC | 5269 | Payload Type | RACH | 5270 | Sequence Number| PATTERN | 5271 | Timestamp | PATTERN | 5272 | SSRC | STATIC-DEF | 5273 | CSRC | RACH | 5274 +----------------+----------------+ 5276 Version 5277 This field is expected to have the value two and the field is 5278 therefore classified as STATIC-KNOWN. 5280 Padding 5281 The use of this field is application-dependent, but when payload 5282 padding is used it is likely to be present in most or all packets. 5283 The field is classified as RACH to allow for the case where the 5284 value of this field changes. 5286 Extension 5287 If RTP extensions are used by the application, these extensions 5288 are often present in all packets, although the use of extensions 5289 is infrequent. To allow efficient compression of a flow using 5290 extensions in only a few packets, this field is classified as 5291 RACH. 5293 CSRC Count 5294 This field indicates the number of CSRC items present in the CSRC 5295 list. This number is expected to be mostly constant on a packet- 5296 to-packet basis and when it changes, change by small amounts. As 5297 long as no RTP mixer is used, the value of this field will be 5298 zero. 5300 Marker 5301 For audio, the marker bit should be set only in the first packet 5302 of a talkspurt, while for video it should be set in the last 5303 packet of every picture. This means that in both cases the RTP 5304 marker is classified as SEMISTATIC. 5306 Payload Type 5307 Applications could adapt to congestion by changing payload type 5308 and/or frame sizes, but that is not expected to happen frequently, 5309 so this field is classified as RACH. 5311 RTP Sequence Number 5312 The RTP Sequence Number will be incremented by one for each packet 5313 sent. 5315 Timestamp 5316 In the audio case: 5317 As long as there are no pauses in the audio stream, the RTP 5318 Timestamp will be incremented by a constant value, 5319 corresponding to the number of samples in the speech frame. It 5320 will thus mostly follow the RTP Sequence Number. When there 5321 has been a silent period and a new talkspurt begins, the 5322 timestamp will jump in proportion to the length of the silent 5323 period. However, the increment will probably be within a 5324 relatively limited range. 5325 In the video case: 5326 Between two consecutive packets, the timestamp will either be 5327 unchanged or increase by a multiple of a fixed value 5328 corresponding to the picture clock frequency. The timestamp 5329 can also decrease by a multiple of the fixed value for certain 5330 coding schemes. The change in timestamp value, expressed as a 5331 multiple of the picture clock frequency, is in most cases 5332 within a limited range. 5334 SSRC 5335 This field is part of the definition of a flow and must thus be 5336 constant for all packets in the flow. The field is therefore 5337 classified as STATIC-DEF. 5339 Contributing Sources (CSRC) 5340 The participants in a session, who are identified by the CSRC 5341 fields, are usually expected to be unchanged on a packet-to-packet 5342 basis, but will infrequently change by a few additions and/or 5343 removals. 5345 Appendix A.6. ESP Header Fields 5347 +------------------+-------------+ 5348 | Field | Class | 5349 +------------------+-------------+ 5350 | SPI | STATIC-DEF | 5351 | Sequence Number | PATTERN | 5352 +------------------+-------------+ 5354 SPI 5355 This field is used to identify a specific flow and only changes 5356 when the sequence number wraps around, and is therefore classified 5357 as STATIC-DEF. 5359 ESP Sequence Number 5360 The ESP Sequence Number will be incremented by one for each packet 5361 sent. 5363 Appendix A.7. IPv6 Extension Header Fields 5365 +-----------------------+---------------+ 5366 | Field | Class | 5367 +-----------------------+---------------+ 5368 | Next Header | STATIC-DEF | 5369 | Ext Hdr Len | | 5370 | Routing | STATIC-DEF | 5371 | Hop-by-hop | STATIC | 5372 | Destination | STATIC | 5373 | Options | | 5374 | Routing | STATIC-DEF | 5375 | Hop-by-hop | RACH | 5376 | Destination | RACH | 5377 +-----------------------+---------------+ 5379 Next Header 5380 This field will have the same value in all packets of a flow and 5381 is therefore classified as STATIC-DEF. 5383 Ext Hdr Len 5384 For the Routing header, it is expected that the length remains 5385 constant for the duration of the flow, and a change in the length 5386 should be classified as a new flow by the ROHC compressor. For 5387 Hop-by-hop and Destination options headers, the length is expected 5388 to remain static, but can be updated by an IR packet. 5390 Options 5391 For the Routing header, it is expected that the option content 5392 remains constant for the duration of the flow, and a change in the 5393 routing information should be classified as a new flow by the ROHC 5394 compressor. For Hop-by-hop and Destination options headers, the 5395 options are expected to remain static, but can be updated by an IR 5396 packet. 5398 Appendix A.8. GRE Header Fields 5400 +--------------------+---------------+ 5401 | Field | Class | 5402 +--------------------+---------------+ 5403 | C flag | STATIC | 5404 | K flag | STATIC | 5405 | S flag | STATIC | 5406 | R flag | STATIC-KNOWN | 5407 | Reserved0, Version | STATIC-KNOWN | 5408 | Protocol | STATIC-DEF | 5409 | Checksum | IRREGULAR | 5410 | Reserved | STATIC-KNOWN | 5411 | Sequence Number | PATTERN | 5412 | Key | STATIC-DEF | 5413 +--------------------+---------------+ 5415 Flags 5416 The four flag bits are not expected to change for the duration of 5417 the flow, and the R flag is expected to always be set to zero. 5419 Reserved0, Version 5420 Both these fields are expected to be set to zero for the duration 5421 of any flow. 5423 Protocol 5424 This field will have the same value in all packets of a flow and 5425 is therefore classified as STATIC-DEF. 5427 Checksum 5428 When the checksum field is present, it is expected to behave 5429 unpredictably. 5431 Reserved 5432 When present, this field is expected to be set to zero. 5434 Sequence Number 5435 When present, the Sequence Number increases by one for each 5436 packet. 5438 Key 5439 When present, the Key field is used to define the flow and does 5440 not change. 5442 Appendix A.9. MINE Header Fields 5444 +---------------------+----------------+ 5445 | Field | Class | 5446 +---------------------+----------------+ 5447 | Protocol | STATIC-DEF | 5448 | S bit | STATIC-DEF | 5449 | Reserved | STATIC-KNOWN | 5450 | Checksum | INFERRED | 5451 | Source Address | STATIC-DEF | 5452 | Destination Address | STATIC-DEF | 5453 +---------------------+----------------+ 5455 Protocol 5456 This field will have the same value in all packets of a flow and 5457 is therefore classified as STATIC-DEF. 5459 S bit 5460 The S bit is not expected to change during a flow. 5462 Reserved 5463 The reserved field is expected to be set to zero. 5465 Checksum 5466 The header checksum protects individual routing hops from 5467 processing a corrupted header. Since all fields of this header 5468 are compressed away, there is no need to include this checksum in 5469 compressed packets and it can be regenerated at the decompressor 5470 side. 5472 Source and Destination Addresses 5473 These fields can be used to define the flow and are not expected 5474 to change. 5476 Appendix A.10. AH Header Fields 5478 +---------------------+----------------+ 5479 | Field | Class | 5480 +---------------------+----------------+ 5481 | Next Header | STATIC-DEF | 5482 | Payload Length | STATIC | 5483 | Reserved | STATIC-KNOWN | 5484 | SPI | STATIC-DEF | 5485 | Sequence Number | PATTERN | 5486 | ICV | IRREGULAR | 5487 +---------------------+----------------+ 5489 Next Header 5490 This field will have the same value in all packets of a flow and 5491 is therefore classified as STATIC-DEF. 5493 Payload Length 5494 It is expected that the length of the header is constant for the 5495 duration of the flow. 5497 Reserved 5498 The value of this field will be set to zero. 5500 SPI 5501 This field is used to identify a specific flow and only changes 5502 when the sequence number wraps around, and is therefore classified 5503 as STATIC-DEF. 5505 Sequence Number 5506 The Sequence Number will be incremented by one for each packet 5507 sent. 5509 ICV 5510 The ICV is expected to behave unpredictably and is therefore 5511 classified as IRREGULAR. 5513 Appendix B. Compressor Implementation Guidelines 5515 This section describes some guiding principles for implementing a 5516 ROHCv2 compressor with focus on how to efficiently select appropriate 5517 packet formats. The text in this appendix should be considered 5518 guidelines; it does not define any normative requirement on how 5519 ROHCv2 profiles are implemented. 5521 Appendix B.1. Reference Management 5523 The compressor usually maintains a sliding window of reference 5524 headers which contains as many references as needed for the 5525 optimistic approach. Each reference contains a description of which 5526 changes occurred in the flow between two consecutive headers in the 5527 flow, and a new reference is inserted into the window each time a 5528 packet is compressed by this context. A reference may for example be 5529 implemented as a stored copy of the uncompressed header being 5530 represented. When the compressor is confident that a specific 5531 reference is no longer used by the decompressor (for example by using 5532 the optimistic approach or feedback received), the reference is 5533 removed from the sliding window. 5535 Appendix B.2. Window-based LSB Encoding (W-LSB) 5537 Section 5.1.1 describes how the optimistic approach impacts the 5538 packet format selection for the compressor. Exactly how the 5539 compressor selects a packet format is up to the implementation to 5540 decide, but the following is an example of how this process can be 5541 performed for lsb-encoded fields, through the use of Window-based LSB 5542 encoding (W-LSB). 5544 With W-LSB encoding, the compressor uses a number of references (a 5545 window) from its context. What references to use is determined by 5546 its optimistic approach. The compressor extracts the value of the 5547 field to be W-LSB encoded from each reference in the window, and 5548 finds the maximum and minimum values. Once it determines these 5549 values, the compressor uses the assumption that the decompressor has 5550 a value for this field within the range given by these boundaries 5551 (inclusively) as its reference. The compressor can then select a 5552 number of LSBs from the value to be compressed, so that the LSBs can 5553 be decompressed no matter if the decompressor uses the minimum value, 5554 the maximum value or any other value in the range of possible 5555 references. 5557 Appendix B.3. W-LSB Encoding and Timer-based Compression 5559 Section 6.6.9 defines decompressor behavior for timer-based RTP 5560 timestamp compression. This section gives guidelines on how the 5561 compressor should determine the number of LSB bits it should send for 5562 the timestamp field. When using timer-based compression, this number 5563 depends on the sum of the jitter before the compressor and the jitter 5564 between compressor and decompressor. 5566 The jitter before the compressor can be estimated using the following 5567 computation: 5569 Max_Jitter_BC = 5570 max {|(T_n - T_j) - ((a_n - a_j) / time_stride)|, 5571 for all headers j in the sliding window} 5573 Where (T_n - T_j) is the difference in timestamp between the 5574 currently compressed header and a reference header and (a_n - a_j) is 5575 the difference in arrival time between those same two headers. 5577 In addition to this, the compressor needs to estimate an upper bound 5578 for the jitter between compressor and decompressor (Max_Jitter_CD). 5579 This information may for example come from lower layers. 5581 A compressor implementation can determine whether the difference in 5582 clock resolution between compressor and decompressor induces an error 5583 when performing integer arithmetics; it can then treat this error as 5584 additional jitter. 5586 After obtaining estimates for the jitters, the number of bits needed 5587 to transmit is obtained using the following calculation: 5589 ceiling(log2(2 * (Max_Jitter_BC + Max_Jitter_CD + 2) + 1)) 5591 This number is then used to select a packet format which contains at 5592 least this many scaled timestamp bits. 5594 Authors' Addresses 5596 Ghyslain Pelletier 5597 Ericsson 5598 Box 920 5599 Lulea SE-971 28 5600 Sweden 5602 Phone: +46 (0) 8 404 29 43 5603 Email: ghyslain.pelletier@ericsson.com 5604 Kristofer Sandlund 5605 Ericsson 5606 Box 920 5607 Lulea SE-971 28 5608 Sweden 5610 Phone: +46 (0) 8 404 41 58 5611 Email: kristofer.sandlund@ericsson.com 5613 Full Copyright Statement 5615 Copyright (C) The IETF Trust (2008). 5617 This document is subject to the rights, licenses and restrictions 5618 contained in BCP 78, and except as set forth therein, the authors 5619 retain all their rights. 5621 This document and the information contained herein are provided on an 5622 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 5623 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 5624 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 5625 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 5626 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5627 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5629 Intellectual Property 5631 The IETF takes no position regarding the validity or scope of any 5632 Intellectual Property Rights or other rights that might be claimed to 5633 pertain to the implementation or use of the technology described in 5634 this document or the extent to which any license under such rights 5635 might or might not be available; nor does it represent that it has 5636 made any independent effort to identify any such rights. Information 5637 on the procedures with respect to rights in RFC documents can be 5638 found in BCP 78 and BCP 79. 5640 Copies of IPR disclosures made to the IETF Secretariat and any 5641 assurances of licenses to be made available, or the result of an 5642 attempt made to obtain a general license or permission for the use of 5643 such proprietary rights by implementers or users of this 5644 specification can be obtained from the IETF on-line IPR repository at 5645 http://www.ietf.org/ipr. 5647 The IETF invites any interested party to bring to its attention any 5648 copyrights, patents or patent applications, or other proprietary 5649 rights that may cover technology that may be required to implement 5650 this standard. Please address the information to the IETF at 5651 ietf-ipr@ietf.org. 5653 Acknowledgment 5655 Funding for the RFC Editor function is provided by the IETF 5656 Administrative Support Activity (IASA).